Anais - ENUCOMP - 2017 PDF

ANAIS ELETRÔNICOS ENUCOMP 2017
1ª Edição
EDITORA
Fundação Universidade Estadual do Piauí-FUESPI
ORGANIZAÇÃO
Ricardo de Andrade Lira Rabêlo
Rodrigo Augusto Rocha Souza Baluz
Thiago Carvalho de Sousa
PROMOÇÃO
REALIZAÇÃO
PARNAÍBA – PI
2017
Ficha Catalográfica elaborada pela Bibliotecária
Christiane Maria Montenegro Sá Lins CRB/3 - 952
E56a
ENCONTRO UNIFICADO DE COMPUTAÇÃO.
(10: 2017: Parnaíba, PI).
Anais Eletrônicos ENUCOMP 2017, Parnaíba, PI, 15 a 17
de novembro de 2017: [recurso eletrônico]/ Organização
[de] Ricardo de Andrade L. Rabêlo, Thiago C. de Sousa e
Rodrigo Augusto R. S. Baluz. - Parnaíba: FUESPI, 2017.
869 p.: Il.
ISBN: 978-85-8320-201-1
1. Ciência da Computação. 2. Congressos. I. Rabêlo,

Ricardo de Andrade L. (org.) II. Baluz, Rodrigo Augusto
R. S. (org.) III. Sousa, Thiago C. de (org.)
III. Título. CDD 001.642
PREFÁCIO
Em 2008, as instituições parnaibanas que atuam no ensino superior, técnico e profissional de

informática sentiram a necessidade de criar um evento de computação maior e mais completo para a
cidade. Assim, surgiu o projeto ENUCOMP (Encontro Unificado de Computação em Parnaíba),
criado numa parceria do CEEP, FAP, IFPI e UESPI, cujas propostas foram pautadas na contribuição
para a troca de experiências, buscando a união dos acadêmicos; no fortalecimento da parceria no
desenvolvimento da educação e da informática; e no incentivo à produção de trabalhos científicos
ligados à área de tecnologia. Nos últimos anos, o ENUCOMP vem mantendo estes mesmos ideais,
mas retirou o nome Parnaíba, expandindo suas fronteiras litorâneas e se tornando um evento do
Piauí. Em sua décima edição, o evento ganha grande envergadura, confirmando o seu crescimento
consistente ano após ano. Cerca de 400 participantes vindos de diversos Estados brasileiros devem
comparecer ao ENUCOMP 2017, o que indica que já somos uma referência regional no Norte-
Nordeste do Brasil na área de Computação.
A edição deste ano, que ocorre nos dias 15, 16 e 17 de novembro, inclui treze palestras, com
temas sobre redes neurais, diagnóstico por imagem, internet das coisas, m-health , data science,
privacidade, inovação e empreendedorismo. Além disso, o evento oferece doze minicursos com
assuntos relativos à virtualização de redes, roteamento dinâmico, processamento digital, TVDi,
linguagem Go, robótica, computação em nuvem, Android, dentre outros. A programação do
ENUCOMP 2017 conseguiu montar mais uma vez um excelente Comitê de Programa, composto por
quase cinquenta pesquisadores e professores de renomadas universidades e empresas de todas as
cinco regiões brasileiras, para realizar a arbitragem de artigos por pares. Como consequência, foram
recebidos mais de 130 trabalhos, sendo selecionados apenas 79 para apresentação no evento. Os
artigos versam sobre mais de 20 áreas da computação, com destaque para Computação Gráfica, TV
Digital, Engenharia de Software, Inteligência Artificial, Informática Médica e Internet das Coisas.
Assim, neste volume dos Anais Eletrônicos do ENUCOMP 2017 o leitor encontrará os textos de
cada um dos artigos selecionados pelo Comitê de Programa e apresentados nas sessões técnicas,
bem como dos 12 minicursos ministrados.
Por último, gostaríamos de agradecer ao corpo editorial da Revista Learning and NonLinear
Models pela parceria na publicação dos 6 melhores artigos do nosso evento relativas a sua área de
atuação, bem como aos editores da Revista de Informática Aplicada (RIA) por acolher em uma
edição especial 8 dos nossos melhores artigos. O nosso muito obrigado também aos palestrantes, aos
ministrantes de minicursos e aos membros da equipe de apoio e do comitê de programa, por
acreditarem em nosso evento. O trabalho voluntário realizado por vocês foi de fundamental
importância para o sucesso do ENUCOMP. Desejamos que o evento possa trazer frutos para o
trabalho de todos.
Até a próxima!
Comissão Organizadora
ENUCOMP 2017
iii
COMISSÃO ORGANIZADORA
COORDENAÇÃO GERAL
Prof. Rodrigo Augusto Rocha Souza Baluz (UESPI/Parnaíba)
COORDENAÇÃO ADJUNTA
Prof. Antônio Oseas de Carvalho Filho (UFPI/Picos)
COMISSÃO DE FINANÇAS
Prof. Rodrigo Augusto Rocha Souza Baluz (UESPI/Parnaíba)
COMISSÃO DE MINICURSOS
Prof. Athanio de Souza Silveira (IFPI/Parnaíba)

Prof. Antonio dos Santos Sousa (IFPI/Parnaíba)
COMISSÃO DE PALESTRAS
Prof. Sérgio Barros de Sousa (UESPI/Parnaíba)

Prof. Eyder Franco Sousa Rios (UESPI/Parnaíba)
COMISSÃO DAS SESSÕES TÉCNICAS DE ARTIGOS
Prof. Ricardo de Andrade Lira Rabelo (UFPI/Teresina)

Prof. Thiago Carvalho de Sousa (UESPI/Teresina)
COMISSÃO DE INSCRIÇÕES E CERTIFICAÇÃO
Prof. Francisco das Chagas Rocha (UESPI/Parnaíba)

Prof. Leinylson Fontelene Pereira (FMN/Parnaíba)
COMISSÃO DE PATROCÍNIO
Prof. Ricardo de Andrade Lira Rabelo (UFPI/Teresina)

Prof. Henrique Rocha Fontenele (FMN/Parnaíba)
iv
COMISSÃO DE PASSAGENS E HOSPEDAGENS
Prof. Luciano Kelvin da Silva (UESPI/Parnaíba)

Profa. Lianna Mara Castro Duarte (UESPI/Teresina)
COMISSÃO DE ARTICULAÇÃO CARAVANAS
Profa. Cornélia Janayna Pereira Passarinho (UESPI/Parnaíba)
COMISSÃO DE DIVULGAÇÃO, CRIAÇÃO E ARTE
Prof. Francisco Gerson Amorim de Meneses (IFPI/Parnaíba)

Empresa TDA Informática (Polo Tecnológico de Parnaíba/SEBRAE)
COMISSÃO DA EXPO APP
Prof. Paulo César Coutinho (Polo Tecnológico de Parnaíba/SEBRAE)

Prof. Gildário Dias Lima (UFPI/Parnaíba)
COMITÊ DE PROGRAMA
Prof. Dr. Ricardo de Andrade Lira Rabêlo

Universidade Federal do Piauí (UFPI)
Prof. Dr. Thiago Carvalho de Sousa

Universidade Estadual do Piauí (UESPI)
Prof. Dr. Gildário Dias Lima

Prof. Dr. Hermes Manoel Galvão Castelo Branco

Profa. Dra. Cornélia Janayna Pereira Passarinho

Prof. Dr. Fabio de Jesus Lima Gomes

Instituto Federal do Piauí (IFPI-Teresina)
Prof. Dr. Ariel Soares Teles

Instituto Federal do Maranhão (IFMA)
Prof. Dr. Marcos Antonio de Oliveira

Universidade Federal do Ceará (UFC)
v
Prof. Dr. Carlos Giovanni Nunes de Carvalho
Profa. Dra. Atslands Rego da Rocha

Prof. Dr. Ed Porto Bezerra

Univeridade Federal da Paraíba (UFPB)
Prof. Dr. André Luiz de Oliveira

Universidade Federal de Juiz de Fora (UFJF)
Prof. Dr. Fábio Levy Siqueira

Escola Politénica da Universidade de São Paulo (Poli-USP)
Prof. Dr. Eduardo Takeo Ueda

Instituto de Pesquisas Tecnológicas do Estado de São Paulo
Prof. Dr. Flávio Rubens de Carvalho Sousa

Prof. Dr. Eyder Franco Sousa Rios

Prof. Dr. Sérgio Barros de Sousa

Prof. Dr. José de Ribamar Martins Bringel Filho

Profa. MSc. Alcilene Dalília de Sousa

Universidade Federal do Piaui (UFPI)
Prof. MSc. Romuere Rodrigues Veloso e Silva

Profa. MSc. Patricia Medyna Lauritzen de Lucena Drumond

Prof. MSc. Flávio Henrique duarte de Araújo

Profa. MSc. Patricia Vieira da Silva Barros

Prof. Dr. Francisco Airton Pereira da Silva

vi
Profa. Dra. Rafaela Vilela da Rocha Campos
Universidade Federal do ABC (UFABC)
Profa. Dra. Samáris Ramiro Pereira

Universidade de São Caetano do Sul (USCS)
Prof. Dr. Gustavo Augusto Lima de Campos

Universidade Estadual do Ceará (UECE)
Prof. Dr. Wladimir Araújo Tavares

Prof. Dr. Guilherme Guimarães Lage

Universidade Federal de São Carlos (UFSCAR)
Prof. Dr. Antônio Helson Mineiro Soares

Profa. Dra. Simone dos Santos Hoefel

Prof. Dr. Ivan Saraiva Silva

Prof. Dr. Daniel Barbosa

Universidade Federal da Bahia (UFBA)
Prof. Paulo Sérgio Marques dos Santos

Prof. MSc. José de Oliveira Brito Neto

Prof. Dr. André Castelo Branco Soares

Prof. MSc. Guilherme Enéas Vaz Silva

Prof. Dr. Rodrigo de Melo Souza Veras

Prof. MSc. Pedro Almir Martins de Oliveira

Instituto Federal do Maranhão (IFMA)
Prof. Dr. Pedro de Alcântara dos Santos Neto

vii
Prof. Dr. Fábio Anderson Silva Borges
Universidade de São Paulo (USP)
Prof. Dr. Kelson Rômulo Teixeira Aires

Prof. Dr. José Valdemir dos Reis Junior

Prof. Dr. Evandro Ottoni Teatini Salles

Universidade Federal do Espírito Santo (UFES)
Prof. Dr. Mário Sarcinelli Filho

Universidade Federal do Espírito Santo (UFES)
viii
SUMÁRIO
ARTIGOS
1. Agentes Inteligentes: conceituação e aplicações
2. Técnicas e Padrões para Otimizar a Interpretação de Código Fonte Aplicados à Fábrica de
Softwares
3. Novo Algoritmo de Ordenação Higher Count Comparado aos Demais
4. Experiência de desenvolvimento do Quiz Lógica: uma solução para aplicação do pensamento
computacional e gamificação no ensino da programação
5. Automação da horta do CTT utilizando Arduino
6. A Aplicação da Lógica de Fuzzy no Auxílio do Diagnóstico do Câncer de Mama
7. Técnica de Inteligência Computacional Aplicada na Qualificação da Rede do Assinante
8. Reconhecimento de Caracteres Manuscritos com SVM
9. DESENVOLVIMENTO DE UMA METODOLOGIA PARA PROCESSAMENTO DE
IMAGENS GEORREFERENCIADAS.
10. Análise de sentimentos de possíveis candidatos às eleições presidenciais de 2018 através da
rede social Twitter
11. Sistema Fuzzy Como Ferramenta de Apoio no Processo de Diagnóstico da Retocolite
Ulcerativa
12. Alocação Ótima de Reguladores de Tensão no Sistema Elétrico utilizando Algoritmos
Genéticos
13. VocaTeen: Um Jogo Multiplataforma Auxiliar para Orientação Vocacional de Adolescentes
14. Proposta de um Sistema para Detecção de Obstáculos Utilizando Câmera de um Smartphone
para o Auxílio a Deficientes Visuais
15. Projeto Versu: um aplicativo de legenda de filmes e seriados para surdos
16. AutoHome - Automação residencial de baixo de custo
17. Identificação de Fenômenos de Transferência Grafo-fônico-fonológica do Português
Brasileiro (L1) Para o Inglês (L2) Utilizando Frequências Formantes
18. Internet das coisas: o caminho para cidades inteligentes no Brasil
19. Análise da Segurança de Rede em um Ambiente Acadêmico: Uma Abordagem Utilizando
Pentest
20. Uma Analise da Segurança da Informação no Contexto da Vulnerabilidade Técnica do Painel
Administrativo de um Website
21. ADA: Evolução do Algoritmo do Duelista Aplicado a Problemas de Otimização Global
ix
22. Algoritmos Evolucionários Multiobjetivos para a Seleção de Casos de Teste para Sistemas
Inteligentes
23. Plataforma IoT para automação de controle IR não invasivo aplicado em ar-condicionado
24. Uma Proposta de uma Sirene Escolar Utilizando Hardware Livre Para os Colégios Técnicos
Vinculados à Universidade Federal do Piauí
25. Segmentação do Disco Óptico para Detecção Automática do Glaucoma Aplicando o
Algoritmo K-means
26. Análise de Desempenho de um Sistema Distribuído para Segmentação de Imagens da Retina
27. Estudo da Abordagem de Ensino Orientado a Projetos: Reflexos no Aprendizado de
Eletrônica Digital
28. Sistema IoT versátil para monitoramento em nuvem de sensores
29. Diagnóstico Automático do Glaucoma usando Convolutional Neural Network e Descritores
de Textura
30. APLICAÇÃO DE ALGORITMOS EVOLUTIVOS PARA RECONFIGURAÇÃO DE
REDES DE DISTRIBUIÇÃO NA PRESENÇA DE GERAÇÃO DISTRIBUÍDA
31. Análise sobre o Efeito de Fatores que Interfere na Acurácia do Registro de Temperatura em
Colmeias
32. Rootsbot
33. Desenvolvimento de uma bateria musical eletrônica sem fio com arduino e android
34. Implementação de uma solução computacional para auxiliar no processo de
acompanhamento de pacientes do Centro de Atenção Psicossocial II (CAPS): um estudo de
caso na sede de Floriano - PI.
35. Sistema Óptico Portátil para Auxílio na Análise de Marcha
36. Uma Avaliação de Desempenho sobre uma Microcloud
37. Diagnóstico Pulmonar baseado em TC usando Análise Funcional, MVS e CNN
38. Modelagem e Simulação do Deslocamento de Pessoas: uma técnica para a previsão de
formação de grupos
39. Plataforma Educacional Para Crianças com Dislexia
40. Gerenciamento agrícola utilizando dispositivos moveis através de bots telegram
41. Time analysis of attacks to USB plug-and-play by human interface device emulation and
keystroke injection
42. MATOFOBIA: Como tratar este sentimento através de um software
43. Um protótipo para automação de criatórios de peixes em uma fazenda escola utilizando
plataforma de hardware livre
44. Heurística para Geração de Configurações Radiais Não Ilhadas em Sistemas de Distribuição
45. Uma abordagem para auxílio à acessibilidade utilizando Internet das Coisas
x
46. Implementação de um módulo medidor para criação de Assinatura de cargas utilizando
Internet das Coisas
47. An approach for clustering sensor nodes by data similarity
48. Um estudo de caso utilizando o Protocolo MQTT e Internet das Coisas na Automação
Residencial
49. Protótipo computacional para averiguar a evasão acadêmica no curso de Bacharelado em
Ciência da Computação
50. Avaliação Comportamental em DoE do Protocolo PRoPHET em Redes Veiculares
Tolerantes a Atrasos
51. Um Modelo de Otimização Multi-Objetivo de Demand Response para Programação de
Carga Residencial
52. A Proposal for Route Selection in IoT Based on the Context of Specific Applications
53. Um Estudo Comparativo entre os Algoritmos de Seleção de Protótipos ENN e CNN
Aplicados ao Classificador KNN em Problemas de Diagnóstico Médico
54. Reconhecimento de gestos usando momentos invariantes de Hu e redes neurais profundas
55. O uso da técnica DAMICORE em dados de alunos do ensino superior para identificar
características de evasão
56. Um Mapeamento Sistemático sobre o uso das Redes Neurais Deep Learning e Interface
Cérebro-Computador em Eletroencefalogramas
57. Automação veicular: Um sistema de sensoriamento para dispositivos móveis baseado em
arduino
58. Um software para obtenção de resultados fidedignos ao Teste de Caminhada de 6 minutos
(TC6)
59. Benchmarking entre Ferramentas de Análise Estática de Códigos Escritos em C
60. Sistema Domótico de Baixo Custo e Eficiente Utilizando Raspberry PI e Arduino
61. Vantagens da utilização do framework SCRUM perante métodos tradicionais
62. Análise Comparativa do Algoritmo Dijkstra com e sem Desfragmentação nas Redes Ópticas
Elásticas
63. Rotulação Automática de Clusters Baseados em Análise de Filogenias
64. TECLA -- Um Módulo para Classificação de Expressões Temporais no Português Brasileiro
65. Sistema Móvel para Reconhecimento Automático de Gestos Estáticos da Linguagem
Brasileira de Sinais
66. A Implementação de Sistemas Distribuídos na Atualidade: descobrindo novas maneiras de
desenvolver computação distribuída.
67. Sistema IoT de comunicação interna por imagens
68. Uma Plataforma Distribuída para Avaliação de Desempenho em Aplicativos Móveis
xi
69. Uma Abordagem Baseada em Índices de Sensibilidade para a Determinação da Sequência de
Ajustes no Controle da Magnitude de Tensão em Sistemas de Transmissão de Energia
Elétrica
70. Avaliação do Padrão IEEE 802.15.4 para Redes Veiculares com Testes Embasados na RFC
2544
71. Avaliação de Usabilidade e Acessibilidade no Sistema de Gerenciamento de Refeitórios -
SARI
72. Desenvolvimento de aplicativo móvel para diagnosticar anemia em pequenos ruminantes
73. Modelo de arquitetura de distribuída aplicada a uma plataforma provedora de serviços
acadêmicos
74. Avaliação de Desempenho das Redes Ópticas Elásticas com Tipos Distintos de Fibras
Ópticas
75. Uma Abordagem Baseada na Máxima Estimativa de Geração de Potência Reativa para a
Determinação da Sequência de Ajustes no Controle da Magnitude de Tensão em Sistemas de
Transmissão de Energia Elétrica
76. Fundamentos da Aprendizagem Cooperativa Aplicados ao Ensino de Lógica de Programação
77. Processo de descoberta de conhecimento em base de dados de Microcefalia utilizando
Algoritmos Não-Supervisionados
78. Avaliação sobre Protocolos de Encaminhamento em Redes Veiculares Tolerantes a Atrasos e
Desconexões
79. Uma heurística para identificação de interesses transversais na escrita de histórias do usuário
MINICURSOS
1. Softwarização em Redes: Do Plano de Dados ao Plano de Orquestração
2. Roteamento Dinâmico em IoT baseado em Requisitos de Aplicações Específicas
3. Construção de Aplicações Baseadas em Física: uma Introdução ao ODE
4. Processamento Digital de Imagens Médicas com Python e OpenCV
5. Produção de Objetos de Aprendizagem Baseados em Vídeos Interativos voltados para o
ambiente TVDi
6. Uma Introdução ao Go: A Linguagem Performática do Google
7. Uma Introdução à Robótica Móvel
8. Construindo Microsserviços em Ambiente de Computação em Nuvem
9. Deep Learning: Uma Introdução às Redes Neurais Convolucionais
10. Introdução ao Desenvolvimento de Aplicativos Android Utilizando Conceitos de
Geolocalização
11. Monitoramento de tráfego em redes de Internet das Coisas
12. Introdução a análise de dados com Python e Pandas
xii
Anais Eletrônicos ENUCOMP 2017 - X Encontro Unificado de Computação - www.enucomp.com.br/2017 - ISBN: 978-85-8320-201-1
Agentes Inteligentes: conceituação e aplicações

Valter Antônio de Lima Cavalcante, Breno Jesus Sousa, Caio Victor Martins
Alves, Adonias Pedrosa de Souza Junior
Curso de Bacharelado em Sistemas de Informação – Universidade Federal do Piauí

(UFPI) – CEAD Valença do Piauí
64300-000 – Valença do Piauí – PI– Brasil
[email protected], [email protected],
[email protected], [email protected]
Abstract. With the growing desire of society for comfort and agility in daily
processes, Intelligent Agents arise within the scope of Artificial Intelligence
(IA) knowledge to serve as the basis for the construction of devices formed by
software and hardware that can interact with the medium through Sensors in
an autonomous and intelligent way. The information presented in this work
aims to bring concepts and applications of these agents in society and were
obtained through a bibliographical research in books, articles and
periodicals, in this way, was understood the great feasibility and possibilities
of applications of Intelligent Agents to solve the Problems found in society.
Resumo. Com o crescente anseio da sociedade por comodidade e agilidade

nos processos diários, os Agentes Inteligentes surgem no âmbito do
conhecimento da Inteligência Artificial (IA) para servir de base para a
construção de dispositivos formados por software e hardware que possam
interagir com o meio através de sensores de forma autônoma e inteligente. As
informações apresentadas neste trabalho tem como objetivo lhe trazer
conceitos e aplicações desses agentes na sociedade e foram obtidas através de
uma pesquisa bibliográfica em livros, artigos e periódicos, dessa forma, foi
entendido a grande viabilidade e possibilidades de aplicações dos Agentes
Inteligentes para solução dos mais variados problemas encontrados na
sociedade.
1. Introdução
Diante do crescente anseio da sociedade por comodidade e agilidade nos
processos diários, pesquisadores buscam desenvolver softwares e hardwares que podem
aprender e em muitos casos tomar decisões baseados na observância do ambiente onde
estão inseridos, ou seja, construir conhecimento através de entidades inteligentes. Dessa
forma surge a Inteligência Artificial, ou IC, para Russell & Norvig (2003), a IC pode ser
definida como um sistema ou conjunto destes criados por serem humanos que podem
atuar racionalmente e de forma autônoma. Para Poole (1998) a IC pode ser definida
como o estudo do projeto de agentes inteligentes, já Oliveira (1996) afirma que a IA é o
ramo da ciência que estuda o fenômeno da inteligência, com o objetivo de modelar e
simular comportamentos inteligentes com máquinas para resolver problemas complexos
sem ter, necessariamente, o auxílio humano. Para tanto, vários processos de raciocínio,
aprendizado e percepção são necessários.
013
2. Conceituação
Para Russel & Norvig (2003) um agente é qualquer entidade capaz de perceber o
mundo exterior através de sensores e agir neste mundo empregando atuadores. Para
Maes (1995) agentes inteligentes são sistemas computacionais que habitam algum
ambiente complexo e dinâmico e são capazes de sensoriar e atuar autonomamente neste
ambiente visando a execução de tarefas para as quais eles foram projetados. Hayes Roth
(1995) agentes inteligentes executam continuamente três funções: percebem as
condições dinâmicas do ambiente, agem alterando as condições do ambiente e
raciocinam de modo a interpretar percepções, resolver problemas, fazer inferências e
determinar ações. Nessa abordagem, os agentes são projetados para atuarem em
domínios específicos que correspondem a subconjuntos do problema principal. A
solução do problema é feita com a ajuda de todos os agentes envolvidos de maneira não
conflitante. (Gasser; Huhns, 1989; Hogg Huberman, 1991).
Brustoloni (1991) propôs uma taxonomia funcional para agentes: Agentes
reguladores (impedem funcionamentos indesejados), Agentes planejadores (antecipam
decisões), Agentes adaptativos (planejam e aprendem). Já Langton (1991) os classificam
de acordo com o ambiente que estão inseridos: Agentes de software (agentes que
buscam monitorar e apreender através de ações realizadas por um software) e Agentes
de vida artificial (agentes que observam e aprendem com os anseios oriundos do mundo
real ). Já Franklin & Graesser (1996) afirmam que um agente pode ser um programa,
mas nem todo programa pode ser um agente entendimento baseado.
3. Aplicações
Como já visto, os agentes inteligentes podem ser utilizados de diversas formas e
possuem uma vasta gama de conceitos e aplicações, a Figura 1 mostra alguma das
aplicabilidades desses agentes e como eles interagem com o meio.
Figura 1. Exemplos de tipos de agentes e suas descrições de PAES

Fonte: Russel & Norvig (2003)
014
3.1. Agentes inteligentes em Sistema de Detecção de Intrusos (SDI)

Lima (2002), coloca os agentes inteligentes como uma das principais forças
contra a detecção de intrusos em redes de computadores, afirma ela, que o uso de novas
tecnologias atuando em conjunto para aumentar o nível de segurança de uma rede
privada se faz necessário, visto que, isoladamente, nenhuma oferece um elevado grau de
segurança, permitindo simultaneamente uma certa flexibilidade e liberdade no uso de
recursos protegidos. De acordo com Crosbie e Spafford (1995) existem alguns fatores
motivadores quanto ao uso de agentes inteligentes para detectar intrusões, os quais
venham garantir as características desejáveis em um sistema de detecção de intrusos:
i) os agentes podem ser adicionados e removidos do sistema sem precisar
reinicia-lo, tornando fácil a sua manutenção e atualização;
ii) os agentes podem ser treinados para identificar novos ataques;
iii) os agentes podem ser ativados e desativados dinamicamente para realizarem
suas tarefas, proporcionando, com isso, melhor recursos do sistema;
iv) um agente pode ser configurado especificamente para necessidade de um host
ou uma rede, aumentando o poder de configuração do sistema.
3.2. Agentes Inteligentes em Jogos de Computador

Dentro do universo dos Jogos de Computadores existem diversos gêneros, cada
um suportando diversos tipos de personagens que povoam o ambiente desses jogos. A
IA é utilizada nesses jogos para controlar inimigos, parceiros e personagens de suporte.
Os inimigos podem ser por exemplo monstros, estes por sua vez, precisam ter sensores e
construir uma inteligência de forma amigável para aqueles que desfrutam dos jogos, e
dessa forma serão construídos todos os componentes desses games. Laird (2010),
criador de um dos principais projetos de IA em games, afirma que quando mais próximo
da realidade humana um personagem precisa estar, mais complexo é o desenvolvimento
do agente que estará o controlando e mais sensores ele terá para se comunicar com o
meio.
O ensino de IA pode ser outra alternativa para a utilização dos jogos, Rondolph
Jones apresenta um curso de projeto de implementação de jogos de computadores em
escolas, defendendo que devido a identificação dos alunos com os games, se cria um
ambiente ideal para o desenvolvimento de conhecimento e habilidades dos alunos no
que tange as Ciências da Computação e principalmente a IA pois os jogos atuais estão
completamente povoados de agentes inteligentes.
3.3 Agentes Inteligentes na Agricultura
Para Vieira (2017) quando é considerado as possibilidades já existentes de coleta
e dados como sensoriamento remoto, dados sobre condição de umidade e fertilidade dos
solos e mapeamento por imagens aéreas em diferentes espectros de onda dentre outros.
Além da possibilidade de conhecer fatores climáticos como temperatura, precipitação,
direção e velocidade de ventos praticamente em tempo real, têm-se a dimensão de como
os agentes inteligentes podem agir dentro da agricultura e é justamente essa gigantesca
quantidade de variáveis o maior complicador da implementação desses instrumentos
dentro do agronegócio, para ele como na maioria dos casos não há dois ambientes
015
exatamente iguais, o teste, a validação e a implantação desse tipo de tecnologia na

agricultura é muito mais trabalhoso que em outras áreas com a indústrias, varejo,
medicina ou financeira.
4. Conclusão
Com o entendimento que os Agentes Inteligentes são softwares ou hardwares
que conseguem absorver informações do meio em que estão inseridos, fazer uma análise
dessas informações e mostrar uma resposta para um outro agente ou para o meio
exterior de forma automatizada e podem ser utilizados para diversos objetivos. É notório
que com o passar dos anos eles estarão massificados nos mais variados dispositivos, e
cada vez com mais sensores. Casos como a utilização destes em projetos de SDI,
trazendo mais segurança para os ambientes privados e Jogos de Computadores,
construindo uma experiência para cada jogador de forma independente e totalmente
amigável, dão uma ideia da vasta gama de utilização, de como eles podem ser poderosos
e o quão eles podem facilitar a vida de todos.
Referências
Brustoloni, J.C. Autonomous Agents: Characterization and Requirements, Carnegie
Mellon Technical Report CMU-CS-91-204, 1991.
Franklin, S. & Graesser, A. Is it an Agent, or just a Program?: A Taxonomy for
Autonomous Agents, Proceedings of the International Workshop on Agent Theories,
Architectures, and Languages, Springer-Verlag, 1996.
Oiveira, D. P. R. de. Sistemas de Informações Gerenciais: estratégicas, táticas
operacionais 10ed. São Paulo: Atlas, 2005.
Russell, S.J. & Norvig, P., Artificial Intelligence: A Modern Approach, 2nd. Edition,
Prentice Hall, 2003.
Langton, C. (ed.) Artificial Life, Addison-Wesley, 1989.
Lima, C. F., Agentes Inteligentes para detecção de intrusos em redes de computadores.
<https://tedebc.ufma.br/jspui/bitstream/tede/316/1/Cristiane%20Lima.pdf>. Acesso
em 17 de julho de 2017.
Vieira, D. Inteligência Artificial na Agricultura: Sonho distante ou realidade?
<http://www.startagro.agr.br/inteligencia-artificial-na-agricultura-sonho-distante-ou-
realidade>. Acesso em 19 de outubro de 2010
Gasser, M. N. & Huhns, L., Themes in distributed artificial inteligence reseach. In Les
Gesser and Michel N. Huhns, editors, Pitman Publishing, 1989.
Silva, F. C. L., Agentes Inteligentes em Jogos de Computador.
<https://www.ime.usp.br/~leliane/MAC5701/2005-
1oSem/PlanosMonografias/Filipe.pdf>. Acesso em: 17 de julho de 2017.
John E. Laird and et al. Soar/games project. http://winter.eecs.umich.edu/.
Ron Coleman, Mary Krembs, Alan Labouseur, and Jim Weir. Game design &
programming concentration within the computer science curriculum. SIGCSE Bull.,
37(1):545–550, 2005. 18
016
Técnicas e Padrões para Otimizar a Interpretação de

Códigos Fontes Aplicados à Fábrica de Software
Raphael Hazin, Washington H. C. Almeida, Luciano de Aguiar Monteiro,

Anderson Cavalcanti de Lima
CESAR.EDU - Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R)
Recife, PE – Brazil
{raphaelhazin,washington.hc.almeida,lucianoaguiarthe,andclima}@gmail.c
om
Abstract. Reading the source code is generally not one of the easiest activities,
especially when we're talking about legacy code. In the software industry has just
become popular, many developers work on a source. Each one has a skill and a
different concept, thus leading to a disruption in the construction of software. The
use of patterns and techniques for optimization of interpretation will greatly assist
developers to understand the code, since it would be an easier activity when followed
with these techniques. This paper has the main objective to explore the best practices
for building / maintenance of source code showing techniques and standards
operated by big names in the field of Software Engineering.
Keywords: Clean Code, Refactoring, Software Maintenance
Resumo. A leitura de código fonte geralmente não é uma das atividades mais fáceis,
principalmente quando estamos falando de códigos legados. Na indústria de
software acaba-se tornando comum vários programadores trabalharem em um
código fonte. Cada um tem uma habilidade e um conceito diferente, levando assim
a uma desorganização na construção de um software. O uso dos padrões e técnicas
para otimização da interpretação ajudará muito aos programadores no
entendimento do código, visto que será uma atividade mais fácil quando seguida
com estas técnicas. O presente artigo terá como objetivo principal explorar as boas
práticas para a construção/manutenção de códigos fontes exibindo técnicas e
padrões explorados por grandes nomes na área da Engenharia de Software.
Palavras Chaves: Código limpo, Refatoração, Manutenção de Software.
017
1. Introdução
O ramo da Engenharia de Software tem crescido muito no decorrer dos anos, gerando
assim mais oportunidades na área. Tendo em vista que este crescimento se deve à
necessidade da informação, temos como fator adverso a falta de pessoas capacitadas para
a realização das atividades, sendo este o motivo da existência da mão de obra deficiente.
As empresas do ramo estão com prazos apertados e pressionam mais os desenvolvedores
para atingirem metas, as quais muitas vezes são impostas de forma errada. A necessidade
de celeridade e prazos apertados acaba ocasionando a construção de um algoritmo
precário e de difícil entendimento, que ocasionalmente, até pelo nível de complexidade,
pode vir a ser descartado posteriormente, especialmente em função da inviabilidade de
sua evolução.
[Martin, 2009] versa uma situação em que ele viveu, na qual uma empresa que era
responsável por um projeto desenvolvido em um nível altamente complexo com código
ilegível teve que contratar outra equipe para construir um novo código para a construção
do mesmo software, sendo desta vez com a tentativa de torná-lo mais legível e flexível
possível. Esta equipe por não conhecer boas práticas e técnicas para a reengenharia do
software viria a cair na mesma situação da equipe anterior. Percebe-se que a empresa
perdeu muito dinheiro ao contratar uma segunda equipe para desenvolver o mesmo
software. No entanto, conclui-se que, se temos um código ruim, fica difícil ou até
impossível a resolução de problemas, e, por essa razão, esses problemas acabam
encurtando a vida do sistema.
O presente artigo tem como principal objetivo guiar o programador na
estruturação do seu código fonte, seguindo boas práticas utilizadas por grandes nomes na
área da engenharia de software. O método utilizado para o levantamento do estudo e a
proposta de solução tem como origem a análise realizada em ambientes reais, junto com
uma pesquisa descritiva com a inclusão de uma pesquisa bibliográfica. Este trabalho
também tem uma visão complementar ao trabalho de [Travassos, 2011], onde o seu
objetivo foi correlacionar as práticas ágeis mais utilizadas em fábricas de software. Os
conceitos apresentados foram aplicados na Fábrica de Software Moenda Digital do Curso
de Mestrado Profissional em Engenharia de Software no CESAR.EDU1.
Este artigo encontra-se organizado da maneira que segue: o item 2 discute técnicas
e padrões para a construção das aplicações; o item 3 versa sobre a Refatoração, que é o
uso de técnicas para reescrita do código sem interferir no comportamento externo do
sistema; por fim, as considerações finais apresentaram a importância da legibilidade do
código.
2. Técnicas e Padrões para a construção das aplicações
O grupo de técnicas descrito a seguir é uma possível solução para implementações ruins
e deficientes de escrita de código fonte, mas ela, por si só, não é a Bala de Prata [Brooks,
1986]. Quando as técnicas são usadas de maneira eficiente, pode-se dizer que ajudará a
percorrer este longo caminho que é a construção de um software de. Apresenta-se, logo
em seguida, algumas técnicas para melhorar esse cenário já conhecido, separados
didaticamente para uma explanação mais clara.
1
www.cesar.edu.br – Centro de Estudos e Sistemas Avançados do Recife
018
2.1 Nomes Significativos
Devem-se usar nomes que revelem seu propósito. Não pense que investir tempo com um
bom nome para uma variável ou um objeto é algo desnecessário. Imagine-se um método
“cadastrar” e dentro da implementação do método temos alguns campos de uso da classe.
Imagine-se que o nome da classe proprietária do método seria “Pessoa”, logo a chamada
do método seria algo como “pessoa.cadastrar”. O nome parece bastante coerente. Mas
considere que na implementação do método se faça uso de alguma variável chamada “a”
ou “b” ou até mesmo “ab”, estes nomes acabam confundindo quem lê o código fonte e
não revelam nada sobre o propósito da variável.
Sempre utilize nomes fáceis de ser pronunciáveis. Não se preocupe com nomes
extensos. Vale mais um nome extenso do que um nome abreviado de difícil entendimento.
Quanto às variáveis “I”,“J”,”K” normalmente utilizadas em laços de repetições, não ha
problema algum por se tratar apenas de uma variável para contagem.
2.2 Funções/Procedimentos/Métodos
De acordo com [Martin, 2009 p.34], em sua literatura ele cita: “Só existe uma coisa
melhor do que uma função pequena é uma função menor ainda”. O código fonte não deve
conter muitos níveis de indentação, como por exemplo, métodos com “if’s” aninhados. O
método sendo um método de nível de abstração mais abaixo deve ser objetivo. O seu
nome e sua implementação devem fazer apenas uma coisa. Se no método houver a
necessidade de atender a mais de uma funcionalidade, ela deve ser separada em outra
função específica.
Nas funções, deve-se evitar a passagem de parâmetros. Eles são difíceis de

entender e dificultam a leitura do código. Para se trabalhar com parâmetros, categorizam-
se as funções em três tipos: Mônades, Díades, Tríades. Mônades é quando a função passa
apenas um parâmetro. Essa é a mais indicada por serem mais fáceis de entender. As díades
são funções um pouco mais complicadas do que as mônades por terem dois parâmetros,
dificultando um pouco mais a sua interpretação. As tríades são um caso especial, onde
uma função passa três parâmetros.
Deve-se levantar a alternativa de criar uma classe para resolver esse problema,
reduzindo assim o número de parâmetros “n” para um apenas, sendo este um objeto da
classe. Na Figura 1, é apresentanda uma classe pouco coesa onde os círculos cinza são os
métodos e os azuis atributos da classe. No fluxo à esquerda temos maior coesão e no fluxo
da direita a coesão é baixa.
Figura 1 – Representação abstrata de uma classe pouco coesa [Almeida and De Miranda
2010]
019
As funções podem ter efeitos colaterais. Isso ocorre quando uma função retorna
resultados diferentes do esperado.
Os parâmetros de uma função devem ter seus papeis bem definidos. Não é uma
boa prática passar um parâmetro de entrada e esperar seu retorno. Separe comando de
consulta. Nunca realize a união deles em uma só chamada. Um exemplo disso é escrever
uma função a qual insere um cliente, mas ao mesmo tempo você espera um resultado
indicando se a operação foi bem sucedida. Se acontecer isso, vai existir algo como “if
(cadastrarCliente)” como linha de código e, dessa maneira, parece ser algo difícil de
entender. A função cadastra um cliente. Neste caso ela seria um comando, mas o if espera
um resultado booleano, sendo assim complicada a interpretação. É meio confuso entender
que a função cadastrou o cliente e ao mesmo tempo confirmou a inclusão.
2.3 Comentários
Comentários na verdade são uma desculpa para uma escrita de código ruim. Os
comentários são partes do código que são esquecidas e que podem, em determinados
momentos, atrapalhar ou até confundir quem está a escrevê-lo. Além do mais, o
comentário deve ser revisado toda vez que o código fonte a que ele refere for alterado.
Evite poluir o sistema com autorias, citando nomes de autores ou e-mails, essa ação não
é mais necessária devido aos bons sistemas de versionamento de códigos fontes hoje
existentes. Essas ações só geram lixo no código.
Existem comentários que têm seu objetivo bem definido e que seu uso não é bem
uma desculpa, como no caso dos comentários de licença de uso do software ou direitos
autorais. Esse comentário pode ser necessário e seu uso não prejudica o entendimento do
software.
2.4 Tratamento de Erro

Parece estranho se trabalhar em tratamentos de erro em um artigo sobre boas práticas,
mas percebe-se o quanto esta atividade é importante para a composição de um código
limpo. Nos primórdios do desenvolvimento de software, algumas linguagens não
conseguiam distinguir um erro retornado por determinada ação do algoritmo.
Os tratamentos desses erros tinham que ser previstos pelos programadores através
de estruturas condicionais. Essas estruturas tinham a função de verificar um valor
esperado, que se, fora do normal, deveria retornar um código de erro. A interpretação
destes códigos de erro nem sempre era uma tarefa fácil e catalogar esses erros também
não era muito usual para os programadores.
Hoje em dia ainda existem algumas linguagens de marcação, como HTML, que,
ao obter uma reposta do servidor, retorna uma requisição com um código especifico,
sendo esse o seu comportamento usual. Os tratamentos de exceções naturalmente já são
uma poluição. As exceções em um bloco que as capturam podem tornar o código ilegível.
Uma boa pratica neste caso é criar as próprias exceções, deixando assim mais claro
e objetivo o retorno de um erro. Forneça exceções com contexto, ficando assim mais claro
020
o surgimento. O Java faz bem o uso de exceções verificadas2. Mas existe um problema
nesta prática de checagem de exceções, que seria a quebra do principio de Aberto-
Fechado3 [Martin 2009].
3. Refatoração
Com a refatoração você pode pegar um projeto ruim até mesmo caótico e transformá-lo
em um projeto bom [Fowler 2004].
Nem todos encaram isso como uma prática boa, principalmente programadores
mal disciplinados. É importante que esta técnica seja compreendida por todos no grupo
para, assim, ser aplicada corretamente. Deve-se apresentar, além da refatoração no
código, uma breve explicação ou até mesmo uma demonstração do beneficio daquela
alteração, correspondendo muitas vezes esse objetivo à remoção do acoplamento e ao
incentivo ao reuso do código.
Outro problema sério nesta abordagem é que o programador quando tem uma
missão no código a ser construído e o mesmo observa que há algo de errado e que podia
ser melhorado no trecho analisado, ele evita se envolver por que esse não é o seu objetivo
principal. A refatoração é comumente utilizada pelas equipes de desenvolvimento que
usam XP4. Esta técnica é muito utilizada para códigos legados, que são aqueles códigos
que precisam de alguns ajustes para o seu funcionamento. Este item foi escolhido para
compor o artigo por ter relações reais e verdadeiras com a re-escrita de código, mantendo
assim a sua qualidade.
Fowler [2004] enfatiza bem que deve-se considerar refatorar sistemas antigos,
identificando os pontos a serem melhorados. Mas atenção: é importante perceber que o
processo de refatoração consiste em um melhoramento do código sem a alteração do seu
resultado externo. Existem até metodologias que adotam bem essa ferramenta e incluem
como umas das suas boas práticas o uso desta ferramenta. É interessante conhecer tanto
a metodologia que a incorpora bem, como a técnica de desenvolvimento que é guiada por
testes e aplica bem este conceito, junto com algumas ferramentas que corroboram a teoria.
A refatoração é muito bem aceita pelo TDD que é uma técnica de desenvolvimento
de software cujo processo é formado por pequenas iterações para o desenvolvimento de
uma nova funcionalidade, começando pela implementação de um caso de teste, depois
pelo código necessário para fazer o teste passar, e finalmente pela refatoração do código
visando melhor acomodar as mudanças feitas. Esta prática consiste em forçar ao
desenvolvedor a criar o código do projeto, tais como classes/métodos/funções, guiado
pelos testes que identificados como cruciais para o comportamento desejado. Com o
resultado, se obtém os testes automatizados.
O Processo ágil de desenvolvimento de software XP (Extreme Programming),
criado por Kent Beck no final da década de 90, segue à risca os princípios das
2
São exceções que podem ocorrer em um determinado trecho e sendo assim previsto pelo compilador
levantando erros em tempo de compilação.
3
Entidades de software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas
para modificações”
4
Extreme Programming – Metodologia de desenvolvimento ágil para criação de softwares.
021
metodologias ágeis definidos por um grupo de programadores de mais alto nível. A

definição destes princípios se denominou manifesto ágil [Highsmith 2001].
Com a implantação das metodologias ágeis, os resultados têm melhorado a taxa
de sucesso de projetos de software conforme evidenciado no “CHAOS Report”, uma
publicação feita pelo Standish Group que compila dados sobre a indústria de software em
nível global. Na Tabela 1, podemos ver um comparativo entre processos ágeis e
tradicionais, sendo que, para a garantia do sucesso, as técnicas apresentadas nesse
trabalho são de fundamental importância.
Tabela 1. Comparativo entre Ágil x Cascata
CHAOS Resolution by Agile versus Waterfall
Size Method Successful Challenged Failed
Agile 39% 52% 9%
All Size Projects Waterfall 11% 60% 29%
Agile 18% 59% 23%
Large Size Projects Waterfall 3% 55% 42%
Agile 27% 62% 11%
Medium Size Projects Waterfall 7% 68% 25%
Agile 58% 38% 4%
Small Size Projects Waterfall 44% 45% 11%
4. Resultados
As técnicas apresentadas foram aplicadas em ambiente de fábrica de software real, no
âmbito do Mestrado Profissional em Engenharia de Software do CESAR.EDU 5 . Os
resultados da aplicação dessas técnicas, tais como boas práticas de metodologias ágeis,
colaboraram para o melhor entendimento do projeto e do software construído, visto que
a clareza do código se tornou evidente no decorrer do projeto, facilitando assim a
evolução e até mesmo a manutenibilidade do produto, sendo claro na eficácia da entrega
das funcionalidades conforme detalhados na Figura 2, que demonstra a situação do
projeto em dois momentos distintos.
Release 1 - Inicial Release 2 - Final

Não
Entreg Não
entreg Entreg
ues entreg
ues ues
49% ues
51% 88%
12%
Figura 2 - Gráfico Tarefas por Situação
As práticas melhoraram o processo de planejamento e de estimativas, encurtoram

as reuniões pela melhor clareza do código fonte e agilizaram o processo de
desenvolvimento. Na Figura 3 é apresentado um gráfico que demonstra a evolução do
desempenho da fábrica com a adoção das técnicas apresentadas nesse trabalho. Percebe-
5
http://fabricas.cesar.edu.br/moendadigital/
022
se que a clareza do código facilitou o andamento das atividades, onde no começo, sem a
utilização em sua plenitude, a linha correspondente ao trabalho executado ficou abaixo
dos valores relacionados ao trabalho planejado. Com a adoção pela equipe das técnicas
demonstradas neste trabalho, ocorreu o inverso. Nota-se esta característica no inicio do
projeto (linha azul), onde não eram utilizadas as técnicas aqui apresentadas, e no seu final
sendo atendido (linha vermelha).
Figura 3 - Gráfico Planejado x Executado
5. Considerações Finais
Existem ganhos significativos na produção de um bom algoritmo, deixando-o assim mais
fácil de ser entendido, minimizando os problemas que geram bugs no sistema. Antes das
visões aqui abordadas por profissionais e engenheiros da área, pensava-se que era
impossível manusear ou até mesmo evoluir um sistema legado. Com a adoção destas
técnicas é possível direcionar o software para um caminho mais próspero e evolutivo,
incrementando assim tanto a sua estrutura interna como suas interfaces.
É de grande valia, para o profissional da área da engenharia de software, dispender
parte do seu tempo, dando o melhor de si, refletindo assim no código-fonte escrito. Torna-
se um profissional deficiente aquele que possui habilidade, mas, por falta de vontade ou
até mesmo por prazos apertados, não aplicam as técnicas apresentadas neste trabalho.
Vale destacar que, quando o software é bem projetado e escrito, acaba se tornando a
principal fonte de documentação, evitando assim excesso de artefatos e documentos. As
IDE’s de desenvolvimento cooperam muito no processo de escrita do software,
facilitando assim a legibilidade do código.
É importante para as pessoas que estejam interessadas em trabalhar na área, pelo
menos, ter um bom entendimento dessas práticas abordadas, com fins tanto para o
desenvolvimento de um software ou até mesmo para gerência de uma equipe, com foco
em resultados e agregação de valor ao negócio, pois a tecnologia da informação é o maior
diferencial competitivo de uma organização na atualidade.
6. Referências
Almeida, L. T. and De Miranda, J. M. (2010). Código Limpo e seu Mapeamento para
Métricas de Código Fonte. Monografia de Graduação em Ciência da Computação, p.
74.
Beck, K. (1999) Extreme Programming Explained: Embrace Change. New Jersey, EUA:
Addison-Wesley.
023
Beck, Kent. (2001) “Manifesto para o desenvolvimento ágil de software”,

http://manifestoagil.com.br/, May.
Boeg, Jesper. “Kanban em 10 passos: Otimizando o fluxo de trabalho em sistemas de
entrega de software”, InfoQ Brasil. 2012.
Cruz, Fábio. (2015) “Scrum e Agile em Projetos: Guia Completo”. Brasport.
Fowler, M. (2004) Refatoração: Aperfeiçoando o projeto de código-fonte
existente, EUA: Addison-Wesley.
Jacobson, I., G. Booch, and J. Rumbaugh, “The Unified Software Development Process”,
Addison-Wesley, 1999.
Highsmith, J. et al. (2001) The Agile Manifesto. Disponível na Internet em:
http://agilemanifesto.org/ . Acesso em 27/03/2017.
InfoQ. (2015) “Chaos report 2015”. https://www.infoq.com/articles/standish-chaos-
2015, May.
Gomes, André Faria. “Agile: Desenvolvimento de software com entregas frequentes e
foco no valor de negócio”. Casa do Código, 2013.
Martin C. R. (2009), Código Limpo: Habilidades Práticas do Agile Software, EUA:
Starlin Alta Com.
Pressman, r. S. and Maxim, b. R. “Engenharia de software: uma abordagem profissional”.
8. ed. Porto Alegre: AMGH, 2016.
Royce, Winston Walker. Managing the development of large software systems, 1970.
Santos, Valério Givisiez Vilete. “A filosofia just in time como otimização do método de
produção”. Face, 2014.
Schwaber, Ken; Sutherland, Jeff. Scrum Guide. Scrum.Org and ScrumInc, 2013.
Scrum Institute, http://www.scrum-institute.org/Sprint_Burndown_Reports.php. 2017.
Sommerville, Ian. “Engenharia de Software”. 9ª Ed. São Paulo: Pearson, 2011.
Abrantes, Jose Fortuna,Travassos, Guilherme Horta. Common Agile Practices in

Software Processes, 2011
024
Novo Algoritmo de Ordenação Higher Count Comparado aos

Demais
Douglas Siqueira Gonçalves
1
Sistemas de Informação
Universidade Federal do Piauı́
Resumo. Os algoritmos surgiram a partir da matemática, estes acabaram se

tornando fundamentais na computação, sendo aprendido por estudantes no
inı́cio do seu curso universitário. Atualmente há vários tipos de algoritmos,
um destes são os algoritmos de ordenação. Sua função é ordenar um grupo de
números, em ordem crescente ou decrescente. Sua utilização é em sites de jogos,
sites de compra, além disso é ensinada em determinadas matérias da universi-
dade. Existem vários algoritmos de ordenação, um para cada caso especı́fico.
A partir do que foi discutido, este artigo tem como finalidade apresentar um
novo algortimo de ordenação chamado, Higher Count, sendo uma opção aos
desenvolvedores, nos seus sistemas e professores, em suas matérias.
1. Introdução
Na área da computação, um dos primeiros ensinamentos são os
algoritmos.[Doneda and Almeida 2016] descreve os algoritmos sendo basicamente
conjuntos de instruções para executar uma tarefa, produzindo uma saı́da de uma de-
terminada entrada. Porém, estas tarefas são das mais diversas, podendo ter calculos
matemáticos, ou até colocar um botão em uma tela. Sendo que, no inı́cio os algoritmos
foram desenvolvidos para a realização de cálculos matemáticos, porem viu-se a sua
necessidade de utiliza-los em outras formas.
Ao longo dos anos, os algoritmos deixaram de realizar apenas cáuculos
matemáticos e começaram a fazer outras tarefas, umas delas é a ordenação de valores.
A ordenação de valores existe a partir de algumas necessidades, como por exemplo, listar
as pessoas mais jovens de uma famı́lia, ou listar as maiores compras em um mercado,
desta forma surgiu os algoritmos de ordenaçao.
Atualmente há uma quantidade variada de algoritmos de ordenação, há algoritmos
que são mais comuns para ordenar valores reais, como o Bucket Sort. Existem outros
algoritmos voltados ao ensino desta técnica, exemplo o Selection Sort e o Bubble Sort.
Também existem os que realizam esta tarefa em pouco tempo, este é o caso do Count Sort
e o Quick Sort. Independente disto, todos eles tem como objetivo principal a ordenação
de valores.
Algo comum em sites de compra terem algoritmos de ordenação, isso acontece
porque os usuários desejam olhar os produtos desde os mais baratos, até os mais caros,
ou o inverso. Normalmente esta tarefa, pode ou não demorar, isto depende do algoritmo.
Por este motivo, que há diversos algoritmos de ordenação. Sendo todos estes estudados
nos cursos universitários de computação, mas alguns destes algoritmos são complicados
para o aprendizado desta técnica.
025
Sabendo destes problemas, neste artigo é apresentado o Higher Count. O Higher

Count é um algoritmo tem como objetivos ser mais uma opção para o desenvolvedor, em
seu sistema, como também, ser uma opção ao professor que ensinará os algoritmos de
ordenação.
O Higher Count é um algoritmo de fácil aprendizado, o qual pode realizar
ordenação de valores reais e também valores inteiros. Neste artigo, será apresentado o
tempo de ordenação deste algoritmo e uma comparação com os outros algoritmos ex-
istentes. Sendo esta comparação realizada em três casos distintos e os valores para a
ordenação são apenas inteiros positivos
Este artigo está dividido em 6 seções. Esta atual seção é a introdução, na segunda
seção contém os trabalhos relacionados e é realizado um comparativo. Na seção três é
explicado como funciona o Higher Count. Na seção quatro os resultados, a partir de uma
comparação entre o Higher Count com outros algoritmos existentes. Na seção cinco tem
as conclusões obtidas com este trabalho. Na seção seis, descreve-se os trabalhos futuros.
2. Trabalhos Relacionados
Esta seção, apresenta trabalhos os quais foram desenvolvidos ou modificados algoritmos
de ordenação. Na tabela 1 abaixo, verifica-se os estudos realizados com semelhanças a
este artigo. Na tabela 2, compara-se o que foi ou não realizado de acordo com as métricas
deste artigo. Em seguida é realizada uma discussão sobre cada trabalho.
Table 1. Comparação Simples Deste Artigo com os Outros
Artigo Comparação com Outros Artigos

Higher Count Comparação com outros algoritmos;
Comparação em no melhor, pior e caso aleatório;
Criação de um novo algoritmo;
[Idrizi et al. 2017] Comparação com outros algoritmos;
[Zafar et al. 2009] Comparação com outros algoritmos;
[Jadoon et al. 2011] Comparação com outros algoritmos;
Modificação de um algoritmo existente
[Qureshi 2009] Comparação com outros algoritmos;
Criação de um novo algoritmo
[Iqbal et al. 2012] Criação de um novo algoritmo;
Nos trabalhos relacionados a este, pode ser observado a utilização de diferentes

métricas para tentar comprovar a viabilidade de cada algoritmo. O artigo [IDRIZI et al.
2017], utilizou-se de diferentes vetores para ordenação, no qual cada vetor tem valores
aleatórios, inclusive valores negativos, porém não houve comparação em diferentes ca-
sos. No [ZAFAR et al. 2009], foi desenvolvido o New Friends, realizou-se comparações
separadas com cada algoritmo, ou seja, o New Friends com o Bubble, o New Friends
com o Insertion, assim, com os demais algoritmos escolhidos no trabalho. Em [IQBAL et
al. 2012], houve a criação de um novo algoritmo, chamado Concatenate Sorting, porém,
026
Table 2. Comparação Minuciosa Deste Artigo com os Outros
Artigo Comparações Comparação em Vários Casos Novo Algoritmo

Higher Count Sim Sim Sim
[Idrizi et al. 2017] Sim Não Sim
[Zafar et al. 2009] Sim Não Sim
[Jadoon et al. 2011] Sim Não Não
[Qureshi 2009] Sim Não Sim
[Iqbal et al. 2012] Nao Não Sim
no trabalho não há nenhuma comparação deste algoritmo com outros já existentes. No
[JADOON et al. 2010], houve uma modificação no algoritmo Selection Sort, desta forma,
os pesquisadores deste trabalho tiveram que comparar o novo Selection Sort com o antigo.
O trabalho [QURESHI et al. 2009], desenvolve-se um novo algoritmo, alem disso, houve
a comparação do mesmo com outros quatro(4) algoritmos.
Em todos estes trabalhos há algo em comum, nenhum deles atentou ao fato no
qual, um algoritmo pode se comportar de maneiras diferentes dependendo de cada caso.
Como já é conhecido nesta área de pesquisa, existem três (3) casos para teste, o melhor
caso, o pior caso e o caso aleatório. Em todos estes casos, houve a comparação do Higher
Count com outros algoritmos.
3. Apresentando o Higher Count

Esta seção irá destacar o Higher Count em duas partes, como o mesmo funciona e as suas
caracterı́sticas. Sendo nesta parte de caracterı́sticas, dando a sua ordem de complexidade
no pior e no melhor caso (são os casos principais para avaliar um Algoritmo), quantidade
de seleções feitas e a sua função matemática.
3.1. Caracterı́sticas do Higher Count
A partir da função do Higher Count pode ser realizado alguns cálculos, desta forma, dando
a sua ordem de complexidade(no melhor e pior caso), quantidade de loops a ser realizado,
como também a quantidade de seleções .
Primeiramente será analisado os loops realizados por esta algoritmo. Este algo-
ritmo ealiza um dois loops, um aninhado ao outro, visto na Figura 1. Com isso pode
ser determinado por conta destes loops, que o algoritmo executa em n2 de repetições.
Outro fato que pode ser determinado a partir disso é a ordem assintótica do Higher Count,
ficando com a ordem de O(n2 ), sendo esta ordem em todos os casos(Melhor, Pior e
Aleatório).
Além da ordem Assintótica, outra coisa que pode ser calculada é a quantidade
de seleções realizadas, sendo esta realizada a partir da quantidade de if dada por este
algoritmo. Em relação as seleções, foi realizado o cálculo no melhor e no pior caso. No
melhor caso a quantidade de seleções é de n2 − n, visto na Figura2. Isso acontece, porque
em todos os casos que é necessário realizar as escolhas. Já no pior caso por conta de
haver dois if’s aninhados a quantidade de seleções aumenta, visto na Figura 3, ficando na
questão matemático com (n2 − n) ∗ 2. Este valor tão alto nos dois casos é decorrente das
estruturas de repetição no algoritmo, como também do aninhado de if’s.
027
Figure 1. Definição da Ordem Assintótica e Loops do Algoritmo
Figure 2. Melhor Caso para Determinar as Seleções
3.2. Funcionamento do Higher Count
O atual algoritmo será explicado por meio da Figura 4. No Higher Count primeiramente
temos um vetor no qual entra em dois laços de repetição for, assim realizando vários
loops. Estes laços aninhados, por conta desta quantidade de loops este algoritmo se torna
lento.
Neste algoritmo há duas comparações . Na primeira comparação é verificado se
há valores iguais no vetor, caso isso aconteça, o segundo valor é descartado. A segunda
comparação é realizada a parte, o qual é dado o nome de Higher, isso porque, captura-se
o valor que é o ı́ndice do primeiro for e verifica se é maior do que o valor o qual é o ı́ndice
do segundo for. Caso seja maior é acrescentado um na variável auxiliar, sendo esta parte
chamada de Count e a comparação repetida até acabar a segunda estrutura de repetição.
No final da segunda estrutura de repetição, a variável auxliar obter um determi-
nado valor, o qual torna-se o ı́ndice do vetor resposta e é posto neste ı́ndice o valor que
estava comparando com o restante do vetor. Desta forma é o funcionamento do Higher
Count.
028
Figure 3. Pior Caso para Determinar as Seleções
Figure 4. Função de Ordenação do Higher Count na Linguagem C
4. Resultados
Nesta seção apresenta os resultados obtidos com as comparações realizadas. Foi com-
parado o Higher Count com outros seis(6) algoritmos, sendo eles, o Bubble Sort, Cock-
tail Sort, Gnome Sort, Insertion Sort, Odd-even Sort e Selection Sort. A escolha destes
algoritmos é por conta deles serem considerados lentos, em seu pior caso. Desta forma,
sendo uma comparação mais justa com Higher Count. Além disso, foi realizado testes
em três casos diferentes, o pior caso, caso aleatório e melhor caso. Isso para que haja
um teste mais amplo e também considerou tamanhos diferentes de vetores. Sendo estes
vetores com quinhentos (500), cinco mil (5000), cinquenta mil (50000) e quinhentos mil
números (500000).
É necessário resaltar, que todos os resultados apresentados neste artigo foram obti-
dos com o mesmo computador e no mesmo ambiente. O computador é um Assus pl401l,
com 8 gb de memória RAM, processador Intel core i3 com quatro núcleos, sistema op-
eracional Linux Ubuntu e a linguagem de programação C.
Todos os resultados serão apresentados por meio de um gráfico e uma tabela. No
qual, o gráfico têm a comparação dos algoritmos e na tabela o tempo de execução. Na
figura 5 abaixo, na qual compara o Higher Count com os demais Algoritmos. E nas
tabelas 3, 4, 5 e 6, apresenta o tempo de execução de cada algoritmo.
029
Table 3. Tempo de Execução com Quinhentos Mil (500000) Números
Algoritmo Melhor caso 500000 Caso aleatório 500000 Pior caso 500000
Higher Count 1232,868463 2663,632439 1239,755240
Buble Sort 588,799690 1463.619349 1035,895536
Cocktail Sort 621,026539 1418,492047 1466,701908
Gnome Sort 0,002434 812,650906 1677,652342
Insertion Sort 0,003447 357,659880 718,050629
Odd-even Sort 583,468878 1359,902906 1482,235744
Selection Sort 577,470711 1418,025073 906,758946
Table 4. Tempo de Execução com Cinquenta Mil (50000) Números
Higher Count 12,453981 27,591690 12,423620
Buble Sort 5,864671 14,375767 10,351910
Cocktail Sort 6,214735 14,244352 14,544504
Gnome Sort 0,000244 8,127140 16,250013
Insertion Sort 0,000348 3,577225 7,140689
Odd-even Sort 5,846774 13,479495 14,785380
Selection Sort 5,400492 14,110960 9,039161
(a) 500000 (b) 50000
(c) 5000 (d) 500
Figure 5. Comparação de Execução com Todos os Valores
030
Table 5. Tempo de Execução com Cinco Mil (5000) Números
Higher Count 0,124283 0,277883 0,124377
Buble Sort 0,059767 0,106947 0,103444
Cocktail Sort 6,214735 14,244352 14,544504
Gnome Sort 0,061967 0,131645 0,148063
Insertion Sort 0,000036 0,038107 0,072273
Odd-even Sort 0,059133 0,118632 0,147699
Selection Sort 0,055692 0,144027 0,090706
Table 6. Tempo de Execução com Cinquenta (500) Números
Higher Count 0,001249 0,002230 0,001251
Buble Sort 0,000595 0,001009 0,001031
Cocktail Sort 0,000634 0,001199 0,001462
Gnome Sort 0,000003 0,000841 0,001655
Insertion Sort 0,000004 0,000389 0,000715
Odd-even Sort 0,000602 0,001226 0,001482
Selection Sort 0,000550 0,001425 0,000895
Com o estudo realizado neste artigo, percebe-se que o Higher Count tem um alto
tempo de execução no melhor caso e no caso aleatório, sendo nestes dois casos, o pior
dentre os algoritmos utlizados neste trabalho. No melhor caso, isso pode ser explicado
por conta da grande quantidade de verificações e de loops o qual o Higher Count realiza.
Já no caso aleatório este, alto tempo é dado por conta do vetor resposta.
Mesmo com os problemas no melhor e no caso aleatório, o Higher Count obteve
um mehor resultado no pior caso, isso quando comparado aos demais. Sendo que neste
caso, o mesmo conseguiu o quarto melhor tempo, estando atrás do Bubble Sort, Insertion
Sort e Selection Sort. Isto ocorre por que o Higher Count realiza menos comparações em
relação aos outros algoritmos. Mesmo com o resultado obtido no seu pior caso, o seu
tempo de execução é considerado alto.
O Higher Count tem uma particularidade dos demais, pois a tendencia de todo
algoritmo é que haja uma grande diferença de tempo entre o pior e o melhor caso. Como
pode ser visto nas tabelas e gráficos apresetados nesta seção. No entanto, o Higher Count
obteve quase os mesmos tempo no pior e no melhor caso, sendo assim, um algoritmo
estável, comparando o seu melhor e o seu pior caso. Assim, em casos os quais é necessário
manter a estabilidade e sem importância ao tempo de execução, recomenda-se utilizar o
Higher Count.
Na comparação realizada nesta seção, pode ser percebido uma vantagem do In-
sertion Sort perante os outros, sendo o melhor algoritmo no caso aleatório, no pior caso
031
e o segundo melhor no melhor caso. Este destaque do Insertion Sort se dá por conta do
mesmo realizar poucas comparações. Outro algoritmo há ser destacado é o Gnome Sort,
este mesmo atingiu o melhor tempo de execução no melhor caso. Isto acontece pela sua
rápida verificação dos valores em ordem.
5. Conclusão
Pode ser concluı́do, que o Higher Count não é a melhor opção comparado com os algo-
ritmos mais conhecidos (Bubble, Selection e Inserction Sort). Entretanto, conseguiu su-
perar alguns algoritmos no pior caso. Caso este, o qual é o mais importante em testes de
ordenação. Desta maneira, se tornando uma boa opção para este caso, em especı́fico. Mas
ainda não é um bom algoritmo por conta dos seus resultados no geral. Por fim, destaca-se
a sua facilidade de aprendizado, assim, o Higher Count pode ser uma boa opção para o
ensino de algoritmos de ordenação.
6. Trabalhos Futuros
O Higher Count contém diversas problemáticas, as quais devem ser melhoradas futura-
mente. Uma delas é a impossibilidade de ordenar um vetor com dois, ou mais valores
iguais. Outro problema são os seus altos tempos de ordenação, porém, pretende-se mel-
horar o algoritmo neste fato, principalmente no caso aleatório. Caso este, que o Higher
Count esteve com uma diferença de 1200,01309 segundos, em relação ao segundo pior,
isto no teste com quinhentos mil números(500.000)
References
Doneda, D. and Almeida, V. A. (2016). What is algorithm governance? IEEE Internet
Computing, 20(4):60–63.
Idrizi, F., Rustemi, A., and Dalipi, F. (2017). A new modified sorting algorithm: A
comparison with state of the art. In Embedded Computing (MECO), 2017 6th Mediter-
ranean Conference on, pages 1–6. IEEE.
Iqbal, S. Z., Ismail, M., and Gull, H. (2012). New relative concatenate sorting algorithm.
In Computer Science and Automation Engineering (CSAE), 2012 IEEE International
Conference on, volume 1, pages 1–6. IEEE.
Jadoon, S., Solehria, S. F., and Qayum, M. (2011). Optimized selection sort algorithm
is faster than insertion sort algorithm: a comparative study. International Journal of
Electrical & Computer Sciences IJECS-IJENS, 11(02):19–24.
Qureshi, M. A. (2009). Qureshi sort: A new sorting algorithm. In Computer, Control and
Communication, 2009. IC4 2009. 2nd International Conference on, pages 1–5. IEEE.
Zafar, S., Wahab, A., et al. (2009). A new friends sort algorithm. In Computer Science
and Information Technology, 2009. ICCSIT 2009. 2nd IEEE International Conference
on, pages 326–329. IEEE.
032
Experiência de desenvolvimento do Quizz Lógica: uma solução

para aplicação do pensamento computacional e gamificação
no ensino da programação
Thalisson Sousa da Silva1 , João Gabriel Alves de Carvalho1 ,
Otávio Henrique Guimarães1 , Geraldo Abrantes Sarmento Neto1
1
Colégio Técnico de Floriano – Universidade Federal do Piauı́ (UFPI)
Floriano – PI – Brasil
Abstract. Programming learning for beginning students has been considered

a worrying issue for educators, since the unsatisfactory performance of these
youngsters often leads to high rates of retention and dropout. Aiming to avoid
this problem, by dynamizing the teaching of this subject through the insertion
of some computational thinking principles, we proposed the creation of a quiz
game which address programming logic topicss with a regionalist visual and
language: the ”Oxente! Quizz Lógica?”. This work describes the experience
about the game development by students of a vocational computer course. At
the conclusion of the process of creating that tool, we observed how the stu-
dents involved increased their knowledge in software development generating
an application with great potential to help many other students to increase their
understand about programming concepts.
Resumo. A aprendizagem de programação para alunos iniciantes vem sendo

considerada uma questão preocupante para educadores, pois o desempe-
nho muitas vezes insatisfatório desses jovens conduz a elevados ı́ndices de
reprovação e desistência de curso. Para tentar contornar essa problemática,
dinamizando o ensino dessa matéria através da inserção de alguns princı́pios
do pensamento computacional, foi proposta a criação de um jogo de perguntas
e respostas abordando temas de lógica de programação com um visual e lin-
guagem regionalistas: nasceu então o ”Oxente! Quizz Lógica?”. Este trabalho
descreve a experiência sobre o desenvolvimento dessa solução por alunos de um
curso técnico de Informática. Findando o processo de criação dessa ferramenta,
observou-se o quanto os discentes envolvidos incrementaram seus conhecimen-
tos em desenvolvimento de software através uma aplicação com grande poten-
cial para auxiliar muitos outros alunos a compreender melhor os conceitos de
programação.
1. Introdução
Tema que vem sendo muito discutido na atualidade, a inserção de noções de lógica
de programação para alunos da educação básica vem ganhando espaço como campo de
pesquisa. Na Europa e nos Estados Unidos essa tendência já é uma realidade e começa a se
consolidar, sobretudo após a adoção do modelo curricular K-12 [Oliveira et al. 2014]. No
033
Brasil, essa iniciativa ainda encontra certos entraves polı́ticos e culturais para uma efetiva
implantação, sendo observado ainda seu tı́mido crescimento em cursos técnicos e alguns
casos sendo observados envolvendo como público estudantes dos nı́veis fundamental e
médio [França and Tedesco 2015].
Não tendo contato com esses conceitos no ensino básico, o estudante de curso
de graduação tardiamente inicia seus estudos em programação, apresentando frequente-
mente dificuldades de incorporar determinados fundamentos dessa área. Especialistas
associam tal dificuldade a um conjunto de habilidades necessárias, como: capacidade ou
experiência em resolução de problemas, raciocı́nio lógico e determinado grau de desen-
volvimento cognitivo [Baidowi et al. 2013]. Essas exigências tornam-se um fardo para
muitos estudantes que apresentam quedas de desempenho [Sarmento Neto et al. 2016b].
Isso impacta negativamente no psicológico desses jovens, o que pode desmotivá-los em
continuar seguindo seus estudos na área de computação.
Pensando nessa problemática, especialistas e pesquisadores vêm aplicando
técnicas e ferramentas para dinamizar o aprendizado da programação, aumentando
a motivação dos alunos e, consequentemente, melhorando o desempenho em seus
cursos de TI. Como métodos que vêm sendo utilizados, cita-se: os jogos sérios
[Vahldick et al. 2015] e o pensamento computacional que permitem o desenvolvimento
de capacidades que contribuem no sentido de melhorar o raciocı́nio lógico dos es-
tudantes [Rodriguez et al. 2015] utilizando, por exemplo, técnicas de gamificação.
Como ferramentas, é marcante o uso do Scratch [Mota et al. 2014] e do App Inventor
[Duda et al. 2015] para esses propósitos.
Nesse sentido, este trabalho propõe relatar uma experiência sobre o desenvolvi-
mento de um jogo de perguntas e respostas para dispositivos móveis, que pode ser uti-
lizado como uma ferramenta de apoio no ensino da programação. O aplicativo foi de-
senvolvido por meio da plataforma App Inventor em forma de quiz, trazendo perguntas
sobre temas de lógica de programação com diferentes graus de complexidade; propondo
ao jogador uma forma lúdica de aprendizagem.
A criação de soluções tecnológicas com viés pedagógico no ensino de lógica de
programação vem contribuir para desenvolver um ambiente favorável à aprendizagem, au-
mentando a capacidade de construção do conhecimento por parte do aluno e promovendo
a autonomia no processo de ensino-aprendizagem.
O restante do artigo está organizado sob a seguinte estrutura: na Seção 2 são apre-
sentadas as caracterı́sticas e funcionalidades do App Inventor. Na Seção 3 são discutidas
as questões metodológicas desta pesquisa. Na Seção 4 é discutida a experiência resul-
tante do aplicativo desenvolvido. Na Seção 5 são apresentados e discutidos os trabalhos
relacionados. Finalmente, na Seção 6 são feitas as considerações finais.
2. Desenvolvimento com o App Inventor

O App Inventor é uma plataforma para desenvolvimento de aplicações para An-
droid utilizando um modelo de programação orientado a design [Gomes and Melo 2012].
Atualmente sendo mantido pelo Instituto de Tecnologia do Massachusetts (MIT - Massa-
chusetts Institute of Technology) em parceria com a Google Inc.
A plataforma é ideal para usuários inexperientes em desenvolvimento mobile e
034
pode ser utilizada como ferramenta de apoio para estudos introdutórios em lógica de
programação [Finizola et al. 2014]. Desse modo, essa solução foi desenvolvida para mi-
nimizar barreiras no que diz respeito à criação de aplicativos para smartphones e outros
dispositivos que utilizam como o sistema operacional o Android.
Vale ressaltar que a praticidade dessa ferramenta derruba a máxima de que apenas
um profissional da área da computação, dedicando muito tempo de estudos, tem poten-
cial para desenvolver um aplicativo para dispositivos móveis. Nesse sentido, não apenas
pessoas ligadas a essa área, mas todos que têm o interessante em começar a desenvol-
ver aplicativos voltados para o sistema Android, têm a capacidade de realizar tal ação de
forma bem simples e didática.
O App Inventor permanece sendo atualizado constantemente com o intuito de
melhorar sua interface e sua dinâmica, visando facilitar cada vez mais a sua utilização.
Isso contribui para tornar a plataforma mais simples e utilizável, sobretudo para aqueles
que estão iniciando no campo de desenvolvimento para Android. Dessa forma torna-se
possı́vel qualquer pessoa desenvolver seu próprio aplicativo de acordo com os componen-
tes que a plataforma disponibiliza.
A ferramenta permite que toda a programação necessária seja feita em forma de
blocos de construção. Toda a criação do aplicativo é feita de forma visual juntando seus
componente em uma tela, como uma espécie de quebra-cabeça. Conforme mostra a Fi-
gura 1, a criação de um aplicativo se desenrola por meio da seleção de componentes e
montagem de blocos, que especificam quais os atributos que a aplicação irá conter.
Figura 1. Componentes em bloco do Quizz Lógica no App Inventor
Utilizando a dinâmica do App Inventor, o usuário não fica alheio à programação,

pois a estruturação dos blocos representa comandos lógicos que precisam estar dispostos
035
como um algoritmo. O que a plataforma faz é facilitar a representação desses comandos

utilizando uma série de elementos gráficos (blocos) disponı́veis em vez de se ter apenas
um editor com um cursor esperando a entrada de um código em forma textual.
3. Materiais e Métodos
Pela sua natureza, o trabalho assumiu o caráter de estudo de caso, pois se trata de
uma investigação inicialmente particular realizada por alunos de iniciação cientı́fica júnior
do curso de Informática de um colégio técnico federal. Essa iniciativa foi pensada após
ser observado o nı́vel preocupante de desempenho verificado na disciplina de Lógica de
Programação [Sarmento Neto et al. 2016b], uma realidade também observada em escala
nacional e internacional [Gomes and Melo 2012].
Nesse sentido, este trabalho assumiu um perfil de pesquisa descritiva e qualita-
tiva. Isso é justificado principalmente devido ao seu propósito em relatar e discutir a
experiência obtida na elaboração de uma solução para auxiliar o processo de ensino e
aprendizagem em disciplinas introdutórias de programação.
Com vistas a melhor organizar as informações sobre tal experiência, optou-se por
enumerar as etapas que envolveram todo o desenvolvimento da solução proposta, desde o
planejamento até a implementação do aplicativo. Cada etapa foi então enumerada como
segue:
1. Determinar a plataforma alvo para a solução: aplicativo para desktop, Web ou
mobile?
2. Selecionar a ferramenta de edição e desenvolvimento de acordo com a plataforma
escolhida;
3. Planejar o desenvolvimento do conteúdo do aplicativo: no caso de um quiz, que
temas abordar, quantas perguntas devem ser necessárias, que nı́veis de dificuldade
abordar
4. Modelar a solução: será necessário aplicar algum método de engenharia de soft-
ware, qual será a sequência de eventos que o aplicativo deve realizar?
5. Implementar a aplicação: haja vista que todos os passos anteriores foram con-
cluı́dos, inicia-se a codificação e construção da ferramenta.
Além desses passos relacionados é necessário levar em conta o tempo e recursos
desprendidos para o desenvolvimento, bem como o nı́vel de experiência da equipe. Os
desenvolvedores da solução foram três alunos de um curso técnico de Informática que até
então tinham pouco contato com o desenvolvimento de aplicações completas.
4. Resultados e Discussão
Como já descrito, este trabalho pretende compartilhar a experiência sobre o de-
senvolvimento de uma solução que pode auxiliar o professor a dinamizar o processo de
ensino-aprendizagem de disciplinas de programação. Pensando nessa problemática, uma
equipe de alunos do curso de Informática de um colégio técnico federal se dispôs a ela-
borar um aplicativo que pudesse trazer os conteúdos dessa matéria, porém de uma forma
mais didática e dinâmica.
Pensando nisso, a plataforma alvo escolhida para essa solução foi a mobile com
sistema Android. Aplicativos para dispositivos móveis apresentam a grande vantagem
036
de sua inerente ubiquidade. Aliado a esse fato, em uma abrangência regional, há a
acessibilidade maior ao sistema em apreço devido à sua natureza aberta e maior opção
de smartphones disponı́veis atualmente que adotam esse sistema. Consequentemente, a
relação custo-benefı́cio dessa plataforma torna-se mais favorável. Essa foi a primeira
etapa no desenvolvimento da solução proposta conforme a enumeração descrita na Seção
3.
Curiosamente o objetivo inicialmente proposto era utilizar a API (Application Pro-
gramming Interface) do Android para o desenvolvimento da solução. No entanto, após os
quatro meses iniciais de projeto, percebeu-se uma dificuldade por parte desses discentes
em dominar as tecnologias necessárias. É importante ressaltar que a construção do aplica-
tivo foi uma das atividades propostas em um projeto de iniciação cientı́fica júnior em que
os alunos de um curso técnico eram participantes. Portanto lidar com noções de pesquisa
e desenvolvimento antes de uma graduação foi algo novo e desafiador para esses jovens.
Um contraponto do desenvolvimento de aplicativos por meio do uso direito da
API do Android é justamente a complexidade de sua arquitetura de desenvolvimento e as
tecnologias envolvidas, o que exige em geral uma curva maior de aprendizagem para alu-
nos com pouca experiência em programação. Por esse motivo, optou-se pela utilização
do App Inventor como ferramenta de apoio para o desenvolvimento do aplicativo pro-
posto, possibilitando que os alunos envolvidos pudessem participar mais no processo de
desenvolvimento da solução. Concluiu-se assim a segunda etapa dessa experiência.
Na terceira etapa, ao idealizar o conteúdo da aplicação, optou-se pelo uso da
gamificação por ser uma prática que traz motivações mais lúdicas. Dessa forma foi con-
cebido o embrião do “Oxente, Quizz Lógica?”: um jogo de perguntas e respostas acerca
de conceitos e fundamentos de lógica de programação tendo como base a linguagem Por-
tugol (um pseudocódigo intuitivo em Português) e utilizando elementos visuais e sonoros
com aspectos regionalistas do sertão nordestino.
Através do uso do App Inventor foi possı́vel realizar a modelagem do aplicativo
dentro da própria ferramenta através de sua dinâmica de componentes em bloco. Desse
modo, facilmente foi possı́vel realizar o sequenciamento dos eventos, dispensando, nessa
versão inicial, o uso de métodos mais formais de engenharia de software. Findou-se então
a quarta etapa.
Na quinta e última etapa, finalmente o jogo foi implementado. A equipe trabalhou
junta por um mês e meio colocando em prática o que foi planejado. Após esse lapso
temporal, o jogo ficou pronto. Conforme é exibido na Figura 2, foi dado enfoque para a
questão do regionalismo para deixar o usuário mais familiarizado com a ferramenta. Ao
utilizar a solução, o nome do usuário é solicitado e então ele segue resolvendo a uma série
de perguntas sobre lógica de programação. O aspecto da gamificação fica mais evidente
ainda quando o usuário joga o quiz com o intuito de obter uma boa pontuação e ficar bem
colocado no ranking disponibilizado no aplicativo.
Enxerga-se nessa proposta um grande potencial para motivar alunos iniciantes
em programação, pois o jogo ao mesmo tempo que tenta obter o foco do aprendiz, traz
também termos e elementos visuais regionais que certamente tornam os temas, normal-
mente vistos como um tabu na sala de aula, como algo agradável e familiar de se abordar.
Pensando nisso, pretende-se aplicar a ferramenta em turmas iniciantes de programação
037
Figura 2. Interface do Quizz Lógica
em alguns cursos técnicos de Informática com vistas a validar a eficácia da solução e do

método propostos.
A adoção de aplicativos para dispositivos móveis desenvolvidos como ferramentas
de apoio pedagógico é uma iniciativa que está sendo muito explorada no meio acadêmico.
O trabalho de [Freitas et al. 2016] descreve uma experiência sobre o desenvolvimento de
vinte e um aplicativos para o ensino da matemática em uma disciplina do mestrado profis-
sional em ensino de matemática da Universidade do Estado do Pará. Os apps contemplam
temas que vão desde problemas aritméticos simples até áreas como geometria, análise
combinatória e probabilidade.
O uso do App Inventor para estimular a aprendizagem da programação também foi
o objeto de estudo de [Duda et al. 2015] em um campus do Instituto Federal do Paraná.
É relatado, nessa pesquisa, o desenvolvimento de atividades e materiais que poderiam ser
adotados por docentes na área da matemática em suas aulas. Em um intervalo relativa-
mente curto (quatro meses), os alunos envolvidos no estudo evoluı́ram consideravelmente
em conceitos de desenvolvimento de aplicativos.
Aproximando-se mais do objetivo deste trabalho, coloca-se em pauta agora o en-
sino de programação. Tirar os alunos de uma dimensão simplesmente passiva, estática
e inseri-lo como condutor do seu próprio processo de aprendizagem, experimentando,
descobrindo, errando e depurando, é utilizar técnicas construcionistas em sala de aula.
Essa estratégia foi utilizada por [Gomes and Melo 2012] com alunos do 1o ano e 2o ano
do ensino médio de uma escola da rede pública estadual de Pernambuco. Os educadores
utilizaram o próprio ambiente da plataforma do App Inventor para incentivar os alunos a
desenvolverem seus aplicativos, aprendendo e explorando a linguagem de programação e
ferramentas do ambiente.
Para esse tipo de estratégia, julga-se importante o acompanhamento mais inten-
sivo de um orientador (professor, tutor ou monitor) para verificar também a adaptação
a ambientes que podem ser complexos para alunos presumivelmente inexperientes no
assunto. No caso do App Inventor, sua interface dinâmica somado ao seu modelo de
programação orientada a design [Finizola et al. 2014] torna-se um atrativo ao aprendiz,
sem expô-lo à complexidade inerente do desenvolvimento mobile em um nı́vel mais baixo
038
de abstração, como ocorre no desenvolvimento utilizando diretamente a API do Android

[Deitel et al. 2013].
Nas perspectiva dos jogos sérios, que trazem conteúdos educacionais através da
abordagem interativa da gamificação, muitas são as iniciativas de soluções que buscam di-
namizar o ensino da programação [Vahldick et al. 2015][Sarmento Neto et al. 2016a]. A
abordagem adotada neste trabalho segue uma linha que está situada entre a estratégia de
[Silva and Carvalho 2016] que utiliza o App Inventor como ferramenta fim no processo de
aprendizagem dos alunos e [Brito and Madeira 2015] que aplica a gamificação para tratar
o problema da motivação e participação dos alunos em uma disciplina de programação.
A proposta deste trabalho descreve o uso do App Inventor como uma ferramenta meio
buscando aplicar as técnicas do pensamento computacional principalmente nos eventuais
usuários da ferramenta construı́da, embora deva-se reconhecer que os alunos desenvol-
vedores dessa solução também tiveram essa experiência didática durante a elaboração da
aplicação.
6. Considerações Finais
Este trabalho teve como intenção descrever a experiência no desenvolvimento de
um quiz que pode servir de ferramenta de apoio ao professor nas aulas de programação,
pois vem sendo observado que é uma área em que os alunos vêm encontrando muitas difi-
culdades para assimilar o conhecimento necessário. O projeto foi desenvolvido por alunos
de iniciação cientı́fica júnior do curso técnico em Informática de um colégio técnico fe-
deral.
Essa iniciativa pretende inserir o pensamento computacional na sala de aula, to-
mando como exemplo a disciplina introdutória de Lógica de Programação, na qual vem
se observando um desempenho ruim e um alto ı́ndice de reprovações. Portanto é mister
que o professor utilize metodologias que dinamizem o processo de ensino-aprendizagem
da disciplina, tornando o aluno um agente mais ativo em busca do conhecimento e, con-
sequentemente, trazendo o motivação e melhores desempenhos desse estudante.
Nesse sentido, a solução desenvolvida neste projeto poderá ser futuramente apli-
cada como ferramenta de verificação em uma pesquisa qualitativa para se observar o im-
pacto prático do uso dessa abordagem pedagógica na sala de aula. Acredita-se que a
aplicação do pensamento computacional aliada aos aspectos interativos da gamificação
pode ajudar alunos iniciantes em programação a obter mais motivação e participação,
tornando a programação um conhecimento significativo em sua formação.
Referências
Baidowi, Z. M. P. A., Noh, N. M., and Noh, N. A. M. (2013). A study on the significance
of students’ thinking level to students’ performance. Procedia - Social and Behavioral
Sciences, 90(0):914 – 922. 6th InCULT.
Brito, A. and Madeira, C. (2015). Xp & skills: gamificando o processo de ensino de
introdução a programação. In Anais dos Workshops do Congresso Brasileiro de In-
formática na Educação, volume 4, pages 1124–1133.
Deitel, H. M., Deitel, A., and Morgano, M. (2013). Android para programadores: uma
abordagem baseada em aplicativos. Bookman Editora.
039
Duda, R., da Silva, S. d. C. R., Zontini, D. D., and Grossi, L. (2015). Elaboração de
aplicativos para android com uso do app inventor: uma experiência no instituto federal
do paraná–câmpus irati. Revista Brasileira de Ensino de Ciência e Tecnologia, 8.
Finizola, A. B., Raposo, E. H. S., Pereira, M. B. P. N., Gomes, W. S., de Araújo, A. L.
S. O., and Souza, F. V. C. (2014). O ensino de programação para dispositivos móveis
utilizando o mit-app inventor com alunos do ensino médio. In Anais do Workshop de
Informática na Escola, volume 20, page 337.
França, R. and Tedesco, P. (2015). Desafios e oportunidades ao ensino do pensamento
computacional na educação básica no brasil. In Anais dos Workshops do Congresso
Brasileiro de Informática na Educação, volume 4, page 1464.
Freitas, R. S. d. S., Santos, R. V., Pereira, M. F. F., Silva, D. C. d., and Alves, F. J. d. C.
(2016). O uso de tecnologias de informação e comunicação no processo de ensino-
aprendizagem da matemática: Desenvolvimento de aplicativos com o app inventor 2.
In XII Encontro Nacional de Educação Matemática, pages 1–8, São Paulo. Sociedade
Brasileira de Educação Matemática.
Gomes, T. C. S. and Melo, J. C. B. d. (2012). App inventor for android: Uma pro-
posta contrucionista para experiências significativas de aprendizagem no ensino da
programação. In 4o Simpósio Hipertexto e Tecnologias na Educação, pages 1–9, Re-
cife. Universidade Federal de Pernambuco.
Mota, F. P., Ribeiro, N. F., Emmendorfer, L., Butzen, P., Machado, K. S., and Adamatti,
D. F. (2014). Desenvolvendo o raciocı́nio lógico no ensino médio: uma proposta uti-
lizando a ferramenta scratch. In Brazilian Symposium on Computers in Education
(Simpósio Brasileiro de Informática na Educação-SBIE), volume 25, page 377.
Oliveira, M. L. S. d., Souza, A. A. d., Barbosa, A. F., and Barreiros, E. F. S. (2014). Ensino
de lógica de programação no ensino fundamental utilizando o scratch: um relato de
experiência. In XXXIV Congresso da SBC-XXII Workshop de Ensino de Computação,
Brası́lia.
Rodriguez, C., Zem-Lopes, A. M., Marques, L., and Isotani, S. (2015). Pensamento
computacional: transformando ideias em jogos digitais usando o scratch. In Anais do
Workshop de Informática na Escola, volume 21, page 62.
Sarmento Neto, G. A., Castro, C. d. A., Camelo, J. H., and Rabelo, R. L. (2016a). A
memory game applied to reinforce programming learning in secondary schools. In
Escola Regional de Informática do Piauı́, pages 1–6, Teresina. ERIPI.
Sarmento Neto, G. A., Silva, F. H., Silva, V. S., and Fernandes, P. B. (2016b). Análise
preliminar sobre fatores que impactam sobre o desempenho discente em programação
utilizando técnicas de mineração de dados. In Escola Regional de Informática do
Piauı́, pages 1–6, Teresina. ERIPI.
Silva, L. and Carvalho, D. (2016). Saberes davó: Uma abordagem para o ensino de
programação no ensino médio. In Anais do Workshop de Informática na Escola, vo-
lume 22, pages 1–10.
Vahldick, A., Mendes, A. J., Marcelino, M. J., Hogenn, M., and Schoeffel, P. (2015).
Testando a diversão em um jogo sério para o aprendizado introdutório de programação.
23o WEI-WORKHOP SOBRE EDUCAÇÃO EM COMPUTAÇÃO.
040
Automação da horta do CTT utilizando Arduino

Nayriane F. Carvalho, João Bezerra, José Laércio
Colégio Técnico de Teresina – Universidade Federal do Piauí( UFPI)
Teresina – PI – Brasil
{nayriane.nay,heavenwait08,laecio-silva}@hotmail.com
Abstract:This paper presents the idea of sustainability and economics in the

field of agriculture and technology using Arduino, a tool that was created to help
the small developer, the focus is to improve the rudimentary situation of the
vegetable garden in CTT and in future increase this automation for all
plantations because school it has a focus on the agricultural sector.
Resumo: Esse artigo apresenta a ideia de sustentabilidade e economia no ramo
da agricultura e tecnologia utilizando Arduino, ferramenta essa que foi criada
para ajudar o pequeno desenvolvedor, o foco é melhorar a situação rudimentar
da horta no CTT e futuramente aumentar essa automação para todas as
plantações do colégio por possuir foco no setor agrícola.
1.Introdução
A agricultura faz parte da vida do brasileiro e iniciou-se no nordeste do Brasil, no

século XVI, com a criação das chamadas “Capitanias Hereditárias” e o início do
cultivo da cana. A irrigação no Brasil surgiu no século passado, porém ainda continua
limitada devido a fatores econômicos tanto para o grande agricultor quanto o pequeno,
justamente pela falta de conhecimento da plataforma Arduino e como ela ajudaria na
infraestrutura da irrigação.
Assim, pensando no campo da tecnologia crescente existe meios para que

usuários comuns podem desenvolver sua horta sem um grande custo utilizando a
plataforma embarcada Arduino que possui um microcontrolador capaz de
desenvolver atividades de controle, interação e automação.
No intuito de causar o melhoramento da irrigação da horta do Colégio Técnico

de Teresina nosso projeto visa automatizar a irrigação que encontra-se rudimentar
para uma escola que possui meus técnicos de ensino através do curso técnico em
informática.
2.Irrigação
A irrigação tem a função de repor a água consumida pelas plantas e garantir que elas
se desenvolvam, como a irrigação deve ser feita depende do tipo de solo, relevo, clima
e cultura que deseja-se cultivar.
041
Segundo a Organização das Nações Unidas para a Agricultura e Alimentação

(FAO) de toda a água consumida no mundo, 70% são consumidos pela agricultura,
22% na indústria e somente 8% no uso doméstico. Portanto a agricultura é
considerada a grande vilã, principalmente pelo alto consumo na irrigação, portanto o
seu uso nas lavouras deverá ser feito de forma consciente em sem desperdício.[João,
2014].
O projeto está focado no consumo de água, que acaba sendo grande pela falta
de controle. As condições climáticas da região afetam diretamente a irrigação como
a intensidade das chuvas, variações de temperatura, umidade do ar e ocorrência de
ventos ao longo do ano, o conhecimento desses assuntos irá contribuir na questão de
vezes que a horta vai ser irrigada ao longo do ano e a quantidade da mesma.
O Colégio Técnico de Teresina já possui sensores que recebem dados do

aspecto climático, facilitando a irrigação por aspersão que é ligada manualmente em
determinados dias, o nosso foco é desenvolver essa irrigação usando sensores com o
uso do Arduino e assim a horta será completamente automatizada e será irrigada de
acordo com sua necessidade a fim de economizar água, energia e melhorar o cultivo
das hortaliças.
3.Arduino
O Arduino surgiu com a ideia de ser acessível para estudantes como meio para que
eles pudessem desenvolver interações e projetos com um baixo custo, por isso é uma
plataforma open source isto quer dizer que tudo relacionado ao Arduino está livre
para estudo e produção.
Segundo Michael McRoberts [2011] o Arduino pode ser utilizado para

desenvolver objetos interativos independentes, ou pode ser conectado a um
computador, a uma rede, ou até mesmo à Internet para recuperar e enviar dados do
Arduino e atuar sobre eles. Em outras palavras, ele pode enviar um conjunto de dados
recebidos de alguns sensores para um site, dados estes que poderão, assim, ser
exibidos na forma de um gráfico.
O Arduino é perfeito para o projeto de automação da horta por ser open source
assim estudando o método de irrigação adequado para a horta em conjunto com o
Arduino, os dois farão a harmonia necessária podendo expandir para outras hortas do
Colégio Técnico de Teresina ou para o quintal de um aluno. O ganho para a
agricultura familiar utilizando o Arduino é bastante eficaz para o desenvolvimento
sem um alto custo de água ou de dinheiro.
4.Dados da situação
A horta do CTT (Colégio Técnico de Teresina) possui um tamanho de 8x10m²

com uma grande variedade de hortaliças, onde 3 pessoas são responsáveis para
042
ligar e desligar a irrigação para que as hortaliças sejam aguadas todos os dias
de segunda á segunda com uma duração de 2 a 3 horas.
5.Conclusão
O projeto está começando e esperamos ter êxito na sua execução, contamos

com apoio da orientadora do projeto e também com pessoas de outras áreas
como eletrônica e agropecuária para que a ideia seja bem implementada e na
sua devida funcionalidade.
Referências
Agrosmart, Vantagens e desvantagens dos principais tipos de irrigação. Disponível em
<https://www.agrosmart.com.br/blog/vantagens-tipos-de-irrigacao/>. Acesso em 11
de Julho.2017.
Batista, João.(2014) "Manual prático de irrigação". EMATER-RI, Niterói, p. 2-19.
Cunha, K. C. B. da; Rocha, R. V. (2015) "Automação no processo de irrigação na
agricultura familiar com plataforma Arduíno". RECoDAF – Revista Eletrônica
Competências Digitais para Agricultura Familiar, Tupã, v. 1, n. 2, p. 62-74.
InfoEscola, Agricultura Brasileira. Disponível
em<http://www.infoescola.com/agricultura/agricultura-brasileira/>. Acesso em 11 de
julho.2017.
Multilógicashop, Arduino guia iniciante. Disponível
em<https://multilogicashop.com/download_guia_arduino>. Acesso em 15 de
julho.2017.
043
A Aplicação da Lógica de Fuzzy no Auxı́lio do Diagnóstico do

Câncer de Mama
Paulo Henrique Araújo da Silva1 , Rhyan Ximenes de Brito2 ,
Janaide Nogueira de Sousa Ximenes 3 , Ronieri Nogueira de Sousa 4
1
Faculdade IEducare (FIED) – Rua Conselheiro João Lourenço, 406 -
Caixa Postal 62320-000 – Tianguá – CE – Brasil
2
Instituto Federal de Educação, Ciência e Tecnologia do Ceará–(IFCE)
Av. 13 de Maio, 2081 – Caixa Postal 60040-531 – Fortaleza – CE – Brasil
3
Mestrado Acadêmico em Ciências da Computação – Universidade Estadual do Ceará (UECE) –
Av. Dr. Silas Munguba, 1700 – Caixa Postal 60.714.903 – Fortaleza – CE – Brasil
4
{paulohenriq91, rxbrito, nogueirajanaide, nsronieri}@gmail.com
Abstract. Fuzzy systems are appropriate to manipulate subjective information,

as in the scenario of this research. The main objective of this study is to define
a fuzzy system to help analyze the risks of a woman developing or already be
a carrier of breast cancer. Three variables are evaluated: age, symptoms and
risk factors. Currently, breast cancer has a high mortality rate among women
in Brazil.
Resumo. Os sistemas fuzzy são apropriados para a manipulação de

informações subjetivas, como no cenário desta pesquisa. Este trabalho tem
como objetivo principal definir um sistema fuzzy para auxiliar na análise dos
riscos de uma mulher desenvolver ou já ser portadora do câncer de mama, tendo
como medida de avalição três variáveis que são: a idade, os sintomas e os fato-
res de risco. Atualmente, o câncer de mama tem um alto ı́ndice de mortalidade
entre as mulheres no Brasil.
1. Introdução
O câncer de mama é um dos mais frequentes em todo o mundo, é a doença mais temida
pelas mulheres devido sua gravidade, evolução imprevisı́vel e mutilação, que causa sig-
nificativas alterações na autoimagem, diminuindo a autoestima[Godoy et al. 2016].
De fato o câncer de mama é o mais frequente entre as mulheres, devido
o aumento da urbanização e da industrialização de produtos, sua incidência vem
aumentando[AICR 2008]. Sobre esse aspecto, esta pesquisa objetiva auxiliar os profissi-
onais de saúde no diagnóstico dos riscos de câncer de mama em mulheres, utilizando a
lógica fuzzy.
A lógica fuzzy começou a surgir na indústria na década de 80, principalmente
na Ásia e na Europa[Weber and Klein 2003]. Também conhecida como lógica Nebulosa,
é a lógica que suporta os modos de raciocı́nio que são aproximados, ao contrário dos
044
sistemas lógicos tradicionais. Derivada do conceito de conjuntos fuzzy, a lógica cons-

titui a base para o desenvolvimento de métodos e algoritmos de modelagem e o con-
trole de processos, permitindo a redução da complexidade de projeto e implementação,
tornando-se a solução para problemas de controle que ainda são intratáveis por técnicas
tradicionais[Gomide et al. 1995].
A motivação deste trabalho está relacionada a carência de sistemas que fazem
uso da lógica não tradicional, como a lógica de Fuzzy, para auxiliar no diagnóstico de
doenças, de modo que se possa avaliar diversas variáveis e gerar uma saı́da com valores
linguı́sticos. Este trabalho está dividido em seis seções, onde a seção a seguir apresenta
os trabalhos relacionados sobre a abordagem tratada, a seguinte apresenta sucintamente
o câncer de mama feminino. Logo após, são evidenciadas as principais caracterı́sticas
de um sistema Fuzzy, sequentemente é descrita a metodologia utilizada no trabalho e
são apresentados alguns dos resultados gerados pelo sistema Fuzzy nesta pesquisa. E
finalmente são apresentadas as conclusões da abordagem e os trabalhos futuros.
Esta seção apresenta uma revisão bibliográfica sobre a utilização da lógica de fuzzy como
instrumento auxiliador na busca por respostas a diferentes problemas pesquisados na
saúde. Dessa forma é apresentado um resumo das abordagens descritas com suas princi-
pais caracterı́sticas.
[Lopes et al. 2005], propõem um sistema fuzzy que simula a atuação de um profis-
sional da saúde no diagnóstico de pacientes que apresentam sinais e sintomas de doenças
das vias áereas superiores e inferiores. A partir da compensação das trocas gasosas como
antecedente de um outro sistema baseado em regras fuzzy, é determinado se a respiração
mecânica é fraca ou forte. Desta forma, a abordagem gera um indicativo para o especia-
lista, se o indivı́duo tem condições de respirar espontaneamente.
[Ortega 2001], apresenta uma abordagem de aplicação da teoria de conjuntos
fuzzy a problemas da biomedicina. É proposto maneiras, de realizar uma junção efetiva
dessa teoria com as áreas da biomedicina, principalmente a epidemiologia. Foram elabo-
radas diversas pesquisas envolvendo, um estimador de risco fuzzy em epidemiologia, as
probabilidades de eventos epidemiológicos fuzzy, é apresentado também um processo de
decisão fuzzy para escolher uma estratégia de vacinação para o sarampo no Estado de São
Paulo, entre outras.
[Kawamura et al. 2007], nesta abordagem é proposto a utilização de um sistema
de Fuzzy, nele concentrou-se na utilização dos conceitos. Nesses termos foram analisadas
as vantagens e desvantagens dos métodos Mamdani e método Sugeno. Assim a partir das
caracterı́sticas do câncer do esôfago e dos conceitos de sistemas fuzzy foi desenvolvido
um sistema Fuzzy para diagnósticos.
[Sacchetta et al. 2002], propõem uma generalização de uma modelo epide-
miológico clássico, considerando a heterogeneidade da população. Na abordagem são
utilizados os sinais (resultados de exames diagnósticos, conjunto de sintomas, sinais
clı́nicos, etc.), são incluı́dos na dinâmica da epidemia. Assim, na abordagem, cada in-
divı́duo apresenta indicadores clı́nicos, usados para classificá-lo como infectado ou não,
por um processo de decisão fuzzy.
045
3. Câncer de Mama
O câncer de mama tem sua importância fundamentada por diversos fatores, dentre os
quais se destacam alta incidência, elevado ı́ndice de mortalidade, dificuldade para se es-
tabelecer o diagnóstico precoce e a escassez de informações quanto ao comportamento
biológico[Hegg 2000].
A doença vem acometendo progressivamente um número maior de mulheres,
em faixas etárias cada vez mais novas e com taxa de mortalidade também crescente no
Brasil[SILVA and ORTIGARA 2014].
De acordo com a análise das informações de 89 hospitais especializados no tra-
tamento de câncer e sete serviços isolados de quimioterapia ou radioterapia, referentes
a 43.442 casos de câncer de mama, mostrou que, entre 1995 e 2002, 87,7% das mulhe-
res diagnosticadas com câncer de mama encontravam-se em estágios avançados (estágio
II=42,8%, estágio III=32,6% e estágio IV=12,3%)[Thuler and Mendonça 2005].
Segundo uma outra pesquisa sobre a incidência de câncer no Brasil feita pelo
INCA, estimou-se que em 2014/2015 o Brasil teria 576 mil novos casos de câncer, a
neoplasia maligna de mama, também chamada de câncer de mama é o segundo tipo mais
frequente no mundo, respondendo por 22% dos casos novos a cada ano [INCA 2017].
Considerando as altas taxas de incidência no Brasil, existem muitas pesqui-
sas em relação aos fatores associados ao câncer de mama. Sabe-se que os mesmos
são variáveis que interferem diretamente no desenvolvimento da doenças em mulheres
[SILVA and ORTIGARA 2014].
4. Fuzzy
Considera-se que um sistema fuzzy é uma coleção de variáveis de entrada, uma coleção
de conjuntos para a variável de saı́da e uma coleção de regras que associam as entradas
para resultar em conjuntos para a saı́da. Considera-se que cada variável de entrada é uma
coleção de conjuntos [Weber and Klein 2003].
Figura 1. Demonstração de valor resultante na lógica fuzzy.
Nos sistemas lógicos binários o valor resultante pode assumir dois valores que são:
verdadeiro(1) ou falso(0). Já nos sistemas que utilizam a lógica fuzzy, os valores verdade
são expressos linguisticamente, em que cada termo linguı́stico é interpretado como um
046
subconjunto fuzzy do intervalo unitário. Conforme a Figura1 pode-se atribuir diversos

tipos de valores resposta.
A probabilidade, no contexto da lógica clássica, é um valor numérico ou um
intervalo. Na lógica nebulosa existe a opção adicional de se empregar probabilida-
des linguı́sticas, interpretados como números fuzzy e manipuladas pela aritmética fuzzy
[Kaufmann and Gupta 2003]. Os fatos citados serviram como base na criação da lógica
Fuzzy, baseando-se na lógica clássica, com acréscimo de novos operadores. Nos conjun-
tos nebulosos as leis do terceiro excluı́do e da contradição não são complacentes.
Segundo [JÚNIOR and NOVAKOWSKI 2005], os conjuntos fuzzy foram desen-
volvidos para determinar o quanto um elemento pertence ou não a um determinado con-
junto, com o uso de graus de pertinência, que são valores no intervalo [0;1]. Assim é
possı́vel determinar os elementos que pertencem a um grupo e seu respectivo grau de
pertinência.
5. Metodologia
Para a construção do modelo foram consideradas três variáveis: a idade da paciente, os
fatores de risco e os sintomas(se houver). A variável ”idade”foi classificada como: muito
jovem, jovem, madura e avançada. Essa variável é de total relevância pois, quanto maior
a idade, maiores são as chances de desenvolvimento da doença.
Na variável “fatores de risco”, foram levantados os fatores de risco
exitentes na literatura em [Ramos 2010], [Thuler 2003], [INCA 2017] e
[PIRHARDT and TERRA 2008], e selecionados os onze mais relevantes. Os fato-
res selecionados foram: hiperplasia epitelial com e sem atipia, ausência de gestação
(nuliparidade), menarca precoce, histórico de câncer na famı́lia na pré e na pós-
menopausa, menopausa tardia, dieta rica em gordura, obesidade, sedentarismo, idade da
primeira gestação após os 34 anos de idade, terapia de reposição hormonal há mais de
cinco anos e alcoolismo.
Em relação à variável ”sintomas”, foram selecionados os mais citados na literatura
em [Stein 2009], [INCA 2017] e [Marinho et al. 2003], foram elencados: Alterações do
tamanho ou forma da mama, vermelhidão, inchaço, calor ou dor na pele da mama, nódulo
ou caroço na mama, inchaço e nódulos, assimetria entre as duas mamas, presença de um
sulco na mama como se fosse um afundamento de uma parte da mama, endurecimento
da pele da mama semelhante a casca de laranja, coceira frequente na mama, formação de
crostas ou feridas na pele, liberação de lı́quido pelo mamilo, inversão súbita do mamilo,
veia facilmente observada e crescente.
O sistema possui três variáveis de entrada e uma de saı́da, está representado grafi-
camente na Figura 2. As variáveis combinadas geram 45 regras, conforme Figura 3.
O método de inferência utilizado foi o Método Sugeno e para a geração da saı́da,
foram consideradas as variáveis linguı́sticas: muito elevado, elevado, medianamente ele-
vado e pouco elevado. Para a construção do modelo foi utilizado o Fuzzy Logic Toolbox
do MATLAB , R versão 2.0.
Foram realizados os testes com 30 pacientes ficticı́as e dentre estes, foram esco-
lhidos dois casos aleatóriamente para demonstrar os resultados obtidos pelo sistema. Vale
salientar que, estes dados foram submetidos a avaliação de um especialista em oncologia
047
Figura 2. Variáveis de entrada e saı́da do sistema Fuzzy
Figura 3. Regras do Sistema Fuzzy
e os resultados do sistema Fuzzy foram validados com o diagnóstico feito pelo médico
sendo que, na maioria dos casos, os resultados foram equivalentes.
A Figura 4 representa a resposta do sistema fuzzy em relação a uma paciente com
50 anos de idade, que possui cinco fatores de risco e está com seis sintomas dos já citados
anteriormente, o sistema concluiu que a paciente possui risco muito elevado de câncer.
A Figura 5, demonstra a resposta do sistema fuzzy, de uma paciente com 30 anos
de idade, sem sintomas e que em seu histórico possui dois fatores de risco, em resposta a
situação o sistema gerou que o risco é pouco elevado.
6. Conclusão
Esse estudo foi desenvolvido com o intuito de auxiliar no processo de diagnóstico do
câncer de mama, onde as simulações foram realizadas com pacientes fictı́cias. Entretanto,
pode ser validado com dados reais e adaptado para produzir resultados confiáveis que
poderão ser utilizados por profissionais da sáude.
Como visto, o sistema poderá ser usado para auxı́lio na detecção precoce do câncer
de mama, pois quando a doença é descoberta no inı́cio as chances de cura é muito alta.
Dessa forma, o monitoramento das mulheres cuja chances de desenvolvimento de câncer
de mama for alta, permitirá o tratamento imediato em caso de aparecimento do carcinoma.
Para trabalhos futuros sugere-se o desenvolvimento de outro sistema Fuzzy, utilizando o
método Mamdani, para que possa ser comparado os resultados dos testes, podendo ser
incluı́dos outros tipos de problemáticas, como por exemplo, doenças cardı́acas, respi-
ratórias, alérgicas entre outras.
048
Figura 4. Resposta Sistema Fuzzy
Referências
AICR (2008). World cancer research fund/american institute for cancer research. food,
nutrition, physical activity, and the prevention of cancer: A global perspective.
Godoy, M. K., Soares, M., Guth, A. K., and Rezer, J. F. P. (2016). Mastectomia e estética
corporal: Uma revisão. Salão do Conhecimento, 2(2).
Gomide, F., Gudwin, R. R., and Tanscheit, R. (1995). Conceitos fundamentais da teoria
de conjuntos fuzzy, lógica fuzzy e aplicações. In Proc. 6 th IFSA Congress-Tutorials,
pages 1–38.
Hegg, R. (2000). Câncer de mama. RBM, 57(5):463–74.
INCA (2017). -. INSTITUTO NACIONAL DO CANCER Rio de Janeiro– Brasil 2017.
Disponı́vel em:<www.site.com.br/index.html>, Acessado em:22 de junho
de 2017.
JÚNIOR, I. and NOVAKOWSKI, S. (2005). Lógica fuzzy sistemas de apoio a decisão.
Rio Grande do Sul, UNISINOS, Abr.
Kaufmann, A. and Gupta, M. (2003). Introduction to fuzzy arithmetic: theory and appli-
cations. 1985. Von nostrand Reinhold Company, New York.
Kawamura, J. et al. (2007). Aplicação de um sistema fuzzy para diagnostico de cancer do
esofago.
Lopes, W. A., Jafelice, R. S. d. M., and Barros, L. C. d. (2005). Modelagem fuzzy de
diagnóstico médico e monitoramento do tratamento da pneumonia. Revista Bioma-
temática, 15:77–96.
Marinho, L. A. B., Costa-Gurgel, M. S., Cecatti, J. G., and Osis, M. J. D. (2003). Conhe-
cimento, atitude e prática do auto-exame das mamas em centros de saúde. Revista de
Saúde Pública, 37(5):576–582.
049
Figura 5. Resposta Sistema Fuzzy
Ortega, N. R. S. (2001). Aplicação da teoria de conjuntos fuzzy a problemas da biomedi-

cina. São Paulo (SP): Instituto de Fı́sica/USP.
PIRHARDT, C. R. and TERRA, K. L. (2008). Prevenção e detecção precoce do câncer de
mama: nı́vel de conhecimento dos acadêmicos do centro de ciências da saúde. Campus
Biguaçu curso de graduação em enfermagem.
Ramos, P. Z. A. (2010). Segmentação de imagens ultrassonográficas para detecção de
nódulos. PhD thesis, Universidade de São Paulo.
Sacchetta, T. E., Ortega, N., Branco, F. I. R., Menezes, R. X., and Massad, E. (2002).
Modelo Reed-Frost fuzzy para estudo de dispersão de epidemias. PhD thesis, Tese
apresentada à Faculdade de Medicina da Universidade de São Paulo para obtenção do
tı́tulo de Doutor em Medicina. São Paulo.
SILVA, A. M. d. and ORTIGARA, E. P. d. F. (2014). Fatores associados ao câncer de
mama. REVISTA CIENTÍFICA MULTIDISCIPLINAR DO CTESOP, page 23.
Stein, Airton Tetelbon, e. a. (2009). Rastreamento do câncer de mama: recomendações
baseadas em evidências. Revista da AMRIGS, 53(4):438–446.
Thuler, L. C. (2003). Considerações sobre a prevenção do câncer de mama feminino. Rev
Bras Cancerol, 49(4):227–38.
Thuler, L. C. S. and Mendonça, G. A. (2005). Estadiamento inicial dos casos de câncer de
mama e colo do útero em mulheres brasileiras. Rev bras ginecol obstet, 27(11):656–60.
Weber, L. and Klein, P. A. T. (2003). Aplicação da lógica fuzzy em software e hardware.
Editora da ULBRA.
050
Técnica de Inteligência Computacional Aplicada na

Qualificação da Rede do Assinante
Edson Brito Junior
Centro Universitário Estácio do Ceará – Fortaleza – CE – Brazil

[email protected]
Abstract. The computers network popularization, the Internet, some information

in digital format becomes more accessible. Documents, image files, sound and
video pass through all time in the network. New applications appear, it’s
distinguished among them the video conferences, and video uploads, games.
Inside this context appears the necessity to get a larger transference of bits
offered by the traditional dial-up connection, to offer this service in a high quality
for the subscribers, it’s essential for the telephone companies know the status of
subscribers’ telephone loop. With the intention to qualify the subscribers’ enlace,
the suggestion is an implantation of a methodology through knowledge
extraction, using the stored information in database of measures subscribers’
loop.
Resumo. Com a popularização da rede mundial de computadores, a Internet,

informações no formato digital tornam-se mais acessíveis. Documentos, arquivos
de imagem, áudio e vídeo trafegam em todo instante na rede. Novos aplicativos
surgem na rede, entre eles destacam-se as conferências, descarregamento de
vídeo, jogos etc. Dentro deste contexto surge a necessidade de se alcançar taxas
de bits maiores, para que este serviço seja oferecido com excelente qualidade ao
assinante, é de fundamental interesse para as operadoras conhecer o estado do
enlace telefônico deste assinante. Com intuito de qualificar o enlace do
assinante, propõe-se neste trabalho experimentos com Mineração de Dados para
extrair conhecimentos das informações armazenadas em uma base de dados
referentes às medidas dos parâmetros físicos da rede dos assinantes.
1. Introdução
Com o constante surgimento de novos aplicativos na Internet, e com a grande

evolução do processamento de dados, torna-se cada vez mais difícil manter o
gerenciamento e qualidade dos serviços e da infraestutura dessa rede.
Uma maneira de avaliar o estado atual do enlace é conhecer os valores de medições
dos parâmetros físicos conhecidos como: função de transferência, impedância de entrada e
parâmetro de espalhamento S11, com isso as operadoras podem chegar a um resultado mais
preciso sobre a atual condição do enlace local do assinante. Essa avaliação é conhecida
como Qualificação do enlace (Loop Qualification). Diante disso, surgem inúmeras
possibilidades de utilizar as informações armazenadas na base de dados para extrair
conhecimento e tomada de decisões quanto ao melhoramento e ao aumento da taxa de bits
entregue ao assinante.
O principal objetivo deste artigo é apresentar experimentos com o uso da técnica de
inteligência computacional usando uma base de dados de medições dos parâmetros físicos
051
do enlance local do assinante, ressaltando a sua importância na utilização desses modelos

para se classificar um enlace com presença ou não de extensões (classe binária).
Este artigo está organizado da seguinte maneira: Na Seção 2, são revisados os
conceitos importantes sobre o enlace local do assinante e da mineração de dados. Na Seção
3, é descrito a metodologia para os experimentos de classificação binária. Na Seção 4, são
apresentados os resultados obtidos a partir desses classificadores. Na Seção 5, é visto a
análise dos resultados para o teste dos classificadores e finalmente, na Seção 6 são
apresentadas as considerações finais.
2. Fundamentos
Enlace Local do Assinante
Segundo (MUNCINELLI, 2001) o enlace telefônico de par trançado é chamado de

enlace local do assinante. Sendo assim, pelo fato de possuir várias topologias de
comprimentos variáveis e muitas vezes maiores que 3 km são constituídos de uma ou mais
seções e extensões. Uma extensão (bridge tap) é qualquer comprimento de cabo que não
esteja dentro do caminho central telefônica/modem do assinante. Por exemplo, um par
utilizado anteriormente para outro aparelho telefônico, que continua conectado em uma
posição intermediária. A existência de uma extensão não é fator determinante para o
impedimento de um serviço DSL, mas sim o seu comprimento.
Mineração de Dados
Segundo (FAYYAD et al., 1996) Mineração de Dados é um conjunto de técnicas

computacionais para a extração de informações desconhecidas e potencialmente úteis em
grandes volumes de dados por meio de um resumo compacto dos mesmos. O termo
“mineração de dados” é uma das etapas de um processo maior denominado descoberta de
conhecimento em banco de dados (KDD - Knowledge Discovery in Databases (KDD).
Os métodos de Mineração de Dados requerem diferentes necessidades de pré-
processamento (GOLDSCHMIDT, 2015). Tais necessidades variam em função do aspecto
extensional da base de dados em que o método será utilizado. Em decorrência da grande
diversidade de métodos de pré-processamento de dados, são muitas as alternativas
possíveis de combinações entre métodos. A escolha dentre estas alternativas pode
influenciar na qualidade do resultado do processo de KDD (MORIK, 2000).
3. Metodologia para os Experimentos de Classificação Binária
A metodologia para a proposta dos experimentos neste artigo consiste nas etapas
mostradas na Figura 1. A primeira etapa consiste na coleta e seleção de dados obtidos
através das medições do módulo da função de transferência |FT|, do módulo do parâmetro
de espalhamento S11 |PE| e da impedância de entrada |IE|, a partir das bases de dados de
medições do enlace local do assinante compostas por cabos reais e simuladores de linha.
(JUNIOR, 2008). Na segunda etapa, o pré-processamento dos dados, consiste de um
tratamento estatístico dos dados selecionados na etapa anterior, com a intenção de se
identificar os erros de natureza sistemáticas e/ou aleatórios cometidos nos processos de
medição. A terceira etapa consiste na transformação dos dados originais obtidos através da
052
primeira etapa, tais dados foram trabalhados de forma, que os mesmos possam facilmente
ser utilizados na construção dos classificadores.
Figure 1. Diagrama da Implementação da Metodologia.
A Figura 2 mostra a composição da base de dados de medições, composta pelos

valores dos parâmetros citados acima. A base de dados é formada por 1430 instâncias e
quatro atributos (incluindo a classe 0 sem extensão ou 1 com extensão) do tipo numérico.
Figura 2. Composição da Base de Dados de Medições.
Na quarta etapa utilizou-se a Mineração de Dados que consistiu na construção dos

classificadores. Para essa etapa foi utilizado o pacote de mineração de dados Waikato
Environment for Knowledge Analysis – WEKA (WEKA, 2017). A quinta etapa consistiu
da interpretação e avaliação dos resultados para análise da presença de extensões na rede.
4. Os Experimentos
Classificador Binário com Redes Neurais Artificiais (RNA)

O classificador binário RNA nos dados do elance local do assinante, consistiu em
avaliar diferentes topologias com duas ou cinco camadas intermediarias como mostrado na
Figura 3(a) e 3(b).
(a) (b)
Figura 3. (a) RNA para o Classificador Binário com duas camadas intermediárias. (b) RNA
para o Classificador Binário com cinco camadas intermediárias.
053
A Tabela 1 contém os dados usados para a construção da RNA. Para o treinamento,

validação e teste da RNA, admitiram-se um erro mínimo desejado entre a resposta da RNA
e a resposta desejada de 0.08.
Tabela 1. RNA com duas e cinco camadas intermediaria e taxas de aprendizagem.
Topologia Nº de Camadas Taxa de MSE de MSE de MSE de

da Intermediarias
Aprendizagem Train. Valid. Test.
RNA
1 2 0.001 0.05322 0.04519 0.03301
2 2 0.01 0.05280 0.04422 0.02924
3 2 0.02 0.05253 0.04410 0.02845
4 2 0.04 0.05189 0.04384 0.02253
5 2 0.8 0.05225 0.04456 0.01290
6 2 1.0 0.05175 0.04460 0.01256
7 5 0.001 0.05225 0.04443 0.03115
8 5 0.04 0.05212 0.03980 0.03062
9 5 0.8 0.05475 0.02647 0.01747
10 5 1.0 0.05345 0.03798 0.02869
O gráfico da Figura 4 mostra a evolução de erro do classificador nas etapas de

treino, validação e teste da RNA ao longo do processo de aprendizagem para cada
topologia testada. Verifica-se que para todos os casos a RNA conseguiu classificar de
maneira adequada os padrões que lhe foram apresentados.
Figura 4. Taxa de Erro para do Classificador RNA x Taxa de Aprendizagem da Rede.
Classificador Binário com Árvore de Decisão

Segundo (MITCHELL, 2001) a árvore de decisão gerada pelo algoritmo J4.8 é
baseada no princípio que o algoritmo tende a gerar árvores menores (teoria mais simples) a
partir das instâncias de treinamento, utilizando a heuristica da entropia.
A Tabela 2 contém os dados usados para a construção da Árvore de Decisão. Para
as etapas de treinamento, validação e teste utilizaram-se alguns valores para os parâmetros:
fator de confiança e para o número mínimo de objetos por folha.
054
Tabela 2. Configuração da Árvore de Decisão.
Fator Nº de MSE MSE MSE

de Objetos de de de
Confiança Minímos Train. Valid. Test.
(C) (M)
0.15 2 0.0701 0.0590 0.0468
0.35 2 0.0570 0.0402 0.0059
0.55 2 0.0541 0.0400 0.0005
0.15 3 0.0713 0.0590 0.0468
0.35 3 0.0610 0.0450 0.0059
0.55 3 0.0558 0.0420 0.0055
0.15 5 0.0727 0.0590 0.0468
0.35 5 0.0690 0.0463 0.0081
0.55 5 0.0633 0.0390 0.0076
No que diz respeito aos valores obtidos na Tabela 2, percebe-se que o melhor
resultado segundo o MSE de treinamento, validação e teste foi alcançado com os valores de
0.55 para o fator de confiança e 2 para o número mínimo de objetos por folha. Neste caso,
optou-se por esses valores de parâmetros para a construção do classificador binário J4.8.
Para validação e estimação da acurácia de testes, foi utilizado o método 10 fold Cross-
Validation, sendo gerada a árvore de decisão apresentada na Figura 5.
Figura 5. Árvore de Decisão para o classificador J4.8.
Os valores da acurácia (percentual de classes preditas corretamentes) obtidos na

utilização da árvore de decisão J4.8 estão apresentados na Figura 6. Tais resultados
expressam o desempenho do classificador binário para as etapas: treino, validação e teste.
Como pode ser observado nas estatísticas do classificador avaliado, houve uma melhora
que diz à acurácia de teste.
055
Figura 6. Acurácia de Testes para a Árvore de Decisão do classificador J4.8.
Classificador Binário com K-NN

O classsificador K-NN consiste no aprendizado baseado na analogia dos elementos
da base de dados. Para o conjunto de treinamento cada elemento deste conjunto representa
um ponto no espaço n-dimensional (BOSCARIOLI et al.,2008).
A metodologia desse classificador para determinar a classe de um elemento que não
pertença ao conjunto de treinamento é a seguinte: o classificador K- NN procura K
elementos do conjunto de treinamento que estejam mais próximos deste elemento
desconhecido. Estes K elementos são chamados de K-vizinhos mais próximos. Verifica-se
quais são as classes desses K vizinhos e a classe mais freqüente será atribuída à classe do
elemento desconhecido.
A Tabela 3 com a variação do número de K-vizinhos (1 a 15 vizinhos mais
próximos) e os valores obtidos para MSE em relação às etapas de treino, validação e teste
do classificador binário com K-NN.
Tabela 3. Variação do K-NN e o MSE do Classificador.
K- MSE MSE MSE

Vizinhos
de de de
Train. Valid. Test.
1 0.0520 0.0113 0.0041
3 0.0471 0.0273 0.0041
5 0.0526 0.0350 0.0056
7 0.0499 0.0372 0.0057
10 0.0513 0.0356 0.0088
12 0.0497 0.0421 0.0221
15 0.0528 0.0423 0.0213
A Figura 7 compara os resultados obtidos variando o valor de K a partir desta

métrica.
Figura 7. Acurácia de Testes para o classificador K-NN.
056
Classificador Binário com Naive Bayes

O classificador binário com Naive Bayes calcula a probabilidade de uma instância
pertencer a cada uma das classes pré-determinadas, assumindo que não há independência
entre os atributos que descrevem a instância (DOMINGOS et al., 1997).
O classificador binário Naive Bayes foi induzido a partir do conjunto de
treinamento apresentado, utilizando para a validação e estimação da acurácia de teste o
método 10 fold Cross-Validation. Os valores estatisticos do MSE obtidos da utilização
deste classificador estão apresentados na Tabela 4.
Tabela 4. Estatisticas do Classificador Binário Naive Bayes.
Treino Validação Teste
Instâncias Corretamente Classificadas 91.2% 94 % 92 %
Instâncias Erroneamente Classificadas 8.8 % 6% 8%
Erro Quadrático Médio (MSE) 0.0691 0.0511 0.0621
5.Análise dos Resultados
Os experimentos realizados neste trabalho podem ser analisados utilizando o valor

médio da acurácia dos classificadores RNA, J4.8 e K-NN, isto se dá devido a utilização de
diferentes valores de parâmetros, para melhor obtenção da acurácia dos modelos. Porém,
para o classificador binário Naive Bayes não foi utilizada essa média pelo fato do mesmo
não oferecer possibilidade de escolha de um parâmetro adequado. A Figura 8 compara os
classificadores nesta métrica.
Figura 8. Acurácia de Testes dos Diferentes Classificadores.
Considerando os valores obtidos do erro quadratico médio MSE, pode-se avaliar a

relação desse parâmetro estatístico com os valores das acurácias. Através da Figura 9
percebe-se que o classificador K-NN possui nas etapas de treino, validação e teste os
menores resultados para o erro MSE.
Figura 9. Comparativo das Estatísticas do MSE dos Classificadores.
057
6.Considerações Finais
Dentro da proposta deste trabalho ressaltou-se que as informações contidas na base

de dados das operadoras, quando obtidas de forma confiáveis, permitem que a tarefa de
qualificação do enlace seja feita através das medições dos parâmetros físicos. Diante desse
fato, a contribuição desse tabalho se deu na descoberta de conhecimento contido em tais
medições. Os resultados obtidos para cada experimento foram comprovados pela obtenção
da acurácia, e do parâmetro estatístico MSE de cada modelo obtido. Dentre esses
resultados alguns foram obtidos variando os parâmetros importantes dos classificadores
escolhidos.
Neste ponto é relevante dizer que todos os classificadores obtidos neste trabalho
quando utilizados de forma adequados, fornecem resultados confiáveis para tomada de
decisões pelas operadoras de serviços DSL. Porém, do ponto de vista mais eficiente, em
relação a sua estrutura e escolha dos seus parâmetros adequados, a Rede Neural é a que
permite melhor utilização da descoberta de detecções de extensões no cenário de estudo
deste trabalho. Em relação a trabalhos futuros tem-se a possibilidade de combinar mais de
uma técnica. Desse modo se fará a utilização de técnicas de inteligência computacional
hibrída melhorando ainda mais o desempenho dos experimentos.
Referências
BOSCARIOLI, CLODIS; TABUSADANI, F. YUKIO; BIDARRA, JORGE. O uso
Integrado de K-NN e Scatter Plots 2D na Mineração Visual de Dados. UNIOESTE
– Paraná, 2008.
DOMINGOS, PEDRO; PAZZANI, MICHAEL. “On the optimality of the simple

Bayesian classifier under zero-one loss”. Machine Learning, 29:103-137. 1997.
FAYYAD, U. M.; PIATETSKY-SHAPIRO, G.; SMYTH, P. From Data Mining to

Knowledge Discovery: An Overview. Knowledge Discovery and Data Mining, Menlo
Park: AAAI Press, 1996.
GOLDSCHMIDT, R.; PASSOS, E. Data Mining um Guia Prático. Rio de Janeiro,

Elsevier, 2015.
JUNIOR, E. B. Metodologia para a Medição de Parâmetros Relacionados com a

Qualificação do Enlace Digital do Assinante. Dissertação de Mestrado, UFPA-Belém-
PA, 2007.
MITCHELL, TOM M. Machine Learning. McGraw-Hill, 2001.
MORIK, K. The Representation Race – Preprocessing for Handling Time Phenomena.

Proceedings of the European Conference on Machine Learning 2001, Lecture Notes in
Artificial Intelligence 1810. Berlin: Springer Verlag, 2001.
MUNCINELLI, GIANFRANCO. Qualificação de Linha para Serviço ADSL. Anais do

CININTEL 2001 – IV Congresso Internacional de Infraestrutura para
Telecomunicações, 2001.
WEKA(visitado em junho, 2017). http://www.cs.waikato.ac.nz/ml/weka. Nova Zelândia,

2017.
058
Reconhecimento de Caracteres Manuscritos com SVM

Francisco W. Rodrigues Jr.1 , Iális C. de Paula Jr. 1
1
Universidade Federal do Ceará (UFC)
Sobral – Ce – Brasil
Abstract. Handwriting recognition is an important area of study, encompas-

sing knowledge of the areas of pattern recognition and digital image processing
(PDI). This work addresses a combination of histogram and contour projection
features extraction techniques applied to a Support Vector Machine (SVM) with
the One-On-One classification strategy for multiple classes configured for the
MNIST database. At the end, the results achieved with the proposed approach
are presented.
Resumo. O reconhecimento de caracteres manuscritos é uma área de estu-

dos importante, abrangendo conhecimentos das áreas de reconhecimento de
padrões e processamento digital de imagens (PDI). Este trabalho aborda uma
combinação das técnicas de extração de caracterı́sticas projeção de histogra-
mas e de contorno, aplicadas a uma Support Vector Machine (SVM) com a
estratégia de classificação Um Contra Um para múltiplas classes, configura-
das para a base de dados MNIST. Ao final, são apresentados os resultados
alcançados com a abordagem proposta.
1. Introdução
O reconhecimento de caracteres manuscritos ou handwritten character recognition
(HCR) é uma desafiadora área de processamento digital de imagens (PDI) e de reco-
nhecimento de padrões [Pradeep et al. 2012],[Mori et al. 1995]. Os caracteres manuscri-
tos por apresentarem diversas variações de estilos e formas de escrita tornam o processo
de reconhecimento por parte das máquinas mais difı́cil. Devido isso, diversos trabalhos
na literatura abordam a utilização de diferentes técnicas de extração de caracterı́sticas e
métodos de inteligência computacional em busca de minimizar esse problema, reduzindo
o tempo de execução e elevando a precisão do HCR [Kumar et al. 2012].
O HCR pode ser dividido em duas categorias, online e offline
[Plamondon and Srihari 2000],[Kumar et al. 2012],[Pradeep et al. 2012]. No pri-
meiro, os caracteres gerados são processados no instante em que são criados, avaliando
as coordenadas bidimensionais de pontos sucessivos como uma função temporal e a
ordem dos traços gerados. No segundo, os documentos são digitalizados e armazenados
em um computador para que sejam processados posteriormente. E devido as inúmeras
aplicações utilizando técnicas de inteligência computacional, esses sistemas são mais
explorados cientificamente em busca de altos nı́veis de precisão para reconhecimento de
caracteres [Kumar et al. 2012].
Embora diferentes sistemas HCR possuam o mesmo objetivo, cada um trabalha
em determinado domı́nio, ou seja, não é possı́vel projetar um sistema genérico capaz de
059
processar todos os scripts e idiomas [Rao et al. 2016]. Neste trabalho é utilizado a base de
dados gratuita MNIST [LeCun et al. 1998], na qual disponibiliza cerca de 70000 (setenta
mil) dı́gitos manuscritos dispostos de 0 a 9.
Assim, motivado pelas aplicações interessantes dos sistemas HCR offline, como
processamento de documentos manuscritos digitalizados, reconhecimento de endereços
postais e entre outros, o foco deste trabalho está em torno dos processos que envol-
vem um sistema HCR offline, com o objetivo de alcançar altas taxas de precisão no
HCR. Esses processos estão relacionados com a manipulação da base de dados MNIST,
como a aplicação de técnicas de pré-processamento nas imagens, utilização das técnicas
de extração de caracterı́sticas e de Support Vector Machine (SVM) com a estratégia de
classificação para múltiplas classes Um Contra Um (ou do inglês, One Against One ou
OAO). para reconhecimento de padrões.
Este trabalho é apresentado por seções. Na seção 2 é apresentado uma revisão
bibliográfica sobre a área de HCR. Na seção 3 são descritos os principais processos e
técnicas utilizadas. A seção 4 apresenta os resultados alcançados neste trabalho e na
seção 5, é apresentada uma visão geral dos resultados obtidos baseados na metodologia
proposta.
Em [Trier et al. 1996], diversas técnicas para extração de caracterı́sticas em caracteres
manuscritos são abordadas e podem ser utilizadas em imagens com várias tonalidades de
cinza, binarizadas e com contornos de caracteres.
Em [Kumar et al. 2012], são apresentados resultados comparativos entre as
técnicas Redes Neurais Artificiais (RNA) e SVM utilizando uma metodologia especı́fica
para cada classificador. Ao final os resultados obtidos indicam que SVM obtiveram de-
sempenho superior, alcançando uma acurácia de máxima de 94,8%.
Em [Yerra et al. 2017], o HCR é realizado por uma SVM, sendo utilizado apenas
a técnica de Histogramas de Gradientes Orientados (HOG). Ao final, são apresentados os
resultados obtidos, assim como uma comparação com outros trabalhos na literatura que
utilizaram técnicas semelhantes.
Em [Rodrigues et al. 2001], são utilizados técnicas de projeção de contorno utili-
zando polı́gonos regulares como quadrado e hexǵono para extração de caracterı́sticas de
dı́gitos manuscritos. Uma RNA é utilizada para o processo de classificação dos dı́gitos
manuscritos, alcançando uma acurácia máxima de 94,64%.
3. Metodologia
Nesta seção, os processos que envolvem o sistema de reconhecimento proposto são des-
critos. A Figura 1 apresenta a estrutura do sistema usando SVM para o reconhecimento
de padrões. No primeiro processo, é realizada a obtenção da base de dados MNIST, para
em seguida técnicas de pré-processamento serem aplicadas as imagens adquiridas. Após
esses processos, técnicas de extração de caracterı́sticas são aplicadas para determinar o
conjunto de caracterı́sticas de cada caractere manuscrito presente e em seguida sepa-
rar os conjuntos de dados de treinamento e de teste. Então uma SVM é utilizada para
classificar e reconhecer as caracterı́sticas apresentadas pelos conjuntos de treinamento
060
e teste, usando a estratégia de classificação para múltiplas classes OAO com variações
nos parâmetros do classificador SVM. Ao final, uma matriz de confusão é utilizada para
avaliar o desempenho do processo de classificação para cada conjunto de parâmetros abor-
dado.
Figura 1. Estrutura do sistema de reconhecimento com SVM.
3.1. Aquisição de Dados

A base de dados de imagens MNIST é utilizada neste trabalho, disponı́vel de forma gra-
tuita na web [LeCun et al. 1998]. Fornece 70000 (setenta mil) dı́gitos manuscritos isola-
dos e centralizados em imagens com dimensões fixas de 28x28, distribuı́da para os dı́gitos
de 0 a 9. Sendo 60000 (sessenta mil) para treinamento e 10000 (dez mil) para testes. A
Figura 2 apresenta alguns dı́gitos retirados da base de dados.
Figura 2. Exemplos da base de dados MNIST.
3.2. Pré-Processamento
As imagens da base de dados MNIST por padrão, encontram-se com diversos tons de
cinza, onde os pixels que representam os dı́gitos, encontram-se com tons brancos ou quase
brancos. Então, para que o sistema proposto seja capaz de trabalhar apenas com imagens
binarizadas e com caracteres de tonalidade preta, as técnicas de pré-processamento utili-
zadas são transformação de negativo e binarização das imagens aplicando um threshold
de 150, ambas as técnicas referenciadas em [Gonzalez and Woods 2006]. A Figura 3
apresenta graficamente a aplicação dessas técnicas em uma imagem da base de dados.
Figura 3. Aplicação de técnicas de pré-processamento sobre o dı́gito 4.
3.3. Extração de Caracterı́sticas

Uma SVM necessita de um vetor de caracterı́sticas correspondente a cada amostra, que
para este caso, esses vetores são determinados a partir da aplicação de técnicas de extração
de caracterı́sticas sobre as imagens da base de dados MNIST previamente processadas.
061
Além disso, essas técnicas possuem o objetivo de reduzir a dimensionalidade desses ve-
tores e consequentemente ampliar a eficiência do classificador no reconhecimento dos
padrões.
Dessa forma, este trabalho aborda as técnicas de projeção dos histogramas ho-
rizontal e vertical, e projeção de contorno de cada dı́gito utilizando um quadrado como
referência, avaliando as distâncias entre borda e contorno nos quatro lados.
3.3.1. Projeção de Histogramas
Esta técnica tem como objetivo projetar as distribuições ou histogramas horizontais e

verticais das imagens, totalizando um conjunto com 56 caracterı́sticas. Essas projeções
são obtidas a partir da contagem de pixels pretos em relação a horizontal e a vertical
das imagens [Trier et al. 1996]. A Figura 4 ilustra a projeção de histogramas aplicada
em alguns dı́gitos, onde a projeção a esquerda de cada dı́gito representa o histograma
horizontal, enquanto a projeção abaixo representa o histograma vertical.
Figura 4. Projeção dos histogramas horizontal e vertical de dı́gitos.
3.3.2. Projeção de Contorno
Esta técnica baseia-se na projeção do contorno do objeto contido na imagem sobre as

bordas de um polı́gono regular ao redor do mesmo [Rodrigues et al. 2001], calculando os
conjuntos de distâncias entre borda e contorno para cada lado do polı́gono.
Neste trabalho, o polı́gono de referência utilizado foi o quadrado, formato padrão
das imagens digitais, onde cada lado possui 28 pixels de acordo com as dimenões das
imagens dos dı́gitos manuscritos obtidos da base de dados MNIST. Assim, para cada lado
da imagem, foram calculados as distâncias horizontais, avaliando linha por linha e as
distâncias verticais, avaliando coluna por coluna. Essas distâncias são entre os pontos
de borda do polı́gono regular, no caso o quadrado, e os pontos de pixel mais próximo,
utilizando a métrica da distância euclidiana entre esses pontos. Caso nenhum pixel preto
seja encontrado, é computada a distância entre uma borda e outra.
Esta técnica contribui com 112 caracterı́sticas para cada dı́gito manuscrito, sendo
28 para cada lado do quadrado. A Figura 5 apresenta as quatro projeções de contorno de
um dı́gito retirado da base de dados MNIST sobre o polı́gono de referência utilizado, em
que as regiões em cinza representam as projeções de contorno do dı́gito manuscrito.
062
Figura 5. Projeção dos contornos de um dı́gito retirado da base de dados MNIST.
3.4. Reconhecimento de Padrões

Neste processo, define-se o mecanismo de classificação do sistema HCR, assim como suas
configurações e parâmetros necessários para realizar treinamento e predição de conjuntos
de caracterı́sticas. O mecanismo utilizado neste trabalho foi uma SVM, por apresentar
boa capacidade de generalização e bom desempenho com dados de grandes dimensões,
aplicada a uma estratégia de classificação de mútiplas classes OAO ou Um Contra Um.
3.4.1. Support Vector Machine
O princı́pio de uma SVM é conseguir transformar conjuntos de dados não linearmente

separáveis em linearmente separáveis, mapeando-os, por meio de uma função de kernel,
para um espaço de maior dimensão em relação a dos dados de entrada, para que seja capaz
de construir um hiperplano de margem máxima entre duas classes nesse novo espaço.
Diferentes tipos de kernel podem ser utilizados para representar os conjuntos de
dados no novo espaço de dimensões superiores. Os mais utilizados na literatura são:
• Linear
• RBF (Radial Basis Function)
• Polinomial
Neste trabalho foi abordado o kernel RBF, por ser utilizado em problemas em que os con-
juntos de dados não são linearmente separáveis e por apresentar bons resultados com
dados de grandes dimensões [Yerra et al. 2017]. Para SVM’s com kernel RBF, dois
parâmetros precisam ser definidos, o C (o parâmetro de penalidade de erro, determi-
nando o limiar de decisão entre duas classes) e o γ (Gamma) (determina a largura do
kernel RBF). A escolha do valor desses parâmetros tem grande influência no processo de
classificação.
Para o problema de HCR, existem múltiplas classes a serem identificadas, sendo
necessário abordar uma estratégia de classificação de múltiplas classes para uma SVM,
ou seja, formular problemas de duas classes. Assim, a estratégia abordada neste trabalho
foi OAO, que para dado um problema envolvendo n classes, serão construı́dos classifica-
dores binários para cada par dessas n classes. Cada classificador é construı́do utilizando
elementos das classes envolvidas, obtendo um total de n (n - 1)/2 classificadores, onde na
etapa de predição, a SVM realiza uma votação para determinar a classe do qual o padrão
apresentado, ou seja, a classe mais votada é selecionada.
3.5. Matriz de Confusão

A matriz de confusão pode ser utilizada para expor informações do processo de
classificação, normalmente de um treinamento supervisionado, assim como para exibir
063
o grau com que determinados valores se confundem com outros durante a classificação.
Cada linha da matriz representa as classes utilizadas, enquanto as colunas representam
os valores que o classificador julgou pertencer aquela classe e sua diagonal representa o
número de classificações corretas. Além disso, outras informações podem ser extraı́das a
partir de uma matriz de confusão como acurácia, precisão e sensibilidade da classificação
por exemplo.
4. Análise dos Resultados

Um total de 60000 (sessenta mil) imagens de dı́gitos manuscritos de 0 até 9 distribuı́dos de
forma não uniforme, como apresentado na Tabela 1, foram utilizados para o treinamento
da SVM. Enquanto que para teste foram utilizados 10000 (dez mil) imagens de dı́gitos
manuscritos de 0 até 9, também distribuı́dos de forma não uniforme como apresentado na
Tabela 2.
Todas as imagens foram submetidas aos processos descritos na seção 3.2. Em
seguida, no processo de extração de caracterı́sticas, as técnicas descritas nas subseções
3.3.1 e 3.3.2 foram utilizadas, totalizando 168 caracterı́sticas para cada imagem, armaze-
nadas em um vetor multidimensional. Assim, foi aplicada uma normalização nesse vetor
de caracterı́sticas, de modo que os dados pertençam ao intervalo [0,1], com o intuito de
reduzir o espaço de informações para o classificador SVM. E em seguida, o vetor foi seg-
mentado em amostras de treinamento e de teste para serem devidamente rotuladas com
suas respectivas classes e serem apresentadas a SVM.
Então, a SVM foi configurada para a estratégia de classificação de múltiplas clas-
ses OAO, utilizando uma função de kernel RBF, para efetuar os processos de treinamento
e predição de amostras. Após isso, foi verificado experimentalmente o desempenho do
classificador para algumas combinações empı́ricas dos parâmetros C e γ.
A Figura 6 apresenta os resultados obtidos neste trabalho com a estratégia de
classficação de múltiplas classes OAO em uma SVM com kernel RBF. A combinação de
parâmetros que atingiu a maior taxa de acertos foi quando C=10 e γ=0.1, porém para
C=100 e γ=0.01 , e C=100 e γ=0.1 os resultados obtidos também foram satisfatórios.
Entretanto, com a combinação C=1 e γ=0.001, o classicador não apresentou um bom
desempenho quando comparado as outras, mostrando que a mudança dessas combinações
afeta diretamente na classificação.
A Tabela 3 apresenta a matriz de confusão obtida da maior acurácia alcançada
a partir das combinações dos parâmetros do classificador SVM apresentados na Figura
6, sendo para C=10 e γ=0.1. As linhas dessa matriz representam as classes de 0 até 9
e as colunas representam o número de vezes que o sistema HCR julgou uma amostra
pertencer a tal classe. Enquanto a diagonal, destacada em negrito, apresenta a quantidade
de amostras identificadas corretamente.
Assim, é possı́vel obter informações como quantidade de vezes com que determi-
nados valores são confundidos com outras classes. Por exemplo, não há confusão entre
zeros e uns, enquanto que entre cincos e três houve confusão em algumas amostras.
064
Tabela 1. Quantidade de imagens para cada dı́gito manuscrito utilizado para

treinamento.
0 1 2 3 4 5 6 7 8 9
5924 6742 5958 6131 5842 5421 5918 6265 5851 5949
Tabela 2. Quantidade de imagens para cada dı́gito manuscrito utilizado para

teste.
0 1 2 3 4 5 6 7 8 9
980 1135 1032 1010 982 892 958 1028 974 1009
Figura 6. Desempenho do processo de classificação OAO de uma SVM com ker-

nel RBF como função dos parâmetros C e γ.
Tabela 3. Matriz de confusão obtida da classificação OAO da SVM com os

parâmetros C=10 e γ=0.1.
0 1 2 3 4 5 6 7 8 9
0 969 0 2 0 1 1 2 2 3 0
1 0 1126 2 1 0 0 2 1 3 0
2 3 0 1007 4 1 0 2 6 9 0
3 0 0 5 985 0 6 0 7 4 3
4 0 0 5 0 962 0 4 0 0 11
5 1 2 0 12 1 860 5 1 6 4
6 4 2 4 1 2 4 939 0 2 0
7 0 4 8 2 4 0 0 996 2 12
8 6 0 4 2 0 3 0 4 952 3
9 3 5 0 9 7 2 0 8 3 972
5. Conclusão
Os resultados obtidos pelo sistema HCR proposto, configurado para a base de dados
MNIST, mostraram-se satisfatórios com a utilização das técnicas de extração de carac-
terı́sticas citadas na seção 3.3, em conjunto com a estratégia de classificação multi-classes
065
OAO para uma SVM com kernel RBF. Além disso, a configuração dos parâmetros do ker-
nel que maximizaram o percentual de reconhecimento foi quando C=10 e γ=0.1, conse-
guindo identificar corretamente 9768 de 10000 dı́gitos manuscritos, ou seja, uma acurácia
de 97,68%. Além disso, os resultados obtidos neste trabalho são superiores em relação
aos trabalhos de [Kumar et al. 2012], que alcançou uma acurácia máxima de 94,8% utili-
zando metodologia semelhante, porém com outras técnicas de extração de caracterı́sticas,
e [Rodrigues et al. 2001], que alcançou 94,64% utilizando a técnica de projeção de con-
tornos e Redes Neurais.
Com o objetivo de elevar a taxa de precisão no HCR, outras técnicas de extração
de caracterı́sticas serão incorporadas ao sistema, assim como a utilização de uma técnica
computacional para estimação de parâmetros do kernel de uma SVM, em busca de uma
combinação automática e ideal capaz de ampliar a discriminação entre os conjuntos de
amostras de cada classe.
Referências
Gonzalez, R. C. and Woods, R. E. (2006). Digital Image Processing (3rd Edition).
Prentice-Hall, Inc., Upper Saddle River, NJ, USA.
Kumar, P., Sharma, N., and Rana, A. (2012). Handwritten character recognition using
different kernel based svm classifier and mlp neural network (a comparison). Interna-
tional Journal of Computer Applications, 53(11).
LeCun, Y., Cortes, C., and Burges, C. J. (1998). The mnist database of handwritten digits.
Disponı́vel em: <https://goo.gl/LU1HuQ>. Acesso em: 20 de abril de 2017.
Mori, S., Suen, C. Y., and Yamamoto, K. (1995). Document image analysis. chapter His-
torical Review of OCR Research and Development, pages 244–273. IEEE Computer
Society Press, Los Alamitos, CA, USA.
Plamondon, R. and Srihari, S. N. (2000). On-line and off-line handwriting recognition:
A comprehensive survey. IEEE Trans. Pattern Anal. Mach. Intell., 22(1):63–84.
Pradeep, J., Srinivasan, E., and Himavathi, S. (2012). Neural network based recognition
system integrating feature extraction and classification for english handwritten. Inter-
national journal of Engineering, 25(2):99–106.
Rao, N. V., Sastry, D. A., Chakravarthy, A., and P, K. (2016). Optical character recogni-
tion technique algorithms. Journal of Theoretical and Applied Information Technology,
83(2).
Rodrigues, R. J., Silva, E., and Thomé, A. C. G. (2001). Feature extraction using contour
projection. Disponv́el em: <https://goo.gl/M3YjoM>. Acesso em: 25 de abril de
2017.
Trier, Ø. D., Jain, A. K., and Taxt, T. (1996). Feature extraction methods for character
recognition - a survey. Pattern Recognition (PR), 29(4):641–662.
Yerra, N., Varanasi, R., Adapaka, H., Surumalla, H., and Dantha, J. (2017). Recognition
of handwritten characters using svm. International Journal of Innovate Research in
Science and Engineering, 4(3).
066
DESENVOLVIMENTO DE UMA METODOLOGIA PARA PROCESSAMENTO

DE IMAGENS GEORREFERENCIADAS.
Grenda Juara Alves Costa¹, Eduílson Lívio Neves da Costa Carneiro¹, Franciéric
Alves de Araújo¹
¹Instituto Federal de Educação, Ciência e Tecnologia do Piauí (IFPI)

Teresina – Piauí – Brasil
[email protected], [email protected], [email protected]
Abstract. The increasing advance of digital technology, together with the

development of new algorithms, allows an increasing number of applications
for the PDI that are of great value for the study of the georeferenced images,
however a good part systems limit the professionals, excluding of Important
processes such as geometric correction. The present work proposed the
development of a PDI methodology using Python for editing and recognition
of existing data in georeferenced images, showing the benefits that Python can
bring to digital image processing, both for Geoprocessing and for several
areas that use PDI.
Resumo. O crescente avanço da tecnologia digital, junto com o
desenvolvimento de novos algoritmos, está permitindo um número cada vez
maior de aplicações para o PDI, que são de grande valia para o estudo das
imagens georreferenciadas, porém boa parte desses sistemas limitam os
profissionais, excluindo de processos importantes como a correção
geométrica. O presente trabalho propôs o desenvolvimento de uma
metodologia de PDI usando Python para edição e reconhecimento de dados
existentes em imagens georreferenciadas, mostrando os benefícios que Python
pode trazer para o processamento digital de imagens, tanto para o
Geoprocessamento como para diversas áreas que utilizam técnicas de PDI.
1. INTRODUÇÃO
Atualmente, observa-se um crescimento elevado na utilização de computadores como
dispositivos auxiliares na execução de tarefas que eram feitas pelo homem. Esses
avanços são notórios em atividades que antes pareciam ser impossíveis, como
reconhecimento e processamento de imagens. O constante desenvolvimento dessa área
só é possível pelo fato de que nos últimos anos surgiram novas técnicas que propiciam o
reconhecimento e refinamento nos modos de aquisição e edição de imagens.
Essas novas tecnologias auxiliam em diversas áreas, tal como o uso de imagens de
satélites que através das técnicas de processamento digital de imagens (PDI) permitem
uma melhor interpretação e identificação de objetos e outras características existentes
nas imagens. Com isto, elas são capturadas, processadas e reconhecidas, possibilitando
a execução de tarefas repetitivas, na qual, sem a utilização de dispositivos e softwares
de processamento seria difícil viabilizar o beneficio do uso dos satélites, radares dentre
067
outros. Com isto tornou-se possível armazenar e representar diversas informações em

ambiente computacional, abrindo espaço para o aparecimento do Geoprocessamento.
De acordo com Câmara e Davis (2001) o Geoprocessamento utiliza técnicas
matemáticas e computacionais para tratamento de informações geográficas e influencia
de maneira crescente as áreas de cartografia, planejamento urbano e regional,
sensoriamento remoto, dentre outras. As ferramentas de Geoprocessamento permitem
realizar análises complexas, ao integrar dados de diversas fontes e apresenta um enorme
potencial baseado nos Sistemas de informações Geográficas (SIG). O PDI manipula
imagens digitais através de técnicas e algoritmos, melhorando ou modificando o aspecto
visual das feições. Podem incluir etapas de visão computacional e de computação
gráfica e tem características multidisciplinares, envolvendo diversos aspectos e
conceitos de ótica, eletrônica, matemática, estatística, fotografia e computação.
Um sistema de PDI é constituído de algumas etapas como: pré-processamento, que
trata preliminarmente dos dados brutos com a finalidade de calibrar a radiometria da
imagem, atenuar os efeitos da atmosfera e corrigir distorções; o realce da imagem, que
modifica através de funções matemáticas os níveis de cinza ou os valores digitais
melhorando a qualidade visual facilitando a análise; e a análise da imagem, que extrai as
informações necessárias.
Esta técnica remove barreiras facilitando a retirada de informações dos dados
obtidos. Dessa forma, a utilização de métodos para obter informações dos dados
georreferenciados vem se tornando cada vez mais comum. O PDI é uma área de estudo
de diferentes ramos, o que faz com que diversas empresas se especializem em softwares
dedicados a essa técnica. Portanto, este trabalho tem como finalidade apresentar uma
metodologia para o processamento digital de imagens georreferenciadas. Para tanto
serão utilizadas algoritmos para o reconhecimento, visualização e análise das imagens,
disponibilizando operações de processamento de forma simples e intuitiva.
Devido à grande quantidade de aplicações do PDI, objetivando um melhor
resultado será usado a linguagem Python, pois é uma linguagem interpretada bastante
moderna e com conceitos de orientação à objetos. A linguagem utiliza de poucas linhas
de código pra fazer algo que, comparado a outras linguagens, exigiria muito mais linhas
e seria bem mais trabalhoso. Python é uma linguagem livre e multiplataforma, ou seja,
significa que os programas escritos em uma plataforma serão executados sem nenhum
problema em qualquer das plataformas sem muitas ou nenhuma modificação. Python
apresenta semântica dinâmica, um moderno mecanismo de tratamento de erros e
exceções, e flexibilidade no tratamento de argumentos.
Além de ser uma linguagem de programação bem projetada, o Python
também é útil para executar tarefas do mundo real - os tipos de coisas
que os desenvolvedores fazem todo dia. Ele é comumente usado em
diversos domínios, como ferramenta para escrever outros
componentes e implementar programas independentes. Na verdade,
como linguagem de propósito geral, as funções do Python são
praticamente ilimitadas. (LUTZ, 2007, p. 33)
A maioria das geotecnologias usadas em geoprocessamento para PDI utiliza Python,
pois ela codifica vários SIG. A utilização dessa linguagem em SIG está se tornando
cada vez maior, não só pela disponibilidade de ferramentas, mas também pela facilidade
de aprendizagem e simplicidade da linguagem.
068
Acredita-se no potencial beneficio para os usuários que utilizam o PDI, como

exemplo alunos iniciantes do curso de geoprocessamento que se deparam com diversas
dificuldades. A solução proposta visa um sistema de maior facilidade de uso, com
simples interface, mais rapidez, com mecanismos que possibilitem melhoramento de
contraste, remoção de ruídos, codificação das informações para visualização de
imagens, extração de características para segmentação, dentre outros.
Portanto, existe uma necessidade de se desenvolver novas rotinas de PDI, para
suprir a carência na área de geoprocessamento. Diante disto a metodologia aqui criada
terá um conjunto de ferramentas multiplataforma, livre, simples de executar e,
sobretudo, de rápida aprendizagem, baseado em Python, uma linguagem bem projetada
que oferece suporte as mais diversas aplicações.
O objetivo central deste trabalho é desenvolver uma metodologia através do uso de
técnicas de PDI pra extração de características, propondo a utilização de algoritmos em
Python para edição e reconhecimento de dados existentes nas imagens
georreferenciadas, com o intuito de suprir os problemas citados acima.
2. METODOLOGIA
Para o desenvolvimento deste trabalho foi necessário a configuração do ambiente de
desenvolvimento, onde foi preferível o uso da plataforma Windows 7, pela maior
rapidez na instalação das ferramentas necessárias. Na iniciação dos algoritmos foi
utilizado o Python 2.7 e o Liclipse, onde foi feita a implementação dos testes nas
imagens. A área de estudo corresponde a alguns bairros do município de Teresina- PI,
as imagens usadas foram disponibilizadas pela PRODATER (Empresa Teresinense de
Processamento de Dados). A Orthofoto aérea tem resolução espacial de 0,10 metros, no
formato Geotiff, ou seja georreferenciadas.
Para a elaboração de mapas foi usado o Quantun GIS 2.18.3, a definição dos
algoritmos foi feita através do estudo das ferramentas de pré-processamento, edição das
imagens e uma análise das funções com alguns testes para facilitar a extração das
informações contidas nas imagens. Foram usadas em especial a biblioteca do Opencv e
o pacote Numpy. As imagens disponibilizadas pela PRODATER são de alta resolução
obtidas nos anos de 2005, 2007 e 2013. Com elas foram feitos vários testes com filtros e
funções que se aplicam as imagens utilizadas em geoprocessamento.
Figura 1: Mapa de localização.
069
Opencv é uma biblioteca multiplataforma que tem como objetivo principal

processar imagens digitais. Ele implementa ferramentas de interpretação de imagens,
operações simples como um filtro de ruído, até operações complexas, tais como a
análise de movimentos, dentre outros. O Numpy é um pacote específico de Python que
suporta matrizes multidimensionais e possui uma coleção de funções matemáticas para
trabalhar com estas estruturas.
O filtro HSV (Hue, Saturation e value) que significa matiz, saturação e valor, onde o
matiz verifica o tipo de cor usando as cores do espectro. Na saturação quanto menor o
valor mais cinza ficará a imagem e o atributo valor define o brilho das cores contidas na
imagem. A detecção de bordas é um grande desfio na área de PDI, trata-se de um tema
em aberto, pois algumas cenas são consideradas difíceis para detectar. Nesta
metodologia foram utilizados alguns algoritmos detectores de bordas usando técnicas
como Sobel, Laplaciano, porém o Canny se mostrou mais eficiente.
Normalmente as técnicas de PDI estão baseadas em métodos matemáticos que
permitem descrever quantitativamente imagens de diversas origens. A maior parte
dessas aplicações requer grande capacidade de cognição por parte de quem ira trabalhar
com os dados, devido à complexidade dos processos envolvidos e a falta de algoritmos
computacionais o bastante para realizá-lo de forma automática. O intérprete tem
capacidade de reconhecer alguns padrões, porém dificilmente é capaz de processar o
grande numero de informações presentes em uma imagem. Vários tipos de distorções
contribuem para limitar a visualização das características.
3. RESULTADOS E DISCUSSÕES
A partir da metodologia utilizada para processar as imagens através da linguagem

Python, foi possível observar a rapidez no retorno dos resultados. Cada filtro foi testado
em imagens de aspectos diferentes para saber em qual tipo de imagem se tornava mais
adequado.
Foram feitas nas imagens vários testes para extração de características das imagens
com o intuito de melhorar o aspecto visual, fornecer ferramentas para facilitar a
identificação e a extração das informações contidas nas imagens,
disponibilizando filtros para melhorar a visualização das imagens.
O HSV (figura 2) se adequou a todas as imagens testadas e tem algumas aplicações
em geoprocessamento como segmentação de curvas de níveis, cobertura vegetacional,
solo exposto, dentre outros.
Figura 2: 2005 e 2013. Fonte: Banco de dados PRODATER-Teresina
070
Com a aplicação do HSV nas imagens foi possível vericar algumas diferenças
ocorridas na paisagem nesta área específica de Teresina, como diminuição de vegetação
em alguns locais, aumento do solo exposto, dentre outras características.
Os detectores de bordas (figura 3) são de extrema importância na vetorização de
imagens, pois na maioria das vezes este processo é feito de forma manual, o que
dificulta e pode demorar bastante tempo.
Figura 3: 2005 e 2013. Fonte: Banco de dados PRODATER-Teresina
Essa detecção de borda foi bem mais eficiente na detecção de recursos hídricos,
ela pode fornecer características como largura, distâncias de uma borda a outra de rios,
dentre outros, pois ela leva em consideração os tons mais próximos de cores o que
facilita na detecção das bordas destes locais. A detecção de bordas para estas imagens
da área de estudo teve a intenção de evidenciar uma parte do rio Poty na área urbana de
Teresina, ela mostrou a diferença em alguns pontos do mesmo, como aumento da coroa
do rio, dentre outros.
4. CONCLUSÃO
A utilização dessa técnica na rotina de PDI, supri de certo modo a carência na área
de geoprocessamento, pois é de rápida aprendizagem, simples de executar e
multiplataforma. Foi obtido um ambiente de desenvolvimento e utilização das técnicas
de PDI. Em todas as técnicas implementadas se teve sucesso como: ajustes de contraste,
manipulação de histograma, detecção de bordas, dentre outras.
Este trabalho foi realizado durante uma bolsa apoiada pelo Programa de Iniciação
Científica do IFPI (PIBIC-IFPI) através do Edital Nº 57-2015, de 04/09/2015.
5. AGRADECIMENTOS
Ao programa do PIBIC pelo financiamento do projeto de pesquisa, ao IFPI-
Instituto Federal de Educação Ciência e Tecnologia do Piauí pela concessão da bolsa de
Iniciação Científica e aos meu orientadores Eduílson Lívio Neves da Costa Carneiro e
Franciéric Alves de Araújo pelo apoio durante a execução do trabalho.
6. REFERENCIAS E FONTES
071
BORGES, E. L. Python para desenvolvedores. Rio de Janeiro: Edição do autor. 2ª

edição. 2010.
BRAGA. J.C; BANON.J.F. Procedência de dados:teoria da aplicação ao processamento

digital de imagens. IEEE LATIN AMERICA TRANSACTIONS, vol.6, 207;214, 2008.
CÂMARA, G.; DAVIS, C.; MONTEIRO, A. M. V. Introdução a Ciência da

Geoinformação. São Paulo: INPE, 2001.
FARIA. D. Analise e Processamento de Imagem. Faculdade de Engenharia da

Universidade do Porto, 2010.
LEITE. D. A. T. Q; GIRALDI. G. A; LIRA. P. H. M; KNEIPP. R. E. (2011)

PyImageVis: Processamento e Visualização de Imagens Médicas em Python, REIC-
Revista de Iniciação Científica. Vol.11,num.1,16;35.
LUTZ, M; ASCHER, D. Aprendendo Python. Porto Alegre: Bookmam, 2007. 568p.
MENESES. P. R; ALMEIDA. T; ROSA. A. N .C .S; SANO. E. E; SOUZA. E. B;

BAPTISTA. G. M. M; BRITES. R. S. Introdução ao Processamento de Imagens de
Sensoriamento Remoto. Brasília, 2012.
RAMOS. M. S. S. (2013). Software Público. Benefícios e Dificuldades para a Gestão

Pública. Universidade Federal do Recôncavo da Bahia. Cachoeira, 2013.
SCURI. A. E. Fundamentos da Imagem Digital. Rio de Janeiro. 2002.
SILVA. A.G. Ambiente de Suporte ao Ensino de Processamento de Imagens Usando a

Linguagem Python. 183 f. Dissertação (Mestrado:engenharia da computação) –
Faculdade de Engenharia Elétrica e de Computação. Campinas, São Paulo, 2003.
072
073
Análise de sentimentos de possı́veis candidatos às eleições

presidenciais de 2018 através da rede social Twitter
Andrio Rodrigo Corrêa da Silva1 , Iális Cavalcante de Paula Junior1
1
Universidade Federal do Ceará (UFC) - Campus Sobral
Abstract. From the opinions generated in the twitter social network it is pos-
sible to create a database and on it to apply techniques for the extraction of
information. This work is based on three main analyzes: the first one is the
analysis and mapping of the followers of the possible candidates for the presi-
dential elections of 2018. The second case is the analysis of sentiments of tweets
using hashtags and classifying them according to the polarity. The third case
explored is the analysis of sentiments in tweets with direct quotations. From the
analysis of these data it was possible to determine in which region there is a
greater number of followers of a given candidate. It was also observed what
was the polarity of the words that are directed to a certain candidate.
Resumo. A partir das opiniões geradas na rede social twitter é possı́vel criar
uma base de dados e sobre ela aplicar técnicas para a extração de informações.
Esse trabalho é baseado em três análises principais: a primeira é a análise e o
mapeamento dos seguidores dos possı́veis candidatos às eleições presidenciais
de 2018. O segundo caso é a análise de sentimentos de tweets utilizando-se
hashtags e classificando-as de acordo com a polaridade. O terceiro caso ex-
plorado é a análise de sentimentos em tweets com citações diretas. A partir
da análise desses dados foi possı́vel determinar em qual região há um maior
número de seguidores de determinado candidato. Observou-se também qual foi
a polaridade das palavras que são direcionadas a determinado candidato.
Introdução
Nos últimos anos houve um intenso aumento no número de dados gerados. Esse fator se
deve principalmente às mı́dias sociais que surgiram ao longo desses anos. Uma das mı́dias
socias que vem chamando atenção nos últimos anos é o Twitter, que tem se tornado uma
plataforma bastante importante no quesito influência no meio digital. O microblog possui
hoje cerca de 284 milhões de usuários ativos e mais de 500 milhões de tweets por dia
[Jianqiang 2016].
Atualmente, o Brasil vive uma das suas piores crises polı́ticas da sua história. Nos
últimos meses, com a operação Lava Jato, que investiga casos de corrupção e lavagem
de dinheiro, e que acabou comprovando o envolvimento de empresários, governadores e
chegando até mesmo à alta cúpula do governo, a presidência da república.
Esse trabalho terá como objetivo principal, utilizando-se a rede social Twitter,
identificar o que as pessoas escrevem, como se sentem a respeito dos possı́veis candidatos,
atualmente destacados, para a corrida presidencial nas eleições de 2018.
074
Materiais e métodos
Data Science
Data Science pode ser descrito como a extração de conhecimento a partir de dados em
determinado campo de trabalho [Shamsuddin and Hasan 2015]. Esse termo já é con-
hecido há um bom tempo, entretanto, só ganhou mais notoriedade com o surgimento
de outro termo, Big Data, que se trata de um grande volume de dados estruturados
e não estruturados difı́cil de armazenar, analisar, processar, compartilhar e visualizar
[Vaishali and Kalaivani 2016].
Nos dias atuais, com Big Data, Data Science está se tornando um campo altamente
promissor tanto para a exploração quanto para o processamento de grandes volumes de
dados que possam ser extraı́dos de várias fontes e em diferentes velocidades.
Análise de Sentimentos
A análise de sentimentos tem como objetivo principal a identificação de qual sentimento
está sendo expresso sobre um determinado objeto, pessoa ou algum tópico especı́fico
[Liu et al. 2009]. Nesse trabalho foram usados dois algoritmos para determinar o tipo de
sentimento expresso nos tweets coletados.
O primeiro algoritmo, utilizado no Estudo de Caso 02 e também no Es-
tudo de Caso 03 (para efeitos de comparação), classifica os sentimentos de -6 até
+6. Essa classificação foi gerada graças a utilização de um Dicionário Léxico
[Souza and Vieira 2012] que inclui cerca de 32.000 palavras polarizadas e classificadas
gramaticalmente. O procedimento é simples: o algoritmo compara cada palavra presente
em determinado tweet com as palavras presentes no Dicionário. Ao final é realizado uma
soma aritmética e o tweet é classificado.
O segundo algoritmo, utilizado no Estudo de Caso 03, funciona da seguinte forma:
há duas listas de arquivos, uma contendo palavras de cunho positivo e outra contendo
palavras de caráter negativo. O algoritmo irá simplesmente verificar se o tweet possui
mais palavras positivas ou mais palavras negativas. Caso possua mais palavras positivas,
ele é classificado como positivo, se o tweet conter mais palavras negativas então ele é
classificado como negativo. Se a palavra não existir em nenhuma das listas, então aquele
tweet é classificado como neutro.
Linguagem R
A linguagem R é utilizada para fins de computação estatı́stica e para propósitos de análise.
Trata-se de uma plataforma open source, ou seja, seu código fonte é disponibilizado e
pode ser modificado e distribuı́do de graça, possuindo versões para Windows, Linux e
MAC OS.
R é uma plataforma estatı́stica que provê aproximadamente 5000 pacotes e oferece
técnicas para análise e exploração de dados [Kumar et al. 2016]. Essa linguagem será a
base de todo o trabalho. Todos os scripts foram criados utilizando-a.
A linguagem R possui uma ampla biblioteca de pacotes que podem ser utilizadas
de forma livre. Um desses pacotes é o twitterR, que foi utilizado para fazer tanto para
estabelecer a conexão com a API do Twitter quanto para realizar a captura de dados tweets.
Outro pacote importante utilizado foi o ROAuth, que fez a conexão do usuário ao servidor
escolhido [CRAN 2016].
075
AWS Amazon
O alto processamento de dados nesse projeto necessitou de uma alta infraestrutura de
hardware. Por essa razão, foram utilizados os serviços de cloud da Amazon, o Amazon
Web Services ou AWS Amazon.
A máquina virtual criada ficou com a seguinte configuração: 8 CPUs, 2.4 GHz,
32 GB de memória e 20 GB de armazenamento.
Power BI Microsoft
Em Data Science a apresentação dos resultados geralmente é feita de forma que o público
alvo possa entender o que está sendo dito, o que os dados representam, e isso é feito
através de Dashboards. O Dashboard seria a apresentação visual das informações obti-
das com o fim de transmitir os dados de forma clara e dinâmica. Nesse trabalho a ferra-
menta Power BI, da Microsoft, foi utilizada como opção para transformar os dados em
informação visual.
Procedimentos para a coleta dos tweets
Será utilizada a rede social Twitter como única fonte de informações. A coleta dos dados
será feita através de scripts escritos em R agregado ao uso da API da rede social. Os prin-
cipais dados a serem considerados nessa coleta serão os tweets postados pelos usuários. A
partir disso, os dados serão armazenados em dataframes, estruturas capazes de armazenar
dados de forma tabular, é composta de linhas e colunas, para análise e exploração.
A API do Twitter permite que tweets sejam coletados baseados em citações diretas
ou em #hashtags.
No fluxograma metodológico da Figura 1 são exibidos os passos que foram toma-
dos para a execução do presente projeto, desde a criação da conta até a geração dos resul-
tados.
Figura 1. Fluxograma Metodológico
Procedimentos para a análise dos tweets

O processo de limpeza e organização dos dados e o de coleta dos dados são os que mais de-
mandam tempo no aspecto geral de Data Science, e nesse trabalho o tempo gasto também
não se diferenciou quanto a limpeza e organização dos dados, sendo o processo mais de-
morado e dificultoso encontrado durante os estudos feitos. Na Figura 2 é possı́vel ver
cada passo que foi seguido para a limpeza dos dados.
076
Figura 2. Fluxograma passo a passo limpeza dos dados
Resultados
Essa seção apresenta os experimentos que foram feitos utilizando análise de sentimentos
através da rede social twitter. Os resultados e a análise dos mesmos são apresentados
nesta seção.
Estudo de caso 1 - Mapeamento dos Followers dos possı́veis candidatos a presidência

da república
A rede social Twitter possui um recurso chamado ”seguir”, em que um usuário poderá
acompanhar o que determinada pessoa posta e compartilha no microblogging em tempo
real. A partir do momento em que o usuário executa essa ação, de acompanhar alguém,
ele se torna um ”seguidor” ou follower. A Figura 3 apresenta um gráfico mostrando a
quantidade de seguidores que cada candidato possui até o presente momento, junho de
2017.
Figura 3. Número total de seguidores em K por candidato
Para realizar o mapeamento dos seguidores dos candidatos foi utilizado o

parâmetro getFollowers do pacote twitterR, e infelizmente com a limitação da API em
relação ao número de requisições, só foi possı́vel a captura de 60.000 usuários seguidores
para cada um dos candidatos. Essa captura foi realizada durante o mês de junho de 2017
e teve como principal objetivo a captura dos dados geográficos dos seguidores desses
candidatos.
077
Na Tabela 1, o campo ”Total após limpeza” representa a quantidade de pessoas

após a limpeza, já que houve a necessidade de eliminar dados que não eram consistentes
com o que se queria, as cidades, visto que a maioria das pessoas preencheu o campo
cidade com palavras obscenas, ou com frases, ou com apenas o paı́s. O procedimento de
limpeza aplicado é mostrado no fluxograma da Figura 2.
Tabela 1. Amostra Total e Amostra Obtida

Candidato Total Seguidores Total seguidores capturados Total após limpeza
Aécio Neves 563,23 mil 60,000 4.580
Jair Bolsonaro 458,07 mil 60,000 1.086
Lula da Silva 113,37 mil 60,000 987
Após a extração dos dados e a limpeza dos mesmos, o próximo passo foi o mapea-
mento desses usuários por região. A Tabela 2 mostra os resultados obtidos para o possı́vel
candidato Aécio Neves. A Tabela 3 apresenta os números para o possı́vel candidato Jair
Bolsonaro. A Tabela 4 exibe as regiões e suas respectivas porcentagens para o possı́vel
candidado Lula da Silva.
Tabela 2. Mapeamento por região - Aécio Neves

Região Porcentagem seguidores (%)
Centro-Oeste 10,98
Nordeste 12,04
Norte 7,38
Sudeste 61,59
Sul 8,01
Tabela 3. Mapeamento por região - Jair Bolsonaro

Centro-Oeste 2,59
Nordeste 12,10
Norte 3,60
Sudeste 65,13
Sul 16,58
Estudo de caso 2 - Análise de sentimentos em tweets obtidos através das Hashtags

#LulaEuConfio e #MoroOrgulhoBrasileiro
O segundo caso a ser estudado trata-se da análise de sentimentos em tweets coletados uti-
lizando hashtag (#) como parâmetro. Uma hashtag ou cerquilha é composta por palavras-
chave ou por apenas uma palavra. Essas palavras acabam tornado-se o assunto mais co-
mentado do momento ou Trending Topics.
As hashtags utilizadas, #LulaEuConfio e #MoroOrgulhoBrasileiro, foram geradas
após o interrogatório do ex-presidente Lula realizado pelo juiz Sérgio Moro para explicar
qual era o seu envolvimento no caso trı́plex. Após esse episódio, a rede social teve essas
duas hashtags chegando aos assuntos mais comentados do paı́s.
078
Tabela 4. Mapeamento por região - Lula da Silva

Centro-Oeste 0,30
Nordeste 28,88
Norte 3,34
Sudeste 48,63
Sul 18,85
A primeira análise feita trata-se da classificação dos tweets obtidos em positivo,

negativo ou neutro. A Tabela 5 mostra a quantidade de tweets que foram extraı́dos para
cada hashtag e o tempo decorrido para capturá-los. Essa captura também foi realizada du-
rante o mês de junho de 2017 e teve como principal objetivo a captura de tweets de qual-
quer usuário em que houvesse a participação da hashtag LulaEuConfio ou MoroOrgulho-
Brasileiro.
Tabela 5. Coleta de tweets hashtags

Hashtag Quantidade tweets Tempo gasto
#LulaEuConfio 50 mil 45 minutos
#MoroOrgulhoBrasileiro 50 mil 43 minutos
Para comparar os resultados obtidos, a Figura 4 mostra dois gráficos que com-
param os tipos de sentimentos extraı́dos dos tweets com a hashtag #LulaEuConfio e dos
tweets com a hashtag #MoroOrgulhoBrasileiro.
Figura 4. Comparativo sentimentos
É possı́vel notar que o algoritmo identificou vários tweets como sendo neutros.
A hashtag LulaEuConfio obteve pouco mais de 12.000 em tweets de cunho positivo en-
quanto a hashtag MoroOrgulhoBrasileiro obteve um número um pouco acima de 10.000.
No quesito palavras negativas, a hashtag LulaEuConfio obteve um número considerável,
na casa dos 8.000 enquanto MoroOrgulhoBrasileiro obteve 8.400 tweets negativos. Já
quando se trata de palavras neutras, a segunda hashtag se mostra um pouco mais a frente
no número de tweets, LulaEuConfio com 29.000 e MoroOrgulhoBrasileiro com 31.000.
Estudo de caso 3 - Análise de sentimentos em tweets com citações diretas aos
candidatos
O estudo do caso 3 utiliza como base de dados os tweets com citações diretas. Uma citação
direta seria simplesmente um determinado tweet mencionando o nome de determinada
pessoa.
079
A Tabela 6 mostra a quantidade de dados utilizados e o tempo para extrai-los do

Twitter. O número escolhido foi ideal, pois o tempo para fazer a limpeza e processamento
dos dados não é muito longo e não há o risco de haver rate limit. Essa captura também
foi realizada durante o mês de junho e teve como objetivo a captura de tweets em que
houvesse a menção do nome de um dos candidatos: Aécio, Bolsonaro ou Lula.
Tabela 6. Coleta de tweets - citações diretas

Candidato Quantidade tweets Tempo gasto
Aécio Neves 100 mil 95 minutos
Jair Bolsonaro 100 mil 86 minutos
Lula da Silva 100 mil 102 minutos
Após a limpeza e normalização dos dados, foi gerado um comparativo entre os

candidatos e os sentimentos que foram apresentados nos tweets que citavam-nos. A Figura
5 mostra esse comparativo.
Figura 5. Score de sentimentos encontrados nos tweets
A utilização do segundo algoritmo gera um resultado parecido com o do primeiro.

Entretanto, o resultado gerado mostra um somatório de todas as palavras negativas, posi-
tivas e neutras, o que permite uma melhor comparação entre os sentimentos. A Figura 6
mostra esse comparativo.
Figura 6. Comparativo de sentimentos a partir de citações diretas
080
Conclusão
Este trabalho mostrou o estudo de 3 casos relacionados à polı́tica brasileira. O primeiro
caso analisado foi tentar descobrir onde se concentravam os seguidores de cada candidato,
dividido em regiões. Em todos os casos foi possı́vel notar uma dominação da região
sudeste, com mais de 50% em cada caso.
No estudo do caso 2, duas hashtags foram analisadas a partir de um Dicionário
Léxico, contendo palavras previamente classificadas. A primeira hashtag #LulaEuConfio,
gerada por apoiadores do ex-presidente, mostrou um número alto de palavras neutras. O
número de palavras positivas, em torno de 12.000, foi maior em comparação as palavras
positivas da hashtag #MoroOrgulhoBrasileiro.
No caso 3 foi utilizado um outro algoritmo, além do já utilizado no caso 2, para
classificar os sentimentos dos tweets obtidos em positivo, negativo ou neutro. Esse algo-
ritmo utiilizou duas listas de palavras, divididas em positivas e negativas. Cada palavra
de tweet é analisada, então é realizada a soma aritmética e o texto é classificado. Difer-
entemente do caso 2, os dados obtidos no caso 3 foram retirados de tweets que continham
citações diretas aos possı́veis candidatos.
Para um futuro melhoramento desse trabalho, já foi colocado em prática a
construção de um novo algoritmo que supera o tempo de rate limit, imposto pela API
do Twitter. Esse novo algoritmo vai permitir que o mapeamento de seguidores seja feito
de forma mais completa, utilizando 100% de todos os seguidores como base de dados
além de permitir que um maior número de tweets seja capturado, permitindo uma melhor
análise de dados.
Referências
CRAN (2016). Roauth package.
Jianqiang, Z. (2016). Combing semantic and prior polarity features for boosting twitter
sentiment analysis using ensemble learning. In First International Conference on Data
Science in Cyberspace. Xi’an, Shaanxi Province, China-.
Kumar, S., Singh, P., and Rani, S. (2016). Sentimental analysis of social media using r
language and hadoop: Rhadoop. In 5th International Conference on Reliability, Info-
com Technologies and Optimization (Trends and Future Directions) (ICRITO). Noida,
India.
Liu, B., Naraynan, R., and Choudhary, A. (2009). Sentiment analysis of conditional
sen- tences. In Conference on Empirical Methods in Natural Language Processing.
Singapore.
Shamsuddin, S. and Hasan, S. (2015). Data science vs big data. In International Confer-
ence on Science in Information Technology (ICSITech). Yogyakarta, Indonesia.
Souza, M. and Vieira, R. (2012). Sentiment analysis on twitter data for portuguese lan-
guage. In 10th International Conference Computational Processing of the Portuguese
Language. Coimbra,Portugal.
Vaishali, G. and Kalaivani, V. (2016). Big data analysis for heart disease detection system
using map reduce technique. In International Conference on Computing Technologies
and Intelligent Data Engineering.
081
Sistema Fuzzy Como Ferramenta de Apoio no Processo de

Diagnóstico da Retocolite Ulcerativa
Francisco Aurélio Paulino Fontenele1 , Rhyan Ximenes de Brito2 ,
Janaide Nogueira de Sousa Ximenes 3 , Ronieri Nogueira de Sousa 4
1
2
3
4
{aureliopaulinof1, rxbrito, nogueirajanaide, nsronieri}@gmail.com
Abstract. Currently the use of technologies in the treatment or prevention of

diseases has increased significantly, involving methods that assist health profes-
sionals in the early diagnosis of the most varied types of diseases. In this scena-
rio the target audience will be patients with ulcerative colitis. This work aims
to present a fuzzy system that will simulate patient diagnoses. For this, using
the fuzzy logic in the analysis of the diagnoses, detailing the various symptoms.
The results were promising as they were very close to those observed by health
professionals.
Resumo. Atualmente o uso de tecnologias no tratamentos ou prevenção de en-

fermidades tem aumentado significativamente, envolvendo métodos que aux-
liam profissionais da saúde, no diagnóstico precoce dos mais variados tipos
de doenças. Nesse cenário o público alvo serão pacientes com a retocolite ul-
cerativa. Este trabalho tem como objetivo apresentar um sistema fuzzy que irá
simular diagnósticos de pacientes. Para tal, utilizando-se da lógica de fuzzy
na análise dos diagnósticos, detalhando os diversos sintomas. Os resultados
mostraram-se promissores na medida que foram bem próximos dos observados
por profissionais da saúde.
1. Introdução
O crescente uso da Inteligência Artificial aplicada à área da medicina é algo cada vez
mais presente, pois há uma necessidade imprescindı́vel de soluções para diagnósticos de
doenças que possuam sintomas relativamente parecidos, ou seja, doenças com diagnóstico
difı́ceis. Nesse contexto foi utilizada a lógica de Fuzzy como método de auxı́lio no di-
agnóstico da retocolite Ulcerativa. Para a realização do trabalho fez-se necessária a mode-
lagem de um sistema utilizando-se o MatLab (do inglês Matrix Laboratory) um programa
computacional conhecido em todo o mundo como uma ferramenta para a resolução de
problemas matemáticos, cientı́ficos e tecnológicos.
082
Por outro lado, a Lógica de Fuzzy, consiste em um elemento fundamental em di-

versos sistemas, sendo considerada uma técnica de excelência no universo computacional
é baseada na teoria dos conjuntos fuzzy, que discorda em suas caracterı́sticas e em seus
detalhes dos tradicionais sistemas lógicos existentes, sendo que, através dessa lógica o
processo no qual o resultado é obtido, funciona de acordo com o raciocı́nio aproximado
[Gomide et al. 1995].
Neste enfoque esta pesquisa objetiva aplicação a lógica Fuzzy para auxiliar no
diagnóstico da retocolite ulcerativa (RCU), na qual é uma doença inflamatória intestinal
de grau variado de gravidade e etiologia desconhecida, cujas manifestações principais
são diarréia, dor abdominal e sangramento retal e que apresenta no corpo e no intestino
inúmeras gravidades.
Segundo [Lanna et al. 2006], a situação clı́nica que é apresentada através das
manifestações de diarréia, dor abdominal e sangramento retal acontecem em perı́odos
de remissão e irritação, apresentando as mais diversas complicações, que podem agre-
gar a presença de manifestações extras intestinais como articulares, cutâneas, oculares,
hepatobiliares e vasculares, que podem anteceder, acompanhar ou ocorrer após a doença
intestinal.
Este trabalho está organizado da seguinte forma: Seção 2 apresenta alguns tra-
balhos relacionados, Seção 3 apresenta um referencial teórico dos principais conceitos
pautados na Lógica de Fuzzy. Em seguida na Seção 4 será mostrada a doença retocolite
ulcerativa, sintomas e fases. Na Seção 5 é apresentada a abordagem proposta e, final-
mente, conclusões e trabalhos futuros são descritos na Seção 6.
Esta seção apresenta uma revisão bibliográfica sobre a utilização da Lógica de Fuzzy,
como mecanismo de apoio ou simulação nos mais diferentes tipos de diagnósticos, com
diferentes abordagens e perspectivas. A análise dos trabalhos relacionados cobre algumas
abordagens propostas para a realização da utilização da Lógica de Fuzzy na Informática
Médica.
Para [Marques et al. 2005] as ferramentas computacionais construı́das para uma
área de domı́nio especı́fico podem apoiar ou facilitar o processo de tomada de decisão em
situações clı́nicas de enfermagem. Nesta abordagem a Lógica Fuzzy foi utilizada como
apoio à decisões clı́nicas de enfermagem, com o objetivo de apresentar noções gerais
sobre esta técnica e por meio dela desenvolver uma formulação teórica, em forma de
guia prático, para o apoio à decisão nos casos de amniotomia em gestantes pimı́paras em
trabalho de parto normal.
[Kawamura et al. 2007] nessa abordagem concentrou-se na utilização dos concei-
tos de sistemas fuzzy, através do emprego de sistemas difusos para a área de saúde. Os
modelos de inferência utilizados foram o método de Mamdani e o método Sugeno, fo-
ram analisadas as vantagens e desvantagens de cada método. Dessa forma a partir das
caracterı́sticas do câncer do esôfago e dos conceitos de sistemas fuzzy foi modelado um
sistema para o diagnóstico.
[Silva 2014] propõem uma nova metodologia de desenvolvimento na área de me-
dicina, no diagnóstico de hérnia inguinal utilizando a Lógica Fuzzy. Dessa forma foi
083
desenvolvido um aplicativo para dispositivos móveis, auxiliando à tomada de decisão no

diagnóstico de pacientes com suspeita de hérnia na região inguinal. Para isso, utilizou-se
a linguagem JAVA juntamente com a biblioteca Lógica Fuzzy, denominada jfuzzylogic,
e o sistema operacional Android para o desenvolvimento da aplicação. Para validar o
aplicativo, utilizou-se a coleta de dados, via questionário, envolvendo 30 pacientes entre-
vistados em consulta médica.
3. Fuzzy
O termo lógico foi criado por Aristóteles, que fez um conjunto de leis que regem o pen-
samento. Entre os maiores filósofo que viveram na Grécia, Sócrates, Platão e Aristóteles
deram uma grande contribuição para o avanço significativo para a futura sistematização
destes princı́pios [Weber and Klein 2003].
Para [Bilobrovec 2005] a Lógica Fuzzy mostra-se como uma forma inovadora no
processo com informações imprecisas, de forma diferente da teoria de probabilidades, ou
seja, a Lógica Fuzzy usa método para traduzir expressões verbais, vagas, imprecisas e
qualitativas, comuns na comunicação humana em valores numéricos para o mundo real.
Para [Marro et al. 2010], o principal objetivo da Lógica de Fuzzy é a modelagem
computacional do raciocı́nio humano, impreciso, ambı́guo e vago. Os softwares que utili-
zam a Lógica de Fuzzy são grandes aliados na criação de sistemas de controle, na prática
propicia a incorporação de certa imprecisão de um problema, através de variáveis reais, do
tipo: velocidade, temperatura, pressão, e outras, que são associadas a termos linguı́sticos
do tipo alto, baixo, pouco baixo, entre outros [Bilobrovec et al. 2004].
Na atualidade a Lógica Fuzzy é aplicada em softwares de controle e de suporte à
decisão, onde a descrição do problema (regras de produção) não pode ser feita de forma
precisa. Esta metodologia tem sido aplicada em análises de dados, construção de sistemas
especialistas, controle e otimização, reconhecimento de padrões, entre outras; portanto,
desde controle de aeronaves a máquinas de lavar roupas, análise de estoques de vendas a
modelos genéticos, de reconhecimento de escritas a ajustes de focos de câmeras de vı́deo.
Segundo [Bilobrovec et al. 2004], a teoria fuzzy já foi usada com perfeição nas
mais diversas áreas, ressaltando-se o uso em controladores de usinas nucleares, refina-
rias, processos biológicos e quı́micos, sistemas de ventilação, na área médica, econômica,
então, são usadas nas mais diversas áreas, onde é capaz de trabalhar com incertezas.
Os fatos citados serviram como base na criação da Lógica Fuzzy, baseando-se na
lógica clássica, com acréscimo de novos operadores. Nos conjuntos nebulosos as leis do
terceiro excluı́do e da contradição não são complacentes [Kaufmann and Gupta 2003].
Segundo [Júnior and Novakowski 2005], os conjuntos fuzzy foram desenvolvidos
para determinar o quanto um elemento pertence ou não a um determinado conjunto, com
o uso de graus de pertinência, que são valores no intervalo [0;1]. Assim é possı́vel deter-
minar os elementos que pertencem a um grupo e seu respectivo grau de pertinência.
4. Retocolite Ulcerativa
A retocolite ulcerativa (RCU) é identificada como doença intestinal inflamatória, de
causa desconhecida, podendo ser uma doença limitada ao reto ou se expandir até in-
testino grosso (cólon). A doença pode acontecer em qualquer idade, porém, a faixa
084
etária que mais acontece o aparecimento da doença é dos 15 a 30 e 50 a 70 anos

[Macedo et al. 2016].
A incidência da RCU é maior em brancos, atingindo tanto o sexo masculino
quanto o sexo feminino, sendo que no sexo feminino têm uma maior prevalência. Em
paı́ses mais desenvolvidos é comum o surgimento de casos da doença [Gomes 2008].
A RCU acontece por intervalos de manifestações, complicações e o estado crônico
da doença provocam perturbações na vida social e psicológica do paciente que na mai-
oria das vezes são internados por longos perı́odos, tornando o tratamento cansativo, que
acomete por afastar o paciente de suas funções rotineiras e da vida profissional e social
durante o tempo de tratamento das crises inflamatórias [Santos 2014].
Segundo [Mantovani et al. 2007], portadores de doenças inflamatórias intestinais
como a RCU têm probabilidades maiores de desenvolver o câncer de colo-retal, devido a
sua cronicidade, que favorece a manifestação de neoplasias na região de cólon e reto. Por
este motivo é de suma importância o diagnóstico correto e rápido da doença.
4.1. Sintomas
Os sintomas apresentados com maior frequência na RCU são a dor abdominal, diarréia
com ou sem sangue, cólica e urgência para evacuar [Barbieri 2000]. Para [Silva 2015],
dependo da gravidade em que a doença se encontra os sintomas apresentam sinais dife-
rentes, sendo que os mais comuns são diarréia seguido de dor abdominal, urgência para
evacuar, muco nas fezes, hematoquezia, anorexia e sinal clı́nico de anemia.
Segundo [Torres et al. 2011], os sintomas não estão restritos apenas aos intesti-
nais como diarréia, sangue e muco nas fezes, tenesmo retal, mas também a uma série de
manifestações extra intestinais que em alguns casos não são notados, como dores articu-
lares, feridas e inflamações no corpo, no olho, vindo a ocasionar o surgimento de algumas
doença como a uveı́te, que é uma doença que deixa o olho vermelho, também proble-
mas urinários fazem parte dos sintomas da doença, podendo citar também problemas
pulmonares, insuficiência renal, etc. O diagnóstico é fundamentado no quadro clı́nico,
endoscópico e histológico, que inicialmente tem o propósito de excluir as infecções e
parasitoses. [Torres et al. 2011]
Nos últimos tempos a RCU vêm sendo diagnosticada de forma rápida e precisa,
devido o aumento dos conhecimentos obtidos quanto aos aspectos, epidemiológicos, fi-
siológicos e clı́nicos, assim proporcionando diferenciá-la de outras doenças que afetam o
cólon, como a doença de Crohn que tem sintomas similares [Houli and Netto 1984].
4.2. Fases
A retocolite ulcerativa é subdividida por fases que são caracterizadas de acordo a intensi-
dade das manifestações clı́nicas e das modificações endoscopia [Houli and Netto 1984].
Essas fases são subdivida em três, que se caracteriza na fase leve, fase moderada e na
fase grave. Fase leve é definida pelo número de evacuações que não ultrapassam de três
a quatro vezes no perı́odo de 24 horas, não apresentando febre, emagrecimento e ane-
mia, diarréia com ou sem sangue, e em alguns casos com a presença de muco nas fazes
[Houli and Netto 1984].
Segundo [Barbieri 2000], a fase moderada é definida por quatro a seis evacuações
085
diárias com a presença de diarréia com sangue, muco, também dor abdominal, perda de
peso, podendo acometer o paciente a se ausentar de algumas atividades rotineiras.
A fase grave é apresentada com uma intensa diarréia, tendo evacuações superio-
res a seis vezes por dia, com muita perda de sangue, muco, forte dor abdominal, febre,
indisposição, anemia, hipotensão arterial, desidratação que acomete ao paciente ficar so-
bre cuidados extensivos [Barbieri 2000].
O objetivo principal do tratamento é melhorar a qualidade de vida do paciente,
reduzir a inflamação, curar as lesões e melhorar o status nutricional. Por outro lado a
interação medicamentosa tem a finalidade de conter os sintomas, provocar a remissão,
restaurar lesões, cicatrizar a mucosa e evitar complicações [Silva 2015].
5. Abordagem Proposta
Com o auxı́lio da plataforma MatLab, modelou-se-se um sistema com a utilização da
Lógica de Fuzzy para a realização de simulações de diagnóstico, onde foi utilizado como
dados de entrada: diarréia com ou sem sangue, diarréia com sangue ou muco, dor abdo-
minal, febre e emagrecimento, todos esses sintomas apresentam as seguintes fases: leve,
moderada e grave. Os sintomas estudados estão classificados em uma escala de 0 a 1,
onde 0 é a menor atribuição e 1 é a maior atribuição.
A Figura 1 apresenta a declaração das variáveis na ferramenta MatLab. No caso, a
aplicação realizada nesse trabalho possui cinco variáveis de entrada e uma de saı́da, sendo
que, as variáveis de entrada correspondem aos sintomas necessários para a identificação
da doença retocolite ulcerativa
Figura 1. Declaração de variáveis de entrada.
A figura 2 demonstra a definição das regras, onde se faz necessário para obter o
diagnóstico da retocolite ulcerativa, no qual, a partir destas regras é possı́vel identificar
se o paciente tem ou não a doença e em que gravidade ela se encontra, ou seja, leve,
moderada ou grave.
Nesse enfoque, foram realizados trinta simulações com pacientes fictı́cios, dentre
estas, foram escolhidas aleatoriamente duas para serem apresentados os resultados. Para
fins de identificação, as simulações foram nomeadas como PacienteX e PacienteY. Vale
destacar que, estes dados foram submetidos a avaliação de um especialista e os resultados
do sistema Fuzzy foram validados com o diagnóstico feito pelo médico sendo que, na
maioria dos casos, os resultados foram equivalentes.
086
Figura 2. Definição das regras.
Observou-se que a aplicação da ferramenta funciona de forma satisfatória, onde

pacientes que sofrem de algum problema intestinal foram diagnosticados para obter uma
confirmação de possuir ou não a doença RCU, assim, podendo iniciar o tratamento ime-
diatamente e ainda podendo saber em qual fase a doença se encontra, ou seja, leve, mo-
derada ou grave.
Porém deve-se salientar que outras doenças podem ter os mesmos sintomas, fi-
cando a critério do profissional da medicina fazer a análise de tal possibilidade, com base
em critérios especı́ficos e válidos para retocolite ulcerativa.
Tabela 1. Simulação com o pacienteX
Na Tabela 1 são apresentados os resultados obtidos com a simulação realizada

com o PacienteX, onde foi verificado que os sintomas estudados apresentam os seguintes
resultados: Diarréia com ou sem sangue teve 0.81, onde já é considerado um estado grave;
Diarréia com sangue e muco teve 0.21, onde se encontra na fase leve; dor abdominal se
encontra na fase leve com 0.12; Febre se encontra na fase leve, mas com proximidade da
fase moderada com o resultado da consulta 0.31; Emagrecimento está inspirando cuida-
dos devidos apresentar-se na fase moderada da doença com o resultado obtido 0.51. O
Diagnóstico obtido com os resultados de todos os sintomas foi 0.50, onde é considerada
que existe a presença da retocolite ulcerativa no paciente e encontra-se na fase considerada
moderada da doença.
Tabela 2. Simulação com o pacienteY
087
A Tabela 2, exibe os resultados obtidos com o PacienteY, onde foi analisado que os
sintomas apresentam os seguintes resultados: Diarréia com ou sem sangue apresenta 0.50
como resultado, onde pode ser percebido que os sintomas se encontram na fase moderada;
Diarréia com sangue e muco teve 0.30, sendo considerado leve e com aproximação da fase
moderada; Dor abdominal foi obtida o resultado 0.10, que é considerada leve, também é
percebido que não há a existência de febre e com o grau de Emagrecimento leve, tendo
0.12 como resultado. O Diagnóstico com o resultado 0.32 mostra que existe a presença da
retocolite ulcerativa, encontrando-se na fase leve da doença e com aproximação da fase
moderada.
6. Conclusões e Trabalhos Futuros

A RCU é uma doença que está presente na vida de muitas pessoas no mundo. Este traba-
lho demonstra que a Lógica Fuzzy é potencialmente válida para o auxı́lio no diagnótico
dela e de outras doenças. Todavia uxiliando médicos a diagnosticarem a presença dela e
em qual estado encontra-se, manifestando assim, maior grau de precisão e possibilitando
identificar a gravidade em que se encontra, ou seja, leve, moderada ou grave. Dessa forma
encaminhando o paciente ao tratamento ideal, afim de evitar que apresente agravantes, que
em casos mais intensos podem gerar câncer de cólon ou mesmo o óbito do paciente.
Para trabalhos futuros sugere-se que a Lógica de Fuzzy seja aplicada para auxiliar
no diagnóstico de outras doenças gastrointestinais, sendo necessário a determinação de
critérios de diagnósticos especializados, comparando método já existentes e determinando
sua acurácia.
Referências
Barbieri, D. (2000). Doenças inflamatórias intestinais. Jornal de Pediatria, 76(Suppl
1):173–180.
Bilobrovec, M. (2005). Sistema especialista em lógica fuzzy para o controle, gerencia-
mento e manutenção da qualidade em processo de aeração de grãos. 2005. 74 f. PhD
thesis, Dissertação (Mestre em Engenharia de Produção)–Universidade Tecnológica
do Paraná, Ponta Grossa, PR.
Bilobrovec, M., Marçal, R. F. M., and Kovaleski, J. L. (2004). Implementação de um
sistema de controle inteligente utilizando a lógica fuzzy. XI SIMPEP, Bauru/Brasil.
Gomes, R. d. S. (2008). Fisiopatologia e tratamento por acupuntura da retocolite ulcera-
tiva.
Gomide, F., Gudwin, R. R., and Tanscheit, R. (1995). Conceitos fundamentais da teoria
de conjuntos fuzzy, lógica fuzzy e aplicações. In Proc. 6 th IFSA Congress-Tutorials,
pages 1–38.
Houli, J. and Netto, G. M. (1984). Retocolite ulcerativa inespecı́fica. Revista Brasileira
de Colo-Proctologia Outubro-Dezembro, 4(4).
Júnior, I. and Novakowski, S. (2005). Lógica fuzzy sistemas de apoio a decisão. Rio
Grande do Sul, UNISINOS, Abr.
Kaufmann, A. and Gupta, M. (2003). Introduction to fuzzy arithmetic: theory and appli-
cations. 1985. Von nostrand Reinhold Company, New York.
088
Kawamura, J. et al. (2007). Aplicação de um sistema fuzzy para diagnostico de cancer do

esofago.
Lanna, C. C. D., Ferrari, M. d. L. A., Carvalho, M. A. P. d., and Cunha, A. S. d. (2006).
Manifestações articulares em pacientes com doença de crohn e retocolite ulcerativa.
Rev Bras Reumatol, 46(S1):45–51.
Macedo, B. F., Schaefer, L. R., Brambilla, R., Brum, J. C. J., and SILVEIRA, R. G. d.
(2016). Retocolite ulcerativa e trombose venosa cerebral: relato de caso. Blucher
Medical Proceedings, 2(7):181–185.
Mantovani, M. d. F., Muniz, M. R., Simões, M. C., Boschco, M. D., and de Oliveira, G. D.
(2007). O perfil dos usuários cadastrados na associação paranaense de ostomizados–
apo. Cogitare Enfermagem, 12(1).
Marques, I. R., Barbosa, S. d. F., Lopes de Oliveira Basile, A., and Marin, H. F. (2005).
Guia de apoio à decisão em enfermagem obstétrica: aplicação da técnica da lógica
fuzzy. Revista Brasileira de Enfermagem, 58(3).
Marro, A. A., Souza, A. d. C., Cavalcante, E. d. S., Bezerra, G. S., and Nunes, R. O.
(2010). Lógica fuzzy: conceitos e aplicações. Natal: Universidade Federal do Rio
Grande do Norte (UFRN).
Santos, L. S. N. (2014). Intervenção nutricional na retocolite ulcerativa: Um relato de
caso.
Silva, A. A. V. d. (2014). Desenvolvimento de aplicações em medicina e agronomia
utilizando lógica fuzzy e neuro fuzzy.
Silva, A. S. (2015). Comparação dos métodos de avaliação do estado nutricional em
pacientes com retocolite ulcerativa.
Torres, J. A. d. P., Santana, R. M. d., Torres, F. A. d. P., Moura, A. R., Neto, T., and
da Rocha, J. (2011). Intestinal inflammatory diseases in the hospital universitario of
universidade federal de sergipe: extraintestinal manifestations. Revista Brasileira de
Coloproctologia, 31(2):115–119.
Weber, L. and Klein, P. A. T. (2003). Aplicação da lógica fuzzy em software e hardware.
Editora da ULBRA.
089
Alocação Ótima de Reguladores de Tensão no Sistema Elétrico

Utilizando Algoritmos Genéticos
Jônatas Macêdo Soares1 , Filipe Bispo Lima1
1
Departamento de Engenharia Elétrica, Universidade Federal do Piauı́
Campus Universitário Ministro Petrônio Portella, Bairro Ininga
Teresina, Piauı́, Brasil, CEP 6409-550
Abstract. This paper presents an application of the simple genetic algorithm

for the optimal allocation of voltage regulators in the Electric Power System
(EPS). The values per unit (p.u) of the electrical voltages of each bar of the
Electric Power System are adopted as reference for calculating the fitness of
the individuals of the evolutionary algorithm. It is possible to allocate up to
04 Voltage Regulators (VRs) for any considered parts of the system and the
best allocation solutions correspond to cases where the voltage value in each
bar is closer to 1 p.u. A simulation of 24 bars, 23 lines and 04 generators in
MATPOWER is used to prove the viability of the method.
Resumo. Este artigo apresenta uma aplicação do algoritmo genético simples

para a alocação ótima de reguladores de tensão no Sistema Elétrico de Potência
(SEP). Os valores por unidade (p.u) das tensões elétricas de cada barra do
Sistema Elétrico de Potência são adotados como referência para cálculo da
aptidão dos indivı́duos do algoritmo evolutivo. É possı́vel alocar até 04 Re-
guladores de Tensão (RTs) para quaisquer trechos considerados do sistema e
as melhores soluções de alocação correspondem aos casos em que o valor da
tensão em cada barra está mais próximo de 1 p.u. É utilizada uma simulação
de 24 barras, 23 linhas e 04 geradores no MATPOWER para comprovar a via-
bilidade do método.
1. Introdução
A análise e correção dos distúrbios da qualidade da energia elétrica são essenciais
para o fornecimento adequado de eletricidade a diferentes tipos de consumidores do Sis-
tema Elétrico de Potência (SEP). A crescente inserção de cargas sensı́veis aos surtos de
tensão elétrica, por exemplo, demanda melhorias significativas nos ı́ndices de qualidade
do suprimento energético de modo a resguardar a integridade dos equipamentos e não
comprometer a vida útil do sistema [Dugan et al. 2002]. Os fenômenos de interrupção,
afundamento e elevação de tensão são relativamente comuns em redes de distribuição de
energia elétrica e estão intimamente ligados à natureza das cargas usadas por consumido-
res residenciais, comerciais e industriais. Perfis de tensão inadequados são responsáveis
por perdas de potência ativa nas malhas de transmissão ou distribuição de energia elétrica
e podem comprometer a correta atuação dos equipamentos de proteção e medição.
O algoritmo evolutivo proposto neste artigo pretende alocar reguladores de tensão
para corrigir quaisquer desvios de potencial observados nos trechos do Sistema Elétrico,
090
através de um algoritmo de busca que utiliza os operadores genéticos de seleção, cru-

zamento e mutação sobre indivı́duos (soluções) representados por vetores de números
binários. A mitigação dos valores das tensões nas barras é realizada através da inserção
de reguladores indutivos. A cada geração do algoritmo genético é avaliado o fluxo de
potência ótimo da malha considerada em estudo através do software MATLAB (ambiente
MATPOWER), para averiguar se as soluções avançam no sentido de reduzir os desvios da
tensão elétrica nos ramos e se as perdas de potência ativa são diminuı́das.
Nos trabalhos de [Resener 2008] e [Alves 2012] é realizada a alocação ótima
de Reguladores de Tensão em Sistemas de Distribuição Elétrica Radiais, usando uma
fórmula linear inteira mista. Em [Hamida et al. 2016] um algoritmo multiobjetivo SPEA2
(Strength Pareto Evolutionary Algorithm) é utilizado para situar e dimensionar os grupos
de Geração Distribuı́da baseada na energia solar, minimizando o custo operacional anual
da instalação e as perdas de potência do sistema. O problema de alocação de reguladores
de tensão apresentado neste artigo, demanda que sejam minimizadas as perdas elétricas do
sistema após a instalação de até 04 equipamentos no máximo. De certo modo, a limitação
da quantidade de reguladores contribui para um segundo objetivo que é de minimizar o
custo financeiro do projeto.
2. Variações de Tensão no Sistema Elétrico

A ANEEL (Agência Nacional de Energia Elétrica) estabelece que nenhum con-
sumidor em tensão superior a 1 kV pode receber energia elétrica num nı́vel de tensão
fora da faixa de -5% a +5% da tensão nominal do sistema. Para os consumidores atendi-
dos em tensão secundária de distribuição a Agência Reguladora recomenda na Resolução
676/2003 as faixas de tensão para os sistemas monofásicos e trifásicos. O regulador de
tensão é um equipamento destinado a manter um determinado nı́vel de tensão em um sis-
tema elétrico, quando submetido a uma variação de tensão fora dos limites especificados.
A Tensão Contratada (TCO) da unidade consumidora (em tensão superior a 1 kV)
deve situar-se entre 95% e 105% da tensão nominal de operação do sistema no ponto
de entrega. Como o nı́vel de carregamento dos sistemas de distribuição varia de forma
significativa ao longo das horas do dia, dos dias da semana e das estações do ano, torna-se
importante um estudo aprofundado sobre como manter a tensão de atendimento dentro
da faixa dos valores adequados. Ademais, a carga do sistema apresenta suas variações
horárias, diárias e mensais. Os valores permitidos nos alimentadores para as variações de
tensão em regime permanente são mostrados na figura 01.
Figura 1. Tensões nominais padronizadas entre 1 kV e 69 kV
Na figura 02 é destacado um Regulador de Tensão tı́pico dos Sistemas de

Distribuição. Esse dispositivo trabalha com tensões nominais em valores por volta de
091
14 kV e geralmente é instalado em posteação de concreto. Neste artigo, apesar de o sis-

tema considerado na simulação ser majoritariamente de distribuição, o algoritmo genético
pode alocar reguladores em quaisquer setores do Sistema Elétrico de Potência.
Figura 2. Regulador de Tensão de 32 degraus
3. Algoritmo Genético Simples

Os algoritmos genéticos (AG) são uma classe de algoritmos da computação evo-
lutiva que são inspirados nos mecanismos de seleção natural para resolver problemas por
meio do emprego de estratégias de busca paralela, estruturada e aleatória. O fluxograma
mostrado na figura 03 esclarece os passos a serem seguidos por um Algoritmo Genético
Simples.
Figura 3. Fluxograma do Algoritmo Genético Simples
092
A modelagem da solução geralmente é realizada por meio da representação de

um indivı́duo. Cada indivı́duo possui um código genético chamado de cromossomo que
pode ser representado por vetores de números binários. Segundo [Holland 1975] qualquer
problema poderia ser satisfatoriamente modelado usando essa codificação. Na figura 04 a
seguir é destacada a estrutura de um indivı́duo representado por um cromossomo binário.
Figura 4. Indivı́duo representado por um cromossomo binário
A população de um AG é um conjunto de indivı́duos selecionados durante cada

iteração do algoritmo. O tamanho da população pode influenciar diretamente no desem-
penho de um AG. Populações muito pequenas não são capazes de garantir a diversidade
de soluções necessárias para a convergência, devido a uma baixa exploração do espaço
de busca. Já o contrário, poderá levar a uma degradação do desempenho do AG pela
quantidade de indivı́duos a serem avaliados em cada geração e pelos recursos computa-
cionais despendidos. Este trabalho apresenta o uso de um AG simples para a alocação
ótima de reguladores de tensão no Sistema Elétrico de Potência, para corrigir distúrbios
de afundamento ou elevação da tensão elétrica.
4. Metodologia
A metodologia deste trabalho baseia-se em determinar quais setores das linhas da
rede de distribuição devem receber reguladores de tensão de 32 degraus, especificando os
nı́veis de tensão a serem ajustados nas saı́das dos mesmos, através de um código simulado
em ambiente MATLAB [Szuvovivski 2008][Robinson 2009]. Na figura 05 é mostrado o
fluxograma do algoritmo desenvolvido.
Figura 5. Fluxograma do Algoritmo desenvolvido
093
O algoritmo da figura 05 inicia através da geração da população inicial, G=0, cal-

culando, em seguida, o fitness de cada indivı́duo. Depois, selecionam-se os n indivı́duos
mais aptos que seguirão para a próxima geração e incrementa-se o número da geração.
Caso o número máximo da geração seja alcançado, o melhor indivı́duo será decodificado
e, em seguida, executa-se o fluxo de potência para verificar os resultados obtidos. Se o
número máximo não for alcançado, realiza-se a seleção por torneio a fim de escolher os
melhores indivı́duos para participarem das operações genéticas, cruzamento e mutação,
que irão formar uma nova população de tamanho 2n. Posteriormente, adiciona-se apenas
o melhor indivı́duo da geração anterior, caracterizando o elitismo.
Por fim, calcula-se novamente o fitness de cada indivı́duo a fim de selecionar os n
mais aptos da nova população, fechando o ciclo que se repete até que o número máximo
da geração seja atingido. A rede na qual o algoritmo realizará a alocação de reguladores
de tensão é um sistema de 24 barras, 23 linhas e 04 geradores. Para determinar o valor das
tensões da barra, utiliza-se o MATPOWER [Zimmerman et al. 2011] para calcular o fluxo
de potência. Em seguida, é verificado se as tensões respeitam os limites exigidos pela
ANEEL. Para garantir isso, a função fitness, a qual o Algoritmo Genético deve minimizar,
indica o somatório da distância entre as tensões nas barras e o valor de 1 pu, sendo a
solução ideal um sistema em que todas as barras possuam valor nominal.
Vale ressaltar que, neste trabalho, serão alocados no máximo quatro reguladores de
tensão. A codificação de um indivı́duo é imprescindı́vel para encontrar a melhor solução
através do Algoritmo Genético. Um indivı́duo mal codificado pode, por exemplo, tornar-
se extenso demais e fazer com que o AG necessite de um número maior de gerações para
obter uma boa solução. A figura 06 apresenta a codificação de um indivı́duo.
Figura 6. Codificação de um indivı́duo
Através da figura 06 percebe-se que a codificação é composta por três partes. A

primeira parte indica a quantidade de reguladores de tensão que serão alocados, cujo valor
máximo é quatro. A segunda parte informa onde os reguladores serão alocados, logo, para
esse sistema, necessita-se de cinco bits. No entanto, se o valor da solução for maior que
23, o mesmo será substituı́do por 23 (quantidade de linhas). Por fim, a terceira parte
determina a tensão na barra após a ação do regulador. Deve-se atentar ao fato de que
essa parte só é gerada caso a opção pela tensão ajustada seja o melhor ajuste entre 0,95 e
1,0469 p.u. Nesse caso, necessita-se sempre de cinco bits para codificar a tensão ajustada.
A decodificação destes bits em tensão requer que eles sejam, primeiramente, convertidos
de binário para decimal e em seguida, este número decimal é aplicado na equação para
ser convertido em um valor de tensão conforme a equação 01 a seguir.
Tensão ajustada = 0,003125*Número Decimal + 0,95 (1)
094
A Tensão ajustada é o valor de potencial na barra subsequente ao regulador de

tensão (RT). O Número Decimal é o valor convertido a partir dos bits que especificam a
tensão elétrica. O número 0,003125 é o step dos 32 degraus possı́veis de serem obtidos
com os cinco bits, possibilitando que o ajuste da tensão na barra subsequente ao RT varie
de 0,95 a 1,0469 p.u. Destaca-se que esse ajuste da tensão elétrica de 0,95 a 1,0469 p.u
foi especificado para garantir uma margem de segurança em relação aos limites impostos
pela Resolução N◦ 505 da ANEEL que são de 0,93 e 1,05 p.u. A junção da segunda
e da terceira partes da codificação de cada regulador de tensão é chamada de molde.
Então, para cada regulador de tensão tem-se um molde, o que acarreta na alocação de, no
máximo, quatro moldes por indivı́duo vide figura 07.
Figura 7. Exemplo de decodificação de um indivı́duo
Para um melhor entendimento da codificação do indivı́duo, a figura 07 apresenta

um exemplo de solução ou indivı́duo para o sistema proposto nesse trabalho. Os dois
primeiros bits à esquerda na figura 07 indicam que serão alocados dois reguladores de
tensão, logo, descartam-se o terceiro e quarto moldes. É importante observar que os
bits 00 à esquerda representam um RT, 01 representam dois RTs, 10 representam três
RTs e 11 representam quatro RTs. Em seguida, as informações do primeiro molde são
decodificadas, onde os bits 00000 indicam que o primeiro regulador estará na linha 01
e os bits 11100 revelam que a tensão ajustada será igual a 1.0375 p.u. Para o segundo
molde os bits 10000 indicam que o segundo regulador estará na linha 16 e os bits 01001
revelam que a tensão ajustada será igual a 0.9781 p.u. Os principais parâmetros utilizados
no algoritmo genético estão apresentados na figura 08.
Figura 8. Parâmetros do Algoritmo Genético Desenvolvido
095
5. Resultados e Discussão
No sistema utilizado para simulação temos uma linha de 115 kV que liga as barras
1 e 24, uma linha de 64 kV que está entre a barra 24 e 23, e todas as demais linhas são
de 14 kV. Definido o sistema a ser otimizado, foi inserido os dados no algoritmo genético
criado em ambiente MATLAB. Após executado dez vezes, os resultados de fitness do AG
foram, respectivamente: 0.3224, 0.3224, 0.3224, 0.3224, 0.3228, 0.3224, 0.3224, 0.3224,
0.3224, 0.3224. Os resultados provam que o valor ”0.3224”, é o valor de fitness mais
indicado, pois foi encontrado em 90 por cento das vezes que o programa foi executado.
Através deste valor de aptidão, o sistema é readequado com a inserção de reguladores
nas seguintes linhas: Linha 1-24, Linha 24-23, Linha 13-3 e Linha 9-10. Na figura 09 é
ilustrado o mapa do sistema com os locais para inserção dos reguladores de tensão.
Figura 9. Localização dos reguladores de tensão sugeridos pelo algoritmo
Com a inclusão dos reguladores de tensão no sistema, as tensões nas barras foram
reajustadas para o valor mais próximo do ideal de 1 p.u, ou para ı́ndices que respeitam
a margem de tolerância de -5% a +5% do valor de tensão nominal. Na figura 10 está
ilustrado um gráfico com as tensões em cada uma das 24 barras do sistema, antes e depois
da implementação dos reguladores de tensão de 32 degraus.
Figura 10. Valores de tensão nas barras do sistema
096
6. Conclusão
Enfim, este artigo apresentou uma metodologia baseada no Algoritmo Genético
Simples para a alocação de Reguladores de Tensão no Sistema Elétrico de Potência e
obteve resultados satisfatórios. O ajuste da tensão elétrica das barras do sistema para
valores próximo de 1 p.u (valor nominal) contribui para a redução da perda de potência
ativa. Manter os nı́veis de tensão adequados nos barramentos do SEP é importante tanto
para a concessionária de energia elétrica, que precisa garantir o fornecimento energético
de qualidade, quanto para o consumidor que busca tarifas mais baixas.
Analisando os resultados obtidos por meio da simulação percebe-se a eficiência
do Algoritmo Genético no processo de alocação dos reguladores de tensão, sendo possı́vel
manter os nı́veis de tensão dos alimentadores compatı́veis com as normas previstas pela
ANEEL. Estabelecer a quantidade máxima de reguladores que devem ser alocados na
rede elétrica, serve como uma medida para redução dos custos advindos da instalação
dos equipamentos, fazendo o algoritmo buscar as melhores localizações dos RTs segundo
uma adequada viabilidade econômica de projeto.
Como trabalhos futuros pode-se utilizar uma abordagem multiobjetivo através dos
algoritmos SPEA2 (Strength Pareto Evolutionary Algorithm) e NSGA2 (Non-dominated
Sorting Genetic Algorithm) para lidar com mais metas de projeto. É possı́vel ainda incluir
restrições que devam ser respeitadas quando da execução do mecanismo de busca por
soluções em uma fronteira Pareto-Ótima.
Referências
Alves, R. P. (2012). Alocação Ótima de Reguladores de Tensão em Sistemas de
Distribuição de Energia Elétrica Radiais Usando Uma Fórmula Linear Inteira Mista.
Ilha Solteira, SP, first edition.
Dugan, R. C., McGranaghan, M., and Beaty, S. S. . H. (2002). Electrical Power Systems
Quality. McGraw-Hill, second edition.
Hamida, I. B., Salah, S. B., Mshali, F., and Mimouni, M. F. (2016). Optimal integration of
solar distributed generations in distribution network using spea2. In 2016 17th Inter-
national Conference on Sciences and Techniques of Automatic Control and Computer
Engineering (STA), pages 368–373.
Holland, J. (1975). Adaptation in Natural and Artificial System. Complex Adaptive Sys-
tems. The MIT Press, first edition.
Resener, M. (2008). Alocação e Ajuste Ótimo de Reguladores de Tensão em Sistemas de
Distribuição. Worcester polytechnic institute, porto alegre edition.
Robinson, P. (2009). Analysis of Distributed Resources Potential Impacts on Electric
System Efficacy. Worcester polytechnic institute, master of science edition.
Szuvovivski, I. (2008). Alocação Simultânea de Bancos de Capacitores e Reguladores de
Tensão em Sistemas de Distribuição Usando Algoritmos Genéticos e Fluxo de Potência
Ótimo. UFPR, curitiba edition.
Zimmerman, R. D., Murillo-Sanchez, C. E., and Thomas, R. J. (2011). Matpower:
Steady-state operations, planning, and analysis tools for power systems research and
education. IEEE Transactions on Power Systems, 26(1):12–19.
097
VocaTeen: Um Jogo Multiplataforma Auxiliar para

Orientação Vocacional de Adolescentes
Francisco Ramon, Francisco Imperes e Rodrigo Leal
Universidade Federal do Piauı́ (UFPI)

Picos – PI – Brasil
{fcoramon, fcoimperes, rodrigo.trabalhos.ufpi}@gmail.com
Abstract. Choosing a professional career is an important occasion in the future

of a teenager’s life. In a period so crucial and motivated by the lack of appropri-
ate professionals for this, some of these young people look for some alternatives
that can help them in their decision. The process of Vocational Guidance (OV)
is one of the methods to which they can resort. As time has passed, these forms
of guidelines have been improved in order to provide content that can help and
favor these students in the moment of their decision. Examples include online
vocational tests and games that are available for many platforms. This paper
presents a tool named VocaTeen for OV. This tool was evaluated for its accuracy
and usability. The results showed that the tool was 74% correct when predicting
a professional career, and 90% for most of the interface criteria evaluated.
Resumo. A escolha da carreira profissional é uma decisão importante para a

vida e o futuro de um adolescente. Em um perı́odo tão crucial e em muitos casos
desmotivados por falta de profissionais adequados para auxiliá-los, parte destes
jovens procuram algumas alternativas que possam ajudá-los em sua escolha. O
processo de Orientação Vocacional (OV) é um dos meios que os adolescentes
podem recorrer. Com o passar dos tempos estas formas de orientações vêm se
modernizando com o intuito de disponibilizar conteúdos que possam facilitar
ou encorajar os jovens no momento de sua decisão. Como exemplos podem
ser citados os testes vocacionais online e os games disponibilizados nas mais
diversas plataformas. O presente trabalho apresenta uma ferramenta chamada
VocaTeen para OV. A ferramenta foi avaliada quanto ao acerto em orientações
e usabilidade. Os resultados foram 74% para acerto aproximado de profissões,
e acima de 90% em maior parte dos critérios de interface avaliados.
1. Introdução
A escolha de uma área acadêmica é um dos principais desafios para a maior parte dos
jovens, dado que, além da indecisão que alguns possuem, eles também se sentem influ-
enciados por familiares, amigos e até mesmo por questões financeiras, motivando-os a
tomar uma decisão que pode não ser adequada para sua carreira [Gonçalves 2008].
[Andrade et al. 2002] afirmam que a Orientação Vocacional (OV) é uma forma de
ajuda para os adolescentes e que não resulta somente na escolha de uma profissão, assim
como também no auxı́lio do seu autoconhecimento, envolvendo-os e incluindo-os em um
contexto social, econômico e cultural.
098
A OV é um processo de auxı́lio direcionado principalmente para estudantes de

nı́vel médio, entretanto, a ausência de psicólogos (profissionais adequadas para auxı́lio
de orientação) nas instituições de ensino públicas e até privadas é notável. Uma pesquisa
realizada por [Arreguy 2014] apresenta que cerca de 15% de instituições (públicas ou pri-
vadas) de cidades do Rio de Janeiro, no ano de 2010 a 2011, disponibilizavam psicólogos.
Um estudo feito por [Barreto et al. 2009] com visita a 24 escolas (públicas e privadas) da
cidade de Natal, no ano de 2006, constatou a ausência desses profissionais na rede pública,
assim como contratação com carga horária reduzida por instituições particulares.
[Dias et al. 2010] comprovam, em sua pesquisa, que a falta de OV para estudantes
acarreta diversos pontos negativos, dentre eles, um alto grau de desistência de ingressan-
tes no curso superior de Ciências Contábeis da Universidade Estadual de Montes Claros
(Unimontes).
Com isto, alternativas precisam ser avaliadas e estudadas para minimizar as con-
sequências da ausência de psicólogos para OV em escolas públicas e privadas. Os Testes
Vocacionais possuem a finalidade de orientar a escolha profissional de jovens apoiado em
suas aptidões [Abade 2005].
A presente proposta apresenta uma ferramenta, chamada de VocaTeen, direcio-
nada para auxı́lio vocacional de estudantes do ensino médio ou concludentes. A Seção
2 apresenta o software VocaTeen. Já a Seção 3 apresenta os trabalhos relacionados que
abordam a mesma temática deste trabalho. A Seção 4 exibe o experimentos para avaliação
da ferramenta de OV VocaTeen, como também os resultados obtidos. A Seção 5 discute
as conclusões e, por fim, etapas de continuidade desta pesquisa.
2. VocaTeen
A presente seção é voltada para apresentação do software VocaTeen. Discute-se sobre

suas funcionalidades, tecnologias, plataformas e imagens de execução. O VocaTeen é
baseado em duas etapas a saber:
• Aplicação de Questionário;
• Simulação de Rotina Profissional.
A Aplicação do Questionário é formada por 25 questões que devem ser respondi-

das pelo usuário. As questões procuram identificar o perfil do entrevistado baseado em
uma pontuação obtida por cada resposta. O questionário foi desenvolvido pela pedagoga
e orientadora educacional Maria da Luz Calegari e disponı́vel na página Veja.com1 . A
Figura 1 apresenta uma questão disponı́vel na primeira etapa do software. Ao término do
questionário, a aplicação exibe as carreiras profissionais apropriadas para o usuário. A Fi-
gura 2 demonstra o resultado das carreiras mais apropriadas após concluir o questionário.
099
Figura 1. Questionário. Figura 2. Carreiras.
Conforme o resultado do questionário aplicado, o estudante pode ser direcionado

para a segunda etapa do jogo: Simulação de Rotina Profissional. Esta etapa busca auxiliar
no conhecimento vocacional permitindo que estudantes tenham acesso ao cotidiano de
alguns profissionais. Para efeito de simulação, desenvolveu-se a rotina profissional de
duas classes de trabalhadores: Médico e Professor.
A simulação de Professor é baseada na apresentação de informações sobre
História, Matemática e Geografia (nı́vel médio) e após isso, o usuário simulando o pro-
fessor deve resolver um grupo de perguntas que são as dúvidas dos estudantes. A Figura
3 apresenta um conteúdo sobre Geografia passado para o usuário, em seguida, a Figura 4
demonstra uma dúvida de um estudante, em que o usuário deve responder corretamente.
Figura 3. Conteúdo. Figura 4. Dúvida.
A simulação da rotina profissional do Médico foi baseada no trabalho proposto por

[Oliveira 2014]. Este trabalho apresentou um simulador de cirurgia de Cataratas (doença
que pode levar a cegueira) utilizando realidade virtual para treinamento médico. A ci-
rurgia de Cataratas é realizada com Facoemulsificação, e configura-se como uma técnica
adequada para treinamento de médicos oftalmologista (especialistas no cuidado de olhos)
[Oliveira 2014].
A simulação do Médico é baseado na apresentação de instruções, e realização de
ações para a cirurgia que são a escolha da ferramenta e carregamento desta para o local
de uso. A Figura 5 apresenta as instruções para o usuário realizar cada passo da cirurgia,
em sequência, o usuário se depara com a tela da Figura 6 em que vai ter que aplicar o
conhecimento recebido anteriormente.
1
http://veja.abril.com.br/educacao/teste-vocacional-descubra-as-carreiras-que-tem-mais-a-ver-com-
voce/. Acesso em 04.08.2016
100
Figura 5. Instruções. Figura 6. Ferramentas.
O jogo VocaTeen possui disponibilidade para execução online, em que pode ser
acessada através de um endereço eletrônico ou com um aplicativo disponı́vel para siste-
mas Android, ou ainda offline para execução desktops com sistema operacional Windows
ou Linux. A adequação dos elementos da tela e configurações do jogo foram adaptadas
para cada plataforma atendida. A Figura 7 apresenta a ferramenta VocaTeen executada
em dispositivos móveis.
Figura 7. VocaTeen por Aplicativo.
A Figura 8 apresenta a versão online com hospedagem para uso em navegadores

na Internet. O usuário pode acessar os serviços através de microcomputadores ou dispo-
sitivos móveis (tablets, smartfones, etc). Assim, o VocaTeen se adapta para os recursos
disponı́veis para o usuário.
Figura 8. VocaTeen por Browser.
O acesso também é possı́vel para estudantes e concludentes que estejam sem co-
nexão à Internet. A Figura 9 apresenta o uso do aplicativo VocaTeen no sistema operaci-
onal Windows 7. O sistema pode também ser executado em outras versões do Windows,
ou de softwares livres como versões do Linux.
101
Figura 9. VocaTeen executado em Desktop.
Nesta seção, discute-se sobre pesquisas e trabalhos que propuseram ferramentas para
auxı́lio de OV. A Tabela 1 apresenta os trabalhos relacionados descritos em corres-
pondência com critérios confrontados. Logo em seguida, os critérios são discutidos para
cada um dos trabalhos pesquisados.
Tabela 1. Comparativo entre os trabalhos relacionados.

Trabalhos Plataforma Simulação de Rotina de Profissões
[Mahl et al. 2005] Uso Manual Não
[Bertelli 2007] Uso Manual Não
[Oliveira and Neiva 2013] Uso Manual Não
[Sousa 2016] Android Não
[Martins 2017] Online Não
Trabalho proposto Online, Desktop e Android Sim
• Plataforma: Mahl et al. (2005) desenvolveram uma técnica de orientação profis-

sional para estudantes interessados em vestibulares. O projeto de orientação foi
realizado como um retiro com acompanhamento dos pais e discussão de vários
temas profissionais. Bertelli (2007) implementou um jogo manual (para aplicação
individual ou em grupo) que permite os jogadores conhecerem suas aptidões pro-
fissionais. Oliveira e Neiva (2013) também propuseram uma técnica manual para
OV de estudantes. Os autores realizavam encontros em grupo para discussão e
avaliação de habilidades profissionais. Ao contrário dos autores e trabalhos an-
teriormente apresentados, Sousa (2016) desenvolveu um aplicativo para OV em
dispositivos Android. O aplicativo apresenta um questionário, para então, po-
der relacionar as respostas dos usuários com perfis profissionais. Martins (2017)
também seguiu essa linha de raciocı́nio ao desenvolver um teste vocacional (dis-
ponı́vel online) inspirado no questionário de afinidade.
• Simulação de Rotina de Profissões: Mahl et. al (2005) durante sua técnica ma-
nual de OV não realiza uma simulação de rotinas profissionais, apesar de apre-
sentar informações de profissões que são superficiais. Bertelli (2007) e Oliveira
e Neiva (2013) também não discutem ou demonstram o cotidiano, entretanto,
apresentam informações e condições sociais das profissões. Sousa (2016) e Mar-
tins (2017) desenvolveram um questionário online para OV sem demonstração de
simulações ou informações de profissionais.
102
Sobre o critério Plataforma, o VocaTeen se diferencia em relação aos demais

com sua abrangência de uso. A plataforma pode ser usada de forma online, ou offline
com execução em microcomputadores, notebooks e dispositivos móveis.
Em relação a Simulação de Rotina de Profissões, percebe-se uma inexistência
ou inadequação das soluções de OV relacionadas. Algumas pesquisas até propuseram a
discussão das informações e restrições das profissões, entretanto, não possibilitaram uma
simulação do cotidiano de profissionais. A proposta VocaTeen se destaca por simular o
ambiente profissional e rotineiro de algumas profissões, auxiliando o conhecimento das
mesmas por parte dos estudantes.
4. Experimento e Resultados
A seção discute sobre a eficácia da ferramenta para estudantes de nı́vel médio discutindo
sobre um experimento para verificação do acerto da ferramenta em identificação profis-
sional, e também sobre a usabilidade do sistema. O número de alunos da investigação
foram cinquenta estudantes de nı́vel médio, dentre estes, trinta e sete defenderam que se
identificaram com algumas das carreiras listadas no fim do questionário.
A Figura 10 apresenta o Gráfico de Setores buscando representar a predominância
das opiniões sobre a ferramenta VocaTeen. O Gráfico de Setores permite a realização
de comparações entre uma informação com o total, o que possibilita uma interpretação
instantânea dos dados agrupados.
Gráfico de Setores de Afinidade Com Alguma Área
26,0%
Categoria
Não
74,0% Sim
Figura 10. Predominância de Afinidade de Profissões.
Um outro dado importante é que os participantes entrevistados, sem exceção, con-

firmaram que a simulação do perfil profissional realizada pelo software VocaTeen contri-
buiu para entendimento da área profissional. Outro fator importante para avaliação de um
sistema é a sua Usabilidade. Usuários podem deixar de usar sistemas por consequência
de deficiências e dificuldades de interação [Sommerville et al. 2003].
Para avaliar a Usabilidade e Habilidade de Interação foi aplicado um questionário
ao fim do uso do software para os entrevistados. O questionário foi formulado com o
ErgoList1 , ferramenta desenvolvida pelo Laboratório de Utilizabilidade da Informática -
LabIUtil ( Universidade Federal de Santa Catarina - UFSC), com o intuito de inspecionar
a interface de um software. A Tabela 2 apresenta as perguntas e o que procuram investigar
no aplicativo VocaTeen.
1
http://www.labiutil.inf.ufsc.br/ergolist/
103
Tabela 2. Perguntas e Categorias.

Pergunta Avalia em
1 Menus de Páginas
2 Disposição de Objetos
3 Feedback das Ações
4 Denominações Concisas
5 Navegação
6 Interação de Aprendizagem
7 Interface Amigável
8 Código de Comunicação
9 Fácil Aprendizado e Uso
10 Utilidade do Software
11 Erro como Algo Negativo ou Positivo
12 Contextos Adequados
13 Linguagem de Fácil Entendimento
Durante aplicação dos questionários, os usuários poderia opinar Sim (como

satisfação de um critério), Não (como não satisfação) e Não se Aplica (como opção para
usuários que não queriam responder ou que achavam que a questão não se aplicava).
Nenhuma questão teve avaliação estatı́stica significativa para Não Aplicação de uma per-
gunta, os entrevistados avaliaram assim abaixo de 10% dos casos.
O gráfico da Figura 11 apresenta a satisfação dos usuários considerando as per-
guntas (ver Tabela 2) após uso do VocaTeen. Dentre as treze perguntas, dez foram ava-
liadas com satisfação acima de 90% pelos cinquenta entrevistados. A Figura 11 permite
reconhecer a deficiência do aplicativo VocaTeen no reconhecimento do erro por parte do
usuário. Cerca de 45% dos usuários defenderam que o sistema retorna a interpretação de
erro para o usuário, o que pode causar desestı́mulo, já que o software não se trata de um
jogo de pontuação ou ranking.
Gráfico de Satisfação de Usabilidade e Interação
100,00%
80,00%
Satisfação
60,00%
40,00%
20,00%
0,00%
1 2 3 4 5 6 7 8 9 10 11 12 13
Pergunta
Figura 11. Satisfação das Perguntas pelo VocaTeen.

A plataforma VocaTeen representa uma plataforma de OV que pode ser acessada por
diversos meios e dispositivos. Observamos que os usuários, em 74% dos casos, tiveram ou
apresentaram uma afinidade com a área recomendada pelo aplicativo. A avaliação sobre
104
a satisfação com a Simulação de Rotinas Profissionais foi expressiva dado que todos os
entrevistados avaliaram como uma funcionalidade agregadora na Orientação Vocacional.
A Usabilidade do VocaTeen apresentou avaliações acima de 90% em dez dos treze
quesitos. Como trabalho futuro, pretende-se fazer uma maior avaliação sobre a acurácia
na Orientação Vocacional. Ressalta-se que o uso da ferramenta é auxiliar para instituições
e escolas, não substituindo o papel dos profissionais especializados nesta tarefa.
Referências
Abade, F. L. (2005). Orientação profissional no brasil: uma revisão histórica da produção
cientı́fica. In Revista Brasileira de Orientação Profissional, pages 15–24. Belo Hori-
zonte.
Andrade, J. M., Meira, G. R., and Vasconcelos, Z. B. (2002). O processo de orientação
vocacional frente ao século xxi: perspectivas e desafios. In Psicologia: ciência e
profissão, volume 22, pages 46–53. Brası́lia, 3rd edition.
Arreguy, M. E. (2014). Violência e ausência de psicólogos nas escolas. In Physis: Revista
de Saúde Coletiva, volume 24, page 230. Rio de Janeiro.
Barreto, M. d. A., Calafangel, P. Â. F. R. D., and Zilanda, P. d. L. (2009). Estudo com
psicólogos escolares: Ações e desafios. Psicol. argum, 27(58):261–269.
Bertelli, S. B. (2007). Jogo das profissões: uma forma divertida de conhecer as profissões
e o perfil correspondente. 1d edition.
Dias, E. C. M., TheÓphilo, C. R., and Lopes, M. A. S. (2010). Evasão no ensino superior:
estudo dos fatores causadores da evasão no curso de ciências contábeis da universidade
estadual de montes claros–unimontes–mg. Congresso USP De Iniciação Cientı́fica Em
Contabilidade.
Gonçalves, Á. d. (2008). Proposta de Orientação Vocacional Profissional – Ensino
Médio. UnB.
Mahl, A. C., Soares, D. H. P., and Oliveira Neto, E. (2005). POPI: Programa de
Orientação Profissional Intensivo: Outra forma de fazer orientação profissional. São
Paulo.
Martins, C. (2017). Teste vocacional: Qual a profissão que combina com você.
Oliveira, C. M. R. d. and Neiva, K. M. C. (2013). Orientação vocacional/profissional:
avaliação de um projeto piloto para estudantes da educação profissional. Revista Bra-
sileira de Orientação Profissional, 14(1):133–143.
Oliveira, F. Z. (2014). Simulador de cirurgia de catarata aplicando realidade virtual. Mo-
nografia (Bacharel em Análise e Tecnologia da Informação), FATEC Ourinhos (Facul-
dade de Tecnologia de Ourinhos), São Paulo, Brasil.
Sommerville, I. et al. (2003). Engenharia de software, volume 6. Addison Wesley São
Paulo.
Sousa, P. L. P. (2016). Vocação do estudante: protótipo de um aplicativo android para
a realização de teste vocacional. Monografia (Bacharel em Sistemas de Informação),
UFPI (Universidade Federal do Piauı́), Picos, Brasil.
105
Proposta de um Sistema para Detecção de Obstáculos

Utilizando Câmera de um Smartphone para o Auxı́lio a
Deficientes Visuais
Diego P. Rocha1 , André M. Santana1 , Karoline de M. Farias1
1
Departamento de Computação – Universidade Federal do Piauı́ (UFPI)
Campus Universitário Petrônio Portella – 64049-550 – Teresina – PI – Brasil
{diegoporto,andremacedo}@ufpi.edu.br, [email protected]
Abstract. This paper aims to study and develop a mobile application with the
purpose of assisting the visually impaired to walk in a certain environment avoi-
ding collision with obstacles. This paper analyzed some computer vision algo-
rithms in order to find a solution with a viable cost to do obstacle detection on
mobile devices.
Resumo. Este artigo tem como objetivo o estudo e desenvolvimento de uma

aplicação móvel com o propósito de auxiliar deficientes visuais a caminhar por
um determinado ambiente evitando a colisão com obstáculos. Neste trabalho
são analisados alguns algoritmos de visão computacional a fim de encontrar
uma solução que apresente um custo viável para detecção de obstáculos em
dispositivos móveis.
1. Introdução
O Instituto Brasileiro de Geografia e Estatı́stica (IBGE) mostra que no Brasil existem
6,5 milhões de pessoas com deficiência visual [IBGE 2010] e, no mundo, de acordo a
Organização Mundial da Saúde (OMS), cerca de 39 milhões de pessoas são cegas e outros
246 milhões sofrem limitações severas de visão [OMS 2013].
Especialistas em orientação e mobilidade – profissionais treinados especifica-
mente para ensinar pessoas com deficiência visual como se locomover – afirmam que
deficientes visuais são capazes de se movimentar com segurança, confiança, de forma
independente, em casa e na comunidade, usando uma ampla gama de ferramentas e
técnicas [Bruno 2006]. Bengala branca com ponta vermelha (sı́mbolo internacional da
cegueira), cães-guia, piso tátil, semáforos com autofalantes e até mesmo softwares que
usam informações de GPS são exemplos de ferramentas/técnicas/softwares que auxiliam
os portadores de deficiência visual. O desenvolvimento da autonomia de locomoção acon-
tece de forma dificultosa para pessoas que não nasceram cegas, pois estas não apresentam
muita afinidade com os métodos de deslocamento para deficientes.
[Gonçalves et al. 2004] comentam que para o ano de 2004 as estimativas sobre o
número de deficientes visuais no Brasil chegou a mais de 1,2 milhões, onde essa quanti-
dade obedece a seguinte distribuição: 765 mil - população em regiões de pobre economia
e com pobres serviços de saúde; 414 mil - população em regiões de razoável economia e
com pobres serviços de saúde e 48 mil - população em regiões de boa economia e com
bons serviços de saúde.
106
Atualmente, é inegável a massificação dos dispositivos móveis, mais especifica-

mente dos smartphones que vem ficando cada vez mais baratos devido à sua produção
em massa. Além disso, o aumento das capacidades de processamento e armazenamento
destes dispositivos é notório e eles normalmente possuem diversos sensores embarcados
que podem ser usados como um sistema de percepção extraceptivo.
Neste sentido, o objetivo deste trabalho é analisar algoritmos de segmentação de
imagem para a detecção de obstáculos em um sistema de atenção para deficientes visu-
ais usando smartphones. A intenção é identificar um algoritmo que apresente um bom
resultado e baixo custo computacional devido as limitações de hardware do dispositivo
móvel.
No contexto dos dispositivos de auxı́lio a deficientes visuais, alguns inventores destinam

esforços para o desenvolvimento de artefatos que identificam a existência de obstáculos
no percurso do deficiente. O engenheiro brasileiro Gustavo Brancante, criou um boné
que consegue capturar imagens de objetos que estejam próximos aos deficientes visuais e
enviar pequenos estı́mulos elétricos ao cérebro, tornando possı́vel o desvio de obstáculos
e eventuais acidentes, ver Figura 1(a). O princı́pio desse método é captar informações
do ambiente, em um raio de seis metros, por meio de sonares acoplados a um boné
[Brancante 2011]. Assim, quando o deficiente visual está utilizando o boné e se apro-
xima de um obstáculo os sensores emitem sinais ao cérebro através de contatos com o
couro cabeludo indicando que ele deve desviar. O engenheiro comenta as dificuldades
que teve ao utilizar microcontroladores e diversos componentes eletrônicos, muitos dos
quais precisaram ser importados e integrados.
Usando câmeras como sensores principais para fornecerem informações aos de-
ficientes visuais, destaca-se o projeto EYE-21 [Eye-21 2011], ver Figura 1(b). Os enge-
nheiros do Centro de Pesquisa de Tecnologias Gráficas da Universidade Politécnica de
Valencia (UPV) criaram um sistema experimental, de modo a permitir que os deficien-
tes visuais entendam seus arredores através do uso do som. O sistema consiste em um
óculos com duas micro câmeras de vı́deo, um computador e um par de fones de ouvido.
As câmeras analisam o espaço à frente, e criam um modelo tridimensional do mesmo.
Os sons são atribuı́dos a cada uma das superfı́cies do espaço, e são reproduzidos através
dos auscultadores. Ao ouvir este mosaico de sons, os usuários deficientes visuais são
supostamente capazes de ”ouvir o espaço”com seus cérebros, transformando os sons em
formas.
O sistema TrueSight [Ferreira et al. 2012], onde o usuário utiliza um smartphone
com sistema operacional (SO) móvel Android para fotografar uma estrutura visual de re-
ferência como, por exemplo, um prédio ou uma parede caracterı́stica. A localização do
usuário é obtida com o reconhecimento da estrutura na foto. A aplicação então indica a
direção de qualquer destino que o usuário deseje, desde que o destino tenha sido previ-
amente armazenado na base de conhecimento da aplicação. Cabe destacar, ainda, que o
sistema TrueSight tem o intuito de demonstrar a viabilidade de um sistema de navegação
pedestre baseado em reconhecimento visual e em um banco de dados local.
107
(a) Capacete de Gustavo Bran- (b) Projeto EYE-21

cante.
Figura 1. Exemplos de projetos que usam câmeras como sensores para auxı́lio
a deficientes visuais.
3. Ferramentas Computacionais
As ferramentas básicas utilizadas na criação de um sistema de detecção de obstáculos em
smartphones consistem em bibliotecas de visão computacional e o dispositivo móvel com
sistema operacional. Das ferramentas de visão computacional, destacam-se as bibliotecas
Open Source Computer Vision (OpenCV), Lehrstuhl fuer Technische Informatik (LTI) e
Vision Something Libraries (VXS), e dos dispositivos móveis com sistema operacional,
cita-se os sistemas iOS da Apple, Windows Phone da Microsoft e Android da Google.
Para este trabalho foi selecionado a biblioteca OpenCV e dispositivos com sistema An-
droid.
3.1. OpenCV
O OpenCV foi originalmente desenvolvido na Intel, como uma iniciativa para avançar
a pesquisa em visão e promover o desenvolvimento de aplicativos com uso intensivo da
CPU baseados em visão. Após uma série de versões beta, a versão 1.0 foi lançada em
2006. Um segundo grande lançamento ocorreu em 2009 com o lançamento do OpenCV
2 que propôs importantes mudanças, especialmente a nova interface em C++.
OpenCV é uma biblioteca de código aberto, que atualmente se encontra na versão
3.2, com mais de 2500 algoritmos otimizados para processamento e análise de imagem
e vı́deo [OpenCV 2017]. Desde a sua introdução, tem sido amplamente adotado como
ferramenta de desenvolvimento pela comunidade de pesquisadores e desenvolvedores em
visão computacional.
Um dos objetivos da OpenCV é fornecer uma infra-estrutura de visão de compu-
tador simples de usar e que ajude as pessoas a construirem aplicações de visão sofistica-
dos rapidamente. A biblioteca OpenCV contém funções que abrangem muitas áreas, in-
cluindo inspeção de produtos em fábrica, processamento de imagens médicas, segurança,
interface de usuário, calibração da câmera, visão estéreo e robótica. Como Visão Com-
putacional e Aprendizado de Máquina, muitas vezes andam de mãos dadas, o OpenCV
também contém uma biblioteca completa, para uso de propósito geral, de Aprendizado
de Maquina (Machine Learning). Esta sub-biblioteca é focado em reconhecimento de
padrões estatı́sticos e clustering. A biblioteca de ML é muito útil para as tarefas de Visão
Computacional que estão no núcleo da OpenCV, mas também é geral o suficiente para
ser usado para qualquer problema de Aprendizagem de Máquina. Dentre os algoritmos
presentes no OpenCV, se destacam os algoritmos de segmentação de imagem, tais como
108
o Limiar de Média RGB, Blob Detection e Mean Shift, aos quais são utilizados nesse
trabalho.
3.2. OpenCV para Android

Devido à necessidade de rapidez ao realizar as tarefas de processamento de imagem. A bi-
blioteca de OpenCV para Android [OpenCVAndroid 2017] foi implementada em código
nativo, através da NDK permitindo que as suas principais funções e algoritmos de uso
intenso de CPU, sejam chamadas na linguagem Java, provendo as vantagens da facili-
dade de programação que o Android fornece para o ambiente Java e o poder e rapidez de
execução de um código nativo.
Embora a implementação nativa da biblioteca apresente uma grande vantagem de
desempenho, é importante lembrar que devido às limitações de hardware dos dispositivos
móveis, o desempenho da execução dos algoritmos em um computador é muito superior
à execução do mesmo em um smartphone ou tablet.
4. Proposta
O objetivo geral deste trabalho consiste em desenvolver um aplicativo para smartphone
baseado em Android e OpenCV com o intuito de auxiliar a locomoção de deficientes
visuais através da detecção de obstáculos em imagens capturadas pelo dispositivo.
O método proposto para o desvio de obstáculos será da seguinte forma. Primei-
ramente o dispositivo ficara acoplado à pessoa na altura da cintura e com inclinação de
aproximadamente 45o , de forma que a câmera consiga capturar a região próxima aos pés
do usuário como visto na Figura 2. Então, a heurı́stica irá considerar a área próxima
aos pés do usuário como região base (uma área sem obstáculos) e realizará um proces-
samento no resto da imagem procurando regiões que possuem uma textura diferente da
região sem obstáculo. As regiões com textura diferente serão consideradas como regiões
de obstáculo, ver Figura 3.
Figura 2. Posicionamento do sistema e região de visibilidade.
Foram escolhidos três algoritmos clássicos da biblioteca OpenCV para serem im-
plementados e analisados na detecção de obstáculos, o Limiar de Média RGB, Blob De-
tection de Cor e Mean Shift.
O Algoritmo por Limiar de média RGB se trata de um método para detectar
regiões que pertençam a uma mesma textura. Inicialmente a imagem é dividida em sub-
regiões e uma região base é definida, calculam-se as médias RGB de todas as sub-regiões
109
(a) (b) (c)
Figura 3. (a) Imagem original, (b) região base, próxima aos pés do usuário, (c)
imagem segmentada, a área quadriculada corresponde ao obstáculo.
e é feito um comparativo com a média RGB da região base. As sub-regiões que estiverem
dentro de um limiar r com relação à média da região base, então são classificadas como
pertencentes à mesma textura da região base, ver Figuras 4(a) e 4(d).
O Blob Detection é um algoritmo destinado a detectar as regiões em uma imagem,
que diferem nas propriedades como o brilho ou cor em relação às zonas ao redor dessa
região [Rosenfeld 1978]. Neste algoritmo, blob é uma região de uma imagem digital, em
que algumas propriedades são constantes ou que variam dentro de uma gama de valores
descritos previamente, ver Figuras 4(b) e 4(e). Há dois principais tipos de Blob Detection:
um por meio de métodos diferenciais, que é feito por meio da derivada da função com
relação à posição, e outro por meio de métodos de localização dos extremos, que são
pontos de máxima e mı́nimo de uma função. Todos os pontos pertencentes a uma região
blob podem ser considerados, de alguma forma, como semelhantes um ao outro. Para a
analise, foi utilizado o Blob Detection de Cor com localização de extremos.
O Mean Shift é um algoritmo iterativo para localizar a máxima de uma função de
densidade dado um exemplo discreto dessa função [Comaniciu and Meer 2002]. O Mean
Shift é uma técnica de homogeneização local que é muito útil para amortecimento de
sombreamento ou diferenças de tonalidade em objetos localizados, ou seja, ele substitui
cada pixel de uma vizinhança de até uma distancia d pelo valor da média da vizinhança se
o valor do pixel estiver dentro de um alcance r. Um exemplo está nas Figuras 4(c) e 4(f).
5. Resultados
Para os resultados, os três algoritmos foram implementados utilizando a versão 2.4.8 da
biblioteca OpenCV para Android, IDE eclipse versão 3.7.2, Android SDK versão 22.3.0
e executados em três dispositivos Android diferentes. Foram coletados dados quanto
ao tempo de execução dos algoritmos em relação a diferentes resoluções de imagem na
entrada, além de comparar o poder de processamento de cada dispositivo em cada teste.
É importante destacar a falta de controle da luminosidade que pode afetar os resultados.
E por fim, fez-se a análise do custo computacional por algoritmo.
Foram considerados 4 artefatos diferentes para a avaliação da execução dos algo-
ritmos com as seguintes configurações:
• Artefato 1 - Android 2.3.7 - S5P6422 ARM @ 667 MHz - 192 MB RAM;
• Artefato 2 - Android 4.4 - Dual-core Exynos Cortex-A9 ARM @ 1.2 GHz - 1GB
RAM;
• Artefato 3 - Android 4.4 - Quad-core Snapdragon S4Pro Krait ARM @ 1.5 GHz -
2GB RAM;
110
(a) (b) (c)
(d) (e) (f)
Figura 4. (a), (b) e (c) Imagens de originais, (d) Imagem ‘a’ após aplicação de
média RGB, (e) Imagem ‘b’ após aplicação de Blob Detection, (f) Imagem ‘c’ após
aplicação de Mean Shift.
• Artefato 4 - Desktop - Intel Core i7 de 64bits @ 2.0 GHz – 4GB RAM.

Os resultados de desempenho obtidos para cada artefato quanto ao tempo de
execução de cada algoritmo estão dispostos nas Tabelas 1. Foram realizadas 30 medições
para cada algoritmo, em cada resolução é calculada a média e desvio padrão. As imagens
são obtidas da câmera do dispositivo pelo modo Preview, onde o modo de captura é de
30 quadros por segundo. Os valores foram medidos em milissegundos e a resolução em
pixels, os campos não preenchidos correspondem às resoluções de imagem não suportada
pelo dispositivo.
Tabela 1. Tempo de execução dos algoritmos em relação ao tamanho das ima-

gens
Algoritmo 320x240 640x480 720x480 1280x720
Limiar M. RGB 28.6±10.5 - - -
Artefato 1 Blob Detection 29.9±3.6 - - -
Mean Shift 5528.3±1516.8 - - -
Limiar M. RGB 17.8±10.8 48.4±36.7 48.4±36.7 -
Artefato 2 Blob Detection 14.0±1.9 41.0±12.6 40.2±13.5 -
Mean Shift 1735.7±79.7 4160.5±673.6 4286.2±6475.2 -
Limiar M. RGB 6.1±0.4 30.1±13.0 37.1±24.6 76.8±17.6
Artefato 3 Blob Detection 5.9±0.4 20.0±4.2 22.1±6.1 54.2±7.7
Mean Shift 1049.6±741.6 2027.7±344.6 2386.0±412.7 6012.9±2030.8
Limiar M. RGB 1.8±0.3 5.3±0.1 - 22.1±1.9
Artefato 4 Blob Detection 1.7±0.0 5.3±0.1 - 13.3±0.5
Mean Shift 750.7±25.9 2368.2±484.6 - 8825.9±2228.7
Dos três algoritmos, o Blob Detection e Limiar de média RGB apresentaram o

melhor custo computacional, porem o Blob Detection apresentou algumas detecções in-
corretas, e o Mean Shift apresentou um custo computacional muito elevado. A Figura 5
111
representa a execução dos algoritmos citados com as regiões de obstáculo identificadas,

em um smartphone Android.
(a) (b) (c)
Figura 5. Resultado da execução dos algoritmos. (a) Limiar de Média RGB, (b)
Blob Detection, (c) Mean Shift.
6. Conclusão e Trabalhos Futuros

O trabalho teve como objetivo pesquisar soluções para o auxı́lio de deficientes visuais,
fazendo a utilização de visão computacional em dispositivos móveis. O sistema apre-
sentado demonstrou ter um custo computacional viável e uma taxa de acerto aceitável
na detecção de obstáculos em dispositivos móveis, porem ainda é necessário melhorias,
como a otimização e ou paralelização dos algoritmos implementados melhorando a ro-
bustez da aplicação.
Como trabalhos futuros, propõe-se, além da otimização dos algoritmos de
detecção, o desenvolvimento de interface de comunicação entre o deficiente visual e a
aplicação proposta.
Referências
Brancante, G. (2011). Boné equipado com sensores ajuda cegos
a desviar de objetos. http://www.lerparaver.com/lpv/
bone-equipado-sensores-ajuda-cegos-desviar-objetos. [On-
line; Acessado em 31/07/2017].
Bruno, M. M. G. (2006). Educação infantil: saberes e práticas da inclusão: dificuldades
de comunicação sinalização: deficiência visual. Brası́lia: Ministério da Educação.
Comaniciu, D. and Meer, P. (2002). Mean shift: A robust approach toward feature space
analysis. IEEE Transactions on pattern analysis and machine intelligence, 24(5):603–
619.
Eye-21 (2011). Project eye-21. http://newatlas.com/
eye-21-sound-system-for-blind/19138/. [Online; Acessado em
31/07/2017].
Ferreira, A. L. S., dos Santos, S. R., and de Miranda, L. C. (2012). Truesight a pedestrian
navigation system based in automatic landmark detection and extraction on android
smartphone. In Virtual and Augmented Reality (SVR), 2012 14th Symposium on, pages
91–99. IEEE.
Gonçalves, E., Avila, M., and Lousada, N. (2004). Projeto pequenos olhares. Conselho
Brasileiro de Oftalmologia.
112
IBGE (2010). Censo por estado de 2010. http://www.ibge.gov.br/

estadosat/. [Online; Acessado em 15/03/2014].
OMS (2013). World health organization - visual impairment and blindness. http://
www.who.int/mediacentre/factsheets/fs282/en/. [Online; Acessado
em 15/03/2014].
OpenCV (2017). Open source computer vision. http://opencv.org/. [Online;
Acessado em 31/07/2017].
OpenCVAndroid (2017). Opencv para android. http://opencv.org/
platforms/android/. [Online; Acessado em 31/07/2017].
Rosenfeld, A. (1978). Iterative methods in image analysis. Pattern Recognition,
10(3):181–187.
113
Projeto Versu: um aplicativo de legenda de filmes e seriados

para surdos
Evelyn Karinne Macedo Mota Silva1, Luania Caroline Paiva Lopes2
1
Colégio Técnico de Teresina (CTT) – Universidade Federal do Piauí (UFPI)
64049-550 – Teresina, PI – Brasil
2
Instituto Federal do Piauí (IFPI)
64000-040 - Teresina, PI – Brasil
Resumo. Este artigo tem o objetivo de mostrar o aplicativo Versu, que é um

recurso de inclusão e incentivo à compreensão do português pela pessoa surda.
O intuito do aplicativo é propiciar ao surdo acesso às informações midiáticas e
lazer audiovisual que comumente não têm legendas, com legendas adaptadas e
em português formal, servindo como ponte a uma melhor compreensão e de
incentivo ao uso do português adequado; uma vez que terão acesso aos dois
tipos de legendas: uma que facilitará sua compreensão e outra que será aliada
na escrita e leitura do português formal, usado e compreendido mais
facilmente por ouvintes.
Abstract. This paper aims to show the Versu application that is a resource for
inclusion and encouragement to the understanding of Portuguese by the deaf
person. The purpose of the application is to provide the deaf access to media
information and audiovisual leisure that usually have no subtitles, with
adapted subtitles and in Portuguese, serving as a bridge to a better
understanding and encouragement to use the appropiate Portuguese; since they
will have access to the two types of subtitles: one that will facilitate their
understanding and another that will be allied in the writing and reading of
formal Portuguese, used and understood more easily by listeners.
1. Introdução
Pessoas com limitações auditivas ainda sofrem diversos preconceitos no meio em que
vivem, seja na escola, ambiente de trabalho e até mesmo no meio familiar. Termos
como “mudinho” ou “surdo-mudo” geram bullying por parte de pessoas ouvintes que
acreditam que os surdos possuem algum tipo de deficiência mental ou que são incapazes
de fazer algumas atividades. Infelizmente, esses preconceitos ainda são praticados e
presenciados em relação às minorias.
O surdo tem limitações, no entanto, apenas auditiva; mas, em razão da “cultura”
114
do preconceito e do bullying, os mesmos se sentem marginalizados em relação à

sociedade considerada “normal”. Sentem-se marginalizados, sozinhos, deixados à parte
em uma roda de bate papo descontraído ou não escolhidos para participarem das
atividades em grupos da escola. Por vezes, os surdos sentem-se não compreendidos,
pelo fato de a grande maioria dos ouvintes preferirem o afastamento a tentar aprender a
se comunicar ou tentar entender esse universo silencioso.
Temos as variações de representações no decorrer de história de surdos e ao lado

destas representações, baseadas nos discursos ouvintistas, encontramos os vários
estereótipos negativos acerca de surdos, tais como mudo, deficiente, anormal, doente
e outros (STROBEL, 2007).
A pessoa surda é prática, consegue ver além e entende expressões e imagens

com mais facilidade do que, talvez, um psicólogo em sua análise. Estima-se que no
mundo mais de 360 milhões de pessoas possuem algum tipo de déficit auditivo,
segundo a OMS 2014 (Organização Mundial de Saúde). No Brasil, de acordo com o
IBGE 2010, existem mais de 9 milhões de pessoas com alguma deficiência auditiva. As
razões para que uma pessoa possa ter algum tipo de limitação auditiva são várias,
podendo ser do tipo leve, moderada, severa ou profunda; sendo adquirida desde o
nascimento ou por algum tipo de lesão. Segundo um estudo de classificação de Davis e
Silverman 1970, para o nível leve há uma perda entre 25 a 40dB, para a perda moderada
há uma perda entre 41 a 70dB, a severa fica entre 71 a 90dB e para a profunda acima de
90dB.
Em termos de educação, no Brasil, somente em 1857 os surdos tiveram acesso

aos estudos pelo Instituto Imperial dos Surdos-Mudos, fundado por D. Pedro II.
Atualmente é chamado de Instituto Nacional de Educação de Surdos (INES). Em
relação à comunicação o surdo possui sua própria língua que no Brasil é chamada de
Libras (Língua Brasileira de Sinais). A Libras, que é a primeira língua da pessoa surda,
tendo o português como a segunda, só foi oficialmente reconhecida em 2002 com a lei
nº 10.436/2002 e regulamentada em 2005 pelo decreto nº 5.626. Deve ser garantido, por
legislação, que a LIBRAS seja difundida como meio de comunicação e é assegurado ao
surdo o uso dela.
Relembrando que o surdo não é uma pessoa com deficiência intelectual e, por
vezes, há algum tempo, empregava-se o termo “surdo-mudo” que traz uma carga
depreciativa e de desconhecimento em relação ao surdo. Atualmente, esse termo é
malvisto pela própria comunidade surda.
(...) as comunidades de surdos de todo o mundo passaram a ser comunidades
culturais (...) "falantes" de uma língua própria. Assim, mesmo quando não vocaliza,
um surdo pode perfeitamente "falar" em sua Língua de Sinais, não cabendo a
denominação SURDOMUDO. Por outro lado, a mudez é um tipo de patologia
causado por questões ligadas às cordas vocais, à língua, à laringe ou ainda em
função de problemas psicológicos ou neurológicos. A surdez não está absolutamente
vinculada à mudez (...). Dizer que alguém que fala com dificuldades é MUDO é
preconceituoso, não acham? (RAMOS apud STROBEL, 2008)
115
2. Tecnologia Assistiva
Tecnologia é uma palavra de origem grega, que significa técnica, arte, ciência.
Tecnologias são meios, ferramentas e instrumentos que visam facilitar a vida em seus
diversos aspectos.
Ela está presente em todos os setores da sociedade e áreas de interesse, desde a

invenção da roda às inúmeras tecnologias de ponta que se tem conhecimento. Com isso,
temos o termo “Tecnologia Assistiva” que de acordo com a portaria n° 142, de 16 de
novembro de 2006, é
uma área do conhecimento, de característica interdisciplinar, que engloba

produtos, recursos, metodologias, estratégias, práticas e serviços que
objetivam promover a funcionalidade, relacionada à atividade e participação
de pessoas com deficiência, incapacidades ou mobilidade reduzida, visando
sua autonomia, independência, qualidade de vida e inclusão social.
A Tecnologia Assistiva tem por objetivo possibilitar à pessoa com deficiência

uma vida autônoma, condições para o bem-estar global do indivíduo e interação social.
Ampliando o acesso à comunicação, mobilidade, educação, trabalho, incluindo-a ao
meio em que vive.
Voltando o foco para o público surdo, a Tecnologia Assistiva transforma os

conceitos citados em prática, auxiliando a vida do surdo, principalmente na sua
comunicação com o meio ouvinte. Toda essa viabilidade faz com que o surdo se sinta
mais integrado/incluído nos ambientes em que frequenta. Várias ferramentas e serviços
já existem para promover essa interação, por exemplo: aparelhos auditivos, implante
coclear, alertas luminosos, Closed Captions, SignAloud (luva que transforma os
movimentos das mãos em sons), relógio vibratório etc.
Dentro da área de recursos digitais e dentre vários outros recursos que objetivam
proporcionar ao surdo uma vida com maior inclusão, na era dos smartphones e
supercomputadores temos:
a) Aplicativos de videochamadas: por meio do uso do recurso de vídeo, estes aplicativos

auxiliam o surdo em sua comunicação, presentes, por exemplo, no Whatsapp, Skype e
Facebook.
b) Intérpretes virtuais: esses intérpretes traduzem Português-Libras e Libras-Português,

por meio de texto escrito, áudio e vídeo. Por exemplo, o Hand Talk e VLibras, ambos
desenvolvidos no Brasil.
c) Sites acessíveis: disponibilizam intérprete virtual que auxilia na leitura de textos e

possibilitam um melhor acesso às informações presentes neles, tais como: sites de
universidades, de órgãos públicos etc.
116
3. O projeto Versu
O aplicativo Versu se enquadra entre as tecnologias assistivas, pois tem o propósito de

desenvolver alternativas que promovam a inclusão e minimizem a desigualdade de
possibilidades, independente de sua particularidade. Aliado à educação, estimula a
interpretação, leitura, compreensão e, no caso específico da pessoa surda, o
bilinguismo.
É um recurso de inclusão e incentivo à compreensão do português pela pessoa
surda. Ele insere e adapta legendas, que podem ser de dois tipos:
1. Português adaptado: destinado a uma melhor compreensão do surdo,
adequando algumas expressões e retirando termos pouco usados por eles, dando mais
objetividade, fluidez e clareza aos textos. O que faz com que o surdo apreenda melhor
as informações dos vídeos.
2. Português brasileiro formal: destinado ao incentivo do uso adequado do
português (norma-padrão). Uma vez captada a mensagem no português adaptado, o
surdo pode praticar a compreensão do português formal, por meio da leitura das
legendas nos vídeos.
O aplicativo tem o objetivo de proporcionar ao surdo acesso às informações
midiáticas e lazer audiovisual, que comumente não têm legendas, com legendas
adaptadas e em português formal. Servindo como uma ponte para uma melhor
compreensão e de incentivo ao uso do português formal, uma vez que terão acesso aos
dois tipos de legendas: uma que facilitará sua compreensão e outra que será aliada na
escrita e leitura do português formal, usado e compreendido.
A figura 1 mostra a tela inicial do aplicativo, nela o usuário terá as opções de
fazer o login caso já tenha um cadastro, cadastrar-se para usuários novos e recuperar a
senha.
Figura 1. Tela inicial do Versu
117
A figura 2 mostra o perfil do usuário depois de logado e o menu, onde tem as

opções de configuração do perfil e sugestões – com indicações de mídias do interesse
do surdo e feedback de melhorias ao aplicativo.
Figura 2. Conta do usuário e menu de configurações
A figura 3 mostra o vídeo já selecionado pelo usuário e as opções de legendas

disponíveis, sendo uma em português (formal) e a outra em português adaptado, voltado
para um melhor entendimento do surdo.
118
Figura 3. Tela da mídia e opção de legenda.
O projeto Versu, para ser utilizado, necessita que o usuário crie um perfil, no
qual irá preencher um cadastro com informações. Criado este perfil, poderá acessar e
escolher os filmes disponíveis na plataforma que estão separados por categorias. O
usuário também pode editar suas informações e recuperar e/ou trocar a senha de
acesso.
É um aplicativo de fácil uso e provê, inclusive, uma opção para dicas e sugestões
por parte do usuário, tornando o app bem mais interativo.
4. Conclusão
A tecnologia viabiliza a evolução da sociedade e permite que sejam alcançadas
melhorias em vários setores, como saúde, educação, meio ambiente; usando os recursos
e ampliando-os com aspectos que promovem a inclusão em variadas formas. Uma
dessas, em relação ao surdo, oportuniza a ampliação de sua cidadania, uma vez que é
uma ferramenta que o propicia certa autonomia por permitir a ele a comunicação com
ouvintes, mesmo que estes não dominem ou conheçam a Libras. O cenário de ações
para essa inclusão é muito desnivelado, visto que muitos estados brasileiros sofrem pelo
precário acesso à internet. Isso dificulta o alcance às tecnologias já existentes que dão
apoio aos surdos, familiares e amigos.
Com a necessidade do surdo de acessibilidade para filmes e vídeos, existe o

Closed Caption – que faz tradução simultânea –, e as legendas disponíveis e presentes
nas mídias; mas que não contam com adaptação na transmissão da informação, o que
pode comprometer o sentido real e o entendimento do que está sendo exibido ao surdo.
O Versu tem como diferencial a adaptação em suas legendas, priorizando o melhor
entendimento e acesso pleno à informação para o público-alvo, o que torna o projeto
totalmente focado ao mundo do sujeito surdo e suas idiossincrasias.
O aplicativo está em fase de implementação no seu desenvolvimento, e possui

como suporte a avaliação e feedback de alguns usuários surdos e de profissionais na
área de Libras.
5. Referências
Brasil. (2002) “Lei nº 10.436, de 24 de abril de 2002. Dispõe sobre a Língua Brasileira
de Sinais - LIBRAS e dá outras providências.” Diário Oficial da União.
http://www.planalto.gov.br/ccivil_03/Leis/2002/L10436.htm, Julho.
Brasil. (2005) “Decreto nº 5.626, de 22 de dezembro de 2005. Regulamenta a Lei nº
119
10.436, de 24 de abril de 2002, que dispõe sobre a Língua Brasileira de Sinais - Libras,
e o art. 18 da Lei no 10.098, de 19 de dezembro de 2000.”
http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2005/decreto/d5626.htm, Julho.
Brasil. (2009) “Tecnologia Assistiva.” Subsecretaria Nacional de Promoção dos
Direitos da Pessoa com Deficiência. Comitê de Ajudas Técnicas – Brasília: CORDE,
138 p.
http://www.pessoacomdeficiencia.gov.br/app/sites/default/files/publicacoes/livro-
tecnologia-assistiva.pdf, Julho.
IBGE. (2010) “Censo Demográfico 2010 – Características gerais da população, religião
e pessoas com deficiência”.
http://biblioteca.ibge.gov.br/visualizacao/periodicos/94/cd_2010_religiao_deficiencia.p
df, Julho.
STROBEL, Karin Lilian. (2007) “História dos Surdos: representações ‘mascaradas’ das
identidades surdas”. In: Estudos Surdos II. Petrópolis, RJ: Arara Azul. http://editora-
arara-azul.com.br/estudos2.pdf, Julho
STROBEL, Karin Lilian. (2008) “Surdos: vestígios culturais não registrados na
história.”. Tese (Doutorado em Educação) - Universidade Federal de Santa Catarina:
UFSC, Santa Catarina.
https://repositorio.ufsc.br/xmlui/bitstream/handle/123456789/91978/261339.pdf?sequen
ce=1&isAllowed=y, Julho.
120
AutoHome - Automação residencial de baixo de custo

Carlielson Damasceno de Souza1, José Vigno Moura Sousa2
1
Bacharel em Ciência da Computação pela Universidade Estadual do Piauí (UESPI) –
Piripiri – PI - Brasil
2
Mestrado acadêmico em Ciência da Computação, Professor efetivo na Universidade
Estadual do Piauí (UESPI) – Piripiri - PI – Brasil
Abstract. This paper presents a prototype of home automation (AutoHome) to
control internal lighting and air conditioning of homes, including a security
system with intrusion detection, gas leak and fire sensors, using the Arduino
platform. The system also automates the external lighting of the residence,
allowing as lamps to light at dusk and turn off at dawn. This prototype has as
main objective to reduce the costs to obtain the type of technology,
guaranteeing reliability, efficiency and convenience.
Resumo. Apresenta-se neste trabalho um protótipo de automação residencial
(AutoHome) para controle de iluminação interna e climatização de
residências, incluindo ainda um sistema de segurança com sensores de
detecção de intrusão, vazamento de gás e incêndio, com uso da plataforma
Arduino. O sistema também automatiza a iluminação externa da residência,
permitindo que as lâmpadas acendam ao anoitecer e apaguem ao amanhecer.
Este protótipo tem como principal objetivo minorizar os custos para obtenção
deste tipo de tecnologia, garantindo confiabilidade, eficiência e comodidade.
1 Introdução
Com o avanço da tecnologia, o homem sempre pensa em seu bem estar, conforto,
comodidade e segurança. Diante disso, ele tem buscado desenvolver ferramentas para
lhe proporcionar melhorias na qualidade de vida no seu ambiente residencial.
A automação residencial integra as diversas tecnologias do ambiente doméstico,
tais como: os eletrodomésticos, aparelhos de áudio, vídeo, persianas, portões
automáticos, iluminação, etc. Esse tipo de tecnologia também pode ser chamado de
domótica, que é representação da utilização de processos automatizados em residências
[TEZA 2002].
A automação residencial, além de trazer segurança, conforto e comodidade,
proporciona acessibilidade para pessoas idosas e/ou para pessoas com deficiência (com
dificuldades de locomoção). Um exemplo disso dá-se ao fato do (a) deficiente ou o (a)
idoso (a) não precisar ir até o interruptor para acender ou apagar a lâmpada, ou acionar
outra funcionalidade de sua residência, pois tal ação pode ser feita via celular, ou
computador, ou pelo comando de voz de forma simples.
Nesse trabalho, foi proposto o desenvolvimento de uma aplicação para a
plataforma Android, com o intuito de gerenciar os dispositivos de uma residência
conectando-os a um Arduino. Essa aplicação permite a conexão de um smartphone com
um microcontrolador, através do bluetooth, ativando e desativando alguns equipamentos
121
e sensores. Além disso, foi elaborado um sistema de automação residencial com uso dos
seguintes hardwares: Arduino, sensor de gás, sensor de presença, sensor de chamas e
sensor de luminosidade. Dessa forma, construiu-se uma maquete para integrar todos os
hardwares e demonstrar seu funcionamento em uma casa em miniatura.
2 Trabalhos relacionados
Na metodologia de Alves (2014) foi apresentado um sistema de automação residencial
utilizando um smartphone com sistema operacional Android e a placa Arduino com
ethernet shield para conectar-se com a rede. A comunicação entre o smartphone e o
Arduino é obtida por meio de um aplicativo desenvolvido para esta finalidade. Neste
projeto, controla-se a iluminação interna e externa da residência, usando um
smartphone, proporcionando assim o acionamento da iluminação de qualquer lugar
onde esteja.
Alvarez e Antunes (2015) construíram um sistema de automação para controlar
a iluminação de 6 cômodos e abertura/fechamento de 2 portões. O sistema é controlado
por uma página web que pode ser acessada de qualquer lugar do mundo ou por um
aplicativo através do bluetooth, que funciona apenas localmente. Desenvolveram este
aplicativo para a plataforma Android. Por intermédio da página ou do aplicativo, o
usuário escolhe a opção que desejar, e será enviado ao microcontrolador Arduino uma
mensagem e este executará a ação solicitada na mensagem.
No contexto dos trabalhos citados, a metodologia desse trabalho deu-se por
desenvolver um sistema de automação residencial fazendo integração do Arduino com
um celular Android. Para tanto, desenvolveu-se um aplicativo para a plataforma
Android, para gerenciar os dispositivos de uma residência que estão conectados ao
Arduino através do bluetooth, afim de automatizar o acionamento (ligar/deligar) de
lâmpadas e/ou de um ar condicionado. Além disso, consolidar um sistema de alarme,
caso a residência seja invadida ou se houver vazamento de gás ou focos de incêndio.
O diferencial deste projeto com relação aos trabalhos mencionados é o
acréscimo de alguns sensores, tais como: aplicação de um sensor MQ-2 para detecção
de vazamento gás, utilização do sensor de chamas para a percepção de focos de
incêndio e uso de um sensor de presença para detectar intrusões. Assim, quando esses
sensores detectam essas alterações no ambiente, automaticamente é acionada uma sirene
para alarmar sobre essas ações.
3 Material e Método
Nesta seção são citados todos os principais componentes de hardware usados para a
elaboração do protótipo de automação residencial. Estes foram divididos em módulos.
A Tabela 1 mostra todos os módulos com seus respectivos componentes de hardware.
Tabela 1: Módulos do protótipo
Módulos Materiais
Ligação de equipamentos Relé, cooler, interruptor three Way, e sensor LDR.
Alarme Relé, sensor de presença, sensor de chama e sensor de gás MQ-2.
Central Microcontrolador ArduinoUNO R3, e módulo Bluetooth HC-05.
A execução do sistema AutoHome é feita de forma sequencial. Primeiramente

são iniciados todos os sensores e configurado as portas do Arduino (entrada ou saída de
122
dados). O sistema então realiza uma sequência de instruções em ciclo constante

enquanto este estiver ligado (como mostra no hexágono na Figura 1).
Figura 1: Fluxograma do software

No ciclo, enquanto o Arduino não receber nenhum comando para executar, ele
permanecerá realizando a leitura dos sensores. Somente quando estes detectarem
alguma alteração no ambiente é que executarão a ação que está relacionada (pré-
programada) ao sensor. Caso contrário, apenas retorna para o início do ciclo.
No início do ciclo, se o Arduino receber algum comando para executar, seja para
ligar ou desligar algum equipamento, este realizará a ação informada. Assim, despois de
efetuada a ação solicitada, retornará para o início do ciclo e tudo repetirá. Nesse sentido,
o ciclo se torna infinito. Apenas será interrompido quando o sistema for desligado.
3.1 Módulo de ligação de componentes

O módulo de ligação de componentes é utilizado para o controle da iluminação interna e
externa da residência e para o controle da climatização. Neste módulo são usados os
seguintes componentes: 1(um) relé, 1(um) cooler, 1(um) interruptor three Way e 1(um)
sensor LDR, que serão descritos nas subseções seguintes.
O relé é utilizado para controlar dispositivos de alta tensão usando o Arduino.
Com este módulo é possível ligar qualquer equipamento com voltagem de até 220volts
[Alves 2014]. A Figura 2 mostra o módulo relé usado no trabalho, com o propósito de
controlar o acionamento e o desligamento das lâmpadas.
O LDR (Light Dependent Resistor ou resistor dependente de luz) é um sensor de
luminosidade. Sua resistência varia conforme a luminosidade incidida sobre ele, de
forma inversamente proporcional. Assim, se estiver claro sua resistência será baixa.
Quando estiver escuro, sua resistência será alta [Almeida 2010]. A Figura 3 apresenta o
sensor LDR usado nesse projeto com intuito de apagar e acender a iluminação externa.
Se for noite, as lâmpadas acenderão e, se for dia, elas apagarão.
123
O interruptor three way é um interruptor paralelo que permite ligar e desligar

lâmpadas de pontos diferentes [Júnior 2015]. Neste projeto, esse tipo de interruptor
funciona em paralelo com o smartphone, ou seja, possibilita acender e apagar as
lâmpadas manualmente ou usando um smartphone com Android.
O cooler é um ventilador, usado em computadores para resfriar as peças
internas, principalmente o processador. Este está sendo usado para simular um ar
condicionado que será representado em uma maquete. A Figura 4 mostra o cooler usado
no projeto.
Figura 3: Sensor
LDR
Figura 2: Módulo relé Figura 4: Cooler
3.2 Módulo Alarme

O módulo alarme possui sensores para detectar invasão, vazamento de gás e focos de
incêndio no ambiente. Neste módulo são usados: 1(um) relé, 1(um) sensor de presença,
1(um) sensor de chama e 1(um) sensor de gás MQ-2.
O sensor de movimento presença PIR (Figura 5) detecta movimento em um
local. Este módulo funciona da seguinte maneira: quando detecta alguma variação de
radiação infravermelha, os sinais analógicos são convertidos para digital, fornecendo
dois valores: zero ou um [Da Sila 2014].
De acordo com Theory circuit (2016) o módulo sensor de chamas (Figura 6)
detecta fontes de calor no recinto (usado no projeto para detectar focos de incêndio),
através de um sensor infravermelho que detecta o comprimento de onda da luz entre
760nm e 1100nm.
O sensor de gás MQ-2 (Figura 7) detecta a presença de fumaça e de alguns
gases, como: GLP (gás de cozinha), propano, metano, hidrogênio e outros tipos de
gases. Esse sensor consegue identificar se estiver em nível de 300 a 10.000 ppm (partes
por milhão) de gás no ar [Torres 2014].
Figura 5:
Figura 6: Sensor de
Sensor Figura 7:
chamas
movimento Sensor de gás
presença PIR MQ-2
3.3 Módulo central

O módulo central controla os módulos de ligação de equipamentos e alarme, recebendo
ou enviando informações aos sensores. Neste módulo, são usados os seguintes
componentes: 1 (um) Arduino UNO R3 e 1 (um) Bluetooth HC-05.
124
O Arduino UNO é uma placa de microcontrolador baseado no ATmega328P que

possui 14 pinos digitais de entrada / saída (6 podem ser usados como saídas PWM ), 6
entradas analógicas, tensão de funcionamento de 5V, memória flash de 32 KB, uma
conexão USB e um conector de alimentação. A linguagem de programação usada pra
para programá-lo é uma linguagem baseada em C/C++ [Bergmann 2013]. Na Figura 8
visualiza-se o Arduino UNO R3 usado no projeto AutoHome para gerenciar, ligar e
desligar os dispositivos conectados a ele. A programação do Arduino é feita na IDE
Arduino, como mostra a figura 9, onde o código é repassado, para o Arduino, por meio
dessa IDE via conexão USB.
O módulo Bluetooth HC – 05 é utilizado no AutoHome para comunicação com
smartphone. O módulo está representado na Figura 10.
Figura 10: Módulo

Figura 8: Arduino Bluetooth HC – 05
UNO R3
Figura 9: IDE
Arduino
4 Desenvolvimento do aplicativo SmartControl

O aplicativo SmartControl é desenvolvido na linguagem java para a plataforma Android
para fazer a comunicação do smartphone com o Arduino. No SmartControl, o usuário
escolhe a opção desejada e este envia uma mensagem para o AutoHome, que pode ser,
por exemplo, solicitando ligar uma lâmpada ou sensor de presença.
A interface principal do aplicativo SmartControl (Figura 11), com as opções de
Conexão, Quarto, Sala e Alarme. O submenu Conexão (Figura 12) possui as opções
para conectar e desconectar com módulo Bluetooth HC-05 do Arduino, podendo assim,
procurar por dispositivos para estabelecer uma conexão.
No submenu quarto, exibido na Figura 13, existem as opções de ligar e desligar
os dispositivos lâmpadas e ar condicionado do quarto. O submenu sala (Figura 14)
apresenta as seguintes opções: ligar e desligar a iluminação deste cômodo. Por fim, o
submenu alarme detém as opções de ligar ou desligar o sensor de presença do sistema
de segurança, além da opção de desligar a sirene, caso ocorra o disparo automático
(Figura 15).
5 Maquete
O protótipo do AutoHome foi desenvolvido em uma maquete (Figura 16). Nessa
maquete estão integrados todos os componentes de hardware que, a partir do aplicativo
SmartControl, é realizado um sequência de testes para comprovar o funcionamento dos
módulos e dos equipamentos de hardware conectados nessa maquete.
Para validar o funcionamento do AutoHome, inicialmente foi feito um teste de
pareamento, onde foi realizado uma conexão via bluetooth do SmartControl com o
125
Arduino instalado na maquete. Em seguida, foi testado o envio das mensagens do

aplicativo para o Arduino e, por fim, cada sensor conectado ao Arduino fora testado
para garantir a total funcionalidade da maquete.
Figura 11: Menu Figura 12: Tela Figura13: Tela

principal do aplicativo do submenu submenu
SmartControl Conexão Quarto
Figura 14: Tela Figura 15: Tela

submenu Sala submenu Alarme Figura 16: Maquete
6 Resultados
Nesta seção são descritos os resultados dos testes do aplicativo SmartControl, com os
submenus Conexão, Quarto, Sala e Alarme, interagindo com o AutoHome.
O aplicativo desenvolvido mostra-se eficiente na comunicação com o módulo
bluetooth do Arduino e no envio das mensagens. Nos testes realizados para
acionamento das lâmpadas e do cooler com o aplicativo, obteve-se uma resposta em
1segundo entre o clique no botão do aplicativo e o ligar ou desligar das lâmpadas. Nos
testes realizados com os interruptores three way as lâmpadas são acionadas
instantaneamente.
Na detecção de gás, o sensor MQ-2 teve um desempenho favorável,
conseguindo detectar a presença de gás quando o sensor atinge o valor especificado no
código, e disparando, automaticamente, o alarme. O sensor de chamas de fogo detecta
um foco de incêndio e também dispara um alarme. Neste caso, o alarme de incêndio.
O sistema de segurança usa um sensor de movimento presença, que, igualmente
aos sensores anteriores, apresentou um bom desempenho e dispara o alarme sempre que
percebe uma invasão.
126
O Arduino UNO apresentou um bom desempenho no recebimento,

processamento, execução das tarefas solicitadas e leitura dos dados dos sensores
instalados no sistema de automação, afirmando assim, a eficiência e eficácia de todos
componentes usados nesse projeto.
7 Custo total do projeto com hardware

Nesta seção é apresentado o valor gasto com todos os hardware usados no projeto
AutoHome. Os equipamentos possuem uma boa relação custo-benefício, devido à
eficiência destes e pelo baixo custo de aquisição dos mesmos. A Tabela 2 especifica os
valores dos principais componentes de hardware que foram usados neste projeto.
Tabela 2: Custo com hardware
Hardware Quantidade Preço Unitário Preço Total
Arduino UNO 1 R$ 49,90 R$ 49,90
Módulo Bluetooth HC- 05 1 R$ 39,90 R$ 39,90
Sensor de Gás MQ-2 1 R$ 19,90 R$ 19,90
Sensor de Chama fogo 1 R$ 14,90 R$ 14,90
Interruptor Three way 2 R$ 6,00 R$ 12,00
LDR 1 R$ 1,40 R$ 1,40
Sensor de Movimento 1 R$ 12,90 R$ 12,90
Fonte chaveada DC 9V 1 R$ 19,90 R$ 19,90
MóduloRelé 4 canais 1 R$ 26,90 R$ 26,90
Total R$ 197,70
No projeto desenvolvido, o custo com hardware foi de R$ 197,70. Entretanto,

para instalar em uma residência o custo aumenta, dependendo de outros acessórios úteis
à instalação, como: fios, relé e o pagamento de um técnico para a instalação. Contudo,
mesmo com esse dispêndio adicional, o custo da casa automatizada com sensores e
sistema de segurança é acessível. Atualmente, a instalação de um projeto de automação
residencial pode variar entre R$ 4.000 e R$ 70.000 ou mais, segundo o site
TechinBrazil (2015).
8 Conclusão
Neste trabalho, apresentou-se uma prototipação de automação residencial para controle
de iluminação interna e climatização da residência, incluindo ainda um sistema de
segurança com sensores de detecção de intrusão, vazamento de gás e incêndio, e
automatização da iluminação externa, permitindo que as lâmpadas acendam ao
anoitecer e apaguem ao amanhecer, tudo isso, com uso da plataforma Arduino. E
através do aplicativo SmartControl é possível conectar-se ao AutoHome, via bluetooth,
para controlar o acionamento e desligamento da iluminação, do ar condicionado e do
sistema de segurança. O sistema denominado AutoHome traz diversos benefícios para
uma residência, pois automatiza algumas atividades cotidianas.
Além disso, este protótipo de automação residencial diminui os custos, garante
confiabilidade e eficiência. Outros benefícios deste projeto para o usuário são:
comodidade, acessibilidade para pessoas idosas e/ou deficientes com dificuldades de
locomoção, e proporciona, ainda, segurança para os residentes da casa.
Como perspectiva, pretende-se aprimorar o protótipo, acrescentando 1) um
Shield GSM para que o sistema possa mandar mensagens para o proprietário da
127
residência na ocorrência dos seguintes casos: i) se o sistema de segurança disparar

(indicando que alguém invadiu a casa) ou ii) se o sensor de gás detectar que o botijão
está vazando ou iii) se o sensor de chamas detectar fogo, o sistema mandará um SMS
para o proprietário da residência informando o fato ocorrido, para que ele possa intervir.
2) um Shield Ethernet para que possa controlar a residência de qualquer lugar, bastando
apenas estar conectado à internet para fazer isso. 3) Implementar a função para controlar
ar condicionado. 4) E, ainda, expandir o desenvolvimento do aplicativo SmartControl
para a plataforma IOS e Windows Phone.
Referências
Almeida, Gustavo Caetano. Sistema controlador de iluminação de ambientes através de

interface computadorizada. 2010. 123 f. Trabalho de conclusão de curso (Engenharia
da Computação) – UNICEUB – DF.
Alves, Ígor Felipe Rorigues. Automação Residencial com Arduino e Android: Casa
inteligente. 2014. 55 f. Trabalho de conclusão de curso (Sistemas de Informação) –
FUNVIC - SP.
Alvarez, Daniel; Antunes, Felipe. Automação residencial utilizando bluetooth, ethernet
e smartphone. 2015. 47 f. Trabalho de conclusão de curso (Graduação em
Mecatrônica Industrial). UTFP, Curitiba-PA.
Bergmann, Sergio Oliveira. Acessibilidade através da automação residencial. 2013. 80
f. Trabalho de conclusão de curso (Engenharia da computação) – UNICEUB – DF.
Da Silva, Bruna Roberta Seewald. Sistema de automação residencial de baixo custo
para redes sem fio. 2014. 55 f. Trabalho de conclusão de curso (Engenharia da
Computação) – UFRGS – RS.
Júnior, José Maria Sombra. Novas abordagens para o ensino de física no ensino médio:
construção de projetos experimentais com materiais de baixo custo. 2015. 102 f.
Dissertação de mestrado (Mestrado Profissional de Ensino de Física) – UFERSA –
RN.
TechinBrazil. Integradores de automação residencial no Brasil. Junho de 2015.
Disponível em: < https://techinbrazil.com.br/integradores-de-automacao-residencial-
no-brasil> Acessado em: 23 de Maio de 2016.
Teza, Vanderlei Rabelo. Alguns aspectos sobre a Automação Residencial - Domótica.
2002. 108 f. Dissertação de Mestrado (Ciência da computação) – UFCS – SC.
Theory circut. Arduino flame sensor interface. 2016. Disponível:
<www.theorycircuit.com/arduino-flame-sensor-interface/> Acesso em: 15 de jun. de
2016.
Torres, Hector. Sensor de gas (MQ2). 2014. Disponível em: <hetpro-
store.com/TUTORIALES/sensor-de-gas-mq2/> Acesso em: 16 de jun. de 2016.
128
Identificação de Fenômenos de Transferência Grafo-

fônico-fonológica do Português Brasileiro (L1) Para o Inglês
(L2) Utilizando Frequências Formantes
Atos Apollo S. Borges1, Washington Luiz P. Rodrigues Filho1, Aratuza Rodrigues
Silva Rocha2, Wilson Júnior de Araújo Carvalho2, Fábio Rocha Barbosa1
1
Departamento de Engenharia Elétrica – Universidade Federal do Piauí (UFPI) –
Teresina, PI – Brasil
2
Programa de Pós-Graduação em Linguística Aplicada – UECE – Universidade Estadual
do Ceará – Fortaleza, CE – Brasil
{atosborges00,aratuzarocha}@gmail.com, [email protected],
Abstract. The phenomena of interlanguage transfer by non-native speakers are

already known and well documented in the literature. However, the
recognition and classification it is made mainly through transcriptions, a slow
and laborious process. In this paper, an investigation was made regarding the
use of formant frequencies as voice descriptor to classify these phenomena via
software. The mean of the formant frequencies were used to classify three
transfer phenomena through a kNN algorithm and an ANN. The results
indicate that the mean of the formant frequencies have potential to be used in
the classification of transfer processes.
Resumo. Os fenômenos de transferência entre línguas cometidos por falantes

não nativos já são conhecidos e bem documentados na literatura. Contudo, o
reconhecimento e classificação dos mesmos é feita, principalmente, através de
transcrições, um processo lento e trabalhoso. Neste trabalho foi feita uma
investigação a respeito do uso de frequências formantes como descritor de voz
para classificação desses fenômenos via software. Utilizou-se a média das
frequências formantes para classificar três fenômenos de transferência
através de um algoritmo kNN e uma RNA. Os resultados apontam que a média
das frequências formantes tem potencial no uso de classificação de processos
de transferência.
1. Introdução
Durante a aprendizagem de uma nova língua, manifesta-se um processo chamado de
fonologia da interlíngua. Esse processo caracteriza-se como a criação de um sistema
linguístico diferente da língua estrangeira aprendida (L2), por conta das características
da língua nativa (L1), que ainda exerce influência sobre tal sistema [ROCHA, 2012].
Assim, um estudante não muito experiente de uma língua estrangeira, por força da
língua materna, acaba transferindo seus conhecimentos para a nova língua, prejudicando
a sua compreensão. Tal fenômeno, que pode se manifestar durante a fala ou leitura oral,
denomina-se transferência de conhecimento grafo-fônico-fonológico de L1 para L2
129
[ZIMMER e ALVES, 2006]. Quando o indivíduo se depara com uma estrutura

desconhecida na língua estrangeira, este se utiliza de estratégias para adaptar L2 a uma
estrutura já conhecida presente em L1. A Tabela 1 reúne alguns dos processos de
transferência estudados em Zimmer e Bittencourt (2008), além de dar exemplos de
palavras onde ocorrem. A descrição da pronúncia está de acordo com o International
Phonetic Alphabet (IPA).
Tabela 1. Lista de alguns processos de transferência.
Palavra Pronúncia Pronúncia

Processo
exemplo correta produzida
Simplificação de encontros
skull [skul] [iskul]
consonantais por epêntese
Schwa paragógico dog [dɔg] [dɔgi]
Dessonorização terminal does [dΛz] [dΛs]
Mudança consonantal think [θInk] [tInk] ou [fInk]
Deslaterização de líquidas well [wel] [wew]
Vocalização de nasais finais beam [bi:m] [bi˜y]
O fato de que os sistemas de Text to Speech (TTS) da ferramenta Google

Tradutor® apresentam desvios quando são apresentadas palavras que não fazem parte
do léxico de treinamento já é reconhecido e a empresa regularmente publica artigos que
desenvolvem técnicas para evitar essas situações [KOU et al., 2015; GONZALVO e
PODSIADLO, 2014]. Como há indicativos para o tipo de arquitetura usada no sistema
online ser do tipo rede neural artificial [VAN DEN OORD et al., 2016], é possível
ponderar que a ferramenta seja capaz de simular os processos de transferência que
ocorrem em humanos. Nesses casos, o sistema se comporta como um aprendiz iniciante
de língua estrangeira, adaptando padrões já conhecidos pela sua rede neural (o cérebro
no caso do aprendiz), produzindo assim formas da L2 que apresentam características
indevidas da L1.
Apesar de se ter uma literatura já desenvolvida para fenômenos de transferências
grafo-fônico-fonológicas, há uma escassez de trabalhos voltados a reconhecer e
classificar esses processos de forma automatizada. A maioria dos estudos realiza o
reconhecimento do processo de transferência através da transcrição dos áudios, uma
tarefa árdua e custosa. Portanto, este trabalho procurou estudar a possibilidade de um
método para reconhecer a ocorrência desses fenômenos de forma automática através de
técnicas de classificação por software, como Redes Neurais Artificiais (RNAs) e
algoritmos k-Nearest Neighbor (kNN). Para gerar os exemplos de pronúncias nativas e
carregadas de fenômenos, foi utilizada a ferramenta Google Tradutor®.
O kNN é um classificador que faz previsões de acordo com os rótulos dos K
vizinhos mais próximos da instância de teste [FRUTUOSO et al., 2013]. A amostra é
classificada como da classe que possui o maior número de vizinhos próximos. Esta
técnica pode ser muito efetiva, mas requer que seja armazenado o conjunto inteiro de
treinamento e pode ter um alto custo computacional. Para a RNA, como trata-se de um
problema de classificação simples, optou-se por usar a arquitetura clássica MLP.
130
Foram escolhidos três processos de transferência baseando-se nos estudos de

Zimmer (2003), Rocha (2012) e Cabañero e Alves (2008). São eles: a) simplificação de
encontros consonantais resultando em epêntese (SCE), b) mudança consonantal (MC) e
c) schwa paragógico (SP). No primeiro processo o aprendiz, nativo do Português
Brasileiro, insere o elemento epentético no início da palavra. Como na palavra speak a
produção registrada é [is’piki] ao invés de [spIk]. O segundo processo trata da
substituição de uma consoante por outra, no caso da fricativa dental em palavras como
think, substituir [θ] por [t], ou por [f], ou até por [s], resultando na seguinte produção:
[tink], [fink], [sink], respectivamente. O terceiro processo caracteriza-se pela inclusão da
vogal final como estratégia de ressilabificação. Usando, por exemplo, nas palavras sing
e tongue temos que a produção dos aprendizes figura da seguinte forma: [singi], [tongi],
não obedecendo o padrão silábico-lexical do inglês.
Para realizar essa tarefa através de software, é necessário encontrar uma forma
apropriada de descrever o sinal de fala. Na literatura, é possível encontrar que as
frequências formantes são uma opção viável de descritor para os sinais de voz. O som
produzido pelas pregas vocais (fonte) passa pelo trato vocal, que funciona como um
filtro, onde ressoa com maior ou menor intensidade. A onda com máxima ressonância é
aquela cujos pontos de mínima e máxima vibração coincidem com o comprimento do
trato vocal. Na literatura sobre a produção de fala, a frequência dessas ondas de máxima
ressonância são denominadas formantes [SILVA, 1996, NOBRE-OLIVEIRA, 2007].
Essas frequências são especialmente úteis na caracterização de vogais, já que,
normalmente, as consoantes apresentam-se mais como ruídos. Portanto, uma hipótese
testada, neste trabalho, foi a de que, por serem capazes de identificar e caracterizar
vogais, as frequências formantes são capazes de identificar os processos de transferência
selecionados. Dessa forma, é possível saber se são realmente necessários outros
descritores em um sistema que faça a classificação de forma automática.
2. Fundamentação Teórica
Como a produção desses fenômenos de transferência leva em consideração tantos
aspectos do processo de aprendizagem, é interessante verificar o nível de proficiência
dos aprendizes através da sua habilidade de reconhecimento e produção de sons em
outras línguas. Zimmer e Bittencourt (2008) utilizaram-se disso para promover um
estudo que relaciona a ocorrência de fenômenos de transferência e a nota dos aprendizes
nos testes de Listening do TOEIC (Test of English for International Communication),
demonstrando que há correlação inversa entre a ocorrência de fenômenos e a nota no
teste. Dessa forma, há a possibilidade de se desenvolver um método de avaliação do
nível de aprendizado dos alunos baseado na identificação desses fenômenos. Uma forma
automatizada de realizar esse teste seria de grande valia para escolas de línguas e
sistema de ensino à distância, por exemplo.
Quanto à utilização de frequências formantes como descritor é possível
encontrar trabalhos como de Huang e Lippmann (1988) onde foi utilizado um banco de
dados de frequências formantes de vogais de palavras com estrutura [hVd]. Na Figura 1
é possível observar as fronteiras de decisão de uma rede neural de duas camadas
treinada com o algoritmo backpropagation. Na figura é mostrado como os aspectos
fonológicos podem ser classificados por até mesmo redes de arquitetura simples. Os
131
eixos representam os valores das frequências formantes das palavras indicadas. É

possível notar a formação de aglomerados passíveis de classificação.
Figura 1. Fronteiras de decisão de uma rede neural sobre as frequências

formantes de diversas palavras em inglês (HUANG e LIPPMANN, 1988, p.395).
Considerando o que foi encontrado, pode-se afirmar que há uma escassez de

trabalhos que utilizem técnicas de inteligência computacional para identificar
fenômenos de transferência de conhecimento grafo-fônico-fonológico. Dentre os
trabalhos encontrados destaca-se Silva (2010), que implementa uma rede neural de
Kohonen com o objetivo de facilitar a visualização da formação de aprendizes por grau
de similaridade no que se referia à transferência de acento de L1 para L2. Em resumo, a
rede foi capaz de agrupar os falantes que transferiram padrões acentuais do português
para o inglês e, de forma análoga, também foi capaz de segregar os grupos no mapa
auto-organizável.
3. Metodologia de Pesquisa
O corpus desta pesquisa foi construído a partir da literatura pesquisada. Foram retiradas
palavras já presentes nos trabalhos de Zimmer (2003), Rocha (2012) e Cabañero e Alves
(2008) que possibilitam os seguintes processos de transferência: a) simplificação de
encontros consonantais resultando em epêntese (SCE), b) mudança consonantal (MC) e
c) schwa paragógico (SP). As palavras foram selecionadas de acordo com várias
categorias: alta frequência (palavra de muito uso na língua), baixa frequência (palavra
de baixo uso na língua), cognatas, não-cognatas e logatomas (itens destituídos de
significado, mas que seguem a fonotática da língua em questão. Neste estudo, os
logatomas foram gerados a partir da modificação de palavras da língua inglesa). Na
Tabela 2 é mostrada a distribuição das palavras de cada categoria para cada processo.
Tabela 2. Distribuição do número de palavras-teste por categoria.
Processo Alta Frequência Baixa Frequência Cognata Não-cognata Logatoma Total

SCE 26 7 8 25 10 47
MC 27 6 8 25 10 43
SP 30 3 4 29 10 43
132
Para coleta de fenômenos foi utilizado o Google Tradutor® em duas opções de

idioma: Português Brasileiro (PB) e Inglês Norte-Americano (INA). As palavras foram
escritas na caixa de entrada da ferramenta e as opções selecionadas para inglês e
português. Para que o programa não traduza a palavra, a opção na caixa de entrada deve
ser selecionada para PB, e então deve-se escrever a palavra inglesa. Dessa forma, o
programa constrói a produção de voz da palavra inglesa utilizando um sistema adaptado
para PB, ocorrendo assim os fenômenos de transferência observados em humanos. Após
selecionar o idioma Inglês para a outra caixa, que corresponderia à tradução, aparece a
própria palavra inglesa. Também foi coletado o áudio nessa opção para obter a
pronúncia nativa da palavra. As palavras foram produzidas e coletadas uma a uma, já
que o algoritmo de TTS tenta levar em conta o contexto da sentença apresentada, o que
alteraria as amostras. Para gravar a produção foi utilizado o software Audacity, que
permite a gravação e manipulação de áudio. Os áudios foram gravados em formato
WAV 32-bit float PCM com frequência de amostragem de 44,1 kHz.
A frequências formantes foram obtidas através do software Praat, o qual faz
análise de sinais sonoros e já é adaptado para análise de aspectos fonológicos da fala. Os
áudios extraídos foram analisados e cortados no próprio software. Assim, foi obtido a
média das frequências formantes somente na região da palavra onde o fenômeno é
observado.
Para realizar a identificação de fenômenos nas produções foi desenvolvido um
algoritmo kNN através do software Matlab®. O algoritmo apresenta sua estrutura
clássica de classificação por número de vizinho mais próximos. As amostras de treino
correspondem à média das frequências formantes extraídas das palavras-teste.
Também foi desenvolvida uma RNA de arquitetura do tipo Multilayer
Perceptron (MLP). Novamente foi utilizado o software Matlab®, já que este apresenta
diversas ferramentas auxiliadoras na construção de redes neurais. Como não se trata de
uma base de dados muito grande, a opção utilizada para o treinamento foi o algoritmo
Levenberg-Marquardt. A rede, assim como o kNN, foi alimentada com os resultados das
extrações de média das frequências formantes dos áudios coletados.
4. Análise dos Resultados

Os resultados para a ocorrência de fenômenos de transferência grafo-fônico-fonológica
ocorreram conforme o esperado. Para os fenômenos SCE e MC o desvio na pronúncia
ocorreu em 100% das coletas feitas no idioma PB (47/47 no processos SCE e 43/43 no
processo MC). Já para o fenômeno SP a taxa de ocorrência foi de 39,5% (17/43). Este
resultado mais baixo já era esperado, já que dentre as palavras escolhidas para o corpus
haviam verbos com o sufixo “–ing” (25,6%), os quais não costumam causar processos
de transferência [CABAÑERO e ALVEZ, 2003].
Obviamente, quando a opção de áudio era o Inglês Norte-Americano não
ocorreram fenômenos de transferência. As pronúncias dessa opção de áudio foram
tomadas como referência para a classificação, sendo consideradas nativas.
A partir das extrações das frequências formantes dos áudios foi possível plotar
um gráfico relacionando as duas primeiras frequências formantes, de forma a observar
se há formação de grupos distintos. Na Figura 2 são mostrados os resultado para os
133
processos SCE (a) e SP (b). Na plotagem, foram incluídas todas as amostras coletadas,
tanto produzidas na opção de idioma PB como INA. É possível observar uma clara
aglomeração dos fenômenos no processo SCE. Para o processo SP há também uma
aglomeração, embora mais próxima das outras amostras.
(a) (b)
Figura 2. Plotagem das frequências formantes das amostras de dois processos.

(a) Processo SCE. (b) Processo SP.
Já a plotagem do processo MC pode ser observada na Figura 3. Embora os

fenômenos tenham ocorrido em todas as amostras coletadas no idioma PB, não é
possível observar uma formação clara de aglomerados.
Figura 3. Plotagem das frequências formantes das amostras do processo MC.
Com os resultados para o classificador kNN, foi possível perceber que o mesmo
teve um desempenho satisfatório na classificação dos processos de transferência SCE e
SP. Já para o processo MC, a porcentagem de acertos foi consideravelmente inferior em
relação aos outros processos. Isso ocorreu por conta da dispersão das frequências
formantes já demonstrada na Figura 3. Na Tabela 4 são exibidos os resultados
encontrados pela classificação com três diferentes porcentagens de testes. O valor de K
foi escolhido como 9 através de testes de tentativa e erro.
134
Tabela 3. Porcentagens de acerto do algoritmo kNN (K = 9).
Divisão dos dados Porcentagens de acerto para os Processos de Transferência

estudados (%)
(Treino/Classificação)
(%) SCE SP MC
30/70 100 90 15,4
50/50 100 90,9 31,8
70/30 100 90 63,3
Observando as porcentagens de acertos exibidas na Tabela 4, é possível
identificar que, colocando mais ou menos dados para treino não é sinônimo de uma
porcentagem de acertos maior ou menor. Isto ocorre em função da escolha dos dados de
treinamento. A porcentagem escolhida para os dados de treinamento influencia na
dispersão dos mesmos. A adição de mais amostras pode tornar o espaço mais disperso, e
portanto, mais difícil de classificar.
Usando a RNA os resultados também foram satisfatórios para classificação dos
processos SCE e SP. Embora tenha tido uma certa dificuldade para reconhecer
exemplos positivos do processo SP, por conta de sua menor ocorrência, a RNA foi
capaz de diferenciar as amostras e generalizar para exemplos não conhecidos. Já para o
processo MC a rede apresentou um percentual de acerto mais baixo, não sendo
totalmente capaz de reconhecer a ocorrência dos fenômenos dada a grande dispersão do
espaço de amostras. Os valores da Tabela 5 correspondem à média dos resultados após
50 repetições dos testes.
Tabela 4. Resultados da classificação pela RNA.
Acertos da rede de acordo com divisão dos Acerto da

dados (Treino/Validação/Teste) (%) Época média de
Processo melhor rede
convergência
20/15/65 50/15/35 70/15/15 (%)
SCE 99,4 99,9 100 100 27

SP 90,4 94,9 94,8 100 13
MC 50,6 52,5 52,9 76,9 10
5. Conclusão
Mesmo testando com técnicas mais simples, como kNN, e com técnicas mais
elaboradas, como a RNA, os algoritmos foram capazes de classificar com eficiência
somente os casos onde os desvios estão relacionados a vogais. Portanto, por serem
descritores leves e de fácil obtenção, é vantajoso utilizá-los para identificar fenômenos
específicos, os quais apresentem alteração, surgimento ou apagamento de vogais. Dessa
forma, é possível utilizar as frequências formantes concomitantes com outros
descritores. Por serem leves, estes tornam-se mais atrativos para situações onde se tem
espaço ou processamento limitado, como em dispositivos móveis ou embarcados.
Outras pesquisas devem ser desenvolvidas no futuro para obtenção de mais
informações sobre a classificação desses e de outros processos de transferência. Outros
descritores mais gerais devem ser testados, como LPC (Linear Predictive Coding) ou
135
Coeficientes Mel-Cepstrais, além de novas técnicas de classificação ou diferentes tipos

de arquitetura para os algoritmos utilizados. Além disso, a utilização de um conjunto de
dados maior também se faz necessária para alcançar níveis maiores de generalização.
Referências
Cabañero, M. B. e Alvez, U. K. (2008) “A transferência grafo-fônico-fonológica na
produção de seqüências ortográficas ‘ng’ do inglês (L2): uma abordagem
conexionista”, In: ReVEL. Vol. 6, n. 11, agosto de 2008. ISSN 1678-8931.
Frutuoso, R. L. et al. (2013) “Reconhecimento de câncer de pele do tipo melanoma”, In:
SBIC. Anais do 11º Congresso Brasileiro de Inteligência Computacional. Brasil.
Gonzalvo, X. e Podsiadlo, M. (2014) “Text-To-Speech with cross-lingual Neural
Network-based grapheme-to-phoneme models”, Proceedings of Interspeech, ISCA.
Huang, W. e Lippmann, R. (1988) “Neural Net and Traditional Classifiers”, In: Neural
Information Processing Systems, Anderson, D. (ed.), 387-396. New York: American
Institute of Physics.
Nobre-Oliveira, D. (2007) “The Effect of Perceptual training on the learning of English
vowels by Brazilian Portuguese speakers”, 211f. Tese (Doutorado), Pós-Graduação
em Letras/Inglês e Literatura Correspondente, Universidade Federal de Santa
Catarina, Florianópolis.
Rocha, A. R. S. (2012) “Os efeitos da instrução explícita em fonologia na produção e
percepção de consoantes da língua inglesa”, Dissertação (Mestrado) – Programa de
Pós-Graduação em Linguística Aplicada, Universidade Estadual do Ceará, Fortaleza.
Silva, A. C. C. (2010) “O uso de redes neurais auto-organizáveis para a análise do
conhecimento acentual em aprendizes brasileiros de língua inglesa”, Tese
(Doutorado)-Programa de Pós-Graduação em Linguística, Universidade Federal do
Ceará, Fortaleza.
Silva, A. H. P. (1996) “Para a descrição fonético-acústica das líquidas no português
brasileiro: dados de um informante paulistano”, 230p. Dissertação (mestrado) -
Universidade Estadual de Campinas, Instituto de Estudos da Linguagem, Campinas.
Van den Oord, A. et al. (2016) “WaveNet: A Generative Model for Raw Audio”,
Disponível em: https://arxiv.org/abs/1609.03499. Acesso em: 23/02/2017.
Zimmer, M. C. (2003) “A transferência do conhecimento fonético-fonológico do
português brasileiro (L1) para o inglês (L2) na recodificação leitora: uma abordagem
conexionista”, Tese (Doutorado). Faculdade de Letras, Pontifícia Universidade
Católica do Rio Grande do Sul, Porto Alegre.
Zimmer, M. C. e Alves, U. K. (2006) “A produção de aspectos fonético-fonológicos da
segunda língua: instrução explícita e conexionismo”, In: Revista Linguagem &
Ensino, Pelotas,v. 9, n. 2, p. 101-143.
Zimmer, M. C. e Bittencourt, H. R. (2008) “Produção e Percepção Oral em L2: Os
Processos de Transferência do Conhecimento Grafo-fônico-fonológico do Português
Brasileiro (L1) Para o Inglês (L2) e o Desempenho em Listening (L2)”, In: Cadernos
de Estudos Lingüísticos, v. 50, p. 1. 2008.
136
Internet das coisas: o caminho para cidades inteligentes no

Brasil
Leila Maria R. de Sousa1 , Wendley S. Silva2
1
Graduanda em Engenharia da Computação
Universidade Federal do Ceará (UFC - Campus Sobral) – CE, Brasil
2
Professor Ms. Engenharia da Computação
Universidade Federal do Ceará (UFC - Campus Sobral) – CE, Brasil
Abstract. Technological revolutions are setting new paradigms for society. In

this context, the Internet of Things emerges, intensifying these transformations.
This article proposes a theoretical approach that allows conduct reflections on
the concepts of Internet of things and smart city on the national scene, particu-
larly in the Northeast. Presenting a current and accepted view in the literature
about the definitions of IoT and its applications. The results presented were ob-
tained through a bibliographic review in books, congresses, articles, nationally
and internationally recognized.
Resumo. As revoluções tecnológicas estão estabelecendo novos paradigmas

para a sociedade. Neste contexto, surge a Internet das Coisas, intensificando
essas transformações. O presente artigo propõe uma aproximação teórica que
permita realizar reflexões sobre os conceitos de IoT e smart city no contexto
nacional, principalmente no Nordeste. O trabalho apresenta uma visão atual e
aceita na literatura sobre as definições de Internet das Coisas e suas aplicações.
Os resultados apresentados foram obtidos através de uma revisão bibliográfica
em livros, congressos, artigos, reconhecidos nacional e internacionalmente.
1. Introdução
Segundo [Giles 2010], a Internet teve início durante a Guerra Fria na década de 1960, a
partir de um projeto do exército americano. Os principais objetivos eram: desenvolver
um sistema de informação e comunicação em rede, que resistisse a um ataque nuclear, e
impulsionar a troca de informações entre os centros de produção científica. Os militares
consideravam que um único centro de computação, concentrando toda a informação, era
mais vulnerável a um ataque do que pontos conectados em rede. O embrião, do que
atualmente denominamos de Internet, foi então elaborado e chamado de Arparnet.
A popularização aconteceu em 1990, crescendo velozmente como uma rede global
de redes de computadores. Em 2000, havia aproximadamente 361 milhões de usuários de
Internet em todo mundo [Pingdom 2015]. No Brasil, a democratização aconteceu a partir
de 1995, segundo o Comitê Gestor de Internet no Brasil – [CGI 2010]. O acesso a rede
cresceu significativamente no país. Conforme o [CGI 2016], em 2014, 50% dos domicí-
lios, em áreas urbanas e rurais, possuía acesso à Internet. Em 2005, esse número era bem
menor: 17% dos domicílios urbanos possuíam computador e 13% estavam conectados.
137
Segundo [Duquennoy et al. 2009], atualmente cada vez mais dispositivos estão
funcionando a nossa volta. Os usuários necessitam acessar facilmente dispositivos, in-
dependentemente de suas escolhas de implementação. Na literatura, essa interconexão
de dispositivos globais é denominada Internet das Coisas (em inglês Internet of Things -
IoT).
De acordo com [Bartleson 2014], IoT anuncia ser uma das maiores revoluções
tecnológicas que a humanidade já observou. É um fenômeno em evolução. Para facilitar
a nossa compreensão, podemos dividi-la em quatro partes: dispositivos portáteis, casas e
aparelhos inteligentes, veículos conectados e cidades inteligentes. Pouco a pouco, a IoT
vai se tornando realidade e invadindo sutilmente o nosso cotidiano.
Em 2012, de acordo com especialista da área, a IoT foi classificada como uma
tecnologia emergente. Foi previsto que levaria entre cinco e dez anos para ser adotada
pelo mercado [Gartner 2015]. As aplicações possíveis com esse tipo de tecnologia são
diversas, produzindo impactos em todas áreas, incluindo eletrônica de consumo, saúde,
indústria, segurança, e de forma colateral, na maneira como a sociedade consome infor-
mação [Almeida 2015].
O presente trabalho propõe contextualizar o conceito de Internet das coisas, cida-
des inteligentes, bem como apresentar um panorama sobre smart cities, no cenário atual
do nosso país, com foco principal no Nordeste. O artigo também apresenta uma visão
atual e aceita na literatura sobre as definições de IoT e suas aplicações. A metodologia
empregada foi baseada em revisão bibliográfica de artigos, publicações em congressos
nacionais e internacionais, e livros.
2. Fundamentação teórica
2.1. Internet das Coisas
A Internet das coisas surgiu por meio dos avanços de várias áreas como microeletrônica,
sistemas embarcados, sensoriamento e comunicação. Em 1990, John Romkey desen-
volveu uma torradeira que poderia ser ligada e desligada pela Internet, considerado o
primeiro dispositivo de IoT [Mancini 2015]. O artigo Computer for the 21st Century,
publicado por Weiser em 1991, é considerado um marco na pesquisa sobre a IoT, sendo
citado em grande parte da literatura sobre o assunto [Singer 2012].
O termo Internet das Coisas foi utilizado pela primeira vez pelo britânico Ashton
e seus colegas de laboratório, no trabalho “I made at Procter & Gamble” publicado em
1999 [Ashton 2009]. Definir IoT não é uma tarefa simples, principalmente se pensar na
quantidade de áreas possíveis de envolver.
De acordo com a visão de [Singer 2012], IoT é um paradigma computacional com
grandes consequências na relação entre homem e objetos. Ela possibilita aos objetos do
cotidiano, que possuem capacidade computacional e de comunicação, conectarem-se à
Internet. Através dessa conexão, é possível controlar remotamente os objetos, acessá-los
como provedores de serviços, tornando-os inteligentes. Os objetos inteligentes apresen-
tam capacidade de processamento e comunicação aliados a sensores [Mancini 2015].
Conforme [Almeida 2015], IoT pode ser entendida como uma integração de ob-
jetos, tanto físicos como virtuais, conectados à Internet, permitindo que estes coletem,
138
compartilhem e armazenem uma grande quantidade de dados. Uma vez processados e

analisados tais dados geram informações e serviços.
2.2. IoT no Brasil
Em 2010, a cidade de Salvador recebeu o primeiro evento de IoT do Brasil, conhecido
como “1o Congresso de Tecnologia, Sistemas e Serviços com RFID”, organizado pelo CI-
MATEC SENAI e Saint Paul Etiquetas Inteligentes. Em 2011, Búzios sediou a 2a edição,
renomeada para “Congresso Brasileiro de Internet das coisas e RFID” [Mancini 2015].
Ainda no ano de 2011, foi criado o Forúm Brasileiro de Internet das Coisas, com o propó-
sito de expor à sociedade a importância e os impactos da IoT no desenvolvimento técnico
e econômico do nosso país [Fórum Brasileiro de IoT 2017].
O Governo Brasileiro, em 2014, instituiu a Câmara IoT, com objetivo de auxiliar a
elaboração de políticas públicas, viabilizar e acompanhar desenvolvimento de soluções de
Comunicação Máquina a Máquina (M2M) e de Internet das Coisas (IoT) para o mercado
brasileiro [Participa.br 2016].
Em dezembro de 2015, a Associação Brasileira em Internet das Coisas (ABINC)
foi fundada, com a finalidade de incentivar a troca de informações, estimular a ativi-
dade comercial, de pesquisa e desenvolvimento, e representar o mercado perante Anatel,
Ministério das Comunicações e outros órgãos reguladores setoriais, por meio dos seus
associados [ABINC 2016].
Em 2016, o Fórum realizou o 1o Congresso Brasileiro e Latino-Americano em
Internet das Coisas com o tema: “Smart Word: a IoT como base de um mundo me-
lhor”. Em setembro de 2017, será realizado a segunda edição na cidade de São Paulo
[IoT Latin America 2017].
A Câmara IoT realizou uma consulta pública, com intuito de identificar tópicos
chave para a viabilização de IoT no Brasil. A consulta teve início em dezembro de 2016
e ficou disponível até 16 de janeiro de 2017 [Participa.br 2016].
Durante a 6a edição do Growth, Innovation and Leadership Summit em São Paulo,
a Frost & Sullivan apresentou o estudo intitulado “O Mercado industrial brasileiro de In-
ternet das Coisas, Cenário para 2021”. Segundo a pesquisa, no ano de 2016, o mercado
de IoT no Brasil, movimentou US$ 1,35 bilhão, liderado pelos setores da indústria auto-
motiva e verticais de manufatura. O crescimento para os próximos cinco anos será signi-
ficativo, sendo esperada uma receita de US$ 3,29 bilhões. A pesquisa define IoT como
objetos de uso cotidiano que são conectados à internet e também interligados uns aos ou-
tros. Com exceção dos objetos e IoT que exigem interface humana para o funcionamento
[Batimarchi 2017].
2.3. Cidades Inteligentes
Até 2050, estima-se que aproximadamente 70% a 75% da população mundial estará vi-
vendo em centros urbanos. Com o aumento populacional, crescem os desafios para go-
vernos, empresas e academia, gerando preocupação constante sobre o futuro dos grandes
centros urbanos. Neste contexto, surge o conceito de cidade inteligente ou smart city
[Marques 2015].
De acordo com a definição da União Europeia pode-se entender as cidades inte-
ligentes como sistemas de pessoas, interagindo e utilizando energia, materiais, serviços
139
e financiamento para incentivo do desenvolvimento sustentável, garantindo resiliência e

qualidade vida. Esses movimentos e interações são inteligentes quando utilizam estra-
tegicamente infraestrutura e serviços de informação e comunicação em um processo de
clareza do planejamento e gestão urbana, com capacidade de suprir as deficiências sociais
e econômicas da sociedade [Finguerut e Fernandes 2015].
A definição ainda não é um consenso pelos diferentes domínios que ela envolve,
pode-se observar que um ponto em comum entre as definições é a presença da Tecnolo-
gia da Informação e Comunicação (TIC). De acordo com [Komninos 2008], as cidades
inteligentes nascem da união de sistemas locais de inovação, que funcionam nas próprias
cidades (bairros tecnológicos, parques tecnológicos, polos de inovação), beneficiados por
redes digitais e de aplicações da sociedade da informação.
Na visão de [Lemos 2013], smart city é sinônimo de uma cidade, na qual tudo é
sensível ao ambiente e fornece, consome e compartilha um grande número de informações
em tempo real. Esse processamento inteligente servirá como base e auxiliará nas deci-
sões tomadas por governos, empresas e cidadãos. Dessa forma, a cidade funciona como
estrutura informacional, o qual reage e atualiza sobre suas condições constantemente.
As smart cities podem ser conceituadas como espaços inteligentes, onde as TIC
são “invisíveis”, incorporadas em objetos físicos e lugares que as pessoas vivem e/ou
trabalham. A promessa atual é que essa tecnologia embarcada permita suporte inteligente
e contextualmente pertinente, elevando a qualidade de vida e experiência do mundo físico
de uma forma positiva e não intrusiva [Steventon e Wright 2010].
A partir dessas definições, surge outro conceito interessante: cidadão inteligente
ou smart citizen. Conforme [Lemos 2013], as pessoas também começam a produzir infor-
mações. Com conhecimento disponível e acessível de forma mais simples e mais próxima
do dia a dia, o cidadão além de ter uma melhor percepção do espaço onde vive, pode pro-
por soluções criativas e inovadoras para otimização das cidades.
As soluções propostas sob a designação das cidades inteligentes não possuem pa-
drões e resoluções iguais e replicáveis em qualquer contexto, mas observam as necessi-
dades peculiares de cada cidade e buscam soluções com ganhos sociais, econômicos e
melhorias no bem-estar dos cidadãos [Finguerut e Fernandes 2015].
3. Cenário de smart cities no Brasil

Para atender aos objetivos propostos por este artigo, optou-se por realizar uma pesquisa de
caráter exploratório. Os passos seguidos foram: verificação de material bibliográfico, lei-
tura e compreensão do material escolhido e estudo individual das cidades. Para o estudo
foram consideradas cidades brasileiras com características geográficas e culturais distin-
tas, que são reconhecidas como futuras cidades inteligentes, tanto no cenário nacional
quanto internacional.
No contexto brasileiro, os desafios encontrados para construção de cidades in-
teligentes são intensos, dadas as condições de infraestrutura tecnológica da maioria das
cidades. Ainda assim, muitas capitais e cidades menores se destacam em várias categorias
relevantes e caminham para ser denominadas smart cities.
A Connected Smart Cities apresenta o Ranking Connected Smart Cities, que iden-
tifica e avalia as cidades brasileiras que apresentam iniciativas importantes para o desen-
140
volvimento das cidades em 11 setores de mais de 700 municípios, a partir de 70 indi-

cadores. Os setores considerados são: Mobilidade, Urbanismo, Tecnologia e Inovação,
Empreendedorismo, Governança, Educação, Energia, Meio Ambiente, Saúde, Segurança
e Economia. O evento conceitua smart city, uma cidade que prospera na direção de grande
incorporação das inteligências humana, coletiva e artificial (espaço físico, infra-estrutura
local e ferramentas públicas) [Computer World 2017].
A terceira edição aconteceu em junho de 2017 e considerou a capital paulista como
primeiro lugar no ranking, seguida por Rio de Janeiro e Curitiba. Na região Nordeste a
campeã foi Recife [Computer World 2017].
3.1. São Paulo (SP)

A cidade mais populosa do país nos últimos anos elaborou uma série de iniciativas para
mudar a relação das pessoas com São Paulo, otimizar a mobilidade, requalificar e de-
mocratizar os espaços, entre outros projetos. Um dos focos principais é a otimização da
mobilidade urbana, especialmente o transporte coletivo e sustentável.
Conforme o [Connected Smart Cities 2016], São Paulo é considerada uma das ci-
dades com a melhor infraestrutura de telecomunicações e conexões de internet do país,
oferecendo uma ampla cobertura de redes 3G/4G, fibra ótica e banda larga de alta velo-
cidade. Também concentra o maior número de patentes registradas, assim como o maior
aporte investidos em pesquisas financiadas pelo Conselho Nacional de Desenvolvimento
Cientifico e Tecnológico (CNPq).
A capital paulista também se destaca em Urbanismo através do Plano Diretor e
Plano de Uso de Solo, que contou com a participação popular e diversas entidades. É a
primeira da América Latina a possuir centrais mecanizadas de triagem de resíduos sólidos,
priorizando a destinação correta dos resíduos para evitar a criação de novos aterros e a
multiplicação de lixões.
Além das iniciativas desenvolvidas pelo setor público, as universidades possuem
grande relevância na construção da smart city, uma vez que dispõem de pesquisadores es-
pecializados em diversas áreas do conhecimento, que podem ser mobilizados para extrair
informações de bases de dados e produzir sistemas de informação confiáveis e atualizados
sistematicamente sobre temas de interesse público [Alisson 2016].
Um bom exemplo é o projeto desenvolvido por um grupo de pesquisadores do
Departamento de Ciência da Computação do IME-USP, em colaboração com colegas da
New York University e do IBM T. J. Watson Research Center, nos Estados Unidos, de um
software para obter imagens de ambientes urbanos, capturadas por câmeras de rua e dis-
ponibilizadas na internet. Por meio de técnicas de visão computacional e aprendizado de
máquina, os pesquisadores pretendem usar essas informações para identificar, por exem-
plo, incidentes ou comportamentos anormais e emitir alertas em tempo real para órgãos
públicos, como a Defesa Civil [Alisson 2016].
4. Cidades Inteligentes na Região Nordeste

4.1. Recife (PE)
Recife é um dos principais pontos tecnológicos do país, principalmente por iniciativas de
Universidades, pelo forte cenário de Startups e Porto Digital. A cidade é vista como um
141
dos principais núcleos econômicos, acadêmicos e políticos da região Nordeste. Em 2017,

conforme o Ranking Connected Smart Cities, foi eleita pela terceira vez consecutiva a
cidade nordestina mais inteligente e conectada.
A prefeitura tem desenvolvido nos últimos anos, politicas publicas inovado-
ras com objetivo de tornar Recife como um importante centro de produção das
TIC, de oferta de bens e serviços modernos, como afirmou o prefeito Geraldo Julio
[Connected Smart Cities 2016].
Além do Porto Digital, a cidade possui também o Porto Social, projeto que reúne
o setor público e privado com finalidade de oferecer iniciativas de ação comunitária, in-
cubando atualmente 50 projetos, como: Instituto Sarepta, Educomídias e Cidade Que
Queremos [Porto Social 2016].
O Play Town Recife é um projeto em desenvolvimento que planeja utilizar a tec-
nologia para impulsionar o turismo e disponibilizar material inteligente capaz de interagir
com os visitantes [PlayTown Recife 2016].
A cidade também tem projetos para viabilizar o plano de desenvolvimento da
mobilidade urbana, como a criação da “Pesquisa de Origem e Destino”, um levantamento
sobre as deficiências de deslocamento da população. Além disso, expandir o “Conecta
Recife” que tem foco principal disponibilizar wi-fi gratuito para os habitantes, atualmente
200 mil pessoas são atendidas pelo serviço [Connected Smart Cities 2016].
4.2. Croatá, São Gonçalo do Amarante (CE)

Croatá é um distrito localizado na cidade de São Gonçalo do Amarante, situado a 69 km
de Fortaleza. O distrito não aparece no ranking das 100 cidades inteligentes, mencionada
na seção anterior, porém foi eleita para ser a primeira smart city social do mundo.
Planet, uma startup italiana de soluções inteligentes em moradia, planeja construir
a Smart City Laguna na cidade cearense com estrutura para comportar cerca de 25 mil
habitantes. Apostando em um novo tipo de arranjo social, com uma cultura colaborativa
amadurecida. A ideia é criar um modelo referencial que possa ser replicado para novas
cidades, com um custo reduzido e que atenda às necessidades dos habitantes.
O planejamento envolve a criação de corredores verdes, ciclovias, áreas para pe-
destre, serviços de mobilidade alternativos, tratamento de águas residuais e aproveita-
mento de águas pluviais, produção de energia solar e eólica, redes wi-fi públicas, entre
outros [Instituto Smart City Business America 2016].
A primeira etapa, com prazo de entrega para dezembro de 2017, deverá possuir
350 casas em 90 hectares. E uma segunda etapa, com 1,5 mil casas em 240 hectares.
A expectativa é que entre 2020 e 2021 o projeto seja concluído. O investimento total é
estimado em US$ 50 milhões.
Segundo [Galdino 2017], as habitações sociais comuns possuem projeto arqui-
tetônico padronizado e repetitivo, inflexível às necessidades dos habitantes, paisagens
homogêneas sem integração com a malha urbana, infraestrutura básica e modelos, geral-
mente, não sustentáveis. As habitações propostas pela Planet, possuem financiamento por
meio do programa “Minha Casa, minha vida” do Governo Federal. São casas funcionais
com modelos variados e projeto arquitetônico moderno em harmonia com meio externo,
142
infraestrutura inteligente e sustentáveis.

Para monitorar as informações, gastos, utilizar serviços, como carros e bicicletas
compartilhadas, interagir com os demais habitantes, entre outros, os moradores poderão
utilizar o aplicativo disponibilizado pela startup, Planet App.
5. Conclusão
A constante expansão das Tecnologias da Informação e Comunicação elevam o mundo
a um estado melhor. Os impactos da sua presença são notáveis no cotidiano, não seria
diferente para as cidades. A tecnologia é um caminho sem volta para os municípios,
cidades e estados.
De fato, no Brasil ainda não existem cidades completamente smart city. Porém,
diversos projetos em desenvolvimento e execução, parcerias da iniciativa privada, pública
e acadêmica, vão mudando o cenário atual das nossas cidades.
O presente artigo teve como objetivo fomentar a discussão no campo científico
de cidades inteligentes no contexto brasileiro, apresentando características, definições e
projetos implementados. O estudo possui restrições por ser um artigo teórico, mas sugere-
se a realização em trabalhos futuros de pesquisas empíricas neste campo, realizadas em
âmbito nacional.
Agradecimentos
A todas as pessoas, que direta ou indiretamente, contribuíram com atenção e carinho
durante o desenvolvimento desse trabalho.
Referências
(2010). CGI.br: uma história de sucesso. Comitê Gestor de Internet no Brasil (CGI.br),
3(2):12–14.
(2016). Acesso à internet no Brasil: Desafios para conectar toda a população. Comitê
Gestor de Internet no Brasil (CGI.br), 10(7):27.
ABINC (2016). Disponível em: http://abinc.org.br/www/abinc/. Acesso
em: 19 de julho de 2017.
Alisson, E. (2016). Universidades podem contribuir para tornar são paulo uma cidade
inteligente. Disponível em: https://goo.gl/PWsxr6. Acesso em: 29 de julho
de 2017.
Almeida, H. (2015). Tudo conectado. Computação Brasil, 29(4):7.
Ashton, K. (2009). In the real world, things matter more than ideas. RFID Journal.
Bartleson, K. (2014). The internet of things is a standards thing. Electronic Design.
Batimarchi, S. (2017). O futuro industrial da internet das coisas no mercado brasileiro.
Disponível em: https://goo.gl/uahPxW. Acesso em: 24 de julho de 2017.
Computer World (2017). São Paulo lidera ranking de 2017 das cidades mais inteligentes
do brasil. Disponível em: https://goo.gl/sUUy5m. Acesso em: 25 de julho de
2017.
143
Connected Smart Cities (2016). São paulo: primeiro lugar no ranking. Catálogo Connec-
ted Smart Cities 2016.
Duquennoy, S., Grimaud, G., e Vandewalle, J.-J. (2009). The web of things: interconnec-
ting devices with high usability and performance. In Embedded Software and Systems,
2009. ICESS’09. International Conference on, pages 323–330. IEEE.
Finguerut, S. e Fernandes, J. (2015). Planejanto as cidades no século xxi. Cadernos FGV
Projetos, 24:56.
Fórum Brasileiro de IoT (2017). Disponível em: http://iotbrasil.org.br/
home/o-forum/. Acesso em: 19 de julho de 2017.
Galdino, A. (2017). Habitações sociais: redefinindo o conceito. Disponível em: https:
//goo.gl/4GVQQv. Acesso em: 21 de julho de 2017.
Gartner, I. (2015). Gartner’s 2015 hype cycle for emerging technologies identifies the
computing innovations that organizations should monitor. Gartner Web site.. Published
http://www. gartner. com/newsroom/id/3114217. Updated.
Giles, D. (2010). Psychology of the media. Palgrave Macmillan.
Instituto Smart City Business America (2016). Empresa italiana cria smart city para
famílias de baixa renda no brasil. Disponível em: https://goo.gl/WxWmtA.
Acesso em: 25 de julho de 2017.
IoT Latin America (2017). Disponível em: http://iotlatinamerica.com.br/.
Komninos, N. (2008). Cidades inteligentes-sistemas de inovação e tecnologias da in-
formação ao serviço do desenvolvimento das cidades. Unidade de pesquisas Urenio.
Universidade Aristoteliciana de Salônica. Acesso em 24 de julho de 2017, 15.
Lemos, A. (2013). Cidades inteligentes. GV-executivo, 12(2):46–49.
Mancini, M. (2015). Internet das coisas: História, conceitos, aplicações e desafios. Pro-
ject Design Management, 73.
Marques, J. (2015). As cidades inteligentes, nosso futuro? Estudo de caso de cinco
projetos de cidades inteligentes. Congresso Internacional Interdisciplinar em Sociais
e Humanidade, page 103.
Participa.br (2016). Disponível em: http://www.participa.br/cpiot/.
Pingdom, R. (2015). The incredible growth of the internet since 2000. Royal Pingdom.
PlayTown Recife (2016). Disponível em: http://www.playtownrec.com.br/
playtown/. Acesso em: 23 de julho de 2017.
Porto Social (2016). Sobre nós - o que é o porto social. Disponível em: http://www.
portosocial.com.br/sobre-nos/. Acesso em: 25 de julho de 2017.
Singer, T. (2012). Tudo conectado: conceitos e representações da internet das coisas.
Simpósio em tecnologias digitais e sociabilidade, 2:1–15.
Steventon, A. e Wright, S. (2010). Intelligent spaces: The application of pervasive ICT.
Springer Science & Business Media.
144
Análise da Segurança de Rede em um Ambiente Acadêmico:

Uma Abordagem Utilizando Pentest
Abstract. Along with the advent of information technology and the increase in
networked devices, the number of attacks that cause disruption to business
processes has increased. The main objective of this work is to identify low or
high potential vulnerabilities in the network of an academic environment
through Pentest (Penetration Test) techniques. For this, a set of specific
machines of a teaching institution is explored, using a computer with the Kali
Linux system in conjunction with tools like Nessus and Metasploit Framework.
The aim is to discover flaws where possible attackers can exploit. The results
found point to vulnerable services, security holes in several computers on the
network and still shows a percentage of the number of vulnerabilities found in
the network. Finally, solutions are proposed that allow the mitigation of
vulnerabilities, in order to improve security in this environment.
Resumo. Juntamente com o advento da tecnologia da informação e com o
aumento dos dispositivos conectados nas redes, o número de ataques que
causam interrupção nos processos de negócios tem consequentemente
aumentado. O objetivo principal deste trabalho é identificar vulnerabilidades
de baixo ou alto potencial existentes na rede de um ambiente acadêmico por
meio de técnicas de PenTest (Penetration Test). Para isso, é explorado um
conjunto de máquinas específicas de uma instituição de ensino, utilizando-se de
um computador com o sistema Kali Linux em conjunto com ferramentas como
Nessus e Metasploit Framework. O intuito é descobrir falhas onde possíveis
invasores possam explorar. Os resultados encontrados, apontam para serviços
vulneráveis, falhas de segurança em diversos computadores da rede e ainda
mostra uma porcentagem do quantitativo de vulnerabilidades encontradas na
rede. Por fim são propostas soluções que possibilitem a mitigação das
vulnerabilidades, de forma a melhorar a segurança neste ambiente.
1. Introdução
Na mesma proporção que novas tecnologias são criadas, novas vulnerabilidades
aparecem e com isso a informação fica ainda mais fácil de ser roubada. Moraes (2010),
afirma que são muitos benefícios que as empresas têm quando fazem uso dos recursos
tecnológicos, por outro lado ficam suscetíveis a riscos que podem acarretar em danos
como por exemplo, o tempo que a rede fica indisponível ou por ameaças aos dados
importantes através do acesso à Internet.
Nesse contexto, com o rápido desenvolvimento das diversas tecnologias em todas
as áreas do conhecimento, a sociedade e as organizações de um mode em geral ficam
mais expostas se tornando alvos fáceis para pessoas mal intencionadas.
Devido a grande importância da segurança da informação, é imprescindível
certificar-se de que as informações que trafegam nas redes de computadores estão sendo
acessadas somente por pessoas autorizadas. Existem muitos métodos para analisar essa
145
situação e neste trabalho será utilizado o Pentest, acrônimo de teste de intrusão, que
segundo Menezes, Cardoso e Rocha (2015, p. 4) nada mais é do que “uma penetração que
faz no sistema, onde se descobre as falhas do sistema.”
Diante deste contexto, o presente trabalho propõe um estudo da segurança da rede
utilizando a técnica Pentest em um ambiente acadêmico. Para isso, explora-se um
conjunto de máquinas específicas da instituição onde a pesquisa foi conduzida. O
objetivo consiste em descobrir falhas que possíveis invasores poderiam encontrar e
consequentemente danificar ou roubar informações relevantes, como dados de alunos ou
funcionários.
2.1. Segurança da Informação

Segurança da informação “é a proteção da informação de vários tipos de ameaças para
garantir a continuidade do negócio, minimizar o risco ao negócio, maximizar o retorno
sobre os investimentos e as oportunidades de negócio” (ABNT NBR ISO/IEC
17799:2005, p. IX). Com isso pode-se perceber o quanto é importante sempre
implementar novas ferramentas e métodos para assegurar a proteção dos dados.
2.2. Estágios do Pentest

De acordo com Scarfone et al., (2008), os testes que são realizados por métodos e seguem
as normas técnicas, apresentam inúmeras vantagens, visto que aplicarão uma
metodologia anteriormente elaborada. Desta forma o profissional terá uma orientação
apoiada nas melhores práticas bem como os elementos utilizados já serão conhecidos,
tornando o prognóstico mais fácil e evita erros. Este processo de penetração pode ser
dividido em fases. Existem diversas formas aceitáveis de agrupar as ações envolvidas
durante esse processo. A Figura 2 representa as quatro fases do teste de penetração.
Figura 2. Metodologia do Pentest. Fonte: Scarfone et al. (2008)
2.3. Pentest
Existem definições similares nas bibliografias, como exemplo, temos à de Bozhinovski et
al. (2013, p. 1), Pentest “é um tipo de teste de segurança que serve para avaliar uma rede
e os sistemas de uma organização simulando ataques de hackers maliciosos”. É realizado
para encontrar os riscos de segurança que podem estar presentes na organização que será
avaliada.
No entendimento de Bertoglio e Zorzo (2017, p. 1), compreende Pentest como
sendo uma “tentativa controlada de penetrar em um sistema ou rede, a fim de identificar
146
vulnerabilidades”. As técnicas aplicadas durante os testes, são as mesmas utilizadas

durante um ataque real. Esta alternativa segundo Whitaker e Newman (2005) permite que
as empresas tomem medidas adequadas para eliminar as vulnerabilidades, antes que
possam ser exploradas por pessoas não autorizadas.
Figura 1. Tipos de Pentest. Fonte: Adaptado de Bozhinovski et al. (2013)
2.4. Trabalhos Relacionados

Pavan e Guardia (2015), mostraram a importância da segurança da informação
envolvendo testes de penetração por meio de ferramentas específicas em um ambiente de
rede acadêmica. Investigaram as vulnerabilidades de segurança que podem prover acesso
não autorizado aos equipamentos e sistemas de uma universidade.
Bishop, M. (2007), sonda em detalhes o funcionamento de testes de penetração,
analisando o entendimento mais adequado em resultados de um Pentest e reiterando a
necessidade de análises detalhadas acerca das atividades que o compõem. Da mesma
forma, Menezes, Rocha e Cardoso (2015) apresentam as principais abordagens e opiniões
sobre Pentest em um artigo que representa grande parte das citações atuais de pesquisas
da área em virtude da sua consolidação.
Em pesquisa conduzida por Hamisi et al,. (2009), foram realizados experimentos
em diferentes períodos de tempo. O artigo aborda um estudo de caso realizado na rede
interna de uma universidade de Salaam na Tanzânia. Implementou-se etapas do teste de
penetração, e por meio de pontuação de sites específicos de segurança, os autores
verificaram que a classificação de segurança da rede foi de 50%.
3. Metodologia
Nesta seção, serão expostas as ferramentas utilizadas durante a avaliação de
segurança de alguns hosts da rede da instituição. Uma destas, é o Nmap, programa que
mostra informações sobre portas, serviços e hosts. Com essas informações é possível
criar um mapa de rede.
O programa utilizado para mostrar as vulnerabilidades detalhadas de cada host ou
da rede foi o Nessus, que com sua linguagem de script, consegue obter a versão do
sistema operacional e nome da máquina, rota de rastreamento, hosts de teste para
determinada vulnerabilidade. Sendo capaz de analisar os hosts ativos e encontrar
potenciais falhas, dentre outras funcionalidades.
Outra ferramenta de muita importância nos testes foi o Metasploit Framework
(MSF), que desenvolve, executa e explora códigos em máquinas remotas, fornecendo
opções para verificar as vulnerabilidades dos sistemas de computadores com o intuito de
protegê-los.
147
Após, a instalação dos programas no computador (laptop), acima mencionadas,

foram realizados vários scanners na rede com a ferramenta Nmap. Através das
informações obtidas foi possível ter uma visão geral de como os sistemas em análise
operam. Para a fase do ataque, utilizou-se o Metasploit Framework, pois este possui
uma grande variedade de exploits1 e payloads2 prontos para o uso, facilitando muito a
exploração das falhas.
Em um primeiro momento, obteve-se a identificação das máquinas na rede e a
situação de cada uma delas por meio de um gráfico de vulnerabilidades. Em seguida,
escolheu-se uma máquina que possivelmente apresentariam falhas a serem exploradas,
para que sejam realizadas simulações de ataques e por fim apontar possíveis soluções
para correções dos problemas comprovados.
Os ataques foram de dois tipos: o primeiro foi um teste de acesso remoto, obtendo
acesso ao disco rígido do host que foi atacado; o segundo foi o DoS (ataque por negação
de serviço) na rede sem fio deixando todos os dispositivos sem acesso. Por fim, gerou-se
relatórios e gráficos mostrando a situação da rede e dos sistemas.
4. Estudo de Caso
O estudo foi conduzido no laboratório de redes de computadores do Instituto Federal de
Educação, Ciência e Tecnologia do Ceará (IFCE), no campus Jaguaribe. A Figura 3,
mostra o cenário utilizado durante os testes. O cenário está dividido em dois ambiente,
onde o primeiro é a rede administrativa e o segundo a partir do switch é a rede do
laboratório. O laptop está com o Kali Linux instalado, e com ele foram realizados os
procedimentos práticos. A fase da Descoberta foi realizada em todos os dispositivos
ativos da rede e a do Ataque foram realizadas nos dispositivos do laboratório. Os tipos de
ataques são do tipo interno e de caixa branca.
A ferramenta de análise de vulnerabilidade Nessus identifica o nível de
vulnerabilidade em cada nó da rede e classifica-o de acordo com o sistema comum de
pontuação de vulnerabilidade (CVSS) nos níveis crítico, alto, médio e baixo.
1 ) “São programas ou scripts especializados para explorar vulnerabilidades específicas”

(SCARFONE et al., 2008).
2 ) “São basicamente códigos ou scripts maliciosos concebidos como parte de um exploit ou
desenvolvidos de uma forma independente, os quais permitirão, dentre outras ações, o controle integral ou
parcial do sistema explorado” (LEPESQUEUR; OLIVEIRA, 2016).
148
Figura 3. Cenário de Testes

Levando em conta que a fase de planejamento foi realizada com o levantamento
de dados como informações de ips, domínio, entre outras, inicia-se o teste na fase da
descoberta, como visto na fundamentação teórica (Seção 2). A Figura 4 mostra o
resultado do primeiro scanner feito utilizando a ferramenta Nessus. Mostrando algumas
vulnerabilidades e especificando os níveis de criticidade em diversos host da rede que
estavam ativos no momento que o scanner foi realizado.
Figura 4. Nessus - Resultado: Vulnerabilidades em diversos hosts da rede.

Ainda através do Nessus, ao observar todos os 47 hosts que foram identificados no
primeiro scanner, o que aponta ser um alvo em potencial a ser explorado é o host de ip
10.1.1.84, pois acessando o status dele e em seguida por meio da aba Vulnerabilities,
foram detectadas 38 vulnerabilidades, enquanto no geral de todos os 47 hosts foram
identificadas 98, pode-se verificar isso na Figura 5 (imagem resumida). O fato de um host
possuir muitas vulnerabilidades não implica que este será o melhor alvo, mas vai
depender da criticidade das falhas.
De todas as fragilidades encontradas duas são críticas, a primeira faz com que o
host Windows seja afetado por uma vulnerabilidade de execução remota de código,
devido ao processamento inadequado de pacotes, especificamente o Secure Channel
(Schannel). Um invasor pode explorar essa vulnerabilidade, enviando pacotes
especialmente criados para um servidor Windows. Para o CVSS v3.0 a vulnerabilidade
149
citada tem uma pontuação Base Score: 10,0.

Outra falha crítica identificada foi a existência de uma vulnerabilidade de
divulgação de informações no SMBv1 (Microsoft Server Message Block 1.0). Um
invasor remoto não autenticado pode explorar isso, através de um pacote especialmente
criado, para divulgar informações confidenciais. Para o CVSS v3.0 essa vulnerabilidade
tem uma pontuação Base Score: 9.8.
Figura 5. Nessus - Resultado: Vulnerabilidades em um Host específico

Na fase do ataque foi utilizado o MSF para conseguir acesso a máquina atacada.
Por questões éticas, foi realizado um exemplo do ataque utilizando uma máquina do
laboratório de redes, ao invés de um usuário ativo da rede.
Com a utilização deste software realizou-se um scanner na rede para conseguir
mais informações como: tipo de sistema operacional, nome do host e nível de
vulnerabilidade no rank CVSS (Sistema de pontuação de vulnerabilidades comuns).
Como pode-se ver na Figura 6 o host 10.1.1.84, tem um nível 10, que é o maior grau de
criticidade neste rank.
Figura 6. Metasploit - Resultado: Scanner.

Através de uma análise feita no host em questão, foram obtidos os nomes dos
serviços críticos que estavam sendo executados, bem como: porta de acesso, o protocolo,
o estado das portas (se estavam abertas ou fechadas) e algumas informações desses
serviços. A porta TCP 445 mostrada na Figura 7, é do SMB (Server Message Block), a
qual serve para compartilhamento de arquivos. A partir do Windows 2000, a Microsoft
trocou as conhecidas portas TCP 139 e UDP 137-138 fazendo o SMB trafegar direto
sobre o protocolo TCP/IP, através da porta 445. Pode-se explorar essa falha como
Metasploit, por meio da opção exploit, porém essa funcionalidade só está disponível
através de uma licença proprietária.
150
5. Análises e Resultados
Após serem exploradas as vulnerabilidades detectadas no ambiente educacional alvo
observou-se a existências de um ponto crítico como causa principal, que foi o protocolo
de compartilhamento de arquivos (smb), o mesmo encontrou-se frágil ocasionando uma
grande falha de segurança em quase todos os hosts. Também foi verificado que o
Protocolo de Exibição Remota da Microsoft (MSRDP), possuía brechas a serem
exploradas. Após a investigação dessas falhas foi possível criar a Quadro 3, onde são
identificados protocolos, serviços e portas mais críticas encontradas na rede.
Quadro 3. Protocolos e serviços Críticos encontrados na rede.
Protocolo Serviço Porta
SMB Compartilhamento de arquivo em rede 445
MSRDP Acesso remoto 3389
Depois de analisados os resultados obtidos com a utilização dos programas

descritos na seção anterior, foi possível elaborar um Gráfico que relaciona a porcentagem
de Criticidade por Vulnerabilidades. De todas as 98 vulnerabilidades, 53 estão em um
nível baixo, totalizando 53,06%. No nível médio foram reportadas 36 Vulnerabilidades,
totalizando 36,73%. Já nos níveis alto e crítico alcançaram 3 e 7 Vulnerabilidades,
totalizando 3,06% e 7,14% respectivamente.
Estabelecer práticas que forneçam as máquinas dos usuários correções
automatizadas de atualizações de falhas de segurança é uma das muitas atribuições de um
administrador de rede. Tratando-se de uma rede onde a maioria das máquinas utilizam o
sistema operacional Windows, intervenções quanto ao uso de licenças originais,
habilitação do Firewall, além da frequente análise de logs que permitam identificar e
corrigir falhas rapidamente, são algumas das atitudes imprescindíveis para o
estabelecimento de uma consistente defesa da rede interna.
Gráfico 2 - Total de Vulnerabilidades em Percentual.
Por meio do Active Directory presente nos sistemas Windows Server é possível a
estruturação de políticas de grupo de forma que sejam liberados, rigorosamente, somente
151
as ferramentas necessárias aos desempenhos dos trabalhos de cada área da empresa ou de

cada usuário. Algumas intervenções poderão ser realizadas como manter fechadas
algumas portas de serviços que não estão em uso, como pode ser visto na figura 6 da
seção anterior.
Na segurança para dispositivos sem fio uma possível solução seria a instalação de
um servidor RADIUS (Remote Authentication Dial In User Service) e a integração da
rede sem fio com o mesmo. Outra possível medida para melhorar a segurança da rede é a
instalação de um IDS (Intrusion detection system).
6. Conclusão
Este trabalho apresentou uma das principais metodologias utilizadas na atualidade para
conseguir identificar Vulnerabilidades nas redes de ambientes corporativos que é a
utilização do Pentest. Foram realizadas avaliações do desempenho da rede através de
simulações de ataques e por meio de scanners realizados no ambiente de teste. Os
resultados apontam que com a utilização de algumas ferramentas pode-se conseguir a
descoberta de muitas falhas para uma análise efetiva da situação da rede, que antes
poderiam ser explorada por hackers/crackers, e assim tomar medidas preventivas para
correção das mesmas.
Algumas limitações foram encontradas durante as etapas da pesquisa, tendo como
e exemplo, explorar recursos específicos de algumas ferramentas, que não foi possível
porque as licenças são proprietárias, por outro lado com a utilização delas consegue-se
um alto desempenho na análise das vulnerabilidades. Para trabalhos futuros pode-se
aplicar essas sugestões de melhoria no ambiente real da instituição e logo em seguida
monitorar o desempenho da rede por meio dos scanners e comparar os resultados.
Referências
Bertoglio, D. D., & Zorzo, A. F. (2017). Overview and open issues on penetration test.
Journal of the Brazilian Computer Society, 23(1), 2.
Bishop, M. (2007). About penetration testing. IEEE Security & Privacy, 5(6).
Hamisi, N. Y., Mvungi, N. H., Mfinanga, D. A., & Mwinyiwiwa, B. M. M. (2009,
January). Intrussion detection by penetration test in an organization network. In
Adaptive Science & Technology, 2009. ICAST 2009. 2nd International Conference on
(pp. 226-231). IEEE.
Moraes, A. F. D. (2010). Segurança em Redes: Fundamentos. Primeira Edição, São
Paulo, Editora Érica.
Pavan, P. V. A., & Guardia, H. C. (2016). Pentest para auditoria de segurança de rede
em ambientes corporativos. Revista TIS, 4(2).
Potter, B; Mcgraw, G. Software security testing. Revista IEEE SECURITY & PRIVACY,
2/5, 2004. p.81-85.
Scarfone, K., Souppaya, M., Cody, A., & Orebaugh, A. (2008). Technical guide to
information security testing and assessment. NIST Special Publication, 800, 115.
152
Uma Análise da Segurança da Informação no Contexto da

Vulnerabilidade Técnica do Painel Administrativo de um
Website
Roney Damasceno Freitas1 , Rhyan Ximenes de Brito2 ,
Janaide Nogueira de Sousa Ximenes3
Ronieri Nogueira de Sousa 4
1
2
3
4
{roneyfreitas, rxbrito, nogueirajanaide, nsronieri}@gmail.com
Abstract. On the Internet, large amounts of data travel, many of which are in
secure environments, and managed only by authorized people who have creden-
tials that allow them to be manipulated correctly. The present work addresses
a study on security and information management with a focus on web applica-
tions. The overall objective of this study is to perform intrusion testing using
a virtual machine together with the Kali Linux operating system through some
tools to show vulnerabilities that exist in the administrative panel of a site.
Resumo. Na Internet trafegam grandes quantidades de dados, muitos deles

estão em ambientes seguros e gerenciáveis apenas por pessoas autorizadas que
possuem credenciais que permitem a manipulação de forma correta. O pre-
sente trabalho aborda um estudo sobre a segurança e gestão da informação
com foco em aplicações web. O objetivo geral desse estudo é realizar testes
de invasão utilizando uma máquina virtual juntamente com o sistema operaci-
onal Kali Linux através de algumas ferramentas com a finalidade de mostrar
vulnerabilidades que existem no painel administrativo de um site.
1. Introdução
Este trabalho está direcionado a gestão da segurança da informação voltado ao painel
administrativo de um site, onde apenas pessoas autorizadas devem ter acesso ao geren-
ciamento das informações administrativas do site e terá o controle dos dados que serão
expostos ao público em geral. A motivação para investigar tal temática, foi a participação
como membro da equipe de desenvolvimento do site, tendo a percepção e vivência do
quanto se faz necessário preocupar-se com a segurança e a integridade das informações
na web. Dentro dessa perspectiva a segurança da informação é algo importante, pelo fato
153
de que criminosos estão sempre em busca de vulnerabilidades, que podem resultar em

ataques ou mesmo ameaças. Assim as aplicações web sofrem constantemente com esses
ataques que tem como objetivo adquirir acesso as informações confidenciais, podendo
expor ou alterar tais informações.
Buscando-se, deste modo, uma clara abordagem na identificação dos elementos,
os quais serão indagados para a contribuição do levantamento cientı́fico teórico, trazendo
de forma clara e concreta a resolução para o problema exposto. Segundo [Dias 2000],
a segurança visa proteger informações, sistemas, recursos e serviços contra manipulação
não autorizada e desastres visando a redução do impacto e diminuir a probabilidade de
incidentes de segurança.
Em uma abordagem de [Carneiro 2002], define segurança sendo, um conjunto
de medidas e procedimentos, com o objetivo de proteger informações, contra destruição
indevida, ou mesmo alterações de forma não organizada. Pode-se então, destacar com
[Ferreira 2003], que a segurança da informação protege a informação dos diversos tipos
de ameaças. Dessa forma a segurança da informação é de fundamental importância contra
acessos indevidos de pessoas não autorizadas que possuem o objetivo de manipular as
informações.
2. Conceitos Básicos de Segurança da Informação

As organizações, as quais fazem parte do meio tecnológico, estão constantemente sujeitas
a exploração de vulnerabilidades, fazendo-se necessário o uso da gestão de segurança da
informação com a finalidade de buscar a proteção das informações. A exploração dessas
fraquezas é realizada por meios de ações de origem humana, que quando são exploradas
estão sujeitas a identificar fendas, onde a partir desses pontos crı́ticos pode-se produzir
ataques, e logo, comprometer as informações, causando a perda de um ou mais pilares
básicos da segurança da informação, como por exemplo a confidencialidade, disponibili-
dade, integridade e autenticidade.
A segurança da informação para [Sêmola 2014], é a proteção de diversos tipos
de ameaças as informações, preservando seus atributos. Pode-se destacar que, ter um
conhecimento mais aprofundado sobre os principais pilares da GSI(Gestão da Segurança
da Informação) é essencial para entender de forma detalhada o conceito de segurança da
informação.
De acordo com [RAMOS 2008], é definido o atributo de confidencialidade da
segurança da informação como o sigilo da informação, então preservar a confidenci-
alidade significa garantir que apenas as pessoas autorizadas poderão ter acesso. Di-
ferentes tipos de informação terão diferentes necessidades em termos de confidenciali-
dade. Já no que diz respeito a integridade, fato esse meramente importante para qualquer
organização referente ao tratamento das informações, no qual [RAMOS 2008] destaca
que a preservação da integridade envolve proteger as informações contra modificações
em seu estado original. Essas modificações podem ser tanto intencionais quanto aciden-
tais.
Quando se diz respeito a disponibilidade, quer dizer que a informação precisa es-
tar disponı́vel a todo o momento. [RAMOS 2008] aborda que uma informação disponı́vel
é aquela que pode ser acessada por aqueles que dela necessitam, no momento em que seja
154
necessário. Já para [Silva et al. 2003] , disponibilidade é vital ao acesso a informação,
de modo que ter a informação necessária, mas não ter disponı́vel no momento desejado,
equivale a não possuir qualquer informação. É destacado também o atributo de autenti-
cidade, onde o mesmo pode garantir a identidade de quem está enviando algum tipo de
informação.
Uma ameaça pode ser considerada fı́sica ou virtual, podendo comprometer toda a
segurança da informação, esse acontecimento pode ser causado por um fenômeno natural
ou por uma simples ação humana. Entre as ameaças possı́veis, pode-se citar criminosos
virtuais e vı́rus. Segundo [Dias 2000] uma ameaça é um evento ou atitude indesejável, ou
seja, roubo, incêndio ou vı́rus, que tem um potencial de remover, desabilitar, danificar ou
destruir um recurso.
Na rede mundial de computadores atualmente existem milhares de aplicações dis-
ponibilizando algum tipo de informação e todas as informações consequentemente estão
em um ambiente inseguro, onde qualquer tipo de vulnerabilidade na aplicação pode possi-
bilitar explorações por atacantes virtuais, com possibilidades de gerar grandes prejuı́zos.
Sistemas web (online) são os alvos preferidos dos usuários mal intencionados, pois es-
tando diretamente ligado a Internet viabiliza ao criminoso virtual se aproveitar do ambi-
ente de forma camuflada para estar explorando as vulnerabilidades em busca de falhas de
segurança.
Os ataques são resultados de ações realizadas por invasores que utilizam de fer-
ramentas como vı́rus, com a finalidade de roubar informações das vı́timas. Essas ações
são realizadas geralmente em ambientes virtuais, devido o rápido alcance as informações,
altos ganhos e o baixo risco que os criminosos podem estar expostos. Ele se trata de um
acesso não autorizado que pode fazer modificações nas informações. Um ataque corres-
ponde a concretização de uma ameaça, podendo ser bem sucedida ou não, mediante uma
ação deliberada e por vezes meticulosamente planejada [Marciano 2009]
Já o risco é a possibilidade de que aconteça alguma ação prejudicial, é a pos-
sibilidade de um perigo iminente, onde se materializa a chance de se executar alguma
ação perigosa. Para [Sêmola 2014] o risco é a probabilidade de que agentes, que são as
ameaças, explorem vulnerabilidades, mostrando os ativos a perdas de confidencialidade,
integridade e disponibilidade, e causando impactos.
O termo criptografia vem das palavras kryptos (oculto) e graphein (escrita), co-
nhecida por ser a ciência que estuda maneiras para codificar as mensagens deixando seu
conteúdo de forma secreta. O termo criptografia não é ocultar a existência da mensagem,
e sim deixar escondido o seu significado, esse processo é conhecido como encriptação
[SINGH 2008].
Através do método de codificação da informação, torna-se mais seguro o envio
de mensagens através da Internet, como e-mails ou transações bancárias e comerciais,
levando em consideração que os dados trafegam por um ambiente público e vulnerável. A
cada dia técnicas criptográficas são aperfeiçoadas, com o objetivo de buscar altos nı́veis
de segurança e impedir que informações mesmo que interceptadas por criminosos, não
poderão decifrar a informação contida na mensagem.
A criptografia é uma ferramenta extremamente importante para a sociedade, ela
tem o objetivo de manter as informações confidenciais, proporciona integridade, auten-
155
ticidade e maior segurança. Atualmente existem vários sistemas criptográficos que são
baseados em algoritmos, onde os mesmos são responsáveis em deixar os dados cripto-
grafados usando transformações complexas em sua execução, transformando um texto
simples em um texto cifrado ou criptografado. Pode-se destacar alguns algoritmos im-
portantes nesse processo criptográfico, como o DES (Data Encryption Standard), AES
(Advanced Encryption Standard), RSA (Devido aos seus desenvolvedores Rivest, Sha-
mir, e Adleman) e MD5 (Message-Digest algorithm 5).
3. Mecanismos de Segurança Implementados no Painel de Controle

Pensando na segurança das senhas dos usuários, foi realizado a implementação do al-
goritmo de função criptografia MD5 hash, utilizado para deixar as senhas armazenadas
no banco de dados de forma cifrada, onde nem mesmo o próprio administrador ou um
possı́vel acesso indevido ao banco de dados, poderão ter acesso ao texto claro da senha
e sim um texto cifrado, dificultando qualquer possibilidade de uso indevido com as cre-
denciais dos usuários do sistema. Um dos sistemas de criptografia e autenticação que
apresenta segurança computacional que é utilizado nas mais diversas aplicações é o algo-
ritmo de chave pública MD5 [Azevedo 2006].
3.1. Forma de Autenticação
O método de autenticação utilizado foi baseado no reconhecimento do login e senha como
mostra na Figura 1:
Figura 1. Tela de Login

Fonte: Elaborado pelos autores.
A Figura 2, mostra parte do código utilizado na implementação, responsável pela

verificação de validação de usuários do sistema, onde é realizado o processo de recebi-
mentos de nome de usuário e senha, para acesso ao painel. No código, a função empty
tem como finalidade verificar se o usuário está passando dados vazios, caso isso aconteça
a função evitará tal ação, a função addslashes tem a finalidade de retornar string com
barras invertidas quando são usados caracteres indevidos que podem ser utilizados em
ataques como SQL Injection, já a função md5 tem a finalidade de gerar a criptografia da
senha ingressada e será verificada se a mesma corresponde a senha já gravada no banco
de dados. Quando o usuário ingressa seu login e senha é submetida a uma verificação se
os dados correspondem aos dados armazenados no banco de dados, caso essa verificação
seja verdadeira o usuário terá acesso ao painel administrativo, caso contrário o acesso é
evitado.
O processo de identificação define para o computador que realmente é o usuário e
a senha corresponde a um autenticador, isto é, ela prova ao computador que o usuário é
quem realmente ele diz ser [Santos and Silva 2012].
156
Figura 2. Implementação das variáveis de login e senha

3.2. Controle de Usuário

Os usuários que têm acesso ao painel administrativo são controlados por nı́veis, onde
o nı́vel 1, corresponde aos usuários administradores do sistema, podendo realizar desde
criação de usuários até a publicação e aprovação de conteúdos, o nı́vel 2, corresponde
aos usuários administradores que poderão apenas gerenciar a publicação e aprovação dos
conteúdos a partir do painel.
Figura 3. Niveis de usuário

4. Simulações, Testes e Resultado de Ataques ao Painel do Site

Com o objetivo de verificar e futuramente corrigir falhas de segurança no painel admi-
nistrativo do site, foram realizados alguns testes de invasão a fim de ganhar acesso a área
administrativa do painel. Foram utilizadas algumas ferramentas para a exploração de vul-
nerabilidades e ataques onde o sistema operacional utilizado como cenário da realização
das análises foi o Kali Linux instalado no ambiente virtualizado com o VirtualBox.
O ambiente é criado com um aplicativo de virtualização onde permite a instalação
e execução de vários sistemas operacionais dentro de várias máquinas virtuais ao mesmo
tempo, proporcionando também o compartilhamento do mesmo hardware. O sistema
operacional Kali Linux é uma distribuição Linux baseada em Debian destinada a testes
de penetração avançados e auditoria de segurança. O sistema contém várias ferramentas
destinadas à realizar testes de segurança e adaptado especialmente as necessidades dos
profissionais. Na figura 4, mostra a execução do Kali Linux na VM (Máquina Virtual).
4.1. Nessus
Após a preparação do ambiente, foi utilizado o software Nessus, um dos mais popu-
lares para realização de testes de análises de vulnerabilidades, com o objetivo de de-
tectar os pontos considerados fracos em seus serviços de execução. [Pauli 2014] e
[Weidman 2014], apontam que o Nessus é um dos scanners de vulnerabilidades dis-
ponı́veis mais populares para realizar o passo de scanning de vulnerabilidades onde seu
banco de dados inclui vulnerabilidades em plataformas e protocolos, e o seu scanner re-
aliza uma série de verificações para detecção de problemas conhecidos. Na Figura 5 é
mostrado os resultados realizado pelo Nessus no módulo de testes para aplicações web.
157
Figura 4. Execução do Kali Linux na VM

Figura 5. Histórico de vulnerabilidades encontradas pelo Nessus no Site

Como pode ser observado na Figura 5, os resultados da varredura mostra que

existem duas vulnerabilidades média e o restante apenas informações, onde os nı́veis são
classificados como, crı́tico, alto, médio, baixo e informativo. Em relação as vulnerabilida-
des de nı́vel médio encontradas o Nessus relata que, caso o arquivo php.info seja acessado
por um invasor remoto ele pode descobrir uma grande quantidade de informações sobre
o servidor web remoto, como o nome do usuário que instalou o php e se é usuário SUDO
(possui todas as permissões do sistema), endereço do host, versão do sistema operacional,
versão do servidor web, diretório raiz do servidor web e configuração sobre instalação
remota do php. O Nessus mostra como solução para eliminar essas vulnerabilidades en-
contradas efetuar a remoção do arquivo afetado php.info.
4.2. Nmap
O Nmap tem como finalidade fazer varreduras no alvo a procura de portas abertas,
serviços ativos, versões de sistemas operacionais e vários outros tipos de scan. Segundo
[Pauli 2014], o Nmap é o scanner de porta popularmente mais utilizado e continua a
ganhar destaque como o melhor scanner de portas do mundo, com funcionalidades adici-
onais para exploração de falhas e scanning de vulnerabilidades. Na Figura 6, mostra os
resultados obtidos pela Nmap.
Como mostra a Figura 6, o comando executado ”nmap -sV -sS -O
186.202.153.147”realiza as seguintes ações: I- sV: designa o scan como um scan de
versão, que mostrará como resultado as versões especı́ficas dos serviços em execução.
II- sS: inicia um scan camuflado, ou seja, ele descobre se uma porta está aberta sem
se conectar totalmente com o alvo. III -O retorna informações referentes ao sistema
operacional. o IP (Protocolo de Internet) 186.202.153.147 é equivalente ao domı́nio
158
Figura 6. Resultados obtidos pela ferramenta Nmap

http://www.brasilsystems.net/*. O resultado mostra duas portas abertas com seus res-

pectivos serviços e versões, revelando também a existência de uma probabilidade de 89%
que o sistema operacional é o Linux 2.6.38.
4.3. Nikto
O Nikto é uma ferramenta que tem o objetivo de constatar diversos tipos de arquivos,
configurações de programas padrões e inseguros nos servidores web que podem ser passi-
vos a algum tipo de ataque. [Pauli 2014], relata que o Nikto realiza verificações relativas a
6.400 arquivos e scripts potencialmente perigosos, 1200 versões desatualizadas de servi-
dores e cerca de 300 problemas especı́ficos de versões de servidores web, é um scanning
de vulnerabilidades de código aberto. De acordo com [Weidman 2014], o Nikto é um
scanner de vulnerabilidades de aplicações web, que procura problemas como arquivos
perigosos, versões desatualizadas e erros de configuração. Na Figura 7, mostra os resul-
tados obtidos pela ferramenta Nikto.
Figura 7. Resultados obtidos pela ferramenta Nikto

Como pode ser observado, o comando realizado na Figura 7, foram executa-

das uma série de consultas simultâneas, com o objetivo principal de verificar todos os
diretórios raiz, tentar adivinhar diretórios, enumera nomes de usuários via apache reali-
zando força bruta em alguns serviços, lista nomes de usuários via CGI (Common Gateway
Interface) e testa força bruta em subdomı́nios. De acordo com os resultados apresentados,
alguns dados como o IP e servidor, apresenta que apenas alguns tipos de cabeçalhos não
estão definidos, mas as principais consultas não conseguiram trazer resultados relevantes.
O presente trabalho apresentou conceitos sobre a segurança da informação além da
realização de analises de vulnerabilidades ao painel do site. Nesse contexto sabe-se que
159
todas as aplicações web na Internet, estão suscetı́veis a serem alvos fáceis para os crimino-
sos virtuais, onde buscam por vulnerabilidades para a efetivação de seus ataques. Diante
de tal fato, fica evidente a necessidade de buscar métodos de segurança que colaborem e
contribuam contra a inibição de qualquer tipo de ataques contra aplicações web.
A realização de testes em aplicações web é de fundamental importância, pois é
nesse processo onde se pode mensurar e precaver os riscos, evitando graves problemas de
invasões. Durante a elaboração deste trabalho foram utilizadas de várias ferramentas para
auxiliar na composição de ataques ao painel administrativo do site, com a finalidade de
identificar suas vulnerabilidades.
Como sugestão de trabalhos futuros, serão analisados e testados novos métodos de
ataques, com a finalidade de focar nos nı́veis de segurança da aplicação, de maneira a apri-
morar mecanismos de autenticação, criação de usuários, senhas, métodos de criptografia,
validação de formulários, dentre outros. Buscando sempre proporcionar a segurança da
informação na aplicação, evitando qualquer tipo de ataques realizados por criminosos
virtuais que venham a comprometer a segurança das informações.
Referências
Azevedo, M. S. S. (2006). Protocolo Hı́brido para Autenticação Quântica de Mensagens
Clássicas com uso do Gerador de Seqüências Pseudo-aleatórias Blum-Blum-Shub.
PhD thesis, Universidade Federal de Campina Grande.
Carneiro, A. (2002). Introdução à segurança dos sistemas de informação.
Dias, C. (2000). Segurança e auditoria da tecnologia da informação. Axcel Books.
Ferreira, M. (2003). Propaganda eleitoral na internet.
Marciano, J. L. P. (2009). Segurança da informação: uma abordagem social.
Pauli, J. (2014). Introdução ao Web Hacking: Ferramentas e técnicas para invasão de
aplicações web. Novatec Editora.
RAMOS, A. (2008). Security officer–1: Guia oficial para formação de gestores em
segurança. Segunda Edição. Porto Alegre–RS: Editora Zouk.
Santos, D. L. R. and Silva, R. M. S. (2012). Segurança da informação: a norma iso/iec
27000 e iso/iec.
Sêmola, M. (2014). Gestão da segurança da informação, volume 2. Elsevier Brasil.
Silva, P. T., Carvalho, H., and Torres, C. B. (2003). Segurança dos sistemas de
informação: gestão estratégica da segurança empresarial.
SINGH, S. (2008). O livro dos códigos. a ciência do sigilo-do antigo egitoa criptografia
quântica. Sétima ediçao.
Weidman, G. (2014). Testes de invasão: Uma introdução pratica ao hacking. Novatec
Editora.
160
ADA: Evolução do Algoritmo do Duelista Aplicado a

Problemas de Otimização Global
Demison Rolins de Souza Alves1, Mário Tasso Ribeiro Serra Neto1, Rodrigo Lisbôa
Pereira2,3, Edson Koiti Yasojima2
1
Centro Universitário do Estado do Pará, Belém, Pará, Brasil. Grupo de Estudos Temático em
Computação Aplicada -Laboratório de Inteligência do Centro Universitário do Estado do Pará
(GET-COM -LINCOMP CESUPA)
2
Universidade Federal do Pará, UFPA Laboratório de Computação Bio-Inspirada (LCBIO)
Belém, Pará, Brasil
3
Universidade Federal Rural da Amazônia, Paragominas, Pará, Brasil
[email protected], [email protected], [email protected],
[email protected]
Abstract. The Duelist Algorithm (DA) is a technique that obtained good performance
solving problems of optimization with real variables, however, presents high
randomness. Thus, this work presents an adapted model called ADA (Adapted Duelist
Algorithm) that applies mathematical formulation to the classical algorithm to obtain
a fast convergence. In order to validate its effectiveness, the algorithm to be tested in
benchmark functions and its results compared to the canonical versions of the
Algorithm Genetic and Duelist, without classification was superior in the test cases.
Resumo. O Duelist Algorithm (DA) é uma técnica que obteve bom desempenho
solucionando problemas de otimização com variáveis reais, entretanto, apresenta
alta aleatoriedade. Sendo assim, este trabalho apresenta um modelo adaptado
denominado ADA (Algoritmo do Duelista Adaptado) que aplica formulações
matemáticas ao algoritmo clássico para obter uma rápida convergência. Com o
propósito de validar a eficiência do mesmo, o algoritmo fora testado em funções de
benchmark e seus resultados comparados com as versões canônicas do Algoritmo
Genético e Duelist Algorithm, no qual mostrou-se superior nos casos de teste.
1. Introdução
Há diversos algoritmos utilizados e descritos na literatura solucionando problemas de
otimização como o Genetic Algorithm (GA) por Holland (1975), Artificial Bee Colony (ABC)
por Karaboga (2005), entre outros, o Duelist Algorithm (AD), desenvolvido por Biyanto et al.
(2016). É mais uma técnica plausível a ser utilizada para soluções de tais problemáticas onde o
objetivo é atingir o valor máximo ou mínimo de uma função, o foco deste artigo é expor a
eficiência da adaptação realizada na técnica de crossover concebido por Yasojima et al. (2016),
aplicado ao AD.
O trabalho está organizado da seguinte forma: a seção 2 explica o embasamento teórico
sobre o AD, bem como são modeladas matematicamente; seção 3 explana a adaptação realizada
ao modelo original; a seção 4 descreve as configurações e testes; na seção 5 têm-se os resultados
obtidos; por fim, conclui-se o trabalho na seção 6.
161
2. Algoritmo do Duelista
Proposta por Biyanto et al. (2016), o AD é uma técnica para otimização inspirado em um duelo
entre indivíduos. Este pode ser considerado uma competição esportiva como: uma luta de boxe,
duelo entre dois lutadores, ou uma partida de futebol, duelo entre duas equipes [Reilly, 2003.
Woodward, 2006.].
O modelo original é semelhante ao AG proposto por Holland (1975), que define
indivíduos portadores de um cromossomo, e.g. vetor de elementos, e um valor de adaptação
baseado em seu cromossomo. Entretanto, o AD trata o arranjo de elementos como um skillset
(e.g. conjunto de habilidades), uma capacidade de luta como valor de fitness e um fator de sorte
para cada duelista da população. O algoritmo é composto de seis etapas principais, em que com
exceção da primeira etapa, outras estão inseridas em um ciclo finito de iterações, sendo estas:
 Registro e Pré-qualificação: Esta etapa corresponde ao processo de inicialização,
encontrado em outros algoritmos apresentados por Binitha e Sathya (2012). O registro
e pré-qualificação correspondem respectivamente a: 1) gerar aleatoriamente novos
conjuntos de habilidade para cada duelista; 2) avaliar cada conjunto de habilidade e
determinar sua capacidade de luta.
 Determinar o quadro de campeões: O quadro é gerado por uma série de treinamento
entre o melhor duelista encontrado e outro duelista aleatório. O melhor duelista tende a
passar experiência para seu treinando, este novo duelista substituiria a posição de
melhor duelista no jogo e se juntaria ao próximo duelo. [Biyanto et al., 2016. Biyanto
et al. 2017]
 Definir a tabela de duelos e Premiação: Dois duelistas, A e B, são selecionados
aleatoriamente para, posteriormente, entrarem em um duelo baseado em sua capacidade
de luta e sorte. Se a sorte do duelista A mais a sua capacidade de luta for maior que a do
duelista B, A é dado como vencedor do duelo e B como perdedor. Caso contrário, B é o
vencedor e A é o perdedor. A sorte para cada duelista é definida por (1),
𝑠𝑜𝑟𝑡𝑒 = 𝐷𝑓 ∗ (𝐶𝑆 + (rand(0,1) ∗ 𝐶𝑆)) (1)
em que, 𝐷𝑓 é a capacidade de luta do duelista e 𝐶𝑆 é coeficiente de sorte composto por
um valor real. O vencedor do duelo continua seu treinamento para tornar-se um melhor
duelista, enquanto que, o perdedor tem chances de adquirir determinada habilidade do
vencedor através da experiência. [Byanto et al. 2016]
 Eliminação: Por fim, a cada competição, conjunto de duelos, o pior duelista é eliminado
da competição, que abre uma oportunidade para outro duelista. [Biyanto et al., 2016.
Biyanto et al. 2017]
3. Algoritmo do Duelista Adaptado

O trabalho desenvolvido por Biyanto et al. (2016), propôs um novo algoritmo de otimização
para problemas de maximização de função e fora comparado com algoritmos presentes na
literatura. O algoritmo demonstrou convergência em ambos os casos apresentados, entretanto,
devido à alta aleatoriedade encontrada no algoritmo, modificações são necessárias para que o
mesmo obtenha melhores resultados em problemas de otimização sem comprometer a analogia
dos duelos. No Algoritmo do Duelista Adaptado (ADA), é abordada uma modificação em uma
etapa encontrada no algoritmo original, respectivamente: a etapa de premiação foi reescrita, tal
que, o novo modelo permite a capacidade de o perdedor explorar sabiamente o que deve
melhorar em seu conjunto de habilidades para uma melhor capacidade de luta. Enquanto que o
vencedor treina exaustivamente a mesma habilidade para chegar ao topo rapidamente.
162
3.1. Premiação Adaptada

Para a etapa de premiação, o duelista vencedor recebe um valor aleatório destinado a seu
conjunto de habilidade e para o perdedor, o valor do vencedor era designado ao mesmo.
Todavia, este modelo de premiação contempla o perdedor de forma mais significativa que para
o vencedor, tal que, um valor aleatório inserido ao valor do conjunto de habilidade do vencedor,
pode causar a estagnação em um melhor local, pois o vencedor pode não melhorar com o novo
treinamento aleatório. Enquanto isso, o perdedor por sua vez, obtém rapidamente um valor
melhor que seu anterior.
Após a etapa de duelos e, definir vencedor e perdedor, o ajuste no conjunto de habilidade
do perdedor é dado por (2),
𝑃𝑖 = 𝑃𝑖 + 𝛼 ∗ (𝑉𝑖 − 𝑃𝑖 ), 𝑆𝑒, 𝑉𝑖 ≤ 𝑃𝑖 (2)
𝑓(𝑥) = {
𝑃𝑖 = 𝑃𝑖 + 𝛼 ∗ (𝑉𝑖 + 𝑃𝑖 ), 𝑆𝑒, 𝑉𝑖 > 𝑃𝑖
Em que, Pi corresponde ao conjunto de habilidade aleatório i do perdedor, Vi equivale ao
conjunto de habilidade aleatório i do vencedor e por fim, α equivale a uma constante cujo
objetivo é controlar o valor de adaptação do perdedor. Este mecanismo de adaptação ao
treinamento é uma simplificação do modelo apresentado por Yasojima et al. (2016), que aborda
um fluxo de direções para cada valor do cromossomo dos indivíduos. Para a bonificação do
vencedor, (3) é aplicada,
𝑉𝑖 = 𝑉𝑖 + (𝑉𝑖 ∗ 𝛼) (3)
em que, Vi e α correspondem ao mesmos valores encontrados em (2). O mecanismo adotado
incrementa o treinamento de ambos os duelistas auxiliando a adaptação para que, em outro
duelo, estes venham a obter desempenho melhor que outros futuros adversários. A Figura 1
ilustra o mecanismo abordado para bonificação dos treinamentos pôs duelo.
Figura 1. Mecanismo de otimização para vencedores e perdedores.
4. Configurações e testes
No seguinte experimento, a Tabela 1 apresenta as funções de benchmark utilizadas para validar
a eficiência do algoritmo, ambas com o objetivo de maximização. Estas funções são
consideradas representativas pela comunidade cientifica a fim de testar a eficiência de qualquer
algoritmo com proposito de otimização numérica.
No que diz a respeito dos parâmetros do algoritmo, as configurações propostas por
Byanto et al. (2016), foram utilizadas para o ADA, sendo estas: 1) 100 duelistas; 2) o valor
163
designado a constante α é igual a 0.05; 3) 200 gerações; 4) coeficiente de sorte 0.1. Por fim, os
parâmetros do Algoritmo Genético adotado foram: 1) 100 indivíduos; 2) 200 gerações; 3)
probabilidade de mutação 0.5; 4) probabilidade de crossover 0.8.
Tabela 1. Funções de benchmark utilizadas.
Função Limite Dimensão Equação Global
F1 [0-10] 2 𝑓(𝑥) = −(𝑥. sin(4. 𝑥) + 1,1. 𝑦. sin(2, 𝑦)) 18.5547
F2 [0-10] 2 𝑥.(𝑦+5) 30.3489

𝑓(𝑥) = −(√𝑥 2 + 𝑦 2 . cos(𝑥 − 𝑦) . 𝑒
(cos( ))
7 )
5. Resultados
A Tabela 2 apresenta os resultados estatísticos associados às funções. Estes resultados foram
obtidos por intermédio dos valores encontrados em 30 execuções distintas e seeds aleatórias
diferentes, sendo assim, garantindo que nenhuma técnica fora influenciada pela máquina.
Tabela 2. Resultados estatísticos para as funções de benchmark.
DA GA
Função Resultados ADA Biyanto et al. Biyanto et al.
(2016) (2016)
Fitness 18.5495 18.5285 -
F1 Média 18,1099
DP 0,32955
Fitness 30.3248 30.3060 30.3017
F2 Média 30,2277
DP 0,4960
A Tabela 3 apresenta a evolução das melhores soluções obtidas, onde para F1

encontrou-se o resultado após a vigésima iteração e para F2 após a decima sétima.
Tabela 3. Evolução das soluções máximas encontradas utilizando o ADA.
F1 F2
164
Após a análise de resultados, constatou-se que o algoritmo aqui proposto obteve melhor
desempenho quando comparado à versão canônica, encontrando valores mais aproximados do
máximo global. Portanto, as modificações inseridas permitiram uma ampla busca no espaço,
encontrando duelistas mais aptos para estes problemas.
6. Conclusão
O objetivo deste estudo foi analisar o desempenho do ADA em comparativo com a versão
canônica do mesmo para funções de benchmark, onde por meio destes testes efeituados obteve
resultados superiores ao GA e o AD desenvolvido por Biyanto et al. (2016). A modificação
realizada no AD provou-se efetiva, por meio da adaptação da técnica de crossover concebida
por Yasojima et al. (2016), onde pela qual conseguiu aproveitar de forma mais ampla o espaço
de busca deparando-se com soluções melhores.
Como trabalhos futuros, pretende-se ampliar os testes do algoritmo proposto com o
intuito de encontrar suas limitações, para talvez aplicar uma próxima modificação no mesmo
assim buscando conseguir resultados melhores.
Referências
Binitha, S., and S. Siva Sathya. "A survey of bio inspired optimization algorithms."
International Journal of Soft Computing and Engineering 2.2 (2012): pp 137-151.
Biyanto, Totok R., Henokh Yernias Fibrianto, and Hari H. Santoso. "Duelist Algorithm: An
Algorithm in Stochastic Optimization Method." Advances in Swarm Intelligence, The Seventh
International Conference on Swarm Intelligence, Junho. 2016.
Biyanto, Totok R., et al. "Techno Economic Optimization of Petlyuk Distillation Column
Design Using Duelist Algorithm." Procedia Engineering 170 (2017): pp 520-527.
J. Holland. Adaptation in Natural and Artificial Systems. University of Michigan Press, 1975.
K. Woodward, Boxing, Masculinity and Identity. The" I" of the Tiger: Routledge, 2006.
Karaboga D. “An idea based on honey bee swarm for numerical optimization”. Vol. 200.
Technical report-tr06, Erciyes university, engineering faculty, computer engineering
department, 2005.
T. Reilly, Science and soccer: Routledge, 2003.
Yasojima, Edson Koiti Kudo, et al. "Analyzing Genetic Algorithm with Game Theory and
Adjusted Crossover Approach on Engineering Problems." International Conference on Hybrid
Intelligent Systems. Springer, Cham, 2016.
165
Algoritmos Evolucionários Multiobjetivos para a Seleção de

Casos de Teste para Sistemas Inteligentes
Daniel V. Saraiva1, Francisca Raquel de V. Silveira1
1
Grupo de Engenharia de Software e Redes de Computadores (GERCOM)
Instituto Federal de Educação, Ciência e Tecnologia do Ceará - IFCE
Aracati, Brasil
Abstract. With the increase use of computer systems, rational agent emerges as a
promising technology in solution from relatively simple problems, as well as
complex problems. Due to its autonomy, agent testing has become a major
challenge because these agents can present different results in the same test
entry. This work presents the proposal of a tester that performs local search in
the state space of utility-oriented test cases and uses multiobjective evolutionary
algorithms, NSGAII, SPEA2, PAES and MOCell with the objective of identifying
which ones are more efficient in the generation of test cases for rational agents.
Resumo. Com o aumento da utilização de sistemas computacionais, agente

racional surge como uma tecnologia promissora na solução desde problemas
relativamente simples, bem como, problemas complexos. Devido sua autonomia,
testes de agentes tem se tornado um grande desafio, pois esses agentes podem
apresentar diferentes resultados em uma mesma entrada de testes. Com isso, este
trabalho apresenta a proposta de um agente testador que realiza busca local no
espaço de estados de casos de teste orientado por utilidade e utiliza os
algoritmos evolucionários multiobjetivos, NSGAII, SPEA2, PAES e MOCell com
o objetivo de identificar quais deles são mais eficientes na geração de casos de
testes para agentes racionais.
1. Introdução
Os softwares estão cada vez mais complexos e não dependem, em última análise, do
aumento do poder computacional. Desse modo, o objetivo central da Inteligência Artificial
(IA) é procurar incorporar nos programas e sistemas, conhecimentos e capacidades
normalmente associadas ao ser humano, a fim de encontrar soluções viáveis [Costa e
Simões 2015].
Agentes racionais surgem, então, como uma tecnologia promissora. Um agente
racional deve possuir atributos capazes de distingui-lo dos demais programas, tais como:
operação sob controle autônomo; percepção do ambiente; persistência por tempo
prolongado; adaptação às mudanças e capacidade de criação e perseguição de metas. Sua
racionalidade pode ser definida quando o agente atua para alcançar o melhor resultado
[Russel e Norvig 2013].
Entretanto, a autonomia por um lado, ajuda os agentes de software a lidarem com
ambientes complexos e abertos. Por outro lado, faz com que testes de agentes se tornem
uma tarefa desafiadora. Em uma mesma entrada de teste, os resultados podem ser
diferentes em diferentes execuções. Por esta razão, os testes de agentes requerem um
procedimento que sirva para uma grande variedade de contextos de casos de testes e devem
ser aplicados nos casos de testes mais exigentes [Nguyen et al. 2012].
166
Visto que testar esses sistemas tornou-se uma premissa fundamental, este trabalho
apresenta a proposta de um agente testador que realiza busca local1, baseado em população
e orientado por uma função utilidade2 para encontrar conjuntos de casos de teste satisfatórios,
ou seja, encontrar casos que levem os agentes testados a um maior índice de falhas. Dessa
forma, serão realizadas comparações entre quatro estratégias de busca local de algoritmos
evolucionários multiobjetivos (MOEAs - Multiobjective Evolutionary Algorithms)
utilizados pelo agente testador, primeiramente na geração inicial de um conjunto de casos
de testes e em seguida, entre os conjuntos avaliados pela função utilidade associado ao
desempenho dos agentes testados, a geração de um novo conjunto de casos de testes mais
útil que o anterior.
Os algoritmos Non-dominated Sorting Genetic Algorithm (NSGA-II), Strength
Pareto Evolutionary Algorithm (SPEA2), Pareto Archived Evolution Strategy (PAES) e
MultiObjective Cellular (MOCell) foram escolhidos por serem largamente utilizados e
representam diferentes estratégias de evolução para lidar com problemas de otimização.
Para avaliar a acurácia desses algoritmos a serem comparados, foram desenvolvidos quatro
tipos diferentes de programas de agentes que foram testados com os casos de teste gerados
por cada MOEA. Dessa forma, ao final do ciclo de testes, as comparações entre as
aplicações de cada algoritmo têm o objetivo de identificar quais deles possuem os melhores
desempenhos para que possam ser utilizados por um agente testador na geração de casos de
teste que sejam capazes de apresentar informações relevantes sobre o desempenho dos
agentes testados.
2. Fundamental Teórica
2.1. Agentes Racionais
Agente Racional é toda entidade capaz de interagir com o ambiente guiada, em geral (mas
não necessariamente) por objetivos. Um agente possui um mecanismo que permite recolher
informações do ambiente (percepção), mecanismos que lhe permitem atuar sobre o
ambiente (ação) e processos que definem qual a melhor ação a realizar (decisão) [Costa e
Simões 2015].
Cinco tipos básicos de programas de agentes que incorporam os princípios
subjacentes a quase todos os sistemas inteligentes são enumerados em [Russel e Norvig
2013]: (i) agente reativo simples (seleciona suas ações com base na sua percepção atual,
ignorando o restante do histórico de percepções); (ii) agente reativo baseado em modelo
(que seleciona ações com base no seu histórico de percepções e assim reflete sobre alguns
dos aspectos não observados do estado atual); (ii) agente baseado em objetivos (que possui
como característica, selecionar ações com base nos objetivos que descreve situações
desejáveis); (iv) agente baseado em utilidades (seleciona suas ações que maximizam a
utilidade esperada dos resultados da ação) e (v) agente com aprendizagem (converte todos
os agentes básicos citados anteriormente e pode melhorar o desempenho de seus
componentes de modo a gerar melhores ações).
2.3. Algoritmos Evolucionários Multiobjetivos
Inicialmente, problemas de grande importância tinham suas soluções baseadas nos métodos
matemáticos. Porém, a complexidade desses modelos levou os pesquisadores a concentrar
1
Os algoritmos de busca local são úteis para resolver problemas de otimização, nos quais o objetivo é
encontrar o melhor estado de acordo com uma função objetivo (RUSSELL; NORVIG, 2013).
2
A função utilidade é essencialmente uma internalização de uma medida de desempenho para o agente.
167
seus esforços no desenvolvimento de heurísticas com soluções baseadas nos fenômenos

biológicos, sociais ou físicos observados na natureza [Ponsich et al., 2013].
O uso de algoritmos evolutivos para resolver problemas desta natureza, tem sido
motivado principalmente por causa da natureza populacional que permite a geração de
várias soluções em uma mesma execução. Além disso, a complexidade de alguns
problemas de otimização multiobjetivos, como por exemplo, problemas com grande espaço
de busca e de incertezas, podem impedir a utilização ou aplicação de técnicas tradicionais
[Coello et al. 2007]. Neste contexto, existe uma grande motivação para o uso de algoritmos
evolucionários multiobjetivos em vez de outras técnicas.
Diferentes agentes autônomos foram testados usando diferentes técnicas ao longo dos anos.
Por exemplo, metodologias de testes de softwares orientados a objetivos [Houhamdi 2011],
algoritmos evolutivos [Nguyen et al. 2012], agentes testadores [Silveira et al., 2014;
Carneiro et al., 2015] com o objetivo de verificar o comportamento dos agentes para
atender as especificações e os desejos dos usuários.
Baseados nesses trabalhos, verificamos se as abordagens são capazes de atender aos
seguintes critérios adotados em nosso trabalho: (I) noção de agentes racionais de Russell e
Norvig (2013), (II) utilização de casos de testes gerados de acordo com os objetivos, (III)
medida de avaliação de desempenho do agente testado, (IV) consideração dos planos que
são necessários para que este agente alcance estes objetivos, (V) simulação da avaliação de
desempenho das interações do agente testado com seu ambiente (histórias) , (VI) utilização
de estratégias de busca local multiobjetivo orientada por utilidade para encontrar casos de
teste e histórias correspondentes em que o agente não foi bem avaliado e (VII)
comparações entre diferentes algoritmos para identificar qual deles apresenta os melhores
resultados levando em consideração as mesmas configurações de testes.
A Tabela 1 apresenta o comparativo entre os trabalhos relacionados citados nessa
seção. Podemos constatar que três das abordagens analisadas não podem atender a todos os
critérios definidos e o trabalho de Carneiro et al., 2015 realiza comparações com somente 2
algoritmos multiobjetivos, enquanto esse trabalho realiza comparações com 4 algoritmos.
Dessa forma, a necessidade da geração automatizada de testes e a aplicação de diferentes
algoritmos multiobjetivos para a seleção de casos de teste, foco deste trabalho, podem gerar
de forma automatizada bons casos de testes que proporcione informações relevantes sobre
o desempenho insatisfatório dos componentes dos agentes testados.
Tabela 1: Medida de Avaliação de Desempenho.
Trabalhos Relacionados
Houhamdi, Nguyen et Silveira et Carneiro et al., Nossa Abordagem
2011 al.,2012 al., 2014 2015
Critérios II, IV e VI II, III, IV e I, II, III, I, II, III, IV, V, VI e I, II, III, IV, V, VI e
Avaliados VI IV, V e VI VII (com apenas 2 VII ((com 4
algoritmos) algoritmos)
4. Abordagem Proposta e Metodologia
4.1. Visão Geral
A abordagem fundamenta-se na noção de agentes inteligentes de Russell e Norvig (2013),
Costa e Simões (2015) e na interação dos agentes abordada em Silveira et al. (2015). Assim,
essa abordagem considera que além do Projetista, existem quatros programas agentes
168
envolvidos na seleção e testes: (i) o programa agente a ser testado, denominado Agente,
concebido pelo projetista; (ii) o programa ambiente de tarefa, Ambiente; (iii) um programa
agente para a geração e seleção de casos de testes, Agente Testador, foco principal desta
abordagem.
A Figura 1 ilustra as interações entre os agentes. Primeiramente, o Projetista é o
responsável pelo desenvolvimento do Agente, pela definição da medida de avaliação de
desempenho e por outras informações necessárias para o Agente Testador executar o
processo de teste do Agente em Ambiente e um programa agente monitorador, Monitor.
Figura 1: Visão geral da abordagem.
O processo do Agente Testador inicia com a geração inicial de casos de testes, uma
população formada por um conjunto de indivíduos (casos de testes), gerada de maneira
aleatória por um algoritmo evolucionário. No próximo passo, todos os casos de testes da
geração inicial são executados, o que significa submeter o Agente a cada um dos cenários
de teste. Na avaliação das histórias, o Agente Testador calcula o valor de cada medida de
avaliação de desempenho. As histórias avaliadas são submetidas ao um algoritmo
evolucionário multiobjetivo, que selecionam os melhores casos de testes e geram novas
populações ou modificam as populações existentes. Nesta fase é possível selecionar
indivíduos mais capazes que possuem maior probabilidade de gerar mais descendentes,
enquanto que os menos capazes poderão ainda gerar descendentes, porém em uma escala
menor. O Agente Testador, após os ciclos de testes, envia para o agente Monitor os casos
de teste em que Agente obteve o comportamento mais inadequado, um conjunto de
histórias correspondentes e seus valores de utilidade contendo os objetivos não satisfeitos
adequadamente pelo Agente e as falhas cometidas por ele em Ambiente.
4.2. Agente Testados
O ambiente considerado para os experimentos desses agentes possui 25 salas, dispostas em
forma de uma matriz 5 x 5, em que cada eixo (x,y) representa uma sala que pode conter ou
não sujeira. Em cada iteração com o ambiente, independentemente da sala, a função do
agente pode escolher uma das seguintes Ações: aspirar (Asp), não operar (N-op), ou mover-
se para outra sala vizinha (Acima, Esquerda, Direita, Abaixo). Como o ambiente é estático,
cada caso de teste é instanciado em um programa ambiente (Ambiente) que obedece ao
modelo determinístico.
O primeiro agente desenvolvido foi denominado de RS_Parcial do tipo reativo
simples, no qual a seleção da ação a ser executada baseia-se apenas na percepção atual do
ambiente parcialmente observável, de forma que o agente consegue identificar apenas a sua
169
localização e a presença ou não de sujeira. O segundo agente desenvolvido foi denominado

de Agente reativo simples com alteração, RS_Parcial_Alterado. Esse agente foi
desenvolvido com o objetivo de verificar a sensibilidade da abordagem proposta e as
possíveis falhas para que fosse possível avaliar o desempenho dos algoritmos com outros
agentes que realizam suas ações avaliando suas percepções e seu histórico de salas já
visitadas. Esse agente, toma suas ações independentemente do estado da sala na qual o
agente se encontra. O terceiro agente testado (RS_Total) diferencia-se dos dois primeiros
agentes no seguinte aspecto: a observabilidade do ambiente. Nesse agente, foi considerada
a capacidade de uma visibilidade total do ambiente. Assim, o agente movimenta-se em
direção à sujeira mais próxima. O quarto e último agente testado (RM_Parcial) foi do tipo
baseado em modelo com visibilidade parcial do ambiente, no qual uma representação
interna do ambiente é mantida com todas as salas já visitadas, a fim de evitar que o agente
visite salas já percorridas.
Para avaliar o desempenho dos agentes testados, a função Utilidade avalia os
conjuntos gerados, considerando valores de pesos iguais a 0,5 tanto para o atributo limpeza
quanto para o atributo energia gasta em cada ação ( ). Além desses valores,
acrescentou-se a esta função um ganho por caso de teste que é igual ao número de salas
sujas ao final das iterações de Agente com Ambiente. Assim, com a inclusão desse valor,
faz com que o Agente Testador busque selecionar casos de teste em que o Agente teve um
comportamento inadequado em termos de energia e limpeza, dando privilégios aqueles
casos em que o ambiente permaneceu com a maior quantidade de salas sujas ao final das
interações.
4.3. Plano Experimental
Os parâmetros para utilização dos MOEAs foram ajustados para que cada algoritmo
execute seu processo evolutivo específico, entretanto, diante de um ambiente similar. Além
disso, foi considerado como critério de parada, o número máximo de 30 gerações
(iterações) para cada algoritmo. Os Valores dos Parâmetros Utilizados pelos MOEAs são
apresentados na Tabela 2.
Tabela 2: Valores dos Parâmetros Utilizados pelos MOEAs
Método de seleção torneio NSGA-II, SPEA2; MOCell

Operador de cruzamento (SinglePointCrossover NSGA-II, SPEA2; MOCell
probabilidade = 0.9)
Operador e taxa de mutação (BitFlipMutation, NSGA-II, SPEA2; PAES; MOCell
probabilidade= 0.6)
Tamanho do Arquivo Externo (tamanho 20) SPEA2; PAES; MOCell
Os casos de testes iniciais, foram gerados de forma aleatória pelos algoritmos

multiobjetivos testados. Ao todo, são gerados 20 casos (NCasos), ou seja, representa o
tamanho da população, e cada caso de teste é formado por 25 salas. A avaliação de
desempenho final em cada caso, leva em consideração a realização de 5 simulações (Ns),
onde cada simulação dá origem a uma história contendo 25 episódios correspondentes às
iterações de Agente em Ambiente (Nit).
5. Apresentação e Análise dos Resultados
A Figura 2 ilustra os resultados dos quatros experimento obtidos por Agente Testador
considerando a função Utilidade, conforme os valores de pesos para os
170
objetivos energia e limpeza ao longo de 30 gerações utilizando os quatro algoritmos

multiobjetivos.
Figura 2: Resultados dos Experimentos.
Os pontos marcados linearmente com os rótulos, identificam o melhor caso de teste

na população em sua geração, já os pontos não rotulados, significam que o melhor fitness
daquela geração está abaixo do melhor caso de teste encontrado em uma geração anterior,
ou seja, não houve melhora na geração seguinte.
No experimento 1 com RS_Parcial (Figura 2 (a)), o algoritmo NSGA-II apresentou
o melhor valor de fitness em dois momentos, na 15ª e 22ª geração com utilidade = 16,1. Na
utilização do algoritmo SPEA2, o melhor valor da função é obtido também na 22ª geração,
entretanto, com utilidade = 15,5. Para o algoritmo PAES, o melhor valor é obtido na 25ª
geração com utilidade = 14,1 e para o algoritmo MOCell, o melhor valor é obtido apenas
na 27ª geração com utilidade = 15,5. Podemos destacar também, o número de vezes (4
vezes) que os algoritmos SPEA2 e o PAES conseguiram evoluir suas populações de casos
de teste. Assim, temos ao final desse primeiro experimento, considerando os melhores
casos de teste, o NSGA-II com o melhor resultado, seguido pelos algoritmos SPEA2 e
MOCell e, com o pior desempenho, o algoritmo PAES.
No experimento 2 com RS-Parcila-Alterado (Figura 2(b)), podemos observar que
esse agente é mais inadequado que o agente RS_Parcial. Isso ocorre devido as regras
condição-ação do agente RS_Parcial_Alterado serem definidas aleatoriamente,
possibilitando que o subsistema de tomada de decisão seja capaz de selecionar ações que
podem produzir episódios com falhas, tornando o valor de Utilidade mais inadequado. Na
utilização do algoritmo NSGA-II, o melhor valor é obtido na 26ª geração com utilidade =
23,6. Nas próximas gerações, esse valor é tomado apenas como referência e não é
selecionado nenhum caso de teste com valor de utilidade superior. Para o algoritmo
171
SPEA2, o melhor valor da função é obtido na 27ª geração com utilidade = 23,4. Já para o
algoritmo PAES, o melhor valor é obtido na 28ª geração com utilidade = 21,8 e para o
último algoritmo, MOCell, o melhor valor é obtido na 8ª geração com utilidade = 20,6,
entretanto, o algoritmo não conseguiu mais gerar casos de testes com utilidade superior a
partir dessa geração.
A Figura 2(c) apresenta os experimentos do terceiro experimento. O valor de
inadequação do agente reativo simples em um ambiente totalmente observável é bem
menor que os valores dos outros dois agentes em um ambiente parcialmente observável.
RS_Total percebe todo o ambiente e isso permite a concepção de um subsistema de tomada
de decisão capaz de selecionar as ações que sejam realmente racionais em cada interação
com o ambiente. Na utilização do NSGA-II, o algoritmo obteve o seu melhor valor da
função Utilidade na 23ª geração com utilidade = 6,5. Na utilização do algoritmo SPEA2, o
melhor valor da função é obtido também na 28ª geração com utilidade = 7,5. Na utilização
do PAES, o algoritmo não conseguiu gerar casos de testes mais eficientes, tendo o mesmo
valor de utilidade em todas as gerações. Para o algoritmo MOCell, o melhor valor é obtido
apenas na 30ª geração com utilidade = 6,5.
A Figura 2(d) apresenta os experimentos do agente RM_Parcial. Na utilização do
algoritmo NSGA-II, o melhor valor da função é obtido na 26ª geração com utilidade =
13,1. Na utilização do algoritmo SPEA2, o melhor valor da função é obtido na 8ª geração
com utilidade = 11,9. Na utilização do PAES, o melhor valor é obtido na 12ª geração com
utilidade = 9,9. Para o algoritmo MOCell, o melhor valor é obtido na 30ª geração com
utilidade = 12,3. Nesse experimento, o NSGA-II foi o algoritmo que obteve o melhor
resultado, seguido pelos algoritmos MOCell e SPEA2 e com o pior desempenho, o
algoritmo PAES.
6. Conclusões
Esta pesquisa apresentou a aplicação de um agente testador orientado por uma
função utilidade e pelas estratégias de busca local dos algoritmos evolucionários
multiobjetivos (MOEAs) baseadas em populações para encontrar conjuntos de casos de
teste satisfatórios para o problema de otimização de seleção de casos de teste.
Com os resultados obtidos por meio dos quatro experimentos para cada algoritmo, a
viabilidade da utilização da estratégia NSGA-II que identificou, em média, maiores
situações de casos de teste em que o agente obteve um maior valor da função Utilidade, ou
seja, piores desempenhos. Em segundo lugar ficou o algoritmo SPEA2 que conseguiu
atingir um desempenho acima das demais técnicas implementadas, o que a credenciou
como uma boa técnica de otimização para o problema estudado juntamente com NSGA-II.
O algoritmo evolutivo MOCell obteve o terceiro melhor desempenho e o algoritmo PAES
foi o algoritmo com o pior desempenho que obteve em média, o menor valor da função, se
mostrando uma opção ineficiente na geração de casos de testes para essa problemática.
Assim, o agente testador selecionou um conjunto de casos de teste satisfatório em
termos dos resultados gerados sobre o desempenho irregular do agente, principalmente com
a utilização dos algoritmos NSGA-II e SPA2. Dessa forma, a utilização do elitismo pelos
algoritmos NSGA-II e SPA2, tem como objetivo, prevenir a perda do melhor caso de teste
encontrado em uma geração anterior. Com base nesses resultados, a abordagem possibilita
informações que possam realizar mudanças objetivas na estrutura interna do agente de
forma a melhorar seu desempenho, ressaltando a importância dessa pesquisa, tanto na área
de Inteligência Artificial (IA) como de Engenharia de Software (ES).
172
O aperfeiçoamento e a continuidade deste trabalho, constituem-se em

oportunidades para trabalhos futuros que incluem além do emprego de agentes com
maiores complexidades a serem testados, uma proposta de um agente testador que usa
aprendizagem de máquina para resolução do problema de seleção de casos de testes. Para
isso, o agente testador poderá utilizar algoritmos de aprendizagem de máquina para
aprender o desempenho dos agentes testados a partir de um conjunto de atributos e
propriedades obtidas das características do ambiente e do problema que o agente busca
solucionar.
Referencias
CARNEIRO, S. M.; SILVA, T. A. R. da; RABêLO, R. d. A. L.; SILVEIRA, F. R. V.;
CAMPOS, G. A. L. de. Artificial immune systems in intelligent agents test. In: 2015
IEEE Congress on Evolutionary Computation (CEC). [S.l.: s.n.], 2015. p. 536–543.
ISSN 1089-778X.
COELLO GARY B. LAMONT, D. A. V. V. a. C. A. C. Evolutionary Algorithms for
Solving Multi-Objective Problems: Second Edition. 2. ed. Springer US, 2007. (Genetic
and Evolutionary Computation Series). ISBN 978-0-387-33254-3,978-0-387-36797-
2.Disponívelem:<http://gen.lib.rus.ec/book/index.php?md5=E14DAD9680795E083639
D060B9BD8247>.
COSTA, E.; SIMÕES, A. Inteligência Artificial: Fundamentos e Aplicações. 3. ed.. ed.
[S.l.]: Lisboa: FCA, 2015.
HOUHAMDI, Z. Test suite generation process for agent testing. Indian Journal of
Computer Science and Engineering IJCSE, v. 2, 2011.
NGUYEN, C. D.; MILES, S.; PERINI, A.; TONELLA, P.; HARMAN, M.; LUCK, M.
Evolutionary testing of autonomous software agents. Autonomous Agents and Multi-
Agent Systems, v. 25, n. 2, p. 260–283, 2012. ISSN 1573-7454. Disponível em:
<http://dx.doi.org/10.1007/s10458-011-9175-4>.
PONSICH, A.; JAIMES, A. L.; COELLO, C. A. C. A survey on multiobjective
evolutionary algorithms for the solution of the portfolio optimization problem and other
finance and economics applications. IEEE Transactions on Evolutionary Computation,
v. 17, n. 3, p.321–344, June 2013. ISSN 1089-778X.
RUSSELL, S.; NORVIG, P. Inteligência Artificial. 3. ed.. ed. [S.l.]: Rio de Janeiro:
Elsevierl, 2013.
SILVEIRA, F. R. de V.; CAMPOS, G. A. L. de; CORTéS, M. I. A problem-solving agent
to test rational agents - a case study with reactive agents. In: Proceedings of the 16th
International Conference on Enterprise Information Systems. [S.l.: s.n.], 2014. p. 505–
513. ISBN 978-989-758-027-7.
SILVEIRA, F. R. V.; CAMPOS, G. A. L. de; CORTéS, M. Monitoring and diagnosis of
faults in tests of rational agents based on condition-action rules. In: Proceedings of the
17th International Conference on Enterprise Information Systems. [S.l.: s.n.], 2015. p.
585–592. ISBN 978-989-758-096-3.
173

Plataforma IoT para automação de controle IR não

invasivo aplicado em ar-condicionado
Leonardo da S. Costa, Paulo Mateus M. da Silva, Pedro Hericson M. Araújo,
Diego L. C. Gonçalves, Manuel A. de S. Maciel, Daniel B. de Castro, Raul G. C. de
Melo, Sandro C. S. Jucá
Campus Maracanaú – Instituto Federal de Educação, Ciência e Tecnologia do Estado do
Ceará (IFCE)
CEP: 61.939-140 – Maracanaú – CE – Brasil
{leonardo.costa, mateus.moura, hericson.araujo}@ppgcc.ifce.edu.br,
{zyhazz, manuel.ifce, dcastro.infor, raullmello, sandro.juca}@gmail.com
Abstract. Air conditioning equipment are widely used in homes and public
offices. Its use contributes considerably to the value of the energy bill, which
can represent half of the total electricity consumption. In this sense, an IoT
platform was developed consisting of AutoCast - low-cost equipment to control
air conditioners in an automated and non-invasive way through infrared - and
SystemCast - Web application responsible for managing via internet or
intranet air conditioners . The HTTP and MQTT communication protocols
were used for communication between SystemCast and AutoCast. The
proposed platform was tested and validated in a computer lab. An AutoCast
was used to simultaneously control two air conditioners.
Resumo. Equipamentos condicionadores de ar são amplamentes utilizados em
residências e repartições públicas. Sua utilização contribui consideravelmente
no valor da conta de energia, podendo representar metade do consumo total
de energia elétrica. Nesse sentido, foi desenvolvida uma plataforma IoT
constituída por AutoCast – equipamento de baixo custo para controlar
aparelhos de ares-condicionados de forma automatizada e não invasiva por
meio de infravermelho – e pelo SystemCast – aplicação Web responsável por
gerenciar via internet ou intranet condicionadores de ar. Os protocolos de
comunicação HTTP e MQTT foram utilizados para comunicação entre o
SystemCast e o AutoCast. A plataforma proposta foi testada e validada em um
laboratório de informática. Um AutoCast foi utilizado para controlar
simultaneamente dois ares-condicionados.
1. Introdução
Aparelhos ares-condicionados split system são amplamente utilizados em residências,
edificações comerciais e repartições públicas. Buscando melhorar a qualidade de vida
[Pontes et al. 2017] ou atender à legislação [BRASIL 2007], muitos recorrem à sua
utilização a fim de possibilitar um melhor controle da climatização dos ambientes.
Seu uso pode representar um valor significativo no consumo de energia de uma
residência: segundo Almeida (2016), o consumo médio mensal em residências pode
alcançar até 21% na conta de energia, que equivale a 200 reais considerando um
ar-condicionado de 10.000 BTU ligado diariamente por um intervalo de 8 horas. Já em
174

prédios públicos, é estimado que o uso de sistemas de refrigeração contribua com cerca
de 48% [Magalhães 2002].
Um fator agravante é o desperdício decorrente do controle manual e individual
dos condicionadores de ar. Repartições em que convivem uma grande quantidade de
pessoas são propensos a possuírem aparelhos ligados desnecessariamente. Além do
aumento da conta de energia, problemas de suprimento da demanda de energia elétrica
pode se tornar uma realidade quando se tem um consumo excessivo proveniente dos
ares-condicionados [Pires 2005].
Um dos caminhos buscados para a redução de desperdícios é através de
automação e monitoramento [Urzêda 2010]. Aplicações na automação industrial
oferecem formas de controle através de Sistema Digital de Controle Distribuído
(SDCD). Mais recentemente, o advento da Internet das Coisas (IoT) trouxe a automação
para ambientes residenciais (domótica) e comerciais, buscando trazer comodidade
[Morales 2011].
Entretanto, ainda de forma comum, tais alternativas necessitam que
equipamentos possuam o suporte à tecnologia empregada [Ribeiro 2016], são
economicamente proibitivas para residências e entidades, ou são invasivas –
necessitando adaptações na infraestrutura do ambiente para que seja possível o controle.
Buscando oferecer uma alternativa viável, é proposto neste artigo o AutoCast,
um sistema embarcado de baixo custo – composto por hardware e software – para
controle não invasivo de ares-condicionados através de infravermelho (IR). Além disso,
foi desenvolvido o SystemCast, um sistema Web para o acompanhamento e controle
remoto via MQTT de ambientes que utilizam AutoCasts.
O desenvolvimento deste trabalho foi composto pelas seguintes etapas: (i)
análise bibliográfica de trabalhos relacionados; (ii) seleção de equipamentos, estudo do
protocolo e construção do hardware para controle dos ares-condicionados (iii);
desenvolvimento do sistema para gerenciamento remoto; e, (iv) testes para
comprovação da funcionalidade e da usabilidade.
2. Trabalhos relacionados
Esforços aplicados em automação residencial (domótica) buscam oferecer novas formas
de interação em equipamentos já presentes no lares bem como proporcionar conforto ao
manipulá-los remotamente [Lima 2015]. Aplicar conceitos de domótica, além de poder
trazer conforto, segurança e praticidade, pode tornar-se um aliado na redução de gastos
desnecessários em recursos como água e energia [Bolzani 2007].
Sob uma perspectiva de automação em repartições públicas, a fácil interação
entre dispositivos como sensores, atuadores, displays, câmeras de vigilância, veículos,
possibilita a obtenção de uma grande variedade de dados para análise, monitoramento e
segurança [Kulkarni 2017].
Nesse sentido, vários projetos têm sido desenvolvidos nos últimos anos. Piyare
(2013) propôs um sistema de controle e monitoramento de luzes, sensores de
temperatura e de corrente utilizando um Web service baseado em RESTful sobre um
Arduino Uno conectado à rede utilizando shield ethernet. Para o gerenciamento dos
sensores e equipamentos eletroeletrônicos, foi desenvolvido um aplicativo na
plataforma Android.
175

Figueiredo (2013) construiu um sistema de controle supervisionado e aquisição

de dados (SCADA), no qual os comandos enviados ao sistema embarcado é realizado
por uma aplicação em MATLAB que fornece aos sistemas SCADA a capacidade de
gerenciar algoritmos de controle complexos, denominado plataforma
SCADA-MATLAB.
Especificamente para aparelhos ares-condicionados, Mercier (2015) elaborou
um sistema de controle remoto universal. O sistema construído permite gravar os sinais
IR de um aparelho não registrado. Foi utilizado o microcontrolador Arduino Uno para
enviar os comandos IR e um aplicativo na plataforma Android para o controle dos
equipamentos. A comunicação entre os dispositivos ocorre através de Bluetooth Low
Energy (BLE).
Diante dos trabalhos relacionados apresentados, nota-se algumas debilidades. As
propostas não oferecem uma opção para controle simultâneo de equipamentos. Nos
trabalhos realizados por Piyare (2013) e Figueiredo (2013) a utilização de cabos
ethernet para comunicação dificulta a instalação dos equipamentos. Na tese de Mercier
(2015) é possível somente um controle local, pois o alcance é restringido pela
capacidade da tecnologia de comunicação utilizada.
3. Desenvolvimento
A partir do estudo bibliográfico orientado pela problemática de desperdício de energia,
o objetivo do projeto foi definido: desenvolver um sistema não intrusivo que permita
controle remoto centralizado, de forma que promova comodidade aos que utilizam-se da
plataforma e auxilie no gerenciamento para economizar energia,.
Para alcançá-lo, foi desenvolvido um sistema para controle de
ares-condicionados remotamente de fácil instalação (Figura 1). Este é dividido em duas
partes: AutoCast (aparelho para controle de equipamentos de ar de forma não intrusiva)
e SystemCast (sistema Web para gerência remota de AutoCasts).
Figura 1. Elementos participantes do projeto: (a) dispositivos clientes para
controle remoto, (b) servidor SystemCast, (c) AutoCast e (d) equipamentos
controlados.
3.1. AutoCast
AutoCast é um sistema embarcado gerenciado remotamente para controle de
condicionadores de ar através da transmissão de comandos IR. O equipamento é
composto por três partes: microcontrolador com acesso à rede Wi-Fi, módulo de
transmissão e módulo de captura.
Dentre as alternativas de sistemas embarcados para a construção do projeto, foi
escolhido o ESP8266, um microprocessador de 32 bits com pinos de entrada e saída
digitais e analógicas e suporte a conexão Wi-Fi (Figura 2 - B) [Molloy 2016]. O
176

microprocessador foi utilizado por meio do NodeMCU (Figura 2 - A), um firmware e

kit de desenvolvimento open-source amplamente utilizado em projetos embarcados
[Vicenzi 2015].
O NodeMCU é mais rápido e barato diante de outros microcontroladores como o
Arduino Uno, sendo considerado o equipamento ideal para diversas soluções que
envolvam IoT por possuir conexão WiFi embutida. Outra vantagem relevante é seu
tamanho reduzido, o que possibilita uma fácil adaptação e instalação em cases para
aplicações de automação [Souza 2016].

Figura 2. Esquema interno de controle infravermelho do AutoCast.
A transmissão dos sinais de comando para controle de um ar-condicionado é

realizada por meio de LEDs infravermelho (Figura 3 - B): ao receber uma requisição de
execução de um comando, o AutoCast utiliza-os para transmitir a informação ao
equipamento. Os LEDs foram estrategicamente distribuídos a fim de alcançar uma
maior área de abrangência. O transistor BC 337 (Figura 2 - C) foi incrementado ao
sistema com o intuito de aumentar a intensidade do sinal de forma a compensar perda de
intensidade decorrente da conexão em paralelo dos LEDs.
Foi adicionado ao sistema embarcado um receptor infravermelho (Figura 3 - A)
para a captura de sinais de controle. Botões do controle remoto do ar-condicionado
foram pressionados para que os comandos correspondentes fossem armazenados e
mapeados para uma utilização posterior pelo AutoCast, esses dados podem ser
persistidos no servidor para que outros usuários venha a utilizar. A Figura 3 mostra um
protótipo construído para a realização dos testes.
Figura 3. LEDs dos Módulos de Transmissão e de Captura do AutoCast em
destaque. Versão protótipo do AutoCast.
177

Um problema existente na solução não invasiva apresentada é uma possível

inconsistência do estado de aparelhos gerenciados pelo AutoCast decorrente de um
controle manual. Foi adicionado ao AutoCast um sensor de temperatura. Assim,
decisões coerentes e reajustes podem ser tomadas pelo usuário do sistema ou,
futuramente, pelo próprio sistema com base em padrões estabelecidos em tempo real.
3.2. SystemCast
O gerenciamento de AutoCasts é realizado através do sistema desenvolvido SystemCast.

Ele oferece uma interface Web para controle e comunica-se com os dispositivos
utilizando MQTT (Message Queue Telemetry Transport). Por meio dele, usuários com
permissão podem controlar dispositivos individualmente ou simultaneamente, onde as
instruções direcionadas a um grupo lógico de equipamentos serão executadas
concomitantemente para os dispositivos associados a ele.

Figura 4. Esboço de telas do SystemCast.
O sistema proposto pode ser utilizado como plataforma online, onde clientes
cadastram os equipamentos na internet. E modo intranet, onde um servidor é
configurado para controlar equipamentos da rede interna.
Em uma versão anterior, eram utilizados notificações pull, onde os clientes

(AutoCast) requerem de tempos em tempos o estado dos equipamentos a serem
controlados diretamente de um banco de dados não estruturado na plataforma Firebase.
Entretanto, uma utilização desnecessária de banda, bem como a impossibilidade do
sistema ser executado em intranets sem permissão de acesso à Internet, inviabilizou a
utilização dessa tecnologia. Decidiu-se então migrar para uma tecnologia cuja
comunicação é orientada à push: o servidor envia notificações para AutoCasts
cadastrados via MQTT, de modo que a banda é utilizada apenas quando necessário.
4. Testes
Testes foram realizados em um laboratório de informática que possui aparelhos
condicionadores de ar modelo split de mesma marca posicionados em uma mesma
parede e separados à uma distância de 3 metros um do outro (Figura 5 - B). Para
controle, um AutoCast foi posicionado no teto ligado à uma tomada (Figura 5 - A).
Verificou-se que o controle simultâneo de ares-condicionados ocorreu de forma
esperada. A disposição dos LEDs infravermelhos permitiu que o AutoCast, em uma
distância de 4 metros, conseguisse com êxito controlar ambos os aparelhos. O AutoCast
(Figura 5 - A) controla os dois ares-condicionados simultaneamente, não sendo possível
controlá-los individualmente. Os equipamentos gerenciados por um mesmo AutoCast
178

devem ser de mesma marca e, preferencialmente, de mesmo modelo para que não haja
incompatibilidade de protocolos.
Figura 5. Laboratório utilizado como ambiente de testes.
Em testes do módulo de captura de comandos, foram realizadas leituras de sinais

de controles de televisão e de aparelhos ares-condicionados de outras marcas. De forma
geral, a captura ocorre com êxito. Entretanto, para protocolos de controle cuja
mensagem transmitida eram grandes, a leitura do sinal demandou um esforço
redobrado: informações irrelevantes eram capturadas durante o processo de leitura.
Recomenda-se que esta etapa ocorra longe de outras fontes emissoras de infravermelho,
bem como evitar exposição ao sol, um emissor natural de IR.
Estudos realizados por Mercier (2015) identificaram uma semelhança entre
codificações IR de diferentes fabricantes. Desta forma, adaptadores universais podem
ser construídos com bases nesses padrões encontrados. Informações específicas de uma
mensagem infravermelho permite também que adaptadores consigam conhecer sinais de
controle até então desconhecidos.
Com base nas características citadas da plataforma IoT, uma tabela comparativa
foi formulada (Tabela 1) com intuito de caracterizar e comparar o trabalho proposto
com trabalhos relacionados.
Tabela 1. Análise comparativa com trabalhos relacionados.
AutoCast + Figueiredo
SystemCast (2013) Piyare (2013) Mercier (2015)
Equipamentos Ar-condicionado Sensor de água Sensores de Ar-condicionado

alvo luminosidade,
temperatura,
corrente.
Microcontrolador ESP8266 PLCs Arduino Arduino
Standalone Não Não Sim Não
Gerenciamento Internet e Intranet Intranet Internet e Intranet Bluetooth

remoto (Internet)
Protocolo para MQTT DDE RESTful CIR

controle
179


A plataforma desenvolvida (AutoCast e SystemCast) permite o controle remoto de
aparelhos ares-condicionados modelo split através de uma tecnologia não invasiva de
baixo custo. Comunicando-se por meio de infravermelho, um AutoCast transmite
comandos para aparelhos ao receber requisições MQTT provindas a partir da aplicação
Web SystemCast controlada por um usuário.
Oferecendo uma forma de controle centralizado de aparelhos distribuídos
fisicamente, o sistema apresentado pode ser utilizado como ferramenta para a aplicação
de métodos de controle consciente dos aparelhos condicionadores de ar. Ainda, em
conjunto com outra ferramentas de automação, possui potencial para transformar
edificações em ambientes inteligentes.
Como trabalhos futuros, almeja-se (i) implementar novas variações do AutoCast,
permitindo o controle de outros equipamentos por meio da implantação de outros
protocolos e de tomadas inteligentes, e (ii) estender o SystemCast, integrando-o com
padrões para IoT recentes, como Web Thing API [Mozilla 2017].
Por fim, um estudo da aplicação da tecnologia aqui apresentada deverá ser
realizado de forma a mensurar, ainda sob uma perspectiva científica, o impacto
financeiro de sua implantação e a economia gerada. Para isso, pretende-se realizar um
projeto em conjunto com uma instituição de ensino pública.
6. Referências
Almeida, T. (2016) “Como calcular o consumo de energia do ar-condicionado”.
Disponível em:
http://industriahoje.com.br/como-calcular-o-consumo-de-energia-do-ar-condicionado
. Acessado em: Fevereiro/2017.
Bolzani, C. (2007). Desmistificando a domótica. Escola Politécnica da Universidade de
São Paulo.
Brasil (2007). “NR 17 Ergonomia” Ministério do Trabalho e Emprego. Normas
Regulamentadoras de Segurança e Medicina do Trabalho. Disponível em:
http://www.trt02.gov.br/geral/tribunal2/LEGIS/CLT/NRs/NR_17.html. Acesso em:
12 de julho de 2017.
Figueiredo, J., Botto, M. A., and Rijo, M. (2013). Scada system with predictive
controller applied to irrigation canals. Control Engineering Practice, 21(6):870–886.
Kulkarni, R., Kawade, A., Prabhune, S., and Dhakne, A. R. (2017). Web based
monitoring of sensor data for smart cities. International Journal of Engineering
Science, 12643.
Lima, J. C. (2015). Estudo de viabilidade de implantação de automação residencial a
baixo custo. Monografia (Engenharia Elétrica), URCAMP (Faculdade de Cariacica),
Cariacica, Brasil.
Magalhães, L. C. (2001). Orientações gerais para conservação de energia elétrica em
prédios públicos. Rio de Janeiro: Eletrobrás.
180

Mercier, A. (2015). Universal infrared adapter for air conditioners. PhD thesis. Upp-
sala University, Disciplinary Domain of Science and Technology, Mathematics and
Computer Science, Department of Information Technology.
Molloy, D. (2016). Wireless communication and control. Exploring Raspberry Pi, pages
535–575.
Morales, G. (2011). La domótica como herramienta para un mejor confort, seguridad y
ahorro energético. Ciencia e Ingeniería, pages 39–42.
Mozilla. (2017). Web Thing API. W3C Member Submission 24 July 2017. Disponível
em: http://iot.mozilla.org/wot/. Acesso em: 01 de agosto de 2017.
Pires, L., Silva, P. D., and Castro Gomes, J. (2005). A importância do consumo
energético dos edifícios na europa: soluções propostas para a sua redução.
Universidade da Beira Interior, Covilhã, Portugal.
Piyare, R. (2013). Internet of things: ubiquitous home control and monitoring system
using android based smart phone. International Journal of Internet of Things,
2(1):5–11.
Pontes, V. V., Silva, A. M. H. L. D., Ramos, A. C. P., de Oliveira, M. B., and Jardim,
M. R. (2017). Qualidade de vida no trabalho: O caso de uma indústria gráfica em juiz
de fora-mg. Anais-CAT, 2(1).
Ribeiro, T. J. de A., O. S. C. (2016). Projeto de um gateway para automação residencial.
Revista de Engenharia e Pesquisa Aplicada, 1(1).
Souza, M. V. d. (2016). Domótica de baixo custo usando princıṕ ios de iot. Master’s
thesis, Brasil. Mestrado Profissional em Engenharia de Software) - Instituto
Metrópole Digital, Universidade Federal do Rio Grande do Norte, Natal.
Urzêda, C. C. d. (2010). Software scada como plataforma para a racionalização
inteligente de energia elétrica em automação predial. Master’s thesis, Universidade
de Brasília, Brasília. Mestrado em Engenharia Elétrica.
Vicenzi, A. (2015). Bustracker: Sistema de rastreamento para transporte coletivo.
Monografia de Centro de Ciências Exatas e Naturais - Curso de Ciência da
Computação – Bacharelado.
181
Uma Proposta de uma Sirene Escolar Utilizando Hardware Livre Para

os Colégios Técnicos Vinculados à Universidade Federal do Piauí
Bernan Rodrigues do Nascimento1, Wilamis Kleiton Nunes da Silva2, Maria
Arlenilde dos Santos3, João Gabriel Alves de Carvalho4, Otávio Henrique
Guimarães5, Otília de Sousa Santos 6
1
Colégio Técnico de Floriano – CTF/UFPI
Rodovia BR 343, Km 3,5, S/n - Meladão, Floriano - PI, 64808-605
[email protected], {bernanr7, otavioguimaraes999,
[email protected]}
Abstract. The Arduino platform is an open hardware technology that has as

one of its objectives to make electronic applications and programming simpler
and more intuitive. The objective of this work is to develop a system of low
cost and easy to access school siren automation that can be implemented in
technical schools linked to the Federal University of Piauí - UFPI. During the
test phase, the prototype showed a good functioning even with the lack of
electricity, all class hours were flagged normally, without delays as defined in
the implementation. It can be concluded that the prototype presents itself as a
viable solution of low cost for automation of the sirens of the technical
colleges linked to UFPI.
Resumo. A plataforma Arduino é uma tecnologia open hardware que tem

como um dos seus objetivos tornar as aplicações técnicas de eletrônica e
programação mais simples e intuitivas. O objetivo do trabalho foi desenvolver
um sistema de automação de sirene escolar de baixo custo e de fácil acesso,
que possa ser implantado nas escolas técnicas vinculadas a Universidade
Federal do Piauí - UFPI. Durante a fase de teste, o protótipo apresentou um
bom funcionamento mesmo com a falta de energia elétrica, todos os horários
das aulas foram sinalizados normalmente, sem atrasos conforme definidos na
implementação. Pode-se concluir que, o protótipo apresenta-se como uma
solução viável de baixo custo para automação das sirenes dos colégios técnicos
vinculados a UFPI.
1. Introdução
A cada dia fica mais difícil encontrar hardwares e softwares livres de baixo
custo e fácil acesso, que sejam rápidos e confiáveis. Os sistemas de automação ou
domótica como também é conhecido, estão em constante crescimento e atuam em várias
áreas.
Uma preocupação recorrente desta tecnologia tem sido o desenvolvimento de
sistemas inteligentes e automatizados com o intuito de facilitar a vida das pessoas. Mas
nem todo usuário pode possuir esse sistema, por não ter condições relativamente
182
financeiras para mantê-lo (CARDOSO, 2014). Existe um interesse por domótica pela
sociedade com vistas a melhorar a qualidade de vida, tornando-a mais prática. Porém,
devido aos custos relativamente altos, a sua popularização ainda não é uma realidade
(STOPPA, et al. 2013).
STOPPA et al. (2013) complementa que, usuários tem interesse pela tecnologia,
mas os custos relativamente altos ainda atrapalha a sua utilização. A automação não
deve ser vista sob a concepção de luxo, mas sim como uma melhoria na vida de seus
usuários e maior rendimento no ambiente de trabalho.
Visando automatizar o acionamento da sirene de um Colégio Técnico vinculado
a Universidade Federal do Piauí - UFPI, sirene esta responsável por sinalizar o começo e
o fim das aulas, a plataforma Arduino foi adotada por ser uma solução tecnológica de
baixo custo e de fácil acesso, que possui hardware livre e vários componentes
eletrônicos que podem ser adicionados a ela. O que motivou o trabalho foi a busca por
um sistema de automação de sirene escolar de baixo custo e de fácil acesso, que pudesse
ser implantado nas escolas técnicas vinculadas à UFPI, haja visto que, não foram
encontradas sirenes automatizadas nas referidas escolas.
2. Plataforma Arduino
A plataforma Arduino é uma tecnologia open hardware e utiliza um
microcontrolador da família AVR, e um dos seus objetivos é tornar as aplicações
técnicas de eletrônica e programação mais simples e intuitivas. Com ela, podem-se
monitorar sensores, comunicar com computadores e celulares e, inclusive, pode-se
controlar algumas funções como ligar e desligar lâmpadas, abertura de fechaduras
elétricas, leitura de sensores, etc (NOGUEIRA, et al. 2013).
Existem vários modelos de Arduino no mercado e o escolhido para o
desenvolvimento do protótipo foi o modelo uno R3, ver Figura 1.
Figura 1: Placa Arduino uno R3.

Fonte: CARDOSO, 2014.
183
A placa Arduino uno R3 é baseada no microcontrolador ATmega328. Possui 14

entradas/saídas digitais dos quais seis dessas podem ser usadas como saídas PWM
(Pulse-Width Modulation - Modulação por largura de pulso), 6 entradas analógicas, uma
conexão USB, um conector de alimentação e um botão de reset. Para comunicação
utiliza o protocolo ICSP (In Circuit Serial Programming – Programação Serial em
Circuito).
O Arduino possui uma IDE (Integrated Development Environment) baseado nas
linguagens C/C++ para programação da placa que é disponibilizada para download, essa
IDE roda nas plataformas Windows e Linux e ainda possui uma linguagem de
programação onde todo o código fonte é aberto, fazendo com que exista uma grande
comunidade de desenvolvedores que disponibilizam bibliotecas na internet.
3. Lista de Materiais
A execução deste trabalho é baseada na plataforma Arduino, que é uma
plataforma de hardware e software open source, cuja principal vantagem é a facilidade
em criar projetos interativos nas áreas da robótica, automação, monitoramento, etc.
devido à grande quantidade de material disponível para estudo e simulação, e sua
linguagem de fácil compreensão e alto nível de abstração (originalmente baseada na
linguagem C/C++), além de diversos componentes eletrônicos compatíveis (ARDUINO,
2017).
Tabela 1: Lista de materiais utilizados no protótipo
COMPONENTE DESCRIÇÃO DO COMPONENTE
Adicionar um relógio de tempo real ao
projeto com uma memória não volátil para
a) Módulo RTC DS1307
armazenar dia do mês, semana, mês, ano,
hora, minuto e segundo.
b) Display LCD 16x2 Exibir mensagens de texto para o usuário.
Ligar ou desligar o fluxo elétrico, cumprindo
c) Jumpers
as configurações específicas.
d) Módulo relé (5v) 4 canais Controlar as cargas utilizada no projeto.
e) Potenciômetro 10k Controlar o brilho e contraste da tela LCD.
Uma placa de desenvolvimento
f) Placa Arduino Uno R3
microcontrolada.
Na intenção de encontrar novas tecnologias de baixo custo, foi executada

pesquisa tipo exploratória no intuito de se aprofundar no título e no conteúdo a ser
apresentado, sendo realizando levantamento bibliográfico e visitas ao ambiente escolar
onde seria implementado o sistema de automação. A Figura 2 apresenta os componentes
utilizados na montagem do protótipo.
184
Figura 2: Componentes utilizados no trabalho.

Fonte: autoria própria.
Antes de realizar a montagem do circuito foram realizados testes individuais em
todos componentes do circuito, após a fase de teste foi realizado a montagem do
protótipo. A Figura 3 apresenta o desenho do circuito utilizado no projeto.
Figura 3: Desenho do circuito utilizado no projeto.

No circuito da Figura 3 a placa Arduino está conectada ao módulo RTC (relógio

de tempo real) por meio de suas portas analógicas, o módulo RTC é responsável por
armazenar data e hora, após data e hora serem recebidas e processadas pela placa
Arduino são exibidas no display LCD, para ajustar o contraste do display LCD foi
utilizado um potenciômetro.
O módulo relé está conectado na porta digital do Arduino esperando enviar um
sinal para que ele possa acionar uma carga externa como a sirene que está conectado a
ele. Para o circuito funcionar, a placa Arduino tem que ser alimentada e programada
185
para executar os comandos e tarefas foi designada na implementação, após conectada e

alimentada via USB em um computador com o ambiente de programação do Arduino.
Dentro da IDE do Arduino é criado e carregado na placa o código responsável
por, ajustar data e hora do módulo RTC e a programação dos horários que o módulo relé
vai ser acionado.
Após o carregamento do código na placa Arduino o protótipo fica em fase de
teste e observação, visando analisar se a data e hora está adiantando ou atrasando e se a
sirene está sendo disparada de acordos com a programação. Na fase de teste do protótipo
foi utilizada uma lâmpada de 220V para simular a sirene, ver Figura 4.
Figura 4: Fase de teste.

5. Considerações finais
Durante a fase de teste o protótipo apresentou um bom funcionamento mesmo
com falta de energia elétrica, a hora e a data não foram atrasadas ou adiantadas. Todos
os horários das aulas foram sinalizados normalmente sem atrasos conforme foram
definidos na programação. Por tanto, pode-se concluir que o protótipo apresenta uma
solução viável e de baixo custo para automação das sirenes dos colégios técnicos
vinculados à UFPI.
186
Referências
ARDUINO. What is Arduino?, 2017. Disponível em:

<https://www.arduino.cc/en/Guide/Introduction>. Acessado em: 17/10/2017.
CARDOSO, Luis Filipe Campos. Sistema de Automação Residencial Via Rede

Celular Usando Microcontroladores e Sensores. Revista de Engenharia da
Universidade Católica de Petrópolis, Petrópolis-RJ, v. 8, p.70-83, 2014.
NOGUEIRA, Carolina Lio Mende. Autocontrol: uma Proposta Para Acessibilidade e

Segurança Residencial com o Apoio da Plataforma Arduino. Revista Tecnologias em
Projeção, Taguatinga-DF, v. 4, p.1-9, jun. 2013.
STOPPA, Marcelo Henrique et al. Domótica: Uma Solução Para A Vida Moderna -
Automação Residencial Com Controle Via Web. Revista Ceppg, Catalão-, v. 28, p.71-
84, 2013.
187
Segmentação do Disco Óptico para Detecção Automática do

Glaucoma Aplicando o Algoritmo K-means
Antônio Sousa Vieira de Carvalho Júnior1 , Antônio Oseas de C. Filho1 ,
Alcilene D. de Sousa 1 ,Patricia Vieira da S. Barros1 , Patrı́cia Medyna L. de L. Drumond1
1
Campus Senador Helvı́dio Nunes de Barros – Universidade Federal do Piauı́ (UFPI)
{antoniooseas,alcileneluzsousa,petibarrosthe}@gmail.com
{junior sousa95,patymedy}@hotmail.com
Abstract. Glaucoma is a disease developed in the region of the optic disc by the
increase of the intraocular pressure that causes the loss of the vision of progres-
sive form. It is of the utmost importance that glaucoma be identified early to
facilitate treatment. Computer vision through digital image processing techni-
ques has been developing methods for automatic detection of glaucoma. In this
research a method was applied applying the extraction of red, green and blue
channels into retinal images using the k-means algorithm for the segmentation
of the optical disc and then the extraction of characteristics addressing index
descriptors of phylogenetic diversity indexes and finally the attributes with mul-
tiple classifiers were classified. The results were significant with highlight to the
classifier textit Random Forest, presenting a Sensitivity of 75.4 %, Specificity of
86.6 % and Accuracy of 77.5 %.
Resumo. O glaucoma é uma doença desenvolvida na região do disco óptico

pelo aumento da pressão intraocular onde resulta na perda da visão de forma
progressiva. É de suma importância que o glaucoma seja identificado no inı́cio
para facilitar o tratamento. A visão computacional através de técnicas de pro-
cessamento digital de imagens vem desenvolvendo métodos para a detecção au-
tomática do glaucoma. Nesta pesquisa foi desenvolvido um método aplicando
a extração dos canais red, green e blue em imagens da retina, utilizando o al-
goritmo k-means para a segmentação do disco óptico e em seguida a extração
de caracterı́sticas abordando descritores de texturas baseados em ı́ndices da
diversidade filogenética e por último foi classificado os atributos com múltiplos
classificadores.Os resultados foram significativos com destaque para o classi-
ficador Random Forest, apresentando uma Sensibilidade de 75,4%, Especifici-
dade de 86,6% e Acurácia de 77,5%.
1. Introdução
O glaucoma é uma doença silenciosa caracterizada quando a pressão intraocular é ele-
vada devido o canal de circulação do lı́quido Humor Aquoso ser subitamente obs-
truı́do. A patologia é a segunda maior causa de cegueira irreversı́vel no mundo, es-
tudos revelam que em 2020 mais de 79 milhões de pessoas poderão ser portadores do
glaucoma[Ayub et al. 2016]
188
O desenvolvimento do glaucoma pode ocorrer em diversas formas, congênito, com

uso de medicamentos sem prescrição médica ou ser adquirido por meio de outras doenças
oculares. Quando a doença se manifesta, inicialmente o paciente pode perder o campo
visual das regiões periféricas e depois o campo central, isso acontece pelo fato da pressão
intraocular estar elevada podendo causar alterações no campo visual e cegueira.
Como não há cura para o glaucoma é essencial o diagnóstico precoce para
facilitar no tratamento. Algumas tecnologias como, Optical Coherence Tomography
(OCT), Canning Laser Polarimetry (SLP) e o Confocal Scanning Laser Ophthalmos-
copy (CSLO), auxiliam no diagnóstico da patologia, porém esses exames possuem um
alto custo[Maheshwari et al. 2017]. O Processamento Digital de Imagens (PDI) por meio
da análises de imagens médicas da retina busca desenvolver métodos para detecção au-
tomática do glaucoma possibilitando ao especialista uma segunda avaliação sobre o di-
agnóstico.
Devido ao glaucoma originar na região do Disco Óptico (DO), é de fundamental
importância isolar o DO para extrair as caracterı́sticas aplicando descritores de texturas
que contêm informações sobre a distribuição espacial, variação de luminosidade, suavi-
dade, rugosidade, regularidade e descreve o arranjo estrutural das superfı́cies e as relações
entre os pixels próximos [de Oliveira and Fernandes 2016].
O objetivo do trabalho é desenvolver um método para a detecção automática do
glaucoma aplicando o algoritmo de clusterização k-means, que procura formar grupos
com base nos valores médios da distância euclidiana entre os atributos das diversas áreas
em um conjunto de dados [Andrade et al. 2016]. Em seguida extrair as caracterı́sticas
de textura baseadas em ı́ndices da diversidade filogenética com o propósito de classificar
os atributos para validar o desempenho do método na busca pela detecção automática do
glaucoma.
Esta seção é voltada para abordagens de alguns trabalhos da literatura desenvolvidos com
outros métodos para detecção automática do glaucoma, de forma a analisar cada metodo-
logia utilizadas.
No trabalho de Firdausy e Oktoeberza (2016), os algoritmos de Asghari e Jalali
foram usados para detectar o DO. O projeto é dividido em três etapas, a primeira trata-
se do pré-processamento, onde é feito a extração dos canais Red, Green e Blue (RGB).
Em seguida o canal Red é escolhido para outros processamentos, logo após efetuada a
segmentação utilizando as imagens da base Drishti no canal Red, para separar o DO do
restante da imagem e por ultimo a avaliação e classificação onde o valor preditivo positivo
resultou em 97.74%.
Em Santos et al (2015) a metodologia foi desenvolvida apenas com canal ver-
melho para melhorar a qualidade da segmentação. No estudo foram usadas três bases
públicas: RIM-ONE, Drishti e DRIONS-DB. Na segmentação foi necessário encontrar o
centro do DO para que pudesse traçar uma circunferência ao redor DO onde acontece o
glaucoma. Quando comparada a segmentação das três bases a que apresentou os resulta-
dos mais satisfatórios foi a RIM-ONE obtendo uma acurácia de 83%.
Em Salam et al (2017), a metodologia de estudo teve como objetivo a detecção au-
189
tomática do glaucoma. Durante o projeto foram aproveitadas imagens das bases STARE,
DRIVE, HRF e MESSIDOR disponı́veis publicamente. A principio as imagens foram
cortadas para reduzir processamento, logo após feita a segmentação para detecção do
DO e determinado um valor do Hue Saturation Value (HSV), novamente foi aplicada
outra segmentação para encontrar o copo óptico em busca de avaliar a progressão do
glaucoma, que quando avaliada a técnica, resultou em 25 imagens glaucomatosas e 72
imagens saudáveis classificadas corretamente, obtendo uma especificidade de 0,98, sen-
sibilidade em 0,92 e acurácia de 97,0% de precisão.
A metodologia aplicada por Pinheiro et al. (2015), foi segmentar a região de
interesse utilizando os canais Red, Green e Blue (RGB), em conjunto com algoritmo K-
means separando em 5 clusters para definir a área do DO e melhorar a segmentação. Na
validação dos resultados foi utilizado o classificador F-scores chegando a uma porcenta-
gem de acurácia em 91,75%.
Em relação aos trabalhos, observa-se a necessidade de melhorar os resultados em
Pinheiro et al. (2015), pois as manchas em volta dos pixels do DO não foram removidas,
visto que ocorreu uma má segmentação de forma a alterar os resultados. Já em Santos e
Veras (2012) a utilização de poucas imagens atrapalha na fidedignidade dos métodos. A
proposta da metodologia é desenvolver um método automático para a detecção do glau-
coma usando o algoritmo k-means em as duas bases RIM-ONE e Drishti, afim de obter
maior veracidade nos resultados, em relação aos encontrados na literatura, com finalidade
de auxiliar os especialista com resultados significativos, facilitando o diagnóstico precoce
do glaucoma.
A metodologia proposta tem como objetivo aplicar os canais red, green e blue para seg-
mentar a região do DO com o algoritmo k-means e extrair as caracterı́sticas usando des-
critores de textura baseados em Índices de Diversidade Filogenética para avaliar que canal
obteve melhor desempenho na detecção automática do glaucoma.O projeto desenvolvido
foi separado em 4 fase, como ilustra o fluxograma da Figura 1.
Figura 1. Fluxograma de execução.
190
4. Aquisição de Imagens
O método desenvolvido utilizou as bases RIM-ONE e Drishti, onde foram aproveitadas
245 imagens da retina, sendo 149 são de olhos saudáveis e 96 de glaucomatosos, são
bases publica fornecida por três hospitais: Hospital Universitário de Canarias, Hospital
Clı́nico San Carlos e Hospital Universitário Miguel Servet. Para diminuir o tempo de
processamento as imagens da base Drishti foram cortadas em forma de um retângulo,
como mostra na Figura 2.
Figura 2. Delimitação da região de interesse.
Com objetivo em identificar o DO mais precisamente, as imagens originais con-

tida no formato (RGB) foram separadas entre os três canais Red, Green e Blue. Com
base na literatura alguns canais apresentam uma melhor performa-se na identificação da
estrutura do DO e subtração dos vasos sanguı́neos, por permitir acentuar melhor o con-
traste e a luminosidade, facilitando a detecção da região do DO devido a sua textura
[Pinheiro et al. 2015].
5. Segmentação
Devido ao glaucoma surgir na região do DO, é essencial a segmentação da área do DO,
afim de, não influenciar na extração das caracterı́sticas [Firdausy and Oktoeberza 2016].
Com a necessidade em separar o DO do restante da imagem, foi aplicado o algoritmo
k-means, por operar dividindo uma imagem em múltiplos clusters.
A técnica de agrupamento tem sido amplamente utilizada em visão computaci-
onal, por meio da segmentação de imagens. O objetivo e agrupar conjuntos de amos-
tras de imagens cujas caracterı́sticas são semelhantes, bem como separar as imagens
diferentes. K-means é um dos mais utilizados e simples dos algoritmos de agrupa-
mento, é o método mais adequado para agrupamentos em reconhecimento de padrões
[Kulshreshtha et al. 2017].
O k-means é um algoritmo de aprendizado não-supervisionado que busca orga-
nizar grupos com base nos valores médios da distância euclidiana entre os atributos das
diversas áreas contidas em uma imagem [Andrade et al. 2016].
Durante o processo de segmentação as imagens foram divididas em dois clusters,
sendo uma classe com a região de interesse e a outra com o fundo do olho e os vasos
sanguı́neos. O objetivo é isolar a região do DO para extrair as caracterı́sticas a fim de não
interferir nos resultados obtidos, por influencia de pixels externos. Como mostra a Figura
3 usando a base RIM-ONE e a Figura 4 utilizando base Drishti.
191
Figura 3. Imagem glaucomatosa da retina (a), Segmentação aplicando k-

means no canal Red (b), Segmentação aplicando k-means no canal Green (c),
Segmentação aplicando k-means no canal Blue (d).
Figura 4. Imagem saudável da retina (a), Segmentação aplicando k-means no ca-

nal Red (b), Segmentação aplicando k-means no canal Green (c), Segmentação
aplicando k-means no canal Blue (d).
6. Extração de Caracterı́sticas
Tradicionalmente, os ı́ndices baseados na riqueza e abundância de espécies foram usados
para quantificar a biodiversidade de um ecossistema, onde esses ı́ndices são baseados na
contagem e não são responsáveis pela diversidade genética [Hickey et al. 2011]
Os Índices de Diversidade Filogenética (IDF) são utilizado na ecologia para cal-
cular a biodiversidade em um ecossistema, onde são usadas métricas de grupamento em
setores de uma área, para estimar a diversidade de uma população na qual cada elemento
pertence a uma única comunidade.
Nos IDFs Phylogenetic Diversity (PD) é calculado o somatório dos comprimentos
dos ramos de cada classe e B é o número de ramificação da árvore, Li é comprimento do
ramo e Ai é a abundância média de classes que compartilham ramos, como mostrada na
Equação 1.
PB
Li Ai
BX Pi B (1)
i Ai
A Equação 2 mostra a representação do ı́ndice filogenético Sum of Phylogenetic

Distances (SPD) que é a soma das distâncias filogenéticas entre cada par de classe e dmn
é a distância entre as classes m e n, am , abundância de classes m, S é o numero de classes
no conjunto focal.
ΣΣm < n2 mna ma n

!
S (S − 1)
X (2)
2 ΣΣm < na ma n
O Mean Nearest Neighbour Distance (MNND) trata-se da distância média do
táxon mais próximo, onde dmn é a distância entre as espécies m e n, am , é abundância de
espécies m.(Equação 3).
192
S
X
mi n (dmn ) am (3)
m
O ı́ndice diversidade Phylogenetic Species Variability (PSV) é a variabilidade de

classes filogenéticas, que retrata o grau em que as classes em uma comunidade são filo-
geneticamente relacionadas, como mostrado na Equação 4, onde, o trC corresponde a
soma dos valores da diagonal de uma matriz C, 0 c e o somatório de todos os valores da
P
matriz, n é o numero de classes e 0 c é a media dos elementos da diagonal de C.
ntrC − Σc
P SV = = 1 − 0c (4)
n (n − 1)
O IDF Phylogenetic Species Richness (PSR) é a riqueza de classes e quantifica o

número de classes em um grupo. O valor do PSR é encontrado multiplicando-se o número
de classes n pela variabilidade da comunidade, conforme os parâmetros na Equação 5.
P SR = nP SV (5)
7. Classificação e Resultados
Após extrair as caracterı́sticas de textura, realizou-se a etapa de classificação dos atribu-
tos. Como o framework WEKA contém um conjunto de algoritmos para aprendizado de
máquina, foram utilizados os classificadores Random Forest, Random Commitee, Random
Tree e J48 . A classificação foi especificada manuseando os parâmetros com os valores
padrões utilizando a validação cruzada k-folds, onde k = 10, sendo 9 grupos para treino e
um grupo de teste, para no final ser gerado uma média.
As métricas de avaliação dos resultados foram, a Sensibilidade, que é a capaci-
dade de um teste diagnóstico identificar os verdadeiros positivos nos indivı́duos verdadei-
ramente doentes, Especificidade, que calcula capacidade de um teste de diagnóstico iden-
tificar os verdadeiros negativos nos indivı́duos verdadeiramente saudáveis e Acurácia, que
determina a proporção de acertos, os olhos verdadeiros positivos e verdadeiros negativos
[Araújo et al. 2017].
Os resultados obtidos na classificação aplicando apenas o canal blue para a
detecção automática do glaucoma são exibidos na Tabela 1. Apresentando o melhor re-
sultado com o Random Forest com Sensibilidade de 70,8%, Especificidade em 83,5% e
Acurácia de 51,5%.
Tabela 1. Resultados da classificação aplicando o canal blue.
Durante a classificação com o canal green os resultados apresentados na Tabela 2
193
os mais expressivos foram obtidos com o Random Forest, onde conseguiu uma Sensibili-
dade de 75,4%, Especificidade em 86,6% e Acurácia de 77,5%.
Tabela 2. Resultados da classificação aplicando o canal green.
A classificação aplicando o canal red os melhores resultados foram com o clas-

sificador Random Forest mostrados na Tabela 3, onde conseguiu uma Sensibilidade de
71,2%, Especificidade em 78,3% e Acurácia em 62,5%
Tabela 3. Resultados da classificação aplicando o canal red.
A Tabela 4 apresenta os resultados da comparação dos trabalhos relacionados com

a metodologia desenvolvida.
Tabela 4. Comparação da metodologia com os trabalhos relacionados.
A Tabela 4 mostra os resultados alcançados pelos trabalhos relacionados e a me-

todologia desenvolvida, de modo, a fazer uma breve comparação. São apresentadas as
bases utilizadas e a métrica de validação em acurácia. Entre os trabalhos relacionados a
metodologia apresentou resultados inferiores, porém alguns trabalhos como, Santos et al
(2015) e Firdausy e Oktoeberza (2016), o numero de imagens utilizadas é menor. Deste
modo, o método desenvolvido se mostra promissor por alcançar um resultado significa-
tivo com uma quantidade de imagens superior. Entretanto é importante esclarecer que a
comparação é subjetiva, pois as metodologias aplicadas são diferentes, igualmente como
algumas bases utilizadas.
8. Conclusão
Este trabalho apresentou uma metodologia para detecção automática do glaucoma em
imagens da retina de fundo do olho segmentando região do DO onde o glaucoma se
manifesta, em seguida foi extraı́da as caracterı́sticas de textura baseados nos IDF, que
194
usa métricas de agrupamento para calcular a diversidade em uma imagem onde cada pixel
pertence a uma única classe. Os testes de detecção do DO foram realizados em duas bases
de imagens distintas. A segmentação trouxe bons resultados, satisfazendo as expectativas,
onde destaca-se o canal green com o melhor resultado apresentando uma Sensibilidade
de 75,4%, Especificidade em 86,6% e Acurácia de 77,5%.
Para trabalhos futuros pretende-se aplicar um pre-processamento para melhoras
aquisição das imagens e a aplicação de outros descritores e implantar abordagem baseadas
em Deep Learning, com finalidade em melhorar os resultados.
Referências
Andrade, E. d. O., Sampaio, I. G., Viterbo, J., da Silva, J. M., and Boscarioli, C. (2016).
Identificação de perfis de consumo domiciliar de energia elétrica a partir de algoritmos
de agrupamento.
Araújo, J. D. L., de Paiva, A. C., De Almeida, J. D., Neto, O. P. S., de Sousa, J. A., Silva,
A. C., and Júnior, G. B. (2017). Diagnóstico de glaucoma em imagens de fundo de
olho utilizando osı́ndices de diversidade de shannon e mcintosh.
Ayub, J., Ahmad, J., Muhammad, J., Aziz, L., Ayub, S., Akram, U., and Basit, I. (2016).
Glaucoma detection through optic disc and cup segmentation using k-mean clustering.
In Computing, Electronic and Electrical Engineering (ICE Cube), 2016 International
Conference on, pages 143–147. IEEE.
de Oliveira, W. E. B. and Fernandes, S. R. (2016). Classificação de padrões em ima-
gens utilizando descritores de textura-pattern classification in images using descriptors
of texture. Multiverso: Revista Eletrônica do Campus Juiz de Fora-IF Sudeste MG,
1(1):17–24.
Firdausy, K. and Oktoeberza, K. W. (2016). Segmentation of optic disc using dispersive
phase stretch transform. In Engineering Seminar (InAES), International Annual, pages
154–158. IEEE.
Hickey, G., Blanchette, M., Carmi, P., Maheshwari, A., and Zeh, N. (2011). An appro-
ximation algorithm for the noah’s ark problem with random feature loss. IEEE/ACM
Transactions on Computational Biology and Bioinformatics, 8(2):551–556.
Kulshreshtha, D., Singh, V. P., Shrivastava, A., Chaudhary, A., and Srivastava, R. (2017).
Content-based mammogram retrieval using k-means clustering and local binary pat-
tern. In Image, Vision and Computing (ICIVC), 2017 2nd International Conference
Maheshwari, S., Pachori, R. B., and Acharya, U. R. (2017). Automated diagnosis of
glaucoma using empirical wavelet transform and correntropy features extracted from
fundus images. IEEE journal of biomedical and health informatics, 21(3):803–813.
Pinheiro, A. F., Almeida, J. D., Júnior, G. B., and Silva, A. C. (2015). Metodologia
computacional para detecç ao automática do glaucoma em imagens de fundo de olho.
195
Análise de Desempenho de um Sistema Distribuído para

Segmentação de Imagens da Retina
Edson Carvalho, Marcos Vinicius Ferreira, Rodrigo Leal e Francisco Airton Silva
Universidade Federal do Piauí - UFPI

Campus Senador Helvidio Nunes de Barros - CSHNB
{edsondamasceno11,ferreiraviniciussdi,rocaleal98,francsilva10}@gmail.com
Abstract. Eye diseases affect hundreds of thousands of people around the

world. Medical specialists use computerized images to diagnose eye diseases.
Besides the diagnosis, execution time is important to avoid complications and
to anticipate treatment. This paper proposes a Sensitivity Analysis focused on
the efficiency of retinal image segmentation method. Two image segmentation
algorithms were observed: Otsu and K-means. Three factors were investigated
in 240 observations applying the statistical method Design of Experiments: (A)
Algorithm, (B) Image Size, and (C) Image Tonality. Factors A and B had a sig-
nificant impact on segmentation time. The results confirm that segmentation
with the Otsu algorithm with 400×400 images has obtained the best perfor-
mance. This work will assist future understanding about the development of
efficient computadorized diagnosis of retinal problems.
Resumo. Doenças nos olhos acometem centenas de milhares de pessoas no

mundo. Imagens computadorizadas são usadas por médicos especialistas para
diagnosticar doenças oculares. Além do diagnóstico, o tempo de execução é im-
portante para evitar complicações e antecipar o tratamento. Este artigo propõe
uma Análise de Sensibilidade focada na eficiência de sistemas de segmentação
de imagens da retina. Foram utilizados dois algoritmos para segmentação das
imagens que são: Otsu e K-means. Três fatores foram observados em 240 obser-
vações aplicando o método estatístico Design of Experiments: (A) Algoritmo,
(B) Tamanho da Imagem e (C) Tonalidade da Imagem. Os fatores A e B tiveram
impacto significativo no tempo de segmentação. Os resultados confirmam que
a segmentação com o algoritmo Otsu com imagens 400×400 tem o melhor de-
sempenho. Este trabalho auxiliará a futura compreensão do desenvolvimento
de sistemas eficientes para diagnóstico de imagens de retina.
1. Introdução
As doenças dos olhos e do sistema visual podem deixar sequelas que variam desde
uma discreta diminuição da acuidade visual até a perda total da visão [WHO 2012].
Segundo dados do World Health Organization (WHO) (2012) e do Vision 20201 , a cada
cinco segundos, uma pessoa se torna cega no mundo. Além disso, do total de casos de
cegueira, 90% ocorrem nos países emergentes e subdesenvolvidos. Estima-se que, até
2020, o número de pessoas com deficiência visual poderá dobrar no mundo.
1
Vision 2020: www.iapb.org/vision-2020/
196
Segundo a WHO (2014)2 , 43% dos problemas visuais, em países em desenvolvi-

mento, são causados por erros refrativos não corrigidos e 80% de todas as deficiências
visuais podem ser evitadas ou curadas. A análise e extração de informações por ima-
gens se tornou uma técnica para médicos especialistas diagnosticarem e identificarem
enfermidades. O tratamento de doenças visuais se beneficia de avaliações de especia-
listas sobre imagens computadorizadas.
Para realização da análise da doença, as imagens devem ser digitalizadas. Após
isso, podem ser feitas diversas transformações na imagem, até conseguir-se a solução
(ou melhor aproximação) do problema [Neves et al. 2008]. O interesse nos métodos de
processamento de imagens digitais proveem de duas áreas principais de aplicação que
são elas: (i) a melhoria da informação visual para a interpretação humana; e (ii) o pro-
cessamento de dados de imagens considerando a percepção automática de máquinas
[Nunes 2006].
Uma importante etapa dos sistemas de processamento de imagem é a segmen-
tação. Especificamente no caso de imagens da retina, a etapa de segmentação pode
ser utilizada para reduzir a área da imagem a ser processada, o que facilita e auxilia
no diagnóstico [Barbosa Filho et al. 2011]. A segmentação representa a eliminação de
partes da imagem que não trazem informações necessárias à detecção e ao diagnóstico
médico como, por exemplo, o fundo da imagem.
Em um sistema para segmentação de imagem, o tempo de execução depende
de vários fatores. A análise desses fatores pode ajudar na escolha dos parâmetros ade-
quados para o desenvolvimento de um sistema eficiente. Com o objetivo de enten-
der melhor fatores que impactam em um resultado fim de um sistema existe um mé-
todo estatístico geral chamado Análise de Sensibilidade. Tal análise pode ser feita de
várias maneiras e uma das formas mais sofisticadas é o Design of Experiment (DoE)
[Minitab 2017]. O DoE estuda um processo e seus fatores para identificar quais os fa-
tores que mais influenciam em seu comportamento e como utilizá-los a seu favor.
Este artigo apresenta uma Análise de Sensibilidade do tipo DoE em fatores que
impactam no tempo de execução da segmentação de imagens da retina. Baseado em
estudos da literatura médica foram escolhidos os fatores Algoritmo de Segmentação,
Tamanho da Imagem e Tonalidade da Cor da Imagem. O objetivo fim foi saber qual
dos fatores impactou mais no tempo de resposta dos sistemas. Como contribuições
principais do presente trabalho podem ser listadas:
1. Identificação do impacto de fatores sob o tempo de resposta de sistemas de

segmentação de imagens da retina;
2. Análise dos níveis dos fatores analisados;
3. Um sistema distribuído para realizar a segmentação de forma paralela e tendo
um dispositivo móvel como cliente ‘magro’; e
4. Listagem de possíveis direcionamentos para desenvolver novos sistemas de
segmentação de imagens.
O restante do artigo está estruturado da seguinte forma: a Seção 2 apresenta

o referencial teórico; a Seção 3 apresenta os experimentos, resultados e discussões; a
2
World Health Organization: www.who.int/mediacentre/factsheets/fs282/en/
197
Seção 4 mostra os trabalhos relacionados e a Seção 5 lista as conclusões e trabalhos

futuros.
2. Background
Esta seção é voltada para a apresentação de conceitos necessários ao entendimento
do trabalho. A segmentação envolve a divisão dnotepade imagens em subseções que
são de particular interesse [Ballard and Brown 1982]. Os algoritmos de segmentação
de imagens podem ser várias, dentre elas, destacam-se o Threshold (algoritmo Otsu) e
Clustering (algoritmo K-means). Ambos algoritmos são descritos a seguir.
2.1. Algoritmo Otsu

O Otsu é um algoritmo de limiarização, que determina o valor ideal de limiar, que se-
pare os elementos do fundo e da frente da imagem em dois grupos, atribuindo a cor
branca ou preta para cada um deles [Otsu 1979]. Após encontro do limiar ideal, a ima-
gem original é sobreposta a imagem gerada pelo método de Otsu, gerando uma nova
imagem. A Figura 1 demonstra um exemplo (em fases) de imagem segmentada usando
o método Otsu.
Figura 1. (A) Imagem normal, em (B) limiarização de Otsu e em (C) imagem so-
breposta
2.2. Algoritmo K-means

O K-means é uma técnica que usa o algoritmo de agrupamento de dados por K-médias
(K-means clustering). O objetivo deste algoritmo é encontrar a melhor divisão de P
dados em K grupos C i , = 1, ..., K , de maneira que a distância total entre os dados de
um grupo e o seu respectivo centro, somada por todos os grupos, seja minimizada
[MacQueen et al. 1967].
O procedimento do algoritmo K-means é finito, entretanto, não há compro-
vação matemática que sempre conseguirá encontrar a melhor configuração (situação
ótima) correspondente ao objetivo. O K-means pode ser executado várias vezes para
procurar o encontro de melhor configuração. A Figura 2 mostra um exemplo de ima-
gem normal e segmentada com o método K-means.
3. Experimento
Nesta seção, descrevem-se as informações e configurações do experimento investiga-
tivo realizado. A intenção é conseguir estipular o impacto de cada fator (Algoritmo de
Segmentação, Tamanho da Imagem e Tonalidade da Imagem) à fim de reportar a con-
figuração com superior eficiência de tempo na segmentação de imagens da retina. A
Tabela 1 apresenta os fatores e níveis para combinação e análise.
198
Figura 2. (A) Imagem normal, em (B) com limiarização K-means e em (C) imagem
sobreposta.
Tabela 1. Fatores e Níveis do Experimento.

Fatores Níveis
Otsu
Algoritmo
K-means
400 x 400
Tamanho da Imagem
800 x 800
Cinza
Tonalidade da Imagem
RGB
Considerando os fatores descritos na Tabela 1, fundamentos da Análise Com-

binatória demonstram que o número de combinações possíveis para o experimento
é: 2×2×2 = 8 (multiplicação de níveis envolvidos). Desta forma, são oito combinações
possíveis para investigação. A máquina de execução teve as seguintes configurações:
processador Intel Core™ i3-2375M CPU 1.50 GHz × 4, memória RAM de 4 GB e 500
GB de memória interna. Para obter o tempo de execução para cada combinação, foi
utilizada a biblioteca timeit 3 . Na Figura 3 tem-se a arquitetura dos experimentos.
Figura 3. Arquitetura dos experimentos
A base de imagens utilizada foi a RIM-ONE [Trucco et al. 2013], que é formada
por 169 imagens (com diversas resoluções) de retina dos hospitais: Hospital Univer-
sitário de Canarias, Hospital Clínico San Carlos e Hospital Universitário Miguel Servet
[Fumero et al. 2011]. Para a pesquisa proposta, utilizou-se 30 imagens com resoluções
400 × 400, e 800 × 800 em tons de Cinza e RGB. O Design of Experiments (DoE) foi apli-
cado para conhecimento dos efeitos de variações dos fatores estudados sobre o Tempo
de Execução.
3
Biblioteca Timeit: https://docs.python.org/3/library/timeit.html
199
3.1. DoE sobre Tempo de Execução

Nesta seção, realizou-se uma Análise de Sensibilidade usando Design of Experiments
(DoE) sobre o Tempo de Execução para segmentação de imagens da retina. A Tabela 3
apresenta as combinações estudadas durante o DoE. Para cada combinação, realizou-
se 30 observações, o que resulta em 240 investigações por completo. As observações
tiveram distribuição normal considerando α = 0.05, ou seja, 95% de intervalo de con-
fiança.
Tabela 2. Combinações de teste realizado

Algoritmo Tamanho Tonalidade
Otsu 400×400 Cinza
Otsu 400×400 RGB
Otsu 800×800 Cinza
Otsu 800×800 RGB
K-means 400×400 Cinza
K-means 400×400 RGB
K-means 800×800 Cinza
K-means 800×800 RGB
Para apresentação dos resultados, o Gráfico de Pareto (ver Figura 4) descreve

a importância de um efeito por seu absoluto valor, desenhando uma linha vertical de
referência no gráfico. Ao passo que o efeito prolonga essa linha, maior é a influência
na variável dependente. A linha vermelha tracejada representa a magnitude mínima
de efeitos estatisticamente significativos, considerando-se o critério de significância
estatística α = 0.05.
Figura 4. Efeitos dos Fatores sobre o Tempo de Execução
O gráfico da Figura 4 demonstra a influência superior do fator Algoritmo, em

seguida, observa-se a combinação Tamanho da Imagem e Algoritmo, e fator Tama-
nho da Imagem com expressão estatística significativa. As outras combinações estão
abaixo do nível estatístico de significância 1.021, e assim, não possuem efeitos com ex-
pressão matemática relevante. O Algoritmo apresenta um tempo de execução maior
como consequência de ser o fator responsável pela análise das imagens.
200
Quando aumentamos a imagem, a área de processamento é aumentada, como

consequência, o tempo de execução é maior. Isso vale tanto para o fator Algoritmo
como o Tamanho da imagem. Assim, o Algoritmo e Tamanho da Imagem possuem
maior influência no tempo de execução do sistema. Buscando complementar e melhor
detalhar o estudo, utilizou-se o gráfico de Efeitos Principais (que pode ser visualizado
na Figura 5). Este gráfico é usado para se demonstrar, detalhadamente, como um ou
mais fatores categóricos influenciam em uma resposta contínua.
Figura 5. Efeitos dos Fatores sobre o Tempo de Execução
Percebe-se que o fator “Algoritmo"tem maior inclinação por ser o fator de

maior impacto. O algoritmo Otsu retornou um tempo de execução reduzido. O “Tama-
nho da Imagem"possui impacto intermediário (inclinação mediana dentre as do grá-
fico). A imagem com tamanho 400×400 obteve menor consumo de tempo. Com me-
nor influência, está o fator “Tonalidade". Observa-se que a tonalidade RGB apresenta
um tempo de execução menor em relação a tonalidade Cinza. Com isso, a precedência
de configuração dos fatores resultou em 1º Algoritmo; 2º Dimensões da Imagem; e 3º
Tonalidade.
A eficiência de algoritmos de segmentação está vinculada à extração de estru-
turas e subpartes de interesse. Nesse sentido, os métodos são adaptados à aplicação
em estudo. Vale ressaltar que não existem algoritmos de segmentação convenientes
a todos os tipos de aplicação. Assim, é necessário realizar uma projeção comproba-
tória para a definição do método que possui tendência a ter melhor desempenho em
contexto ou problema.
Esta seção apresenta os trabalhos relacionados ao presente estudo. Para melhor visu-
alização a Tabela 3 elenca dois fatores comparativos: DoE e Fator de Análise. A seguir
estes fatores são comentados.
DoE: O Design of Experiments é uma ferramenta poderosa de análise estatística, pois

diminui o trabalho em repetir experimentos. Os trabalhos relacionados encon-
trados não fizeram uso desta abordagem e simplesmente fizeram comparações
com fatores de forma individual e não agrupada.
201
Tabela 3. Comparação da Metodologia Proposta com os Trabalhos Relacionados

[Autor Ano] DoE Fator de Análise
[Diyana et al. 2003] Não Eficiência e Tempo
Precisão, Recall simples e um
[Estrada and Jepson 2005] Não
Algoritmo de correspondência
[Ge et al. 2007] Não Coeficiente Jaccard
[Estrada and Jepson 2009] Não Precisão e Recall
Índice Jaccard e um novo Índice
[McGuinness and O’connor 2010] Não
Jaccard fuzzy
[Kajla and Bansal 2016] Não PSNR e Complexidade do Tempo
Nosso Estudo Sim Tempo de Execução
Fator de Análise: Este fator refere-se à variável dependente do estudo. O nosso tra-
balho focou em tempo de execução, ou seja, o tempo de resposta do sistema.
Alguns trabalhos relacionados focaram em precisão [Estrada and Jepson 2009,
Estrada and Jepson 2005]; outros focaram em coeficientes diferenciados como
o coeficiente Jaccard [Ge et al. 2007, McGuinness and O’connor 2010]. Ao con-
trário da nossa proposta os estudos relacionados não exploraram o tempo
de execução como um todo em um sistema distribuído; apenas estudaram o
tempo de computação [Diyana et al. 2003] ou exploraram a complexidade do
tempo em um módulo específico do sistema [Kajla and Bansal 2016].
5. Conclusões e Trabalhos Futuros
Este artigo apresentou uma Análise de Sensibilidade utilizando DoE sobre fatores que
impactam na segmentação de imagens da retina. Os resultados do DoE demonstra-
ram, matematicamente, que os fatores Algoritmo e Tamanho das imagens possuem
maior impacto sobre o Tempo de Execução do processamento. O fator Tonalidade
(Cinza ou RGB) teve uma discreta influência estatística. A ordem de precedência para
impacto no Tempo de Execução foi: 1º) Algoritmo, 2º) Tamanho da Imagem e 3º) To-
nalidade da Imagem. O nível do fator Algoritmo que teve maior influência no Tempo
de execução foi o Otsu. A utilização de imagens com dimensões 400×400 representou
o tamanho ideal para experimentos de segmentação, em comparação com 800×800. A
Tonalidade RGB apresentou menores tempos de segmentação. Portanto, combinando
os três fatores os níveis com melhor performance foi Algoritmo Otsu + Imagens com
dimensão 400×400 + Tonalidade RGB. Essa combinação representa a melhor configu-
ração para execução de segmentação de imagens. Como trabalho futuro, pretende-se
avaliar a execução de segmentação de imagens em uma Nuvem composta por dis-
positivos móveis com outros servidores disponíveis de forma paralela. É interessante
também abranger outros algoritmos de segmentação de imagens.
Referências
Ballard, D. H. and Brown, C. M. (1982). Computer vision, 1982. Prenice-Hall, Englewood

Cliffs, NJ.
202
Barbosa Filho, J., Batista, L., Schiabel, H., and Verçosa, L. (2011). Segmentação do
músculo peitoral em imagens mamográficas através do recorte automático de roi e
da binarização de otsu. In VII Workshop de Visão Computacional, pages 190–195.
Diyana, W. M., Larcher, J., and Besar, R. (2003). A comparison of clustered microcalcifi-
cations automated detection methods in digital mammogram. In Acoustics, Speech,
and Signal Processing, 2003. Proceedings.(ICASSP’03). 2003 IEEE International Con-
ference on, volume 2, pages II–385. IEEE.
Estrada, F. J. and Jepson, A. D. (2005). Quantitative evaluation of a novel image segmen-
tation algorithm. In Computer Vision and Pattern Recognition, 2005. CVPR 2005.
IEEE Computer Society Conference on, volume 2, pages 1132–1139. IEEE.
Estrada, F. J. and Jepson, A. D. (2009). Benchmarking image segmentation algorithms.
International Journal of Computer Vision, 85(2):167–181.
Fumero, F., Alayon, S., Sanchez, J. L., Sigut, J., and Gonzalez-Hernandez, M. (2011).
Rim-one: An open retinal image database for optic nerve evaluation. In 2011 24th
International Symposium on Computer-Based Medical Systems (CBMS), pages 1–6.
Ge, F., Wang, S., and Liu, T. (2007). New benchmark for image segmentation evaluation.
Journal of Electronic Imaging, 16(3):033011–033011.
Kajla, S. and Bansal, R. (2016). Efficient improved k means clustering for image seg-
mentation. International Journal of Innovative Research in Computer and Commu-
nication Engineering, 4:10625–10629. DOI: 10.15680/IJIRCCE.2016. 0406057.
MacQueen, J. et al. (1967). Some methods for classification and analysis of multiva-
riate observations. In Proceedings of the fifth Berkeley symposium on mathematical
statistics and probability, volume 1, pages 281–297. Oakland, CA, USA.
McGuinness, K. and O’connor, N. E. (2010). A comparative evaluation of interactive
segmentation algorithms. Pattern Recognition, 43(2):434–444.
Minitab (2017). Designing an experiment. Disponível em: support.minitab.com/en-
us/minitab/17/getting-started/designing-an-experiment. Acesso em: 14/06/2017.
Neves, S. C. M., Pelaes, E. G., and de Sinais, L. d. P. (2008). Estudo e implementação
de técnicas de segmentação de imagens. Revista Virtual de Iniciação Acadêmica
da UFPA-Universidade Federal do Pará–Departamento de Engenharia Elétrica e de
Computação, 1(2).
Nunes, F. L. (2006). Introdução ao processamento de imagens médicas para auxílio a
diagnóstico–uma visão prática. Livro das Jornadas de Atualizações em Informática,
pages 73–126.
Otsu, N. (1979). A threshold selection method from gray-level histograms. IEEE tran-
sactions on systems, man, and cybernetics, 9(1):62–66.
Trucco, E., Ruggeri, A., Karnowski, T., Giancardo, L., Chaum, E., Hubschman, J. P., Al-
Diri, B., Cheung, C. Y., Wong, D., Abramoff, M., Lin, G., Kumar, D., Burlina, P., Bress-
ler, N. M., Jelinek, H. F., Meriaudeau, F., Quellec, G., Macgillivray, T. E., and Dhillon,
B. (2013). “validating retinal fundus image analysis algorithms: Issues and a propo-
sal”. Invest. Ophthalmol. Vis. Sci.
WHO, W. H. O. (2012). Relatório mundial sobre a deficiência. São Paulo: SEDPcD.
203
Estudo da Abordagem de Ensino Orientado a Projetos:

Reflexos no Aprendizado de Eletrônica Digital
Francisco Thales R. Sousa1 2 , Francisco Mauro F. M. Filho1 ,
Abner S. Nascimento1 2 , Jermana L. Moraes1
1
Bloco das Engenharias – Universidade Federal do Ceará (UFC)
Rua Coronel Estanislau Frota s/n – CEP 62.010-560 – Sobral – CE – Brasil
2
Membro do Programa de Educação Tutorial do Curso de Engenharia de
Computação – PET-EC – UFC Campus Sobral
thales [email protected], [email protected],
Abstract. The current teaching approach is based on the traditional educational

model, since the knowledge is taken as immutable and cumulative. Therefore,
memorization of definitions and application of formulae are the only roles reser-
ved for the students. However, for Engineering classes, such methodology can
be unproductive. Considering this scenario, pedagogical strategies that empha-
size practical applications have been broadly researched. The current paper
assesses the impact that the development of electronic system prototypes has
over the conduction of the Digital Electronics undergraduate course in Compu-
ter Engineering at UFC Sobral Campus in what regards its educational benefits.
Resumo. A atual abordagem de ensino está pautada sobre o modelo educacio-

nal tradicional, em que o conhecimento é tido como pronto e cumulativo e aos
alunos é atribuı́do o papel de memorizar definições e aplicar fórmulas. Para o
ensino de Engenharia, tal metodologia é improdutiva, em razão do seu caráter
empı́rico. Por esse motivo, tem-se buscado adotar estratégias que ressaltem
essa caracterı́stica. O presente artigo descreve o impacto que o desenvolvimento
de protótipos de sistemas eletrônicos reais provoca na condução da disciplina
de Eletrônica Digital, no curso de Graduação em Engenharia de Computação
da UFC Campus Sobral, no tocante à melhoria da qualidade do aprendizado.
1. Introdução
A essência da abordagem atual de ensino fundamenta-se no processo tradicional, no qual
o professor age como sujeito ativo, que transmite conhecimentos curricularmente pré-
-estabelecidos, e o aluno torna-se um receptor passivo cujo papel se reserva à ar-
mazenagem das informações a ele apresentadas [Mizukami 1986]. Tal metodolo-
gia tem se mostrado ineficaz, visto que o crescimento da produção de informação
intrı́nseco a ela conduz ao aumento dos currı́culos pedagógicos e do tempo de per-
manência em sala de aula, porém com reduzido compromisso com a didática aplicada
[Donoso-Garcia and Torres 2007].
No âmbito da Engenharia, a questionabilidade desse método se torna mais evi-
dente, em razão da necessidade da absorção de conceitos e integração de conhecimentos,
204
embasada na concepção de atributos técnicos e habilidades ético-sociais, que auxiliam na

compreensão dos impactos das soluções da engenharia na sociedade. Nesse sentido, a
adoção de posturas não tradicionais de ensino vem crescendo continuamente, de modo a
suprir a notória deficiência da abordagem tradicionalista [Fink 2002].
Em cursos de graduação em Engenharia, nota-se, corriqueiramente, em disciplinas
que possuem ênfase em aplicações práticas, a carência de atividades laboratoriais que
não se limitem a realização de simulações ou testes virtuais, ou experimentos fastidiosos
incongruentes à realidade de um engenheiro. Tal cenário, aliado ao fato de que a carga
horária dedicada às aulas teóricas é muito superior a das aulas práticas, tende a suscitar
desinteresse, por parte dos alunos, na permanência do curso, o que gera elevadas taxas de
evasão nesses cursos [Hoed 2017].
Nesse contexto, a introdução de projetos de protótipos reais torna-se uma alter-
nativa de ensino-aprendizagem capaz de proporcionar ao educando o alicerce exigido
pelo panorama tecnológico contemporâneo. O norteamento da concepção desses pro-
jetos didáticos, na Engenharia, dá-se através de alguns tópicos básicos, elucidados em
[Cavin et al. 2003]. Dentre eles, destacam-se:
• Manter sólida participação de atividades laboratoriais na formação acadêmica;

• Enfatizar a importância da ética profissional;
• Instigar um amor pelo aprendizado em Engenharia;
• Reconhecer o valor dos estágios profissionais;
• Valorizar o esforço de professores e orientadores.
Portanto, atenta-se ao fato de que, dada a devida observância aos pontos ante-
riormente elencados, o desenvolvimento de projetos torna o ensino mais envolvente e
dinâmico para o aluno, visto que a ele é incumbida uma participação ativa no processo
de aprendizado, que sedimenta os conhecimentos adquiridos e valoriza as habilidades de
trabalho em equipe, criatividade, análise crı́tica e engajamento pessoal.
Neste artigo, retrata-se um estudo de caso referente a disciplina de Eletrônica Digi-
tal, ministrada para o curso de graduação em Engenharia de Computação da Universidade
Federal do Ceará no Campus de Sobral. Aos alunos, no decorrer do perı́odo letivo, foi
imputada a construção de projetos de sistemas eletrônicos, a partir da utilização de lógica
digital, a fim de otimizar a experiência dos mesmos na condução prática da disciplina.
2. A Eletrônica no Contexto Educacional

A Eletrônica Digital pode ser concebida como uma disciplina que insere o aluno do
curso de Engenharia em um ambiente de desenvolvimento de circuitos eletrônicos, so-
bretudo através de práticas laboratoriais. Nessa disciplina são apresentados os prin-
cipais conceitos referentes a lógica digital e a utilização da mesma na construção
de circuitos combinacionais e sequenciais, e na elaboração de sistemas eletrônicos
[Pró-Reitoria do Curso de Engenharia de Computação 2006].
Na grande maioria dos cursos de graduação em Engenharia, a organização da
grade curricular dos primeiros semestres do curso opta pela formação teórica em detri-
mento da prática, como no caso das disciplinas de Cálculo e Fı́sica. Nesse contexto, o
primeiro contato do aluno com atividades práticas ocorre por meio da Eletrônica Digital,
205
isto é, após percorrer toda a base teórica daquelas disciplinas iniciais, o estudante é inse-
rido em um ambiente integralmente novo, na qual se supõe a capacidade de manipulação
de componentes e equipamentos não tão intuitivos.
Nessa circunstância, é natural que haja certa dificuldade no manejo de determina-
dos dispositivos eletrônicos por parte do aluno, em virtude da pouca, ou nenhuma, fami-
liaridade com tais instrumentos. Desse modo, é cada vez mais indispensável a adoção de
estratégias pedagógicas que auxiliem na condução prática da disciplina, a fim de atenuar
as dificuldades enfrentadas pelos estudantes e, portanto, otimizar a experiência de apren-
dizado do conteúdo, pois, apesar da simulação de circuitos digitais ser inserida como fer-
ramenta de apoio ao ensino, ela sozinha não é eficaz [Amaral and da Silva Martins 2012].
O programa curricular da disciplina é bastante vasto, compreendendo diversos
conceitos de circuitos eletrônicos importantes para as aplicações cotidianas, de modo
a possibilitar a utilização dos sistemas digitais de forma ampla. Nesse sentido, a pro-
posta da disciplina é introduzir tais conceitos ao estudante, de maneira que lhe seja
possı́vel cumprir os requisitos de projeto, concepção, análise e construção desses circuitos
[Pró-Reitoria do Curso de Engenharia de Computação 2006].
2.1. Metodologia de Ensino e Avaliação da Disciplina

A disciplina de Eletrônica Digital, no curso de Engenharia de Computação da UFC -
Campus de Sobral, tem sido ofertada em caráter obrigatório, com disponibilidade de, pelo
menos, 2 turmas, cada qual com capacidade entre 12 e 14 alunos. A carga horária total
exigida é de 6 créditos, que correspondem a 96 horas semestrais, com 64 horas destinadas
a aulas teóricas e 32 horas correspondentes a aulas práticas.
À teoria, é dedicada fundamental atenção, em razão da importância da mesma
para a realização das atividades práticas. Essa teoria é ensinada com base na bibliografia
adotada pelo curso.
A realização das aulas práticas se dá através da construção de sistemas eletrônicos,
com base nos conceitos abordados nas aulas teóricas. Para tanto, utilizam-se banca-
das, compostas por equipes de três estudantes, que possuem componentes essenciais à
confecção das atividades, em suma, uma mesa digital didática, computador com acesso
ao software de simulação Proteus [LabCenter 2017], fontes de alimentação, circuitos in-
tegrados (CIs) diversos e uma variedade de outros componentes eletrônicos.
Além das atividades mencionadas, é proposta a montagem de dois projetos de
protótipos de sistemas eletrônicos reais. Em duplas, os alunos devem pesquisar e confec-
cionar um projeto que possua aplicações relevantes. Essa confecção é feita a partir dos
conhecimentos adquiridos ao longo do perı́odo letivo, e envolve as etapas de simulação
no software Proteus e montagem em protoboard e, facultativamente, em placa de circuito
impressa. Exige-se também, somente para o segundo projeto, a elaboração de um re-
latório técnico e uma apresentação em mı́dia digital que descreva a motivação, objetivo,
fundamentação teórica e o princı́pio de funcionamento do sistema construı́do.
O desempenho dos alunos ao decorrer da disciplina é avaliado com base nos
conteúdos teóricos abordados e no desenvolvimento das atividades práticas propostas,
bem como com a análise dos resultados dos projetos realizados.
A avaliação dos projetos é realizada por dois métodos distintos, um referente
206
a cada projeto. Para o primeiro, realiza-se uma avaliação simples, que consta de
apresentação oral acerca do funcionamento do sistema construı́do, com enfoque nos
componentes eletrônicos utilizados. Já com relação ao segundo projeto, utiliza-se uma
avaliação mais rigorosa, baseada nos seguintes quesitos:
• Apresentação do projeto (utilização do tempo, organização de mı́dia digital, cla-

reza, objetividade, conhecimento sobre o assunto abordado);
• Ideia de implementação do protótipo;
• Teste e funcionamento do sistema;
• Elaboração do relatório.
A partir da determinação dessas notas, é possı́vel calcular a média final do aluno

através de um cálculo de média ponderada. Nesse sentido, são necessárias duas notas
médias parciais (MPs). A MP1 é composta pela média da primeira etapa, com peso igual
a 70%, e a nota do primeiro projeto, que equivale a 30%. A MP2 é formada pela média
da segunda etapa e a média do segundo projeto, ambas correspondendo a 50% da média
parcial. Por fim, a nota final é a média aritmética dessas duas MPs.
Nesse contexto, a metodologia de avaliação empregada se propõe a simular, o
mais fielmente possı́vel, um ambiente de trabalho correspondente à realidade de um en-
genheiro, tendo em vista o comprometimento do discente na execução dos projetos.
3. Projetos Eletrônicos
Nesta seção, são listados três projetos desenvolvidos durante a disciplina de eletrônica
digital nos anos de 2016 e 2017.
3.1. Sistema para Controle de Fluxo de Veı́culos
O trabalho em questão teve por finalidade a construção de um sistema de cancela

eletrônica que visava ao controle do acesso de tráfego de automotores. Para o desen-
volvimento deste projeto, foram utilizados elementos da teoria de circuitos sequenciais,
tais como flip-flops, contadores e decodificadores. Durante a produção do projeto, os alu-
nos elaboraram uma placa de circuito impresso e que teve por finalidade controlar todas
as entradas e saı́das do sistema digital. Este projeto pode ser observado na Figura 1. Na
produção da placa, foram utilizados CI’s da famı́lia 74, osciladores 555, dentre outros
componentes eletrônicos.
3.2. Sistema para Controle de Motor de Passo
O projeto “Controle de Motor de Passo”, implementado a partir de lógica digital, foi

desenvolvido com o intuito de reger os passos de um motor através das bobinas que o
compõem. O funcionamento do sistema depende de elementos eletrônicos tı́picos, obtidos
a partir dos circuitos integrados 555 e da famı́lia 74, especificamente, oscilador, contador e
decodificador. A partir do embasamento teórico adquirido nas aulas, foi possı́vel entender
o funcionamento do sistema, bem como os pormenores envolvidos na sua montagem,
de modo a possibilitar o entendimento da importância da referida atividade prática. O
circuito montado é ilustrado na Figura 2.
207
Figura 1. Maquete elaborada pelos autores do projeto.
Figura 2. Circuito elaborado pelos autores do projeto.
3.3. Sistema para Controle de Estacionamentos

O trabalho “Sistema para Organização de Estacionamentos”, embasado na teoria da lógica
de circuitos combinacionais e sequenciais, propôs a construção de um sistema para otimi-
zar a experiência de uso dos clientes de estabelecimentos comerciais que oferecem serviço
de estacionamento. Por meio da utilização de componentes, como circuitos integrados da
famı́lia 74, decodificadores e displays, os alunos vivenciaram a aplicação prática de con-
ceitos aprendidos em sala de aula para a solução de problemas reais, presentes no contexto
social em que estão inseridos. O protótipo desenvolvido pode ser observado na Figura 3.
4. Impacto Didático
Conforme definido pelas Diretrizes Curriculares Nacionais para o ensino de graduação
em Engenharia, alguns princı́pios fundamentais são essenciais para a formação de um
engenheiro, entre os quais ressalva-se a necessidade de estı́mulo a atuação crı́tica e criativa
na identificação e resolução de problemas [Brasil 2002]. Nesse sentido, os métodos de
ensino atualmente empregados não conseguem suprir tais necessidades.
A abordagem apresentada neste trabalho se propõe a derrubar a barreira alicerçada
sobre o método tradicionalista, que imputa ao aluno um papel passivo no processo de
ensino. Dessa forma, torna-se possı́vel uma formação acadêmica na qual o indivı́duo é
capaz de produzir seu próprio conhecimento a partir de experiências que simulam o real
ambiente de atuação em que o futuro profissional estará envolvido.
208
Figura 3. Protótipo construı́do pelos autores do projeto.
O impacto da utilização da abordagem do ensino orientado a projetos se reflete

diretamente no desempenho acadêmico dos estudantes, pois, por meio dessa metodo-
logia, atribui-se ao mesmo o papel de protagonista no seu próprio processo de ensino-
-aprendizagem. Além disso, a implementação desse sistema de atividades estimula o
desenvolvimento de habilidades notáveis em um engenheiro, tais como, capacidade de
trabalhar em equipe, desenvolvimento do pensamento crı́tico, fortalecimento da habili-
dade de comunicação entre companheiros e incitação a criação de uma postura ética no
tratamento dos colegas.
5. Resultados
A abordagem do ensino orientado a projetos somente passou a ser adotada a partir das tur-
mas do segundo semestre de 2015, após a realização de uma pesquisa sobre a metodologia
de ensino da disciplina de eletrônica digital. Os resultados desta pesquisa mostraram o in-
teresse dos alunos na parte de desenvolvimento de projetos como um método mais eficaz
de ensino e aprendizagem de eletrônica.
A pesquisa foi destinada, exclusivamente, a alunos que cursaram (75,8%) ou es-
tavam cursando (24,2%) a disciplina de Eletrônica Digital até encerramento da pesquisa,
com um total de 91 alunos entrevistados. Os resultados dessa pesquisa podem ser anali-
sados nas Figuras 4 e 5.
3,3%
13,2%
25,3% Nenhuma
Pouco/Baixo
Médio/Regular
27,5%
Muito/Alto
Muitíssimo/Altíssimo
30,7%
Figura 4. Você teve/tem alguma dificuldade nas aulas práticas da disciplina?
209
2,2%
16,5%
Nenhuma
Pouco/Baixo
Médio/Regular
Muito/Alto
81,3% Muitíssimo/Altíssimo
Figura 5. Você acredita que o desenvolvimento de projetos ao longo da disciplina

de Eletrônica Digital auxilia no aprendizado?
Através da análise da Figura 4, percebe-se que os alunos apresentaram uma certa

dificuldade nas aulas práticas. Já pela análise da Figura 5, nota-se um elevado percentual
de alunos (81,3%) que acreditam que o desenvolvimento de projetos auxilia no aprendi-
zado da disciplina de eletrônica digital.
Abstração excessiva da bancada

digital utilizada nas aulas
Ausência de contato anterior
com eletrônica
Dificuldade com conteúdo
teórico
Dificuldade de passar o circuito da
bancada digital para a protoboard
Dificuldade de reconhecer
componentes danificados
Falta de material didático de apoio
Montagem dos Circuitos
0 10 20 30 40 50 60
Número de Alunos
Figura 6. Principais dificuldades dos alunos durante as aulas práticas.
Na pesquisa realizada também foi perguntado aos alunos quais as principais difi-
culdades durante as aulas práticas de eletrônica digital. As principais dificuldades listadas
pelos alunos podem ser verificadas na Figura 6. Cada aluno poderia identificar até três
principais dificuldades. Pela análise da Figura 6, percebe-se que as três principais maiores
dificuldades dos alunos são Montagem dos Circuitos, Ausência de contato anterior com
eletrônica e Dificuldade de reconhecer componentes danificados.
Desta forma, nota-se que o desenvolvimento de projetos durante a disciplina de
eletrônica digital é uma maneira satisfatória de solucionar as três principais dificuldades
listadas pelos alunos. O estudante passa a ter maior contato com montagem de circuitos,
entender com maior excelência o funcionamento dos CIs e identificar mais facilmente os
210
problemas comuns de cada circuito integrado.
6. Conclusões
A abordagem do ensino orientado a projetos busca equilibrar teoria e prática por meio
do desenvolvimento de protótipos de sistemas eletrônicos reais. Portanto, por meio desse
método, pretende-se conferir ao estudante a carga teórica necessária para o desenvolvi-
mento desses projetos, de tal forma que não seja preciso memorização de conceitos, mas
sim a compreensão dos mesmos.
A disciplina de Eletrônica Digital é essencial na formação acadêmica de um enge-
nheiro, visto que é, frequentemente, o primeiro contado que o aluno tem com atividades
práticas. Por ser de caráter fundamentalmente tecnológico, tal disciplina possui conteúdo
curricular extenso, que compreende conceitos que permeiam desde a criação de tabelas-
-verdade até a implementação de circuitos.
Nesse contexto, a implementação da abordagem descrita foi executada de tal
forma que semelhante metodologia pode ser aplicada em diferentes áreas do conheci-
mento, especialmente nas de cunho teórico-prático, de forma que seja possı́vel envolver
intensamente os discentes na jornada da Engenharia.
Referências
Amaral, A. M. and da Silva Martins, C. A. (2012). Método de aprendizado de eletrônica
digital baseado em projeto e implementação de sistemas dedicados em hardware.
Brasil (2002). Resolução cne/ces 11/2002, de 11 de março de 2002. Institui
as diretrizes curriculares do curso de graduação em engenharia. Diário Oficial
[da] República Federativa do Brasil, Brası́lia, DF, 11 mar. 2002. Disponı́vel em:
http://portal.mec.gov.br/cne/arquivos/pdf/CES112002.pdf. Acesso em: 21 jul. 2017.
Cavin, R., Joyner, W. H., and Wiggins, V. C. (2003). A semiconductor industry perspec-
tive on future directions in ece education. IEEE Transactions on Education, 46(4):463–
466.
Donoso-Garcia, P. F. and Torres, L. (2007). Ensino orientado ao projeto desafio: uma
experiência para o ensino de controle, instrumentação e eletrônica. In CONGRESSO
BRASILEIRO DE EDUCAÇÃO EM ENGENHARIA–COBENGE, volume 35.
Fink, F. K. (2002). Problem-based learning in engineering education: a catalyst for re-
gional industrial development. World Transactions on Engineering and Technology
Education, 1(1):29–32.
Hoed, R. M. (2017). Análise da evasão em cursos superiores: o caso da evasão em cursos
superiores da área de computação.
LabCenter (2017). Proteus pcb design and simulation software. Disponı́vel em:
https://www.labcenter.com/. Acesso em: 21 jul. 2017.
Mizukami, M. d. G. N. (1986). Ensino: as abordagens do processo. Editora Pedagógica
e Universitária.
Pró-Reitoria do Curso de Engenharia de Computação, C. (2006). Programa da disciplina
de eletrônica digital. Universidade Federal do Ceará - Campus Sobral.
211
Sistema IoT versátil para monitoramento em nuvem de

sensores
Ayrton A. M. Silva, Sandro C. S. Jucá, Leonardo S. Costa, Paulo M. M. Silva
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE)

{ayrton.alexmds, sandro.juca}@gmail.com, {leonardo.costa,
mateus.moura}@ppgcc.ifce.edu.br
Abstract. In this age of automation, the acquisition and monitoring of sensor

data is essential to ensure the correct condition and functioning of machines
and systems without need of manual verifications. This paper describes the
development, assembling and configuration of a versatile system for sensor data
acquisition and cloud based monitoring. In the project two sensors are used,
but the system can be extended to acquire data from up to six sensors. The
data acquired is read and processed by a microcontrolled board and sent to
a Raspberry Pi, which sends this information to the Internet, where it can be
accessed through a PHP system where the data is available as charts.
Resumo. Nesta era de automação, a aquisição e o monitoramento de dados de

sensores são essenciais para assegurar a condição e funcionamento correto de
máquinas e sistemas sem necessidade de verificações manuais. Este artigo de-
screve o desenvolvimento, montagem e configuração de um sistema versátil para
a aquisição e monitoramento baseado em nuvem de dados de sensores. No pro-
jeto são utilizados dois sensores, mas o sistema pode ser estendido para recolher
dados de até seis sensores. Os dados são lidos e processados por uma placa mi-
crocontrolada e enviados para um Raspberry Pi, que envia essas informações
para a Internet, de onde podem ser acessadas através de um sistema PHP que
disponibiliza essas informações na forma de gráficos.
1. Introdução
A Internet das Coisas (IoT) é um tema que está se tornando cada vez mais popular em
todo o mundo. Trata-se de um conceito que não só tem o potencial de influenciar nossas
vidas, como também nossa forma de trabalhar [Morgan 2014]. A IoT é um assunto muito
abrangente, mas que de forma simplificada significa conectar dispositivos (ou até mesmo
parte de dispositivos) à Internet e permitir a comunicação entre eles.
Nos últimos anos tem-se visto um crescente desenvolvimento de sistemas de
aquisição e tratamento digital de sinais [SMAR 2017], e estimativas indicam que até
2020 teremos cerca de 50 bilhões de dispositivos conectados à internet [Cisco 2011]. O
monitoramento de sensores é essencial em inúmeras áreas, pois ele é o que possibilita a
automatização de processos delicados que precisam de monitoramento constante. Con-
tudo, os sistemas de monitoramento atuais geralmente lidam com poucos sensores, um
problema que este projeto visa tratar.
O presente trabalho tem como objetivo demonstrar o desenvolvimento de um sis-
tema versátil de aquisição de dados para persistência em nuvem e monitoramento remoto.
212
Para isso, serão utilizados uma placa microcontrolada SanUSB (com o microcontrolador
PIC18F2550) e um Raspberry Pi. Os dados serão persistidos na plataforma ThingSpeak
e o monitoramento será realizado através de um sistema desenvolvido em PHP, onde as
informações estarão disponı́veis na forma de gráficos. Por se tratar de um sistema uni-
versal para sensores AD, o projeto pode ser facilmente estendido para outras linhas de
pesquisa relacionadas.
Nas próximas seções serão abordados os trabalhos relacionados, os recursos uti-
lizados para o desenvolvimento do sistema e seu funcionamento. Por fim, serão discutido
os resultados, as considerações finais, sugestões e melhorias para trabalhos futuros.
Foram encontrados outros trabalhos com objetivos similares, envolvendo a aquisição e
monitoramento de dados de sensores para propósitos especı́ficos ou genéricos.
[Andreola et al. 2016] trata da aquisição de dados de sensores para o estudo da
viabilidade de instalação de turbinas eólicas em um determinado local. É utilizado um
microcontrolador da famı́lia PIC, que armazena estes dados em um cartão SD durante o
perı́odo de um ano.
[GALANTE and GARCIA 2014] trata de um sistema para aquisição e
visualização de dados provenientes de um sensor substituı́vel . É baseado em Arduino, e
também armazena os dados em um cartão SD.
[Khera et al. 2016] construiu um sistema de aquisição de dados para monitora-
mento em tempo real de módulos fotovoltaicos e reposicionamento dos mesmos, baseado
na luz solar captada. O sistema é baseado em Arduino e grava os dados obtidos tanto
em uma unidade de armazenamento local como também na plataforma ThingSpeak, por
meio de um modem GSM.
[Mutha et al. 2016] propôs um sistema para a aquisição de dados de diversos sen-
sores relacionados ao ambiente (temperatura, umidade, etc), baseado em Arduino. Os
dados coletados foram armazenados na nuvem, no servidor de IoT Carriots.
Os trabalhos acima apresentam limitações tanto na quantidade de sensores (com
o máximo de 4 em [Mutha et al. 2016]) e na forma de armazenamento (dados na nuvem
são mais acessı́veis que dados salvos localmente, e a plataforma Carriots não é totalmente
gratuita). Este documento propõe um protótipo mais versátil, que além de aceitar mais
sensores pode utilizar locais de armazenamento alternativos e ter seus sensores alterados
com mudanças mı́nimas no código.
3. Recursos utilizados
Esta seção aborda os recursos utilizados no desenvolvimento do sistema: a placa mi-
crocontrolada SanUSB, o Raspberry Pi, os sensores, a ferramenta SanUSB, a biblioteca
WiringPi para utilização do RPi, a ferramenta curl para envio dos dados, a biblioteca
FusionCharts para geração dos gráficos PHP/JavaScript e a plataforma ThingSpeak, uti-
lizada para o armazenamento dos dados.
3.1. Placa microcontrolada SanUSB, Raspberry Pi, e sensores utilizados
O Raspberry Pi (RPi) é um computador de tamanho e custo reduzidos fabricado pela
Fundação Raspberry Pi, que apesar de seu tamanho reduzido possui recursos e funcional-
213
idades de um computador convencional. Neste projeto, a função do RPi será a de receber

os dados da placa microcontrolada e enviá-los para a plataforma ThingSpeak para ar-
mazenamento. Isso será feito com a utilização de um software escrito na linguagem C,
em conjunto com as bibliotecas WiringPi e curl. Como qualquer outro computador de
propósito geral, o RPi possui um sistema operacional instalado, neste caso o Raspbian1 ,
um sistema operacional gratuito baseado em Debian otimizado para o hardware do RPi.
Embora o RPi seja uma ótima ferramenta de aprendizado, tão útil quanto um com-
putador comum para a maioria das tarefas e amplamente utilizado em projetos IoT, ele não
possui um conversor analógico/digital. Tal conversor — que não está presente na maio-
ria dos computadores comuns — é necessário para a leitura de dados de sensores que
informam os dados monitorados por meio de valores analógicos. Por isso, para a leitura
dos dados dos sensores, será utilizado o conversor AD do microcontrolador PIC18F2550.
Depois, o microcontrolador enviará os dados convertidos para o RPi via comunicação
serial.
Outra vantagem do uso do RPi é a possibilidade de extensões ao projeto (como
a implantação de atuadores que alterem o estado do ambiente) sem a necessidade de se
alterar o sistema de aquisição.
Um microcontrolador é um sistema computacional completo, no qual estão in-
cluı́dos internamente uma CPU, memórias RAM, flash e EEPROM, pinos de I/O, além
de outros periféricos internos [Jucá and Pereira 2017]. O microcontrolador PIC18F2550
foi escolhido para este projeto por sua sinergia com a ferramenta SanUSB (explicada em
3.2). Além disso, o microcontrolador utilizado oferece as vantagens da famı́lia PIC18,
como alta performance computacional por um valor econômico e durabilidade adicional,
e memória de programa flash aprimorada [Microchip 2006].
Neste projeto, são utilizados dois sensores: temperatura, e luminosidade. Eles
serão alimentados pelo RPi e cada um será lido por uma das portas analógicas da placa.
Até seis sensores (limite explicado em 3.4) podem ser utilizados simultaneamente com
poucas adições ao código fonte.
3.2. Ferramenta SanUSB

A transferência de programas para os microcontroladores é normalmente efetuada através
de um hardware de gravação especı́fico [Jucá et al. 2009]. Para facilitar essa transferência
consideravelmente (motivo por trás da escolha deste modelo especı́fico de microcontro-
lador), agilizar o processo de desenvolvimento do projeto e integrar o PIC ao RPi de
forma eficiente, foi utilizada uma placa microcontrolada SanUSB. O objetivo desta placa
é facilitar o processo de gravação do microcontrolador, se comunicando com a porta USB
do computador para realizar a gravação e alimentação, além de fornecer diversas out-
ras funções úteis ao uso do microcontrolador. Um esquema do circuito da placa está
disponı́vel em [Jucá et al. 2009].
Após a montagem e configuração inicial da placa microcontrolada, é necessária
a utilização do aplicativo SanUSB para a gravação do código fonte no microcontrolador.
Antes da gravação, o código é compilado de C para assembly (linguagem de máquina,
necessária para execução no microcontrolador). O aplicativo SanUSB pode ser utilizado
1
https://www.raspbian.org/
214
tanto via interface gráfica, como via linhas de comando (o que possibilita a gravação
do microcontrolador diretamente pelo Raspberry Pi, forma utilizada neste projeto). A
eficácia da utilização conjunta do microcontrolador com o RPi está demonstrada em di-
versos artigos, como [Queiroz et al. 2016].
3.3. Bibliotecas utilizadas

WiringPi2 é uma biblioteca de acesso GPIO (General-purpose input/output, ou pino
genérico de entrada/saı́da) escrita em C para o processador BCM2835 utilizado no Rasp-
berry Pi. Embora ela seja escrita em C — que é a linguagem utilizada no desenvolvimento
do software de aquisição de dados — esta biblioteca é utilizável em diversas outras lin-
guagens. Neste projeto, a biblioteca WiringPi é utilizada para a configuração, leitura e
escrita de dados nas portas GPIO.
Embora o RPi neste projeto já esteja conectado à rede via cabo Ethernet, o sis-
tema de aquisição precisa de um meio para enviar as informações coletadas à plataforma
ThingSpeak. Para este fim é utilizada a ferramenta/biblioteca de transferência de dados
curl3 , um software livre e de código aberto. A curl é utilizada em linhas de comando
ou códigos para transferir dados, e é utilizada nas transferências de dados de milhares de
aplicativos.
Para a geração dos gráficos do sistema de monitoramento, foi utilizada a biblioteca
FusionCharts. Baseada em JavaScript, ela também possui um plugin para uso com PHP e
é capaz de gerar vários tipos de gráficos 2D, 3D e até mesmo mapas com base nos dados
definidos dinamicamente. Ela foi escolhida para este projeto por sua facilidade de apren-
dizado e de utilização, com diversos modelos de gráficos que podem ser selecionados pelo
usuário a nı́vel de implementação.
3.4. ThingSpeak e sistema PHP

A plataforma de armazenamento escolhida para utilização neste projeto é a ThingS-
peak.com4 . ThingSpeak é uma plataforma IoT que auxilia o usuário a armazenar da-
dos coletados de sensores na nuvem e desenvolver aplicações IoT. A plataforma fun-
ciona como um sistema de “canais” que atuam como as tabelas de um banco de dados.
Cada canal possui um máximo de oito campos para armazenamento, e dois são configu-
rados neste projeto para armazenar a data e a hora do envio de cada leitura, totalizando
seis campos para uso dos sensores. Os dados enviados pelo RPi serão armazenados na
plataforma do ThingSpeak com o intuito de posteriormente serem acessados pelo sistema
PHP atráves de uma chave compartilhada.
Para o monitoramento dos dados, foi desenvolvido um sistema em PHP que acessa
os dados do ThingSpeak e os converte em gráficos. Este sistema de monitoramento pre-
cisa estar instalado em um servidor acessı́vel, para que os gráficos possam ser sempre
consultados caso necessário. O sistema tem um layout amigável, e utiliza um sistema de
controle de usuários baseado em MySQL.
Contudo, o sistema de monitoramento pode ser substituı́do por algo feito pelo
próprio usuário desde que use a API do ThingSpeak para acessar os dados corretamente.
2
http://wiringpi.com/
3
https://curl.haxx.se/
4
https://www.mathworks.com/help/thingspeak/
215
No projeto é utilizada a conta de um dos autores para os testes, mas qualquer usuário pode
utilizar a sua própria. No momento da criação do canal são geradas duas chaves de API
(leitura e escrita) que podem ser utilizadas em requisições do usuário. Requisições de
leitura retornam os dados do canal em um JSON de fácil compreensão. Uma vantagem
de se utilizar o ThingSpeak ao invés de outra plataforma (como o Carriots) é que todos os
seus serviços são gratuitos. Ainda assim, o uso do ThingSpeak não é obrigatório. Ele pode
ser substituı́do por outra plataforma, ou até mesmo por um servidor local (removendo a
dependência de uma empresa), com mudanças mı́nimas ao código.
4. Funcionamento do Sistema
O projeto é dividido em duas partes (Figura 1): o sistema embarcado Linux para a
aquisição dos dados dos sensores e um sistema PHP para o monitoramento online. O
sistema embarcado é composto pelo PIC (b, lado esquerdo), pelo RPi (b, lado direito) e
pelos sensores utilizados (a), conectados com o auxı́lio de um protoboard e um conjunto
de fios. O sistema online de monitoramento (d) possui uma interface amigável para a con-
sulta dos dados armazenados, além de uma funcionalidade de controle de acesso, onde os
usuários autorizados são armazenados em um banco de dados local.
Figura 1. Esquema do projeto
A alimentação dos circuitos dos sensores é provida pelo RPi. A entrada de leitura
é conectada à uma porta analógica da placa microcontrolada. A Figura 2 mostra o sistema
em funcionamento: placa microcontrolada (A), Raspberry Pi (B), sensores — temperatura
e luminosidade — (C) e LEDs (D).
Figura 2. Sistema completo montado com protoboard
O PIC realiza a leitura da tensão fornecida pelos sensores e as converte para um

número entre 0 e 1023 (10 bits), onde 1023 corresponde ao valor máximo que pode ser
216
lido. Ele está conectado ao RPi via cabo USB para alimentação e gravação, e via serial
(TX e RX) para transferência de dados.
O PIC realiza leituras de cada sensor conectado durante o intervalo de um minuto,
e calcula uma média para cada um deles para eliminar ruı́do e dar estabilidade às leituras.
Após cada leitura, ele usa a conexão serial estabelecida para enviar os dados das leituras
de cada sensor delimitadas por um caractere especial predefinido no código.
Ao receber todas as leituras do minuto, o RPi utiliza funções da biblioteca curl
para enviá-las para um canal do ThingSpeak por meio de uma requisição do tipo POST.
Caso o envio seja feito com sucesso o LED verde é aceso. Caso o envio falhe, o LED
vermelho é aceso e os dados cujo envio falhou são salvos na unidade de armazenamento
do RPi. Estes dados não podem ser automaticamente enviados após a recuperação da
conexão, mas podem ser inseridos em requisições novas e enviados manualmente ao
canal. As Figuras 3 e 4 mostram fluxogramas de ambas as etapas da aplicação.
O sistema PHP desenvolvido tem como finalidade principal a visualização dos
dados adquiridos em forma de gráficos. Além disso, ele possui um controle de acesso às
informações. Os dados podem ser consultados por meio de filtros, onde o usuário pode
informar quais os dias e os horários que ele pretende verificar, e o sistema dá uma opção
de resumir esses dados, calculando uma média dos dados de determinados perı́odos de
tempo.
Figura 3. Fluxograma do algoritmo executado no PIC
217
Figura 4. Fluxograma do algoritmo executado no RPi
5. Resultados
Um dos grandes diferenciais do projeto descrito neste artigo em comparação à outros tra-
balhos encontrados é a quantidade de sensores utilizados (até seis com poucas adições ao
código, podendo se estender até dez — quantidade de portas analógicas na placa micro-
controlada — com adaptações mais extensas). Além disso, o trabalho em conjunto com
o Raspberry Pi possibilita a adição de funcionalidades extras por parte do usuário, além
de uma divisão de responsabilidades entre o PIC e o RPi, tornando mais simples o código
gravado no microcontrolador.
Os sistemas operam da forma esperada, e capturas de tela do sis-
tema de monitoramento estão disponı́veis em uma pasta compartilhada no Drop-
box [Silva and Costa 2017a]. Além disso, foi adicionado um vı́deo no youtube
[Silva and Costa 2017b] do sistema de aquisição em funcionamento, e os códigos de-
senvolvidos estão disponı́veis no GitHub [Silva and Costa 2017c].
6. Considerações finais
Por meio do estudo dos conceitos e de trabalhos similares o objetivo deste projeto foi
atingido com êxito, com todas as partes do sistema funcionando da maneira esperada.
O projeto possui grande potencial de extensão para utilização com uma gama
de sensores, pois uma boa quantidade deles pode ser lida por meio do PIC e seus da-
dos analógicos convertidos para valores digitais, com necessidade de adições mı́nimas ao
código.
E é justamente este potencial de extensão que traz ideias para projetos futuros,
como um sistema que utilize os dados coletados para tomada de decisões, ou um sistema
que automatize o processo de adição/remoção de sensores do sistema de aquisição por
meio de geração de código, tornando as adaptações mais dinâmicas.
218
Referências
Andreola, A. T., Senter, M. J. D., Todero, E. L., and Cardoso, G. (2016). Low cost data
acquisition system for wind prospecting. In 2016 12th IEEE International Conference
on Industry Applications (INDUSCON), pages 1–6.
Cisco (2011). The Internet of Things. http://www.cisco.com/c/dam/en -
us/about/ac79/docs/innov/IoT IBSG 0411FINAL.pdf. Acesso em: 23/07/2017.
GALANTE, A. C. and GARCIA, R. F. (2014). Sistema de aquisição de dados de sen-
sores de baixo custo baseado no Arduı́no. In Congresso Brasileiro de Agricultura de
Precisão, volume 6.
Jucá, S. C., Carvalho, P. C., and Brito, F. (2009). SANUSB: software educacional para o
ensino da tecnologia de microcontroladores. Ciências & Cognição, 14(3).
Jucá, S. C. S. and Pereira, R. I. S. (2017). Aplicações Práticas de Microcontroladores
utilizando Software Livre. Imprima, 1 edition.
Khera, N., Singh, S., Sharma, A., and Kumar, S. (2016). Development of photovoltaic
module tracking and web based data acquisition system. In 2016 2nd International
Conference on Applied and Theoretical Computing and Communication Technology
(iCATccT), pages 100–103.
Microchip (2006). PIC18F2455/2550/4455/4550 Data Sheet.
http://ww1.microchip.com/downloads/en/devicedoc/39632c.pdf. Acesso em:
23/07/2017.
Morgan, J. (2014). A Simple Explanation Of ’The Internet Of Things’.
http://www.forbes.com/sites/jacobmorgan/2014/05/13/simple-explanation-internet-
things-that-anyone-can-understand/. Acesso em: 23/07/2017.
Mutha, V. R., Kumar, N., and Pareek, P. (2016). Real time standalone data acquisition
system for environmental data. In 2016 IEEE 1st International Conference on Power
Electronics, Intelligent Control and Energy Systems (ICPEICES), pages 1–4.
Queiroz, T. A. F., Dias, D. L., Araújo, P. H. M., Figueiredo, R. P., and Jucá, S. C. S.
(2016). Sistema Embarcado Linux para Análise de Sensores de Temperatura DHT11
e LM35. ERIPI 2016.
Silva, A. A. M. and Costa, L. S. (2017a). Disponı́vel em:
https://www.dropbox.com/sh/zrkpg4tmwsapd93/AABvs7gp9UqKC0dinsTIWUXLa.
Acesso em: 28/07/2017.
Silva, A. A. M. and Costa, L. S. (2017b). Disponı́vel em:
https://www.youtube.com/watch?v=j68Pd2bpm3M. Acesso em: 28/07/2017.
Silva, A. A. M. and Costa, L. S. (2017c). Disponı́vel em:
https://github.com/Ayrtonms/sistema-de-aquisicao-e-monitoramento. Acesso em:
28/07/2017.
SMAR (2017). Sistemas de Supervisão e Aquisição de Dados.
http://www.smar.com/brasil/artigo-tecnico/sistemas-de-supervisao-e-aquisicao-
de-dados. Acesso em: 23/07/2017.
219
Diagnóstico Automático do Glaucoma usando Convolutional

Neural Network e Descritores de Textura
Marcos Vinı́cius dos Santos Ferreira1 , Antônio Oseas de C. Filho1 , Alcilene D. de

Sousa 1 Patricia Vieira da S. Barros1 , Patrı́cia Medyna L. de L. Drumond1
1
Campus Senador Helvı́dio Nunes de Barros – Universidade Federal do Piauı́ (UFPI)
{ferreiraviniciussdi,antoniooseas,alcileneluzsousa,petibarrosthe}@gmail.com
[email protected]
Abstract. Glaucoma is an asymptomatic disease caused by optic nerve damage

as a result of increased intraocular pressure, which, being diagnosed early, has
a greater chance of controlling its progress. It is a major problem in the glo-
bal health as a cause of blindness, only losing to cataract. This study presents
the development of a method for the automatic detection of Glaucoma in retinal
images using the neural network Convolutional Neural Network. The metho-
dology used in the study was image acquisition, neural network training with
retinal images, extraction of blood vessels, and extraction of texture characte-
ristics. Finally, the results were validated to evaluate if the proposed method
was efficient, obtaining 98% accuracy, 98% sensitivity and 96% specificity.
Resumo. O Glaucoma é uma doença assintomática causada por lesão do nervo

óptico em decorrência do aumento da pressão intra-ocular, que sendo diagnos-
ticada cedo há maior chance de controlar seu avanço. É um grande problema na
saúde mundial como causa de cegueira, perdendo apenas para a catarata. Este
estudo apresenta o desenvolvimento de um método para a detecção automática
do Glaucoma em imagens da retina usando a rede neural Convolutional Neural
Network. A metodologia utilizada no estudo foi aquisição de imagens, treina-
mento da rede neural com imagens da retina, extração dos vasos sanguı́neos, e
extração de caracterı́sticas de textura. Finalmente, foram validados os resulta-
dos para avaliar se o método proposto foi eficiente, obtendo acurácia de 98%,
sensibilidade de 98% e especificidade de 96%.
1. Introdução
O glaucoma é uma doença crônica assintomática que devido ao aumento da Pressão Intra-
Ocular (PIO) elevada, causa dano ao nervo óptico e perda periférica irreversı́vel ou total
da visão . Com o nervo óptico lesionado, causa um maior alargamento da escavação ou
Copo Óptico-(CO) se comparado ao alargamento do Disco Óptico-(DO). Apesar de não
possuir cura, o glaucoma pode ser controlado com tratamento adequado e contı́nuo se
detectada a tempo, geralmente no estágio inicial da doença em que raramente apresentam
sintomas e que a lesão do nervo óptico não esteja agravada. O glaucoma está entre as
principais causas de cegueira, atingindo mais de 67 milhões de pessoas, estimando que 6.6
220
milhões sejam cegos, sendo um grande problema na saúde mundial ficando atrás apenas
para catarata [Yin et al. 2012].
Para diagnosticar o glaucoma podem ser realizados exames periódicos como: me-
dida PIO, exame de campo visual e exame de fundo de olho. Embora o exame clı́nico seja
o método mais indicado para avaliação do nervo óptico e da camada das fibras nervosas
da retina, existem aparelhos para auxiliar o diagnóstico do glaucoma, dentre eles a Op-
tical Coherence Tomography (OCT), e a oftalmoscopia Heidelberg Retinal Tomography
(HRC). A OCT é um exame complementar utilizado no diagnóstico das doenças da re-
tina, e o HRT é um procedimento utilizado para a observação precisa da cabeça do nervo
óptico. Estes exames apresentam bons resultados no diagnóstico do glaucoma, porém
possuem um custo elevado.
Uma alternativa viável a esses exames são os Computer-Aided Detection
(CAD)/Computer-Aided Diagnostic (CADx). Esses sistemas são ferramentas computa-
cionais para auxiliar e melhorar os diagnósticos médicos através de imagens, propor-
cionando ao especialista uma segunda opinião para apoio a um diagnóstico mais pre-
ciso [Oliveira et al. 2015]. Visando trazer uma solução para o diagnóstico automático
do glaucoma, esse trabalho apresenta um CAD/CADx utilizando a Convolutional Neu-
ral Network (CNN) para localização precisa ROI (Region Of Interest), e descritores de
textura para extração de caracterı́sticas dessa região, trazendo melhorias na quantificação
da patologia. Este trabalho traz contribuições diretas para alguns campos. No campo
da medicina, a contribuição é o desenvolvimento de um sistema automático para di-
agnóstico do glaucoma através de CNN e análise da textura do DO. No campo da ciência
da computação, contribui-se nos seguintes aspectos: a) no uso de CNN para reconheci-
mento preciso do DO, e b) no uso de árvores filogenéticas para caracterização de lesões
no nervo óptico.
Nesta seção são apresentados trabalhos que tratam da segmentação automática de imagens
de retina para detecção automática do glaucoma.
Em Chen et al. (2015) os autores desenvolvem uma arquitetura de CNN para ser
capaz de capturar as caracterı́sticas discriminativas que melhor caracterizam os padrões
ocultos relacionados ao glaucoma. A estrutura da CNN adotada contém seis camadas:
quatro camadas convolucionais e duas camadas totalmente conectadas. A saı́da da última
camada totalmente conectada é alimentada para um classificador soft-max para a previsão
do glaucoma. Os resultados mostram a área sob curva ROC de 0.831 e 0.887. No trabalho
de Sevastopolsky (2017) é apresentado uma abordagem para a segmentação automática
do DO e CO que se baseia em Deep Learning utilizando uma modificação da arquitetura
de CNN U-Net. O método atinge qualidade comparável aos atuais métodos de última
geração para a segmentação do DO e CO, superando-os em termos de tempo de previsão.
Os resultados mostram que a segmentação automática do DO pode ser feita com qualidade
comparativa com o humano, entretanto o CO é mais complexo para reconhecer.
Yadav et al. (2014) apresentam um estudo e análise dos recursos de textura em
imagens no fundo de olho e suas variações quando a imagem apresenta incidência do
glaucoma. As caracterı́sticas de textura são localizadas em torno do DO e extraı́das com
a matriz de concorrência. O método de classificação proposto é o uso do classificador de
221
rede neural com a ajuda da extração de caracterı́sticas de textura da área localizada no DO

das imagens do fundo de olho. O método obtem 72% de acurácia na classificação.
Fondón et al. (2015) apresentam uma técnica inovadora para a detecção do CO
em imagens de fundo da retina. O método, baseado em um espaço de cores relacionado à
percepção humana e adaptado às condições circundantes, utiliza um classificador Random
Forest para obter pixels de borda do CO. O método foi testado em uma base de dados
publicamente disponı́vel, GlaucomaRepo, de onde usamos 35 imagens para treinamento
e 55 para teste. O trabalho atingiu 97.80% de sensibilidade, 86.95% de especificidade, e
95.04% de acurácia como resultados nos experimentos.
No trabalho de Claro et al. (2015), o método proposto tem como finalidade detec-
tar o glaucoma a partir de imagens digitais da retina, usando extração de caracterı́sticas
e classificação. Inicialmente foi realizada a aquisição de imagens e o pré-processamento.
O próximo passo foi a extração da entropia e das caracterı́sticas de cor das imagens. Em
seguida foram selecionadas as principais caracterı́sticas que representavam as imagens e
por fim, essas caracterı́sticas selecionadas foram utilizadas para a classificação das ima-
gens em glaucomatosas ou não. Como resultado o método obtém 93,67% de acurácia na
classificação das imagens em normais ou glaucomatosas.
Diante do exposto nesta seção, o problema é trazer um diagnóstico mais com-
pleto, e torná-lo mais eficiente para que possa ser utilizado como sistema de diagnóstico
auxiliado por computador, que ajudam a diminuir a variabilidade de interpretação, forne-
cendo uma segunda opinião ao especialista. Assim, com o uso da CNN e descritores de
textura este trabalho tem como objetivo trazer resultados promissores na quantificação do
glaucoma, fornecendo uma ferramenta viável para o diagnóstico dessa patologia.
3. Metodologia
Esta seção aborda a metodologia proposta neste trabalho para detecção, extração, e
classificação de caracterı́sticas do DO, para diagnóstico automático do glaucoma. A
primeira etapa foi a aquisição de imagens, utilizando três bases de imagens públicas
de fundo de olho. Em seguida, foi utilizada a CNN baseada na arquitetura U-Net
[Ronneberger et al. 2015] para o treinamento com imagens da retina selecionadas para
treino. Após o treinamento, é realizado a segmentação com a CNN sobre as imagens
de teste para localização da ROI. Com a ROI definida, foi realizado a sobreposição da
imagem testada com a máscara que a CNN localizou, para ter somente a região do DO
a fim de facilitar a análise sobre as caracteı́sticas da patologia e diminuir a região a ser
processada. Em seguida foi realizada a extração dos vasos sanguı́neos através de uma
segmentação por limiar. Após essa etapa, foi feita a extração de caracterı́sticas, utilizando
descritores de textura baseados em ı́ndices de diversidade filogenético. E por fim, foi
realizada a classificação usando quatro classificadores, para verificar qual classificador
apresentaria melhor eficácia do método ao diagnosticar o glaucoma.
3.1 Base de Imagens
Neste trabalho são utilizadas três bases de imagens da retina, a RIM-ONE
[Trucco et al. 2013], a DRIONS-DB [Carmona et al. 2008] e DRISHTI-GS
[Drishti-Gs 2014]. Essas são bases de imagens públicas que foram dispostas para
pesquisa, teste e desenvolvimento de soluções computacionais para auxı́lio ao di-
agnóstico do glaucoma. A base RIM-ONE possui 169 imagens sendo 119 de retinas
222
normais, e as outras 51 com nı́veis diferentes do glaucoma, possuindo todas cinco

marcações do DO para cada imagem. A base DRISHTI-GS contém 101 imagens,
sendo que 50 delas apenas possuem a marcação do DO feito por especialistas. Já a
base DRIONS-DB contém 110 imagens e as marcações do DO foram feitas por dois
especialistas.
3.2 Convolutional Neural Network

Convolutional Neural Network é uma arquitetura de Deep Learning, sendo uma variação
da rede neural artificial perceptron de múltiplas camadas, baseada no processamento de
dados visuais, capaz de aplicar filtros nesses dados, mantendo a relação de vizinhança
entre os pixels da imagem ao longo do processamento da rede. Em técnicas de Deep
Learning, existem várias arquiteturas de CNNs, cada uma desenvolvida com um objetivo,
seja classificação, detecção, reconhecimento, entre outras. Para tratar a primeira etapa
do problema proposto, buscou-se utilizar uma arquitetura de CNN para segmentação de
imagens. Para detecção do ROI, a imagem da retina tem que ser segmentada para separar
o DO do restante da imagem. Para isso utilizou-se a arquitetura de CNN U-net, que
tem atingido bons resultados em segmentação rápida e precisa de imagens médicas. Ela
vem superando os métodos existentes em vários desafios biomédicos de segmentação de
imagens [Ronneberger et al. 2015].
3.2.1 Arquitetura
A arquitetura tem a forma de U que consiste em dois caminhos, um de contratação (lado

esquerdo) e o outro um caminho expansivo (lado direito). O caminho de contratação se-
gue a arquitetura tı́pica de uma CNN. Consiste na aplicação repetida de duas convoluções
3x3, cada uma seguida por uma função de ativação ReLU e uma operação de max-pooling
de 2x2 com stride 2 para downsampling. Em cada etapa de downsampling dobra-se o
número de canais de caracteı́sticas. Cada passo no caminho expansivo consiste em um
levantamento do mapa de caracteı́sticas seguido de uma convolução 2x2 que faz a metade
do número de canais de caracteı́sticas, que é uma junção com o mapa de caracteı́sticas
correspondentemente cortado do caminho de contratação e dois 3x3 convoluções, cada
uma seguida por uma função de ativação uma ReLU. Essa etapa do caminho expan-
sivo é necessário devido à perda de pixels de borda em cada convolução no caminho de
contratação. Na camada final é utilizada uma convolução 1x1 para mapear cada vetor de
caracterı́sticas de 64 componentes para o número desejado de classes. Para a segmentação
nas imagens da retina, a saı́da desejada inclui a localização, ou seja, uma etiqueta de classe
deve ser atribuı́da a cada pixel, que no caso é a máscara contento a ROI nas imagens
de treinamento. No total, a rede possui 23 camadas convolutivas. Como algoritmo de
otimização da rede, utilizou-se algoritmo Adam, pois é invariável ao redimensionamento
diagonal dos gradientes e é adequado a grandes problemas em termos de dados.
3.2.2 Treinamento da CNN
Para o treinamento, os algoritmos foram desenvolvidos em linguagem de programação

Python 3.5, e framework Keras para treinamento de redes neurais. A biblioteca OpenCV
foi usada para manipulação de imagens. A máquina utilizada contém hardware composto
223
por processador Intel Core I5 64 bits, e 4GB de memória RAM DDR3. Para o treinamento
da CNN, o próximo passo e muito importante é selecionar os dados de entrada para o
treino da rede, pois eles determinam se a taxa de aprendizado foi eficiente ou não. Para
isso, foram selecionadas 235 imagens das três bases, sendo 130 da RIM-ONE, 50 da
DRISHTI-GS, e 55 da DRIONS-DB, deixando as demais para testes.
[Dosovitskiy et al. 2014] relata que as redes neurais convolucionais são eficien-
tes no aprendizado com uma grande quantidade de dados de entrada, presumiu-se que
235 imagens eram poucas para o treinamento. Para aumentar o número de amostras uma
solução encontrada foi rotacionar cada imagem em 45, 90, 135, 225, 270, e 315 graus jun-
tamente com suas máscaras, produzindo assim mais seis novos pares de amostras. Para
a CNN aprender as caracterı́sticas do DO e segmentar imagens da retina para detectar
a ROI, foram passados como parâmetros de entrada para o treinamento as imagens da
retina e suas devidas máscaras, sendo o papel da máscara apontar a classe que deve ser
aprendida, que no caso é toda a estrutura do DO. No treinamento, os pesos dos filtros con-
volucionais foram iniciados aleatóriamente, o número de épocas foi de 20, e o treinamento
foi a partir do zero, ou seja, não foi utilizado nenhum modelo de rede pré-treinado.
3.3 Extração dos Vasos Sanguı́neos

Antes de validar as imagens geradas com a ROI, retirou-se as veias para facilitar a
abstração de caracterı́sticas relevantes para posterior classificação. Para isso foi desen-
volvido um algoritmo de segmentação por limiar baseado no algoritmo Otsu. Com isso
deseja-se obter de forma rápida e automática o valor limite correto para escolher entre dois
modo de histograma, permitindo-lhes aplicar o limiar de forma otimizada, para então se-
parar os vasos do restante da imagem por possuı́rem uma tonalidade mais escura no DO.
3.4 Extração de Caracterı́sticas

A diversidade filogenética procura as diferentes espécies ou de indivı́duos diferentes em
uma população, provavelmente começará com uma análise filogenética. Para a extração
de caracterı́sticas das ROIs após a detecção do DO e extração das veias, utilizou-se os
ı́ndices de diversidade filogenéticas Phylogenetic Diversity (PD), Sum of Phylogenetic
Distances (SPD), Mean Nearest Neighbour Distance (MNND), Phylogenetic Species Va-
riability (PSV) e Phylogenetic Species Richness (PSR) para extração de caracterı́sticas
baseadas em textura. Esses ı́ndices consideram a distância filogenética, calculada a partir
da arquitetura da árvore filogenética [de Carvalho Filho et al. 2017].
3.5 Classificação
Para a classificação foi utilizada a suı́te de algoritmos de mineração de dados e aprendi-
zado de máquina WEKA, usando os classificadores: J48Consolidated, J48, AdaBoostM1
e BayesNet. Esses classificadores foram utilizados por serem robustos no processo de
classificação, apresentando um bom resultado na categorização de padrões do DO.
3.6 Validação dos Resultados

Para validação dos resultados do método em quantificar o glaucoma em imagens de fundo
de olho, utilizou-se de métricas de avaliação baseadas em estatı́stica como Acurácia, Es-
pecificidade, e Sensibilidade.
224
4. Resultados e Discussões
Nesta seção são apresentados os resultados obtidos com base na metodologia proposta
neste trabalho em quantificar as imagens em glaucomatosas ou normais com base no
conjunto de imagens selecionadas para teste.
Um teste realizado com 50 imagens da base RIM-ONE, dentre elas, contém ima-
gens da retina normais e com diferentes nı́veis de glaucoma, sendo que essas imagens
não foram utilizadas para treinamento, somente para teste. Com isso desejava-se saber se
após o treino, a segmentação da CNN conseguiria identificar o DO em novas imagens da
retina para garantir que a CNN detectaria a localização correta do DO. Na Figura 1, apre-
senta os resultados sobre as etapas para processamento da ROI. Na Figura 1(a) tem-se a
imagem utilizada para teste. Na Figura 1(b) tem-se a predição feita pela CNN, realizando
a segmentação sobre essa a imagem 1(a), retornando a máscara apontando o DO. Na Fi-
gura 1(c) é ilustrado a sobreposição feita entre 1(a) e 1(b) para ter a ROI isolada em tons
de cinza. Por fim, na Figura 1(d) ilustra a imagem resultante após a extração dos vasos
sanguı́neos, estando apta a ser extraı́das as caracterı́sticas para posterior classificação.
Figura 1. Detecção do DO e extraçãos da veias.
Com a remoção dos vasos sanguı́neos, em seguida foi realizada a extração de

caracterı́sticas utilizados os ı́ndices de diversidade filogenética PD, SPD, MNND, PSV,
PSR, no qual descrevem a variedade de informações presentes nos valores dos pixels. Para
encontrar padrões nessas caracterı́sticas que possam quantificar imagens glaucomatosas,
é utilizado o WEKA para classificação com os classificadores: J48Consolidated, J48,
AdaBoostM1 e BayesNet.
Tabela 1. Resultados da Metodologia

Classificador Acurácia (%) Sensibilidade (%) Especificidade (%)
J48Consolidated 97 100,0 89
J48 97 99 88
AdaBoostM1 98 98 96
BayesNet 98 98 96
Pode-se observar na Tabela 1 que os resultados obtidos na classificação foram

promissores, tendo como melhor os classificadores AdaBoostM1 e BayesNet que atingi-
ram uma acurácia de 98%, sensibilidade de 98% e especificidade de 95%, se destacando
como classificadores que apresentam melhor capacidade no diagnóstico. O classificador
J48 obteve o pior resultado, com acurácia de 97%, sensibilidade de 99% e especifici-
dade de 88%, mas que comparados aos melhores resultados houve pouca variação. Os
resultados obtidos demostram que com a classificação, a detecção do DO usando CNN
225
foi precisa, e que os descritores de textura conseguiram distinguir as regiões de imagens

normais e glaucomatosas.
Tabela 2. Comparação com os trabalhos relacionados

Trabalho Base A (%)
[Sevastopolsky 2017] RIM-ONE, DRIONS-DB, DRISHTI-GS -
[Chen et al. 2015] ORIGA, SCES -
[Fondón et al. 2015] GlaucomaRepo 95.4
[Claro et al. 2015] RIM-ONE, DRIONS-DB, DRISHTI-GS 93
[Yadav et al. 2014] Privada 72
Metodologia RIM-ONE, DRIONS-DB, DRISHTI-GS 98
Em comparação com os trabalhos relacionados, como demonstra a Tabela 2, a

metodologia se destacou. O trabalho de [Sevastopolsky 2017] apresentou em sua meto-
dologia o uso de uma CNN para segmentar o DO e CO em que apresenta bons resultados,
mas so realiza a etapa da segmentação. Nos demais trabalhos vão além da segmentação,
eles quantificam a patologia, mas a abordagem e técnicas de extração de caracterı́scticas
se diferem aos usados na metodologia proposta por a mesma utilizar os descritores ba-
seados em textura para extrair caracterı́sticas da imagens. O referente trabalho se difere
dos demais por trazer uma metodologia diferente apresentando resultados superiores aos
trabalhos relacionados, contribuindo com resultados promissores ao diagnóstico do glau-
coma.
5. Conclusão
Com o uso de técnicas de PDI e Deep Learning, este trabalho apresentou uma meto-
dologia para detecção automática do DO em imagens da retina, utilizando CNN para
segmentação, descritores baseados em textura para discriminação, e distintos classifi-
cadores para classificação de regiões em imagens da retina em glaucomatosas ou nor-
mais. A análise de imagens da retina utilizando a ROI apresentou resultados eficientes
na categorização de padrões de lesões glaucomatosas, atingindo uma taxa de acerto de
98% de acurácia, sensibilidade de 98%, e especificidade de 95%, na quantificação do
glaucoma. Assim, o referente trabalho tem uma maior relevância na área médica e com-
putacional, pois com o uso dessas novas tecnologias, possibilitam ao profissional da área
recursos para diagnosticar a doença em seu estágio precoce, tornando um meio viável ao
diagnóstico do glaucoma. A partir dos resultados obtidos, pode-se inferir que a utilização
da CNN para detecção da ROI, e descritores baseados na textura das regiões, apresentam
resultados eficazes na classificação do quantificação do glaucoma. O uso de descrito-
res de textura para descrever padrões em regiões de imagens mostrou-se eficiente para a
metodologia proposta.
Referências
Carmona, E. J., Rincón, M., Feijoo, G. J., and Martı́nez, J. M. (2008). “Identification of
the ptic nerve head with genetic algorithms”. artificial intelligence in medicine, Vol.
43(3), pp.243-259.
Chen, X., Xu, Y., Wong, D. W. K., Wong, T. Y., and Liu, J. (2015). Glaucoma detection
based on deep convolutional neural network. In Engineering in Medicine and Biology
226
Society (EMBC), 2015 37th Annual International Conference of the IEEE, pages 715–
718. IEEE.
Claro, M. L., de Araújo, F. H. D., de Lima e Silva, W., de Moura Santos, L., e Silva,
R. R. V., and Santana, A. M. (2015). Detecção automática do glaucoma por extraçãs
de caracterı́sticas e classificação. XII Simpósio Brasileiro de Automação Inteligente
(SBAI).
de Carvalho Filho, A. O., Silva, A. C., de Paiva, A. C., Nunes, R. A., and Gattass, M.
(2017). Computer-aided diagnosis of lung nodules in computed tomography by using
phylogenetic diversity, genetic algorithm, and svm. Journal of Digital Imaging, pages
1–11.
Dosovitskiy, A., Springenberg, J. T., Riedmiller, M., and Brox, T. (2014). Discriminative
unsupervised feature learning with convolutional neural networks. In Advances in
Neural Information Processing Systems, pages 766–774.
Drishti-Gs (2014). “provided by medical image processing (mip) group, iiit
hyderabad”. Disponı́vel: http://cvit.iiit.ac.in/projects/mip/
drishtigs/mip-dataset2.
Fondón, I., Valverde, J. F., Sarmiento, A., Abbas, Q., Jiménez, S., and Alemany, P. (2015).
Automatic optic cup segmentation algorithm for retinal fundus images based on ran-
dom forest classifier. In EUROCON 2015-International Conference on Computer as a
Tool (EUROCON), IEEE, pages 1–6. IEEE.
Oliveira, F. S. S., de Carvalho Filho, A. O., Silva, A. C., de Paiva, A. C., and Gattass,
M. (2015). Classification of breast regions as mass and non-mass based on digital
mammograms using taxonomic indexes and svm. Computers in biology and medicine,
57:42–53.
Ronneberger, O., Fischer, P., and Brox, T. (2015). U-net: Convolutional networks for
biomedical image segmentation. In International Conference on Medical Image Com-
puting and Computer-Assisted Intervention, pages 234–241. Springer.
Sevastopolsky, A. (2017). Optic disc and cup segmentation methods for glaucoma de-
tection with modification of u-net convolutional neural network. arXiv preprint ar-
Xiv:1704.00979.
Trucco, E., Ruggeri, A., Karnowski, T., Giancardo, L., Chaum, E., Hubschman, J. P.,
Al-Diri, B., Cheung, C. Y., Wong, D., Abramoff, M., Lin, G., Kumar, D., Burlina, P.,
Bressler, N. M., Jelinek, H. F., Meriaudeau, F., Quellec, G., Macgillivray, T. E., and
Dhillon, B. (2013). “validating retinal fundus image analysis algorithms: Issues and a
proposal”. Invest. Ophthalmol. Vis. Sci.
Yadav, D., Sarathi, M. P., and Dutta, M. K. (2014). Classification of glaucoma based
on texture features using neural networks. In Contemporary Computing (IC3), 2014
Seventh International Conference on, pages 109–112. IEEE.
Yin, F., Liu, J., Wong, D. W. K., Tan, N. M., Cheung, C., Baskaran, M., Aung, T., and
Wong, T. Y. (2012). Automated segmentation of optic disc and optic cup in fundus
images for glaucoma diagnosis. In Computer-based medical systems (CBMS), 2012
25th international symposium on, pages 1–6. IEEE.
227
Aplicação De Algoritmos Evolutivos Para Reconfiguração

De Redes De Distribuição Na Presença De Geração
Distribuída
Abstract— This work presents a methodology to identify configurations in

radial distribution systems that best fit after contingency situations, aiming at
the minimization of the voltage drop and the adequacy of the voltage level in
the bars according to the limits established by the (ANEEL), taking into
account the use of distributed generation. For the meeting of possible
configuration solutions, we used the Genetic Algorithm with elitism,
implemented in python. The methodology was tested by means of simulations of
a distribution system composed of 50 bars, 3 distributed generators, using the
program of calculation and simulation of electrical systems, PowerFactory,
demonstrating the efficiency of the algorithm.
Resumo— Este trabalho traz o estudo de uma metodologia para identificar
configurações, em sistemas de distribuição radiais, que melhor se adéquam
após situações de contingência, objetivando a minimização da queda de tensão
e a adequação do nível de tensão nas barras de acordo com os limites
estabelecidos pelo órgão regulamentador(ANEEL), levando em consideração a
utilização de geração distribuída. Para o encontro de possíveis soluções de
configuração, foi utilizado o Algoritmo Genético com elitismo, implementado
em Python. A metodologia foi testada por meio de simulações de um sistema de
distribuição composto 50 barras, 3 geradores distribuídos, utilizando o
programa de cálculo e simulação de sistemas elétricos, PowerFactory,
demonstrando a eficácia do algoritmo.
I. INTRODUÇÃO
O sistema elétrico de potência (SEP) é visto como grandes sistemas de energia que
englobam a geração, transmissão e distribuição de energia elétrica. Com o passar dos
anos, ele vem ficando cada vez mais essencial para a humanidade e juntamente com isso
cresce também a sua complexidade, devido a diversos fatores, como por exemplo, o
aumento da quantidade de cargas conectadas, a expansão do sistema, a incorporação de
novas tecnologias, aumento das exigências quanto aos índices de qualidade da energia, e
o emprego crescente de Geração Distribuída (GD) dentre outros [DUGAN,2003]. Por
outro lado, questões financeiras, limitadoras da capacidade de investimento das
empresas, estão cada vez mais presentes no contexto dos projetos de planejamento de
sistemas de energia. Como consequência, as empresas que apresentam uma crescente
necessidade de uso de sistemas computacionais para apoio às atividades de
planejamento e operação das suas redes [SANTOS et al, 2010].
Um dos procedimentos associados à operação dos SEPs é a reconfiguração das
redes, principalmente os Sistemas de distribuição (SD), que por serem radiais estão mais
sujeitos às interrupções. Os SDs representam a parte do sistema no qual ocorrem a
maioria das falhas, influenciando na qualidade do serviço, nele também ocorre a maior
228
quantidade de perdas de potência ativa e queda de tensão, influenciando no custo da

operação do sistema. Para permitir a reconfiguração, os sistemas de distribuição
possuem chaves dispostas em seu percurso, que operam com estado aberto ou fechado.
Na ocorrência de uma eventual falta, o sistema deve ser restaurado o mais rápido
possível, mas na prática não é o que acontece, leva um certo tempo para o
restabelecimento da rede e a realimentação de setores próximos a contingência. Para
isso, a reconfiguração de sistema de distribuição de energia elétrica pode ser uma
importante ferramenta tanto para solucionar o ocorrido, quanto para a melhoria das
condições de estabilidade de tensão, diminuição de perdas por efeito Joule e amenização
do carregamento, principalmente em momentos de alta demanda [PEREIRA, 2010].
Neste trabalho, propõe-se uma metodologia para a determinação da configuração
ótima de redes de distribuição, em caso de faltas únicas e múltiplas, considerando
presença de geradores distribuídos, objetivando a minimização da queda de tensão,
utilizando Algoritmos Genéticos (AGs) programado diretamente no software de
simulação de SEP PowerFactory. Nessa proposta o AG atua diretamente no sistema de
distribuição modelado no PowerFactory, modificando as configurações do sistema e
avaliando a função objetivo a cada configuração indicada para o SEP.
II.DEFINIÇÃO DO PROBLEMA
O problema de reconfiguração de redes é combinatório, pois existindo um sistema de N
chaves, haverá 2𝑁 topologias possíveis. Muitas dessas configurações possíveis são
insatisfatórias, pois não cumprem as restrições de radialidade, ausência de sobrecarga
em equipamentos da rede e das subestações, manutenção dos níveis de tensão dentro
dos intervalos exigidos pela legislação em cada país, ou contém barras desconectadas,
tornando-se topologicamente infactíveis [SCHMDT et al, 2005], [MARQUES et al,
2014].
Para cada configuração deve ser verificada a factibilidade, para determinar se
essa soluções é usável ou não. Mesmo desconsiderando as soluções que não atendem às
restrições, para sistemas de grande porte, ainda assim a quantidade de soluções
possíveis é enorme, bem maior do que uma pessoa seria capaz de visualizar e analisar.O
problema de reconfiguração de redes trata-se de um problema de programação não-
linear inteiro misto, o que faz dos Algoritmos Evolutivos bastante atraente para sua
resolução dentre diversas outras técnicas.
As redes de distribuição são tradicionalmente redes radiais, logo todos os
equipamentos, dispositivos e procedimentos presentes na distribuição foram projetados
para funcionar segundo essa topologia. A Geração distribuída muda essa característica,
pois o fluxo de potência deixa de ter um único sentido, da subestação em direção as
cargas, e passa a ter também a contribuição do gerador conectado à rede, podendo
também reduzir ou aumentar as perdas em um sistema, dependendo do nível de geração,
da sua localização, da demanda de carga e da topologia da rede [AYRES, 2010]. Por
exemplo, caso a geração distribuída exceda os 25% da geração total haverá perdas na
qualidade da energia [ZHU et al, 2005]. Este estudo considerará a presença de geradores
distribuídos e a possibilidade da operação ilhada (isolada da subestação) dos geradores
desde que consigam suportar a carga presente na ilha.
229
Sistema teste
O sistema de distribuição utilizado nesse trabalho possui 50 barras e opera com
tensão nominal 13,8 KV, frequência de 60 Hz, quatro transformadores, três geradores
distribuídos, carga total de 6,46MW de potência ativa e 3,24MVAr de potência reativa.
O sistema utilizado em [SGUAÇABIA, 2015] foi adaptado, sendo acrescentadas três
linhas, tornando a topologia radial com recurso.
A Figura 1 mostra o sistema após a adaptação, utilizado nos testes, com a
localização das chaves.
Figura 1:Sistema adaptado de 50 barras usado nesse artigo.

Fonte: Do autor
Na adaptação, foram adicionadas as linhas 46, 47 e 48. A seguir, na TABELA I é

mostrado os dados das novas linhas:
TABELA I
DADOS DAS LINHAS AÉREAS DE DISTRIBUIÇÃO QUE FORAM ADICIONADAS.
Nome da Barra de Barra de Destino Resistência Reatância Comprimento

Linha Origem
46 2 22 0,053819 0,077077 8 km
47 21 61 0,053819 0,077077 6 km
230
48 39 32 0,053819 0,077077 3 km
Após diversas execuções do algoritmo, foi identificado que a configuração com

menor somatório de queda de tensão foi a que deixou as chaves 17, 22 e 43 abertas, com
valor de 0,0657. Portanto, consideraremos esta como a configuração normal de
operação.
III. SOLUÇÃO DO PROBLEMA
Para a reconfiguração do sistema teste, já mostrado, foi utilizado o Algoritmo Genético

simples [GOLDBERG, 1989]. Na metodologia proposta cada gene do cromossomo
corresponde a uma chave do sistema elétrico. O valor de um bit igual a “1” indica que a
chave correspondente está fechada. E valor de bit igual a “0” indica que a chave está
aberta.
Para o algoritmo desenvolvido neste trabalho, foi utilizado um cromossomo de
tamanho 53, a mesma quantidade de chaves presentes no sistema, tamanho de
população igual a 150, tamanho de torneio igual a 4, taxa de cruzamento igual a 100% e
taxa de mutação igual a 2%, com elitismo de 1 indivíduo, utilizando como critério de
parada o número de gerações, nesse artigo foram utilizadas 60 gerações. Para respeitar a
radialidade do sistema e fornecimento a todas as cargas foram impostas restrições ao
AG.
Para implementação deste algoritmo, foi utilizada a linguagem de programação
Python versão 3.3.2, no programa Pycharm, executado dentro do programa de cálculo e
simulação de sistemas elétricos, PowerFactory. O computador usado nas simulações
continha um processador Intel Core i5, 2.60 GHz.
A função fitness é calculada de acordo com a seguinte equação:
𝐹𝑖𝑡𝑛𝑒𝑠𝑠 = 𝐹𝑂 + (𝑅 × ∑ 𝑙𝑜𝑜𝑝𝑠) + (𝐿 × ∑ 𝑇𝑖𝑛𝑎𝑑𝑒𝑞𝑢𝑎𝑑𝑜 ) + (𝐶 × ∑ 𝐶ℎ𝐹𝑎𝑙𝑡𝑎)

(I)
Em que R, L e C são penalidade dadas por valores bem grandes, e FO é a função
objetivo e é dada por:
𝑚𝑖𝑛 𝐹𝑂 = ∑𝑛,𝑚𝜖𝐵|𝑇𝑛 − 𝑇𝑚| , 𝑠𝑒 𝑎 𝑏𝑎𝑟𝑟𝑎 𝑛 𝑒𝑠𝑡𝑖𝑣𝑒𝑟 𝑙𝑖𝑔𝑎𝑑𝑎 𝑎 𝑏𝑎𝑟𝑟𝑎 𝑚
( II )
Sendo n e m duas barras distintas que estejam conectadas, Tn e Tm são as
tensões nas barras n e m, respectivamente, e B é o conjunto de todas as barras do
sistema.
A função objetivo consiste no somatório do módulo das diferenças de tensão
(queda de tensão) entre as barras conectadas, ou seja, se a chave entre elas estiver
fechada.
A fim de manter a radialidade do sistema, na função fitness (I) foi calculado o
somatório de loops, considerando que para o sistema operar é primordial que não
existam loops. E para isso foi aplicada uma penalização (R) de 100.000 para cada loop
que a configuração apresentou. Foi escolhido um valor tão alto porque a quantidade de
loops possíveis era pequeno (seis), o que tornava relativamente raro a ocorrência dessa
situação, pois para que um loop fosse formado todas as chaves de uma determinada área
deveriam estar fechadas.
231
Para garantir que todas as barras estivessem com o nível de tensão adequado,
adicionou-se à equação ( I ) um termo que realiza o somatório das barras com nível de
tensão inadequado e penalização (L) de valor 5. Esse valor pequeno foi escolhido pois
ao gerar a população, a grande maioria dos indivíduos deixavam barras fora da tensão
adequada, visto que grande parte dos bits dos indivíduos, inicialmente, possuíam valor
igual a zero, deixando assim barras desenergizadas.
Objetivando a desenergização da linha ou linhas onde a(s) falta(s), foi
adicionado à equação ( I ) um termo que faz a soma do estado da chave conectada a
linha em defeito, ou seja, se a chave da linha com defeito estiver fechada, o valor do
estado é 1 (um) e se a chave estiver aberta, o estado é 0 (zero). Após testes, verificou-se
que o valor de 500 para a penalidade (C) era suficiente para garantir que a linha em que
foi simulada a falta permanecesse desenergizada.
Método de reconfiguração para otimização da rede

O método de reconfiguração deste trabalho envolverá o uso do Algoritmo
Genético para o encontro da melhor configuração, em situações de contingência,
buscando diminuir a queda e melhorar o nível de tensão. A seguir é explicado tal
método.
a) Na Figura 2 mostra-se um sistema em funcionamento normal, com todas as
barras energizadas. As linhas contínuas representam setores energizados, a linha
descontínua (tracejada) representa uma linha desenergizada.
Figura 2: Sistema de 6 barras com a linha 5 desenergizada.

Fonte: Do autor
b) Supondo a ocorrência de uma contingência na linha 3 (com o raio preto), a chave

da linha 5 deverá ser ativada (fechada) para garantir o suprimento de demanda de todo o
sistema.
Figura 3: Sistema de 6 barras com a linha 3 desernegizada.
232
Fonte: Do autor
IV. RESULTADOS DE IMPLEMENTAÇÃO
Neste tópico utilizaremos o método de reconfiguração já explicado para

reconfiguração do sistema teste, após uma e múltiplas faltas.
Para a primeira simulação, supõe-se que ocorreu um curto circuito na linha 18 e
para que seja feita a manutenção, esta linha deverá continuar sem energia. Assim, o
algoritmo genético irá procurar pela configuração que mantenha a linha sem energia e
que supra toda a demanda do sistema, deixando todas as barras com tensão adequada, de
acordo com a ANEEL. Para a escolha da melhor configuração, o algoritmo foi
executado 5 vezes. A configuração encontrada mostrará quais chaves permanecerão
abertas, consequentemente todas as outras chaves estarão fechadas. As configurações
encontradas e a queda de tensão estão expostas na TABELA II.
TABELA II
CONFIGURAÇÕES ENCONTRADAS PARA A FALTA NA LINHA 18.
Execução Falta Chaves Abertas Queda de tensão

1 CH16-L18 [7, 16, 44] 0,0687
2 CH16-L18 [7, 16, 44] 0,0687
3 CH16-L18 [7, 16, 44] 0,0687
4 CH16-L18 [7, 16, 44] 0,0687
5 CH16-L18 [7, 16, 44] 0,0687
Agora supõe-se uma outra situação, em que ocorre uma falta dupla, nas linhas 23 e 48.
Os resultados, quanto a queda de tensão, são apresentados a seguir:
TABELA III
CONFIGURAÇÕES ENCONTRADAS PARA AS FALTAS NAS LINHAS 23 E 48.

1 CH21-CH44 [6, 21, 38, 44] 0,0884
2 CH21-CH44 [8, 21, 44] 0,0857
3 CH21-CH44 [8, 21, 44] 0,0857
4 CH21-CH44 [8, 21, 44] 0,0857
5 CH21-CH44 [8, 21, 44] 0,0857
Para o terceiro caso, foi simulada uma falta na linha 40, que deixou o gerador 3
operando ilhado no sistema. Os resultados, quanto a queda de tensão, são apresentados
a seguir:
TABELA IV
CONFIGURAÇÕES ENCONTRADAS PARA A FALTA NA LINHA 40.

1 CH38-L40 [5, 16, 22, 38] 0,0724
2 CH38-L40 [5, 16, 22, 38] 0,0724
3 CH38-L40 [5, 16, 22, 38] 0,0724
4 CH38-L40 [9,16,38, 43] 0,0994
5 CH38-L40 [5, 16, 22, 38] 0,0724
233
V. ANÁLISES DOS RESULTADOS
Pode-se perceber que, quando a falta ocorreu na linha 18 (chave 16), em todas
as 5 execuções o algoritmo encontrou a configuração com as chaves 7, 16 e 44 abertas,
representando assim a melhor configuração encontrada para a situação do sistema, com
queda de tensão de 0,0687.
Considerando a falta dupla nas linhas 23 e 48 (chaves 21 e 44), as
configurações obtidas possuem quedas de tensão muito próximas, porém a que
economizará mais, em termos de chaves manobradas, será a configuração que deixará
as chaves 8, 21 e 44 abertas e queda de tensão de 0,0857, pois é necessário apenas abrir
a chave 8 quando as linhas das chaves 21 e 44 tiverem em contingência.
Já para a falta na linha 40 (chave 38), em que houve ocorrência de ilhamento do
gerador 3, a configuração com menor queda tensão foi a que deixou as chaves 5, 16, 22
e 38 abertas e a queda de tensão foi 0,07244876. Com tal configuração, o gerador
trabalhou em boas condições, ou seja, sem sobrecarga.
Para todos os casos a metodologia proposta funcionou adequadamente.
VI. CONCLUSÃO
Nesse artigo foram apresentados os resultados obtidos com a implementação de

um algoritmo genético simples, em python, para o restabelecimento de energia em um
sistema de distribuição radial com recurso, visando a minimização de queda de tensão
no sistema e considerando a presença da geração distribuída. O estudo de caso foi
realizado num sistema de 50 barras, supondo uma e múltiplas faltas. Os resultados
obtidos na simulação demonstraram que o algoritmo implementado conseguiu encontrar
soluções satisfatórias para cada falta simulada, respeitando as restrições de radialidade
do sistema, níveis de tensão dentro do intervalo aceitável, ausência de sobrecarga e de
barras desconectadas.
Os trabalhos futuros incluem a implementação de algoritmos evolutivos multi-
objetivos para resolução desse problema.
REFERÊNCIAS
AYRES, H. M. (2010). Desenvolvimento de Metodologias de Análise de Geradores

Distribuídos em Sistemas de Distribuição de Energia Elétrica. Tese (Doutorado em
Engenharia Elétrica), Universidade Estadual de Campinas, Campinas.
DUGAN R. C., et al. (2003), Electrical Power Systems Quality. McGraw-Hill

Professional.
GOLDBERG, D. E. (1989). Genetic Algorithms in Search Optimization and Machine

Learning, 0201157675,Addison-Wesley Pub.Co.
234
MARQUES L. T., JUNIOR J. C. M. V., SANCHES D. S., JUNIOR J. B. A. L. (2014).

Análise da influencia da Geração Distribuída no problema de restabelecimento de
energia. Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG.
PEREIRA, F. S. (2010). Reconfiguração ótima de sistemas de distribuição de

energia elétrica baseado no comportamento de colônias de formigas. 2010. 104 f.
Tese (Doutorado em Engenharia Elétrica) - Escola de Engenharia de São Paulo,
Universidade de São Paulo, São Carlos.
SANTOS, A. C. ; DELBEM, A. C. B. ; LONDON, JR., J. B. A. ; BRETAS, N. G.

(2010). Node-Depth Encoding and Multiobjective Evolutionary Algorithm Applied
to Large-Scale Distribution System Reconfiguration. IEEE Transactions on Power
Systems, v. 25, p. 1254-1265.
SCHMDT, H. P.;IDA, N.; KAGAN, N.; GUARALDO, J. C. (2005). Fast

reconfiguration of distribution systems considering loss minimization. IEEE
Transactions on Power Systems, New York, v. 20, n. 3, p. 1311-1319.
SGUAÇABIA, R. R. (2015). Avaliação do impacto da geração distribuída sobre o

sistema de proteção de sobrecorrente de uma rede de distribuição operando em
ilhamento intencional. Diss.de Mestrado, Universidade de São Paulo.
ZHU, S. et al. (2005). Discussion on parallel operation between distributed generator

and distribution system. Journal of Shenyang Institute of Engineering, v. 4, p. 1-4.
235
Análise sobre o Efeito de Fatores que Interfere na Acurácia do

Registro de Temperatura em Colmeias
Ricardo da Silva, Daniela Sena, Rodrigo Leal, Imperes Filho e Francisco Airton Silva
Universidade Federal do Piauı́ - UFPI
{ricardobrunof,d.c.senna61,rocaleal98,fcoimperes,francsilva10}@gmail.com
Abstract. The beekeeping is explored in many parts of the world with a wide
variety of techniques and technologies. There are computer systems that moni-
tor various health characteristics of hives. Such monitoring can be performed
by sensors that are part of what is called the ”Internet of Things”. In Brazil the
use of these technologies is still limited. the high temperatures in the Northeast
of Brazil causes constant losses in honey production. This work presents a sen-
sitivity analysis focusing on the accuracy of temperature records in hives at the
Piauı́ region. The study made it possible to identify factors that have a greater
impact on the temperature accuracy measured by the system called SISMAC.
Four factors were observed in the 480 experiments applying the Design of Ex-
periments method: (A) Day Period, (B) Sensor Position, (C) Sensor Type, and
(D) Presence of Propolis. The decreasing order of impact was: B, C, D, and A.
The results permit to conclude that the more accurate configuration is positio-
ning the sensor DS18B20 at the central region of the hive. This work certainly
collaborates with studies of IoT in beekeeping field.
Resumo. Em diversas partes do mundo a apicultura é explorada com uma

grande variedade de técnicas e tecnologias. Existem sistemas computacionais
que monitoram várias caracterı́sticas da saúde das colmeias. Tal monitora-
mento pode ser realizado por sensores que fazem parte do que chama-se de
“Internet das Coisas”. No Brasil o uso destas tecnologias ainda é limitado.
As altas temperaturas do Nordeste causam perdas constantes na produção e
prejuı́zos aos apicultores. Este trabalho apresenta uma análise de sensibilidade
focando na precisão de registros de temperatura em colmeias no Piauı́. O es-
tudo possibilitou identificar fatores que possuem maior impacto na acurácia da
temperatura medida pelo sistema denominado SISMAC. Quatro fatores foram
observados nos 480 experimentos aplicando o método estatı́stico Design of Ex-
periments: (A) Perı́odo do Dia, (B) Posição do Sensor, (C) Tipo de Sensor, e (D)
Presença de Própolis. A ordem decrescente em termos de impacto obtido foi:
B, C, D e A. Os resultados permitem afirmar, por exemplo, que a configuração
com melhor desempenho foi o sensor DS18B20 posicionado na região central
da colmeia. Este trabalho auxiliará na futura compreensão do uso de sensores
na apicultura.
236
1. Introdução
A apicultura tem se destacado como uma atividade importante do ponto de vista
econômico, social, ambiental, além de ter extrema importância para a produção agrı́cola,
já que as abelhas realizam a polinização [Freitas et al. 2004]. Segundo pesquisa da
Organização das Nações Unidas para Agricultura e Alimentação (FAO)1 , entre o ano
de 1999 e 2009, o crescimento médio da produção de mel foi de 22% no mundo, com
crescimento de 96% no Brasil.
Abelhas são insetos sensı́veis às mudanças em seu habitat. Seca, calor e frio
podem interferir diretamente na produção melı́fera. A regulação de temperatura (para
situações de calor) é feita pelas abelhas, entretanto, se o calor continuar, as abelhas aban-
donam as colmeias (processo chamado de enxameação). O apicultor deve ter mecanismos
e técnicas que reduzam ou tratem essas ameaças à sua produção [GloboRural 2016].
Na apicultura, tecnologias podem ser usadas para monitoramento de temperatura,
umidade e outras variáveis das colmeias. Com isso é possı́vel identificar problemas que
estejam ocorrendo na colônia e, assim, evitar prejuı́zos como pouca produtividade da
colmeia ou enxameação das abelhas [Murphy et al. 2015]. A Internet das Coisas (Inter-
net of Things - IoT) é um paradigma que interliga inteligência e monitoramento senso-
rial e que pode ser usada para esta problemática [Almeida 2008, Meitalovs et al. 2009,
Eskov e Toboev 2011, Sombra et al. 2013, Stalidzans e Berzonis 2013].
Este artigo procura mitigar a enxameação e perdas de produção usando uma ar-
quitetura IoT denominada SISMAC. Fazendo uso do método Design of Experiments
[Minitab 2017a] combinamos várias configurações de sensores e neste direcionamento
as principais contribuições deste trabalho são:
• Realizar uma Análise de Sensibilidade sobre o impacto de fatores na acurácia de
temperatura na apicultura;
• Identificar a melhor configuração de sensores para obter a temperatura mais ade-
quada em colmeias.
O restante do artigo está organizado em: a Seção 2 discute os conceitos ne-
cessários ao entendimento da proposta; Seção 3 descreve nosso sistema de monitora-
mento de temperatura; Seção 4 descreve o experimento realizado para investigação de
fatores com maior impacto na acurácia da temperatura; a Seção 5 apresenta os trabalhos
relacionados com esta pesquisa e a Seção 6 traça conclusões e trabalhos futuros.
2. Referencial Teórico
Esta seção contextualiza o gênero das abelhas observadas, e os malefı́cios da enxameação.
As abelhas do gênero Apis Mellifera são insetos de origem europeia e africana que se
adaptam com facilidade a diferentes ambientes No Brasil, as condições fizeram com que
essas abelhas tivessem uma ótima adaptação [Oliveira 2010].
As abelhas são importantes para a humanidade e meio ambiente, seja por seus
produtos ou pela polinização. O mel é o principal produto produzido, mas elas produ-
zem também cera, pólen e a própolis. Utilizados na produção de fármacos, cosméticos,
compostos de vitaminas, minerais, fibras e outros [Almeida 2008].
1
Sebrae: goo.gl/33CiP9
237
A enxameação por abandono (abandono de colmeias) pode ocorrer por vários mo-
tivos, dentre os quais, destaca-se o calor excessivo como principal influenciador. Quando
a temperatura interna atinge 41o C, as abelhas não conseguem controlar a temperatura in-
terna da colmeia causando, assim, o abandono. No Brasil, essas altas temperaturas têm
trazido grandes prejuı́zos aos apicultores, em especial, aos nordestinos. Portanto, para
obter melhor produção os apicultores devem evitar a enxameação [Almeida 2008].
3. SISMAC
Foi utilizado neste trabalho uma arquitetura IoT denominada SISMAC (Sistema de Mo-
nitoramento Automatizado de Colmeias). A arquitetura do SISMAC é dividida em dois
módulos: O Módulo de Coleta é responsável pela coleta e envio dos dados da colmeia; E
o Módulo de Apresentação que possui a função de processar, armazenar e exibir os dados
coletados.
A Figura 1 apresenta uma ilustração mais detalhada da arquitetura apresentada
anteriormente destacando a interação de sete componentes. Tudo se inicia dentro da col-
meia (1) onde um sensor de temperatura (2) recolhe os dados da colmeia e envia para o
Arduino e Shield Ethernet (3) que interpreta dados e envia informações através da Inter-
net (4) para armazenamento na plataforma Thinger IO (5) e análise na plataforma Keen
IO (6); por fim, os dados são disponibilizados ao cliente (7) em uma aplicação Web e
aplicativo Android.
Ar
dui
no+Shi
ldEt
her
net 5
3
4 Pl
ataf
ormaThi
ngerI
O
I
nter
net
6
SensordeTemper
atur
a
2
Pl
ataf
ormaKeenI
O
1 7
Col
mei
a Cl
ient
e
Figura 1. Diagramas de Interação do SISMAC
4. Experimento
Esta seção descreve os experimentos. Para avaliar o desempenho dos sensores do SIS-
MAC, foi realizado um Design of Experiments (DoE). O DoE (discutido na Subseção
4.1) é um planejamento de experimentos que permite estudar um produto ou processo e
seus fatores associados para identificar quais os fatores que mais influenciam em seu com-
portamento. Assim, é possı́vel obter a melhor configuração e ainda otimizar o produto ou
processo de interesse [Franco 2015].
4.1. Desenho do Experimento

Para a realização de um DoE, o primeiro passo é a definição dos fatores e nı́veis do expe-
rimento. A Tabela 1 apresenta os fatores e nı́veis considerados neste trabalho. O objetivo
238
é identificar o fator com maior impacto na acurácia dos sensores (LM35 e DS18B20) de
temperatura do SISMAC. O próximo passo é combinar os fatores e nı́veis à fim de de-
senhar as especificações de experimentação. Para combinar os fatores e nı́veis definidos
nesse trabalho foi utilizado a ferramenta estatı́stica Minitab 17. O Minitab 17 trata-se de
um software estatı́stico poderoso para analisar dados de forma eficaz [Minitab 2017b]. A
Tabela 2 apresenta as combinações possı́veis que resultou em 16.
Tabela 2. Combinações
No Combinações
1 Manhã - Centro - Parcial - DS18B20
2 Manhã - Centro - Total - DS18B20
3 Manhã - Lateral - Parcial - DS18B20
4 Manhã - Lateral - Total - DS18B20
Tabela 1. Fatores e Nı́veis 5 Manhã - Lateral - Parcial - LM35
Fator Nı́vel I Nı́vel II 6 Manhã - Lateral - Total - LM35
Perı́odo do Dia Manhã Tarde 7 Manhã - Centro - Parcial - LM35
Posição do Sensor Centro Lateral 8 Manhã - Centro - Total - LM35
Presença de Própolis Total Parcial 9 Tarde - Lateral - Parcial - DS18B20
Tipo de Sensor LM35 DS18B20 10 Tarde - Lateral - Total - DS18B20
11 Tarde - Centro - Parcial - DS18B20
12 Tarde - Centro - Total - DS18B20
13 Tarde - Centro - Parcial - LM35
14 Tarde - Centro - Total - LM35
15 Tarde - Lateral - Parcial - LM35
16 Tarde - Lateral - Total - LM35
4.2. Coleta de Dados

Os valores de temperatura foram coletados em um apiário cedido pela cooperativa de api-
cultores da localidade Várzea, situada na cidade de Isaı́as Coelho. A Figura 2 apresenta a
colmeia usada para realização dos experimentos. Para cada combinação (descrito na Ta-
bela 2), foram coletadas 30 medições de temperatura, o que resultou em 480 observações.
Figura 2. Colmeia Monitorada.
As coletas foram realizadas em dois dias. O perı́odo de coletas da parte da manhã

teve inı́cio às 7:30 e término às 10:30, e com inı́cio às 13:00 e término as 16:00 horas pela
tarde. Foi usado um termômetro digital chamado HT332012 (com acurácia de ±0,5o C)
239
para comparação com sensores. O cálculo da acurácia baseou-se na diferença do valor da

medição do termômetro com o sensor. Por exemplo, supondo que o termômetro digital
obteve 35o C, e o sensor avaliado 34,5o C, a acurácia do sensor seria de 0,5.
4.3. Análise de Dados

A Figura 3 apresenta um Gráfico de Pareto para os fatores deste trabalho. O Gráfico
de Pareto descreve a importância de um efeito por seu absoluto valor, dispondo uma
linha vermelha vertical. Cada barra significa o nı́vel de impacto do fator (ou interação de
fatores) sobre a variável dependente. A linha vermelha tracejada representa a magnitude
mı́nima de efeitos estatisticamente significativos (quantificada como 1.97), considerando-
se o critério de significância estatı́stica α = 0.05. Ao passo que a barra do fator transpassa
esta linha, sua influência será maior sobre a variável dependente.
Figura 3. Influências dos Fatores na Acurácia da Medição dos Sensores.
Quando o impacto de um fator é dito alto, quer dizer que alterando o nı́vel daquele
fator são obtidos valores bem distintos. Neste estudo foi observado que os fatores com
impactos mais elevados sobre a acurácia foram: Posição do Sensor e Tipo de Sensor. A
Posição do Sensor possui maior impacto dentre todos os fatores. Portanto, a localização
do sensor é determinante na confiabilidade da medição. Dado que se sabe os fatores com
maiores impactos, o próximo passo é saber quais nı́veis tiveram melhores resultados.
A Figura 4 apresenta os efeitos de cada fator na acurácia dos sensores, usando
o Gráfico de Efeitos Principais. O gráfico de Efeitos Principais é usado para demons-
trar, detalhadamente, como um ou mais fatores categóricos influenciam em uma resposta
contı́nua. Tal gráfico apresenta inclinações (coloridas em azul) entre as variáveis inde-
pendentes estudadas. Os valores decrescentes 8, 6, 4 e 2 representam a proximidade com
o valor de temperatura do termômetro (em Co ). Quanto mais inclinada for a linha, maior
o impacto sobre a variável dependente.
O sensor situado na posição central da colmeia apresenta aumento de acurácia
dos sensores por estar situado em um ponto sem dispersão de temperatura. As abelhas
se situam no centro buscando se defender contra o aumento de temperatura ocasionados
pelas bordas da colmeia. Nas bordas da colmeia, a temperatura sofre mais influência do
ambiente externo.
12
Instrumentos: goo.gl/4NK1x4
240
Figura 4. Gráfico de Efeitos Principais para Acurácia dos Sensores.
Em termos do Tipo de Sensor, o sensor DS18B20 teve melhor resultado. O sensor

DS18B20 tem circuito protegido por uma cápsula de metal, enquanto que o sensor LM35
não. Acreditamos que a não proteção do sensor LM35 faz com que ele fique sujeito a
interferência das abelhas.
Esta seção apresenta os trabalhos relacionados ao presente estudo. Para melhor
visualização, a Tabela 3 elenca três fatores comparativos: DoE, Propriedades Monito-
radas e Plataforma. A seguir estes fatores são comentados.
Tabela 3. Comparativo entre Trabalhos Relacionados.

Trabalho DoE Propriedades Monitoradas Plataforma
[Almeida 2008] Não Atividades de vôo, Temperatura e Umidade Web
[Meitalovs et al. 2009] Não Temperatura e Umidade Software Local
[Eskov e Toboev 2011] Não Temperatura Nenhuma
[Sombra et al. 2013] Não Ação do Sol, Temperatura e outras Nenhuma
[Stalidzans e Berzonis 2013] Não Temperatura Software Local
[Kridi et al. 2014] Não Temperatura Nenhuma
[Nominato 2015] Não Doses de Inseticidas Nenhuma
[Kviesis et al. 2015] Não Temperatura e Umidade Web
[Edwards-Murphy et al. 2016] Não Temperatura, Umidade e Gases Software Local
[Dutra 2016] Não Temperatura, Umidade e outras Web
[Kridi et al. 2016] Não Temperatura Software Local
[Rolke et al. 2016] Não Alimentação de Colza Nenhuma
Nosso Estudo Sim Temperatura Web e Aplicativo Android
• DoE: O Design of Experiments é uma ferramenta poderosa de análise estatı́stica,

pois diminui o trabalho em repetir experimentos. Os trabalhos relacionados en-
contrados não fizeram uso desta abordagem e simplesmente fizeram comparações
com fatores de forma individual e não agrupada.
• Propriedades Monitoradas: este critério designa as caracterı́sticas acompanha-
das pelas soluções de monitoramento de colmeias. Alguns trabalhos focaram es-
pecificamente em temperatura tal qual nosso estudo como [Eskov e Toboev 2011],
[Stalidzans e Berzonis 2013], [Kridi et al. 2014] e [Kridi et al. 2016]. Outros tra-
balhos além da temperatura, adicionaram outras propriedades como, por exem-
plo, a umidade ([Almeida 2008], [Meitalovs et al. 2009], [Sombra et al. 2013],
241
[Kviesis et al. 2015], [Edwards-Murphy et al. 2016] e [Dutra 2016]). Um es-

tudo especı́fico realizou uma Análise de Sensibilidade (sem DoE) conside-
rando Doses de Inseticidas [Nominato 2015] e outro com Alimentação de Colza
[Rolke et al. 2016], porém, não trataram da temperatura ou outras propriedades.
• Plataforma: a plataforma designa o meio de acesso das medições de tempe-
ratura. Parte dos trabalhos relacionados não implementaram sistema ou plata-
forma. Apenas os trabalhos [Meitalovs et al. 2009], [Stalidzans e Berzonis 2013],
[Edwards-Murphy et al. 2016] e [Kridi et al. 2016] implementaram um software
local para monitoramento de colmeias, usando conexão serial ou wireless sem
compartilhamento na Internet; Os trabalhos [Almeida 2008], [Kviesis et al. 2015]
e [Dutra 2016] deram acesso ao sistema por uma plataforma Web, somente. Nosso
trabalho possibilitou monitoramento por plataforma Web e Android.
Este trabalho difere-se dos demais pois teve como objetivo realizar uma análise de sensi-
bilidade sobre a acurácia da temperatura em colmeias. Foi verificado os fatores e nı́veis
que interferem na acurácia, a partir da combinação dos mesmos, utilizando o método
estatı́stico DoE. Além disso, diferente dos trabalhos relacionados o nosso sistema está
disponı́vel para plataforma Web e Mobile.
6. Conclusão
Este artigo apresentou uma análise de sensibilidade sobre a acurácia de sensores de tempe-
ratura em colmeias. Para a análise de sensibilidade foi usado o método estatı́stico DoE. Os
experimentos mostraram que a Posição do Sensor e Tipo de Sensor tiveram maior impacto
na acurácia medida. A Posição do Sensor no nı́vel Central retornou maior acurácia por
conta de não sofrer interferência externa. Em termos de sensores, o sensor DS18B20 teve
melhor acurácia, por apresentar componentes fı́sicos com melhor adaptação ao meio de
medição. Combinando os dois fatores têm-se que o sensor DS18B20 sediado na posição
central da colmeia é a configuração estatisticamente mais adequada para monitoramento
de temperatura. A arquitetura SISMAC é montada com base nesta configuração obser-
vada nas experimentações. Como trabalho futuro, pretende-se testar outros sensores e
observar outras espécies de abelhas já que algumas são mais mais agressivas que outras.
Referências
Almeida, G. F. (2008). Fatores que interferem no comportamento enxameatório de
abelhas africanizadas. 2008. 120 f120. PhD thesis, Tese (Doutorado em Ciências)–
Faculdade de Filosofia, Ciências e Letras de Ribeirão Preto, Ribeirão Preto.
Dutra, T. F. S. (2016). Beehiveior-sistema de monitoramento e controle de colmeias de
produção apı́cola. Master’s thesis, Brasil.
Edwards-Murphy, F., Magno, M., Whelan, P. M., O’Halloran, J., e Popovici, E. M. (2016).
b+ wsn: Smart beehive with preliminary decision tree analysis for agriculture and
honey bee health monitoring. Computers and Electronics in Agriculture, 124.
Eskov, E. e Toboev, V. (2011). Seasonal dynamics of thermal processes in aggregations
of wintering honey bees (apis mellifera, hymenoptera, apidae). Entomological review,
91(3):354–359.
Franco, G. (2015). Entenda o que é doe – design of experiments Disponı́vel em:
http://www.escolaedti.com.br/entenda-o-que-e-doe/. Acesso em: 13/08/2017.
242
Freitas, D. G. F., Khan, A. S., e Silva, L. M. R. (2004). Nı́vel tecnológico e rentabili-

dade de produção de mel de abelha (apis mellifera) no ceará. Revista de Economia e
Sociologia Rural, 42(1):171–188.
GloboRural (2016). Especialista dá dicas para manter produção de mel em climas extre-
mos. In Especialista dá dicas para manter produção de mel em climas extremos.
Kridi, D. S., Carvalho, C. G. N. d., e Gomes, D. G. (2014). A predictive algorithm for
mitigate swarming bees through proactive monitoring via wireless sensor networks. In
Proceedings of the 11th ACM symposium on Performance evaluation of wireless ad
hoc, sensor, & ubiquitous networks, pages 41–47. ACM.
Kridi, D. S., de Carvalho, C. G. N., e Gomes, D. G. (2016). Application of wireless sensor
networks for beehive monitoring and in-hive thermal patterns detection. Computers
and Electronics in Agriculture, 127:221–235.
Kviesis, A., Zacepins, A., Durgun, M., e Tekin, S. (2015). Application of wireless sensor
networks in precision apiculture. In Proceedings of the 14th International Scientific
Conference Engineering for Rural Development (ERDev), Jelgava, Latvia.
Meitalovs, J., Histjajevs, A., Stalidzans, E., et al. (2009). Automatic microclimate control-
led beehive observation system. In 8th International Scientific Conference Engineering
for Rural Development, pages 265–271.
Minitab (2017a). Designing an experiment. Disponı́vel em: support.minitab.com/en-
Minitab (2017b). Minitab statistical software.
Murphy, F. E., Popovici, E., Whelan, P., e Magno, M. (2015). Development of an he-
terogeneous wireless sensor network for instrumentation and analysis of beehives. In
Instrumentation and Measurement Technology Conference (I2MTC), 2015 IEEE Inter-
national, pages 346–351. IEEE.
Nominato, F. C. (2015). Análise do efeito de inseticidas neonicotinóides sobre a
orientação e coleta de alimento de operárias de apis mellifera l.
Oliveira, P. S. (2010). Relação da composição quı́mica com a origem geográfica e ativi-
dade antioxidante de méis de meliponı́neos e apis mellifera produzidos no estado do
pará. Master’s thesis, Dissertação (Mestrado) – Universidade Federal do Pará. Instituto
de Ciências Exatas e Naturais. Programa de Pós-graduação em Quı́mica, Belém.
Rolke, D., Fuchs, S., Grünewald, B., Gao, Z., e Blenau, W. (2016). Large-scale mo-
nitoring of effects of clothianidin-dressed oilseed rape seeds on pollinating insects in
northern germany: effects on honey bees (apis mellifera). Ecotoxicology, 25(9).
Sombra, D. d. S. et al. (2013). Monitoramento do desenvolvimento de colônias de abe-
lhas africanizadas sobre a influência do sol e sombra na região semiárida do nordeste
brasileiro (mossoró-rn).
Stalidzans, E. e Berzonis, A. (2013). Temperature changes above the upper hive body re-
veal the annual development periods of honey bee colonies. Computers and electronics
in agriculture, 90:1–6.
243
Rootsbot
Abstract. Educational Robotics is a very interesting pedagogical resource

which motivates a part of the students in their activities. However, the asso-
ciation of a particular subject with a robotic application should not be easy.
This work presents a low-cost small mobile robot developed to support the re-
solutions of second-order polynomial equations aiming to enhance the learning
of this elementary mathematics topic at the fundamental level 2.
Keywords: Educational Robotics, Elementary Education Level 2, Second Order
Polinomials Equations
Resumo. A Robótica Educacional é um recurso pedagógico bastante interes-

sante pois motiva boa parte dos alunos em suas atividades. Porém, nem sem-
pre é fácil associar um conteúdo de uma disciplina especı́fica a uma aplicação
robótica. Este trabalho apresenta um pequeno robô móvel de baixo custo desen-
volvido para servir de apoio às resoluções de equações polinomiais de segundo
grau com objetivo de impulsionar o aprendizado deste tópico da matemática
elementar no nı́vel fundamental 2.
Palavras-chave: Robótica Educacional, Ensino Fundamental 2, Equações do
Segundo Grau
1. Introdução
A robótica educacional como base de um ensino tecnológico tem se tornado um recurso
pedagógico bastante estimulante para professores e alunos, dentro de um novo cenário na
escola tradicional. Segundo (Piaget, 1972), é importante que o indivı́duo construa o seu
próprio conhecimento a partir da iteracão com o ambiente em que vive, proporcionando o
desenvolvimento e uma maior significação da aprendizagem. As diretrizes do ensino que
utiliza a robótica como suporte pedagógico estabelece esta possibilidade de construção e
aprendizagem.
A utilização da robótica educacional em sala de aula tem aumentado o interesse
dos estudantes nas atividades letivas promovendo um maior aprendizado dos conteúdos
escolares. O ensino da matemática, como integrante desta realidade, não fica de fora e
recebe propostas inovadoras como forma de motivar os jovens que fazem uso diário das
novas tecnologias. Mas, o grande desafio para os professores é associar boa parte dos
conteúdos com uma aplicação robótica.
Este artigo apresenta o Rootsbot, um pequeno robô móvel de baixo custo cons-
truı́do para aplicações educacionais com fins didáticos para ser utilizado nas escolas
públicas de Picos. Os movimentos do Rootsbot dependem basicamente da resolução cor-
reta de equações do segundo grau. Algumas considerações são apresentadas a partir de
uma oficina de experimentação realizada com alunos do curso de Matemática da UFPI.
2. Robótica Livre e suas Aplicações

A utilização de kits comerciais de robótica educacional quase sempre esbarra no custo
proibitivo para montagem de um laboratório de robótica numa escola pública. Diante
desta realidade, busca-se alternativas de diversos tipos. Uma das alternativas que tem se
244
tornado bastante popular é a construção de robôs, utilizando uma plataforma de hardware

livre e mais uma série de materiais alternativos de baixo custo.
Kits de robótica livre apresentam uma solução à difusão das aulas de robótica
educacional nas escolas brasileiras, permitindo que a robótica esteja ao alcance de todos.
Eles são compostos por equipamentos eletrônicos, como motores e sensores, que podem
ou não ser retirados de equipamentos tecnológicos, como computadores e sons. A carcaça
do robô é, em sua maioria, composta por elementos de sucata, segundo (C. C. Fernandes,
S. T. Sá, L. M. G. Gonçalves, 2012).
Um problema recorrente quando da utilização de um kit de robótica livre é a
programação do robô construı́do. Uma outra questão inerente é a aplicação deste robô,
dentro do contexto da sala de aula. Aliar o uso deste dispositivo motivador a um dos
tópicos a ser estudado dentro do conteúdo das diversas disciplinas, é um grande desafio
para os professores. No âmbito da matemática, apesar de ser um dos fundamentos da
ciência robótica, nem sempre esta associação ao conteúdo é feita de forma direta.
A utilização de robôs na área de ensino não é novidade. Alguns trabalhos apontam para
esta direção. Embora boa parte das referências, utilizem kits comerciais como o kit da
LEGO para utilização no ensino especı́fico da matemática. Neste tópico será apresentado
sem minúcias alguns trabalhos que foram desenvolvidos na tentativa de aliar a utilizacão
da robótica à uma determinada aplicacão na matemática.
(Silva, Silva e Silva, 2015) relataram a experiência de uma aula usando robôs, as-
sociando as áreas de matemática, robótica e educação no trânsito, que teve intuito de pri-
orizar a fixação do conteúdo de números inteiros e a formacão cidadã dos indivı́duos. (Ri-
beiro, Coutinho e Costa, 2011) realizaram uma oficina usando a Plataforma Lego Minds-
torms para ensinar conteúdos que envolviam multiplicação, divisão e proporcionalidade
entre medidas de tempo, distância, rotação e ângulo. (Almeida, 2007) desenvolveu um
projeto com professores da rede pública de ensino usando um robô de baixo custo, para
explorar conceitos de Matemática, como poliedros, polı́gonos, áreas, volumes, ângulos, e
outros.
(Araújo, Santos e Meireles, 2017) realizaram uma investigação no campo experi-
mental da educacão e matemática, utilizando o kit de robótica educacional LEGO Minds-
torms. Programaram os robôs para realizar algumas trajetórias, com intuito de observar os
movimentos e identificar padrões geométricos como, noções de ângulos, raio, diâmetro,
cálculo da distância percorrida e regra de três simples. (Fagundes, Pompermayer, Basso
e Jardim, 2005) ministraram um projeto com alunos envolvendo conceitos de matemática
e fı́sica usando o kit de robótica educacional LEGO Mindstorms. Os principais assun-
tos desenvolvidos foram aritmética, geometria, números positivos e negativos, frações,
razão, rigidez e lógica. Depararam-se com termos como movimentos e deslocamentos
que envolvem distâncias e amplitudes de rotacão.
4. O Rootsbot
Entrevistas preliminares com alunos do 9o Ano, apontam o tópico de equações do 2o grau
como um dos mais interessantes e difı́ceis do conteúdo de matemática visto durante o
245
ano. A ideia de inserir um robô neste contexto de aprendizado, traz à tona o conceito de
robótica educacional e ensino tecnológico. Apresentar este recurso como algo lúdico e
ao mesmo tempo, desafiador e que seja capaz de despertar a atenção dos alunos para a
aprendizagem deste tópico, está associada à observação do fascı́nio que a robótica exerce
em crianças e adolescentes. A figura 1 mostra o Rootsbot.
Figura 1. Rootsbot.
O Sistema proposto orbita dentro do espaço da robótica livre e é formado por um

protótipo de um pequeno robô móvel e um software de testes com estágios de controle
e comunicação, construı́do para este fim. E este pequeno robô móvel é capaz de exibir
sua mobilidade, seguindo para frente, para trás ou virando à direita ou à esquerda. Sua
aplicação nos domı́nios da Matemática está aliada ao tema de resolução de equações do
segundo grau.
4.1. O Robô
Dentro da ideia de construir um dispositivo de baixo custo, o Rootsbot é um pequeno
robô móvel diferencial com três rodas, sendo duas tracionadas e uma roda cega. As rodas
tracionadas são movidas por motores DC e controladas por uma placa Arduino com o
auxı́lio de uma Ponte H. Na primeira versão a placa utilizada é um Arduino UNO, o
circuito driver Ponte H é o L-298 e o módulo de comunicação Bluetooth é um módulo
HC05. A figura 2 mostra o circuito do Rootsbot.
4.2. O Software
O software de controle do Rootsbot leva em consideração o propósito para o qual, o
mesmo foi projetado. Partindo do princı́pio que o ”combustı́vel”do robô são raı́zes e que
ele se alimenta das raı́zes de equações do segundo grau, a concepção do software primou
por oferecer um desafio para os estudantes, gerando de forma aleatória equações para
resolução. Uma vez gerada a equação, o sistema fornece um tempo para que as raı́zes
sejam fornecidas em local apropriado.
246
Figura 2. Hardware do Rootsbot.
A arquitetura do sistema apresenta um módulo randômico de geração de equações,

responsável pela geração de equações do segundo grau, respeitando os seguintes requisi-
tos:
1. O sistema gera apenas equações com coeficientes reais;
2. O sistema tem restrições internas que não habilitam equações com raı́zes comple-
xas.
Tais restrições foram postas devido a aplicação do Rootsbot para alunos do 9o ano
do ensino fundamental 2.
Para a verificação, foi criado um módulo solucionador de equações para checar
se as raı́zes fornecidas fazem parte do conjunto solução da equação proposta. Uma vez
fornecidas as raı́zes, este módulo checa a veracidade da solução e congratula o aluno caso,
a resposta esteja correta. caso a resposta esteja errada, o módulo gera uma mensagem de
apoio e incentiva uma nova tentativa. É preciso deixar claro que o sistema não resolve
as equações se o usuário não se dispor a resovê-las. Isso reforça a sua utilização como
recurso didático, capaz de incentivar a resolução de exercı́cios de equações do segundo
grau. A figura 3 mostra a arquitetura do sistema.
Quando as respostas fornecidas estão corretas, o sistema habilita o módulo de
comunicação e a partir daı́, este transmite via Bluetooth, as raı́zes para o robô que vai re-
ceber esses números e transformá-los em movimento, acionando os seus motores e dando
partida, no caso da primeira solução ou continuando seus movimentos, a partir da se-
gunda solução. O objetivo do Rootsbot nesta aplicação é motivar o estudo e a resolução
de equações do segundo grau. Quanto maior for o nı́vel de acerto do aluno ou equipe,
mas longe o Rootsbot chegará.
A figura 4 mostra a tela inicial e as opções de menu existentes no estágio atual
da construção do software. O número limitado de opções não impede o funcionamento
básico do sistema. Este software foi criado especificamente para que o aluno interaja
com o robô, no intuito de motivá-lo no estudo de equações. Existem opções para ”Gerar
Equações”, ”Verificar Solução”, ”Salvar” ou ”Imprimir” as equações resolvidas. É dispo-
nibilizado também a opção ”Help” para orientar o estudante sobre como usar o aplicativo
do Rootsbot. Na opção ”Transmissão”, o aluno pode, uma vez resolvida a equacão do 2o
247
Figura 3. Arquitetura proposta para o Sistema do Rootsbot.
grau e verificada, transmitir as raı́zes para o robô, conectado via Bluetooth.
Figura 4. Tela 1 do Software de Controle do Rootsbot.
A figura 5 exibe uma equação proposta para resolução gerada pelo sistema. Ao
resolver a equação proposta, o aluno tem a oportunidade de checar o seu sucesso ativando
a opção de verificação disponibilizada na interface. Uma vez acolhida a sua resposta o
sistema emite uma caixa de mensagem parabenizando o aprendiz pelo o acerto e ativa o
modo de comunicação para que possa enviar as raı́zes para o dispositivo robótico. Nesse
momento, vai estar abastecendo o robõ para que o mesmo possa iniciar seu movimento.
248
Figura 5. Tela 2 do Software de Controle do Rootsbot.
5. Resultados Preliminares e Considerações Finais

Devido ao fato do primeiro estágio deste projeto ter ficado pronto recentemente, os testes
iniciais de utilização do dispositivo foram realizados com alunos do curso de Matemática
da Universidade. O Rootsbot causou uma boa impressão entre alunos e professores do
curso. Seu sistema foi recebido como um jogo que desafia os jogadores a resolverem as
equações propostas para abastecerem o robô. O número de acertos nas equações propostas
pelo sistema, torna o movimento do robô no plano fı́sico, uma realidade.
Figura 6. Opinião dos alunos sobre o auxı́lio da robótica no ensino da ma-

temática.
A figura 6 mostra os resultados das primeiras avaliações feitas com alunos de

nı́vel superior. É preciso dizer que o foco de orientação dos trabalhos são alunos no nı́vel
fundamental 2. O gráfico mostra a porcentagem de alunos que consideraram como de
muito auxı́lio, o uso de robótica no ensino de matemática.
A figura 7 mostra o resultado da opinião dos alunos referente a utilização de robôs
no apoio à aprendizagem de matemática, caso do Rootsbot.
249
Figura 7. Gráfico 2.
A pesquisa em andamento, projeta testes na Escola, logo após a volta às aulas
neste segundo semestre de 2017. Contatos prévios com professores de Escolas Públicas
já foram feitos e o projeto apresentado para diretores, coordenadores e professores de
Matemática. Espera-se que os alunos rendam-se ao fascı́nio da Robótica e demostrem
interesse em conhecer o dispositivo proposto.
O sistema do Rootsbot será refinado, a partir da realimentação com as impressões
inicialmente colhidas, durante os primeiros testes.
6. Agradecimentos
Um agradecimento especial ao aluno do curso de Sistemas de Informação, Natanael Mi-
randa e a professora Luzia Custódio do ensino fundamental 2 por ter cedido os livros
e o material do professor para nossa consulta e a todos alunos e professores da Escola
Estadual Landri Sales, pela consulta inicial do projeto. E agradecemos ainda aos alunos
do curso de Matemática da UFPI, do Campus de Picos pela disposição em participar das
primeiras avaliações com o Rootsbot.
Este trabalho foi desenvolvido no LIPPO - Laboratório de Investigação e Pesquisa
em Poéticas Digitais do Curso de Sistemas de Informação da UFPI, no Campus do Junco,
na cidade de Picos.
7. Referências
S. do Rocio, Zilii (2004). A robótica educacional no ensino fundamental: perspectivas e
prática. Dissertação de Mestrado, UFSC – Centro Tecnológico, PPGEP, 2004.
L. Tortelli et al (2012). Robótica como alternativa nos processos educativos da Educação
Infantil e dos Anos Iniciais do Ensino Fundamental. In XVIII Congresso Argentino de
Ciencias de la Computación. 2012.
250
C. C. Fernandes, S. T. Sá, L. M. G. Gonçalves (2012). Uma nova abordagem em Robótica

Educacional utilizando Simuladores e Kits de Robótica Livre. In Anais do III WRE,
Fortaleza. (2012).
J. Piaget (1972). Psicologia e pedagogia. Forense Universitária, Rio de Janeiro, RJ. 1972.
H. R. Silva, S. F. Silva e J. R. Silva (2015). Robótica e Matemática na Formação para a
Cidadania – Associando Números Negativos e Educação no Trânsito. Mostra Nacional
de Robótica (MNR). 2015.
C. A. P. Araújo, J. da P. Santos, J. C. de Meireles (2017). Uma proposta de investigação
tecnológica na Educação Básica: aliando o ensino de Matemática e a Robótica Educacio-
nal. In Revista Exitus 7.2: 127-149. 2017.
C.A. N. Fagundes, E. M. Pompermayer e M. V. A. Basso (2005). Aprendendo Matemática
com Róbotica. Novas Tecnologias na Educação. CINTED-UFRGS. Porto Alegre. 2005.
M. A. Almeida (2007). Possibilidades da robótica educacional para a educação. Curitiba,
Paraná. 2007.
C.Ribeiro, C. Coutinho e M. F. Costa (2011). A Robótica Educativa como Ferramenta
Pedagógica na Resolução de Problemas de Matemática no Ensino Básico. 2011.
251
Desenvolvimento de uma bateria musical eletrônica sem fio

com arduino e android
Marcos. S. Oliveira1 , José. V. M. Sousa1 , Aratã. A. Saraiva1
1
Universidade Estadual do Piauı́, Piripiri, Brasil.
{marquinhoscamaleao,josevigno,aratasaraiva}@gmail.com
Abstract. This work presents the development of a low-cost electronic prototype

of electronic music drums. The touch of the drumstick on a handmade pad
is captured by piezoelectric sensors connected to the Arduino platform. The
Arduino is used to receive and process the signal from the sensors and send
through a Bluetooth connection the corresponding signal from each pad in real
time to an application developed for Android device and thus to simulate the
main sounds of a real acoustic battery. The results demonstrate a satisfactory
operation and allows in the future the assembly of versions with more advanced
features.
Key words: Electronic battery; Cost; Arduino; Android; Bluetooth
Resumo. Este trabalho apresenta o desenvolvimento de um protótipo eletrônico

de baixo custo de bateria musical eletrônica. O toque da baqueta do baterista
em um pad artesanal é captado por sensores piezoelétricos conectados a plata-
forma Arduino. O Arduino é usado para receber, processar o sinal dos sensores
e enviar através de uma conexão Bluetooth, o sinal correspondente de cada
pad em tempo real para um aplicativo desenvolvido para dispositivo Android e
assim simular os sons principais de uma bateria acústica real. Os resultados
demonstram um funcionamento satisfatório e permite que futuramente a monta-
gem de versões com mais recursos avançados.
Palavras-chave: Bateria eletrônica; Custo; Arduino; Android; Bluetooth
1. Introdução
O uso de instrumentos musicais para diversão no dia a dia das pessoas é cada vez mais
comum, sendo um excelente hobby aprender a tocar um instrumento musical. Algumas
das vantagens deste hábito são: o alı́vio do estresse do dia a dia, o aumento de habilidades
fı́sicas, mentais e motoras, como é o exemplo da bateria musical.
A bateria musical convencional é um instrumento formado por um conjunto de
tambores e pratos de diferentes tamanhos e espessuras, no qual o usuario denominado
baterista, utiliza as baquetas para percutir o instrumento e produzir os sons, porém ela é
considerada um tanto inadequada em alguns ambientes devido ao seu tamanho e ao seu
alto volume sonoro.
Em contrapartida foi lançada em 1976, a primeira bateria eletrônica musical, a
Sydrum Pollard, formada por um módulo eletronico e tambores[Almeida and Fressatti ],
tornando-se o estopim para o desenvolvimento de versões cada vez melhores.
Hoje, as baterias musicais eletrônicas nas versões mais modernas, além de robus-
tas, possuem uma alta qualidade sonora, chegando a reproduzir sons quase idênticos a
252
versão convencional. Porém, o seu elevado custo, mesmo quando se trata de uma versão
mais simples, impossibilita que pessoas com baixa renda possuam um exemplar.
Por outro lado, com a grande facilidade de acesso a tecnologia nos dias atuais,
onde se destacam em grande maioria os celulares, e por estes dispositivos utilizarem o
sistema operacional Android[GOMES et al. 2012], plataforma conhecida por ser de uso
livre, o desenvolvimento de aplicativos que simulem instrumentos musicais ficou bastante
facilitado, inclusive para os celulares de baixo custo.
Nas baterias musicais eletrônicas é comum a utilização de vários fios para a trans-
missão do sinal de cada pad ao módulo de processamento central, que podem por ventura,
se romper ou sofrer danos caso não sejam manuseados de forma correta. Este problema
pode ser solucionado utilizando uma conexão wireless[Lee et al. 2007], na qual propor-
ciona uma redução no uso de fios total ou parcial.
A plataforma Arduino[McRoberts 2011],também conhecida por ser uma plata-
forma livre, é utilizada cada vez mais para prototipação dos mais diversos tipos de proje-
tos e disponibiliza uma vasta gama sensores e módulos disponı́veis, como por exemplo o
módulo bluetooth, dispositivo que permite a comunicação sem fio a outros equipamentos
compatı́veis como o celular, demonstrando assim ser bastante viável ao projeto.
O objetivo do nosso trabalho é demonstrar o protótipo de bateria musical
eletrônica de baixo custo, produzida a partir da utilização da plataforma Arduino, em
conexão com um aplicativo desenvolvido para plataforma Android por meio de conexão
bluetooth [Haartsen 2000].
No trabalho apresentado por [Chedid 2015], foi implementado um protótipo expe-
rimental de bateria eletrônica musical sem fio. O autor utilizou sensores piezos
elétricos[Nadalin et al. 2007] para captação das batidas dos usuários, um microcontrola-
dor PIC[Martins 2005] para o tratamento e conversão dos sinais analógicos para digitais,
um Arduino[McRoberts 2011] como módulo central de processamento e por fim utilizou
módulos XBee[Faludi 2010] para transmissão por meio de radio frequência.
Porém nesta abordagem do autor, foi utilizado para cada pad da bateria como
um pequeno sistema sem fio separado, desse modo, para cada tom temos em conexão um
circuito com um sensor piezo elétrico, um microcontrolador PIC e mais um módulo XBee,
além do mais, é necessário o uso de um arduino com um outro módulo XBee para receber
os dados de todos os módulos presentes nos tons, e daı́ em diante passar a reproduzir o
som armazenado em um cartão SD em baixa qualidade.
Apesar de ser uma tecnologia de boa eficiencia, a tecnologia Xbee ainda possui
um preço elevado no brasil, e utilizar um exemplar para cada pad no projeto se mostra
inviável devido ao seu alto orçamento final.
Já [Almeida and Fressatti ], demonstra em sua abordagem uma maneira mais sim-
ples, o autor utilizou sensores piezos elétricos em cada pad, em seguida, diferente do
método citado anteriormente, ele conectou cada pad diretamente ao Arduino, para con-
versão dos sinais, mas, por outro lado é necessário a conexão do arduino com um com-
putador por meio de conexão serial, para que os dados sejam convertidos e reproduzidos
através de softwares instalados no computador.
253
Neste trabalho o autor mostra uma solução de baixo custo para o circuito de cada
pad se utilizando apenas de fios de conexão ao Arduino, mas, ao utilizar softwares de
computador para executar seus sons, demonstrando assim a sua dependencia de conexão
fı́sica, o que dificulta a sua mobilidade, algo diferente do projeto proposto.
Na abordagem de [Hsiao and Huang 2013] é descrito um método semelhante com
piezo elétrico e um Arduino conectado a um computador, porém neste caso, é demons-
trado a sua aplicação em dois tipos de casos. No primeiro caso foi demonstrado a sua
aplicação na construção de um pad de bateria musical eletrônica levando em consideração
a velocidade com que o usuário utilize sua baqueta, já no outro caso, o autor mostra a
aplicação do mesmo, desta vez como captador de contato para um violão acústico, de-
monstrando neste sentido que há uma vasta utilidade para esse tipo de sistema.
O projeto citado no paragrafo acima tanbém demonstra um certo nı́vel de depen-
dencia fı́sica dos equipamentos, mas, em especial um fator interessante ao projeto pro-
posto é o reconhecimento da velocidade da batida do usuário, mostrando-se bem usual,
por outro lado na abordagem do trabalho proposto neste artigo é mais viável especiali-
zar o sistema apenas como instrumento, para assim evitar um custo maior de poder de
processamento.
Dada a tarefa de protótipar uma bateria musical eletrônica, foi iniciado uma pesquisa
de viabilidade de componentes eletrônicos de fácil utilização, precisão e baixo consumo
de energia, que atendessem as necessidades do projeto. Como alicerce, foi escolhido a
plataforma open source Arduino, que além de ser de baixo custo, é livre e proporciona
a facilidade de utilização de seus vários tipos de sensores, shields e comunicação com
outros dispositivos.
O Arduino escolhido é mais especificamente o Arduino Mega
2560[Arduino and Mega 2016]. A placa possui o microcontrolador ATMEL ATmega
2560, no qual dentre suas vantagens, destacam-se: o maior espaço de memória, maior
capacidade de processamento e baixo consumo energético, o ideal para o processamento
dos pulsos elétricos dos sensores exigido para tarefa.
Os sensores utilizados para captação das batidas do musico em cada tom durante a
performance, são chamados sensores piezo elétricos, que são discos capazes de gerar uma
corrente elétrica quando recebem uma pressão mecânica sobre eles, possibilitando medir
a intensidade da força aplicada com a batida sobre ele, fator importante por exemplo, para
controlar o volume de cada toque.
O Arduino com suas limitações não permite a reprodução de sons simultâneos em
alta qualidade, devido à sua arquitetura de baixo processamento. Para que a necessidade
de um alto processamento fosse atendida, foi desenvolvido um aplicativo para um celular
com sistema operacional Android, visando sanar a necessidade de processamento. A
escolha se deu pelas suas vantagens como: ser uma plataforma de código aberto, fácil de
desenvolver e os softwares gerados disponı́veis na internet podem ser facilmente baixados.
Para que as duas plataformas se comuniquem em tempo real, é usado
como intermediário a conexão bluetooth, uma tecnologia capaz de enviar e rece-
ber mensagens a curta distância e sem custos bastante presente nos artefatos móveis
254
digitais[Medeiros 2011]. Em especial, para este projeto foi escolhido o módulo HC-06
para determinada tarefa, este dispositivo cobre uma área de até 10 metros, funciona com
tensão de 3,6 a 6v além de possuir baixo custo.
O software desenvolvido para o arduino, avalia constantemente o sensor piezo
elétrico, no qual seus valores provenientes de cada batida são os principais ativadores de
cada som. Quando o software verifica a cada iteração se o valor do piezo está diferente
de zero, caso esteja, o software então envia um sinal via bluetooth com a informação de
qual piezo ativado e volta ao inicio da iteração.
Os dados do arduino são recebidos e processados em tempo real pelo aplicativo
instalado em um dispositivo Android, o aplicativo tem como vantagem uma base de dados
com sons de alta qualidade captados de uma bateria acústica convencional.
Ao abrir o aplicativo o usuário será solicitado a permissão para ativar o blueto-
oth, logo após ativado o usuário poderá ter acesso a lista de dispositivos disponı́veis, em
seguida ao selecionar nesta lista o bluetooth do arduino o aplicativo esta pronto para uso.
O aplicativo no celular é pronto para receber constantemente os dados na conexão
com o arduino, quando os dados sçao recebidos, o aplicativo decide a partir do comando
qual som deverá ser executado e de maneira simultanea a reprodução do som, continua a
espera de novos comandos do bluetooth, possibilitando desta forma a reprodução de sons
simultâneos, assim um ou mais de dois tons poderão ser ouvidos quando percutidos ao
mesmo tempo.
Terminado toda esta etapa iniciou-se o teste principal, para utilização neste teste
foi montado apenas um tom, produzido com matérias baratos e fáceis de encontrar, os
materiais escolhidos foram, Dvd’s e E.V.A.
Para montagem do tom utilizou-se dois dvd’s, foi colocado acima e entre eles
E.V.A para que ficasse uma espaço para ser adicionado o sensor piezo elétrico e para
que melhore a captação deste sensor. Com este espaço, ao receber uma batida sobre sua
superfı́cie o dvd tem a capacidade de vibrar, possibilitando uma noção básica da força
durante cada batida pela captação do sensor.
Os componentes eletrônicos foram montados conforme conhecimento adquirido
em fóruns especializados no assunto, todos os equipamentos podem ser adquiridos em
uma loja de componentes local ou mais facilmente encontrados em lojas online e tem
um extenso material sobre a utilização e os cuidados que se deve tomar para proteger o
circuito. abaixo é demonstrado o diagrama de circuito do protótipo.
255
Figura 1. Pad artesanal. Fonte: imagem do autor.
4. Resultados
Como resultado foi possı́vel verificar que o protótipo de instrumento musical atende ao
requisito principal de ser um protótipo de baixo custo e teve resultado bastante satisfatório.
O pad criado é básico de construir, o material necessário é de baixo custo e pode
ser encontrado facilmente, além disso, o sensor piezo elétrico instalado entre as camadas
do pad foi capaz de captar o impacto da batida do usuario, assim como a sua intensidade
conforme a sua localização no pad, e a quantidade de camadas amortecedoras(E.V.A) do
impacto das baquetas, deixando em aberto a possibilidade de estudos mais aprofundados
de uma captação mais realista do sistema. Abaixo (figura 2) é demonstrado a imagem do
pad construı́do.
Figura 2. Pad artesanal. Fonte: imagem do autor.
256
O aplicativo desenvolvido (figura 3) para a reprodução dos sons é simples, e de

fácil uso, de modo que o usuário apenas precisará iniciar o aplicativo, conectar-se ao
bluetooth do Arduino e começar a sua perfomance com sons de bateria convencional
de alta qualidade. Para efeito de análise durante os testes de perfomance, o custo de
processamento e consumo de bateria do aplicativo no celular se mostrou baixo.
Figura 3. Interface do aplicativo. Fonte: imagem do autor.
No geral o protótipo desenvolvido ilustrado na figura 4 atendeu as metas espera-

das, estas que se resumem em baixo custo e boa capacidade de realizar a determinada
tarefa. No entanto, entre os vários testes, notou-se que durante a comunicação entre o
aplicativo e o Arduino foi comum um atraso na razão de 50 milissegundos.
Figura 4. Protótipo. Fonte: imagem do autor.
5. Conclusão
Um protótipo de instrumento musical viável economicamente foi projetado e usado para
transmitir os parâmetros através de uma ligação bluetooth para um aplicativo simulador no
dispositivo android. A partir dos resultados obtidos nos testes realizados pode se concluir
257
que ele é funcional, e atende ao objetivo de ser uma inovação tecnológica de baixo custo,
pois a maioria dos matériais podem ser encontrados a preços acessı́veis.
Como trabalhos futuros planeja-se implementar o projeto com uma comunicação
melhor para, assim, resolver o atraso, montar a bateria completa, desenvolver pads com
qualidade mais realista, desenvolver versões para outros sistemas operacionais como IOS
e Windows Phone, e implementar o aplicativo com mais funcionalidades como, a troca
dos timbre de cada pad pelo usuário.
Referências
Almeida, W. B. and Fressatti, W. Bateria eletrônica com arduıno.
Arduino, M. and Mega, A. (2016). 2560. URL: https://www. arduino.
cc/en/Main/ArduinoBoardMega2560#, consultado, 1.
Chedid, R. (2015). Protótipo de uma bateria eletrônica musical sem fio.
Faludi, R. (2010). Building wireless sensor networks: with ZigBee, XBee, arduino, and
processing. ”O’Reilly Media, Inc.”.
GOMES, R. C., FERNANDES, J. A. R., FERREIRA, V. C., and FERNANDES, N. C.
(2012). Sistema operacional android. Universidade Federal Fluminense.
Haartsen, J. C. (2000). The bluetooth radio system. IEEE personal communications,
7(1):28–36.
Hsiao, C.-Y. and Huang, C.-F. (2013). Piezo-based interactive music system.
Lee, J.-S., Su, Y.-W., and Shen, C.-C. (2007). A comparative study of wireless protocols:
Bluetooth, uwb, zigbee, and wi-fi. In Industrial Electronics Society, 2007. IECON
2007. 33rd Annual Conference of the IEEE, pages 46–51. Ieee.
Martins, N. A. (2005). Sistemas microcontrolados. Uma abordagem com o Microcontro-
lador PIC 16F84. Editora Novatec Ltda, 1a edição.
McRoberts, M. (2011). Arduino básico. São Paulo: Novatec.
Medeiros, M. (2011). O lugar na comunicação: um estudo sobre a comunicação locativa
em zonas bluetooth.
Nadalin, E. Z. et al. (2007). Determinação da força peso, a partir dos impactos de pisadas,
utilizando um sensor piezoeletrico.
258
Implementação de uma Solução Computacional para Auxiliar

no Processo de Acompanhamento de Pacientes do Centro de
Atenção Psicossocial (CAPS) II: um Estudo de Caso na Sede
de Floriano-PI
Maria Clara L. de Alencar¹, Natália F. Louzeiro¹, Rayla N. Pereira¹, Gian Matheus
F. Pinheiro¹, Jainã Kersi T. Leal¹, Rafael P. de Deus¹, Simone Fernanda M. Silva²,
Willamys Rangel N. de Sousa²
¹Graduando (a) do curso de Tecnologia em Análise e Desenvolvimento de Sistemas do

IFPI- Campus Floriano
²Professor (a) do Instituto Federal de Educação, Ciência e Tecnologia do Piauí –
Campus Floriano
{lealclaram,rayamerio2016,sfernandasm,ralfdrewpereira,jainakersi}
@gmail.com,{natalia.louzeiro,gianpinheiro1}@hotmail.com,
[email protected]
Abstract. The present paper proposes the development of a computational tool

to be used in the process of follow-up the psychic situation of patients in the
Psychosocial Care Center - (CAPS) II in the city of Floriano - PI. The
research was based on the qualitative strategy, with an exploratory nature,
through a case study in the referred institution, allowing the professionals, to
have more agility in the process of filling in information that is necessary for
the monitoring of their patients. Furthermore, it was sought the improvement
the efficiency of the activities and essential procedures of the daily life of those
who are responsible for the control of the Psychic Evolution, with a time
reduction in the reception and agility in all management processes of the
follow-up of patients with mental illness.
Resumo. O presente trabalho propõe o desenvolvimento de uma ferramenta

computacional para ser utilizada no processo de acompanhamento do quadro
psíquico dos pacientes do Centro de Atenção Psicossocial (CAPS) II na
cidade de Floriano–PI. A pesquisa foi embasada na estratégia qualitativa, de
cunho exploratório, através de um estudo de caso na referida instituição,
permitindo que os profissionais tenham mais agilidade no preenchimento de
259
informações necessárias para o monitoramento de seus assistidos. Além disso,

buscou-se ampliar a eficiência das atividades e procedimentos essenciais do
cotidiano daqueles que são responsáveis pelo controle da evolução psíquica,
com redução de tempo na recepção e agilidade em todos os processos de
gerenciamento do acompanhamento dos pacientes com problemas mentais.
1. Introdução
As diligências em saúde mental sofreram grandes transformações nas últimas décadas.
Anteriormente, não havia proposta terapêutica à pessoas acometidas por problemas
mentais. A modalidade de tratamento era reservada aos hospícios e asilos, a cura era
postulada pelo isolamento da sociedade [Ministério da Saúde 2005].
Segundo o Ministério da Saúde (2005), por meio da Conferência Regional de

Reforma dos Serviços de Saúde Mental, onde se discutiu o processo de Reforma
Psiquiátrica nos anos de 1970, e posteriormente a aprovação da Lei Federal 10.216,
ocorreram mudanças na abordagem dos tratamentos psiquiátricos, como consequência
de denúncias do tipo de cuidado que os mesmos recebiam em centros de tratamentos
mentais.
Neste período de Reformas Psiquiátricas, obteve-se o surgimento de um novo

dispositivo institucional, o Centro de Atenção Psicossocial (CAPS) que redirecionou o
modelo assistencial em saúde mental e, posteriormente, foi constituído por modalidades,
distinguindo-se por características do portador, disponíveis na Portaria n.º 336/GM em
19 de fevereiro de 2002 e Portaria nº 130, de 26 de janeiro de 2012, mas que cumprem a
mesma função no atendimento da população de saúde mental [Ministério da Saúde
2005].
Geraram inovações, com práticas e serviços no atendimento e na reestruturação

da atenção psíquica, acarretando a necessidade de controle desses processos e dos
procedimentos quanto ao paciente, usando como auxílio instrumentos que diminuam a
duração da burocracia na recepção dos portadores, visto que progressivamente os
pacientes evoluem em números nessas instituições e exigem um maior cuidado e
agilidade no acolhimento. Esse controle dos processos e da evolução psicológica é
acompanhado através de fichas ou prontuários, onde são armazenados registros e
diagnósticos pregressos. No Centro de Atenção Psicossocial (CAPS), onde o fluxo de
260
pessoas procurando acolhida é enorme, a busca manual dessas fichas retarda o

atendimento dessas pessoas.
Portanto, propor o acompanhamento e atendimento dos indivíduos no CAPS II

na cidade de Floriano-PI, por meio de uma ferramenta eletrônica, a fim de que agilize a
busca por dados históricos sobre os pacientes, aumente a agilidade dos profissionais nas
intervenções dos usuários, aponte informações para reinserção social é de grande
viabilidade para essa instituição, pois amplia a possibilidade de solução ou amenização
das dificuldades recorrentes.
Segundo Vam Bemmel (1997) apud Manzella (2014), os prontuários em papéis já
existem há muitos anos. Durante o século V a.C., Hipócrates incentivou os médicos a
realizarem os registros sobre os pacientes por escrito, tendo como objetivos o
conhecimento do estágio em que a doença se encontrava e a análise das possíveis
causas. Estes registros eram feitos por meio de fichas de identificação amarrados ao
punho dos enfermos e fichas únicas com informações da situação do paciente. Até o
começo do século XIX, estes dados dos indivíduos eram gerados através do que os
médicos viam, sentiam e ouviam [Patrício et al 2011].
Entretanto, esta forma de armazenamento de registros em um único documento

trouxe uma dificuldade para os médicos na localização de informações específicas. Foi
quando, a partir de 1907, optou-se pela utilização de prontuários individuais, para cada
paciente, como os casos da Clínica Mayo, nos EUA [Vam Bemmel 1997].
No Brasil, a necessidade de uma padronização da coleta de informações do

paciente, resultou, em 2002, no surgimento de um conjunto mínimo de dados a serem
coletados de cada paciente, feito pelo Ministério da Saúde. E, posteriormente, em julho
de 2007, o Conselho Federal de Medicina (CFM) aprovou técnicas para digitalização e
uso de sistemas informatizados para manipulação desses dados [Patrício et al 2011].
Ainda de acordo com o CFM, sobre regência da Resolução CFM Nº 1.821, de

11 de julho de 2017:
Art. 3º Autorizar o uso de sistemas informatizados para a guarda e manuseio
de prontuários de pacientes e para a troca de informação identificada em
saúde, eliminando a obrigatoriedade do registro em papel, desde que esses
261
sistemas atendam integralmente aos requisitos do "Nível de garantia de

segurança 2 (NGS2)", estabelecidos no Manual de Certificação para Sistemas
de Registro Eletrônico em Saúde;
Dessa forma, o Prontuário Eletrônico do Paciente (PEP) tornou-se uma

ferramenta de fundamental importância, devido às vantagens ofertadas, tais como o
acesso simultâneo, além de permitir que os médicos possam consultar e inserir
informações de onde estiverem, garantir de forma mais confiável que os dados não
sofram danos/perdas [Massad, 2003].
Para tal implementação, o PEP forneceu um modelo a ser seguido pela área
básica de saúde em municípios brasileiros no ano de 2016, segundo a Comissão
Intergestores Tripartite/Ministério da Saúde, sobre regência da Resolução CIT/MS Nº 7,
de 24 de novembro de 2016:
Art. 1º Definir que o registro das informações relativas às ações da atenção básica
deverá ser realizado por meio de prontuários eletrônicos do paciente.
§ 1º Entende-se como prontuário eletrônico um repositório de informação
mantida de forma eletrônica, onde todas as informações de saúde, clínicas e
administrativas, ao longo da vida de um indivíduo estão armazenadas, e suas
características principais são: acesso rápido aos problemas de saúde e
intervenções atuais; recuperação de informações clínicas; sistemas de apoio à
decisão e outros recursos.
Atualmente, existem diversas ferramentas que atuam como facilitadoras no

processo de atendimento na área da saúde básica, bem como ferramentas estruturadas
que dão apoio a grandes hospitais, como EMED Tecnologia (2017), HiDoctor® (2017).
No entanto, para instituições que tratam da saúde mental existem outros tipos de estudos
necessários para entender a história pregressa do paciente que nos dispositivos citados
não são encontrados, pois essa área necessita de informações específicas.
3. Metodologia
O estudo foi embasado na estratégia qualitativa de pesquisa, de cunho exploratório,

através de um estudo de caso no CAPS II da cidade de Floriano – PI. Esta instituição é
destinada ao atendimento a indivíduos que sofrem com transtornos mentais e
comportamentais, evitando internações e auxiliando em sua inclusão social. A mesma
presta serviços no município, desde o ano de 2006 [Brito; Sousa 2009].
262
O acompanhamento dos usuários é realizado por meio de prontuários manuais.

Entretanto, mostrou-se ineficaz, visto o tempo investido na coleta de dados e,
principalmente, na perda de dados importantes de pacientes. Assim, o presente estudo
preocupou-se em propor o desenvolvimento de uma plataforma computacional, que atue
na melhoria do atendimento aos usuários, fornecendo aos profissionais um apoio no
processo de cadastramento e acompanhamento dos indivíduos. Para o desenvolvimento
do projeto, o mesmo foi dividido em seis etapas, conforme o ilustrado na Figura 1.
Definição Trabalhos Escolha da Modelagem Implementação Validação

do problema Relacionados Instituição e de dados de um protótipo dos Dados
Coletas de do sistema
Dados
1ª Etapa 2ª Etapa 3ª Etapa 4ª Etapa 5ª Etapa 6ª Etapa
Figura 1– Metodologia de desenvolvimento do estudo

Fonte: Autoria própria (2017).
A etapa de definição do problema foi realizada por meio de propostas de

implementações de sistemas, com o objetivo de composição de prontuários que
pudessem servir de referência ao projeto a ser desenvolvido.
Em seguida, foram pesquisados trabalhos relacionados com a mesma

finalidade do proposto no estudo, mas para instituições em saúde mental, pois existem
outros tipos de informações necessárias, que nas ferramentas citadas não foram
encontradas.
Posteriormente, foi feita a escolha da instituição objeto de estudo da aplicação

da pesquisa, com base nas dificuldades recorrentes na organização. Foram utilizados
instrumentos de pesquisa, estilo questionários, com questões abertas e subjetivas, tendo
como finalidade coletar informações dos pacientes, problemas preexistentes, além da
forma de controle desses dados utilizada na instituição.
Depois dessa etapa, foi processada a modelagem de dados, visando um melhor

entendimento do problema, em que foram delimitadas as necessidades e funcionalidades
do sistema.
Em seguida, foi executada a implementação de um protótipo de um aplicativo

baseado nos requisitos definidos por meio da etapa anterior. A mesma foi fundamental
para o desenvolvimento do produto final, visto que este sistema auxiliará diretamente o
263
profissional no acompanhamento do paciente durante toda sua reabilitação, por meio do

controle de dados, tratamento, medicamentos utilizados e situação atual do paciente.
Ao final da etapa de prototipação, foi realizada a validação do sistema, por

meio do feedback dos usuários da instituição.
4. Análises e Resultados
Com a aplicação dos procedimentos metodológicos, gerou-se como resultado uma
plataforma computacional que permitiu aos profissionais do CAPS II otimizar as etapas
de cadastro e acesso às informações de cada paciente.
A plataforma é composta por 5 (cinco) módulos: cadastros, atendimento,

solicitações de exames, buscas de pacientes e emissão de relatórios. Na interface
principal do aplicativo, através da seleção de um paciente, é feita a consulta, onde são
capturadas a identificação, o Cadastro Internacional de Doenças (CID), a data e horário
do atendimento, o profissional que está atendendo, e a sua especialidade, o tipo de
atendimento, a anamnese, medicamentos e as observações dos mesmos. No módulo de
relatórios, os usuários têm acesso aos dados gerais do paciente, às consultas e exames,
tornando o acompanhamento mais ágil, beneficiando ambos.
A implantação da ferramenta afeta 8 (oito) profissionais que atuam no

tratamento dos usuários e 1 (um) funcionário que presta assistência aos profissionais -
psicólogos, psiquiatra, nutricionista, enfermeiros e técnico em informática.
Posteriormente a introdução da ferramenta, foi aplicado um questionário, com 66% da
equipe, com perguntas objetivas e subjetivas. Observou-se em 33% deles, a dificuldade
na adaptação à plataforma computacional durante o atendimento, provocada pela falta
de prática e a preocupação com a diminuição da interação entre profissional e pacientes.
Apesar destes problemas, os profissionais entrevistados relataram também

impactos positivos, que foram sentidos nos seguintes aspectos: auxílio durante a
consulta; agilidade no acesso dos históricos dos pacientes, onde alguns profissionais
descreveram que o tempo gasto foi reduzido e assim ocasionando menor inquietação
dos pacientes na espera pelas consultas. Os relatórios gerados pela ferramenta também
foram apontados como fator positivo, já que irão auxiliar na elaboração dos projetos
264
terapêuticos singulares. “Otimiza o tempo de acesso às informações do usuário e

organiza os processos de trabalho no serviço” (Psicóloga).
Os profissionais da instituição acreditam que esta facilidade de acesso e

compartilhamento de informações leva a uma melhoria na assistência, na medida em
que permite acessar informações sobre o paciente de forma rápida e possibilita troca de
informações entre médicos e entre médico e paciente.
5. Conclusões
O trabalho apresentado mostra os resultados da implementação de uma solução
computacional desenvolvida para ajudar no desempenho dos especialistas do CAPS II,
facilitando o registro e o acesso às informações. O reflexo gerado pelo uso dessa
ferramenta poderá ser sentido à medida que os profissionais da instituição dispõem de
mais tempo para atenção dedicada ao problema do paciente, com a consequente redução
do tempo nas atividades burocráticas necessárias à realização da consulta e ao registro
das informações, permitindo que sejam realizados mais atendimentos por dia, ou ainda,
na melhoria da qualidade de vida do profissional, contribuindo nas obrigações
cotidianas.
A partir dos resultados obtidos neste trabalho, conclui-se que a ferramenta traz
importante aporte, uma vez que havia um mau gerenciamento dos documentos da
instituição, gerando problemas como: perda de fichas, muito tempo gasto nas tarefas
repetitivas e burocráticas, entre outros.
Tal estudo pode ser ampliado por meio de novas adaptações, visando trazer
maior mobilidade aos usuários com o objetivo de dar suporte em atendimento
domiciliar dos pacientes, podendo oferecer facilidade de uso e simplicidade que são
condições importantes para obtenção de maior sucesso da aplicação.
Referências
Brasil, Ministério da Saúde. Portaria n.º 336/GM de 19 de fevereiro de 2002: Estabelece

CAPS I, CAPS II, CAPS III, CAPS i II e CAPS ad II. Diário Oficial da União, 2002.
_______, Ministério da Saúde. Secretaria de Atenção à Saúde. Dape. Coordenação

Geral de Saúde Mental. Reforma psiquiátrica e política de saúde mental no Brasil:
265
Documento apresentado à Conferência Regional de Reforma dos Serviços de Saúde

Mental: 15 anos depois de Caracas. 2005.
Brito, Mychelangela de Assis; Sousa, Flávia Regina. Perfil Sócio demográfico dos
Usuários de Procedimento Assistidos no CAPS II Adulto de Floriano-PI que
Tentaram Suicídio –Floriano-PI -2009.
Comissão Intergestores Tripartite/Ministério da Saúde. Define o prontuário eletrônico

como modelo de informação para registro das ações de saúde na atenção básica e dá
outras providências. Resolução CIT/MS nº 7, de 24 de novembro de 2016. Diário
Oficial da União; Poder Executivo, Brasília, DF 28 nov. 2016. Seção 1, p.108.
Conselho Federal de Medicina. Aprova as normas técnicas concernentes à digitalização

e uso dos sistemas informatizados para a guarda e manuseio dos documentos dos
prontuários dos pacientes, autorizando a eliminação do papel e troa de informação
identifica em saúde. Resolução CFM nº 1.821, de 11 de julho de 2017. Diário Oficial
da União; Poder Executivo, Brasília, DF, 23 nov. 2007. Seção I, p. 252.
Emed Tecnologia Sistema de Gestão Clinicas. Sistema de Gestão na nuvem visando

resultados rápidos. Disponível em < http://www2.emed.com.br/~emedcom/> Acesso
em 28 de maio de 2017.
HiDoctor. Software médico HiDoctor®: Ágil e prático, organiza seu consultório.

Disponível em: < https://hidoctor.com.br/> Acesso em 28 de maio de 2017.
Manzella, Luiz Augusto de Azevedo. Impacto na realização de consultas de médicos

cardiologistas com a utilização do módulo de evolução eletrônica de pacientes de um
sistema de gestão integrada de clínicas. 2014
Massad, E.; Marin, H.F.; Azevedo, R.S. (Editores). Colaborador Lira A. C. O. O

Prontuário do Paciente na Assistência, Informação e Conhecimento Médico. São
Paulo: H. de F. Marin, 2003.
Mourão, Alice Diniz; Neves, JT de R. Impactos da Implantação do Prontuário

Eletrônico do Paciente sobre o Trabalho dos Profissionais de Saúde da Prefeitura
Municipal de Belo Horizonte. Belo Horizonte: Faculdade Cenecista de Varginha –
FACECA, 2007.
266
Sistema Óptico Portátil para Auxílio na Análise de Marcha

Ranulfo Plutarco Bezerra Neto1 , Francisco Bruno Rocha1 , Diego Porto Rocha1
Ricardo de Andrade Lira Rabêlo1 , André Macêdo Santana1
1
Departamento de Computação – Universidade Federal do Piauí (UFPI)
Caixa Postal 64049-550 – Teresina – PI – Brasil
[email protected], {ricardoalr, andremacedo}@ufpi.edu.br
Abstract. This article presents a motion capture optical system using a

smartphone as the runtime environment. The objective of the study is to perform
clinical gait analysis through the use of active markers obtained by image seg-
mentation using BlobDetection. Tests were performed comparing the processing
time in different resolutions of images for each stage of the system, aiming to va-
lidate the accuracy and practicability of software execution. From the analysis
of the results it is possible to prove the viability of the system, which presents
an average capture of 18 frames per second in an environment with artificial
lighting.
Resumo. Este artigo apresenta um sistema óptico de captura de movimento

utilizando um smartphone como ambiente de execução. O objetivo do estudo é
realizar análise de marcha clínica por meio do uso de marcadores ativos obtidos
por segmentação de imagens usando BlobDetection. Foram realizados testes
comparando tempo de processamento em diferentes resoluções de imagens para
cada etapa do sistema, no intuito de validar a acurácia e praticabilidade de
execução do software. A partir da análise dos resultados foi possível comprovar
a viabilidade do sistema, que apresentou uma média de captura de 18 frames
por segundo em ambiente com iluminação artificial.
1. Introdução
A marcha, para um padrão bípede, é a movimentação dos membros inferiores, à frente e
de corpo ereto, que pode ser descrito em um ciclo compreendendo desde o contato de um
pé ao solo até o contato seguinte desse mesmo pé, como pode ser visto na Figura 1. Esse
ciclo se repete indefinidamente a cada passo [Viel 2001]. De acordo com o [IBGE 2010],
5,7% da população brasileira sofre de deficiência motora. Com esse paradigma, a análise
de marcha compara o movimento saudável a movimentos realizados por pacientes em fase
de recuperação de danos motores nos membros inferiores, para que, dessa forma, haja um
acompanhamento mais preciso do desenvolvimento dos pacientes.
A análise do processo de movimentação biológica definida como marcha humana
tem sido utilizada, nos últimos tempos, como um meio mais preciso de diagnóstico em
terapias ou etapas de recuperação de sujeitos com distúrbios, deficiências, anomalias ou
limitações. De acordo com [Tanaka et al. 2007] um alto número de artigos na literatura
ainda apresenta a análise de marcha por método observacional não tão fidedigno quanto
o computacional, entretanto ainda se é feito por conta do alto custo do sistema e não
praticidade devido necessidade de um técnico para monitorar o sistema.
267
Figura 1. Ciclo de Marcha
Este trabalho busca propor uma alternativa, portátil e prática, para analise de mar-
cha. Essa alternativa tem como base a utilização de um smartphone com marcadores
ativos para gerar a posição do pé, joelho e quadril, juntamente com o ângulo formado
pelo joelho do sujeito analisado.
A análise de marcha computadorizada se apoia em diferentes tipos de sistemas de captura
de movimento, como sistemas com acelerômetro, giroscópio, sensores magnéticos, e sen-
sores com eletromiograma (EMG). Dentre os citados os mais cotados, recentemente, são:
dispositivos baseados em eletromiografia (EMG), dispositivos de acelerômetros e por fim
os sistemas que usufruem da tecnologia de captura de movimento baseada em câmeras,
com e sem marcadores.
Um sinal eletromiográfico (EMG) consiste em um potencial elétrico produzido
pela contração de determinado músculo, sendo medido na superfície da pele (não inva-
sivo) ou internamente à pele (invasivo) nas camadas mais superficiais do músculo. A
partir desta captura de sinal, é possível traçar parâmetros para a condução de uma inter-
face como as descritas em [Kunju et al. 2009, Sasayama and Murakami 2013].
Os acelerômetros são instrumentos que medem a aceleração aplicada em um
ou mais eixos. O mecanismo se faz a partir da movimentação do segmento ou local
onde o sensor foi fixado, que com sua inércia em relação a uma base fixa no interior
é detectada e transformada em um sinal elétrico. Trabalhos como [Barbieri et al. 2004,
Martins et al. 2014] mostram algumas formas de interpretar estes sinais.
Sistema de captura de movimento óptico (SCMO) é o processo de identificar ca-
racterísticas em uma streaming de vídeo usando técnicas de processamento de imagem.
Um dos principais problemas encontrados pelos sistemas óticos é o alto processamento
necessário para extrair as características chaves. De forma a amenizar este problema é uti-
lizado marcos e câmeras preposicionadas tanto em soluções comerciais como na pesquisa
[Bailey 2007]. A Figura 2 mostra um SCMO sendo utilizado para reabilitação.
Há três tipos de câmeras sendo usadas pelas SCMO: IRLED câmeras, RGB câ-
meras, e câmeras normais. O primeiro tipo trabalha diretamente com marcos passivos,
marcos com substancias retro refletivas, emitindo luz infravermelha que é refletida pelo
marco discriminando a posição do mesmo. O segundo tipo utiliza cores primarias para
segmentar a imagem, e para melhor eficácia é utilizada uma roupa colorida para segmentar
as partes do corpo [Lindequist 2004]. O ultimo é geralmente utilizado com marcos ativos,
leds emissores de infravermelho ou RGB fixadas no corpo, estes marcos são capturados
através da emissão vinda de cada led. Exemplos de trabalhos com marcos ativos, passivos
268
Figura 2. Sistema de captura ótico sendo utilizado para reabilitação
e sem marco são respectivamente [IVO Stanic 2010], [Tanie et al. 2005, Yang et al. 2016]
e [Sridhar et al. 2013].
3. Sistema Proposto
Figura 3. Sistema Óptico Proposto
Visando o baixo custo e portabilidade do sistema, foi desenvolvido um sistema

óptico de captura de movimento utilizando um smartphone e fitas de led representando
marcos ativos, como pode ser visto na Figura 3. O sistema busca utilizar técnicas de
processamento de imagem para detectar o posicionamento dos marcos e calcular o ân-
gulo formado pelas juntas do individuo. Na Figura 4 podemos ver o passo a passo do
procedimento realizado.
A captura e processamento de imagem foi implementada através da biblioteca
OpenCV [OpenCV 2016]. Com o frame capturado é realizado um cálculo para correção
da distorção da imagem através da matriz obtida pela calibração. E então a imagem é
convertida para HSV (hue, saturation and value). pela sua representação direta de lumi-
nosidade através da saturação. Com a imagem convertida em HSV é realizada a segmen-
tação separando a imagem em 3 canais e aplicado a escala mínima e máxima: (0,250,0),
269
(0,255,0) apenas no canal correspondente a saturação, para segmentar a imagem, desta-

cando apenas os marcos.
Figura 4. Fluxograma de estados
Com a imagem segmentada, é feita a detecção de centroides de cada segmento

de imagem resultante da segmentação. Para isso foram utilizados alguns algoritmos de
detecção de blob e foi escolhido o findContours [Suzuki and Abe 1985] para armazena-
los. Blobs são uma região da imagem em que algumas propriedades, como brilho ou cor,
são constantes ou aproximadamente constantes. Então, é executado para cada blob um
cálculo do centroide através da função Moments que utiliza o teorema de Green que pode
ser visto em [Green 1828] para calcular o centro da área do blob.
4. Resultados
No experimento 1 foi posicionado um sujeito vestindo as fitas de led a dois metros do
smartphone em ambiente fechado com iluminação artificial, este procedimento visa ave-
riguar os tempos de processamento e os procedimentos realizados para cada etapa. A cap-
tura da imagem é realizada por uma função da OpenCV em Java, e obtemos em média:
41,48 a 179,9ms. As demais etapas foram implementadas em C++ utilizando Android
NDK [AndroidNDK 2016].A calibração da imagem é realizada apenas uma vez para ar-
mazenar a matriz de calibração. Após este procedimento cada frame precisa ser multi-
plicado pela matriz de calibração para corrigir a distorção causada pela lente da câmera.
Este procedimento leva em média: 38,67 a 611,13ms.
Após experimentação, foram obtidos os mesmos resultados de discriminação de
imagem tanto pela conversão para o HSV (hue, saturation and value) quanto para o HLS
(hue, lightness and saturation), pois as duas transformações de imagem possuem uma
variável que representa a luminosidade. Porém o tempo médio de processamento do
HSV foi significativamente mais rápido comparado ao HLS, dependendo da resolução
em média 5 vezes mais rápido. O resultado pode ser visto na Figura 5(b).
O processo de segmentação da imagem, como pode ser visto na Figura 5(c), foi
obtido em média entre 7,27 e 123,67ms. E, por fim, a Figura 5(d) mostra a detecção
utilizando o algoritmo findContours obteve em média entre 1,79 e 20,97ms. As médias de
menor tempo e maior tempo foram feitas utilizando as resoluções 320x240 e 1024x768,
respectivamente, como pode ser visto na Figura 4, quanto maior a resolução maiores são
os tempos de processamento para cada etapa.
Foi observado também que quanto menor a resolução mais é perdida informação
dos marcos, tanto com relação a luminosidade quanto em relação a possíveis partículas
que podem ser visualizadas como marcos. Por este motivo, a resolução de 640x480 é
ideal para ambientes com luminosidade pelo custo benefício. Já para ambientes escuros
270
(a) (b)
(c) (d)
Figura 5. (a): Imagem Capturada (b): Imagem Calibrada (c): Imagem Segmentada
(d): Imagem após Detecção
a resolução de 320x240 é mais aconselhável pela rapidez. A Figura 6 ilustra os tempos

de execução destes algoritmos em diferentes resoluções. É visto que, quanto menor a
resolução, menor será o tempo de processamento de cada etapa, entretanto uma resolução
abaixo de 640x480 só é aconselhável em ambiente sem iluminação pelo reduzido tamanho
do marco capturado pelo sistema.
Para comprovar a funcionalidade do cálculo de ângulo dos marcos, foi realizado o
experimento 2 utilizando uma fita de led inteira, e ocultando duas partes para representar
três marcos em angulação de 0 graus. Foram obtidos resultados entre 0,42 e 0,67 graus,
como não foi possível mesurar o real ângulo entre os marcos acusamos a comprovação da
funcionalidade, sem a certeza do grau de erro. A Figura 7 ilustra o procedimento. Nesse
mesmo experimento foi observada a diferença dos graus entre o frame calibrado e não
calibrado, e obtivemos em média 0,002194 a 0,06964 graus.
Como resultado final deste trabalho foi realizado o experimento 3, contemplando
um sujeito a dois metros de distancia do smartphone utilizando os marcos ativos no qua-
dril, joelho e pé. Foi utilizado ambiente sem iluminação. A resolução escolhida foi de
320x240, por obter resultados mais rápidos. O sujeito foi então capturado dando uma pas-
sada no sentido perpendicular à câmera, começando com a perna de trás que não possui
marcos e finalizando o ciclo da passada com a perna vestida nos marcos. As Figuras 8(c)
e 8(a) mostram os pontos de sensores capturados por cada marco, ilustrando o movimento
realizado pelo sujeito em coordenadas x/y representadas em pixels. Sendo que o primeiro
movimento (8(d) e 8(c)) foi capturado utilizando a correção de distorção da imagem, já o
segundo movimento (8(b) e 8(a)) é refeito, entretanto sem a correção de distorção.
Nas Figuras 8(d) e 8(b) obtemos os ângulos do joelho correspondentes aos mo-
vimentos realizados nas Figuras 8(c) e 8(a). É importante observar que no primeiro mo-
vimento o sistema está funcionando em torno de 10 frames por segundo, enquanto que
no segundo movimento obtemos uma media de 18 frames por segundo. Por este motivo,
271
(a) (b)
(c) (d)
Figura 6. Tempos de Execução para as Resoluções: (a): 1024x768 (b): 800x600

(c): 640x480 (d): 320x240
Figura 7. Experimento para Calculo do Ângulo dos Marcos dos Marcos
obtivemos resultados bem mais esparsos e agudos no movimento um comparado ao movi-

mento dois. Mesmo com a baixa frequência de processamento tanto a Figura 8(d) quanto
8(b) retratam com clareza o ciclo de movimento realizado pelo sujeito.
5. Conclusão
Os experimentos realizados com o protótipo mostraram que é possível implementar um
sistema de captura de movimento utilizando um smartphone com marcos ativos. Obser-
vamos que, para uma análise mais consistente dos dados, será necessário uma diminuição
do tempo de captura e distorção da imagem.
Como trabalhos futuros, visamos implementar a própria classe de captura de ima-
gem para diminuição do tempo de captura obtido pela OpenCV, e um estudo mais apurado
para viabilidade da distorção da imagem em uma câmera de celular. Além disso, uma in-
terface para comunicar os resultados mostrando a classificação de cada fase do ciclo de
marcha.
272
(a) (b)
(c) (d)
Figura 8. (a): Posição em coordenadas x/y sem correção de distorção (b): Ân-
gulo do joelho sem correção de distorção (c): Posição em coordenadas x/y com
correção de distorção (d): Ângulo do joelho com correção de distorção
Referências
AndroidNDK (2016). Android native development kit. http://developer.
android.com/intl/pt-br/tools/sdk/ndk/index.html. [Online; aces-
sado 1-Fevereiro-2016].
Bailey, B. (2007). Real time 3d motion tracking for interactive computer simulations.
Master’s thesis.
Barbieri, R., Farella, E., Benini, L., Riccó, B., and Acquaviva, A. (2004). A low-power
motion capture system with integrated accelerometers. Consumer Communications
and Networking Conference.
Green, G. (1828). An Essay on the Application of Mathematical Analysis to the Theories
of Electricity and Magnetism. Harvard University.
IBGE (2010). Características gerais da população, religião e pessoas com defi-
ciência. ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_
2010/Caracteristicas_Gerais_Religiao_Deficiencia/
caracteristicas_religiao_deficiencia.pdf. [Online; acessado
1-Fevereiro-2016].
IVO Stanic, DANIELA Borojevic, V. Z. (2010). Human kinematics measuring using
a high speed camera and active markers. International Conference on Simulation,
Modelling and Optimization.
Kunju, N., Kumar, N., Pankaj, D., Dhawan, A., and Kumar, A. (2009). Emg signal
analysis for identifying walking patterns of normal healthy individuals. Indian Journal
of Biomechanics.
273
Lindequist, J. (2004). Construction of a motion capture system. Master’s thesis, Vaxjo

University.
Martins, M., Elias, A., Cifuentes, C., Alfonso, M., Frizera, A., Santos, C., and Ceres, R.
(2014). Assessment of walker-assisted gait based on principal component analysis and
wireless inertial sensors. Revista Brasileira de Engenharia Biomédica.
OpenCV (2016). Opencv. https://opencv.org/. [Online; acessado 1-Fevereiro-
2016].
Sasayama, M. and Murakami, T. (2013). Design of a gait rehabilitation system: Gait
analysis and gait trajectory generation algorithm. Symposium on Industrial Electronics.
Sridhar, S., Oulasvirta, A., and Theobalt, C. (2013). Interactive markerless articulated
hand motion tracking using rgb and depth data. International Conference on Computer
Vision (ICCV).
Suzuki, S. and Abe, K. (1985). Topological structural analysis of digitized binary images
by border following. Computer Vision, Graphics, and Image Processing.
Tanaka, M. S., Luppi, A., Morya, E., Fávero, F. M., Fontes, S. V., and Oliveira, A. S. B.
(2007). Principais instrumentos para a anÃ¡lise da marcha de pacientes com distrofia
muscular de duchenne. Revista Neurociências.
Tanie, H., Yamane, K., and Nakamura, Y. (2005). High marker density motion capture by
retroreflective mesh suit. International Conference on Robotics and Automation.
Viel, E. (2001). A Marcha Humana, A Corrida E O Salto. Editora Manole.
Yang, C., Ugbolue, U. C., Kerr, A., Stankovic, V., Stankovic, L., Carse, B., Kaliarntas,
K. T., , and Rowe, P. J. (2016). Autonomous gait event detection with portable single-
camera gait kinematics analysis system. Journal of Sensors.
274
Uma Avaliação de Desempenho sobre uma Microcloud

Douglas Siqueira, Paulo Rocha, Rodrigo Leal e Francisco Airton Silva
{ds417042,paulohenriquegrocha,rocaleal98,francsilva10}@gmail.com
Abstract. The Internet has enabled to access remote computing resources from
anywhere. Due to this accessibility, some computational resources, previously
wasted, have became of constant and scalable use. This paradigm known as
Cloud Computing has brought the potential of solving complex computational
problems. In practice, Cloud Computing is formed by server machines wor-
king together. These servers — said traditional — often have high price and
high energy expenditure. Unlike traditional servers, microcontrollers (“small
computers”) have very limited resources, but with low price. One question that
rises is: Is it possible to replace traditional servers with microcontrollers? This
paper presents a systematic performance evaluation comparing traditional ser-
vers and microcontrollers Raspberry Pi (named Minicloud). The experiments
suggest that a Minicloud can be both, cheap and low energy consumer atten-
ding certain Service Level Agreements (SLAs).
Resumo. Com a facilitação do acesso à internet, alguns recursos computaci-

onais, antes desperdiçados, passaram a ser de uso constante e de forma es-
calável. Este paradigma conhecido como Computação em Nuvem (Cloud Com-
puting) trouxe o potencial de resolução para problemas computacionais bas-
tante complexos. Na prática, a Cloud Computing é formada pelo trabalho con-
junto de máquinas servidoras. Estes servidores — ditos tradicionais — muitas
vezes possuem preço elevado e alto gasto energético. Diferente dos servido-
res tradicionais existem hoje microcontroladores que funcionam como pequenos
computadores com recursos bem limitados porém com preço baixo. A pergunta
que se faz neste contexto é: Seria possı́vel substituir servidores tradicionais
por microcontroladores? Este artigo apresenta uma avaliação de desempenho
sistemática comparando servidores tradicionais e uma Cloud com microcontro-
ladores Raspberry Pi (nomeada de Microcloud). Os experimentos sugerem que
a Minicloud além de ser uma arquitetura mais barata possui menor consumo
energético e atende determinados Acordos de Nı́veis de Serviço (SLA).
1. Introdução
O avanço dos meios de comunicação facilitaram o acesso a recursos computacionais po-
derosos. Uma das tecnologias que foi impulsionada com esse avanço, foi a Computação
em Nuvem (do inglês Cloud Computing). A Cloud Computing é um modelo de negócios
que disponibiliza o acesso a uma gama de recursos computacionais de maneira ubı́qua,
conveniente e sob demanda [Mell e Grance 2016].
275
Construir uma infraestrutura de Cloud Computing requer um alto investimento em

uma série de equipamentos. Não apenas servidores de alto processamento mas também
tecnologias de armazenamento e rede.
Existem outras questões secundárias como refrigeração, mecanismos de
contenção de risco e alto gasto de energia. Este alto investimento para a construção de
data centers tem incentivado o uso de nuvens públicas como a Amazon, Rackspace e Di-
gital Ocean. No entanto, a adoção de nuvens públicas pode trazer dois desafios: a questão
da privacidade e tempo de resposta. Em termos de privacidade, a provedora irá manter
seus dados e controlar seus serviços. Em termos de tempo de resposta, dependo de onde
seus recursos estão alocados o tempo de resposta pode ser elevado exigindo alternativas
mais viáveis.
Microcontroladores são dispositivos de baixo custo que tem recursos computacio-
nais semelhantes aos computadores tradicionais. Apesar de mais limitados em processa-
mento, estes dispositivos tem um baixo consumo energético. O microcontrolador Rasp-
berry Pi (ver Figura 1) é um dos mais utilizados no mercado e é aplicado em diversas
áreas [Wilcox et al. 2015, Abrahamsson et al. 2013, Hajji e Tso 2016, Tso et al. 2013].
Figura 1. Raspberry Pi 3 Model B.
O trabalho conjunto de Raspberries trouxe um novo conceito, a Minicloud. Uma

Minicloud é uma cloud de pequeno porte composta por microcontroladores (ver exemplo
na Figura 2). A formação de uma Minicloud com vários dispositivos já mostrou possuir
alto poder de processamento [Anwaar e Shah 2015, Wilcox et al. 2015]. No entanto, de-
pendendo do QoE (Quality of Experience) do usuário tais recursos podem ficar ociosos
e um número bem menor de microcontroladores ser suficiente. Ao invés de Miniclouds
esta arquitetura mais reduzida é chamada de Microcloud [Bonomi et al. 2012].
Figura 2. Exemplo de Minicloud com 16 Raspberries Pi
Este trabalho mostra uma estudo sistemático de uma Microcloud buscando evitar
276
ociosidade e obter economia energética. Foi montada uma Microcloud com três Raspber-
ries Pi Model B. O desempenho desta Microcloud foi comparada com servidores tradici-
onais. Para comparação justa, esses servidores também têm baixo poder computacional.
A análise de desempenho foi realizada com o método estatı́stico Design of Experi-
ments (DoE). O DoE é aplicado sobre a influência de fatores em uma variável dependente
de forma concomitante [Minitab 2017]. No presente estudo foram analisados os fatores
Consumo Energético, Tempo de Processamento e Custos de Aquisição. Os resultados
dos experimentos apontam que o baixo custo, menor espaço fı́sico para posicionamento e
reduzido gasto energético podem compensar o uso de Microclouds.
O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta o
passo a passo da avaliação de desempenho realizada; a Seção 3 apresenta os trabalhos
relacionados; e a Seção 4 traça algumas conclusões e trabalhos futuros.
2. Avaliação de Desempenho
Esta seção apresenta os resultados dos experimentos conduzidos.
2.1. Ambiente de Testes

Neste estudo foi montada uma Microcloud com microcontrolodares Raspberry Pi 3 Model
B. Cada placa Raspberry possui processador Broadcom BCM2837 ARMv8 com quatro
núcleos, e 1 GB de memória RAM. A distribuição de processamento entre as placas foi
feita com um Message Broker chamado RabbitMQ7 .
A Microcloud foi comparada individualmente com dois servidores de capacidades
computacionais distintas. A Tabela 1 apresenta as configurações dos servidores adotados.
Tabela 1. Configurações dos Servidores.

Servidor CPU Frequência RAM
Servidor 01 i3 2,5 Ghz 7,7 GB
Servidor 02 i5 1,7 Ghz 3,7 GB
Como variáveis dependentes foram escolhidos o Tempo de Execução, o Custo

para montagem e o Gasto de Energia. Para coletar o Tempo de Execução o código cliente
foi instrumentado. O Gasto de Energia foi capturado com um equipamento chamado
Wanf WF-D02A8 (Figura 3) que mede a corrente que passa por ele.
2.2. Estudo do Impacto dos Fatores

O Design of Experiments (DoE) é um método estatı́stico que procura identificar a in-
fluência de fatores independentes sobre uma variável dependente. Tal processo visa
a otimização de resultados [Minitab 2017]. Os fatores analisados foram: Servidor e
Número de Imagens Processadas. O servidor representa a máquina responsável pelo pro-
cessamento de requisições. A aplicação Benchmark utilizada foi um software de proces-
samento de imagens que aplica uma técnica de segmentação. O número de imagens é
7
RabbitMQ: https://www.rabbitmq.com/
8
Manual do Wanf WF-D02A: solarlab.se/solpanel/datablad/WF-D02A-energy-meter.pdf
277
Figura 3. Aparelho Wanf WF-D02A
variado para observar o comportamento da infraestrutura com o aumento de carga de tra-

balho. O número de imagens foi variado entre três, seis, e doze. Vale ressaltar que foram
usadas imagens de iguais tamanho, definição e formato. A Tabela 2 apresenta os fatores
e nı́veis do experimento.
Tabela 2. Fatores e Nı́veis do Experimento.

Fatores Nı́veis
Microcloud com placas Raspberry
Servidor
Servidor 01
Servidor 02
3 imagens
Número de Imagens
6 imagens
12 imagens
Os resultados ou variáveis dependentes estudadas foram: Tempo de Execução e

Gasto Energético. Portanto, foram feitas duas análises DoE, onde foram realizadas 900
observações, 100 para cada combinação de nı́veis. Os ensaios foram aleatorizados para
aumento do rigor do experimento.
A Figura 4 apresenta um Gráfico de Pareto para a variável tempo de processa-
mento. O Gráfico de Pareto descreve a importância de um efeito por seu valor absoluto,
dispondo de uma linha vermelha vertical. Cada barra significa o nı́vel de impacto do fator
(ou interação de fatores) sobre a variável dependente. A linha vermelha tracejada repre-
senta a magnitude mı́nima de efeitos estatisticamente significativos (quantificada como
2.0), considerando-se o critério de significância estatı́stica α = 0.05. Ao passo que a barra
do fator transpassa esta linha, sua influência será maior sobre a variável dependente.
Como pode-se observar, todos os dois fatores tiveram impacto significativo tanto
sobre o tempo de execução quanto sobre o gasto energético. Em outras palavras, caso
se altere a configuração do servidor uma grande diferença no tempo de resposta e ener-
gia do sistema irá ser observada. Com a mudança da carga de trabalho também ocorre o
mesmo, quando se envia mais imagens para ser processadas o tempo de resposta e ener-
gia se altera bastante. O impacto da interação entre as variáveis — apesar de menor —
também é significativo, ou seja, a alteração de um fator interfere no outro fator. Sabendo
agora que os impactos dos fatores são significativos os nı́veis podem ser observados mais
detalhadamente.
278
(a) Tempo de Execução (b) Gasto Energético
Figura 4. Gráficos de Pareto
2.3. Análise Detalhada dos Fatores

Esta seção apresenta uma análise mais apurada sobre os resultados já obtidos em relação
a Tempo de Execução, Gasto Energético e Custo. A Figura 5 apresenta a média de Tempo
de Execução e Gasto Energético para cada uma das três configurações. O gráfico apre-
senta o consumo variado entre os servidores e variando número de imagens. Pode-se
observar que a Microcloud possui o consumo energético inferior, até mesmo com o Ser-
vidor 02 que se destaca por suas configurações.
(a) Tempo de Execução (b) Gasto Energético
Figura 5. Comparação de Nı́veis
A conclusão dos gráficos da Figura 5 é bem simples. O tempo e energia foram

crescentes nas variações da quantidade de imagens. Em termos de tempo, o Servidor 02
foi mais rápido do que o Servidor 01 que por sua vez foi mais rápido do que a Microcloud
montada. No entanto, vale ressaltar que a unidade de medida é milissegundos, sendo algo
significativo apenas em sistemas com alto rigor de tempo de resposta. Como estamos
tratando de infraestruturas de baixı́ssimo custo então tal resultado não é tão negativo para
a Microcloud. Supondo por exemplo que o Acordo de Nı́vel Serviço de um provedor
seja executar 12 imagens em até 100 ms. Neste caso, nossa proposta seria suficiente para
atender o requisito. Além do mais este resultado pode ser melhorado utilizando-se um
algoritmo para balanceamento de carga ou mesmo aumentando um pouco mais o número
de microcontroladores. Em relação ao gasto energético a Microcloud foi mais eficiente do
que os servidores 01 e 02 por ter um hardware bem mais simples. Vale ressaltar que não
foi utilizado nenhum dissipador de temperatura nos microcontroladores e mesmo assim
teve um bom desempenho. Além do desempenho, uma Microcloud possui uma vantagem
em termos de custo de aquisição. A Tabela 3 apresenta a relação dos custos médios para
279
cada servidor.
Tabela 3. Preço dos Equipamentos.

Servidor Preço em R$
Servidor 019 2.300,00
Servidor 0210 2.300,00
Microcloud11 570,00
A Figura 6a, 6b e 6c estabelecem um estudo de comparação relativa entre o Gasto

Energético e Tempo de Execução para três, seis e doze imagens, respectivamente.
(a) 3 Imagens (b) 6 Imagens
(c) 12 Imagens
Figura 6. Comparação de Tempo e Gasto Energético
É possı́vel perceber que enquanto o número de imagens cresce, o Gasto Energético

e o Tempo de Execução também crescem. Acompanhando o comportamento das linhas,
pode-se perceber que da Microcloud para o Servidor 01 o Tempo de Execução decai e o
Gasto Energético aumenta. Do Servidor 01 para o Servidor 02, ambos, o Gasto Energético
e o Tempo de Execução decaem. Como já falado anteriormente, o Servidor 02 possui me-
lhores configurações e por conta disto atingiu resultados superiores. Porém, o resultado
mais interessante está em comparar a MicroCloud com o Servidor 01 pois há um cru-
zamento das linhas. Caso a prioridade seja economia de energia, a Microcloud é mais
indicada. Caso a prioridade seja o Tempo de Execução, os servidores são mais indicados.
Esta seção apresenta os trabalhos relacionados. Sendo que, estes trabalhos utilizam
métricas e cargas de trabalhos diferentes desta Microcloud. Os atuais trabalhos relaci-
onados apresentados neste estudo estão ordenados por ano (de 2013 a 2016). Para melhor
visualização, a Tabela 4 elenca quatro fatores comparativos: Métricas de Monitoramento,
Comparação com Servidores e DoE. A seguir, estes fatores são comentados.
9
Preço de Servidor 1: http://tinyurl.com/y7yw59lk
10
Preço de Servidor 2: http://tinyurl.com/yah3bnp6
11
Preço de Servidor 3: http://tinyurl.com/y9knd8nv
280
Tabela 4. Comparativo entre Trabalhos Relacionados

Trabalho Métricas de Monitoramento Comparação com Sevidores DoE
[Abrahamsson et al. 2013] Gasto Energético e Tempo de Execução Não Não
[Chang et al. 2013] CPU, Memória, Custo, Rede e outras métricas Sim Não
[Tso et al. 2013] Custo e Gasto Energético Sim Não
[Cloutier et al. 2014] Custo, Gasto Energético, Processamento e outras métricas Sim Não
[Wilcox et al. 2015] Custo, Gasto Energético e Tempo de Execução Sim Não
[Sadooghi et al. 2015] Memória, CPU, Rede e Perfomance de Cálculo Sim Não
[Felter et al. 2015] CPU, Memória, Rede e Tempo Sim Não
[Anwaar e Shah 2015] Custo, Gasto Energético, Programação e outras métricas Sim Não
[Wilcox et al. 2015] Gasto Energético, CPU, Preço Sim Não
[Morabito 2016] CPU, Rede, Memória e E/S do Disco Rı́gido e Gasto Energético Não Não
[Hajji e Tso 2016] Custo, Gasto Energético, Processamento e outras métricas Não Não
[Mappuji et al. 2016] Gasto Energético, CPU Sim Não
Nosso Estudo Custo, Gasto Energético e Tempo de Execução Sim Sim
• Métricas de Monitoramento: este critério corresponde às propriedades

monitoradas nos servidores estudados. Cinco trabalhos [Chang et al. 2013,
Cloutier et al. 2014, Wilcox et al. 2015, Morabito 2016, Hajji e Tso 2016] reali-
zaram o monitoramento das métricas tratadas neste trabalho. Os demais trataram
de métricas diversas.
• Comparação com Servidores: este tópico trata do estudo comparativo
entre servidores. Três trabalhos [Abrahamsson et al. 2013, Morabito 2016,
Hajji e Tso 2016] não realizaram essa análise comparativa. O restante das pesqui-
sas realizaram avaliações comparativas entre servidores aplicados a Cloud Com-
puting. Vale ressaltar que os servidores comparados nesses trabalhos tinham
configurações avançadas, e portanto, possuı́am preços elevados.
• DoE: o Design of Experiments é uma ferramenta otimizada para análise estatı́stica
que permite estudo de interação entre causa e efeito e reduz o erro experimental.
Os trabalhos relacionados não fizeram uso desta abordagem e simplesmente fize-
ram comparações com fatores de forma individual e não agrupada.

Este artigo apresentou uma avaliação de desempenho comparando uma Microcloud com
servidores de baixo poder computacional. A Microcloud é uma alternativa de baixo custo
que agrega microcontroladores para trabalhar em conjunto. Para a comparação foi uti-
lizado um software de processamento de imagens. Foi aplicado um estudo estatı́stico
de Design of Experiments com dois fatores: Servidor e Número de Imagens. O resul-
tado do DoE indicou que ambos fatores tiveram impactos significativos sobre o Tempo
de Execução e Gasto Energético das arquiteturas propostas. Como esperado, o aumento
do número de imagens para serem processadas pelas máquinas aumentou o Tempo de
Execução e o Gasto Energético. O resultado mais significativo deste trabalho foi per-
ceber que o uso de uma Microcloud pode compensar em casos que o Gasto Energético
deve ser baixo e o tempo de resposta não precisa ser muito alto. Em termos de custos
a Microcloud também se mostra mais viável que o uso de servidores tradicionais. Um
exemplo pode ser na área de telecomunicações onde as estações remotas de controle (no
meio das matas) exigem muitos pontos de controle e as Microclouds podem ser uma al-
ternativa de baixo custo. Como trabalho futuro pretende-se avaliar outras métricas como
protocolos de comunicação. Talvez a utilização de outros protocolos agilizem ainda mais
o processamento paralelo das Microclouds.
281
Referências
Abrahamsson, P., Helmer, S., Phaphoom, N., Nicolodi, L., Preda, N., Miori, L., Angri-
man, M., Rikkila, J., Wang, X., Hamily, K., et al. (2013). Affordable and energy-
efficient cloud computing clusters: the bolzano raspberry pi cloud cluster experiment.
In Cloud Computing Technology and Science (CloudCom), 2013 IEEE 5th Internatio-
nal Conference on, volume 2, pages 170–175. IEEE.
Anwaar, W. e Shah, M. A. (2015). Energy efficient computing: A comparison of raspberry
pi with modern devices. Energy, 4(02).
Bonomi, F., Milito, R., Zhu, J., e Addepalli, S. (2012). Fog computing and its role in the
internet of things. In Proceedings of the first edition of the MCC workshop on Mobile
cloud computing, pages 13–16. ACM.
Chang, B. R., Tsai, H.-F., e Chen, C.-M. (2013). Evaluation of virtual machine per-
formance and virtualized consolidation ratio in cloud computing system. Journal of
Information Hiding and Multimedia Signal Processing, 4(3):192–200.
Cloutier, M. F., Paradis, C., e Weaver, V. M. (2014). Design and analysis of a 32-bit
embedded high-performance cluster optimized for energy and performance. In Proce-
edings of the 1st International Workshop on Hardware-Software Co-Design for High
Performance Computing, pages 1–8. IEEE Press.
Felter, W., Ferreira, A., Rajamony, R., e Rubio, J. (2015). An updated performance
comparison of virtual machines and linux containers. In Performance Analysis of Sys-
tems and Software (ISPASS), 2015 IEEE International Symposium On, pages 171–172.
IEEE.
Hajji, W. e Tso, F. P. (2016). Understanding the performance of low power raspberry pi
cloud for big data. Electronics, 5(2):29.
Mappuji, A., Effendy, N., Mustaghfirin, M., Sondok, F., Yuniar, R. P., e Pangesti, S. P.
(2016). Study of raspberry pi 2 quad-core cortex-a7 cpu cluster as a mini supercom-
puter. In Information Technology and Electrical Engineering (ICITEE), 2016 8th In-
ternational Conference on, pages 1–4. IEEE.
Mell, P. e Grance, T. (2016). The nist definition of cloud computing. recommendations of
the national institute of standards and technology (september 2011).
Minitab (2017). Designing an experiment. In Designing an Experiment.
Morabito, R. (2016). A performance evaluation of container technologies on internet
of things devices. In Computer Communications Workshops (INFOCOM WKSHPS),
2016 IEEE Conference on, pages 999–1000. IEEE.
Sadooghi, I., Martin, J. H., Li, T., Brandstatter, K., Zhao, Y., Maheshwari, K., de La-
cerda Ruivo, T. P. P., Timm, S., Garzoglio, G., e Raicu, I. (2015). Understanding
the performance and potential of cloud computing for scientific applications. IEEE
Transactions on Cloud Computing.
Tso, F. P., White, D. R., Jouet, S., Singer, J., e Pezaros, D. P. (2013). The glasgow
raspberry pi cloud: A scale model for cloud computing infrastructures. In Distributed
Computing Systems Workshops (ICDCSW), 2013 IEEE 33rd International Conference
282
Wilcox, E., Jhunjhunwala, P., Gopavaram, K., e Herrera, J. (2015). Pi-crust: a raspberry
pi cluster implementation. Technical report, Technical report, Texas A&M University.
283
Diagnóstico Pulmonar baseado em TC usando Análise

Funcional, MVS e CNN
Kelly Maria da S. Oliveira1 , Antonio Oseas de Carvalho Filho1 ,
Alcilene de Sousa1 , Patricia Medyna Lauritzen de L. Drumond1 ,
Patricia Vieira da S. Barros1
1
Campus Senador Helvı́dio Nunes de Barros
Universidade Federal do Piauı́ (UFPI) – Picos, PI – Brasil
{kellysilva0307, antoniooseas, alcileneluzsousa, petibarrosthe}@gmail.com,
[email protected]
Abstract. A Computer-Aided Diagnosis (CAD) methodology is proposed for the

classification of malignant and benign pulmonary nodules from computed to-
mography images. Functional diversity indexes were used to extract the nodule
characteristics, the classification was performed using the WEKA tool using the
Classifier in Vector Support Machine and Convolutional Neural Networks, the
results were validated with ROC curve metrics, sensitivity, specificity and ac-
curacy . In the results obtained with CNN, it reached an average sensitivity
of 85.4%, specificity average of 87.14%, mean accuracy of 86.7% and average
area of the ROC curve of 0.915.
Resumo. É proposto uma metodologia de auxı́lio no diagnóstico por computa-

dor (Computer-Aided Diagnosis -CADx) para classificação de nódulos pulmo-
nares em maligno e benigno a partir de imagens de tomografia computadori-
zada. Foram utilizados ı́ndices de diversidade funcional para extração das ca-
racterı́sticas dos nódulos, a classificação foi realizada com a ferramenta WEKA
usando os classificadores em Máquina de Vetor de Suporte e Redes Neurais
Convolucionais, os resultados foram validados com as métricas curva ROC,
sensibilidade, especificidade e acurácia. Nos resultados obtidos com CNN,
alcançou uma média de sensibilidade de 85,4%, média de especificidade de
87,14%, média de acurácia de 86,7% e área média da curva ROC de 0,915.
1. Introdução
No fim do século XX, o câncer de pulmão se tornou umas das principais causas de mortes
evitáveis. Em 90% dos casos diagnosticados, o câncer de pulmão está associado ao con-
sumo de derivados de tabaco. Além disso, o câncer pulmonar é o mais comum de todos
os tumores malignos, apresentando aumento de 2% por ano na sua incidência mundial
[Inc 2016].
O nódulo é uma aglomeração de células que difere em densidade e textura
do tecido circundante, quanto a seu comportamento pode ser maligno ou benigno
[Sousa 2007]. Com o intuito de diagnosticar a existência de nódulos pulmonares é feita
a Tomografia Computadorizada (TC) desenvolvida por Godfrey Houndsfiels e Allan Cor-
mack em 1972, exame de imagem fundamentado na aplicação de raios X de baixa inten-
sidade no corpo do paciente. A análise da TC permite ao especialista detectar nódulos
284
e fornecer o diagnóstico. Sobre o câncer pulmonar é importante destacar que um di-

agnóstico prematuro pode aumentar as chances de sobrevida do paciente.
À vista disso, soluções baseadas em Processamento Digital de Imagens (PDI)
vêm sendo desenvolvidas, conhecidas como sistemas Computer Aided Detection (CAD)
e Computer Aided Diagnosis (CADx). Os sistemas CAD e o CADx se complementam,
uma vez que o procedimento comum do especialista é detectar a região suspeita, ava-
liar - através de algum meio – se essa região está clinicamente comprometida e, por fim,
se essa região apresenta comportamento maligno ou benigno. O objetivo principal des-
ses sistemas é colaborar para superação das limitações humanas na realização de tarefas
repetitivas, comuns na análise de grande quantidade de exames [de Carvalho Filho 2016].
Neste contexto, este trabalho contribui com uma abordagem para diagnóstico de
nódulos pulmonares. A partir da medida da heterogeneidade de uma comunidade, ou
seja, diversidade funcional adaptada da biologia. Foram extraı́das caracterı́sticas de tex-
tura (rugosidade, regularidade, intensidade) em imagens de TC, aliadas a classificação
com Máquina de Vetor de Suporte (MVS) e Convolutional Neural Network (CNN). Com
o intuito de melhorar a consistência da interpretação da imagem radiológica, especifica-
mente o diagnóstico de câncer pulmonar.
A literatura apresenta alguns trabalhos com o mesmo objetivo da metodologia apresen-
tada, ou seja, diagnóstico de nódulos pulmonares em maligno e benigno.
Hua et al. (2015) introduz técnicas de deep learning, especificamente baseada
em uma rede de aprendizado profundo e uma rede neural convolucional no contexto da
classificação de nódulos em imagens de TC. A base de imagens utilizada foi a LIDC, com
um total de 2.545 nódulos, a metodologia alcançou uma taxa de sensibilidade de 73,3% e
especificidade 78,7%.
Foi proposto por Kumar et al. (2015) um sistema CADx que usa caracterı́sticas
extraı́das de um autoencoder para classificar nódulos pulmonares como maligno ou be-
nigno. Foram usados 4.303 casos contendo 4.323 nódulos do conjunto de dados do Na-
tional Cancer Institute (NCI) e LIDC. O trabalho alcançou uma acurácia de 75,01% e
sensibilidade de 83,35%.
No CADx desenvolvido por Orozco et al. (2015), tem base na extração, contando
com uma seleção dos descritores mais significativos. Por fim, é usado o classificador
Máquina de Vetor de Suporte. O trabalho foi validado em 45 TCs das bases ELCAP e
LIDC. A acurácia total do método foi de 82% a sensibilidade de 90,9% e a especificidade
de 73,91%.
Na metodologia CADx desenvolvida por Firmino et al. (2016), tem-se um método
de diagnóstico de nódulo pulmonar baseada na probabilidade do mesmo ser maligno. Para
isso, usou-se uma classificação baseada em MVS. O banco de imagens usado para testes
foi a LIDC-IDRI. Os resultados da metodologia alcançaram uma sensibilidade de 93,1%
com uma área sob a curva ROC de 0,91.
No CADx proposto em Dhara et al. (2016), os nódulos pulmonares são segmen-
tados usando uma técnica semiautomática. Medidas de forma e textura são usadas para
representar os nódulos pulmonares. O esquema de classificação proposto é validado no
285
conjunto de nódulos com 891 nódulos pulmonares extraı́dos da base LIDC-IRI. Os re-
sultados obtidos pelo método proposto com o classificador MVS alcançaram uma curva
ROC de 0,882.
Os trabalhos relatados acima são modelos de metodologias baseadas em carac-
terı́sticas de textura e forma, com reconhecimento de padrões para auxı́lio ao diagnóstico
de câncer pulmonar a partir de TC. No intuito de diminuir a disparidade observada em
valores de sensibilidade e especificidade, problemas comuns em sistemas CADx, este tra-
balho pretende explorar um potencial referente a medidas de descrição de textura baseada
em Índices de Diversidade Funcional com a classificação baseada em MVS e CNN.
3. Métodos
A metodologia proposta consiste em quatro etapas: aquisição de imagens; extração de
caracterı́sticas de textura; classificação; e métricas de validação dos resultados obtidos.
3.1. Base
As imagens utilizadas para os experimentos são provenientes da base de imagens LIDC-
IDRI. É uma base pública de exames de TC de nódulos pulmonares disponibilizada na In-
ternet pelo National Cancer Institute (NCI) [Clark et al. 2013]. Sete centros acadêmicos
e oito empresas de imagiologia médica colaboraram para criar este conjunto de dados
que contém 1018 casos. Cada tema inclui imagens de uma tomografia computadorizada
torácica clı́nica e um arquivo XML associado que registra os resultados de um processo
de imagem que contêm as anotações de duas fases realizadas por quatro radiologistas
torácicos experientes [van Ginneken et al. 2010].
A base LIDC-IDRI dispõe de 1.018 exames de TC, entretanto, alguns exames
apresentaram dois fatores que inviabilizaram seu uso no método, mais precisamente 185
exames. O primeiro fator está associado aos exames que não possuem nódulos maiores
que 3 mm. O segundo fator está relacionado a um erro de divergência de informações
encontradas no arquivo de marcação dos exames [de Carvalho Filho et al. 2014]. Assim,
foram usados 833 exames para aplicação do método proposto.
3.2. Índices de Diversidade Funcional

Diversidade funcional é o valor e a variação das espécies e de suas caracterı́sticas
que influenciam o funcionamento das comunidades [Tilman 2001]. Medir a di-
versidade funcional significa medir a diversidade de traços funcionais que influen-
ciam os processos da comunidade, independentemente da filogenia1 dos organismos
[Cianciaruso et al. 2009]. É a soma dos comprimentos dos braços de um dendrograma2
funcional [Petchey and Gaston 2002].
A etapa da extração de caracterı́sticas pode ser dividida em duas categorias de
análises: textura e forma. Em uma análise por textura, a finalidade é a descrição de
aspectos da imagem no que diz respeito a suavidade, rugosidade e regularidade. As três
principais abordagens usadas em PDI para análise de textura são: estrutural, espectral e
estatı́stica [Gonzalez and Woods 2007].
1
história evolutiva de uma espécie ou qualquer outro grupo taxonômico
2
diagrama de árvore usado frequentemente para ilustrar a disposição dos clusters produzidos por agru-
pamento hierárquico.
286
Dentre os métodos mais utilizados na abordagem estatı́stica destaca-se a extração

de caracterı́sticas de textura a partir da matriz de coocorrência. Uma matriz de probabi-
lidade de ocorrência P(i, j) de um determinado par de pixels da imagem, sendo i o nı́vel
de cinza do pixel de interesse da matriz e j o nı́vel de cinza do pixel vizinho ao nı́vel de
interesse, em relação a uma distância de um ângulo Θ escolhido entre eles. Os cálculos
de uma matriz de coocorrência são realizados em quatro ângulos: 0o , 45o , 90o e 135o , nos
dois sentidos da matriz [Haralick et al. 1973]. Uma matriz de coocorrência será gerada
para cada direção.
Com a finalidade de proporcionar uma compreensão da DiversidadeFuncional, é
imprescindı́vel demonstrar a correlação entre a biologia e a metodologia proposta, como
apresentado na Tabela 1.
Tabela 1. Correlação entre os termos da Biologia e a metodologia proposta.

Biologia Metodologia
Comunidade ROI
Espécies Valor do pixel da ROI
Indivı́duos Quantidade de pixels de uma espécie
Neste trabalho associa-se a matriz funcional à matriz de coocorrência. Nas folhas

do dendrograma estão as espécies, representadas pelos valores dos pixels da imagem da
TC, com o objetivo de extrair os Índices de Diversidade Funcional.
Para facilitar a compreensão, a Figura 1 estabelece os fundamentos da análise de
agrupamento e ilustra o funcionamento do algoritmo responsável pela etapa de extração
de caracterı́sticas. A partir de uma imagem é calculado uma matriz de coocorrência para
cada ângulo 0o , 45o , 90o e 135o , posteriormente é convertido para uma matriz de distância
(distância euclidiana). Após a matriz de distância é efetuado o agrupamento que produz
o dendrograma, após é calculado o comprimento total do dendrograma para encontrar
os Índices de Diversidade funcional, e armazenados no Vetor de Caracterı́sticas, junto a
classe 1 para benigno ou -1 para maligno.
Figura 1. Extração de Caracterı́sticas com base em Índices de Diversidade Fun-

cional [Damasceno 2016].
A imagem foi quantizada em 18 nı́veis de cinza, com a finalidade de encontrar

regiões mais homogêneas e reduzir o tamanho da matriz de coocorrência e consequente-
287
mente o tempo de processamento. Foram calculadas as matrizes de coocorrência predefi-

nidas para quatro angulações, distância entre pixels d = 9, atribuı́da através de testes. Na
teoria, regiões malignas tendem a ser mais homogêneas devido ao núcleo da lesão está
bem definido. Já nos benignos isso não ocorre devido a lesão não ter um núcleo tão bem
definido quanto o maligno.
3.3. Classificação
A classificação foi realizada com o uso do software WEKA, que contém ferramentas para
pré-processamento de dados, classificação, regressão, clustering, regras de associação
e visualização [Hall et al. 2009]. Foram utilizados dois softwares: LIBSVM e Neural-
Network.
O LIBSVM [Chang and Lin 2011] que possui a implementação MVS, com o in-
tuito de minimizar o erro com relação ao conjunto de treinamento (risco empı́rico), assim
como o erro com relação ao conjunto de teste. A MVS trata-se de um grupo de métodos
de aprendizado supervisionado que podem ser utilizados para classificação ou regressão.
O algoritmo é baseado na teoria de aprendizado estatı́stico e na dimensão de Vapnik-
Chervonenkis [Ivanciuc 2005]. No classificador dois parâmetros importantes foram ajus-
tados: parâmetro γ para 0.4353 e o parâmetro de custo C para 64.0.
O NeuralNetwork, baseado na arquitetura CNN [LeCun et al. 1998], modelos de
deep learning (redes neurais com multicamadas ocultas) biologicamente inspirados em
conceitos de campos receptivos, que apresentam benefı́cios recentes no que diz respeito
ao aumento do poder de processamento. Uma rede completamente conectada realiza a
classificação de padrões a partir das caracterı́sticas extraı́das pelas camadas de convolução
e subamostragem [Silva 2015].
O diagnóstico é feito a partir dos conjuntos de caracterı́sticas previamente ex-
traı́das das imagens, e posteriormente submetidas à avaliação de um classificador que
informa se o nódulo é maligno ou benigno, a partir de treino prévio. Nos dois classifica-
dores foram utilizado método k-fold cross validation para a obtenção dos resultados. Os
dados foram divididos em 10 conjuntos, sendo 9 deles para treinamento e 1 para testes.
Este processo é repetido 10 vezes, de maneira que o conjunto escolhido para o teste será
diferente do anterior e no final é gerada uma média dos resultados.
3.4. Validação dos Resultados

Para avaliar o desempenho de modelos de classificação, geralmente são utilizadas algu-
mas estatı́sticas descritivas, como Sensibilidade (S), Especificidade (E) e Acurácia (A). A
finalidade da utilização destas métricas é medir o desempenho da metodologia utilizada
neste trabalho como satisfatório ou não. Com o intuito de apresentar pontos positivos e
negativos que permita melhorias futuras deste trabalho.
A sensibilidade (S) de um teste é definida pela proporção de verdadeiros positivos
(VP), ou seja, a capacidade da metodologia em predizer corretamente a condição para ca-
sos que realmente ocorre. Tem a função de indicar a eficácia do método. A especificidade
(E) é definida através da proporção de verdadeiros negativos (V identificados no teste, in-
dicando o quão bom é o teste para identificar indivı́duos não doentes. A especificidade é
a capacidade do sistema em predizer corretamente a ausência da condição para casos que
288
realmente não ocorrem. Enquanto que a acurácia (A) é a proporção de predições corretas,
sem levar em consideração o que é positivo e o que é negativo.
A avaliação do desempenho quantitativo de uma determinada técnica ou modelo
proposto pela comunidade cientı́fica são as curvas Receiver Operationg Characteristic
(ROC) [Van Erkel and Peter 1998]. Desenvolvida em bases estatı́sticas onde a principal
caracterı́stica é a relação percentual de acertos. O ideal para um sistema é que a quan-
tidade de acertos no diagnóstico tanto em fatores VP quanto em VN sejam máximas,
conceitos definidos como sensibilidade e especificidade.
O classificador baseado em CNN obteve melhor equilı́brio entre as três métricas de
avaliação com acurácia de 86,7%, sensibilidade de 85,4% e especificidade de 87,1% e
uma curva ROC de 0,91 que o classificador MVS que obteve acurácia de 82,3%, sensibi-
lidade de 62,6% e especificidade de 95,9% e curva ROC de 0,85.
A comparação dos trabalhos relacionados é uma tarefa complexa, já que grande
parte dos autores não disponibilizam os códigos ou bases de imagens utilizadas. Além
disso, algumas bases são diferentes da usada no método proposto. Portanto, os dados
apresentados na Tabela 2, são apenas para ilustrar/comparar os resultados obtidos com os
trabalhos da área.
Tabela 2. Comparação entre trabalhos relacionados e a metodologia proposta.

Trabalho Técnicas Base Am. A(%) S (%) E (%)
[Hua et al. 2015] DBN e CNN LIDC 2545 - 73,3 78,7
[Kumar et al. 2015] Autoenconder LIDC 4323 75,1 83,3 -
[Orozco et al. 2015] ELCAP 106 82 90,9 73,9
e LIDC
[Dhara et al. 2016] MVS LIDC- 891 - 89,7 74,9
IDRI
[Firmino et al. 2016] MVS LIDC- 1109 - 93,1 88,1
IDRI
Método Proposto MVS LIDC- 1403 82,3 62,6 95,9
IDRI
Método Proposto CNN LIDC- 1403 86,7 85,4 87,1
IDRI
Um bom método deve ser capaz de classificar com sucesso, tantos os casos de po-
sitivos (que possuem a doença) como os casos de negativos (que não possuem a doença).
Ao analisar a Tabela 2 pode-se destacar Hua et al. (2015) que utiliza modelos baseado
em deep learning, ou seja, uma abordagem similar a utilizada neste trabalho com o clas-
sificador baseado em CNN que sobressai em relação aos resultados. Conclui-se que o
equilı́brio entre as três métricas de desempenho para a solução de diagnóstico pulmonar
proposta neste trabalho baseado em CNN mostra-se mais eficiente que Hua et al. (2015),
Kumar et al. (2015), Orozco et al. (2015) e Dhara et al. (2016), com resultados acima
de 85% para os valores de acurácia, sensibilidade e especificidade, aduzindo que este
trabalho traz contribuições relevantes para o estudo do tema.
289
É relevante destacar que a base LIDC-IDRI não dispõe de exames histopatológicos

para comprovação da malignidade ou benignidade de um nódulo pulmonar, este por sua
vez, tem sua classificação baseada em informações dos quatro radiologistas. Além disso,
a base LIDC-IDRI não dispõe de exames em séries temporais para um acompanhamento
de uma suspeita de malignidade. Estas são limitações encontradas na base de imagem
utilizada [de Carvalho Filho 2016].
5. Conclusão
Neste trabalho foi proposto um CADx de nódulo pulmonar para classificar com MVS e
CNN, a partir de caracterı́sticas extraı́das por Índices de Diversidade Funcional adaptados
da biologia. Os resultados obtidos foram promissores com acurácia de 86,7%, sensibili-
dade de 85,4% e especificidade de 87,1% e uma curva ROC de 0,91 com o classificador
CNN. A diversidade de nódulos benignos e malignos presentes na base de imagens LIDC-
IDRI utilizada agrega confiabilidade a metodologia, garantida pelos 1.403 nódulos, destes
1.009 benignos e 394 malignos.
Dificilmente o câncer pulmonar é dignosticado em estágio inicial, devido a
ausência de sintomas. O diagnóstico precoce representa um aumento na probabilidade
de sobrevida dos pacientes. A automatização da classificação de nódulos pulmonares pre-
sente neste trabalho, poderá integrar uma ferramenta CADx para ser aplicada em casos
atuais no diagnóstico e acompanhamento de câncer de pulmão, com intuito de identificar
a natureza dos nódulos pulmonares em maligno ou benigno, fornecendo ao especialista
uma segunda opinião.
Referências
(2016). Inca.
Chang, C.-C. and Lin, C.-J. (2011). Libsvm: a library for support vector machines. ACM
Transactions on Intelligent Systems and Technology (TIST), 2(3):27.
Cianciaruso, M. V., Silva, I. A., and Batalha, M. A. (2009). Diversidades filogenética
e funcional: novas abordagens para a ecologia de comunidades. Biota Neotropica,
9(3):93–103.
Clark, K., Vendt, B., Smith, K., Freymann, J., Kirby, J., Koppel, P., Moore, S., Phillips, S.,
Maffitt, D., Pringle, M., et al. (2013). The cancer imaging archive (tcia): maintaining
and operating a public information repository. Journal of digital imaging, 26(6):1045–
1057.
Damasceno, M. d. S. (2016). Classificaccão automática de massas em imagens ma-
mográficas usando ı́ndices de diversidade funcional.
de Carvalho Filho, A. O. (2016). Métodos para sistemas cad e cadx de nódulo pulmonar
baseada em tomografia computadorizada usando análise de forma e textura.
de Carvalho Filho, A. O., de Sampaio, W. B., Silva, A. C., de Paiva, A. C., Nunes, R. A.,
and Gattass, M. (2014). Automatic detection of solitary lung nodules using quality
threshold clustering, genetic algorithm and diversity index. Artificial intelligence in
medicine, 60(3):165–177.
290
Dhara, A. K., Mukhopadhyay, S., Dutta, A., Garg, M., and Khandelwal, N. (2016). A
combination of shape and texture features for classification of pulmonary nodules in
lung ct images. Journal of digital imaging, 29(4):466–475.
Firmino, M., Angelo, G., Morais, H., Dantas, M. R., and Valentim, R. (2016). Computer-
aided detection (cade) and diagnosis (cadx) system for lung cancer with likelihood of
malignancy. Biomedical engineering online, 15(1):2.
Gonzalez, R. C. and Woods, R. E. (2007). Image processing. Digital image processing,
2.
Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., and Witten, I. H. (2009).
The weka data mining software: an update. ACM SIGKDD explorations newsletter,
11(1):10–18.
Haralick, R. M., Shanmugam, K., et al. (1973). Textural features for image classification.
IEEE Transactions on systems, man, and cybernetics, 3(6):610–621.
Hua, K.-L., Hsu, C.-H., Hidayati, S. C., Cheng, W.-H., and Chen, Y.-J. (2015). Computer-
aided classification of lung nodules on computed tomography images via deep learning
technique. OncoTargets and therapy, 8.
Ivanciuc, O. (2005). Svm-support vector machines. Retrieved April, 10:2012.
Kumar, D., Wong, A., and Clausi, D. A. (2015). Lung nodule classification using deep
features in ct images. In Computer and Robot Vision (CRV), 2015 12th Conference on,
pages 133–138. IEEE.
LeCun, Y., Bottou, L., Bengio, Y., and Haffner, P. (1998). Gradient-based learning applied
to document recognition. Proceedings of the IEEE, 86(11):2278–2324.
Orozco, H. M., Villegas, O. O. V., Sánchez, V. G. C., Domı́nguez, H. d. J. O., and Alfaro,
M. d. J. N. (2015). Automated system for lung nodules classification based on wavelet
feature descriptor and support vector machine. Biomedical engineering online, 14(1):9.
Petchey, O. L. and Gaston, K. J. (2002). Functional diversity (fd), species richness and
community composition. Ecology Letters, 5(3):402–411.
Silva, G. L. F. d. (2015). Detecção de lesões mamográficas usandon redes neurais com-
pletamente convolucionais.
Sousa, J. R. F. (2007). Metodologia para detecção automáticas de nódulos pulmonares.
Tilman, D. (2001). Functional diversity. Encyclopedia of biodiversity, 3(1):109–120.
Van Erkel, A. R. and Peter, M. (1998). Receiver operating characteristic (roc) analy-
sis: basic principles and applications in radiology. European Journal of radiology,
27(2):88–94.
van Ginneken, B., Armato, S. G., de Hoop, B., Van Amelsvoort Van de Vorst, S., Duin-
dam, T., Niemeijer, M., Murphy, K., Schilham, A., Retico, A., Fantacci, M. E., et al.
(2010). Comparing and combining algorithms for computer-aided detection of pul-
monary nodules in computed tomography scans: the anode09 study. Medical image
analysis, 14(6):707–722.
291
Modelagem e Simulação do Deslocamento de Pessoas: uma

técnica para a previsão de formação de grupos
Frank C. L. Véras1 , Alisson V. de Brito2 , Angelo Negreiros2 , Nécio de L. Véras3
1
Universidade Federal do Piauı́ (UFPI)
Picos – PI, Brazil
2
Centro de Informática – Universidade Federal da Paraı́ba (UFPB)
João Pessoa – PB, Brazil
3
Instituto Federal do Ceará (IFCE)
Tianguá – CE, Brazil
[email protected]
Abstract. The use of Wireless Sensor Networks has been diffused in several
areas of research and application, such as in environments where people move
with common characteristics of movement. The proposal of this work is a study
on how to use these sensors to monitor the displacement of people and predict
the formation of groups. Using the Ptolemy II simulator with ZigBee protocol,
sensors identified by Cartesian coordinates, people with RFID tags and with
specific characteristics, it was possible to mathematically formalize the move-
ment of the crowd. The data collection was interpreted by an algorithm that
estimates the formation of multitude in a certain region.
Resumo. O uso das Redes de Sensores sem Fio tem sido difundido em diversas
áreas de pesquisa e aplicação, como em ambientes em que pessoas se deslocam
com caracterı́sticas comuns de movimento. A proposta deste trabalho é um
estudo sobre como utilizar esses sensores para monitorar o deslocamento de
pessoas e prever a formação de grupos. Utilizando o simulador Ptolemy II, com
protocolo ZigBee, sensores identificados por coordenadas cartesianas, pessoas
com etiquetas RFID e com caracterı́sticas especı́ficas, foi possı́vel formalizar
matematicamente o movimento da multidão. A coleta dos dados foi interpretada
por um algoritmo que estima a formação de multidão em determinada região.
1. Introdução
Ambientes com grandes aglomerados de pessoas têm sido alvo de importan-
tes pesquisas, com resultados significantes para a humanidade. Exemplos
como: um sistema de bloqueio veicular contra acidentes envolvendo pedestres
[Saito and Raksincharoensak 2016], a simulação do movimento de multidão durante
inundação [Vijitpornkul and Marurngsith 2015], o monitoramento ambiental e detecção
biológica [Das and Roy 2014], bem como tecnologias utilizadas no cotidiano das cidades
[Iscaro and Nakamiti 2013] demonstram o avanço nessa área e a necessidade de controlar
ambientes com fluxo maior de pessoas.
292
Atualmente, vários projetos para Cidades Inteligentes utilizam RFID (Radio Fre-
quency Identification), IoT (Internet of Things) e VANTs (Veı́culos Aéreos Não Tripu-
lados) que podem ser utilizados como um nó móvel, recolhendo e entregando dados em
uma RSSF (Rede de Sensores sem Fio), cuja comunicação pode ser realizada pela rede
de celular ou por um rádio dedicado de longa distância [Giyenko and Cho 2016].
O avanço da microeletrônica e das RSSF tornaram possı́vel o uso de sensores
de baixo custo que coletam informações e beneficiam o uso do RFID. A proposta de
[Yu and Chan 2014] é usar etiquetas inteligentes e leitores RFID para localizar coordena-
das de um objeto, auxiliado por GPS (Global Positioning System). Porém, [Fahmy 2016]
apresenta um Smartphone Android, usado como uma IMU (Inertial Measurement Unit),
para rastrear uma pessoa deslocando-se no interior de um ambiente, baseando-se no fato
de que a navegação por satélite não é capaz de funcionar em lugares fechados.
A proposta deste artigo é apresentar uma técnica que realize a estimativa do mo-
vimento de multidões baseada na troca de mensagens entre sensores, desenvolvido em
ambiente simulado e aplicado às RSSF. O ponto forte deste trabalho está no uso da tec-
nologia para gerenciar multidões e evitar transtornos com públicos maiores, usando mo-
delagem e simulação do deslocamento de pessoas, além de uma solução baseada na troca
de mensagens para estimar, antecipadamente, a formação de grupos de pessoas.
2. Modelagem e Simulação do Deslocamento de Pessoas

Para simular o ambiente real, um modelo de posicionamento dos sensores baseado em um
sistema de coordenadas cartesianas capta os movimentos das pessoas que valida o cálculo
proposto das distâncias percorridas pelos objetos, definindo-se as posições de cada sensor
e a distância entre eles.
2.1. Modelagem dos Componentes

No ambiente de simulação do Ptolemy II, baseado no projeto de [Baldwin 2013], um
objeto é uma pessoa (ator) em movimento e, para cada pessoa simulada, foram atribuı́dos
parâmetros individuais: idPeople (número inteiro), velocidade de deslocamento de uma
pessoa e o tipo de movimento que a pessoa percorrerá até o alvo (retilı́neo, hiperbólico ou
parabólico). O alvo é um ponto a ser atingido no ambiente.
Para a coleta de dados, cada pessoa carrega um transmissor RFID que emite sinais
de rádio frequência e, com o deslocamento das pessoas, são detectadas pelos Sensores
RFID Base (SB). A comunicação entre os Sensores Centrais (SC) é baseada no proto-
colo [ZigBee 2012]. Cada SC está ligado a outros oito SC’s próximos a ele (Figura 1)
e são identificados como vizinho do Norte, do Sul, do Leste, do Oeste, do Noroeste, do
Nordeste, do Sudoeste e do Sudeste.
Cada SC representa uma das quinze regiões (R1 a R15) em que foi distribuı́da
a RSSF. Cada SB transmite os dados recebidos (identificação da pessoa, a posição e o
instante da detecção) para o seu SC, registrando a presença de cada pessoa naquela região
e naquele instante.
O cenário simulado foi o pátio de acesso de um estádio brasileiro, cujos dados
foram extraı́dos do [Google-Earth 2014]. Para o posicionamento dos sensores, foi res-
peitada a recomendação relativa às distâncias entre os sensores (17,7 metros) de uma
293
RSSF com protocolo [ZigBee 2012], resultando num retângulo com dimensões 160,06
por 88,86 metros.
Figura 1. Posição dos sensores, regiões e distâncias no Ptolemy II
A modelagem do deslocamento da multidão é uma função movimento uniforme.

Assumindo que as pessoas se deslocam sem aceleração, é possı́vel extrair a variação do
movimento num intervalo e prever sua localização futura. Assim, a coleta dos dados
sobre o movimento das pessoas em intervalos pequenos de tempo, mantém atualizadas as
informações sobre o movimento e melhora a acurácia da estimativa.
Mensagens de alarme são disparadas antecipando que, provavelmente, multidões
serão formadas naquela região, havendo tempo hábil para que sejam tomadas medidas de
preparação para determinado evento.
2.2. Estimativa da Formação de Grupos Através da Troca de Mensagens

A troca de mensagens entre sensores vizinhos ocorre através de mensagens pontuais en-
viadas por um sensor e são elas: Notify, Alert e Alarm. Se um sensor detecta um aumento
na quantidade de pessoas em sua área, uma mensagem Notify é enviada por um sensor a
todos os seus vizinhos.
Os parâmetros especificados nessa mensagem informam: qual foi o sensor “s” que
originou a mensagem, o momento “tn ” em que a variação foi detectada, a quantidade “n”
da variação de pessoas e a identificação “id” de cada pessoa que foi detectada naquele
instante. O “id” é um parâmetro utilizado para que cada sensor realize uma checagem
e eliminação das pessoas que são contabilizadas repetidamente. Isso ajusta o algoritmo
desenvolvido para que ele não conte mais de uma vez a mesma pessoa, em um mesmo
tempo.
Por outro lado, os vizinhos que recebem um Notify, armazenam esta mensagem,
até que seja enviado para ele um Alert, em um momento seguinte. Caso um sensor detecte
uma variação de pessoas para mais na sua região e ele tenha armazenado uma mensagem
Notify anteriormente, uma mensagem Alert será criada e enviada por ele, indicando alerta
de movimentação de pessoas numa determinada direção e sentido. A mensagem é enviada
apenas para um sensor, denominado de destinatário e definido como “sd”. Ela conterá
também a quantidade estimada “n” de pessoas em movimentação e o tempo da previsão
“tp ” em que essa quantidade alcançará seu vizinho.
As mensagens Alert recebidas são sempre repassadas para os vizinhos e atua-
lizam o tempo estimado para a formação de aglomeração. O “sd” de uma mensagem
294
Alert é o sensor vizinho que está na mesma direção e em sentido contrário à origem da
movimentação das pessoas. Por exemplo, se um sensor recebe um Notify do seu vizinho
do oeste e percebe uma variação de pessoas no instante seguinte em sua própria região,
ele assume que há, possivelmente, um fluxo de pessoas vindo do oeste para o leste. Em
seguida, cada sensor envia um Alert para seu vizinho do leste, propagando-se a mensagem
pela rede.
A quantidade de pessoas “n” será dada pela variação de pessoas na sua área (e
não no que determina a mensagem Notify armazenada). O tempo “tp ” será definido pelo
tempo atual (ta ), mais a diferença entre “ta ” e o tempo indicado na mensagem Notify (tn ),
ou seja: “tp ” = ta + (ta - tn ).
A mensagem Alarm é utilizada para indicar que, num determinado instante, haverá
uma aglomeração de pessoas numa determinada região. Isso ocorrerá em um instante “t”,
se a soma de todas as quantidades de pessoas previstas nas mensagens Alert recebidas por
um sensor for maior ou igual ao limite aceitável, previamente configurado.
3. Experimentos
Um cenário foi configurado no Ptolemy II para simular torcedores acessando um estádio
de futebol. O experimento realizado foi repetido várias vezes, porém, todos eles foram
feitos em janelas de tempo, cuja variação foi de 5 em 5 unidades de tempo (ut), por
critério de validação do algoritmo. Antes disto, foi feita uma adequação de escalas entre
o ambiente simulado e o ambiente real.
3.1. Relação de Escalas do Ambiente Real com o Simulado

Como a disposição dos sensores (Figura 1) forma quadrados, cuja diagonal mede 25,13
metros, tem-se que a área de cobertura de um SB é de 495,35m2 .
Segundo a [ABNT-NBR-9050 2004], considera-se três pessoas por metro qua-
drado como uma quantidade suportável de pessoas. Então, proporcionalmente, a área de
um SB comporta um limite de 1.486 pessoas. A partir de 12 objetos pessoa detectadas
por esse sensor, por unidade de tempo, é que mensagens Alarm são enviadas para alertar
aos vizinhos dos riscos iminentes.
Para a simulação, a escala de referência é de 20 unidades de comprimento no
simulador, para cada 1 (um) metro no ambiente real e, cada unidade de tempo simulado,
corresponde a um segundo. Portanto, convencionou-se que a velocidade de um objeto
pessoa é de 1 m/s, seguindo as referências do [DNIT 2014].
4. Resultados
4.1. Cenário - Estádio
Simulando 50 pessoas chegando ao estádio de diversas direções e tipos de movimentos
diferentes, em busca do Portão de entrada (alvo), elas percorrem a área da RSSF em 70
unidades de tempo, correspondentes a 1 minuto e 10 segundos reais.
A Figura 2 apresenta um gráfico com a quantidade de pessoas detectadas em três
regiões simuladas. A Região 15 é a primeira do canto superior esquerdo (conforme Figura
1), a Região 8 fica no centro e a Região 1 está no canto inferior direito, próximo ao alvo,
e que registra aumento na quantidade de pessoas ao longo do tempo.
295
Figura 2. Gráfico das regiões do Cenário 1: Quant.Pessoas x Tempo
O Grau de Antecipação (GA) mede quantas unidades de tempo, antes do evento

real, o algoritmo prevê a aglomeração. No modelo simulado, o algoritmo previu (e alar-
mou) que 17 pessoas estariam no alvo (portão), com GA de 15 unidades de tempo, embora
20 pessoas tenham chegado no alvo, na realidade.
5. Repetibilidade e Análise das Medições

Nesta etapa, foram repetidos 60 testes (simulações) para o cenário descrito anteriormente,
divididos em três grupos de 20 testes cada, de acordo com o GA desejado. Neste caso, o
Grupo 1, com GA igual a 15 ut, o Grupo 2, com 20 ut e o Grupo 3, com 25 ut. A grandeza
GA foi adotada para medir as Unidades de Tempo, antes do evento real, que o algoritmo
poderia calcular, prevendo a formação de grupos de pessoas, caso ocorresse, no Portão de
acesso.
Figura 3. Gráfico das regiões para 15ut
A Incerteza Padrão (U M (I)), que é a medida da intensidade da componente

aleatória do erro de medição e que corresponde à estimativa do desvio padrão da
distribuição dos erros de medição, conforme [Albertazzi and Sousa 2008], foi estimada
296
através de procedimentos estatı́sticos a partir de um conjunto de “n” medições repetidas,

de acordo com a Equação 1:
sP
n
− I)2
i=1 (IK
UM (I) = (1)
n−1
A partir dos dados coletados pelo algoritmo, de acordo com os três grupos de
testes, foram calculados, para cada grupo, a Média da Exatidão (em porcentagem), o
Desvio Padrão, o Erro e o cálculo da (UM (I)). O grau de liberdade para a repetição dos
testes é de 19 (pois, n – 1 = 20 – 1).
As Figuras 3, 4 e 5 apresentam gráficos, de acordo com os GA’s aplicados (15ut,
20ut e 25ut, respectivamente), relativos às variações na Exatidão (em porcentagem) regis-
tradas em cada um dos grupos de 20 testes.
Para encontrar a Incerteza Expandida, foi multiplicado o valor da (UM (I)) pelo
valor do Coeficiente de Student [Albertazzi and Sousa 2008], correspondente ao número
de Graus de Liberdade, conforme a Tabela 1.
Tabela 1. Cálculo da Incerteza Expandida
6. Conclusões
A simulação proposta usou um algoritmo que apresentou uma técnica de previsão de
formação de aglomeração de pessoas, tendo emitido vários alarmes corretamente nos
cenários apresentados.
Observando os cálculos realizados com a ajuda da Equação 1, foi encontrada a In-
certeza Padrão aplicada à Exatidão (em porcentagem) da previsão de formação de grupos
de pessoas, baseado nos três GA’s simulados. A análise mostrou que a menor Incerteza
Padrão encontrada foi aquela em que o GA aplicado era igual a 15 ut. Fazendo a devida
aproximação das casas decimais, foi encontrado o seu (UM (I)) = 0,694, bem como o seu
RM E (Resultado da Medição da Exatidão): RM E = 84,97 + ou - 0,694.
297
Como propostas futuras, seria apropriado realizar novos testes e aprimorar as

técnicas e métodos tecnológicos e metrológicos para, aumentar o GA e diminuir ainda
mais (ou ao menos manter) a Incerteza Padrão (UM (I)).
Assim, pela acurácia encontrada (84,97%, com a exatidão variando entre + ou -
0,694), a técnica pode ser útil para evitar aglomerações excessivas e que poderão causar
pânico. Nesses casos, pode auxiliar na tomada de decisões diante de situações considera-
das de risco e evitar tragédias, emitindo os alertas.
Referências
ABNT-NBR-9050 (2004). In Guia prático de acessibilidade.
http://ptolemy.eecs.berkeley.edu/papers/05/visualsense/visualsense.pdf.
Albertazzi, A. and Sousa, A. R. (2008). Fundamentos de metrologia cientı́fica e industrial.
Ed. Manole.
Baldwin, P. (2013). In VisualSense: Visual Modeling for Wireless and Sensor Network
Systems. http://ptolemy.eecs.berkeley.edu/papers/05/visualsense/visualsense.pdf.
Das, T. and Roy, S. (2014). Coordination based motion control in mobile wireless sen-
sor network. International Conference on Electronic Systems, Signal Processing and
Computing Technologies - IEEE.
DNIT (2014). Departamento nacional de infraestrutura de transportes. In Manual de
projeto geométrico de travessias urbanas, page 740. http://ipr.dnit.gov.br/normas-e-
manuais/manuais/publicacoes.
Fahmy, Y. (2016). Android smartphone usage as a pedestrian tracking system. Cairo
University, ICM-IEEE.
Giyenko, A. and Cho, Y. I. (2016). Intelligent unmanned aerial vehicle platform for smart
cities. Department of Computer Engineering, SCIS-IEEE, Graduate School, Gachon
University, Korea.
Google-Earth (2014). http://earth.google.com.
Iscaro, G. and Nakamiti, G. (2013). A supervisor agent for urban traffic monitoring. Inter-
national Multi-Disciplinary Conference on Cognitive Methods in Situation Awareness
and Decision Support, CogSIMA-IEEE.
Saito, Y. and Raksincharoensak, P. (2016). A shared control in risk predictive braking
manoeuvre for preventing collision with pedestrian. Tokyo University of Agriculture
and Technology, SMC-IEEE.
Vijitpornkul, S. and Marurngsith, W. (2015). Simulation crowd movement in agent-based
model of large-scale flood. In Department of Computer Science. Thammasat Univer-
sity, Thailand, ICAICTA-IEEE.
Yu, H. and Chan, J. (2014). An intelligent space location identification system based on
passive rfid tags. International Conference on Machine Learning and Cybernetics -
IEEE, Department of Electrical Engineering, National Taiwan University of Science
Technology.
ZigBee (2012). http://zigbee.org.
298
Plataforma Educacional para Crianças com Dislexia

Maria Jadielly Dias Lima1 , Me.Frank César Lopes Véras3 , Ma.Isabel Orquiz2 ,
Josafá Martins dos Santos1 , Naara Macêdo1
1
Sistemas de Informação – Universidade Federal do Piauí (UFPI)
CEP 64600-000 – Picos – PI – Brazil
2
Pedagogia – Universidade Federal do Piauí (UFPI)
CEP 64600-000 – Picos – PI – Brazil
3
Departamento de Ciência da Computação
Universidade Federal da Paraíba (UFPB) – João Pessoa, PB – Brazil
{desenvolvedorajadielly, devjosafa}@gmail.com
Abstract. In the initial school phase, some students face too much difficulty in
developing and understanding language. This problem may be associated with
a learning disorder called dyslexia. In this work a web platform was developed
with educational games for dyslexic children, aiming to improve their language
learning abilities. During the research, data were collected through question-
naires related to the performance of the developed system and the Human Com-
puter Interaction of the platform. The results presented a low percentage of
game error messages, making the environment useful for the area in question.
Resumo. Alguns alunos enfrentam dificuldade no desenvolvimento e na com-

preensão da linguagem. Este problema pode estar associado a uma dificuldade
de aprendizagem denominada Dislexia. Este trabalho apresenta uma plata-
forma web com jogos educativos para crianças disléxicas, com objetivo de me-
lhorar suas habilidades de aprendizado. Nesta pesquisa, foram coletados dados
através de questionários relacionados ao desempenho do sistema desenvolvido
e à sua Interação Humano Computador. Os resultados apresentaram um baixo
percentual nas mensagens de erros dos jogos,porém o sistema foi considerado
útil para a área em questão.
1. Introdução
Atualmente, um dos grandes desafios das escolas é fornecer uma educação de qualidade
para crianças que possuem Necessidades Educacionais Especiais(NEE). Estas podem es-
tar associadas a problemas temporários que com o passar do tempo e tratamento adequado
o problema pode ser sanado, porém em alguns casos, estes alunos podem apresentar Difi-
culdades de Aprendizagem(DA).
DA refere-se a um distúrbio em um ou mais processos psicológicos básicos envol-
vidos no entendimento ou no uso da linguagem, podendo se manifestar em uma aptidão
imperfeita para ouvir, pensar, falar, ler, escrever, soletrar ou realizar cálculos matemáti-
cos [Grigorenko and Stenrnberg 2003]. Geralmente, são caracterizadas pela desordem ou
disfunção no processo de aprendizado [Barbosa 2015].
299
É necessário que fornecer maior atenção aos alunos que manifestem tais dificul-
dades, pois sem o devido acompanhamento, a situação pode agravar-se. Estas atitudes
trazem benefícios no desenvolvimento educacional dos alunos e no seu desempenho es-
colar.
Dentre os diversos tipos de DA, a Dislexia pode ser notada na fase de alfabetiza-
ção, sendo caracterizada pela falta de maturidade cognitiva e intelectual. No entanto, em
grande parte dos casos ela não é detectada, dificultando ainda mais o desenvolvimento
das habilidades de leitura e escrita da criança [Guckert and Faveri 2008].
Este trabalho tem o objetivo de apresentar uma plataforma web, desenvolvida para
permitir que uma equipe multidisciplinar possa indicar jogos, presentes na plataforma,
para crianças disléxicas de acordo com suas habilidades afetadas, a fim de utilizar estes
jogos como forma de execitação.
2. Revisão Bibliográfica
As dificuldades de aprendizado estão presentes no âmbito escolar há um tempo conside-
rável. Até parte século XIX, todas as DAs apresentadas pelas crianças eram atribuídas a
um déficit intelectual [Pinheiro 2009]. Somente, mais tarde elas foram estudadas e com-
preendidas, amenizando os problemas dos indivíduos portadores desta condição.
2.1. A Dislexia
A dislexia caracteriza-se por uma deficiência na habilidade de leitura e escrita, que va-
riam de pessoa para pessoa, podendo apresentar desde graus mais leves aos mais graves
[Santos et al. 2014].
Os sintomas tornam-se mais notórios na escola, onde é preciso buscar a ajuda
especializada para o tratamento desta disfunção [Santos et al. 2014]. E é na sala de aula
que a dislexia é mais incidente [ABD 2016].
A Dislexia é uma desordem genética que de acordo com o Misnistério da Educa-
ção [MEC 2017] afeta cerca de 5% da população brasileira e 17% da população mundial,
nos casos diagnosticados, e embora não seja um assunto tão abordado atualmente, é consi-
derada uma das causas mais frequentes de baixo rendimento, fracasso e abandono escolar.
São três os tipos de dislexia [IPODINE 2014] : a) Visual - onde o indivíduo con-
funde letras e palavras parecidas, podendo revertê-las; b) Auditiva - dificuldade para dis-
tinguir unidades de sons da linguagem, dividir palavras por sílabas, relacionar o som com
a escrita, soletrar; e c) Mista - considerado o mais grave tipo, pois possui tendência de
apresentar ambos os problemas visual e auditiva.
No entanto, há alguns sinais que requerem a atenção . A Associação Brasielira de
Dislexia [ABD 2016] aponta vários destes sinais na pré-escola (como o atraso no desen-
volvimento da fala e da linguagem) e na idade escolar (como a dificuldade na aquisição
e automação da leitura e da escrita) e que devem ser analisados de forma cuidadosa, para
garantir que a criança obtenha um acompanhamento adequado e eficiente.
2.2. Diagnóstico e a Tecnologia da Informação Interventiva

A avaliação e o diagnóstico da dislexia deve ser realizado por uma equipe multidiscipli-
nar composta por psicólogos, neurobiologistas, psicopedagogos e fonoaudiólogos que se
300
utilizam de instrumentos para avaliar a linguagem oral e escrita, bem como as funções
cognitivas e perceptivas do indivíduo [ABD 2016].
No tratamento, métodos de intervenção pedagógicos, como o Multissensorial
(olhar letras impressas e subvocalizar sons, realizar movimentos e utilizar conhecimen-
tos linguísticos para aceder ao sentido das palavras) e o Fônico (privilegia o uso da vi-
são, audição e tato), auxiliam no desenvolvimento das habilidades afetadas pela Dislexia
[Prado and Alioto 2012].
No entanto, a Tecnologia da Informação (TI), combinada com métodos pedagógi-
cos de ensino, diminuem essa dificuldade que os alunos têm em aprender na sala de aula
[Souza and Souza 2010] e tem se tornado uma ferramenta bastante eficaz para se trabalhar
com o disléxico.
Tabela 1. Comparação de softwares.

Caracteristicas Aprendendo c. as S. Aramumo Mimosa Plataforma
Memorização, asso-
Memorização,
ciar de imagem e
Associação entre associar imagem
palavras, sílabas Separação silábica,
fonemas, repre- e palavras, sepa-
com seus fonemas, ortografia, reconhe-
sentação gráfica, rar sílabas, reco-
Habilidades? interpretação, dife- cimento e memori-
escrita e interna- nhecer grafemas
renciação de pala- zação de sons e
lização de novas e fonemas e co-
vras, percepção e coordenação motora.
palavras. ordenação moto-
imitação auditiva
ra.
e visual.
Sons? Sim Sim Sim Sim
Não foram
Não foram encontra- Não foram encontra-
Experimentos? encontrados Sim.
dos experimentos. dos experimentos.
experimentos.
Não foi encontrada
Plataforma Android Android Web
esta informação.
Existem trabalhos que também buscam oferecer formas de intervir na Dislexia. Dentre
estes softwares estão: a) o Aprendendo com as sílabas, desenvolvido por alunos da Es-
cola Superior de Criciúma (ESUCRI); b) o Aramumo; e c) Mimosa e o Reino das Cores,
os dois últimos foram desenvolvidos por alunos do Instituto Tecnológico de Aeronáutica
(ITA) em parceria com o Instituto ABCD (organização social que atua no apoio a crianças
com dificuldades de aprendizagem) [Stolk et al. 2013]. As principais semelhanças e di-
ferenças destes softwares e da Plataforma Educacional, podem ser visualizados na Tabela
1.
4. Desenvolvimento do software
Para desenvolvimento desta plataforma foram utilizadas as linguagens Ruby on Rails,
HTML, CSS e Java Script. A primeira é um framework que utiliza a linguagem orientada
a objetos, chamada Ruby e as demais, são utilizadas para construção de páginas web.
301
O objetivo de desenvolvimento desta plataforma é proporcionar uma maior intera-

ção entre a equipe multidisciplinar e crianças dislexas. Para isso, a plataforma conta com
4 (quatro) jogos, que serão apresentados a seguir. com isso, a equipe multidisciplinar
poderá indicar, através da plataforma, as atividades (jogos) que a criança deve realizar.
É importante ressaltar, que o sistema não dispensa a avaliação pessoal da equipe
multidisciplinar e também a tradicional intervenção. O intuito da plataforma é apenas
propor uma alternativa lúdica no tratamento da Dislexia e que possa auxiliar nos aspectos
como: Memorização, separação de sílabas, reconhecimento de grafemas e fonemas, as-
sociação de imagens e palavras e coordenação motora, que são habilidades afetadas por
esta DA.
Para que a criança tenha acesso as jogos em casa, é preciso entrar no sistema
através de login e senha, e então as atividades disponíveis para ela podem ser visualizadas,
Figura 1(a).
(a) (b)
Figura 1. Visualização dos jogos recomendados e Nível 02 Jogo das vogais.
Os jogos dispostos no sistema foram desenvolvidos utilizando o Construct 2, fer-

ramenta gratuita para construção de jogos 2D. Além disso, os jogos foram desenvolvi-
dos com acompanhamento de pedagogos, psicopedagogos e psicólogos, profissionais que
avaliam, diagnosticam e fazem o acompanhamento e tratamento de disléxicos.
A partir disso, os profissionais sugeriram o uso dos jogos construídos a partir de
metodologias pedagógicas. As metodologias utilizadas são denominados método Fônico
e método Multissensorial, comumente utilizados no tartamento da Dislexia.
Para uma maior interação com a criança e, também, para que a mesma possa
compreender o que é pedido nos jogos, há uma boneca de interação que, através de falas
fornece as informaçãoes necessárias para as ações do usuário,instruindo-o em todas as
telas. Além disso, cada jogo possui níveis e fases com aumento de dificuldades, para
que o usuário possa exercitar gradativamente suas habilidades, sendo permitido encerrar
o jogo a qualquer momento ou reiniciá-lo quando desejado.
4.1. Jogo das Vogais
Este jogo possui 2 (dois) níveis, no primeiro a criança é incentivada a conhecer as vo-
gais, através de sons e assossiações com imagens. Já o segundo a mesma é convidada a
apontar qual é a vogal que inicia cada palavra, de acordo com a Figura 1(b). Casoa vogal
escolhida não for a correta, então é apresentada uma mensagem de erro, onde a boneca de
interação pede para que a criança tente outra vez, e então automaticamente retona para a
tela anterior, Figura 2(a).
302
(a) (b)
Figura 2. Mensagem de Erro e Jogo do Alfabeto.
4.2. Jogo do Alfabeto

Neste jogo são dispostas todas as letras do alfabeto e uma imagem por vez, apresentada
aleatoriamente e então, a criança deve clicar na letra que inicia a palavra que representa
a imagem. Ao clicar na imagem ou nas letras é possível ouvir o seu som, por exemplo
"caju", Figura 2(b). O jogo encerra quando o usuário passar por todas as letras do alfabeto.
4.3. Jogo das Sílabas

Este possui 3 (três) níveis, onde são apresentadas uma imagem, uma palavra incompleta
e um par de sílabas para que o usuário possa apontar a sílaba que completa corretamente
a palavra. A cada nível o tamanho da palavra aumenta e, consequentemente o nível de
dificuldade, Figura 3(a).
(a) (b)
Figura 3. Jogo das Sílabas e do Labirinto.
4.4. Jogo do Labirinto

Este jogo possui 3 níveis e, conforme se avança de nível, obviamente, aumenta-se a difi-
culdade. Neste jogo, não são apresentadas palavras pois o seu intuito é tratar a dificuldade
espacial da crianças dislexas, bem como sua capacidade de diferenciação de lados, além
de habilidades motoras, Figura 3(b).
5. Resultados
Para avaliação dos resultados destes experimento, é importante ressaltar que o sistema
não pode ser validado com crianças dislexas, pois ainda não houve tal oportunidade, con-
siderando que este tipo de experimento requer bastante tempo, sendo necessário uma ava-
liação com uma amostra de dislexicos que devem utilizar o sistema por um determinado
período de tempo e comparar os resultados com os métodos tradicionais.
303
Os experimentos foram realizados com profissionais, que representam a equipe

multidisciplinar, estudantes de Pedagogia e de Sistemas de Informação, pois acreditamos
que esta seria outra forma válida de avaliação. Contudo, não descartamos a validação
futura com crianças dislexas na Educação Básica.
5.1. Experimento com Acadêmicos de Licenciatura em Pedagogia
Para estes experimentos, contamos com uma amostra de 14 (quatorze) estudantes de Pe-
dagogia. Estes, puderam utilizar o sistema e, em seguida responderam ao questionário,
Tabela 2. O intuito deste questionário é coletar informações de estudantes que já possuem
experiência com educação especial, e verificar a sua opinião a respeito da utilidade do
sistema em relação ao tratamento da Dislexia.
De acordo com as respostas encontradas, os estudantes classificaram o sistema
como sendo "Excelente"em quase todas as questões perguntadas, como na questão 7,
por exemplo, no que se refere a utilidade do mesmo para a equipe multidisciplinar. Foi
classificado como "Bom"na questão 2, 2, em relação a interface. Obtivemos poucas res-
postas para "Regular", somente nas questões 2, 3 e 6. O sistema não foi classificado como
"Ruim"ou "Péssimo"pelos estudantes.
De acordo com os estudantes, o sistema é bastante útil, no que diz respeito a
utilidade tanto para a equpe multidisciplinar quanto para crianças Dislexas. Para eles deve
ser melhorados em aspectos como cores de interface e em relação aos jogos, a boneca de
interação deve fornecer mais informações ao usuário para as ações que o mesmo deve
realizar.
Tabela 2. Questionário para acadêmicos de Pedagogia e Profissionais.

1 Considera que o software é útil?
2 A interface é agradável?
3 O software é fácil de utilizar?
4 Como você considera o funcionamento do software?
5 O software é de fácil compreensão?
As atividades propostas no software auxiliam no desenvolvimento das capacidades de
6
leitura e escrita do disléxico?
7 Este software auxilia o trabalho da equipe multidisciplinar?
8 Em relação ao tempo de resposta do software. Considera adequado?
Com relação a finalidade do software, você considera que este realiza as atividades para
9
as quais foi desenvolvido?
10 Considera a disposição de objetos na tela adequado?
5.2. Experimento com Pedagogos e Psicólogos

Para estes experimentos, utilizamos uma amostra com 5 (cinco) profissionais, entre eles
uma psicóloga e 4 (quatro) pedagogos. Estes profissionais também utilizaram o sistema e,
a partir disso, responderam ao questionário, 2. Este tem como objetivo coletar a opinião
dos mesmos em relação a eficiência do sistema para disléxicos e para a equipe multidis-
ciplinar.
Para os profissionais, o sistema foi classificado como "Excelente"e "Bom", não
havendo resppostas para as demais opções, 4(b). Em perguntas como questão 3 e 5, em
304
(a) (b)
Figura 4. Experimento de Estudantes e Profissionais.
aspectos de facilidade de uso e compreensão, por exemplo, os profissionais classificaram

como excelente 100%.
De acordo com estes profissionais, o sistema é bastante útil para a finalidade pela
qual foi desenvolvido, o tratamento de dislexos. Porém é necessário melhorar em pontos
como, por exemplo, fornecer mais informações nos jogos, sobre as ações do usuário. No
quesito interface e adequação de jogos, consideraram que o sistema é bastante eficiente.
5.3. Experimentos com Acadêmicos de Sistemas de Informação

Neste experimento, uma amostra com 15 (quinze) estudantes de Sistemas de Informação
utilizaram o sistema e, em seguida responderam ao questionário, Tabela 3. O objetivo
deste questionário é coletar a opinião dos alunos que cursaram a disciplina de Interação
Humano Computador (IHC), com o intuito verificar o aspecto usabilidade do sistema
através de suas respostas, Figura 5.
Tabela 3. Questionário para acadêmicos de Sistemas de Informação.

1 O usuário encontra disponível as informações para suas ações?
2 O sistema fornece feedback para todas as ações do usuário?
3 Os ícones são legíveis?
4 A densidade informacional das janelas é reduzida?
5 As telas apresentam informações necessárias para o usuário em sua tarefa?
6 O usuário necessita lembrar os dados exatos de uma tela para outra?
7 O sistema aresenta um grande números de janelas que podem desconcentrar o usuário?
8 As mensagens de erro ajudam a resolver o problema do usuário?
9 As frases das mensagens de erro são curtas, significativas e de uso comum?
10 Os formatos de apresentação dos dados são mantidos de uma janela para outra?
11 As denominações dos títulos estão de acordo com o que eles representam?
12 As denominações das opções de menu são familiares ao usuário?
13 A informação principal de uma mensagem de erro encontra-se no início da mensagem?
14 O sistema adota códigos significativos ou familiares ao usuário?
15 Ilustrações e explicações são usadas para completar as explicações do texto?
De acordo com as respostas obtidas, observa-se que em aspectos como por exem-
plo, a disponibilidade de informações (questão 1), feedback(2) e denominações de menu
(12), Tabela 3,os alunos consideraram que estes são bastante positivos, pois implica em
305
facilidade de uso e interação do sistema com o usuário . Já a questão 8, foi classificada

com cerca de 40% de respostas "Não"e questão 12 cerca de 50% para a resposta "Não se
aplica"pois, de acordo com os alunos, isso se dá por conta das mensagens de erro apenas
comunicarem a existência de erro e não detalhar qual o erro do usuário. Os estudantes
pontuaram que é necessário esta informação.
Desta forma, é possível notar que a usabilidade do sistema foi considerada regu-
larmente coerente, de acordo com a opinião dos estudantes, visto que, em grande maioria
as respostas "Sim"obtiveram índices superiores a 50% em relação as demais opções de
respostas,Figura 5.
Figura 5. Experimento de Usabilidade.
6. Conclusão
Sabemos que é um grande desafio tanto para pais, professores e profissionais, fornece-
rem atenção de qualidade a crianças que possuem distúrbios ou algum tipo de limitação.
Porém, atualmente, graças a tecnologia, podemos encontrar diversas que ferramentas que
podem auxiliar neste tipo de situação. A Plataforma Educacional para Disléxicos surgiu
com o intuito de ajudar neste tipo de caso e contribuir para que dislexos possam aprender
e progredir de séries na escola, adquirindo aprendizado de maneira lúdica.
Para isso realizamos experimentos para avaliar a utilidade de nosso sistema e ob-
tivemos respostas que nos alegraram, como a aprovação de profissionais que lidam diari-
amente com crianças que possuem estas limitações. Para eles o nosso sistema foi classifi-
cado com um bom potencial para desenvolver as habilidades para o qual foi desenvolvido.
Para comprovar isso, será necessário a realização de exprimentos com dislexos, que futu-
ramente o faremos.
Referências
ABD, A. B. d. D. (2016). O que é dislexia?
Barbosa, P. d. S. (2015). Dificuldades de aprendizagem. In Luís:UemaNet, S., editor,
Department of Computer Science, page 18.
Grigorenko, E. L. and Stenrnberg, R. J. (2003). Crianças rotuladas - o que é necessário
saber sobre as dificuldades de aprendizagem.
306
Guckert, L. S. and Faveri, J. E. d. (2008). A dislexia nas series iniciais: estrategias e

atividades de superacao. Revista Caminhos, 1(9):81–90.
IPODINE, I. P. d. D. e. O. N. E. (2014). Tipos de dislexia.
MEC, M. d. E. (2017). Direito de aprender.
Pinheiro, S. M. d. S. L. R. (2009). Dificuldades específicas de aprendizagem: a dislexia.
page 129. Curso de Educação Especial, Departamento de Ciência da Educação e do
Patrimônio, Universidade Portucalense Infante D. Henrique, Porto,.
Prado, E. and Alioto, O. E. (2012). Estratégias na alfabetização de crianças disléxicas.
pages 1–11.
Santos, R. C., Santos, C. A. d., Silva, M. M., Alves, W. F., and Beltrão, L. (2014). Jogos
educativos na dislexia. pages 1–10.
Souza, I. M. A. d. and Souza, L. V. A. d. (2010). O uso da tecnologia como facilitadora
da aprendizagem do aluno na escola. Revista Forúm Identidades, 8(4):128–142.
Stolk, A. B., Casagrande, C. E., and Bernhardt, M. d. F. (2013). Aprendendo com as
sílabas: software de apoio ao aprendizado de crianças com dislexia. Nuevas Ideas en
Informatica Educativa, pages 413–418.
307
Gerenciamento agrı́cola utilizando dispositivos móveis através

de bots Telegram
Nator Junior C. Costa1 , Marcos. S. Oliveira1 , José. V. M. Sousa1 , Aratã. A. Saraiva1
1
Universidade Estadual do Piauı́, Piripiri, Brasil.
{natorapps,marquinhoscamaleao,josevigno,aratasaraiva}@gmail.com
Abstract. There is a growing need to computerize Piauı́ agriculture to facilitate

agricultural decision making, temperature and humidity variations directly in-
fluence the quality of the product and the incidence of diseases, the sensing is
performed by an Arduino attached to an Orange Pi that makes The interface
with the Telegram API allowing the farmer to send commands requesting infor-
mation, graphics and images in a short time, the use Telegram API simplifies the
use.
Key words: Telegram bot. Precision agriculture. Low cost
Resumo. Existe uma necessidade crescente de informatizar a agricultura pi-

auiense para facilitar a tomada de decisões no âmbito agrı́cola, as variações de
temperatura e umidade influenciam diretamente na qualidade do produto e na
incidência de doenças, o sensoriamento é realizado por um Arduino acoplado
a um Orange Pi que faz o interfaceamento com a API Telegram possibilitando
que o agricultor envie comandos solicitando informações, gráficos e imagens
em um curto espaço de tempo, o uso a API Telegram simplifica o uso.
Palavras chave: Telegram bot. Agricultura de Precisão. Baixo custo
1. Introdução
O agricultor de modo geral está exposto a variações espaciais, temporais que afetam
diretamente sua produção e podem elevar os custos, o uso da agricultura de precisão
(AP) em conjunto com técnicas agrı́colas aumenta a produtividade e qualidade ambiental
[Pierce and Nowak 1999] .
Haja vista que as necessidades hı́dricas estejam na quantidade e na qualidade cor-
reta, a evapotranspiração máxima está relacionada diretamente a variações meteorológicas
[Dalmago et al. 2006], o entendimento dessas relações é importante para agregar quali-
dade ao produto final [Dalmago et al. 2006]. Além do mais as produções agrı́colas ge-
ralmente se localizam distantes das cidades, necessitando que o agricultor esteja presente
para ter acesso a informações de interesse, gerando a necessidade de uma ferramenta que
esteja sempre disponı́vel para consulta de dados de maneira remota.
Hoje em dia, a tecnologia móvel está cada vez mais popular e o seu
uso para acesso a informação mais comum. Junto a isso tem-se o paradigma
Internet das Coisas (IoT), a tecnologia de intercâmbio de informações, onde é
possı́vel comunicação pessoas-para-máquina[Santaella et al. 2013] ou máquina-para-
máquina[Namiot and Sneps-Sneppe 2014], deste modo possibilitando a aquisição de
informações, execução de comandos de maneira remota a hardware de diferentes re-
cursos e propósitos [Namiot and Sneps-Sneppe 2014], permitindo assim ser usada para
automação em situações diárias [Santaella et al. 2013].
308
No âmbito das pesquisas referentes a automação e aquisição de dados remota-

mente já é comum ter, além do já difundido Arduino [da Fonseca and Alexandre 2011],
o uso de computadores embarcados para tratamento de dados que exigem mais processa-
mento por parte do hardware, como por exemplo processamento de imagens.
Neste sentido o IOT [Gubbi et al. 2013] unido as plataformas Arduino e um com-
putador embarcado, mais especificamente o Orange PI PC, permite que o agricultor com
o auxı́lio do aplicativos de mensagens Telegram consigam trocar informações com as
plataformas remotamente através da internet.
No estudo proposto é demonstrado um protótipo do sistema AGROTBOT, que
possibilita a aquisição de informações do ambiente agrı́cola através do Telegram bot API,
permitindo que o usuário a partir de comandos no seu aplicativo Telegram obtenha ima-
gens processadas e gráficos referentes a temperatura e umidade locais.
A utilização de bots em sistemas embarcados já se mostra bastante usual, como exempli-
ficado em [de Oliveira et al. 2016]. Neste trabalho, o autor demonstra todo o processo da
implementação de bots com Telegram conectado a um Arduino, é relatado em seus testes
a possibilidade de aquisição de dados de sensores assim como o controle de ativação de
suas portas.
Já em [oshizaki and Lopes 2016] é mostrado a utilização de bot com Telegram
para controle de computadores por meio de acesso ao seu terminal. De acordo com os
seus testes o autor demonstra que a média de tempo de acesso nas principais funções são
executadas por meio de SSH, normalmente delongam mais tempo. Quando realizadas
pelo bot ganha-se tempo e praticidade, mostrando-se assim a sua otimização na usabili-
dade.
No trabalho de [Karrei et al. 2016] é apresentado uma técnica de detecção de mo-
lhamento foliar por meio de análise de imagens. O autor destaca o uso de dois métodos na
tentativa de detecção da água, no primeiro método foi utilizado o filtro Canny Edge De-
tector, com objetivo de identificar as gotı́culas de água a partir da detecção de suas bordas,
porém os resultados obtidos não foram satisfatórios. No segundo método, o autor decidiu
utilizar a técnica de filtragem de cores, para segmentar as partes do local fotografado,
molhado ou não molhado dividindo-as entre preto ou branco.
[Giandoni and Gambarato 2011] utilizou técnicas de processamento de imagens
para a detecção de oı́dio em folhas de seringueira. Utilizou-se a segmentação através da
manipulação da intensidade dos pixels e aplicou-se várias faixas de frequências diferentes
de modo a modificar a intensidade de cores encontrados em cada pixel. Deste modo,
descobriu-se o valor exato de cada pixel que determina a folha com e sem fungo.
[Pecoraro et al. 2010] por sua vez fez o uso de visão computacional e redes neu-
rais para detecção e classificação de fungos em laranjas após a colheita. Utilizou-se uma
câmera digital para a aquisição de imagens de frutos contaminados, para serem usadas
como treinamento da rede. Posteriormente foi utilizado a técnica de binarização para
fornecer uma primeira imagem de segmentação ao usuário. Posteriormente utilizou-se
a rede neural mais especificamente a perceptron para identificar o fungo em qualquer
imagem desconhecida.
309
3. Agricultura de Precisão
[BERNARDI and Inamasu 2008] demostra que AP pode ser decisiva ao traçar estratégias
para o agronegócio brasileiro. [SOUZA FILHO et al. 2004] mostra que existe uma
distinção entre os produtores que se enquadram na agricultura familiar, que variam desde
produtores cuja produção é de subsistência até produtores com dotação de grandes recur-
sos como terra, capacitação e conhecimento, demostra ainda que produtores mais jovens
tendem a adotar a AP em suas produções.
O conhecimento agrı́cola e de mercado são cruciais para o bom desenvolvimento
e a sustentabilidade da agricultura familiar [SOUZA FILHO et al. 2004], tornando assim
a adoção de tecnologias de manejo agrı́colas junto ao AP fundamentais para o bom de-
senvolvimento do agronegócio no ambiente familiar [SOUZA FILHO et al. 2004]
Na tabela 1 é demostrado os módulos utilizados na produção do protótipo, nos módulos
de controle foram utilizados a placa de prototipagem Arduino Uno e o Orange Pi PC. O
Arduino recebe e trata dados do módulo de sensoriamento que são umidade e temperatura
e enviar para o Orange Pi PC, onde está o módulo de atuação que é responsável por
direcionar os dados quando solicitados ou armazenar para consultas futuras.
No módulo de interface (figura 3) é utilizado o aplicativo Telegram que faz o
interação do produtor com o sistema AGROTBOT, que ao utilizar comandos especı́ficos
irá conseguir dados de sua propriedade.
Tabela 1. Lista de materiais

Nome Componente Descrição
Módulos de con- Placa de prototipagem Ar- Módulos responsáveis por interfa-
trole duino uno e Orange Pi PC cear o App Telegram e os sensores.
Módulo de senso- Sensores de temperatura e Capta as variações de umidade e
riamento umidade do ambiente temperatura do ambiente
Módulo de inter- App Telegram Responsável pele comunicação do
face usuário com o bot
Módulo de bot Telegram Responsável pelo direcionamento
atuação dos dados geradas pelos sensores
Na tabela 2, é possı́vel verificar o custo total e parcial do AGROTBOT,

sendo listado o preço e suas respectivas quantidades. Como demostrado por
[SOUZA FILHO et al. 2004], a agricultura familiar é heterogênea apresenta-se produto-
res com diferentes recursos, sendo o custo do protótipo considerado baixo de acordo com
os recursos e capacidades de cada produtor.
As ações demostradas pelo fluxograma (figura 1) demostram o funcionamento
do do módulo de atuação, é possı́vel verificar que se trata de um loop cujo o objetivo
é aguardar requisições trata-las e caso o comando seja reconhecido retornar o que foi
requisitado.
310
O módulo de atuação do AGROTBOT é composto por alguns comandos, como

é demostrado na imagem 3 que também exemplifica o resultado do envio do comando
”/graph”.
Tabela 2. Custo total e parcial do protótipo

Nome Quantidade Preço
Orange Pi PC 01 R$ 130,00
Arduino Uno r3 01 R$ 50,00
Sensor DHT 11 01 R$ 10,00
Webcam 01 R$ 33,50
Total 04 R$ 223,50
Figura 1. fluxograma do software de controle
5. Resultados
O protótipo do sistema AGROTBOT foi montado em laboratório para facilitar as etapas
de testes, como pode ser visto na figura 2 onde o mesmo se encontra operante, ainda
311
na figura 2 é possı́vel verificar os componentes que compõe os módulos de controle e

sensoriamento.
As avaliações foram realizadas em laboratório com intuito de verificar a eficiência
na captação dos dados pelo sensor e no tratamento dessas informações pelo módulo de
atuação.
O AGROTBOT adquiriu dados durante aproximadamente duas semanas, do dia
16/07/2017 ao dia 30/07/2017, onde foi realizado requisições periódicas de gráficos de
temperatura e umidade (figura 3). Os testes de captura de imagem e correção de ruı́dos
foram realizados na UESPI do campus de Piripiri (figura 4).
(a) (b)
Figura 2. Protótipo
(a) (b)
Figura 3. Imagens App Telegram enviando comandos
312
(a) (b)
Figura 4. Imagens App Telegram filtro mediana
6. Conclusão
O sistema de gerenciamento agrı́cola através de bots Telegram (AGROTBOT) efetivou
êxito na sua proposta, obtendo e tratando dados de umidade e temperatura, armazenando
para consultas futuras, capturando fotos, aplicando filtros, gerando gráficos e enviando
para o usuário quando solicitado.
Há um leque de possibilidades de acesso remoto a funções do bot desde as citadas
até controle de máquinas agrı́colas, sistemas de irrigação, controle e prevenção de pragas
e doenças.
A inovação está cercada de incertezas que influenciam a adoção de novas tecno-
logias. O risco torna-se uma variável potencial para a inclusão da AP em uma produção
agrı́cola, nesse sentido o uso do AGROTBOT para monitoramento reduz o risco e aumenta
as informações para tomada de decisões.
Referências
BERNARDI, A. d. C. and Inamasu, R. Y. (2008). Adoção da agricultura de precisão no
brasil. Embrapa Instrumentação-Capı́tulo em livro técnico-cientı́fico (ALICE).
da Fonseca, E. G. and Alexandre, S. (2011). Tutorial sobre introdução a projetos utili-
zando o kit de desenvolvimento arduino.
Dalmago, G. A., Heldwein, A. B., Nied, A. H., Grimm, E. L., and Pivetta, C. R. (2006).
Evapotranspiração máxima da cultura de pimentão em estufa plástica em função da
313
radiação solar, da temperatura, da umidade relativa e do déficit de saturação do ar.

Ciência rural, Santa Maria. Vol. 36, n. 3 (maio/jun. 2006), p. 785-792.
de Oliveira, J. C., Santos, D. H., and Neto, M. P. (2016). Chatting with arduino plat-
form through telegram bot. In Consumer Electronics (ISCE), 2016 IEEE International
Symposium on, pages 131–132. IEEE.
Giandoni, A. L. T. and Gambarato, R. L. (2011). Desenvolvimento de uma ferramenta
computacional para a detecção do oı́dio nas folhas de seringueira. Tekhne e Logos,
2(2):73–89.
Gubbi, J., Buyya, R., Marusic, S., and Palaniswami, M. (2013). Internet of things (iot):
A vision, architectural elements, and future directions. Future generation computer
systems, 29(7):1645–1660.
Karrei, M. A., Dallagasperina, R. W., Benvegnú, T., Rieder, R., Hölbig, C. A., Fernandes,
J. M. C., and Pavan, W. (2016). Detecç ao do molhamento foliar por meio de analise
de imagens.
Namiot, D. and Sneps-Sneppe, M. (2014). On iot programming. International Journal of
Open Information Technologies, 2(10):25–28.
oshizaki, A. and Lopes, W. (2016). Gerenciamento de ambiente server através de
aplicação em plataforma móvel bot mananger.
Pecoraro, W., JORGE, L. d. C., Barbato, D., and DE GROOTE, J.-J. (2010). Detecção
e classificação de fungos em laranjas pós-colheita por meio de processamento digital
de imagens. In Embrapa Instrumentação-Artigo em anais de congresso (ALICE). In:
WORKSHOP DE VISÃO COMPUTACIONAL, 6., 2010, Presidente Prudente, São
Paulo. Anais... Presidente Prudente: FCT/UNESP, 2010.
Pierce, F. J. and Nowak, P. (1999). Aspects of precision agriculture. Advances in agro-
nomy, 67:1–85.
Santaella, L., Gala, A., Policarpo, C., and Gazoni, R. (2013). Desvelando a internet das
coisas. Revista GEMInIS, 1(2 Ano 4):19–32.
SOUZA FILHO, H. M., Buainain, A. M., Guanziroli, C., and Batalha, M. O. (2004).
Agricultura familiar e tecnologia no brasil: caracterı́sticas, desafios e obstáculos. In
CONGRESSO da Sober, volume 42, pages 1–20.
314
Time analysis of attacks to USB plug-and-play by human

interface device emulation and keystroke injection
C. David B. Borges, J. Rafael B. de Araujo,
Robson L. de Couto, A. Márcio A. Almeida
Computer Engineering – Universidade Federal do Ceará (UFC)

Campus Mucambinho – Sobral – CE – Brazil
Abstract. This paper presents a security analysis of the USB plug-and-play

configuration protocol with regards to human interface device emulation and
keystroke injection attacks. We explore how an adversary can compromise con-
fidentiality, integrity and availability of computer systems by exploiting a vul-
nerability of USB plug-and-play. We perform a set of experiments to measure
the required time for successful injection of exploits into different operating sys-
tems. Our results show that human interface device emulation and keystroke
injection can cause significant damage and that current USB specifications are
insufficient to protect against these threats.
1. Introduction
Plug-and-Play is a specification that facilitates the attachment of USB keyboards, mice
and other devices to a computer. When a plug-and-play human interface device (HID) is
connected to a machine, it is automatically configured to perform input/output operations
[Microsoft 2017]. This flexibility helped USB to become very popular. Nowadays, USB
ports can be found on every consumer laptop, desktop and a large number of other devices.
From the user perspective, plug-and-play makes device connection a straightforward task,
however, this can be seen by an adversary as an attack vector. One is able to design a
hardware apparatus capable of disguising itself as a different device, such as a keyboard,
and then issue commands to a target computer by entering keystrokes in a shell terminal
[Kang and Saiedian 2015]. This attack is known as keystroke injection.
In this paper, we analyze how an adversary is able to perform a fast keystroke
injection and compromise the security of a computer system, given a limited amount
of access time to a plug-and-play enabled machine. This is important, because such an
exploit is a powerful tool for an adversary to obtain unauthorized access to data or gain
control over a system. Also, in order to design protective mechanisms, it is essential to
understand what an adversary can do by exploiting a vulnerability [Anderson 2008].
We analyze the dangers of fully automatic USB device configuration and propose
ideas to alleviate the threats. In our scenario, the adversary has a cheap microcontroller,
such as an ATMEGA32U4, that is programmed to emulate a keyboard and input a set
of predefined keystrokes when connected to a computer. These keystrokes are specially
crafted to open a shell terminal and enter an exploit command. We measure the effec-
tiveness of exploits that compromise confidentiality, integrity and availability (CIA) of a
computer system and how much access time is required for them to be performed. The
315
experiments encompass two kinds of operating systems, GNU/Linux and Windows, and
five different exploits. The main contribution of our work is a time analysis of attacks to
USB plug-and-play by HID emulation and keystroke injection.
2. Related Work
The dangers associated with USB plug-and-play are recurrent topics in computer security.
[Tetmeyer and Saiedian 2010] published a study about transient storage devices (TSD),
data storage peripherals that can be connected via USB port. The authors discuss the
risks of using TSDs, including theft of sensitive data, malware installation and data loss.
They also present mitigation techniques and strategies that apply to scenarios when an
adversary takes advantage of capabilities granted to peripherals.
Attacks that specifically exploit vulnerabilities in plug-and-play HIDs were pro-
posed by [Clark et al. 2011b]. The authors investigate the possibility of using hard-
ware trojans to exfiltrate data through unintended USB channels, the Keyboard LED
channel and the Audio channel. A proof-of-concept hardware trojan was presented by
[Clark et al. 2011a]. In [SRLabs 2014], the USB plug-and-play flaw was exploited with
the use of a microcontroller and a storage device coupled together. The authors demon-
strated attacks in which an adversary could gain administrative access to Windows and
Linux machines. These attacks were able to install a keylogger in the target computer,
gain root access and infect other USB devices. These vulnerabilities also acquired popu-
larity in the hacking community. A tool that exploits USB plug-and-play by HID emula-
tion, known as Rubber Ducky, is available online. The device, which includes a 60 MHz
32-bit CPU and Micro SD storage, is disguised as a regular flash drive and programmed
to perform keystroke injection attacks when connected to a computer.
A measure to mitigate the threat of a USB plug-and-play exploit by unwanted HID
emulation is to require user prompt before allowing the USB HID to interact with other
applications. G-Data, a computer security company, distributes a software that captures
all keystroke events of a newly connected HID and redirects them to a user prompt pop up.
The new keyboard is not allowed to send keystrokes to any other application before being
granted access by the computer’s owner [GData 2014]. A sophisticated approach to mit-
igate USB plug-and-play insecurities was shown by [Kang and Saiedian 2015]. The au-
thors propose and implement a hardware interface between the computer system and USB
peripherals. The interface enumerates newly connected devices and a software prompts
the user to verify whether the peripheral is trusted before allowing it to operate. This
measure adds a physical protection layer against granting resources to fake HIDs.
3. USB plug-and-play and Human Interface Devices

In this section, we investigate the configuration protocol for USB Human Interface De-
vices, which supports the plug-and-play feature on most operating systems used today,
such as Windows 10, GNU/Linux distributions and MAC OSX. The USB standard sup-
ports hot plugging, that is the ability to attach new devices to the I/O bus without the need
to shut down the system. This feature, along with plug-and-play, allows computer sys-
tems to automatically allocate resources for newly connected devices and configure them
for immediate operation.
USB is a polled bus, this means all the transactions are controlled by the host.
316
When a device is connected to a USB port, the host starts a process called enumeration.
This process is detailed in the Universal Serial Bus Specification [Compaq et al. 1998].
Enumeration consists of resetting the device, in order to bring it to a default state, and
then asking the device for its configuration descriptors. The descriptors are Read-Only
Memory (ROM) segments that represent information about the device. It contains device
manufacturer, id, class, subclass and USB version.
The host computer examines the received descriptors and loads the correct driver
for the device. There are different class codes for different applications. In this paper,
we focused on the HID class, which is used by keyboards, mice and joysticks. Because
the HID class is defined in the USB HID specification [Intel et al. 1998], nearly every
modern operating system has the drivers for HID devices. Therefore, most HID devices
don’t required any action or driver installation and can be fully operational seconds after
being connected to a computer. The USB initialization protocol is shown in figure 1.
Figure 1. USB plug-and-play setup protocol (Adapted from [SRLabs 2014])
There are plenty of inexpensive microcontrollers with USB support. With such
a microcontroller, one is able to craft a USB device with custom descriptors. This al-
lows the device to fake its class and function as another. For example, by presenting the
descriptor of an HID, a microcontroller can emulate a USB keyboard and is allowed to
inject arbitrary keystrokes in the system. Such an equipment has the capability to perform
keystroke injection attacks. In this study, we used an ATMEGA32U4 to emulate a USB
keyboard. This microcontroller is USB 2.0 compliant, has one 8-bit processor core, can
run up to 16 MIPS and has 32 kB of program flash memory, but an SD card may be used
to expand storage [Atmel 2015].
4. Principles of Designing Secure Systems

The fact that an operating system complies with current USB plug-and-play specification
implies that it is vulnerable to HID emulation and keystroke injection attacks. A plug-and-
play exploit is possible because current USB standards ignore some security principles.
In computer security, it is important to frequently reexamine all assumptions about
threat agents and the environment [Beznosov 2015]. The principle of complete mediation
317
states that every access and every object should be checked every time. A secure system
should assume that the environment where it operates is hostile and be reluctant to trust
[McGraw 2013]. In the case of plug-and-play, the object is a new USB device that re-
quests access to the USB bus as an HID. The only verification step during configuration is
related to device class. Because the class information is provided by the device itself, it is
not reliable. After the drivers are loaded and the device is configured, there is no verifica-
tion concerning its behavior. This disobeys the principles of questioning all assumptions,
complete mediation and reluctance to trust, thereby creating a security flaw.
5. A USB plug-and-play Attack Scenario

A security attack scenario is a description of the components of a system, possible at-
tackers, their goals and how the components are capable of preventing or allowing the
fulfillment of the attacker’s goals [Mouratidis et al. 2004]. Our attack scenario is based
on a adversary model with the goal of breaking confidentiality, integrity and availability of
the target [Stallings 2011]. The attacker has access to a microcontroller capable of emu-
lating a keyboard and can program the device to generate any sequence of keystrokes. The
adversary model summarizes the goals, required set of hardware and software skills and
a set of conditions necessary for initiating a plug-and-play attack in a computer system.
Adversary Model
• Goals:
– Obtain unauthorized access to information in the target computer;
– Modify or destroy information;
– Block access to the target computer;
• Hardware and software skills:
– Resources to purchase a compatible microcontroller, such as an AT-
MEGA32U4 Mini Development Board ($6.00 on Ebay);
– Ability to program the microcontroller to transmit a chosen sequence of
keystrokes when connected to a USB port;
• Conditions for initiating a plug-and-play attack:
– A target computer with a logged-in user;
– A distraction of approximately 5 seconds or less;
– Insertion of the rogue microcontroller into a USB port;
Attack Scenario
The target system is composed of a desktop or laptop. We assume that the target is on
and a user, Alice, is currently logged-in. The machine may be connected to the Internet.
A local attacker, Eve, as described in our adversary model, wants to break confidential-
ity, integrity and availability of Alice’s computer. Some methods to compromise these
properties are described below:
• Confidentiality: extraction of information from Alice’s computer, such as obtain-

ing copies of documents, images, videos or data of any kind;
• Integrity: unauthorized modification or deletion of personal or system files;
• Availability: block Alice from accessing resources or even log in to her account.
318
Eve has a cheap programmable microcontroller device, a USB ATMEGA32U4

Mini Development Board, capable of emulating a USB keyboard. She carefully designs
an exploit code, using Arduino language, compatible with the ATMEGA32U4. The code,
as soon as the device is plugged in to a USB port, uses keyboard shortcuts to open a
terminal and enter a set of exploit commands. After execution, Eve removes the device
and swiftly goes away.
Assuming that Eve doesn’t want her access to be noticed, she would have to wait
or create an opportunity to act. At this point, Eve could use a social engineering approach
to generate a distraction and quickly accomplish her attack. The key for the success of
this attack is the amount of time Eve has unauthorized access to Alice’s machine. If the
required time for the device to open a terminal and input the payload is small enough,
then a plug-and-play exploit can be considered feasible.
6. Experiments
Some tools, like the Rubber Ducky, were considered to perform the experiments. How-
ever, we decided to use the ATMEGA32U4 Mini Development Board. While it contains a
low end microcontroller, it is still capable of keyboard emulation, has much lower cost and
is compatible with Arduino. The test firmware was designed using Arduino language and
capable of injecting an average of 242 keystrokes per second. When the microcontroller
connected to a USB port, the firmware injected keyboard shortcuts to open a terminal and
entered the payload, a shell script to be run as a background process. Our purpose was to
measure how much access time would be required for an adversary to perform compro-
mising keystroke injection attacks. The payload size for each exploit is shown in table 1.
Each test attack was responsible for breaking at least one of the CIA properties:
• copy: copies and uploads a known directory and its contents to a remote server.
This could be used by an attacker to steal specific files with a known path;
• search/copy: searches for files that match a pattern and uploads them to a remote
server. In our tests, the matching pattern was a .pdf extension. This could be used
by an adversary to steal any file accessible to the user;
• delete: deletes a know directory and its contents. This is a manner to destroy
information on the target machine;
• encrypt: encrypts a know directory and its contents. An adversary could use this
exploit and force the user to pay a ransom to recover the encrypted files;
• forkbomb: run a fork bomb and provoke a system crash. This is a way for an
adversary to compromise the availability of the computer system.
In our tests, the interaction between the microcontroller and the target computer
has two phases. First, after the device is connected to a USB port, the device firmware
injects a set of keystrokes to open a terminal. It then must sleep for a predefined time in-
terval while the terminal program is loaded into main memory (RAM). The time between
the first keystroke injection and full loading of the terminal is dependent whether it is cur-
rently in RAM buffer/cache or it must loaded from the disk. Our experiments considered
both situations.
The second phase happens after the terminal is fully loaded. Now, the firmware
delivers the payload, a shell script, containing the exploit, that will be executed as a back-
ground process. After delivery, the firmware injects keystrokes to close the terminal and
319
the device can be disconnected. The total time of the attack is measured from the instant
the ATMEGA32U4 is connected to the USB port to the moment it is disconnected. We
performed ten measurements for each exploit, in which five of them loaded the terminal
from disk and the other five loaded it from RAM buffer/cache. The experiments were
done in GNU/Linux and Windows operating systems.
Table 1. Payload size, in bytes, for each exploit
Exploits GNU/Linux Windows 10
copy 77 313
search/copy 200 432
delete 14 112
encrypt 133 282
forkbomb 13 29
Figures 2 and 3 show the average times obtained for each test exploit in
GNU/Linux and Windows 10 systems, respectively. The GNU/Linux system of choice
was elementaryOS Loki, a Debian-based distribution. Both systems used an Intel Core i5
processor, 4GB 1600 MHz DDR3 RAM and a SATA HDD disk.
8
Loading from disk
Loading from RAM buffer/cache
7 6.71 6.60
6.33 6.44 6.33
6
5
Time (s)
4
3.12 3.18
3 2.57
2.42 2.31
2
1
0 copy search/copy delete encrypt forkbomb
Figure 2. Average required attack times measured in a GNU/Linux system
We observe from figure 2 that the attack time on GNU/Linux had little depen-
dence on which exploit was being executed. However, a significant time variation is seen
between the attacks that use RAM buffer/cache and those that need to load the terminal
from disk. This variation was expected and only highlights that attacking a system that
already loaded a terminal application during its operation is faster, even if the application
is no more in use. This happens because application data is kept in RAM buffer/cache
after the process terminates, as a measure to improve overall system performance.
Figure 3 shows that, on Windows 10, the difference between attack times that
load the terminal from disk and RAM buffer/cache is is slightly lower. We observe that
320
the average time to perform different attacks shows a larger variation than the attacks
made on GNU/Linux.
8
Loading from disk
Loading from RAM buffer/cache
7.10
7
6.30
6
5.29
5 4.57
Time (s)
4 3.69 3.67
3.49
3.20
3
2.29 2.31
2
1
0 copy search/copy delete encrypt forkbomb
Figure 3. Average required attack times measured in a Windows 10 system
The experiments showed that the mean required attack time when the terminal
must be loaded from disk is 6.48 seconds on GNU/Linux and 5.21 seconds on Windows
10. This value is computed as the mean average attack time, considering each exploit.
This implies that an adversary, taking advantage of the plug-and-play vulnerability, needs
access for approximately 6 seconds or less to inject payloads that compromise confiden-
tiality, integrity and availability of a computer system. The situation is worse if a terminal
application has already been loaded since initialization, as it’s very likely that application
data is kept in RAM buffer/cache. In this case, the mean attack time drops to 2.26 seconds
on GNU/Linux and 3.17 seconds on Windows 10.
7. Conclusion and Future Work

The current USB plug-and-play specification has security flaws that allow unwanted HID
emulation and keystroke injection attacks. One important risk factor in these attacks is
the amount of time required to inject the payload into the target computer. According
to our experiments, an adversary can exploit these flaws and violate each CIA property
in 6 seconds or less of access time to the target machine. In the case a terminal shell
has been loaded during system operation, and adversary could take advantage of RAM
buffer/cache and reduce required attack time to approximately 3 seconds.
USB plug-and-play presents a clear trade-off between usability and security. The
automatic configuration protocol provides desirable usability, but it has been proved inse-
cure regarding HID emulation and keystroke injection. While HID emulation is difficult
to treat, an alternative to counter keystroke injection is to use an interface agent to inter-
pose communication between USB keyboards and the computer. A software layer could
analyze typing speed patterns and block atypical behavior. Our next step in this research is
321
to work on the development of a reliable software layer that intercepts keystroke events,
recognizes keystroke injection attacks and blocks offending devices before redirecting
keystrokes to other processes.
References
Anderson, R. (2008). Security Engineering: A Guide to Building Dependable Distributed
Systems. Wiley.
Atmel (2015). Atmega32u4 datasheet. [Available] http://www.atmel.com/Images/Atmel-
7766-8-bit-AVR-ATmega16U4-32U4 Datasheet.pdf [Access 30-07-2017].
Beznosov, K. (2015). Computer security: Principles of designing secure systems. [Avail-
able] http://courses.ece.ubc.ca/cpen442/sessions/08-design principles.pdf [Access 30-
07-2017].
Clark, J., Leblanc, S., and Knight, S. (2011a). Compromise through usb-based hardware
trojan horse device. Future Gener. Comput. Syst., 27(5):555–563.
Clark, J., Leblanc, S., and Knight, S. (2011b). Risks associated with usb hardware trojan
devices used by insiders. In 2011 IEEE International Systems Conference, pages 201–
208.
Compaq, Intel, Microsoft, and NEC (1998). Universal serial bus specification. [Available]
http://esd.cs.ucr.edu/webres/usb11.pdf [Access 30-07-2017].
GData (2014). Usb keyboard guard: How to be sicher from usb attacks. [Available]
https://www.gdatasoftware.com/en-usb-keyboard-guard [Access 30-07-2017].
Intel, Microsoft, SunMicrosystems, Logitech, Alps, Cybernet, DEC, KeyTron-
icCorporation, LCS/Telegraphics, NCR, and ThrustMaster (1998). De-
vice class definition for human interface device (hid). [Available]
http://www.usb.org/developers/hidpage/HID1 11.pdf [Access 30-07-2017].
Kang, M. and Saiedian, H. (2015). Usbwall: A novel security mechanism to protect
against maliciously reprogrammed usb devices. Information Security Journal: A
Global Perspective.
McGraw, G. (2013). Thirteen principles to ensure enterprise system secu-
rity. [Available] http://searchsecurity.techtarget.com/opinion/Thirteen-principles-to-
ensure-enterprise-system-security [Access 30-07-2017].
Microsoft (2017). Hardware dev center – plug and play. https://msdn.microsoft.com/en-
us/library/windows/hardware/dn614609(v=vs.85).aspx [Access 30-07-2017].
Mouratidis, H., Giorgini, P., and Manson, G. (2004). Using security attack scenarios to
analyse security during information systems design. In Proceedings of the Interna-
tional Conference on Enterprise Information Systems, Porto-Portugal, pages 10–17.
SRLabs (2014). Badusb: On accessories that turn evil. [Availbale] https://srlabs.de/wp-
content/uploads/2014/11/SRLabs-BadUSB-Pacsec-v2.pdf [Access 30-07-2017].
Stallings, W. (2011). Cryptography and Network Security: Principles and Practice 5th
Edition. Prentice Hall.
Tetmeyer, A. and Saiedian, H. (2010). Security threats and mitigating risk for usb devices.
IEEE Technology and Society Magazine, 29(4):44–49.
322
MATOFOBIA: Como tratar este sentimento através de um

software
Tulio Vidal Rolim1, Débora Ferreira Angelim1, Marcos Alan Sousa Barbosa2,
Vânia Teixeira Lima3, Jorge Correia da Silva Neto4, Ronnie Edson Santos5
1
Faculdade Vale do Salgado (FVS), Icó-Ceará, Brasil.
2
Universidade Federal de Campina Grande (UFCG), Cajazeiras-Paraíba, Brasil,
3
Escola Estadual de Ensino Profissionalizante José Walfrido Monteiro (EEEPJWM),
Icó-Ceará, Brasil.
4
Universidade Federal Rural de Pernambuco (UFRPE), Recife–Pernambuco, Brasil,
5
Universidade Federal de Pernambuco (UFPE), Recife–Pernambuco, Brasil.
{tulio.xcrtf, deboraferreira001, jorgecorreianeto,
ronnie.gd }@gmail.com, {m.alanbarbosa, vania-jora}@hotmail.com
Abstract. Many students of Mathematics consider it incomprehensible and

inapplicable. Consequently, many of these students end up generating a mental
blockage, also known as "mathophobia" - fear of Mathematics. This work
presents the application of a software in the 1st year classes of the school
Deputy José Walfrido Monteiro able to identify the presence and cause of the
mathophobia, generating later an intervention proposal for the problem
diagnosed. After the application of the software and the methodological
adequacy of teacher, it was verified that 60% of the students changed their
perception about Mathematics, reducing the mathophobia and increasing
exponentially the level of achievement in the discipline.
Resumo. Muitos estudantes da disciplina de Matemática consideram-na como
incompreensível e inaplicável. Por conseguinte, muitos desses alunos, acabam
gerando um bloqueio mental, também conhecido por “matofobia”- medo de
Matemática. Esse trabalho apresenta a aplicação de um software nas turmas
do 1° ano da escola Deputado José Walfrido Monteiro capaz de identificar a
presença e a causa da matofobia, gerando posteriormente, uma proposta de
intervenção para cada problema diagnosticado. Após a aplicação do software
e a adequação metodológica do professor, constatou-se que 60% dos alunos
mudaram a sua percepção acerca da Matemática, amenizando a matofobia e
aumentando exponencialmente o nível de aproveitamento na disciplina.
323
1. Introdução
A Matemática é uma ciência imprescindível na formação de um cidadão. Muitas áreas do
conhecimento se desenvolveram e tornaram-se úteis ao ser humano graças a
conhecimentos matemáticos. Entretanto, muitos estudantes da disciplina consideram-na
como “incompreensível”, “monótona” e “inaplicável”. Julgamento este que pode
influenciar em índices de insucesso da área em vestibulares, concursos e similares, além
de reprovação durante o Ensino Fundamental e Médio. Desta forma, o educando
apresenta uma defasagem não restritamente em Matemática, mas também em outras áreas
do conhecimento, uma vez que esta ciência é interdisciplinar. Papert (1988) define esta
defasagem no educando através de diversos fatores que, tanto diretamente quanto
indiretamente, criam um bloqueio mental no aluno chamado por ele de “matofobia”-
medo ou aversão à Matemática.
A matofobia se caracteriza como um impedimento no aprendizado de qualquer
coisa relacionada a matemática, mesmo não apresentando dificuldade quando não a
reconhecem. Esse sentimento pode ser justificado por meio de algumas metodologias
ineficazes de ensino, que não se adéquam a necessidade singular do educando,
dissociando a aprendizagem do afetivo, do social e ignorando a própria causa do
sentimento (BLOOM, 1971). Em uma visão contemporânea, Oliveira (2016) alega que o
modelo atual de transmissão dos conhecimentos presente no ambiente escolar reduz a
criatividade, tornando assim mais difícil o ensino-aprendizagem da Matemática.
Como uma proposta metodológica, os recursos tecnológicos podem se apresentar
como uma alternativa aos docentes em sala de aula, principalmente no que diz respeito
aos computadores. Perante os avanços tecnológicos do mundo atual, os alunos possuem
acesso à informação de uma forma cada vez mais rápida, cabendo ao professor tornar-se
um indivíduo ativo capaz de utilizar a tecnologia como instrumento de mediação à
aprendizagem (FIGUEIREDO, NOBRE e PASSOS, 2015). Diante disso, Carvalho et. al.
(2008) observa que por meio da utilização do computador, o processo de aprendizagem
ocorre de maneira tranquila e natural, expressando a presença da tecnologia e seus
recursos no processo de ensino-aprendizagem. Entretanto, na literatura não há trabalhos
aplicados até o presente momento que utilizem um software como ferramenta de auxílio
ao problema da matofobia.
A dificuldade em Matemática não acarreta restritamente a ciência enquanto
disciplina, mas todo um conjunto de ciências e a própria vida cotidiana do educando. Este
fato, consequentemente, tem refletido em nossa realidade escolar no município de Icó-
Ceará. Este trabalho possui como objetivo identificar e amenizar este sentimento de
aversão à Matemática através da aplicação de um software denominado Matofobia em
alunos do primeiro ano do ensino médio, gerando posteriormente, uma proposta de ação
que se adeque a necessidade individual de cada estudante.
Este artigo está organizado da seguinte forma: a Seção 2 apresenta o software
Matofobia e suas funcionalidades; a Seção 3 apresenta a metodologia adotada; a Seção 4
apresenta os resultados e discussões; e a Seção 5 apresenta as conclusões.
324
2. Software Matofobia
O software constitui-se como uma ferramenta voltado ao diagnóstico e proposta de
intervenção à matofobia e suas causas, servindo como instrumento de apoio aos
professores para identificar e posteriormente reduzir os índices de aversão à matemática
durante as aulas. O software Matofobia é um software gratuito que foi desenvolvido
utilizando a linguagem de programação Java SE (Standard Edition), estando assim,
disponível para todos os sistemas operacionais que operam em computadores desktop e
notebooks. Como sistema de banco de dados foi adotado uma abordagem dinâmica em
sua definição, possibilitando a utilização por meio de um banco de dados local através do
SQLite ou em rede utilizando o Sistema de Gerenciamento de Banco de Dados (SGBD)
MySQL.
As funções contidas no software Matofobia, são respectivamente: Questionário
Matofóbico, Visualizar Questionários, Gerar Relatório Geral, Gerar Relatório Individual,
Visualizar Gráfico Geral e Visualizar Proposta de Intervenção.
A Figura 1 apresenta o questionário matofóbico composto por 9 questões objetivas e 1
aberta sendo questões de múltipla e simples escolha. Inicialmente, o estudante deve
informar seu nome e curso (em caso de escola profissionalizante), em seguida, é
necessário que todas as dez questões sejam respondidas sem exceção. Durante este
processo, há um personagem na tela chamado “Coruja Professor” que é encarregado de
dar orientações ao usuário quando clicado. A navegabilidade da tela é feita por meio dos
botões de avançar e voltar.
Figura 1. Questionário Matofóbico
Após a conclusão do questionário é possível visualizar o diagnóstico e sua
325
proposta de intervenção, assim como uma justificativa aos problemas identificados,

conforme pode ser observado na Figura 2.
Figura 2. Proposta de Intervenção
A Figura 3 apresenta a função de visualizar gráficos como forma de disponibilizar

ao professor uma visão geral dos índices coletados pelo software. Os itens apresentados
na figura são quantidades relativas ao número de indivíduos avaliados, os diagnosticados
com matofobia e suas causas mais comuns, sendo elas: trauma, base de conteúdos
insuficiente, incompreensão metodológica, insegurança, medo por desconhecimento e
fatores socioculturais.
Figura 3. Gráficos
326
3. Metodologia
A pesquisa adotada neste trabalho é de natureza aplicada, por ser uma pesquisa que
objetiva gerar conhecimentos para aplicação prática, dirigidos a solução de problemas
específicos (GERHARDT e SILVEIRA, 2009). Quantos aos objetivos, caracteriza-se
como descritiva no que tange a pesquisa de campo por meio de entrevistas, e exploratória
por meio da pesquisa bibliográfica, já que para sua execução fez-se necessário pesquisas
em diversas áreas do conhecimento, como a Pedagogia, Informática, Psicologia e a
Etnomatemática.
A partir do depoimento de alguns alunos, percebeu-se a necessidade de estudar a
realidade das turmas do 1° ano da Escola Estadual de Ensino Profissionalizante Deputado
José Walfrido Monteiro da cidade de Icó-CE, através de um software capaz de identificar
a presença e as causas da matofobia no aluno.
O software foi atestado por psicólogos, no qual comprovaram a sua eficácia em
identificar a matofobia. Através de mecanismos e combinações entre as questões é
possível gerar um relatório que discrimina a presença do sentimento no aluno e a sua
respectiva causa. Para efeitos de intervenção, o aplicativo gera uma proposta de ação para
a causa identificada, sugerindo uma maneira de amenizar o sentimento. Desta forma foi
possível ao professor obter o perfil individual de cada educando, adequando-os
posteriormente a metodologias específicas.
Através da aplicação do software com 178 educandos foram coletados os dados
que, estatisticamente, indicaram quantitativamente os alunos matofóbicos e suas
respectivas causas.
4. Resultados e Discussões
O software apresentou uma realidade até então desconhecida: 43% dos alunos
apresentaram a matofobia. A repulsa pela disciplina foi evidenciada através da resolução
do questionário contido no software, cujas causas foram diversas. Após a adequação
metodológica do professor e a reaplicação do software, houve uma melhora significativa
no rendimento dos alunos na disciplina de matemática, sendo constatado que 60% dos
discentes que anteriormente cultivavam antipatia à Matemática tiveram uma
transformação do seu sentimento com a disciplina.
Gráfico 1: Índice de alunos matofóbicos nos 1° anos.
327
Gráfico 2: Redução do índice de matofobia a partir da aplicação do software.
Isso aconteceu devido ao trabalho específico na raiz da causa da matofobia

identificado no software através da aplicação das intervenções nas aulas complementares.
Evidencia-se, portanto, a importância individual a cada aluno, visto que não existe aluno
igual a outro no que diz respeito ao aprendizado, cada um possui seu ritmo e forma de
abstração individual. É evidente que há a necessidade de se arquitetar o ensino de
matemática para suportar uma maior diversidade pedagógica, visando assim, ajudar os
alunos no aprendizado matemático. Polya (1985) ressalta que não há métodos que sejam
melhores que outros, bem como complementa dizendo que também não há uma melhor
interpretação da sonata de Beethoven.
Já Bloom (1971) destaca que a aprendizagem não é composta apenas por fatores
cognitivos, sendo importante considerar também aspectos como os afetivos e sociais. Daí
revela-se a importância de uma análise do perfil individual de cada educando. Ao
conhecer o aluno, o professor pode direcionar de uma forma mais precisa os conteúdos a
serem utilizados, tornando-os instrumentos pioneiros durante a aprendizagem (COELHO,
2000; GIORDAN, 1996). Sendo assim, a adoção de metodologias alternativas que se
adéquem a necessidade individual de cada aluno demonstra ser um fator contribuinte para
a amenização do sentimento matofóbico.
328
5. Conclusões
A Matemática, apesar de ser uma disciplina tão próxima do nosso dia a dia, não é
enxergada como tal pelas pessoas. Este sentimento de intangibilidade associado a outros
aspectos criam no indivíduo um fenômeno chamado de matofobia, o que acarreta baixos
índices de aproveitamento na disciplina. Entretanto, através de intervenções individuais,
disponíveis no software da pesquisa, este sentimento pode ser amenizado, uma vez que
os educandos apresentam realidades distintas e, portanto, necessitam de métodos
distintos. Por conseguinte, através da aplicação do software e adoção metodológica por
parte do docente foi possível tornar uma disciplina tida por muitos como inaplicável,
monótona e antagônica em uma prática interessante, lúdica e factível, amenizando a
matofobia e aumentando consideravelmente o nível de aproveitamento na disciplina.
Referências
BLOOM, B. S. et al. Taxonomia de los Objetivos de la Educación: La clasificación

de las metas educacionales. Buenos Aires: Talleres Gráficos Cadel, S.C.A, 1971.
CARVALHO, M. et al. Desenvolvimento de Software Para Alfabetização de Adultos
Baseado em Princípios Freirianos. In: Anais do XIX Simpósio Brasileiro de Informática
na Educação (SBIE 2008).
COELHO, S. M. et al. Conceitos, atitudes de investigação e metodologia experimental

como subsídio ao planejamento de objetivos e estratégias de ensino. Caderno
Catarinense de Ensino de Física. v.17, n.2, p.122-149. 2000.
FIGUEIREDO, G.; NOBRE, I; PASSOS, M. L. S. Tecnologias computacionais na

educação: desafios na prática docente. In: Anais do Workshop de Informática na
Escola, Brasil, 21, 127-136. 2015.
GERHARDT, T. E.; SILVEIRA, D. T. Métodos de pesquisa. Porto Alegre: Editora da

UFRGS, 2009.
GIORDAN, A.; VECCHI, G. trad. Bruno Charles Magne. As Origens do Saber: das
concepções dos aprendentes aos conceitos científicos. Porto Alegre: Artes Médicas,
1996.
OLIVEIRA, A. N.; BERCHT, M.; BASSO, M.; NASCIMENTO, A. O Uso das

Tecnologias Digitais no Apoio a Construção do Conhecimento Matemático. In: XXII
Workshop de Informática na Escola (WIE 2016).
PAPERT, S. Logo: Computadores e Educação. São Paulo: Brasiliense S.A, 1988.
POLYA, G. O ensino por meio de problemas. Revista do Professor de Matemática,
329
n.7, p. 11-16, 2. Sem. 1985.
330
Um protótipo para automação de criatórios de peixes em uma

fazenda escola utilizando plataforma de hardware livre
Bernan Rodrigues1 , Idalete Lopes1 ,
Geraldo Abrantes Sarmento Neto1 , Franklhes Santos Carvalho1 , Diego Porto1
1
Colégio Técnico de Floriano – Universidade Federal do Piauı́ (UFPI)
{bernanr7, idaletelopes018}@gmail.com,
{geraldosarmento, franklhes}@ufpi.edu.br, [email protected]
Abstract. The application of automation technologies is increasingly advancing

in agricultural sectors, allowing a greater control of production and facilitating
the decision making. By concentrating efforts on an area of fish farm of a vo-
cational school, we found an opportunity to develop a solution for automation
of the feeding module of fish tank, a task traditionally carried out in a manual-
fashion. With the aid of sensors and free hardware components, we assembled
and tested a low-cost prototype with the potential to be deployed in an operating
environment.
Resumo. A aplicação de tecnologias de automação vem avançando cada vez

mais em setores da agropecuária, permitindo um maior controle da produção
e facilitando as tomadas de decisões. Concentrando esforços para a área
da piscicultura da Fazenda do Colégio Técnico de Floriano, buscou-se uma
oportunidade para se desenvolver uma solução para automação do módulo de
alimentação de um criatório, tarefa tradicionalmente realizada de forma ma-
nual. Com o auxı́lio de sensores e componentes de hardware livre, foi possı́vel
montar e testar um protótipo de baixo custo com potencial para ser implantado
em ambiente operacional.
1. Introdução
A agropecuária é uma área onde crescentes aplicações de automação e mo-
nitoramento estão sendo desenvolvidas com as mais diversas funcionalidades bus-
cando a finalidade de facilitar o controle dos processos utilizados e otimizar a
produção [Bernardi et al. 2017]. As tendências atuais na aplicação de sistemas de
automação são em áreas como: máquinas e implementos agrı́colas, irrigação, criadouros,
processamento, armazenamento e transporte de produtos agrı́colas, construções rurais e
ambiência [Sousa et al. 2014].
No campo da piscicultura não é diferente; busca-se cada vez mais otimizar a
produção de peixes aliado a um menor custo para os seus produtores. Muitos são os
fatores que contribuem e são fundamentais para a manutenção de um criatório de peixes
como por exemplo manter a qualidade da água aferindo a sua temperatura, o seu potencial
Hidrogeniônico (pH), oxigênio dissolvido, assim como o controle da alimentação entre
outras, fatores esses que são passı́veis de automação contribuindo assim para uma maior
produtividade na criação de peixes.
331
O Colégio Técnico de Floriano (CTF), vinculado à Universidade Federal do Piauı́

tem como finalidade formar profissionais técnicos em diversas áreas, tais como, Enfer-
magem, Agropecuária, Agente Comunitário em Saúde e Informática. E como apoio ao
processo de ensino e aprendizagem dos alunos do curso Técnico em Agropecuária, io
CTF conta com uma fazenda escola onde atualmente são realizadas todas as atividades
de campo sendo algumas delas suinocultura, bovinocultura, caprinocultura, avicultura,
ovinocultura, piscicultura entre outras.
Diante desse cenário, este trabalho tem como objetivo apresentar uma proposta
de desenvolvimento de uma solução de baixo custo com uso do hardware livre que auto-
matize a alimentação e permita algum monitoramento nas condições de um criatório de
de peixes na fazenda do CTF, otimizando funções que hoje ainda são realizadas manual-
mente e que são fundamentais para a reprodução e/ou criação dos animais.
Para essa finalidade, foi utilizada a plataforma de hardware livre Arduino devido
à sua facilidade de manuseio e adaptabilidade de soluções. Com essa tecnologia de baixo
custo, é possı́vel realizar o acompanhamento de diversos sensores instalados nos tanques
de criação/reprodução dos peixes. O sistema de monitoramento e controle poderá ser
acessado através da Internet, na qual os seus usuários poderão verificar e ou acompanhar
as informações relativas aos dados coletados pelos sensores.
O restante do artigo está organizado sob a seguinte estrutura: na Seção 2 abrange
a conceitualização e implementação das plataformas de hardware livre. Na Seção 3 são
apresentados e discutidos os trabalhos relacionados. Na Seção 4 são abordados os aspec-
tos de materiais e métodos desta pesquisa. Na Seção 5 discute-se a montagem e teste do
protótipo desenvolvido. Finalmente, na Seção 6 são feitas as considerações finais.
2. Automação com Hardware Livre

2.1. A Plataforma Arduino
O Arduino consiste de uma plataforma de computação fı́sica e embarcada com
base em uma placa microcontroladora e um ambiente de desenvolvimento que permite
o desenvolvimento de projetos simples por meio da interação entre hardware e software
[McRoberts 2011]. Assim, facilmente podem ser desenvolvidos projetos que podem va-
riar desde o simples piscar de um LED até o controle e automação de uma série de dispo-
sitivos em uma residência, por exemplo. A propriedade de hardware livre permite utilizar
essa plataforma em diversas soluções com uma licença livre de taxas, o que reduz os
custos do projeto.
Um dos modelos mais utilizados e mais básicos é o Arduino UNO, exibido na
Figura 1. Utilizado principalmente no acoplamento de sensores, ele possui um microcon-
trolador ATMEGA328 que opera com 5 volts e possui uma configuração de 14 entradas
e saı́das digitais, 6 entradas analógicas, 32KB de memória flash, 2KB de SRAM, 1KB de
EEPROM e um clock de 16MHz [Arduino 2017].
O projeto Arduino ainda disponibiliza um ambiente de desenvolvimento para a
criação, edição e depuração dos programas que irão executar na placa, os denominados
sketches. A linguagem utilizada pelo Arduino é basicamente C++ provida de adaptadores
para facilitar a operação das funcionalidades do hardware [Galante and Garcia 2014]; a
332
Figura 1. Vista superior do Arduino UNO
exemplo da função setup(), para a inicialização das variáveis e loop() para repetir
indefinidamente as instruções principais do sketch.
Vem crescendo a utilização de plataformas de hardware livre como o Arduino
para a automação de tarefas na área da agropecuária. É possı́vel construir sistemas de
monitoramento com o uso de sensores de baixo custo permitindo obter os dados do am-
biente e enviá-los, por exemplo, via serviço de mensagens telefônicas SMS (Short Mes-
sage Service) [Siveira Júnior et al. 2015]. Esse tipo de comunicação facilita a obtenção
de informações por parte do produtor, necessárias para tomada de decisões que visam o
aumento de sua produção.
A integração de plataformas de hardware livre com outras tecnologias também
é uma solução que pode abrir caminho para muitas pesquisas. O trabalho de
[Baldi and Feuser 2015] aborda a aferição do nı́vel de umidade do solo, transmitindo
dados para dispositivos de Internet das Coisas e deles para computadores e celulares
conectados. O sistema utiliza componentes de baixo custo e têm a sua montagem e
programação facilmente modificáveis. Essa solução visa contribuir no desenvolvimento
agrı́cola através da economia de água.
Em áreas mais especı́ficas, a exemplo da piscicultura, o monitoramento da
água deve ser constante, pois alterações em indicadores como: temperatura, pH, tur-
bidez e presença de sólidos, podem trazer prejuı́zos à cultura. Quando essa tarefa
é feita de forma manual, pode estar sujeita a esquecimento ou impossibilidade por
parte do responsável, o que pode ocasionar em perdas significativas para a produção
[Sampaio et al. 2013] [Siveira Júnior et al. 2015].
O critério presença de sólidos é levado em conta no trabalho de
[Sabari Akilesh et al. 2017]. A pesquisa apresenta um alimentador automático para
um criatório de peixes que estima o nı́vel de sujeira nos tanques e utiliza um módulo
GMS (Global System for Mobile) para alertar aos produtores essa condição. O sistema
permite que sejam inseridos, por meio de um teclado acoplado, o número aproximado
333
de peixes, quantidade de ração e intervalo de tempo pretendido entre cada ciclo de

alimentação.
Preocupando-se com o monitoramento do ambiente, [Uddin et al. 2016] desen-
volveu um um disposito de alimentação automática para piscicultura utilizando um servo
motor e um módulo GSM apoiado pelo serviço de mensagens SMS que alerta ao usuário
sobre a reposição de ração no recipiente de armazenamento. Apesar de também monitorar
a temperatura da água, nosso protótipo não utiliza um sistema de alerta por mensagens,
fazendo com que a presença humana próxima aos tanques seja necessária com frequência.
De modo mais particular, a pesquisa de [Rosyid et al. 2014] que segue a mesma
linha do trabalho proposto neste artigo, inclusive no que diz respeito aos modelos dos
componentes: utilizando um módulo RTC DS1307 com display LCD 16x2 interligados
a um Arduino UNO. Um dos diferenciais dessa pesquisa indonesiana é que seu protótipo
de alimentação automática conta com dois recipientes de armazenamento de ração inte-
grados. Um sinal emitido por um fotodiodo indica que o recipiente menor (responsável
diretamente pela alimentação dos peixes) está cheio, retornando o recipiente maior (que
abastece o recipiente menor) à sua posição incial. Assim, o sistema de alimentação pos-
sui uma autonomia maior que o proposte neste artigo, pois os produtores não precisam
monitorar e reabastecer o reciente menor com frequência, salvaguardados pelo recipiente
maior.
Este trabalho consiste basicamente em um estudo de caso envolvendo uma solução
de protótipo para o setor de piscicultura da fazenda do Colégio Técnico de Floriano, uma
instituição vinculada à Universidade Federal do Piauı́.
A pesquisa exploratória realizada demandou inicialmente um levantamento bi-
bliográfico em busca das melhores práticas para a montagem do protótipo da solução.
A seguir, visando uma melhor compreensão dos requisitos do projeto, foram realizadas
entrevistas com professores e técnicos do departamento de Agropecuária, bem como vi-
sitas realizadas na fazenda do Colégio para observações in loco das instalações atuais dos
criatórios.
Inicialmente foi verificado o ambiente onde o sistema de automação seria utili-
zado. Outra questão analisada foram as práticas da piscicultura abordadas, quais são os
parâmetros considerados como condições ideais da água e como são executadas as ativida-
des nos tanques de peixes. Após essa análise foram identificados vários fatores referentes
à qualidade da água que poderiam pôr em risco a vida e a reprodução dos peixes como,
por exemplo: a temperatura da água que não era monitorada.
As temperaturas acima ou abaixo do ótimo influenciam de forma a reduzir
seu crescimento. Em caso de temperaturas extremas, podem acontecer mortalida-
des [Silva et al. 2009] gerando prejuı́zos aos criadores.
Atualmente, a alimentação dos peixes é uma atividade realizada de forma manual
na fazenda do CTF. Caso ela não seja feita nos horários corretos, pode trazer sérios riscos
a saúde dos animais, segundo [Camargo et al. 2012], os animais necessitam se alimentar
com qualidade, não somente a qualidade do alimento em si, como os horários e quantidade
de alimentação fornecida. Em pouca quantidade inviabiliza o desenvolvimento e saúde do
334
peixe, e em excesso gera acúmulo de gordura no animal, o que reduz seu tempo de vida, e
ainda o que não é comido pelo peixe, suja a água podendo gerar problemas maiores como
doenças.
Tudo isso foi levado em consideração para o projeto de nosso protótipo. Visando
desenvolver um sistema com componentes eletrônicos viáveis que pudessem realizar mo-
nitoramento da temperatura da água e automação de um alimentador, foram realizados
estudos e foram levantados todos os componentes eletrônicos listados na Tabela 1.
Tabela 1. Componentes eletrônicos aplicados ao projeto

Qtd. Componentes
01 Placa Arduino Uno REV3
01 Disp lay LCD 20x4
01 Módulo RTC DS1307
01 Resistor pull-up 4,7kΩ
01 Sensor de temperatura(DS18B20)
01 Motor DC(12v)
02 Potenciômetro 10kΩ
01 Módulo relé de 4 canais(5v)
25 Jumpers
01 Protoboard
01 fonte bivolt 12V/1A
A Figura 2 apresenta o desenho do circuito desenvolvido para a montagem do

protótipo.
Figura 2. Modelagem do protótipo da solução
A respeito da solução propriamente dita, foi oportuno e pertinente segregar o seu

projeto em duas fases: a fase de montagem da maquete e a fase de testes. Essa divisão
permite discutir melhor as caracterı́sticas e identificar em que etapa cada uma delas tem
ênfase. Essas fase são discutidas com mais profundidade na Seção 5.
5. Discussão da Solução
Como já justificado, a discussão das caracterı́sticas do protótipo proposto é reali-
zada neste trabalho através da distinção de duas fases importantes: montagem e teste da
335
solução. Na primeira, são abordados aspectos mais relativos à estrutura do protótipo e

encaixe dos componentes listados na Tabela 1. A seguir, a segunda fase discute apenas os
aspectos relativos aos testes realizados em laboratório com a solução, uma vez que ela se
encontra montada e pronta.
5.1. Fase de Montagem

Inicialmente, deu-se inı́cio a montagem do protótipo com a construção de uma
maquete para simular um pequeno criatório de peixes em tanque escavado. No modelo
do tanque foi instalado o motor DC e o sensor de temperatura da água, no motor foi
encaixado um cilindro responsável por armazenar a ração para liberação dentro de um
intervalo definido via software.
O Arduino e os outros componentes eletrônicos não podiam entrar em contato
com a água então foram montados fora da maquete. O Arduino controla e se comunica
com os componentes eletrônicos por meio de suas portas digitais e analógicas. O modulo
RTC (Real Time Clock) foi conectado nas portas analógicas; já nas portas digitais foram
conectados o sensor de temperatura DS18B20 à prova de d’água, o módulo relay e o
display LCD que exibe hora, data, temperatura da água, e quantas vezes o motor foi
acionado.
Na montagem do circuito do display foram inseridos dois potenciômetros para
realizar a função de ajustar o contraste e o brilho, deixando legı́vel as informações que
são exibidas. O motor DC conectado ao primeiro canal do módulo relé precisa de uma
energia externa para ser acionado, então para alimentar o mesmo foi utilizada uma fonte
bivolt 12V/1A.
Toda a etapa de codificação do protótipo foi realizada no ambiente de desenvol-
vimento do Arduino que é apresentado na Seção 2.1. O software realiza basicamente as
funções de converter as variáveis de temperatura da agua na escala Celsius e controlar
o ciclo temporal de alimentação do criatório e o acionamento do motor. A placa do Ar-
duino foi alimentada via USB e esse mesmo barramento foi utilizado para transferir o
código do computador para a memória do dispositivo. A Figura 3 exibe o protótipo em
funcionamento.
5.2. Fase de Testes

Após ser finalizada a fase de montagem, o protótipo entrou em observação por 5
dias levando em consideração três critérios, sendo eles:
1. Verificar se a data e hora estavam atrasando, mesmo com o Arduino desligado.
Isso é importante para verificar se a sincronização temporal está correta, não interferindo
no ciclo temporal necessário para acionar o cilindro de alimentação.
2. Verificar se a alimentação estava sendo realizada nos horários definidos. Tais
horários foram às 8h e às 15h. Tempo que está de acordo com a polı́tica adotada pela
própria Fazenda do Colégio.
3. Verificar o comportamento do sistema em águas com temperaturas diferentes.
Durante a fase de teste, o protótipo apresentou um bom funcionamento onde os
três critérios impostos foram atendidos perfeitamente.
336
Figura 3. Modelagem do protótipo da solução
6. Considerações Finais e Trabalhos Futuros

O uso do Arduino como solução para a automação do campo da agropecuária vem
ganhando cada vez mais espaço. Como essa tecnologia, na piscicultura, por exemplo,
é possı́vel criar protótipos com sensores para monitorar diversos atributos do ambiente
criatório, como: temperatura da água, pH e turbidez. Nesse contexto, este trabalho bus-
cou descrever um protótipo desenvolvido para a automação do módulo de alimentação
de um criatório de peixes na fazenda do Colégio Técnico de Floriano, tarefa realizada
manualmente por funcionários da instituição.
Iniciativas como essa buscam apoiar um melhor controle das condições do am-
biente, permitindo melhores resultados na produção. Apesar do protótipo desenvolvido
estar repassando apenas informações sobre temperatura da água, futuramente novos sen-
sores poderão ser acoplados para ampliar as funcionalidades do projeto, permitindo um
controle ainda maior. Pretende-se ainda implantar a solução de forma completamente
operacional na Fazenda do Colégio Técnico de Floriano. Isso incluiria, entre outros ajus-
tes, substituir a alimentação via USB por uma com baterias para placa e motor.
Referências
Arduino (2017). Arduino uno. <http://www.arduino.org/products/boards/arduino-uno>.
Acesso em: 28/06/2017.
Baldi, M. A. and Feuser, L. B. (2015). Protótipo open source de sensoriamento remoto
em ambiente agrı́cola. In Congresso Brasileiro de Agroinformática, pages 1–11, Ponta
Grossa. Universidade Estadual de Ponta Grossa.
Bernardi, A. d. C., Luchiari Junior, A., Perez, N., and Inamasu, R. (2017). Potencial
de uso das tecnologias de agricultura e pecuária de precisão e automação. Embrapa
Pecuária Sudeste-Documentos (INFOTECA-E).
337
Camargo, C. B., Costa, L. F., and PARADISO3, S. R. (2012). Sistema de controle para
aquariofilia. Anais Eletrônico, pages 1–14.
Galante, A. C. and Garcia, R. F. (2014). Sistema de aquisição de dados de sensores de
baixo custo baseado no arduı́no. In Congresso Brasileiro de Agricultura de Precisão,
volume 6.
McRoberts, M. (2011). Arduino Básico. Novatec Editora, São Paulo, 1st edition.
Rosyid, A. et al. (2014). Prototype of Automatic Fish Feeder Using Timer Module RTC
DS1307 Based on Arduino Uno. PhD thesis, [Yogyakarta]: Universitas Gadjah Mada.
Sabari Akilesh, K., Savitha, V., Vinithra, N., and Dhansekar, J. (2017). Smart fish feeder.
Sampaio, F. G., Losekann, M. E., Luiz, A. J. B., Neves, M. C., Frascá-Scorvo, C. M. D.,
and Rodrigues, G. S. (2013). Monitoramento e gestão ambiental da piscicultura em
tanques-rede em reservatórios. Informe Agropecuário, 34(272):1–11.
Silva, V. K., Ferreira, M. W., and Logato, P. V. R. (2009). Qualidade dá água na psicul-
tura. Ufla, Lravas-mg, 1st edition.
Siveira Júnior, C. R. d., Alves, A. R., and Correia, L. H. (2015). O uso do celular no mo-
nitoramento do ambiente de piscicultura. In Congresso Brasileiro de Agroinformática,
pages 1–11, Ponta Grossa. Universidade Estadual de Ponta Grossa.
Sousa, R. V. d., Lopes, W. C., and Inamasu, R. Y. (2014). Automação de máquinas
e implementos agrı́colas: eletrônica embarcada, robótica e sistema de gestão de
informação. Embrapa Informática Agropecuária-Capı́tulo em livro cientı́fico (ALICE).
Uddin, M. N., Rashid, M., Mostafa, M., et al. (2016). Development of automatic fish
feeder. Global Journal of Research In Engineering.
338
Heurística para Geração de Configurações Radiais Não

Ilhadas em Sistemas de Distribuição
Ênio Rodrigues Viana1, Aldir Silva Sousa 2
1
Programa de Pós-graduação em Engenharia Elétrica – Universidade Federal do Piauí
Teresina – PI – Brazil
2
[email protected], [email protected]@uespi.br
Abstract. Power distribution systems are generally operated in a radial
configuration once that configuration allows for greater efficiency in the
network protection system. In addition, by legal prohibitions, the system should
not operate with islands. Therefore, we propose a methodology to generate
radial configurations, by key management, in a distribution system. In addition,
the proposed methodology is capable of detecting and removing islets from the
distribution system. Tests were carried out in several systems and, after analysis,
we can verify the efficiency and robustness of the proposed methodology even
for large systems.
Resumo. Os sistemas de distribuição de energia elétrica são geralmente

operados em uma configuração radial. Isto devido a tal configuração
possibilitar maior eficiência ao sistema de proteção das redes. Além disso, por
proibições legais, o sistema não deve operar com ilhas. Diante disso, propõe-
se neste trabalho uma metodologia para gerar configurações radiais, por
manejo de chaves, em sistema de distribuição. Além disso, a metodologia aqui
proposta é capaz de detectar e remover ilhamentos do sistema de distribuição.
Testes foram realizados em diversos sistemas e, após análise, pode-se constatar
a eficiência e robustez da metodologia aqui proposta mesmo para sistemas de
grande porte.
1. Introdução
A continuidade no fornecimento de energia elétrica é fundamental para os consumidores,
o que justifica as exigências feitas pelas agências reguladoras em todo o mundo. Índices
de qualidade e confiabilidade ruins podem denegrir a imagem das empresas distribuidoras
e impactar negativamente o faturamento delas. Assim, é do interesse das distribuidoras
de energia elétrica implantar metodologias que resultem na melhoria dos seus
indicadores. [SAL 2016].
As perdas técnicas de potência são inerentes ao processo de geração, transmissão
e distribuição de energia elétrica e devem ser minimizadas para se garantir maior
eficiência do sistema. Na distribuição, em que as perdas técnicas se dão pelo efeito Joule,
as concessionárias adotam diversas ações para minimizá-las, dentre as quais, a
reconfiguração das redes tem se tornado bastante atrativa. (PEREIRA, 2014).
339
Os sistemas de distribuição de energia elétrica são, na maioria dos casos,

configurados radialmente [CAVELLUCCI 1998], [LORENZETI 2004], [MAGALHÃES
2007], [BUENO 2005], [JÚNIOR 1985] e [PEREIRA 2000] com o objetivo de evitar
problemas com a coordenação da proteção e atenuação de correntes de curto curto-
circuito. No entanto, a estrutura radial pode resultar em problemas do ponto de vista
operacional pois não garante alternativas de fornecimento de energia em situações de
contingências ou sobrecargas, nas quais seriam necessárias manobras de isolamento do
defeito e corte de carga, com provável ilhamento de barras [GUIMARÃES 2009].
Diante do exposto, torna-se importante o desenvolvimento de metodologias
capazes de gerar configurações radiais em redes de distribuição e, além disso, detectar e
corrigir possíveis ilhamentos no sistema. Uma metodologia capaz de detectar e corrigir
ilhamentos, além de gerar configurações radiais em Sistemas de Distribuição tem
aplicação tanto do ponto de vista da operação do sistema de distribuição, como em auxílio
a metaheurísticas no intuito de tornar factíveis propostas de solução com ciclos ou
ilhamentos.
Este trabalho propõe uma heurística para recuperar a condição de radialidade sem
ilhas do sistema de distribuição ao tratar do problema de Reconfiguração de Sistemas de
Distribuição Radial (RSDR).
2. Heurística proposta
Propõe-se neste trabalho uma abordagem do tratamento de configurações de um Sistema
de Distribuição Radial (SDR) utilizando-se a teoria dos grafos.
2.1 Detecção de ciclo e ilhamentos

A existência de ciclos, também conhecido como loops, não é desejável dentro do contexto
de um SDR. Na teoria dos grafos, dado um grafo não-direcionado G = (9,10), ver Figura
1, a existência de ciclos e ilhamentos pode ser detectada através de uma BEP(Busca em
Profundidade).
Em uma BEP, as arestas são exploradas a partir do vértice 𝑣 mais recentemente
descoberto que ainda tem arestas inexploradas saindo dele. Quando todas as arestas de 𝑣
são exploradas, a busca regressa para explorar as arestas que deixam o vértice a partir do
qual 𝑣 foi descoberto. Se restarem quaisquer vértices não descobertos, então um deles
será selecionado como uma nova origem. Esse processo continua até descobrirmos todos
os vértices acessíveis a partir do vértice de origem inicial [CORMEN et al 2002].
Neste trabalho utilizou-se uma BEP para detecção da existência de ciclos e
ilhamentos. Dado um grafo G não-direcionado. para cada vértice visitado 𝑣, se existe um
340
adjacente 𝑢 de modo que 𝑢 já foi visitado e 𝑢 não é pai de 𝑣 então existe um ciclo no
grafo, do contrário, não há ciclo.
Figura 1 - Grafo não-direcionado com ciclos e ilhas.

Digamos que o grafo seja representado pelas estruturas da Figura 2.
Figura 2 – Representação computacional de um grafo.

Considere que o grafo consista de uma Lista de No, chamada de 𝑉 e uma lista de
arcos, chamada de 𝐸. Considera-se partindo do nó 0. O desempenho do algoritmo é
independente do nó inicial.
O algoritmo consiste em percorrer cada nó do grafo e seus respectivos vizinhos.
Se um nó não contém vizinhos, é o nó folha, então o caminho está completo sem ciclos.
Partindo de 0, adicionado este nó ao caminho atual 𝐶. Podemos ir para {1} ou {2}
(vizinhos de {0}. Decidimos ir para {1} e marcamos este nó como visitado. Poderia ser
para {2}, não faz diferença. Porém, o nó {2} é posto em uma pilha de espera P, os não
visitados, e {1} é adicionado ao caminho atual 𝐶. Assim, temos: 𝐶 = {0 − 1} e 𝑃 = {2}.
Todos os nós em 𝐶 devem ser marcados como visitados.
Agora, olhamos para os vizinhos de {1}, que são {3,4,0}. Como estamos vindo do
nó {0}, não podemos voltar neste momento para ele, pois este é pai e também já foi
visitado. Adicionamos o nó {3} ao caminho e {4} à pilha de espera: 𝐶 = {0 − 1 − 3}.
𝑃𝑖𝑙ℎ𝑎 = {2,4}. Cabe lembrar o princípio da estrutura de dados pilha: adicionar e remover
da mesma posição.
Chegamos ao nó {3}. Seus vizinhos são = {1,2,4,5}. Como estamos vindo do nó
{1}, não podemos voltar neste momento para ele, pois este é pai e também já foi visitado.
Em outras palavras, o nó {1} é o nó origem de {3}, ou seja, seu pai. Então, o próximo nó
que podemos adicionar ao nosso caminho é o nó {2}. Os demais vão para a pilha se ainda
não estiverem lá. Não há necessidade de repetir o nó na pilha. Se um nó já estiver na pilha,
basta atualizar o nó de origem. Temos: 𝐶 = {0 − 1 − 3 − 2}. 𝑃𝑖𝑙ℎ𝑎 = {2,4,5}.
Uma vez estando no nó {2}, prosseguimos com os passos. Filhos de {2} = {3,0}.
Não devemos voltar para {3}, pois este é nó de pai de {2}. Devido à atualização. Então,
devemos ir para o nó {0}. Assim, temos: 𝐶 = {0 − 1 − 3 − 2 − 0}. 𝑃𝑖𝑙ℎ𝑎 = {2,4,5}.
341
Note que o nó {0} se repetiu no caminho. Isto é suficiente e necessário para

afirmar que temos um ciclo envolvendo os nós {0,1,3,2,0}. Em outras palavras, percorrer
estes nós nesta sequência se terá um ciclo. Como não desejamos ciclos em nossa rede,
devemos destruí-los.
Para destruir um ciclo é muito simples. Seja 𝑘 qualquer um dos nós pertencentes
a 𝐶. Ou seja, 0 ou 1 ou 3 ou 2. Será fácil notar que para qualquer nó em 𝐶, este nó terá
como filho pelo menos dois outros nós também pertencentes a 𝐶. Para quebrar o ciclo,
basta remover de 𝑘 algum nó que vizinho de 𝑘 também pertença a 𝐶. Abaixo as opções.
Figura 3 – Remoção de ciclo para k = 0.

Para 𝑘 = 0.
𝑉(0) = {1,2}. Note que tanto {1} como {2} pertencem a 𝐶. Então devemos
remover de 𝑉(0) ou o nó {1} ou o nó {2}. Digamos que removemos {2}. Podemos usar a
seguinte heurística: Como o ciclo se fechou em {0}, removemos dos vizinhos de {0} o
seu nó de origem. No caso, o nó {2}, ver Figura 3.
Para 𝑘 = 1. 𝑉(1) = {0,3}. Então, seguindo a heurística acima, devemos
remover de {1} o seu nó de origem. No caso, o nó {0}. Em outras palavras, é removida a
aresta que liga {0} a {1}, ver Figura 4.
Figura 4 - Remoção de ciclo para k = 1.

Para 𝑘 = 2. 𝑉(2) = {0,3}. Então, seguindo a heurística acima, devemos
remover de {2} o seu nó de origem. No caso, o nó {3}. Em outras palavras, é removida a
aresta que liga {3} a {2}, ver Figura 5.
342
É fácil notar agora que se 𝑘 = 3, deveríamos remover o arco 1 − 3, ver Figura 6.

Uma vez detectado e removido o ciclo, faz 𝐶 = {} e 𝑃 = {}. E reiniciar o processo.
Marca-se, então, todos os nós como não visitados. Parte-se novamente de {0}.
Considere que o cenário escolhido foi o 𝑘 = 2, ver Figura 5. Agora, temos: 𝐶 =
{0} e 𝑃 = {}. Todos os nós marcados como não visitados.
Novamente, os vizinhos de {0} são 𝑉(0) = {1,2}. Digamos que o adicionamos
{2} ao caminho. Para encurtar a explanação do algoritmo. Assim, temos 𝐶 = {0 − 2}.
𝑃 = {1}.
O passo seguinte será procurar um vizinho de {2} para seguir o caminho. Porém,
{2} não tem mais vizinhos, é um nó folha. Assim, remove-se {2} de 𝐶 e adiciona-se o
próximo da pilha de espera. Ou seja: 𝐶 = {0 − 1}. P={}. O processo prossegue
iterativamente.
Quando o algoritmo convergir, teremos removido todos os ciclos, ver Figura 7.
Além disso, para todo nó não ilhado teremos 𝑣. 𝑣𝑖𝑠𝑖𝑡𝑎𝑑𝑜 = 𝑡𝑟𝑢𝑒. E somente para os nós
ilhados 𝑣. 𝑣𝑖𝑠𝑖𝑡𝑎𝑑𝑜 = 𝑓𝑎𝑙𝑠𝑒. Os nós 𝑣. 𝑣𝑖𝑠𝑖𝑡𝑎𝑑𝑜 = 𝑓𝑎𝑙𝑠𝑒 serão ilhas. Liga-se uma aresta
de qualquer nó para um nó com atributo visitado igual a falso.
Repete-se todo o processo. Até que não haja mais nenhum nó com atributo 𝑣𝑖𝑠𝑖𝑡𝑎𝑑𝑜 =
𝑓𝑎𝑙𝑠𝑜.
Figura 7 - Grafo após remoção de ciclos e ilhamentos
2.2 Complexidade do algoritmo

Busca em profundidade, usado para percorrer o grafo, tem ordem de complexidade:
𝑂(𝑚 + 𝑛) [CORMEN et al 2002].
Como a cada ciclo detectado o algoritmo precisa ser reiniciado, devemos
acrescentar à complexidade: 𝑂(𝑐𝑥(𝑚 + 𝑛)). Onde 𝑐 é o número de ciclos no grafo sem
ilhas; 𝑚 é o número de arcos e 𝑛 o número de nós.
A cada ilha detectada o algoritmo é reiniciado. Porém, é possível que na ilha haja
ciclos, ver Figura 7.
343
Figura 8 - Ilha com ciclos

Como o grafo pode conter 𝑝 ilhas, podemos ter a seguinte complexidade
𝑂 (∑𝑝𝑖=1 𝑐𝑖 𝑥(𝑚𝑖 + 𝑛𝑖 )).
3. Análise dos Resultados

A heurística proposta foi capaz de tratar a infactibilidade de SDRs em diversos cenários,
conforme a Tabela 1, com tempo de execução extremamente baixo e aceitável desde
sistemas pequenos, 14 barras e 19 linhas, até sistemas de grande porte, 300 barras e 409
linhas. Cenários com ilhamento e com ciclo, sem ilhamento e com ciclo, com ilhamento
e sem ciclo foram simulados e em todos os casos o tempo médio de execução ficou abaixo
de 0.15 segundos, sendo esta uma heurística robusta para tratamento de infactibilidade
de grafos representativos de SDRs.
Em todos os cenários, independente do número de ciclos ou ilhamentos, foi
possível o tratamento da infactibilidade em tempo de execução satisfatório.
Tabela 1 - Tempo de execução, número de ciclos e número de manobras. Média
de 10 execuções
Nº de
Nº de Barras Nº de Linhas Tempo execução Nº de Ciclos Nº de Ilhas
Manobras
14 19 0,0009 6 6 0
30 39 0,002 10 10 0
57 78 0,0054 22 22 0
118 179 0,0296 62 62 0
300 409 0,1218 110 110 0
9 10 0,0006 3 4 1
12 14 0,0008 4 5 1
4. Conclusão
Os sistemas de distribuição geralmente devem operar de forma radial. Além disso, por
limitações legais, os sistemas de distribuição não podem operar com ilhamentos. Diante
disso, torna-se importante o desenvolvimento de metodologias capazes de gerar
configurações radiais em redes de distribuição e, além disso, detectar e corrigir possíveis
ilhamentos no sistema.
344
Diante deste cenário, neste trabalho são propostos algoritmos em O(n) para
geração de configurações radiais, e para detecção e correção de ilhamentos no sistema de
distribuição. Testes foram realizados em diversos sistemas de distribuição, tanto com
ilhamentos como com ciclos. Em análises realizadas, pôde-se constar a eficiente e
robustez do algoritmo aqui proposto, mesmo diante de sistemas de grande porte: 300
barras e 409 linhas.
5. Referências
SAU, Rodrigo Ferreira Gonçalves. Alocação otimizada de indicadores de falta em redes
de distribuição de energia elétrica considerando a presença de geradores distribuídos.
Dissertação(Mestrado em Engenharia Elétrica) - FEEC/UNICAMP, Campinas - SP.
2016.
PEREIRA, Ezequiel Campos. Reconfiguração de redes de distribuição de energia elétrica
para minimização de perdas técnicas. Dissertação(Mestrado em Engenharia Elétrica)
- UNICAMP, Campinas - SP. 2014.
CAVELLUCCI, Celso. Buscas informadas baseadas em grafos para a minimização das
perdas em sistemas de distribuição de energia elétrica. Tese(Doutorado em Engenharia
Elétrica) - FEEC/UNICAMP, Campinas - SP. 1998.
LORENZETI, Jorge Fernando Canato. Reconfiguração de sistemas de distribuição de
energia elétrica para melhoria das condições de operação com relação à estabilidade
de tensão. Tese (Mestrado em Engenharia Elétrica). Faculdade de Engenharia de
Campinas - UNICAMP. Campinas - SP. 2004.
MAGALHÃES, Alana da Silva. Multi-Chaveamento para Restauração de Serviço e
Balanceamento de Carga em Sistemas de Distribuição de Energia Elétrica.
Dissertação(Mestrado em Engenharia Elétrica) - UNICAMP, Campinas - SP. 2007.
BUENO, Edilson Aparecido. Redução de Perdas Técnicas através de Reconfigurações de
Redes de Distribuição de Energia Elétrica sob Demandas Variáveis. Tese(Doutorado
em Engenharia Elétrica) - FEEC/UNICAMP, Campinas - SP. 2005.
JÚNIOR, Carlos Alberto de Castro. Reconfiguração automática de redes de distribuição
de energia elétrica.Tese (Mestrado em Engenharia Elétrica). Faculdade de Engenharia
de Campinas - UNICAMP. Campinas - SP. 1985.
PEREIRA, Marcelo Adorni. Conjuntos nebulosos e algoritmos genéticos aplicados à
restauração de distribuição de energia elétrica. Tese(Doutorada em Engenharia
Elétrica) - UNICAMP, Campinas - SP. 2000.
CORMEN, Thomas H. et al. Algoritmos: teoria e prática. Editora Campus, v. 2, 2002.
345
Implementação de um módulo medidor para criação de

Assinatura de cargas utilizando Internet das Coisas
Thiago C. Sousa1 , Altamir J Gallas2 , Davi L. de Oliveira1 , Artur F. S. Veloso3 ,

Antônio A. Rodrigues4
1
Universidade Federal do Piauı́ (UFPI), PI – Brasil
2
Faculdade Maurı́cio de Nassau, PI – Brasil
3
Faculdade Estácio (CEUT), PI – Brasil
4
Faculdade FAETE, PI – Brasil
{thiago.engee, tami.gallas, daviluis323, arturfdasveloso,
junioraraujo03}@gmail.com
Abstract. Signature of loads consists of a set of electrical characteristics unique

to each device, such as: Current, voltage, active and apparent power, power fac-
tor and energy consumed. These characteristics can be measured and used to
discriminate against them. In view of the difficulty of monitoring the consump-
tion of electricity by the consumer in real time, this work proposes the devel-
opment of a measurement system aiming at the acquisition of electrical param-
eters such as current (I) and voltage (V) through a metering module, Sending
this data to cloud services. The analysis was performed by collecting the data
stored in the cloud service. These collected data are plotted on graphs gener-
ated by MATLAB, installed in a computer, in which it was possible to observe
some parameters that formed the signature for each appliance. After the forma-
tion of the signatures of the loads, it was possible to use them for discrimination
between the two machines in operation at the same time.
Resumo. Assinatura de cargas consiste em um conjunto de caracterı́sticas

elétricas únicas para cada aparelho, como: Corrente, tensão, potências ativa e
aparente, fator de potência e energia consumida. Essas caracterı́sticas podem
ser medidas e utilizadas para discriminação das mesmas. Diante da dificul-
dade de acompanhamento em tempo real do consumo de energia elétrica pelo
consumidor, este trabalho propõe o desenvolvimento de um sistema de medição
visando à aquisição de parâmetros elétricos, tais como corrente (I) e tensão (V)
através de um módulo medidor, enviando esses dados para serviços na nuvem.
A análise foi realizada por meio da coleta dos dados armazenados no serviço da
nuvem. Esses dados coletados são plotados em gráficos gerados pelo MATLAB,
instalado em um computador, nos quais foi possı́vel observar alguns parâmetros
que formaram a assinatura para cada eletrodoméstico. Após a formação das
assinaturas das cargas, foi possı́vel utilizá-las para discriminação entre os dois
aparelhos em funcionamento ao mesmo tempo.
346
1. Introdução
A expansão acentuada do consumo de energia elétrica apresenta aspectos negativos,

como: a possibilidade do esgotamento dos recursos utilizados para a sua produção,
o impacto ao meio ambiente e elevados investimentos exigidos tanto na pesquisa de
novas fontes de produção de energia como na construção de novas usinas. Esta ex-
pansão pode ser verificada pelo consumo de energia elétrica no Brasil que totalizou
38.259 GWh em setembro de 2016, um avanço de 1,4% sobre igual mês de 2015
[Poyrazoglu and Oh 2016]. No Brasil, o Ministério de Minas e Energia (MME) criou
o Programa Nacional de Conservação de Energia Elétrica (Procel) para estimular, desde
1985, o uso eficiente de energia e, assim, conter essa expansão [Conde et al. 2013]. Uma
melhor compreensão de onde (em quais aparelhos) e quando (em quais perı́odos do dia) a
energia está sendo gasta leva tanto à redução quanto à mudança de consumo dos perı́odos
de pico para perı́odos fora de pico [Bacurau 2014]. Uma solução comercial para o mon-
itoramento do consumo de energia para unidades residenciais é o Open Energy Monitor
(OEM), sistema que permite que o usuário acompanhe em tempo real o consumo, po-
dendo gerar relatórios de seu consumo diário [OEM 2016].
Segundo [OEM 2016], o hardware do seu sistema é composto por um emonPi,
que é uma unidade de monitoramento baseada em um Raspberry Pi, para uma instalação
simples em um local que esteja disponı́vel Wifi ou Ethernet para processamento, registro e
visualização da energia de forma remota através do seu sistema Emoncms (aplicativo web
de código aberto). Entretanto, o Raspberry Pi ainda é uma tecnologia muito cara. Dentre
as plataformas de microcontroladores e microprocessadores o Arduino e o ESP8266 se
destacam por serem de baixo custo, fácil implementação e possuir hardware e software
livre, tornando mais acessı́vel sua utilização, juntamente com alguns sensores e módulos,
para criação da Assinatura de cargas dos eletrodomésticos.
Assinatura de cargas consiste em um conjunto de caracterı́sticas elétricas únicas
para cada aparelho, que podem ser medidas e usadas para discriminação de cargas. Os
parâmetros elétricos mais usados para essa discriminação são: tensão e corrente, potências
ativa, reativa e aparente, fator de potência e harmônicas do sinal de corrente. Segundo
[Bacurau 2014], é necessário o uso de algoritmos para discriminação de cargas, processo
de parâmetros elétricos medidos e, identificação de aparelhos que estão em uso constante.
Diante da dificuldade de acompanhamento em tempo real do consumo de energia elétrica
pelo consumidor [Priyanka and Vasisht 2015], e consequentemente melhorar o gerenci-
amento, este trabalho propõe o desenvolvimento de um sistema de medição utilizando
o Arduino e o ESP8266 acompanhados por sensores de corrente e tensão para gerar de
forma confiável o consumo instantâneo de energia elétrica, discriminando-o para cada
eletrodoméstico residencial, monitorando assim sua a assinatura de carga através da in-
ternet [Zanella et al. 2014].
Este trabalho está organizado na seguinte forma, na Seção 2 será feito um estudo
de caso onde será implementado o módulo medidor para monitorar os eletrodomésticos
através de sua Assinatura de carga, apresentando alguns dados no aplicativo em tempo
real. Na Seção 3, serão expostos os resultados obtidos pelo estudo de caso. Adicional-
mente, serão feitas discussões e apresentações de trabalhos futuros na Seção 4. Final-
mente, será feita a conclusão do trabalho na Seção 5.
347
2. Estudo de caso: Implementação do Open Energy Monitor para monitorar

a Assinatura de cargas de eletrodomésticos residenciais
Para o estudo de caso, será implementado um módulo medidor, capaz de medir a corrente
e tensão de cada eletrodoméstico de uma casa, apresentar os dados no gráfico do aplica-
tivo Blynk instalado em um Smartphone e na LCD do módulo. Seu desenvolvimento é
dividido nas seguintes etapas: 2.1 Medir a corrente e a tensão da residencia; 2.2 Calcular
o consumo acumulado, potências ativa e aparente, e o fator de potência; 2.3 Enviar os da-
dos para o Aplicativo Blynk, através da internet; 2.4 Apresentar os dados em um gráfico
do aplicativo em tempo real; 2.5 Exibir os dados no display LCD; 2.6 Gerar a Assinatura
de carga de cada eletrodoméstico utilizado neste estudo.
Figure 1. Arquitetura da automação realizada
Na Figura 1, é apresentada a estrutura da rede elétrica desde sua geração até o

consumo final. Em cada residencia, será composta por um Smart Meter (Medidor In-
teligente), ele quem fará a função de ler a corrente e tenção da casa, e fazer o gerencia-
mento das cargas. Entretanto, o foco deste trabalho será apenas fazer um módulo medidor,
que funcionará dentro do SM, gerando uma Assinatura de carga para cada eletrodoméstico
e fornecendo alguns dados para serviços na nuvem, possibilitando seu monitoramento em
dispositivos conectados a internet.
2.1. Medição da corrente e tensão
Dos sensores de correntes existentes no mercado atual, o escolhido para ser utilizado no
projeto foi o sensor SCT-013-000, devido à possibilidade de se medir correntes de até 100
A e por ser não invasivo. Este sensor apresenta em sua saı́da uma variação de corrente,
sendo necessário um circuito para condicionar o sinal a fim de que possa ser conectado
ao Arduino. A tensão da rede é muita alta para ser medida diretamente pela entrada
analógica do Arduino fazendo-se necessária sua transformação em um nı́vel de tensão
seguro. Para isso é utilizado um transformador 220/9V e um circuito para se realizar o
condicionamento do sinal proveniente da saı́da do transformador, de forma que o sinal
resultante tenha um pico positivo menor que 5 V e um pico negativo maior que 0 V.
348
2.2. Cálculo do consumo acumulado, potências ativa e aparente, e fator de potência
Foram utilizados 2 eletrodoméstico residenciais, sendo eles: Um micro-ondas e uma

geladeira. Inicialmente cada aparelho foi ligado e medido individualmente para que o
módulo medidor pudesse gerar a sua assinatura de carga. A assinatura, foi criada através
dos diversos parâmetros elétricos medidos pelo Arduino. Para efetuar os cálculos, foi uti-
lizada a biblioteca ”EmonLib.h”, da própria Arduino IDE. Na qual, tem como parâmetros
de entrada os dados coletados pelos sensores de corrente e tensão. A biblioteca possui
uma função denominada ”Emon.calcVI (20, 2000);”, que retorna os valores de corrente,
tensão, fator de potência, potências ativa e aparente.
2.3. Envio dos dados para o Aplicativo Blynk
O módulo medidor trabalha em conjunto com o ESP8266 tipo 01. Este microprocessador
é capaz de se conectar a internet por meio do WI-FI. A troca de dados é possı́vel através
da utilização do protocolo MQTT [Thatmann et al. 2015], que é um serviço na nuvem
fácil de se utilizar e possui uma comunicação em tempo real. A grande contribuição da
sua utilização é, a troca de dados através da internet, que permite seu monitoramento de
qualquer lugar em tempo real. O aplicativo Blynk, trabalha como um cliente MQTT, que
recebe os dados enviados pelo módulo implementado. O acesso do aplicativo também é
feito através da internet.
2.4. Apresentação dos dados em um gráfico do aplicativo em tempo real
O aplicativo apresenta os dados coletados em um gráfico, e faz a plotagem do dados obti-

dos pelo sensor, em tempo real. Na Figura 2 é apresentado o print da tela do aplicativo no
momento da leitura dos eletrodomésticos, e a estrutura do módulo medidor na instalação
elétrica da residencia.
Figure 2. Módulo medidor e o print da leitura feita no aplicativo em tempo real
2.5. Exibição dos dados no display LCD
No módulo, foi utilizando um LCD 16x2 para apresentar os valores utilizados para a
formação da assinatura de carga. Seu objetivo é apresentar os dados localmente sem a
necessidade da internet e de um aplicativo.
349
2.6. Geração da Assinatura de carga de cada eletrodoméstico utilizado neste estudo

Após apresentação dos dados no aplicativo, foram armazenados os valores coletados dos
sensores em um arquivo de texto. Com o módulo medidor construı́do, realizaram-se
testes com diversos eletrodomésticos de uma residência. Cada teste teve duração de 1
hora, com medidas sendo realizadas a cada segundo, totalizando 3600 amostras para cada
aparelho. A seguir são apresentadas as curvas obtidas através do software MATLAB
[MATLAB 2017]. São analisados os parâmetros para cada aparelho, observando-se prin-
cipalmente as potências ativa e aparente, além do fator de potência. Estes parâmetros são
necessários para o reconhecimento de cargas através de suas assinaturas.
2.6.1. Geladeira
A Figura 3 exibe os gráficos dos diversos parâmetros elétricos para uma geladeira frost
free da marca Consul utilizada como uma das cargas no presente trabalho.
Figure 3. Leitura dos parâmetros da Geladeira
Através da Figura 3 é formada a assinatura de consumo para este eletrodoméstico,

identificando-se corrente média igual a 0,825 A, potência ativa média igual a 89,89 W e
aparente igual a 182,6 VA, com fator de potência igual a 0,49. Esses parâmetros facilitam
a identificação deste aparelho quando em funcionamento.
2.6.2. Micro-ondas
Para o teste com o micro-ondas foi utilizado um aparelho da marca Panasonic de 15

litros. Com este eletrodoméstico não foi possı́vel medir em funcionamento durante uma
hora seguida, como feita com a geladeira. Então foi realizado o seguinte procedimento:
o medidor ficou ligado durante uma hora realizando as leituras e gravando os dados e
em diversos momentos o micro-ondas foi ligado com duração de 1 a 2 minutos em in-
tervalos de 10 minutos, aproximadamente, entre cada acionamento. A Figura 4 exibe as
curvas observando-se os ciclos de funcionamento do aparelho em cada pico de corrente ou
potência. Para levantamento das caracterı́sticas deste eletrodoméstico, tais como potência
350
média, corrente média e fator de potência, foram eliminadas todas as leituras iguais à zero,
deixando somente os dados gravados em que o micro-ondas esteve em funcionamento 5.
Figure 4. Leitura dos parâmetros do Micro-ondas
Através da 4 observa-se que o equipamento apresentou altos nı́veis de corrente e

potência, o que pode facilitar sua identificação por se diferenciar bastante dos nı́veis de
consumo dos outros eletrodomésticos. Um detalhe importante comparando-se o valor da
tensão média nas Figuras 4 e 5 é que o uso do micro-ondas leva a uma significativa queda
de tensão. Nos dados gravados observou-se uma queda de tensão de aproximadamente 3
V no momento em que o micro-ondas era ligado.
Figure 5. Leitura dos parâmetros do Micro-ondas
Através das Figuras 4 e 5 é realizada a formação da assinatura de carga para o

micro-ondas. Tem-se que a corrente média foi igual a 5,26 A, potência ativa média de
1080 W e aparente de 1184 VA. O fator de potência médio para este equipamento fica em
torno de 0,91. Esses parâmetros, além da forma de onda das curvas, assim diferencia-se
quando comparado com equipamentos de potência ativa próxima, como o ferro de passar
roupas por exemplo. A energia consumida observada foi de 0,12 kWh, totalizando um
custo de R$0,077 em aproximadamente 7 minutos de uso do equipamento. O que pode
mostrar ao consumidor que o micro-ondas apresenta alto custo quando muito utilizado.
351
3. Resultados
Após formação das assinaturas das cargas utilizadas no presente trabalho é possı́vel uti-
lizá-las para identificar as mesmas quando medidas simultaneamente. A Figura 6 ex-
emplifica esta situação, sendo apresentada a curva de potência ativa. Como os dois
equipamentos analisados apresentam valores de potência ativa bem distintos é possı́vel
discriminá-los através deste parâmetro. Analisando-se a Figura 6 verifica-se que inicial-
mente nenhuma das cargas está em funcionamento. Em seguida percebe-se que o forno
micro-ondas foi ligado, pois a curva de potência é similar à apresentada anteriormente na
Figura 4. Depois de um momento ele torna a ser desligado e a potência medida igual a
zero. Na amostra de número 620, aproximadamente, nota-se um pico de potência ativa de-
vido ao acionamento do compressor da geladeira e em seguida a curva representado o fun-
cionamento da mesma durante 22 minutos até o momento em que o micro-ondas também
é acionado. Observa-se que a potência medida equivale à soma dos valores dos dois dis-
positivos em análise, durante 1 minuto e 30 segundos, confirmando-se a identificação das
cargas através da análise dos parâmetros elétricos medidos.
Figure 6. Assinaturas de carga da geladeira e do micro-ondas sendo apresen-

tadas simultaneamente
Os dados foram apresentados e armazenados em tempo real através da internet,

na nuvem. Isto possibilitou um melhor monitoramento permitindo o acesso a estes val-
ores em qualquer lugar e a qualquer momento. A utilização das tecnologias IoT foram
de grande importância para o monitoramento do consumo de energia elétrica e armazena-
mento de dados para formação das assinaturas, o que torna mais fácil sua adoção por
usuários que buscam tecnologias mais flexı́veis e fáceis de utilizar.
4. Conclusões, discussões e propostas de trabalhos futuras

Observa-se nos resultados obtidos que, para todas as medições apresentadas neste tra-
balho, o consumo total de energia elétrica foi de 0,39297 kWh aproximadamente. Lem-
brando que o micro-ondas foi acionado somente por 7 minutos durante o teste sozinho e
mais 7 minutos quando funcionando juntamente com a geladeira. Entretanto, a criação
das assinaturas de carga, foi realizada manualmente. Onde, os dados armazenados no
352
serviço da nuvem são coletados e plotados em um gráfico do MATLAB. O Arduino

e o ESP8266 demonstraram ser eficazes na construção do módulo medidor de energia
elétrica, por seu baixo custo e facilidade de aquisição, programação livre e comunicação
com diversos sensores disponı́veis no mercado. A sua troca de dados em tempo real
com serviços na nuvem, possibilita a adoção dessa tecnologia, apresentando uma solução
que amplia a conectividade com dispositivos usados no dia-a-dia, como Smartphones.
Através do sensor de corrente e um transformador de tensão 220/9 V possibilitou-se a
construção do medidor, a fim de se obter diversos parâmetros elétricos. Com esses dados,
permitiu-se a geração de gráficos pelo software MATLAB. Foi possı́vel também, con-
hecer e analisar as diversas caracterı́sticas de consumo dos eletrodomésticos. Essa análise
tem o intuito de determinar suas assinaturas, de forma a possibilitar a identificação das
cargas quando estiverem em funcionamento juntas. Conclui-se que, este trabalho utiliza
tecnologias IoT para a facilitar a criação da assinatura de cargas. Com estas assinaturas,
será possı́vel a implementação de um Smart Meter capaz de fornecer o monitoramento
de cargas de maneira independente. Ou seja, fornecer a energia consumida por equipa-
mento ou até mesmo, identificar qual equipamento está em funcionamento, permitindo o
controle de cargas através da internet. Como trabalhos futuros, pretende-se implementar
uma Inteligência Artificial para a identificação de cargas. A melhoria do módulo medidor
também será realizada, adicionando um aplicativo que possa fornecer todos estes dados
de forma simplificada e completa aos usuários e concessionárias de energia elétrica.
References
Bacurau, R. M. (2014). Medidor de energia inteligente para discriminação de consumo
por aparelho através de assinatura de cargas. In Dissertação (Mestrado em Engenharia
Elétrica) - Universidade Estadual de Campinas, pages 1–94.
Conde, G. A. B., dos Santos, F. C., de Santana, A. L., Silva, R. D., Frances, C. R. L., and
de Lima Tostes, M. E. (2013). New methodology for grouping electric power consum-
ing units to meet continuity indicators targets established by the brazilian regulatory
agency. In IET Generation, Transmission Distribution, pages 414–419. IEEE.
MATLAB (2017). MATLAB - The Language of Technical Computing. [Online; accesso
15-Julho-2017].
OEM (2016). Open Energy Monitor. www.openenergymonitor.org. [Online;
accesso 25-Julho-2017].
Poyrazoglu, G. and Oh, H. (2016). The impacts of electric power market simulation on
engineering education. In IEEE/PES Transmission and Distribution Conference and
Exposition (T&D), pages 1–5. IEEE.
Priyanka, N. and Vasisht, A. (2015). Smart cities. In International Journal of Engineering
Science Invention, pages 43–49. IJESI, 4th edition.
Thatmann, D., Zickau, S., Forster, A., and Kupper, A. (2015). Applying attribute-based
encryption on publish subscribe messaging patterns for the internet of things. In IEEE
International Conference on Data Science and Data Intensive Systems, pages 556–563.
IEEE.
Zanella, A., Bui, N., Castellani, A., Vangelista, L., and Zorzi, M. (2014). Internet of
things for smart cities. In IEEE Internet of things journal, pages 6–15. IEEE.
353
An approach for clustering sensor nodes by data similarity

Marcus Lemos1,3 , Carlos Giovanni1 , Marcel Mei1 , Kenneth Sepulveda1 ,
Dara Oliveira1 , Abdias Viana1 , Ricardo Rabelo2 , Raimir Holanda3
1
State University of Piaui (Uespi)
Teresina, Piaui, Brazil
2
Federal University of Piaui (UFPI)
Teresina, Piaui, Brazil
3
University of Fortaleza (Unifor)
Fortaleza, Ceara, Brazil
{marvin,cgnc}@uespi.br, {marcel,kennethsousabr,dara}@gmail.com
Abstract. In Wireless Sensor Networks, data aggregation is a crucial task since

it is capable of reducing the network traffic, increasing the overall network life-
time. However, most works consider aggregation when nodes are close to each
other since the common assumption is that if a set of sensor nodes are physically
close to each other, they produce highly correlated data. Nevertheless, the fact
that nodes are close to each other does not guarantee data correlation in order
to perform aggregation. Hence, the objective of this paper is to present Akasen
to clusters sensor nodes based on the data similarity. Results from experiments
in IntelLab dataset show that the Akasen reduces energy consumption by 5.5×,
providing a solution to be considered in wireless sensor networks scenarios.
1. Introduction
Wireless Sensor Networks (WSN) consist of a large set of small electronic devices, called
sensor nodes, capable of sensing and transmit (usually by a wireless transceiver) envi-
ronmental variables, such as temperature, humidity, light and so on [Rawat et al. 2014].
Considering that sensor nodes are usually battery-powered, the energy consumption im-
poses severe restrictions on this kind of network. Since the transceiver requires more
energy than sensing activities, some researches on the literature have directed studies to
reduce the overall data traffic generated by the sensors nodes [Jiang et al. 2011].
As many applications are related to the periodic monitoring, and it is well known
that, in such scenarios, redundant data may be sent by sensor nodes [Carvalho et al. 2011],
most works in literature consider data aggregation to reduce the overall traffic
[Kridi et al. 2016], [Gielow et al. 2015] and [Kim et al. 2014]. In these works, aggrega-
tion occurs when nodes are close to each other, exploiting the spatial correlation between
them. The common assumption is that if a set of sensor nodes are physically close to each
other, they produce highly correlated data [Karasabun et al. 2013]. However, the fact that
nodes are close to each other does not guarantee data correlation in order to perform ag-
gregation. To exemplify that observation, consider the temperatures taken from the Intel
Lab project dataset1 . Figure 1 compares the correlation of temperature of one sensor node
1
http://db.csail.mit.edu/labdata/labdata.html
354
Figure 1. Correlations between node

1 and others sensor nodes, from Intel
Figure 2. Heatmap showing that is
possible to cluster nodes based on the
Lab dataset. The black line shows a de-
similarity of their measurements
sired threshold. Notice that even dis-
tante nodes are correlated.
1 with all others nodes. It is clear that even distant nodes have temperature correlated
with Node 1. In Figure 2, each circle of the grid means a group of sensor nodes put to-
gether based on the correlation of first 200 temperature measurements. The grid, created
by SOM algorithm [Kohonen 1998] gives the idea that nodes from different geographical
areas could fall in same clusters.
In fact, the authors in [Lemos et al. 2017] exploited that idea and presented
ACASIM, a clustering approach where the physical sensor nodes are clustered according
to their measurements similarity. And by selecting only a sub-set of sensor nodes from
each cluster, ACASIM could reduce energy consumption, while attending the applications
requirements. The clustering process is controlled by a error threshold, i.e., whenever the
measurements from a sensor nodes does not not fit its clusters anymore, ACASIM reorga-
nize all the clusters again. However, we argue that the reduction of energy consumption
could be improved if the algorithm first tries to reconstruct only the clusters whose mea-
surements are deviating from the pattern. Hence, we propose Akasen, Adaptive K-Means
Algorithm for Sensor Networks, for clustering sensor nodes in a WSN. Akasen uses K-
Means algorithm to group the nodes according the similarity of their measurements. The
value of K is find automatically according to a threshold parameter defined by the appli-
cation. And differently from ACASIM, Akasen tries first to reallocate the sensor nodes
whose measurements diviate from their clusters, before construct all clusters again.
The article is structured as follows: Section 2 discusses in more detail the oper-
ation of Akasen. Section 3 presents the performance evaluation of the proposed, while
Section 4 discusses the results. Finally, in Section 5, the conclusions are presented along
with some future research directions.
2. Adaptive K-Means Algorithm for Sensor Networks

The main goal of Akasen is to clusters sensor nodes based on the similarity of their mea-
surements. The clustering process guarantees that the correlation between the measure-
ments from each cluster are below an threshold parameter. In that sense, it not necessary
that all sensor nodes transmit their measurements anymore. As all values are correlated
and the sensor nodes are homogeneous, the sink node needs to receive the measurements
from one sensor node of each cluster, at least. This approach leads to a significant im-
provement in the energy consumption reduction. At any point in time, Akasen is in one
355
of the following modes: configuration, training, and maintaining (Figure 4), which are
described next.
2.0.1. Configuration
Initially, it is necessary the configuration of three parameters: training window,

initial k, threshold, according Figure 4a. The training window delimiters how many
measurements the sink nodes must receive, during the training mode in order to execute
K-Means algorithm, while initial k and threshold are used by the training itself to adjust
the clusters formation, as explained later in this section. The values of these parameters is
a decision project and are based upon the nature of the measurements. After that, training
mode begins (4b).
2.0.2. Training
This step represents the main core of Akasen, since it is responsible for executing K-
Means to clusters sensor nodes. First, sink node must receive measurements sent from all
sensor nodes during a specific time-window, represented by training window. Whether
more than one measurements from each node arrives, sink node aggregates them using a
average operation. The measurements are stored in a matrix Xnm , where n > 0 represents
the values monitored by each sensor node and m ≥ 1 corresponds to the sensors nodes in
the network. In sequence, K-Means algorithm is executed. Usually, the value of K, which
corresponds to the number of desired clusters, must be given a priori. However, is not
always easy to determine the best value. A traditional strategy to select K is to execute
K-Means repeated times and increment the value of K in each execution. The goal of
this procedure, named Elbow method [Jain 2010], is to find the K value that makes the
variance of the clusters falls below 0.2. The value 0.2 usually means an ”elbow” in a scree
plot, as pointed out by Figure 3.
Figure 3. Scree plot. The ”elbow” (pointed out by the green arrow) represents
the point where adding another cluster does not produce better models.
The intuition is that below the ”elbow”, the variance of the generated model slowly
decreases, i.e., adding another cluster does not produce better models. However, Akasen
does not use variance to control the value of K. Instead, it refines the clustering models
until a criterion is reached. Algorithm 1 shows how K-Means works.
356
Data: initial k, threshold, matrix

Result: Clusters
1 K = initial k;
2 while True do
3 kmodel ← kmeans(matrix, K);
4 clusters over = exists clusters over threshold(kmodel, threshold);
5 if clusters over threshold == False then
6 best k ← K;
7 best model ← kmodel;
8 break;
9 else
10 K ← K + 1;
11 end
12 end
Algorithm 1: K-Means
Initially, the K variable is configured with the initialk value (Line 1) and, in
sequence, the algorithm enters a loop (Line 2). Each loop iteration executes k-means with
the last K value and stores the model in kmodell variable (Line 3). Then Akasen executes
a function, named exists clusters over threshold, which checks if some of the clusters (in
kmodel) contain at least one node whose euclidian distance between its measurements
and the center of the clusters is over threshold. In the case of T rue, K is incremented,
and the process is repeated. Otherwise, Akasen has just found the best K value, and
the loop is broken down (after storing K and kmodel values). Then, Akasen selects
only one sensor node from each cluster and broadcast a special message, warning all
other sensor nodes to enter a low power state, along with the coefficients of a linear
model which represents the measurements of each node, according to the strategy used
in [Lemos et al. 2017]. These linear models will be used during Maintaining mode. All
these procedures are depicted in 4b. Then, it begins the maintaining mode.
2.0.3. Maintaining
As each cluster contains only node whose measurements are close to each other (based
on threshold value), it does no matter if the distance between the sensor nodes is small
or not; the selected nodes can represent all other nodes from their clusters. Moreover,
as only one node is selected, the overall energy consumption of the WSN is reduced.
However, it can happen that the measurements from some sensors nodes start to deviate
from the pattern of their clusters. In that case, Akasen should reconstruct the clusters.
Therefore, in maintaining mode, each sensor node not transmitting checks the status of
its measurements. Whether the absolute error between the new measurements and the
measurement predicted by the linear model is bigger than threshold, the sensor nodes
send a message to sink node, along with its new measurements. Before executing K-
Means again, sink node verifies if that sensor node can be reallocated to another cluster.
In the case of success, sink node generates a new linear model and send back to the sensor
node. However, if the reallocation process fails, K-Means is executed again (4c).
357
Figure 4. Akasen
3. Performance Evaluation
Akasen have been evaluated based on real data obtained from the Intel project, Berke-
ley Lab Data2 , as it is publicly available and used by several works on literature
[Gielow et al. 2015, Carvalho et al. 2011, Jiang et al. 2011]. The dataset consists of the
measurements of 54 sensor nodes measured every 31 seconds between 28 February and 4
April 2004. However, the nodes do not have the same number of measurements (possibly
due to errors or failures in the sensor-reading process). Therefore, to properly evaluate
the performance of the simulations, the first 5,000 measurements were taken (correspond-
ing approximately to the measurements of the first day). The original dataset contains
missing values, which were interpolated with the average of the values from the previ-
ous and subsequent measurements. The results described here have been produced by
simulations performed with R3 language. Akasen was compared with LEACH protocol
[Heinzelman et al. 2000]. In the LEACH protocol, only cluster heads communicate with
the sink node, and each sensor node has probability P of being elected cluster head. The
cluster heads receive all measurements from nodes in their clusters and generate an aggre-
gate value from them. In this work, the mean is considered as the aggregation function.
The single-hop (direct) communication [Meghji 2011] was used as a benchmark case. In
the single-hop communication, each node transmits its measurements directly to the sink
node.
The mean squared error (MSE) and energy consumption were chosen to evaluate
2
http://db.csail.mit.edu/labdata/labdata.html
3
http://www.r-project.org/
358
Akasen properly. As the created clusters may include sensor nodes not physically close to
each other, MSE helps to investigate how reliable is the measurements sent by the selected
sensors, i.e., how they can be representative of multiple regions. The energy consumptions
measures how well Akasen selects the sensor nodes in order to save energy. The models
(from both metrics) defined in [Lemos et al. 2017] were used.
4. Results and Discussion

4.1. LEACH protocol results
In LEACH protocol, every node has a probability P of being selected as a cluster head.
For this reason, it was simulated eight scenarios with different values of P . The values of
P considered were 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, and 0.9. Table 1 shows the results in
the eight scenarios. Considering the table, MSE is closely correlated with the value of P ,
which was expected since, in the LEACH protocol, the clusters are based on the nodes’
proximity (based on physical distance).
Small values of P mean that few cluster heads are selected. In this case, the MSE
is higher since each cluster may contain nodes with measurements significantly different
from each other. As the value of P increases, the number of cluster heads increases as
well. Hence, the MSE decreases because the clusters contain more nodes close to each
other (based on physical distance).
Regarding energy consumption savings (in compare with single-hop communica-
tion), as the value of P increases, more nodes are selected as cluster heads, which boosts
the number of transmissions inside the network. Consequently, the energy consumption
savings decrease. As the value of P approaches 1, the energy consumption of LEACH
becomes more similar to the single-hop communication.
4.2. Akasen results

Akasen was simulated in eight different scenarios with the following T HRESHOLD
values: 0.1, 0.3, 0.5, 1.0, 2.0, 3.0, 4.0, and 6.0. Table 2 shows the results in the eight sce-
narios simulated. It is possible to see a positive correlation between the T HRESHOLD
and the energy consumption savings; i.e., as the T HRESHOLD value increases, the per-
centage of energy consumption savings also increase. This is because high values of that
parameter generate fewer clusters, and each cluster contains a large number of nodes. As
only one node responds, the energy consumption decreases. However, regarding M SE,
there is an increasing tendency as the value of T HRESHOLD rises.
4.3. Comparing the results of LEACH and ACOSIM

The highest value of MSE in Akasen (7.68) is about 3.7× lower than highest value of
MSE in LEACH scenarios (28.72). Considering these same scenarios, energy savings of
LEACH is slightly superior (about 1.5×). It is important to stress that these is just the
scenarios with highest energy savings in both solutions. However, a MSE equals to 28.72
makes LEACH, with P = 0.2, infeasible for WSN applications. Considering Node 18,
Figure 5 shows the absolute error between the transmitted values from the nodes’ clusters
and its real measured values during the simulations in the scenarios with P = 0.2. From
theses results, it is possible to see that the error falls beyond 5 ◦ C in most of the time.
359
Figure 5. Absolut error in LEACH scenarios with P equals to 0.2
In Akasen, the highest value of M SE is 7.68 (when T HRESHOLD = 6), which

is about 3× worse than the lowest M SE for the LEACH protocol (M SE = 2.09 when
P = 0.9). However, with this same configuration, the energy consumption reduction of
ACOSIM is 53.92%, which is about 5.5× better than LEACH protocol with P = 0.9 (the
scenario with the lowest MSE), where the percentage energy savings value is 9.80%.
Table 1. LEACH results

Table 2. Akasen results
Thr. Energy (mJ) Sav.(%) MSE
P Energy (mJ) Sav.(%) MSE
0.1 130, 604.90 0.005 0.013
0.2 26, 227.10 79.91 28.72
0.3 130, 461.50 0.115 0.086
0.3 39, 334.82 69.88 22.83
0.5 130, 287.10 0.24 0.14
0.4 52, 422.89 59.86 18.06
1.0 90, 532.30 2.53 0.48
0.5 65, 567.48 49.80 13.98
2.0 70, 338.40 13.10 1.87
0.6 78, 544.14 39.86 10.39
3.0 60, 688.79 29.02 3.89
0.7 91, 599.68 29.86 7.26
4.0 55, 551.39 38.33 5.63
0.8 104, 681.71 19.85 4.50
6.0 30, 679.35 53.92 7.68
0.9 117, 804.67 9.80 2.09
5. Conclusions and Future Works

This paper presented Akasen, an algorithm to clusters sensor nodes based on the simi-
larity of their measurements with the purpose of reducing energy consumption. Akasen
performs the clustering based on a modified version of K-Means which automatically
choose the value of K considering a threshold parameter. This approach leads to group
together sensor nodes not close physically (based on the physical distance), as traditional
works on literature do. However, since the measurements are correlated, according to an
threshold parameter, sink node may select only few sensor nodes from each cluster in or-
der to transmit its measurements, while the others may change their states to a low-power
mode operation. Hence, there is an improvement in the overall energy reduction of the
WSN.
Simulations have shown that Akasen, compared to LEACH protocol, has better
performance regarding energy consumption (about 5.5 × %) and MSE (3.7×), indicating
the feasibility of the proposed algorithm. As future work, we intend to: (i) perform
360
simulations in more complex environments, taking into account other variables such as
the routing protocol, (ii) compare Akasen with moderns clustering algorithms, including
ACASIM, and (iii) develop an algorithm to perform the optimal selection of sensor nodes
that will transmit the measurements.
References
Carvalho, C., Gomes, D. G., Agoulmine, N., and de Souza, J. N. (2011). Improving
prediction accuracy for wsn data reduction by applying multivariate spatio-temporal
correlation. Sensors, 11(11):10010–10037.
Gielow, F., Jakllari, G., Nogueira, M., and Santos, A. (2015). Data similarity aware
dynamic node clustering in wireless sensor networks. Ad Hoc Networks, 24:29–45.
Heinzelman, W. R., Chandrakasan, A., and Balakrishnan, H. (2000). Energy-efficient
communication protocol for wireless microsensor networks. In Proceedings of the
33rd Hawaii International Conference on System Sciences, volume 8 of HICSS ’00,
pages 8020–, Washington, DC, USA. IEEE Computer Society.
Jain, A. K. (2010). Data clustering: 50 years beyond k-means. Pattern Recognition Let-
ters, 31(8):651 – 666. Award winning papers from the 19th International Conference
on Pattern Recognition (ICPR).
Jiang, H., Jin, S., and Wang, C. (2011). Prediction or not? an energy-efficient framework
for clustering-based data collection in wireless sensor networks. IEEE Transactions
on Parallel and Distributed Systems, 22(6):1064–1071.
Karasabun, E., Korpeoglu, I., and Aykanat, C. (2013). Active node determination for
correlated data gathering in wireless sensor networks. Computer Networks, 57(5):1124
– 1138.
Kim, J.-Y., Sharma, T., Kumar, B., Tomar, G. S., Berry, K., and Lee, W.-H. (2014).
Intercluster ant colony optimization algorithm for wireless sensor network in dense
environment. International Journal of Distributed Sensor Networks, 2014.
Kohonen, T. (1998). The self-organizing map. Neurocomputing, 21(1):1 – 6.
Kridi, D. S., de Carvalho, C. G. N., and Gomes, D. G. (2016). Application of wireless
sensor networks for beehive monitoring and in-hive thermal patterns detection. Com-
puters and Electronics in Agriculture, 127:221 – 235.
Lemos, M., d. Carvalho, C., Lopes, D., Rabelo, R., and Filho, R. H. (2017). Reducing
energy consumption in provisioning of virtual sensors by similarity of heterogenous
sensors. In 2017 IEEE 31st International Conference on Advanced Information Net-
working and Applications (AINA), pages 415–422.
Meghji, Mahirand Habibi, D. (2011). Transmission Power Control in Single-Hop and
Multi-hop Wireless Sensor Networks, pages 130–143. Springer Berlin Heidelberg,
Berlin, Heidelberg.
Rawat, P., Singh, K. D., Chaouchi, H., and Bonnin, J. M. (2014). Wireless sensor net-
works: a survey on recent developments and potential synergies. The Journal of Su-
percomputing, 68(1):1–48.
361
Um estudo de caso utilizando o Protocolo MQTT e

Internet das Coisas na Automação Residencial
Artur F. da S. Veloso1, Antonio A. Rodrigues2, Altamir de J. Gallas Neto3, Thiago
C. de Sousa4 Davi L. de Oliveira4
1
Faculdade Estácio CEUT – PI, Brasil
2
Faculdade Faete – PI, Brasil
3
Faculdade Maurício de Nassau – PI, Brasil
4
Universidade Federal do Piauí (UFPI) – PI, Brasil
{arturfdasveloso, junioraraujo03, tami.gallas, thiago.engee,
daviluis323}@gmail.com
Abstract. The Residential Automation is a concept used for houses composed

of technologies such as sensors and actuators that makes it possible to
automate daily manual work in a residence. This work proposes a case study
of residential automation using concepts of IoT - Internet of Things, along
with the MQTT protocol. Providing services in the cloud that provide
communication between intelligent objects. A framework has been proposed to
show communication between IoT nodes that are responsible for turning on /
off electronic home devices and monitoring distributed sensors. Its
development was based on experimental tests in the real scenario.
Resumo. A Automação Residencial é um conceito utilizado para casas

compostas por tecnologias como sensores e atuadores que possibilita
automatizar trabalhos manuais do dia-a-dia em uma residência. Este trabalho
propõe um estudo de caso de automação residencial utilizando conceitos de
IoT – Internet das Coisas, juntamente com o protocolo MQTT. Dispondo de
serviços na nuvem que fornecem a comunicação entre os objetos inteligentes.
Uma estrutura foi proposta para mostrar a comunicação entre os nós IoT que
são responsáveis por ligar/desligar os dispositivos eletrônicos da casa e
monitorar sensores distribuídos. Seu desenvolvimento foi baseado em testes
experimentais no cenário real.
1. Introdução
Uma casa residencial tem uma gama de eletrodomésticos e funcionalidades que

precisam ser automatizadas, como: ar-condicionado, cafeteira, geladeira, TV, radio e
entre outros equipamentos que podem torná-la uma casa inteligente [Bhatt and Patoliya
2016]. Neste cenário surge o conceito de IoT - Internet of Things [Zanella et al. 2014],
paradigma que consiste em interligar todas as coisas, possibilitando sua comunicação. A
IoT é uma convergência de múltiplas coisas tecnológicas que envolvem desde a
comunicação sem fio, internet, sistemas embarcados e objetos inteligentes. Com o
avanço deste paradigma das coisas conectadas, surgiram novas perspectivas de
362
implementação em diversas áreas de sua aplicação como, por exemplo: automação

residencial, robótica, domótica e tecnologias vestíveis. Estes sistemas inteligentes
constituem-se de uma extensão da computação ubíqua, que envolve a incorporação de
sistemas inteligentes em objetivos do dia-a-dia, com o objetivo de fornecer conforto,
segurança, comodidade e sustentabilidade [S. et al. 2011].
Nesta abordagem, surge a automação residencial composta por inúmeros
benefícios fornecidos por aplicações de IoT. Onde ambientes inteligentes se
caracterizam por propiciar aos usuários de uma residência, um local onde eles podem
interagir com dispositivos espalhados por toda a parte [Priyanka and Vasisht 2015].
Além disso, esses ambientes devem possuir a capacidade de se detectarem e
comunicarem entre si [S. et al. 2011]. As coisas se comunicam através da atuação de
sensores dos objetos e de dados gerados pela comunicação, recebidos pelos
microcontroladores, com finalidade na tomada de decisões. Neste contexto, a
abordagem deste trabalho visa fazer um estudo de caso dos diferentes meios de
transmissão de dados em aplicações de automação residencial com Internet das Coisas,
como padrões de comunicação e protocolos.
Neste trabalho, será discutida a funcionalidade da aplicação do protocolo
Publish-Subscribe na IoT, em soluções de Automação Residencial. Assim o trabalho
busca desenvolver um estudo de caso utilizando o protocolo Publish-Subscribe,
apresentando resultados da abordagem, comparações com outros protocolos, discussões
e finalmente apresentar uma conclusão.
2. Estudo de Caso: Automação residencial utilizando IoT com o Protocolo

MQTT
Para saber como funciona o protocolo MQTT e sua relevância na IoT, serão
apresentados conceitos sobre sua aplicação e implementações com sua utilização na
automação residencial. Essas implementações foram feitas e testadas em um ambiente
real, portanto, os dados coletados são extraídos de sensores distribuídos na casa.
2.1. Protocolo MQTT (Publish-Subscribe)

O protocolo MQTT - Message Queue Telemetry Transport, é um protocolo de rede do
tipo publish/subscribe (Publicar/Inscrever) [Thatmann et al. 2015], de mensagens leves
para a comunicação M2M - Machine to Machine. Os dispositivos utilizam um
BROKER MQTT disponibilizado na Cloud Computer (Computação em Nuvem), para
publicar as mensagens em tópico do BROKER. Este tópico pode ser localizado em
qualquer lugar da internet por qualquer dispositivo que subscreva este tópico. Assim
podendo recebendo os dados em tempo real, assim que alterados no tópico. Nesse tipo
de protocolo não há comunicação direta entre o dispositivo que envia e os que recebem
as mensagens [Li et al. 2017], [Rani et al. 2017]. As informações recebidas passam por
um servidor que recebe as mensagens publicadas e aguarda até que um dispositivo
solicite a mensagem [Triawan et al. 2016], [Li et al. 2017]. No olhar da sua utilização, e
a necessidade de baixo processamento, banda larga ou consumo de energia o MQTT é
um dos protocolos ideais para os dispositivos que exigem pouco poder de
processamento e maior durabilidade em sua utilização.
As partes que envolvem a comunicação do MQTT são compostas por:
publishers, quem irá publicar os dados/informações no tópico, e subcribers, quem irá
363
receber as informações. Já o Broker, é uma parte que visa fornecer o serviço como
servidor MQTT, através da conexão com a internet. O Broker é o responsável pelo
funcionamento, assim sobrando mais tempo para gerenciar outras partes do
desenvolvimento [Grgic et al. 2016]. O MQTT [Lampkin et al. 2012] é um protocolo de
mensagens extremamente simples e leve. Sua arquitetura segue o modelo apresentado
na figura 1.
Figura 1. Arquitetura do protocolo MQTT Publish/Subscribe
O Broker MQTT possui dois parâmetros importantes na sua execução:
• Tópico - É a chave de identificação da publicação. Faz o direcionamento da

mensagem publicada, e envia para os subscribes assinados nele.
• Payload - É a informação que se deseja enviar.
Figura 2. Implementação do protocolo MQTT no monitoramento da

Temperatura de um ambiente da casa
A comunicação via Broker é organizado por um tópico, cada tópico possui um

payload (dado), este dado é publicado pelo publish, e enviado aos subscribers [Babovic
et al. 2016]. Em outras palavras para descrever a solução proposta em IoT a utilização
do protocolo MQTT possui a função de servidor Broker, e o restante sendo assim
364
clientes MQTT. Na Fig. 2 é apresentada a utilização deste protocolo na automação

residencial. O Sensor de temperatura faz a leitura do ambiente e publica esse dado em
um tópico denominado por “temperature” no Broker. O Smar Watch e a API AdminIoT
fazem o papel de subscribes, eles receberão esses dados assim que atualizados no
tópico.
2.2. Proposta de automação residencial utilizando o protocolo MQTT
A automação residencial proposta foi desenvolvida para analisar um estudo de caso

sobre a utilização do protocolo MQTT. Na Fig. 3, são apresentados os eletrodomésticos
automatizados. A direita da imagem, o usuário apresentando os dados coletados pelo
sensor de corrente e plotados em tempo real no aplicativo mobile. Todo o
gerenciamento e controle da automação da casa, é realizada através do aplicativo, que
trabalha com o protocolo MQTT implementado na residência.
Figura 3. Eletrodomésticos utilizados na Automação Residencial
No estudo de caso, foram utilizados 25 eletrodomésticos e 10 sensores [Javed et

al. 2016]. Entre os sensores, foi implementado um sensor de corrente, que mede a
corrente utilizada por todos os eletrodomésticos presentes na automação, conforme
apresentado na Fig. 4. Como o sensor de corrente representa o consumo utilizado pela
casa, foi feito um cálculo, convertendo a corrente lida pelo valor em real.
Figura 4. Sensor de corrente e sua plotagem no aplicativo mobile
Com o intuito de utilizar o protocolo MQTT dentro do cenário IoT, foram

criadas aplicações que processam tópicos em ambientes de automação residencial.
365
Utilizando os conceitos abordados na seção anterior, foram implementados alguns

cenários de situações, como mostra a Fig. 5.
Figura 5. Protocolo MQTT utilizando o Broker HiveMQ
No exemplo representado na Fig. 5, o protocolo MQTT utilizado é o HiveMQ

uma plataforma aberta assim como o eclipse.io, utilizado neste trabalho. No exemplo,
um sensor de temperatura publica no tópico “temperature”, presente no BROKER. E os
dispositivos, laptop e aplicativo mobile estão assinados neste tópico. Os dispositivos
recebem os dados assim que eles são modificados em tempo real. A diferença entre o
HiveMQ e o eclipse.io, é o limite disponível gratuitamente. O HiveMQ possui uma
disponibilidade de dados, dispositivos e limite de acessos. Já o eclipse.io não tem esses
limites e é inteiramente grátis.
2.3. Comparações entre os principais protocolos da IoT
Para o desenvolvimento do estudo de caso, sobre automação residencial em cenário com

IoT, analisaremos alguns protocolos presentes no cenário atual. Expondo as vantagens e
desvantagens dos protocolos: REST, MQTT, CoAP, Bluetooth, Wireless, ZigBee.
Como apresentado na tabela a seguir.
Tipo Vantagens Desvantagens

➢ Apresentar vantagens para ser
utilizado em dispositivos com ➢ Na arquitetura REST, não existe
pouca capacidade de hardware um descritor de funcionamento
ou restrição de banda de rede do serviço.
REST disponível.
➢ Algumas implementações REST
➢ É a opção mais adequada para não suportam invocações e
construção de APIs Web para eventos assíncronos.
acesso a objetos do mundo real.
➢ Permitindo que dispositivos de ➢ Não adota uma abordagem

baixa potência possam interagir tradicional estilo cliente-
através de RESTfull. servidor em vez de uma
CoAP abordagem de brokers e foi
➢ São adequados para o uso em
projetado para ser utilizado
dispositivos com baixo consumo
sobre UDP.
de energia.
366
➢ Baixo consumo nos dispositivos ➢ São baixas taxas de

que não necessitam altas taxas de transferência o que mesmo para
processamento. aplicações simplórias o
➢ A segurança, Capacidade anti- inviabiliza em certas ações que
ZigBee interferência, velocidade de precisam de um taxa de
transmissão. transferências maiores.
➢Alto custo
➢Implementação do protocolo ➢Implementação de alta
802.15.4 complexidade
➢ Não é recomendado para o
➢ É ótima alternativa para estabelecimento conexões de
ambientes de negócios em que Internet.
Bluetooth as transferências de arquivos
➢ Transfere lentamente os
sem fio.
arquivos.
➢ Maior alcance de área com a ➢ Restrição de energia.

rede sem sio.
➢ A qualidade do serviço provido
Wireless
➢ Permitindo o acesso a uma rede ainda é menor.
sem estar conectado fisicamente.
➢ Transmite mensagens leves para ➢ Não há comunicação direta
a comunicação M2M. entre o dispositivo.
➢ Ideais para os dispositivos que ➢ Necessita de Broker servidor
MQTT exigem pouco poder de para fazer a conexão com a
processamento e maior Internet.
durabilidade. ➢ Baixo custo
Implementação do protocolo ➢ Fácil implementação
800.11
Após efetuar as comparações, o protocolo MQTT apresentou uma estrutura bem

simples e leve na sua aplicação, utiliza o modelo de publisher/subscriber e são
estabelecidas ou gerenciadas pelo servidor de Broker. Todos estes protocolos discutidos
nesta seção tem uma especificação de atuação em cenários diferentes ou similares. O
protocolo MQTT aplicado para este cenário proposto foi consideravelmente o mais
vantajoso pela simplicidade de implementação e funcionalidade em oferecer diversos
recursos simples ao enviar e receber as informações pelo Broker. Este protocolo propôs
a maior facilidade no recebimento do monitoramento do consumo dos dispositivos e
distribuição dos dados na rede.
3. Resultados
No cenário proposto com a utilização do protocolo MQTT, a solução implementada
permite ligar/desligar todos os eletrodomésticos automatizados e monitorar sensores
implantados neste ambiente de automação residencial. A utilização do protocolo MQTT
nesta automação, possibilitou a utilização diversos tipos de tecnologias como Arduino,
nodeMCU, Raspberry PI, Serviços na nuvem, aplicativos e entre outros. Os resultados
têm por objetivo demonstrar o funcionamento da rede desenvolvida para obter a maior
facilidade da realização dos testes com experimentos reais. O desenvolvimento desta
automação residencial trouxe uma série de benefícios, obtidas nas métricas realizadas
com base em testes práticos. Alguns desses benefícios no quesito distribuição de
367
informações obtidas através dos serviços na nuvem, e aplicativo disponível em

dispositivos mobile conectados à internet, utilizados nos testes, são:
• Maior poder de eficiência na distribuição de informações;

• Um protocolo leve e de fácil implementação;
Após alguns teste e experimentos realizados para verificação da confiabilidade e

validação da proposta. O desempenho da proposta e troca de informações entre os nós
de sensores IoT, instalados, no interior da casa, com a utilização do protocolo MQTT,
demonstrou ser bem eficaz no monitoramento através dos serviços solicitados pelos
clientes. Os testes demonstraram a confiabilidade da proposta apresentada na
automação residencial e obteve eficiência e poder de precisão na transmissão de dados
na rede local, desenvolvida no cenário proposto. Essas métricas foram obtidas através
de testes, onde cada dado enviado, foi apresentado acompanhado com o tempo de envio,
tamanho do arquivo e status do dados, para saber se chegou ou não ao destinatário.
4. Conclusão e Proposta de Trabalhos Futuros
Este trabalho apresentou um estudo sobre os principais modelos de protocolos para

troca de dados entre nós IoT presentes nos eletrodomésticos de uma casa automatizada.
Além disso, foi desenvolvido um estudo de caso utilizando o protocolo BROKER
MQTT. O projeto demonstrou ser um possível produto na implantação de casas
inteligentes e atingiu os seus objetivos pretendidos. Entre os objetivos estão, baixa
utilização de poder de processamento na comunicação entre os dispositivos, avaliação
da troca de dados em um cenário real e validação do funcionamento do protocolo
MQTT em uma automação residencial. Para a sua aplicação em grande escala, ainda
dependerá bastante de investimentos e testes mais aprofundados, como testes utilizando
os demais protocolos, comparando-os com o utilizado neste trabalho. Como trabalho
futuro, pretende-se estudar a utilização do protocolo 802.15.4 em redes mesh, como a
utilização de dispositivos como xBee, LoRa entre outros que permitem este tipo de
cenário. A segurança da rede é um ponto importante a ser estudado e implementado
futuramente. Tende-se a pesquisar e desenvolver um módulo de base para
gerenciamento da segurança dos dados trafegados na rede. Contudo, uma parte
importante a ser trabalhada nas pesquisas futuras é a adoção de inteligência artificial na
automação residencial no cenário IoT, como o uso de Machine Learning (Aprendizado
de máquina) e BigData, que juntos, fomentam uma melhor implementação de Smart
Home (Casa inteligente).
Referências
Babovic, Z. B., Protic, J., and Milutinovic, V. (2016). Web performance evaluation for
internet of things applications. In International Journal IEEE Access, pages 6974–6992.
IEEE, 4th edition.
Bhatt, A. and Patoliya, J. (2016). Cost effective digitization of home appliances for
home automation with low-power wifi devices. In International Conference on
Advances in Electrical, Electronics, Information, Communication and Bio-Informatics
(AEEICB16), pages 643–648. IEEE.
368
Grgic, K., Speh, I., and Hedi, I. (2016). A web-based iot solution for monitoring data
using mqtt protocol. In International Conference on Smart Systems and Technologies
(SST), pages 249–253. IEEE.
Javed, A., Larijani, H., Ahmadinia, A., Emmanuel, R., Mannion, M., and Gibson, D.
(2016). Design and implementation of cloud enabled random neural network based
decentralized smart controller with intelligent sensor nodes for hvac. In IEEE Internet
of Things Journal, pages 1–11. IEEE.
Lampkin, V., Leong, W. T., Rawat, S., Subrahmanyam, N., and Xiang, R. (2012).
Building smarter planet solutions with mqtt and ib wevsphere mq telemetry. In
ibm.com/redbooks, pages 1–270. IBM, 14th edition.
Li, R., Asaeda, H., and Li, J. (2017). A distributed publisher-driven secure data sharing
scheme for information-centric iot. In IEEE Internet of Things Journal, pages 1–13.
IEEE.
Priyanka, N. and Vasisht, A. (2015). Smart cities. In International Journal of
Engineering Science Invention, pages 43–49. IJESI, 4th edition.
Rani, S., Ahmed, S. H., Talwar, R., and Malhotra, J. (2017). Iomt: A reliable cross layer
protocol for internet of multimedia things. In IEEE Internet of Things Journal, pages1–
9. IEEE.
S., R. B., G., J. G. R., C., S. M., and Decouchant, D. (2011). Towards a uniform
sensorhandling scheme for ambient intelligence systems. In Electrical Engineering
Computing Science and Automatic Control (CCE), pages 1–6. IEEE.
Thatmann, D., Zickau, S., Forster, A., and Kupper, A. (2015). Applying attribute-based
encryption on publish subscribe messaging patterns for the internet of things. In IEEE
International Conference on Data Science and Data Intensive Systems, pages 556–563.
IEEE.
Triawan, M. A., Hindersah, H., Yolanda, D., and Hadiatna, F. (2016). Internet of things
using publish and subscribe method cloud-based application to nft-based hydroponic
system. In IEEE 6th International Conference on System Engineering and Technology
(ICSET), pages 98–104. IEEE, 6th edition.
Zanella, A., Bui, N., Castellani, A., Vangelista, L., and Zorzi, M. (2014). Internet of
things for smart cities. In IEEE Internet of things journal, pages 6–15. IEEE, 1th
edition.
369
Protótipo computacional para averiguar a evasão acadêmica

no curso de Bacharelado em Ciência da Computação
João Marcos C. Lima1 , Jeferson N. Soares 1 , Francisco A. R. Neto1 , José V. M. Sousa1
1
UESPI - Universidade Estadula do Piauı́ (UESPI)
Caixa Postal 64026-000 – Piripiri – PI – Brazil
{joaomarcosdeveloper,fricartent,josevigno}@gmail.com
Abstract. Academic evasion is a problem that affects many university courses in

Brazil and the world, bringing a major economic and social damage. However,
it is possible to predict this problem by the use of machine learning techniques
classifying which students are at risk of evasion enabling the university to take
steps to avoid this situation. This work aims to present a computational pro-
totype that investigate and determine some features associated with academic
evasion rates.
Resumo. A evasão acadêmica é um problema que atinge vários cursos de uni-

versidades no Brasil e no mundo, trazendo um grande prejuı́zo econômico e
social. Contudo, é possı́vel prever esse problema através de técnicas de Apren-
dizagem de Máquina classificando quais alunos que estão em risco de evasão
possibilitando que a universidade tome medidas para evitar essa situação. Esse
trabalho tem como objetivo apresentar um protótipo computacional que in-
vestigua e determina algumas caracterı́sticas associadas às taxas de evasão
acadêmica.
1. Introdução
O ensino superior é de grande importância para o estudante e a sociedade por ser consider-
ado como um dos fatores fundamentais para o desenvolvimento econômico, social e cul-
tural nas nações, em um contexto de crescente competição global[Ferreira 2009]. Porém,
com a facilidade de ingresso no ensino superior surgiram novos fatores de preocupação
nos ı́ndices de evasão, como o desempenho no ensino médio e as condições socioe-
conômicas[Ribeiro 2005].
Esse problema do grande número de evasão acadêmica é sofrido por várias as
universidades no Brasil e no mundo. Isso traz consequências que preocupam tanto o sis-
tema organizacional quanto os próprios alunos. São diversos os motivos que levam o
aluno a evasão do curso, desde a não identificação com o curso, até dificuldades no apren-
dizado em disciplinas especı́ficas. Cursos das áreas exatas como Ciências, Matemática
e Computação apresentam grandes ı́ndices de evasão, como aponta os dados do Instituto
Nacional de Estudos e Pesquisas Educacionais Anı́sio Teixeira INEP[Silva Filho 2007].
O INEP1 divulga em seu portal, dados estatı́sticos da educação superior, onde ex-
istem informações como dados gerais das instituições de ensino, matrı́culas, quantidade
de concluintes em cursos entre outros. Segundo os dados divulgados em 2014, há um
1
http://portal.inep.gov.br/censo-da-educacao-superior
370
maior número de Instituições de Ensino Superior (IES) privadas no Brasil, correspon-

dendo 87.4% das IES brasileiras, enquanto apenas 12.6% são públicas. Os dados ainda
mostram que apenas 13.1% dos alunos de IES privada e 12.3% dos alunos de IES pública
concluem o curso de graduação, totalizando 12.9% de todas as IES do Brasil.
Ainda segundo os dados do INEP, nos cursos de Bacharelado em Ciência da
Computação (BCC) apenas 9.4% dos alunos de IES públicas e 16.2% dos de IES privada
concluı́ram o curso de BCC. A tabela 1 mostra a quantidade de matriculas, alunos con-
cluintes e evadidos dos dois tipos de IES dos cursos de BCC. Diante disso, tratar a evasão
e a retenção de alunos tem sido um dos desafios do ensino superior[Sarker et al. 2010].
Table 1. Situação de alunos nas IES dos cursos de BCC, segundo dados do INEP
em 2014.
Matrı́culas Concluintes Evadidos

Pública 39742 3131 36611
Privada 83669 10585 73084
Total 123411 13716 109695
A Universidade Estadual do Piauı́(UESPI), a IES usada como base desse trabalho,

oferece em sua grade o curso de Bacharelado em Ciência da Computação (BCC), e assim
como acontece em outros cenários, esse curso apresenta um grande número de alunos
evadidos. Diante do problema apresentado, esse trabalho apresenta um protótipo com-
putacional que busca investigar os fatores que levam a evasão acadêmica utilizando a
base de dados dos alunos do BCC da UESPI. Tal análise é conduzida através de um
levantamento estatı́stico inicial sobre os componentes curriculares desses alunos, e em
seguida essas informações são utilizadas na criação de um modelo de aprendizagem de
máquina[Mitchell 1997] para classificar os alunos que concluı́ram o curso de BCC, e
aqueles que evadiram. Experimentos demonstram taxas de acurácia de até 91.19% na
classificação desses alunos.
Esse trabalho está organizado da seguinte forma: a seção 2 discute os trabalhos
relacionados a essa pesquisa. Seção 3 apresenta os dados utilizados nesse trabalho. Seção
4 mostra como ocorreu o processo de elaboração do protótipo. Em seguida, a seção 5
apresenta o experimento realizado para validação dos atributos propostos. Por fim a seção
6 encerra esse trabalho mostrando as considerações finais e propostas futuras.
Os trabalhos sobre evasão acadêmica têm ganhado um espaço maior no meio cientı́fico.
Essas pesquisas buscam determinar os principais fatores que causam a evasão a fim de
combater esse recorrente problema nas IES Brasileiras.
Couto e Dantas[Couto 2014] avaliaram por meio de técnicas de mineração de da-
dos os três cursos oferecidos pelo Departamento de Ciência da Computação da Univer-
sidade de Brası́lia, onde mostram em seu trabalho que há uma diferença nos motivos de
evasão entre homens e mulheres. Enquanto homens abandonam o curso por falta de de-
sempenho as mulheres acabam abandonando por falta de identificação com o curso. Os
autores realizaram análises estatı́sticas nas disciplinas dos blocos iniciais que são ofere-
371
cidas pelos departamentos de fı́sica, matemática e computação, onde afirmam que a taxa
de reprovação nessas disciplinas está ligado diretamente à evasão acadêmica.
No trabalho de Dekker et al. [Dekker 2009], foi realizado uma análise com os
dados dos alunos do curso de Engenharia Elétrica da Universidade de Eindhoven. Assim
como Couto e Dantas [Couto 2014] os autores levantaram estatı́sticas e identificaram que
os blocos iniciais são os que apresentam o maior número de evasão. Com as caracterı́sticas
levantadas, os autores utilizaram diversos algoritmos de Aprendizagem de Máquina com
a técnica Supervisionada e obtiveram acurácias de 75% a 80%.
Através de um levantamento estatı́stico, Palmeira e Santos [Palmeira 2014] iden-
tificaram maiores ı́ndices de evasão nos blocos 2, 3 e 4. Além disso os autores levantaram
outras caracterı́sticas relacionadas diretamente à evasão, como, sexo, escola de origem e
o desempenho médio em disciplinas obrigatórias. Essas informações foram aplicadas em
algoritmos de Aprendizagem de Máquina, e obtiveram acurácias de 83% a 90%.
Brito et al.[Brito 2015] utilizaram dados do histórico de alunos do curso de BCC,
da Universidade Federal da Paraı́ba. Os autores mostraram que o curso apresentou no
perı́odo de 2001 a 2013 três matrizes curriculares, porém com poucas diferenças. Eles
utilizaram cinco disciplinas do primeiro bloco em comum com os três currı́culos, onde
utilizaram as notas de cada uma. Com base no desempenho das disciplinas escolhidas os
autores iniciaram o treinamento dos algoritmos. Eles obtiveram acurácias de 84% a 86%,
assim como Couto e Dantas[Couto 2014], o de melhor desempenho foi o classificador
baseado em árvore de decisão.
Diferentemente de [Couto 2014], [Dekker 2009] e [Brito 2015], esse trabalho in-
vestiga também se a origem escolar do aluno afeta diretamente na decisão de continuar
ou não o curso de BCC. Além disso, esse trabalho obteve melhores taxas de acurácia em
relação aos trabalhos de [Dekker 2009], [Palmeira 2014] e [Brito 2015], apesar de terem
sido aplicados em ambientes diferentes do BCC da IES.
3. Levantamento Estatı́stico
Para definir os fatores de evasão é necessário um estudo em dados relacionados a diversos
aspectos do aluno de ensino superior(e.g. quais são as disciplinas mais cursadas, quais
possuiem maiores ı́ndices de reprovação/aprovação, em qual dos perı́odos do curso de
graduação essas disciplinas se encontram, etc.). Tendo em vista essa necessidade, foi
utilizado nesse trabalho a base de dados contendo informações de 2340 alunos dos cursos
de BCC da UESPI, do perı́odo de 2000 até 2015. É importante ressaltar que não foram
disponibilizadas informações de conteúdo restrito dos alunos, apenas dados relacionados
ao histórico acadêmico e informações de caráter público.
A primeira etapa da pesquisa foi analisar a base de dados e verificar como es-
tava organizada. Logo após iniciou-se um levantamento estatı́stico para descobrir quais
elementos influenciam diretamente na evasão acadêmica. É essencial esse levantamento
para validar os fatores que influenciam na evasão, pois alguns atributos acabam não sendo
relevantes na classificação.
Inicialmente, procurou-se verificar as informações a respeito dos alunos evadidos
e concluı́dos. Para a evasão têm-se os valores: matrı́cula cancelada, desistente, trans-
ferido, mudança de campus, acúmulo de curso, e inexistente matrı́cula especial. E para os
372
Figure 1. Índice de evasão por bloco.
alunos que concluı́ram o curso: graduado e aguardando colação. Os dados de alunos que
estavam cursando não foram utilizados nas demais fases.
Assim como [Couto 2014], [Dekker 2009], [Palmeira 2014] e [Brito 2015]
buscou-se investigar o ı́ndice de evasão de alunos por bloco, a fim de tentar definir quais
os elementos associados, se são disciplinas de computação, se são disciplinas de outros
cursos. A figura 1 mostra o ı́ndice de evasão por bloco. Observa-se que os três blocos
iniciais apresentam o maior número de evasão.
Figure 2. Índice de reprovação e aprovação na disciplina de Lógica de

Programação dos alunos evadidos e formados.
Diante dos ı́ndices apresentados na figura 1, é válido discutir as disciplinas cur-

sadas pelos alunos nos respectivos blocos. Contudo, desde a criação do curso até o ano de
2015 foram utilizados diversos currı́culos de disciplinas, e dessa forma, existem na base
de dados informações diferentes relativas às disciplinas cursadas por cada aluno. Com
isso foi levantado as 10 disciplinas mais cursadas em cada curso a fim de averiguar o
ı́ndice de aprovação e reprovação por aluno. As disciplinas mais cursadas dentro do BCC
com o respectivo bloco são: Lógica de Programação - Bloco I, Introdução a Computação
- Bloco I, Programação I - Bloco II, Cálculo I - Bloco I, Álgebra Linear I - Bloco I, Es-
373
tatı́stica - Bloco II, Programação II - Bloco III, Calculo II - Bloco II, Álgebra Linear II -
Bloco II e Inglês Instrumental - Bloco I.
As disciplinas que apresentaram os maiores ı́ndices de reprovação foram Lógica
de Programação, Cálculo I, Programação I, Cálculo II e Programação II. As figuras 2 e 3
mostram os ı́ndices de reprovação e aprovação nas disciplinas de Lógica de Programação
e Cálculo 1, apresentando também a situação acadêmica do aluno indicando a evasão ou
a conclusão.
Figure 3. Índice de reprovação e aprovação na disciplina de Cálculo I dos alunos

evadidos e formados.
Figure 4. Situação dos alunos por tipo de escola.
Como é possı́vel verificar em ambas disciplinas (figuras 2, e 3), o alto ı́ndice

de reprovação se relaciona com a quantidade de alunos evadidos. Em Lógica de
Programação, 566 alunos que reprovaram na disciplina de Lógica de Programação
acabaram desistindo de sua graduação, enquanto 57, que apesar de conseguirem a
aprovação, evadiram posteriormente. Já a disciplina de Cálculo 1, apesar de ter um alto
374
ı́ndice de reprovação em relação aos alunos que conseguiram concluir o curso, 385 estu-
dantes que reprovaram nessa disciplina optaram pela desistência do curso de BCC.
Outra informação importante e que foi pouco explorada por trabalhos da área é
se a evasão acadêmica possui alguma com o tipo de escola de origem do aluno, pública
ou privada. É sabido que existe uma diferença de qualidade na formação escolar no
ensino médio público e privado, porém esse não deve ser único fator para caracterizar essa
evasão. Esse mesmo alunado oriundo do ensino público são provavelmente indivı́duos que
possuem menor renda familiar, e podem acabar deixando o curso para outras atividades
em função da famı́lia. A figura 4 mostra um alto ı́ndice de evasão associado ao aluno
oriundo do ensino público.
4. Abordagem
Com base nas estatı́sticas estudadas, foi possı́vel identificar algumas caracterı́sticas que
impactam em determinar o perfil do aluno como evadido ou formado. Essas carac-
terı́sticas foram tratadas e serão utilizadas em algoritmos de Aprendizagem de Máquina
que classificarão a situação de cada aluno do BCC da IES. As caracterı́sticas utilizadas
são descritas na tabela 2.
Table 2. Vetor de atributos para classificação.
Atributo Descrição
Origem Escola de origem do aluno.
Nota Nota do aluno na disciplina
Repetiu Define se o aluno cursou mais de uma vez a disciplina
Situacao Reprovação ou aprovação do aluno na disciplina
TotalCursado Total de disciplinas cursadas do conjunto de dez disciplinas
Classe Define se o aluno é evadido ou formado
O atributo Origem descreve a o tipo de escola em que o aluno concluio seu ensino
médio, se foi escola pública, privada ou outro. Confome a figura 4 apresenta, acredita-se
que essa informação é valiosa para a análise da evasão acadêmica.
Os atributos Nota, Repetiu, e Situação são avaliados nas 10 disciplinas mais
cursadas apresentadas na seção 3. Nesse sentido o atributo Repetiu verifica a quantidade
de vezes que o aluno cursou a disciplina, sendo um incremento ou decremento de valor
2 dependendo da situação (aprovado ou reprovado). O atributo Nota recebe o valor da
última nota do aluno na disciplina. Por fim, o atributo Situação indica o status do aluno
na ultima vez que cursou a disciplina, sendo o valor 0 para reprovado ou 1 para aprovado.
Para diferenciar a quantidade de disciplinas cursadas por cada aluno foi adicio-
nando o atributo TotalCursado, que recebe o total das disciplinas que o aluno cursou do
total das 10 utilizadas no levantamento estatı́stico. Caso não haja registro de que o aluno
não tenha cursado a disciplina, ele receberá um valor único (9999) em todos os campos
(quantidade, nota, situação) para que se possa distinguir do aluno que cursou a disciplina.
375
5. Experimento
Para a condução do experimento desse protótipo foram utilizados dados 1761 alunos que
já concluı́ram o curso de BCC, ou evadiram do curso. Para a obtenção desses dados
foi criado uma aplicação em comunicação com o Banco de Dados disponibilizado pela
IES, possibilitando assim a extração dessas informações, tratando cada valor e gerando o
conjunto de dados com base nos atributos apresentados na seção anterior. Desse conjunto,
foram utilizadas 1201 informações pertencentes aos alunos evadidos, enquanto 560 dessas
informações são referentes aos alunos que obtiveram a conclusão do curso.
A técnica de Aprendizagem de Máquina utilizada foi a Supervisionada, esse
método permite que o processo aprenda com base em exemplos de dados que já pos-
suem os resultados esperados conhecidos [Mitchell 1997]. Os algoritmos utilizados para
realização do experimento foram as implementações de Support Vector Machine (SVM),
Multilayer Perceptron (MLP), Naive Bayes e Árvore de Decisão, contidos na ferramenta
Weka [Hall et al. 2009].
Para a avaliação desse experimento foi utilizada a métrica da acurácia, a qual foi
obtida através da Validação Cruzada com 10 folds. A tabela 3 apresenta os resultados obti-
dos no experimento. Como é possı́vel observar o modelo com melhor taxa de Acurácia
foi a MLP, obtendo 91,19%. O modelo SVM (90,35%) apresentou resultado próximo ao
da MLP, seguido do modelo Árvore de Decisão, que foi um pouco inferior aos modelos
anteriores, alcançando 89,21% de acurácia. Por fim, o modelo que apresentou o menor
resultado foi o Naive Bayes, conseguindo 80,69%.
Table 3. Situação de alunos nas IES, segundo dados do INEP em 2014.
Avaliação SVM Multilayer Perceptron Naive Bayes Árvore de Decisão

Acurácia 90,35% 91,19% 80,69% 89,21%
Apenar das classes do modelo estarem desbalanceadas, ou seja, há a presença de

classes majoritárias com frequência muito maior que as outras classes minoritárias, não
houve necessidade de usar alguma técnica de balanceamento de classes, já que a classe mi-
noritária teve um melhor desempenho do que a classe majoritária durante a classificação
[Hastie et al. 2009].
Nesse trabalho foi apresentado um protótipo para avaliar algumas caracterı́sticas associ-
adas à evasão acadêmica no curso de BCC. O problema da evasão vem afetando diversos
pontos econômicos e sociais, trazendo prejuı́zo aos cofres das IES, e aos cidadãos que
buscam vagas nas universidades que estão sendo desperdiçadas com a desistência de out-
ros candidatos.
O experimento conduzido obteve a melhor taxa acurácia com um algoritmo MLP,
alcançando 91,19%. Outros modelos como o SVM e a Árvore de Decisão obtiveram
resultados próximos à Rede Neural. Um dos passos seguintes desse trabalho é realizar
um experimento estatı́stico, utilizando testes, a fim averiguar qual desses modelos é o
superior.
376
Como é possı́vel observar, protótipo apresentado neste trabalho reforça a relação

entre o alto ı́ndice de evasão e a quantidade de alunos que ficam reprovados nas principais
disciplinas dos blocos iniciais. Apesar da alta taxa de acurácia aqui mostrada, é possı́vel
ainda explorar mais fatores associados à evasão acadêmica. Uma proposta de trabalho
futuro é aumentar a quantidade de atributos utilizada pelo protótipo, e estudar a relevância
desses atributos para a determinação das classes durante a execução dos algoritmos de
AM.
Por fim, destaca-se a utilidade desse trabalho como uma ferramenta inicial para
fazer a previsão de potenciais alunos que possam se evadir do curso de BCC. Dessa forma,
outro projeto futuro desse trabalho é analisar os alunos matriculados nos cursos de BCC
da IES, e tentar prever quais desses alunos são potenciais candidatos à evasão do curso.
References
Brito, D. M. (2015). Identificação de estudantes do primeiro semestre com risco de
evasÃ£o através de técnicas de data mining. In Congreso Internacional en Infomática
Educativa, volume 20, pages 459 – 463.
Couto, G.; Dantas, M. (2014). Utilizando mineração de dados na resolução de proble-
mas de gênero na UnB. Monografia, Instituto de Ciências Exatas da Universidade de
BrasÃlia, Brası́lia.
Dekker, G.; Pecheniskiy, M. V. J. (2009). Predicting students drop out: A case study. In
In Proceedings of the International Conference on Educational Data Mining.
Ferreira, J. B.; Machado, M. L. M. A. (2009). A importancia e a satisfação no ensino
superior: a perspectiva dos estudantes. In X Congresso da Sociedade Portuguesa de
Ciências da Educação. Instituto Politécnico de Bragança.
Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., and Witten, I. H. (2009).
The WEKA Data Mining Software: An Update, volume 11. ACM, New York, NY,
USA.
Hastie, T., Tibshirani, R., and Friedman, J. (2009). The elements of statistical learning:
data mining, inference and prediction. Springer, 2 edition.
Mitchell, T. M. (1997). Machine Learning. McGraw-Hill, Inc., New York, NY, USA, 1
edition.
Palmeira, L. B., S. M. P. (2014). Evasão no Bacharelado em Ciência da Computação da
Universidade de Brası́lia: análise e mineração de dados. Monografia - Instituto de
Ciências Exatas da Universidade de Brası́lia, Brası́lia.
Ribeiro, M. A. (2005). O projeto profissional familiar como determinante da evasÃ£o
universitária: um estudo preliminar. Revista Brasileira de Orientação Profissional,
6:55 – 70.
Sarker, F., Davis, H., and Tiropanis, T. (2010). A review of higher education challenges
and data infrastructure responses.
Silva Filho, R. L. L. e. a. (2007). A evasão no ensino superior brasileiro. Cadernos de
Pesquisa, 37:641 – 659.
377
Avaliação Comportamental em DoE do Protocolo PRoPHET

em Redes Veiculares Tolerantes a Atrasos
Jaqueline C. Sousa, Leonardo A. G. Silva, Pablo A.Vieira,
Luciana M. Carvalho
1
Universidade Federal do Piauı́ (UFPI) - Picos, PI - Brasil.
[email protected],[email protected]
Abstract. Vehicular Networks are becoming increasingly common in mobile

computing due to their potential use to solve everyday problems. These networks
are made up of vehicles equipped with wireless communication devices. This
work analyzes the performance of the Doe-structured PRoPHET protocol, ap-
plying a combinatorial approach with different factors and levels, testing its
message delivery averages in the vehicle-to-vehicle (V2V) architecture. The re-
sults showed that the protocol can meet the needs of the possible alert applica-
tions, if an adequate choice of node speed, packet size and buffer is made.
Resumo. As Redes Veiculares estão se tornando cada vez mais comuns na área
da computação móvel. A sua popularidade se dá por conta da sua potencial
utilização na solução de diversos problemas cotidianos. Essas redes são cons-
tituı́das por veı́culos equipados com dispositivos de comunicação sem fio. Este
trabalho analisa o desempenho do protocolo PRoPHET estruturado em DoE
(Desing of Experiment), aplicando uma abordagem combinatória com fatores
e nı́veis diferentes, testando suas médias de entrega de mensagens na arquite-
tura V2V (Vehicle-to-vehicle). Os resultados mostraram que o protocolo pode
atender as necessidades das possı́veis aplicações de alerta, se feita uma escolha
adequada de velocidade dos nós, tamanho dos pacotes e buffer.
1. Introdução
A crescente necessidade de comunicação promove a busca por maneiras mais eficientes
de realizá-la . Com o desenvolvimento da tecnologia da informação, as redes de compu-
tadores tornaram-se uma parte muito importante da comunicação moderna.
Com o avanço das pesquisas nessa área, criou-se a rede móvel Ad Hoc (Mobile
Ad Hoc Network - MANETs), que possibilita formar uma rede em áreas onde não há uma
infra-estrutura pré-definida de comunicações, ocasionando melhorias na acessibilidade e
mobilidade da rede [de Sousa and Soares 2015].
A partir das MANETs, surgiram as Redes Veiculares Ad hoc (Vehicular Ad Hoc
Network - VANETs). As Redes Veiculares estão ligadas diretamente a segurança no
trânsito, auxiliando os condutores nas estradas. Elas também são usadas em sistemas
de localização, entretenimento e suporte ao socorro de vı́timas em locais de difı́cil acesso
[de Sousa and Soares 2015].
378
Diariamente são noticiados inúmeros acidentes de trânsito, que na sua maioria

poderiam ser evitados. Segundo dados do Portal Brasil, em 2016, ocorreram 20.994 aci-
dentes graves em rodovias federais1 . As VANETs podem prover aplicações que focam
na segurança do condutor, e fornecem maior eficiência do tráfego dos veı́culos nas vias
públicas.
Nesse cenário de comunicação veicular, este trabalho analisa o desempenho do
protocolo PRoPHET (Probabilistic Routing Protocol using History of Encounters and
Transitivity). Tal análise é baseada em DoE (Desing of Experiment) e aplica uma aborda-
gem combinatória com diferentes fatores e nı́veis a fim de identificar a correlação entre
recursos e adversidades. Nossa proposta oferece um guideline para seleção de parâmetros
em simulação de VANETs.
Um experimento planejado, ou seja, um DOE, é um teste, ou série de testes, no
qual são feitas mudanças propositais em algumas variáveis de entrada de um processo, de
modo a podermos observar e identificar mudanças correspondentes na resposta. O objeto
de estudo pode ter uma ou mais caracterı́sticas de qualidade observáveis. Algumas das
variáveis do processo de experimento são controláveis, enquanto outras não. Todas essas
caracterı́sticas devem ser analisadas para o planejamento do experimento, incluindo ainda
a especificação do objetivo do estudo.
As redes veiculares necessitam de uma estratégia eficiente de disseminação de
mensagens capaz de maximizar o número de veı́culos receptores, diminuir o tempo de en-
trega da mensagem[Soares et al. 2013]. Diversos protocolos são utilizados nessas redes,
neste trabalho adotamos o PRoPHET devido à sua ampla adoção na literatura, apresen-
tando resultados promissores.
Em análise, [Choudhary et al. 2016] concluı́ram que o custo de transmissão mais
baixo para a entrega de um pacote em termos de despesas gerais de rede e consumo de
energia é conseguido pelo PRoPHET, pois este envia pacotes apenas para nós confiáveis,
além disso, ele se mostrou o roteador mais adequado para a transferência de dados, cor-
roborando nossa escolha.
O PRoPHET será avaliado através de simulação, onde a taxa de entrega na ar-
quitetura V2V (Vehicle-to-vehicle) será analisada. Tal análise permite avaliar em quais
situações o protocolo se comporta de forma negativa ou positiva para possı́veis envios de
pacotes, a partir disso é possı́vel selecionar melhores métricas para utilização de recursos
para as VANETS. Este trabalho está organizado como descrito a seguir. A Seção 2 apre-
senta o Background, relacionando diversos aspectos das VANETS. Na Seção 3 os Traba-
lhos Relacionados são apresentados. O Projeto e Descrição do Ambiente de Simulação é
explanado na Seção 4. As avaliações são discutidas na Seção 5 e, por fim, as conclusões
são apresentadas.
2. Background
Ao longo desta seção diversos aspectos relacionados às VANETs são apresentados, como
suas dificuldades e tecnologias utilizadas em sua implementação, como estão dispostas as
suas estruturas e também os aspectos do protocolo PRoPHET.
1
http://www.brasil.gov.br/defesa-e-seguranca/2017/02/mortes-em-rodovias-federais-cairam-6-8-em-
2016
379
2.1. Redes Veiculares: Estruturas e Implantação

Os veı́culos são os principais componentes de uma rede veicular, os chamados nós (termi-
nais de comunicação). Estes possuem uma interface de comunicação sem fio para enviar,
receber ou trocar informações [Wangham et al. 2014].
A arquitetura das redes veiculares define a forma como os nós se organizam e se
comunicam. Existem três arquiteturas: o modo Ad hoc puro realiza comunicação apenas
de veı́culo para veı́culo (V2V), e tem como principal vantagem o baixo custo por ser
mais simples. Entretanto, a sua principal desvantagem está na conectividade da rede, que
depende da densidade e da mobilidade dos veı́culos. Já o modo infraestruturado (V2I) é
caracterizado pela comunicação entre veı́culos e infraestruturas localizadas nas margens
das vias (Road Side Units - RSUs), e tem como vantagem uma alta conectividade da
rede, porém o custo para implantação e manutenção das RSUs se torna elevado. O modo
hı́brido, caracterizado pela existência dos dois tipos de comunicações – V2V e V2I –
(Vehicle to Everything - V2X), busca obter o melhor das duas arquiteturas [Soares et al. ].
A Figura 1 apresenta essas três arquiteturas.
Figura 1. Esquema de comunicação em uma rede veicular [Wangham et al. 2014].
2.2. Protocolo PRoPHET

O PRoPHET é um protocolo de roteamento DTN (Delay Tolerant Netowork) com o obje-
tivo de usar o conhecimento obtido de encontros anteriores com outros nós para otimizar
a entrega de pacotes [Patel and Shah 2016]. Podemos analisar seu funcionamento mais
detalhadamente na Figura 2.
Figura 2. Princı́pio de funcionamento do histórico de contatos entre nós e da

propriedade de transitividade do protocolo PRoPHET [Soares et al. 2013]
O PROPHET é um protocolo de comunicação unicast (direção única) para Redes

Tolerantes a Atrasos. O protocolo PRoPHET (PP) usa o histórico de encontros entre
380
nós e transitividade para estimar a probabilidade de os nós se encontrarem e explorar a

mobilidade de alguns nós para levar as mensagens até mais perto dos seus destinos. A
métrica de previsibilidade de entrega é atualizada em cada contato entre nós, e é utilizada
para tomar decisões de encaminhamento. Um nó a apenas replica um agregado para um
nó b encontrado se a previsibilidade de entrega for superior em b. Tal abordagem visa
tentar limitar a replicação excessiva de agregados [Soares et al. 2013].
Nesta seção, podemos analisar algumas caracterı́sticas acerca de trabalhos relacionados
no contexto das VANETs. A Tabela 1 apresenta os critérios analisados, confrontando suas
contribuições, diferenças e semelhanças com relação com presente trabalho.
Tabela 1. Trabalhos Relacionados

DoE
(Desing
Trabalho (Ano) Principais Contribuições
of
Experiments)
Avaliação da Versão Diferente
[Sok et al. 2013] NÃO
PRoPHET (DiPRoPHET)
[Ayub et al. 2014] Novo Protocolo de Roteamento Chamado DF NÃO
Investigar o Desempenho dos Protocolos
[Shinko et al. 2015] NÃO
First Contact, PRoPHET eSpray-and-Wait.
[Choudhary et al. 2016] Análise do Impacto do Tamanho do Buffer NÃO
Análise Combinatória Em DoE com Nı́veis
Nosso Estudo (2017) e Parâmetros Diversos Na Investigação SIM
do Comportamento do PRoPHET
[Sok et al. 2013] realizaram uma avaliação de desempenho entre o PRoPHET tra-
dicional e o DiPRoPHET, versão modificada do PRoPHET tradicional proposto através
de uma simulação NS2 (Network Simulator – 2). No artigo de [Ayub et al. 2014] foi
proposto um protocolo de roteamento chamado DF (Delegated Forwarding) ++ que cal-
cula o valor da qualidade do nó com base no modelo probabilı́stico usado no proto-
colo PRoPHET e encaminha a mensagem para o nó atual pela computação adaptativa do
espaço de buffer disponı́vel. No trabalho de [Shinko et al. 2015] investigou-se o desem-
penho dos protocolos First Contact, PRoPHET e Spray-and-Wait em um cenário de en-
caminhamento da Rede Veicular Tolerante a Atrasos (VDTN), os padrões de mobilidade
dos veı́culos são gerados por SUMO (Simulação de Mobilidade Urbana) e como simula-
dor de protocolo de comunicação foi usado o ONE (Ambiente de Rede Oportunı́stico).
No trabalho de [Choudhary et al. 2016] analisaram o impacto do tamanho do buffer na
probabilidade de entrega, número de relés e relação.
O presente trabalho se destaca em relação aos trabalho correlatos devido ao uso
do método estatı́stico DoE. A grande contribuição do DoE está na análise combinatória
que permite investigação mais profunda sobre nı́veis diferentes relacionados a parâmetros
ou recursos diferentes que podem ser modificados. Isso possibilita um aperfeiçoamento
na criação e no desenvolvimento de novas métricas sobre o comportamento do protocolo
PRoPHET ou outros protocolos VDTNs.
381
4. Descrição dos Testes na Simulação e Avaliação

Esta seção documenta o desempenho das estratégias de roteamento propostas em termos
de taxa de entrega de mensagens (pacotes) no simulador ONE. Ele é capaz de gerar movi-
mentos de nós usando diferentes modelos de movimento, roteando mensagens entre nós
com vários algoritmos de roteamento DTN e tipos de remetente e receptor. O ONE trans-
fere mensagens entre os nós usando vários algoritmos DTN, além de permitir visualizar a
mobilidade e a passagem da mensagem em tempo real [Shinko et al. 2015].
A análise combinatória foi realizada com 27 configurações de experimentos, ou
seja, todos os fatores foram combinados entre si, na forma de (3x3x3), onde cada execução
se repetiu 30 vezes, visando obter mais confiança nos experimentos, totalizando 810
repetições.
Como escolha de fatores que influenciam no comportamento de uma rede vei-
cular, foram escolhidos aqueles que são os mais comuns e desafiadores na área de re-
des veiculares tais são: velocidade dos nós, tamanho do buffer dos nós, e tamanho das
mensagens (pacotes). Os demais parâmetros foram deixados em default, pois o arquivo
de configuração do ONE conta com parâmetros pré-configurados para testes primários,
como por exemplo, tempo de simulação em segundos, números de interface dos nós, en-
tre outros.
Os nı́veis e fatores foram escolhidos com o objetivo de fazer uma análise combi-
natória entre eles, observando qual a relação na entrega dos pacotes e perda dos pacotes.
Está disposta na Tabela 2 os nı́veis e os parâmentos em DoE para a realização dos testes.
Tabela 2. Design da Experiência

Fatores
Velocidades Tamanhos de Buffers Tamanhos de Pacotes
10 km/h- 30 km/h 5 MB 150 Kb - 250 Kb
Nı́veis
30 km/h- 40 km/h 15 MB 250 Kb - 450 Kb
40 km/h- 50 km/h 25 MB 450 Kb - 1 MB
4.1. Resultados
Esta seção discute as avaliações e conclusões em relação aos resultados obtidos. Neste
trabalho, o desempenho do protocolo é mensurado pela taxa de entrega, desse modo,
quanto maior o número de pacotes entregues com sucesso, mais eficiente será para um
sistema veicular.
Os dados estão apresentados como médias ajustadas para cada nı́vel de avaliação.
O número de mensagens criadas foram 362 em todas as execuções para serem enca-
minhadas aos seus destinos. O numero de hosts emissores de mensagens iniciava-se
com 40 (número mı́nimo padrão para o simulador ONE) e aumentava-se 5 hosts a cada
execução,para que fossem analisados de forma mais eficiente, tendo em vista algumas
limitações do ONE, desse modo, segundo [Villares et al. 2013], estes resultados acabam
sendo otimistas quando comparados à situações reais. Na Figura 3 são mostrados os
resultados relativos ao comportamento do protocolo com os fatores analisados.
• Comportamento das Velocidades
382
Figura 3. Gráfico de Efeito
No nı́vel 1 (velocidades pequenas entre 10 km/h e 30 km/h) a média de mensagens

entregues se manteve entre 175 e 176. Para o nı́vel 2 (velocidades de 30 km/h a
40 km/h) a média de entrega se manteve entre 177 e 178. Já o nı́vel 3 (velocidades
entre 40 km/h e 50 km/h) a média das entregas teve um aumento, variando entre
179 e 180.
• Comportamento dos Buffers
Para o nı́vel 1 (buffers pequenos de 5 MB) a média de entrega de mensagens se
manteve entre 177 e 178. Para o nı́vel 2 (buffers razoáveis de 15 MB) as entregas
foram as mais positivas entre 179 e 180. No nı́vel 3 (buffers grandes de 25 MB)
as entregas se mantiveram instáveis, entre 176 e 177.
• Comportamento dos Pacotes
No nı́vel 1 (pacotes pequenos entre 150 Kb e 250 Kb) obtivemos o melhor re-
sultado nas entregas, permanecendo entre 179 e 180 mensagens. Para ambos nos
nı́veis 2 (pacotes razoáveis entre 250 kb e 450 kb) e nı́vel 3 (pacotes grandes entre
450 Kb e 1 MB) a taxa caiu de maneira semelhante, entre 175 e 176.
Podemos notar que para todos os fatores do nı́vel 2, manteve-se uma instabilidade
maior em relação aos outros nı́veis. O nı́vel 1 se mostrou melhor com relação ao tamanho
dos pacotes. Já o nı́vel 3 teve um bom resultado apenas para velocidades altas. Adequando
as caracterı́sticas do nı́vel 1 ao nı́vel 2 é possivel estabelecer uma combinação satisfatória
para o aumento da taxa de entrega. O tamanho do buffer razoável, somado a tamanhos
de pacotes pequenos e velocidades medianas influenciaram a instabilidade do nı́vel 2.
Notamos que nı́vel 1 não obteve desempenho melhor em relação ao nı́vel 2, pelo fato do
tamanho do buffer ser pequeno.
Quanto mais espaço de armazenamento para os agregados, mais chances há de
não virem a ser descartados pelo estouro do buffer, um dos grandes problemas das redes
veiculares, porém o tamanho dos pacotes tem influência direta na entrega das mensagens,
quanto maiores os tamanhos dos pacotes, mais irão lotar o buffer e maior será sua de-
mora em ser transmitido, caso não sejam entregues, pois logo são descartados e a taxa
diminui. Tal caracterı́sticas levou o nı́vel 3 a ter um resultado insatisfatório comparado
aos demais. Cabe ressaltar que a simulação foi realizada em um tempo equivalente a 3
horas de relógio para cada execução em ambiente real urbano em um mapa idêntico ao da
383
cidade de Heisinki Capital da Finlândia. Na Figura 4 mostramos os resultados a cerca da

comparação entre os nı́veis e seu devidos fatores selecionados.
Figura 4. Gráfico de Interação
Na Figura 4 (a), na interação dos nı́veis de velocidades e buffers notamos que a en-
trega foi mais bem sucedida nos nı́veis 1 em que a velocidade e o buffers eram razoáveis.
Os casos medianos foram os de nı́veis 2, em que as velocidades são baixas e buffers pe-
quenos, mantendo um crescimento constante na entrega das mensagens. Os piores casos
foram os de nı́veis 3, com velocidades altas e tamanhos de buffers grandes. Possivelmente
o tempo de contato foi o causador dessa caracterı́stica, pois se não há tempo suficiente
para manter o enlace da troca de dados, as mensagens não serão passadas com sucesso
pela rede.
Na Figura 4 (b) está a interação da velocidade com tamanho de pacote. Para os
melhores casos estão os de nı́veis 2, com velocidades e buffers razoáveis, mantendo uma
crescente e constante entrega de mensagens. Os casos intermediários foram os nı́veis
1, com velocidades pequenas e pacotes pequenos. Os piores casos foram os de nı́veis
3 com velocidades e os pacotes maiores, tal caracterı́stica reafirma o que foi relatado
anteriormente na análise do gráfico de efeito na Figura 3, o gráfico de efeito demostrou
que o tempo de contado influencia a entrega, e agora somado a tamanhos de pacotes
grandes, a influência fica maior.
Na interação do buffer e tamanho de pacote, na Figura 4 (a), os melhores casos
foram para os de nı́veis 1, com velocidades pequenas e buffers pequenos, porém aceitáveis
para o contexto das VANETs. Os casos intermediários (nı́vel 2) foram com buffer e
tamanho razoáveis. Nos piores casos ficaram os de nı́veis 3, em que os tamanhos de
buffer e pacotes são grandes.
5. Conclusão
Podemos concluir que os tamanhos dos pacotes influenciam diretamente na interação com
o buffer caso o seu tamanho seja grande ele continuará negativando a entrega de pacotes.
Como consequência a média de entrega de mensagens não terá aumento, faz-se necessário
pacotes com tamanhos um pouco reduzidos como os do nı́vel 2. Notamos também que
tamanhos de pacotes grandes relacionadas a velocidades altas, têm influência negativa no
384
uso do recurso do buffer, ou seja, expandir seu tamanho não é a principal medida para
aumentar a média da entrega.
As velocidades altas em um meio VDTN ocasionam um número maior de
distâncias percorridas nas vias em menor tempo, isto influencia diretamente em que mais
nós sejam alcançados para o encaminhamento de pacotes, porém isso pode ocasionar pro-
blemas na entrega de mensagens, pois quanto maiores são as velocidades, menos tempo
de contato existirá entre os nós. Como o protocolo PRoPHET se baseia em número de
contados entre os nós, indiferentemente do tempo de contato entre eles, quanto maiores
são as velocidades, menor é o tempo de contado entre os nós, logo quanto maiores forem
os pacotes mais difı́cil é sua transferência pela rede.
A avaliação do método estatistico DoE mostrou-se poderosa na análise das carac-
teristicas particulares a cada nı́vel submetido. Para trabalhos futuros pretendemos realizar
novas análise com outras variáveis dependentes, como a latência ou Throughput, além de
executar uma avaliação do PRoPHET integrado a uma aplicação de emergência.
Referências
Ayub, Q., Zahid, M. S. M., Rashid, S., and Abdullah, A. H. (2014). Df++: An adaptive
buffer-aware probabilistic delegation forwarding protocol for delay tolerant network.
Cluster computing, 17(4):1465–1472.
Choudhary, N., Mittal, K., Kota, K. D., Nagrath, P., and Aneja, S. (2016). Analyzing and
designing energy efficient routing protocol in delay tolerant networks. CSI transactions
on ICT, 4(2-4):285–291.
de Sousa, R. S. and Soares, A. C. B. (2015). Estimativa e sinalizaç ao de congestiona-
mentos de tráfego através de redes veiculares v2v.
Patel, D. and Shah, R. (2016). Improved prophet routing protocol in dtn.
Shinko, I., Oda, T., Spaho, E., Kolici, V., Ikeda, M., and Barolli, L. (2015). A simulation
system based on one and sumo simulators: Performance evaluation of first contact,
prophet and spray-and-wait dtn protocols. In Broadband and Wireless Computing,
Communication and Applications (BWCCA), 2015 10th International Conference on,
pages 137–142. IEEE.
Soares, R., Galeno, S., and Soares, A. Simulação de redes veiculares.
Soares, V. N., Dias, J. A., Isento, J. N., and Rodrigues, J. J. (2013). Protocolos de en-
caminhamento para redes veiculares com ligações intermitentes. In CRC 2012: 12a
Conferência sobre Redes de Computadores, pages 77–84.
Sok, P., Tan, S., and Kim, K. (2013). Prophet routing protocol based on neighbor node
distance using a community mobility model in delay tolerant networks. In High Per-
formance Computing and Communications & 2013 IEEE International Conference on
Embedded and Ubiquitous Computing (HPCC EUC), 2013 IEEE 10th International
Conference on, pages 1233–1240. IEEE.
Villares, T. L., Campos, C. A. V., and Viana, A. C. (2013). A influência de nós especiais
na entrega de mensagens nas redes tolerantes a atrasos e interrupções. WRA, 13:44–57.
Wangham, M. S., Nogueira, M., Fernandes, C. P., Paviani, O., and da Silva, B. F. (2014).
Segurança em redes veiculares: Inovações e direções futuras.
385
Um Modelo de Otimização Multi-Objetivo de Demand

Response para Programação de Carga Residencial
Igor Rafael S. Silva1 , Jaclason M. Veras2 , Ricardo A. L. Rabêlo1 , Plácido R. Pinheiro2
1
Departamento de Computação
Universidade Federal do Piauı́ (UFPI) – Teresina – PI – Brasil
2
Programa de Pós-Graduação em Informática Aplicada
Universidade de Fortaleza (UNIFOR) – Fortaleza, CE – Brasil
[email protected],{jaclason,placidrp}@gmail.com,[email protected]
Abstract. This paper presents a multi-objective optimization model for residen-

tial Demand Response (DR) based on real-time electricity price (RTP), in order
to minimize the cost of electricity associated with consumption and the discom-
fort caused in the consumer. The proposed model was formalized as a nonlinear
programming problem bound to a set of constraints associated with energy con-
sumption and operational aspects related to residential appliance categories.
The results obtained by the non-dominated classification algorithm II (NSGA-
II) allow the user to make a decision on the reduction of the required cost, in
order to seek adequacy to the amount of inconvenience tolerated by the consu-
mer.
Resumo. Este trabalho apresenta um modelo de otimização multi-objetivo para

a Demand Response (DR) residencial baseando-se no preço da energia elétrica
em tempo real (RTP), a fim de minimizar tanto o custo da eletricidade asso-
ciada ao consumo quanto o desconforto causado no consumidor. O modelo
proposto foi formalizado como um problema de programação não-linear sujeito
a um conjunto de restrições associadas ao consumo de energia e aspectos ope-
racionais relacionados às categorias de aparelhos residenciais. Os resultados,
obtidos pelo Non-Dominated Sorted Genetic Algorithm II (NSGA-II), permitem
ao usuário tomar uma decisão sobre a redução do custo exigido, de forma a
buscar adequação à quantidade de inconveniência tolerada pelo consumidor.
1. Introdução
A Demand Response (DR), como parte da Smart Grid (SG), tende a estimular os
consumidores finais a modificarem seu consumo energético em resposta às mudanças
ocorridas no preço da eletricidade ao longo do tempo e, também, durante horários de
picos do sistema. Assim, a DR permite que as concessionarias de energia elétrica
ofereçam incentivos (descontos ou créditos na conta de energia) destinados a impulsi-
onar a redução do consumo energético em horários que os preços de mercados estão
elevados ou quando a confiabilidade da rede é comprometida com a sobrecarga do
sistema. Dessa maneira, o aumento excessivo da demanda de energia elétrica fez o
uso da DR ser interessante aos consumidores e às concessionárias de energia elétrica
[Parvania and Fotuhi-Firuzabad 2010];[Siano 2014].
386
No entanto, o gerenciamento e o planejamento do consumo energético residencial

se torna complexo devido a fatores como a falta de experiência do consumidor para lidar
com a programação diária e as particularidades de operações de cada aparelho residencial.
Diante disso, um modelo de otimização multi-objetivo é proposto para o gerenciamento
do consumo de energia elétrica residencial, minimizando os custos da eletricidade sem
modificar o conforto/satisfação dos consumidores finais, com o intuito de melhorar a
confiabilidade e a eficiência do sistema elétrico de potência (SEP).
A proposta apresentada neste artigo foi formulada como um problema de
programação não-linear que considera as diversas restrições associadas ao consumo
energético (limites inferior e superior da carga para cada intervalo de tempo, limites de
rampa, consumo mı́nimo relacionado ao horizonte de tempo) e os aspectos vinculados
ao conforto/satisfação dos consumidores finais (restrições operacionais das categorias de
aparelhos residenciais). Nas simulações, devido a sua eficiência com problemas de natu-
reza combinatória [Deb et al. 2002], foi utilizado o Non-Dominated Sorted Genetic Algo-
rithm (NSGA-II) para a obtenção dos resultados do problema multi-objetivo.
As contribuições relacionadas ao uso do modelo proposto incluem: a) a
determinação de uma programação otimizada para operar diferentes categorias de apa-
relhos residenciais em horizontes de tempo com tamanho variável; b) a representação de
diferentes aspectos (localização geográfica, temperatura climática, preferências dos con-
sumidores e o preço por hora da eletricidade) e suas implicações no consumo de energia
elétrica das residências; c) avaliação da inconveniência, de modo a permitir ao consumi-
dor tomar a decisão de aderir ou não ao programa DR.
Este trabalho está disposto na seguinte forma: a Seção 2 discute o problema, o
modelo de otimização e o algoritmo NSGA-II; a Seção 3 apresenta um estudo de caso
que mostra o cenário de teste e os resultados numéricos obtidos na simulação que aplica
o modelo multi-objetivo; e, por fim, a Seção 4 descreve as principais contribuições deste
trabalho e trabalhos futuros.
2. Definição do Problema e Modelo de Otimização

A operação de diferentes categorias de aparelhos residenciais precisa ser administrada
para minimizar o custo da eletricidade associado ao consumo em um cenário com preços
variáveis de energia elétrica no decorrer de um horizonte de tempo. Assim, há a necessi-
dade de um método de programação de carga que exija pouca atenção dos consumidores
em sua configuração e manutenção que permite a comparação dos custos e benefı́cios
dos diferentes agendamentos de uso dos aparelhos residenciais. Neste sentido, o plane-
jamento das cargas pode ser feito de forma automática, por meio do uso de técnicas de
otimização, por exemplo.
2.1. Modelo de otimização multi-objetivo

O modelo multi-objetivo deste trabalho é composto por duas funções de minimização,
sendo uma com o objetivo de minimizar o custo associado ao consumo da eletricidade,
chamada de f1, e uma outra visando minimizar a inconveniência do consumidor final,
chamada de f2. A função que visa a minimização do custo associado ao consumo de
energia elétrica considera um horizonte de tempo T , que pode ser definido pelo con-
sumidor (por exemplo, 24 horas) com discretização por hora, a potência (em kW) e o
387
consumo energético (em kWh) de cada aparelho residencial por intervalo de tempo. Fo-
ram usadas diferentes categorias de aparelhos escolhidos com base nos perfis de con-
sumo de carga residencial criados por meio da ferramenta Load Profile Generator (LPG)
[Pflugradt 2016]. Tais perfis foram desenvolvidos para compor uma base de dados com
os diferentes cenários de consumidores residenciais objetivando uma análise destinada a
aplicabilidade e a eficácia da DR. Na equação (1) é apresentada a função f1.
N
X T
X
M inimize Ei (P rt ∗ DSAt,i )2 (1)
i=1 t=1
onde N representa o número de aparelhos residenciais; Ei (i = 1, . . . , N ) corresponde ao

vetor com o consumo de energia elétrica dos aparelhos residenciais i quando estiver em
operação; T indica o horizonte de tempo; P rt corresponde ao preço da energia elétrica no
intervalo de tempo t; DSA (Configuração Diária dos Aparelhos) corresponde à matriz de
programação das cargas com a seguintes configuração:
(
1, se aparelho i ligado no tempo t,
DSAt,i =
0, caso contrário.
sujeito as diversas restrições a seguir.
N
X
dmin
t ≤ DSAt,i ∗ Pi ≤ dmax
t , ∀t=1,...,T (2)
i=1
N
X
(DSAt,i − DSAt+1,i ) ∗ Pi ≤ rD , ∀t=1,...,T −1 (3)
i=1
N
X
(DSAt+1,i − DSAt,i ) ∗ Pi ≤ rU , ∀t=1,...,T −1 (4)
i=1
N X
X T
DSAt,i ∗ Ei ≥ mdc (5)
i=1 t=1
T
X
DSAt,i ≥ Reqi , ∀i ∈ AI (6)
t=1
T ReqiY
X +(q−1)
DSAt,i ≥ 1, ∀i ∈ AII (7)
q=1 t=q
ETi
X
DSAt,i ≥ Reqi , ∀i ∈ AIII (8)
STi
388
A restrição (2) estabelece limites (mı́nimo e máximo) para os nı́veis de carga em

cada intervalo de tempo onde Pi (i = 1, . . . , N ) é o vetor com a potência (em kW) de cada
aparelho residencial. As restrições (3) e (4) definem os limites de rampa máximo/mı́nimo
por intervalo de tempo. A restrição (5) estabelece um consumo mı́nimo (mdc) diário de
energia elétrica. As restrições (6-8) estão relacionadas aos tipos de aparelhos residen-
ciais especificados por suas particularidades operacionais [Chen et al. 2012], sendo eles:
interruptible e deferrable (AI ); uninterruptible e deferrable (AII ); e, uninterruptible e
non-deferrable (AIII ). Uninterruptible significa que uma tarefa não pode ser interrom-
pida até que seja concluı́da. Non-deferrable significa que uma tarefa deve ser iniciada
no primeiro intervalo de tempo do perı́odo requerido para seu funcionamento. Com base
nessas definições, pode-se especificar as restrições que lidam com as diferentes categorias
de aparelhos residenciais AI , AII e AIII .
A restrição (6) define que o inı́cio da operação dos aparelhos residenciais AI pode
variar ao longo do horizonte de tempo T desde que Reqi seja respeitado. A restrição (7)
estabelece que o inı́cio da operação do aparelho residencial do tipo AII pode ser adiado
no horizonte de tempo T mas, uma vez que seu funcionamento foi iniciado, não pode
ser interrompido. Por fim, a restrição (8) visa garantir que, entre o tempo definido pelos
consumidores para inı́cio (STi ) e fim (ETi ) da operação dos aparelhos residenciais do tipo
AIII , o seu funcionamento seja ininterrupto durante o tempo requerido Reqi no horizonte
de tempo T , onde AI , AII e AIII são os conjuntos de ı́ndices de aparelhos das categorias
interruptible e deferrable, uninterruptible e deferrable, uninterruptible e non-deferrable
respectivamente.
A função f2 avalia como as modificações de uso dos aparelhos residenciais podem
interferir no conforto/satisfação dos consumidores finais, minimizando a inconveniência.
Este cálculo compara o consumo de energia elétrica real (Baseline) no intervalo de tempo
t para o aparelho residencial i da famı́lia analisada por meio da ferramenta LPG e o con-
sumo (OP T ) sugerido pelas técnicas de otimização utilizadas nas simulações computaci-
onais. Portanto, a matriz Baselinet,i pode ser definida da seguinte forma:
(
Baselinet,i =
O OP Tt,i é a programação de carga sugerida pela técnica de otimização para os

diversos modelos de DR.
(
OP Tt,i =
Partindo desse pressuposto, o cálculo da inconveniência associado a uma

programação de operação dos aparelhos residenciais permite ao consumidor tomar a
melhor decisão de utilização dos aparelhos residenciais no programa de DR. Assim, a
formulação da função f2 é mostrada na equação (9) e assume-se que, tanto a Baselinet,i
quanto o OP Tt,i estejam na forma de uma matriz binária (composta apenas por 1’s e 0’s)
para indicar quais os aparelhos estão em operação em cada intervalo de tempo.
T X
X N
M inimize (Baselinet,i − OP Tt,i )2 (9)
t=1 i=1
389
Definidas as funções f1 e f2, a função objetivo do nosso modelo multi-objetivo se

apresenta da seguinte maneira:
minimize(f 1)
(10)
minimize(f 2)
2.2. Non-Dominated Sorting Genetic Algorithm II (NSGA-II)

A ideia central do Non-Dominated Sorting Genetic Algorithm II (NSGA-II)
[Deb et al. 2002], também conhecido como Elitist NSGA-II, é encontrar um conjunto
de indivı́duos não dominados em relação ao restante da população e apontar este conjunto
como o de nı́vel de dominância mais alto. Em seguida, repete o mesmo procedimento
com o restante da população, separando-a em vários nı́veis de não-dominância.
O NSGA-II surgiu como uma versão melhorada do NSGA
[Srinivas and Deb 1994]. O algoritmo tradicional do NSGA apresenta algumas diferenças
em relação a um algoritmo genético (AG) simples, uma vez que as soluções são classi-
ficadas com base nas informações de dominância de cada uma. Desse modo, para cada
solução é calculada a sua não-dominância (número de soluções que a dominam) e o
conjunto de soluções dominadas pela mesma [Coello 2006]. Assim, é feito um ranking
com base na relação de não-dominância [Srinivas and Deb 1994];[Kunwar et al. 2013].
Além da não-dominância, o NSGA-II calcula a distância média entre as
soluções ao longo de cada função objetivo para obter a densidade que envolve
cada solução presente na população - distância de aglomeração (crowding distance)
[Deb et al. 2002];[Coello 2006]. A técnica de otimização (NSGA-II) termina seu fun-
cionamento quando o critério de parada número máximo de gerações for atingido, e os
indivı́duos do primeiro nı́vel (Fronteira de Pareto ótima) representam as soluções do pro-
blema [Kung et al. 1975];[Miettinen 2012]. A Figura 1 a seguir, ilustra o procedimento
de seleção do NSGA-II.
Figura 1. Procedimento de seleção do NSGA-II [Deb et al. 2002].
3. Estudo de Caso
Nesta seção, são apresentados os cenários de testes e os resultados das simulações com-
putacionais considerando a técnica de otimização (NSGA-II) implementada para determi-
nar a operação dos aparelhos residenciais. Foram criados, por meio da ferramenta Load
Profile Generator (LPG) [Pflugradt 2016], vários perfis de consumo de carga residen-
cial levando em consideração as preferências dos consumidores em relação ao uso dos
aparelhos, as diferentes localizações geográficas, e as temperaturas climáticas e suas res-
pectivas implicações em cada região do Brasil. Além disso, foram adotados para o cálculo
390
do preço dinâmico da energia elétrica os valores fornecidos pelo Mercado Ibérico de Ele-
tricidade (OMIE) de Portugal [OMIE 2015], pois o Brasil ainda não utiliza o programa
de DR baseado no preço em tempo real.
3.1. Cenário de Teste

Foram utilizadas nas simulações computacionais famı́lias que possuı́am diferentes perfis
de consumo de carga e a mesma quantidade de integrantes: 02 adultos que trabalham e 02
adolescentes. Elas residem em 05 cidades brasileiras (Belém, Brası́lia, Teresina, Rio de
Janeiro e Florianópolis) situadas nas 05 regiões do Paı́s respectivamente: Norte, Centro-
Oeste, Nordeste, Sudeste e Sul. O horizonte de tempo T é constituı́do por um total de
120 dias, com discretização por hora. Assim, cada intervalo do horizonte corresponde
a uma hora, o que resulta em um horizonte com tamanho igual a 2880. Ressalta-se que
o horizonte contempla os dias de maior e menor consumo de energia elétrica por mês
para cada famı́lia entre o perı́odo de 01 de janeiro de 2015 a 31 de dezembro de 2015,
segundo o perfil de consumo energético fornecido pela LPG. Além disso, considerou-se
que cada famı́lia possui 29 aparelhos na sua residência, totalizando 145 aparelhos anali-
sados. Na Tabela 1 são apresentados os aparelhos residenciais utilizados nas simulações
computacionais deste trabalho com suas respectivas categorias.
Tabela 1. Categorias dos Aparelhos Residenciais.

Categorias Aparelhos Residenciais
Lâmpadas 100W, 20W e 60W, receptor de sinal de satélite, TV, carregador de celular,
AI Microsoft Xbox 360, receptor de sinal digital, lâmpada de emergência, notebook,
CD/DVD Player, computador, Roteador, monitor de computador, rádio de cozinha.
Adega, ferro a vapor, secador de cabelo, fogão elétrico, microondas, forno elétrico,
AII
espremedor, máquina de lavar roupa, sanduicheira elétrica, máquina de café.
AIII Geladeira, ar condicionado, freezer, secadora de roupa.
Os parâmetros utilizados no NSGA-II foram obtidos experimentalmente via

simulações computacionais com mapa de controle, e, dessa forma, foi verificado que
essa configuração é ideal para solucionar o problema de DR deste trabalho. Portanto, foi
utilizada uma população de tamanho 500, mesmo valor do número máximo de iterações
do NSGA-II. O método de seleção utilizado foi o Torneio de tamanho 3, e os métodos
de crossover e mutação escolhidos foram o Single Point e o Bit Flip, com taxas de 85%
e 1%, respectivamente. Além disso, foram utilizados alguns parâmetros como Demanda
Máxima (dmax ) e Mı́nima (dmin ), Limite de Rampa Superior (rD ) e Inferior (rU ) contendo
os valores de 3 kW, 0 kW, 1 kWh e 1 kWh, respectivamente. É importante mencionar que
cada cidade possui um valor de parâmetro mdc distinto devido ao consumo diferenciado
de cada famı́lia em consequência das várias posições geográficas e suas implicações nos
experimentos.
3.2. Resultados das Simulações e Discussões

A Figura 2 mostra, a Fronteira de Pareto ótima com os resultados obtidos nas simulações
computacionais. Para efeito de análise, tais resultados foram divididos em 3 grupos: um
com as soluções que obtiveram a maior redução de custo da eletricidade, um com as que
atingiram a melhor redução de inconveniência, e um grupo intermediário, composto por
aquelas soluções medianas nos dois objetivos. Com base nesses grupos, foi analisado o
391
quanto cada unidade de inconveniência reflete na redução do custo da eletricidade, o que

vai ser chamado de Trade-off de inconveniência. O Trade-off para cada grupo com as
soluções é mostrado na Tabela 2.
Figura 2. Fronteira de Pareto ótima.
Tabela 2. Trade-off de inconveniência das soluções

Grupo Trade-off
Minimizar Custo 0.151837
Minimizar Inconveniência 0.063502
Grupo Intermediário 0.091648
Pode-se observar que, naquelas soluções que conseguiram uma maior redução no
custo da eletricidade, o Trade-off de inconveniência é maior, o que resulta numa maior
redução por unidade de inconveniência causada ao consumidor final. Já na outra ponta,
naquelas soluções que alcançaram a maior redução de inconveniência, o Trade-off é o me-
nor visto que essas soluções visam manter a inconveniência a menor possı́vel, permitindo
manter o consumo de eletricidade igual ao padrão de consumo original.
Outra análise foi feita com o intuito de verificar quais aparelhos residencias apre-
sentam maior influência na quantidade de inconveniência causada ao consumidor de modo
a aperfeiçoar o agrupamento dos aparelhos apresentados na Tabela 1. Para realizá-la, foi
considerada a solução que obteve a menor redução de inconveniência (maior redução de
custo). Os aparelhos da Categoria AI , proporciona 95.34% da inconveniência total da
solução, enquanto que a Categoria AII é responsável por 4.66% e a Categoria AIII não
causa inconveniência. Assim, isso é motivado pela não definição da preferência de um
horário de funcionamento para tais aparelhos, o que leva a técnica de otimização a alo-
car suas operações nos horários onde o custo da eletricidade é mais baixo. Conhecendo
tal fato, dá-se ao consumidor a liberdade de definir quais aparelhos não irão causar-lhe
inconveniência (terão seu funcionamento bem definido previamente), com base em suas
preferências utilizando-se do agrupamento dos aparelhos residenciais.
392
4. Conclusão
Neste trabalho foi apresentado um modelo de otimização multi-objetivo de DR para con-
sumidores residenciais que visa minimizar tanto o custo associado ao consumo da eletri-
cidade quanto a inconveniência causada aos consumidores finais. Para tanto, por meio do
NSGA-II, a programação do uso dos aparelhos foi baseada no preço da energia elétrica
em tempo real e nas particularidades operacionais das diferentes categorias de aparelhos
residenciais.
Desse modo, foram obtidos resultados que permitem ao consumidor tomar a de-
cisão de como modificar seu consumo de energia elétrica, tendo como preferência a
redução do custo ou a manutenção do seu conforto/satisfação. Vale ressaltar que os nı́veis
de inconveniência normalmente não é contemplado na formulação de modelos de DR,
pois o objetivo central comum é a minimização dos custos da eletricidade.
Como trabalho futuro propõe-se a implementação de modelos de DR visando a
otimização de microgrids. Esses ambientes que possuem algumas caracterı́sticas espe-
ciais, como a similaridade de padrões de consumo de energia, o que é propı́cio para o
surgimento de diferentes horários de pico na aplicação de modelos comuns de DR. Tal
estudo aumentaria a robustez do modelo proposto neste trabalho.
Referências
Chen, Z., Wu, L., and Fu, Y. (2012). Real-time price-based demand response management
for residential appliances via stochastic optimization and robust optimization. IEEE
Transactions on Smart Grid, 3(4):1822–1831.
Coello, C. C. (2006). Evolutionary multi-objective optimization: a historical view of the
field. IEEE computational intelligence magazine, 1(1):28–36.
Deb, K., Pratap, A., Agarwal, S., and Meyarivan, T. (2002). A fast and elitist multiob-
jective genetic algorithm: Nsga-ii. IEEE transactions on evolutionary computation,
6(2):182–197.
Kung, H.-T., Luccio, F., and Preparata, F. P. (1975). On finding the maxima of a set of
vectors. Journal of the ACM (JACM), 22(4):469–476.
Kunwar, N., Yash, K., and Kumar, R. (2013). Area-load based pricing in dsm through
ann and heuristic scheduling. IEEE Transactions on Smart Grid, 4(3):1275–1281.
Miettinen, K. (2012). Nonlinear multiobjective optimization, volume 12. Springer Sci-
ence & Business Media.
OMIE (2015). Electricity market price. http://www.omie.es/inicio.
Parvania, M. and Fotuhi-Firuzabad, M. (2010). Demand response scheduling by stochas-
tic scuc. IEEE Transactions on smart grid, 1(1):89–98.
Pflugradt, N. D. (2016). Modellierung von wasser und energieverbräuchen in haushalten.
Master’s thesis, Technische Universitat Chemnitz, Chemnitz.
Siano, P. (2014). Demand response and smart grids - a survey. Renewable and Sustainable
Energy Reviews, 30:461–478.
Srinivas, N. and Deb, K. (1994). Multiobjective optimization using nondominated sorting
in genetic algorithms. Evolutionary computation, 2(3):221–248.
393
A Proposal for Route Selection in IoT Based on the

Context of Specific Applications
Harilton da S. Araújo 1,3, Raimir H. Filho 1, Joel J. P. C. Rodrigues 1,2,3, Ricardo de
A. L. Rabelo 4, Natanael de C. Sousa 4, José C. C. L. S. Filho4,
José V. V. Sobral 5
1
University of Fortaleza (UNIFOR), Fortaleza, CE, Brazil
2
National Institute of Telecommunications (Inatel), Santa Rita do Sapucaí, MG, Brazil
3
Instituto de Telecomunicações, Portugal
4
Computing Department, University Federal of Piauí, Teresina, PI, Brazil
5
Instituto de Telecomunicações, Universidade da Beira Interior, Covilhã, Portugal
[email protected]; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]; [email protected]
Abstract. The term Internet of Things (IoT), basically, means the

interconnection of intelligent and addressable devices, allowing autonomy and
proactive behavior. The dissemination of data in IoT, usually depends on the
application and requires context-aware routing protocols that must have auto-
configuration features (which adapt the behavior of the network at runtime,
based on contextual information). This article describes an approach to route
selection in the IoT for to meet the context of specific Applications. For this
purpose, it have suggested four Objective Functions (OFs) for the Routing
Protocol for Low-power and Lossy-networks (RPL). Such OFs are
dynamically selected based on contextual information. The aforementioned
OFs were originated from the fusion of the following metrics: Expected
Transmission Count (ETX), Number of Hops (NH) and Energy Consumed
(EC). The simulations carried out illustrate that the implemented proposal,
when compared to objective functions OF0 and MRHOF, can provide the
assurance of data delivery, more energy efficiency and shorter delay when
considering contexts of IoT applications.
1. Introduction
The Internet of Things (IoT) is the pervasive presence of a variety of devices, such as:
sensors, Radio Frequency Identification (RFID) tags and smartphones, among other
devices which can interact with each other for a common purpose [Atzori et al., 2010].
In the scenario of the IoT, plurality is increasing and forecasts indicate that over 40
billion devices will be connected until 2020 [Forbes 2014], allowing for the emergence
of new application possibilities, such as: smart cities, health, smart houses, etc.
Among the most promising technologies for the IoT paradigm are RFID and
Wireless Sensor Networks (WSN), according to [Atzori et al. 2010] and [Sobral et al.
2015]. WSNs have limitations on the identification of a person or object in some types
394
of applications. However, unlike WSNs, RFID systems are unable to sense data from
the place in which they are inserted, such as: humidity, temperature and pressure, which
are provided by the WSN. This is an indication that the IoT, by means of the integration
between the RFID and WSN technologies, maximizes the benefits, thus opening up new
perspectives for applications that consider context information, such as: temperature
monitoring in remote areas and the air quality of a specific city or region, control of
vehicle flow in one way, among others. The context usually refers to location, but it can
also cover different information used to characterize entities involved in the interaction
between the user and the application. According to [Baldauf et al. 2007], context-
sensitive systems are able to adapt their behavior to current conditions with no explicit
intervention from the user.
In IoT, a number of information, such as features of the device itself, of the
environment which surrounds it and of its capacity, can be used as a source of
contextual information. This requires context-sensitive routing protocols for the
fulfillment of a number of challenges during the exchange of messages in the IoT, such
as: a shorter delay, greater reliability on data transmission and minimal power
consumption. Based on these challenges, this article proposes an adjustment of the RPL
protocol [RFC 6550], which is implemented from the creation of four new OFs. The use
of proposed OFs occurs in the process of establishing routes, in order to meet the
context of the applications.
The paper is organized as follows. Section 2 sets out the related Works. Section
3 describes the adjustment done on the RPL protocol. The assessment of the proposed
approach is discussed in Section 4, followed by the conclusions in Section 5.
2. Related Work
According to [Vasseur, J., et al., 2012], the RPL makes use of metrics specified in RFC
6551 which are suitable for IPv6 over Low power Wireless Personal Area Networks
(6LoWPAN) environments, such as: number of hops; latency; delivery ratio, node
energy; throughput; level of link quality; and transmission reliability. In [Thubert 2012]
a standard objective function called Objective Function Zero (F0) was proposed for the
RPL; it was designed to enable interoperability among different implementations of the
RPL. The operation of OF0 is simplified and does not use any routing metrics for the
definition of the rank. A node chooses as its preferred parent the neighbor within reach
which has the lowest rank.
In [Levis & Gnawali 2012], the Minimum Rank with Hysteresis Objective
Function (MRHOF) objective function was introduced. MRHOF is only suitable for the
metrics specified in RFC 6719. The selection of the favorite “parents” is made taking
into account the adopted metrics, where the routes that minimize the cost associated
with the metrics are preferable.
[Jayaraman and Delirhaghighi 2013] propose a context-aware approach that
alters the functioning of a sensor node based on the phenomena collected from the
environment, such as: temperature, humidity, pressure, etc. The contribution of the
author, entitled Situation-Aware Adaptation Approach for Energy Conservation in
Wireless Sensor Network (SA-A-WSN), aims at monitoring the way the sensor node
works in the environment, in order to reduce the network’s power consumption.
According to [Perera et al., 2014] context-sensitive computing has been gaining
more market and relevance, to the extent that it is currently being considered to be an
important component of the Internet of Things.
395
A context-sensitive objective function called Context Aware Objective Function

(CAOF), proposed by [Sharkawy et al. 2014] and aimed at wireless sensor networks, is
based on residual resources and on the change in the sensor node’s state over time. The
function proposed by [Sharkawy et al. 2014] performs a weighted sum of the metrics:
degree of connectivity of the node, level of power of the battery, and position of the
node in the routing tree in relation to the parent node. The ultimate goal of the function
proposed by [Sharkawy et al. 2014] is to find a probability of delivery to each sensor
node.
The use of fuzzy logic to calculate the objective function for the RPL protocol is
proposed by [Gaddour et al. 2014]. In this work, the objective function is the
component used to select the paths by identifying a parent node among many existing
nodes. The objective function called QoS-aware fuzzy logic objective function (OF-FL)
associates parameters with linguistic variables which are combined with preset fuzzy
rules in order to identify the route to be selected. The parameters considered in the OF-
FL are hop numbers, end-to-end delay, packet loss rates, and default route change rate.
In [Chen et al 2015] a Scalable Context-Aware Objective Function (SCAOF)
Objective Function is proposed; it adapts the RPL protocol to the environmental
monitoring within the area of agriculture with a scalable context. The performance of
the SCAOF was assessed both in simulation and field testing. The experimental results
obtained confirm that the SCAOF can extend the network’s service life and improve the
Quality of Service (QoS) in the different agriculture-oriented simulation scenarios.
The papers written by authors [Sharkawy et al. 2014], [Gaddour et al. 2014],
and [Chen et al 2015] motivate the authors to propose a new approach for two reasons:
i) for using metrics which are suitable for 6LoWPAN environments, and ii) to perform a
weighted average of the metrics to provide quality messaging transmission over a
wireless sensor network.
The above-mentioned contributions serve as a basis for the construction of the
proposed approach presented in the next section.
3. Proposed Approach
In this article, it propose an approach focused on adaptation of the Routing Protocol for
Low-power and Lossy-networks (RPL), [RFC 6550]. The main purpose of this proposal
is to optimize routing in order to meet the context requirements of specific applications.
3.1. The RPL Protocol

The RPL protocol is implemented in 4 stages: a) Setup Stage; b) Establishment of
Routes Stage; c) Data Communication stage; and d) Path Reconstruction Stage.
In the route Setup Stage, the RPL protocol, in its original version, uses the OF0
to enable the nodes to select the parent nodes (default route), based on information from
the rank and on the number of hops of a given node for the sink, as described in
expression (1):
𝑅(𝑁) = 𝑅(𝑃) + 𝑟𝑎𝑛𝑘𝑖𝑛𝑐𝑟𝑒𝑎𝑠𝑒 (1)
Where:
• 𝑅(𝑁), is the node new rank;
• 𝑅(𝑃), is the preferred parent rank;
396
• 𝑟𝑎𝑛𝑘𝑖𝑛𝑐𝑟𝑒𝑎𝑠𝑒 , is a variation factor (delta) between the node and the parent
rank.
3.2. Proposed Approach

Figure 1 illustrates the functioning model of the proposed approach, which is based on
the relationship among three nodes. The APPLICATIONS module represents the
context of each application. The DATABASE module contains the objective functions
which will be used for generating routes that meet the requirements of each application.
Four objective functions to be used during the establishment of routes stage were
proposed: DQCA-OF1, DQCA-OF2, DQCA-OF3, and DQCA-OF4.
Figure 1. Functional Model of the Proposed Approach.
The objective functions proposed in the approach enable the devices to select the
parent nodes (default route) based on the context information obtained from the
application. Each application may have requirements that simultaneously need up to
three metrics Expected Transmission Count (ETX) and/or Number of Hops (NH) and/or
Energy Consumed (EC), which allows us to rate them according to their priority level
(N) as (High = 1; Medium = 3; Low = 5). Each of these metrics is represented by an F
function. Based on this information, a T(ni) weight is achieved by each network device,
which represents the sum of the context functions. Table 1 shows the objective
functions used to calculate the route selection.
Table 1. Objective functions used to calculate the route selection
Objective Composition of objective functions Metrics

Function
T(ni)=NETX . FETX(ni)+NNH . FNH(ni) (2) ETX, NH;
DQCA-OF1
T(ni)=NETX . FETX(ni)+NEC . FEC(ni) (3) ETX, EC;
DQCA-OF2
T(ni)=NNH . FNH(ni)+NEC . FEC(ni) (4) NH, EC;
DQCA-OF3
DQCA-OF4 T(ni)=NETX .FETX(ni)+NNS .FNS(ni)+NEC .FEC(ni) (5) ETX, NH, EC
The route selection is carried out by applying the value of T(ni) to the route
selection mechanism described in expression (6), which enable the nodes to locally
decide which route to use for sending the data without incurring the high costs related
to the knowledge of the topology of the overall network. The route selection process can
397
be represented as follows. Consider that G = (N, L) is a directed graph, where N is the

set of vertices (devices) and L is the set of non-sorted data (u,v) of elements in N
connections. If a message is forwarded by path 𝐶 = (𝑣1, 𝑣2, … , 𝑣𝑘−1 , 𝑣𝑘 ) in a 𝐺 graph,
where 𝑣1 , ...,𝑣𝑘 are vertices and (𝑙1 , 𝑙2 ), ..., (𝑙𝑘−1 , 𝑙𝑘 ) are edges, then each node in 𝐶 has
a message delivery cost. Considering that 𝑇(𝑛𝑖) is the weight that represents the cost for
the delivery of the message from 𝑣𝑖 , this means that the (∑ 𝑇(𝑛𝑖)) for 𝑖 = 1, … , 𝑘 − 1,
represents the path quality denoted by 𝑄𝐶 , where:
𝑄𝐶 = ∑𝑘−1
𝑖=1 𝑇(𝑛𝑖)𝑣𝑖 (6)
The rule implemented in the protocol suggests that, the lighter the weight of
𝑇(𝑛𝑖), the better the quality of the 𝑄𝐶 path. Thus, the best path to choose is the one
which, among all the paths that are available from origin to destination, achieves the
lowest value corresponding to the 𝑄𝐶 .
4. Performance Assessment
In order to assess the development of the approach proposed in this paper, it used the
COOJA [Osterlind 2006] simulator, which is part of the Contiki simulation
environment.
The objective functions proposed herein were assessed and compared with the
OF0 and MRHOF functions, which are native objective functions of the RPL. The
energy consumption model used for the performance assessment concerning energy was
the Energest module from the Contiki [Dunkels et al. 2007], which measures the energy
consumption within an IoT device.
4.1. Simulation Scenario and Performance Metrics

The scenario for the simulation, which is shown in Figure 2, consists of 11 sensor
nodes, 6 tags (RFID), 2 reader nodes (RFID) and 1 sink node. There are 20 devices
within a fixed network topology.
Figure 2. Topology of the scenario used in the study.
The total simulation time was 35 minutes; it repeated the simulation five times,
considering that, from the fifth time, no change was observed in the results. However, in
order to assess the dynamic change between the objective functions, the time simulated
was 140 minutes, because each application lingers for 35 minutes. The messages were
simulated with 30-byte packages (default from Contiki). The initial power of the nodes
398
was adjusted to 200 joules above the Energest energy consumption model from the
Contiki [Dunkls et al. 2007].
Five metrics used by the RPL [RFC 6551] were chosen for the assessment of the
approach: Energy Consumed (EC), Cost of the Reception of Messages (CR), Number of
Hops (NH), Delivery Ratio (TX) e Expected Transmission Count (ETX). O Cost of the
Reception of Messages (CR) is the ratio between the number of messages received by
the sink and the total remaining energy of the network. The Expected Transmission
Count (ETX) is equal to the average number of transmissions required (including
retransmissions) so that a package is duly delivered to its destination.
Four applications were taken into account for this study. The first application
requires priority in reliability (represented by the delivery ratio). The second application
requires a shorter delay (represented by the number of hops). The third application
requires a long life span (represented by the energy consumed), and the fourth
application requires QoS for data delivery (represented by the ETX).
4.2. Results Analysis

The results obtained show that the application that require high priority regarding life
span and delay used, among the functions available in the DATABASE, the DQCA-
OF4 function for the route selection process. This function was selected because it can
forecast, in its structure, the metrics energy consumed and number of hops, allowing for
the selection of routes with lower energy consumed and a lower number of hops.
Figure 3 shows that the DQCA-OF4 function achieved, at the end of the
simulation, higher remaining energy (approximately 170 joules) when compared to the
MRHOF and OF0 objective functions which achieved consumption rates of 100 joules
and 80 joules, respectively.
Figure 3. Energy consumption for the Figure 4. Message delivering delay for the
network nodes. sink.
Also in figure 4, from 525 seconds to the end of the simulation, the DQCA-OF4
function had a shorter delay when compared to the MRHOF and OF0 objective
functions. Figure 5 shows that all the objective functions proposed had a lower Cost of
the Reception of Messages when compared to the MRHOF and OF0 objective
functions. This occurred because the proposed approach uses specific objective
functions for each application, which is not the case with the MRHOF and OF0
objective functions.
399
Figure 5. Cost of the Reception of Figure 6. Delivery rate for the sent
Messages (Number of messages/J). messages.
For applications that require reliability in the delivery of data, figure 6 shows
that the DQCA-OF1 function achieved the best performance, with a delivery ratio of
89% when compared to the MRHOF and OF0 objective functions, which achieved
delivery ratios of 65% and 50,4%, respectively. This occurred because, for the selection
of routes, the RPL protocol used the function which forecasts the Expected
Transmission Count (ETX) and Number of Hops (NH) metrics; in this case, both with
high priority.
Figure 7 shows that, for applications that require priority in the quality of the
delivery of data, the DQCA-OF2 (EC=High) function achieved the best performance in
the number of transmissions/retransmissions with ETX=42 when compared to the
DQCA-OF2 (EC=Low) functions, which achieved ETX=88, MRHOF with ETX=140
and OF0 with ETX=180. This difference was achieved because the application required
a high level of priority in the Energy consumed (EC) metrics.
Figure 7. Quality of Service (QoS).
5. Conclusion
This paper proposes an approach for dynamic route selection in IoT based on contextual
information of from the applications. The results showed that the proposed approach is
more effective when compared to the one used by the RPL protocol in its original
version. This was possible because the objective functions which were proposed for the
adaptation of the routing in the RPL protocol showed positive results in terms of life
span, delay, cost of the reception of messages, reliability, and QoS. Moreover, the route
selection mechanism, which was also proposed in this paper, helped in the choice of the
highest quality path. Our intention for the next papers is to implement this approach in
other protocols which apply to the IoT, taking into account the scalability of the devices
that make up an IoT structure.
400
Acknowledgements
This work has been partially supported by National Funding from the FCT - Fundação
para a Ciência e a Tecnologia through the UID/EEA/50008/2013 Project, and by Finep,
with resources from Funttel, Grant No. 01.14.0231.00, under the Centro de Referência
em Radiocomunicações - CRR project of the Instituto Nacional de Telecomunicações
(Inatel), Brazil.
References
Atzori, L., Iera, A. and Morabito, G. (2010). The Internet of things: A survey, Computer
networks, 54(15): 2787–2805.
Baldauf, M., Dustdar, S., Rosenberg, F. (2007) “A survey on context-aware systems”,
International Journal of Ad Hoc and Ubiquitous Computing, vol. 2, no. 4, pp.
263277.
Chen, Y., Chanet, J., Hou, K., Shi, H., De Sousa, G.: A scalable Context-Aware
Objective Function (SCAOF) of Routing Protocol for Agricultural Low-Power and
Lossy Networks (RPAL). Sensors 19507–19540 (2015).
Dunkels, A., Osterlind, F., Tsiftes, N., e He, Z. (2007). Software-based on-line energy
estimation for sensor nodes. In Proceedings of the 4th Workshop on Embedded
Networked Sensors, EmNets ’07, pages 28-32, New York, NY, USA. ACM.
Forbes (2014). Internet of Things By The Numbers: Market Estimates And Forecasts.
Gaddour, O.; Koubaa, A.; Baccour, N.; Abid, M. OF-FL: QoS-aware fuzzy logic
objective function for the RPL routing protocol. In: Modeling and Optimization in
Mobile, Ad Hoc, and Wireless Networks (WiOpt), 2014 12th International
Symposium on. IEEE, 2014, p. 365-372, 2014.
Jayaraman, P. P.; Delirhaghighi, P. SA-A-WSN: Situation-aware adaptation approach
for energy conservation in wireless sensor network. In: Intelligent Sensors, Sensor
Networks and Information Processing, 2013 IEEE Eighth International Conference
on. IEEE, 2013, p. 7-12, 2013.
Miorandi, D., Sicari, S., De Pellegrini, F. and Chlamtac, I. (2012). Internet of things:
Vision, applications and research challenges, Ad Hoc Networks 10(7): 1497–1516.
Osterlind, F.; Dunkels, A.; Eriksson, J.; Finne, N.; Voigt, T. Cross-level sensor network
simulation with cooja. In: Local Computer Networks, Proceedings 2006 31st IEEE
Conference on. IEEE, 2006, p. 641-648, 2006.
Perera, C., Zaslavsky, A., Christen, P., Georgakopoulos, D. (2014) "Context Aware
Computing for The Internet of Things: A Survey", IEEE Communications Surveys &
Tutorials, vol. 16, no. 1.
Pister, K., et al. Industrial Routing Requirements in Low-Power and Lossy Networks.
Network Working Group . 2009. RFC 5673.
Sharkawy, B.; Khattab, A.; Elsayed, K.M.F. Fault-tolerant RPL through context
awareness. In: Internet of Things (WF-IoT), 2014 IEEE World Forum on. IEEE,
2014. p. 437-441, 2014.
Sobral, J., Rabêlo, R., Oliveira, D., Lima, J., Araújo, H., e Holanda, R. (2015). A
framework for improving the performance of IoT applications. In The 14 th
International Conference on Wireless Networks, 2015, pages 143-140, Las Vegas,
NV, USA.
Vasseur, J., et al. Routing metrics used for path calculation in low power and lossy
networks. Network Working Group . 2012. RFC 6551.
401
Um Estudo Comparativo entre os Algoritmos de Seleção de

Protótipos ENN e CNN Aplicados ao Classificador KNN em
Problemas de Diagnóstico Médico
Elynildo Lima Moreira1 , Francisco Edvan Chaves1 , Elidiane Martins Freitas1 ,
Hitalo Joseferson Batista Nascimento1 , Werther Xisto da Silva Cardoso 1
1
Faculdade Integrada da Grande Fortaleza (FGF)
Av. Porto Velho, 401 - João XXIII - Fortaleza/CE - CEP: 60.525-571
[email protected], {edvan, elidiane, hitalo, werther}@fgf.edu.br
Resumo. Atualmente vivemos em um mundo onde tudo depende de sistemas

tecnológicos. Em particular, temos os sistemas de Reconhecimento de Padrões,
que nos auxiliam em diversas atividades, inclusive como apoio a diagnóstico
médico. Um dos classificadores mais comuns é o KNN (K-Nearest Neighbors),
que consiste em associar um novo elemento à mesma classe que o mais pró-
ximo a ele. Assim sendo, o K-NN precisa comparar um novo padrão a ser
classificado com todos os demais. Para reduzir a quantidade de comparações
realizadas por esse classificador, sugiram os algoritmos de seleção de protó-
tipos. Nesse contexto, este trabalho avalia a influência dos algoritmos ENN
(Edited Nearest Neighbor) e CNN (Condensed Nearest Neighbor) aplicados em
problemas médicos. Os experimentos foram realizados com alguns datasets do
repositório UCI. Os resultados demonstraram que o ENN apresentou uma pe-
quena melhoria nas acurácias obtidas enquanto que o CNN apresentou uma
piora significativa, quando comparados com os dados originais.
Palavras-chave: Classificação de Padrões, Seleção de Protótipos, Diagnóstico
Médico.
Abstract. We live now in a world where everything depends on technological

systems. In particular, Pattern Recognition systems help us in many activities,
including in medical diagnosis. Many decision support systems in medical di-
agnosis use classifiers, and K-Nearest Neighbors (K-NN) is one of the most used
classifiers. K-NN algorithm assigns to a new (unknown) pattern the most com-
mon class of its k-nearest neighbors. In order to avoid comparing the new pat-
tern with all other patterns, many prototype selection algorithms were created.
This work evaluates two prototype selection algorithms, Edited Nearest Neigh-
bor (ENN) and Condensed Nearest Neighbor (CNN), when applied to some of
UCI medical datasets. Experiments with ENN show a small improvement in
accuracy in comparison with original results, while CNN decreased accuracy
significantly..
Keywords: Pattern Classification, Selection Prototypes , Medical Diagnostics.
1. Introdução
Atualmente vivemos em um mundo rodeado de tecnologias denominado de cidades inte-
ligentes que nos ajudam em diversas atividades. Há diversos sistemas automatizados que
402
realizam diversas tarefas como: detectar se um veículo passou o sinal vermelho, analisar
uma imagem de satélite e verificar se há desmatamento ou queimadas, analisar uma ima-
gem de um exame de um paciente e identificar alguma doença, etc. Ou a partir dos dados
de um paciente, identificar se ele tem ou não determinadas doenças. Essas ferramentas
que auxiliam nas tomadas de decisão e que tentam simular o nosso cérebro para resolver
determinados problemas são denominadas de Reconhecimento de Padrões (RP).
Desta forma, RP visa classificar uma determinada entidade desconhecida dentre
um conjunto de classes conhecidas. Ou seja, corresponde a um problema de classifi-
cação, sendo a aprendizagem supervisionada a mais utilizada. Há diversos modelos de
classificação, dentre eles podemos destacar os classificadores estatísticos, redes neurais,
bayesianos, probabilísticos. Um dos classificadores mais simples e intuitivo é o KNN
(K-Nearest Neighbours), que é um modelo que associa uma entidade desconhecida como
sendo da mesma classe que a entidade mais próxima a ela.
Na abordagem de aprendizagem supervisionada, há uma fase de treinamento e
uma de testes. Dependendo da cardinalidade e da qualidade dos conjuntos de treina-
mento, essa etapa pode consumir muito tempo e gerar modelos cuja acurácia seja baixa.
Diante desse contexto, surgiram os algoritmos de seleção de protótipos para reduzir a car-
dinalidade dos conjuntos de treinamentos e melhorar tanto a acurácia quanto o tempo de
processamento. Dentre esses algoritmos, destacam-se o ENN (do inglês Edited Nearest
Neighbor Rule) e o CNN (do inglês Condensed Nearest Neighbor). O primeiro algoritmo
elimina os elementos próximos às fronteiras de decisão enquanto que o segundo realiza o
inverso.
Visto que uma das linhas de aplicação de RP é diagnóstico médico, o objetivo
deste trabalho é realizar um estudo comparativo entre os algoritmos de seleção de protó-
tipos ENN e CNN aplicados em problemas médicos.
O restante do trabalho está organizado da seguinte forma: a Seção 2 apresenta
um resumo dos principais tópicos teóricos detalhando o classificador KNN e os dois al-
goritmos de seleção de protótipos estudados. Em seguida, apresenta-se a metodologia
e os resultados obtidos. Por fim, são apresentadas as conclusões e recomendações para
trabalhos futuros.
2.1. Reconhecimento de Padrões
Como visto, Reconhecimento de Padrões (RP) vêm sendo aplicado em diversas áreas de
conhecimento, desde processamento de imagens, análise de crédito a diagnóstico médico.
Um padrão pode ser qualquer entidade que possa ser associada a uma determinada classe.
Por exemplo, uma pessoa que pode ser associada a classe dos indivíduos que possuem
diabetes; uma compra realizada em um site de vendas pode ser classificado como sendo
uma fraude; uma mensagem de correio eletrônico pode ser classificada como spam, etc.
Segundo Marques [dos Santos Salvador Marques 2000], RP consiste em, a partir da iden-
tificação de um objeto, escolher qual classe melhor se adapta ao objeto identificado dentre
um conjunto de hipóteses.
Dessa forma, RP consiste em associar um padrão desconhecido a uma classe
que é já conhecida previamente pelo classificador. Em geral, um padrão é modelado
403
por um conjunto de dados determinados características (ou vetor de características) e

representado através de um vetor ou uma tupla. Assim sendo, um padrão é represen-
tado por um vetor de dados p-dimensional x = (x1 , x2 , ..., xn )T , no qual cada xi repre-
senta uma característica, e está associado a uma das c classes ou grupos (ω1 , ω2 , ..., ωc )
[Webb and Copsey 2011].
Mesmo com a existência de vários algoritmos de classificação, observa-se que
todos visam minimizar o erro de classificação e permitir que a classificação seja eficiente
computacionalmente [Campos 2001]. Neste trabalho, optou-se por usar um classificador
simples e intuitivo: KNN (K-Nearest Neighbors).
2.2. Classificador K-Nearest Neighbors (KNN) e Seleção de Protótipos

O KNN (do inglês, K-Nearest Neighbors) é um modelo de classificação não paramé-
trico baseado apenas no conjunto de treinamento. É baseado no ditado popular: “Diz-me
com quem andas e dir-te-ei quem és”. Para classificar um elemento x de classe desco-
nhecida, o KNN seleciona dentre o conjunto de treinamento os k padrões mais próxi-
mos de x, usando alguma métrica de distância. Dentre esses k elementos selecionados,
verifica-se qual a classe predominante entre eles e a atribui a x. Em problemas de clas-
sificação binária, para evitar empate, escolhe-se sempre o valor de k como sendo ímpar
[Norvig and Russell 2014].
Um problema de classificação é geralmente solucionada através da aprendizagem
supervisionada, onde há uma fase de treinamento e uma de testes. Visando reduzir a
cardinalidade dos conjuntos de treinamento, algoritmos de seleção de protótipos seleci-
onam um subconjunto do conjunto de treinamento original para serem utilizados para
classificação de novos padrões. Além da vantagens gerais como a diminuição do espaço
de armazenamento e redução de esforço computacional para classificação, a seleção de
protótipos pode ainda aumentar o desempenho do classificador. Esta melhora está rela-
cionada à eliminação de ruídos e outliers, pois os protótipos aumentam a capacidade de
generalização do classificador [Oliveira 2011].
Os algoritmos escolhidos para esse estudo foram o ENN (do inglês Edited Nearest
Neighbor Rule) e o CNN (do inglês Condensed Nearest Neighbor). A escolha se deu pelo
fato deles terem comportamentos distintos, como dito na Seção 1: o primeiro algoritmo
elimina os elementos próximo às fronteiras de decisão enquanto que o segundo realiza o
inverso.
2.3. Algoritmo ENN

O algoritmo ENN é uma técnica que elimina ruídos nas regiões de fronteira de classifi-
cação. Possui uma baixa capacidade de redução, mas elimina os elementos que possam
influenciar em erros de classificação. O algoritmo mantém as instâncias que estão mais
próximas do centróide de cada classe, exceto no caso de instâncias com extrema probabi-
lidade de erro [Oliveira 2011].
O algoritmo ENN é determinístico, ou seja, ele vai selecionar sempre os mesmos
elementos independente da ordem que se encontram. Com isso, o ENN aplicado a uma
base de dados, com o mesmo valor de K, sempre terá o mesmo resultado. Como ele pos-
sui a característica de eliminar ruídos, o algoritmo mantém informações desnecessárias,
deixando o processo de classificação mais demorado. O ENN é utilizado como método de
404
pré-processamento da base de dados, eliminando apenas instâncias que apresentam alta

probabilidade de serem ruídos [Oliveira 2011]. O Algoritmo 1 ilustra esse processo.
Algoritmo 1: ENN
Entrada: Conjunto de Treinamento T
Saída: Conjunto de Treinamento Selecionado L
inicio
Conjunto treino = T ;
Conjunto L = ∅ ;
para cada ei ∈ T faça
Conjunto teste = ei ;
Classificador knn = new Classificador(treino);
float acuracia = knn.classificar(teste);
se acuracia == 0 então
L.adicona(ei );
fim
fim
S = T − L;
fim
retorna S
Fonte: Elaborado pelo autor.
2.4. Algoritmo CNN

O objetivo do algoritmo CNN é eliminar informações que estão em excesso. O CNN
tem como ideia principal encontrar o menor subconjunto de dados originais, utilizando o
1-NN, que classifica corretamente todos os elementos da base original. Com isso, o CNN
seleciona os elementos mais próximos da fronteira de classificação [Oliveira 2011]. A
desvantagem deste método é que quando os dados são excluídos, a característica estatís-
tica dos dados também é eliminada. Uma vantagem do modelo é o alto índice de redução
[Oliveira 2011].
O Algoritmo 2 ilustra esse processo. Um ponto importante na descrição do al-
goritmo, é a palavra aleatoriamente, o que significa que o CNN aplicado numa mesma
base de dados com um mesmo valor de K para o KNN, nem sempre resulta nos mesmos
protótipos. É bem comum ocorrer algumas modificações no CNN, porém, mesmo com
estas modificações, o CNN ainda não é determinístico, pois a ordem em que as instâncias
são classificadas afeta o resultado final [Oliveira 2011].
3. Materiais e Métodos
Visando atingir os objetivos deste trabalho, foram implementados os algoritmos ENN e
CNN. A linguagem usada para implementação foi Java usando algumas funcionalidades
da biblioteca Weka, que é disponibilizada juntamente com a aplicação Weka, que é uma
ferramenta de aprendizagem máquina gratuita bastante utilizada. Os experimentos foram
realizados utilizando bases de dados de domínio público. Os experimentos foram feitos
com os dados originais e com os dados selecionados pelos algoritmos ENN e CNN. Com
os dados originais, os experimentos foram realizados com a ferramenta Weka, enquanto
que com os dados selecionados, foram utilizados as implementações realizadas.
405
Algoritmo 2: CNN
Entrada: Conjunto de Treinamento T
Saída: Conjunto de Treinamento Selecionado L
inicio
L = ObtemUmElementoAleatorioPorClasse(T )
para cada ei ∈ T faça
Conjunto treino = L
Conjunto teste = ei
Classificador knn = new Classificador(treino);
float acuracia = knn.classificar(teste);
se acuracia == 0 então
L.adicona(ei );
fim
fim
fim
retorna L
Para atingir o objetivo deste trabalho, foram selecionadas algumas bases de dados
gratuitas disponíveis em [UCI 2016], a saber: diabetes, hepatitis e sick. A Tabela 1 apre-
senta um comparativo entre essas bases. Não foi aplicado nenhum método de extração
de características. Para realização dos experimentos, foi utilizada a técnica de validação
cruzada com 10 folds. Os dados foram baixados no formato ARFF, que é o formato de
arquivo utilizado pelo Weka.
Tabela 1. Bases de dados.

Nome Num. de padrões Num. de características Num. de classes Descrição das classes
diabetes 768 8 2 positive, negative
hepatitis 155 19 2 die, live
sick 3772 29 2 negative, sick
Os experimentos foram realizados com a ferramenta Weka, que é uma ferramenta

de aprendizagem máquina gratuita bastante utilizada [WEKA 2016]. O Weka também
disponibiliza uma biblioteca que pode ser facilmente incorporada em qualquer sistema.
3.1. Detalhes de Implementação

A implementação dos algoritmos ENN e CNN foi realizada em Java usando a biblioteca
weka.jar, que faz parte da API da ferramenta Weka. O projeto consistiu em três classes, a
saber: Main, ENN e CNN.
A classe Main é responsável pela execução dos experimentos. Contém o método
que ler um arquivo no formato ARFF e em seguida, executa o experimento com validação
cruzada, usando 10 folds. O Código 1 apresenta como os experimentos foram codificados.
O experimento é repetido 10 vezes, sendo que em cada execução um fold é selecionado
para teste e os restantes para treinamento, linhas 5 e 6. Em seguida, aplicou a seleção de
protótipos, nesse caso, o ENN, através do método selecionaPrototipos, que será detalhado
406
posteriomente (linha 10). Prosseguindo, são instanciados dois classificadores (Classifier)

do tipo IBk, que é a implementação do KNN disponibilizada no Weka (linhas 19 e 17). O
classificador classif é inicializado com o conjunto de treinamento original e o classifSele-
cionados, com o conjunto selecionado pelo ENN. Após a inicialização, são instanciados
dois objetos do tipo Evaluation, sendo um para cada classificador e que realizam a classi-
ficação de cada elemento do conjunto de teste (linhas 21 e 22). A classificação é realizada
através do método evaluateModel. Em seguida, obtém-se a acurácia de cada um dos expe-
rimentos (método pctCorrect), linhas 28 e 29. Por fim, são exibidas as acurácias médias
dos 10 experimentos realizados. A classe ENN é responsável pela implementação do
ENN. Também utiliza a API do Weka e contém um método denominado selecionaPro-
totipos, que recebe como parâmetro um objeto do tipo Instances e devolve um objeto do
mesmo tipo contendo os elementos selecionados pelo ENN. A classe CNN é responsável
pela implementação do CNN, que contém o método selecionaPrototipos com o mesmo
protocolo do implementado na classe ENN.
Código 1. Classe Main - Realização dos experimentos. Fonte: Elaborado pelo

autor.
2 // Testando cada FOLD

3 for (int n = 0; n < folds; n++)
4 {
5 Instances treino = dadosRandomicos.trainCV(folds, n);
6 Instances teste = dadosRandomicos.testCV(folds, n);
7 ...
8
9 // Aplicar o ENN
10 Instances treinoSelecionados = enn.selecionaPrototipos(treino)
;
11
12 // Classificador KNN para testar os padres sem aplicar o ENN
13 Classifier classif = new IBk();
14 classif.buildClassifier(treino);
15
16 // Classificador KNN para testar os padres APLICANDO o ENN
17 Classifier classifSelecionados = new IBk();
18 classifSelecionados.buildClassifier(treinoSelecionados);
19
20 // Realizando os testes
21 final Evaluation eval = new Evaluation(treino);
22 final Evaluation evalSelecionados = new Evaluation(
treinoSelecionados);
23
24 eval.evaluateModel(classif, teste);
25 evalSelecionados.evaluateModel(classifSelecionados, teste);
26
27 // Obtendo a acurcia (taxa de acertos) dos experimentos
28 acuracia += eval.pctCorrect();
29 acuraciaSelecionados += evalSelecionados.pctCorrect();
30 }
407
4. Experimentos/Análise dos Resultados

Os experimentos sem seleção de protótipos foram realizados variando os valores K e a
métrica de distância. Os números de vizinhos foram 1, 3 e 5 enquanto que as distâncias
foram Euclidiana e Manhattan. Foram realizados diretamente na ferramenta Weka. Os
resultados são apresentados na Tabela 2. Usando K = 1 e distância euclidiana, para o clas-
sificador KNN, foram obtidas as seguintes acurácias: diabetes 70,18%; hepatites 80,65%
e sick 96,18%. Com K = 1 e com a distância de Manhattan, os resultados foram respec-
tivamente: 68,62%, 81,94% e 95,89%. Com K = 3, a média dos experimentos usando
distância Euclidiana foi de 83,37% (desvio padrão: 11,90) e Manhattan, 82,61% (desvio
padrão: 12,75). Usando K = 5, a média dos experimentos usando distância Euclidiana foi
de 85,12% (desvio padrão: 11,61) e Manhattan, 85,08% (desvio padrão: 11,97).
Tabela 2. Resultados dos experimentos realizados com o classificador KNN

K K=1 K=3 K=5
Base Euclidiana Manhattan Euclidiana Manhattan Euclidiana Manhattan
diabetes 70,18 68,62 72,65 70,96 73,18 72,48
hepatitis 80,65 81,94 81,29 80,65 85,81 86,45
sick 96,18 95,89 96,18 96,23 96,37 96,32
Média 82,34 82,15 83,37 82,61 85,12 85,08
Desvio-padrão 13,08 13,64 11,90 12,75 11,61 11,98
Os experimentos com seleção de protótipos (ENN e CNN) foram realizados atra-

vés de implementação realizada (classe Main), usando o KNN com k = 1 e distância
euclidiana (Tabela 3). Observa-se que em alguns casos, o ENN melhorou um pouco a
acurácia dos experimentos passando de 70,17 % para 72,13% com a base diabetes e de
80,62 % para 82,62 % com a base hepatitis. Já quanto o CNN, os resultados pioraram
significativamente, como por exemplo, o ocorrido com a base hepatitis, cuja acurácia caiu
de 80,65% para 62,50 %.
Tabela 3. Resultados dos experimentos realizados com o classificador KNN com

o ENN e CNN
Base Sem o CNN Com o CNN Sem o ENN Com o ENN
diabetes 70,18 61,84 70,17 72,13
hepatitis 80,65 62,50 80,62 82,62
sick 96,18 93,07 96,18 95,89
Média 82,32 72,47 82,32 83,55
Desvio-padrão 13,08 17,84 13,09 11,91
Foram feitos experimentos com outros valores de k, porém não houve melhoria
considerável na taxa de acertos do classificador. O desvio padrão foi relativamente alto,
com isso, faz-se necessário investigar outros bancos de dados. Para os experimentos com
seleção de protótipos, verificou-se que o ENN melhorou a acurácia em 2 dos 3 experi-
mentos realizados. Já o CNN, a acurácia foi reduzida nos 3 experimentos.
408
5. Conclusão
Os resultados mostraram que o classificador KNN pode ser utilizado como apoio ao di-
agnóstico de doenças, conforme experimentos realizados. Como a acurácia média foi
abaixo de 90%, é necessário realizar experimentos com outros conjuntos de dados e com-
parar os resultados com outros classificadores. Em relação aos dois algoritmos avaliados,
ENN e CNN, conclui-se que os mesmos não apresentaram resultados satisfatórios para
as bases testadas. Assim sendo, os algoritmos não são recomendados para utilização em
ferramentas de apoio ao diagnóstico médico. Apesar do ENN ter melhorado o custo em
63% dos experimentos, não justifica sua utilização pelo custo de execução. Além disso, a
melhoria foi de apenas 2%.
Como trabalhos futuros, recomenda-se estudar a influência de algoritmos de sele-
ção de protótipos sobre a performance de outros classificadores, como Redes Neurais e
Máquinas de Vetores de Suporte (SVM). Recomenda-se testar com outras bases e também
outros algoritmos. Recomenda-se avaliar não somente a acurácia, mas também outros fa-
tores, como tempo de processamento e precisão.
Referências
Campos, T. E. (2001). Técnicas de seleção de características com aplicações em reconhe-
cimento de faces. Mestrado em ciência da computaçõo, Universidade de São Paulo,
São Paulo.
dos Santos Salvador Marques, J. (2000). Reconhecimento de padrões: métodos esta-
tísticos e neuronais. Coleção Ensino da Ciência e da Tecnologia. Instituto Superior
Técnico.
Norvig, P. and Russell, S. (2014). Inteligência Artificial, 3ª Edição, volume 1. Elsevier
Brasil.
Oliveira, D. V. R. (2011). Análise comparativa de técnicas de seleção de protótipos em ba-
ses desbalanceadas. Bacharelado em engenharia da computação, Universidade Federal
de Pernambuco, Recife.
UCI (2016). Uci machine learning repository.
Webb, A. R. and Copsey, K. D. (2011). Statical Pattern Recgnition. Wiley.
WEKA (2016). Weka 3: Data mining software in java.
409
Reconhecimento de gestos usando momentos invariantes de

Hu e redes neurais profundas
Raimundo F. Pinto Júnior, C. David B. Borges, Abner S. Nascimento,
Iális C. de Paula Júnior
Engenharia de Computação – Universidade Federal do Ceará (UFC)

Campus Mucambinho – Sobral – CE – Brasil
Abstract. This paper proposes a gesture recognition method based on Hu mo-

ment invariants and deep neural networks. The procedure involves background
subtraction, hand polygon approximation, computation of Hu moments, trai-
ning and testing with different deep neural network architectures. The descri-
bed method is invariant to hand translation, scaling and rotation and achieves
success rates above 90%, making it a feasible alternative in the development of
human-machine interaction applications.
Resumo. Este artigo propõe uma metodologia de reconhecimento de gestos ba-

seada em momentos invariantes de Hu e redes neurais profundas. O procedi-
mento envolve técnicas de remoção do plano de fundo, aproximação poligonal
da mão, extração de momentos de Hu, treinamento e testes com diferentes ar-
quiteturas de redes neurais profundas. A metodologia descrita é invariante a
translação, redimensionamento e rotação da mão e obtém taxas de acerto su-
periores a 90%, o que a torna uma alternativa viável no desenvolvimento de
aplicações de interação humano-máquina.
1. Introdução
Os desenvolvimentos recentes em ferramentas inovadoras de visualização e in-
terfaces gráficas impulsionam o avanço de novas tecnologias de interação humano-
máquina. A viabilidade dessas tecnologias dá-se devido ao crescimento conjunto de
campos como computação gráfica, realidade aumentada, realidade virtual e robótica
[Technavio 2015]. Interfaces capazes de fornecer a sistemas computacionais uma entrada
humana são um fator chave, do qual os setores mencionados são altamente dependentes
[Vilarinho 2014]. Equipamentos como Kinect, Cyberith Virtualizer e Razer Hydra são
exemplos de inovação em tecnologia de dispositivos de entrada [Betancourt et al. 2015].
Contudo, essas ferramentas ainda possuem elevado custo financeiro de aquisição.
Uma possı́vel solução é o uso de técnicas de processamento digital de imagens
(PDI) e visão computacional (VC) para reconhecimento de gestos a partir de imagens de
uma câmera de computador comum. Essa abordagem permite reduzir de forma significa-
tiva os custos associados ao desenvolvimento de aplicações que necessitem de interação
humano-máquina.
Os principais desafios na elaboração de algoritmos eficientes de reconhecimento
de gestos são: segmentação do cenário da imagem, extração de caracterı́sticas relevantes,
410
normalização dos dados adquiridos e classificação dos gestos [Conti and Gonzaga 2011,
Zhang 2012]. As técnicas de reconhecimento de gestos podem ser divididas em duas
categorias: gestos estáticos ou dinâmicos. As técnicas utilizadas para gestos estáticos
realizam o reconhecimento com base em uma única imagem e, por isso, tem um me-
nor custo computacional quando comparadas a técnicas para gestos dinâmicos, que utili-
zam sequências de vı́deo. Na literatura, existem diversas abordagens de reconhecimento
de gestos utilizando técnicas de aprendizagem supervisionada ou não-supervisionada,
como: redes neurais [Ming-Hsuan Yang and Tabb 2002], máquinas de vetor de suporte
[Deng-Yuan Huanga and Changa 2011], nearest-neighbor [den Bergh et al. 2011], grafos
[Triesch and von der Malsburg 2001], Distributed Locally Linear Embedding (DLLE)
[Ge et al. 2006], entre outros [Pisharady and Saerbeck 2015].
Este artigo apresenta uma técnica de reconhecimento de gestos estáticos baseada
na extração de momento invariantes de Hu e classificação com redes neurais profundas.
As taxas de acerto de três diferentes arquiteturas de rede são calculadas a partir de cinco
experimentos, com variação das frações de imagens utilizadas para treino e validação.
2. Fundamentação Teórica
Esta seção aborda as técnicas de pré-processamento, extração de caracterı́sticas
e classificação utilizadas neste trabalho. Em primeiro lugar, realiza-se uma etapa
de remoção de plano de fundo, na qual adota-se o método de segmentação por cor
[Phung et al. 2005] para distinguir a mão presente na imagem e o plano de fundo. A
partir de uma aproximação poligonal do contorno da mão [Suzuki et al. 1985], as carac-
terı́sticas extraı́das são os momentos invariantes de Hu [Hu 1962]. Esses atributos são
fornecidos a uma rede neural profunda durante os treinamentos e testes para que seja
realizada a classificação de gestos.
2.1. Segmentação por cor

É possı́vel aplicar segmentação por cor baseando-se na coloração da pele humana
[Phung et al. 2005]. Para isso utiliza-se o classificador Naı̈ve Bayes. A segmentação
torna possı́vel descartar objetos do cenário que não são relevantes à tarefa de classificação
e potencialmente afetariam o resultado final.
O Teorema de Bayes estabelece uma relação matemática para as probabilidades
de eventos condicionados a evidências prévias. A probabilidade de um evento A, dado
que houve a observação de uma evidência B, é descrita por:
P (B|A) · P (A)
P (A|B) = . (1)
P (B)
Essa modelagem matemática pode ser aplicada para a segmentação de imagens
como uma técnica de classificação binária de pixels: pele e não-pele. Para imagens repre-
sentadas em espaços de cor de 3 canais, por exemplo, considera-se que o evento A repre-
senta o fato de um pixel pertencer a uma região de pele e B corresponde ao valor numérico
que um pixel assume em determinado canal. É necessário, portanto, obter P (A), P (B|A)
e P (B), conhecidos como probabilidades a priori. De forma intuitiva, tem-se P (A),
probabilidade de encontrar determinado pixel; P (B), probabilidade de encontrar pele; e
P (B|A), probabilidade de encontrar pele dado que um pixel possui determinado valor.
411
A partir de um conjunto de imagens com regiões de pele rotuladas, é possı́vel cal-

cular as probabilidades a priori necessárias para a aplicação do teorema de Bayes. Após
a análise de todos os exemplares em um conjunto pré-classificado com o auxı́lio de um
editor de imagens, os valores obtidos das probabilidades para cada canal são armazenados
em uma tabela de referência.
Ao receber uma imagem inédita, o algoritmo busca, para cada pixel, uma pro-
babilidade correspondente na tabela, de acordo com os valores de seus canais, isto
é, sua cor. Em seguida, Q os valores obtidos são multiplicados, conforme a equação
n
P (A1 , A2 , · · · , An |B) = i=1 P (Ai |B), para obtenção da classificação final. Dessa
forma, a imagem torna-se uma matriz de probabilidades inferidas, com valores entre 0
e 1. Determina-se, então, um limiar λ, de modo que:

0 pi ≤ λ
CA (pi ) = . (2)
1 pi > λ
Na equação 2, pi é a probabilidade inferida e CA corresponde à classe atribuı́da ao

pixel, isto é, 0 para não-pele e 1 para pele. Para avaliar a capacidade de acerto do algo-
ritmo, utiliza-se a tabela de referência para classificar as imagens usadas no treino. Assim,
é possı́vel comparar as probabilidades inferidas com a classificação realizada manual-
mente. Considerando o erro quadrático médio do algoritmo aplicado em uma imagem
composta por n pixels, obtém-se a equação 3, na qual Ci é o valor atribuı́do ao i-ésimo
pixel na classificação manual.:
n
X (pi − Ci )2
= , (3)
i=1
n
2.2. Contorno da mão humana

O contorno da região de interesse, após a segmentação, é um fator carac-
terı́stico relevante. Para obtê-lo, primeiramente, extrai-se o contorno, como descreve
[Suzuki et al. 1985]. Contudo, o conjunto de pontos gerado é demasiadamente grande
e identificar quais deles estão posicionados sobre os dedos exige um elevado custo com-
putacional. É possı́vel aplicar o algoritmo de Ramer-Douglas-Peucker para simplificar
o contorno obtido. Conforme descrito em [Ramer 1972], este método elimina recursiva-
mente pontos cuja distância em relação a curva ultrapassem um valor ε, que é a distância
máxima entre a curva original e a curva simplificada. O parâmetro ε é escolhido empi-
ricamente, de forma que a quantidade de pontos a ser desconsiderada é diretamente pro-
porcional ao valor de entrada. Portanto, esse parâmetro deve ser escolhido de modo que
o polı́gono ajuste-se sobre o contorno inicial com uma quantidade moderada de pontos.
2.3. Momentos invariantes de Hu

A partir do contorno poligonal é possı́vel extrair os momentos invariantes de Hu.
Considerando os valores individuais dos pixels como uma função densidade de probabi-
lidade, é possı́vel calcular os momentos estatı́sticos de uma imagem. Estes momentos
descrevem a distribuição espacial dos pontos. A equação 4 mostra como calcular esses
412
momentos. Na equação, ηij representa o i-ésimo momento para o eixo x e j-ésimo mo-
mento para o eixo y; x e y são ı́ndices correspondentes a cada pixel; e I(x, y) indica o
valor, em escala de cinza, do pixel correspondente.
XX
ηij = xi y j I(x, y) (4)
x y
Ming-Kuei Hu, propôs em [Hu 1962] um conjunto de equações que, a partir dos
momentos de uma imagem, obtém valores invariantes em relação a rotação, escala e
translação. Estas equações são conhecidas como momentos de Hu ou momentos inva-
riantes de uma imagem.
2.4. Redes Neurais

Redes neurais artificiais são estruturas muito utilizadas na tarefa de classificação.
Ao utilizar esse mecanismo, o objeto a ser classificado é apresentado à rede através da
ativação de neurônios artificiais na camada de entrada. Essas ativações são processa-
das nas camadas internas por subsequentes ativações ou supressões de conexões entre
os neurônios de diferentes camadas, como mostram as Figuras 1(a) e 1(b). O resultado
emerge como um padrão na camada de saı́da. A rede da Figura 1(a), conhecida como per-
ceptron simples, possui uma única camada e, portanto, só é capaz de resolver problemas
linearmente separáveis. Para resolver problemas não linearmente separáveis é necessário
utilizar uma rede neural de múltiplas camadas ou rede neural profunda. A rede neural
profunda é constituı́da por uma camada de entrada, um determinado número de camadas
ocultas e uma camada de saı́da, como pode ser visto na Figura 1(b).
(a) Rede neural perceptron. (b) Rede neural profunda.
Figura 1. Arquiteturas básicas de redes neurais
A adequação da rede neural a uma tarefa de classificação é determinada por seus

pesos. O treinamento de uma rede neural profunda consiste em adaptar os pesos das sinap-
ses artificiais a um problema especı́fico. Para treinamento de uma rede neural profunda
é necessário utilizar o algoritmo backpropagation, no qual os pesos das conexões das
unidades das camadas internas são modificados conforme o erro é propagado no sentido
inverso, com objetivo de adaptar a rede neural à resolução do problema [Bufo 2000].
Existem diversos métodos de validação de técnicas de classificação; os mais co-
muns consistem em dividir as amostras em conjuntos de treinamento e teste. Essa divisão
413
das amostras é repetida um determinado número de vezes e sempre são escolhidas amos-
tras aleatoriamente. O objetivo é garantir que os dados de saı́da não sejam repetidos
durante os testes. A Figura 2 ilustra o funcionamento desse método, que foi adotado neste
trabalho.
Figura 2. Fluxograma do algoritmo de classificação de gestos.
3. Metodologia
As fases de segmentação por cor e reconhecimento de gestos exigem um base de
dados de imagens. Um software foi desenvolvido para aquisição dessa base de dados.
Foram coletadas imagens de mãos, de diferentes pessoas e etnias, realizando 6 classes de
gestos. Mais de 500 amostras foram coletadas, contendo os gestos definidos na Figura 3.
(a) Gesto 1 (b) Gesto 2 (c) Gesto 3 (d) Gesto 4 (e) Gesto 5 (f) Gesto 6
Figura 3. Gestos da mão definidos para o processo de reconhecimento.
O modelo de segmentação de pele foi calculado utilizando as imagens obtidas. A

Figura 4(b) mostra um exemplo de segmentação realizado pelo modelo Naı̈ve Bayes.
A imagem segmentada fornece um contorno que envolve a mão. No entanto, esse
contorno possui uma quantidade elevada de pontos e um grau de ruı́do. A redução dessas
variáveis é feita com a aplicação de uma aproximação poligonal [Ramer 1972]. A Figura
4(c) exibe a imagem segmentada e mostra o contorno inicial em azul e a aproximação po-
ligonal em verde. Os momentos invariantes de Hu são calculados a partir da aproximação
poligonal para cada classe de gesto. Os momentos de Hu são invariantes à rotação e
proporção. Isso possibilita a classificação de gestos a diferentes distâncias e orientações.
No experimento, foram utilizadas 403 imagens no total, divididas em seis classes.
As configurações de rede neural foram definidas a partir de testes empı́ricos. As três
configurações escolhidas foram as que resultaram nas maiores taxas de acerto:
414
(a) Imagem original. (b) Imagem segmentada. (c) Aproximação poligonal.
Figura 4. Processo de segmentação por cor
• RN 1: Rede neural com 1 camada oculta de 15 neurônios;

• RN 2: Rede neural com 3 camadas ocultas contendo 20, 20 e 10 neurônios;
• RN 3: Rede neural com 4 camadas ocultas contendo 20, 20, 10 e 10 neurônios.
A validação das rede neurais foi realizada através de quatro métodos, utilizando
diferentes frações da base de imagens para treino e teste:
• 25% para treinamento e 75% para teste;
• 100% para treinamento e 100% para teste.
A matriz caracterı́stica de momentos Hu possui mais de 400 amostras, então é
importante normalizar os dados. Tal medida foi realizada para a obtenção de vetores de
caracterı́sticas com média nula e variância unitária, para cada classe. Além disso, sempre
que a rede é novamente treinada, é feita uma permutação da matriz de caracterı́sticas, de
maneira a evitar qualquer vı́cio na rede neural.
4. Resultados
Os quatro experimentos foram executados para as três configurações de rede neu-
ral, cada uma com 30 rodadas de simulação. A partir dos resultados obtidos uma média
da taxa de acertos foi calculada. A Tabela 1, apresenta os resultados obtidos acerca da
porcentagem da taxa de acertos após o treinamento e teste das redes.
Tabela 1. Taxa de acertos dos experimentos.
RN 1 RN 2 RN 3
25% treino / 75% teste 86.52% 90.27% 90.81%
50% treino / 50% teste 91.83% 93.57% 93.84%
75% treino / 25% teste 94.07% 94.43% 94.69%
100% treino / 100% teste 99.15% 99.95% 99.89%
Observa-se a partir dos resultados que as redes RN 2 e RN 3, respectivamente com

3 e 4 camadas ocultas, obtiveram taxas de acerto bastante similares. É importante ressaltar
que a rede neural com duas camadas ocultas obteve um resultado muito próximo a RN1.
Assim como ocorreu com a RN2 e a RN3, por isso esse resultado não foi adicionado
à tabela. Nesse caso, conclui-se que é mais vantajoso a utilização de RN2, pois reduz-
se o tempo necessário para treinamento, devido ao menor número de camadas ocultas,
mantendo-se uma taxa de acerto equivalente.
415
Podemos comparar os resultados obtidos com outros trabalhos, apesar de existir

uma diferença nos gestos e nas caracterı́sticas utilizadas, os métodos comparados ado-
tam o uso de redes neurais como classificador das imagens. Os trabalhos relacionados
são identificados como TR1 [Hasan and Kareem 2013], TR2 [Nguyen et al. 2015] e TR3
[Avraam 2014]. Essa comparação pode ser vista na Tabela 2.
Tabela 2. Taxa de acertos dos experimentos.
Parâmetros Proposto TR1 TR2 TR3

Número de gestos 6 6 24 10
Taxa de acerto (%) 94.69% 86.38% 94.3% 80.3%
Pode-se concluir a partir dos experimentos que é possı́vel a obtenção de boas

taxas de acerto no reconhecimento de gestos utilizando apenas imagens capturada por
câmeras comuns, sem suporte de recursos avançados como câmeras de profundidade,
laser ou sensores acoplados à mão. Um fator importante foi a utilização dos momentos de
Hu, que forneceu ao sistema a capacidade de reconhecer gestos em diferentes escalas e
nı́veis de rotação. Essa propriedade é importante, pois permite a identificação dos gestos
independentemente da mão utilizada, direita ou esquerda.
5. Conclusões e Perspectivas
A segmentação por cor apresentou um ótimo desempenho, resistente a variações
no ambiente. A utilização de momentos de Hu, invariantes a escala e rotação mostrou-se
eficaz e capaz de diferenciar adequadamente as seis classes de gestos escolhidas nos ex-
perimentos. A classificação utilizando rede neurais profundas apresentou taxas de acerto
superiores a 90%, demonstrando a elevada capacidade de reconhecimento de gestos da
técnica apresentada. O método, portanto, mostra-se uma alternativa viável no desenvolvi-
mento de aplicações de interação humano-máquina.
Apesar dos resultados promissores, os métodos apresentados podem ser aprimo-
rados. É possı́vel obter informações acerca de profundidade a partir de imagens bidimen-
sionais, o que possibilitaria adotar técnicas de reconhecimento tridimensional de gestos.
Essas informações poderiam complementar os atributos de entrada da rede neural e elevar
a taxa de acertos dos algoritmos. É relevante também a implementação de um algoritmo
que realize o rastreamento dos dedos para o reconhecimento de gestos dinâmicos. Essa
medida elevaria o número de aplicações do trabalho apresentado, como, por exemplos, o
reconhecimento de gestos aplicado a libras.
Referências
Avraam, M. (2014). Static gesture recognition combining graph and appearance feature
s. International Journal of Advanced Research in Artificial Intelligence, 3(2).
Betancourt, A., Morerio, P., Regazzoni, C. S., and Rauterberg, M. (2015). The evolution
of first person vision methods: A survey. Circuits and Systems for Video Technology,
IEEE Transactions on, 25(5):744–760.
Bufo, M. J. (2000). Aplicação de rede neural artificial como auxiliar na predição do
desempenho de um land farming. Dissertação (Mestrado em Engenharia Agrı́cola),
page 192 p.
416
Conti, C. and Gonzaga, A. (2011). Rastreamento do movimento dos dedos da mão hu-
mana em imagens de vı́deo. Journal of the Brazilian Neural Network Society, 9:104–
119.
den Bergh, M. V., Carton, D., Nijs, R. D., Mitsou, N., Landsiedel, C., Kuehnlenz, K.,
Wollherr, D., Gool, L. V., and Buss, M. (2011). Real-time 3d hand gesture interaction
with a robot for understanding directions from humans. In 2011 RO-MAN, pages 357–
362.
Deng-Yuan Huanga, W.-C. H. and Changa, S.-H. (2011). Gabor filter-based hand-pose
angle estimation for hand gesture recognition under varying illumination. Expert Sys-
tems with Applications, 38(5):6031–6042.
Ge, S. S., Yang, Y., and Lee, T. H. (2006). Hand gesture recognition and tracking ba-
sed on distributed locally linear embedding. In 2006 IEEE Conference on Robotics,
Automation and Mechatronics, pages 1–6.
Hasan, H. S. and Kareem, S. B. A. (2013). Gesture feature extraction for static gesture
recognition. Arabian Journal for Science and Engineering, 38(1):3349–3366.
Hu, M.-K. (1962). Visual pattern recognition by moment invariants. Information Theory,
IRE Transactions on, 8(2):179–187.
Ming-Hsuan Yang, N. A. and Tabb, M. (2002). Extraction of 2d motion trajectories and
its application to hand gesture recognition. IEEE Transactions on Pattern Analysis and
Machine Intelligence, 24(8):1061–1074.
Nguyen, T.-N., Huynh, H.-H., and Meunier, J. (2015). Static hand gesture recognition
using principal component analysis combined with artificial neural network. Jounal of
Automation and Control Engineering, 3(1):40–45.
Phung, S. L., Bouzerdoum, A., and Chai, D. (2005). Skin segmentation using color pixel
classification: analysis and comparison. IEEE transactions on pattern analysis and
machine intelligence, 27(1):148–154.
Pisharady, P. K. and Saerbeck, M. (2015). Recent methods and databases in vision-based
hand gesture recognition. Comput. Vis. Image Underst., 141(C):152–165.
Ramer, U. (1972). An iterative procedure for the polygonal approximation of plane cur-
ves. Computer graphics and image processing, 1(3):244–256.
Suzuki, S. et al. (1985). Topological structural analysis of digitized binary images by
border following. Computer Vision, Graphics, and Image Processing, 30(1):32–46.
Technavio (2015). Global robotics market 2015-2019. Technical report, Research and
Markets.
Triesch, J. and von der Malsburg, C. (2001). A system for person-independent hand pos-
ture recognition against complex backgrounds. IEEE Transactions on Pattern Analysis
and Machine Intelligence, 23(12):1449–1453.
Vilarinho, L. (2014). Interface homem-máquina. Engenharia de Software Magazine, (47).
Zhang, Z. (2012). Microsoft kinect sensor and its effect. MultiMedia, IEEE, 19(2):4–10.
417
Anais Eletrônicos
ENUCOMP 2017 - X Encontro Unificado de Computação - www.enucomp.com.br/2017 - ISBN: 978-85-8320-201-1
O uso da técnica DAMICORE em dados de alunos do ensino

superior para identificar características de evasão
Tiego A. do Nascimento1, Isaac B. S. Souza1, Jordano L. Baluz1, Matheus W. G.
Santos1, Luis O. N. Teles1, Rodrigo A. R. S. Baluz1
1
Departamento de Ciência da Computação – Universidade Estadual do Piauí (UESPI)
Parnaíba – PI – Brasil
{tiegonasc, isaacwinfor, jordanolb95, matheuswilliamsantos22,
luisotaviotavim28, rodrigobaluz}@gmail.com
Resumo. A evasão é um problema sério que afeta as Instituições de Ensino
Superior (IES) brasileiras. A Universidade Estadual do Piauí (UESPI),
campus Prof. Alexandre Alves de Oliveira não fica de fora desta realidade.
Este trabalho objetiva demonstrar o uso da técnica DAMICORE para auxiliar
na identificação de alunos que têm tendência a abandonar seus estudos.
Através desta técnica de Mineração de Dados é possível agrupar dados
específicos de alunos e identificar aqueles que têm grandes chances de evasão.
Fazendo uso do método de identificação de alunos proposto neste artigo
espera-se ser possível ter um maior controle sob o índice de evasão na UESPI
de Parnaíba através de um acompanhamento mais direcionado.
Abstract. Evasion is a serious problem that affects Brazilians Higher
Education Institutions. The University of Piauí State (UESPI), campus Prof.
Alexandre Alves de Oliveira is not out of this reality. This paper aims to
demonstrate the use of the DAMICORE technique to help to identify students
who tend to abandon their studies. Through this technique of Data Mining it is
possible to group specific data of students and to identify those that have great
chances of university dropout. Using the method proposed in this paper it is
expected to be possible to have a greater control under the evasion index in the
UESPI of Parnaíba city through a more accurate monitoring.
1. Introdução
A evasão é hoje um dos maiores problemas que instituições de ensino superior têm para
resolver e tem sido alvo de muitas pesquisas educacionais. Muitos gestores buscam
minimizar efetivamente esse problema através de ações concretas como atendimento
psicológico [Moura e Facci 2016] ou até mesmo aulas preparatórias para o nivelamento
do conhecimento [Campos 2009]. Porém, para que essas ações sejam postas em prática
de forma mais seletiva e eficaz é necessário que esses gestores saibam quem são os
estudantes propensos a desistir de seus estudos.
Pensando nisto e considerando o escopo da UESPI de Parnaíba, este trabalho
propõe o uso de uma técnica de mineração de dados para fazer a classificação de alunos
que têm características de desistente. O que se espera é que os resultados obtidos sirvam
para auxiliar os gestores dessa instituição de ensino a agir antecipadamente,
minimizando os problemas relacionados à evasão.
418
Anais Eletrônicos
DAMICORE é uma técnica de mineração de dados que é poderosa na tarefa de
classificar, agrupar e encontrar correlações em dados de diversos tipos. No trabalho de
Abreu Silva et al. (2014), a técnica mostrou-se ser capaz de encontrar correlações
complexas. Nesse trabalho, ela é aplicada com objetivo de classificar os dados de
alunos, visando a identificação daqueles com perfil de desistente.
O presente artigo foi organizado nas seguintes seções. A seção 2 descreve
trabalhos relacionados à mineração de dados educacionais e afins. A seção 3 define a
proposta geral deste trabalho. A seção 4 define e explica a metodologia utilizada. E a
seção 5 conclui esse artigo com uma visão geral do que se pode esperar como resultados
da aplicação do método proposto na UESPI de Parnaíba.
Existem diversas pesquisas na área relacionado as predições do desempenho acadêmico
e sua relação com a evasão da formação educacional utilizando mineração de dados, o
qual floresceu bastante nos últimos anos. Tem despontado como uma área relevante de
estudo pois permite analisar grande volumes de dados proporcionando soluções mais
rápidas para um tema que está sempre em foco dos educadores.
Segundo Santos et al. (2016) a área cresceu nos últimos anos, seu estudo
analisou diversos trabalhos da área, analisando as principais técnicas e ferramentas
utilizadas. Fica evidente que muitos trabalhos utilizaram uma abordagem mais direta nas
disciplinas, deixando de empregar uma tratamento mais focado no aluno, porém é
amplamente utilizado Árvores de Decisão, isso favorece esta técnica como uma
abordagem segura e bem sucedida.
Rigo, Cambruzzi e Barbosa (2014) apresentam um sistema de descoberta de
conhecimento em bases de dados educacionais, que resultou de uma parceria com uma
empresa de tecnologia educacional, o sistema busca identificar tendências de alunos
possibilitando assim que os gestores possam tratar e minimizar qualquer impacto,
principalmente os casos de evasão imediata. O trabalho busca um foco mais direto ao
aluno, investindo em soluções mais sociais, onde não está focado apenas no bem da
instituição, mas do discente também. No entanto foi utilizada uma abordagem extensa
para solucionar os problemas encontrados, podendo causar um gasto excessivo de
tempo e atrasando a solução para a ocorrência.
Júnior, Noronha e Kaestner (2016) têm como objetivo definir um modelo de
previsão da evasão, utilizando dados extraídos do sistema acadêmico da UTFPR, foram
testados trinta e seis atributos e criados onze atributos para contribuir na tarefa de
mineração de dados. Foi então selecionado os dez melhores atributos, entre eles está o
coeficiente de rendimento, mostrando assim que este é uma ótima escolha para
identificar se o aluno tem disposição a evasão escolar.
Silva (2017) propõe um sistema previsor capaz de indicar quais alunos estão
com maior risco de não conseguirem formar, para seu desenvolvimento foi utilizado
dados de alunos da área de computação que já saíram da universidade. Foi constatada a
viabilidade da utilização de mineração de dados para prever o risco do aluno evadir.
Simões Gomes (2015) usou dados estatísticos educacionais procedentes do
419
Anais Eletrônicos
Exame Nacional do Ensino Médio (ENEM) dos anos de 2013 e 2014 para descobrir
padrões e regras de associação dos dados utilizando-se de técnicas e métodos de
mineração de dados. A autora buscou dar ênfase aos dados do questionário
socioeconômico disponibilizado pelo Instituto Nacional de Estudos e Pesquisas
Educacionais Anísio Teixeira (INEP), tentando encontrar correlações entre os dados do
questionário com o desempenho dos inscritos no ENEM. Um dos algoritmos usados em
seu trabalho encontrou uma forte relação entre a renda familiar dos estudantes e o seu
desempenho na prova, principalmente dos advindos da escola pública.
Moro et al. (2014) têm como objetivo identificar padrões relevantes de
comportamento de alunos, que utilizaram a plataforma MathTutor. Empregando a
ferramenta DAMICORE para realizar a mineração de dados, o experimento obteve
resultados positivos que demonstram a eficácia da ferramenta para esta tarefa. O
trabalho se enquadra em um projeto maior, sendo assim a sua elaboração é um meio
para validar os métodos utilizados, a fim de dar continuidade.
3. Proposta
Tendo em vista os prejuízos causados por um aluno desistente e os problemas causados
pela evasão em geral, esse trabalho propõe o uso da técnica de mineração de dados
DAMICORE para analisar dados de universitários concluintes do primeiro semestre dos
cursos da UESPI de Parnaíba, comparando com dados de alunos já evadidos, e concluir
se os dados de determinado aluno são semelhantes ou não aos dos desistentes através de
agrupamento de dados. O que se espera é que universitários com características de
desistente sejam imediatamente identificados de forma automática e eficiente, e que,
dessa forma, os gestores da UESPI de Parnaíba possam ter um maior controle sobre a
evasão nessa instituição, utilizando-se das medidas necessárias para o tratamento deste
problema. Essas medidas podem ser direcionadas especificamente àqueles identificados
pela ferramenta.
4. Método
Devido a natureza teórica desta obra, os métodos descritos são baseados em trabalhos de
terceiros com intuito de efetuar trabalhos futuros aplicando o que foi abordado e
validando as explanações descritas. Por tratar-se de uma proposta, os dados utilizados no
artigo são fictícios devido ao seu objetivo de demonstração do funcionamento das
técnicas debatidas. Para explicar o método, aqui é feito um exemplo simples que ilustra
o DAMICORE aplicado em uma base de dados de alunos.
O DAMICORE é uma técnica de mineração de dados na qual os dados são
dispostos em arquivos e armazenados em um diretório único. A técnica é caracterizada
pela aplicação em tipos de dados diversos graças ao Normalized Compression Distance
(NCD), uma métrica baseada em compressor que visualiza os dados como simplesmente
uma sequência de bits. O funcionamento do DAMICORE se dá através das técnicas
NCD, Neighbor Joining e Fast Newman [Sanches, Cardoso e Delbem 2011; Gomes
2016].
A implementação das etapas segundo Rigo (2012), descoberta do conhecimento,
registro de padrões de interesse, identificação de tendências conforme os padrões
descobertos, aviso aos envolvidos e registro das ações realizadas e resultados obtidos.

420
Anais Eletrônicos
Com essas informações coletadas é feito sua entrega aos envolvidos para que possam ser
tratadas e reduzir seu impacto.
4.1. Dados dos alunos

No problema da evasão alguns fatores se mostram chaves como abandono por fracasso
nas disciplinas iniciais, deficiências em conteúdos anteriores, inadequação aos métodos
de estudo, podem ser utilizados para identificação de alunos com tendência a evasão.
A escolha dos atributos ideais é um grande obstáculo, já que não foram
encontradas referências que definem aqueles que são os melhores. Por tanto, nesse
exemplo simples são usados três dos atributos definidos por Manhães et al. (2012). Os
autores colocam que o Coeficiente de Rendimento Acadêmico (CRA), o número de
Reprovações por Média (RM) e o número de Reprovações por Faltas (RF) são
adaptações para o processo de mineração dos dados. Para fins de demonstração, esses
atributos serão usados aqui.
Dois perfis de alunos devem ser considerados para que o DAMICORE possa
distinguir com clareza os dados e fazer a classificação corretamente. Um desses perfis é
o do aluno desistente, o qual, em geral, tem notas ruins e uma ou mais reprovações. O
outro perfil é o do aluno com bom desempenho acadêmico, que tem boas notas e
nenhuma reprovação.
4.2. Base de Dados

Os dados de cada discente são colocados em um arquivo .txt nomeado com um id único
que identifica cada aluno. Esses arquivos são organizados em um mesmo diretório onde
o DAMICORE pode buscá-los. Cada arquivo contém 3 dados específicos de cada aluno:
CRA, RM e RF. É necessário que esses dados fiquem separados de alguma forma dentro
do arquivo para não haver uma mistura entre eles e não gerar qualquer tipo de confusão.
Nesse exemplo é usada uma quebra de linha para fazer a separação. É importante frisar
que no mesmo diretório devem estar contidos o arquivo .txt do aluno que se pretende
fazer a análise, os arquivos .txt de alunos com bom rendimento e os arquivos .txt dos
alunos já evadidos.
4.3. Aplicação do DAMICORE na base de dados

DAMICORE é uma aplicação que é executada direto na linha de comando de Sistemas
Operacionais (SO) GNU Linux e Windows, portanto todo o processo de execução das
tarefas é feito no Terminal (Linux) ou Prompt de Comando (Windows).
Antes de iniciar o DAMICORE, precisamos definir a base de dados. Neste
exemplo são definidos os dados fictícios de dez alunos com rendimento acadêmico ruim.
Além disso, são inseridos na mesma pasta dez alunos com bom rendimento acadêmico.
Para o melhor funcionamento da aplicação, os dados a serem analisados devem estar
livres de sujeira, que geralmente são partes nos dados que se repetem de forma
desnecessária. No caso específico do atributo CRA, há uma vírgula no seu valor que
poderá vir a prejudicar os resultados, portanto, a vírgula em questão será ignorada.
Desta forma, um CRA com valor 7,5, por exemplo, será reescrito como 75.
A Tabela 1 lista os dados de alunos desistentes. Observa-se que eles têm CRA
421
Anais Eletrônicos
baixo e reprovações RM e FR. A Tabela 2 lista os dados dos alunos que tiveram bom
CRA e não reprovaram em nenhuma disciplina no primeiro período letivo.

Tabela 1. Dados de alunos com rendimento acadêmico ruim após conclusão do primeiro
período letivo.
Nome do arquivo CRA RM RF

aluno_001.txt 60 2 1

Tabela 2. Dados de alunos com bom rendimento acadêmico após conclusão do primeiro
período letivo.
Nome do arquivo CRA RM RF

aluno_014.txt 100 0 0
aluno_017.txt 100 0 0

Os dados ficam separados dentro dos arquivos por uma quebra de linha e seguem
a ordem CRA, RM e RF. O mesmo procedimento é feito para o aluno fictício que será
alvo da análise. Esse aluno será chamado de aluno_000 para evitar confusões ao tentar
encontrá-lo nos resultados gerados. Os dados do aluno_000 são CRA = 50, RM = 1 e
RF = 1. Os nomes dos atributos são desconsiderados, pois esse tipo de informação não é
422
Anais Eletrônicos
relevante e interfere negativamente nos resultados gerados.

Base de dados definida, agora o DAMICORE já pode ser executado. Na linha de
comando, o DAMICORE pode ser executado com o comando:
./damicore-python/src/damicore.py examples-artigo/texts --graph-image out.png
--compressor gzip, na qual definimos onde o script se encontra, o diretório contendo os
arquivos texto ou imagens. A opção --graph-image define o arquivo de imagem a ser
gerado, e a --compressor qual o utilitário para compressão dos dados.
5. Resultados
Na Figura 1, pode-se ver que o aluno_000, alvo fictício da análise, foi posicionado do
lado de baixo da árvore, circulado em vermelho, onde estão agrupados corretamente
todos os alunos com notas ruins. Esse é o resultado esperado, pois o aluno_000
realmente tem os dados com valores próximos aos dos alunos definidos como evadidos.
No exemplo, conclui-se, então, que o aluno_000 tem características de desistente.
Porém, ao analisar o resultado mais profundamente, vê-se que há grupos mais
especializados. O DAMICORE realiza esse agrupamento em etapas posteriores à etapa
inicial, afinando as comparações e aproximando mais as folhas. Houve, no resultado
gerado, um engano da aplicação. Ao analisar a tabela dos alunos com desempenho ruim,
constata-se que o aluno_004 não é o mais parecido com o aluno_000, mas sim o
aluno_003, que, embora esteja no mesmo ramo, poderia ter sido melhor classificado e,
como resultado, estar posicionado ao lado do aluno_000. Ainda que os resultados de
agrupamentos de ramos mais especializados não sejam de interesse desse trabalho, este
é um erro que chama atenção e causa preocupação.

Figura 1. Árvore filogenética gerada pelo DAMICORE. Fonte: Autor.
423
Anais Eletrônicos
As linhas pontilhadas não fazem parte da imagem gerada pelo DAMICORE,
foram inseridas na figura para destacar e separar visualmente os dois grupos. O grupo
circulado em vermelho contém os alunos com notas ruins, e o grupo circulado em azul,
os que têm bom rendimento acadêmico.
A seção anterior exemplifica bem o funcionamento do DAMICORE aplicado em
uma base de dados estudantil. O resultado mostrado na Figura 1 é pouco detalhado
devido à quantidade de registros na base de dados. O que se espera de uma aplicação
real é que se tenha centenas de instâncias e o uso de vários atributos quantitativos
relacionados ao desempenho dos discentes, inclusive dados socioeconômicos, para que
os resultados sejam mais precisos.
Como é possível observar na metodologia, para melhores resultados na aplicação da
técnica é necessária uma grande base de dados de alunos, pois, dessa forma, a chance de
encontrar semelhanças aumenta. Deve-se também levar em conta os índices de acertos e
desempenho do DAMICORE, que, tratando-se dessa abordagem, não podem ser
estimados, pois não há referência suficiente na literatura usando essa técnica para se
determinar um percentual.
Quanto aos alunos que podem ser considerados ideais para participar desta
análise é necessário levar em consideração que nos primeiros período letivos a evasão é
relativamente maior [Silva Filho et al. 2007]. Desta forma, o primeiro período letivo é
uma excelente fonte de dados referentes ao problema. Por tratar-se de um exemplo, esta
questão não é colocada em foco, porém, na execução do método em uma situação real
esta faixa de alunos pode ser vista como ideal.
O objetivo do trabalho foi demonstrar a aplicação da técnica DAMICORE em
uma base de dados de alunos universitários para identificar aqueles com tendência a
evasão. O que se espera com a aplicação dessa técnica na UESPI de Parnaíba é a
diminuição do índice de desistência dessa instituição. Mas, para isso, é imperativo que
se debruce sobre o perfil do aluno, acompanhando as alterações e realizando
continuamente ajustes no modelo pedagógico [Moura e Facci 2016].
Assim fica em aberto para trabalhos futuros sua utilização no banco de dados da
UESPI de Parnaíba, para que seja trabalhado neste local e demonstrado sua capacidade
para ajudar no combate a evasão de alunos.
Referências
Abreu Silva, B. de., Cuminato, L. A., Delbem, A. C., Diniz, P. C. e Bonato V. (2014).
Application-oriented cache memory configuration for energy efficiency in
multi-cores. IET Computers & Digital Techniques, Reino Unido, vol. 9, n. 1, p.
73-81, fev. 2014.
Campos, M. (2009). Calouros passam por nivelamento. Disponível em:
<http://www.gazetadopovo.com.br/educacao/vida-na-universidade/vestibular/calouro
s-passam-por-nivelamento-bs4u73lw4ujla5k37ks6lcuoe/>. Acesso em: 16 de jul.
2017.
424
Anais Eletrônicos
Gomes, E. A. P. (2016). Detecção de ilhamento de geradores síncronos distribuídos por
correlações da mineração complexa de dados. Dissertação de Mestrado, Escola de
Engenharia de São Carlos, USP, São Carlos.
Júnior, José G. de Oliveira, Noronha, Robinson Vida; Kaestner, Celso A. Alves (2016).
Criação e Seleção de Atributos Aplicados na Previsão da Evasão de Curso em Alunos
de Graduação. Computer On The Beach, São José, p.61-70, abr. 2016.
Manhães, L. M. B., Cruz, S. M. S. da., Costa, R. J. M., Zavaleta, J. e Zimbrão, G.
(2012). Identificação dos Fatores que Influenciam a Evasão em Cursos de Graduação
Através de Sistemas Baseados em Mineração de Dados: Uma Abordagem
Quantitativa. VIII Simpósio Brasileiro de Sistemas de Informação (SBSI), Anais, São
Paulo, p. 468-479, mai. 2012.
Moura, F. R. e Facci, M. G. D. (2016). A atuação do psicólogo escolar no ensino
superior: configurações, desafios e proposições sobre o fracasso escolar. Psicologia
Escolar e Educacional, São Paulo, v. 20, n. 3, p. 503-514, set./dez. 2016.
Moro, Luis F. de S. et al. Caracterização de Alunos em Ambientes de Ensino Online:
Estendendo o Uso da DAMICORE para Minerar Dados Educacionais. 3º Congresso
Brasileiro de Informática na Educação, [s.l], p.631-640, 2014.
Rigo, S. J., Cazella, S. C. e Cambruzzi, W. (2012). Minerando Dados Educacionais com
foco na evasão escolar: oportunidades, desafios e necessidades. I Workshop de
Desafios da Computação Aplicada à Educação, Paraná, jul. 2012.
Rigo, S. J., Cambruzzi, W., Barbosa, Jorge L. V. (2014). Aplicações de Mineração de
Dados Educacionais e Learning Analytics com foco na evasão escolar: oportunidades
e desafios. Revista Brasileira de Informática na Educação, [s.l.], v. 22, n. 1,
p.132-146, mar. 2014.
Sanches, A. Cardoso, J. M. P. e Delbem, A. C. B. (2011) “Identifying Merge-Beneficial
Software Kernels for Hardware Implementation” in International Conference on
Reconfigurable Computing and FPGAs, p. 74-79.
Santos, R. M. M. dos, Pitangui, C. G., Andrade, A. V., Assis, Luciana P. de (2016).
Análise de Trabalhos Sobre a Aplicação de Técnicas de Mineração de Dados
Educacionais na Previsão de Desempenho Acadêmico. V Congresso Brasileiro de
Informática na Educação, Porto Alegre, p.960-969, 2016.
Silva, Gabriel Ferreira (2017). Análise Preditiva do Desempenho Acadêmico de Alunos
de Graduação da UnB Utilizando Mineração de Dados. 2017. 63 f. TCC (Graduação)
- Curso de Ciência da Computação, Universidade de Brasília, Brasília, 2017.
Silva Filho, R. L. L., Motejunas, P. R., Hipólito, O. e Lobo, M. B. de C. M. (2007). A
evasão no ensino superior brasileiro. Cadernos de pesquisa, São Paulo, v. 37, n. 132,
p. 641-659, set./dez. 2007.
Simões Gomes, T. Carina (2015). Descoberta de Conhecimento Utilizando Mineração
de Dados Educacionais Abertos. TCC. Universidade Federal Rural de Pernambuco,
Departamento de Estatística e Informática, Recife.

425
Anais Eletrônicos
Um Mapeamento Sistemático sobre o uso das Redes

Neurais Deep Learning e Interface Cérebro-Computador em
Eletroencefalogramas
Matheus W. G. Santos1, Luis O. N. Teles1, Tiego A. Nascimento1, Jordano L. Baluz1,
Isaac B. S. Souza1, Rodrigo A. R. S. Baluz1
1
Departamento de Ciência da Computação – Universidade Estadual do Piauí (UESPI)
Parnaíba – PI – Brasil
{matheuswilliamsantos22, luisotaviotavim28, tiegonasc, jordanolb95,
isaacwinfor, rodrigobaluz}@gmail.com
Abstract. For years the electroencephalogram(EEG) has been shown to be of
paramount importance in the diagnosis of epilepsy, encephalopathy and
various infections of the central nervous system. However, its results still have
a deficit in the precision of the data obtained, which impairs more reliable
analyzes. Therefore, other technologies and tools such as Neural Networks and
BCI (Brain-Computer Interface) have been used with EEGs. This article
describes the steps of a systematic mapping performed for the purpose of
describing the current efficiency of the application of deep learning and BCI to
the improvement of the results, as well as to detail the next steps for the
advance in this area of research, that seek to minimize the errors in EEGs.
Resumo. Há anos o eletroencefalograma(EEG) tem se mostrado de suma
importância no diagnóstico de epilepsias, encefalopatias e outras diversas
infecções do sistema nervoso central. Porém, seus resultados ainda possuem
um déficit no que diz respeito à precisão dos dados obtidos, o que prejudica
análises mais confiáveis. Com isso, outras tecnologias e ferramentas como as
Redes Neurais e a Interface cérebro-computador foram utilizadas junto aos
EEGs. Este artigo detalha as etapas de um mapeamento sistemático realizado
para expor a atual eficiência da aplicação de aprendizagem profunda e BCI no
aprimoramento dos resultados, bem como detalhar os próximos passos para o
avanço desta área de pesquisa, que buscam minimizar os erros nos EEGs.
1. Introdução
Há séculos o avanço da tecnologia beneficia a área da saúde na obtenção de exames,
diagnósticos e cirurgias com cada vez mais eficiência, o que implica na melhoria da
condição de vida da população mundial como um todo. Uma das ciências da saúde que
muito se tem estudado é a neurologia, devido a complexidade do sistema neurológico e
das suas funções. Apesar de tamanha complexidade dessa região, inúmeros tipos de
exames e diagnósticos foram criados, a fim de detectar irregularidades e evitar que estes
se transformem em problemas maiores e consequentemente deixem sequelas.
O tipo de exame mais utilizado na neurologia é o eletroencefalograma. O EEG
consiste na realização de mapeamento cerebral, por meio de uma série de eletrodos
inseridos na parte externa do crânio do paciente e que monitora os sinais oriundos do
426
Anais Eletrônicos
cérebro[E. Nurse et al, 2016]. Com isso, é possível diagnosticar inúmeros problemas
cerebrais como epilepsia, demência ou narcolepsia.
Apesar de ser o principal tipo de exame desde a segunda metade do século
passado, o EEG ainda apresenta alguns déficits no diagnóstico e nos resultados
finais[Becker K., et al 2004]. Para haver aumento na eficiência dos resultados nesse tipo
de situação, é necessária a utilização de ferramentas computacionais, que são criadas
justamente no intuito de resolver problemas na maioria das áreas. O objetivo deste
artigo foi por meio de um mapeamento sistemático, fazer uma ‘’varredura’’ na literatura,
em busca de trabalhos que fizeram esta mesma combinação de ferramentas e com
aplicações próximas utilizando os conceitos já detalhados anteriormente e, além disso,
ter conhecimento sobre o estado da arte.
Após a seção de introdução, este artigo foi organizado nas seguintes seções. A
seção 2 corresponde aos conceitos que fundamentam a pesquisa. A seção 3 detalha
todas as etapas do mapeamento sistemático realizado. A seção 4 diz respeito às
conclusões dos autores sobre os resultados do mapeamento sistemático. E por último, na
seção 5 são descritas as considerações finais sobre o artigo e as lacunas a serem
estudadas em pesquisas futuras com o intuito de complementar o conhecimento gerado
por este trabalho.
2. Referencial Teórico
Redes neurais artificiais são modelos computacionais inspirados pelo sistema nervoso
central de um animal, que são capazes de realizar o aprendizado de máquina, bem como
o reconhecimento de padrões. Redes neurais artificiais geralmente são apresentadas
como sistemas de "neurônios interconectados que podem computar valores de
entradas"[F.A.C. Azevedo et al, 2009].
Deep Learning é uma subcategoria de redes neurais artificiais que corresponde a
oportunidades de aprendizagem profundas com o uso de redes neurais para melhorar
algumas funcionalidades, tais como reconhecimento de fala, visão computacional e
processamento de linguagem natural. Além disso a Deep Learning tem se tornado uma
das áreas mais estudadas na computação moderna.
Outra ferramenta computacional estudada neste artigo foi a Interface
Cérebro-Computador(BCI), que pode ser descrito de forma mais detalhada como “um
caminho comunicativo direto entre o cérebro e um dispositivo externo” ou como “um
sistema de inteligência artificial que usa sinais de controle coletados a partir da atividade
eletroencefalográfica”. BCI são direcionados para auxiliar, aumentar ou reparar a
cognição humana ou as funções sensório-motor[Liu, J. et al, 2015].
3. O Mapeamento Sistemático
O Mapeamento Sistemático surgiu da base da engenharia de software e é apontado
como uma das metodologias, que se baseia em evidências para realização de pesquisas.
A etapa de criação do mapa representativo do conhecimento estudado é uma das
atividades mais difíceis de ser realizada pela falta de um processo claro e de uma
ferramenta que o apoie, pois nem sempre o acesso ao conhecimento que já foi gerado
naquele estado da arte é livre. Por conta disso, os Mapeamentos Sistemáticos são
427
Anais Eletrônicos
realizados utilizando como principal ferramenta avaliativa que apoia os pesquisadores na
produção de revisões sistemáticas. Os resultados do Mapeamento Sistemático
apresentados neste trabalho seguem um conjunto de diretrizes [Kitchenham et al, 2007],
que têm por objeto a identificação e sumarização sobre o uso de redes neurais no
processo de eletroencefalograma. É composto por 3 etapas, planejamento , execução e
sumarização.
3.1 Planejamento
Buscando direcionar esforços durante o levantamento e compreensão dos estudos
primários sobre o uso das redes neurais no processo de eletroencefalograma, foram
utilizadas questões de pesquisa a fim de satisfazer a mesma ao final do mapeamento
sistemático. A revisão sistemática deve ser realizada com o objetivo primário de
responder essa questão. Então é necessário formular uma string que possa contemplar os
trabalhos que atendam à questão de busca. Para tanto, alguns grupos devem ser
atendidos.
Foram utilizados 3 conceitos principais, os quais já foram mencionados na seção
de introdução deste artigos, para a formulação das palavras-chave que resultaram na
string final. Os conceitos utilizados foram os de Eletroencefalograma, que remete ao
exame que analisa a atividade elétrica cerebral, captada através da utilização de
eletrodos colocados sobre o couro cabeludo; Neural Network, o qual remete às técnicas
computacionais de redes neurais(deep learning), que apresentam um modelo
matemático inspirado na estrutura neural de organismos inteligentes e que adquirem
conhecimento através da experiência; e BCI, que refere-se à ferramentas
computacionais que visam criar um caminho entre cérebro e computador a fim de
corrigir falhas na cognição humana.
Por fim, apresento a questão de pesquisa e suas subquestões que guiaram este trabalho.
Tabela 1 - Questões e Subquestões de pesquisa
Questão de Pesquisa e Subquestões
Há aplicação utilizando redes neurais com Deep Learning em EEG?

Quais as áreas sofreram melhoria após os trabalhos?
Quais os anos possuem mais publicações envolvendo os temas
abordados?
Há algum engineer implementado os trabalhos?

Baseado nas questões de pesquisa, utilizou-se o critério PICOC(Population,
Intervention, Comparison, Outcomes, Context) [Petticrew and Roberts 2008] para
elaboração da String de pesquisa A String de pesquisa utilizada para encontrar os EP
foram utilizados os critérios população, intervenção, resultados e contexto utilizada para
encontrar os EP.
3.1.1 Estratégia de Pesquisa

A estratégia de pesquisa se inicia através da formação da string de pesquisa que será
utilizada para realizar as buscas nas bibliotecas digitais. As etapas realizadas neste
Mapeamento sistemático serão discutidas a seguir.
428
Anais Eletrônicos
3.1.1.2 String de Busca

O processo de construção da string de pesquisa foi realizado em 3 etapas, inicialmente
foram identificados os termos chaves contidos em Eletroencephalogram e Neural
Network. Foram identificados sinônimos ou palavras alternativas para cada termo
encontrado na primeira etapa e foi usado o conectivo lógico OR para ligar os termos;
após a realização da segunda etapa os termos de Eletroencephalogram foram conectados
com cada termo de Neural Network, os termos resultantes foram ligados através do
conectivo AND.
Tabela 2 - Construção da String de Pesquisa
Etapa Resultado
Etapa 1 População: EEG e Intervenção : tool

População: electroencephalogram, brain-computer, brain-computer
Etapa 2 interface, brain interface, BCI, deep learning
( "electroencephalogram" ) OR ( "EEG" ) ) AND ( "deep learning" )

Etapa 3 AND ( "BCI" ) OR ( "brain-computer" ) OR ( "brain-computer interface" )
OR ( "brain interface" ) ) )

Para a realização da pesquisa foi utilizada apenas uma base de dados, Scopus.
Esta foi escolhida, devido a sua relevância na questão de acervo de artigos. Com base na
sintaxe do Scopus e nas keywords já mencionadas anteriormente, a String de busca
utilizada para a pesquisa foi a que está representada na tabela 3.
Tabela 3 - String de Busca
String de Busca
( ( TITLE-ABS-KEY ( "electroencephalogram" ) OR TITLE-ABS-KEY ( "EEG" ) ) AND
TITLE-ABS-KEY ( "deep learning" ) AND ( TITLE-ABS-KEY ( "BCI" ) OR
TITLE-ABS-KEY ( "brain-computer" ) OR TITLE-ABS-KEY ( "brain-computer interface" )
OR TITLE-ABS-KEY ( "brain interface" ) (PUBYEAR > 2012) AND( PUBYEAR < 2017)))
3.1.1.3 Processo de Seleção dos Estudos

A tabela 4 define os critérios de Inclusão e Exclusão utilizados para a seleção de quais
artigos seriam utilizados para a extração de dados e consequentemente a sumarização
dos resultados.
O processo de seleção de estudos foi realizado em duas fases.
I. Leitura de títulos e resumo: Nesta etapa, os pesquisadores aplicaram os critérios de
inclusão e exclusão no título e resumo de todos os artigos encontrados da base Scopus
candidatos à estudos primários identificados durante a pesquisa.
II. Leitura completa dos trabalhos: Nesta etapa, os pesquisadores fizeram leitura
completa dos artigos que restaram após a primeira etapa da seleção de estudos.
Tabela 4 - Critérios de Seleção das publicações
429
Anais Eletrônicos
Critérios de Inclusão
Fossem escritos em Inglês
Possuir palavras da expressão em seu título e/ou resumo
Ter sido publicado nos últimos 5 anos(2013, 2014, 2015, 2016, 2017)
Trabalhos que abordam sobre redes neurais no processo de EEG
Trabalhos que possuem como temática algumas das técnicas já citadas.
Critérios de Exclusão
Estivessem disponíveis somente em forma de resumos
Trabalhos hospedados em serviços pagos não financiados pela universidade.
3.1.1.4 Processo de Extração dos Dados

A seleção dos trabalhos da base Scopus foram feitos manualmente. A extração das
informações relevantes foi realizada pelos pesquisadores com o auxílio de planilhas
eletrônicas contendo campos gerais (título, autores, ano etc.) e contendo campos
específicos para cada questão de pesquisa. Os dados foram sintetizados para cada
questão de pesquisa.
3.2 Execução
A tabela 5 detalha os resultados da pesquisa obtidos após a aplicação da String de
Busca, e por conseguinte as 2 etapas descritas na seção 3.1.2.
Tabela 5 - Resultados da Pesquisa
Publicações Publicações Selecionadas
Biblioteca Digital Retornadas
Primeira Etapa Segunda Etapa
Scopus 64 50 24
Total de Publicações Extraídas 24
I. Leitura de títulos e resumo: Dos 64 trabalhos, 50 foram aceitos pelos pesquisadores

e em nenhuma das avaliações dos trabalhos houve discordâncias entre os pesquisadores
na seleção.
II. Leitura completa dos trabalhos: Nesta etapa, dos 50 trabalhos aceitos, 10 foram
removidos por estarem disponíveis somente em forma de abstracts ou resumos
expandidos e 14 foram removidos após a leitura das seções de introdução e conclusão,
resultando em 24 trabalhos aceitos na base de estudo Scopus.
3.3 Sumarização
A etapa de sumarização em um mapeamento sistemático é utilizada a fim de facilitar a
visualização dos resultados obtidos na extração dos dados os quais respondem a questão
e as subquestões de pesquisa. Além de dar a possibilidade de conclusões mais precisas
sobre os mesmos.
3.3.1 Publicações por ano
Ao verificar as publicações selecionadas, em relação ao número de publicações por ano,
pode-se verificar um número muito pequeno de pesquisas nesta área, ou seja, há um
430
Anais Eletrônicos
leque muito grande ainda a ser explorado. Isso significa que as pesquisas sobre o uso
das Redes Neurais(Deep Learning) no processo de Eletroencefalograma vêm ganhando
espaço nas pesquisas e devem aumentar ainda mais. A Figura 1 apresenta o número de
publicações identificadas por ano.

Figura 1 - Publicações por ano
3.3.2 Setores aprimorados pelas publicações

A Figura 2 o gráfico descreve quais setores da pesquisa(Redes Neurais do tipo Deep
Learning, EEGs ou BCI) foram analisadas e modificadas, por meio de alterações no
modelo de treinamento das redes neurais, mudanças de critérios para a captação de
sinais dos EEGs ou pelos ajustes na transmissão feita pelo BCI utilizado e pelos autores
a fim de obter melhores resultados finais contribuindo para o avanço no aproveitamento
dos resultados obtidos por EEGs.

Figura 2 - Publicações por áreas aprimoradas
3.3.3 Utilização de engineers nas publicações

Dos 24 artigos restantes após todos os processos de seleção, 12 deles utilizaram algum
tipo de engineer durante a pesquisa descrita nos mesmos.Apenas o MATLAB teve
aparição em mais de um trabalho, os outros trabalhos utilizaram ferramentas distintas.

431
Anais Eletrônicos
4. Discussão dos resultados

Ao verificar as publicações selecionadas, em relação ao número de publicações por ano,
pode-se verificar um número muito pequeno de pesquisas nesta área, ou seja, há um
leque muito grande ainda a ser explorado. Isso significa que as pesquisas sobre o uso das
Redes Neurais(Deep Learning) no processo de Eletroencefalograma vêm ganhando
espaço nas pesquisas e pode aumentar ainda mais. É possível detalhar problemas
resolvidos e descritos em dois artigos retornados após todos os processos de seleção, e
que consequentemente ressaltam a eficiência da aplicação de Redes Neurais do tipo
Deep Learning e BCI para a melhoria do exame de EEG.
Primeiramente, citamos o artigo cujo título é “A novel deep learning approach
for classification of EEG motor imagery signals”. Este trabalho tinha como objetivo
utilizar os métodos do Deep Learning para melhorar o desempenho de classificação
dos sinais extraídos do EEG de pessoas fazendo movimentos imaginários[Tabar Y.R
and Halici U. 2017]. Como resultado, a rede proposta pelos autores obteve melhores
resultados de desempenho do que a redes profundas prontas introduzidas para extração
de recursos. A rede realizou a classificação rapidamente e com um desempenho mais
elevado do que outros métodos na literatura por um treinamento, apesar de utilizar
apenas algumas amostras.
Por fim, o artigo “Expanding the (kaleido) scope: exploring current literature
trends for translating electroencephalography (EEG) based brain computer
interfaces for motor rehabilitation in children”. Como o próprio título descreve, o
artigo citado anteriormente tinha como objetivo explorar na literatura trabalhos que
tivessem utilizado a tecnologia dos BCIs para ajudar na reabilitação motora de
crianças.[Kinney-Lang et al, 2016]
A neuroreabilitação por BCI se mostrou eficaz ao explorar as propriedades
neurológicas do cérebro através de tarefas de imagens mentais. No entanto, essas
aplicações e resultados estão atualmente restritos a adultos, visto que não existe,
essencialmente, literatura que descreve aplicações BCI reabilitadoras de motor que
utilizem eletroencefalogramas (EEG) em crianças, apesar dos avanços em tais
aplicações com adultos.
Com base nos resultados obtidos, o objetivo do artigo que era fazer uma análise
interessante à respeito do estado da arte da área de pesquisa abordada e de suas
necessidades futuras, foi atingido. Concluímos que esta combinação de áreas e
ferramenta possui potencial promissor e deve ser mais explorada. Em relação aos
problemas e necessidades futuras abordados pela maioria dos artigos, a principal lacuna
encontrada foi a necessidade de maior base de dados, a fim de resultados finais mais
detalhados e convincentes além da possibilidade de maiores comparações entre os
resultados. Além disso, também é preciso que haja mais trabalhos que abordam em seus
métodos novas combinações em relação às redes neurais e seus algoritmos de
treinamentos.
432
Anais Eletrônicos
Referências
An, X., Kuang, D., Guo, X., Zhao, Y., He, L. (2014) “A deep learning method for
classification of eeg data based on motor imagery”. Lecture Notes in Computer
Science (including subseries Lecture Notes in Artificial Intelligence and Lecture
Notes in Bioinformatics), 8590 LNBI, pp. 203-210.
Azevedo FA, Carvalho LR, Grinberg LT, Farfel JM, Ferretti RE, Leite RE, Jacob Filho
W, Lent R, Herculano-Houzel S.(2009) “Equal numbers of neuronal and nonneuronal
cells make the human brain an isometrically scaled-up primate brain”, Instituto de
Ciências Biomédicas, UFRJ, Rio de Janeiro, Brazil.
Becker, K., Sinzig, J.K., Holtmann, M. (2004)”Attention deficits and subclinical
epileptiform discharges: Are EEG diagnostics in ADHD optional or essential?'
Developmental Medicine and Child Neurology, 46 (6), pp. 431-432.
E. Nurse, Benjamin S. Mashford, Antonio J. Yepes, I. Kiral-Kornek, S. Harrer (2016)
"Decoding EEG and LFP signals using deep learning: heading TrueNorth" CF '16
Proceedings of the ACM International Conference on Computing Frontiers Pages
259-266, Italy.
Kinney-Lang, E., Auyeung, B., Escudero, J. (2016) “Expanding the (kaleido)scope:
Exploring current literature trends for translating electroencephalography (EEG)
based brain-computer interfaces for motor rehabilitation in children” Journal of
Neural Engineering, 13 (6), art. no. 061002, .
Kitchenham, B. & Charters, S. (2007) “Guidelines for performing systematic literature
reviews in software engineering, Technical Report” EBSE-2007-01, School of
Computer Science and Mathematics, Keele University.
Liu, J., Cheng, Y., Zhang, W. (2015) “Deep learning EEG response representation for
brain computer interface” Chinese Control Conference, CCC, 2015-September, art.
no. 7260182, pp. 3518-3523.
Petticrew M., Roberts H. (2008) “Systematic reviews–do they ’work’ in informing
decision-making around health inequalities?” Health economics, policy, and law, 3
(Pt 2). pp. 197-211. ISSN 1744-1331 DOI: 10.1017/S1744133108004453
Tabar, Y.R., Halici, U.(2017)”A novel deep learning approach for classification of EEG
motor imagery signals” Journal of Neural Engineering, 14 (1), art. no. 016003, .
Young, B.M., Nigogosyan, Z., Nair, V.A., Walton, L.M., Song, J., Tyler, M.E., Edwards,
D.F., Caldera, K., Sattin, J.A., Williams, J.C., Prabhakaran, V. (2014) “Case report:
Post-stroke interventional BCI rehabilitation in an individual with preexisting
sensorineural disability”. Frontiers in Neuroengineering, 7 (JUN), art. no. 18, .
433
Automação veicular: Um sistema de sensoriamento para

dispositivos móveis baseado em arduino
Alex A. Silva1 , Jhonatan F. de Oliveira2 e Daniel R. S. Ribeiro1
1
Faculdade de Ciência da Computação – Fundação Universidade de Itaúna (UIT)
Caixa Postal 100 – 35.680-142 – Itaúna – MG – Brasil
2
Faculdade de Engenharia da Computação – Universidade do Estado de Minas Gerais (UEMG)
Av. Paraná – 3001 – Jardim Belvedere 35.501–170 – Divinópolis – MG – Brasil
[email protected]
Abstract. Through the worldwide vehicle trade environment, there is a lack of

accessibility in popular cars, there is a need to think about getting a viable new
technology to be integrated into the car. In this context, it is presented an idea of
developing a mobile application a being integrated by means of a board with a
microcontroller. IoT concepts, automation, optimization, integration of systems
and platforms, as well as the use of advanced design standards and practices
are included in this work.
Resumo. Através do ambiente mundial do comércio de veı́culos, nota-se a falta

de acessibilidade em carros populares. Deste modo surge a necessidade de se
pensar em obter uma nova tecnologia, viável, para ser integrada ao automóvel.
Nesse contexto, apresenta-se a ideia de desenvolver uma aplicação móvel, a ser
integrada por meio de uma placa com um microcontrolador. Aborda-se nesse
trabalho os conceitos de IoT, automação, otimização, e integração de sistemas
e plataformas, além de utilizar padrões e práticas, de projeto, avançadas.
1. Introdução
Pode-se conferir cada vez mais a tecnologia atuando em nosso ambiente, seja ela em
casa, no trabalho e nos trajetos feitos no dia-a-dia. Essa é uma realidade a qual, parte
dela, se dá pelo conceito de internet das coisas, onde tudo pode estar interligado em rede.
Exemplos disso, seria projetos como Casa Inteligente empregando a automação residen-
cial, a qual consiste em equipar uma casa com uma gama de dispositivos voltados para a
gestão de energia, conforto, automação de tarefas domésticas, sistemas de áudio, vı́deos
e iluminação [Elétrica 2015], Automação veicular, onde apresenta-se um veı́culo, como
um carro, composto por componentes responsáveis por controlar alguma funcionalidade
do veı́culo, como vidros elétricos, ignição e faróis, ou por enviar informações, como con-
sumo de combustı́vel e velocidade média em algum trecho e softwares de controle de
exercı́cios fı́sicos, como a corrida, os quais são responsáveis por identificar o percurso
feito, exibir a distância percorrida juntamente com o tempo gasto, velocidade média e
outros tipos de informações relevantes para o usuário.
Para realização de projetos, cujo apresenta-se o emprego de conceitos de IoT (In-
ternet of Things), pode-se utilizar plataformas de prototipagem eletrônica como o Ar-
duino ou Raspberry, os quais são placas compostas por um microcontrolador e, também,
434
smarthphones com o sistema operacional Android e alguns recursos integrado, como o

GPS (Global Positioning System) e bluetooth.
Internet das Coisas, termo criado por Kevin Ashton, pioneiro tecnológico
britânico [Elétrica ], é uma ampla rede de dispositivos conectados à internet, onde tro-
cam e reúnem informações visando a automatização de funcionalidades [SAP ].
Diante deste cenário, os termos inovação e tecnologia estão, cada vez, conquis-
tando diversas áreas, como educação, comércio, industriais, aviação e automobilı́sticas,
onde o seu investimento é fundamental para o desenvolvimento das mesmas. Analisando
este aspecto, torna-se necessário a aplicação de novas tecnologias em setores como os
mencionados, com o objetivo de maximizar a procura, visibilidade e desenvolvimento.
Diante do quadro apresentado, visa-se obter alternativas para automatizar veı́culos
populares, com o principal motivo o aumento da acessibilidade, propondo uma integração
de uma aplicação móvel a um automóvel interligados por uma placa Arduino, empregando
um ambiente com conceitos presentes na automação e otimização.
Por fim, almejando atingir o objetivo principal o qual é o emprego de uma
automatização em um veı́culo utilizando uma aplicação móvel, tem-se que analisar como
é o funcionamento da parte elétrica do veı́culo para realizar a ligação do mesmo com a
placa de prototipagem, apontar o método de comunicação entre as tecnologias, identificar
as linguagens de programação a serem utilizadas para desenvolver o protótipo, baseado
em pesquisas realizadas, voltado para a automatização.
O restante do trabalho está organizado da seguinte forma. A Seção 2 apresenta os
trabalhos relacionados utilizados para o desenvolvimento do projeto. A Seção 3, exibe a
solução proposta, juntamente com detalhes e algoritmos utilizados. A Seção 4, apresenta
o cenário abordado e os resultados obtidos por meio de pesquisas. Finalizando, a Seção 5
apresenta as conclusões e alguns projetos futuros para este trabalho.
2. Trabalhos Correlatos
A utilização de sistemas baseados em IoT está cada vez mais comum e necessário, devido
a necessidade de se ter todas as informações na nuvem. Na literatura pode-se encon-
trar várias pesquisas relacionadas ao tema, além de ainda existir produtos já no mercado
disponibilizados para o uso.
No dia 21 de junho de 2017, o site btcsoul anunciou que as empresas IBM e
AOS firmaram uma parceria com o intuito de construir um blockchain para rastrear a
proveniência e o status de caminhões e seus produtos, onde registra o tratamento de
transações e informações sobre as cargas para ter-se maior transparência no processo de
entrega [Chrys 2017].
Firmando o fato de que a tecnologia está avançando maiores campos as fabrican-
tes de automóveis Tesla, Toyota e Volvo têm-se mantido o foco no desenvolvimento de
veı́culos que podem interagir com os ambientes [Econômico 2017]. O caminho para isso
é implantar o sistema de biometria nos veı́culos, onde o mesmo poderá identificar quem
é o usuário e o ambiente. Segundo a Equipe de Mobilidade Inteligente da Frost Sullivan,
um terço dos veı́culos novos terá sensores biométricos até 2025.
No meio automobilı́stico, o termo tecnologia se torna comum, onde visa-se sem-
435
pre o seu avanço. Levando isso em conta, tem-se buscado cada vez mais a automatização
neste ambiente e um fato que pode-se confirmar isto é a implantação de semáforos inte-
ligentes, o qual controla-se o seu tempo de acordo com o fluxo de veı́culos presentes na
via. Este sistema utiliza o Google Maps para identificar onde há mais veı́culos e deixa o
sinal aberto por mais tempo [do Paraı́ba e região 2017].
Na literatura, pode-se encontrar, também, diversos trabalhos que tem-se como
tema a utilização de IoT no ambiente veicular. Um exemplo disso é o trabalho de desen-
volvimento de sistema de rastreamento de veı́culos usando GPS e modem GSM (Global
System for Mobile Communications), onde visa-se o rastreio do veı́culo, remotamente,
através da rede móvel. Com o número de veı́culos crescendo significativamente devido às
economias crescentes, há falta de sistemas de rastreamento e apresentou-se a necessidade
de algo semelhante para ter-se maior segurança com os veı́culos, sejam eles pessoais ou
públicos e também algo mais acessı́vel a população [Pham et al. 2013].
3. Metodologia e Desenvolvimento
O sistema será composto por uma aplicação móvel, destinada para usuários finais, onde
possibilita-se o controle de alguns comandos destinados ao veı́culo, como acionar a
ignição e os faróis, e uma placa de prototipagem eletrônica, chamada arduino, responsável
por receber os comandos enviados pelo smartphone e realizar as devidas ações no veı́culo.
A comunicação entre as plataformas se dará via bluetooth.
Para os testes foi utilizado o smartphone Asus Zenfone 2 Deluxe, o Arduino Uno
R3, para a realização dos comandos e transmissão de dados foi utilizado um módulo
relé de 8 canais de 5V cada e um módulo bluetooth Hc06, os quais podem ser vistos na
Figura 1, e para os testes reais em veı́culo, foi utilizado o veı́culo Gol G4 2013/2014.
Figura 1. Componentes utilizados.

Fonte: Próprio Autor
436
Um esboço da arquitetura do sistema conferi-se na Figura 2. Pode-se constatar

que o usuário faz requisição de alguma ação, o dado dessa ação é serializado e enviado
via conexão bluetooth para a placa, a qual recebe este dado referido e o desserializa para
poder identificar qual função ela deverá executar no veı́culo, seja acionar ignição ou farol
baixo, por exemplo.
Os dados enviados são números, onde cada número representa uma ação a ser
executada pela placa. Por exemplo, ao acionar no aplicativo a função de acionar ignição,
é enviado o número 1 (um) para a placa, a qual interpreta esse dado e realiza a função
referida.
Figura 2. Arquitetura do sistema desenvolvido.

A seguir será explicado, em subseções, um pouco de cada tecnologia desenvol-

vida, onde a subseção 3.1 apresenta a placa arduino e a subseção 3.2 a aplicação móvel.
3.1. Placa Arduino

O Arduino é uma plataforma que possibilita a prototipagem eletrônica de projetos de
hardware livre. A placa Arduino é composta de um microcontrolador Ateml, circuitos de
entrada e saı́da que podem ser conectados a um computador. A fase inicial do projeto e
a realização de testes, foi utilizado uma placa Uno e um módulo bluetooth HC06 para a
comunicação entre o smartphone e o circuito elétrico do automóvel. A composição do
projeto contou com uma protoboard de 400 pontos matriz de contato, onde é conectado
o módulo bluetooth HC06 e ligada a placa por jumpers recebendo os sinais da aplicação
android. A aplicação android comunica via bluetooth do smarthphone enviando caracte-
res entre números e letras para o módulo bluetooth HC06, caracteres que são repassados
para o arduino onde aciona a porta especifica para cada função, acionando o travamento
das portas, abertura e fechamento dos vidros elétricos ou acionando a partida e desliga-
mento do automóvel. A placa conectada ao sistema elétrico do carro proporciona varias
possibilidades de controle e monitoramento do consumo ou segurança do veı́culo.
437
Figura 3. Esboço final do arduino, juntamente com a protoboard utilizada.

3.2. Aplicação Móvel

O aplicativo foi desenvolvido na linguagem Java, a qual é nativa do Android, com isso
torna-se o software disponı́vel apenas para celulares cuja a plataforma seja Android, com
o intuito de disponibilizar uma aplicação para usuários finais, para que os mesmos pos-
sam executar os comandos através de smartphones. Um esboço da interface gráfica do
aplicativo pode ser constatada na Figura 4. No desenvolvimento, utilizou-se o padrão de
arquitetura MVC (Model-View-Controller) e a programação orientada a objetos, objeti-
vando a facilidade de leitura e manutenibilidade do código.
Figura 4. Interface gráfica da aplicação móvel.

Ao executar o aplicativo, é verificado e acionado, automaticamente, o bluetooth

do dispositivo, deixando-o preparado para uma possı́vel conexão e, consequentemente,
438
transmissão de dados. Ao acionar algum botão, o qual seja referente a alguma ação a ser
executada no veı́culo, o dispositivo móvel procura algum outro dispositivo para se conec-
tar, já pré-definido, o qual é o arduino. Ao obter êxito na conexão, os dados referentes são
serializados e transmitidos ao arduino, para, posteriormente serem traduzidos e executar
as devidas ações.
4. Resultados
Como demonstração dos resultados, realizou-se uma entrevista com 31 pessoas, de dis-
tintos locais e idades, as quais foram submetidas a responder a algumas questões. Dentro
das questões propostas foram avaliados, de uma escala de 1 a 10, os seguintes itens:
• Nı́vel de usabilidade do aplicativo, o qual é o grau de facilidade com que os

usuários obtiveram para aprender a operar o aplicativo. Onde 29% das pessoas
entrevistadas atribuı́ram nota 7;
Figura 5. Nı́vel de Usabilidade.
• Nı́vel de dificuldade ao manusear o software. Onde, também, 29% das pessoas

entrevistadas atribuı́ram nota 1, alegando não haver dificuldades;
Figura 6. Nı́vel de dificuldade para operar o sistema.
• Nı́vel de facilidade para operar as funções do veı́culo. O qual 29% dos entrevista-
dos atribuı́ram nota 1, constatando não haver nenhuma dificuldade.
439
Figura 7. Nı́vel de facilidade para operar o veı́culo.
• Probabilidade de indicação do sistema para outra pessoa. Onde 32,3% responde-

ram que indicaria o sistema, com certeza.
Figura 8. Probabilidade de indicação.
Além de resultados quantitativos, como exibido anteriormente, foram feitas

questões para propor sugestões e opiniões perante o sistema apresentado. Possibilitou-
se que os participantes citassem pontos negativos e positivos além de sugerir algumas
mudanças no aplicativo, seja acréscimo, decréscimo ou correção de algo.
Essa análise qualitativa do aplicativo, nota-se que 24 dos entrevistados relataram
que o sistema seria viável nos veı́culos próprios ou de terceiros. 12 pessoas relataram que
utilizaria o mesmo por causa da praticidade, facilidade e comodidade que o aplicativo iria
proporcionar, além de envolver questões de segurança e maior controle do veı́culo em um
único dispositivo. 3 pessoas, representando a maioria, disseram que um ponto positivo
relevante é a facilidade que o sistema proporciona e 2 pessoas, representando, também, a
maioria, relataram que a a segurança pode ser um ponto negativo do software.

Após realizada várias pesquisas para a criação do projeto, nota-se o grande impacto que
o setor de desenvolvimento de aplicações móveis envolvendo os conceitos de IoT está
impactando na sociedade e na tecnologia. Levando em conta esse fato, pode-se observar
440
que há falta de meios tecnológicos em alguns setores e em algumas classes sociais, como
é o caso de automação em veı́culos populares.
No desenvolvimento do sistema, pode-se concluir que há uma certa eficiência na
criação de aplicações móveis através de linguagens nativas, pois a mesma permite uti-
lizar mais recursos sobre a plataforma. Além disso, percebe-se que a comunicação via
bluetooth foi pouco eficiente, levando em consideração que seu alcance e sua veloci-
dade de transmissão é menor em comparação com o wifi [Jordão 2013], contudo o seu
custo/benefı́cio é menor [Kate T. 2017], o qual teve como objetivo o desenvolvimento de
um protótipo, onde visa-se a demonstração das funcionalidades empregadas.
Finalizando, esse sistema abre portas para diversas possibilidades, levando em
conta a sua capacidade de funcionar em diferentes plataformas. Algumas pretensões para
futuros trabalhos são a alteração da comunicação utilizada para Wifi, visando o aumento
da velocidade e do alcance para transmissão de dados, ampliação do campo de alcance
do aplicativo, tornando-o multi-plataforma, onde terá a disponibilidade para dispositivos
iOS, criação de novas funcionalidades como a possibilidade de rastrear o veı́culo e con-
trolá-lo, independente da localização do veı́culo e do smartphone e também a instalação
de uma funcionalidade para cortar o combustı́vel do veı́culo, em caso de possı́vel furto,
com o intuito de aumentar a segurança.
Referências
Chrys (2017). Ibm e aos: uso de blockchain para rastreamento de veı́culos. [Online;
accessed 17-agosto-2017].
do Paraı́ba e região, G. V. (2017). Semáforos ’inteligentes’ são implantados na avenida
dos astronautas. [Online; accessed 17-agosto-2017].
Econômico, B. (2017). Biometria nos veı́culos: veja como a experiência de transporte
será impactada. [Online; accessed 17-agosto-2017].
Elétrica, S. Internet das coisas. [Online; accessed 12-abril-2017].
Elétrica, S. (2015). Automação residencial e casa inteligente: Bem vindo ao futuro.
Jordão, F. (2013). Tecmundo explica: qual a diferença de bluetooth para wifi? [Online;
accessed 17-agosto-2017].
Kate T., Poonam S., P. S. N. J. I. B. K. G. (2017). Bluetooth vs. wi-fi. [Online; accessed
17-agosto-2017].
Pham, H. D., Drieberg, M., and Nguyen, C. C. (2013). Development of vehicle tracking
system using gps and gsm modem. In 2013 IEEE Conference on Open Systems (ICOS),
pages 89–94.
SAP. O que é a internet das coisas (iot)? [Online; accessed 12-abril-2017].
441
Um software para obtenção de resultados fidedignos ao Teste

de Caminhada de 6 minutos (TC6)
Pedro Luis Saraiva Barbosa1, Tulio Vidal Rolim2, Jorge da Silva Correia
Neto3, Walquiria Castelo branco Lins4
1
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE)
Cedro – CE - Brasil
2
Faculdade Vale do Salgado (FVS)
Icó – CE – Brasil
3
Universidade Federal Rural de Pernambuco (UFRPE)
Recife – PE - Brasil
4
Centro de Estudos e Sistemas Avançados do Recife (CESAR)
Recife – PE - Brasil
Abstract. The overall goal consists to develop and validate a software to

obtain reliable results in the execution of the six-minute walk test (6MWT). The
survey was conducted with a sample of 14 patients in a non-probabilistic way
in the Clinical of Faculty Dr. Leão Sampaio. This study concluded that the use
of the accelerometer, encapsulated in the mobile device, can be used to
measure distance and that the OSFisio Client proved to be a good alternative
for the automation of the 6MWT, facilitating the work of professionals that
applies the test, by performing the necessary calculations in addition to the
distance measurement and finally displaying the diagnosis if either the patient
is within their normal range or not.
Resumo. O objetivo geral consiste em desenvolver e validar um software para
obter resultados confiáveis na execução do teste de caminhada de seis minutos
(TC6). A pesquisa foi conduzida com uma amostra de 14 pacientes de forma
não probabilística na Clínica da Faculdade Dr. Leão Sampaio. Este estudo
concluiu que o uso do acelerômetro, encapsulado no dispositivo móvel, pode
ser usado para medir a distância e que o Cliente OSFisio provou ser uma boa
alternativa para a automação do TC6 facilitando o trabalho dos profissionais
que aplicam o teste, realizando os cálculos necessários, além da medição da
distância e finalmente exibindo o diagnóstico se o paciente estiver dentro do
seu alcance normal ou não.
1. INTRODUÇÃO
O Teste de Caminhada de 6 minutos (TC6) mede a capacidade funcional dos pacientes,
sendo efetuado por profissionais da área de saúde, comumente por Fisioterapeutas. O
teste, habitualmente é realizado de forma manual e tem por objetivo identificar a
capacidade funcional do paciente, isto é, o quanto de distância o sujeito consegue atingir
no intervalo de seis minutos. A avaliação do TC6 é recomendado para identificação de
442
doenças pulmonares obstrutiva crônicas (DPOC) (RODRIGUES et al, 2004).

O teste de caminhada de seis minutos geralmente é executado em ambientes
fechados, no qual a precisão do GPS é falha. Por meio disso, uma proposta mais
adequada seria utilizar acelerômetros triaxiais, pois pode-se analisar a variação dos
eixos x, y e z ao movimentar o dispositivo, que, com o auxílio de um algoritmo eficaz
consegue-se identificar o passo.
O problema desta pesquisa está relacionado com a confiabilidade de um método
utilizado de forma manual, concebido neste trabalho de forma automática a fim de
identificar se os resultados continuarão fidedignos ao teste.
Este trabalho objetiva desenvolver e validar um software que apresente
resultados fidedignos na execução do Teste de Caminhada de Seis Minutos (TC6). Para
isso, faz-se necessário acompanhar e analisar a execução do TC6 junto de especialistas,
desenvolver um software que atenda à realidade observada e por fim, aplicar o software
para se obter os resultados e comparar com métodos manuais a fim de perceber a
fidedignidade.
As seções posteriores do trabalho organizam-se da seguinte forma: a seção 2
apresenta a fundamentação teórica e o estado da arte utilizado no trabalho; a seção 3
aborda o software OSFisio de maneira detalhada; a seção 4 contém a metodologia
utilizada no trabalho; a seção 5 apresenta a análise dos resultados; por fim, a seção 6
apresenta a conclusão do trabalho.
2. FUNDAMENTAÇÃO TEÓRICA
O TC6 representa de maneira mais aprimorada as limitações às atividades diárias, e
mostrou-se mais considerável que os testes em esteiras (MORALES-BLANHIR, 2011).
Morales-Blangir (2011), corrobora que o TC6 mede de forma objetiva a dessaturação de
oxigênio durante o exercício de pacientes com doenças pulmonares. Por ser um teste
submáximo e fidedigno é um instrumento confiável para realização de avaliações do
sistema de cardiopatas.
Em 2002, foi publicado pela American Thoracic Society - ATS1 as diretrizes
para a realização do TC6, explicitando que o TC6 deve por precaução, ser realizado em
locais que possuam facilidade de acesso em caso de emergência, pois pacientes que
realizam os testes podem sofrer de patologias cardiovasculares que limitam o esforço
físico. Pesquisas realizadas em Osaka-Japão, pela National Cardiovascular Center
demonstra que a Distância do Teste de Caminhada de 6 minutos – DTC6 é um fator
importantíssimo na avaliações de mortalidade de pessoas com hipertensão
(MIYAMOTO, 2010).
1
http://www.thoracic.org/
443
Figura 1. Ambiente para realização do TC6

Fonte: GILEAD (2008).
Para avaliar a normalidade de um paciente foram apresentados na literatura

alguns cálculos que predissesse a distância para indivíduos, baseados na altura, no
gênero, na idade e peso. A seguir está a fórmula apresentada por Enright (1998 apud
BRITTO, 2006):
Homens:
DP = (7.57 x altura cm) - (5.02 x idade) - (1.76 x peso Kg) - 309m.
Subtrair 153m para obter o limite inferior de normalidade.
DP = distância prevista no teste de caminhada de 6 minutos.
Mulheres:
DP = (2.11 x altura cm) - (2.29x peso Kg) - (5.78 x idade) + 667m.
Subtrair 139m para obter o limite inferior de normalidade.
Antes do teste ser iniciado deve-se colher as informações sobre a pressão
arterial, peso, altura, idade e gênero do sujeito. Estas informações são importantes para
definir algumas limitações do paciente durante o teste, como por exemplo, a frequência
cardíaca máxima alcançada e a distância predita. Durante o teste, o paciente caminha
durante seis minutos em um ambiente demarcado em 30 metros com cones, andando em
círculos. Ao final da caminhada é necessário obter informações do tempo em minutos e
a distância percorrida em metros com precisão. Baseado nesses dados, é verificado se o
paciente atingiu a distância predita, caso sim, o mesmo está dentro de sua normalidade,
ao contrário, está fora de sua normalidade.
A caminhada pode ser interrompida pelo Fisioterapeuta, Paciente ou finalizada
quando chega aos seis minutos cronometrados. O fisioterapeuta pode decidir encerrar a
caminhada ao perceber que o paciente não possui condições necessárias para a sua
realização, como por exemplo, se o sujeito atingir a frequência cardíaca máxima. O
Paciente pode decidir parar o teste ao perceber que não tem condições fisiológicas para
prosseguir (GILEAD, 2008).
Há alguns software similares ao que se propõe esta pesquisa, mas nenhum foi
encontrado com a arquitetura definida para este sistema, o qual utiliza de conexão
bluetooth para oportunizar ao profissional verificar em tempo real o estado do sujeito
que está executando o teste. Abaixo é demonstrado alguns software disponíveis no
mercado.
O 6MWT auxilia na execução do TC6 e está disponível em três idiomas: inglês,
espanhol e italiano (6MWT, 2017). Quando o teste finaliza o aplicativo emite um som
que alerta o usuário, calcula automaticamente as medições e transfere os dados para um
arquivo no dispositivo. O aplicativo cobra uma taxa única para que o usuário possa
utilizá-lo e está disponível na loja de aplicativos para Android Play Store.
Capela, Lemaire e Baddour (2014), produzem um aplicativo para auxiliar no
TC6 para o smartphone BlackBerry, nesse trabalho o smartphone é utilizado na parte
inferior das costas enquanto o usuário caminha. Foi utilizado com 5 participantes
válidos, e a distância calculada pelo aplicativo estava a menos de 1 metro de diferença
da distância medida manualmente. Conclui-se que um smartphone, pode ser utilizado
para esta finalidade.
444
O WalkTest executa um teste de caminhada de 2 ou 6 minutos, após o teste,

relatórios biomecânicos são gerados e podem ser convertidos no formato PDF (TOHRC
Walk Test, 2017). Os detalhes sobre o método utilizado pelo WalkTest foram
publicados por Capela, Lemaire e Baddour (2015), que desenvolveram um algoritmo e
validaram-o através de uma amostra de 15 participantes válidos, concluindo que é
possível utilizar um smartphone ao invés de um dispositivo dedicado para fornecer
resultados clinicamente relevantes ao TC6.
3. OSFISIO
O Our Source Fisioterapia (OSFISIO) é uma proposta de software para auxiliar
profissionais da área da saúde, especificamente os Fisioterapeutas, a realizarem o TC6
(Teste de Caminhada de 6 minutos) com pacientes. Atualmente o teste é realizado
manualmente.
As funcionalidades do OSFisio estão descritas a seguir:
● (1) Iniciar Caminhada;
● (2) Cronometrar o tempo e a distância da caminhada;
● (3) Realizar os cálculos de distância predita e frequência cardíaca máxima;
● (4) Finalizar caminhada.
O OSFisio divide-se em duas aplicações que se comunica. Uma aplicação
servidora (OSFisio Server), na qual será armazenado os dados de acompanhamento, e
uma aplicação cliente (OSFisio Client) que poderá ser executada no modo
Fisioterapeuta ou Paciente. Na Figura 2 pode-se analisar a ilustração da arquitetura do
OSFisio.
Figura 2. Arquitetura OSFisio

Fonte: Elaborada pelo Autor
3.1 OSFISIO
O OSFisio Server é responsável por disponibilizar ao OSFisio Client uma interface para
conexão com o banco de dados, além de gerar relatórios sobre os testes armazenados.
Através desta aplicação pode-se também manipular dados sobre os
usuários/fisioterapeutas e pacientes. As informações sobre os testes realizados são
apenas para consulta nesta aplicação. A conexão entre o dispositivo que executa o
OSFisio Client e o OSFisio Server é feita por meio de web services. O OSFisio Server
não é ferramenta de estudo deste trabalho.
No OSFisio Client temos a presença de dois dispositivos móveis, sendo a
comunicação entre eles realizada pela tecnologia bluetooth, que conecta dispositivos
que estão há uma pequena distância. A tecnologia foi preferível por menos riscos de
interferência.
445
Esta aplicação possui dois modos: o modo paciente e o modo fisioterapeuta. No

OSFisio Client Fisioterapeuta, o dispositivo estará nas mãos do profissional
acompanhando em tempo real a distância do paciente. No início do teste deve ser
informado a esta aplicação informações como: peso, idade, altura, e sexo. A necessidade
desses dados, se dá pela geração da distância predita do paciente de forma automática.
No OSFisio Client Paciente, é necessário que dispositivo esteja fixado na
panturrilha da perna direita ou esquerda. A aplicação utiliza o acelerômetro do celular
para medir a distância, identificando cada passo dado, e ao final multiplicando a
quantidade de passos pela média em centímetros destes.
4. METODOLOGIA
Por se tratar de uma técnica onde os possíveis benefícios ainda estão sendo
investigados, surgiu a necessidade de realizar um estudo exploratório através da
pesquisa experimental.
Todos os pacientes julgados pelos especialistas necessários a realizar o teste no
período desta pesquisa o fizeram com o auxílio do software OSFisio. Cada teste foi
realizado com no mínimo dois fisioterapeutas e um estudante de fisioterapia. Um dos
fisioterapeutas utilizava o software instalado em um celular para controlar a caminhada
em intermédio ao software, instalado em outro celular fixado na panturrilha do paciente,
o qual contava os passos do mesmo transmitindo via bluetooth para o celular nas mãos
do fisioterapeuta a distância que estava sendo percorrida. Outro fisioterapeuta era
responsável por resolver os cálculos que resultava em frequência cardíaca máxima e
distância predita. O terceiro, um aluno do 8º semestre de fisioterapia, em processo de
estágio, contava o número de voltas que o paciente realizava, ao final, multiplicava o
número de voltas por 30 para chegar a distância percorrida em metros. Por fim, os
resultados dos cálculos e distância do software eram confrontados com os feitos pelos
especialistas.
Os sujeitos da pesquisa foram selecionados na clínica escola de Fisioterapia da
Faculdade de Ciências Aplicadas Dr. Leão Sampaio, situada na cidade de Juazeiro do
Norte-CE, no mês de agosto de 2014. A amostra total foi composta por 14 (quatorze)
pacientes, 13 (treze) do gênero feminino e 1 (um) do gênero masculino. Todo o
procedimento foi acompanhado por 2 (dois) especialistas e 10 (dez) estudantes do 8º
semestre do curso de Fisioterapia.
As variáveis a serem estudadas nesta pesquisa foram: distância predita,
frequência cardíaca máxima, distância percorrida após os seis minutos de caminhada, e
índice de normalidade do paciente.
A distância predita é calculada de acordo com a altura, peso e idade. O resultado
deve mostrar quantos metros o paciente deverá caminhar em 6 minutos. Caso o mesmo
não atinja a distância predita, deve-se diminuir 153m para os homens, ou 139m para as
mulheres desta distância.
A frequência cardíaca máxima é calculada subtraindo a idade do paciente do
valor 220. Caso o mesmo atinja frequência cardíaca igual ou superior ao valor resultante
do cálculo, durante a caminhada, o teste deve ser interrompido.
A distância percorrida - após os seis minutos de caminhada - é a quantidade em
metros percorrida pelo paciente. Caso ela seja inferior a distância predita, mesmo depois
das subtrações realizadas, indica que o paciente não está em sua normalidade, caso
contrário, afirma-se que o sujeito está no nível de normalidade.
446
5. ANÁLISE DOS RESULTADOS

Ocorreram 14 testes, 13 pacientes do gênero Feminino e 1 paciente do gênero
Masculino (Teste 5). A menor idade encontrada foi 08 anos (Teste 4) e a maior idade
encontrada foi 75 anos (Teste 2). O menor peso encontrado foi 39 kg (Teste 5) e o maior
de 116,3 kg (Teste 12). A menor estatura encontrada foi de 143 cm (Teste 8), e a maior
de 169 cm (Teste 9). Como pode ser percebido no Gráfico 1.
Gráfico 1. Caracterização da Amostra Por Peso

Fonte: Dados da Pesquisa
Entre as razões para que os pacientes se submetessem ao teste, estão: sofria de

bronquite asmática, tinha dificuldade de manter o equilíbrio, se cansa rápido, sobrepeso,
fibrose pulmonar, pneumonia e suspeita de hipertensão arterial.
5.1 Cálculos
Não existiu inconstância entre os cálculos realizados pelo software e o do fisioterapeuta
em nenhum teste. Os cálculos informatizados foram o de: frequência cardíaca máxima e
distância predita.
5.2 Distância Percorrida

Houve diferenças em 11 testes, entre a distância percorrida resultante do software, e a
distância percorrida analisada pelo profissional. Apenas em três situações (Teste 7,
Teste 10 e Teste 14), 21.42%, existiu exatidão entre os resultados, como pode ser
analisado no Gráfico 2
O Teste 7, Teste 10 e Teste 14 foram realizados com pessoas do sexo feminino,
a primeira possuía 59 anos, 76.8 kilogramas e 158 centímetros de altura. A segunda,
têm 72 anos, 84.5 kilogramas e 161 centímetros de altura. O terceiro, têm 70 anos, 85
kilogramas e 158 centímetros de altura.
A maior diferença ocorreu no Teste 5, no qual o resultado da distância
percorrida no OSFisio foi 425 metros, e na contagem do profissional somou 390 metros,
existindo uma diferença de 35 metros entre as contagens. O Teste 5 foi executado com o
paciente do sexo Masculino de 48 anos, 39 kilogramas e 159 cm de altura. Enxerga-se
dois motivos para essa disparidade: por um erro de contagem do fisioterapeuta causado
pela perda de atenção na contagem das voltas; pela aplicação não ser fidedigna na
identificação do passo de pessoas mais leves, como é o caso do paciente, com menor
peso da amostra.
447
Gráfico 2. Distância Percorrida por Paciente

Fonte: Dados da Pesquisa
5.3 Resultado Final

Todos os resultados do OSFisio coincidiram com os dos especialistas. O resultado teve
três testes com pacientes abaixo da normalidade (Teste 2, 4 e 5) e 11 testes com
pacientes na normalidade.
O erro de contagem na distância pode modificar o resultado final do teste. Em
situação que a distância predita para um indivíduo do gênero masculino seja 771.28
metros e o mesmo atingir 620 metros segundo a aplicação OSFisio e 617 metros
segundo contagem manual, após subtrair o limite inferior de normalidade que é de 153
metros para homens, a distância predita diminui para 618.28 metros, sendo que no
primeiro um resultado ele está em sua normalidade, já no segundo, fora dela.
6. CONCLUSÃO
O OSFisio se mostrou uma boa alternativa para automatização do TC6, facilitando o
trabalho do profissional que aplica o teste realizando os cálculos necessários, além de
medir distância e ao final mostrar o diagnóstico, que poderá afirmar se o paciente está
ou não dentro de sua normalidade. Dessa forma, o profissional que aplica o teste terá
preocupações de acompanhar mais atentamente o paciente.
O objetivo deste trabalho foi atingido, pois foi desenvolvido um software que
atendeu as necessidades do TC6, e sua validação na Clínica Escola de Fisioterapia da
Faculdade de Ciências Aplicadas Dr. Leão Sampaio trouxe resultados fidedignos.
O trabalho se limita a uma amostra não probabilística e com fórmulas adequadas
ao padrão de vida brasileiro.
Como trabalhos futuros é pretendido realizar o teste com uma amostra
probabilística maior do que a realizada neste, inserir outras fórmulas, e com o histórico
de testes realizados, decidir qual a melhor fórmula para indivíduos com determinadas
características.
Referências
6MWT. Play Store. Disponível em: <https://goo.gl/J1NMHY>. Acessado em: 02 de
Outubro de 2017.
ATS. American Thoracic Society Statement: guidelines for six-minute walk test.
American Journal Respiratory Critical Care Medicine 2002.
448
BRITTO, R. R., Teste De Caminhada De Seis Minutos Uma Normatização Brasileira.

Fisioterapia em Movimento, Curitiba, v.19, nº 4, p.49-54, 2006.
CAPELA, N. A. LEMAIRE, E. D. BADDOUR, N. Novel Algorithm for a
Smartphone-based 6-minute Walk Test Application: Algorithm, Application
Development, and Evaluation. 2015. Disponível em: <https://goo.gl/supZQm>.
Acessado em: 20 de setembro de 2017.
CAPELA, N. A. LEMAIRE, E. D. BADDOUR, N. A smartphone approach for the 2
and 6-minute walk test. 2014. Disponível em: <https://goo.gl/ZxEMfQ>. Acessado
em: 20 de setembro de 2017.
ENRIGHT, P. L. The six-minute walk test. Respiratory Care 2003, 48: 783-785.
GILEAD. Guidelines for the 6-Minute Walk Test. Disponível em:
<https://goo.gl/9BBmde>. Acesso em: 02 de Julho de 2017.
MIYAMOTO, S. Clinical correlates and prognostic significance of six-minute walk test
in patients with primary pulmonary hypertension: comparison with cardiopulmonary
exercise testing. American journal of respiratory and critical care medicine, v. 161
n. 2, p. 487-492. 2000.
MORALES-BLANHIR, J. E. et al. Teste de caminhada de seis minutos: uma
ferramenta valiosa na avaliação do comprometimento pulmonar. Jornal Brasileiro de
Pneumologia, v. 37, n. 1, p. 110-117, 2011.
RODRIGUES, S. L. et al. Teste de Caminhada de seis minutos: estudo do efeito do
aprendizado em portadores de doença pulmonar obstrutiva crônica. Jornal Brasileiro
de Pneumologia, vol. 30, nº 2, São Paulo, 2004.
TOHRC Walk Test. Play Store. Disponível em: https://goo.gl/EuCw5D. Acesso em: 30
de setembro de 2017.
449
Benchmarking entre Ferramentas de Análise

Estática de Códigos Escritos em C
Rodrigo Leal, Guilherme Freitas e Francisco Airton Silva
Sistemas de Informação
Abstract. Most systems in production have errors. To minimize this, Verifica-

tion and Validation activities are indispensable. Static Code Analysis (SCA) is
a software engineering technique for moderating errors, as well as for verifying
styles, or both. Clang and Splint are examples of tools for the C language that
aid in the reduction of errors using the AEC. This study aims at comparing these
tools, evaluating and measuring the number of errors found and the execution
time, by applying scenarios with different size codes with the same number of
errors, two different machines executing the execution, and finally the 2 code
analyzers. It was identified that the Algorithm used has more influence on the
Execution Time of the ACS. As for the number of errors found, the Clang tool
obtained maximum performance in the encounter of the errors, while it pre-
sented a greater cost of execution time when compared to the Splint.
Resumo. Grande parte dos sistemas em produção apresentam erros. Para mi-
nimizar isto, as atividades de Verificação e Validação são indispensáveis. A
Análise Estática de Código (AEC) é uma técnica da Engenharia de Software
para moderar erros, assim como para a verificação de estilos, ou ambos. Clang
e Splint são exemplos de ferramentas para a linguagem C que auxiliam na
redução de erros utilizando a AEC. Este estudo busca realizar a comparação
dessas ferramentas, avaliando e mensurando o número de erros encontrados e
o tempo de execução, mediante a aplicação dos cenários com códigos de tama-
nhos diferentes com mesmo número de erros, duas máquinas diferentes reali-
zando a execução e por último, os 2 analisadores de código. Identificou-se que
o Algoritmo usado possui maior influência sobre o Tempo de Execução da AEC.
No que concerne ao número de erros encontrados, a ferramenta Clang obteve
desempenho máximo no encontro dos erros, enquanto apresentou um custo
maior de tempo de execução quando comparado com o Splint.
1. Introdução
O desenvolvimento de um software pode se tornar difícil conforme as dimensões do
problema. Além disso, o processo de desenvolvimento está sujeito a vários proble-
mas, sejam eles internos ou externos, que resultam em um produto diferente do plane-
jado. Diversos problemas podem ser identificados, porém, a maioria deles tem origem
no erro humano [Maldonado and Delamaro 2016]. Com isso, cria-se a necessidade de
maneiras para melhorar a qualidade do produto na indústria de software.
450
A Engenharia de Software trata da organização para produção de sistemas, e

apresenta, então, processos para atingir a qualidade de produção que são: Verifica-
ção e Validação. A Verificação procura checar se o software atende a seus requisitos
funcionais e não funcionais. Já, a Validação busca garantir que o software atenda às
expectativas do cliente [Sommerville 2011].
Dentre as formas de se realizar a Verificação e Validação, destaca-se a Análise
Estática de Códigos, uma técnica de Verificação que não envolve a execução de um
programa e ajuda na captura e correção de erros humanos, desde imperfeições de sin-
taxe até imprecisões sérias que podem comprometer a segurança dos usuários; e os
Testes Unitários usados para Validação de sistemas [Sommerville 2011].
Há várias ferramentas automáticas para realizar Análise Estática de Códigos na
literatura para diversas linguagens de programação, como Ruby lint1 para a linguagem
Ruby, Pylint2 para Python, FindBugs3 para Java, e muitos outros analisadores.
A linguagem C se apresenta entre as linguagens mais populares quando se con-
sidera grande parte das áreas da computação. A Figura 1 apresenta, em ordem decres-
cente, as linguagens mais populares em uso na IEEE Xplore, Google e Github segundo
[Spectrum 2015]. Considerando-se somente o critério Embedded, a linguagem C as-
sume o topo do ranking de popularidade segundo a mesma pesquisa.
Figura 1. Popularidade de Linguagens de Programação.
O Clang e o Splint são analisadores da linguagem C frequentemente atualizados

pela comunidade de desenvolvimento. O Clang é uma ferramenta, voltada para C e
variantes, usada para encontrar erros no código e pode ser integrado com Interfaces de
Desenvolvimento (IDEs) [Clang 2017]. O Splint, assim como o Clang, busca encontrar
erros e vulnerabilidades de segurança. O Splint está na versão 3.1.2 e pode ser instalado
em sistemas operacionais Linux e Windows [Splint 2017].
Este artigo estuda a influência dos algoritmos de análise no resultado final de
um teste, e quais fatores tem maior impacto no tempo de execução dos analisado-
res Clang e Splint. Procura-se, assim, auxiliar engenheiros de software na seleção dos
analisadores estáticos da linguagem C considerando o critério de desempenho em en-
contro de erros, e tempo gasto para execução.
O artigo é organizado com a seção 2 que apresentamos o estudo comparativo
que retrata as ferramentas testadas, a metodologia empregada nos testes, a detecção
1
https://github.com/YorickPeterse/ruby-lint
2
https://www.pylint.org/
3
http://findbugs.sourceforge.net/
451
de erros das ferramentas e o Design of Experiments, na seção 3 descrevemos os traba-

lhos relacionados com este estudo, e encerrando com a seção 4 com as conclusões.
2. Estudo Comparativo
Alguns erros que ocorrem em algoritmos não são visíveis para determinados compi-
ladores. A Análise Estática de Código é a maneira para encontrar erros e reduzir de-
feitos em aplicações [Bardas et al. 2010]. A Análise Estática de Código pode ser feita
com diversas técnicas, bibliotecas e algoritmos. Para a linguagem C, existem diver-
sas ferramentas para realização dessa análise, a destacar Clang4 e Splint5 por conta de
suas frequentes atualizações pela comunidade nos repositórios dessas ferramentas no
GitHub 6 .
O Clang é uma ferramenta para Análise Estática de linguagens como C, C++,
Objective-C e variantes. Esse artefato de análise é usado para encontrar erros no có-
digo e pode ser integrado com Interfaces de Desenvolvimento (IDEs) [Clang 2017].
Clang tem código mantido no GitHub pela comunidade de desenvolvimento, e passa
por constantes revisões e atualizações. O Clang possui algumas funcionalidades e me-
tas disponíveis, entre elas, destaca-se a rápida compilação, baixo uso de memória, di-
agnósticos expressivos e código fonte de fácil entendimento.
Splint é uma ferramenta para verificação estatística de programas em C que
busca encontrar erros e vulnerabilidades de segurança. O Splint está na versão 3.1.2 e
pode ser instalado em sistemas operacionais Linux e Windows [Splint 2017]. A ferra-
menta Splint tem código-fonte mantido na plataforma GitHub, de forma aberta para a
comunidade, e passa por atualizações frequentes [Splint 2017].
Para mensurar a performance do Splint e Clang, foram considerados os seguin-
tes parâmetros: Número de erros encontrados, número de falsos positivos encontra-
dos e tempo de execução das ferramentas.
Neste artigo, foram selecionadas, como estudos de caso, alguns erros frequen-
temente cometidos em projetos de software para avaliar a eficácia das ferramentas de
análise estática, segundo [Terra 2008] há uma categorização de defeitos baseando-se
no grau de impacto no projeto. Porém, esta categorização é baseada nos efeitos dos
defeitos, e não nas causas ou nos tipos da ocorrência no código. As categorias são
listadas na Tabela 1.
Tabela 1. Categorização de Erros de Código.

Índice Categoria
1 Pane na aplicação
2 Falha lógica
3 Tratamento de erro insuficiente
4 Princípios da programação estruturada
5 Manutenibilidade do código
4
https://github.com/llvm-mirror/clang
5
https://github.com/ravenexp/splint
6
https://github.com/
452
Considerando-se a Análise de Sensibilidade sobre os fatores que interferem no

tempo de execução, utilizou-se três variáveis que podem influenciar diretamente no
tempo gasto na execução. A Tabela 2 apresenta os fatores e níveis usados no experi-
mento.
Tabela 2. Fatores e Níveis do Experimento.

Fatores Níveis
Splint
Algoritmo
Clang
1200 linhas
Tamanho de Código
300 linhas
Alta (Intel Core i5, 8GB de RAM, 1TB HD)
Configuração da Máquina
Baixa (Intel Core 2 Duo, 4 GB RAM, 320 HD)
Em cada caso foram utilizados os mesmos algoritmos, com os mesmos núme-

ros e tipos de erros executados 30 vezes, o que resultou em um número total de 240
experimentos ensaiados de forma aleatória. Para estudar o impacto desses fatores no
tempo de execução, foi feita uma Análise de Sensibilidade usando DoE. Os resultados
da Análise Sensibilidade pode ser observado no item B dessa mesma seção.
2.1. Detecção de Erros

O experimento para verificar a eficiência no encontro de erros foi organizado bus-
cando apresentar as taxas percentuais de acerto para cada ferramenta de análise es-
tática, considerando-se erros encontrados dentre os erros inseridos. Utilizou-se, no
experimento, de 12 casos de erros aplicados para verificação e detecção do Splint e
Clang. A Figura 2 apresenta o percentual de acerto para cada analisador estático.
Figura 2. Quantidade de Erros Encontrados por cada Ferramenta.
O Splint detectou corretamente nove dos doze erros, obtendo uma taxa de
acerto de 75%. O Splint foi capaz de detectar: repetições infinitas, bloco de condi-
ções declaradas erroneamente, uso de variáveis não declaradas e tipo de função ine-
xistente. Entretanto, Splint não foi capaz de detectar os três seguintes tipos erros: falta
de ponto-e-virgula, erro de alocação de memória pela declaração errada de ponteiros
e utilização de função de biblioteca não declarada. Por outro lado o Clang conseguiu
detectar todos os erros do teste.
453
Vale ressaltar que em ambos os casos de testes testados não houve ocorrência
de falsos positivos, para melhor entendimento, consideramos falso positivo quando o
algoritmo que rodamos os casos acusam erros em lugares onde não existem, assim,
os erros encontrados realmente existiam no código. Um detalhamento dos erros uti-
lizados nos experimentos com sua respectiva categorização estão dispostos na Tabela
3.
Tabela 3. Descrição de Categorias de Erros.

Índice Descrição do experimento Categoria Splint Clang
1 Utilização de variável não declarada Princípio da programação estruturada Sim Sim
2 Não utilizar ponto-e-virgula ao fim da instrução Princípio da programação estruturada Não Sim
3 Estrutura de repetição sem fim Falha lógica Sim Sim
4 Bloco de condições declaradas sem parênteses Princípio da programação estruturada Sim Sim
5 Tipo de função inexistente Princípio da programação estruturada Sim Sim
6 Declaração errada da função scanf Tratamento de erro insuficiente Não Sim
7 Utilização de biblioteca não declarada Princípio da programação estruturada Não Sim
8 Declaração errada de struct Falha lógica Sim Sim
9 Alocação dinâmica realizada de forma errada Tratamento de erro insuficiente Sim Sim
10 Switch case com erro de break Falha lógica Sim Não
11 Valores de retorno ignorados Princípio da programação estruturada Sim Sim
12 Comentário errado realizado no código Manutenibilidade do código Sim Sim
Na Tabela 3, observa-se a descrição de cada erro dos testes submetidos com

suas respectivas classificações quanto ao grau de impacto sobre o projeto segundo
[Terra 2008].
2.2. Análise de Sensibilidade com DoE

O Desenho de Experimento, do inglês Design of Experiments (DoE) permite conhecer o
efeito de variações de parâmetros sobre o resultado, orientando, assim, a um processo
de otimização. O DoE varia repetidamente cada um dos parâmetros, mantendo os
demais constantes e observa as influências no resultado, conseguindo-se assim obter
um ranking de influências [Minitab 2017]. Diversos gráficos podem ser usados para
representação de estudos estatísticos, dentre eles, destaca-se o gráfico de Pareto.
O gráfico de Pareto apresentado na Figura 3 descreve a importância de um
efeito por seu absoluto valor, desenhando uma linha vertical de referência no gráfico.
Ao passo que o efeito prolonga essa linha, maior é a influência na variável dependente.
A linha vermelha tracejada representa a magnitude mínima de efeitos estatisticamente
significativos, considerando-se o critério de significância estatística α=0.05.
Figura 3. Influência dos Fatores sobre o Tempo de Execução.
454
Pode-se observar no gráfico que o fator com maior influência na variável de-
pendente (Tempo de Execução) é o Algoritmo usado (representando pela letra A no
gráfico). Variando-se a escolha entre o analisador Splint e Clang, obtêm-se a maior
influência no tempo da análise estática de códigos.
Outras variáveis independentes como Tamanho de Código e Configuração da
Máquina (representadas como B e C, respectivamente) não possuem influência esta-
tística considerável na variável independente (Tempo de Execução).
Buscando complementar e melhor detalhar o estudo, utilizou-se o gráfico de
Efeitos Principais (que pode ser visualizado na Figura 4). Este gráfico é usado para se
demonstrar, detalhadamente, como um ou mais fatores categóricos influenciam em
uma resposta contínua. A Figura 4 apresenta o gráfico de Efeitos considerando o expe-
rimento.
Figura 4. Gráfico de Efeitos Principais para Tempo de Execução.
O gráfico de Efeitos Principais apresenta inclinações (coloridas em azul no grá-

fico da Figura 4) entre as variáveis independentes estudadas. Quanto maior o esforço
de inclinação, maior é a diferença da resposta contínua para as variáveis comparadas.
A ordem de esforço de inclinação é distinta para cada variável independente.
Por ordem decrescente, o esforço de inclinação é organizado em Algoritmos, Configu-
ração da Máquina e Tamanho de Código. Isso demonstra que o Tempo Médio de Exe-
cução é altamente distinto para os níveis de Algoritmos, regularmente distinto, para os
níveis de Configuração de Máquina, e menor para o Tamanho de Código. A inclinação
entre os níveis de Algoritmos é acentuada, o que retrata um Tempo Médio de Execução,
elevadamente, distinto entre o analisador Splint e Clang. O analisador estático Splint
teve um tempo inferior quando comparado com o Clang, com o tempo chegando a ser
até 6 vezes menor e podendo gerar um impacto maior com códigos maiores.
Na Tabela 4 estão dispostos os trabalhos relacionados que seguem direção similar de

pesquisa, ou dão base para este estudo.
455
Tabela 4. Comparativo entre Trabalhos Relacionados.

Trabalho Linguagem Análise de Sensibilidade
[Zitser et al. 2004] C e C++ Não
[Manzoor et al. 2012] C, C++ e Java Não
[Chahar et al. 2012] C, C++ e Java Não
[Goseva-Popstojanova and Perhinschi 2015] C, C++ e Java Não
Nosso Trabalho C Sim
No geral foram encontrados artigos com estas características. Manzoor et al.

(2012) procuraram medir a eficácia das ferramentas RELAY, RacerX e CheckThread em
identificar bugs. Um ponto negativo deste trabalho foi a avaliação de ferramentas que
ainda possuíam pouco uso da comunidade. Já Zitser et al. (2004) testaram cinco fer-
ramentas que são: ARCHER, BOON, PolySpace C Verifier, Splint, e UNO. Os autores
mensuraram as taxas de detecção e alarmes falsos (falsos positivos e negativos) das
ferramentas em questão. Chahar et al. (2012) realizam análises de desempenho para
comparar as ferramentas de verificação Flawfinder, Splint, e Cppcheck em um ambi-
ente estático, bem como para comparar as ferramentas de verificação de códigos PMD,
Findbugs, e Valgrind em um contexto dinâmico. Goseva-Popstojanova e Perhinschi
(2015) realizaram um experimento de análise de códigos utilizando a Juliet benchmark,
buscando um melhor entendimento de suas vantagens e de suas limitações.
Já neste trabalho, além de analisar o número de erros encontrados,
diferenciando-se dos demais pelo estudo de DoE, verificando quais os fatores que tem
maior impacto sobre o tempo de execução dos códigos testados.
• Linguagem: no quesito linguagem, foram encontrados Manzoor et al. (2012)
que procurou medir o desempenho de ferramentas para as linguagens C, C++
e Java, assim como Chahar et al. (2012) e Goseva-Popstojanova e Perhinschi
(2015) , já o Zitser et al. (2004) só contemplou as linguagens C e C++.
• Análise de Sensibilidade: com exceção deste trabalho, nenhum dos outros ci-
tados acima realiza análise de sensibilidade.
4. Conclusões
Com relação ao número de erros encontrados na execução dos testes e ao número
de falsos positivos, podemos concluir que a ferramenta Clang superou a ferramenta
Splint nestes quesitos, pois foi capaz de encontrar todos os erros propostos nos testes,
obtendo completo êxito, enquanto o Splint não conseguiu encontrar todos, obtendo
uma taxa de acerto de 75%. Com estes resultados, pode-se concluir que a ferramenta
Clang teve um melhor resultado no quesito eficácia. Em outro experimento apresen-
tado, percebe-se que o tempo de execução sofreu influência dos três fatores estudados,
o que pode ser comprovado com a Análise de Sensibilidade apresentada na seção 2.2.
O fator que teve maior influência sobre o tempo de execução foi o Algoritmo, acima
de configuração da máquina e tamanho de código, o que pode ponderar com maior
valor a escolha adequada do algoritmo para aumento da eficiência da análise estática.
Atrás do fator de algoritmo, a configuração da máquina exerceu pouca influência so-
bre os resultados, se comparado com o fator algoritmo, sendo responsável por pouco
alterar o tempo de processamento durante variação das propriedades da máquina de
456
análise. Mas embora sua relevância ser pouca ainda se sobre-sai quando comparado
ao tamanho do código.
Referências
Bardas, A. G. et al. (2010). Static code analysis. Journal of Information Systems and
Operations Management, 4(2):99–107.
Chahar, C., Chauhan, V. S., and Das, M. L. (2012). Code analysis for software and system
security using open source tools. Information Security Journal: A Global Perspective,
21(6):346–352.
Clang (2017). Clang: a c language family frontend for llvm. In Clang: a C language
family frontend for LLVM.
Goseva-Popstojanova, K. and Perhinschi, A. (2015). On the capability of static code
analysis to detect security vulnerabilities. Information and Software Technology,
68:18–33.
Maldonado, C, J. and Delamaro, E. M. (2016). Introdução ao Teste de Software. Elsevier,
2th edition.
Manzoor, N., Munir, H., and Moayyed, M. (2012). Comparison of static analysis tools
for finding concurrency bugs. In Software Reliability Engineering Workshops (ISS-
REW), 2012 IEEE 23rd International Symposium on, pages 129–133. IEEE.
Sommerville, I. (2011). Engenharia de Software. Pearson, 9th edition.
Spectrum, I. (2015). Interactive: The top programming languages 2015. In Interactive:
The Top Programming Languages 2015.
Splint (2017). Splint - secure programming lint. In Splint - Secure Programming Lint.
Terra, R. (2008). Splint - secure programming lint. In Ferramentas para Análise Estática
de Códigos Java.
Zitser, M., Lippmann, R., and Leek, T. (2004). Testing static analysis tools using exploi-
table buffer overflows from open source code. In ACM SIGSOFT Software Enginee-
ring Notes, volume 29, pages 97–106. ACM.
457
Sistema Domótico de Baixo Custo e Eficiente Utilizando

Raspberry PI e Arduino
Icaro Caio de Sousa Machado1 , Irvayne Matheus de Sousa Ibiapina1 ,
Otávio Cury da Costa Castro1 , Wilson Leal Rodrigues Junior1 ,
Alexandre Cristian Lages de Araújo1 , Dyogo Medeiros Reis 1 ,
Ronnasayd de Sousa Machado 1
1
Brasil
Abstract. This work presents the implementation of a home automation system,

using free hardware and software, whose main objective was to develop a low
cost and efficient prototype that offers comfort, security and energy manage-
ment. For this purpose, the following components were used: Raspberry PI and
Arduino platforms, sensors and actuators, and finally a webpage was developed
for the control and supervision of the proposed system. The system was imple-
mented and tested in a residence. The tests were done separately by each device,
and later with the integrated components. With respoect to the results obtained
at the end of the project, it was verified that the home automation system deve-
loped is really low cost and efficient.
Resumo. Este trabalho apresenta um sistema domótico, utilizando hardware e

software livres, cujo objetivo principal é apresentar um sistema capaz de contro-
lar e gerenciar algumas atividades inerentes do(ao) dia a dia das pessoas, com
o objetivo de facilitar a vida de seus usuários, eficiente e de baixo custo(com
eficiência e baixo custo). Para este fim, foram utilizados os seguintes compo-
nentes: plataformas Raspberry PI e Arduino, sensores e atuadores, e por fim foi
desenvolvida uma página web para o controle e supervisão do sistema proposto.
O sistema foi implementado e testado em uma residência (em ambiente resi-
dencial). Os testes foram feitos separadamente por(de forma individual para)
cada dispositivo, e posteriormente com os componentes integrados. Quanto aos
resultados obtidos ao final do projeto, foi verificado que o sistema domótico
desenvolvido é realmente de baixo custo e eficiente.
1. Introdução
A inserção da tecnologia no ambiente residencial está chegando a nı́veis cada vez mais
altos. Desde tarefas mais simples, como acordar de manhã com alarme do celular a tarefas
mais complicadas como sair de casa pelo portão eletrônico. Na década de 90, Weiser criou
o termo computação ubı́qua para se referir a sistemas presentes nos mais triviais objetos
do dia a dia, de maneira mais tangı́vel ao usuário [Weiser 1991].
458
Todavia, para que isso fosse possı́vel nos dias atuais, muitos avanços foram ne-
cessários. A evolução das redes computadores, miniaturização dos componentes de hard-
ware, redução de custo de componentes computacionais, e outros fatores, permitiram que
as ideias de Weiser fossem, enfim, possı́veis [Lyytinen and Yoo 2002].
Tais avanços tecnológicos beneficiaram diferentes áreas de atuação, dentre elas a
Domótica que tem como finalidade proporcionar maior comodidade, conforto e segurança
em ambientes domésticos [Bonino and Corno 2008]. Além disso, algumas aplicações
desse campo podem ajudar na economia de recursos como água, energia elétrica, e tempo
com a automatização de atividades.
O presente trabalho tem por objetivo apresentar um sistema de automação resi-
dencial com a plataforma Raspberry PI de maneira a simplificar tarefas comuns em um
ambiente residencial. Desta forma, foi projetado e desenvolvido um sistema domótico de
baixo custo que controla, através da internet, dispositivos conectados ao sistema como:
controle de iluminação (lâmpadas), temperatura ambiente, leitura de sensores e câmera
de segurança.
O sistema de controle desenvolvido utiliza um microcomputador, microcontrola-
dor e um smartphone. Desta forma, foi desenvolvido um protótipo de hardware e soft-
ware integrados com sensores, atuadores, plataformas de comunicação, que apresenta
uma solução facilitada para tarefas comuns do dia a dia, bem como um consumo eficiente
de energia elétrica para uma residência.
O restante deste artigo está organizado da seguinte maneira. A Seção 2 discorre
sobre o referencial teórico necessário para o bom entendimento do trabalho, a Seção 3
apresenta uma visão geral do sistema desenvolvido. Por fim, a Seção 4 apresenta as
conclusões e direções para trabalhos a serem desenvolvidos
Nessa seção serão apresentados alguns conceitos importantes para uma boa compreensão
do trabalho.
2.1. Domótica
A Domótica pode ser conceituada como um aglomerado de serviços proporcio-
nados por sistemas integrados, com o propósito de satisfazer necessidades dos
ocupantes de uma residência. É um conceito conhecido também como ”casa
inteligente”[Ricquebourg et al. 2006].
A automação residencial é o agregamento de serviços oferecidos por sistemas tec-
nológicos integrados, com o intuito de prover serviços como: comunicação, segurança,
gestão energética. O principal fator que define automação residencial é a integração en-
tres equipamentos que têm a capacidade de se comunicarem em um sistema que permite
receber e executar comandos programáveis [Association et al. 2010].
2.2. Internet das Coisas

A Internet das Coisas (do inglês Internet of Things – IoT) é um paradigma que vem
ganhando terreno na telecomunicação. A ideia é a presença ubı́qua de uma variedade
459
de objetos conectados à internet com a capacidade de realizar variados processamentos,

capturar variáveis ambientais e reagir a estı́mulos externos [Atzori et al. 2010].
Um dos cenários onde a IoT mais exerce impacto é no cotidiano e nos aspectos do
comportamento das pessoas. No cenário residencial, ligar e desligar aparelhos, monitorar
a temperatura e iluminação de ambientes, tudo isso através da internet, são exemplo de
como a IoT pode estar presente no cotidiano [Gubbi et al. 2013].
2.3. Arduino
O Arduino é uma plataforma de prototipagem eletrônica criada na Itália que tornou o
mundo da robótica mais acessı́vel às pessoas. Iniciado em 2005, a ideia base era que ele
fosse utilizado como apoio educacional em aplicações escolares.
Ele é constituı́do basicamente por um microcontrolador Atmel AVR de 8 bits,
pinos analógicos e digitais de entrada e saı́da, e entrada USB. Embutido no Arduino existe
um firmware, que mescla memoria ROM para leitura e um programa gravado nesse tipo
de memória, carregado na memória da placa e compatı́vel com os sistemas operacionais
Windows, Linux, e Mac OS X [McRoberts 2011].
2.4. Raspberry PI
O Raspberry PI é um computador de pequeno porte, do tamanho de cartão de crédito, com
dimensões de 85.60 mm por 21 mm que pesa 45g. Esse computador de código aberto foi
criado para estimular o ensino de programação e tecnologia [Pi 2013].
Além disso, o Raspberry PI conta com as Portas Programadas de Entrada/Saı́da
(General Purpose Input/Output – GPIO ), que é basicamente um conjunto de pinos res-
ponsável por fazer a comunicação de entrada e saı́da de sinais digitais. Dependendo do
modelo do Raspberry PI, ele pode contar com 26 ou 40 GPIO. Com esse pinos é possı́vel
acionar LEDs, relés, motores e fazer leitura de sensores digitais.
2.5. Sensores
Sensor é um dispositivo que responde a um estimulo fı́sico ou quı́mico de maneira espe-
cifica e mensurável analogicamente. Sensores são responsáveis pelas informações sobre
variáveis que precisam ser medidas, como: temperatura, umidade, velocidade, corrente,
entre outras. Essas variáveis são mensuradas por elementos sensı́veis como circuitos
eletrônicos não digitais [Wendling 2010].
Os sensores digitais só podem assumir dois valores no seu sinal de saı́da ao longo
do tempo, que podem ser interpretados como zero e um. Nãos existem naturalmente
grandezas fı́sicas que assumam esses valores, mas elas são assim mostradas ao sistema de
controle após serem convertidos por um circuito eletrônico.
2.5.1. Sensor de Corrente
O sensor de corrente não invasivo atua como um indutor e responde ao campo magnético
ao redor de um condutor portador de corrente. Pela leitura da quantidade de corrente pro-
duzida pela bobina pode-se calcular a corrente que está passando pelo condutor [Flipeflop
2017].
460
2.6. Relé
Segundo [Souto 2004], é um dispositivo eletromecânico que funciona com pequenas cor-
rentes, mas é capaz de controlar circuitos externos que envolvem correntes elevadas, e
é formado basicamente por uma bobina e um conjunto de contatos. Para [Braga 2010]
relés são dispositivos comutadores eletromecânicos. Através de uma corrente de con-
trole aplicada a bobina de um relé, podemos abrir, fechar ou comutar os contatos de uma
determinada forma, controlando assim as correntes que circulam por circuitos externos.
3. Abordagem
O sistema domótico desenvolvido é composto por três componentes principais que
quando sincronizados, provêm um ambiente para iteração entre o usuário e sistema. Os
componentes são: placa Raspberry, Arduino e sistema web. Na Figura 1 podemos obser-
var um diagrama simplificado da comunicação entre esses componentes. Cada compo-
nente exerce um papel especı́fico no sistema, como por exemplo, a central de controle de
processamentos, realizado pelo Raspberry, a comunicação entre o usuário e a aplicação, o
sistema Web, e, por fim, a coleta de dados dos dispositivos finais (luzes, ar-condicionados
e controle energético) e comunicação entre a central de processamento realizados pelo
arduino.
Figura 1. Diagrama Simplificado do Sistema
3.1. Central de Controle de Processamento

A central de controle de processamento é o principal componente do sistema. Uma placa
Raspberry é responsável por realizar esse papel no sistema. Sua escolha deu-se pelo
fato desse sistema embarcado possuir um alto poder de processamento, possuir poucas
dimensões fı́sicas, e ser capaz de realizar toda a troca de informações e a comunicação
entre os outros componentes do sistema. Na Figura 2 podemos observar a arquitetura
detalhada desse componente, enfatizando os canais que ele provê serviços, além da sua
capacidade de escalabilidade.
3.2. Aplicação Web

Foi desenvolvida uma aplicação web para realizar a interação entre o usuário e o sistema.
Ela foi desenvolvida utilizando a linguagem Python e o framework de desenvolvimento
web Django. Essa aplicação é composta por algumas funcionalidades que podem ser
461
acessadas pelo usuário através dos principais navegadores. Esse acesso ocorre por meio
de uma comunicação intranet, onde o usuário deve estar conectado a rede.
A aplicação desenvolvida é composta por 4 funcionalidades: login, controle de
iluminação, controle de temperatura e gestão energética. Inicialmente, para o usuário
ter acesso as funcionalidades presentes na aplicação, é necessário realizar um login no
sistema. Na Figura 3 podemos observar uma imagem que representa essa área de acesso
inicial do usuário.
Figura 3. Página de Login
Após realizar o login, o usuário é direcionado para a página inicial da aplicação.

Nela são exibidas as opções como: conforto (funcionalidade que realiza o controle da
iluminação), controle de temperatura e gestão energética. Essa página pode ser observada
na Figura 4.
Um dos objetivos para a construção de um sistema domótico é a praticidade no
controle dos sistemas elétricos residenciais. Devido à isso, a aplicação web desenvolvida
disponibiliza uma página que permite esse controle. Ela pode ser acessada através da
opção ’Conforto’ presente na pagina inicial da aplicação. Nessa página é possı́vel ligar
ou desligar as luzes dos cômodos da residência. Na Figura 5 podemos observar essa
página.
Outra funcionalidade presente no sistema é o controle de temperatura. Nele
é possı́vel realizar operações no ar-condicionado presente nos cômodos configurados
na aplicação (Figura 6). Nessa funcionalidade é possı́vel ligar e desligar o aparelho
462
Figura 4. Dashboard
Figura 5. Página de Conforto
de refrigeração, além de definir algumas temperaturas para seu funcionamento. Uma

informação importante disponibilizada pelo sistema é a temperatura atual nos cômodos.
Com essa informação, o usuário pode definir qual a melhor opção de temperatura para o
determinado momento. Isso, além dos benefı́cios em relação a comodidade, pode trazer
redução nos gastos energéticos, trazendo economia para seus usuários.
Figura 6. Página de Temperatura
A página de Gestão Energética conta com informações sobre o consumo de ener-

gia diário e mensal, através de dados coletados em tempo real. Com ela, o usuário tem
uma real noção sobre os gastos que estão ocorrendo diariamente, e assim, propor meios
para redução de gastos desnecessários. Na Figura 7 podemos ver a imagem que representa
essa página.
463
Figura 7. Página de Consumo
3.3. Coleta de Dados

Para realizar a coleta de dados dos dispositiveis elétricos da residência, é utilizada uma
placa Arduino que juntamente com alguns sensores, realizam a captura desses dados.
Na Figura 8 podemos ver a arquitetura do componente para coleta de dados. Para a
construção desse componente, foram utilizados sensores para obtenção do valor da cor-
rente e infravermelho (comunicação com os condicionadores de ar), e relés para controle
de corrente (manipulação do fluxo energético em uma determinada porta de saı́da).

Durante o desenvolvimento do projeto, percebeu-se o quão é grande o leque de ferramen-
tas disponı́veis para serem utilizadas em processos de automação residencial. Os critérios
para a seleção das ferramentas utilizadas foram basicamente: custo, eficiência, simplici-
dade e o quanto ferramenta permite a exploração e execução de novos conceitos.
Com casas progressivamente automatizadas por sistemas como o proposto, os re-
sidentes obterão cada vez mais lazer e gastarão cada vez menos tempo com atividades
diárias, das mais simples às mais complexas. Além disso, sendo o sistema controlado
por uma página web, os usuários podem monitorar certas atividades a qualquer hora e em
qualquer lugar.
Para planos futuros, pretende-se expandir cada vez mais o alcance do sistema
desenvolvido. Para isso, integrações com outros componentes de uma casa já estão sendo
464
estudadas, como televisores e geladeiras, como o intúito de monitoramento, e visando

uma maior economia de energia.
Referências
Association, C.-H. A. S. et al. (2010). What is home automation? systems that integrate
with home automation. home automation system (spanish website).
Atzori, L., Iera, A., and Morabito, G. (2010). The internet of things: A survey. Computer
networks, 54(15):2787–2805.
Bonino, D. and Corno, F. (2008). Dogont-ontology modeling for intelligent domotic
environments. The Semantic Web-ISWC 2008, pages 790–803.
Gubbi, J., Buyya, R., Marusic, S., and Palaniswami, M. (2013). Internet of things (iot):
A vision, architectural elements, and future directions. Future generation computer
systems, 29(7):1645–1660.
Lyytinen, K. and Yoo, Y. (2002). Ubiquitous computing. Communications of the ACM,
45(12):63–96.
McRoberts, M. (2011). Arduino básico. São Paulo: Novatec.
Pi, R. (2013). Raspberry pi. Raspberry Pi, 1:1.
Ricquebourg, V., Menga, D., Durand, D., Marhic, B., Delahoche, L., and Loge, C. (2006).
The smart home concept: our immediate future. In E-Learning in Industrial Electro-
nics, 2006 1ST IEEE International Conference on, pages 23–28. IEEE.
Weiser, M. (1991). The computer for the 21st century. Scientific american, 265(3):94–
104.
Wendling, M. (2010). Sensores. Universidade Estadual Paulista. São Paulo.
465
VANTAGENS DA UTILIZAÇÃO DO FRAMEWORK SCRUM

PERANTE MÉTODOS TRADICIONAIS
Laísa K; Simoes¹, Jhonatan F Oliveira¹, Luis H. Valadares²

¹Universidade do Estado de Minas Gerais (UEMG)
Divinópolis –MG – Brasil
²Faculdade Pitágoras
Divinópolis –MG – Brasil
[email protected],[email protected],
[email protected]
Abstract. Due to the increasing market demand for innovation, flexibility and quality in
software development processes, so-called agile methods have emerged. Among these methods,
the Scrum framework stands out, in order to optimize the work of the developers and solve
complex and adaptive problems, delivering the product with the highest possible value. The
objective of this work is to present the advantages of using the Scrum framework in software
development.
Keywords: Scrum, software, agile, framework, flexibility, innovation.
Resumo. Devido o aumento da demanda do mercado por inovação, flexibilidade e qualidade

nos processos de desenvolvimento de softwares, surgiu os chamados métodos ágeis, dentre
esses métodos se destaca o framework Scrum, com intuito de otimizar o trabalho dos
desenvolvedores e resolver problemas complexos e adaptativos, entregando o produto com o
maior valor possível. O objetivo deste trabalho é apresentar as vantagens do uso do framework
Scrum no desenvolvimento de softwares.
Palavras-chave: Scrum, software, ágil, framework, flexibilidade, inovação.
1. INTRODUÇÃO
Com a rápida evolução da tecnologia, os softwares se tornam obsoletos de forma mais rápida,
pois o acesso a informações precisas e confiáveis fazem com que as necessidades mudem
constantemente. Como consequência, os prazos diminuem e a demanda aumenta. Diante disso
o desenvolvimento de softwares torna-se um processo mais sensível à influência de fatores
externos à equipe técnica. [Bassi Filho 2008].
Surgindo assim os chamados métodos ágeis, nesse contexto, destaca-se o Scrum, um

framework que auxilia no gerenciamento de projetos de desenvolvimento de produtos. Foi
desenvolvido por Jeff Sutherland em 1993, juntamente com Mike Beedle e Ken Schwaber,
baseado em um estudo artigo de Takeuchi e Nonaka (1986) em que abordavam-se as vantagens
dos pequenos times no desenvolvimento de produtos. Inicialmente, o foco seria o
desenvolvimento de softwares, embora atualmente seja utilizado no gerenciamento de
quaisquer outros processos de desenvolvimento de produtos. [Cristal; Wildt; Prikladnicki
2008].
O Scrum tem ganhado o mercado atualmente por ser um framework de fácil aplicação e por
formar equipes auto gerenciáveis, conforme Carvalho e Mello (2012) em seu artigo “Aplicação
do método ágil Scrum no desenvolvimento de produtos de softwares em uma pequena empresa
466
de base tecnológica”, apresenta uma implantação relacionada ao time de desenvolvimento

quanto á motivação, comunicação e colaboração, entre outras características da implantação do
Scrum na empresa.
Este trabalho tem como objetivo demonstrar as vantagens da utilização do framework Scrum
perante aos métodos tradicionais de desenvolvimento de software. Será realizado um estudo
entre uma empresa que utiliza o framework Scrum no desenvolvimento de software e uma
empresa que utiliza métodos tradicionais, e posteriormente, analisar e apresentar os resultados
obtidos. Este estudo também explica o que é o framework Scrum, suas principais características
e como é utilizado. A presente pesquisa trata-se de um estudo descritivo qualitativo, através da
observação da rotina do time Scrum das empresas.
2.Objetivos
2.1 Objetivo geral
Este artigo tem como relevância apresentar a importância da utilização do método ágil o
framework Scrum, como forma de elevar os valores empresariais, voltada para a gestão de
desenvolvimento de softwares em empresas no que refere a escopo e prazo.
2.2 Objetivos específicos

• Reduzir riscos no que se refere a criação e manutenção de softwares;
• Facilitar o acompanhamento dos projetos que estão sendo executados;
• Analisar o desempenho das atividades dos desenvolvedores;
• Inspecionar e adaptar aos processos;
• Diagnosticar principais diferenças entre as empresas;
3. Metodologia
Trata-se de um estudo descritivo, exploratório, de abordagem qualitativa realizado em duas

empresas de desenvolvimento de softwares em Divinópolis/MG no ano de 2017. Esse estudo
buscou fundamentos que comprova que o uso do framework Scrum gera resultados satisfatórios
para as empresas de desenvolvimento tanto na implementação do produto quanto na entrega.
O estudo foi realizado em duas empresas de desenvolvimento de softwares, a empresa A possui

um time de 6 pessoas, utiliza o framework Scrum há 5 anos e constatou a eficiência dele em
relação aos anos anteriores, onde utilizavam métodos tradicionais. A empresa B possui um time
de 4 pessoas e utiliza métodos tradicionais em seu processo de desenvolvimento.
Foram realizadas visitas de acompanhamento diário nas duas empresas, em um período de 90

dias, a empresa A foi visitada 3 vezes, enquanto a empresa B recebeu 6 visitas.
O estudo foi dividido em 6 etapas que são descritas nas sessões abaixo.
Aplicação do formulário 1
Foi aplicado o formulário 1 na empresa B, afim de entender o nível de conhecimento do time

sobre o framework Scrum e métodos ágeis, com base nas respostas obtidas serão observadas as
principais dificuldades e traçado planos de ação.
467
Apresentações do Framework Scrum na empresa
Foi aplicado um minicurso com o time da empresa B. Esse minicurso foi focado nos valores e
princípios do Scrum, com exemplos de casos reais, com intuito de despertar o interesse da
equipe.
Aplicação do formulário 2
Foi aplicado o formulário 2 após o minicurso do Scrum com perguntadas voltadas somente para
o que foi apresentado, com intuito de avaliar o conhecimento adquirido e observar a nova visão
da equipe sobre o framework.
Acompanhamentos do dia a dia da empresa
Foram realizadas visitas frequentes, em um período de 60 dias na empresa B, para acompanhar

a rotina e como eram executadas as tarefas do dia a dia. Essas visitas foram somente para
observação.
Definições de adaptação de algumas práticas do Scrum
Juntamente com o time foram realizados levantamentos de algumas práticas interessantes a

serem utilizadas dentro da empresa.
Implantações do Scrum
Através da análise comportamental realizada dentro da empresa, (1) inicialmente foram

realizadas a mudanças de papéis dentro da equipe; (2) inclusão de um quadro para auxílio no
acompanhamento da rotina da equipe; (3) implementação das reuniões.
3.1 Metodologia do Scrum
As metodologias ágeis surgiram para facilitar o desenvolvimento de software com intuito de

suprir as necessidades do mercado, tornando-os mais flexíveis, facilitando assim o seu
desenvolvimento quanto aos métodos tradicionais. Existem inúmeros métodos ágeis, todos
fundamentados nos valores do manifesto ágil: - Indivíduos e interações mais que processos e
ferramentas; -Software em funcionamento mais que documentação abrangente; -Colaboração
com o cliente mais que negociação de contratos e -Responder a mudanças mais que seguir um
plano.
Os métodos ágeis são caracterizados por fazer entregas pequenas e, também, versões para os
clientes a cada duas ou três semanas. Os clientes participam das versões durante o
desenvolvimento para melhor comunicação entre ambas ás partes, evoluindo nos requisitos,
diminuindo a documentação e utilizando mais a comunicação informal. [Sommerville 2011].
Dentre os métodos ágeis, destaca-se o framework Scrum, uma abordagem enxuta que auxilia
no planejamento e desenvolvimento de produtos. O Scrum é baseado em práticas já
comprovadas e está em constante crescimento por décadas no desenvolvimento de software.
Caracteriza-se por ser “empírica, adaptativa e inovadora” utilizada de forma incremental no
468
desenvolvimento de software, onde o ciclo de vida do produto é bastante instável e sofre

constantes mudanças, que resultam em uma abordagem flexível, adaptável e produtiva.
[Schwaber & Beedle apud Leitão 2010].
A partir de R. S. Pressman “O Scrum (nome derivado de uma atividade que ocorre durante um
jogo de rugby) é um modelo ágil de processo que foi desenvolvido por Jeff Sutherland e por
sua equipe no início da década de 1990”. [Andrade; Oliveira; Barbosa; Silveira 2015].
O Scrum possui três pilares, são eles: “transparência, inspeção e adaptação”. A

transparência assegura que os processos estão visíveis aos responsáveis pelo
resultado.[Schwaber & Sutherland apud Leitão 2010]. A inspeção é o monitoramento dos
artefatos do Scrum, através da união dos pilares Inspeção e Transparência temos o processo de
adaptação, fazendo os ajustes necessários em todo o fluxo. O ciclo do Scrum pode ser
visualizado na Figura 1.
Figura 1 - Ciclo do Scrum. Fonte: Schwaber & Beedle (2002); Schwaber (2004).
O framework Scrum possui em seu ciclo a seguinte divisão:
Time Scrum:
• Product Owner: É o responsável pela relação com cliente, definindo características do

produto e a prioridade de execução dos requisitos. O que faz o projeto ter sucesso é
respeitar e seguir as decisões do Product Owner. Concentrando as informações de
maneira a obter uma visão única dos requisitos do sistema. [Leitão 2010].
• Scrum Master: Acompanha o desenvolvimento e remove impedimentos, participa de
todas as reuniões e garante que o Scrum seja aplicado conforme planejado. Funcionando
como escudo para o time de possíveis interferências externas. Também é responsável
por disponibilizar a cooperação entre todos os papéis e função. Trabalha próximo ao
Product Owner, visando gerenciar seus interesses juntamente com a equipe de
desenvolvimento. [Leitão 2010].
• Time de Desenvolvimento: É o time de desenvolvimento auto gerenciada, auto
organizada e multifuncional. É composta por equipes pequenas entorno de 5 a 9 pessoas,
sendo todos os membros responsáveis pela entrega em cada sprints. [Leitão 2010].
469
Artefatos do Scrum
• Backlog do Produto: Segundo Varaschim (2009) “é a lista que contém as

funcionalidades de negócio, os requisitos técnicos e os erros encontrados no sistema que
precisam ser desenvolvida”. Está sempre em constantes mudanças, tornando uma lista
de prioridades. [Varaschim 2009].
• Backlog do Sprint: É criado a partir das estórias retiradas do Product Backlog e o que
serão feitas durante a Sprint. Nas estórias aceitadas pela equipe durante a Sprint
Planning são separadas em pequenas tarefas, realizadas no máximo em um dia, para
serem acompanhadas durante o Sprint, sendo redigidas e registradas para a Sprint,
gerando novas tarefas. [Varaschim 2009].
• Incremento: Define-se incremento todas as partes do Backlog do Produto, os quais são
completados durante a Sprint mais o valor dos incrementos das Sprints anteriores.
Segundo Schwaber e Sutherland (2013), “no final da Sprint um novo incremento deve
estar no estado de "Pronto", significando que a condição deve estar utilizável e deve
atender ao estado de "Pronto" do Time Scrum.
Eventos Scrum:
• Reunião de Planejamento da Sprint: É onde acontece a separação das estórias que serão
implantadas durante o ciclo. Salientando que a função do Planejamento da Sprint já se
considera que exista um Product Backlog. Geralmente acontece em um dia, porém de
acordo com a duração do Sprint o tempo pode variar. [Varaschim 2009].
• Reunião Diária: É a reunião que acontece todos os dias no mesmo horário com tempo
máximo de duração de 15 minutos, todos os participantes ficam de pé e o time responde
a três perguntas:
De acordo com Schwaber e Sutherland (2013) são elas:
1. “O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta

da Sprint?“
2. “O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da
Sprint?“.
3. “Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no
atendimento da meta da Sprint?”
• Revisão da Sprint: É a revisão que acontece no final de cada Sprint. Segundo Varaschim,
(2009) “Durante esta reunião o time mostra o resultado do seu trabalho para o Product
Owner e para outros clientes opcionalmente”. Os itens que são analisados durante a
Revisão são os requisitos que foram definidos durante a Sprint Planning. É realizada
durante essa etapa a demonstração das estórias desenvolvida, cada estória é avaliada de
acordo com as circunstâncias existentes de aceitação. [Varaschim 2009].
• Retrospectiva da Sprint: É focado no time, acontece sempre ao final de cada Sprint com
intuito de aplicar correções de problemas observados pelo time durante o
desenvolvimento, útil também para elaboração de melhorias. Ressaltando sempre o foco
na metodologia usada para o time não voltar a utilizar os métodos tradicionais. Durante
a reunião o Scrum Master ajuda o time a listar os principais problemas. [Varaschim
2009].
5. Resultados
Inicialmente através das respostas dos formulários era nítida a falta e a falha da
comunicação entre a equipe e com os clientes. Durante o acompanhamento dentro da empresa
470
percebeu-se a falta de planejamento durante a realização da entrega do produto. Após a

implementação de algumas práticas do Scrum, com o objetivo principal do aumento da
produtividade e a comunicação entre a equipe, os produtos passaram a ser entregue dentro do
prazo estipulado e com a participação ativa dos clientes, acarretando em redução de custos.
Conforme no quadro 1, os resultados foram bastante satisfatórios, a equipe ficou mais motivada
e mais segura em relação à tomada de decisões, otimizando os recursos e aumentando os lucros.
Quadro 1: Análise dos resultados após implantação do Scrum. Fonte: Próprio autor.
Análise dos resultados após implantação do Scrum
Antes Depois
Definição de papéis entre equipe. Sendo: 1 Product

Equipe sem papéis definidos. Owner, 1 Scrum Master e 2 Time de
Desenvolvimento.
Divisão por ciclos de acordo com lista de prioridades,

Equipe fazia muitas horas extras e trabalho para entrega do produto, com definição através da
em casa. reunião de planejamento.
Dentro da equipe nem sempre era claro o Transparência no processo de desenvolvimento entre
que cada desenvolvedor estava fazendo e a equipe, através das reuniões diárias.
desorganização.
Equipe mais motivada e auto gerenciáveis.

Equipe muito dependente do gerente.
Muito retrabalho e erros. Os clientes passaram a ter contato ativo dentro da

empresa, tornando as entregas frequentes e
entregando o que realmente foi solicitado.
Entregas sempre atrasada. Com as reuniões de planejamento e retrospectiva, a

equipe passou a estipular prazo de entrega, de acordo
com experiências já obtidas.
Falta de planejamento, o desenvolvimento

era guiado a demandas, sempre que entrava Foram criadas as Sprints, com isso o time era focado
novas solicitações a mesma era repassada em um único objetivo, atingir a meta da Sprint.
diretamente para o desenvolvedor,
empilhando solicitações em andamento,
sem qualquer processo de priorização.
5.1 Dificuldades encontradas
471
Dentre as dificuldades encontradas durante a implementação a principal foi às reuniões não

serem gerenciadas em tempo fechado, esse requisito acarretava em atraso de outras tarefas.
Outra dificuldade encontrada foi reunião diária sem conter informações básicas a equipe fugia
um pouco do foco. A equipe estava acostumada com o papel do gerente, direcionando as tarefas
e sempre realizando cobranças, até que a equipe entendesse o conceito de multidisciplinaridade
levou tempo, pois o processo de cobrança/monitoramento entre os próprios membros do time
geraram muitos conflitos.
6.Referências
Andrade, w. et al, O.J.B.P.S.F (2015). “Gestão de Projeto com Scrum: Um Estudo de Caso”.
Disponível em: < http://eloquium.com.br/wp/wp-content/uploads/2015/12/scrum.pdf> Acesso
em 25 de maio de 2017.
Bassi Filho, Dairton. (2008) ”Experiências com desenvolvimento Ágil”. São Paulo. Disponível
em: < https://www.ime.usp.br/~dairton/files/Dissertacao-DairtonBassi.pdf > Acesso em 17 de
abril de 2017.
Carvalho, Bernardo; Mello, Carlos.(2012) ”Aplicação do método ágil scrum no

desenvolvimento de produtos de software em uma pequena empresa de base
tecnológica”. Gest. Prod., São Carlos , v. 19, n. 3, p. 557-573. Disponível em
<http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104530X2012000300009&lang
=pt > Acesso em: 20 de abril de 2017.
Leitão, Michele de Vasconcelos.(2010) “Aplicação de Scrum em Ambiente de Desenvolvimento

de Software Educativo”. Disponível em:
<http://tcc.ecomp.poli.br/20101/TCC_final_Michele.pdf> Acesso em 19 de abril 2017.
Pressman, R. S.(2006) “Engenharia de Software”. 6ª. ed. São Paulo: MCGrawHill,
Schwaber K.; Sutherland J.(2009) “Scrum Guide: Developed and sustained”. Scrum.org.
Schwaber, K.; Beedle, M.(2002) “Agile Software Development With Scrum”. Prentice-Hall,
Nova Jersey.
Schwaber, Ken; Sutherland, Jeff.(2013) “Um guia definitivo para o Scrum: As regras do jogo”.
Disponível em:<https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-
BR.pdf>. Acesso em: 19 de julho 2017.
Silva, M. A. C.; Roriz Filho, H.; Silva, H. F. N. (2010) “Análise do BA durante o Processo
Scrum. XVII Simpósio de Engenharia de Produção”. Bauru – SP.
Sommerville, I.(2011) “Engenharia de software”, 9ª Edição, Ed. Pearson Prentice Hall, São
Paulo.
Varaschim, Jacques.(2009) “Implantando o SCRUM em um Ambiente de Desenvolvimento de

Produtos para Internet”. Disponível em: <ftp://ftp.inf.puc-
rio.br/pub/docs/techreports/09_07_varaschim.pdf> Acesso em 06 de julho 2017.
7. Apêndice
472
Formulário 1
1) Você sabe o que está sendo desenvolvido? O que será o produto final e para quem está sendo
desenvolvido?
2) O prazo de entrega do produto é de conhecimento dos desenvolvedores? Se não, Quem
estipula o prazo de entrega?
3) Dentro da equipe cada desenvolvedor sabe o que seu "parceiro" está fazendo?
4) Existe alguma lista de prioridades para desenvolvimento do produto?
5) Você desenvolvedor, depende de outro desenvolvedor para finalizar algum processo? Se sim
o que pensa sobre isso?
6) Como é feita a prioridade das solicitações ?
7) Como é realizado o monitoramento diário de atividades ?
8) A equipe realiza o planejamento das demandas ?
9) A Equipe realiza estimativas das solicitações ?
10) Existem metas da equipe ?
11) A equipe utiliza requisitos como base no desenvolvimento ?
12) Quando o código é integrado ao servidor de versões ?
13) Como uma solicitação é definida como concluída ?
14) Quando a equipe discute sobre o andamento dos trabalhos ?
15) Os colaboradores possuem autonomia para cobrarem um dos outros ?
16) A entrega das solicitações são feitas com qual frequência ?
17) Como a equipe apresenta o que foi desenvolvido em um intervalo de tempo ?
18) A equipe possui papeis claros e ativos ?
19) Qual a medida utilizada nas estimativas ? (Story points, horas, pontos de função, ideal day)
20) A equipe discute a cada projeto/iteração/Fase, pontuando os itens que devem ser
melhorados e o que deve ser mantido ?
21) O processo de gerenciamento utilizado é transparente ?
22) O processo de gerenciamento é simples ?
Formulário 2
1) O que são métodos ágeis ?
2) O que é Scrum ?
3) Sabem diferença entre agilidade e velocidade ?
4) Vocês utilizam reuniões diárias ?
5) Utilizam backlog ?
6) Utilizam retrospectivas ?
7) Utilizam reuniões de revisão ?
8) Realizam estimativas de tarefas ?
9) Possuem meta de desenvolvimento ?
10) Realizam reuniões de planejamento ?
11) A equipe realiza priorizações frequentes das estórias ?
12) Possuem papeis claros e ativos ?
13) A equipe se sente motivada com o processo atual ?
14) Todo o trabalho realizado/ e a ser realizado está claro e de fácil acesso a equipe (Quadro,
Software, etc ) ?
15) Porque não utilizam SCRUM ?
473
Anais Eletrônicos ENUCOMP 2017 - X Encontro Unificado de Computação - www.enucomp.com.br/2017 - ISBN: 978-85-8320-201-1 331
Análise Comparativa do Algoritmo Dijkstra com e sem

Desfragmentação nas Redes Ópticas Elásticas
Selles G. F. C. Araújo1 , Ênio L. V. Barbosa1 , André C. B. Soares1 , José V. dos R. Júnior1
1
Abstract. Elastic optical networks have emerged with the goal of dealing with
the great growth of data traffic on the Internet, using the resources of the network
efficiently. Efficiency happens through the use of Orthogonal Frequency Divi-
sion Multiplexing technology, which allows the division of the spectrum into
frequency ranges called slots. For the establishment of an optical path in the
elastic networks, it is necessary to define a route and a range of spectrum. With
the establishment and closure of circuits in a dynamic scenario, the problem
of fragmentation arises, which makes it impossible to attend to new requests.
To mitigate this problem, defragmentation algorithms are run periodically. In
this work, an analysis of the Dijkstra algorithm with and without the use of de-
fragmentation is proposed, in order to evaluate the loss and gain related to the
metrics of circuit block probability, external fragmentation and spectrum usage.
Finally, the energy consumption of the scenarios was also analyzed.
Resumo. As redes ópticas elásticas surgiram com o objetivo de lidar com o

grande crescimento de tráfego de dados na Internet, utilizando os recursos da
rede de forma eficiente. A eficiência acontece através da utilização da tecno-
logia Orthogonal Frequency Division Multiplexing, que permite a divisão do
espectro em intervalos de frequência denominado slots. Para o estabelecimento
de um caminho óptico nas redes elásticas, é necessário a definição de uma rota
e de uma intervalo de espectro. Com o estabelecimento e encerramento dos
circuitos em um cenário dinâmico, surge o problema da fragmentação, que im-
possibilita o atendimento de novas requisições. Para mitigar este problema,
algoritmos de desfragmentação são executados com periodicidade. Neste tra-
balho, é proposto uma análise do algoritmo Dijkstra com e sem a utilização de
desfragmentação, a fim de avaliar a perda e o ganho relacionado às métricas
de probabilidade de bloqueio de circuito, fragmentação externa e utilização do
espectro. Por fim, foi analisado também o consumo energético dos cenários.
1. Introdução
O crescente aumento no número de usuários e o surgimento de diversos serviços na Inter-
net, tem requerido uma maior largura de banda no núcleo dos sistemas de comunicações.
Segundo a Cisco, estima-se que em 2021 cerca de 51% da população mundial estará co-
nectada à rede. Além disso, dentre as diversas aplicações existentes ou emergentes na In-
ternet, o vı́deo sob demanda será responsável por 82% do tráfego IP global [Cisco 2017].
474
Para suportar o alto crescimento do tráfego, as redes ópticas elásticas (EONs -

Elastic Optical Networks) tem se destacado por atender a grandes volumes de trans-
missões de dados de forma eficiente [Alexandre Fontinele 2016]. Isto acontece devido
a utilização da tecnologia Multiplexação Ortogonal por Divisão de Frequência (OFDM -
Orhogonal Frequency Division Modulation), que divide o espectro em slots de frequência,
permitindo assim flexibilidade no atendimento de requisições com diferentes taxas de bits.
No âmbito das redes elásticas, dois problemas fundamentais têm se tornado cada
vez mais recorrentes: o problema de roteamento e atribuição de espectro (RSA - Rou-
ting and Spectrum Assigment) e o problema de fragmentação de espectro. Para solucio-
nar o problema RSA, é necessário escolher a rota e faixa espectral ideal para atender as
requisições. Já o problema da fragmentação é mitigado a partir de execuções periódicas
de algoritmos de desfragmentação [Horota et al. 2014].
Neste trabalho, é apresentado uma análise comparativa do desempenho do algo-
ritmo Dijkstra (DJK) com e sem a utilização do processo de desfragmentação. A avaliação
do desempenho dos cenários considera as seguintes métricas: probabilidade de bloqueio
de circuito, utilização do espectro e fragmentação externa. Além disso, foi analisado
também o consumo energético rede. O algoritmo DJK foi escolhido para este estudo por
ser uma solução comumente utilizada na literatura para fins comparativos.
O restante deste trabalho está organizado da seguinte forma. A Seção 2 apresenta
os trabalhos relacionados. Na Seção 3, é apresentado conceitos e desafios das EON. A
Seção 4 apresenta a avalização de desempenho do estudo. E por fim, a Seção 5 apresenta
as conclusões e trabalhos futuros.
No contexto das EONs, o problema da fragmentação do espectro se torna comum. Este
problema acontece em decorrência do estabelecimento e remoção dos circuitos, gerando
na rede uma distribuição de pequenos fragmentos não-contı́guos no espectro, dificultando
o atendimento de novas demandas. Trabalhos na literatura têm sido proposto para mitigar
o problema da fragmentação [Horota et al. 2014, Moura et al. 2014].
Para aliviar a fragmentação na rede, é realizada a execução de algoritmos de
desfragmentação do espectro. O objetivo é reorganizar as conexões existentes a fim
de disponibilizar o maior número de slots contı́guos para acomodar futuras requisições.
Esse mecanismo de desfragmentação do espectro é um ponto significativo para redução
da probabilidade de bloqueio dos circuitos [Zhang et al. 2014]. Diversas estratégias de
desfragmentação são encontradas na literatura.
Em [Ba et al. 2017], é proposto uma estratégia de desfragmentação utilizando so-
brevivência, no qual cada circuito terá uma rota backup (secundária) que será utilizada
caso a rota primária falhe. Dessa forma, tanto as conexões primárias e de backup serão
realocadas. Quando uma conexão primária for reconfigurada, é realizado uma troca de
funções do caminho primário para o de backup. A avaliação de desempenho é feita com-
parando um cenário sem e com a utilização da estratégia proposta. A probabilidade de
bloqueio, utilização do espectro, número médio de realocações e troca de funções de ca-
minhos são as métricas utilizadas para avaliar o desempenho.
Já os autores em [Fávero et al. 2015], utilizam uma estratégia de desfragmentação
475
que realocam as conexões que compartilham o enlace mais fragmentado, de acordo com
uma métrica de fragmentação dada na proposta. O processo de desfragmentação é inici-
ado quando a quantidade de circuitos finalizados atinge um limiar (10, 50 e 100 utilizados)
e a avaliação de desempenho é realizada a partir da métrica de probabilidade de bloqueio.
Um esquema sem interrupção de tráfego utilizando a informação de Holding Time
dos circuitos é proposto em [Singh and Jukan 2016]. A ideia é reorganizar os circuitos
ativos em ordem descrescente de tempo de permanência na rede, do menor ı́ndice de
slot para o maior. Consequentemente, os circuitos serão finalizados seguindo de uma
extremidade à outra. Dito isso, o desempenho da rede foi avaliado através da métrica de
probabilidade de bloqueio de circuito e do número médio de reconfigurações.
Portanto, este estudo avalia o desempenho do algoritmo DJK com e sem
desfragmentação através de um amplo conjunto de métricas. O objetivo a partir da análise
comparativa dos cenários em questão é apresentar o impacto causado pelo processo de
desfragmentação no desempenho da rede sob vários aspectos.
3. Redes Ópticas Elásticas

Nas EONs, o espectro óptico é divido em um conjunto de slots com largura espectral de
6,25GHz ou 12,5GHz [Colombo and Morganti 2014, Huang et al. 2014]. Os slots adja-
centes podem ser agrupados para compor maiores intervalos de frequência, permitindo o
atendimento de requisições que exigem maior largura de banda.
Além da capacidade de agrupar slots, as EONs realizam a transmissão de dados
utilizando diferentes nı́veis de modulação. A modulação está relacionada à quantidade de
bits transmitidos simultaneamente em um sinal óptico. Para cada distância de propagação
do sinal óptico é determinado um formato de modulação, no qual são utilizados os
formatos BPSK(Binary Phase-Shift Keying), QPSK(Quadrature Phase-Shift Keying) e
16QAM[Gerstel et al. 2012], para as distâncias de 10.000, 5.000 e 1.000 quilômetros,
respectivamente.
Para o estabelecimento de um circuito óptico nas EONs, é fundamental defi-
nir uma a rota e selecionar um intervalo de espectro disponı́vel. Porém, é necessário
que a faixa espectral selecionada atenda a restrição de contiguidade e continuidade. A
restrição de contiguidade é atendida quando um conjunto de slots atribuı́dos a um cir-
cuito são adjacentes. Já para o atendimento da restrição de continuidade, o intervalo
espectral selecionado para uma requisição deve ser o mesmo em todos os enlaces da rota
[Shirazipourazad et al. 2013].
Por fim, é importante avaliar as EONs quanto ao consumo energético, que
consiste no uso dos recursos consumidos durante o funcionamento da rede. Para
uma análise do consumo, adotou-se o modelo de consumo energético proposto em
[Vizcaı́no et al. 2012a], no qual foram utilizados os transponders, comutadores ópticos e
amplificadores. O consumo de um transponder varia conforme o formato de modulação,
largura de banda e quantidade de slots da requisição [Vizcaı́no et al. 2012a]. O consumo
do comutador óptico depende do grau do nó, além de uma adição de 150 Watts para sua
localização [Vizcaı́no et al. 2012b]. Já o consumo para um amplificador, considerou-se 60
Watts por direção (par de fibras) do enlace, além da adição de 140 Watts pela localização
do amplificador [Vizcaı́no et al. 2012b].
476
4. Avaliação de Desempenho
Nesta seção é apresentado os resultados obtidos via simulações computacionais utilizando
o simulador SNetS (SLICE Network Simulator) [de Sousa Santos 2015]. Para a avaliação
de desempenho da rede, adotou-se a métrica de probabilidade de bloqueio de circuito,
probabilidade de bloqueio de banda, fragmentação externa, utilização do espectro e con-
sumo energético. A Tabela 1 apresenta os parâmetros utilizados para as simulações.
Tabela 1. Parâmetros de simulação

Parâmetros
Topologia NSFNet (14 nós e 21 enlaces)
Quantidade de Requisições 100.000
Quantidade de slots 400
Frequência do slot 12,5 GHz
Larguras de banda 80, 160, 320, 500, 750, 1000 e 1250 Gbps
Formatos de modulação BPSK, QPSK e 16QAM
Replicações 10
Pontos de carga 5
Nı́vel de confiança 95%
Em relação ao tráfego, as requisições na rede são geradas segundo um processo

poissoniano de taxa de chegada média (λ) e tempo de permanência dos circuitos expo-
nencialmente distribuı́do com média 1/ µ ( µ representa a taxa de atendimento média). A
carga de tráfego é distribuı́da uniformemente entre todos os pares de nós da rede e é dada
por ρ = λ / µ (Erlangs) [Alexandre Fontinele 2016].
Foi utilizado para os experimentos o algoritmo de roteamento Dijkstra (DJK), que
seleciona a rota com menor distância, e a polı́tica de alocação de espectro FirstFit, que
retorna o primeiro intervalo de espectro disponı́vel que atenda uma requisição.
Para os cenários com desfragmentação, as conexões são realocadas para uma
das três menores rotas de um par origem-destino. A rota selecionada será a que apre-
senta o conjunto de slots mais próximo do inı́cio do espectro. Após a escolha da nova
posição na rede, a migração do tráfego acontece com a utilização da técnica make-before-
break[Takagi et al. 2011], no qual é necessário ligar um circuito em sua nova posição
antes de desligá-lo da sua posição anterior, não interrompendo os serviços.
Com relação ao inı́cio e periodicidade de execução da desfragmentação, uma
condição especı́fica deve ser atendida, denominada de gatilho. O gatilho utilizado é ba-
seado na proposta de [Fávero et al. 2015], no qual o processo de desfragmentação ocorre
quando a quantidade de requisições liberadas na rede atingir um limiar. Foram gerados
três cenários com desfragmentação e limiares 10, 50 e 100.
A Figura 1 apresenta a probabilidade de bloqueio de circuitos. Os experi-
mentos com desfragmentação apresentam taxa de bloqueio inferior ao cenário sem
desfragmentação. Isso acontece devido o maior atendimento de requisições, pois a
reconfiguração das conexões produz novos espaços contı́guos.
Ainda na Figura 1, o DJK(Gat=10) apresenta a menor taxa de bloqueio em todos
os pontos de carga com relação a todos os outros cenários. Quando a carga é 300 er-
477
Probabilidade de Bloqueio por Circuito (NSFNet)

0,25
Probabilidade de Bloqueio 0,2
0,15
0,1
0,05
0
100 150 200 250 300
Carga (Erlangs)
DJK DJK (Gat=10) DJK (Gat=50) DJK (Gat=100)
Figura 1. Probabilidade de bloqueio de circuito do cenário com e sem

desfragmentação.
langs, por exemplo, observa-se que a diminuição da probabilidade de bloqueio do DJK

(Gat=10), DJK (Gat=50) e DJK (Gat=100), em relação ao DJK foi de 32%, 28% e 22%
respectivamente. Quanto menor foi o valor do gatilho, mais reconfigurações ocorreram
na rede e portanto, mais circuitos foram atendidos.
Fragmentação Externa (NSFNet)

0,6
0,55
Fragmentação Externa
0,5
0,45
0,4
0,35
0,3
0,25
0,2
100 150 200 250 300
Carga (Erlangs)
Figura 2. Fragmentação externa.
Já na Figura 2, é apresentado os resultados da fragmentação na rede. O cenário

com maior ı́ndice de fragmentação é o DJK, pois não utiliza estratégia para lidar com a
distribuição de pequenos fragmentos não-contı́guos no espectro. O DJK(Gat=10) apre-
478
senta a menor utilização do espectro com redução média de 14% em relação ao DJK. A
redução da fragmentação acontece devido a reorganização das conexões ativas da rede. E
além disso, o processo de reorganização suaviza a existência de fragmentos não-contı́guos
no espectro.
Utilização do Espectro Óptico (NSFNet)

0,55
0,5
Taxa de Utilização do Espectro
0,45
0,4
0,35
0,3
0,25
0,2
100 150 200 250 300
Carga (Erlangs)
Figura 3. Utilização do espectro óptico.
De acordo com a Figura 3, o cenário com desfragmentação DJK(Gat=10),

DJK(Gat=50) e DJK(Gat=100), obtiveram melhor desempenho em termos de utilização
do espectro. Observa-se que quando o tráfego é 300 erlangs, a utilização do espectro
óptico do DJK(Gat=50) é próximo de 50% enquanto a do DJK é cerca de 40%, apre-
sentando um ganho de 25%. Isso ocorre devido a desfragmentação, no qual permite a
utilização de recursos que antes eram impossibilitados de serem usados.
Consumo Energético (NSFNet)

1,29E+20
1,09E+20
Consumo Energético (J)
8,9E+19
6,9E+19
4,9E+19
2,9E+19
9E+18
80 160 320 500 750 1000 1250
Largura de Banda (Gbps)
DJK DJK (Gat = 10) DJK (Gat = 50) DJK(Gat =100)
Figura 4. Consumo enérgetico da rede o primeiro ponto de carga.
479
É apresentado na Figura 4 o resultado do consumo energético da rede conside-

rando o primeiro ponto de carga. Observa-se que o algoritmo DJK apresentou um con-
sumo energético inferior quando comparado ao DJK com desfragmentação. Foi reali-
zado a média dos consumos por largura de banda, no qual o algoritmo DJK apresentou
um consumo energético inferior de 6,21 %, 6,00 % e 5,06 %, quando comparado ao
DJK(Gat=10), DJK(Gat=50) e DJK(Gat=100), respectivamente. O consumo de cenário
com desfragmentação é superior devido a reorganização das conexões permitir o aten-
dimento de requisições que seriam bloqueadas por fragmentação, possibilitando maior
utilização dos recursos.
5. Conclusão
O crescente tráfego de dados está diretamente relacionado ao aumento no número de

usuários da Internet e o surgimento de aplicações que necessitam de maiores larguras
de banda. Neste contexto, uma candidata promissora para lidar com esse crescimento
exponencial de dados são as redes ópticas elásticas.
As redes elásticas aproveitam de forma mais eficiente os recursos da rede que as
redes atuais. A tecnologia OFDM utilizada nas redes elásticas, permite dividir o espectro
em intervalos de frequência denominado slots, os quais podem ser agrupados para atender
requisições que necessitem de maior largura de banda.
A possibilidade de alocar e desalocar diferentes slots, ocasiona o problema da
fragmentação, o qual contribui para o bloqueio de requisições. Para amenizar este pro-
blema, é utilizada estratégias de desfragmentação, com o objetivo de reorganizar as co-
nexões a fim de liberar novos intervalos de frequência. Isto, por sua vez, gera a possibili-
dade de estabelecimento de novas demandas de tráfego.
Foram realizadas simulações através da ferramenta SNetS, nas quais foi avali-
ado o desempenho do algoritmo DJK com e sem desfragmentação na topologia NSF-
Net. Foi constatado que, para os mesmos parâmetros de simulação, o cenário com
desfragmentação apresentou melhor probabilidade de bloqueio, fragmentação externa e
utilização do espectro em relação ao cenário DJK sem desfragmentação. A periodicidade
influenciou diretamente nos resultados obtidos. Isto é, quanto maior foi a frequência da
desfragmentação, maior foi o impacto no desempenho da rede neste estudo.
Referências
Alexandre Fontinele, Iallen Santos, J. N. N. D. R. C. e. A. S. (2016). Um novo algoritmo

rsa ciente de imperfeições de camada fı́sica para redes ópticas elásticas. Sociedade
Brasileira de Redes de Computadores.
Ba, S., Chatterjee, B. C., and Oki, E. (2017). Defragmentation scheme based on ex-
changing primary and backup paths in 1 plus 1 path protected elastic optical networks.
IEEE/ACM Transactions on Networking, 25(3):1717–1731.
Cisco, V. N. I. (2017). Tráfego global de ip irá triplicar nos próximos cinco anos ultrapas-
sando os 3 zettabytes em 2021. http://www.cisco.com/c/pt_pt/about/
press/news-archive-2017/20170608.html.
480
Colombo, C. and Morganti, S. (2014). Transmission aspects of optical superchannels

using reconfigurable dp-16qam/qpsk transponders in a flexgrid arrangement. In 2014
Fotonica AEIT Italian Conference on Photonics Technologies, pages 1–4.
de Sousa Santos, I. G. (2015). Alocação de recursos para o estabelecimento de circuitos
em redes ópticas wdm e ofdm. Universidade Federal do Piauı́.
Fávero, R. V., Marçal, J. S., Silva, P. C. B., Bonani, L. H., and Abbade, M. L. F. (2015).
A new elastic optical network defragmentation strategy based on the reallocation of
lightpaths sharing the most fragmented link. In 2015 SBMO/IEEE MTT-S International
Microwave and Optoelectronics Conference (IMOC), pages 1–5.
Gerstel, O., Jinno, M., Lord, A., and Yoo, S. J. B. (2012). Elastic optical networking: a
new dawn for the optical layer? IEEE Communications Magazine, 50(2):s12–s20.
Horota, A., Figueiredo, G. B., and d. Fonseca, N. L. S. (2014). Routing and spectrum
assignment algorithm with fragmentation minimization in elastic optical networks. In
2014 Brazilian Symposium on Computer Networks and Distributed Systems, pages
436–442.
Huang, S., Zhou, Y., Yin, S., Kong, Q., Zhang, M., Zhao, Y., Zhang, J., and Gu, W. (2014).
Fragmentation assessment based on-line routing and spectrum allocation for intra-data-
center networks with centralized control. Optical Switching and Networking, 14, Part
3:274 – 281. SI: Optimization and Application in Converged Optical and Data Center
Networks.
Moura, P. M., d. Fonseca, N. L. S., and Scaraficci, R. A. (2014). Fragmentation aware
routing and spectrum assignment algorithm. In 2014 IEEE International Conference
on Communications (ICC), pages 1137–1142.
Shirazipourazad, S., Derakhshandeh, Z., and Sen, A. (2013). Analysis of on-line routing
and spectrum allocation in spectrum-sliced optical networks. In 2013 IEEE Internati-
onal Conference on Communications (ICC), pages 3899–3903.
Singh, S. K. and Jukan, A. (2016). Non-disruptive spectrum defragmentation with
holding-time awareness in optical networks. In 2016 International Conference on Op-
tical Network Design and Modeling (ONDM), pages 1–6.
Takagi, T., Hasegawa, H., i. Sato, K., Sone, Y., Hirano, A., and Jinno, M. (2011). Disrup-
tion minimized spectrum defragmentation in elastic optical path networks that adopt
distance adaptive modulation. In 2011 37th European Conference and Exhibition on
Optical Communication, pages 1–3.
Vizcaı́no, J. L., Ye, Y., and Monroy, I. T. (2012a). Energy efficiency analysis for dyna-
mic routing in optical transport networks. In 2012 IEEE International Conference on
Communications (ICC), pages 3009–3014.
Vizcaı́no, J. L., Ye, Y., and Monroy, I. T. (2012b). Energy efficiency analysis for flexible-
grid ofdm-based optical networks. Computer Networks, 56(10):2400 – 2419. Green
communication networks.
Zhang, M., You, C., Jiang, H., and Zhu, Z. (2014). Dynamic and adaptive bandwidth
defragmentation in spectrum-sliced elastic optical networks with time-varying traffic.
Journal of Lightwave Technology, 32(5):1014–1023.
481
Rotulação Automática de Clusters Baseados em Análise de

Filogenias
Francisco N. C. de Araújo1 , Antonio H. M. Soares1 , Vinicius P. Machado1 ,
Ricardo de A. L. Rabêlo1
1
{netoaraujjo, ahelsonms}@gmail.com, {vinicius,ricardoalr}@ufpi.edu.br
Abstract. This paper proposes the joint use of unsupervised and supervised Ma-
chine Learning methods for data clustering and labeling tasks, respectively. The
labeling task consists in identifying the clusters through their most relevant cha-
racteristics. The algorithms used are known to be efficient, obtaining satisfac-
tory results in the definitions of the clusters formed, frequently exceeding 90%
accuracy in the done experiments.
Resumo. Neste trabalho propõe-se a utilização em conjunto de métodos de

Aprendizagem de Máquina não supervisionada e supervisionada para as tarefas
de agrupamento e rotulação de dados, respectivamente. A tarefa de rotulação
consiste em identificar os clusters através de suas caracterı́sticas mais relevan-
tes. Os algoritmos utilizados são reconhecidamente eficientes, obtendo resul-
tados satisfatórios nas definições dos clusters formados, frequentemente supe-
rando taxas de acerto de 90% nos experimentos realizados.
1. Introdução
A rápida popularização do uso de computadores para informatizar diversos setores da
sociedade resultou no expressivo crescimento das bases de dados. Pesquisadores pas-
saram então a utilizar técnicas de reconhecimento de padrões, por meio da detecção de
correlações entre os dados, que pudessem trazer à tona conhecimentos relevantes e úteis,
potencialmente contidos nessas bases [Fayyad et al. 1996].
Uma das principais técnicas de reconhecimento de padrões é o agrupamento (clus-
tering), o qual visa organizar os dados em grupos (clusters). É comum a presença de uma
diversidade de tipos de dados em uma mesma base, o que torna a inferência de uma
correlação entre eles um processo geralmente não trivial e relativamente complexo. O
método DAMICORE (do inglês, DAta MIning of COde REpository) [Sanches et al. 2011]
mostrou ser capaz de encontrar correlações em bases de dados de tipos mistos (registros
com diferentes tipos de dados).
Embora tenha sido um dos focos principais dos pesquisadores, o processo de clus-
tering não fornece informações que permitam inferir de forma clara as caracterı́sticas de
cada cluster formado, o que se deve a limitações das métricas de distância utilizadas
[Anaya-Sánches et al. 2008]. A rotulação de dados visa identificar essas caracterı́sticas e
permitir então que se tenha a plena compreensão dos clusters resultantes.
A rotulação de um cluster busca resumir sua definição, ou seja, descrevê-lo em
função de seus atributos mais relevantes, e suas respectivas faixas de valores, a fim de
482
melhor compreendê-lo. Assim, este conjunto de valores representa uma definição para
um cluster qualquer – isto é, um rótulo – capaz de fornecer ao especialista um melhor
entendimento sobre os dados.
Em Lopes et al. [Lopes et al. 2016] é proposta a utilização de Redes Neurais Ar-
tificiais para identificar quais os atributos relevantes, e suas respectivas faixas de valores,
que juntos formam o rótulo de um determinado cluster, ou seja, determinam as carac-
terı́sticas predominantes pelas quais os elementos foram alocados em um mesmo cluster.
A abordagem proposta por Lopes et al. [Lopes et al. 2016] obteve resultados positivos,
conseguindo rotular clusters com taxa de acerto média de 85%, aos ser aplicada em agru-
pamentos realizados pelo algoritmo K-means [MacQueen 1967].
O método de clustering utilizado é um dos fatores de maior influência sobre a
acurácia da rotulação. Assim, quanto melhor o agrupamento realizado, maior será a
capacidade dos rótulos encontrados definirem os clusters. Neste artigo apresenta-se a
utilização do Método de Rotulação Automática (MRA) [Lopes et al. 2016] para rotular
os clusters formados pelo DAMICORE, em substituição ao K-means, e compara-se os
resultados com os obtidos em Lopes et al. [Lopes et al. 2016]. Com isso aferiu-se a
eficiência do MRA em rotular agrupamento por filogenias, alcançando acurácia superior
a 90%.
O texto a seguir está organizado da seguinte maneira: na Seção 2 tem-se o re-
ferencial teórico com descrição dos métodos utilizados; na Seção 3 é descrita a forma
como foram conduzidos os testes e são apresentados os resultados; na Seção 4 é feita uma
comparação com os resultados de [Lopes et al. 2016]; por fim, na Seção 5 são apresenta-
das as conclusões obtidas.
A seguir apresenta-se o funcionamento básico dos métodos DAMICORE e MRA, utiliza-
dos para clustering e rotulação automática de dados, respectivamente.
2.1. DAMICORE
O DAMICORE une algoritmos largamente utilizados na literatura, produzindo resultados
eficientes como demonstrado em Sanches et al. [Sanches et al. 2011]. O método faz
uso de um conjunto de técnicas de várias áreas do conhecimento (Teoria da Computação,
Bioinformática e Fı́sica) de forma a extrair informações através de uma métrica universal e
robusta. O DAMICORE surge como um método de identificação de correlação entre tipos
de dados diversos, procedimento relativamente complexo para a maioria dos algoritmos
de agrupamento. Além disso, não é necessário informar ao algoritmo a quantidade de
clusters na qual os elementos devem ser alocados.
A execução do DAMICORE é iniciada pelo cálculo da Matriz de Distância usando
a NCD (Normalized Compression Distance) [Cilibrasi e Vitányi 2005], a qual calcula
uma razão de distância entre os dados determinando a semelhança entre os valores das
variáveis com base nos tamanhos de seus dados compactados. A NCD tem sido aplicada
com sucesso em áreas como a genética, literatura, música e astronomia. Essa abordagem
não requer nenhum conhecimento especı́fico do domı́nio da aplicação.
A partir da Matriz de Distância é reconstruı́da uma Árvore Filogenética
[Cancino e Delbem 2007] (que pode representar relações hierárquicas entre os in-
483
divı́duos) usando o algoritmo NJ (Neighbor Joining) [Saitou e Nei 1987]. A saı́da do NJ

é, por sua vez, convertida do formato Newick1 para o formato de Matriz de Adjacências.
Na Matriz de Adjacências obtida é aplicado o FA (Fast Newman Algorithm)
[Newman e Girvan 2004], um algoritmo de detecção de estruturas de comunidades da
área de Redes Complexas [Duch e Arenas 2005]. O FA realiza o Particionamento Fi-
nal das variáveis do problema, contemplando todos os nós da Árvore Filogenética. Por
fim são removidos os nós internos, restando apenas os nós folhas, que representam as
variáveis do problema.
2.2. Rotulação Automática de Clusters com MRA

Lopes et al. [Lopes et al. 2016] propõe a utilização de Redes Neurais Artificiais (RNA)
do tipo Perceptron Multi-Camadas para a obtenção de um rótulo para cada grupo, que
melhor o define. Para cada atributo dos elementos de um dado cluster é criada uma
RNA. Estas RNAs apresentam como saı́da o valor estimado do atributo avaliado (atributo
classe) e como entrada os valores dos demais atributos. As RNAs de um mesmo cluster
trabalham com os mesmos elementos variando somente a maneira como estes elementos
são utilizados – entrada ou saı́da.
Cada RNA é criada de forma a representar e avaliar a importância de um atributo
em relação aos demais, para cada cluster. Assim, um atributo é relevante se puder ter seu
valor determinado como uma combinação dos valores dos demais atributos. Os atributos
de saı́da das RNAs de cada cluster com as maiores taxas de acerto são definidos como
rótulo.
Um parâmetro de variação v é utilizado para reduzir ambiguidades entre rótulos
de diferentes clusters, assim, todos os atributos – bem como suas faixas de valores –
que obtiveram uma taxa de acerto até uma diferença de v da taxa de acerto máxima são
incluı́dos no rótulo, e os demais são descartados. Como exemplo, caso v tenha o valor 5
e a maior taxa de acerto para um determinado cluster tenha sido de 95%, todas as RNAs
com taxa de acerto a partir de 90% serão selecionadas para compor o rótulo.
3. Experimentos e Resultados
Para a realização dos experimentos foram utilizados os mesmos data sets usados por
Lopes et al. em [Lopes et al. 2016] para rotulação de clusters criados pelo algoritmo K-
means (Glass, Iris e Seeds). A Figura 1 resume as etapas da metodologia utilizada. Antes
de serem agrupados os data sets foram submetidos a um pré-processamento, composto
pelas fases de discretização (I) e codificação (II).
Os atributos cujos valores eram contı́nuos foram discretizados utilizando dois
métodos: EWD (Equal Width Discretization), no qual o intervalo de valores assumidos
pelo atributo é dividido em faixas de larguras iguais; e o EFD (Equal Frequency Dis-
cretization), que divide o intervalo de valores do atributo de forma a alocar a mesma
quantidade de elementos em cada faixa resultante.
Em seguida, os data sets foram submetidos a uma fase de codificação na qual os
valores de atributos numéricos são substituı́dos por códigos alfanuméricos. Essa fase visa
1
usualmente empregado por ferramentas de bioinformática.
484
Figura 1. Etapas do método proposto.
reforçar a diferença entre valores como, por exemplo, 1 e 11 – que por vezes são conside-
rados mais próximo que 1 e 2. O data set codificado é então submetido ao DAMICORE
para realização do agrupamento (III). Obtém-se ao final do processo, uma lista contendo
o ı́ndice de cada elemento seguido por um número inteiro representando o cluster ao
qual o elemento foi alocado. Esses valores são adicionados ao data set original e então
submetidos ao MRA (IV), que fornecendo um rótulo para cada cluster.
As Tabelas 1 a 3 apresentam os resultados obtidos pela aplicação do MRA sobre
os clusters formados pelo DAMICORE para os 3 data sets utilizados. Ressalta-se que
são apresentados somente os melhores resultados em relação ao método de discretização
(EWD ou EFD), sendo a quantidade de faixas utilizada a mesma apontada pela literatura
para cada data set. Além disso os valores atribuı́dos à variação v em cada experimento
foram os mesmos utilizados por Lopes et al. [Lopes et al. 2016].
3.1. Glass - Identificação de Vidros
O data set Glass se refere à identificação de vidros e pode ser encontrado no repositório
de dados UCI Machine Learning2 . O data set é composto por 214 elementos (amostras
de vidros), caracterizados por 9 atributos, definindo seu Índice de Refração (IR) e sua
composição quı́mica em termos das porcentagens dos óxidos (Na, Kg, Al, Si, Ca, Ba e Fe).
Os elementos podem ser organizados em 7 clusters diferentes quanto à sua destinação de
uso e a presença ou não de processamento [Evett e Spiehler 1988].
A Tabela 1 apresenta os resultados da rotulação obtidos em relação ao data set
Glass utilizando o método de discretização EFD. O DAMICORE organizou os elementos
em 22 clusters. Entretanto é possı́vel visualizar que os clusters 1 e 4 possuem o mesmo
rótulo, que se repete ainda em outros clusters não visı́veis na Tabela 1. Isto ocorre pelo
fato de o DAMICORE subdividir um cluster maior em clusters menores, devido à natu-
reza hierárquica da reconstrução de filogenias inerente à estrutura de árvore.
Em vários dos demais grupos vê-se o atributo Ba com a mesma faixa de valores (0
∼ 0,15). Porém, quando combinado com outros atributos considerados relevantes (e suas
faixas de valores), novos rótulos são formados, evidenciando caracterı́sticas diferentes
entre clusters, de fato, distintos.
2
http://archive.ics.uci.edu/ml/datasets/Glass+Identification
485
Tabela 1. Rótulos e taxas de acerto obtidos pelo MRA aplicado aos clusters
formados pelo DAMICORE no data set Glass.
Rótulos Análise
Cluster # Elem. Rel. (%)
Atrib. Intervalo # Erros Acertos (%)
1 15 Ba 0 ∼ 0,15 100 0 100
.. .. .. .. .. .. ..
. . . . . . .
4 9 Ba 0 ∼ 0,15 100 0 100
.. .. .. .. .. .. ..
. . . . . . .
IR 1,5202 ∼ 1,5339 66,67 1 92,86
14 14 Si 71,96 ∼ 72,48 66,67 1 92,86
Ba 0 ∼ 0,15 72,22 2 85,71
.. .. .. .. .. .. ..
. . . . . . .
21 13 Mg 0 ∼ 2,39 100 0 100
K 0 ∼ 0,13 100 0 100
22 9 Mg 0 ∼ 2,39 100 0 100
Al 1,94 ∼ 3,5 100 0 100
3.2. Iris - Identificação de Plantas

Este data set contém 3 classes com 50 elementos cada e se refere à identificação de
plantas. Cada classe corresponde a um tipo especı́fico da planta Iris. É apresentado
em Fisher [Fisher 1936], podendo ser encontrado no repositório de dados UCI Machine
Learning3 .
Os 150 elementos do data set são descritos por 4 caracterı́sticas cujos valores são
contı́nuos: comprimento da pétala (PL), largura da pétala (PW), comprimento da sépala
(SL) e largura da sépala (SW). Os resultados obtidos são apresentados na Tabela 2. Neste
caso o método de discretização EWD apresentou os melhores resultados.
Para este data set o DAMICORE definiu um total de 18 clusters. Mais uma vez
observa-se a presença de clusters com rótulos iguais (grupos 10 e 13), além de outros que
não estão visı́veis na Tabela 2, reafirmando a natureza hierárquica do agrupamento. Os
demais clusters exibidos apresentam rótulos distintos, caracterizando-os individualmente.
3.3. Seeds - Identificação de Sementes

O último data set utilizado nos experimento se refere à identificação de sementes de plan-
tas e – assim como os data sets Glass e Iris – pode ser encontrada no repositório de dados
UCI Machine Learning4 Seeds, tendo sido apresentado em Kulczycki e Charytanowicz
[Kulczycki e Charytanowicz 2011].
Este conjunto de dados é composto por 210 amostras de 3 tipos de sementes de
trigo, sendo 70 amostras de cada tipo. Os elementos são descritos por 7 atributos que re-
presentam as caracterı́sticas geométricas das sementes: área, perı́metro, densidade, com-
primento da semente (LK), largura da semente (WK), coeficiente de assimetria (AC) e
3
http://archive.ics.uci.edu/ml/datasets/Iris
4
http://archive.ics.uci.edu/ml/datasets/seeds
486
formados pelo DAMICORE no data set Iris.
Rótulos Análise
PW 0,1 ∼ 0,4 100 0 100
1 12
SL 4,0 ∼ 5,6 93,33 1 91,67
PW 0,1 ∼ 0,4 100 0 100
2 11 SL 4,3 ∼ 4,9 86,67 2 81,82
PL 1 ∼ 1,7 100 0 100
.. .. .. .. .. .. ..
. . . . . . .
10 8 PW 1,1 ∼ 1,5 100 0 100
.. .. .. .. .. .. ..
. . . . . . .
13 8 PW 1,1 ∼ 1,5 83,33 0 100
.. .. .. .. .. .. ..
. . . . . . .
PW 1,9 ∼ 2,5 100 0 100
18 7
PL 6,3 ∼ 7 100 0 100
comprimento do sulco da semente (LKG). Os resultados obtidos para este data set, utili-
zando o método de discretização EFD (que forneceu os melhores resultados), são exibidos
na Tabela 3.
formados pelo DAMICORE no data set Seeds.
Rótulos Análise
WK 3,073 ∼ 3,337 72,22 2 84,62
1 13
Área 13,37 ∼ 15,11 66,67 5 61,54
.. .. .. .. .. .. ..
. . . . . . .
Wk 3,073∼ 3,337 100 0 100
12 7 Área 12,05 ∼ 13,37 100 0 100
Perı́metro 13,31 ∼ 14,02 100 0 100
.. .. .. .. .. .. ..
. . . . . . .
AC 4,933 ∼ 8,456 72,22 2 84,62
Área 10,59 ∼ 12,05 66,67 2 84,62
23 13
LKG 4,805 ∼ 5,132 66,67 2 84,62
Perı́metro 12,41 ∼ 13,31 66,67 3 76,92
O DAMICORE determinou um total de 23 clusters para este data set. O número

de clusters formado foi mais de 7 vezes superior ao apontado pela literatura (3). Nova-
mente houve repetição nos rótulos atribuı́dos aos clusters, o que mostra que na verdade
são subclusters de um cluster maior. A taxa de acerto dos rótulos definidos novamente
foi superior à obtida com o agrupamento do K-means.
487
4. Discussão dos Resultados

A Figura 2 apresenta um gráfico comparativo entre as taxas de acerto da rotulação re-
sultantes da aplicação do MRA aos agrupamentos realizados pelo K-means e pelo DA-
MICORE sobre os 3 data sets citados anteriormente. Os valores fazem referência à taxa
de acerto total, em que o número de acertos corresponde ao total de elementos que se
enquadram nas faixas de valores de todos os atributos apontados como relevantes para
determinado cluster.
Figura 2. Comparação entre as taxas de acerto do MRA aplicado aos clusterings

realizados pelo K-means e pelo DAMICORE.
A taxa de acerto do MRA para os agrupamentos do DAMICORE foi superior

nos 3 casos, pois o método consegue expressar melhor a similaridade entre os elementos
de cada cluster. Para o data sets Glass a diferença em relação à rotulação dos clusters
formados pelo K-means foi de apenas 5,14%.
Para a rotulação do agrupamento do data set Seeds, embora a taxa de acerto tenha
sido de apenas 80,00%, ela está 25,71 pontos percentuais acima da obtida ao se rotular
o agrupamento do K-means – que foi apenas 54,29%. O resultado que mais se destacou
foi o obtido na rotulação do data set Iris, onde a taxa de acerto com o agrupamento do
DAMICORE (92,00%) ficou 29,33% acima da obtida com o agrupamento do K-means,
que foi de apenas 62,67%.
5. Conclusão
O Método de Rotulação Automática (MRA) foi utilizado para rotular clusters forma-
dos pelo DAMICORE. Os resultados obtidos foram comparados com os apresentados
em Lopes et al. [Lopes et al. 2016], ao se realizar a rotulação automática sobre clus-
ters formados pelo K-means. A análise dos resultados mostrou que os rótulos obtidos da
aplicação do MRA sobre os clusters formados pelo DAMICORE possuem maior acurácia
em comparação à alcançada pela aplicação sobre o agrupamento do K-means.
A eficácia da rotulação obtida para o agrupamento do DAMICORE é atribuı́da à
quantidade de clusters resultantes. Com um maior número de clusters ocorre uma maior
especificidade das caracterı́sticas de seus respectivos elementos, devido ao menor grau de
488
generalização. Reforça-se ainda o fato de que a técnica de agrupamento é determinante

para a qualidade dos rótulos atribuı́dos pelo MRA, pois quanto maior for a semelhança
intra-grupo maior será a acurácia dos rótulos encontrados.
Referências
Anaya-Sánches, H., Pons-Porrata, A., e Berlanga-Llavori, R. (2008). A new document
clustering algorithm for topic discovering and labeling. In 13th Iberoamerican Con-
gress on Pattern Recognition - CIARP 2008, pags 161–168. LNCS.
Cancino, W. e Delbem, A. (2007). Inferring phylogenies by multi-objective evolutionary
algorithm. In International journal of information technology and intelligent compu-
ting, pags 1–26.
Cilibrasi, R. e Vitányi, P. (2005). Clustering by compression. In IEEE Transactions on
Information Theory, pags 1523–1545. University of California Press.
Duch, J. e Arenas, A. (2005). Community detection in complex networks using extremal
optimization. In Physical Review E, pags 406–425.
Evett, I. e Spiehler, E. (1988). Rule induction in forensic science. In Knowledge based
systems, pags 152–160. Halsted Press.
Fayyad, U., Piatetsky-Shapiro, G., e Smyth, P. (1996). From data mining to knowledge
discovery in databases. In Advances in Knowledge Discovery and Data Mining, pags
37–54. AAAI Press.
Fisher, R. (1936). The use of multiple measurements in taxonomic problems. In Annals
of Eugenics, pags 17–188.
Kulczycki, P. e Charytanowicz, M. (2011). A complete gradient clustering algorithm.
In Proceedings of the Third International Conference on Artificial Intelligence and
Computational Intelligence, pags 497–504. Springer-Verlag.
Lopes, A., Machado, V., e Rabêlo, R. (2016). Automatic labelling of clusters of discrete
and continuous data with supervised machine learning. In Knowledge-Based Systems,
pags 231–241. LNCS.
MacQueen, J. (1967). Some methods for classification and analysis of multivariate ob-
servations. In Proceedings of the fifth Berkeley Symposium on Mathematical Statistics
and Probabilitys, pags 281–297. University of California Press.
Newman, M. e Girvan, M. (2004). Finding and evaluating community structure in
networks. In Physical Review E, pags 406–425.
Saitou, N. e Nei, M. (1987). The neighbor-joining method: a new method for reconstruc-
ting phylogenetic trees. In Molecular Biology and Evolution, pags 406–425.
Sanches, A., Cardoso, J., e Delbem, A. (2011). Identifying merge-beneficial software
kernels for hardware implementation. In Reconfigurable Computing and FPGAs (Re-
ConFig), pags 74–79. AAAI Press.
489
TECLA – Um Módulo para Classificação de Expressões

Temporais no Português Brasileiro
José Patrício de Sousa Filho1 , Raimundo Santos Moura2
1
Bairro Ininga – CEP 64049-550 – Teresina – PI – Brasil
2
Departamento de Computação
Universidade Federal do Piauí (UFPI) – Teresina, PI – Brasil
{patriciosousafilho,jpegx100}@gmail.com1 , [email protected]
Abstract. The area of Natural Language Processing seeks to analyze the lan-
guage used naturally by humans for interpersonal communication. A task that
has gained prominence in this area refers to the temporal location of the expres-
sed opinion or fact, that is, when the fact or opinion occurred or was expressed.
This task is commonly divided into the Temporal Expressions Classification and
Normalization subtasks, the first task being to identify time-denoting expressi-
ons and the second task in order to obtain a formal date from the expressions
identified in the first one. This work focuses on the Classification subtask and
describes the creation of the TECLA module for identification of temporal ex-
pressions for Portuguese.
Resumo. A área de Processamento de Linguagem Natural procura analisar a

linguagem utilizada naturalmente pelos seres humanos para comunicação in-
terpessoal. Uma tarefa que tem ganhado destaque nessa área se refere à loca-
lização temporal da opinião ou fato expresso, isto é, quando o fato ou opinião
ocorreu ou foi expresso. Essa tarefa é comumente dividida nas subtarefas de
Classificação e Normalização de Expressões Temporais, estando a primeira en-
carregada de identificar expressões que denotam tempo e a segunda de obter
uma data formal a partir destas expressões. Este trabalho tem seu foco na
subtarefa de Classificação e descreve a criação do módulo TECLA para identi-
ficação de expressões temporais para o Português.
1. Introdução
Não há dúvidas de que a Internet mudou as formas de relação humana e elevou o impacto
de situações que de outra forma ficariam restrits a um pequeno grupo de indivíduos, como
vídeos ou relatos de acontecimentos curiosos e não-usuais que de um dia para o outro
percorrem todo o mundo e são vistos e comentados por milhões de pessoas. Com a
internet as pessoas conseguem produzir e consumir conteúdo em quantidades e formatos
nunca antes figurados. E através das Redes Sociais Online torna-se real e cotidianamente
presente a troca de informações e experiências entre pessoas das mais diversas culturas
ao redor do globo.
Segundo a União Internacional das Telecomunicações(UIT) [1], órgão ligado à
Organização das Nações Unidas(ONU), no final de 2016 quase 3,5 bilhões de pessoas
490
tinham acesso à internet, representando 47% da população mundial. Outro relatório di-
vulgado pela CISCO [2] mostra que em 2016 essas pessoas foram responsáveis pelo trá-
fego de mais de 2 exabytes de dados por dia na internet, sendo 17% destes utilizados por
aplicações como email, blogs, fóruns de discussão e etc.
Esses dados que trafegam pela internet levam consigo informações pessoais, opi-
niões e tendências, e manifestam tanto o pensamento coletivo quanto as impressões de
cada indivíduo sobre os mais variados assuntos. Daí pode-se observar o real valor desses
dados, uma vez que uma análise deles pode possibilitar – dentre diversos outros casos – a
uma empresa poder medir a aceitação de um produto, a um político poder saber os pontos
de discordância dos eleitores e suas propostas, ou a um pesquisador poder analisar traços
do comportamento humano. A área de Processamento de Linguagem Natural(PLN) é a
área da Ciência da Computação que se encarrega da análise destes dados.
O termo "Processamento de Linguagem Natural"é utilizado para definir a tarefa de
geração e compreensão de textos escritos em alguma das linguagens naturalmente faladas
pelos seres humanos, tais como: Inglês, Português, Espanhol e etc.
Uma tarefa que tem requerido especial atenção de pesquisados da área de PLN é
a Resolução de Expressões Temporais(RET), que de forma simplista consiste em obter
uma data formal para acontecimentos cujas datas ou períodos de tempo são descritos
valendo-se de termos e expressões próprias da linguagem natural. Bittar[3] defende que a
importância da tarefa de RET reside no fato de que a estrutura temporal é parte primordial
da narrativa e que só através dela pode-se obter completo entendimento do texto estudado.
Desta forma, podemos observar que a obtenção de dados temporais possibilita melhor
entendimento do contexto em que o texto foi criado ou a que se refere, como também
auxilia na organização cronológica dos fatos narrados.
Podemos utilizar como exemplo para a tarefa de RET a frase “chegarei no dia 7
de setembro e retornarei no dia seguinte” onde o autor especifica formalmente sua data
de chegada, mas não a de retorno. Neste caso uma ferramenta de RET deveria ser capaz
de identificar o termo “dia seguinte” como uma Expressão Temporal(ET) e normalizá-la
formalmente como dia 8 do mês de setembro.
A RET pode ainda ser dividida nas subtarefas de Classificação e Normalização.
Sendo a primeira responsável por identificar ETs presentes no texto original e a segunda
responsável por transformar cada ET encontrada em uma data ou período de tempo for-
mal.
O objetivo deste trabalho é apresentar a ferramenta TECLA(Temporal Expression
CLAssifier) que visa realizar a classificação de ETs para o Português. O restante deste
trabalho está organizado da seguinte forma: a Seção 2 descreve a fundamentação teórica,
onde estão explanados os princípais termos e conceitos pertinentes ao desenvolvimento
deste trabalho, como também as tecnologias utilizadas durante a fase de implementa-
ção; a Seção 3 discorre sobre os trabalhos que serviram de influencia e auxílio no desen-
volvimento deste; na Seção 4 estão descritos desenvolvimento e forma de utilização do
TECLA; já na Seção 5 temos a metodologia de avaliação utilizada e seus resutados; na
Seção 6 explanamos sobre os resultados gerais do TECLA e os trabalhos futuros a ele
relacionados; por fim temos a Seção 7 mostrando referências deste trabalho.
491
Nesta seção explanamos sobre os principais termos, ferramentas e tecnologias que são
importantes para a plena compreensão do restante deste trabalho.
2.1. Processamento de Linguagem Natural
Jackson e Moulinier[4] definem o termo Processamento de Linguagem Natural(PLN)

como os componentes de software ou hardware em um sistema computacional que ana-
lisam ou sintetizam linguagem falada ou escrita naturalmente pelos seres humanos, ex-
cluindo assim dessa definição linguagens formais como notação matemática ou lógica. A
área de PLN tem evoluído nos últimos anos devido ao fenômeno do enorme crescimento
na produção e distribuição de dados pela internet e à necessidade de análise automatizada
destes dados.
O uso de PLN pode ser visto em uma grande quantidade dos sistemas computaci-
onais atuais. Diversas aplicações que utilizamos cotidianamente como o corretor automá-
tico dos teclados de Smartphones ou tradutores de textos que encontramos online utilizam
técnicas de PLN para realizar suas tarefas.
Existem também os grandes projetos de computação cognitiva como o IBM Wat-
son[5] que utiliza largamente PLN para diversas de suas tarefas ou o Google Flu Trends[6]
que estima com grande precisão a quantidade de casos de gripe que ocorrerão em deter-
minada região com base nas pesquisas e sites acessados por usuários nessa região.
2.2. Expressões Regulares
Jurafsky e Martin[7] definem expressão regular(ER) como “a notação padrão para se-
quencias de caracteres”. Expressões regulares são amplamente utilizadas na computação
para a representação de padrões textuais, busca de subpartes de um texto, definição de
sintaxe de linguagens formais e etc.
Imagine por exemplo que definamos uma linguagem cujas palavras devam iniciar
com o símbolo a, e serem seguidas por uma sequencia de tamanho não-determinado de
ocorrências dos símbolos a e b, terminando com o símbolo b. Essa linguagem teria então
palavras como: aaaaab, ab e abab.
Figura 1. Exemplo da definição de uma ER
Assim, uma expressão regular que denote tal linguagem poderia ser definida como
mostrado na Figura 1. Onde os parentêses servem para agrupar subpartes da expressão,
o asterísco significa a ocorrência de zero ou mais instâncias do símbolo ou conjunto de
símbolos agrupados antecessor a ele, e a barra vertical representa o operador lógico "ou".
Então podemos ver que a ER da Figura 1 representa formalmente a linguagem definida
no parágrafo anterior.
492
2.3. Reconhecimento de Expressões Temporais

Ahn et al.[8] defendem que para a real compreensão de uma informação faz-se neces-
sário entender sua estrutura temporal. Assim, o Reconhecimento de Expressões Tempo-
rais(RET) busca encontrar no texto as ETs e trabalhá-las, afim de contribuir para o total
entendimento da informação expressa no texto. A tarefa de RET pode – e comumente é –
dividida nas subtarefas de classificação e normalização.
A subtarefa de classificação é o ato de identificar a parte do texto que corresponde
a uma ET, e é de suma importância para a continuidade do processo de RET. Já a subtarefa
de normalização funciona transformando o resultado da fase de classificação em um valor
de data ou período de tempo computável.
Como exemplo podemos imaginar que um texto publicado no dia 19 de janeiro
de 1995 contenha a frase “Anteontem nós fomos à pizzaria”, a saída esperada do módulo
de classificação de ETs de uma ferramenta de RET seria a palavra “anteontem” por esta
representar a data não-computável de acontecimento do fato expresso. Em seguida o
módulo de normalização de ETs com base na palavra “anteontem” e na data de publicação
do texto deveria dar como resultado a data “17-1-1995” em formato computável.
2.4. Corpus
A palavra corpus vem do Latim e significa corpo ou conjunto. Neste trabalho o sentido do
termo corpus é o mesmo empregado pelos pesquisadores da área de linguística e definido
por Sardinha[9] como “conjunto de dados linguísticos textuais coletados criteriosamente
com o propósito de servirem para a pesquisa de uma língua”.
McEnery et al.[10] categorizam os corpus em anotados e não-anotados. Sendo
os primeiros aqueles que contem marcações ou metadados linguísticos que trazem ganho
de informação, ou seja, um corpus anotado é aquele no qual além do texto existem in-
formações linguísticas perninentes ao escopo da pesquisa para o qual ele servirá. Já um
corpus não-anotado é aquele onde encontra-se somente o texto na forma como foi escrito
ou trasncrito originalmente.
2.5. Web Scraping

O termo Web Scraping se refere à ação de extrair informações encontradas em páginas
Web. Um programa que faz Web Scraping típicamente realiza o download de uma página
encontrada na Web e retira destas as marcações HTML e código CSS afim de extrair da
página somente as informações requeridas.
2.6. Tecnologias e Ferramentas

2.6.1. Python
Python é uma linguagem de programação interpretada e multidomínio amplamente uti-

lizada. Martelli Et al.[12] descrevem Python como uma linguagem de programação de
alto nível focada na agilidade e facilidade de desenvolvimento. Também é comumente
utilizada como linguagem de script por sua sintaxe simples e compatibilidade com uma
grande variedade de ecossistemas. Por essas características ela foi escolhida para ser
utilizada na implementação da ferramenta descrita neste trabalho.
493
2.6.2. Scrapy
Scrapy[13] é um framework colaborativo e de código aberto para extração de dados em

páginas Web – ou Web Scraping como mencionado anteriormente. É desenvolvido em
Python[12] e é um dos principais frameworks utilizados para captura de informações en-
contradas online. O Scrapy conta com uma comunidade ativa, vasta documentação oficial
e diversos artigos e tutoriais escritos por outros usuários. Ele foi utilizado neste trabalho
para a coleta dos textos que compuseram o corpus utilizado na avaliação.
2.6.3. Corpus Booking.com
Na fase de avaliação desse trabalho fez-se necessário um corpus anotado com informações
sobre as expressões temporais. Antes de realmente criar o corpus anotado fez-se necessá-
ria a definição do domínio deste. Para tal, foram coletados e analisados 50 comentários de
cada um dos domínios de: hotelaria, jogos online, cinema e produtos eletrônicos. Sendo
escolhido o domínio de hotelaria por este apresentar maior número de ETs por comentário
em relação aos demais.
Assim, foi criado um corpus contendo 200 comentários extraídos do site Boo-
king.com[11] sobre 5 hóteis das cinco regiões do Brasil no período de janeiro a dezembro
de 2016. O site Booking.com foi escolhido por ter mais de 1,3 milhões de hóteis cadas-
trados em todo o mundo, e 121 milhões de comentários de clientes reais.
O corpus teve suas ETs anotadas por um especialista da área de PLN em conjunto
com um especialista da área de linguística.
Nessa seção são descritos os trabalhos relacionados ao nosso ou que de alguma forma
serviram de influência para este.
Antes de mais nada é importante falar sobre os corpus CSTNews[14] e
TimeBankPT[15]. Eles foram essenciais para o desenvolvimento do nosso método de
classificação de ETs, pois possibilitaram o entendimento da forma com ETs se manifes-
tam em textos em Português e a modelagem dos padrões utilizados para a identificação
destas. O CSTNews contém um conjunto de mais de 150 notícias veiculadas por jornais
de circulação no Brasil, as notícias têm suas expressões temporais anotadas por um grupo
de especialistas das áreas de computação e linguística. Já o TimeBankPT é a tradução do
corpus TimeBank(originalmente escrito e anotado em Inglês) para o Português de Portu-
gal – que não apresenta diferenças com o Português Brasileiro no que se refere às ETs.
O trabalho de Menezes e Pardo[16] propõe um método para RET. Para a im-
plementação os autores optaram por seguir a estratégia de dividir a tarefa nas fases de
Classificação e Normalização. Durante a fase de Classificação, os autores puderam notar
que a maioria das ETs apresenta padrões que podem ser previstos utilizando Expressões
Regulares(ERs). Escolhendo esta como a forma de identificação das ETs. Tais ERs foram
obtidas através do estudo do corpus CSTNews[14].
O protótipo criado pelos autores foi então submetido a um conjunto de textos de
entrada, e sua saída(a anotação das expressões temporais contidas nos textos) foi ava-
494
liada pela comparação com a anotação realizada por especialistas. Obtendo a anotação
automática índices de acerto de 75% em comparação com realizada pelos especialistas.
Entretanto os autores ressaltam que o projeto ainda se encontra em fase de desenvolvi-
mento, necessitando de ajustes.
No trabalho de Baptista et al.[17] os autores detalham as regras e relatam as expe-
riências obtidas na segunda edição do HAREM. O HAREM é um concurso que contém
uma série de tarefas que fazem uso de PLN, onde os participantes são convidados a mos-
trar seus trabalhos, trocar ideias e promover o avanço do estudo de PLN no Português. Ele
é descrito pelos autores como “uma avaliação conjunta na área de PLN em português”.
O evento teve duas edições, sendo a primeira em 2006 contando com 5 grupos de pes-
quisa em inscritos, e a segunda em 2008, contando com 20 grupos inscritos e sendo esta
a primeira a incluir a tarefa de RET, nomeada de “PISTA TEMPO”. Todas as discussões,
apresentações e resultados das tarefas do evento foram sumarizados no Livro Segundo
HAREM[17] que entre outras contribuições oferece um panorama geral do estado da arte
das técnicas de PLN exploradas pelos participantes do evento, seus resultados e métodos
de avaliação.
Outro trabalho que nos influenciou durante o desenvolvimento deste foi
Carneiro[18] que descreve a proposta e implementação do CoppeTER(Coppe Tempo-
ral Expression Recognizer), um sistema que trabalha através da combinação de regras e
aprendizado de máquina para o reconhecimento e normalização de ETs em português. O
protótipo implementado por Carneiro[18] trabalha utilizando um processador linguístico
como porta de entrada para o sistema, que retira construções textuais não essenciais para
a tarefa de reconhecimento das ETs, e gera como saída um conjunto de tuplas do tipo <pa-
lavra, classe_gramatical>. O resultado dessa fase é então processado pelo módulo de Pro-
cessamento Temporal, que utiliza um conjunto de expressões regulares associados a um
dicionário de gatilhos(descrito pelo autor como um “conjunto de palavras comumente as-
sociadas a expressões temporais”) e um dicionário de datas especiais para escolher quais
partes do texto de entrada serão enviados ao motor de regras que fará a classificação das
expressões como temporais ou não-temporais. O sistema foi avaliado utilizando o con-
junto de dados, métricas e diretrizes da Pista Tempo do Segundo HAREM[17], obtendo
resultados que o deixam em igualdade com os melhores trabalhos de RET para a lingua
inglesa, que é reconhecidamente a língua onde estão concentrados os maiores esforços e
melhores resultados de pesquisa em PLN de forma geral. Apesar dos bons resultados o
CoppeTER não está disponível à comunidade e não há no trabalho os anexos que seriam
necessários para a reprodução do mesmo(como a base de regras utilizada, o conjunto de
expressões regulares, o dicionário de gatilhos ou o calendário de datas especiais).
4. Módulo TECLA
A ferramenta TECLA(Temporal Expression CLAssifier) é um módulo de código aberto
para classificação de ETs em Português desenvolvido para a linguagem de programação
Python[12], e é a principal contribuição deste trabalho. A seguir estão relatadas as etapas
de seu desenvolvimento e sua forma de utilização.
4.1. Desenvolvimento
O desenvolvimento do módulo TECLA ocorreu por meio das etapas descritas a seguir.
495
4.1.1. Estudo dos Corpus
Iniciamos com o estudo dos corpus CSTNews[14] e TimeBankPT[15] afim de identificar

os padrões seguidos pelas mais de cinco mil ETs anotadas nestes. Esse estudo revelou que
a grande maioria das ETs presentes nos textos observados seguia padrões simples que –
assim como Menezes e Pardo[16] já haviam observado – podem ser identificados fazendo
uso unicamente de expressões regulares.
Pudemos notar, por exemplo, a vasta ocorrência de um ou mais dígitos represen-
tando o dia seguidos da preposição “de” e terminando em um mês do ano. Esse e outros
formatos comuns de ETs foram então utilizados na fase de implementação do protótipo.
4.1.2. Arquitetura do Projeto
O TECLA tem sua arquitetura mostrada na Figura 2 recebe como entrada principal o
texto no qual se deseja verificar a ocorrência das ETs. Este sofre então a tentativa de
"matching"(ou casamento) com os padrões observados durante a fase de estudo dos cor-
pus. Essa fase é seguida por uma busca no texto por palavras que estejam no banco de
expressões temporais.
Figura 2. Arquitetura do módulo TECLA
O banco de ETs padrão do TECLA conta com 75 ETs que não foram incluídas
nos padrões principais por não serem tão significativas, ou seja, não se encontrarem co-
mumente nos corpus analisados. Existe ainda a opção de substituir-se o banco de ETs
padrão por um da escolha do utilizador do módulo.
4.2. Utilização do TECLA

A instalação do TECLA é feita através do Pip, o gerenciador de pacotes padrão do Python,
utilizando comando pip install tecla. Após isso o módulo está instalado e pronto para uso.
Para utilizar o TECLA é necessário apenas a importação deste como pode ser visto
na Figura 3 que demonstra a utilização do módulo.
496
Figura 3. Exemplo básico de utilização do TECLA em um programa em Python
Como foi dito anteriormente há também a opção de fazer a substituição do banco

de ETs padrão. Um exemplo disso é mostrado na Figura 4. Cabe ressaltar aqui que o
banco padrão já contém as estações do ano assim como uma grande variedade de outros
termos e palavras que denotam ETs, o exemplo mostrado na Figura 4 é apenas ilustrativo.
Figura 4. Exemplo de substituição do banco de ETs padrão
5. Avaliação
A avaliação do TECLA foi feita utilizando o corpus de comentários extraídos do site
Booking.com[11] e anotado por um especialista da área de PLN em conjunto com um
especialista da área de linguística. Os resultados do TECLA foram então comparados
com os resultados de Menezes e Pardo[16] e Carneiro[18].
Nos 200 comentários que compunham o corpus utilizado foram encontradas 142
setenças que continham ETs, essas foram unidas a outras 142 sentenças que não conti-
nham ETs e submetidas unitariamente ao TECLA. Para a avaliação foram utilizadas as
medidas de precisão, cobertura e medida-F, que como demonstra Powers[19] são as mais
indicadas para avaliação de sistemas de predição.
O TECLA obteve precisão de 83%, cobertura de 88% e medida-F de 85%. Os
cálculos foram feitos com base na matriz de confusão mostrada Figura 5 que confronta
as ETs anotadas manualmente no corpus com as ETs encontradas pelo TECLA.
Em comparação com o trabalho de Menezes e Pardo[16] e Carneiro[18] – que uti-
liza o mesmo princípio de procura de padrões por meio de expressões regulares para iden-
tificar ETs – podemos notar que o TECLA tem índices de precisão, cobertura e medida-F
superiores, como demonstrado na tabela da Figura 6 e no gráfico da Figura 7. Entretanto,
tem valores de precisão e cobertura inferiores aos apresentados por Carneiro[18].
Vale salientar que mesmo estando atrás dos resultados conseguidos por
Carneiro[18] o TECLA tem uma abordagem e arquitetura mais simples que este, e tam-
bém está totalmente disponível à comunidade por meio do código-fonte disponibilizado
no Github[20], um repositório de códigos livre e gratuito.
497
Figura 5. Matriz de confusão da avaliação do TECLA
Figura 6. Comparação dos índices de precisão, cobertura e medida-F em por-

centagem
Figura 7. Gráfico dos valores de precisão, cobertura e medida-F dos trabalhos

comparados
6. Conclusão e Trabalhos Futuros

Apesar dos resultados considerados satisfatórios do TECLA há ainda muito a ser feito
para que este alcance a eficiência pretendida. Dentre as possíveis modificações a serem
feitas temos: a verificação da classe gramatical das palavras para evitar a classificação de
falsas ETs; realização de um estudo mais aprofundado dos casos de erro para a correção
498
destes e aumento da precisão da ferramenta; implementação de outras funcionalidades no

módulo como, por exemplo, dar ao usuário a possibilidade de especificar um conjunto
de padrões de ETs que não devem ser procurados, para que o usuário possa fazer uso do
TECLA da forma que desejar e que for benéfica a seu trabalho e etc.
Também existem trabalhos a serem feitos a partir do TECLA, como a criação de
um módulo de Normalização de ETs que possa ser utilizado em conjunto com o TECLA
para a criação de uma ferramenta completa de Resolução de Expressões Temporais para
o Português.
7. Referências
[1] SANOU, B. "ICT Facts & Figures The world in 2016. ICT Data and Statistics Division
Telecommunication Development". Bureau International Telecommunication Union,
2016.
[2] Cisco, I. "Cisco visual networking index: Forecast and methodology, 2016–2021".
CISCO White paper, 2016.
[3] BITTAR, A. "Annotation of Events and Temporal Expressions in French Texts: SA-OT
accounts for pronoun resolution in child language". LOT Occasional Series, 2009.
[4] JACKSON, P.; MOULINIER, I. "Natural Language Processing for Online Applications:
Text Retrieval, Extraction and Categorization". John Benjamins Publishing Com-
pany, 2002.
[5] HIGH, R. "The era of cognitive systems: An inside look at ibm watson and how it works".
IBM Corporation, Redbooks, 2012.
[6] LAZER, DAVID, et al. "The parable of Google Flu: traps in big data analysis". Science,
2014.
[7] JURAFSKY, D.; MARTIN J. "Speech and Language Processing: An Introduction to Na-
tural Language Processing Computational Linguistcs, and Speec Recognition". Pe-
arson Education Inc., 2008.
[8] AHN, D.; RANTWIJK, J.; RIJKE, M. "A Cascaded Machine Learning Approach to In-
terpreting Temporal Expressions". Proceedings of Human Language Technologies:
The Annual Conference of the North American Chapter of the Association for Com-
putational Linguistics, 2007.
[9] SARDINHA, T. "Lingüística de corpus". Editora Manole Ltda, 2004.
[10] McENERY, T.; RICHARD, X.; TONO, Y. "Corpus-based language studies: An advanced
resource book". Taylor & Francis, 2006.
[11] Booking Inc. Disponível em: <https://www.booking.com>, acesso em Março de 2017.
[12] MARTELLI, A.; RAVENSCROFT, A.; ASCHER, D. "Python cookbook". O’Reilly Me-
dia, Inc., 2005.
[13] KOUZIS-LOUKAS, D. "Learning Scrapy". Packt Publishing Ltd, 2016.
[14] SOUZA, J., FELIPPO A. "Corpus CSTNews e sua Complementaridade Temporal". Inst.
de Ciências Matemáticas e de Computação (ICMC) - Universidade de São Paulo
(USP).
499
[15] COSTA, F.; BRANCO, A. "TimeBankPT: A TimeML Annotated Corpus of Portuguese".

LREC, 2012.
[16] MENEZES, L., PARDO, T. "Detecção de Expressões Temporais para Sumarização Mul-
tidocumento". Instituto de Ciências Matemáticas e de Computação, Universidade de
São Paulo, 2011.
[17] BAPTISTA, J., HAGÈGE, c., MAMEDE N. "Identificação, classificação e normalização
de expressões temporais do português: A experiência do segundo HAREM e o fu-
turo. Desafios na avaliação conjunta do reconhecimento de entidades mencionadas:
o segundo HAREM". Linguateca, 2008.
[18] CARNEIRO, H. "RECONHECIMENTO E NORMALIZAÇÃO DE EXPRESSÕES TEM-
PORAIS EM PORTUGUÊS". Tese de Doutorado. Universidade Federal do Rio de
Janeiro, 2011.
[19] POWERS, D. "Evaluation: from precision, recall and F-measure to ROC, informedness,
markedness and correlation". 2011.
[20] GitHub, Inc. Disponível em <https://github.com/ >. Acesso em Junho de 2017.
500
Sistema Móvel para Reconhecimento Automático de Gestos

Estáticos da Linguagem Brasileira de Sinais
Francisco Mendes da C. Neto1 , Rodrigo de M. S. Veras1 , Pedro H. P. Albuquerque2
1
[email protected] ,[email protected] 1
, [email protected]
Abstract. The Brazilian Sign Language (LIBRAS) is the official language in the
communication of the deaf in Brazil. Although it is the primary means of com-
munication for the hearing impaired, LIBRAS is still not very widespread in the
rest of society. In this way, sign language recognition is a research area of high
relevance, since it aims to include deaf people in the rest of community. Based
on this, we propose in this article a mobile system, compatible with any Android
device with a camera, for the recognition of static gestures, that is, gestures that
do not need the movement of hands, in LIBRAS. The proposed system uses a
skin detection algorithm to segment the region of interest, then seeks to identify
the hand of the individual and extract some characteristics regarding their posi-
tion and finally recognize the gesture signaled through the information extracted
using a classifier Support Vector Machine. The developed system obtained a rate
of 86.5% accuracy in recognition of the evaluated gestures
Resumo. A Lı́ngua Brasileira de Sinais (LIBRAS) é a lı́ngua oficial na

comunicação dos surdos no Brasil. Embora seja o principal meio de
comunicação dos deficientes auditivos, a LIBRAS ainda é pouco difundida no
resto da sociedade. Dessa forma, o reconhecimento de lı́ngua de sinais é uma
área de pesquisa de grande relevância, pois tem o objetivo de incluir o surdo no
resto da sociedade. Baseado nisso, propomos nesse artigo um sistema móvel,
compatı́vel com qualquer dispositivo Android com câmera, para o reconheci-
mento de gestos estáticos, ou seja, gestos que não necessitem do movimento
das mãos, em LIBRAS. O sistema proposto utiliza um algoritmo de detecção de
pele a fim de segmentar a região de interesse, em seguida procura-se identificar
a mão do individuo e extrair algumas caracterı́sticas referente ao seu posici-
onamento e finalmente reconhecer o gesto sinalizado através das informações
extraı́das usando um classificador Máquina de Vetor de Suporte. O sistema de-
senvolvido obteve uma taxa de 86,5% de acerto no reconhecimento dos gestos
avaliados.
1. Introdução
Segundo o censo do Instituto Brasileiro de Geografia e Estatı́stica (IBGE) de 2010 ha-
via no Brasil uma população de mais de 190 milhões de pessoas, dessas 45,6 milhões
(23,9%) apresentaram algum tipo de deficiência, sendo 9,7 milhões (5,1%) portadoras
de deficiência auditiva. Algumas das dificuldades encontradas pelos deficientes podem
ser contornadas por meio do uso de Tecnologias de Informação e Comunicação (TICs).
501
A apropriação de recursos tecnológicos modifica significativamente o estilo de vida, as

interações e a conduta social ao inovar hábitos e atitudes em relação à educação, ao lazer
e ao trabalho, à vida familiar e comunitária.
A dificuldade de se comunicar com a sociedade predominantemente ouvinte é um
grande obstáculo no dia a dia para a comunidade surda. Isso ocorre principalmente pela
falta de conhecimento dos ouvintes sobre a linguagem de sinais. Com isso, tarefas co-
muns e simples para a maioria da população, como fazer compras, realizar uma operação
bancária e ir a uma consulta médica, podem ser um grande desafio para os deficientes
auditivos, uma vez que a Lı́ngua Brasileira de Sinais (LIBRAS) é a única lı́ngua utilizada
por eles para interagir com a sociedade.
Com base nas dificuldades apresentadas acima, propõe-se um sistema de Reco-
nhecimento Automático de gestos estáticos em LIBRAS disponı́vel para dispositivos que
possuam câmera e o sistema operacional Android. Escolha é justificada por este ser o
sistema mais utilizado no Brasil de acordo com os números divulgados em 2016 pela
consultoria IDC, sendo que cerca de 93% dos aparelhos vendidos no Brasil possuem o
Android.
O objetivo do sistema proposto é identificar um sinal em LIBRAS a partir da
entrada fornecida pela câmera do dispositivo.
O restante do texto esta dividido da seguinte forma: trabalhos relacionados são
apresentados na Seção II. A metodologia proposta é apresentada na Seção III. Apresen-
tamos os resultados e experimentos na Seção IV. Finalmente, temos as conclusões e os
trabalhos futuros na Seção V.
Foi realizado uma busca por softwares que possuam o mesmo ou um objetivo semelhante
ao sistema proposto. Na busca, foram encontrados sistemas, não necessariamente mo-
bile, que fazem o reconhecimento de gestos de LIBRAS e o traduza para português. No
entanto, a pesquisa por sistemas móveis retornou apenas alguns aplicativos que fazem a
conversão do português para a LIBRAS, ou seja, o inverso do objetivo mostrado nesse
trabalho.
Tal busca também se estendeu para aplicações Desktop, agora retornando alguns
programas listados na Tabela 1
Tabela 1. Resultado da pesquisa de anterioridade no INPI.

Pedidos Depósitos Tı́tulo
BR 51 2015 000885 4 04/08/2015 TRADUTOR DE LIBRAS
BR 51 2014 000097 4 04/02/2014 LOQUI-LIBRAS
10695-4 19/05/2010 SENSOR LIBRAS-SOFTWARE TRADUTOR DE LINGUA BRASILEIRA DE SINAIS (LIBRAS)
Entre os programas listados na Tabela 1, apenas o terceiro realiza a tradução de

LIBRAS para o português. Os demais também possuem o objetivo inverso. O programa
Sensor Libras, no entanto, não pode ser comparado ao sistema proposto, visto que ele
utiliza sensores que devem ser colocados nos pulsos do usuário, diminuindo consideravel-
mente a sua usabilidade, pois além de necessitar tal acessório, trata-se de uma aplicação
que funciona apenas em desktop.
502
Além disso, foi feita uma busca cientifica para se ter conhecimento dos princi-
pais métodos proposto existente. Com isso, foi analisado o retorno da pesquisa, onde
foram classificados como sendo de maior relevância para o desenvolvimento do sistema
os seguintes trabalhos: [SIOLA 2010], [Koroishi 2016],[Brandt 2015], [Teodoro 2015] e
[Souza et al. 2007]
Em [SIOLA 2010] o método possui diversas restrições entre elas: o processo deve
ser realizado em um ambiente controlado, com um fundo de cor branca ou preta, somente
o interprete da linguagem deve ser visı́vel a câmera, o interprete deve utilizar roupas
brancas ou pretas de manga comprida, uma luva de cor azul na mão direita deve ser usada
para sinalizar os gestos e outra de cor laranja na mão esquerda, no inicio do vı́deo o
interprete deve estar com suas mãos posicionadas para cima e ao final do vı́deo suas mãos
deveram estar para baixo.
Ja em [Koroishi 2016] e [Brandt 2015], os autores estudaram a viabilidade do uso
de sensores 3d, como o Kinect, para o reconhecimento da LIBRAS baseando-se nessa
classificação para uma abordagem probabilı́stica e com uso de redes neurais.
No trabalho de [Souza et al. 2007] o reconhecimento de um sinal em LIBRAS é
feito através de uma sequência de várias imagens que são consideradas marcantes para
o gesto representado, o seu trabalho dá ênfase no uso de Modelos de Markov Oculto
(HHMs) para a classificação. Para testar o desempenho do método proposto foi construı́do
um banco com amostras de imagem correspondente a 47 sinais diferentes, sendo que todas
as imagens foram capturadas com o fundo estático e uniforme.
O último trabalho citado foi o de [Teodoro 2015] em seu projeto a autora desen-
volveu um sistema de reconhecimento de algumas palavras em LIBRAS para desktop,
que processa vı́deos gravados e armazenados em um banco construı́do pelo próprio au-
tor. Porém, apresenta uma usabilidade melhor do que os trabalhos anteriores, pois seu
sistema não necessita do uso de luvas, nem outro tipo de acessório para o funcionamento.
Nesse trabalho o sistema analisa a sequência de imagens gravadas que correspondem ao
sinal, realiza uma etapa de pré-processamento para melhorar a imagem, em seguida seg-
menta a região de interesse através do método Kovac, faz o rastreamento do movimento
da mão para identificar sinais dinâmicos, em seguida extrai as caracterı́sticas utilizando o
descritor Random Forest e reconhece o sinal.
Além dos trabalhos citados, o sistema desenvolvido por [Qin 2015] foi de grande
relevância para esse projeto, nele foi desenvolvido um aplicativo que é capaz de abrir
outros aplicativos instalados no celular através do reconhecimento dos dedos das mãos,
porém seu sistema necessita de uma etapa de pré-treinamento sempre que é iniciado,
precisando ser informado onde está o fundo e a mão do usuário.
3. Metodologia
Nesse trabalho, utilizamos o sistema operacional Android e a linguagem de programação
Java. O sistema proposto é compatı́vel com qualquer dispositivo Android, tendo apenas a
câmera como pré-requisito funcional. O funcionamento do sistema ocorre em três etapas:
detecção da mão, reconhecimento da mão e o reconhecimento do sinal. O Funcionamento
do sistema está resumido no fluxograma apresentado na Figura 1 e será detalhado nas
próximas seções.
503
Figura 1. Fluxograma do sistema proposto.
3.1. Detecção da mão

Para a primeira etapa utilizamos um algoritmo de detecção de pele desenvolvido na lin-
guagem Java, próprio para ser utilizado em Android. Esse algoritmo utiliza a câmera do
dispositivo que o está executando e processa toda a imagem capturada, em seguida clas-
sifica cada pixel como sendo pele ou não pele, os pixels que forem classificados como
não pele são preenchidos de preto, já os classificados como pele são preenchidos com
um determinado tom de cinza, que varia de acordo com a exposição à luz, os pixels mais
expostos tendem a ter um tom de cinza mais claro, já os que estiverem menos exposição
terão um tom de cinza mais escuro. Com isso, obtém-se como saı́da do algoritmo uma
matriz contendo somente a região da pele, como mostra a Figura 2.
Figura 2. Matriz resultante da detecção de pele.
Após obter a matriz resultante com a região da pele detectada, o sistema aplica
algumas técnicas na matriz a fim de melhorar a imagem com a região da mão. Para isso,
inicialmente é aplicado o filtro da mediana com o objetivo de equilibrar a imagem que
504
possui pixels mais claros e mais escuros. Em seguida, a imagem passa por um processo
de limiarização threshold disponı́vel na biblioteca Opencv, isso faz com que ela seja seg-
mentada em todos os pixels que tiverem o valor inferior a taxa de threshold, no sistema
proposto esta taxa foi definida com o valor 20, tal escolha foi feita devido a esse valor ter
realizado a limiarização com mais eficiência, sem grandes perdas na imagem. Com a área
de interesse (pele) segmentada, usamos a função da biblioteca OpenCv findContours, que
nos retorna os contornos encontrados a partir da imagem passada.
3.2. Reconhecimento da mão
Como na etapa anterior a matriz foi restrita a conter apenas a região da mão, a função
irá retornar somente os contornos correspondente aos da mão. A partir daı́ é criado uma
caixa, chamada boundingbox na qual é limitada somente à região da mão, é a partir das
informações representadas dentro do boundingbox que um sinal é reconhecido, como
mostra a Figura 3.
Figura 3. Representação do conjunto de informações.
As informações referentes a um sinal estão representadas da seguinte forma: o

boundingbox está representado na Figura 3 pela caixa verde, as linhas em azul representa
o menor polı́gono criado contendo todos pixels correspondente a mão, chamado de convex
hull. As linhas em vermelho delimitam o contorno das mãos, já os pontos de cor azul são
as áreas de defect points usados para dividir a área de contorno do final de um dedo e o
inicio do outro. O circulo em amarelo representa a região da palma da mão, e finalmente
as linhas em verde escuro são os vetores que representam os dedos e a ordem é indicada
pelos números.
Os recursos utilizados para representar a configuração de mão usado em um sinal
são basicamente os vetores de dedos. Esses vetores são calculados a partir do centro da
palma da mão e a ponta dos dedos. O centro da palma da mão é calculado com o contorno
e os pontos fornecidos pelo convexhull juntamente com o boundingbox. Já a ponta dos
dedos é obtida utilizando somente as informações dos defect points. Com isso, os vetores
de dedos correspondem ao valor da distância entre o centro da palma da mão até cada
ponta dos dedos dividido pelo raio da palma da mão. Caso seja sinalizado um gesto que
não exponha nenhum dedo, as caracterı́sticas usadas para representar o sinal é o tamanho
do formato que o contorno da mão irá assumir.
505
3.3. Reconhecimento do Gesto

A última etapa consiste no reconhecimento do gesto, nessa etapa utiliza-se o algoritmo
de aprendizado de máquina SVM multiclasses para treinar o sistema com as imagens ca-
dastradas previamente que contêm as caracterı́sticas na qual os gestos sinalizados devem
conter para serem identificados corretamente.
Figura 4. Reconhecimento das letras do alfabeto.
4. Resultados e Experimentos
Foram realizados testes para validar a eficiência do sistema proposto. Esses testes foram
realizados em um smartphone Xiaomi Redmi 2 que utiliza o sistema operacional Android
na versão 4.4 com as seguintes configurações:
• Modelo: Redmi 2;
• Marca: Xiaomi;
• Versão do Android: 4.4.4 KTU84P;
• Chipset: Qualcomm MSM8916 Snapdragon 410;
• CPU: Quad-core Max 1,2 GHz;
• Memória RAM: 1GB;
• GPU: Qualcomm Adreno 306;
• Câmera: 8 Mp.
Para testar a aplicação foram convidadas 5 pessoas que se disponibilizaram para
sinalizar os gestos selecionados para o teste. Os voluntários escolhidos possuem diferen-
tes tonalidades de cor de pele para evidenciar o desempenho do algoritmo desenvolvido
com o maior leque de caracterı́sticas possı́veis, além disso, nenhum dos participantes pos-
sui conhecimentos avançados em LIBRAS.
Os gestos escolhidos para serem testados foram as 10 primeiras letras do al-
fabeto que possuam gesto estático, ou seja, que não seja necessário realizar ne-
nhum movimento com a mão para o sinal ser executado. O sistema foi treinado
com 10 amostras de gestos de cada letra, com isso as letras a serem analisadas são:
“A”,“B”,“C”,“D”,“E”,“F”,“G”,“I”,“L” e “M”.
Os testes foram executados em ambientes com o fundo heterogêneo e não con-
trolado. Foi criado um pequeno algoritmo para calcular o resultado dos testes, onde é
contabilizado a quantidade de vezes que o sistema classificou a letra sinalizada correta-
mente dividido pelo total, ou seja, quantidade de vezes que o sistema classificou o sinal de
forma correta ou incorreta durante os 50 primeiros frames da câmera, o que corresponde
a mais ou menos de 7 a 10 segundos para cada letra. Os resultados dos testes variam de 0
506
Tabela 2. Resultado dos testes de cada letra analisada.

Letra Voluntário 1 Voluntário 2 Voluntário 3 Voluntário 4 Voluntário 5
A 1,0 1,0 1,0 1,0 1,0
B 0,91 1,0 0,95 1,0 1,0
C 1,0 1,0 1,0 0,55 1,0
D 1,0 1,0 0,93 1,0 1,0
E 0,79 0,34 1,0 0,97 0,28
F 1,0 0,61 0,16 0,08 1,0
G 1,0 0,71 0,97 0,43 0,63
I 1,0 1,0 1,0 1,0 1,0
L 1,0 1.0 1.0 0.88 1.0
M 0,69 1,0 0,97 1,0 0,56
(caso o sistema em nenhum momento tenha reconhecido a letra corretamente) a 1 (caso o

sistema tenha classificado corretamente durante todo o perı́odo de análise), os resultados
podem ser conferidos na Tabela 2.
Os resultados mostram que o sistema apresentou um desempenho satisfatório,
tendo em vista que os voluntários não possuı́am conhecimento em LIBRAS, consequen-
temente não apresentando habilidades para sinalizar os gestos com perfeição, isso fica
evidente ao perceber que os gestos considerados mais fáceis obtiveram maiores taxas de
acerto, enquanto os mais difı́ceis como a letra “F” obteve uma taxa menor.
Além disso, o conjunto de gestos usado nos testes contém gestos que se asseme-
lham, como a das das letras “A” e “E” que não apresentam os dedos expostos o que seria
determinante para diferenciá-los com mais precisão. A Figura 5 mostra a média das
porcentagens exibidas anteriormente para cada letra.
Figura 5. Desempenho do sistema para cada letra.
Baseado nos resultados analisados na Figura 5 ao fazer uma média dos valores de
cada letra podemos afirmar que o sistema faz o reconhecimento de gestos com uma taxa
507
de 86,5 % de acerto. Esse número foi significamente afetado pelas baixas taxas de acerto
das letras “E”, “F” e “G” já citadas anteriormente.

O Trabalho proposto mostra-se uma ferramenta bastante relevante para facilitar a
comunicação e inclusão entre surdos que utilizam a Lı́ngua Brasileira de Sinais com a
população ouvinte que não conhece LIBRAS. Um dos principais objetivos desse trabalho
é construir uma aplicação com uma boa usabilidade que possa ser utilizada facilmente no
dia a dia. Apesar do sistema ter sido testado reconhecendo letras, pode ser usado também
para reconhecer qualquer gesto estático. Os testes mostraram uma taxa de 86,5 % de
eficiência, esse valor pode ser melhorado aumentando a quantidade de amostras para o
treinamento dos gestos, pois assim o sistema será capaz de reconhecer os sinais quando
executados com pequenas variações.
Como trabalhos futuros, pretende-se expandir o sistema para o reconhecimento de
palavras que possuem sinais dinâmicos, ou seja, gestos sinalizados com o movimento da
mão, isso pode ser feito usando o rastreamento da mão para mapear o percusso que ela
irá percorrer no momento da sinalização.
Referências
Brandt, A. H. (2015). Lirann: sistema de reconhecimento de libras baseado em redes
neurais artificiais com kinect. Trabalho de Conclusão de Curso, Universidade de Santa
Cruz do Sul, Santa Cruz do Sul, pages 30–38.
Koroishi, G. O. (2016). Reconhecimento de sinais da libras por visão computacional.
Mecatrone, 1(1):2–7.
Qin, Y. (2015). Color-based hand gesture recognition on android.
SIOLA, F. (2010). Desenvolvimento de um software para reconhecimento de sinais libras
através de vı́deo. Trabalho de Conclusão de Curso, Universidade Federal do ABC,
Santo André, pages 32–41.
Souza, K. P., Dias, J. B., and Pistori, H. (2007). Reconhecimento automático de gestos
da lıngua brasileira de sinais utilizando visao computacional. In III Workshop de Visao
Computacional, pages 3–5.
Teodoro, B. T. (2015). Sistema de reconhecimento automático de Lı́ngua Brasileira de
Sinais. PhD thesis, Universidade de São Paulo.
508
A Implementação de Sistemas Distribuídos na Atualidade:

Descobrindo Novas Maneiras de Desenvolver Computação
Distribuída.
Naylson Ferreira da S. Andrade1 e Lauriene Rodrigues Santana1,
1 Graduandos do curso de Tecnologia e Análise de Desenvolvimento de Sistemas -
Instituto Federal do Piauí (IFPI) CEP 64.808-475 – Floriano –PI – Brasil
{naylsonfsa, larosafree}@gmail.com
Abstract: This scientific article offers a wealth of information on tools for
developing distributed systems. Information acquired through bibliographic
research. It also demonstrates the development of software and the final
analysis of the efficiency of the tools used to develop it. The general objective is
to present to academic society the new technologies available for the
development of distributed computing.
Resumo: Este artigo científico oferece uma ampla quantidade de informações
sobre ferramentas para desenvolvimento de sistemas distribuídos. Informações
essas adquiridas através de pesquisa bibliográfica. Demonstra ainda o
desenvolvimento de um software e a análise final da eficiência das ferramentas
utilizadas para desenvolvê-lo. O objetivo geral é apresentar a sociedade
acadêmica as novas tecnologias disponíveis para o desenvolvimento da
computação distribuída.
1. INTRODUÇÃO
Desde a invenção do ENIAC, o primeiro computador digital eletrônico de grande escala,
criado em fevereiro de 1946 pelos cientistas norte-americanos John Eckert e John
Mauchly, da Electronic Control Company (TERRA, 2017), muitas inovações
aconteceram na área da tecnologia da informação (TI).
O modelo de desenvolvimento denominado Computação Distribuída vem
ganhando cada vez mais espaço, e têm contribuído para desenvolvimento de novas
tecnologias. Segundo Coulouris et. al (2007) um Sistema Distribuído(SD) é aquele no
qual os componentes localizados em computadores interligados em rede se comunicam e
coordenam suas ações apenas passando mensagens.
Este artigo procura demonstrar tecnologias para o desenvolvimento de sistemas
distribuídos e o desenvolvimento de um software com algumas destas tecnologias. O
desenvolvimento aconteceu seguindo as etapas de: Levantamento de dados, elaboração
do projeto, desenvolvimento e análise final. O sistema desenvolvido deve apresentou
algumas das principais características de um SD que são: Heterogeneidade, Segurança,
Escalabilidade, Concorrência e Transparência.
Possivelmente a presença da computação na rotina da população despertara o
interesse das pessoas pela área do desenvolvimento de software. Em 2007 uma pesquisa
realizada por técnicos da Universidade de Maastricht, da Holanda, mostrou que o Brasil
tinha o maior número de desenvolvedores de software de código aberto, dentre os países
que participaram da pesquisa naquela época (INTERVOZES, 2015).
509
Portanto a tendência é que o número de desenvolvedores aumente ainda mais. De

acordo com os dados publicados pelo artigo da ABES Software, ilustrado na Figura 01,
o mercado de tecnologia da informação vem ganhando cada vez mais espaço no cenário
de negócios brasileiro (ABES, 2017).
Figura SEQ Figura \* ARABIC 1- Gráfico da evolução dos indicadores de
mercado
Figura 1-de TI no Brasil
Cenário de mercado de tecnologia no Brasil de 2004 a 2015
Fonte: Página da ABES Software

Tendo em vista o crescimento evidente do número de pessoas ligadas à área de TI e
considerando que uma das tendências do mercado de software na atualidade é a
computação distribuída, pode-se prever que existirá uma demanda proporcionalmente
crescente a procura de informações sobre as novas tecnologias para o seu
desenvolvimento, e que o acesso a uma análise da eficiência das mesmas na prática da
implementação possui considerável relevância para os desenvolvedores que buscam
informações sobre elas e ainda para a sociedade acadêmica ligada a área.
Portanto a produção de um trabalho científico que forneça informações sobre as
inovações na área do desenvolvimento de sistemas distribuídos justifica-se pelo aumento
crescente do público ligado a essa área da programação e pela necessidade de divulgar as
novas tendências relacionadas a ela.
2. REVISÃO TEÓRICA
É possível entender o surgimento e propagação dos sistemas distribuídos ao observar a
evolução da computação, pois esse desenvolvimento envolve necessariamente, não
proporcionalmente, hardware e software por estarem ligados, ou seja, à medida que
novos hardware surgem, a implementação de novo software faz-se necessário.
Esse progresso acelerou em meados da década de 1980 com o desenvolvimento
dos microprocessadores de grande capacidade e a invenção de redes de computadores de
alta velocidade (TANENBAUM; STEEN, 2007). Fato que possibilitou a implementação
510
de novos modelos de sistemas, como os distribuídos que têm as redes de computadores

como a sua principal ferramenta.
A linguagem de programação Python é um exemplo de uma tecnologia que remete
a outra, nesse caso a uma biblioteca padrão. Ela é uma linguagem dinâmica com
poderosas bibliotecas, como o Django, um framework que abstrai grande parte da
complicação do desenvolvimento web (SANTANA; GALESI, 2010). Fato que torna a
implementação mais ágil. Ele é um framework Python Web de alto nível que incentiva o
desenvolvimento rápido e o design limpo e pragmático. (FOUNDATION, 2017). É
possível que essas características tenham contribuído para a sua crescente aceitação por
parte dos desenvolvedores de software. A Figura 02 demonstra o gráfico publicado no
site da IEEE (Institute of Electrical and Electronics Engineers), que exibe a Python no
topo do ranque das linguagens mais utilizadas em 2017 (CASS, 2017).
Figura 2- Ilustração do ranque das linguagens de programação mais utilizadas no ano de

2017
Fonte: Página da IEEE Spectrum

Outra característica da Linguagem Python é a sua desenvoltura na computação
distribuída, que por sua vez adquiriu um outro forte aliado no que diz respeito a
comunicação entre aplicações, o middleware. O conceito de middleware diverge, visto
que muitos autores o classificam de maneiras diferentes, mas no que diz respeito à sua
funcionalidade, a opinião é quase unânime entre os autores pesquisados. Segundo o
exposto no site da Imaster, o middleware é um software capaz de interpretar os aplicativos
e traduzi-los na linguagem do sistema operacional em que ele reside. Tem-se o CORBA,
DCOM e RMI como exemplos de middlewares, onde o processamento passou a ser
repassado para vários servidores (RECKZIEGEL, 2006). Entre as diversas definições de
middleware, a Microsoft o define como:
O software que se encontra entre o sistema operacional e os aplicativos nele
executados. Funcionando como uma camada oculta de tradução, permitindo a
comunicação e o gerenciamento de dados para aplicativos distribuídos.
Exemplos comuns de middleware incluem middleware de banco de dados,
middleware de servidor de aplicativos, middleware orientado a mensagens,
middleware de web e monitores de processamento de transações.
(MICROSOFT, 2017)
511
O HTTP (Hypertext Transfer Protocol) é utilizado na implementação de diversos

modelos de web services, esta é uma solução utilizada na integração de sistemas e na
comunicação entre aplicações diferentes. Com isso ela torna possível que novas
aplicações possam interagir com outras, mesmo que tenham sido desenvolvidas em
plataformas diferentes, tornando-as compatíveis.
Outro protocolo utilizado na criação de web services é o SOAP(Simple Object
Access Protocol), ele é um protocolo para intercâmbio de mensagens entre programas de
computador(PORTAL,2012). Essa sua característica é relevante dentro do
desenvolvimento de sistemas distribuídos. Tanto o SOAP quanto o REST
(Representational State Transfer) ainda são utilizados no desenvolvimento de servidores
web, no entanto o REST, é cada vez mais usado como alternativa ao “já antigo” SOAP
onde que a principal crítica a esse é a burocracia, algo que REST possui em uma escala
muito menor (MATERA, 2017). Entre as definições disponíveis para o REST, ele pode
ser definido como:
Um estilo arquitetônico para aplicações de hipermídia em rede, é usado
principalmente para construir serviços da Web que são leves, mantidos e
escaláveis. Um serviço baseado em REST é chamado de serviço RESTful. O
REST não depende de nenhum protocolo, mas quase todos os serviços
RESTful usam HTTP como seu protocolo subjacente (VAQQAS, 2014) .
Embora novas linguagens surjam, existem algumas que permanecem sendo muito
utilizadas como a HTML. Esta é a sigla em inglês para Hyper Text Markup Language,
que, em português, significa linguagem para marcação de hipertexto (SILVA, 2011).
O código HTML está presente nas páginas da web há mais de dez anos e tem uma
larga aceitação dos usuários por todo o mundo. Desde então vem evoluindo até chegar a
versão 5. A semelhança entre o HTML5 e seus antecessores, HTML 4.01 e XHTML 1.0,
é significante. Quem está familiarizado com as versões anteriores não sentirá nenhuma
dificuldade na transição, e para quem ainda vai aprender a linguagem, os novos elementos
deixarão o processo mais simples (LOPES, 2017). Ela é utilizada juntamente com outras
linguagens, cumprindo seu papel na estruturação das páginas web, e conta com o auxílio
da CSS3 no tratamento de imagens e melhoramento do layout da página.
O CSS é o acrônimo de Cascading Style Sheets que em português seria algo como
“folhas de estilo em cascata”. O CSS traz toda a informação do layout, isto é, cores,
posicionamento, fontes, tamanhos e imagens de fundo, enquanto o HTML deve fornecer
uma “arquitetura” para o conteúdo (SYSTEMS, 2012). Ambas contribuem para o
melhoramento da estrutura e aparência as páginas. Assim como outras linguagens, a CSS
também vem aperfeiçoando-se e chegou a versão 3. Ela possui o Semantic Ui como
framework o que torna o processo de desenvolvimento mais ágil (SOURCE, 2017).
A JavaScript é utilizada para controlar o HTML e o CSS e para manipular
comportamentos na página. É uma linguagem criada e mantida pela ECMA (Ecma
International), ela é uma associação industrial fundada em 1961, dedicada à padronização
de sistemas de informação e comunicação (W3C, 2017). Outra vantagem dessa
linguagem são as opções de frameworks como Jquery aceito pelos browsers Chrome,
Edge, Firefox, Safari, Android e IOS (JQUERY, 2017).
A HTML conta ainda com o framework Angular, que possui diversas especificidades,
entre elas o data binding, um mecanismo para coordenar o que os usuários vêem, com
valores de dados da aplicação (ANGULAR, 2017). Isso permite que o desenvolvedor
512
apenas declare as ligações entre fontes vinculativas e elementos HTML de destino e a

partir de então o Angular executa o restante do processo.
Existe ainda uma outra ferramenta que complementa o desenvolvimento de um SD, o
Bucardo. Ele realiza a replicação do banco de dados do sistema, contribuindo para a
segurança dos dados. (VALE, 2014):
Bucardo é um sistema de replicação para PostgreSQL que fornece recursos
tanto master-master e master-slave. Ele é assíncrono e baseado em trigger.
Seus principais objetivos são fornecer replicação master-master para
balanceamento de carga e failover, e para fornecer balanceamento de carga e
armazenamento de dados via replicação master-slave. Faz leitura e escrita
escaladas, e é ativado por trigger’s, não sendo necessário alterar o core do
postgresql.
Considerando todos os dados obtidos na pesquisa bibliográfica, construiu-se uma
ampla base teórica que fundamenta e orienta o desenvolvimento do trabalho científico e
do software em questão.
3. METODOLOGIA
Tendo em mãos o resultado da pesquisa que resultou em um grupo de tecnologias para o
desenvolvimento da aplicação, deu-se continuação a prática do projeto elaborado
realizando a implementação do sistema.
O desenvolvimento do sistema teve uma instituição de ensino da rede federal
como estudo de caso. O Campus analisado possui uma estrutura de rede, além de possuir
uma diversidade de hardware que atende às necessidades para a implantação de um
sistema distribuído.
Dentre os setores do Campus o escolhido foi o da Coordenação de Disciplina
(CODIS), por possuir ligação com outros setores e necessitar automatizar as suas
atividades diárias como: o controle de uso das salas de aula e registro de aulas ministradas
e não ministradas. Além disso o sistema possui como funcionalidade a geração de
horários de aulas, administrada pela diretoria de ensino da instituição mencionada.
Para definir com clareza os requisitos do sistema foram elaborados diagramas,
entre eles o diagrama entidade-relacionamento. E como complemento foi produzido uma
simulação da estrutura de hardware e rede a ser utilizada pelo sistema.
O sistema foi definido em quatro partes que estão diretamente relacionadas, mas
que possuem tecnologias diferentes em sua implementação.
A codificação do sistema aconteceu basicamente em duas etapas, a primeira foi a
criação da API(Application Programming Interface), em português, Interface de
Programação de Aplicativos. Afim de garantir a heterogeneidade nesta etapa foram
utilizados alguns frameworks da linguagem Python. Utilizou-se uma adaptação do
controle do Django para receber as requisições do cliente, todas as respostas da API
utilizam a notação do objeto Javascript, JSON(JavaScript Object Notation).Utilizou-se o
Django Rest Framework para converter os dados de texto simples para Json. Tornando
possível que futuras aplicações independente da linguagem que possam ser
implementadas, possam ser integradas ao sistema.
Toda a questão de segurança do sistema deu-se do seguinte modo: A autenticação
dos usuários através de token foi implementada com JSON Web Token(JWT). Foi
513
escolhido o banco de dados Postgresql, que utiliza a Psycopg2, uma biblioteca Python,
para conectar o banco com a API. No que se refere ao gerenciamento de permissões de
quais domínios poderiam consumir esses dados e para permitir o token no cabeçalho das
requisições foi usado o Django-cords-heads.
Com o objetivo de tornar o sistema escalável, ou seja, torná-lo capaz de suportar
maior quantidade de acessos e prepará-lo para integração com futuras aplicações, criou-
se duas bases de dados replicadas (master x master) com o uso da extensão Bucardo, do
postgresql. A primeira instância do banco de dados foi implementada nos sistema
operacionais Windows versão 8.1. A segunda instância do banco no sistema operacional
Linux, Distribuição Linux Mint versão 18.
Na segunda etapa foram construídos dois tipos de clientes, uma página na web e
um aplicativo móvel híbrido, ou seja, um aplicativo executável em diversas plataformas.
A transparência do sistema é evidenciada, por exemplo, quando o site consome dados da
API através de requisições AJAX(Asynchronous Javascript and XML), essas requisições
acontecem de modo que a url não muda, o cliente tem a ideia de que os recursos são
requisitados apenas uma vez. Em seu desenvolvimento, a fim de obedecer os princípios
do Representational State Transfer (REST), o controle de acesso dos dados acontece
através de requisições HTTP, característica que contribui para a segurança dos dados,e
pode acontecer por exemplo, a utilização de uma mesma URL em diferentes requisições
mudando somente o verbo (GET, POST).
O Angular, que é um framework javascript, é o responsável por solicitar, receber
e mostrar esses dados, além de os converter json em texto simples com o auxílio de
marcações da linguagem HTML5, apresentando assim a página ao usuário de forma
amigável. E como complemento utilizou-se o Semantic UI, framework da linguagem
CSS, para melhorar a aparência da página.
Finalmente, o aplicativo móvel desenvolvido com o framework Ionic, versão 2. O
aplicativo acessa os dados do banco através do middleware, nesse caso, é a própria API.
A aplicação móvel não possui uma base de dados local, ou seja, não há dados armazenado
no lado cliente com exceção do token que fica armazenado na memória do aparelho.
Também obedecendo a arquitetura REST, às informações são acessadas via HTTP e
exibidas de forma temporária sendo necessária a conexão com a rede sempre que
necessário revê-las, mantendo as informações sempre atualizadas.
4. RESULTADOS E DISCUSSÃO
Tendo sido realizadas as fases fundamentais para a conclusão do projeto elaborado,
observou-se que existe uma constante atualização das tecnologias e métodos utilizados
no desenvolvimento de sistemas como um todo, mas principalmente no que diz respeito
à computação distribuída.
O software desenvolvido foi executado numa pequena estrutura de rede construída
especificamente para a análise do sistema e nesta foram realizados o testes.
A Figura 3 ilustra o esquema de hardware e de rede usados para realizar os testes da
aplicação:
514
Figura 3 - Esquema de rede utilizado no sistema desenvolvido
FONTE: AUTORIA PRÓPRIA

Dos três laptops utilizados na estrutura, dois deles possuem o sistema operacional
Linux e o terceiro possui o Windows, enquanto o smartphone utiliza o sistema operacional
Android. Todos conectados na mesma rede.
5. CONCLUSÃO
Conclui-se a partir do investigado que existem inúmeras tecnologias disponíveis para o
desenvolvimento de sistemas distribuídos, sendo possível o desenvolvimento de um
software com a arquitetura e as tecnologias abordadas.
Observou-se a existência de grandes desafio para a computação distribuída, como por
exemplo a baixa velocidade da internet em algumas instituições e as falhas na arquitetura
de rede. É necessário àqueles que desejem seguir nessa área específica que aumentem
seus conhecimentos tanto na programação de sistemas como também em redes de
computadores.
Foi percebido que há grandes vantagens em desenvolver sistemas distribuídos,
pois estes possuem um grande potencial para expansão e integração com sistemas já
existentes. Sendo também o futuro da computação, a integração de todos os sistemas
através da internet.
REFERÊNCIAS
ABES, A. B. Mercado Brasileiro de Software - Panorama e Tendências. 2007.
Disponível em: <www.abes.org.br: http://www.abessoftware.com.br/dados-do-
setor/estudo-2017--dados-2016>. Acesso em: 07 Agos. 2017)
ANGULAR. Angular. Disponível em: <angular.io: https://angular.io/guide/template-
syntax>. Acesso em: 13 Agos. 2017.
CASS, S. As principais linguagens de programação de 2017. 2017. Disponível em:
<http://spectrum.ieee.org/computing/software/the-2017-top-programming-languages>.
Acesso em: 10 Agos. 2017.
COULOURIS, G.DOLLIMORE, J. & KINDBERG, T. SIstemas Distribuídos
Conceitos e Projeto. Porto Alegre. ABDR, 2007. 15p.
515
FOUNDATION, D. S. Django. Disponível em: <Djangoproject:

https://www.djangoproject.com/> . Acesso em: 05 Agos 2017.
INTERVOZES. Observatório do Direito à comunicação.2015. Disponível em:
<http://www.intervozes.org.br/direitoacomunicacao/?p=18374> Acesso em: 17 Ago.
2017.
JQUERY, T. F. Jquery write less, do more. Disponível em: <https://jquery.com/>.
Acesso em: 15 Agos. 2017.
LOPES, A. S. Projeto Integrador. Disponível em:
<gti.projetointegrador.com.br/~151N154200016/fundamentosTI.pdf> Acesso em: 15
Agos. 2017.
MATERA. Como Funciona um Webservice REST. Disponível em:
<http://www.matera.com/br/2012/10/22/como-funciona-um-webservice-rest/>. Acesso
em: 31 Jul. 2017.
MICROSOFT. O que é Middleware?. Disponível em: <https://azure.microsoft.com/pt-
br/overview/what-is-middleware/>. Acesso em: 10 Agos. 2017.
RECKZIEGEL, M. Entendendo os Web Services. 2006. Disponível:
<https://imasters.com.br/artigo/4245/web-services/entendendo-os-
webservices?trace=1519021197&source=single>. Acesso em: 18 Agos. 2017.
SANTANA, O., & GALESI, T. Python e Django Desenvolvimento ágil de aplicações
web. São Paulo. Novatec. 2010. 16p.
SILVA, M. S. HTML 5 A Linguagem de marcação que revolucionou a WEB. São
Paulo, SP, Brasil. Novatec. 2011.p. 20-22.
SOURCE, F. &. Semantic UI. Disponível em: <https://semantic-ui.com/>. Acesso em:
10 Agos. 2017.
SYSTEMS, M. Matera Systems. 2012. Disponível em:
<http://www.matera.com/br/2012/07/25/o-que-e-css-e-qual-sua-importancia/>. Acesso
em: 15 Agos. 2017.
TANENBAUM, A. S., & STEEN, M. V. Sistemas Distribuídos Princípios e
Paradigmas. São Paulo. Pearson. 2007. 1p.
TERRA. Histórias sobre site de busca. Disponível em:
https://sites.google.com/site/historiasobreossitesdebusca/primeiro-computador-do-
mundo>. Acesso em: 05 Jul. 2017.
VALE, V. Bucardo replicação Master->Master. 2014. Disponível em:
<http://www.viniciusvale.com/bucardo-replicacao-master-master/>. Acesso em: 18
Agos. 2017.
VAQQAS, M. Serviços Web RESTful: um tutorial. 2014. Disponível em:
<http://www.drdobbs.com/web-development/restful-web-services-a-
tutorial/240169069>. Acesso em: 17 Agos. 2017.
W3C. ECMA. Disponível em: < http://www.ecma-international.org/> Acesso em: 14
Agos. 2017.
516
Sistema IoT de avisos por imagens utilizando Aprendizagem

Baseada em Projeto
Pedro V. S. Guimarães, Manuel A. S. Maciel, Sandro C. S. Jucá
Departamento de Ciência da Computação

Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE)
Caixa Postal 61.939-140 – Maracanaú – CE – Brasil
{pedrovitorti, manuel.ifce,sandro.juca}@gmail.com
Abstract. This paper describes the use of a Linux embedded system for use in
digital information and communication technology in order to generate image
warnings using Internet of Things (IoT) principles. The proposed project
generated a product, developed using concepts of project-based learning
(ABP), called SECI (electronic internal communication system) that is
accessed by students to view online warnings by distributed monitors and also
by mobile devices connected to the Internet.
Resumo. O presente trabalho descreve a utilização de um sistema embarcado

Linux para uso em tecnologia digital de informação e comunicação no intuito
de gerar avisos por imagens utilizando princípios de Internet of Things (IoT).
O projeto proposto gerou um produto, desenvolvido utilizando conceitos de
aprendizagem baseada em projeto (ABP), chamado SECI (sistema eletrônico
de comunicação interna) que é acessado pelos alunos para visualização de
avisos online por monitores distribuídos e também por dispositivos móveis
conectados à Internet.
1. Introdução
A internet das coisas (IoT) possibilita o desenvolvimento de sistemas que nos permite
controlar o ambiente a nossa volta de forma cada vez mais automática. Hoje podemos
conectar diversos dispositivos em rede e trocar mensagens de controle, tornando as
nossas rotinas diárias mais rápidas, eficientes e gerando uma quantidade de informações
sobre o nosso ambiente doméstico e de trabalho.
A sociedade vive hoje em constante mudança, visto isso e a prospecção de novas
tecnologias, nada mais natural do que estas
T
et al. 2006].
Neste artigo, é proposto o desenvolvimento de um sistema de avisos sem fio,
que visa facilitar a divulgação de mensagens em uma comunidade acadêmica, baseado
em IoT usando Raspberry pi. O Raspberry pi é um computador completo de baixo
custo, ele é usado acoplado em monitores através de uma conexão via cabo HDMI. Está
configurado para abrir uma página web usando Wi-fi toda vez que é inicializado de
517
forma automática, nesta página são exibidas de forma cíclica imagens no formato jpg
(Joint Photographics Experts Group) contendo informações que antes eram divulgadas
através de papéis que exigia um esforço humano para distribuí-los, o gasto com papel,
bem como o gasto com tinta da impressora e o trabalho para trocar esses avisos
manualmente em quadros onde eram fixados.
Para isso foi criado um sistema Web chamado SECI (Sistema Eletrônico de
Comunicação Interna), onde os responsáveis pelo setor de comunicação gerenciam em
tempo real as imagens exibidas em cada monitor espalhados pela instituição.
Esse trabalho teve como princípio de desenvolvimento o método de
aprendizagem baseada em projeto (ABP) que permite identificar problemas do mundo
real e transformar ideias em produtos que atenderão às necessidades da comunidade que
fazem parte.
Nesta seção, são apresentados trabalhos relacionados que têm por objetivo propagar
informações para um determinado grupo de indivíduos usando a tecnologia para
melhorar a forma de distribuição de avisos, bem como reduzir custos com materiais.
O Multi Electronic Notice Board criado por Kruthika Simha, Shreya, Chethan
Kumar, Parinitha C, Shashidhar Tantry, utiliza-se um LCD alfanumérico para exibir
mensagens de texto. O circuito contém um centro de controle com um módulo GSM,
que é usado para receber os avisos como SMS. Esse centro de controle é usado para
gerenciar todos os LCDs que receberam os textos. A comunicação entre o centro de
controle e os centros de exibição é conseguida usando um protocolo de comunicação
serial com fio, enquanto os avisos podem ser enviados de qualquer lugar do mundo. O
uso de GSM é vantajoso, já que o ponto de envio não precisa ser vinculado a um local
fixo, aumentando substancialmente o alcance da comunicação. A introdução de um
módulo GSM neste sistema torna a mensagem exibida dinâmica, ou seja, o aviso que
está sendo exibido na placa muda conforme e quando as mensagens são enviadas.
Entretanto o LCD é limitado a exibir somente texto, apesar de poder variar o tamanho
do LCD ele sempre exibirá o mesmo formato de conteúdo alfanumérico.
Neeraj Khera, Divya Shukla, Shambhavi Awasth propuseram um sistema que
usa comunicação de dados em série sem fio Bluetooth ou Wi-Fi em exibição de
mensagens em um quadro de notificação digital remoto. Os programas de aplicação
baseados em Android disponíveis para comunicação Bluetooth e Wi-Fi para
dispositivos de assistente digital pessoal (PDA) são usados para transmitir as mensagens
de texto alfanuméricas. Para este fim, uma placa de microcontrolador de baixo custo
(Arduino Uno) está programada para receber mensagens de texto alfanuméricas em
qualquer um dos modos de comunicação selecionados. A placa de microcontrolador
Arduino Uno é programada para receber a mensagem do usuário remoto em tecnologia
de comunicação sem fio Bluetooth e Wi-Fi. Assim como o Multi Electronic Notice
Board, o sistema proposta é limitado a exibir também conteúdo alfanumérico.
O SECI, apresentado neste artigo, melhora os sistemas apresentados nesta seção
ao não se limitar a um LCD alfanumérico para exibir os avisos, visto que o SECI utiliza
qualquer monitor que tenha entrada HDMI, como monitores para computadores, TVs
etc. Por usar o modo gráfico do Raspberry pi o sistema utiliza um navegador web para
518
exibição, logo pode usar todos os recursos e os formatos aceitos em um browser como
jpg, png, gif, mp4, etc. No caso foi escolhido o formato jpg para exibir imagens em
forma fullscreen nos monitores.
3. Metodologia
Utilizando o princípios de ABP [Nobre et al. 2006], foi analisado o ambiente acadêmico
em busca de problemas onde o uso da tecnologia poderia tornar-se presente. Observou-
se como era feita a divulgação de avisos internamente na comunidade acadêmica, quais
métodos e recursos eram utilizados. Na instituição de ensino superior utilizada na
pesquisa, refletiu o que se é possível ver em muitas instituições de ensino, o uso de
flanelógrafos espalhados pelas dependências da instituição, onde são fixados os avisos
pelo setor de comunicação, que é o responsável pela distribuição dos avisos em cada
flanelógrafo, que acarreta no consumo excessivo de papéis.
O SECI disponibiliza uma página web onde os avisos em formato jpg ficam
sendo exibidos de forma cíclica. Essa página é aberta em um browser através de um
sistema embarcado Linux composto por um Raspberry Pi (RPi) conectado ao monitor
via cabo HDMI, ela também pode ser acessada pelos alunos via dispositivos móveis,
como pode ser visto na Figura 1.
Figura 1. Ilustração do fluxo do sistema
O Administrador (Figura 1) representa o setor responsável pela moderação

dos avisos que serão exibidos no slideshow, assim foi necessário a criação de um
controle de acesso (Figura 2) para poder garantir segurança ao sistema. Ao fazer
login no SECI, o administrador terá controle sobre os avisos que estão sendo
exibidos, podendo substituí-los realizando o upload de uma imagem .jpg para o
servidor. Quando uma imagem de aviso nova é enviada para o servidor, um arquivo
de controle é alterado informando essa mudança. Os RPis ficam verificando esse
519
arquivo a cada 5 segundos, caso alguma mudança tenha ocorrido o navegador web
é atualizado, exibindo assim os avisos novos em todos os monitores e na página
acessada pelos dispositivos móveis.
Figura 2. Tela inicial do SECI
O processo de desenvolvimento do projeto, bem como sua implementação pode

ser dividido em duas partes, sendo a primeira o desenvolvimento do sistema Web e a
segunda a configuração do Raspberry Pi que ficará ligado nos monitores via cabo a
HDMI, sendo o responsável por executar rotinas automatizadas IoT.
Na parte Web foi utilizado HTML, CSS, JavaScript e PHP para criar o SECI que
fica hospedado em um servidor apache. Quando o usuário administrador efetua o login
(Figura 2) é apresentado um preview dos avisos que estão sendo exibidos nos
monitores, assim como a opção de fazer o upload de novas imagens de avisos.
Para facilitar a divulgação de comunicados que precisam somente de texto, foi
criado um mecanismo de geração de simples imagens contendo mensagens textuais,
facilitando assim a propagação de informações curtas internamente na instituição. O
administrador seleciona o setor de origem do comunicado, define um tema e faz um
breve resumo do que deseja informar (Figura 3).
520
Figura 3. O SIGE possui um mecanismo de geração de imagens de avisos.
A segunda parte fica com a configuração do Raspberry Pi para agir como a CPU
acoplada em cada monitor, sendo responsável por exibir o slideshow com os avisos
assim que é ligada sua fonte de alimentação. Para automatizar a rotina do RPi foi
utilizado um Script que é iniciado junto com o boot do sistema embarcado. As
configurações desse Script possibilitam que no momento da inicialização seja
apresentado o browser de forma automática em modo fullscreen e também é
responsável por verificar se houveram atualizações nas imagens do servidor.
As mudanças feitas no sistema operacional do RPi foram:
1) Abrir firefox de forma automática:

Copiar arquivo de inicialização firefox.desktop localizado em
/usr/share/applications para /etc/xdg/autostart.
2) Executar o shell script ao iniciar o sistema:
Necessário adicionar no final do arquivo .bashrc que fica localizado no
diretório do usuário Pi a seguinte linha de comando: ./f5.sh&. Isso fará o script f5.sh ser
chamado no boot do S.O. e ficar sendo executado em segundo plano.
Essas mudanças permitem que os Rpis conectados aos monitores não precisem
ser acessados para realizar qualquer tipo de configuração, assim logo que forem ligados
já estarão exibindo o sistema Web responsável pelos avisos.
521
No script f5.sh existe uma estrutura de repetição que fica a cada 5 segundos
consultando um arquivo texto hospedado no servidor. Uma verificação nesse arquivo é
necessária para saber se houve alguma imagem nova adicionada para exibição. No
momento em que o administrador do SECI envia um aviso novo esse arquivo de texto é
modificado, assim ao consultá-lo novamente, o RPi sabe que houve uma alteração no
servidor, então o f5.sh executa os sequintes comandos:
export DISPLAY=:0 # Seleciona o display do Rpi

Janela=`xdotool search --name "Mozilla Firefox" # Número janela firefox
xdotool windowactivate $Janela # Seleciona Janela para receber comando
xdotool key F5 # Executa a tecla F5 na Janela, atualizando o browser
Após atualizar as mensagens de avisos, o script f5.sh irá modificar o arquivo

texto no servidor, voltando sua informação para o estado anterior.
4. Descrição dos componentes e ferramentas utilizadas

Este tópico descreve os componentes e ferramentas utilizadas para a realização
desse projeto.
4.1. Apache
O Servidor Web Apache foi escolhido por ser consistente, possibilitar uma
quantidade grande de ferramentas e por ter compatibilidade com o sistema operacional
do Raspberry Pi (2016). A escolha por SECI ser um sistema web ocorreu pelo fato de
tornar a atualização dos avisos mais dinâmica e de forma que ocorra em todos os
sistemas embarcados utilizados nos monitores de forma simultânea.
4.2. Raspberry Pi
O Raspberry Pi (Figura 4), considerado o menor computador do mundo, possui
o tamanho de um cartão de crédito, conexões USB para conectar o teclado e mouse
utilizados em computadores de mesa. É possível conectá-lo à TVs com saída RCA ou
HDMI, além de ter um baixo custo de hardware e custo zero em seu software de sistema
embarcado. Todo o hardware é integrado em uma única placa. Têm em sua capacidade a
possibilidade de se desenvolver tudo que um computador convencional faz, como
navegar, criar planilhas, reproduzir vídeos, processar textos, jogos, entre outras tarefas
mais complexas, como o monitoramento online. Dessa forma, é utilizado por crianças
de todo o mundo para aprender como funcionam os computadores, como manipular o
mundo eletrônico ao redor deles, e como programá-los.
522
Figura 4. Raspberry Pi [Richardson e Wallace 2013]
4.3. Linguagem de programação PHP

O PHP é utilizado em grande parte dos sites vistos na web. Ela possui uma
grande estrutura e ferramentas que facilitam a vida do programador. Sua integração com
o HTML e o JavaScript foi um dos motivos da escolha do PHP para ser a linguagem
que o SECI seria desenvolvido.
4.4. HTML/CSS/JavaScript
A junção dessas três linguagens possibilitou a criação do site como pode ser
visto da Figura 2, onde é gerada uma imagem jpg nas dimensões da TV. A figura 5
mostra uma das estações com o Raspberry pi conectado a uma TV, o sistema foi
montando no restaurante acadêmico da universidade e funcionou de forma correta
substituindo os avisos com papel.
Figura 5. TV exibindo os avisos através do SECI
523
Como foi visto neste trabalho, o sistema embarcado Linux composto por um Rpi
utilizado como controlador do sistema IoT de exibição dos avisos funcionou como
projetado utilizando técnicas de aprendizagem baseada em Projeto no início da
disciplina de sistemas embarcados, quando foi concebida essa aplicação.
Foi apresentado neste trabalho o desenvolvimento de um sistema embarcado
Linux baseado em Raspberry pi para uso em tecnologia digital de informação e
comunicação no intuito de gerar avisos por imagens utilizando princípios de IoT. O
projeto proposto gerou um produto, desenvolvido utilizando conceitos de aprendizagem
baseada em projeto (ABP), chamado SECI (sistema eletrônico de comunicação interna)
que é utilizado pelos alunos para visualização de avisos online utilizando dispositivos
móveis conectados à Internet.
6. Referências
BEN ER W N (2014) “ z : çã f
para o século XXI. Porto Alegre: Penso.
CANTINI, M. C; (2006) “O desafio do professor frente às novas tecnologias.
Disponível em:
http://www.pucpr.br/eventos/educere/educere2006/anaisEvento/docs/CI-081-TC.pdf
Acesso em: 17/05/2016
NOBRE, J. C. S; (2006) “ z B P (P -Based Learning
– PBL) fw ” : http://www.br-
ie.org/pub/index.php/sbie/article/download/486/472. Acesso em 30/06/2017.
KRUTHIKA SIMHA, SHEYA, CHETHAN KUMAR, PARINITHA C,
SHASHIDHAR TANTRY. (2016) Electronic notice board with multiple output display
in Paralakhemundi, India. http://ieeexplore.ieee.org/document/7955701/
NEERAJ KHERA, DIVYA SHUKLA, SHAMBHAVI AWASTHI. (2016)
Development of simple and low cost Android based wireless notice board in Noida,
India. http://ieeexplore.ieee.org/document/7785031/
R y P (2016) “ R y P M ”
https://www.raspberrypi.org/documentation/hardware/computemodule/RPI-CM-
DATASHEET- 1_0 f ”
RICHARDSON, M. e WALLACE, S.(2013) Instalação e Configuração, In: M.
R S W (2013) “P P R y P ” Sã P :
Novatec Editora, p.17-36.
524
Uma Plataforma Distribuı́da para Avaliação de Desempenho

em Aplicativos Móveis
João Marcos Rosal, Ricardo da Silva, Brena Maia, Rodrigo Leal e Francisco Airton Silva
rosaljoao,ricardobrunof,brenamaia12,rocaleal98}@gmail.com
e [email protected]
Abstract. The number of Smartphones has increased exponentially worldwide.

Research shows that such a magnitude will triple by 2018. The significant
growth in the number of mobile devices has brought several challenges. Among
them, the battery life of devices that do not have extensive autonomy stands
out. Several surveys have focused on the monitoring of energy expenditure,
without allowing an automatic comparison. This paper proposes a distributed
platform focused on the monitoring and comparison of energy consumption of
mobile applications. Experiments were performed under message delivery ser-
vice of WhatsApp and Messenger applications. The results have showed that
WhatsApp had lower energy expenditure in all models. The Samsung Galaxy S3
SGH-T999 model had the least expense in WhatsApp and a very high expendi-
ture for Messenger. In all model cases, the Messenger has had an inicial energy
consumption superior to WhatsApp .
Resumo. O número de Smartphones em uso tem aumentado em nı́veis exponen-

ciais mundialmente. Esse crescimento elevado tem trazido diversos desafios.
Dentre eles, destaca-se a duração de bateria de dispositivos que não tem auto-
nomia extensa. Diversas pesquisas tem focado no aprimoramento do hardware
e do software para redução de consumo energético. As tecnologias de monitora-
mento de gasto energético por software não possibilitam uma comparação au-
tomática. Este artigo propõe uma plataforma distribuı́da para monitoramento
e comparação de consumo energético de aplicativos móveis de maneira au-
tomática. Experimentos foram feitos sobre a funcionalidade de envio e entrega
de mensagens dos aplicativos WhatsApp e Messenger. Os resultados apontaram
que o WhatsApp teve menor consumo energético nos Smartphones testados. O
Samsung Galaxy S3 SGH-T999, em detalhe, teve o menor gasto do aplicativo, e
um gasto bem elevado no Messenger. Em todos os casos avaliados, o Messenger
teve um carregamento inicial com gasto mais elevado em relação ao WhatsApp
já que possui maior número de recursos que precisam ser iniciados.
1. Introdução
De acordo com um relatório apresentado pela Ericsson no ano de 2012, o número de
Smartphones triplicará até 2018, chegando à marca de 3,3 bilhões de unidades no mundo.
525
O crescimento do uso de Smartphones tem sido exponencial considerando os relatórios

anuais da Ericsson, como o de 2013, 2014, 2015 e 2016. Dentre esses bilhões de disposi-
tivos, estima-se que 82,2% deles possuem sistema operacional Android segundo pesquisa
de Gartner (2015) 2 e The Verge 3 (2015).
O aumento crescente do uso de Smartphones é acompanhado com o aumento
de aplicativos móveis que podem oferecer uma gama de serviços. Eles permitem ouvir
músicas, trocar mensagens, e-mails, pesquisar e ver vı́deos em tempo real, por exemplo.
Porém, os desenvolvedores de aplicativos móveis também precisam se preocupar com a
eficiência energética de seus softwares.
Os Smartphones são atualmente carregados por baterias de Lı́tium-Íon. O Bat-
tery University4 discute a duração de baterias de Smartphones. A duração de vida da
bateria é de cerca de um ano a um ano e meio, o que representa 300 e 500 recargas.
O que motiva o desenvolvimento de estratégias que minimizem o consumo energético
de aplicativos sem necessidade de modificação no hardware que representa maior custo
[Silva-Filho et al. 2012].
Diversas pesquisas cientı́ficas foram feitas a respeito do monitoramento de con-
sumos energéticos de aplicativos móveis [Zhang et al. 2010, Jung et al. 2012, Choi 2013,
Hao et al. 2013, Hao et al. 2014]. Existem também aplicações que realizam o monitora-
mento do gasto de bateria, como por exemplo o PowerTutor9 que é amplamente utilizado
na academia cientı́fica [Saipullah 2012, Lee et al. 2012, Xiao et al. 2010]. No entanto,
nenhuma das pesquisas oferece a possibilidade de comparação automática por aplicativo.
Este artigo propõe uma plataforma distribuı́da para comparação de consumo
energético de aplicativos móveis para o Sistema Operacional Android. O aplicativo de-
senvolvido chamado de AppCompare realiza o monitoramento de gasto energético por
aplicativos instalados no Smartphone ou Tablet. Após monitoramento, a comparação é
realizada com auxı́lio de gráficos estatı́sticos para apontar informações e conclusões im-
portantes.
O restante deste trabalho está organizado da seguinte forma: a Seção 2 discute
e mostra a solução proposta neste trabalho; a Seção 3 demonstra o experimento feito e
os resultados obtidos; a Seção 4 mostra os trabalhos relacionados com esta pesquisa e a
Seção 5 discute as conclusões e trabalhos futuros.
2. Plataforma de Avaliação Distribuı́da

Esta seção procura discutir a ideia de comparação compartilhada de aplicativos móveis
considerando o consumo energético (ver subseção 2.1) e do software AppCompare criado
durante esta pesquisa para a realização dessa tarefa (ver subseção 2.2).
2.1. Visão Geral

A plataforma que foi proposta para comparação de aplicativos é formada pela ideia de um
sistema distribuı́do que coleta informações de monitoramento de diversos dispositivos. A
1
Relatório de 2012 da Ericsson: goo.gl/ALyzFm
2
Gartner: goo.gl/6trBgR
3
The Verge: goo.gl/bBJDSw
4
Battery University: goo.gl/y4m2t2
5
PowerTutor: goo.gl/QMFGkj
526
Figura 1 apresenta a execução de experimentos em diversos dispositivos armazenados em

um servidor na Internet.
Ser
vidornaNuvem
Mot
oG Pl
ay SM-
J710MN LG D337 SM-
J500M LG D392
Figura 1. Esquematização da Arquitetura
Em cada dispositivo, o aplicativo AppCompare executa a comparação e envia as

informações para o servidor. O número de dispositivos (Smartphones e Tablets) que po-
dem participar de um experimento como esse não é limitado pela plataforma. A única
restrição que pode ocorrer é por parte do servidor configurado para recebimento dos da-
dos. O usuário tem a liberdade de definir seu servidor na Nuvem para armazenamento.
2.2. AppCompare
Fazendo parte da plataforma de avaliação de desempenho distribuı́da, foi desenvolvido
um aplicativo que realiza comparação automática entre aplicativos móveis, considerando-
se o critério de consumo energético. A aplicação submetida funciona em cinco fases:
1. Seleção de Aplicativos: Cada usuário pode selecionar um ou mais aplicativos que
estão instalados no sistema para realizar a investigação. A Figura 2 apresenta a
tela para seleção de aplicativos.
2. Configuração do Experimento: Nesta etapa o usuário deve escolher o número
de observações que serão realizadas pelo AppCompare. O número de observações
definido é o mesmo para todos os aplicativos avaliados;
3. Execução do Experimento: Nesta etapa são abertos, em sequência (não simulta-
neamente), os aplicativos avaliados. Após a abertura do aplicativo em avaliação,
o usuário pode usar funcionalidades que deseja conhecer seu gasto energético
e comparar com os outros selecionados. Por exemplo, a comparação entre o
consumo energético do serviço de mensagens do Whatsapp e Messenger seria
um experimento possı́vel. Para execução do experimento foi adotado o conceito
de observações por segundo, onde são capturados os consumos energéticos das
aplicações avaliadas no intervalo de um segundo, formando uma observação. O
tempo de execução do experimento é variável conforme o número de observações,
se forem 30 observações, será, assim, 30 segundos para monitoramento do aplica-
tivo.
4. Geração de Relatório em Gráficos: Nesta etapa o AppCompare executa uma
análise estatı́stica e gera gráficos de fácil interpretação do usuário. Um gráfico
527
de barras apresenta os consumos energéticos durante cada observação para cada

aplicativo (ver Figura 3). Assim, pode ser observado o crescimento do consumo
energético com o passar das observações. O gráfico Boxplot é utilizado para per-
mitir a avaliação da distribuição e amplitude dos dados de gasto energético. O
BoxPlot fornece informação sobre dispersão, outliers de dados e identificar o apli-
cativo com maior eficiência; Na Figura 3 (A) pode ser observado o aumento de
consumo energético com o passar das observações.
5. Geração de Relatório Conclusivo: Posteriormente é apresentado uma conclusão
estatı́stica da comparação. O resultado do teste com T-Student é mostrado quando
a comparação envolve somente dois aplicativos. O AppCompare informa se as
amostras são estatisticamente iguais ou diferentes. Neste ponto o usuário pode
escolher enviar o resultado para o servidor na nuvem ou simplesmente salvar os
valores no próprio dispositivo.
(
A) (
B)
Figura 2. (A) Seleção de Aplicativos (B) Configuração do Experimento
(A) (B)
Figura 3. (A) Gráficos de Barras e (B) Boxplot
3. Experimento
O experimento foi baseado na execução do AppCompare por um conjunto de modelos de
Smartphones distintos. Os aplicativos móveis investigados foram: WhatsApp e Messen-
ger. O número de observações para cada aplicativo foi 30.
528
Foi avaliado somente o serviço de troca de mensagens de texto dos aplicativos.

Para uma comparação mais justa, as mensagens que iam ser trocadas e as respostas foram
definidas. A rede de comunicação que foi utilizada para todos os experimentos também
foi a mesma. Foram seis perguntas e seis respostas de conversação. As perguntas e
respostas estão ilustradas na Figura 4.
Figura 4. Script de Perguntas e Respostas Utilizadas no Experimento
As mensagens definidas são importantes para avaliação já que sua configuração
impacta na avaliação do gasto energético do AppCompare. Para o teste T-Student feito,
o aplicativo utiliza a hipótese que o WhatsApp tem consumo energético distinto do Mes-
senger. Por padrão, o aplicativo considera sempre esta hipótese (de médias diferentes).
Se o resultado for True, então, os aplicativos tem consumos diferentes, caso contrário
(False) os aplicativos possuem consumos estatisticamente iguais. A Figura 5 apresenta os
gráficos BoxPlot gerados para os cinco modelos de Smartphones avaliados.
Em todas as comparações executas, a hipótese padrão (h0) sempre foi classificada
como verdadeira, ou seja, as médias de consumo foram sempre distintas. O aplicativo
AppCompare apresenta textualmente para o usuário que o consumo energético dos apli-
cativos é distinto.
Nos testes apresentados na Figura 5, é possı́vel perceber que o aplicativo Messen-
ger teve maior consumo energético em relação ao WhatsApp em todas as situações. A
ausência de intersecções entre as caixas dos gráficos BoxPlot representa que as medições
foram maiores sempre para o Messenger. O modelo de Smartphone que vale a pena ser
destacado é o Samsung Galaxy S3 SGH-T999 que teve um gasto pequeno e peculiar para a
troca de mensagens no WhatsApp, enquanto que teve um gasto elevado para o Messenger.
Ao avaliar a figura 6, percebe-se que o consumo energético do Messenger é su-
perior em todos os momentos. Isto se deve ao fato de que o Facebook Messenger possui
muito mais recursos do que o Whatsapp, como lista de contatos Online, Status, Jogos
online (Opções Não Existentes no Whatsapp), requerindo maior poder de processamento,
529
(A) (B)
(C) (D)
(E)
Figura 5. Gráficos BoxPlot sobre os Testes
portanto, mais energia.
Esta seção apresenta os trabalhos relacionados ao presente estudo ordenados por ano (de
2010 a 2014). Para melhor visualização, a Tabela 1 elenca quatro fatores comparativos:
Métricas de Monitoramento, Comparação Automática e Contexto. A seguir, estes fatores
são comentados.
Tabela 1. Comparativo entre Trabalhos Relacionados

Trabalho Métricas de Monitoramento Comparação Automática Contexto
[Adhianto et al. 2010] CPU Não Programas de Computador
[Zhang et al. 2010] Performance de Sistema e Consumo Energético Não Dispositivos Móveis
[Wang et al. 2012] Operações E/S Não Dispositivos Móveis
[Jung et al. 2012] Consumo Energético Não Dispositivos Móveis
[Choi 2013] Consumo Energético Não Dispositivos Móveis
[Hao et al. 2013] Consumo Energético, CPU, Memória RAM, Wi-Fi e GPS Não Aplicativos Móveis
[Hao et al. 2014] Performance de Interface e Uso de Rede Não Aplicativos Móveis
Nosso Trabalho Consumo Energético Sim Aplicativos Móveis
530
Modelo Lg D392 Modelo SGH-T999

100 60
Gasto Energético (J)

40
50
20
0 0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
Observações Observações
WhatsApp Messenger WhatsApp Messenger
Modelo SM-J320M Modelo SM-J500M

60 60

40 40
20 20
0 0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
Observações Observações
WhatsApp Messenger WhatsApp Messenger
Modelo XT1068
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
Observações
WhatsApp Messenger
Figura 6. Consumo Energético por Observações
• Métricas de Monitoramento: Métricas são propriedades mensuráveis que quan-

tificam uma tendência ou comportamento, permitindo medir e avaliar o de-
sempenho de algo. Alguns trabalhos focaram no monitoramento de CPU
[Adhianto et al. 2010], outros foram mais abrangentes tratando também de uso
de Memória RAM, Wi-Fi e GPS [Hao et al. 2013]. Este trabalho, assim como
[Choi 2013], está focado no Consumo Energético de dispositivos.
• Comparação Automática: Este fator refere-se a comparação automática dis-
ponı́vel pelo aplicativo entre os resultados do monitoramento. Os trabalhos re-
lacionados anteriormente não ofereceram tal funcionalidade, sendo esse um dife-
rencial desta pesquisa.
• Contexto: O monitoramento foi feito em diversos tipos de aparelhos ou ambi-
entes. Foram estudados Dispositivos Móveis [Choi 2013], Programas de Com-
putador [Adhianto et al. 2010], e gasto de Aplicativos Móveis [Hao et al. 2013,
Hao et al. 2014]. O AppCompare segue a linha de monitoramento sobre Aplicati-
vos Móveis assim como [Hao et al. 2014].
531
5. Conclusão
Este artigo apresentou uma plataforma chamada AppCompare para avaliação de gasto
energético de aplicativos móveis. A comparação automática com teste T-Student foi re-
alizada com os aplicativos WhatsApp e Messenger. O experimento realizado baseou-se
na execução do AppCompare por Smartphones de modelos distintos, e teve as mesmas
configurações (rede, número de observações) para aumento de rigor. O resultado das
execuções demonstrou que o aplicativo WhatsApp teve menor gasto energético em todos
os modelos no quesito trocas de mensagens de texto. O modelo Samsung Galaxy S3
SGH-T999 teve o menor gasto no WhatsApp, e inversamente um gasto bem elevado para
o Messenger. Representando quanto o consumo pode variar pela mudança de aplicativo
de troca de mensagens de texto. O gasto de energia pelo WhatsApp nos modelos tem
valores com menor amplitude, sem existência de picos elevados de consumo, ao contrário
do Messenger. A inicialização foi sempre superior para o aplicativo Messenger visto seu
maior conjunto de funcionalidades que necessitam ser carregadas. Para trabalhos futuros,
pretende-se possibilitar a comparação com três ou mais aplicativos utilizando técnicas es-
tatı́sticas como a ANOVA. Além disso, usar uma técnica ou mecanismo que possibilite
mensurar a precisão do aplicativo no consumo energético.
Referências
Adhianto, L., Banerjee, S., Fagan, M., Krentel, M., Marin, G., Mellor-Crummey, J., and
Tallent, N. R. (2010). Hpctoolkit: Tools for performance analysis of optimized parallel
programs. Concurrency and Computation: Practice and Experience, 22(6):685–701.
Choi, M. (2013). Power and performance analysis of smart devices. Int. J. Smart Home,
7(3):57–66.
Hao, S., Li, D., Halfond, W. G., and Govindan, R. (2013). Estimating mobile application
energy consumption using program analysis. In Software Engineering (ICSE), 2013
35th International Conference on, pages 92–101. IEEE.
Hao, S., Liu, B., Nath, S., Halfond, W. G., and Govindan, R. (2014). Puma: Programma-
ble ui-automation for large-scale dynamic analysis of mobile apps. In Proceedings of
the 12th annual international conference on Mobile systems, applications, and servi-
ces, pages 204–217. ACM.
Jung, W., Kang, C., Yoon, C., Kim, D., and Cha, H. (2012). Devscope: a nonintrusive and
online power analysis tool for smartphone hardware components. In Proceedings of
the eighth IEEE/ACM/IFIP international conference on Hardware/software codesign
and system synthesis, pages 353–362. ACM.
Lee, J., Joe, H., and Kim, H. (2012). Smart phone power model generation using use pat-
tern analysis. In Consumer Electronics (ICCE), 2012 IEEE International Conference
Saipullah, K. M. (2012). Opencv based real-time video processing using android
smartphone. International Journal of Computer Technology and Electronics Engi-
neering, 1(3):1–6.
Silva-Filho, A. G., Bezerra, P., Silva, F., Júnior, A. L., Santos, A. L., Costa, P. H., and
Miranda, R. C. (2012). Energy-aware technology-based dvfs mechanism for the an-
532
droid operating system. In Computing System Engineering (SBESC), 2012 Brazilian

Symposium on, pages 184–187. IEEE.
Wang, J., Wu, X., Wei, J., et al. (2012). Detect and optimize the energy consumption of
mobile app through static analysis: an initial research. In Proceedings of the Fourth
Asia-Pacific Symposium on Internetware, page 22. ACM.
Xiao, Y., Bhaumik, R., Yang, Z., Siekkinen, M., Savolainen, P., and Yla-Jaaski, A. (2010).
A system-level model for runtime power estimation on mobile devices. In Green Com-
puting and Communications (GreenCom), 2010 IEEE/ACM Int’l Conference on & Int’l
Conference on Cyber, Physical and Social Computing (CPSCom), pages 27–34. IEEE.
Zhang, L., Tiwana, B., Dick, R. P., Qian, Z., Mao, Z. M., Wang, Z., and Yang, L. (2010).
Accurate online power estimation and automatic battery behavior based power model
generation for smartphones. In Hardware/Software Codesign and System Synthesis
(CODES+ ISSS), 2010 IEEE/ACM/IFIP International Conference on, pages 105–114.
IEEE.
533
Uma Abordagem Baseada em Índices de Sensibilidade para a

Determinação da Sequência de Ajustes no Controle da
Magnitude de Tensão em Sistemas de Transmissão de Energia
Elétrica
Enza Rafaela de S. Ferreira1 , Thiago Allisson R. da Silva1 ,
Ricardo de A. L. Rabelo1
1
Departamento de Computação – Universidade Federal do Piauí (UFPI)
[email protected],[email protected],[email protected]
Abstract. The voltage magnitudes must be maintained within limits defined by

regulatory agency for the operation of an transmission power system. In this
context, this paper proposes an approach that determines and applies a se-
quence of adjustments to voltage magnitude control in transmission power sys-
tems. The adjustments are determined for one methodology based on sensitivity
indices extracted of the reduced Jacobian matrix (JQV ) of the system power ba-
lance equations. Computational simulations in the IEEE (Institute of Electrical
and Eletronic Engineers) 57 bus system are performed to evaluate the propo-
sed approach considering one operational scenario with voltage violations. The
obtained results provide the dispatch of reactive power necessary for the cor-
rection of the voltage violations, the bus voltage profiles and the active power
losses in the system as adjustments are executed.
Resumo. As magnitudes de tensão devem ser mantidas dentro de limites de-

finidos por órgãos de regulamentação para o funcionamento de um sistema de
transmissão de energia elétrica. Nesse contexto, este trabalho propõe uma abor-
dagem que determina e aplica uma sequência de ajustes no controle da magni-
tude de tensão em sistemas de transmissão de energia elétrica, em que os ajustes
são determinados em função de uma metodologia baseada em índices de sensi-
bilidade extraídos da matriz Jacobiana reduzida (JQV ) das equações de balanço
de potência do sistema. Simulações computacionais no sistema IEEE (Institute
of Electrical and Eletronic Engineers) de 57 barras são realizadas para avaliar
a abordagem proposta considerando um cenário operacional com violações de
tensão. Os resultados obtidos fornecem o despacho de potência reativa neces-
sário para a correção das violações de tensão, os perfis de tensão nas barras
do sistema e as perdas de potência ativa à medida que ajustes são realizados.
1. Introdução
Um sistema de transmissão de energia elétrica interconecta as centrais de geração aos lo-
cais de consumo, devendo ser operado de forma a suportar quaisquer mudanças nos perfis
de geração e de carga de potência [Momoh 2012]. Nos sistemas de transmissão, o con-
trole da magnitude de tensão possui um papel fundamental para a sua operação segura,
pois se as magnitudes de tensão estiverem fora dos limites pré-definidos por órgãos de
regulamentação, o sistema elétrico pode ser levado a operar próximo a condições críti-
cas [Kundur et al. 2004].
Para evitar tais cenários, os operadores do sistema possuem a sua disposição me-
canismos de controle como: geradores síncronos, transformadores em fase, bancos de
534
capacitores e reatores em derivação (shunt), FACTS (Flexible Alternating Current Trans-

mission System) etc. [Robitzky et al. 2015].
Um dos principais fatores que levam as tensões a valores não adequados é a
incapacidade do sistema em atender a demanda de potência reativa. Portanto, torna-
se essencial que sejam implementados mecanismos de controle que determinem um
despacho de potência reativa suficiente para que violações de tensão sejam corrigi-
das [Eremia and Shahidehpour 2013]. O despacho de potência reativa tem sido apli-
cado de forma bem sucedida em diferentes abordagens apresentadas na literatura
[Calderaro et al. 2015].
Em [Silva et al. 2015] uma infraestrutura de comunicação é aplicada para auxiliar
o controle da magnitude de tensão em sistemas de transmissão de energia elétrica. Em
[Loia et al. 2013] é introduzida uma abordagem descentralizada para o controle da mag-
nitude de tensão baseada em uma população de agentes cooperativos fuzzy. Entretanto,
nenhum dos trabalho descritos define e aplica uma sequência de ajustes para corrigir vi-
olações na magnitude de tensão das barras de carga de um sistema de transmissão de
energia elétrica.
Nesse contexto, este trabalho propõe uma abordagem que determina uma sequên-
cia de ajustes a ser executada nos geradores síncronos do sistema para corrigir as viola-
ções de tensão. Para determinar os ajustes,é usada uma metodologia de controle baseada
na em índices de sensibilidade, informações extraídas a partir da matriz Jacobiana redu-
zida (JQV ) [Lage et al. 2013]. A aplicação da metodologia define o conjunto de barras
de controle a ser ajustada, bem como estabelece os ajustes nas magnitudes de tensão dos
geradores síncronos para modificar o despacho de potência reativa.
Por fim, o restante do trabalho está organizado da seguinte forma: a Seção 2 apre-
senta a abordagem proposta para o controle da magnitude de tensão descrevendo a me-
todologia de controle desenvolvida; a Seção 3 apresenta as simulações computacionais
realizadas no sistema IEEE (Institute of Electrical and Eletronic Engineers) de 57 barras
e os resultados obtidos; a Seção 4 apresenta as conclusões e trabalhos futuros.
2. Abordagem de Controle Proposta
Nesta seção é apresentada a abordagem proposta para o controle da magnitude de tensão,

que é formada por dois componentes (Gestor de Controle e os Nós de Controle), a for-
mulação aplicada para realização do despacho de potência reativa e o funcionamento da
abordagem.
2.1. Gestor de Controle
O Gestor de Controle é o componente responsável por resolver o problema do Fluxo de

Carga, determinar as barras com tensões violadas e aplicar a metodologia de controle para
definir a sequência de ajustes no despacho de potência reativa.
Neste trabalho, os limites da faixa adequada de valores da magnitude de tensão
são definidos pelo ONS (Operador Nacional do Sistema Elétrico) e a magnitude de tensão
(Vk ) de uma barra k (em p.u.) deve estar dentro do intervalo definido por 0.95 ≤ Vk ≤
1.05. Caso a magnitude de tensão de uma barra de carga (i) esteja fora da faixa de valores
adequada uma certa quantidade de potência reativa deve ser injetada no sistema.
535
2.1.1. Definição da abordagem
A sequência de ajustes é determinada em função de análises de sensibilidade baseadas na

matriz JQV das equações de balanço de potência do sistema, a qual relaciona variações da
injeção de potência reativa com variações nas magnitudes de tensão nas barras do sistema.
Essas equações de balanço podem ser aproximadas linearmente por (1).

∆P (θ, V ) ∆θ
= J (θ, V ) (1)
∆Q (θ, V ) ∆V
Para encontrar a relação entre variações nas injeções de potência reativa com varia-
ções nas magnitudes de tensão, desconsidera-se que as injeções de potência ativa variem
(∆P (θ, V ) = 0). Dessa forma, consideram-se apenas as variações de potência reativa
(∆Q (θ, V )) como resultantes da combinação entre a matriz Jacobiana J (θ, V ) das equa-
ções de balanço de potência com as variações nos ângulos de fase (∆θ) e as magnitudes
de tensão (∆V ).
0 ∆θ
= J (θ, V ) (2)
∆Q (θ, V ) ∆V
Considerando que:
" ∂P ∂P #
∂θ ∂V J1 J2
J (θ, V ) = = (3)
∂Q ∂Q J3 J4
∂θ ∂V
a redução de (2) em termos de ∆Q e ∆V resulta em:
∆Q = J4 − (J3 J1−1 J2 ) ∆V.

(4)
Dessa forma, tem-se que:
JQV = J4 − (J3 J1−1 J2 ), (5)
Adicionalmente, para a definição da sequência de ajustes é preciso determinar o

vetor de desvios nas magnitudes de tensão (∆VC ), que armazena os valores da diferença
entre a magnitude de tensão das barras de carga e o limite mínimo ou máximo da faixa de
valores adequado, sendo calculado de acordo com (6).
(
Vi − V max , se Vi > V max
∆VC = , i = 1, · · · , NP Q (6)
V min − Vi , se Vi < V min
, onde:
• V min : corresponde ao valor de 0,95 p.u.
• V max : corresponde ao valor de 1,05 p.u.
• NP Q : número de barras de carga no sistema.
Após a definição da matriz Jacobiana reduzida e do vetor ∆VC , obtém-se a esti-
mativa da variação na geração de potência reativa das barras de controle (∆QG ) calculada
de acordo com (7).
∆QG = JQV ∆VC (7)
536
A variação de potência reativa nos geradores síncronos é produzida modificando-

se a magnitude de tensão nas barras de controle. Assim determina-se o quanto variar na
magnitude de tensão das barras de geração, no intuito de injetar a quantidade de potência
reativa desejada de acordo com (8).
−1
∆VG = JQV ∆QG (8)
2.1.2. Funcionamento da Abordagem
A metodologia de controle VSF (Voltage Sensitivity Factor) [Löf et al. 1992] (apresen-
tada no Algoritmo 2), aplica índices de sensibilidade obtidos por meio da inversa da ma-
−1
triz Jacobiana reduzida JQV e recebe como entrada os vetores ∆VC e ∆QG , calculados
de acordo com (6) e (7), e a matriz JQV , calculada de acordo com (5). Inicialmente, ela
determina a barra i que possui a maior violação de tensão (Passo 2). Em seguida, a matriz
S com os índices de sensibilidade é computada (Passo 3). Depois, define-se a barra j a ser
ajustada, aquela cujo índice de sensibilidade da i-ésima coluna de S tiver o maior valor
(Passo 4). Então, calcula-se o ajuste na magnitude de tensão (∆VG ) para ser realizado o
despacho de potência reativa necessário (Passo 5).
Algoritmo 1 Metodologia VSF

1: function VSF(∆VC , ∆QG , JQV )
2: i ← max(∆VC )
−1
3: S ← JQV
4: j ← max(S[· · · , i])
−1
5: ∆VGj ← JQV ∆QG
6: return ∆VGj
7: end function
Os índices de sensibilidade são valores adimensionais que indicam o quanto a

variação da injeção da potência reativa em uma determinada barra de controle altera as
magnitudes de tensão nas barras controladas. Assim, a metodologia VSF seleciona a barra
j para realizar o despacho adicional de potência reativa, cujo índice de sensibilidade é o
maior relacionado a barra de carga i, que contém a violação de tensão mais significativa.
Apresenta-se agora o funcionamento da abordagem proposta no Algoritmo 3. A
princípio, são determinadas as violações de tensão para todas as barras de carga i (Passos 1
a 3). Em seguida, é calculada a variação de potência reativa das barras de geração (∆QG )
(Passo 4). A metodologia de controle é executada (Passo 5) e, por fim, as magnitudes de
tensão de cada uma das Nρ barras de controle (Passos 6 a 8) são ajustadas.
Algoritmo 2 Funcionamento da Abordagem

1: for i ← 1 until NP Q do . Para todas as barras de carga.
2: ∆VC [i] ← |Vi − Vlim.viol. |
3: end for
4: ∆QG ← JQV ∆VC
5: ∆VG ← VSF(∆VC , ∆Q, JQV )
6: for n ← 1 until Nρ do . Para todas as barras de controle a serem ajustadas.
7: VGj [n] ← VGj [n] + ∆VGj [n]
8: end for
537
2.2. Nós de Controle

Os Nós de Controle atuam diretamente nas barras de controle do sistema. Sua tarefa é
determinada pelo Gestor de Controle, que aplica a metodologia de controle, repassando
a sequência de ajustes a ser realizada. Então, os Nós de Controle processam os ajustes,
efetuando as modificações no despacho de potência reativa.
3. Resultados e Discussões
Nesta seção são apresentados os resultados da aplicações da abordagem proposta. Para
avaliá-la é apresentado um cenário de teste com violação da magnitude de tensão. A deter-
minação desse cenário é feita por meio de alterações nas magnitudes de tensão das barras
de controle e/ou modificando-se o carregamento do sistema. Simulações computacionais
são realizadas no sistema IEEE de 57 barras, que representa uma porção do sistema elé-
trico localizado na Região Centro-Oeste dos Estados Unidos [IEEE 1993] e caracterizado
pelo conjunto de barras de controle G = {1, 2, 3, 6, 8, 9, 12}.
A Tabela 1 apresenta os valores (Vk (p.u.), θk (graus), Pk (M W ), Qk (M V ar))
que caracterizam o estado das barras dos sistema, além disso são considerados ativos
todos os taps fixos do sistema. Na Tabela 1 são exibidas apenas as barras que foram
alteradas para se obter as violações de tensão.
Tabela 1. Dados do Cenário de Teste.

Barra (k) Vk Pk Pk Qk Qk
2 1,01364902 3,00000 88,00000 0,00000 -17,00000
3 1,00000000 41,00000 21,00000 40,00000 59,61454
6 0,98305469 75,00000 2,00000 0,00000 25,00000
8 1,00000000 150,00000 22,00000 450,00000 64,74825
9 0,97227140 121,00000 26,00000 0,00000 9,00000
12 1,00000000 377,00000 24,00000 310,00000 112,26267
19 0,98207031 0,00000 0,00000 0,00000 0,00000
20 0,96398089 2,30000 0,20000 0,00000 0,00000
30 0,96869163 3,60000 1,20000 0,00000 0,00000
31 0,94621160 5,80000 1,80000 0,00000 0,00000
45 1,02867853 7,10000 4,40000 0,00000 0,00000
46 1,04840830 7,10000 4,40000 0,00000 0,00000
47 1,02147894 29,70000 13,60000 0,00000 0,00000
3.1. Correção Executada pela Metodologia VSF

No cenário de teste, as barras 31 e 46 possuem violações de tensão. Inicialmente, apenas
a barra 31 possui violação (V31 = 0, 94621) e a metodologia usa a coluna 31 da matriz
−1
JQV (Ajuste 1) para determinar a barra de controle j. Posteriormente a barra 31 possui o
valor da magnitude de tensão dentro dos limites desejados e a barra 46 passa a apresentar
−1
violação de tensão (V46 = 1, 05081), então a coluna 46 da matriz JQV é aplicada para
determinar o Ajuste 2. Finalmente, a coluna 31, em virtude desta barra se encontrar em
subtensão (V31 = 0, 94720), é utilizada para determinação do último ajuste.
A Tabela 2 exibe os índices de sensibilidade das barras de controle aplicados pela
metodologia VSF. Os índices associados as barras 2, 6 e 9 não são exibidos pois estas
violaram seus limites de geração de potência reativa e foram transformadas em barras de
carga, ficando impossibilitadas de corrigir o sistema.
No passo de ajuste 1, a barra 8 possui o maior índice (−0, 078759151) e
a metodologia define que o valor da sua magnitude de tensão deve ser alterado
538
(V81 = 1, 01143 p.u.). Então, o Gestor de Controle transmite o ajuste ao Nó de Controle

conectado a barra 8 para execução da modificação. Em seguida, o Gestor de Controle
resolve novamente o Fluxo de Carga, determina o novo estado do sistema e detecta que a
barra 46 violou seu limite superior. Então a metodologia VSF seleciona a barra 12 (com
índice igual a −0, 032605727) para corrigir a violação de tensão e o Gestor de Controle
transmite o ajuste ao Nó de Controle conectado a barra 12, que tem sua magnitude de
tensão decrementada (V122 = 0, 98953 p.u.) para absorver potência reativa. Mais uma vez
o Gestor de Controle resolve o Fluxo de Carga e determina que a magnitude de tensão
da barra 31 está abaixo do limite inferior, assim a metodologia VSF seleciona outra vez
a barra 8 (cujo índice de sensibilidade é −0, 026210187) para corrigir o sistema. Outra
transmissão é realizada com destino ao Nó de Controle conectado a barra 8 e sua magni-
tude de tensão é alterada (V83 = 1, 02155 p.u.).
Tabela 2. Índice de Sensibilidade das Barras de Controle por Passo de Ajuste.

Barra (k) Ajuste 1 Ajuste 2 Ajuste 3
1 -0,080429836 -0,032687758 -0,026982970
3 -0,081454988 -0,033464270 -0,027320152
8 -0,078759151 -0,033996472 -0,026210187
12 -0,079925820 -0,032605727 -0,026905303
A Tabela 3 exibe o Estado Final do Sistema após a execução das sequência de

ajustes e com todas as magnitudes de tensão dentro dos limites adequados de funciona-
mento.
Tabela 3. Estado do Sistema após Execução da Sequência de Ajustes.

2 1,01364456 3,00000 88,00000 0,00000 -17,00000
3 1,00000000 41,00000 21,00000 40,00000 59,61454
6 0,98305469 75,00000 2,00000 0,00000 25,00000
8 1,00000000 150,00000 22,00000 450,00000 64,74825
9 0,98162506 121,00000 26,00000 0,00000 9,00000
12 0,98952845 377,00000 24,00000 310,00000 74,69925
19 0,98516340 0,00000 0,00000 0,00000 0,00000
20 0,96662544 2,30000 0,20000 0,00000 0,00000
30 0,97528248 3,60000 1,20000 0,00000 0,00000
31 0,95193149 5,80000 1,80000 0,00000 0,00000
45 1,02891909 7,10000 4,40000 0,00000 0,00000
46 1,04833020 7,10000 4,40000 0,00000 0,00000
47 1,02191795 29,70000 13,60000 0,00000 0,00000
Por fim, o despacho de potência reativa nas barras de controle, após a execução dos
ajustes definidos pela metodologia VSF para corrigir a violação de tensão nas barras 31 e
46, é apresentado na Tabela 4. Os ajustes são executados nas barras 8 e 12, que possuem
os maiores índices de sensibilidade com relação as barras 31 e 36, respectivamente. A
barra 8 injeta potência reativa para corrigir a magnitude de tensão da barra 31, enquanto
a barra 12 absorve potência reativa para corrigir a violação de tensão da barra 46.
539
Tabela 4. Geração de Potência Reativa das Barras de Controle para a metodolo-

gia VSF.
Barra (k) Ajuste 0 Ajuste 1 Ajuste 2 Ajuste 3
1 141.88571 140.64789 150.69291 149.58736
3 59.61454 51.96587 56.84640 50.08991
8 64.74825 80.42069 87.97524 102.26601
12 112.26267 103.75421 82.13593 74.69925
3.2. Perdas de Potência Ativa

As perdas de potência ativa, à medida que os despachos de potência reativa foram exe-
cutados, são ilustradas na Figura 1. A metodologia VSF, executa dois ajustes na barra
8 e um ajuste na barra 12 para corrigir a violação de tensão e reduz a perda de potência
de 28,16 M W para 27,88 M W . Para tal cenário, é possível concluir que os índices de
sensibilidade foram capazes de definir uma sequência de ajustes para corrigir as violações
de tensão e reduzir a perda de potência ativa.
Perda de Potência Ativa (MW)
28.1
28
27.9
27.8
0 1 2 3
Passo
Sequência de Ajustes
Figura 1. Perdas de Potência Ativa em Função dos Ajustes.
4. Conclusões e Trabalhos Futuros

O objetivo principal deste trabalho consiste em definir uma sequência de ajustes, no des-
pacho de potência reativa, para corrigir as violações nas magnitudes de tensão das barras
de carga de um sistema de transmissão de energia elétrica. Para a correção das violações
de magnitude de tensão a proposta é uma abordagem formada por dois componentes:
Gestor de Controle e os Nós de Controle. Os ajustes são definidos pela metodologia de
controle VSF que utiliza a matriz JQV para escolher as barras de controle a serem opera-
das.
A metodologia VSF escolhe a barra de geração que produzirá a maior variação no
valor da magnitude de tensão de uma barra a ser controlada com base nos índices de sen-
sibilidade. Os resultados demonstram que as correções definidas pela metodologia VSF
conduzem o sistema a um estado sem violações de tensão em que as perdas de potência
ativa são menores. Como trabalhos futuros é considerado primordial a incorporação de
outras formas de controle, como a determinação de chaveamentos em bancos de capaci-
tores e reatores e/ou comutação de taps de transformadores em fase.
Referências
Calderaro, V., Galdi, V., Lamberti, F., and Piccolo, A. (2015). A smart strategy for vol-
tage control ancillary service in distribution networks. IEEE Transactions on Power
Systems, 30(1):494–502.
540
Eremia, M. and Shahidehpour, M. (2013). Handbook of electrical power system dyna-

mics: modeling, stability, and control, volume 92. John Wiley & Sons.
IEEE (1993). 57 bus power flow test case.
Kundur, P., Paserba, J., Ajjarapu, V., Andersson, G., Bose, A., Canizares, C., Hatziargy-
riou, N., Hill, D., Stankovic, A., Taylor, C., et al. (2004). Definition and classification
of power system stability IEEE/CIGRE joint task force on stability terms and definiti-
ons. IEEE Transactions on Power Systems, 19(3):1387–1401.
Lage, G. G., Fernandes, R. A., and da Costa, G. R. (2013). Functional approximation of
power system steady-state voltage stability limits by artificial neural networks. Journal
of Control, Automation and Electrical Systems, 24(4):544–554.
Löf, P., Smed, T., Andersson, G., and Hill, D. (1992). Fast calculation of a voltage stability
index. IEEE Transactions on Power Systems, 7(1):54–64.
Loia, V., Vaccaro, A., and Vaisakh, K. (2013). A self-organizing architecture based on co-
operative fuzzy agents for smart grid voltage control. IEEE Transactions on Industrial
Informatics, 9(3):1415–1422.
Momoh, J. (2012). Smart grid: fundamentals of design and analysis, volume 63. John
Wiley & Sons.
Robitzky, L., Muller, S. C., Hager, U., and Rehtanz, C. (2015). Evaluating the perfor-
mance of decentralized analyses of voltage stability and power flows. In 2015 IEEE
Eindhoven PowerTech, pages 1–6. IEEE.
Silva, T., Rabêlo, R., Barbosa, D., Fernades, R., and Lage, G. (2015). Infraestrutura
de comunicação baseada em sdn-dwdm para redes de transmissão de energia elétrica
inteligentes. Simpósio Brasileiro de Automação Inteligente, 12(6):1182–1187.
541
Avaliação do Padrão IEEE 802.15.4 para Redes Veiculares

com Testes Embasados na RFC 2544
Leonardo A. G. Silva, Jaqueline C. Sousa, Diego F. Sousa, Pablo A. Vieira 1
1
Universidade Federal do Piauı́ (UFPI) - Picos, PI - Brasil.
(leosilvadrums100, diegofernando5672)@gmail.com
Abstract. Vehicular Ad Hoc Networks (VANETs) are self-generating networks

responsible for the delivery of packets using as vehicles. Research aimed at the
development and standardization of technology is finding it difficult to acquire
specialized radio because of high cost and scarcity factors. The objective of
this work is to evaluate the IEEE 802.15.4 standard of the ZigBee modules as
an alternative to the usual IEEE 802.11p standard, verifying if the standard
meets the minimum requirements, such as: fast connection in textit ad-hoc,
textit broadcast and reach 50 meters of link to the nodes. Applications were
developed allowing an interface with the proposed standard, making it possible
to analyze the usability for future traffic applications. The results showed that
the model of the present study had a considerable frame delivery rate. However,
there was a certain degradation of the network in the delivery of packages at
high speeds in the V2I infrastructure (Vehicle-to-Infrastructure).
Resumo. As Redes Veiculares Ad hoc (Vehicular Ad hoc Networks-VANETs)

são redes autogeradoras responsáveis pela entrega de pacotes usando como
meio veiculos. As pesquisas destinadas ao desenvolvimento e padronização da
tecnologia sofrem dificuldade na aquisição do rádio especializado por fatores
de alto custo e da escassez. O objetivo deste trabalho é avaliar o padrão IEEE
802.15.4 dos módulos ZigBee como uma alternativa ao padrão usual IEEE
802.11p, verificando se o padrão atende aos requisitos mı́nimos, como: co-
nexão rápida em ad-hoc, broadcast permanente e alcance 50 metros de enlace
para os nós. Foram desenvolvidas aplicações permitindo uma interface com o
padrão proposto possibilitando analisar a usabilidade para futuras aplicações
voltadas ao trânsito. Os resultados apontaram que o modelo do presente es-
tudo teve uma taxa de entrega de quadros considerável. Porém houve uma certa
degradação da rede na entrega de pacotes em altas velocidades na infraestru-
tura V2I (Vehicle-to-Infrastructure).
1. Introdução
As Redes Móveis estão em crescimento no cenário mundial devido à procura a uma ampla
conexão de dados. Chamando a atenção das empresas e da comunidade cientıfica para o
estudo e desenvolvimento dessa tecnologia. Podemos citar como exemplos de tecnologias
originadas das Redes Móveis: Serviços de Telefonia Móvel, Localização GPS, Rede 3G
e 4G e também Redes Veiculares, entre outras [Rodrigues et al. 2015].
542
Com o avanço das pesquisas criou-se a Rede Móvel Ad Hoc (Mobile Ad Hoc
Network-MANETs) possibilitando haver uma infraestrutura não inteiramente fixa ocasio-
nando melhorias na acessibilidade e mobilidade [Sant’Ana 2014]. Oriunda das MANETs
derivou-se as Redes Veiculares Ad Hoc (Vehicular Ad Hoc Network-VANET). Elas são
redes autogeradoras responsáveis por sua própria infraestrutura e entrega de pacotes por
meio de veı́culos [Palmeira and dos Santos 2015].
O padrão IEEE 802.11p define a camada fı́sica conhecida como Dedicated Short-
Range Comunications (DSRC) que opera nos EUA em uma faixa exclusiva de 75 MHz.
Na Europa a faixa de frequência varia entre 5,860 GHz e 5.900 GHz, de acordo com a
especificação da European Telecommunications Standards Institute (ETSI), com divisão
de faixa de frequência em canais de 10 MHz [Barcelos et al. 2014].
As aplicações funcionais são quase inexistentes e os trabalhos que focam em testes
de campo são escassos por conta do alto custo da tecnologia e dificuldade ao seu acesso
[Costa 2015]. Tal fato levou ao surgimento de pesquisas paralelas (uma das motivações
do trabalho atual) para o desenvolvimento de tecnologias que podem se adaptar ao mesmo
desempenho e funcionalidades das tecnologias especı́ficas para as VANETs.
[Sukuvaara 2012] utilizou do padrão IEEE 802.11p para Redes veiculares execu-
tando testes práticos capazes de proporcionar comunicações V2I (Veı́culo-para-Veı́culo),
V2V (Veı́culo-para-Infraestrutura) e V2X (Hı́brido) de maneira eficiente com os dispo-
sitivos a rádio NEC Linkbird-MX. As métricas empregadas se propuseram a analisar
medições sobre o tempo de conexão e vazão dos veı́culos.
No trabalho de [Teixeira et al. 2013] foi feita outra análise no mesmo padrão,
porém com dispositivos UNEX DCMA-86P2 instaladas em dois notebooks. Os resul-
tados indicaram que o padrão IEEE 802.11p supriu a latência, jitter, vazão, taxa de perda
de pacotes e tempo de associação necessários para haver o QoS (Qualidade de Serviço,
em inglês, Quality of Service) mı́nimo.
Segundo [Barcelos et al. 2014] o dispositivo UNEX DCMA-86P2 é um dos
únicos no mercado que dão suporte ao padrão IEEE 802.11p. Para sobressair ao custo
elevado, ele utilizou os dispositivos NEC Linkbird-MX para avaliar o padrão. Os resul-
tados do seu trabalho mostraram que a taxa de perda de pacotes manteve-se instável em
distâncias curtas com atraso inferior a 100 ms e com velocidades razoavelmente altas.
Em outro trabalho mais recente, [Sarakis et al. 2016] também utiliza dispositivos
NEC Linkbird-MX para uma avaliação em transmissão multimı́dia entre veı́culos. As
transmissões foram feitas com vı́deos e velocidades diferentes em ambientes distintos.
Como conclusão os resultados se mostraram aceitáveis com a configuração adequada,
manipulação da comunicação disponı́vel e parâmetros de aplicação.
Atualmente no Brasil, o custo dos dispositivos que possuem suporte ao padrão
IEEE 802.11p continuam elevado, além de serem escassos e de difı́cil implantação nos
veı́culos, pois precisam de grandes recursos computacionais para serem instalados. O
presente trabalho pretende desenvolver um protótipo que possa sobressair aos altos custos
para realização de testes em campo.
Foram utilizados os módulos ZigBee no padrão IEEE 802.15.4 como uma alter-
nativa ao padrão IEEE 802.11p. Os resultados apontaram que os módulos Zigbee supor-
543
taram mais 50% na taxa de entrega de quadros para pequenas velocidades nas aplicações,
porém as taxa declinou para altas velocidades com cargas de trabalhos diferentes.
Este trabalho está organizado como descrito a seguir. A Seção 2 apresenta o Back-
ground, sobre aspectos das VANETs. Na Seção 3 são apresentados os Trabalhos Relaci-
onados. A Construção do Protótipo na Seção 4. Na Seção 5 Metodologia e Testes. As
avaliações são discutidas na Seção 6 e por fim na Seção 7 as conclusões são apresentadas.
2. Background
Há um conjunto de fatores ambientais e geográficos que podem influenciar na instalação
de qualquer tipo serviços de redes. [Kurose and Ross 2010]. Tratando das VANETs em
que os nós são dinâmicos a troca de informações depende muito da movimentação dos
mesmos para situações de contato para troca dos pacotes [Serrado et al. 2014].
Por fim a topologia da rede se torna inconstante e de difı́cil previsão, dificul-
tando um estudo prévio de rotas mais eficientes para que a comunicação à radio seja mais
confiável entre os nós. Podemos notar outros fatores como velocidade e distâncias dos
veı́culos que dificulta o contato mı́nimo para que ocorra o salto [Serrado et al. 2014].
2.1. Estrutura das VANETs

Existem três arquiteturas (V2V, V2I e V2X ) presentes nas Redes Veiculares, que possi-
bilitam diferentes tipos trocas de pacotes de acordo com a mobilidade dos nós. Na Figura
1 podemos visualizar a comunicação das arquiteturas.
Figura 1. Arquitetura de comunicação V2I, V2I e V2X, adaptação

[Alves et al. 2009]
A arquitetura primária é conhecida como V2V (Vehicle-to-Vehicle) em que os pa-

cotes são passados por saltos de veı́culo para veı́culo através de Unidades de Bordo (OBU-
On-Board Unit). Essa arquitetura tem a problemática de constante desconexões por ne-
cessitar de grande fluxo de veı́culos [Serrado et al. 2014].
Já a infraestrutura V2I (Vehicle-to-Infrastructure) procura resolver esse problema
com o foco em aumentar os contatos entre os nós. São instaladas Unidades de Acosta-
mento (RSUs - Road Side Unit ) ao longo das margens das malhas viárias dispondo de
transmissores como pontos de acesso (Access Points) [Filho et al. 2016].
544
Outro tipo de infraestrutura que as VANETs possuem é a V2X (Vehicle-to-Mean)

que tem por caracterı́stica unir as duas abordagens de arquiteturas anteriores (V2V e V2I).
Ela minimiza o alto custo que seria para instalar muitas RSUs nas vias (organização V2V),
pois a entrega ocorre também por saltos entre os nós OBUs [Barcelos et al. 2014].
2.2. Modelo WAVE e Padão IEEE 802.11p

Um grupo da pesquisa da IEEE deste o ano de 2004 vem juntando esforços para a
padronização e desenvolvimento das aplicações e tecnologias direcionadas às VANETs.
O padrão que vem sendo aprimorado é conhecido como famı́lia de padrões WAVE (Wi-
reless Access in the Vehicular Environment) e é definido em seis documentos: IEEE
P1609.1, IEEE P1609.2, IEEE P1609.3, IEEE P1609.4, IEEE 802.11 e IEEE 802.11p
[Soares et al. 2016].
Dentro desse padrão está o IEEE 802.11p que especifica a subcamada de Controle
de Acesso ao Meio (MAC) e múltiplas camadas Fı́sicas (PHYs). Ele é formado por dois
documentos, IEEE 802.11p-2010 e IEEE 802.11-2012, que posteriormente foram incor-
porados especificando conjunto de extensões para o IEEE 802.11-2012 operar fora de um
contexto de um conjunto de serviços básicos (BSS) [Alves et al. 2009].
Nesta seção, podemos analisar algumas caracterı́sticas acerca de trabalhos relacionados
no contexto das VANETs. A Tabela 1 apresenta os critérios analisados, confrontando suas
contribuições, diferenças e semelhanças com relação com presente trabalho.
Tabela 1. Trabalhos Relacionados

Envios com
Xbee Testes
Tamanhos
Trabalhos (Ano) Principais Contribuições (Padrão Embasados
Diferentes de
802.14.5) Na RFC 2455
Quadros
[Bhargav and Singhal 2013] Um Sistema de Emergência Resgates de Veı́culos Acidentados Sim Não Não
[Sant’Ana 2014] Uma Aplicação de Detecção de Colisão de Veı́culos Sim Não Não
[Karyemsetty et al. 2015] Sistema de monitoramento GPS em uma rede Zigbee Sim Não Não
Protótipo para Testes de Comunicação

[Shree et al. 2016] Sim Não Não
Entre Veı́culos com Zigbee em varios Cenários
Investigação do Comportamento do Padrão

Este Estudo (2017) IEEE 802.14.5 na Infraestrutura V2I Testando Sim Sim Sim
Quatros com Velocidades diferetnentes
No trabalho de [Bhargav and Singhal 2013] foi fornecida uma abordagem abran-
gente no desenvolvimento de um sistema de eficiente de missões de emergência para o
gerenciamento de resgates de veı́culos envolvidos em acidentes com meio do auxı́lio de
redes Ad-hoc Veiculares (VANETs). Os resultados mostram que os módulos ZigBee aten-
dem aos requisitos para a comunicação de carro para carro para transmissões multimı́dia.
O trabalho de [Sant’Ana 2014] é proposto o desenvolvimento uma aplicação de
detecção de veı́culos em possı́vel risco de colisão, com avisos para a resposta do usuário
para evitar acidentes. Foram realizados testes em ambientes de diferentes caracterı́sticas
545
e densidades. O protótipo que utilizam módulos ZigBee atenderam as especificações para

aplicações voltadas para a segurança no trânsito com latência média de 60 ms.
Um sistema parecido com o anterior, é proposto no trabalho
[Karyemsetty et al. 2015], que utilizam os módulos ZigBee para o estabelecimento
de uma rede simples com cinco nós em veı́culos. Cada protótipo transmite as coor-
denadas GPS para um ponto infraestruturado para o rastreamento da movimentação
dos veı́culos. Os resultados mostraram que a rede tem uma certa degradação em altas
velocidades.
Já no trabalho de [Shree et al. 2016] é desenvolvido um protótipo para o estudo
do uso de redes Zigbee utilizando o padrão 802.15.4 em comunicações entre veı́culos.
Como nos trabalhos citados anteriormente os módulos ZigBee foram adotados por seus
recursos de baixo custo, baixo consumo de energia, controle e monitoramento de rede.
Os resultados justificam o uso dos módulos ZigBee para as comunicações em VANETs
em vários cenários de teste.
O trabalho proposto tem como principal diferencial a metodologia abordada nos
testes com o uso de algumas técnicas abordadas na RFC 2455, tais como envios de qua-
dros seguidos e tempo de espera entre eles. Nos demais trabalhos também não existem
alternância e envio de quadros com tamanhos diferentes. Porém o estudo atual tenta forçar
um workload (carga de trabaho) maior com envios de quadros distintos.
Em um contexto de comunicação veicular a forma mais ideal para a avaliação do
padrão sugerido seria análise combinatória na investigação do comportamento da rede do
padrão IEEE 802.14.5, pois a metodologia permite correlacionar parâmetros distintos a
nı́veis diferentes. Possibilitando um aperfeiçoamento na criação e no desenvolvimento de
novas métricas e técnicas de testes em VANETs.
4. Construção do Protótipo
Para a viabilização da comunicação via rádio das aplicações foram adotados comunica-
dores Zigbee da Digi XBee Ecosystem baseados no padrão IEEE 802.15.4. Os protótipos
desenvolvidos foram dois nós: um deles instalados em um veı́culo e o outro em um note-
book à margem da pista. Na figura 2 estão os protótipos.
Figura 2. Prototipo Onboard (Unidade de Bordo) a esquerda e Offboard (Unidade

Externa) a direita, montados com os Módulos XBees S2C ZigBee Wire Antenna.
A aplicação onboard (OBU) desenvolvida em Android conta com um dispositivo

celular conectado a um módulo Bluetooth RS232 HC-05 dispondo de interface ao Ar-
546
duino para a coleta para dos logs das mensagens. Na Aplicação offboard (RSU) está co-
nectado um módulo Xbee à uma entrada USB de um Notebook que executa um script se-
rial desenvolvido na linguagem Python. Ele é responsável por gravar o horário e conteúdo
das mensagens recebidas.
5. Testes e Metodologia
Para que seja feito um estudo estatı́stico sobre redes é necessário que se forneçam
parâmetros para a análise de métricas mais precisas. As métricas da RFC 2544 espe-
cificam testes que podem descrever as caracterı́sticas de desempenho em dispositivos de
redes e o formato correto em que os dados devem ser apresentados.
Foram enviados quadros de 32 bytes a 40 km/h e 80 km/h, 64 bytes a 40 km/k e
80 km/h e 84 bytes a 40 km/k e 80 km/h. As escolhas dos tamanhos dos quadros foram
embasadas na capacidade de transmissão da tecnologia. Pois a partir de 84 bytes é feita
a quebra e indexação de quadros em tamanhos menores. Na figura 3 está um compilado
com as fotos do ambiente de testes.
Figura 3. Ambiente dos Testes (A direita se encontra o mapa da pista de pouso

de aviões de pequeno porte da cidade de Oeiras-Piauı́. A esquerda está um com-
pilado de fotos dos testes)
Para cada nı́vel foram realizadas 6 voltas, enviando 5 pacotes com 3 segundos de
atraso entre eles, a fim de analisar envios de 30 quadros seguidos (amostra mı́nima para
a estatı́stica). Os quadros foram enviados com seu conteúdo e ID de saı́da do aparelho
celular entre um carro e uma infraestrutura, a uma distância inicial de 20 metros até 60
metros em uma pista de aproximadamente 120 metros. No final das baterias de testes
totalizou 36 voltas (6 nı́veis vezes 6 voltas) com envios de quadros de tamanhos distintos
a velocidades diferentes.
6. Avaliação
Nesta seção são discutidas as avaliações acerca dos resultados. A variável medida é a taxa
de entrega obtida através do número de pacotes encaminhados com sucesso na arquitetura
V2I em um contexto rodoviário. Nas Figuras 4, estão os gráficos de barras com as taxas
de entrega dos quadros de 32 bytes, 64 bytes e 84 bytes em velocidades de 40 km/h e 80
km/h.
547
Figura 4. Taxa de Entrega para os Quadros
O gráfico mostra o comportamento da rede para todas as velocidades testadas. Isso

indica que as métricas e técnicas utilizadas obtiveram um desempenho positivo na análise
do padrão submetido. Notamos que os resultados das taxas foram bastantes estáveis para
todos os nı́veis combinatórios. Nos envios de quadros com tamanho de 32 bytes em
velocidade a 40 km/h a taxa de entrega foi de aproximadamente 56% e de 30% para 80
km/h. Tal resultado foi igualmente obtido para quadros com 84 bytes. Já para os quadros
com 64 bytes se obteve uma pequena melhoria na taxa de 60% de entrega para 40 km/h e
de 36% para 80 km/h.
7. Conclusão
Podemos concluir que o padrão pode ser adotado para aplicações que trabalham em con-
texto veicular, porém há uma série de particularidades a serem analisadas para que pos-
sam ser implementado em âmbito real. Alguns desses questionamentos diz respeito a
que tipo de aplicação se adequaria às tecnologias usadas nos protótipos (onboard e offbo-
ard), e também como as tecnologias se comportam em conjunto. Através dos resultados
notamos que o padrão IEEE 802.15.4, em relação a envios de dados consecutivos em pe-
quenas velocidades, suprem de forma positiva as entregas e o tempo de conexão útil para
o enlace dos nós. Entretanto há uma certa degradação da rede em altas velocidades para
todas as combinações feitas. Nota-se que o padrão se comportou de forma estável mesmo
com o aumento dos tamanhos dos quadros. Isso denota que o padrão atende a envios de
quadros mesmo que seu workload seja aumentado gradualmente e que possı́veis colisões
são recuperadas e reenviadas. A degradação em altas velocidades pode ter sido causada
pelos buffers dos módulos Zigbee e pela transferência de dados do bluetooth utilizado na
aplicação onboard. Para trabalhos futuros estuda-se a possibilidade de fazer uma medição
acerca da latência e taxa de transferência média dos quadros tomando uso de um método
mais aprimorado em combinações como o DoE (Desing Of Experiment).
548
Referências
Alves, R. d. S., Campbell, I. d. V., Couto, R. d. S., Campista, M. E. M., Moraes, I. M.,
Rubinstein, M. G., Costa, L. H. M., Duarte, O. C. M., and Abdalla, M. (2009). Redes
veiculares: Princıpios, aplicaçoes e desafios. Minicursos do Simpósio Brasileiro de
Redes de Computadores, SBRC.
Barcelos, V. P., Amarante, T. C., Drury, C. D., and Correia, L. H. (2014). Sistema de mo-
nitoramento de veıculos usando dispositivos no padrao ieee 802.11 p. XXXII Simpósio
Brasileiro de Redes de Computadores ee Sistemas Distribuı́dos, SBRC, page 20.
Bhargav, K. K. and Singhal, R. (2013). Zigbee based vanets for accident rescue missions
in 3g wcdma networks. In Global Humanitarian Technology Conference: South Asia
Satellite (GHTC-SAS), 2013 IEEE, pages 310–313. IEEE.
Costa, L. A. G. (2015). Análise da utilização de agentes de software em redes veiculares
hı́bridas utilizando zigbee.
Filho, S. G. P., de Sousa, R. S., and Soares, A. C. (2016). Impacto do uso de rsus em um
protocolo de controle de congetionamento de tráfego baseado em redes veiculares.
Karyemsetty, N., Samatha, B., and Rao, K. H. (2015). Design and deployment of vehi-
cle tracking system in vanets using xbee pro: Prototype model. In Communication
Networks (ICCN), 2015 International Conference on, pages 97–100. IEEE.
Kurose, J. F. and Ross, K. W. (2010). Redes de computadores e a internet (preferencial-
mente a 5a edição).
Palmeira, P. C. and dos Santos, M. P. (2015). Survey em redes veiculares usando o mixim
sobre o omnet++. Interfaces Cientı́ficas-Exatas e Tecnológicas, 1(2):47–56.
Rodrigues, D. d. S., Faria, D. B., and Azevedo, J. P. d. A. (2015). Telefonia móvel.
Sant’Ana, A. R. (2014). Sistema de detecção de colisão entre veı́culos utilizando gps e
zigbee.
Sarakis, L., Orphanoudakis, T., Leligou, H. C., Voliotis, S., and Voulkidis, A. (2016).
Providing entertainment app lications in vanet environments. IEEE Wireless Commu-
nications, 23(1):30–37.
Serrado, R. P., Pedroza, A. d. C. P., de Almeida, H. L. S., and Boas, S. B. V. (2014).
Proposta de roteamento para redes veiculares tolerantes a atrasos.
Shree, K. L., Penubaku, L., and Nandihal, G. (2016). A novel approach of using security
enabled zigbee in vehicular communication. In Computational Intelligence and Com-
puting Research (ICCIC), 2016 IEEE International Conference on, pages 1–5. IEEE.
Soares, R., Galeno, S., and Soares, A. (2016). Simulação de redes veiculares.
Sukuvaara, T. (2012). Field measurements of ieee 802.11 p based vehicular networking
entity. In Ubiquitous and Future Networks (ICUFN), 2012 Fourth International Con-
ference on, pages 135–139. IEEE.
Teixeira, F., Silva, V., Leoni, J., Santos, G., Souza, A., Macedo, D., and Nogueira, J.
(2013). Análise experimental de redes veiculares utilizando o padrão ieee 802.11
p. Anais do V Simpósio Brasileiro de Computação Ubı́qua e Pervasiva (SBCUP),
page 10.
549
Avaliação de Usabilidade e Acessibilidade do Sistema de

Gerenciamento de Refeitórios do IFPI – Campus Floriano
Antônio Rodrigues de Araújo Costa Neto1, Carlos Eduardo Moreira Borges1,
Hugo Araújo Gonçalves1, Paulo Miranda Silva e Sousa1, Samuel de Araújo
Fonseca1, Rennê Stephany Ferreira dos Santos1
1
Instituto Federal de Educação, Ciência e Tecnologia do Piauí (IFPI) – Campus Floriano
{[email protected], [email protected], [email protected],
[email protected]}
Abstract. The verification of the usability and the accessibility of a
computational application has enormous notoriety in the use of a virtual
platform. In this perspective, numerous mechanisms to aid the evaluation of
interface performance exist in the digital market. In this article, the IFPI -
Campus Floriano Institutional Restaurant Access System (SARI) evaluation is
presented, through the results obtained through the SortSite and DaSilva
platforms, directed respectively to usability and accessibility analyzes,
providing the necessary solutions for Identified failures. The results of this
evaluation method were exposed, allowing the elaboration of a general list of
the deficiencies presented by the Web application of the educational
institution.
Resumo. A verificação da usabilidade e da acessibilidade de uma aplicação
computacional possui enorme notoriedade na utilização de uma plataforma
virtual. Em tal perspectiva, inúmeros mecanismos de auxílio à avaliação de
performance de interfaces existem no mercado digital. Neste artigo, é
apresentada a avaliação do Sistema de Acesso ao Restaurante Institucional
(SARI) do IFPI – Campus Floriano, mediante os resultados obtidos através
das plataformas SortSite e DaSilva, direcionadas, respectivamente, às análises
de usabilidade e acessibilidade, fornecendo as devidas soluções para as falhas
identificadas. Os resultados desse método de avaliação foram expostos,
possibilitando a elaboração de uma lista geral das deficiências apresentadas
pela aplicação Web da instituição educacional.
1. Introdução
No contexto geral, a internet hoje tem influenciado e facilitado a vida das pessoas,
porque vivemos num mundo de constante transformação aos mais diversos níveis,
políticos, social, econômico, educativo e tecnológico. Com esse meio é possível
explorar e trocar informações instantaneamente e aceder rapidamente a novas soluções
(SILVA, 2012).
Nesse contexto, quando se trata de criações para web e tecnologia em geral, é
550
fundamental lembrar da usabilidade. Usabilidade é o método que visa facilitar a

utilização de uma interface pelo usuário sem perder a interação de suas funcionalidades
com o sistema. Refere-se ao grau no qual o usuário consegue realizar uma tarefa. É
tornar “algo” utilizável e funcional, mais especificamente, refere-se à rapidez com que
os usuários podem aprender a usar alguma coisa e sua eficiência ao utilizá-la, sua
facilidade de aprendizado - facilidade de relembrar (NIELSEN; LORANGER, 2006).
Outra vertente do processo de desenvolvimento sites web é a acessibilidade.
“Acessibilidade na web consiste que cidadãos com algum tipo de deficiência (visual,
auditiva, física, fala, cognitiva e neurológica) possam utilizar, entender, contribuir,
interagir e navegar na Internet sem qualquer empecilho” (Shawn, 2005). Segundo
Façanha, Figueiredo e Félix (2017), é essencial a criação de soluções cada vez mais
interessantes na busca da inclusão daqueles com algum tipo de limitação, tornando seu
acesso à informação e aos meios de comunicação na rede virtual viável e autônomo.
Nessa perspectiva, a acessibilidade e a usabilidade são condições que garantem
a possibilidade, a facilidade e o uso eficiente, produtivo, satisfatório, útil e seguro para o
usuário do computador e destinatário da informação e do conhecimento disponibilizado
na rede. São, portanto, as condições de usabilidade e de acessibilidade que podem
assegurar que a informação disponibilizada na internet possa ser compreendida e
pesquisável por todos, pessoas com deficiências e não deficientes (IGNÁCIO;
CARVALHO, 2008).
Com isso, diversas ferramentas facilitam a identificação dessa usabilidade. Neste
artigo, foram utilizados os mecanismos de análise de desempenho SortSite e DaSilva
para verificar, respectivamente, a usabilidade e a acessibilidade do Sistema de Acesso
ao Restaurante Institucional (SARI), do Instituto Federal de Educação, Ciência e
Tecnologia do Piauí (IFPI) - Campus Floriano. Após o uso dessas plataformas, foi
realizado uma exposição geral dos erros de usabilidade detectados, para que seja
realizado o levantamento das principais falhas. Com isso, nas seções seguintes do
estudo, serão expostos as especificações da ferramenta análise utilizada e estudo de
caso, com os resultados de tais testes, os erros encontrados e as possíveis sugestões de
correção.
2. Aplicação SortSite
Durante o processo de avaliação da usabilidade da aplicação web SARI, foi utilizada a
plataforma de análise SortSite. Tal ferramenta verifica as falhas e os aspectos negativos
que, de alguma forma, prejudicam a experiência virtual do usuário. Não obstante, os
métodos de verificação utilizados são coerentes com os maiores padrões de
direcionamento da programação web no mundo. No processo de análise de desempenho
do SARI, foi utilizada a vertente para desktop, dentro do período de testagem gratuita.
Na página inicial da SortSite (Figura 1), diversas instruções são repassadas ao
usuário para que o processo de análise seja executado da maneira correta. Após a
inserção do site a ser verificado, a aplicação realiza, segundo a empresa desenvolvedora,
inúmeros testes de qualidade e desempenho, coerentes com as diretrizes estabelecidas
551
pela WCGA, Seção 508, W3C e Usability.gov, maiores agências e consórcios de

orientação tecnológica da web.
Figura 1 – Página inicial da aplicação de análise SortSite

Os testes realizados pela SortSite verificam a existência de problemas que
prejudicam a usabilidade da interface, a acessibilidade do usuário, a compatibilidade
entre os navegadores e dispositivos web e a validação nos modelos HTML, XHTML e
CSS. Além disso, o software analisa a ocorrência de links quebrados, a ausência de
imagens, erros de script e de ortografia, falhas na certificação SSL e do vencimento das
licenças dos domínios. A adequação da página web às especificações dos mecanismos
de buscas, a velocidade da navegação e as regras de privacidade também são
devidamente constatadas pela aplicação.
3. A plataforma DaSilva1
Por outro lado, durante o processo de verificação da acessibilidade do SARI, utilizou-se
a plataforma online DaSilva. Sendo o primeiro avaliador de acessibilidade de sites em
língua portuguesa, ela é uma ferramenta desenvolvida pela Acessibilidade Brasil em
parceria com a empresa W2B Soluções Internet. A avaliação do mecanismo consiste
nos princípios de acessibilidade estabelecidos pelo W3C/WAI2 (WCAG1 e WCAG2) e
pelo documento E-mag, desenvolvido pelo governo eletrônico brasileiro em parceria
com a Acessibilidade Brasil, possibilitando a análise das discrepâncias de todas as
páginas do site.
1
Disponível em: http://www.dasilva.org.br/.
2
As recomendações contidas no W3C explicam como tornar o conteúdo web acessível a pessoas com
deficiências. Destinam-se a todos os criadores de conteúdo web (autores de páginas e projetistas de sites)
e aos programadores de ferramentas para criação de conteúdo.
552
4. Estudo de Caso
O presente estudo de caso foi desenvolvido para verificar a eficácia da ferramenta
SortSite no que diz respeito ao processo de identificação dos problemas de usabilidade e
acessibilidade de interfaces da WEB. Para isso, foram realizadas as avaliações de
usabilidade e acessibilidade na aplicação SARI (Figura 2). Tal aplicação web – também
adaptada para dispositivos móveis - é utilizada como instrumento online para controle e
registro da manipulação – compra, venda, reserva e retirada - dos tickets de
alimentação, necessários para acesso dos alunos e servidores ao restaurante.
Figura 2 – Página inicial do SARI
4.1 Resultados da avaliação de usabilidade

Na avaliação de usabilidade, realizada no software SortSite, após o processo de
verificação, foi gerado os resultados finais da verificação (Figura 3).
553
Figura 3 –Relatório de avaliação de usabilidade do SARI utilizando a ferramenta

SortSite
Tal relatório demonstra as questões gerais de usabilidade, indicando problemas
de navegação para os usuários da aplicação SARI. Nesse aspecto, a ferramenta destaca
que algumas páginas violam não só as orientações fornecidas pela Usability.gov, norma
que fornece uma visão geral do processo de design centrado no usuário, como também
as instruções da W3C (World Wide Web Consortium), principal organização de
padronização da rede mundial de computadores. Além disso, o relatório elenca os
problemas em níveis de prioridade, que são classificados de maneira hierárquica,
iniciando em 1 (urgentes) e terminando em 4 (menos relevantes).
No primeiro nível de prioridade, verificou-se que o rótulo de alguns botões não
indica claramente a ação que será aplicada quando o botão for clicado. Etiquetas de
botões comuns incluem atualizar, enviar, cancelar, entrar, voltar para página inicial,
próximo, anterior, entre outros. Além do mais, a aplicação não permite aos utilizadores
ascender à página inicial a partir de qualquer outra página no site, dificultando o acesso
e desrespeitando as normas da Usability.gov.
No segundo nível de prioridade, observou-se que o botão "Voltar" está
indisponível quando os links que abrem novas janelas no navegador foram clicados. A
desativação dessa função é confusa e frustrante para os usuários, e pode impactar
negativamente na satisfação dos utilizadores e na conclusão da tarefa. Além disso, as
URLs do site contêm mais de 78 caracteres, o que pode ocasionar a quebra quando
enviado por e-mail. Por fim, o site não cria um título descritivo, único e conciso para
cada página da web. Nesse âmbito, os títulos são usados pelos motores de busca para
identificar páginas. Se duas ou mais páginas têm o mesmo título, elas não podem ser
diferenciados pelos utilizadores ou pelos recursos "Favoritos" do navegador. Caso os
usuários marcassem uma página, não precisariam ter que editar o título para atender às
características mencionadas acima.
No terceiro nível de prioridade, verificou-se que não existe agrupamento de
opções dentro de um elemento quando uma lista suspensa tem mais de 10 itens. Com
isso, o usuário terá dificuldade para selecionar o que deseja utilizar no sistema.
No quarto nível de prioridade, identificou-se que um botão de rádio em um
grupo de botões de rádio não está sempre selecionado. Nesse caso, os usuários podem
optar por não ativar qualquer uma das opções disponibilizadas nos botões, e com isso,
554
proporcionar uma escolha rotulada com 'Nenhum', ocasionando um possível problema

em campos que não podem ser nulos.
A realização desse estudo de caso permitiu observar a eficácia da ferramenta
SortSite na identificação dos problemas de usabilidade da aplicação web SARI. A
ferramenta, em geral, possibilitou o detalhamento em relação às normas, o que torna
mais fácil o entendimento das causas pela qual o site deve seguir as regras
estabelecidas.
4.2 Resultados da avaliação de acessibilidade
No processo de avaliação da acessibilidade da plataforma SARI, a plataforma
DaSilva exibe o seguinte relatório como resultado da verificação, apresentado na Figura
4. Seguindo as diretrizes básicas de programação para a web, a conclusão da avaliação
divide o resultado em três prioridades, expondo os erros e avisos. Essas prioridades são
pontos da aplicação que os desenvolvedores web podem satisfazer. Caso contrário,
pessoas com determinadas deficiências poderão encontrar dificuldades em acessar as
informações presentes no site.
Figura 4 – Relatório da avaliação da acessibilidade

A satisfação da Prioridade 1 é um requisito básico para que determinados grupos
possam acessar documentos disponíveis na Web. Diversos os erros foram encontrados
nessa diretriz, mas serão comentados e registrados neste artigo apenas as falhas mais
frequentes e importantes. A primeira está relacionada ao conteúdo não-textual da
página. Tais informações não apresentam descrição, dificultando o entendimento das
pessoas com deficiência. Por exemplo, uma pessoa que não consegue visualizar uma
imagem pode entender o conteúdo visual através de uma explicação oral da figura.
Além disso, existem erros referente às informações e relações. Nesse sentido, o site não
deixa explicito o que é título, link e parágrafo, deixando de diferenciá-los em tamanho,
cor e fonte. O SARI ainda apresente deficiência no processo de utilização de suas
funcionalidades. Nesse sentido, não é possível executar todas as utilidades do site
dependendo apenas do teclado, pois em algumas interfaces o operador depende única e
exclusivamente do mouse. Isso é um obstáculo para pessoas sem visão já que para usar
o mouse é preciso sempre está acompanhando o cursor. Por fim, em relação à
modificação no conteúdo, o site não apresenta nenhum aviso prévio quando mudamos
de tela ou abrimos novas guias.
555
Além do mais, a Prioridade 2 significa a remoção de barreiras significativas ao

acesso a documentos disponíveis na Web. O erro encontrado relacionado a esse assunto
faz referência à Identificação Consistente dos elementos do site. Assim, componentes
que possuem a mesma funcionalidade são apresentados de diferentes formas aos
usuários. Com isso, pessoas com limitações cognitivas podem ter dificuldade para
utilizar o site.
A Prioridade 3 têm a função de melhorar o acesso a documentos armazenados na
Web. Nesse quesito, o SARI se saiu muito bem, não sendo encontrado nenhum erro em
relação a essa propriedade.
5. Conclusão
O desempenho de interfaces computacionais possui papel crucial no sucesso de uma
aplicação web. Em tal âmbito, neste artigo, foi demonstrada a análise de usabilidade e
acessibilidade da plataforma online SARI do IFPI – Campus Floriano através dos testes
realizados, respectivamente, pelos mecanismos de verificação SortSite e DaSilva. Os
resultados permitiram identificar as deficiências estruturais, gráficas e funcionais que
prejudicam a interação entre o SARI e os usuários. A avaliação foi baseada nos
parâmetros, consórcios e organizações que regulamentam a programação para a web.
Durante o processo de verificação, o SARI foi exposto a diversos testes de
usabilidade e acessibilidade, oriundos das ferramentas de análise utilizadas no estudo.
Os resultados individuais foram apresentados e organizados em um panorama geral que
representa as principais as falhas da plataforma institucional. Dessa forma, tais erros
podem ser agrupados em duas vertentes: na usabilidade, constatou-se que a rotulação
dos botões não apresenta a função executada, a indisponibilidade do botão “voltar” em
algumas interfaces, o alongamento demasiado das URLs, os títulos inconsistentes das
páginas e as deficiências dos botões de rádio do sistema; na acessibilidade, verificou-se
a ausência de descrição dos componentes do site, a utilização em grande parte através
somente do mouse e a inconsistência de apresentação dos elementos de mesma
funcionalidade do SARI.
A partir desse momento, os problemas evidenciados serão transmitidos ao Setor
de Tecnologia da Informação do IFPI – Campus Floriano para que sejam realizadas as
devidas alterações computacionais a fim de reparar ou diminuir os erros de usabilidade
e acessibilidade detectados. Não obstante, as sugestões de correção, originárias dos
instrumentos de análise, também serão apresentadas à repartição competente visando
auxiliar no processo de aprimoramento do SARI.
Dessa forma, sugere-se ao Setor de TI da Instituição que promova um canal de
comunicação direto com os usuários da plataforma. Essa espécie de ouvidoria
possibilitará um feedback mais rápido e ágil dos estudantes e servidores que utilizam o
restaurante institucional, favorecendo o aperfeiçoamento constante da aplicação web e a
melhoria dos serviços alimentícios.
556
Referências
FAÇANHA, Agebson Rocha; FIGUEIREDO, Renato Busatto; FÉLIX, Phyllipe do
Carmo. Procedimentos para a análise de acessibilidade de sites. Disponível em:
<http://www.infobrasil.inf.br/userfiles/Procedimentos para a análise de
acessibilidade de sites.pdf>. Acesso em: 16 jan. 2017.
GNÁCIO, Edilson Antonio; CARVALHO, José Oscar Fontanini de. Avaliação da
acessibilidade de sites oficiais de pesquisa no Brasil por pessoas com deficiência.
Encontros Bibli: revista eletrônica de biblioteconomia e ciência da informação, [s.l.],
v. 13, n. 26, p.131-146, 24 out. 2008. Universidade Federal de Santa Catarina
(UFSC). http://dx.doi.org/10.5007/1518-2924.2008v13n26p131.
IFPI – CAMPUS FLORIANO. SARI – Sistema de Acesso ao Restaurante
Institucional. Disponível em: <http://www.floriano.ifpi.edu.br/sari/>. Acesso em: 09
set. 2016.
NIELSEN, Jakob. LORANGER, Hoa. Projetando Websites. Traduzido por Edson
Furmankiewicz & Carlos Schafranski. Rio de Janeiro: Campus, 2006. Tradução de:
Prioritizing web usability.
POWERMAPPER. Website Error Checker: Accesibility & Link Checker -
SortSite. Disponível em: <http://www.powermapper.com/products/sortsite/>.
Acesso em: 09 set. 2016.
SHAWN L.H, and participants of the education and Outreach Working Group (EOWG)
(2005) “Introduction to Web Accessibility”. Disponível em: . Acesso em: 16 jan
2017.
SILVA, Maria Luciana da. A INTERNET E SUAS FACILIDADES. 2012.
Disponível em: <http://terceiroperiododehistoria.blogspot.com.br/2012/06/internet-e-
suas-facilidades.html>. Acesso em: 09 set. 2016.
SILVEIRA, Diego Santana; NUNES, Maria Augusta Silveira Netto. AVUSABILITY:
UMA APLICAÇÃO PARA APOIAR A AVALIAÇÃO DE USABILIDADE DE
INTERFACES DA WEB. Geintec, São Cristovão, v. 3, n. 5, p.251-260, jan. 2013.
SOUSA, Felipe Franco de; OSÓRIO, Marcos Coimbra; ANDRADE, Edméia L. P. de.
Proposta de avaliação de acessibilidade em sites por deficientes visuais.
Disponível em:
<http://www.aedb.br/seget/arquivos/artigos08/407_ArtigoFINAL_Alterado.pdf>.
Acesso em: 16 jan. 2017.
557
Desenvolvimento de aplicativo móvel para diagnosticar

anemia em pequenos ruminantes
Tadeu dos S. Jerônimo
Instituto Federal de Educação, Ciência e Tecnologia do Ceará – Sobral – CE – Brasil

[email protected]
Resumo. Este artigo apresenta um projeto de pesquisa em andamento sobre o

desenvolvimento de um aplicativo móvel para diagnosticar anemia em
pequenos ruminantes (cabras1 e ovelhas2), baseado no método FAMACHA.
Metodologia que propõe a comparação da cor da mucosa ocular do animal
com um cartão ilustrativo contendo cinco graus de anemia, onde um operador
compara o olho do animal com a cor do cartão e gera uma indicação para o
grau de anemia do animal, sem a necessidade de testes laboratoriais. Nesse
sentido, essa pesquisa busca desenvolver um aplicativo, onde o operador só
precisa de uma foto do olho animal, capturado através de um dispositivo
móvel, para diagnosticar o grau de anemia do pequeno ruminante.
Abstract. This paper presents an ongoing research project about the

development of a mobile app to diagnose anemia in small ruminants (goats
and sheep), based on FAMACHA method. Methodology that proposes the
comparison of the color of the ocular mucosa of the animal with an
illustrative card containing five degrees of anemia, where an operator
compares the eye of the animal to the color of the card and generates an
indication for the degree anemia of animal, without the need for laboratory
tests. In this sense, this research seeks to develop an app, where the operator
only needs a photo of the animal eye, captured through a mobile device, to
diagnose the degree of anemia of the small ruminant.
1. Introdução
O interesse pela exploração da caprinovinocultura vem aumentando gradativamente nos
países desenvolvidos, onde o uso de tecnologias, com o objetivo de aumentar a
produtividade já é significativo [Vieira 2006]. No entanto, as enfermidades parasitárias
causadas por nematódeos gastrintestinais estão presentes nos rebanhos em todo mundo,
causando sérios prejuízos econômicos aos produtores [Lima 2007].
Um dos principais responsáveis pelas parasitoses gastrintestinais, que afetam a
produtividade do rebanho, é o nematódeo Haemonchus contortus (HC), que se destaca
em mais de 80% dos casos. O controle de verminose em caprinos e ovinos é geralmente
realizado com o uso de anti-helmínticos na vermifugação do rebanho, porém, o uso
indiscriminado dessas drogas por parte dos produtores, pode tornar o rebanho resistente
a produtos antiparasitários do HC [Vieira 2006].
1
Caprinos são mamíferos da espécie Capra aegagrus hircus (bodes, cabras e cabritos).
2
Ovinos são mamíferos da espécie Ovis aries (ovelhas, carneiros e borregos).
558
Diante dessa realidade, na década de 90, foi desenvolvido por pesquisadores sul-
africanos o método FAMACHA (FAffa MAlan CHArt), cartão guia que tem como
objetivo identificar clinicamente animais que apresentem diferentes graus de anemia,
frente à infecção pelo HC. Possibilitando assim, o tratamento de forma seletiva, sem
necessidade de recorrer a exames laboratoriais, onde são vermifugados apenas os animais
que apresentam maior grau de anemia [Molento et al. 2004]. Apesar de a ferramenta ter
sido implementada com sucesso em vários países desde a sua criação, como qualquer
outro método, apresenta taxa de falhas que são atribuídas a fatores como luminosidade e
erro humano ao comparar a conjuntiva do animal ao cartão [Demoliner e Alves 2017].
Neste sentido, o objetivo desta pesquisa é desenvolver uma ferramenta
computacional alternativa ao método FAMACHA, que possibilite ao produtor uma
avaliação mais precisa com a utilização de dispositivos móveis. Isto, através de aplicativo
que a partir da captura de uma foto do olho do animal, seja capaz diagnosticar
automaticamente o grau de anemia do pequeno ruminante, com o emprego de redes
neurais artificiais.
2. Referencial Teórico
Diante dos avanços tecnológicos, cada vez mais é necessária à criação de processos que
auxiliem as pessoas na busca por resultados mais rápidos e precisos em suas atividades,
sejam na área da indústria, agropecuária, saúde, etc. Nesse contexto, a Visão
Computacional (VC) é uma área da ciência que vem avançando e auxiliando na evolução
e desempenho dos processos realizados pelo homem [Borth et al. 2014].
Sabe-se também que uma das áreas onde há constante estudo é a área de
Inteligência Computacional (IC), o que é de fácil verificação devido ao fato desta área
buscar modelar e reproduzir funções de um órgão vital e complexo do ser humano: o
cérebro [Zhang et al. 2013]. Aliado a esse campo de estudo está à área de
Processamento Digital de Imagens (PDI), onde também traz o desafio de reproduzir a
função dos olhos humanos [Almeida 2014].
Nesse sentido, acredita-se que a identificação do grau de anemia em caprinos e
ovinos por meio de dispositivos móveis, baseada no método FAMACHA, só é possível
de ser realizada automaticamente se forem combinadas técnicas que mesclam as áreas de
VC, IC e PDI, estas que envolvem várias outras subáreas multidisciplinares.
2.1. Método FAMACHA

O método FAMACHA (FMC) avalia a conjuntiva ocular do animal guiado por um
cartão que apresenta cinco níveis de coloração, a cada cor é relacionado um grau de
anemia. Onde o grau 5 indica que o animal está altamente parasitado, e,
consequentemente, com alto grau de anemia [Neves et al. 2008].
Foi desenvolvido na África do Sul para ovinos e para caprinos [Vieira 2006].
Onde de acordo com [Chagas, Carvalho e Molento 2007], se estabeleceu correlação
entre a coloração da conjuntiva ocular dos animais e os cinco intervalos de anemia
indicados pelo exame de sangue hematócrito (Tabela 1).
559
Tabela 1. Relação do grau Famacha com a coloração da conjuntiva

ocular e o hematócrito, orientando ou não o tratamento
Grau Famacha Coloração Hematócrito (%) Atitude clínica
1 vermelho robusto > 27 não tratar
2 vermelho rosado 23 a 27 não tratar
3 rosa 18 a 22 tratar
4 rosa pálido 13 a 17 tratar
5 branco < 13 tratar
Segundo [Chagas, Carvalho e Molento 2007], para a sua aplicação, o

examinador deve expor a conjuntiva do animal, pressionando a pálpebra superior com
um dedo polegar e abaixar a pálpebra inferior com o outro. O ideal é observar a
coloração na parte mediana da conjuntiva inferior, comparando-a com as cores do cartão
(Figura 1).
Figura 1. Cartão Famacha em formato reduzido para diagnóstico de anemia

clínica causada por Haemonchus contortus
Fonte: Adaptada de [Vieira 2006]
Quanto a vermifugação dos animais guiadas a partir do cartão, nos dois primeiros
graus (1 e 2) a coloração bem vermelha indica que os animais não apresentam traços de
anemia. A partir do grau 3 já é indicada a vermifugação. Nos graus seguintes (4 e 5) a
vermifugação é imprescindível, pois a mucosa apresenta palidez intensa. No último grau
é indicado a suplemento alimentar ao animal. [Chagas, Carvalho e Molento 2007].
2.2. Imagem Digital e Processamento de Imagens

De acordo com [Gonzalez and Woods 2007], uma Imagem Digital (ID) é definida como
uma função bidimensional de intensidade luminosa denotada por f(x,y), em que a
amplitude de f nas coordenadas espaciais (x,y) resulta no brilho da imagem naquele
ponto.
Sabe-se que os computadores não manipulam imagens contínuas, mas apenas
dados numéricos. Percebe-se, assim, a necessidade de uma representação vetorial em
duas dimensões (matricial) para imagens, em que a menor unidade desta representação é
chamada de pixel (picture element). Sendo assim, uma ID é descrita por uma matriz de
M x N valores de pixels, que indica o brilho em cada posição espacial da imagem
[Almeida 2014].
Quanto ao Processamento Digital de Imagens (PDI), Processamento de Imagem
Digital ou simplesmente Processamento de Imagens, existem várias definições para o
termo, que consiste teoricamente em receber uma imagem como entrada e retornar como
560
saída outra imagem modificado de acordo com filtros aplicados sobre a imagem de
origem, sejam eles de correções ou de outro fim desejado. Segundo os autores
[Marengoni e Stringhini 2009], “podemos dizer que processamento de imagens é um
processo onde a entrada do sistema é uma imagem e a saída é um conjunto de valores
numéricos, que podem ou não compor uma outra imagem”.
Existem diversos algoritmos, ferramentas e frameworks que permitem a
implementação do PDI através do computador. Onde se destaca o OpenCV, que é
gratuito e implementado na Linguagem C/C++ com portes para outras linguagens, como
por exemplo, Java (Android) e Python [Alves 2016].
2.3. Visão Computacional

Sistemas de Visão Computacional (VC) não se resumem a manipular imagens digitais.
Um sistema de VC pode ser definido como um sistema computadorizado capaz de
adquirir, processar e interpretar imagens correspondentes a cenas reais [Almeida 2014].
De acordo com [Gonzalez and Woods 2007], um sistema de VC pode ser
dividido em cinco etapas: 1) aquisição de imagens – é o primeiro passo, em que a
imagem digital é adquirida (normalmente através de câmeras); 2) pré-processamento –
tem por objetivo o melhoramento da imagem em função do que se deseja fazer com ela;
3) segmentação – segmentar uma imagem nada mais é do que extrair da cena partes de
interesse mediante a análise de suas características comuns; 4) representação e
descrição – logo após a etapa de segmentação, é necessário converter os dados (pixels)
em uma forma adequada ao processamento computacional e, em seguida, extrair
atributos que resultem em algum tipo de informação de interesse; e, 5) reconhecimento
e interpretação – a última etapa é o processo baseado nas informações fornecidas
previamente pelo seu descritor. A interpretação, normalmente, envolve o
reconhecimento de padrões já conhecidos a fim de compará-los com os resultados
obtidos e haver um posterior reconhecimento.
Dentre as etapas de um Sistema de VC, a etapa de reconhecimento e
interpretação tende a ser a última etapa e, por esse motivo, é a etapa mais dependente
dos processamentos realizados nas etapas anteriores. Em etapas anteriores se devem
obter parâmetros satisfatórios para descreverem as características da imagem do olho do
animal e, a partir desses parâmetros, ser possível uma correta classificação baseada em
alguma regra ou alguma técnica de IC, como as redes neurais.
2.4. Redes Neurais

As Redes Neurais Artificiais (RNAs) foram criadas inspiradas nas redes neurais
biológicas para tentar resolver uma série de problemas computacionais em áreas como:
reconhecimento e classificação de padrões, processamento de sinais, predição,
otimização, clustering, entre outras [Almeida 2014]. De acordo com [Alexandria 2005],
a técnica da computação neural é aprender a metodologia utilizada pelo cérebro humano
para solucionar problemas e aplicá-la aos sistemas computacionais.
Uma RNA é caracterizada por uma arquitetura, um método de aprendizado ou
treinamento, uma função de ativação e um bias. Segundo [Ramos 2003], o modelo de
RNAs mais utilizada ultimamente é o Perceptron de Múltiplas Camadas (MLP), treinadas
com o algoritmo retropropagação (backpropagation).
561
O aprendizado das RNAs pode ser na forma supervisionada ou não

supervisionada. Onde no primeiro existe um instrutor que orienta à rede a resposta
desejada para o padrão de entrada. Já no segundo não existe um agente externo e a rede
é ajustada de acordo com regularidades estatísticas dos dados de entrada e agrupamento
[Matsunaga 2012].
2.5. Trabalhos Relacionados

Em estudo semelhante realizado na Universidade do Oeste de Santa Catarina,
[Demoliner e Alves 2017] propuseram o Anemimetro, aplicativo que adota a escala de
cores proposta no cartão FMC. Onde foi utilizado o algoritmo Naive Bayes para análise
e classificação de imagens obtidas por smartphones com o sistema operacional Android.
Apesar da semelhança, esta pesquisa pretende avançar no estudo aplicando técnicas de
IC, com o emprego de RNAs, no sentido de aprimorar os resultados obtidos com a
utilização de tecnologias móveis para implementação do método FMC.
Desse modo, buscamos mesclar a utilização de técnicas de VC, IC e PDI no
desenvolvimento de um aplicativo móvel que permita ao produtor diagnosticar o grau de
anemia do animal de forma mais eficiente. Automaticamente, a partir da entrada de
imagens da conjuntivite do mesmo, permitindo um processo de tomada de decisão mais
rápida e precisa.
3. Metodologia de Desenvolvimento
Primeiramente, faz-se necessário um maior aprofundamento do estudo sobre vários
temas que envolvem o desenvolvimento do aplicativo proposto, tanto teórico como
prático. Para que assim, seja possível desenvolver um aplicativo com técnicas de visão
computacional, que realize um prévio processamento das imagens capturadas por
dispositivo do produtor e, em seguida, classifique a mesma por redes neurais treinadas
para diagnosticar o grau de anemia do pequeno ruminante.
De início, serão utilizadas imagens de bancos de dados públicos e devidamente
tratadas. Como também, planeja-se utilizar bibliotecas ou API (Application
Programming Interface) que disponham de técnicas já implementadas de VC e PDI que
serão necessárias para o desenvolvimento da ferramenta proposta, tais como: OpenCV
(Open Source Computer Vision Library) e API JAI (Java Advanced Image). É neste
momento em que será definida a plataforma mais apropriada para o desenvolvimento da
ferramenta. Outra biblioteca a ser utilizada como suporte inicial é a API Weka (Waikato
Environment for Knowledge Analysis), que dispõe de algoritmos de classificação, estes
que devem ser utilizados para o treinamento introdutório da RNA.
No decorrer da pesquisa, espera-se capturar as imagens da conjuntivite dos
animais através de dispositivos móveis, munidos de software com todas as técnicas já
implementadas, se possível, sem dependências adicionais. Possibilitando assim, a
realização de testes em campo sem o uso demasiado dos recursos do hardware.
Na etapa final, deve ser concluído o treinamento da RNA, supervisionado por
profissional experiente na aplicação do método FMC e, posteriormente, após a
quantidade de testes e ajustes necessários, devem ser validados os resultados da pesquisa
na prática.
562
Em resumo, pretende-se implementar técnicas de VC/PDI, visando o realce da

imagem da mucosa ocular do animal, e técnicas de IC, visando a classificação automática
dessas imagens entre os cinco graus de anemia, no emprego de RNAs. Ambas as técnicas
devem ser implementadas, embarcadas e testadas na prática em empresa parceira da
região.
4. Resultados Esperados
Ao término deste projeto espera-se a entrega dos seguintes resultados: 1) Rede neural
treinada para classificação de imagens dentro dos cinco graus de anemia conforme o
método FMC; 2) Pacote de software de plataforma aberta, que ofereça as
funcionalidades necessárias para implementação de aplicações capazes de determinar o
grau de anemia em pequenos ruminantes (caprinos e ovinos); e, 3) Aplicação mobile que
utilize o pacote de software para que potenciais usuários possam utilizar as
funcionalidades de classificação da ferramenta proposta.
Referências
Alexandria, A. R. d. Sistema de Reconhecimento Óptico de Algarismos para Medidores
Convencionais de Energia. Dissertação (Mestrado) - Universidade Federal do Ceará
(UFC), 2005.
Almeida, T. M. de. Uma metodologia de reconhecimento de caracteres manuscritos
utilizando redes neurais embarcadas. Monografia (Especialização). Faculdade 7 de
Setembro (FA7), 2014.
Alves, R. J. F. ANEMIMETRO: App para aplicação do Método Famacha. Seminário de
Iniciação Científica, Seminário Integrado de Ensino, Pesquisa e Extensão e Mostra
científica, [S.l.], 2016.
Borth, M. R., Iacia, J. C., Pistori, H., Ruviaro, C. F. A Visão Computacional no
Agronegócio: Aplicações e Direcionamentos. In: 7º Encontro Científico de
Administração, Economia e Contabilidade (ECAECO), 2014, Ponta Porã. [Trabalho
apresentado na forma de pôster].
Chagas, A. C. de S., Carvalho, C. O. de e Molento, M. B. Método Famacha©: Um
recurso para o controle da verminose em ovinos. São Carlos, SP: Embrapa Pecuária
Sudeste. Circular Técnica 52. 2007.
Demoliner, G., Alves, R. J. F. ANEMIMETRO: app móvel para implementação do
método Famacha. Unoesc & Ciência - ACET, [S.l.], v. 8, n. 1, p. 25-32, jun. 2017.
Gonzalez, R. C. and Woods, R. E. Digital Image Processing (3rd Edition). [S.l.]:
Prentice Hall, 2007.
Lima, M. M. de. Estudo de fatores do aspecto sanitário em relação à infecção por
parasitos gastrintestinais em caprinos e ovinos no estado de Pernambuco - Brasil.
2007. 182 f. Tese (Programa de Pós-Graduação em Ciência Veterinária) -
Universidade Federal Rural de Pernambuco, Recife.
Marengoni, M., Stringhini, D. Tutorial: Introdução à Visão Computacional usando
OpenCV, Universidade Presbiteriana Mackenzie, 2009.
563
Matsunaga, V. Y. Curso de Redes Neurais utilizando o MATLAB. Belém do Pará,

2012.
Molento, M. B., Tasca, C., Gallo, A., Ferreira, M., Bononi, R. e Stecca, E. Método
Famacha como parâmetro clínico individual de infecção por Haemonchus contortus
em pequenos ruminantes. Ciência Rural. v. 34, p.1139-1145. 2004.
Neves, M. R. M. das, Zaros, L. G., Medeiros, H. R. de, Martins, E. C., Navarro, A. M.
Do C. e Vieira, L. da S. Estimativa de custo do método Famacha utilizado no
controle de verminoses gastrintestinais em pequenos ruminantes. In: Congresso
Nordestino de Produção Animal, 5., 2008, Aracaju. Anais... Aracaju: SNPA;
Embrapa Tabuleiros Costeiros, 2008. 3 f.1 CD ROM. 2008.
Ramos, J. P. S. Redes neurais artificiais na classificação de frutos: cenário bidimensional.
Ciênc. agrotec. [online]. 2003, vol.27, n.2, pp.356-362.
Vieira, L. da S. Endoparasitoses gastrintestinais de caprinos e ovinos: alternativas de
controle. In: Encontro Nacional de Produção de Caprinos e Ovinos, 1., 2006,
Campina Grande. [Trabalhos apresentados]. Campina Grande: SEDAP; SEBRAE;
INSA; ARCO, 2006. 11 f. 1 CD-ROM.
Zhang, H. , Zhao, K., Song, Y. Z., Guo, J. Text extraction from natural scene image: A
survey. Neurocomputing. 2013, v. 122, p. 310–232.
564
MODELO DE ARQUITETURA DISTRIBUÍDA

APLICADA A UMA PLATAFORMA PROVEDORA DE
SERVIÇOS ACADÊMICOS
Abstract. The present work consists of a research carried out in an educational

institution where some problems were verified in the academic management of
the institution, motivating the development of a solution for the same one,
considering that it has few resources and short budget for investment in A tool
that solves these problems through cloud computing technology and following
the SaaS model and multi-tenancy architecture, has been presented as a solution
to a fully online environment that provides academic services without the
installation of software, where the client Uses the online application globally,
paying only the value for the service offered instead of the software itself.
Keywords: Cloud Computing, Academic Control, SaaS, web service, REST API.
Resumo. O Presente trabalho consiste em uma pesquisa realizada em uma
instituição de ensino onde averiguou-se alguns problemas na gestão acadêmica
da instituição, motivando o desenvolvimento de uma solução para a mesma,
tendo em vista que esta dispõe de poucos recursos e curto orçamento para
investimento em uma ferramenta que venha a solucionar estes problemas por
meio da tecnologia de cloud computing (computação em nuvem) e seguindo o
modelo SaaS e arquitetura multi-tenancy, foi apresentada como solução um
ambiente totalmente online que fornece serviços acadêmicos dispensando a
instalação de softwares, onde o cliente utiliza a aplicação online globalmente,
pagando apenas o valor pelo serviço ofertado em vez do software em si.
Palavras chave: Computação em nuvem, controle acadêmico, SaaS, web
service, REST API.
1. Introdução
À medida que a aquisição de recursos de Tecnologia da informação (TI) se torna mais
acessível financeiramente, mais rápida também é a sua popularização, sendo vital para o
desenvolvimento de boa parte das empresas ou instituição principalmente pequenas e
microempresas. Com base num estudo encomendado pela ABRADISTI-Associação
Brasileira dos Distribuidores de Tecnologia da Informação, só em 2012 as pequenas
empresas representaram 40% dos investimentos realizados em Tecnologia da Informação.
Estas empresas dos mais diversos ramos de atividade estão se beneficiando com
a tecnologia da informação cada vez mais acessível, tomando como exemplo a Cloud
computing (computação em nuvem) considerando a definição do NIST (National Institute
of Standards and Technology - USA), onde a computação em nuvem representa um
conveniente modelo de acesso, sempre que for necessário, a um conjunto compartilhado
de recursos computacionais configuráveis, tais como, redes, servidores, armazenamento,
aplicações e serviços, que podem ser disponibilizados rapidamente, com o mínimo
esforço, gerenciamento e interação com o provedor dos serviços.
565
Há por parte dessas empresas um grande aproveitamento desses serviços de

computação disponibilizados pela internet principalmente os que têm como base o
conceito de SaaS (Software as a service) onde basicamente o cliente utiliza a aplicação
online globalmente, pagando somente o valor pelo serviço consumido em vez de pagar
pelo software em si, a exemplo serviços como Microsoft Office 365 que consiste numa
versão do pacote Office da Microsoft que roda a partir do navegador e também o serviço
de armazenamento em nuvem Dropbox. Dessa forma A agilidade mais do que o custo
deverá ser a razão primária para muitas empresas adotarem a computação em nuvem
(Gartner, 2014).
Tomando como referência às instituições de ensino em geral que da mesma
maneira estão englobadas no processo de adoção de soluções em TI buscando maior
desempenho nas atividades acadêmicas e demais departamentos. O presente trabalho
consiste no desenvolvimento de um sistema que oferece serviços online para ambientes
escolares aos principais setores do meio acadêmico e da gestão da instituição, de forma
mais específica, através das funcionalidades do ambiente web oferecer serviços para o
setor de controle acadêmico como o controle de entrada e saída de alunos envio de
notificações aos pais sobre o andamento acadêmico dos filhos e ainda o desenvolvimento
de uma aplicação mobile para consulta de notas e frequência e demais recursos da
plataforma.
As funcionalidades acima mencionadas são subdivididas em módulos do
ambiente, proporcionando ao cliente adquirir apenas o que lhe convém e ainda aquisição
de funcionalidades opcionais mediante necessidade do contratante. O desenvolvimento
desta solução partiu da necessidade de melhoria na gestão das atividades acadêmicas,
constatada nas entrevista e formulários aplicados na pesquisa feita na instituição objeto
deste estudo, considerando que a mesma dispõe de recursos financeiros limitados,
mediante a análise de requisitos e considerando o perfil do cliente adotou-se o
desenvolvimento de um ambiente distribuído através da junção das tecnologias da
arquitetura SaaS e do modelo Multi-Tenant (múltiplos inquilinos), modelo este onde cada
cliente (Tenant) acessa o sistema hospedado em nuvem assim maneira distribuída, seja
por computadores ou dispositivos mobiles e demais devices conectados à internet.
Propondo assim uma solução informatizada para melhor atender às especificidades da
instituição
Baseando-se no modelo de implementação de computação em nuvem, o sistema proposto
faz uso da arquitetura SaaS onde a aquisição ou utilização de um software não está
relacionado a compra de licenças, ou seja, lhe permite adquirir o que você necessita,
pagando apenas pelo que utiliza em determinado período ou situação pontual, sendo pelo
consumo dos recursos (Armbrust, 2010) seja este período por hora ou mensal, ou por
assinatura quando o usuário aloca uma quantidade fixa de recursos por mês e paga por
esta Quantidade (Kalyvas, 2013).
Segundo Araújo (2016) os principais motivos que levam ou que podem levar as
empresas a utilizar Software SaaS são a poupança nos custos com Hardware, Software e
suporte de TI. Mas o SaaS não é só um modelo distinto de distribuição de Software, é
uma nova forma de fazer negócio. A escalabilidade das soluções é central para atingir
volumes críticos de forma a gerar os lucros pretendidos.
566
A sigla API (Application Programming Interface) que em português, significa

Interface de Programação de Aplicações), trata-se de um conjunto de rotinas e padrões
definidos e documentados por uma aplicação X, para que outras aplicações consigam
utilizar as funcionalidades desta aplicação de forma transparente.
Já uma REST (Representational State Transfer), em português Transferência de
Estado Representacional) Trata-se de uma abstração da arquitetura da Web.
Resumidamente, o REST consiste em princípios que, quando seguidas, permitem a
criação de um projeto com interfaces bem definidas. Desta forma, permitindo, por
exemplo, que aplicações se comuniquem. Uma web API que é desenhada em
conformidade com os princípios de arquitetura REST é designada por REST API.
No contexto deste Sistema de Informação foi implementada uma REST API que
disponibiliza um conjunto de serviços (endpoints) através dos quais é permitido o acesso
à informação guardada na base de dados (Bogueira, 2016). O uso de REST APIS dispensa
a instalação de softwares e grandes investimentos em hardware resultando em menores
custos ao contratante.
Esse tipo de tecnologia se sobressaem em relação às arquiteturas comuns como
cliente-servidor que acabam perdendo a escalabilidade da aplicação implicando na
aquisição de recursos para cada novo cliente gerando gastos para o fornecedor e
consequentemente para o cliente, enquanto que aplicações distribuídas que utilizam
arquitetura SaaS são mais escaláveis, o crescimento da aplicação permite adicionar uma
quantidade maior de clientes sem necessidade de grandes investimentos em recursos de
hardware permitindo maior escalabilidade.
3. Arquitetura
O desenvolvimento deste projeto foi baseado nos conceitos de cloud computing aplicando
o modelo de negócio SaaS e a arquitetura Multi Tenant, o motivo da adoção desta
arquitetura está justamente possibilitar uma solução de baixo custo e atendendo as
especificidades de cada estudo de caso proporcionando grau considerável de segurança e
alta disponibilidade.
Ao fazer uso da arquitetura convencional de rede cliente-servidor implicaria em
maiores custos tendo em vista a necessidade de aquisição de hardware específico ainda
conforme aumento dos dados poderia comprometer a robustez do sistema limitando o seu
grau de escalabilidade, abaixo (Figura 1) as diferenças das arquiteturas.
Figura 1. Diferenças das Arquitetura Cliente-servidor convencional e Multi Tenancy.
567
Conforme a análise dos requisitos e estudo de caso adotou-se trabalhar com uma
solução de sistema distribuído, que pode ser acessada de qualquer lugar independente do
sistema operacional com o mínimo de Hardware para pleno funcionamento, neste os
serviços são fornecidos através de uma REST API implementada em Laravel Framework
que fornece estes serviços para as aplicações cliente.
O esquema de funcionamento do produto proposto fica disposto da seguinte
maneira, após a confirmação do pagamento o serviço é automaticamente liberado para
uso diferindo-se de outros tipos de aplicações que necessitam de configuração de
hardware e software específicos para funcionamento e uso, o acesso dar-se-á por meio
de uma aplicação cliente (Android, Web, IOS) onde ao inserir o seu login o cliente será
redirecionado ao servidor de autorização Oauth2 que faz a verificação dos dados do
cliente , Após a autorização é feito a autenticação através de um token de acesso que é
retornado com as credenciais do cliente para consumir os recursos da REST API
conforme disposto na (Figura 2).
Figura 2. Funcionamento da arquitetura usada.

O aplicativo foi desenvolvido com apoio do framework VueJS que é utilizado no
desenvolvimento de componentes reativos para interfaces web modernas, também usando
o conceito de SPA (Single Page Application) que em português significa aplicação de
página única, funciona da seguinte maneira a aplicação cliente envia suas credenciais para
o servidor de Autorização Oauth2 solicitando o consumo dos recursos da REST API que
dar-se por meio do token de acesso para usufruir dos serviços seguindo o modelo de SaaS.
4. Metodologia
Foram utilizados para o levantamento de dados deste projeto formulários eletrônicos com
a ferramenta Google forms, direcionados aos funcionários da instituição objeto deste
estudo, no formulário questionou-se aos mesmo quais as dificuldades enfrentadas na
gerência e manipulação dos dados (notas e informações acadêmicas) e demais ocasiões
do dia a dia ainda se almejavam o uso de alguma ferramenta que os auxiliasse nas
atividades do setor dentre outras.
568
Após o levantamento dos dados obtido por meio do questionário, e no processo

de elaboração do estudo de caso também foram feitas revisões bibliográficas em livros,
artigos e sites na internet a respeito de projetos e softwares similares a este, foram
encontrados diversos sistemas como: Q-acadêmico utilizado na rede de Institutos
Federais e o SIGAA (Sistema Integrado de Gestão de Atividades Acadêmicas) utilizado
pela Universidade Federal do Piauí.
Para a implementação utilizou-se o conceito da computação em nuvem, com apoio
do framework Laravel utilizando modelo Multi-Tenancy, com uma base de dados para
cada cliente de forma isolada usando banco de dados relacional em SQL com sistema
gerenciador de banco de dados PostgreSQL, também foi implantado o padrão de
autenticação Oauth2 conferindo maior proteção de acesso ao cliente.
Para o desenvolvimento da aplicação mobile foi utilizado o framework VueJS
aplicando o conceito de SPA (Single Page Application) em português Aplicação de
Página Única, que com êxito no login na aplicação pode-se executar as seguintes tarefas:
cadastro de Turmas professores e respectivas disciplinas por ele ministradas; cadastro
alteração e exclusão de Alunos; Consulta e relatório de entrada e saída dos alunos. A
geração da matrícula é automática ainda no mesmo é feita a geração das carteirinhas que
será explicada adiante no tópico 5.
5. Análise e discussão dos dados

Com a análise dos dados coletados averiguou-se algumas situações enfrentadas pelos
funcionários do setor de controle acadêmico e pela instituição no geral, os funcionários
alegaram entre outras situações, que conforme o aumento dos alunos ingressantes na
instituição, o prazo torna-se insuficiente para a entrega dos documentos contendo as notas
frequência e demais dados, em virtude da quantidade de alunos e burocracia dos métodos
até então usados, somado ao fato de que boa parte dos pais e ou responsáveis pelos alunos
residem em outras cidades, ocasionando uma dificuldade no envio de certas informações
úteis aos mesmos, neste último caso seria interessante adicionar mais um meio de consulta
destas informações e o envio de alertas e demais notificação, surgindo assim umas
funcionalidades do produto.
Outra sondagem importante foi em relação ao armazenamento dos dados que da
forma como eram armazenados e manipulados estavam sujeitos a alterações feitas por
pessoas não autorizadas ou exclusão acidental. Ao término da análise constatou-se a
necessária atenção ao tratamento destas informações resultando na implantação de um
sistema de banco de dados distribuído para o produto.
Para atender às principais necessidades da instituição conforme suas
especificidades o produto desenvolvido, o ambiente foi subdividido em módulos que após
cadastro (Figura 4) da instituição na plataforma a mesma terá acesso aos principais
módulos do ambiente.
569
Figura 4. Tela para cadastro de instituição.
O módulo destinado ao controle acadêmico da instituição disponibiliza o controle

de fluxo de matrículas na instituição permitindo inserir, alterar dados e excluir alunos, a
cada novo aluno é atribuído o ano de ingresso, dados pessoais e CPF (Cadastro de Pessoas
Físicas) dos pais ou responsáveis, ainda na matrícula é atribuído o curso, turma e sala, o
CPF dos responsáveis acima mencionado será usado como um dos requisitos de
segurança do aplicativo móvel que para ter um login de acesso o usuário precisará estar
relacionado com o aluno através do CPF cadastrado.
O número de matrícula é gerado automaticamente com o êxito no cadastro do
aluno na instituição, aos professores é possível efetuar o lançamento das notas das
avaliações e o tipo da mesma, no mesmo módulo é apresentado a relação dos alunos por
turma contendo suas notas, frequência e status na disciplina; aprovado, pendente ou
reprovado. Auxiliando na geração de documentos que necessitam da relação das notas
dos alunos.
O módulo do ambiente responsável pelo controle de entrada e saída de
alunos funciona através consulta da matrícula por inserção ou leitura do código de barras
da carteirinha gerada também pelo módulo, se necessário a qualquer momento pode ser
gerada a relação de alunos ausentes e presente do dia ou determinada data, para os alunos
ausentes é enviada uma notificação aos seus responsáveis sobre o ocorrido,
complementando o aplicativo destinado aos pais permite também a consulta destas
informações sobre seus filhos matriculados e informações relevantes aos mesmos como
eventos e convocação para reuniões como parte do ambiente há um site com informações
sobre a instituição, eventos, fotos e a relação de cursos ofertados. Abaixo tela inicial do
módulo de controle e saída de alunos (Figura 3).
570
Figura 3. Tela inicial do módulo de controle de entrada e saída de alunos.
6. Considerações finais
A adoção das tecnologias de computação em nuvem SaaS e da arquitetura Multi-tenancy
mostraram-se bastante apropriadas ao real intuito do projeto e possibilitam implementar
um grau maior de robustez e coerência das atividades institucionais com as
funcionalidades da plataforma aqui desenvolvida, ao aplicar as principais características
do modelo SaaS ampliou-se as funcionalidade destinadas a auxiliar as principais atividade
da instituição, proporcionando mais agilidade nas tarefas de controle acadêmico com
acesso online aos serviços da plataforma. Será possível diminuir de forma considerável o
risco de atrasos nas entregas, visto que o software apresenta uma relação de alunos e notas
mais precisa e até mesmo a criação do boletim escolar.
Com a base de dados isolada implementada será possível atribuir um grau maior
na segurança, disponibilidade, robustez e evitando também a possível exclusão acidental
da base de dados que antes era armazenada nas maquinas locais. A escolha do Framework
laravel foi de grande importância para o desenvolvimento ágil do ambiente, com o
aplicativo para as plataformas Android e IOS voltado aos pais será mais transparente o
acompanhamento das notas dos alunos assim como notificações e convocações para
comparecimento na instituição.
Durante o projeto foram encontradas algumas dificuldades na fase de
desenvolvimento devido à complexidade de atender às especificidades da instituição e no
início com o pouco conhecimento da equipe com as tecnologias usadas na fase de
implementação que demandou mais tempo. Futuramente para amadurecimento da
aplicação e adição de mais módulos ao ambiente e melhorias no aplicativo para
dispositivos móveis será necessário aumentar o número de desenvolvedores assim como
trabalhos e pesquisas complementares a fim de aprimorar o produto e modelo de negócio
para implantação em mais instituições e demais casos de uso com problemática similar
abrangida pela arquitetura e modelo de negócio aqui usado.
571
Referências
Araújo, Virgínia e Cota, M. (2016). Avaliando SaaS através de métodos combinados de
investigação. CIAIQ2016, 4.
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G.,
Patterson, D., Rabkin, A., Stoica, I., et al. (2010). A view of cloud computing.
Communications of the ACM, 53(4): pp 50–58.
Bogueira, G., Batista, F., & Carvalho, J. P. (2016, agosto). Sistema Inteligente de
Recolha, Armazenamento e Visualização de Informação proveniente do Twitter”. Atas
da Conferência da Associação Portuguesa de Sistemas de Informação Vol. 15, No. 15,
pp. 418-439.
Gartner (2014) “Predicts 2015: Cloud and Digital Business Shape Strategies in the Future
IT Services Market “.
Kalyvas, J. R.; M. R. Overly; M. A. Karlyn (2013) Cloud Computing: A Practical
Framework for Managing Cloud Computing Risk - Part I, Intellectual Property &
Technology Law Journal, (25)3, pp. 7-18.
NIST-National Institute of Standards and Technology -USA (2009). The NIST Definition
of Cloud Computing. Disponível em: http://csrc.nist.gov/publications/drafts/800-
145/Draft-SP-800-145_clouddefinition.pdf.
572
Avaliação de Desempenho das Redes Ópticas Elásticas com

Tipos Distintos de Fibras Ópticas
Gabriel A. Gonçalves1 , Enio L. V. Barbosa1 , André C. B. Soares1 José V. R. Junior1
1
Teresina-PI-Brasil.
Abstract. This paper presents a performance evaluation of elastic optical

networks using three types of optical fibers: the Standard Single-Mode Fiber
(SSMF) with 100 and 50 km Spans, the Ultra-Large Area Fiber (ULAF) and the
Non-zero Dispersion-Shifted Fiber (NZDSF). We adopt the NSFNET topology
scenario, as well as the Dijsktra (DJK) as the routing algorithmic and for spec-
trum allocation we use the Fist-Fit heuristic, in which the frequency slots are
indexed and the connection requisition is accommodated in the first available
bandwidth with lower index. The results show that the ULAF, with effective area
larger, stands out in comparison to the standard fiber, SSMF-100, obtain low
block of 15,08%.
Resumo. Neste artigo é apresentado uma avaliação de desempenho das redes

ópticas elásticas utilizando três tipos de fibras ópticas: a Standard Single-Mode
Fiber (SSMF) com o span de 100 e 50 km, a Ultra-Large Area Fiber (ULAF)
e a Non-zero Dispersion-Shifted Fiber (NZDSF). Adotou se o cenário da to-
pologia NSFNet, bem como o Dijsktra (DJK) como algoritmo de roteamento
e para a alocação espectral utilizou-se a heurı́stica First-Fit, em que os slots
de frequência são indexados e a requisição de conexão é acomodada na pri-
meira banda disponı́vel com menor ı́ndice. Os resultados obtidos apontam que
a ULAF, com área efetiva maior, se destaca em comparação à fibra padrão,
SSMF-100, obtendo bloqueio inferior de 15,08%.
1. Introdução
O tráfego da Internet tem aumentado gradativamente nos últimos anos, devido o crescente
numero de usuários, as aplicações de áudio, vı́deos, TV de alta definição, computação em
nuvem e aplicações de rede em tempo real [Costa and Drummond 2016]. Dessa forma,
para atender o crescente aumento da transmissão de dados a fibra óptica ganha espaço no
cenário, aliada a uma nova tecnologia caracterizada como redes ópticas elásticas (EON-
Elastic Optical Network) [Chatterjee et al. 2015].
As EON utilizam a tecnologia Multiplexação de Divisão de Frequência Ortogo-
nal (OFDM - Orthogonal Frequency Division Multiplexing) [Fontenele 2016], no qual
permite a divisão do espectro óptico em pequenos intervalos de frequência (12.5 GHz),
denominados de slots, e para cada circuito óptico pode ser alocado uma quantia distin-
tas de slot. Dessa forma, as EON tem a capacidade de alocar espectro para os circuitos
ópticos conforme a largura de banda requisitada.
573
As fibras ópticas, atuando como camada fı́sica das EON, tem o objetivo de via-
bilizar maiores larguras de banda, medida da capacidade de transmissão do meio óptico,
resultando em altas taxas de transmissões de dados. Além disso, apresentam baixas perdas
de intensidade do sinal ao longo da transmissão dos dados, cooperando para a utilização
de poucos repetidores de sinal, responsáveis por amplificarem e regenerarem os sinais
ópticos [Gao et al. 2014].
No entanto, apesar de as fibras ópticas serem compostas por materiais dielétricos,
isolantes, no qual possui imunidade a interferência eletromagnética, estão sujeitas aos
efeitos fı́sicos do meio, resultando em perda de sinal, oriundos pela distorção, atenuação e
interferências no sinal [Gonçalves 2012]. Neste contexto, tem-se destacado a importância
de avaliar as imperfeições da camada fı́sica, no qual degradam a qualidade de transmissão
(QoT - Quality of Transmission) a medida que o sinal propaga pelos enlaces e dispositivos
ópticos da rede [Fontinele et al. 2016]. Para que ocorra uma melhor propagação do sinal
óptico é importante analisar e avaliar as fibras ópticas, afim de verificar quais efeitos do
meio podem contribuir para a degradação da QoT.
Portanto, a proposta do trabalho é apresentar uma analise do desempenho dos
tipos distintos de fibras ópticas nas EONs, no qual foram consideradas três tipos de fibras
para os seguintes cenários: a SSMF, com o span de 100 e 50 km, a ULAF e a NZDSF,
utilizando o algoritmo Dijkstra na topologia NSFNet.
Este trabalho está organizado da seguinte forma: Na Seção 2 é apresentada os prin-
cipais trabalhos relacionados; Na Seção 3 é apresentada uma descrição das redes ópticas
elásticas; Na Seção 4 é descrito os os tipos de fibras estudadas nesse artigo; Enquanto que
na Seção 5 é descrito os resultados; seguidos das conclusões.
Em [Gonçalves 2012] foi feito uma análise do comportamento da propagação de pulsos
numa fibra óptica considerando os efeitos lineares e não lineares. Primeiramente são
introduzidos conceitos básicos sobre como os feixes de luz podem viajar pela fibra, apre-
sentando conceitos de difração e reflexão total da luz. Em seguida, faz-se uma breve
descrição sobre por que razão os pulsos luminosos sofrem o efeito da dispersão durante
a propagação na fibra óptica. Como resultados, observa-se que o efeito da dispersão nos
pulsos é o principal limitador da largura de banda do sinal transmitido.
Os autores em [Gao et al. 2014]avaliam as caracterı́sticas da camada fı́sica que
influenciam na performance das redes ópticas elásticas, no qual foi analisada a taxa de
bloqueio de requisições por banda, os tipos de fibras e a utilização da técnica forward
error correction (FEC), uma técnica usada para controlar erros durante uma transmissão
de dados. Além disso, os mesmos autores propuseram um algoritmo para melhorar a
qualidade de transmissão através da adaptação do cabeçalho FEC para cada requisição.
Por fim, apontam que as fibras com maior área efetiva do núcleo e menores perdas por
atenuação podem melhorar a qualidade da contramissão.
Em [Harboe et al. 2008] foi analisado o efeito não linear, denominado de Four
Wave Mixing (FWM), no qual a interação entre os sinais propagados na fibra óptica ge-
ram novos sinais indesejados. Em seguida, são analisadas os tipos de fibras monomodos
utilizados em comunicações ópticas, no qual a Fibra de Dispersão Deslocada Não-Nula
(NZDSF - Non Zero Dispersion Shifted Fiber) é a ideal para suprimir a FWM.
574
Em [Pereira et al. 2012] foram caraterizadas as propriedades dispersivas e não li-

neares em fibras ópticas microestruturadas,verificando que apresentam um bom controle
de dispersão e mais flexibilidade no design. Em seguida, foi desenvolvido um algorı́timo
que permite projetar um determinado tipo de fibra e simular a propagação nessa fibra. Os
resultados apontam que é possı́vel obter elevado confinamento do sinal, baixos valores da
dispersão, para as fibras microestruturadas.
3. Redes Ópticas Elásticas

As EON através da divisão do espectro em intervalos de frequência e alocando diversos
circuitos com diferentes larguras de banda e formato de modulação, possibilitam uma
alta capacidade de transmissão [Brasileiro et al. 2016]. Portanto, a arquitetura de uma
rede óptica tem a finalidade de realizar o planejamento da rede para tolerar caminhos
ópticos de tamanho variável, no qual tem a capacidade de adaptar a larguras de banda
através do ajuste da taxa de bits a ser transmitido [Jr et al. 2016]. As camadas que fa-
zem parte da arquitetura de gerenciamento da rede óptica são representados na Figura 1
[Sócrates-Dantas et al. 2014].
Camada Cliente
Plano de Controle
Camada Física
Figura 1. Componentes da arquitetura de gerenciamento de uma rede ópticas.
Na camada superior representado pela camada cliente, estão as redes clientes que
requerem serviços para a rede óptica, enquanto que o plano de controle representa a in-
terface entre a camada cliente e a camada fı́sica. A comunicação entre os clientes é por
meio do plano de controle, no qual executa os algoritmos RSA estabelecendo a conexão e
alocando os recursos da camada fı́sica. No plano de controle as ligações entre os nós são
efetuadas por conexões lógicas porém, não necessariamente corresponde a uma conexão
fı́sica semelhante na camada fı́sica. A camada inferior representado pela camada fisica
corresponde aos dispositivos ópticos e os dados entre os clientes são percorridos através
da camada fı́sica.
A medida que se propaga um sinal óptico da origem ao destino, o sinal so-
fre degradações devido as imperfeições da camada fı́sica, além disso, o excesso de
degradações do sinal óptico ao longo da rota resulta em uma BER (Bit Error Rate) in-
tolerável no receptor, dificultando a comunicação [Rahbar 2012].
575
Um circuito óptico pode degradar a QoT de outros circuitos devido aos efeitos
de camada fı́sica. Este impacto em outros circuitos acontece quando tem nós e enlaces
em comum e para que estabeleça um novo circuito óptico é necessário que a o espec-
tro da rota escolhida esteja disponı́vel, a QoT do circuito seja aceitável e caso o novo
circuito seja atendido, deverá ser mantida para os outros circuitos ópticos ativos na rede
[Fontinele et al. 2016].
Tendo isso em vista, como a QoT depende da camada fı́sica os diversos tipos
de fibras podem resultar em diferentes QoT, pois tem caracterı́sticas de atenuação e não
linearidade distintas para propagação do sinal óptico [Gonçalves 2012]. Dessa forma, a
seguir serão apresentadas as caracterı́sticas da camada fı́sica, bem como os efeitos que
podem degradar o QoT e, por fim, os 3 tipos diferentes de fibras ópticas estudadas nesse
trabalho, no caso a SSMF, com o span de 100 e 50 km, a ULAF e a NZDSF.
4. Tipos de fibras ópticas

Considerando o contexto da camada fı́sica, para que ocorra as transmissões de dados
são emitidos feixes luminosos, como os emitidos por um LED (Light Emition Diode)
ou ILD (Injection Laser Diode), no qual esses sinais luminosos percorrem a fibra óptica
através de toda sua extensão. Os feixes de luz permanecem confinados na fibra óptica por
conta dos fenômenos fı́sicos da refração e da reflexão interna total [Gonçalves 2012]. A
refração ocorre quando a luz passa de um meio fı́sico para outro e a reflexão interna total
impede que a luz saia ao chegar na parede da fibra óptica. Para fibras de grande extensão
o sinal pode, ainda, passar por regeneradores, para manter a potência do pulso luminoso.
Por último, um fotodetector, localizado na outra extremidade da fibra óptica, converte os
pulsos luminosos em pulsos elétricos que, por fim, serão transformados em bits.
Entretanto, a luz ao viajar pela fibra, principalmente devido as altas taxas de trans-
missão de dados, pode sofrer com efeitos fı́sicos que limitam a transferência dos sinais
e afetam o desempenho da fibra. Esses efeitos são conhecidos como efeitos lineares e
não-lineares.
Dentre os efeitos lineares, a atenuação está relacionada a perda de potência do si-
nal luminoso durante a propagação pela fibra. Outro efeito linear é a dispersão, separação
dos comprimentos de onda pertencente a um feixe de luz e se deve principalmente por
conta das caracterı́sticas materiais e estruturais da fibra [Gonçalves 2012].
Considerando os efeitos não-lineares temos a auto modulação de fase, a
modulação de fase cruzada e a mistura de quatro ondas. Esses efeitos estão relaciona-
dos com a potência do pulso propagado e surgem mais frequentemente quando existe
altas taxas de transmissão. Na auto modulação de fase com a intensidade da luz existe
uma pequena variação do ı́ndice de refração da fibra, o que faz com que a variação de
intensidade de um canal module a fase da luz do mesmo canal. A modulação cruzada de
fase ocorre quando há propagação simultânea de dois pulsos com comprimentos de ondas
diferentes na mesma fibra no qual um pode alterar a fase do outro [Pereira et al. 2012].
A mistura de quatro ondas corresponde à geração de uma quarta frequência quando três
campos ópticos, com frequências diferentes, se propagam na mesma fibra óptica.
No mercado atual são comercializadas diversos tipos de fibras ópticas, no qual
cada uma possui diferentes caracterı́sticas em sua fabricação e, portanto, comporta-
mento distintos em relação aos efeitos fı́sicos. Neste contexto, foram considerados os
576
seguintes tipos de fibras: SSMF-100, SSMF-50, ULAF e a NZDSF, vide Tabela 1.

[Gao et al. 2014].
A SSMF é o tipo de fibra mais utilizada, no qual foi introduzida comercialmente
em 1983 [Harboe et al. 2008]. Essa fibra possui um valor zero de dispersão cromática,
alargamento do pulso durante sua propagação, para frequências próximos de 1310 nm e
aproximadamente 16 ps/nm/km para a janela de 1550 nm, resultando em dificuldades na
utilização para altas taxas de transmissão de longas distâncias. Na região de comprimento
de onda de 1310 possui cerca de 1 dB/Km como coeficiente de atenuação e na região de
1550 possui cerca de 0.5 dB/km.
A ULAF possui um núcleo mais largo, ou seja, uma área efetiva maior, entretanto,
continua se comportando como uma fibra monomodo. Devido a isso, tais fibras são menos
suscetı́veis aos efeitos não lineares relacionadas a potência óptica, por possuı́rem menores
potências por unidade de área. Seu coeficiente de dispersão é de cerca de 20 ps/nm/Km e
perda de 0,16 dB/Km [Gao et al. 2014].
A NZDSF foi projetada para apresentar dispersão cromática muito baixa, porém
não zero, na região de 1550 nm, entre 0,1 e 6 ps/nm/Km, variando de acordo com o
fabricante. Assim como a SSMF, apresenta coeficiente de atenuação em torno de 0,2
dB/Km [Harboe et al. 2008].
Tabela 1. Principais Caracterı́sticas das Fibras Ópticas.

Tipos de fibras L (km) D (ps/nm/km) Perda (dB/Km) Aeff
SSMF-100 100 16 0.2 80
SSMF-50 50 16 0.2 80
NZDSF 100 4 0.2 56
ULAF 100 20 0.16 146
L: Tamanho de um Spam; D: Parâmetro de dispersão da fibra; Aeff: Área efetiva.
Uma vez compreendido como funciona a transmissão de dados em fibras ópticas e

quais os tipos de fibras que foram consideradas neste trabalho, a seguir são apresentados
os resultados de desempenho nas EONs.
5. Análise de Desempenho dos Tipos de Fibras Ópticas

Os resultados contidos nesta seção foram obtidos através de simulações computacionais
utilizando o simulador SNEts (Slice Network Simulator) para a topologia NSFNet, no qual
apresenta 14 nós e 22 enlaces [Santos 2015]. Os parâmetros utilizados são apresentados
na Tabela 2.
Tabela 2. Parâmetros para a simulação.

Parâmetros Valores
Número de Requisições 1.000.000
Quantidade de replicações 10
Pontos de carga 5
Quantidade de slot 320
Intervalo de frequência 12.5 GHz
Larguras de Banda 10, 20, 40, 80, 160, 320 Gbps
577
De acordo com a Tabela 2, foram utilizadas larguras de bandas entre 10 e 320

Gbps [Brasileiro et al. 2016], adotando-se 5 pontos de carga. Os pontos de carga são
representados pela média da taxa de chegada e taxa de atendimento, além disso, adotou-
se 1 milhão de requisições, 10 replicações e 320 slots em cada enlace dividido em 12,5
GHz para a simulação [Brasileiro et al. 2016].
A carga de tráfego entre todos os pares (o,d) é distribuı́do de modo uniforme, en-
tretanto as requisições surgem seguindo o processo de Poisson (λ) e o tempo de retenção é
distribuı́do exponencialmente por meio da média 1/µ. Para avaliação de desempenho dos
tipos de fibras ópticas, foram adotados o algoritmo DJK e a polı́tica de alocação espectral
firstfit.
Probabilidade de Bloqueio por Banda (546 Erlang ) Probabilidade de Bloqueio por Banda (720,72
Erlang )
0,35
0,45
Probabilidade de Bloqueio
0,3
0,4
0,25 0,35
0,3
0,2
0,25
0,15 0,2
0,15
0,1
0,1
0,05 0,05
0 0
10.0 20.0 40.0 80.0 160.0 320.0 10 20 40 80 160 320
Largura de banda (Gbps) Largura de Banda (Gbps)
NZDSF SSMF-100 SSMF-50 ULAF
Figura 2. Probabilidade de bloqueio por banda para diferentes tipos de fibras.
Probabilidade de Bloqueio por Banda Total

0,37
0,32
0,27
0,22
0,17
0,12
31 2
3.24 3
3.48 4
3.72 5
3.96
Pontos de carga
NZDSF SSMF-100 SSMF-50 ULAF
Figura 3. Probabilidade de bloqueio por banda total com diferentes tipos de

fibras ópticas.
Na Figura 2 é apresentado a probabilidade de bloqueio por largura de banda para

o primeiro e quinto ponto de carga, tais pontos representam menor e maior uso da rede.
Foi calculado a media da probabilidade de bloqueio de todas as larguras de banda, no
578
qual verificou-se que no primeiro ponto de carga a SSMF-100 obteve bloqueio inferior
de 144,38%, 155,28% e 32,80% quando comparado a NZDSF, SSMF-50 e ULAF, res-
pectivamente. Para o ultimo ponto de carga, a SSMF-100 apresentou bloqueio inferior
de 77,32% e 65,66% ao igualar com a NZDSF e SSMF-50, nessa ordem. No entanto,
verificou-se probabilidade de bloqueio superior de 11,55% comparando à ULAF.
A Figura 3 apresenta a probabilidade de bloqueio levando em consideração a me-
dia de todas as largura de banda para cada um dos pontos de carga. Foi calculado a média
da probabilidade de bloqueio para todos os pontos de carga, dessa forma, observou-se que
a SSMF-100 obteve bloqueio inferior de 48,35% e 21,73% quando comparado a NZDSF
e SSMF-50, nessa ordem. No entanto, quando comparado à ULAF resultou em um blo-
queio superior de 15,08%.
6. Conclusão
A maleabilidade das redes ópticas elásticas possibilita um melhor aproveitamento dos re-
cursos espectrais e, deste modo, podem suportar altas taxas de transmissões. Entretanto,
as caracterı́sticas da camada fı́sica podem influenciar na performance dessas redes, de-
gradando a qualidade de transmissão. Tendo isso em vista, foram realizados simulações
utilizando a topologia NSFNET, o algorı́timo de roteamento DKJ e a politica de alocação
de espectro First-fit a fim de avaliar a performance das seguintes fibras: a Standard Single-
Mode Fiber (SSMF) com o span de 100 e 50 km, a Ultra-Large-Area Fiber (ULAF) e a
Non-zero Dispersion-Shifted Fiber (NZDSF) .
Foi verificado que a SSMF-100 aponta desemprenho superior em relação à de-
mais fibras, para um brando tráfego de dados, uma probabilidade de bloqueio inferior de
48,35% para NZDSF e 21,73% para SSMF-50. No entanto apresenta um desempenho in-
ferior em comparação à fibra ULAF para redes com intensivo tráfego de informações, um
bloqueio superior de 15,08%. Tal comportamento é resultado dos efeitos não lineares da
fibra óptica relacionados à potencia luminosa como auto modulação de fase, modulação
cruzada de fase e mistura de quatro ondas.
Neste contexto, a ULAF, por ter uma área efetiva maior, apresenta menos inten-
sidade óptica resultando na redução de efeitos não lineares. Para as demais fibras, cujo a
área efetiva é menor, os efeitos não lineares se intensificarão, degradando o sinal ao longo
da transmissão.
Referências
Brasileiro, Í. B., dos Reis Júnior, J. V., and Soares, A. C. B. (2016). Nova solução para
o problema de roteamento em redes opticas elásticas utilizando algoritmo ciente de
fragmentação baseado em sistemas fuzzy. Simpósio Brasileiro de Redes de Computa-
dores - SBRC.
Chatterjee, B. C., Sarma, N., and Oki, E. (2015). Routing and spectrum allocation
in elastic optical networks: A tutorial. IEEE Communications Surveys & Tutorials,
17(3):1776–1800.
Costa, L. R. and Drummond, A. C. (2016). Novo algoritmo rmlsa com roteamento mul-
tihop em redes ópticas elásticas. Simpósio Brasileiro de Redes de Computadores -
SBRC.
579
Fontenele, A. C. (2016). Um novo algoritmo rsa ciente a imperfeições de camada fı́sica

para redes ópticas elásticas. Universidade Federal do Piauı́.
Fontinele, A., Santos, I., Neto, J., Campelo, D., and Soares, A. (2016). Um novo algoritmo
rsa ciente de imperfeiç oes de camada fısica para redes opticas elásticas. Simpósio
Brasileiro de Redes de Computadores - SBRC.
Gao, G., Zhang, J., Wang, L., Gu, W., and Ji, Y. (2014). Influence of physical layer
configuration on performance of elastic optical ofdm networks. IEEE Communications
Letters, 18(4):672–675.
Gonçalves, A. M. (2012). Análise da propagação de impulsos em fibras ópticas. Univer-
sidade Técnica de Lisboa.
Harboe, P., da Siva, E., and Souza, J. (2008). Simulador wdm para análise das penalida-
des impostas por fwm em fibras g. 652, g. 653 e g. 655. aceito para publicação no
MOMAG2008, Florianópolis-SC, Setembro.
Horota, A., Reis, L., Figueiredo, G., and Fonseca, N. L. S. (2016). Routing and spectrum
assignment algorithm with most fragmented path first in elastic optical networks. IEEE
Latin America Transactions, 14(6):2980–2986.
Jr, J. L., Fontinele, A., Moura, I., Soares, A., and Neto-MA-Brasil, C. (2016). Avaliaç ao
de desempenho de algoritmos rsa para redes opticas elásticas com tolerância a falhas
em cenário com imperfeiç oes de camada fısica. Simpósio Brasileiro de Redes de
Computadores - SBRC.
Pereira, O. F. et al. (2012). Caracterização de fibras ópticasa altamente não lineares.
Faculdade de Engenharia da Universidade do Porto.
Rahbar, A. G. (2012). Review of dynamic impairment-aware routing and wavelength
assignment techniques in all-optical wavelength-routed networks. IEEE Communica-
tions Surveys and Tutorials, 14(4):1065–1089.
Santos, I. G. D. S. (2015). Alocação de recursos para o estabelecimento de circuitos em
redes ópticas wdm e ofdm. Universidade Federal do Piauı́.
Sócrates-Dantas, J., Careglio, D., Perelló, J., Silveira, R. M., Ruggiero, W. V., and Solè-
Pareta, J. (2014). Challenges and requirements of a control plane for elastic optical
networks. Computer Networks, 72:156–171.
580
Uma Abordagem Baseada na Máxima Estimativa de Geração

de Potência Reativa para a Determinação da Sequência de
Ajustes no Controle da Magnitude de Tensão em Sistemas de
Transmissão de Energia Elétrica
Enza Rafaela de S. Ferreira1 , Thiago Allisson R. da Silva1 ,
Ricardo de A. L. Rabelo1
1
[email protected],[email protected],[email protected]
Abstract. Voltage magnitude control is an essential task for the operation of

power transmission systems, being applied to keep voltage magnitudes within
predetermined limits defined by regulatory agencies. To perform such a control,
information regarding the current operating point and which control devices
may be adjusted to take the system to an adequate operating point is required.
In this context, this paper proposes an approach that determines and applies
a sequence of adjustments to voltage magnitude control in transmission power
systems. The adjustments are determined for one methodology based on the
greatest variation of reactive power injection for the Jacobian matrix (JQV ) of
the system power balance equations. Computational simulations in the IEEE
(Institute of Electrical and Eletronic Engineers) 57 bus system are performed
to evaluate the proposed approach considering operational one scenario with
voltage violations. The obtained results provide the dispatch of reactive power
necessary for the correction of the voltage violations, the bus voltage profiles
and the active power losses in the system as adjustments are executed.
Resumo. O controle da magnitude é uma tarefa fundamental para a operação
do sistema de transmissão de energia elétrica, sendo aplicado à manutenção das
magnitudes de tensão dentro de limites pré-determinados definidos por órgãos
de regulamentação. Para execução do controle da magnitude de tensão são ne-
cessárias informações relacionadas ao estado do sistema e quais dispositivos
de controle podem ser ajustados para levar o sistema à operação adequada.
Nesse contexto, este trabalho propõe uma abordagem que determina e aplica
uma sequência de ajustes no controle da magnitude de tensão em sistemas de
transmissão de energia elétrica, os ajustes são determinados por uma metodo-
logia baseada na estimativa de variação da geração de potência reativa ob-
tida através da matriz Jacobiana reduzida (JQV ) das equações de balanço de
potência do sistema. Simulações computacionais no sistema IEEE (Institute of
Electrical and Eletronic Engineers) de 57 barras são realizadas para avaliar
a abordagem proposta considerando um cenário operacional com violações de
tensão. Os resultados obtidos fornecem o despacho de potência reativa ne-
cessário para a correção das violações de tensão, os perfis de tensão nas barras
do sistema e as perdas de potência ativa no sistema à medida que os ajustes são
realizados.
1. Introdução
De acordo com [Eremia and Shahidehpour 2013], o objetivo principal do controle da
magnitude de tensão é manter as magnitudes numa faixa de valores adequada. Para
581
isso, o sistema elétrico de potência possui um conjunto de dispositivos de controle

[Capitanescu et al. 2014] que precisam ser operados de forma coordenada a fim de que
sua atuação conjunta garanta valores adequados de tensão em todas as barras do sis-
tema [Paramasivam et al. 2015].
De acordo com [Calderaro et al. 2014], o controle da magnitude de tensão efetu-
ado por intermédio do redespacho de potência reativa é implementado tradicionalmente
de forma centralizada, exigindo um substancial investimento em sistemas de controle e
comunicação de dados, haja vista a necessidade de uma grande quantidade de dados ser
transmitida a um centro de controle. Em [Xu et al. 2012] um método de aprendizado por
reforço é proposto e aplica um sistema multiagente para otimizar o despacho de potência
reativa e minimizar as perdas do sistema. As simulações demonstram que o método é
computacionalmente eficiente. Em [Chen et al. 2015] uma metodologia para controle da
magnitude de tensão que aplica variantes do PSO (Particle Swarm Optimization) combi-
nada com um sistema de inferência fuzzy para determinar o despacho de potência reativa
necessário é proposta. Os resultados provam que a metodologia consegue obter soluções
promissoras.
Em vista disso, este trabalho propõe uma abordagem que determina e executa uma
sequência de ajustes nos geradores sı́ncronos do sistema para corrigir as violações de
tensão. Para determinar os ajustes é desenvolvida uma metodologia de controle baseada
na estimativa de variação na geração de potência reativa, informação extraı́da a partir
da matriz Jacobiana reduzida (JQV ) [Lage 2013]. A aplicação da metodologia define o
conjunto de barras de controle a serem ajustadas, bem como estabelece os ajustes nas
magnitudes de tensão dos geradores sı́ncronos para modificar o despacho de potência
reativa e mostrar as perdas no sistema de potência ativa.
Portanto, o restante do trabalho está organizado da seguinte forma: a Seção 2
apresenta a abordagem proposta para o controle da magnitude de tensão e descreve a
metodologia de controle desenvolvida; a Seção 3 apresenta as simulações computacionais
realizadas no sistema IEEE (Institute of Electrical and Eletronic Engineers) de 57 barras
e os resultados obtidos; a Seção 4 apresenta as conclusões.
2. Abordagem de Controle Proposta
Nesta seção é apresentada a abordagem proposta para o controle da magnitude de tensão

em sistemas de transmissão de energia elétrica, explicitando-se cada um dos componentes
desenvolvidos para a determinação da sequência de ajustes nas variáveis de controle.
2.1. Gestor de Controle
A operação de um sistema elétrico de potência requer o desenvolvimento de técnicas

de controle apropriadas para permitir a entrega de energia elétrica aos consumidores em
conformidade com padrões de segurança operacional [Niknam et al. 2013]. A faixa de
magnitude adequada utilizada nesse trabalho é definida pela ONS (Operador Nacional de
Sistema Elétrico) e corresponde aos valores [0, 95; 1, 05] em p.u.
Para a abordagem funcionar o Gestor de Controle calcula o Fluxo de Carga (com
tap fixo) para determinar as magnitudes de tensão nas barras de carga do sistema. Caso
haja magnitudes de tensão fora da faixa adequada, o Gestor de Controle aciona a abor-
dagem de controle aqui proposta, que aplica uma metodologia e define que ajustes nas
magnitudes de tensão serão aplicados às barras de controle a fim de produzir o despacho
de potência reativa.
582
2.1.1. Definição da abordagem
O funcionamento da metodologia de controle considerada é baseado na matriz Jacobiana

reduzida (JQV ), a qual é obtida a partir da matriz Jacobiana J (θ, V ) das equações de
balanço de potência (1.1) e (1.2) [Lage 2013] para todas as barras do sistema.
Essas equações de balanço podem ser aproximadas linearmente por (1).

∆P (θ, V ) ∆θ
= J (θ, V ) (1)
∆Q (θ, V ) ∆V
Para encontrar a relação entre variações nas injeções de potência reativa com variações
nas magnitudes de tensão, desconsidera-se que as injeções de potência ativa variem
(∆P (θ, V ) = 0). Dessa forma, consideram-se apenas as variações de potência rea-
tiva (∆Q (θ, V )) como resultantes da combinação entre a matriz Jacobiana J (θ, V ) das
equações de balanço de potência com as variações nos ângulos de fase (∆θ) e nas mag-
nitudes de tensão (∆V ).

0 ∆θ
= J (θ, V ) (2)
∆Q (θ, V ) ∆V
Considerando que:
" ∂P ∂P #
∂θ ∂V J1 J2
J (θ, V ) = = (3)
∂Q ∂Q J3 J4
∂θ ∂V
a redução de (2) em termos de ∆Q e ∆V resulta em:
∆Q = J4 − (J3 J1−1 J2 ) ∆V.

(4)
Dessa forma, tem-se que:
JQV = J4 − (J3 J1−1 J2 ), (5)
Após o cálculo do Fluxo de Carga pelo Gestor de Controle, as magnitudes e os

ângulos de fase das tensões da rede elétrica são conhecidos e a matriz JQV pode ser
calculada. Com essas informações a Metodologia de Controle em execução determina o
conjunto de barras controle (ρ) a ser ajustado caso exista violações de tensão.
A metodologia de determinação da sequência de ajustes no controle da magnitude
de tensão são aqui apresentadas para corrigir as violações de tensão nas barras de carga de
um sistema de transmissão de energia elétrica, e todas recebem como entrada os vetores
∆VC e ∆Q, calculados de acordo com (6), e a matriz JQV , calculada de acordo com (5),
resultando em (7).
∆QG = JQV ∆VC (6)
−1
∆VG = JQV ∆QG (7)
583
2.1.2. Funcionamento da Abordagem
A metodologia de controle desenvolvida é denominada MaxQ e descrita no Algoritmo 1,

e determina as maiores variações nas injeções de potência reativa (∆Q) que devem ser in-
jetadas individualmente pelas barras de controle para corrigir violações de tensão (∆VC ).
Inicialmente, ela determina a barra i que possui a maior violação de tensão (Passo 2),
em seguida a barra de geração j, com a maior variação de injeção de potência reativa
estimada por max(∆QG ) (Passo 3). O vetor dos incrementos nas magnitudes de tensão
nas barras de controle (∆VG ), para injetar a potência reativa necessária, é calculado no
(Passo 4).
Algoritmo 1 Metodologia MaxQ

1: function M AX Q(∆VC , ∆QG , JQV )
2: i ← max(∆VC )
3: j ← max(∆QG )
−1
4: ∆VG ← JQV ∆QG
5: return ∆VG
6: end function
Apresenta-se agora o funcionamento da abordagem proposta no Algoritmo 2. A

princı́pio, são determinadas as violações de tensão para todas as barras de carga i (Passos 1
a 3). Em seguida, é calculada a variação de potência reativa das barras de geração (∆QG )
(Passo 4). A metodologia de controle é executada (Passo 5) e, por fim, as magnitudes de
tensão de cada uma das Nρ barras de controle (Passos 6 a 8) são ajustadas.
Algoritmo 2 Funcionamento da Abordagem

1: for i ← 1 until NP Q do . Para todas as barras de carga.
2: ∆VC [i] ← |Vi − Vlim.viol. |
3: end for
4: ∆QG ← JQV ∆VC
5: ∆VG ← MaxQ(∆VC , ∆QG , JQV )
6: for n ← 1 until Nρ do . Para todas as barras de controle a serem ajustadas.
7: VGj [n] ← VGj [n] + ∆VGj [n]
8: end for
2.2. Nós de Controle

A tarefa executada por um Nó de Controle é determinada pela metodologia MaxQ. O Nó
de Controle recebe essa informação como um comando e executa o ajuste na magnitude
de tensão no gerador conectado à barra. Após executar a operação de controle, o Nó de
Controle registra a ação executada, uma vez que esta informação torna-se importante para
realização de análises sobre o funcionamento da abordagem, com o intuito de comparar o
quanto de potência foi realmente injetado e a quantidade que foi estimada a ser gerada.
No intuito de avaliar a aplicação da abordagem proposta para o controle da magnitude
de tensão, são apresentados os cenários operacionais com violações de magnitude de
tensão. A determinação desses cenários é feita por meio de alterações nas magnitudes de
tensão das barras no conjunto de barras de controle G = {1, 2, 3, 6, 8, 9, 12}. Todas as
simulações são realizadas para os sistemas IEEE de e 57 barras que representa uma porção
do sistema elétrico localizado na Região Centro-Oeste dos Estados Unidos [IEEE 1993].
584
Para avaliar a eficácia da abordagem proposta, os seguintes resultados são apresentados:

despacho de potência reativa adicional para eliminar violações de tensão, ajustes nas mag-
nitudes de tensão nas barras de controle e perdas de potência ativa no sistema à medida
que os ajustes são realizados.
A Tabela 1 apresenta os valores (Vk (p.u.), θk (graus), Pk (M W ), Qk (M V ar))
que caracterizam o estado das barras dos sistema, além disso são considerados ativos
todos os taps fixos do sistema. Na Tabela 1 são exibidas apenas as barras que foram
alteradas para se obter as violações de tensão.
Tabela 1. Dados do Cenário de Teste.

2 1,01364902 3,00000 88,00000 0,00000 -17,00000
3 1,00000000 41,00000 21,00000 40,00000 59,61454
6 0,98305469 75,00000 2,00000 0,00000 25,00000
8 1,00000000 150,00000 22,00000 450,00000 64,74825
9 0,97227140 121,00000 26,00000 0,00000 9,00000
12 1,00000000 377,00000 24,00000 310,00000 112,26267
19 0,98207031 0,00000 0,00000 0,00000 0,00000
20 0,96398089 2,30000 0,20000 0,00000 0,00000
30 0,96869163 3,60000 1,20000 0,00000 0,00000
31 0,94621160 5,80000 1,80000 0,00000 0,00000
45 1,02867853 7,10000 4,40000 0,00000 0,00000
46 1,04840830 7,10000 4,40000 0,00000 0,00000
47 1,02147894 29,70000 13,60000 0,00000 0,00000
3.1. Correção Executada pela Metodologia MaxQ
No cenário de teste, as barras 31 e 46 possuem violações de tensão. Inicialmente, apenas

a barra 31 possui violação (V31 = 0, 94621) e a metodologia usa a coluna 31 da matriz
−1
JQV (Ajuste 1) para determinar a barra de controle j. Posteriormente a barra 31 possui o
valor da magnitude de tensão dentro dos limites desejados e a barra 46 passa a apresentar
−1
violação de tensão (V46 = 1.05249), então a coluna 46 da matriz JQV é aplicada para
determinar o Ajuste 2. Finalmente, a coluna 31, em virtude desta barra se encontrar em
subtensão (V31 = 0.94765), é utilizada para determinação do último ajuste.
A Tabela 2 exibe a estimação de variação de potência reativa para a metodologia
MaxQ.
Tabela 2. Estimativa de Variação de Potência Reativa (em p.u.).

Barra (k) Ajuste 0 Ajuste 1 Ajuste 2 Ajuste 3
1 0.0000447251 0.0000021768 -0.000454656 0.0000095122
3 -0.000015041 -0.000003138 0.0001286015 -0.000003098
8 0.0000008151 0.0000045108 0.0000348831 0.0000001628
12 -0.000001136 -0.000024985 -0.000229435 -0.000000243
A Tabela 3 exibe o Estado Final do Sistema após a execução das sequência de

ajustes e com todas as magnitudes de tensão dentro dos limites adequados de funciona-
mento.
585
Tabela 3. Estado do Sistema após Execução da Sequência de Ajustes Definida

pela Metodologia MaxQ.
1 1.05000000 55.00000 17.00000 0.00000 183.38454
2 1.01819877 3.00000 88.00000 0.00000 -17.00000
3 0.98700368 41.00000 21.00000 40.00000 1.15834
4 0.98508870 0.00000 0.00000 0.00000 0.00000
5 0.98415721 13.00000 4.00000 0.00000 0.00000
6 0.98924786 75.00000 2.00000 0.00000 25.00000
7 0.99592197 0.00000 0.00000 0.00000 0.00000
8 1.02000007 150.00000 22.00000 450.00000 100.15253
9 0.98352313 121.00000 26.00000 0.00000 9.00000
12 1.00000000 377.00000 24.00000 310.00000 93.50252
14 0.96448050 10.50000 5.30000 0.00000 0.00000
31 0.95232645 5.80000 1.80000 0.00000 0.00000
46 1.04995139 7.10000 4.40000 0.00000 0.00000
57 0.96282960 6.70000 2.00000 0.00000 0.00000
Por fim, o despacho de potência reativa nas barras de controle, após a execução dos
ajustes definidos pela metodologia MaxQ para corrigir a violação de tensão nas barras 31 e
46, é apresentado na Tabela 4. Os ajustes são executados nas barras 8 e 12, que possuem
os maiores ı́ndices de sensibilidade com relação as barras 31 e 36, respectivamente. A
barra 8 injeta potência reativa para corrigir a magnitude de tensão da barra 31, enquanto
a barra 12 absorve potência reativa para corrigir a violação de tensão da barra 46.
Tabela 4. Geração de Potência Reativa das Barras de Controle para a Metodologia

MaxQ.
Barra (k) Ajuste 0 Ajuste 1 Ajuste 2 Ajuste 3 Ajuste 4
1 141.88571 166.86437 165.77217 184.48835 183.38454
2 -17.00000 -17.00000 -17.00000 -17.00000 -17.00000
3 59.61454 45.06537 38.37173 7.73706 1.15834
6 25.00000 25.00000 25.00000 25.00000 25.00000
8 64.74825 63.64652 77.32953 86.08217 100.15253
9 9.00000 9.00000 9.00000 9.00000 9.00000
12 112.26267 102.14531 94.69987 100.93049 93.50252
3.2. Perdas de Potência Ativa
As perdas de potência ativa, à medida que os despachos de potência reativa foram execu-
tados, são ilustradas na Figura 1. A metodologia de controle, executa dois ajustes na barra
8 e um ajuste na barra 12 para corrigir a violação de tensão e reduz a perda de potência de
28,37 M W para 27,79 M W . Em tal cenário de testes, é possı́vel concluir que a estimação
da variação na geração de potência reativa é capaz de conduzir as magnitudes de tensão
violadas à faixa de operação adequada.
586
Perda de Potência Ativa (MW)

28.4
28.2
28
27.8
0 1 2 3 4
Passo
MaxQ
Figura 1. Perdas de Potência Ativa em Função dos Ajustes.
4. Conclusões
A eficácia da abordagem proposta, no que se refere a análise elétrica, é avaliada de acordo
com o despacho de potência reativa realizado para eliminar as violações de tensão; os
ajustes nas magnitudes de tensão nas barras de controle e as perdas de potência ativa no
sistema à medida que os ajustes são realizados. Então, determina-se o conjunto de barras
de controle a serem operadas e o quanto variar na injeção de potência reativa de cada uma
delas. Para a correção das violações de magnitude de tensão o Gestor de Controle executa
o Fluxo de Carga e determina o estado da rede elétrica. Em seguida, aplica a metodologia
MaxQ para definir as barras de controle a serem operadas e a sequência de ajustes a serem
realizados.
Baseado nos resultados obtidos por meio da execução dos ajustes no despacho de
potência reativa para controlar as magnitudes de tensão violadas nos cenários teste IEEE
57 barras simulado, é possı́vel justificar as contribuições da abordagem apresentada pelos
seguintes itens: determinação de uma sequência de ajustes que, ao serem executados
nos dispositivos de controle do sistema elétrico, foram capazes de corrigir as violações
nas magnitudes de tensão do cenário de teste e a metodologia de controle baseadas na
máxima variação da injeção de potência reativa calculados pela matriz JQV , estabelece os
ajustes nas magnitudes de tensão a serem executados nas barras de controle para alterar o
despacho de potência reativa do sistema.
Referências
Calderaro, V., Galdi, V., Lamberti, F., Piccolo, A., and Graditi, G. (2014). Voltage support
control of unbalanced distribution systems by reactive power regulation. In 2014 IEEE
PES Innovative Smart Grid Technologies Conference Europe (ISGT-Europe), pages
1–5. IEEE.
Capitanescu, F., Bilibin, I., and Romero Ramos, E. (2014). A comprehensive centra-
lized approach for voltage constraints management in active distribution grid. IEEE
Transactions on Power Systems, 29(2):933–942.
Chen, S., Hu, W., Su, C., Zhang, X., and Chen, Z. (2015). Optimal reactive power and
voltage control in distribution networks with distributed generators by fuzzy adaptive
hybrid particle swarm optimisation method. IET Generation, Transmission &
Distribution.
Eremia, M. and Shahidehpour, M. (2013). Handbook of electrical power system dyna-
mics: modeling, stability, and control, volume 92. John Wiley & Sons.
IEEE (1993). 57 bus power flow test case.
587
Lage, G. G. (2013). O fluxo de potência ótimo reativo com variáveis de controle discretas
e restrições de atuação de dispositivos de controle de tensão. PhD thesis, Universidade
de São Paulo.
Niknam, T., Narimani, M., Azizipanah-Abarghooee, R., and Bahmani-Firouzi, B. (2013).
Multiobjective optimal reactive power dispatch and voltage control: a new opposition-
based self-adaptive modified gravitational search algorithm. IEEE Systems Journal,
7(4):742–753.
Paramasivam, M., Dasgupta, S., Ajjarapu, V., and Vaidya, U. (2015). Contingency analy-
sis and identification of dynamic voltage control areas. IEEE Transactions on Power
Systems, 30(6):2974–2983.
Xu, Y., Zhang, W., Liu, W., and Ferrese, F. (2012). Multiagent-based reinforcement
learning for optimal reactive power dispatch. IEEE Transactions on Systems, Man,
and Cybernetics, Part C (Applications and Reviews), 42(6):1742–1751.
588
Fundamentos da Aprendizagem Cooperativa Aplicados ao

Ensino de Lógica de Programação
Brena Kelly S. Lima1 , Victória Tomé Oliveira1 ,
Antônio Márcio A. Almeida1 , Magdiel Campelo A. de Sousa1
1
Engenharia de Computação – Universidade Federal do Ceará (UFC)
Campus Mucambinho – Sobral – CE – Brasil
Abstract. Educational robotics is a tool that has been used to create a lear-
ning environment based on the cooperative learning model. This work shows
the use of the Lego R Mindstorms R NXT 2.0 robotics kit as a methodology for
teaching learning in programming logic, being applied to students who are new
to Computer Engineering. The objective of the project was to promote the lear-
ning and sharing of knowledge through groups of engineering students, making
it possible to consolidate the contents of programming logic seen in the class-
room. The main idea is to get students to develop their methods, concepts and
strategies, offering the opportunity for a concrete and collaborative experience.
In this model, students together become problem solvers constructors involving
programming logic by developing the ability to discover, experiment and learn
by interacting. In this work, we will present some practical examples made in
the classroom, as well as the methodology for development according to the
foundations of cooperative learning.
Resumo. A robótica educacional é uma ferramenta que vem sendo utilizada

para criar um ambiente de aprendizado, baseado no modelo de aprendi-
zagem cooperativa. Este trabalho mostra a utilização do kit de robótica
Lego R Mindstorms R NXT 2.0, como metodologia de ensino em lógica de
programação, sendo aplicada aos alunos iniciantes do curso de Engenharia
de Computação. O objetivo do projeto foi promover o aprendizado e o com-
partilhamento de conhecimento através de grupos de estudantes de engenha-
ria, tornando possı́vel a consolidação dos conteúdos de lógica de programação
vistos em sala de aula. A ideia principal é fazer com que os alunos desenvol-
vam seus métodos, conceitos e estratégias, oferecendo a oportunidade de uma
experiência concreta e colaborativa. Nesse modelo, os alunos em conjunto,
passam a ser construtores de resoluções de problemas práticos envolvendo a
lógica de programação desenvolvendo a capacidade para descobrir, experimen-
tar e aprender interagindo. Neste trabalho, serão apresentados alguns exemplos
práticos realizados em sala de aula, bem como a metodologia para o desenvol-
vimento de acordo com os fundamentos da aprendizagem cooperativa.
1. Introdução
O modelo instrucionista ainda é o modelo mais utilizado na aprendizagem brasileira, nele
o discente assume o papel passivo no processo de aprendizagem, fazendo com que suas
589
fontes provedoras de conhecimento em sala de aula sejam o apenas o docente e o material

de estudo que o mesmo repassa aos discentes.
A ausência de metodologias participativas e o uso de métodos de ensino tradicio-
nais nas escolas fazem com que os alunos participem cada vez mais com atividades indi-
vidualistas. Essas metodologias reforçam a concorrência e o sentimento de baixa eficácia
pelos que obtêm menos aproveitamento nos estudos, reforçando a exclusão social, além
de não preparar os jovens para os desafios e exigências da sociedade.
Os métodos de ensino tradicionais têm um foco conteudista e na transmissão de
conhecimento, resultando num estudante receptor, sem interação com o objeto de estudo e
com outros alunos. A exposição verbal do conteúdo é o principal meio de aprendizagem,
em que alunos se portam com cadernos e lápis na mão, esperando pelos ensinamentos do
professor [Rogers 1977]. Esse tipo de metodologia tem se mostrado pouco eficaz no que
diz respeito tanto a aquisição de conhecimento como para a aquisição de competências
interpessoais, necessárias para as relações em sociedade, para as relações trabalhistas e
também escolares.
O modelo instrucionista impede o crescimento intelectual do discente, partindo
do pressuposto que o seu papel está limitado apenas em receber informações de maneira
passiva sem agregar conhecimentos prévios aos do docente.
Na resolução diante desse problema, a Universidade Federal do Ceará promove
programas estruturados na metodologia de aprendizagem cooperativa [Maia et al. 2016].
A aprendizagem cooperativa aplica diversos programas dentro da universidade, e o mais
adotado são as células estudantis, visto isso foi promovida uma célula voltada a robótica
educacional, que tem como objetivo principal o aprendizado do aluno e o compartilha-
mento de conhecimentos entre os estudantes.
Com essa metodologia de ensino, é esperado que os alunos consigam realizar ta-
refas independentemente do professor está supervisionando ou não. A essência desses
métodos envolve o trabalho de alunos, em pequenos grupos, para que todos tenham opor-
tunidade de participar da tarefa coletiva designada [Cohen 1994].
O conhecimento ocorre numa relação dinâmica e não estática [Piaget 1970]. Todo
conhecimento é melhor compreendido se for possı́vel integrar conceitos teóricos a uma
aplicação prática. A robótica educacional é uma ferramenta que vem sendo aplicada no
processo de ensino-aprendizagem, visando complementar o modelo pedagógico instru-
cionista, propondo métodos de ensino cooperativos, já que a aprendizagem não decorre
unicamente do sujeito, nem do meio ou do objeto, mas sim da interação entre eles.
A utilização da robótica educacional em conjunto com o ensino de lógica de
programação melhora a qualidade do aprendizado através da junção do ensino teórico com
atividades práticas. Assim, os alunos aprendem de forma significativa, tendo a oportuni-
dade de participar de ações que proporcione a aplicação da teoria em situações práticas.
Com o uso da aprendizagem cooperativa os alunos podem se ajudar entre si, assim repas-
sando conhecimento e aprendendo com os membros do grupo.
O Kits de robótica são apresentados por educadores como ferramenta de auxı́lio
ao aprendizado. O Lego R Mindstorms R NXT é um kit bastante utilizado em atividades
educacionais, nele está contido sensores de toque, luz e ultrassônico, servomotores, diver-
590
sas peças de encaixe e um smart brick, este último trata-se de um bloco programável que
utiliza um software de desenvolvimento padrão NXT 2.0 Programming, sua programação
utiliza blocos de comandos bem estruturados e de fácil compreensão.
Além do conhecimento teórico, os alunos precisam desenvolver habilidades cog-
nitivas e cooperativas, para se tornarem profissionais qualificados, já que o mercado de
trabalho e a sociedade requerem profissionais que possam solucionar de forma eficiente e
clara os problemas que lhes são apresentados e que possam trabalhar de forma eficiente
em grupo.
Dessa forma, os discentes tem a oportunidade de aprender através de experiências
práticas em parceria com os outros discentes. Assim, alguns paradigmas tradicionais
como o modelo instrucionista seriam reformulados, proporcionando melhor flexibilidade
e experiências no processo de ensino-aprendizagem, pois os alunos se tornam construtores
do próprio conhecimento ao aprenderem pondo em prática os conceitos visto no decorrer
das células, sendo capazes de criar soluções e desenvolver estratégias.
Neste trabalho será apresentada a utilização da robótica educacional como fer-
ramenta de ensino no estudo de lógica de programação, tendo como base o modelo de
ensino da aprendizagem cooperativa, para os alunos do primeiro semestre do curso de
Engenharia de Computação.
2. Metodologia
2.1. Aprendizagem Cooperativa
A aprendizagem cooperativa pode ser definida como o conjunto de técnicas de ensino
em que os alunos trabalham em pequenos grupos, que são chamados de células, que tem
como principal objetivo a ajuda mútua. Essa ajuda se baseia na ideia de que o aluno
pode ensinar e aprender ao mesmo tempo. Todas as atividades são estruturadas por um
facilitador que é denominado articulador de célula, ele tem como função base acompanhar
e estabelecer o que será desenvolvido e estudado. Esse novo método de ensino permite
que os discentes possam interagir com seus colegas e com o articulador, gerando assim
autonomia e responsabilidade no aprendizado.
Para que a aprendizagem seja cooperativa é necessário que se verifiquem as se-
guintes caracterı́sticas especı́ficas que não atuam isoladamente, mas são ligadas, são elas:
interdependência positiva, responsabilidade pessoal, interação face a face, habilidade so-
cial e processamento de grupo [Johnson 2010].
A interdependência positiva caracteriza-se por um sentido de dependência mútua
que se cria entre os alunos da célula e que pode conseguir-se através da implementação
de estratégias especı́ficas de realização, onde se incluem a divisão de tarefas de
diferenciações de papéis, atribuição de recompensas, estabelecimento de objetivos co-
muns para todo a célula e realização de um único produto, referem ainda que a interde-
pendência positiva cria um compromisso com o sucesso de outras pessoas, para além do
seu próprio sucesso, o qual é a base da Aprendizagem Cooperativa. Referem ainda os
mesmos autores que, sem interdependência positiva, não há cooperação.
A segunda caracterı́stica é a responsabilidade pessoal, cada membro de célula é
responsável pela tarefa que lhe foi atribuı́da, ninguém pode se aproveitar do trabalho
do colega. A finalidade das células de aprendizagem cooperativa é que os estudantes
591
aprendam juntos para, posteriormente, poderem desempenharem as tarefas sozinhos, que

lhe são propostas [Johnson 2010].
A terceira caracterı́stica é a interação face a face, que pode ser definida por manter
os alunos numa situação fı́sica permitindo que cada um esteja frente a frente com os outros
e assim, os diferentes estudantes se encorajem e facilitem os esforços de cada um de modo
a alcançarem os esforços da célula [Marreiros 2001].
A este propósito, consideram que algumas atividades cognitivas e interpessoais só
podem realizar-se quando cada educando promove a aprendizagem dos seus companhei-
ros, explicando verbalmente como resolver os problemas (falar ajuda a pensar) ao analisar
conceitos que estão sendo aprendidos, ou ainda ensinar o que sabe aos seus companhei-
ros [Johnson 2010]. Deste modo, ao promover a aprendizagem pessoal, os membros da
célula adquirem um compromisso uns com os outros, assim como com os seus objetivos
comuns.
A quarta caracterı́stica é a habilidade social, onde os estudantes além de aprende-
rem o conteúdo da célula, também precisam aprender como trabalhar em grupo e viver
em sociedade. Os estudantes não nascem com as competências sociais, elas precisam ser
ensinadas e trabalhadas de forma a permitir os alunos seu aprendizado de forma correta e
sistemática [Pujolàs 2009]. Ele ainda diz que quanto maior for o nı́vel das competências
sociais atingidas por casa estudante da célula, maior será o rendimento e aproveitamento
da aprendizagem cooperativa.
A quinta caracterı́stica é a de processamento de grupo, que refere-se a uma
avaliação que ocorre quando os estudantes da célula analisam em que medida os objetivos
da célula estão sendo alcançados, tendo em conta as 12 regras definidas [Johnson 2010].
Devem ainda determinar quais as atitudes positivas e negativas e quais as condutas que a
célula deve manter ou modificar.
2.2. Robótica Educacional

Segundo Menezes [Menezes 2015] Dicionário Interativo da Educação Brasileira afirma
que robótica educacional é o termo utilizado para caracterizar ambientes de aprendiza-
gem que reúnem kits de montagem compostos por peças diversas, motores e sensores,
controláveis por computador que permitam programar de alguma forma o funcionamento
dos modelos montados.
A robótica educacional é utilizada como ferramenta de ensino que favorece o tra-
balho em equipe e a resolução de problemas cotidianos, onde oportuniza experiências de
aprendizagem que efetivamente contribuem para o desenvolvimento acadêmico, social e
cognitivo dos alunos. Colaborando para tornar o processo de aprendizagem dinâmico e
altamente significativo.
A robótica educacional tem como objetivo levar os alunos a descobrir o funcio-
namento da tecnologia de uma maneira divertida, desta forma, a robótica pode também
discutir o conhecimento acumulado e contribuir para que os alunos possam utilizar, do-
minar e desenvolver o pensamento crı́tico [Ragazzi 2017]. Os alunos serão levados, co-
letivamente à sugerirem e produzirem soluções para problemas do cotidiano, levando em
consideração as necessidades que os cercam, já que nossa intenção será colaborar para o
desenvolvimento de cidadãos ativos, capazes de manusear e compreender o uso de novas
592
tecnologias.
2.3. Lógica de Programação
Ao primeiro contato com a programação, os estudantes encontram um grande obstáculo
em aplicar seus conhecimentos e habilidades, gerando uma fonte de medo, frustração e
desistência do ramo [Castro 2003].
A disciplina de Programação Computacional ofertada no primeiro semestre do
curso de graduação em Engenharia de Computação em Sobral, é uma das disciplinas
onde ocorrem mais taxas de reprovação e desistência. Segundo os dados coletados em
parceria com a coordenação do curso de Engenharia de Computação sobre os calouros
no ano de 2016, no primeiro semestre, 2016.1, foi registrado um total de 27 reprovações
de uma turma de 55 alunos, enquanto no segundo semestre, 2016.2 foi registrado uma
quantidade de 30 reprovações de uma turma de 55 alunos.
Levando em consideração esses dados, fez-se necessário a pesquisa e
implementação de novas técnicas educacionais com o objetivo de reverter essa grande
quantidade de reprovações e tornar o aluno mais criativo e eficiente na solução de pro-
blemas. Utilizando a robótica educacional como mecanismo de ensino cooperativista, os
alunos em conjunto, passam a ser construtores de ideias e desenvolvem habilidades cog-
nitivas e sociais. Os alunos tem a oportunidade de colocar em prática a teoria vista em
sala não somente com o uso de simulações computacionais, mas também com o compar-
tilhamento de saberes ao criar robôs.
3. Metodologia aplicada ao ensino

Foi decidido que os encontros com alunos aconteceriam semanalmente. Um conjunto
de atividades para curso de robótica baseado no cronograma da disciplina Programação
Computacional utilizado pelo professor. Dessa maneira, os alunos teriam a oportunidade
de colocar em prática seus conhecimentos adquiridos em sala de aula, tornando possı́vel
incrementá-los ao solucionar problemas do cotidiano. Assim, quando o professor apli-
casse sua avaliação parcial os alunos teriam mais experiência, habilidades e criatividade
para resolução de problemas que lhes foram designados.
Inicialmente foi realizado um encontro para informar aos calouros a proposta do
curso de robótica educacional e qual seria a metodologia utilizada. Por se tratar de uma
turma grande a sala foi dividida em grupos, visto que a universidade não possui muitos
kits de robótica. Neste trabalho será apresentada uma das práticas realizadas no decorrer
do curso.
A construção de um robô seguidor de linha propõem que os alunos exercitem
de forma prática os conceitos de lógica de programação sobre estruturas de decisão e
repetição, proporcionando o aprendizado por meio da interação de um grupo de pes-
soas. Como solução, os alunos teriam que aplicar os conceitos teóricos de lógica de
programação, de certa forma, demonstrar criatividade ao ligar a parte lógica com a fı́sica,
pois eles teriam que montar o robô e desenvolver o programa de forma que o programa se
comunique corretamente com hardware.
Os alunos estudaram sobre como a metodologia de aprendizagem cooperativa se-
ria aplicada no decorrer das práticas, os instrutores repassaram de forma interativa e par-
ticipativa para os alunos como funciona a plataforma Lego , R seus componentes e como
593
a linguagem de alto nı́vel apresentada pelo professor da disciplina Programação Compu-

tacional seria implementada através da programação baseada em blocos do Lego . R
4. Resultados
Após o professor da disciplina Programação Computacional explicar em sala de aula so-
bre as estruturas de decisão e repetição, os instrutores do curso de robótica sugeriram uma
atividade aos alunos que consistia no desenvolvimento do robô seguidor de linha a fim de
aprofundar os conceitos vistos em sala.
A atividade realizada para aprimoramento dos conceitos de estruturas de decisão
e de repetição, consiste na elaboração de uma estrutura robótica que pudesse seguir um
percurso sob orientação do sensor de luminosidade acoplado a estrutura. O protótipo
montado no processo de desenvolvimento do robô seguidor de linha pode ser visto na
Figura 1.
Figura 1. Estrutura do robô seguidor de linha.
Na parte lógica, os alunos teriam que usar o conteúdo visto em sala de aula e apri-
morá-lo, buscando uma ligação entre a linguagem de alto nı́vel com a linguagem baseada
em blocos. Para alcançar tal resultado, o aluno deve tomar decisões, criar soluções, ser
agente ativo no processo de desenvolvimento do programa.
A Figura 2 apresenta o esquema lógico para a realização da atividade.
Figura 2. Estrutura lógica do robô seguidor de linha.
Como podemos ver na Figura 2, existe duas partes, a externa e a interna, que re-
presentam a parte do programa onde foi utilizado os conceitos de estrutura de repetição e
de decisão, respectivamente. No processo de desenvolvimento do esquema lógico os alu-
nos mostraram seus próprios métodos e estratégias. Aprenderam de forma colaborativa,
interagindo com os colegas e com o próprio objeto de estudo.
594
O método de aprendizagem cooperativa foi aplicado numa turma de 40 alunos,

porém apenas uma parcela desses alunos tiveram interesse em participar da célula coo-
perativa, um total de 15 alunos. No final da disciplina houveram 21 aprovações, onde
13 alunos eram participantes ativos da célula, apenas 2 alunos que frequentavam a célula
foram reprovados.
Analisando a Figura 3 apresenta uma taxa de aprovação e reprovação da turma
na disciplina Programação Computacional. A célula de robótica ajudou os membros a
serem aprovados na disciplina, tendo assim 87% de aprovação na disciplina, enquanto os
25 alunos que não participaram da célula tiveram apenas 32% de aprovação.
Figura 3. Taxa de aprovação e reprovação. a) Alunos que participaram da célula,

b) Alunos que não participaram da célula
No final do semestre letivo foi realizado uma pesquisa de satisfação com os 15

alunos que participaram do projeto. A Figura 4 apresenta o resultado desta avaliação. Na
avaliação, os alunos tinham que classificar de 0 (sem relevância) a 5 (bastante relevante)
o nı́vel de relevância da célula de aprendizagem cooperativa para o ensino de lógica de
programação. Como podemos ver, 60% dos alunos que participaram da célula avaliaram
como sendo um método muito relevante.
Figura 4. Avaliação da aplicação do método aprendizagem cooperativa
5. Conclusão
Neste trabalho fizemos uso da robótica como ferramenta de ensino baseado nas perspecti-
vas cooperativistas para o ensino de lógica de programação, com o objetivo de aperfeiçoar
o aprendizado do aluno, já que a disciplina de lógica de programação, em muitos casos, é
vista como um obstáculo.
595
O modelo de aprendizagem cooperativa no processo de aprendizagem não ocorre

somente através do indivı́duo, e nem apenas com meios externos, mas ele flui através
da interação dos indivı́duos, juntamente com o meio externo. Os alunos participantes
do projeto tiveram a chance de consolidar o conhecimento sobre lógica de programação
através da realização de práticas. Com o auxı́lio da robótica educacional ligada ao método
cooperativista foi possı́vel aplicar de forma prática, interativa e criativa os conceitos vistos
em sala de aula.
Utilizando a robótica em conjunto com os fundamentos de aprendizagem coope-
rativa, os alunos participantes da célula de aprendizagem tiveram a oportunidade de for-
talecer seus conhecimentos em lógica de programação através de experiências práticas.
Dessa forma, contribuindo para o despertar de interesse em relação ao estudo de lógica
de programação e proporcionando melhores resultados durante o decorrer da disciplina.
Referências
Castro, T. C. e. a. (2003). Utilizando programação funcional em disciplinas introdutórias
de computação. Anais do WEI 2003, Brasil.
Cohen, E. G. (1994). Restructuring the classroom: conditions for productive small groups.
Review of Educational Research, v. 64, n. 1, p. 1-35.
Johnson, David. W. ; Johnson Roger. T.; Smit, K. A. (2010). A aprendizagem cooperativa
retorna as faculdades. [Disponı́vel] http://unjobs.org/authors/roger-t.-johnson [Acesso
em: 20-07-2017].
Maia, A., Pereira, A., and Oliveira, A. (2016). Aprendizagem cooperativa e a evasão
acadêmica. Periodicos.ufc.br, page 1.
Marreiros, Antónia; Fonseca, J. C. J. (2001). O trabalho cientı́fico em ambiente de apren-
dizagem cooperativa. In Revista da Educação. Vol. X no 2 99-112.
Menezes, Ebenezer Takuno de; Santos, T. H. d. (2015). Verbete robótica educa-
cional. dicionário interativo da educação brasileira - educabrasil. [Disponı́vel]
http://www.educabrasil.com.br/robotica-educacional/ [Acesso em: 19-07-2017].
Piaget, J. (1970). O Estruturalismo. Trad. Moacir R. de Amorim. São Paulo: Difel.
Pujolàs, M. P. (2009). Aprendizaje cooperativo y educación inclusiva: Una forma práctica
de aprender juntos alumnos diferentes. VI Jornadas de cooperación educativa con ibe-
roamérica sobre educación especial e inclusión Educativa. Barcelona: Universidade de
Vic. [Disponı́vel] http://www.educacion.es/dctm/ministerio/educacion/actividad-
internacional/cooperacion-educativa/2009-ponencia-jornadas-antiguas-pere-
2.pdf?documentId=0901e72b8008d13f [Acesso em: 20-07-2017].
Ragazzi, V. (2017). Robótica na escola: é pra já. [Disponı́vel]
https://microsoft.com/brasil/educacao/parceiro/robotica.mspx [Acesso em: 24-
07-2017].
Rogers, Carl R e Rosemberg, R. L. (1977). A pessoa como centro. Universidade de São
Paulo.
596
Processo de descoberta de conhecimento em base de dados de

Microcefalia utilizando Algoritmos Não-Supervisionados
Lúcia E.S. Silva¹, Vinicius P. Machado¹, Bruno V.A. de Lima¹, Malena C. de M.
Assunção¹, Aline M.L. Silva¹, Francisco C.I. Filho¹
¹Departamento de Informática e Estatística – Universidade Federal do Piauí – UFPI

Caixa Postal 15.064 – 91.501-970 – Teresina – Piauí – Brasil
[email protected]
Abstract. This article presents the application of the Knowledge Discovery

Process (KDD) in a database with information about the pregnancies in which
there was the presence of microcephaly. The process focuses on the analysis of
the clusters formed by the non-supervised algorithms k-means, Cobweb and
Self-organized Map, in order to find relations between the grouped data that
indicate potential causes for the disease. The results suggest a possible relation
between the history of abortions prior to the pregnancy in question, together
with the presence of Zica symptoms, with the occurrence of congenital
microcephaly.
Resumo. Este artigo apresenta a aplicação do Processo de Descoberta de

Conhecimento (KDD) em uma base de dados com informações acerca do de
gestações nas quais houveram a presença de microcefalia. O processo tem
como foco a análise dos agrupamentos formados pelos algoritmos não-
supervisionados k-means, Cobweb e Rede de Kohonen, a fim de encontrar
relações entre os dados agrupados que indiquem potenciais causas para a
doença. Os resultados obtidos sugerem a possível relação entre o histórico de
abortos prévios à gestação em questão, aliado à presença de sintomas de Zica,
com a ocorrência de microcefalia congênita.
1. Introdução
A microcefalia trata-se de uma malformação congênita, em que o cérebro não se

desenvolve de maneira adequada. Neste caso, os bebês nascem com perímetro cefálico
menor que o normal. Essa malformação pode ser efeito de uma série de fatores de
diferentes origens, como substâncias químicas e agentes biológicos, como bactérias,
vírus e radiação. O surto de microcefalia que atingiu o Brasil nos últimos anos motivou
estudos quem confirmaram a associação entre a presença de doenças tropicais, como a
infecção pelo Zica Vírus, e casos de microcefalia. Tais descobertas têm estimulado a
continuidade de estudos que identifiquem as causas da doença.
O volume de dados produzidos pelas clínicas e agências de saúde frente à

ocorrência de uma endemia podem ser analisados a fim de buscar as possíveis causas e
auxiliar o processo de contenção da doença. Na área da Ciência da Computação, a
597
análise de um grande volume de dados pode ser feita através do Processo se Descoberta
de Conhecimento - ou Knowledge Discovery on Databases (KDD), um processo de
pesquisa e manipulação em base de dados, divididos em várias etapas, que tem como
objetivo produzir conhecimento a partir das informações fornecidas.
Neste trabalho, tem-se como objetivo a descoberta de conhecimento em uma base

de dados com informações à cerca de gestações em que houve a ocorrência de
microcefalia através da aplicação do KDD.
2. Processo de Descoberta de Conhecimento
O processo de descoberta de conhecimento em base de dados - ou Knowledge Discovery

on Databases (KDD) - é um processo de várias etapas, não trivial, interativo e iterativo,
para identificação de padrões compreensíveis, válidos, novos e potencialmente úteis a
partir de grandes conjuntos de dados [Fayyad, 1996].
As etapas do KDD podem ser divididas em três: pré-processamento, mineração de
dados e pós-processamento. O pré-processamento é a etapa onde a base de dados será
preparada através de medidas de limpeza e manipulação de dados com o objetivo de
otimizar resultados alcançados pelos algoritmos escolhidos para mineração. Em
contrapartida, enquanto o pré-processamento prepara os dados para a entrada dos
algoritmos, o pós-processamento tem como objetivo analisar os resultados obtidos pela
mineração de dados. Nesta etapa os resultados gerados precisam ser avaliados e
interpretados de maneira que possam ser compreendidos pelos usuários, tornando-os úteis
para o propósito de sua análise.
O foco do processo de KDD é a extração de informações que ocorre na mineração de
dados. Esta é a etapa do KDD que consiste na aplicação de algoritmos específicos, que
extraem padrões a partir dos dados [Fayyad, 1996]. Nessa etapa devem ser escolhidos os
algoritmos a serem utilizados na base de dados de acordo com o objetivo da extração de
conhecimento. Para isso, podemos utilizar as técnicas de Aprendizado de Máquina (AM),
abordadas posteriormente.
3. Aprendizado de Máquina
A área de AM é considerada um ramo da área de Inteligência Artificial (IA), sendo uma

área especializada no estudo e construção de sistemas que sejam capazes de aprender de
forma automatizada a partir de dados [Brink; Richards 2014, apud De Lima, 2015]. As
técnicas de aprendizagem de máquina podem ser dividias em quatro grupos: aprendizado
por reforço, supervisionado, semissupervisionado e não-supervisionado.
Com exceção do aprendizado por reforço que se baseia na recompensa numérica para
os acertos de um agente, os demais grupos diferem entre si pelo tipo de entrada recebia,
sendo estas dados rotulados, parcialmente rotulados e não rotulados, respectivamente.
Nota-se que a existência de um rótulo previamente conhecido para as instâncias da base
de dados pode determinar a escolha dos algoritmos utilizados para a mineração de dados.
Em razão disto, a clusterização, método não-supervisionado que tem como objetivo a
formação de grupos a partir dos dados de entrada, foi escolhida como abordagem para a
598
mineração da base estudada através dos algoritmos de clusterização k-means, Cobweb e

Rede de Kohonem.
3.1 Algoritmo k-means
O algoritmo k-means, apresentado por MacQueen em 1967, utiliza os valores numéricos
de uma base de dados n-dimensional para determinar o agrupamento dos dados em k
grupos, sendo k um parâmetro de entrada, de acordo com a distância euclidiana entre eles.
Inicialmente o algoritmo escolhe aleatoriamente k centroides. Para cada iteração,
deve-se calcular a distância euclidiana entre cada par dado-centroide atribuindo o dado ao
grupo do centroide que apresentar a menor distância. Após a divisão, o centroide do grupo
é recalculado a fim de que seu valor seja o mais próximo de uma média entre os valores
do grupo. O algoritmo encerra quando não há alterações nos valores dos centroides e,
consequentemente, nos grupos; ou atinja um número predeterminado de iterações.
3.2 Algoritmo Cobweb
O Cobweb [Fisher, 1987] é um algoritmo não supervisionado que emprega um método

de agrupamento hierárquico com o objetivo de obter grupos com máxima similaridade
intra-grupo e dissimilaridade inter-grupos.
O Cobweb organiza incrementalmente os objetos em uma árvore que é uma
estrutura onde cada um dos nodos da árvore representa um conceito que é resumido pelas
distribuições dos valores dos atributos dos objetos pertencentes à subárvore do nodo. A
raiz representa o conceito mais amplo que abrange todo o conjunto de objetos. [Ferreira
et al. 2005]
3.3 Algoritmo Rede de Kohonen
A Rede de Kohonen ou Mapas Auto Organizáveis [Haykin, 2001], tem como princípio a
aprendizagem competitiva, simulando processos específicos do cérebro humano na
aprendizagem por respostas sensoriais. Na rede de Kohonen os neurônios são organizados
em uma grade, esta geralmente bidimensional. Essa grade tem a forma de uma superfície
plana, onde os neurônios de saída estão organizados em linhas e colunas [Júnior and
Montgomery 2007].
Baseado na teoria de que o cérebro humano responde à entradas sensoriais
diferentes mapeando-as em regiões especificas do cortéx cerebral, o algoritmo SOM
implementa um processo de competição entre os neurônios da rede, de modo que o
neurônio vencedor ajusta seus pesos para responder melhor ao estímulo recebido, bem
como a sua vizinhança topológica recebe ajustes num processo de cooperação. Assim, os
sinais de entrada apresentados à rede estimulam um grupo de neurônios na camada de
saída. Ao fim do treinamento, a rede de Kohonen pode agrupar os dados apresentados
como entrada de acordo com os neurônios estimulados na camada de saída.
599
3.4 Medidas de Avaliação de Agrupamento
A avaliação do resultado obtido na análise de um agrupamento é comumente chamada de

validação. Na validação do modelo de grupos resultantes de um algoritmo, tem-se o
objetivo de avaliar se esse modelo de fato representa a organização dos exemplares no
conjunto de dados sob análise [Halkidi, Batistaki e Vizirgiannis, 2001, apud Silva, Peres,
e Clodis, 2016]. Dentre os índices de avaliação de agrupamento mais populares está o
Índice de Silhueta Simplificado.
3.4.1 Índice de Silhueta Simplificado
Índice de Silhueta Simplificado (Hruschka et. al., 2004) é uma métrica para avaliação de
agrupamento que utiliza a relação entre a similaridade dos dados de um grupo e a
dissimilaridade entre dados de grupos distintos, podendo ser descrita pela equação:
𝑁
1
𝐼 = ∑ 𝑠(𝑖)
𝑁
𝑖=1
Para cada dado 𝑖 deve ser calculada a relação entre a distância de i para o centroide
de seu grupo – medida de similaridade, dado por a(i), e a distância média de i para o
centroide do grupo vizinho mais próximo – medida de dissimilaridade, dado por b(i), da
seguinte maneira:
𝑏(𝑖) − 𝑎(𝑖)
𝑠(𝑖) =
𝑚𝑎𝑥{𝑎(𝑖), 𝑏(𝑖)}
Podemos verificar que o valor do índice de silhueta simplificada deve variar no

intervalo de [-1,1], e quanto mais próximo de 1, mais definidos são os grupos, uma vez
que as distâncias a(i) são menores que as distâncias b(i).
4. Ferramentas
4.1 Weka
Os algoritmos utilizados na mineração de dados foram executados através da interface do

aplicativo WEKA - Waikato Environment for Knowledge Analysis [of Waikato 2011. O
WEKA é uma aplicação Java de KDD que contém uma série de algoritmos de
aprendizado de máquina, preparação e mineração de dados e validação de resultados,
desenvolvidos pela Universidade de Waikato na Nova Zelandia; um software livre e de
código aberto disponível na Web1, que além de uma interface gráfica de fácil usabilidade,
fornece relatórios, gráficos e informações analíticas e estatísticas dos dados apresentados.
4.2 Base de dados
O objeto de estudo deste trabalho é uma base de dados cujas informações estão
relacionadas às características de gestações nas quais houveram a presença de
1
http://www.cs.waikato.ac.nz/ml/weka
600
microcefalia, coletadas na região de Teresina-PI. A base de dados analisada contém 103

instâncias e 31 atributos, como mostra a Tabela 1.
Tabela 1. Atributos presentes na base de dados

DATA NASCIMENTO TIPO_PARTO TC CRANIO IDADE
CALCIFICACAO (TC2) PATERNA
SEXO SEMANAS ANTECEDENTES VACINAS EM
NASCIMENTO FAMILIARES DIA
TIPO MICROCEFALIA PERIMETRO CONSANGUINEIDADE FONTANELAS
CEFALICO
TRATAMENTO PESO_GRAMAS NUMERO FILHOS HABITACAO
PROCEDENCIA SUCCAO NUMERO ABORTOS RENDA
FAMILIAR
UF PARALISIA PRE NATAL BOLSA
CEREBRAL FAMILIA
INTERCORRENCIA_GRAVIDEZ CONVULCAO IDADE MATERNA PLANO
SAUDE
SINTOMAS ZIKA TC CRANIO ETIOLOGIA
ATROFIA (TC1)
5. Metodologia
A base de dados utilizada no estudo foi submetida ao pré-processamento de dados,

processo no qual foi modificada de forma a poder ser utilizada pelos algoritmos,
excluindo ainda atributos que não representavam importância para o estudo por não
apresentarem informações ou variações relevantes em seus valores, resultando em uma
base de 23 atributos.
Para mineração dos dados foram utilizados os três algoritmos descritos na seção
3. Dos quais os algoritmos k-means e Cobweb foram executados através da ferramenta
WEKA, descrita na sessão 4, enquanto para o algoritmo Rede de Kohonen houve a
necessidade de implementação, na linguagem de programação Java, uma vez que o
WEKA não apresenta suporte para este.
Após a execução dos algoritmos, utilizando como entrada a base de dados em
questão, avaliou-se os agrupamentos gerados através do índice de silhueta simplificada
descrito na sessão 3.4. Cada algoritmo foi executado 10 vezes, gerando um índice de
silhueta simplificada em cada execução, assim, para cada algoritmo, consideramos a
média dos índices obtidos.
Na etapa final, os melhores agrupamentos foram analisados a fim de encontrar
padrões que descrevam os grupos.
5. Resultados
Os resultados obtidos a partir dos agrupamentos gerados pelos algoritmos vistos nas
sessões anteriores foram avaliados segundo o Índice de Silhueta Simplificado (ISS), como
dito anteriormente, considerando-se a média de 10 execuções.
De acordo com os resultados obtidos pelo ISS, para o algoritmo K-means, o
melhor agrupamento ocorre quando o número de grupos é igual a 2, de igual modo para
601
o algoritmo SOM, sendo estes os únicos grupos formados por estes algoritmos cujo ISS
ultrapassa 0,2. O algoritmo Cobweb, por sua vez, demonstrou melhor desempenho, tendo
todos os resultados acima de 0,2; sendo o melhor deles 0,2955, quando o número de
grupos formado é igual a 3.
A análise do conteúdo do melhor agrupamento de cada algoritmo deu-se
observando os valores mais comuns para cada atributo em um mesmo grupo. Entende-se
que quanto mais invariável o valor de um atributo em um grupo, mais relevante ele foi
para determinar o mesmo. Desta forma, calculou-se a persistência de cada atributo como
sendo a porcentagem de instâncias do grupo onde um atributo apresenta o mesmo valor.
Posteriormente, foram considerados os cinco atributos com maiores valores de
persistência. Os resultados podem ser observados nas tabelas Tabela 2, Tabela 3, e Tabela
4.
Tabela 2. Atributos com valores mais persistentes para o algoritmo k-means
Grupo 1 Grupo 2
Atributo Persistência Valor Atributo Persistência Valor

(%) (%)
TRATAMENTO 97,05882 1 TIPO 91,42857 1
TIPO 83,82353 1 SINTOMAS 82,85714 0
ABORTOS 80,88235 0 SUCÇÃO 77,14286 1
SUCCAO 79,41176 1 SEXO 68,57143 2
TC2 77,94118 1 ABORTOS 68,57143 0
O melhor agrupamento, segundo o ISS, do algoritmo k-means gerou dois grupos

com 68 e 35 instâncias, respectivamente. Neste agrupamento, atributo Tratamento
apresentou a maior taxa de persistência, tanto do grupo, quanto entre todos os
agrupamentos. No grupo 1, o atributo assumiu o valor 1 em 97¨% das instâncias, e, apesar
de não estar entre os mais relevantes para a formação do grupo 2, é nele que todas as
instâncias para as quais este atributo assume o valor 2 estão agrupadas.
Tabela 3. Atributos com valores mais persistentes para o algoritmo Cobweb

Grupo 1 Grupo 2 Grupo 3
Atributo Persistência Valor Atributo Persistência Valor Atributo Persistência Valor

(%) (%) (%)
TIPO 88,57143 1 ABORTOS 91,66667 0 TIPO 90,47619 1
ABORTOS 75,71429 0 TC 1 91,66667 1 VACINAS 85,71429 1
TC2 72,85714 1 TC 2 83,33333 1 SINTOMAS 80,95238 0
SUCCAO 71,42857 1 IDADE 83,33333 2 IDADE 76,19048 2
MATERNA MATERNA
FILHOS 67,14286 1 PERIMETRO 83,33333 1 ABORTOS 71,42857 0
CEFÁLICO
O melhor agrupamento para o algoritmo Cobweb apresentou na saída 3 grupos de

70, 12 e 21 instâncias, respectivamente. Nesta execução os atributos relevantes para cada
602
grupo mostraram-se menos semelhantes que no agrupamento dado pelos outros dois
algoritmos.
Tabela 4. Atributos com valores mais persistentes para o algoritmo SOM
Grupo 1 Grupo 2
Atributo Persistência Valor Atributo Persistência Valor

(%) (%)
TIPO 87,69231 1 TIPO 84,21053 1
TRATAMENTO 87,69231 1 VACINAS 84,21053 1
SUCCAO 78,46154 1 SUCCAO 78,94737 1
ABORTOS 75,38462 0 ABORTOS 78,94737 0
TC2 70,76923 1 SINTOMAS 73,68421 0
O algoritmo SOM separou os dados em dois grupos com 65 e 38 instâncias,

respectivamente. Embora as taxas de persistência sejam diferentes, é notável a
similaridade entre os atributos que este algoritmo e o de k-means consideraram relevantes
em suas execuções. De maneira geral, esse foi o algoritmo que apresentou menores taxas
de persistência, justificadas pela menor similaridade intra-grupo apontada pelo menor
valor de ISS.
Ao comparar os três algoritmos podemos perceber a grande similaridade entre o
grupo 1 de todos eles indicando uma possível relação entre os atributos Tipo, Tratamento,
Sucção, Abortos, e TC 2, quando apresentados os valores 1, 1, 1, 0 e 1, respectivamente.
Ainda durante a análise dos resultados, com foco nos atributos citados acima,
constatamos que todos os algoritmos separaram em um mesmo grupo as instâncias nas
quais o atributo Tipo assume o valor 2. Essa informação não consta nas tabelas acima
pois, mesmo estando restritas a um grupo, a quantidade de instancias não representa a
maior persistência do atributo Tipo.
Uma segunda observação relaciona os atributos Aborto, Sintomas e Tipo; todas as
instâncias em que os dois primeiros atributos apresentam valor 1, o atributo Tipo também
assume o valor 1; em contrapartida, em dez das onze instancias em que o atributo Tipo
apresenta o valor 2, não há presença do valor 1 para o atributo Aborto e/ou para o atributo
Sintomas. Tal análise sugere a presença de microcefalia congênita 2 quando há histórico
de aborto3 e sintomas de zica4, e microcefalia não-congênita5 quando negado uma das
duas características. É importante ressaltar que as afirmações inversas não podem ser
feitas, ou seja, o atributo Tipo pode receber o valor 1 sem necessariamente implicar que
os atributos Aborto e Sintomas também recebam o mesmo valor; bem como presença do
2
Representado pelo atributo Tipo com valor 1.
3
O atributo Aborto recebe o valor 1 para histórico de um ou mais abortos, ou o valor 0 para nenhum
histórico de aborto.
4
O atributo Sintoma recebe o valor 1 quando há presença de sintomas de zica, e o valor 0 quando não há.
5
Representado pelo atributo Tipo com valor 2.
603
valor 1 nestes dois atributos não implica necessariamente na impossibilidade da presença

do valor 2 para o atributo Tipo.
6. Conclusão
Os resultados obtidos a partir da avaliação dos agrupamentos gerados pelos

algoritmos k-means, Cobweb e SOM, através do Índices de Silhueta Simplificada
implicaram em valores ainda pequenos quando comparados com o valor ótimo; 1,0. Por
ser um resultado comum para todos os algoritmos, entende-se que para melhora-lo é
necessário remodelar a base de dados utilizada.
Apesar disso, a avaliação dos agrupamentos destaca o algoritmo Cobweb, cujas
execuções geraram os melhores ISS, todos acima de 0,2. A análise dos resultados também
mostra que todos os algoritmos conseguiram formar agrupamentos com pelo menos dois
dos atributos relevantes diferentes entre os grupos, bem como a presença de uma relação
entre 5 dos 23 atributos - Tipo, Tratamento, Sucção, Abortos, e TC 2- em todas as
execuções.
Nos agrupamentos ainda podemos identificar uma implicação para o atributo Tipo
a partir dos atributos Aborto e Sintomas que sugere uma possível relação entre histórico
de abortos prévios à gravidez em questão e a presença de sintomas de Zica com a
ocorrência de microcefalia congênita.
Em relação à aplicação dos métodos de mineração de dados, os resultados foram
satisfatórios para as entradas fornecidas, porém a etapa de pós-processamento dos dados
pode alcançar melhores resultados se analisados por especialistas da área da qual
buscamos gerar conhecimento. Assim, uma análise científica na área da saúde faz-se
necessária para maiores conhecimentos a partir dos resultados alcançados por esse estudo.
7. Referências Bibliográficas
Da Silva, L.A., Peres, S.M. E Boscarioli, C. Introdução à Mineração de Dados: com

aplicações em R, 1.ed. Rio de Janeiro: Elsevier, 2016.
De Lima, B.V.A. Método Semisupervisionado de Rotulação e Classificação Utilizando
Agrupamento por Sementes e Classificadores. 2015. 99f. Dissertação (Mestrado em
Ciência da Computação) - Universidade Federal do Piauí, Teresina-PI. 2015.
Fayyad, U., Piatetsky-Shapiro, G. E Smyth, P. From Data Mining To Knowlegde
Discovery. American Association For Artificial Intelligence,1996.
Ferreira, G., Araujo, R., Orair, G., GonçAlves, L., Guedes, D., Ferreira, R., Furtado, V.,
E Junior, W. M. (2005). Paralelização eficiente deum algoritmo de agrupamento
hierárquico.
Fisher, D. H. Knowledge acquisition via incremental conceptual clustering. Machine
Learning, v. 2, p. 139–172, 1987.
Júnior, O. L. E Montgomery, E. Redes Neurais: Fundamentos e Aplicações com
Programas em C. Rio de Janeiro: Editora Ciência Moderna Ltda., 2007.
Of Waikato, U. Weka 3 Machine Learning Software in Java. University of Waikato, 2011.
604
Avaliação sobre Protocolos de Encaminhamento em Redes

Veiculares Tolerantes a Atrasos e Desconexões
Boaz Costa, Rodrigo Leal, Ivan Nascimento Filho, Patricia Drumond e Pablo Vieira
,[email protected] e [email protected]
Abstract. Vehicular Delay Tolerant Networks (VDTNs) are used in environ-

ments where usual Vehicular Networks are inefficient, such as remote places
that don’t have a stable connection. For this to be possible, specific routing pro-
tocols must be used. In this paper, there are compared some routing protocols
for indicating the best one in this context. The metrics used to measure the per-
formance of these protocols were: Delivery Probability, Network Overhead and
Average Latency. By analyzing these performance criteria, the Spray and Wait
protocol had the best performance, once it had better results for two out of three
metrics. This study also pointed that choosing the Spray and Wait protocol may
have a greater influence over the Delivery Probability, the Network Overhead
and the Packet Time to Live, which can guide network engineers when building
a VDTN.
Resumo. Redes Veiculares Tolerantes a Atrasos e Desconexões (VDTNs) são

usadas em ambientes nos quais as Redes Veiculares comuns são ineficientes,
como locais remotos que não possuem conexão constante. Para que isso seja
possı́vel, protocolos de encaminhamento de dados especı́ficos devem ser utiliza-
dos. Neste artigo, são comparados os protocolos de encaminhamento: Epide-
mic, First Contact, Maxprop e Spray and Wait a fim de apontar o melhor pro-
tocolo. As métricas usadas para medir o desempenho dos diferentes protocolos
foram: Probabilidade de Entrega dos pacotes, Sobrecarga da Rede e Latência
Média. Sob análise desses critérios, o protocolo Spray and Wait obteve o me-
lhor desempenho já que teve melhores resultados em duas das três métricas. O
estudo também apontou a escolha do Protocolo de encaminhamento como de
maior impacto na Probabilidade de Entrega, Sobrecarga da Rede e no número
de Tempo de Vida de Pacote na Latência Média da Rede, guiando engenheiros
na montagem de VDTNs.
1. Introdução
O constante aumento dos congestionamentos e acidentes de trânsito nas cidades causam
impactos negativos em diversas áreas, como na economia, no meio ambiente, na saúde,
dentre outras. A implementação das Redes Veiculares tem auxiliado na redução de aci-
dentes e outros percalços no trânsito, além de promover um controle de tráfego e aumento
de segurança nas rodovias [Naz et al. 2011].
605
Em algumas situações, existem veı́culos trafegando constantemente, e nem sem-

pre é possı́vel existir (ou estabelecer) conexões contı́nuas por um grande perı́odo de
tempo. Nesse contexto, as Redes Veiculares Tolerantes a Atrasos e Desconexões ou
VDTNs (Vehicular Delay Tolerant Network) podem ser usadas para substituir redes em
condições adversas [Câmara et al. 2011]. Para funcionamento das VDTNs, são utilizados
protocolos de encaminhamento especı́ficos, os quais possuem grande influência sobre a
eficiência de uma Rede Veicular [Zeng et al. 2013].
Baseado neste contexto, o presente artigo realiza um estudo sobre a eficiência de
protocolos de encaminhamento em redes VDTNs. As principais contribuições são:
• Avaliação de Desempenho de Protocolos em VDTNs;

• Mensuração de Impacto de Fatores sobre a Probabilidade de Entrega de VDTNs;
• Mensuração de Impacto de Fatores sobre a Latência Média de VDTNs;
• Mensuração de Impacto de Fatores sobre a Sobrecarga de Rede de VDTNs.
Os protocolos avaliados foram: Epidemic, First Contact, Maxprop e Spray and

Wait. O estudo realizado foi formado avaliando a Probabilidade de Entrega, Sobrecarga
da Rede e Latência Média. Os cenários de Redes Veiculares usados nos experimentos
foram variados conforme a densidade da rede (número de hosts), tempo de vida de cada
pacote e tempo de simulação. Complementando, esta pesquisa também aponta o impacto
desses fatores (descritos no perı́odo anterior) na Probabilidade de Entrega, Sobrecarga e
Latência a fim de guiar engenheiros na montagem e configuração de VDTNs.
Este artigo está estruturado da seguinte forma: a seção 2 apresenta o referencial
teórico utilizado neste trabalho; a seção 3 refere-se ao experimento de simulação utilizado
como base para avaliar o desempenho de cada protocolo; a seção 4 apresenta os resultados
obtidos; a seção 5 trata dos trabalhos relacionados com esta pesquisa e a seção 6 trata da
conclusão e de trabalhos futuros.
Esta seção é voltada para discussão dos conceitos deste trabalho. A presente seção discute,
especificamente, os protocolos de encaminhamento estudados. Considerando definições
de Spaho et al. (2016) e Nunes (2013), os protocolos são:
• Protocolo Epidemic: este protocolo funciona espalhando seu conteúdo para todos
os nós ao redor. Dois nós trocam mensagens para decidir se a mensagem não está
armazenada no outro. Após isso é feita uma verificação do espaço de armazena-
mento disponı́vel no nó e, caso tenha espaço, é enviada a mensagem.
• Protocolo First Contact: neste protocolo, os nós enviam as mensagens para o
primeiro nó que encontram, o que resulta em uma busca aleatória pelo destino.
• Protocolo de Maxprop: este prioriza o planejamento dos pacotes que serão trans-
mitidos a outros nós e os pacotes que serão descartados.
• Protocolo Spray and Wait: este protocolo se baseia em disseminar a mensagem e
aguardar algum resultado. Quando um nó retransmissor recebe uma cópia da men-
sagem, ele entra em fase de espera, na qual o retransmissor confirma determinada
mensagem até que o seu destino seja encontrado.
606
3. Experimentos
O simulador ONE1 (Opportunistic Network Environment) foi usado para simular o tráfego
de uma Rede Veicular na arquitetura Ad-hoc na cidade Helsinque na Finlândia. Por
padrão, o simulador fornece um tempo de simulação de 12 horas, 40 hosts divididos em
cinco grupos (três para veı́culos e dois para pedestres), TTL de 300 minutos, comunicação
entre nós do tipo Wi-Fi, velocidade de transmissão de 2 MB por segundo e tamanho do
buffer de 5 MB.
Foram configurados dois cenários: o primeiro composto de uma rede esparsa (com
40 nós), com Tempo de Vida da Transmissão (Time To Live - TTL) e Tempo de Simulação
menores; e o segundo cenário possuindo a rede com maior densidade (composta por 100
nós) e com valores maiores para o TTL e o Tempo de Simulação. A variação dos fatores
foi elaborada para permitir a análise de desempenho para cada ajuste da rede, e assim,
identificar a configuração com melhor desempenho.
Os fatores utilizados foram: Protocolo, TTL, Quantidade de Hosts e Tempo de
Simulação, os nı́veis utilizados para Protocolo foram: Epidemic, First Contact, Maxprop
e Spray and Wait, com nı́veis de TTL 60 e 120, Quantidade de Hosts com nı́veis 40 e 100
e Tempo de Simulação com nı́veis 4 horas e 12 horas.
O número de combinações possı́veis pode ser verificado usando o Princı́pio Fun-
damental da Contagem da Análise Combinatória. O fator Protocolo tem quatro nı́veis,
o TTL dois nı́veis, o fator Quantidade de Hosts dois nı́veis, e o Tempo de Simulação
possui dois, portanto, o número de possibilidades é 4 × 2 × 2 × 2, o que resulta em 32
combinações. Para cada combinação foram feitas 8 observações no simulador, o que re-
sulta em 256 investigações distintas no experimento. As métricas estudadas e monitoradas
durante cada observação foram:
• Probabilidade de Entrega (PE): razão do número de mensagens enviadas (MEV)

pelo número de mensagens criadas (MC). A Equação 1 apresenta o cálculo ma-
temático proposto para esta métrica.
M EV
PE = (1)
MC
• Sobrecarga de Rede (SR): diferença de mensagens repetidas entregues (MRE)
pelo número de mensagens entregues ao destino (D). A Equação 2 apresenta o
cálculo matemático para a Sobrecarga de Rede.
M RE − D
SR = (2)
D
• Latência Média (LM): tempo decorrido desde a criação das mensagens (TMC)
no nó de origem até sua entrega ao nó destino (TED). A Equação 3 apresenta o
cálculo matemático discutido, onde (NR) é o número de mensagens recebidas.
n
X T M C − T ED
LM = (3)
i=1 NR
1
https://www.netlab.tkk.fi/tutkimus/dtn/theone/
607
Para cada uma dessas métricas foi feita uma Análise de Sensibilidade usando o
método estatı́stico Design of Experiments (DoE). DoE é um estudo estatı́stico sobre o
impacto de nı́veis de fatores (variáveis independentes ou parâmetros) sobre um resultado
(variável dependente), orientado assim um processo de otimização [Minitab 2017a]. Os
resultados do experimento configurado são apresentados na Seção 4.
4. Resultados
Os experimentos DoE foram realizados a partir dos dados gerados pelas 256 observações
feitas no simulador ONE. Os ensaios foram aleatorizados para aumento do rigor desta
pesquisa. A organização dos fatores e nı́veis pode ser conferida na Seção 3. Para expressar
a conclusão dos experimentos, utilizou-se o gráfico de Efeitos Principais que pode ser
visualizado nas Figuras 1, 2 e 3 das subseções seguintes. O gráfico apresenta o resumo
do estudo que permitiu concluir os fatores e elementos que impactam em métricas como
Probabilidade de Entrega, Latência e Sobrecarga da Rede.
Os gráficos são usados para demonstrar, detalhadamente, como um ou mais fa-
tores influenciam nos valores das métricas em estudo. Essa influência é percebida pelas
inclinações (coloridas em azul nos gráficos das Figuras 1, 2 e 3) entre as variáveis inde-
pendentes estudadas que representam a ordem de esforço. Quanto mais inclinada for a
linha, maior é o impacto sobre a variável dependente [Minitab 2017b]. Com as conclusões
tiradas desses gráficos foi possı́vel construir um Ranking mostrando a colocação de cada
protocolo em relação à sua eficiência. A Seção 4.4 apresenta o ranking de protocolos de
encaminhamento estudados.
4.1. DoE para Probabilidade de Entrega
Percebe-se pelo gráfico da Figura 1 que a maior inclinação é na escolha do Protocolo em

execução, em detalhe no Maxprop. Pode-se observar uma diferença expressiva durante
alternação de protocolos principalmente entre First Contact e Maxprop. A diferença de
impacto na Probabilidade de Entrega é proveniente das diferentes técnicas utilizadas por
cada protocolo na comunicação. Assim, a escolha do Protocolo tem maior impacto na
Probabilidade de Perda de tráfego em Redes Veiculares do que os outros fatores (TTL,
Número de Hosts e Tempo). O Protocolo Maxprop obteve melhor resultado já que prioriza
o planejamento de envio de pacotes, e com isso, reduz o número e chance de perdas de
pacotes durante encaminhamento.
Figura 1. Gráfico de Efeitos Principais para Probabilidade de Entrega.
608
4.2. DoE para Latência Média

O gráfico da Figura 2 indica que o Fator TTL (Tempo de Vida de Pacote) possui maior
esforço de inclinação, em detalhe no momento de alteração do nı́vel 60 para 100. Com
isso, observa-se que o TTL possui maior influência (dentre os fatores) na variável Latência
Média. O nı́vel 60 de TTL representa uma reduzida Latência Média percebida nas
observações. Quanto menor o TTL, menor o tempo que o nó (veı́culo ou pedestre) espera
pelo pacote, e menor o tempo de Latência na rede (são grandezas diretamente propor-
cionais), o que justifica a queda da Latência Média no decorrer da redução do nı́vel de
TTL. O protocolo também exerce uma influência sobre esta variável, com destaque para
o protocolo Spray and Wait que apresentou configuração com menor Latência Média.
Figura 2. Gráfico de Efeitos Principais para Latência Média.
4.3. DoE para Sobrecarga da Rede

A ordem de esforço das inclinações (coloridas em azul) no gráfico da Figura 3 demons-
tra que o Protocolo selecionado apresenta maior impacto sobre a variável dependente
Sobrecarga da Rede motivada por diferentes caracterı́sticas de funcionamento de cada
protocolo, o que o torna com maior relevância durante escolha desse critério. O nı́vel de
Protocolo que apresenta menor Sobrecarga da Rede é o Spray and Wait. Vale ressaltar que
o número de hosts também exerce uma expressiva influência na Sobrecarga, dado que o
acréscimo de nós numa rede tende a sobrecarregar os recursos e serviços, o que se percebe
reduzido quando se tem 40 nós na rede (são grandezas diretamente proporcionais).
Figura 3. Gráfico de Efeitos Principais para Sobrecarga da Rede.
4.4. Ranking
A presente subseção é voltada para a apresentação de um ranking dos protocolos de en-
caminhamento estudados. O ranking é organizado com base nos resultados obtidos pelas
Análises de Sensibilidade (da Seção 4.1, 4.2 e 4.3) e os desempenhos de cada protocolo.
A seguir será apresentado o esquema de pontuação do ranking na Tabela 1.
609
Por exemplo, quando um protocolo recebe o primeiro lugar em um critério, ganha

5 pontos e caso receba último lugar, ele recebe 0,5 e assim acontece para segundo lugar
e o terceiro lugar (com acréscimo de 2.5 e 1.0, respectivamente). Após a identificação da
colocação a pontuação é somada, o que implicará no resultado final que está apresentado
na Tabela 2. A estrutura de pontuação feita pode ser adequada para a montagem de uma
VDTN especı́fica. Entretanto, com os resultados deste artigo, um engenheiro pode com
seus critérios elaborar os pesos para cada classificação, e assim, usar os resultados do
artigo para encontrar o melhor protocolo para seu serviço.
Classificação Pontos
1o 5,0
2o 2,5
3o 1,0
4o 0,5
Tabela 1. Pontuação por critério.
Probabilidade Sobrecarga Latência

Posição Protocolo Pontuação
de Entrega de Rede Média
Spray And
1o 0,6181 8,0011 1641,9172 10,0
Wait
2o Maxprop 0,7734 40,9028 1900,1374 8,5
First
3o 0,1643 61,1375 1469,9553 6,5
Contact
4o Epidemic 0,3587 65,1828 1916,037 2,0
Tabela 2. Ranking geral analisando cenários densos e esparsos.
De acordo com a Tabela 2, em cenários densos e esparsos, os protocolos Epidemic

e First Contact obtiveram os piores desempenhos, baixas probabilidades de entrega de
pacotes e altas sobrecargas de rede. Quanto a Latência Média, o First Contact mostrou
a menor taxa e o Epidemic obteve a maior Latência Média, classificando-se como o pior
protocolo neste critério. Os melhores desempenhos foram obtidos pelos protocolos Spray
And Wait e Maxprop com altas probabilidades de entrega de pacotes.
No critério Probabilidade de Entrega, o protocolo Maxprop conseguiu entregar
77,34% dos pacotes, tendo o melhor desempenho. Os protocolos Spray And Wait e Max-
prop possuem menores impactos na Sobrecarga da Rede, e tempos de Latência inter-
mediários. Considerando a pontuação estabelecida na Tabela 1, o protocolo Spray and
Wait tem melhor desempenho com suas pontuações.
Os critérios de comparação são comentados. A seguir a Tabela 3 sintetiza as contribuições
do trabalhos relacionados com este artigo. As referências são ordenadas por ano e cate-
gorizadas por três critérios: Protocolos, DoE e Métricas (critérios de avaliação).
610
• Protocolos: Soares et al. (2013) acompanharam e analisaram o desempenho dos

protocolos: First Contact, Direct Delivery, Epidemic, Spray and Wait, PRoPHET,
GeOpps e GeoSpray. Hossen e Rahim (2015) consideraram os protocolos: Epi-
demic, PRoPHET e Spray and Wait (Binary Version) durante seu trabalho. Spaho
et al. (2016) avaliaram os protocolos: Epidemic, Spray and Wait e Maxprop. os
autores Oliveira e Silva (2016) qualificaram o desempenho dos protocolos: First
Contact, Direct Delivery, Spray and Wait, Epidemic e Maxprop.
• Métricas de Desempenho: Soares et al. (2013) investigaram seis métricas de
protocolos de VDTNs. Já Houssen e Rahim (2015) utilizaram quatro métricas.
Spaho et al. (2016) investigaram os impactos da densidade da rede e TTL de
pacotes sobre quatro métricas. Oliveira e Silva (2016) utilizaram três parâmetros
para medir o desempenho de seus protocolos em estudo.
• DoE: o Design of Experiments é uma ferramenta otimizada para análise estatı́stica
que permite estudo de interação entre causa e efeito e reduz o erro experimental.
Os trabalhos relacionados encontrados não fizeram uso desta abordagem e sim-
plesmente fizeram comparações com fatores de forma individual e não agrupada.
Autores Protocolos DoE Métricas de Desempenho

First Contact, Direct Transmissões Iniciadas,
Delivery, Epidemic, Pacotes Descartados,
[Soares et al. 2013] Spray and Wait, Não Probabilidade de Entrega,
PRoPHET, GeOpps Latência Média, Saltos e
e GeoSpray Sobrecarga dos Recursos
Epidemic, Probabilidade de Entrega,
[Hossen e Rahim 2015] PRoPHET, Spray Não Latência Média, Sobrecarga
and Wait e Número de Nós Móveis
Probabilidade de Entrega,
Epidemic, Spray Sobrecarga da Rede,
[Spaho et al. 2016] Não
and Wait e Maxprop Latência Média e Número
Médio de Saltos
First Contact, Direct
Atraso Médio, Taxa de
Delivery, Spray and
[Oliveira e Silva 2016] Não Entrega e Sobrecarga da
Wait, Epidemic e
Rede
Maxprop
Epidemic, First Probabilidade de Entrega,
Nosso Trabalho Contact, Maxprop e Sim Sobrecarga da Rede e
Spray and Wait Latência Média
Tabela 3. Relação entre os Trabalhos Cientı́ficos.
O presente artigo se diferencia por buscar identificar a influência de alguns fatores

(e suas variações) na Probabilidade de Entrega, Sobrecarga da Rede e Latência Média.
Com isso, pretende-se fornecer informações e técnicas estruturadas e comprovadas aos
profissionais para montagem de VDTNs. As Métricas de Desempenho (Probabilidade de
Entrega, Sobrecarga da Rede e Latência Média) que foram definidas e utilizadas neste
trabalho foram aplicadas por Soares et al. (2013), Hossen e Rahim (2015) e Spaho et al.
(2016). O restante dos trabalhos não satisfazem todas as métricas discutidas.
611
Os protocolos aqui estudados também foram tratados no trabalho de Oliveira e

Silva (2016). Os outros artigos relacionados não trataram de todos esses protocolos. Os
protocolos escolhidos para avaliação passaram por avaliações cientı́ficas, com bons de-
sempenhos em critérios, porém, nenhum passou por investigação DoE e ranking estrutu-
rado como nesta proposta (considerando os trabalhos relacionados descritos).

O protocolo Spray and Wait obteve melhor desempenho por apresentar menor Latência
e Sobrecarga da Rede, e uma intermediária Probabilidade de Entrega. O estudo também
apontou que engenheiros de VDTNs devem considerar, principalmente, o Protocolo esco-
lhido no ganho de Probabilidade de Entrega e Sobrecarga da Rede, e número de TTL na
Latência Média. Futuramente, planeja-se uma aplicação veicular tolerante a atraso e des-
conexões usando o protocolo Spray and Wait para obter melhor desempenho. Além disso,
pretende-se integrar outros protocolos como Direct Delivery e PRoPHET nas próximas
avaliações, e passar o estudo de um cenário simulado para um ambiente real.
Referências
Câmara, D., Frangiadakis, N., Filali, F., e Bonnet, C. (2011). Vehicular delay tolerant
networks. Handbook of research on mobility and computing: evolving technologies
and ubiquitous impacts, pages 356–367.
Hossen, M. S. e Rahim, M. S. (2015). On the performance of delay-tolerant routing
protocols in intermittently connected mobile networks. Rajshahi University Journal of
Science and Engineering, 43:29–38.
Minitab (2017a). Designing an experiment. Disponı́vel em: support.minitab.com/en-
Minitab (2017b). O que é um gráfico de efeitos principais? Disponı́vel
em: support.minitab.com/pt-br/minitab/18/help-and-how-to/modeling-
statistics/anova/supporting-topics/basics/what-is-a-main-effects-plot/. Acesso em:
17/06/2017.
Naz, F., Chowdhury, T. A., Sabah, S. H., e Ferdous, H. S. (2011). A study on the challen-
ges and importance of vehicular network in the context of bangladesh. In Research and
Development (SCOReD), 2011 IEEE Student Conference on, pages 265–270. IEEE.
Oliveira, M. e Silva, É. R. (2016). Impacto dos modelos de mobilidade no desempenho
de redes tolerantes a atrasos e desconexões. In Conferência de Estudos em Engenharia
Elétrica. CEEL.
Soares, V. N., Dias, J. A., Isento, J. N., e Rodrigues, J. J. (2013). Protocolos de en-
caminhamento para redes veiculares com ligações intermitentes. In CRC 2012: 12a
Conferência sobre Redes de Computadores, pages 77–84.
Spaho, E., Barolli, L., Kolici, V., e Lala, A. (2016). Performance comparison of different
routing protocols in sparse and dense vdtns. In Advanced Information Networking and
Applications (AINA), 2016 IEEE 30th International Conference on, pages 698–703.
IEEE.
Zeng, Y., Xiang, K., Li, D., e Vasilakos, A. V. (2013). Directional routing and scheduling
for green vehicular delay tolerant networks. Wireless networks, 19(2):161–173.
612
Uma heurística para identificação de interesses transversais na

escrita de histórias do usuário
Abstract.
Resumo. O entendimento das características do software e a criação de testes

são importantes etapas na busca pela construção de sistemas de software com
qualidade, confiança e que atenda as expectativas do usuário. Neste sentido, o
presente trabalho faz uso de Aspect-Oriented Requirements Engineering (AORE)
como uma iniciativa para auxiliar nas especificações de testes baseados em his-
tórias do usuário, como acontece em BDD, e, assim, apresentar uma abordagem
com etapas definidas para identificar interesses transversais durante a escrita
dos testes criados com a notação Gherkin.
1. Introdução
A busca pela construção de sistemas de software com qualidade é algo recorrente nas
pesquisas sobre engenharia de software, seja com vistas na qualidade do produto final,
ou por melhorias durante o processo de desenvolvimento. Desse modo, o entendimento
sobre as características que o software possuirá é uma importante etapa do processo de
construção.
É importante que no processo de construção os usuários descrevam as característi-
cas funcionais e não funcionais desejadas para o sistema, de modo que tais informações
fiquem claras, livres de interpretações múltiplas, fáceis de entender, completas e consisten-
tes[Pressman, 2011] .
Durante este processo, outra importante etapa é a realização de testes, decorrente
da tentativa de evitar ou diminuir significativamente os defeitos (bugs, inconsistência nos
dados, entre outros) e possibilitar um entendimento nítido das funcionalidades que estão
sendo ou serão criadas, proporcionando mais qualidade e confiabilidade ao sistema que será
construído. O teste de software é uma das atividades mais importantes do desenvolvimento,
visto que, por meio dessa etapa, as partes interessadas (stakeholders), conseguem avaliar a
613
qualidade do produto desenvolvido, seja pelo incremento da confiança no código, ou por

meio da identificação de erros para posteriores correções [Restivo, 2015] .
Assim, a procura para atender as necessidades qualitativas na construção de soft-
ware e de adaptar as novas situações nesse processo de construção, considerando as
multiplicidades de agentes envolvidos, tem-se o surgimento de metodologias, ferramen-
tas e técnicas de desenvolvimento, como o Behavior Driven Development (BDD) e a
Aspect-Oriented Requirements Engineering (AORE).
O BDD é uma metodologia de desenvolvimento de software recente, de boa
aceitação na comunidade, que busca especificações executáveis de um sistema por meio de
testes claramente escritos e de fácil entendimento, estabelecendo uma linguagem ubíqua
entre stakeholders e a equipe de desenvolvimento, de modo a auxiliar na especificação
dos testes [North, 2014] . Smart [2015] destaca que a utilização das ferramentas de BDD
pode ajudar no processo de transformação dos requisitos em especificações executáveis
de testes, auxiliando o desenvolvedor a verificar os recursos e a gerar documentação do
software.
Já AORE é a aplicação dos conceitos de orientação a aspecto na busca de identificar
e analisar interesses transversais (crosscutting concerns), aspectos, nas fases inicias do
desenvolvimento, com o intuito de entender seus potencias efeitos em fases posteriores.
Sommerville [2011] destaca que a programação tem sido um dos focos das pesquisas em
orientação a aspectos. No entanto, considera que os interesses transversais são igualmente
importantes em outras fases do processo de desenvolvimento do software.
A forma como os requisitos são entendidos pode impactar seriamente no de-
senvolvimento das funcionalidades e na criação dos testes [Mitchell e Black, 2015], e
consequentemente na qualidade do software. Neste sentido, a escrita das especificações
dos testes, com base no levantamento dos requisitos do usuário, apresenta-se como um
desafio, na medida em que é preciso a utilização de novas técnicas com critérios bem
definidos para a especificação de testes com base nos requisitos do usuário.
As especificações dos testes devem representar bem as funcionalidades do sistema
e como elas estão relacionadas, de modo que fique claro estas relações e como uma
funcionalidade pode interferir na execução de outras, ou necessitar da execução de outras
partes do sistema.
1.1. Objetivo
O Objetivo geral deste trabalho é a aplicação dos conceitos de AORE para auxiliar na
especificação dos testes criados por meio da escrita de histórias e seus respectivos cenários
em busca de identificar interesses transversais. Para tanto, este trabalho apresenta uma
614
heurística com etapas definidas para identificar interesses transversais durante a escrita dos
testes criados com a notação Gherkin.
1.2. Metodologia
Como forma de atingir os objetivos pretendidos foi realizado as seguintes etapas: Identifi-
cação das principais características dos modelos e técnicas encontrados de aplicação de
AORE na literatura; Criação de uma heurística com etapas definidas para identificar inte-
resses transversais durante a escrita dos testes criados com a notação Gherkin; Aplicação
da heurística com um running example.
2. Abordagem proposta
A abordagem proposta foi motivada pelas características e práticas do BDD e pelos
seguintes modelos/abordagens: um modelo de engenharia de requisitos orientada a aspecto
[MOREIRA et al., 2013]; um processo de design orientado a aspecto [SOMMERVILLE,
2011]; e um padrão que descreve uma solução para duplicação de requisitos [Ramos
et al., 2007]. As referências utilizadas pelo trabalho para montar as etapas da abordagem,
foram usadas por se colocarem como abordagens genéricas de aplicação dos conceitos de
orientação a aspecto e da escrita de requisitos. A abordagem está dividida em duas partes:
Escrita das histórias e Identificação dos interesses transversais nas histórias.
Para auxiliar o entendimento das etapas da abordagem foi utilizado um running
example [Moreira et al., 2013] . O running example refere-se a três entidades de um
sistema: Empregado, Usuário e Função. Um empregado possui atributos como nome,
idade e salário. O salário do empregado é calculado de acordo com sua idade e a idade
para aposentadoria. A entidade Usuário possui os atributos nome de usuário e autorizado
(boolean). Os usuários possuem permissões para realizar determinadas tarefas, por isso
na realização de alguma operação deve ser verificado suas permissões. Além disso,
um empregado possui uma função. No running example é estabelecido como requisito
de segurança manter protegido os dados dos salários dos empregados de acessos não
autorizados de usuários para alterações ou visualizações.
2.1. Escrita das histórias

Conforme estabelece a metodologia BDD, as especificações das histórias representam as
funcionalidades do sistema e são compostas por um conjunto de cenários, que representam
diversos exemplos de comportamentos que uma determinada funcionalidade do sistema
possa ter [North, 2015] . Para a escrita das histórias será utilizado a notação Gherkin, na
qual a especificação da história é iniciada com uma narrativa (In order to - As a - I want to)
e a criação dos cenários com o padrão Given-When-Then. A utilização desta notação para
a escrita das histórias e cenários do running example está demonstrada nas Figuras 1 e 2.
615
Figura 1. História “Gerenciar Empregado” escrita com a notação Gherkin.
Figura 2. História “Gerenciar Usuário” escrita com a notação Gherkin.
2.2. Identificação dos interesses transversais nas histórias

A separação e identificação dos interesses do sistema é uma tentativa de organizar cada
elemento (parte) que compõem o sistema com sua respectiva função, de modo que esta
616
função seja única. Logo, é possível entender melhor um interesse do sistema de forma
isolada, sem necessidade do entendimento das outras partes e, assim, mudanças que
possam ocorrer serão localizadas em poucas partes do sistema, facilitando a manutenção e
a evolução [Sommerville, 2011] .
Se um interesse atravessar vários requisitos, ele pode ser considerada um aspecto
[Tekinerdoğan et al., 2005] . Um aspecto pode representar uma função do sistema (log
de operações), um critério de decisão (escolha da arquitetura), um critério de qualidade
(desempenho), ou critérios políticos (regras de negócios) [Rashid et al., 2002].
É importante fazer uma correlação entre os interesses transversais (crosscutting
concerns) e os requisitos para deixar claro a relação existente entre os dois [Rashid et al.,
2002]. Uma forma de representar o impacto que os interesses transversais possam causar
sobre as partes que perpassam, é por meio da criação de uma Requirements Composition
Table (RCT) [Chernak, 2013]. A utilização de uma RCT proporciona a todos os stakehol-
ders do projeto de software uma forma de comunicação clara e simples, gerando uma
linguagem comum entre todos os envolvidos, através de uma visão macro e estruturada
das funcionalidades do software em forma de tabela (Figura 3).
Figura 3. Dimensões da RCT
Com base nas características citadas anteriormente da tabela de composição dos

requisitos, é criado uma Tabela de Composição das Histórias (TCH). A TCH irá relacionar
quais cenários compõem cada história, de modo que os cenários serão listados nas colunas
e as histórias serão listadas nas linhas. A Figura 4 representa as histórias e seus respectivos
cenários para o running example.
Figura 4. Tabela de composição das histórias do running example
617
Se uma coluna da tabela TCH possuir várias linhas marcadas, ou seja, se um cenário
estiver presente em mais de uma história, é considerado que existe um espalhamento e
entrelaçamento da característica que aquele cenário representa. No entanto, os interesses
transversais podem estar presentes na escrita dos próprios cenários das histórias e não
evidenciados em um cenário propriamente. Por exemplo, na TCH do running example não
está claro a presença de nenhum cenário nas duas histórias. No entanto, na descrição dos
cenários C04 e C05 da história “Gerenciar Empregado” pode ser notado a presença do
interesse “verificar permissão do usuário” (Figura 5). Ou seja, este interesse corresponde
ao cenário C07 da história “Gerenciar Usuário” que verifica a permissão do usuário e,
portanto, é um interesse transversal relacionado a segurança.
Figura 5. Presença do interesse “permissão” na história “Gerenciar Empregado”.
Por isso é necessário analisar todos os cenários das histórias para averiguar se
algum cenário, em sua escrita, possui características que não é do seu interesse, ou seja,
que não é da sua responsabilidade e, portanto, não deveria ser implementado por ele. Uma
Tabela de Interesses Transversais (TIT) pode ser criada para demonstrar em quais histórias
e cenários os interesses transversais encontrados estão presentes (Figura 6).
618
Figura 6. Tabela de Interesses Transversais do running example
Heurística para identificação dos interesses transversais

Como uma forma de estabelecer alguns passos a serem seguidos para facilitar a
identificação de tais interesses , foi estabelecido uma heurística para identificação dos
interesses transversais. A heurística foi construída com base nos conceitos de entrelaça-
mento (tangling) e espalhamento (scattering) dos interesses que estejam presentes nas
várias partes dos componentes do sistema. Sendo assim, segue os critérios estabelecidos:
• Fazer o levantamento das histórias e dos cenários que compõem o sistema. Para
auxiliar nesta tarefa, criar uma Tabela de Composição das Histórias (TCH) que irá
permitir uma visão simples dos cenários que compõem as histórias;
• Analisar cada história para verificar a existência de novos comportamentos que não
estão representados nas histórias atuais, e de comportamentos descritos no corpo
dos seus cenários que não são de suas responsabilidades. Caso necessário, atualizar
a TCH;
• Analisar a TCH para verificar se existe cenários espalhados e entrelaçados. Se uma
coluna da TCH possuir mais de uma marcação, este cenário está presente em mais
de uma história e, portanto, espalhado e entrelaçado;
• Montar uma Tabela de Interesses Transversais (TIT) para explicitar os aspectos
identificados, assim como, seus espalhamentos e entrelaçamentos;
• Inserir na TIT os comportamentos transversais identificados que não estão repre-
sentados como cenário de nenhuma das histórias atuais, se houver.
Desse modo, esses passos irão auxiliar na identificação dos interesses transversais
durante a escrita das histórias, assim como, os artefatos gerados (TCH e TIT) irão permitir
a identificação e visualização do espalhamento e entrelaçamento dos interesses.
3. Conclusão
Este trabalho procurou usar os conceitos de AORE com a finalidade de definir etapas para
auxiliar na identificação de interesses transversais durante a escrita de histórias do usuário
619
com a notação Gherkin. Com aplicação da heurística no running example, pode-se obter
com maior brevidade o entendimento de como os requisitos estão relacionados (entrela-
çados e espalhados) e, desta forma, permitir que se possa escrever testes que retratarem
bem as características do software e suas relações. Além disso, outra contribuição, é a
possibilidade da realização de um planejamento para evitar que as especificações de histó-
rias/cenários transversais, quando transformadas em especificações executáveis (códigos),
sejam mapeadas juntas, gerando especificações executáveis também transversais. Deste
modo, identificar interesses transversais no momento da criação das histórias do usuário
pode ser um ponto de partida para automatização de testes de aceitação orientados a aspecto
escritos neste formato. Assim como, também, pode ser considerado uma estratégia útil
para proporcionar aos stakeholders um melhor entendimento dos comportamentos de cada
funcionalidade criada.
Referências
Chernak, Y. (2013). Implementing Aspect-Oriented Requirements Analysis for Investment
Banking Applications, chapter 15, pages 289 – 316. Springer, 1 edition.
Mitchell, J. L. e Black, R. (2015). Advanced Software Testing, volume 3. Rocky Nook, 2
edition.
Moreira, A., Chitchyan, R., Araújo, J., e Rashid, A. (2013). Aspect-oriented requirements
engineering. Springer, 1 edition.
North, D. (2014). BDDWiki: Introduction. Editado pela última vez em 2014-09-29.
North, D. (2015). JBehave.
Pressman, R. S. (2011). Engenharia de Software. Bookman, 7 edition.
Ramos, R., Araújo, J., Moreira, A., Castro, J., Alencar, F., e Penteado, R. (2007). Um
Padrão para Requisitos Duplicados. Supporting Organizations.
Rashid, A., Sawyer, P., Moreira, A., e Araujo, J. (2002). Early aspects: A model for aspect-
oriented requirements engineering. In Requirements Engineering, 2002. Proceedings.
IEEE Joint International Conference on, pages 199 – 202. IEEE.
Restivo, A. M. O. (2015). Incremental Modular Testing in Aspect Oriented Programing.
Faculdade de engenharia informatica, Faculdade de Engenharia da Universidade do
Porto.
Smart, J. F. (2015). BDD in Action: Behavior-Driven Development for the whole software
lifecycle. Manning.
Sommerville, I. (2011). Software Engineering - 9th edition. Pearson.
Tekinerdoğan, B., Moreira, A., Araújo, J., e Clements, P. (2005). Early Aspects: Aspect-
Oriented Requirements Engineering and Architecture Design. In E. Aspects, editor,
Anais do Workshop Proceedings.
620
Capítulo
1
Softwarização em Redes: Do Plano de Dados ao
Plano de Orquestração
Nathan Franklin Saraiva de Sousa (UNICAMP) e Christian Esteve Rothen-

berg (UNICAMP)
Abstract
Packet Processor Programming, Software Defined Network (SDN) and Network Function
Virtualization (NFV) are different technologies involved in network programming, typi-
cally known as Network "Softwarization". This trend is already a reality in the Telecom-
munications and Information Technology and Communication industry. The network pro-
grammability seeks to optimize costs, automate processes, and offer new services with
the flexibility and agility to create them. The “Softwarization" is creating the conditions
for reinventing the network and service architectures. This mini-course has the follow-
ing objectives: to present a bottom-up vision in the area of network programming; to
approach the principles of programming in the data plane presenting the P4 language;
define data forwarding technology through the OpenFlow protocol (SDN); to present the
network function virtualization in the orchestration of services; and finally, to discuss the
main challenges in the area of network programming. Thus, the mini-course will provide
the participants the main points of the network "softwarization" with focus on the current
tendencies for several lines of research.
Resumo
Programação de Processadores de Pacotes, Redes definidas por software (SDN) e Virtua-

lização de funções de rede (NFV) são diferentes tecnologias envolvidas na programação
de redes, tipicamente conhecido como “Softwarização” de redes (Network “Softwariza-
tion”). Esta tendência já é uma realidade na indústria de Telecomunicações e de tec-
nologia da Informação e Comunicação. A programabilidade em redes procura otimizar
custos, com a automatização de processos, e oferecer novos serviços com a flexibilidade
e agilidade na criação dos mesmos. A “softwarização” está criando as condições para
reinventar a rede e as arquiteturas de serviços. Este minicurso tem como objetivos: apre-
sentar uma visão bottom-up na área de programação de redes; abordar os princípios da
621
programação no plano de dados apresentando a linguagem P4; definir a tecnologia de

encaminhamento de dados através do protocolo OpenFlow (SDN); apresentar a virtua-
lização de funções de rede na orquestração de serviços; e por fim, discutir os principais
desafios na área de programação de redes. Por meio destes objetivos, o minicurso pro-
porcionará aos participantes os principais pontos da “softwarização” de redes com foco
nas tendências atuais para diversas linhas de pesquisa.
1.1. Introdução
A infraestrutura das operadoras de telecomunicações consiste de várias tecnologias e es-
pecializados domínios de redes tais como acesso, transporte e núcleo. Atualmente, criar e
implantar serviços de telecomunicações fim-a-fim é um processo manual e lento realizado
através do tradicional Sistema de Suporte a Operação, ou em inglês, Operation Support
System (OSS) [BluePlanet 2017]. Além disso, suas redes estão atreladas a hardware e
software proprietários, os quais demandam altos custos de implantação e de operação
(energia, espaço e técnicos especializados).
Novas tecnologias como Programação de processadores de pacotes, Redes
definidas por Software (SDN) e Virtualização das Funções de Redes (NFV) estão mu-
dando a forma que as operadoras de telecomunicações criarão, implantarão e gerenciarão
os seus serviços [Sonkoly et al. 2014]. Tais tecnologias permitirão a utilização flexível,
escalável e eficiente das infraestruturas de rede. Entretanto, atualmente as operadoras e
provedores de serviços necessitam ter a capacidade de gerenciar e integrar todas essas
tecnologias.
Para acompanhar essas novas tendências, as operadoras de telecomunicações estão
focando na evolução do hardware para o software. Suas infraestruturas devem convergir
para integrar o processamento, o armazenamento e a rede [Galis et al. 2014]. Tecnologias
de virtualização abstraem o hardware e permitem maior elasticidade e automação. No
entanto, atualmente as operadores enfrentam grandes desafios como:
1. Aumento da disparidade entre custo e receita;
2. Grande variedade de tipos de hardware proprietários na suas redes;
3. Ciclo de vida reduzido do hardware, o que faz com que os mesmos sejam substituí-
dos periodicamente;
4. Dificuldade em relação a flexibilidade e agilidade dos serviços em virtude da de-

pendência de soluções baseadas em hardware;
5. Novos serviços são difíceis de serem implantados (acesso a muitos equipamentos e

lentidão no processo) e muitas vezes requerem um outro hardware proprietário.
O conceito de "softwarização" de rede ou em inglês Network "Softwarization" é

um termo recente porém o seu conceito já é aplicado algum tempo por empresas como a
IBM e pelas próprias fornecedoras de equipamentos de rede no desenvolvimento e testes
dos seus produtos.
622
As tradicionais redes são caracterizadas por serem altamente inflexíveis e depen-

dentes dos fornecedores de equipamentos. Geralmente elas são gerenciados através de
interfaces de linhas de comandos (CLI) e/ou soluções proprietárias. O código do sistema
operacional é fechado e necessita ser trocado a cada nova funcionalidade ou geração de
equipamentos. A rede como um todo é formado pelos clássicos appliances de rede de um
ou mais fabricantes [Rosa et al. 2015].
A "softwarização" de rede trouxe a possibilidade da rede ser programável e
flexível se adequando às necessidades dos clientes e do tráfego de dados. Ela mudou
a forma de como construir sistemas de rede. O processamento de pacotes levou a pro-
gramabilidade para a camada de dados da rede. A tecnologia SDN trouxe a flexibilidade
no encaminhamento dos dados desacoplando o plano de encaminhado do plano de con-
trole. Já o NFV proporcionou flexibilidade no processamento, desacoplando as funções
de rede (software) do hardware.
A figura 1.1 mostra como as tecnologias acima mencionadas se localizam na es-
trutura de um sistema de rede. Na camada de dados temos os processadores programáveis
e linguagens de processamento de pacotes como o P4. Logo acima temos APIs, módu-
los de gerenciamento e agentes que proporcionam a comunicação com o plano de con-
trole. Na camada de controle tem-se os sistemas operacionais de rede como ONOS1 ,
OpenDayLigth2 , interfaces southbound e northbound, e protocolos southbound como o
OpenFlow.
Figure 1.1. A "softwarização" de rede definindo as camadas de um sistema de rede.
Paralelamente encontra-se a camada de virtualização das funções de rede. Nessa

camada estão os recursos de hardware como processamento e armazenamento, e a ca-
mada de virtualização para criação das funções de rede virtuais, além de gerenciadores
de infraestrutura e de funções de rede virtuais. No topo ficam os componentes respon-
sáveis por todo o processo de orquestração e gerenciamento: Orquestrador, OSS/Business
Support System (BSS) e aplicações rede em geral.
1 onosproject.org
2 www.opendaylight.org
623
Este minicurso tem como principais objetivos:
1. Apresentar uma visão geral na área de softwarização de redes;
2. Abordar os princípios do plano de dados programável, mais especificamente a lin-

guagem de programação P4;
3. Definir a tecnologia de encaminhamento de dados através do protocolo OpenFlow;
4. Apresentar a virtualização das funções de rede e orquestração de serviços de rede;
5. Discutir os principais desafios e linhas de pesquisa na área de programação de redes;
6. Nortear os participantes em seus primeiros experimentos em P4, OpenFlow e NFV;
Quanto a estrutura do minicurso, o mesmo será apresentado através de 05 princi-

pais seções. A seção 1.2 detalha os principais conceitos no plano de dados e a linguagem
P4. Uma atividade prática com a linguagem P4 também é apresentada. Na seção 1.3 são
mostrados os princípios de Redes definidas por software e a especificação do protocolo
OpenFlow, assim como um caso de uso com o protocolo OpenFlow. Já na seção 1.4 é
introduzido as características técnicas do NFV e seus requisitos, além de uma prática us-
ando um framework de orquestração chamado Tacker-OpenStack. Quanto à seção 1.5, os
principais desafios e oportunidades de pesquisas são identificados. Por fim, as conclusões
do minicurso são apresentadas na última seção.
1.2. Programação na Camada de Dados

As tradicionais redes corporativas são formados por switches e roteadores de um ou mais
fabricantes. Esses equipamentos executam um sistema operacional que hoje é quase sem-
pre baseado no Linux ou Unix BSD. O sistema operacional se comunica com o proces-
sador ASIC (Application Specific Integrated Circuits) através de um driver afim de exe-
cutar os processos relacionados com a rede. Os roteadores e switches trocam informações
sobre a rede para permitir o tráfego entre os diversos segmentos da rede. Basicamente,
esse é o funcionamento das redes atuais. Como os switches e roteadores corporativos
atuais são construídos é resumido na figura 1.2.
Figure 1.2. O funcionamento de roteadores e switches tradicionais.
Nesse cenário a adição de novas funcionalidades necessita de um longo processo

de implantação por parte dos fabricantes. Isto consiste em atualizar o sistema operacional,
624
atualizar drivers, testar e colocar em produção. Geralmente todo esse processo leva alguns
meses ou mesmo anos de trabalho. Em um ambiente em que necessita ser dinâmico e
flexível todo esse processo impacta diretamente no funcionamento da rede.
Geralmente, os equipamentos de redes são desenvolvidos com configurações fixas
e na direção bottom-up (baixo para cima), ou seja, os sistemas operacionais e softwares
precisam se adequar ao que o processador do equipamento pode oferecer.
Pensando nisso novas pesquisas e soluções estão surgindo nesses últimos anos
para mudar como as redes são implementadas. As redes estão começando a ser progra-
madas em uma abordagem top-down. Com isso é possível programar qual o compor-
tamento desejado para o plano de dados. Novos serviços e funcionalidades podem ser
implementadas não necessitando que seja realizado todo processo de desenvolvimento de
novos equipamentos. O que antes faziam em anos agora pode ser feito em horas.
A programabilidade no plano de dados enfrenta diversos desafios e está sendo
investigada pela comunidade acadêmica e a indústria. Os novos switches (equipamentos
de rede) programáveis devem atender requisitos como [Bosshart et al. 2014]:
• Processador de pacotes configurável: O processamento de pacotes não deve está

amarrado a um formato de cabeçalho específico. Com isso é possível o processa-
mento de novos serviços e protocolos.
• Tabelas de pacotes flexíveis: Possibilidade de múltiplas tabelas no pipeline, tanto

tabelas em séries como paralelas. As tabelas devem ser capazes de combinar com
todos os campos definidos na programação do plano de dados. Em função disso,
novas e complexas funcionalidades podem ser desenvolvidas para a rede.
• Primitivas gerais de processamento de pacotes: Os equipamentos devem implemen-

tar primitivas como copiar, adicionar, remover e modificar tanto para os campos de
cabeçalhos de pacotes como para os metadados utilizados no pipeline.
Esses desafios não são superados de um dia para outro, mas a academia e a in-
dústria mostram sinais promissores de progresso nessa direção. Um nova geração de
tecnologias programáveis estão surgindo como por exemplo [Kim 2016]:
• Nova geração de switches Application Specific Integrated Circuits (ASIC): Intel

Flexpipe, Cisco Doppler, Cavium (Xpliant), Barefoot Tofino.
• Network Processor Unit (NPU): EZchip, Netronome.
• CPU: Open Vswitch, eBPF, DPDK, VPP.
• FPGA: Xilinx, Altera.
Estes equipamentos possibilitam programar como os pacotes devem ser processa-

dos e em um custo razoável. Contudo a programação dos processadores é difícil, princi-
palmente por que eles possuem interfaces específicas por fabricante e uma programação
de baixo nível semelhante a codificação de microcódigo.
625
Portanto, é necessário uma linguagem de alto nível que consiga abstrair o plano
de dados e permita programar como os equipamentos de rede devem se comportar. A
figura 1.3 ilustra a proposta do funcionamento de equipamentos de redes programáveis.
Figure 1.3. O funcionamento de equipamentos de redes programáveis. Adaptado

de [Bosshart et al. 2014]
Nesse contexto surgiu uma linguagem de alto nível para programação de pa-
cotes independente de protocolo chamado P4, Programming Protocol-independent Packet
Processors [Bosshart et al. 2014]. Na próxima seção será descrito os detalhes dessa lin-
guagem.
1.2.1. Linguagem P4
A linguagem P4 foi proposta em 2014 no ACM SIGCOMM Computer Communication
Review por um consórcio de várias empresas tais como Barefoot Networks, Intel, Google,
Microsoft e as universidades de Stanford e Princeton. Nos últimos anos a linguagem saiu
de uma simples proposta para uma especificação.
P4 é uma linguagem open source específica para a programação do plano de da-
dos. Atualmente ela é mantida por uma organização chamada P4 Language Consortium.
Basicamente, o P4 abstrai a programação de redes e pode servir como uma interface
genérica entre os equipamentos de rede e o plano de controle (veja figura 1.3).
O projeto da linguagem P4 é baseado em três objetivos principais [Bosshart et al.
2014]:
1. Independência do protocolo: O switch não deve ser atrelado à qualquer protocolo

de rede ou formato de pacote. O programador deve definir como analisar o pacote e
determinar as ações que desejar baseado em um conjunto de tabelas Match+Action;
2. Independência de arquitetura: O programa P4 não deve se preocupar com detalhes
dos equipamentos de processamento de pacotes. Esse detalhes devem ser tratados
pelo compilador.
3. Reconfigurável em campo: Os programadores devem ser capaz de alterar o proces-
samento dos pacotes nos equipamentos de rede mesmo eles já implantados, ou seja,
em tempo de execução.
626
O modelo de encaminhamento abstrato proposto pelo P4 é formado por tabelas

Match+Action arranjadas em série, paralela ou ambos, e por um ou mais analisadores
(parser). O modelo generaliza como os pacotes são processados em diferentes equipa-
mentos (Switch, roteador, Firewall) e em diferentes tecnologias (PISA, NPU, FPGA). A
figura 1.4 detalha o modelo de encaminhamento do P4.
Figure 1.4. Modelo abstrato de encaminhamento do P4. Adaptado de [Bosshart

et al. 2014]
Ao chegar os pacotes são manipulados pelo analisador. Ele organiza e extrai os

campos dos cabeçalhos sem se preocupar com o significado dos mesmos. O analisador
define os protocolos suportados pelo equipamento. Logo após, os campos extraídos são
repassados para as tabelas Match+Action. A tabela de entrada é responsável por definir
as portas de saída e a fila para o pacote. Já a tabela de saída realiza modificações no
cabeçalho do pacote como remover ou adicionar campos (por exemplo, VxLAN).
Para a programação do plano de dados é necessário definir um programa P4. Um
programa P4 é formado por 06 partes. Os headers (cabeçalhos) são listas de campos
ordenados com nome e tamanho. Os parsers são responsáveis por identificar e extrair
os valores dos cabeçalhos (conforme mencionado anteriormente). As actions (ações) são
funções customizadas compostas de ações primitivas como adicionar campo, remover
campo, copiar e incrementar. As Tabelas fazem a relação entre os campos dos pacotes
e as ações. O Controle de fluxo define a ordem das tabelas, condicionais e funções.
Por fim, memórias statefull mantém os contadores, medidores e registros dos pacotes de
forma persistente [Bosshart et al. 2014]. Um exemplo de um programa P4 é mostrado na
figura 1.5.
Para implementar o programa P4 em um rede é necessário um compilador es-
pecífico para cada dispositivo, sendo ele hardware ou software. O compilador mapeia a
descrição do programa em definições do equipamento de rede. Para parser programáveis,
o compilador traduz a descrição do parser dentro de uma máquina de estados. Já para
parser fixos, o compilador simplesmente verifica se a descrição está consistente com o
dispositivo de destino.
Existem dois estágios no processo de compilação. No primeiro o programa P4 é
convertido em um representação de grafos de dependência que determina a dependência
entre as tabelas. Depois este grafo é mapeado para recursos específicos do dispositivo de
rede. A atual versão da linguagem P4 é a 16. Para mais informações e especificações do
P4 visite o sítio http://p4.org.
627
Figure 1.5. Exemplo de um programa P4.
1.2.2. Atividade prática: Roteador Simples

Este caso de uso tem como objetivo mostrar um exemplo da linguagem P4 para introduzir
os primeiros conhecimentos nessa linguagem. Foi criado uma máquina virtual com os
pacotes previamente instalados que o cenário necessita para rodar o programa P4.
Para a construção da rede será utilizado o emulador de rede mininet. A topologia
é formada por duas redes interconectadas através de um roteador. A figura 1.6 resume os
dados do cenário.
Figure 1.6. Topologia para atividade prática com linguagem P4.
Passos para a implementação da atividade prática.
1. Compilar o programa P4 e gerar o arquivo do tipo json para o dispositivo "sim-

ple_router" conforme os comandos abaixo:
cd behavioral-model/targets/simple_router
sudo p4c-bmv2 -- json simple_router.json simple_router.p4
2. Executar o roteador virtual "simple_router" usando o mininet:

cd behavioral-model/mininet/
sudo python 1sw_demo.py -- behavioral-exe ../targets/sim-
ple_router/simple_router -- json ../targets/simple_router/simple_router.json
628
3. Na CLI do mininet testar o ping entre os dois hosts:

> h1 ping h2
4. Em um outro terminal, rodar a aplicação para popular as tabelas do roteador.

cd behavioral-model/targets/simple_router/
./runtime_CLI < commands.txt
5. O arquivo commands.txt tem as seguintes regras:

table_set_default send_frame _drop
table_set_default forward _drop
table_set_default ipv4_lpm _drop
table_add send_frame rewrite_mac 1 => 00:aa:bb:00:00:00
table_add send_frame rewrite_mac 2 => 00:aa:bb:00:00:01
table_add forward set_dmac 10.0.0.10 => 00:04:00:00:00:00
table_add forward set_dmac 10.0.1.10 => 00:04:00:00:00:01
table_add ipv4_lpm set_nhop 10.0.0.10/32 => 10.0.0.10 1
table_add ipv4_lpm set_nhop 10.0.1.10/32 => 10.0.1.10 2
6. Para testar, utilizar o console do mininet para executar novamente um ping entre as
estações do cenário.
> h1 ping h2
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.
64 bytes from 10.0.1.10: icmp_seq=7 ttl=63 time=4.71 ms
64 bytes from 10.0.1.10: icmp_seq=8 ttl=63 time=4.48 ms
O programa P4 utilizado nessa atividade prática e mais detalhes sobre a imple-

mentação do P4 podem ser encontradas no link https://github.com/p4lang.
1.3. Programação na Camada de Encaminhamento

Redes definidas por software (Software Defined Networking (SDN)) são redes cuja in-
fraestrutura física e lógica (software) são separadas em planos de controles diferentes. Na
arquitetura SDN, a lógica e o estado da rede estão logicamente centralizados. A função de
cada equipamento, ou conjunto de equipamentos, é realizada por um software especial-
izado chamado controlador SDN ou Sistema Operacional de Rede. Dessa forma tem-se
uma rede programável, flexível, robusta, simples e com controle centralizado [McKeown
et al. 2008].
Os controladores SDN criam uma visão abstrata da rede ao mesmo tempo que
esconde os detalhes das infraestruturas físicas e/ou virtual das camadas inferiores. Ro-
dando no topo do controlador SDN, as aplicações de rede podem executar não somente as
629
funções tradicionais como roteamento ou balanceamento de carga, mas também propor-

cionar novas serviços tais como serviços de conectividade fim-a-fim através de múltiplos
domínios [Bernardos et al. 2015].
Estas aplicações junto com as iniciativas da indústria e academia [Saraiva et al.
2014] estão provendo serviços de redes programáveis e flexíveis, os quais são os princi-
pais pilares para a rápida adoção da rede definida por software.
Anteriormente à adoção do SDN, os equipamentos de redes são considerados
como caixas pretas com código fechado e comportamento limitados ao que o equipa-
mento proporcionava. O gerenciamento desses equipamentos são feitos através de frame-
works próprios e exigiam uma equipe técnica exclusiva para isso. O SDN mudou esse
paradigma trazendo interfaces abertas (ex, OpenFlow) para instruir os equipamentos o
que fazer, sendo que a tomada de decisão fica centralizado em um equipamento externo.
Orquestrador de serviços, OSS e outros aplicações de rede podem ser desenvolvi-
dos usando Northbound APIs implementados pelos controladores SDN. Northbound API
são ainda um questão aberta com diferentes controladores oferendo uma variedade de
soluções por exemplo, RESTful [Richardson and Ruby 2008], NVP [Koponen et al. 2010]
e SDMN [Pentikousis et al. 2013]. A comunicação entre controlador e os equipamentos
de rede é feito através de Southbound APIs. Diferentes Southbound APIs tem sido propos-
tos, entretanto OpenFlow é o mais amplamente aceito no mercado. A figura 1.7 simplifica
a arquitetura SDN.
Figure 1.7. Visão simplificada de uma arquitetura SDN. Adaptado de [Kreutz et al. 2015]
1.3.1. OpenFlow
O OpenFlow [McKeown et al. 2008] é o primeiro protocolo padrão projetado especifica-
mente para SDN, proporcionando alto desempenho e controle de tráfego granular através
de dispositivos de rede de vários fornecedores. O OpenFlow é um protocolo aberto ado-
tado comercialmente como padrão para SDN. Grandes fabricantes de equipamentos de
rede como Cisco, Juniper, Extreme e HP já o utilizam.
OpenFlow é um protocolo que proporciona acesso à tabela de fluxos dos equipa-
mentos de rede. Dessa forma possibilita configurar várias ações sobre os fluxos de dados,
630
por exemplo, encaminhamento, descarte, túnel, VLAN [Das et al. 2011] e controlador de
redes ópticas [Saraiva and Castelo Branco Soares 2016]. Ele é formado por dois princi-
pais componentes, o switch OpenFlow, que implementa o plano de dados, e o controlador,
que implementa o plano de controle. A comunicação entre estes dois elementos é através
de um canal seguro. Os fluxos de dados da rede são gerenciados pelo controlador. A
Figura 1.8 ilustra a arquitetura do switch OpenFlow.
Figure 1.8. Visão geral da arquitetura do switch OpenFlow. Adaptado de [McKe-

own et al. 2008]
O switch OpenFlow analisa o tráfego de entrada e verifica se existe alguma regra

na tabela de fluxos que se enquadre com os dados analisados. Caso não exista, os dados,
ou parte deles, são enviados, através de um canal seguro, para o controlador definir uma
nova regra.
A versão OpenFlow 1.0 (2009) é formada por uma única tabela de fluxos organi-
zada por uma lista de regras. A tabela de fluxos é formada por 04 colunas: priority - define
a ordem de prioridade das regras, pattern - padrão de correspondência com os cabeçalhos
dos pacotes, actions - acões a serem aplicadas no fluxo (exemplos drop, forward e send to
controller), e counters - estatísticas de número de bytes e pacotes. Um exemplo de tabela
de fluxo do OpenFlow 1.0 é mostrada na tabela 1.1.
A versão OpenFlow 1.0 apresentava algumas limitações como números limitados
de campos de cabeçalho para a definição das regras e limitação para definição de regras
mais complexas com múltiplos estágios e tabelas em série e em paralelo. Em virtude
disso, novas versões dos OpenFlow foram surgindo nos últimos anos [Bosshart et al.
2014]. A tabela 1.2 mostra um resumo com a evolução do OpenFlow.
Atualmente a especificação do OpenFlow é aportada pela Open Networking Foun-
dation (ONF). A ONF é uma organização sem fins lucrativos que foca na adoção de redes
definidas por software através do desenvolvimento de padrões aberto. Para mais infor-
Table 1.1. Exemplo de regras do OpenFlow 1.0

Priority Pattern Actions Counters
2 srcp=10.0.0.* Forward(2) 2500
1 dstip=4.4.3.3,dstport=80 dstip:10.0.0.10, Forward(1) 3600
0 dstport=5050 Send to Controller 480
631
Table 1.2. Evolução do OpenFlow [Bosshart et al. 2014].

Versão Data # Cabeçalhos
OF 1.0 Dez 2009 12
OF 1.1 Fev 2011 15
OF 1.2 Dez 2011 36
OF 1.3 Jun 2012 40
OF 1.4 Out 2013 41
mações sobre o OpenFlow e ONF visite o sítio https://www.opennetworking.org/.
1.3.2. Atividade Prática

Esta atividade prática tem como objetivo ser um guia introdutório sobre o protocolo Open-
Flow para usuários iniciantes. As práticas são direcionadas para a especificação do Open-
Flow 1.0 e 1.3. Uma máquina virtual pré-configurada foi utilizada. A máquina virtual
inclui os softwares mininet (ferramenta de emulação de rede), Open vSwitch (switch de
sofware OpenFlow), wireshark3 (e plugins) e o controlador Ryu4 .
A figura 1.9 ilustra a topologia a ser utilizada nessa atividade. Isto será suficiente
para demonstrar como o OpenFlow funciona e proporcionará conhecimentos para apro-
fundar à utilização do protocolo.
Figure 1.9. Topologia da atividade prática sobre OpenFlow.
Passos iniciais com OpenFlow.
1. Iniciar topologia da rede usando o mininet e o protocolo OpenFlow 1.3 e Open

vSwitch(OVS).
sudo mn -- mac -- switch ovsk -- controller remote
2. Em outro terminal, inicie o wireshark na interface lo e utilize o filtro openflow_v4.

wireshark &
3. Inicie o controlador Ryu sem qualquer aplicação.

sudo ryu-manager
3 www.wireshark.org
4 osrg.github.io/ryu/
632
4. Verifique no wireshark quais as mensagens estão sendo trocadas entre controlador

e switch.
5. Agora vá para a CLI do mininet e tente um ping entre as duas estações.

> h1 ping h2
6. Verifique novamente as mensagens no wireshark.
7. Agora, insira algumas regras no switch para permitir o ping entre as estações usando
os comandos ovs-ofctl
sudo ovs-ofctl show s1
sudo ovs-ofctl dump-desc s1
sudo ovs-ofctl add-flow s1 priority=100,in_port=1,actions=output:2
sudo ovs-ofctl add-flow s1 priority=100,in_port=2,actions=output:1
sudo ovs-ofctl dump-flows s1
8. Tente novamente o ping entre as estações.
9. Verifique a vazão entre as duas estações usando a ferramenta iperf.

> iperf h1 h2
1.4. Programação na Camada de Orquestração e Gerenciamento

Tradicionalmente as operadoras de telecomunicações tem suas redes baseadas em in-
fraestrutura fortemente atreladas a topologias físicas e equipamentos proprietários. Em
virtude disso, os serviços oferecidos são limitados à topologia de rede e a localização dos
equipamentos de redes. Isso dificulta oferecer novos serviços com baixo custo e mais efi-
cientes [Mijumbi et al. 2016]. A virtualização das funções de rede, ou Network Function
Virtualization (NFV), surgiu com o objetivo de resolver esses problemas.
A tecnologia de virtualização de funções de rede é algo relativamente recente
porém já é uma realidade para muitos provedores e operadores de telecomunicação. De
acordo com o European Telecommunications Standards Institute (ETSI) Industry Spec-
ification Group (ISG) [ETSI Industry Specification Group (ISG) NFV 2014b], Network
Function Virtualization é responsável por separar as funções de rede do hardware e
oferecê-los através de serviços virtualizados, decompostos dentro de funções de rede vir-
tualizados (ou Virtualized Network Function (VNF)), rodando sobre servidores genéri-
cos.
O NFV promete a implantação de funções de rede mais flexíveis e mais rápidos
e escalamento dinâmico de VNFs. O processo de orquestração NFV torna a instanci-
ação de funções de rede um procedimento automatizado. Em um ambiente NFV, novos
serviços não requerem uma infraestrutura com hardwares específicos e procedimentos
complexos, simplesmente é necessário a instalação de um software, ou seja, criar uma ou
mais VNFs.
633
Além disso, o NFV é capaz de alocar funções de rede em locais mais apropriados
e prover melhor desempenho para o tráfego dos usuários. Um serviço de rede pode ser de-
composto em um ou mais VNFs, e cada uma pode ser formada por um ou mais máquinas
virtuais (ou Virtual Machines (VMs)). Cada VNF é especificada por um descritor de
função de rede virtualizada (ou Virtualized Network Function Descriptor (VNFD)) que
detalha as informações de funcionamento e implantação da VNF.
As VNFs podem ser conectadas ou combinadas juntas para oferecer um serviço
de comunicação de rede fim-a-fim. Isso é conhecido como cadeia de serviço (ou Service
Chain). A cadeia de Serviço fornece uma conectividade lógica entre os equipamentos
virtuais da NFV cuja a ordem de conectividade é importante. Ela também permite a
interconexão do ambiente lógico com redes físicas.
No escopo do ETSI NFV, cadeia de serviço é definido como um grafo de links
lógicos conectando funções de rede a fim de descrever o fluxo de tráfego entre estes
funções de rede. Esse conceito é equivalente ao Encadeamento de Funções de Serviço, ou
Service Function Chaining (SFC), definido pela Internet Engineering Task Force (IETF).
Um serviço de rede fim-a-fim pode usar um ou mais gráficos de encaminhamento
de funções de rede que conecta dois pontos finais através de funções de rede. A figura 1.10
descreve dois exemplos de serviços de rede fim-a-fim. O primeiro (linha verde) é com-
posto de VNFs do tipo vCPE (Virtual Customer Premises Equipment) e vFW (virtual
Firewall) e dois pontos finais (A1 e A2). O secundo é composto de VNFs do tipo vCPE e
vDPI (virtual Deep Packet Inspection) e os pontos finais B1 e B2. Observe-se que o NFV
permite compartilhar VNFs entre diferentes serviços de rede. Isso é uma vantagem em
termos de reutilização de recursos e rapidez na implementação dos serviços.
Figure 1.10. Exemplo de dois serviços de rede fim-a-fim em uma abordagem NFV.
O European Telecommunications Standards Institute (ETSI) [ETSI Industry

Specification Group (ISG) NFV 2014a] desde de 2012 propõe documentos de especi-
ficação e pré-padronização em diversas áreas, incluindo a área de orquestração e gerenci-
amento de funções de rede, ou Management and Orchestration (MANO). O ETSI desen-
volveu uma arquitetura de referência e especificações para o NFV-Management and Or-
634
chestration (NFV-MANO). Sua arquitetura inclui componentes e serviço físicos e virtu-

ais e recomendações de diversos componentes e interfaces entre os mesmos. A figura 1.11
mostra a arquitetura ETSI NFV como descrita no documento [ETSI Industry Specifica-
tion Group (ISG) NFV 2014a].
Figure 1.11. Arquitetura de referência NFV-MANO.
A arquitetura ETSI NFV é formada principalmente por sete blocos fun-

cionais [ETSI Industry Specification Group (ISG) NFV 2014a]:
• Operation Support System (OSS)/BSS: bloco responsável pela operação e apli-

cações de negócio que os provedores de serviço usam para provisionar e operar
seus serviços de rede. Ele não está fortemente integrado na arquitetura.
• Element Management (EM): componente responsável pelas funções de gerencia-

mento de rede de uma VNF em execução.
• VNF: bloco funcional que representa uma função de rede virtualizada implemen-
tada sobre um servidor físico. Por exemplo, um roteador ou switch virtual, firewall,
etc.
• NFV Infrastructure (NFV): representa todos os componentes de hardware (proces-

samento, armazenamento e rede) e software nas quais as VNFs são implementadas,
gerenciadas e executadas.
• Network Function Virtualization Orchestrator (NFVO): componente que orquestra

os recursos do NFVI através de vários Virtualized Infrastructure Managers (VIMs)
e gerencia o ciclo de vida dos serviços de rede.
• VNF Manager (VNFM): realiza a configuração e gerenciamento do ciclo de vida

da VNF (ex. instanciação, atualização, consulta, escalonamento, término) no seu
próprio domínio.
635
• Virtualized Infrastructure Manager (VIM): prove controle e gerenciamento dos re-

cursos do NFVI bem como a interação da VNF com recursos de hardware. Por
exemplo, OpenStack5 como plataforma de nuvem e OpenDayLight e ONOS como
controladores SDN.
Alguns componentes são organizados em blocos maiores. O bloco funcional

NFV-MANO executa todas as tarefas de automação, coordenação e gerenciamento na
arquitetura NFV e inclui os componentes NFVO, VNFM e VIM.
Entretanto, o NFV-MANO não especifica nada sobre SDN em sua arquitetura.
Ele assume que a infraestrutura de transporte já está estabelecida e pronta para uso. Além
disso, o ETSI somente faz recomendações sobre a arquitetura e não define detalhes técni-
cos principalmente a serviços de rede fim-a-fim. Como também, existe pouca documen-
tação quanto a casos que envolva múltiplas redes com diferentes tecnologias [Katsalis
et al. 2016].
Na próxima seção será apresentada uma atividade prática com um framework de
orquestração NFV do OpenStack chamado de Tacker [OpenStack Foundation 2016].
1.4.1. Atividade prática

Nesta seção é apresentado uma atividade prática com o objetivo de mostrar as principais
funcionalidades da virtualização das funções de rede. A atividade consiste em implantar
um serviço de rede usando um framework de orquestração. Todo o serviço é detalhado
através de um descritor e orquestrado automaticamente em uma infraestrutura de nuvem.
O framework de orquestração NFV é o Tacker e o VIM é o OpenStack.
1.4.1.1. Tacker
Tacker [OpenStack Foundation 2016] é um projeto do OpenStack que implementa um

genérico VNFM e um NFVO para gerenciar e operar serviços de rede e VNFs sobre
uma infraestrutura NFV. Ele é baseado na arquitetura de referência ETSI NFV-MANO
e combina NFVO e VNFM em um único componente, entretanto internamente as fun-
cionalidades são divididas.
Ele é diretamente integrado dentro do OpenStack e portanto prover integração
limitada com outros VIMs. No entanto, o Tacker faz o mapeamento para SFC e suporta
auto escalonamento e templates NFV TOSCA.
Topology and Orchestration Specification for Cloud Applications (TOSCA) [OA-
SIS 2017] é uma linguagem para descrever a topologia de nuvens, seus componentes e
relacionamentos. TOSCA foca em automatizar a implantação de aplicações e gerencia-
mento de ciclo de vida. Ela pode ser usado no domínio NFV para a definição de VNF e
Network Service (NS), monitoramento de nós e políticas como escalonamento e restau-
ração.
5 www.openstack.org
636
1.4.1.2. Descrição da atividade
O fluxo de trabalho para a implementação de uma VNF ou NS no Tacker consiste das

seguintes etapas:
1. Embarcar a VNF ou NS no framework;

Enviar templates VNFD TOSCA para o Tacker usando a CLI ou GUI;
2. Implantação da VNF pode usar o catálogo do Tacker ou diretamente usando o tem-

plate VNFD;
3. Criar as funções virtuais usando os componentes do OpenStack;
4. A VNFD é gerenciada e configurada via driver de gerenciamento;
5. O driver de gerenciamento monitora a VNF e em caso de falhas uma mensagem é

enviada para a API do Tacker;
O VNFD e o NS descritor são baseados no TOSCA V1.0 CSD 036 e escritos

em YAML. As informações de comportamento e implementação da VNF no Tacker
é definida no VNFD. Vários exemplos de VNFD e NS descritor são encontrados em
http://github.com/openstack/tacker/tree/master/samples/tosca-templates/.
A atividade prática consiste em implantar um roteador OpenWRT7 como uma
função de rede virtual. Para isso siga os passos abaixo:
1. Garantir que o Tacker tenha a imagem do OpenWRT. Caso não, usar o comando
abaixo para fazer o upload da imagem.
openstack image create OpenWRT -- disk-format qcow2 -- container-format
bare -- file caminho/Para/Imagem/imagem.img -- public
2. Fazer o download do template yaml chamado tosca-vnfd-openwrt-with-firewall-

rules.yaml que contém configurações do OpenWRT e algumas regras de firewall.
3. Criar uma VNFD no Tacker.

tacker vnfd-create -- vnfd-file tosca-vnfd-openwrt-with-firewall-rules.yaml
openwrtVNFD
4. Criar um VNF a partir do VNFD criado no passo anterior.

tacker vnf-create -- vnfd-name openwrtVNFD openwrtVNF
5. Verificar o status.
tacker vnfd-list
tacker vnf-list
tacker vnf-show <VNF_ID>
6 http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd03/tosca-nfv-v1.0-csd03.html
7 https://openwrt.org/
637
6. Acessar a máquina virtual criada (utilizar a interface web do Tacker ou Openstack)

e confirmar se as regras de firewall foram inseridas
cat /etc/config/firewall
7. Para deleter uma VNFD e uma VNF utilizar os comandos, respectivamente:

tacker vnfd-delete <VNF_ID/NAME>
tacker vnf-delete <VNF_ID/NAME>
1.5. Desafios e Oportunidades de Pesquisa

Na área de programação e virtualização de redes existem muitos desafios que necessitam
de atenção da comunidade científica, industrias e órgãos de padronização. A rede difere
do ambiente de nuvem em dois fatores: as cargas de trabalho no plano de dados são
extremamente altas o que leva a uma busca constante por alta performance, e a rede
requer uma visão geral de toda a topologia para o gerenciamento e estabelecimento de
conexões fim-a-fim. Discuti-se nas próximas seções os principais desafios na área de
"softwarização" de rede.
1.5.1. Desempenho
As mudanças que as tecnologias de processamento de pacotes, SDN e NFV trouxeram
para o ambiente de redes tornou-o extremamente virtualizado e baseado em software. En-
tão, o desempenho é um desafio constante nesse ambiente altamente dinâmico de funções
e serviços virtuais.
Atualmente, o throughput de switches OpenFlow comerciais varia de 38 a 1000
fluxos por segundos [Bifulco and Dusi 2014], [Stephens et al. 2012]. Isso é um fator
limitante que deverá ser abordado no projeto dos processadores dos swithes. O suporte
do OpenFlow nas atuais linhas de produção tem sido mais uma adaptação do que um
planejamento para um projeto específico. Uma possível solução seria a evolução dos
switches SDN através de atividades de padronização das API southbound [Kreutz et al.
2015].
Tecnologias já existentes, como DPDK, ClickOS e FPGA, estão dando suporte aos
desafios de desempenho do NFV, tais como balanceamento de carga dinâmico e automa-
tizado e escalabilidade. É importante notar pela figura 1.12 a complexidade de uso versus
a eficiência de chips genéricos (CPU) podem atender casos de usos mais complexos e
portanto podem habilitar o conceito de NFV [Siracusa et al. 2013].
1.5.2. Portabilidade
A portabilidade e a integração com sistemas legados também é um grande desafio para
"softwarização" de redes. Quanto a linguagem P4, esse problema teoricamente é re-
solvido, pois ela é independente do tipo do hardware. O compilador permitirá o fun-
cionamento de um mesmo programa P4 em várias plataformas diferentes. O que muda é
o compilador e não o programa em si.
Quanto a SDN, a escolha da implementação do switch tem fator decisivo no seu
comportamento, precisão e desempenho, variando desde contadores de fluxos até na
638
Figure 1.12. Eficiência de chip vs. complexidade de caso de uso [Siracusa et al. 2013].
definição das interfaces northbound e southbound. Diferentes implementações dificul-

tam a portabilidade e a integração com equipamentos legados. O OpenFlow é a interface
southbound mais amplamente aceita e implementada pelos fabricantes. No entanto, as
interfaces northbound ainda não foi amplamente padronizada e diferentes controladores
oferecem uma variedade de soluções. Com isso, às aplicações de rede geralmente não são
portáveis entre controladores diferentes.
Atualmente as infraestruturas das operadoras são organizadas em vários domínios
que diferem em termos de localização geográfica, gerenciamento, limites administrativos
e tecnologias. A arquitetura de referência ETSI NFV define recomendações para as inter-
faces de comunicação entre os diversos componentes, porém muitas soluções NFV tais
como ONAP [Foundation 2017], Tacker, OpenBaton8 não possuem interoperabilidade.
Ou seja, um VNF criada em uma dessas soluções não é facilmente migrado para outra
plataforma.
Além disso, não existe ainda uma modelagem de serviços e recursos padrão que
permita uma portabilidade de descritores de NS e VNF entre plataformas NFV diferentes.
Existem alguns templates e linguagens de modelagem que propõe algo similar, tais como
TOSCA, YANG e HOT.
Outro desafio a ser avaliado é o estabelecimento de serviços fim-a-fim onde múlti-
plos provedores de serviços necessitam interoperar, não só em relação as funções de rede
em si, mas também nas negociações de parâmetros de SLAs, de configuração e de bil-
hetagem.
1.5.3. Segurança
Uma infraestrutura de rede softwarizada e virtualizada modifica a forma como os fluxos
de dados e serviços são implementados. E isso impacta diretamente na segurança da rede.
Portanto, novos recursos e funcionalidades necessitam ser implantadas, incluindo capaci-
8 http://openbaton.github.io/
639
dades de gerenciamento avançados de autenticação, identidade e controle de acesso.

A programabilidade e flexibilidade oferecida pela programação de processadores
de pacotes não deve deixar brechas para acesso indevidos às tabelas Match+Action e
manipulação de metadados.
Devido os ataques cibernéticos serem realizados através da rede, a segurança é
um das prioridades principais do SDN. Algumas vulnerabilidades e vários problemas de
segurança foram identificados em redes baseados em OpenFlow [Shin et al. 2014], [Porras
et al. 2012]. Redes SDN tem uma característica que pode viabilizar alguns ataques, elas
concentram o gerenciamento do plano de controle em um equipamento centralizado. As
interfaces northbound e southbound de um controlador SDN devem ser abertas, porém
isso não significa que devem ser vulneráveis e de fácil acesso. Elas devem implementar
mecanismos de segurança e criptografia para evitar a manipulação indevida dos fluxos de
dados.
A definição de funções de redes em servidores comuns pode propiciar o surgi-
mento de falhas de segurança em níveis de virtualização advindos do NFV [Rosa et al.
2014]. Algumas interfaces de comunicação podem ser implementadas internamente em
uma solução NFV o que pode esconder detalhes da comunicação entre os componentes.
No entanto a segurança da comunicação da pilha NFV com elementos externos como OS-
S/BSS e outros orquestradores ainda continua problema em aberto e passível de pesquisa.
1.5.4. Integração P4, SDN e NFV

A programação de processadores de pacotes e mais especificamente a linguagem P4 vi-
abilizam uma "softwarização" no plano de dados dos equipamentos de rede. Já, o SDN
proporciona encaminhamento flexível e direcionamento de tráfego em ambientes de rede
virtual e físico, ou seja, reformula a arquitetura de rede. Enquanto isso, NFV permite uma
colocação flexível de funções de rede virtualizadas através da rede e da nuvem. Com isso,
o NFV propõe uma nova arquitetura para as redes de telecomunicações [Rostami 2014].
Todas esses tecnologias propõem diversas inovações e arquiteturas voltadas para
a programabilidade em redes. No entanto, a integração dessas tecnologias é um grande
desafio. Nota-se que P4, SDN e NFV são ferramentas complementares com o objetivo de
alcançar uma programabilidade completa da rede.
É importante ressaltar que SDN e NFV são independentes, mas isso não ocorre
entre P4 e SDN. A linguagem P4 seria uma versão 2.0 do protocolo OpenFlow. Enquanto
SDN traz uma "inteligência" e programabilidade no plano de controle, o P4 permite uma
maior flexibilidade diretamente no plano de dados. Então é necessário existir uma estreita
relação entre plano de dados e controle. No entanto, não existe uma padronização de como
deve ser essa relação SDN e P4, por exemplo, novas funcionalidades devem ser propostas
pelo controlador ou diretamente aplicada no dispositivo de rede com a compilação do P4?
O NFV cria serviços de rede fim-a-fim que atravessam diferentes domínios ad-
ministrativos e tecnológicos com funções de redes virtualizadas geograficamente sepa-
radas. O SDN permite a conectividade entre essas diversas VNFs viabilizando o estab-
elecimento do serviço de rede. No entanto, na arquitetura de referência ETSI NFV não
está claro a definição de SDN. O controlador SDN pode fazer parte do próprio VIM, ou
640
mesmo ser uma função de rede virtualizada. Existe algumas soluções de orquestração tais
como ONAP e CORD que definem um novo componente SDN em suas arquiteturas. É
necessário uma maior investigação nesse sentido.
1.6. Conclusão
As tradicionais redes são caracterizadas pela forte ligação com hardware fixos e propri-
etários. Esse modelo vem mostrando-se não escalável e inflexível à mudanças. Além
disso, gera um alto custo de implantação devido a aquisição de hardwares específicos,
como também um alto custo de operação e manutenção com complexos gerenciamentos
e manutenção de uma equipe técnica especializada na plataforma adquirida.
A "softwarização" de redes está mudando a forma com as redes são construídas e
gerenciadas permitindo maior flexibilidade, escalabilidade e automação. Nesse minicurso
abordamos as três principais tecnologias fundamentais no processo de "softwarização" de
redes: Programação de processador de pacotes, Redes definidas por Software e Funções
de Redes Virtualizadas. Essa abordagem consiste de uma visão geral de cada tecnologia.
Atividades práticas foram apresentadas com o objetivo de direcionar os participantes em
seus primeiros experimentos com P4, OpenFlow e NFV.
A tecnologia SDN apresenta-se bem consolidada com aporte da ONF e com
plataformas amplamente aceitas como OpenDayLight e ONOS. O NFV ainda estão em
fase de padronização e com algumas soluções propostas como ONAP, Tacker, Cloudify e
OpenBaton. Já a programabilidade do plano de dados está evoluindo rapidamente com a
linguagem P4.
Entretanto, todos essas tecnologias apresentam desafios que necessitam ser estu-
dados e avalidos pela indústria e comunidade acadêmica. Apresentamos alguns desafios
comuns a essas tecnologias, mas muitos outros existem nesse meio tão fértil de novas
oportunidades de pesquisa.
Referências
[Bernardos et al. 2015] Bernardos, C. J., Dugeon, O., Galis, A., Morris, D., and Simon,
C. (2015). 5G Exchange (5GEx) – Multi-domain Orchestration for Software Defined
Infrastructures.
[Bifulco and Dusi 2014] Bifulco, R. and Dusi, M. (2014). Position paper: Reactive logic
in software-defined networking: Accounting for the limitations of the switches. 2014
Third European Workshop on Software Defined Networks (EWSDN), 00:97–102.
[BluePlanet 2017] BluePlanet (2017). Products | Multi-domain Service Orchestration.
[Bosshart et al. 2014] Bosshart, P., Varghese, G., Walker, D., Daly, D., Gibb, G., Izzard,
M., McKeown, N., Rexford, J., Schlesinger, C., Talayco, D., and Vahdat, A. (2014).
P4: Programming Protocol-Independent Packet Processors. ACM SIGCOMM Com-
puter Communication Review, 44(3):87–95.
641
[Das et al. 2011] Das, S., Sharafat, A., Parulkar, G., and McKeown, N. (2011). Mpls with
a simple open control plane. In Optical Fiber Communication Conference/National
Fiber Optic Engineers Conference 2011, page OWP2. Optical Society of America.
[ETSI Industry Specification Group (ISG) NFV 2014a] ETSI Industry Specification
Group (ISG) NFV (2014a). Network Functions Virtualisation (NFV); Management
and Orchestration; Report on Architectural Options.
[ETSI Industry Specification Group (ISG) NFV 2014b] ETSI Industry Specification
Group (ISG) NFV (2014b). Network Functions Virtualisation (NFV); Terminology
for Main Concepts in NFV.
[Foundation 2017] Foundation, L. (2017). ONAP – Open Network Automation Platform.
[Galis et al. 2014] Galis, A., Clayman, S., Mamatas, L., Serrat, J., Rubio-loyola, J., Man-
zalini, A., and Zahariadis, T. (2014). Softwarization of Future Networks and Services
- Programmable Enabled Networks as Next Generation Software Defined Networks.
IEEE SDN for Future Networks and Services (SDN4FNS).
[Katsalis et al. 2016] Katsalis, K., Nikaein, N., and Edmonds, A. (2016). Multi-Domain
Orchestration for NFV: Challenges and Research Directions. In 2016 15th Interna-
tional Conference on Ubiquitous Computing and Communications and 2016 Interna-
tional Symposium on Cyberspace and Security (IUCC-CSS), pages 189–195. IEEE.
[Kim 2016] Kim, C. (2016). Tutorial-Programming The Network Data Plane in P4.
[Koponen et al. 2010] Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski, L.,
Zhu, M., Ramanathan, R., Iwata, Y., Inoue, H., Hama, T., and Shenker, S. (2010). Onix:
A Distributed Control Platform for Large-scale Production Networks. In Operating
Systems Design and Implementation - OSDI, volume 10, pages 1–6.
[Kreutz et al. 2015] Kreutz, D., Ramos, F. M. V., Esteves Verissimo, P., Esteve Rothen-
berg, C., Azodolmolky, S., and Uhlig, S. (2015). Software-Defined Networking: A
Comprehensive Survey. Proceedings of the IEEE, 103(1):14–76.
[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Pe-
terson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: Enabling inno-
vation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74.
[Mijumbi et al. 2016] Mijumbi, R., Serrat, J., Gorricho, J.-l., Bouten, N., De Turck, F.,
and Boutaba, R. (2016). Network Function Virtualization: State-of-the-Art and Re-
search Challenges. IEEE Communications Surveys & Tutorials, 18(1):236–262.
[OASIS 2017] OASIS (2017). TOSCA Simple Profile for Network Functions Virtualiza-
tion (NFV)—Version 1.0.
[OpenStack Foundation 2016] OpenStack Foundation (2016). Tacker - OpenStack.
[Pentikousis et al. 2013] Pentikousis, K., Wang, Y., and Hu, W. (2013). Mobileflow: To-
ward software-defined mobile networks. IEEE Communications Magazine, 51(7):44–
53.
642
[Porras et al. 2012] Porras, P., Shin, S., Yegneswaran, V., Fong, M., Tyson, M., and Gu,
G. (2012). A security enforcement kernel for openflow networks. In Proceedings of
the First Workshop on Hot Topics in Software Defined Networks, HotSDN ’12, pages
121–126, New York, NY, USA. ACM.
[Richardson and Ruby 2008] Richardson, L. and Ruby, S. (2008). RESTful web services.
" O’Reilly Media, Inc.".
[Rosa et al. 2014] Rosa, R. V., Esteve, C., Unicamp, R., Barea, E., Ufscar, C. A., and
Cavalheiro, M. (2014). Network Function Virtualization: Perspectivas, Realidades
e Desafios. In Minicurso do 32o Simpósio Brasileiro de Redes de Computadores e
Sistemas Distribuídos – SBRC 2014.
[Rosa et al. 2015] Rosa, R. V., Santos, M. A. S., and Rothenberg, C. E. (2015). MD2-
NFV: The case for multi-domain distributed network functions virtualization. In 2015
International Conference and Workshops on Networked Systems (NetSys), pages 1–5.
IEEE.
[Rostami 2014] Rostami, A. (2014). The Evolution of Programmable Networks : From
Active Networks to Software Defined Networks ( SDN ).
[Saraiva et al. 2014] Saraiva, N., Falcao, T., Macedo, A., and Soares, A. (2014). A pro-
posed architecture for choice of switching paradigm in hybrid optical networks (OC-
S/OBS). In Proceedings of the 2014 Latin American Computing Conference, CLEI
2014.
[Saraiva and Castelo Branco Soares 2016] Saraiva, N. F. and Castelo Branco Soares,
A. (2016). A Performance Evaluation Programmable Architecture for Choice of
Switching Paradigm in Hybrid Optical Networks. IEEE Latin America Transactions,
14(11):4567–4572.
[Shin et al. 2014] Shin, S., Song, Y., Lee, T., Lee, S., Chung, J., Porras, P., Yeg-
neswaran, V., Noh, J., and Kang, B. B. (2014). Rosemary: A robust, secure, and
high-performance network operating system. In Proceedings of the 2014 ACM SIGSAC
Conference on Computer and Communications Security, CCS ’14, pages 78–89, New
York, NY, USA. ACM.
[Siracusa et al. 2013] Siracusa, D., Salvadori, E., and Rasheed, T. (2013). Edge-to-edge
virtualization and orchestration in heterogeneous transport networks. In 2013 IEEE
SDN for Future Networks and Services (SDN4FNS), pages 1–6.
[Sonkoly et al. 2014] Sonkoly, B., Szabo, R., Jocha, D., Czentye, J., Kind, M., and West-
phal, F.-J. (2014). UNIFYing Cloud and Carrier Network Resources: An Architectural
View. In 2015 IEEE Global Communications Conference (GLOBECOM), pages 1–7.
IEEE.
[Stephens et al. 2012] Stephens, B., Cox, A., Felter, W., Dixon, C., and Carter, J. (2012).
Past: Scalable ethernet for data centers. In Proceedings of the 8th International Con-
ference on Emerging Networking Experiments and Technologies, CoNEXT ’12, pages
49–60, New York, NY, USA. ACM.
643
Capítulo
2
Roteamento Dinâmico em IoT baseado em
Requisitos de Aplicações Específicas
Harilton da Silva Araújo, Raimir Holanda Filho, Joel J. P. C. Rodrigues, Ricardo

de Andrade L. Rabelo, Natanael de Carvalho Sousa, José C. C. L. S. Filho, José
Victor Vasconcelos Sobral
Abstract
The pervasive presence of a variety of devices led to the creation of the Internet of
Things (IoT) paradigm. Data dissemination in IoT is generally application dependent
and requires context-aware routing protocols. This chapter aims to present the main
routing concepts in IoT and demonstrate the operation of dynamic routing protocols
inspired by RPL. In addition, an approach for Dynamic Route Selection in IoT based on
Contextual Information will be presented. It is expected that at the end of this chapter
the reader will be able to propose dynamic routing protocols for specific IoT
applications using the approach presented here.
Resumo
A presença pervasiva de uma variedade de dispositivos levou a criação do paradigma
conhecido como Internet das Coisas (Internet of Things - IoT). A disseminação de
dados em IoT é, geralmente, dependente da aplicação e exige protocolos de roteamento
ciente de contexto. Este capítulo tem por objetivo apresentar os principais conceitos de
roteamento em IoT e demonstrar o funcionamento de protocolos de roteamento
dinâmico inspirados no RPL. Além disso, será apresentada uma abordagem para
Seleção Dinâmica de Rotas em IoT baseada em Informações Contextuais. Espera-se
que ao final deste capítulo, o leitor esteja apto a propor protocolos de roteamento
dinâmicos para aplicações específicas de IoT utilizando a abordagem aqui
apresentada.
644
2.1. Introdução
A Internet das Coisas (Internet of Things - IoT) é a presença pervasiva de uma variedade
de dispositivos, tais como: sensores, etiquetas de Radio Frequency Identification
(RFID), smartphones, dentre outros dispositivos que são capazes de interagir uns com
os outros para um objetivo comum (Atzori et al., 2010). No cenário de IoT, a
pluralidade é crescente e previsões indicam que mais de 40 bilhões de dispositivos
estarão conectados até 2020 [Forbes 2014], possibilitando o surgimento de novas
possibilidades de aplicações, como exemplo: cidades inteligentes, saúde, casas
inteligentes, etc.
Entre as tecnologias mais promissoras para o paradigma de IoT estão a RFID e
Redes de Sensores sem Fio (RSSF), segundo [Atzori et al., 2010] e [Sobral et al. 2015].
As RSSF possuem limitações na identificação de um objeto/pessoa em determinados
tipos de aplicação. No entanto, ao contrário das RSSF, os sistemas RFID não são
capazes de sensorear dados do local onde estão inseridos, tais como: humidade,
temperatura e pressão, proporcionados pela RSSF. Essa é uma indicação de que a IoT,
por meio da integração entre as tecnologias RFID e RSSF, maximiza os seus benefícios
criando novas perspectivas para diversas aplicações, como exemplo as que levam em
consideração as informações de contexto.
O contexto geralmente refere-se à localização, mas pode compreender diferentes
informações usadas para caracterizar entidades envolvidas na interação do usuário com
a aplicação. Segundo [Baldauf et al. 2007], sistemas sensíveis ao contexto são capazes
de adaptar seu comportamento às condições atuais, sem intervenção explícita do usuário
Em IoT, diversas informações como características do próprio dispositivo, do
ambiente que o cerca e de suas capacidades podem ser utilizadas como fonte de
informações contextuais. Muitos trabalhos disponíveis na literatura convergem esforços
para atender questões envolvendo sensibilidade ao contexto em IoT, especialmente
durante a fase de seleção de rotas. Nessa fase, os dispositivos (que possuem fortes
restrições de recursos) processam localmente as informações contextuais a fim de
selecionar o caminho que melhor atenda as necessidades de determinada aplicação.
Esta característica requer protocolos de roteamento sensíveis ao contexto para o
cumprimento de diversos desafios durante a troca de mensagens em IoT, tais como:
menor delay, maior confiabilidade na transmissão dos dados e consumo mínimo de
energia. Baseado nesses desafios, este capítulo também abordará uma adaptação no
protocolo RPL (Routing Protocol for Low-power and Lossy-networks) - (RFC 6550),
que é implementada a partir da criação de quatro novas OF (Functions Objetive).
O uso das funções objetivo propostas ocorre no processo de estabelecimento de
rotas, de maneira a satisfazer aplicações tais como: monitoramento de temperatura em
áreas remotas e da qualidade do ar de uma cidade ou região específica, controle de fluxo
de veículos em uma via, dentre outras.
A estrutura do capítulo está organizada da seguinte forma: a Seção 2.2 apresenta
os principais conceitos de roteamento em IoT. O protocolo RPL é detalhado na seção
2.3. A Seção 2.4 traz uma abordagem para a seleção dinâmica de rotas em IoT, seguida
pela conclusão na Seção 2.5.
645
2.2. Roteamento em IoT

A tecnologia IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) é
uma solução adequada para lidar com o desafio de prover escalabilidade (permitindo
suporte a grande quantidade de dispositivos conectados), padronização da rede além de
possibilitar a adaptação do protocolo RPL. Os dispositivos que utilizam a tecnologia
6LoWPAN possuem recursos limitados em termos de capacidade computacional,
memória, largura de banda de comunicação e de energia da bateria [Winter et al., 2012].
Uma solução de roteamento baseada em IPv6, foi proposta pelo Internet
Engineering Task Force - IETF por meio do Grupo de Trabalho Routing Over Low
power and Lossy - ROLL (IETF Datatracker, 2013). Tal solução consiste na
especificação do protocolo de roteamento RPL, juntamente com as especificações sobre
as métricas de roteamento e função objetivo.
O roteamento utilizando o RPL possibilita a adaptação às exigências de áreas de
aplicações específicas, conhecidas como contexto. Para cada área de aplicação existe
um documento RFC com uma função objetivo que mapeia os requisitos de otimização,
sendo que estes requisitos são definidos na RFC 5548 [Dohler, M., et al., 2009] para
aplicações urbanas de baixa potência, RFC 5673 [Pister, K., et al, 2009] para aplicações
industriais, na RFC 5826 [Brandt e Porcu, 2010] para aplicações de automação
residencial e no RFC 5867 [Martocci, J., et al., 2010] para a construção de aplicações de
automação.
Segundo [Vasseur, J., et al., 2012], o RPL emprega métricas, especificadas na
RFC 6551, que são apropriadas para ambientes 6LoWPAN, tais como: número de
saltos, latência, taxa de entrega, energia do nó, throughput, nível de qualidade do link e
confiabilidade de transmissão.
[Makris et al. 2013] especifica diferentes modelos de contexto, como o orientado
a objetos e o modelo baseado em ontologia A abordagem orientada a objetos estende
esse paradigma para a modelagem de contexto. Modelagem baseada em ontologia
organiza a informação em ontologias, utilizando abordagens semânticas, como a Web
Ontology Language (OWL). A inferência (reasoning) do contexto refere-se à
informação ou ao conhecimento que pode ser inferido a partir da análise de dados e
combinado com informações diferentes.
[Jayaraman e Delirhaghighi 2013] propõe uma abordagem ciente de situações
que altera o funcionamento de um nó sensor baseado nos fenômenos coletados
(contexto) do ambiente, tais como: temperatura, umidade, pressão, etc. A contribuição
do autor intitulada como SA-A-WSN (Situation-Aware Adaptation Approach for
Energy Conservation in Wireless Sensor Network), busca encontrar um trade-off entre
tempo de vida e a corretude dos dados coletados no ambiente a fim de atender uma
aplicação específica. Para tanto, a proposta deste autor objetiva controlar a forma em
que o nó sensor atua no ambiente sensoreado baseado em informações contextuais a fim
de reduzir o consumo de energia da rede.
Em [Thubert 2012] foi proposta uma função objetivo padrão para o RPL
denominada OF0 (Objective Function Zero), projetada para possibilitar a
interoperabilidade entre diferentes implementações do RPL. A OF0 possui um
funcionamento simplista e não utiliza métricas de roteamento na definição do rank. Um
nó escolhe como pai preferido o vizinho alcançável que possuir o menor rank.
646
Em [Levis e Gnawali 2012] foi apresentada a função objetivo MRHOF

(Minimum Rank with Hysteresis Objective Function), baseada no conceito de container
de métricas que explicitam um conjunto de propriedades das métricas e/ou restrições a
serem consideradas no roteamento, difundidas por meio das mensagens DIO. A
MRHOF é compatível apenas com métricas especificadas na RFC 6719. A seleção dos
pais preferidos é feita com base no custo do caminho levando em consideração a
métrica adotada, onde as rotas que minimizam o custo associado a métrica são
preferíveis. Por padrão a MRHOF utiliza o ETX [Couto et. al 2003] que mede a
qualidade do link e objetiva maximizar a vazão de dados. O ETX é definido conforme a
expressão (1).
1
𝐸𝑇𝑋 = (1)
𝐷𝑓. 𝐷𝑟𝑠𝑠
Onde:
 Df é a probabilidade do pacote ser recebido pelo vizinho;
 Dr é a probabilidade do ACK ser recebido com sucesso.
Uma função objetivo sensível ao contexto denominada CAOF (Context Aware

Objective Function), proposta por [Sharkawy et al. 2014] e destinadas às redes de
sensores sem fio, se baseia nos recursos residuais e na mudança de estado do nó sensor
ao longo do tempo. A função proposta por [Sharkawy et al. 2014] realiza uma soma
ponderada das métricas: grau de conectividade do nó, nível energético da bateria e
posição do nó na árvore de roteamento em relação ao nó progenitor. O objetivo final da
função proposta por [Sharkawy et al. 2014] é encontrar uma probabilidade de entrega
para cada nó sensor.
A utilização de lógica fuzzy para cálculo da função objetivo para o protocolo
RPL é proposta por [Gaddour et al. 2014]. Neste trabalho a função objetivo é o
componente utilizado para selecionar os caminhos identificando um nó pai dentre
diversos nós existentes. A função objetivo denominada OF-FL (Fuzzy Logic) associa
parâmetros a variáveis linguísticas que são combinadas com regras fuzzy pré-definidas a
fim de identificar a rota a ser selecionada. Os parâmetros considerados na OF-FL são
números de saltos, tempo de atraso fim-a-fim, taxa de perda de pacotes e taxa de
mudança de rotas default.
Em [Chen et al 2015] foi proposta uma Objective Function SCAOF (A Scalable
Context-Aware Objective Function), que adapta o protocolo RPL ao monitoramento
ambiental na área da agricultura com contexto escalável. A SCAOF teve o seu
desempenho avaliado tanto na simulação como em testes de campo. Os resultados
experimentais obtidos confirmam que SCAOF pode prolongar a vida útil da rede e
melhorar a QoS nos diferentes cenários de simulação voltados para a agricultura.
Os trabalhos dos autores [Sharkawy et al. 2014] e [Gaddour et al. 2014],
motivaram para a elaboração da abordagem proposta na seção 2.4 por duas
características: por empregar métricas que são apropriadas para ambientes 6LoWPAN e
por realizar uma soma ponderada de métricas a fim de proporcionar uma qualidade na
entrega das mensagens trafegadas em uma rede de sensores sem fio.
647
2.3. O Protocolo RPL

O RPL é um protocolo implementado na camada de rede, projetado especialmente para
funcionar em conjunto com 6LoWPAN e operar sobre diversos mecanismos de camada
de enlace incluindo IEEE 802.15.4 camadas MAC e PHY [Brandt et al. 2012]. O RPL
organiza hierarquicamente a rede em uma topologia em árvore e define os melhores
caminhos na rede a partir de uma função objetivo, considerando métricas de custo,
como por exemplo: número de saltos, latência, taxa de entrega, energia do nó,
throughput, nível de qualidade do link e confiabilidade de transmissão, conforme
descrito na RFC 6551.
O RPL utiliza uma topologia em árvore construída a partir de nós raízes,
suportando três tipos de tráfego: Tráfego do gateway para múltiplos nós em
comunicações point-to-multipoint (P2MP), Tráfego de muitos nós para o gateway em
comunicações multipoint-to-point (MP2P) e Comunicação point-to-point (P2P). A
topologia em árvore é baseada no conceito de Direct Acyclic Graph (DAG).
Em cenários de IoT utilizando o RPL, os objetos são os dispositivos que
compõem uma rede cujas relações, entre eles, são as suas próprias ligações. Em um
DAG, os objetos não têm ligações/relações com eles próprios (nenhum caminho se
inicia e termina no mesmo objeto) mas mantêm sempre ligações com os objetos
vizinhos, sendo o grafo obrigado a possuir pelo menos um objeto fonte e um objeto raiz.
No RPL, os Destination Oriented DAG (DODAG) são construídos segundo uma
função objetivo que define a posição para cada nó. A partir dos resultados obtidos com a
função objetivo, os nós escolhem e otimizam os caminhos utilizados para o envio de
pacotes de dados. O resultado da função objetivo é calculado a partir de métricas de
custo, como por exemplo, a qualidade das ligações, energia residual dos nós, latência,
etc.
Um cenário de IoT com RPL pode ser modelado como um grafo G = (N, L),
onde N é o conjunto dos n nós (excluindo o nó raiz) presentes na rede e L é o conjunto
de ligações que interliga esses nós. Para cada nó ni ϵ Ns (i=1,2,...n) existe um conjunto A
de nós candidatos cuja eleição para se tornarem o nó pai de outro nó é realizada baseada
no rank de cada um dos nós. O conjunto dos nós de uma rede e o conjunto de nós
progenitores de qualquer outro nó são representados pelos conjuntos das Expressões (2)
e (3), respectivamente:
𝑁𝑠 = {𝑛1, 𝑛2, . . . 𝑛𝑛} (2)
𝐴(𝑛𝑖) = {𝑎1, 𝑎2, . . . , 𝑎𝑚) (3)
Sendo A um subconjunto do número total de nós, tem-se
𝐴(𝑛𝑖) = ⊂ 𝑁𝑠. O nó raíz representado como ns, é o único nó da rede que não possui
lista de candidatos e, portanto, o seu subconjunto é vazio, expressão (4):
𝐴(𝑛𝑠) = {∅} (4)
Para cada nó ni existe um conjunto de m ligações l, igual ao número de nós
candidatos, conforme demonstrado na expressão (5). No conjunto L existe uma ligação
l pertencente a L(ni). Assim, tem-se que aj pertence a A(ni), onde aj é o nó candidato
selecionado para ser o nó pai de ni.
𝐿(𝑛𝑖) = {𝑙1, 𝑙2, . . . , 𝑙𝑛} (5)
648
Na expressão (6) cada ligação l tem um rank, igual ao rank calculado no nó ni,
em relação a um nó pai selecionado aj (j=1, 2, ..., m):
𝑙(𝑛𝑖, 𝑎𝑗) = 𝑟𝑎𝑛𝑘 (6)

A expressão (7) deve ser seguida para que um nó candidato 𝑎𝑝 seja selecionado
como nó pai. Neste caso, quando o rank calculado, representando por 𝑎𝑝, é maior que o
rank do 𝑎𝑗 (emissor), o 𝑎𝑝 (receptor) aceita o 𝑎𝑗 como sendo seu nó pai, criando através
dele um caminho até o 𝑛𝑠 (nó raíz). Caso contrário, rejeita o emissor como sendo seu nó
pai.
𝑙(𝑛𝑖, 𝑎𝑝) > ∀𝑙(𝑛𝑖, 𝑎𝑗) (7)
Concluindo, a construção da rede para cada nó ni pode ser definida da seguinte
forma:
C = {∀ 𝑛𝑖 ∈ 𝑁𝑠, ∋ 𝑎𝑝 ∈ 𝐴(𝑛𝑖): 𝑙(𝑛𝑖, 𝑎𝑝) > ∀𝑙(𝑛𝑖, 𝑎𝑗)} (8)
O protocolo RPL é implementado em 4 fases:
a) Fase de Configuração:
A construção da rede é iniciada pela fase de configuração, que possui quatro
mensagens. Nessa fase, o gateway emite a primeira mensagem DODAG Information
Object (DIO) que representa a principal fonte de controle de roteamento. A segunda
mensagem enviada, chamada de Destination Object (DAO), habilita o tráfego
descendente de dados. A terceira mensagem enviada é o DODAG Information
Solicitation (DIS), que torna possível que um dado nó solicite uma mensagem DIO de
algum nó vizinho alcançável. Todos os seus nós vizinhos que receberem o DIO
adicionarão o gateway a uma tabela armazenada em memória, relacionada com a tabela
de roteamento, que armazena essencialmente o endereço dos nós vizinhos com os quais
existem futuras e possíveis ligações ascendente e descendente. A quarta mensagem é o
DAO-ACK, que é enviada em resposta ao recebimento de uma mensagem DAO.
b) Fase de Estabelecimento de Rotas:

Na fase de estabelecimento de rotas, o valor do rank do emissor é obtido a partir
do DIO e, após o seu processamento, os nós receptores calculam o seu rank com base
no rank do emissor. Quando o rank calculado é maior que o rank do emissor do DIO, o
receptor aceita o emissor como sendo seu nó progenitor para roteamentos ascendentes,
criando, através dele, uma rota até o gateway. Caso contrário, rejeita o emissor como
sendo seu nó progenitor.
Quando um nó ni receber um pacote DIO de um nó ns, três casos devem ser
avaliados para o estabelecimento de rotas:
i) Se o nó emissor ns está presente na sua lista de endereços;
ii) Se estiver presente, mas não for o seu progenitor corresponde ao segundo caso;
iii) Se estiver e for o seu nó progenitor corresponde ao terceiro caso.
Nessa fase, o protocolo RPL, em sua versão original, utiliza a OF0 (Type 0
Objective Function) para habilitar os nós a selecionarem os nós pai (rota default),
649
considerando informações do rank e o número de saltos de um determinado nó para o

sink, conforme descrita na expressão (9):
R(N)=R(P)+rank_increase (9)
Onde:
 R(N),é o novo rank do nó;
 R(P),é o rank do pai preferido;
 rank_increase, é um fator de variação (delta) entre o rank do pai e o do próprio
nó, descrito na expressão (10):
rank_increase=(Rf*Sp+Sr)*MinHoprank_increase (10)
Onde:
 Rf é o um fator configurável que é usado para multiplicar o valor da propriedade
do link. Por default, utiliza o valor 1;
 Sp,é o passo do rank;
 Sr,é o valor máximo atribuído ao nível do rank a fim de permitir um sucessor
viável.
 MinHoprank_increase, é o incremento mínimo em rank entre um nó e qualquer
de seus pais, cujo valor default é 256;
c) Fase de Comunicação de Dados:

Nessa fase, as mensagens trafegam pela rede com destino ao gateway,
obedecendo as rotas selecionadas na fase de estabelecimento de rotas. Durante a
comunicação, o tráfego de pacotes pode ocorrer de forma ascendente ou descendente.
d) Fase de Reconstrução de Caminhos:

Em função das características inerentes as topologias de rede, as rotas com
destino aos nós progenitores podem ser atualizadas. As alterações nas rotas ascendentes
exigem a necessidade de atualizar as rotas de ligação descendente. Assim, um pacote
(Destination Advertisement Object - DAO) deve ser emitido por um nó (seja o nó
origem, ou seja, um nó intermédiário) sempre que uma rota for atualizada, ou sempre
que se altera o nó progenitor.
2.4. Seleção Dinâmica de Rotas em IoT

Como forma de adaptação do protocolo RPL, foram propostas e avaliadas quatro
funções objetivo a serem utilizadas na fase de estabelecimento de rotas, a DQCA-OF1,
DQCA-OF2, DQCA-OF3 e DQCA-OF4.
Cada uma das funções objetivo são baseadas na fusão de métricas para
ambientes 6LoWPAN empregadas pelo RPL e descritas na RFC 6551. As informações
contextuais de cada aplicação são utilizadas para permitir, de forma dinâmica, a
650
adaptação do roteamento, buscando atender cenários que priorizam simultaneamente as

métricas especificadas na RFC 6551.
As funções objetivo propostas na abordagem permitem os dispositivos elegerem
os nós progenitores (rota default) por meio das informações de contexto obtidas da
aplicação. Cada aplicação pode possuir requisitos que exijam, simultaneamente, até três
métricas (ETX - Estimativa de transmissão) e/ou (NS - Número de saltos) e/ou (EC –
Energia Consumida), permitindo classifica-las, quanto ao nível de prioridade (N) em
(Alta = 1; Média = 3; Baixa = 5). Cada uma das métricas é representada por uma
função F.
A figura 1 apresenta o funcionamento da abordagem proposta, que é baseada na
relação de três módulos. O módulo aplicações representa o contexto de cada aplicação.
O módulo base de dados contém as funções objetivo que serão utilizadas para a geração
de rotas que atendam às exigências de cada aplicação.
Figura 1. Modelo Funcional da Abordagem Proposta
A partir dessas informações um peso T(ni) é obtido por cada dispositivo da rede,
que representa a soma das funções de contexto.
1) DQCA-OF1 (Delivery Quality and Context Aware Type 1 Objective Function):
T(ni)= NETX . FETX(ni) + NNS . FNS(ni) (11)

A função DQCA-OF1 é composta pelas métricas estimativa de transmissão
(ETX) e número de saltos (NS) para o cálculo de seleção de rotas.

T(ni)= NETX . FETX(ni) + NEC . FEC(ni) (12)
(ETX) e a energia consumida (EC) para o cálculo de seleção de rotas.
651

T(ni)= NNS . FNS(ni) + NEC . FEC(ni) (13)
A função DQCA-OF3 é composta pelas métricas número de saltos (NS) e
energia consumida (EC) para o cálculo de seleção de rotas.
T(ni)= NETX . FETX(ni) + NNS . FNS(ni) + NEC . FEC(ni) (14)

(ETX), número de saltos (NS) e energia consumida (EC) para o cálculo de seleção de
rotas.
A seleção das rotas é feita aplicando o valor de T(ni) no mecanismo de seleção
de rotas descrito na expressão (15), que permite os nós decidirem localmente por qual
rota encaminhar os dados sem incorrer em altos custos relacionados ao conhecimento de
toda a topologia da rede.
Pode-se representar o processo de seleção de rotas como a seguir. Seja G = (N,

L), um grafo direcionado onde N é o conjunto de vértices (dispositivos) e L é o conjunto
de pares (u,v) não ordenados de elementos em N conexões. Se for encaminhada uma
mensagem por um caminho 𝐶 = (𝑣1, 𝑣2, … , 𝑣𝑘−1 , 𝑣𝑘 ) em um grafo 𝐺, onde 𝑣1 , ..., 𝑣𝑘
são vértices e (𝑙1 , 𝑙2 ), ..., (𝑙𝑘−1 , 𝑙𝑘 ) são arestas, então cada nó em 𝐶 possui um custo de
envio de mensagens. Seja 𝑇(𝑛𝑖) o peso que representa o custo de envio da mensagem
de 𝑣𝑖 , então, o (∑ 𝑇(𝑛𝑖)) para 𝑖 = 1, … , 𝑘 − 1, representa a qualidade do caminho
denotada por 𝑄𝐶 , onde:
𝑄𝐶 = ∑𝑘−1
𝑖=1 𝑇(𝑛𝑖)𝑣𝑖 (15)
A regra implementada no protocolo preconiza que quanto menor o peso de

𝑇(𝑛𝑖), melhor será a qualidade do caminho 𝑄𝐶 . Assim, o melhor caminho a ser
escolhido é aquele que dentre todos os caminhos disponíveis da origem ao destino
obtiver o menor valor correspondente ao 𝑄𝐶 .
2.4.1. Avaliação de Desempenho da Abordagem Proposta

Para avaliação do desempenho da abordagem proposta neste trabalho, utilizamos
o simulador COOJA [Osterlind, 2006], que faz parte do ambiente de simulação Contiki.
O Contiki ainda não possui funções objetivo que contemplem todas as métricas
especificadas na RFC 6551, se limitando apenas às métricas presentes na função
objetivo adotada pelo RPL em sua versão original.
Para tanto, as funções objetivo aqui propostas foram avaliadas e comparadas
com as funções OF0 e MRHOF, que são funções objetivo nativas do RPL. O modelo de
consumo de energia utilizado para avaliação de desempenho no quesito energia, foi o
módulo Energest do Contiki [Dunkels et al. 2007], que contabiliza a consumo de
energia em um dispositivo de IoT.
652
O modelo de dissipação Energest atribui consumos de energia em (J) a

atividades incluindo o processador (CPU) no modo ativo, o processador no modo de
baixa potência (LPM), a transmissão (TX) e recepção (RX) de pacotes. A energia para
cada atividade é calculada conforme expressão (16).
(𝐸𝑛𝑒𝑟𝑔𝑒𝑠𝑡𝑉𝑎𝑙𝑢𝑒 𝑥 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝑥 𝑉𝑜𝑙𝑡𝑎𝑔𝑒)

(16)
𝑅𝑇𝐼𝑀𝐸𝑅𝑆𝐸𝐶𝑂𝑁𝐷
Onde:
 𝐸𝑛𝑒𝑟𝑔𝑒𝑠𝑡𝑉𝑎𝑙𝑢𝑒 = Valor Energest registrado em cada atividade.
 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 = Consumo atual.
 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 = Voltagem requerida pelas baterias.
 𝑅𝑇𝐼𝑀𝐸𝑅𝑆𝐸𝐶𝑂𝑁𝐷 = Temporizador em segundos que é usado pelo módulo rtimer no
Contik (o temporizador em tempo real)
A. Cenário de Simulação e Métricas Utilizadas

O cenário de simulação foi construído para validar a abordagem proposta neste
trabalho. A topologia do cenário consiste em 11 nós sensores, 6 etiquetas (RFID), 2 nós
leitores (RFID) e 1 nó sink. Há 20 dispositivos em uma topologia de rede fixa, conforme
mostra a figura 2
Figura 2. Topologia do Cenário

Existe um fluxo de dados que consiste em ascendente e descendente. O nó sink
transmite mensagens DODAG Information Object (DIO) sempre que há mudança da
aplicação.
653
O uso das etiquetas RFID no cenário de simulação é justificado por demonstrar

uma visão realística de aplicações de IoT, uma vez que segundo [Welbourne et al.
2009], o excesso de mensagens trocadas entre leitores e etiquetas RFID, influenciam
fortemente no desempenho da rede bem como nos requisitos de QoS das aplicações. No
cenário estudado, o processo de comunicação entre os dispositivos RFID considera as
seguintes premissas:
•As etiquetas não iniciam a comunicação, somente respondem as requisições dos
leitores, informando o seu identificador;
•Os leitores enviam pacotes de difusão solicitando que todas as etiquetas que estejam
em seu alcance enviem pacotes contendo o seu identificador. Os pacotes recebidos pelos
leitores são encaminhados ao sink, que processa, de forma consolidada, as informações
enviadas pelos leitores e pelos nós sensores.
O tempo total de simulação foi de 35 minutos e repetimos a mesma cinco vezes
com intervalo de confiança de 95%, uma vez que a partir da quinta vez não foi
observada variação nos resultados. Entretanto, para a avaliação da mudança dinâmica
entre as funções objetivo, foi simulado o tempo de 140 minutos, em função de cada
aplicação perdurar o tempo de 35 minutos. As mensagens foram simuladas com pacotes
de 30 bytes (default do Contiki). A escolha do nó progenitor para o estabelecimento da
rota é feita utilizando a abordagem proposta neste trabalho. A energia inicial dos nós foi
ajustada para 200 joules sobre o modelo de consumo de energia Energest do Contiki
[Dunkls et al. 2007].
Cinco métricas empregadas pelo RPL (RFC 6551) e que são apropriadas para
ambientes 6LoWPAN, foram escolhidas a fim de avaliar a abordagem, tais como:
Energia Consumida (EC), Custo de Recebimento de Mensagens (CR), Número de Saltos
(NS), Taxa de Entrega (Tx) e Estimativa de Transmissão (ETX).
A Energia Consumida (EC) mede a energia consumida durante todo o
funcionamento, desde a fase de configuração até a morte da rede, que ocorre quando o
sink deixa de receber mensagens. O Custo de Recebimento de Mensagens (CR) é a razão
entre a quantidade de mensagens recebidas pelo sink e a energia residual total da rede. O
Número de Saltos (NS) corresponde ao número de saltos de uma origem ao seu destino.
A Taxa de Entrega (Tx) indica o número de pacotes entregues com sucesso ao destino.
A Estimativa de Transmissão (ETX) corresponde ao número médio de transmissões
necessárias (incluindo retransmissões) para que um pacote seja corretamente entregue
ao seu destino.
Para fins de validação da proposta, quatro aplicações foram consideradas neste
trabalho. A primeira aplicação exige prioridade em confiabilidade (representada pela
taxa de entrega). A segunda exige baixo delay (representado pelo número de saltos). A
terceira aplicação exige elevado tempo de vida (representado pela energia consumida) e
a quarta exige qualidade na entrega dos dados (representada pela estimativa de
transmissão).
654
B. Resultados Obtidos
Analisando os resultados apresentados nas figuras 3 e 4, observamos que
aplicações que exigem prioridade alta relacionada ao tempo de vida e ao delay,
utilizaram, para o processo de seleção de rotas, a função DQCA-OF4. Esta função
obteve, ao término da simulação, maior energia residual (na ordem de 170 joules)
quando comparada com as funções MRHOF e OF0 que obtiveram, respectivamente,
consumos de 100 joules e 80 joules. Isso ocorreu por esta função considerar as métricas
energia consumida e número de saltos, fazendo com que fossem selecionadas rotas que
possuem menor energia consumida e menor número de saltos.
Figure 3. Energia Consumida (Ec)

Ainda na figura 4, observamos que não houve variação nos resultados entre 0 e
525 segundos de simulação. Isso ocorreu em função da rede, nesse intervalo, está em
processo de estabilização, ocorrendo, assim, variação do delay somente a partir de 525
segundos de simulação.
Figure 4. Representação do Atraso (Delay)
655
Na figura 5, observamos o custo de recebimento de mensagens de todas as

funções objetivo avaliadas neste trabalho. Assim, foi identificado que todas as funções
propostas obtiveram menor custo quando comparadas com as funções OF0 e MRHOF.
Isso ocorreu em função da abordagem proposta utilizar funções objetivo específicas
para cada aplicação, o que não ocorre com as funções OF0 e MRHOF.
Observa-se ainda que a DQCA-OF3 obteve um custo de recebimento de
mensagens na ordem de 0,42, custo esse menor quando comparado com as demais
funções. Isso ocorreu em decorrência da função DQCA-OF3 ter contribuído para
selecionar rotas que possuem menor número de saltos, uma vez que recebeu prioridade
alta na métrica Número de Saltos (NS).
Além disso, a presença da métrica Energia Consumida (EC) nesta função, fez
que com o protocolo também levasse em consideração rotas com energia consumida
compatível com a aplicação desejada, possibilitando, assim, a obtenção reduzida do
custo de recebimento de mensagem.
Figure 5. Custo de Recebimento de Mensagens (CR)

Para aplicações que exigem confiabilidade na entrega dos dados, a figura 6
mostra que a função DQCA-OF1 obteve melhor desempenho com uma taxa de entrega
de 89% quando comparada com as funções MRHOF e OF0, que obtiveram,
respectivamente, taxa de entrega de 65% e 50,4%. Isso ocorreu em decorrência do
protocolo RPL ter utilizado, para a seleção de rotas, a função que prever as métricas
Estimativa de Transmissão (ETX) e Número de Saltos (NS), ambas, neste caso, com
prioridade alta.
Figure 6. Taxa de Entrega (Tx)
656
A figura 7 mostra que, para aplicações que exigem prioridade na qualidade da

entrega dos dados, a função DQCA-OF2 (Ec=Alta) obteve melhor desempenho no
número de transmissões/retransmissões com ETX=42 quando comparada com as funções
DQCA-OF2 (Ec=Baixa) que obteve ETX=88, MRHOF com ETX=140 e OF0 com
ETX=180. Essa diferença foi alcançada em função da aplicação ter exigido nível de
prioridade alta na métrica Energia Consumida (Ec).
Figure 7. Estimativa de Transmissão (ETX)
2.4.2. Simulação
No passado, Uzi Landman e seus colegas da Universidade da Georgia, Estados Unidos,
descobriram algumas das regras que explicam porque um metal não-reativo como o
ouro funciona como um catalisador quando ele se uni em agrupamentos de alguns
poucos átomos. Eles não se utilizaram de experimentos reais com porções do metal
precioso. Ao invés disso, eles simularam em computador e descobriram que o ouro é um
catalisador muito efetivo quando se encontra na forma de partículas que contenham
entre 8 e 24 átomos. Eles também descobriram que a absorção de cargas elétricas pelo
metal tem um papel crucial em seu funcionamento como catalisador [Zhang et al.,
2008].
Apenas seis anos mais tarde, a tecnologia disponibilizou o aparato técnico que
permitiu que a equipe realizasse testes de suas previsões experimentalmente. A
experiência mostrou que seus cálculos estavam corretos. Landman e seus colegas
utilizaram-se da metodologia científica para validar seu trabalho. Tal metodologia
orienta-se sobre os seguintes passos: observação, formulação de pergunta, formulação
de hipótese, experiência controlada e análise conclusiva dos dados.
Com base no trabalho de Landman e na realidade atual, percebe-se que a
simulação tornou-se uma ferramenta importante para a verificação de uma hipótese
formulada. Geralmente, o experimento valida uma hipótese. Entretanto, em cenários de
redes, uma hipótese pode ser validada utilizando-se de um ou mais dos seguintes
657
métodos: analítico, simulação e experimento controlado; como pode-se observar na

figura 8.
Figura 8. Etapas do método científico para cenários de rede.
Para a validação de uma hipótese, o método analítico se utiliza de modelos

matemáticos e equações, já o experimento, utiliza-se de uma situação real controlada.
Nas simulações, cria-se um modelo virtual próximo à realidade onde se pode, com o
auxílio de computador, testar e coletar resultados antes de conduzir algum experimento
real.
A simulação é utilizada para o desenvolvimento de aplicações bem como para a
validação de novas propostas., conforme mencionado por [Egea-Lopez et al. 2005].
Muitos trabalhos publicados contem resultados baseados apenas em simulações [Curren
2005]. Muitas vantagens são obtidas com o uso de simulações, tais como: menor custo,
praticidade em testar o comportamento da rede utilizando diferentes parâmetros,
possibilidade de realizar validação de código e avaliação de desempenho de redes em
larga escala. O crescente surgimento de dispositivos que integram a IoT, levou o
aumento do número de simuladores disponíveis, como por exemplo NS-2 [Downard
2004], OMNeT++ [Varga et al. 2001], Castalia [Boulis 2009], COOJA [Osterlind et al.
2006], TOSSIM [Levis et al. 2003], AVrora [Titzer et al. 2005], ATEMU [Polley et al.
2004] e OPNET [Chang 1999]. Alguns simuladores possuem funções específicas.
Outros, funções semelhantes e/ou complementares. Os simuladores existentes para IoT,
em função de suas limitações, podem não levar a podem não representar a realizada do
que se é verificado ou avaliado [Park et al. 2001]. Existem diversas limitações nos
simuladores, como modelos simplificados para simulações específicas, dificuldade para
fazer otimizações bem como encontrar a disponibilidade de protocolos relevantes já
existentes [Handziski et al. 2003].
Para validação do cenário de IoT avaliado neste capítulo, foi utilizado o
simulador Cooja. Esse simulador foi escolhido por possuir todas as características
pertinentes para se avaliar um cenário de IoT.
658
2.4.3. Simulação com Cooja

Abordaremos neste item, um simulador para validação de algoritmos de rede, o Cooja.
Diferentemente de outros simuladores, o Cooja é desenvolvido para aplicações de
Internet das Coisas do Contiki [Science 2005] presente no ambiente de desenvolvimento
Instant Contiki, que permite a emulação de diversos tipos de motes em nível de
hardware e/ou software. Cooja pode simular redes onde os nos sensores podem ser de
diferentes plataformas ao mesmo tempo.
A linguagem utilizada em seu arquivo de configuração é XML. Permite uma
prototipagem rápida de protocolos de rede, possibilitando a realização de simulações
com elevado número de nós em tempo aceitável, o que lhe confere um excelente
desempenho. Quanto ao tipo de simulação, pode-se realizar simulações síncronas, onde
todos os eventos têm seus inícios sincronizados com um clock, similar ao clock de um
processador de computador, por exemplo; ou assíncronas, onde os eventos dependem
uns dos outros para seus inícios e realizações.
Do ponto de vista da interação com o usuário, o Cooja oferece uma interface
gráfica que é muito útil para observar o funcionamento do algoritmo e interagir com o
mesmo em tempo de execução. Basicamente, para simular algo simples com o Cooja, é
necessário iniciar com a execução do Instant Contiki.
A) Executando o Instant Contiki
Primeiramente o Instant Contiki deverá ser descarregado. Trate-se de uma máquina
virtual Linux Ubuntu com um ambiente completo de desenvolvimento incluído o
sistema operacional Contiki, ferramentas e o simulador Cooja. O Instant Contiki está
disponível em http://sourceforge.net/projects/contiki/files/Instant%20Contiki/
Recomenda-se fazer o download da versão mais atual, que possui mais recursos
disponíveis e diversas correções a atualizações no sistema e protocolos de roteamento
presentes por padrão.
2.5. Conclusão
Neste capítulo, foi apresentada uma abordagem para Seleção Dinâmica de Rotas em IoT
baseada em Informações de contexto das aplicações. Os resultados mostraram que a
abordagem, considerando todas as funções objetivo propostas, é mais eficiente quando
comparado com a abordagem utilizada pelo protocolo RPL em sua versão original. Isso
foi possível porque as funções objetivo que foram propostas para adaptação do
roteamento no protocolo RPL, apresentaram resultados positivos com relação a
Estimativa de Transmissão (ETX), Número de Saltos (NS), Energia Consumida (EC),
Energia Residual (ER) e Custo de Recebimento de Mensagens (CR).
Também foram apresentados os principais conceitos de roteamento em IoT e o
detalhamento do protocolo RPL. As características de simulação incluindo um
simulador voltado para IoT foram abordadas para mostrar a forma de se validar uma
proposta semelhante a que foi apresentada neste trabalho.
A avaliação da proposta por meio de simulação, demonstrou que a utilização da
abordagem para Seleção Dinâmica de Rotas em IoT baseada em Informações de
contexto das aplicações apresenta resultados positivos em todas as métricas avaliadas.
659
Pretende-se, em trabalhos futuros, implementar essa abordagem em outros protocolos

aplicados a IoT considerando a escalabilidade dos dispositivos que compõem uma
estrutura de IoT.
Referência
Al-Fuqaha, A., Guizani, M., MOhammade, M., Aledhari, M., e Ayyash, M. (2015).
Internet of things: A survey on enabling Technologies, protocols, and applications.
IEEE Communications Surveys Tutorials, 17(4): 2347-2376.
Atzori, L., Iera, A. and Morabito, G. (2010). The internet of things: A survey, Computer
networks 54(15): 2787–2805.
Baldauf, M., Dustdar, S., Rosenberg, F. (2007) “A survey on context-aware systems”,
International Journal of Ad Hoc and Ubiquitous Computing, vol. 2, no. 4, pp.
263277.
Boulis, A. (2009). Castalia version 2.1 user’s manual.
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., Levis, P., Struik, R., Kelsey, R.,
Clausen, T. H., e Winter, T. (2012). RPL: IPv6 Routing Protocol for Low-Power and
Lossy Network. RFC 6550.
Brandt, A., J. Buron, and G. Porcu. Home Automation Routing Requirements in Low-
Power and Lossy Networks. Internet Engineering Task Force (IETF). 2010. RFC
5826.
Chang, X. (1999). Network simulations with opnet. In WSC ’99: Proceedings of the
31st Conference on Winter Simulation, pages 307–314, New York, NY, USA. ACM.
Chen, Y., Chanet, J., Hou, K., Shi, H., De Sousa, G.: A scalable Context-Aware
Objective Function (SCAOF) of Routing Protocol for Agricultural Low-Power and
Lossy Networks (RPAL). Sensors 19507–19540 (2015)
Curren, D. (2005). A survey of simulation in sensor networks. project report (CS580),
University of Binghamton.
Dohler, M., et al. Routing Requirements for Urban Low-Power and Lossy Networks.
Downard, I. (2004). Simulating sensor networks in ns-2.
Dunkels, A., Osterlind, F., Tsiftes, N., e He, Z. (2007). Software-based on-line energy
estimation for sensor nodes. In Proceedings of the 4th Workshop on Embedded
Networked Sensors, EmNets ’07, pages 28-32, New York, NY, USA. ACM.
Egea -Lopez, E., Vales-Alonso, J., Martinez-Sala, A., Pavon-Marino, P., and Garc´ıa-
Haro, J. (2005). Simulation tools for wireless sensor networks. In Proceedings of the
International Symposium on Performance Evaluation of Computer and
Telecommunication Systems (SPECTS’05).
Forbes (2014). Internet of Things By The Numbers: Market Estimates And Forecasts.
Gaddour, O.; KOUBÂA, A.; BACCOUR, N.; ABID, M. OF-FL: QoS-aware fuzzy
logic objective function for the RPL routing protocol. In: Modeling and Optimization
in Mobile, Ad Hoc, and Wireless Networks (WiOpt), 2014 12th International
Symposium on. IEEE, 2014, p. 365-372, 2014.
660
Handziski, V., Kopke, A., Karl, H., and Wolisz, A. (2003). A common wireless sensor
network architecture. Proc. 1. GI/ITG Fachgesprach Sensornetze(Technical Report
TKN-03-012 of the Telecommunications Networks Group, Technische Universitat
Berlin), Technische Universitat Berlin, Berlin, Germany, pages 10–17.
IETF. IETF Datatracker. [Online] Agosto de 2013.
https://datatracker.ietf.org/wg/roll/charter/.
Jayaraman, P. P.; Delirhaghighi, P. SA-A-WSN: Situation-aware adaptation approach
for energy conservation in wireless sensor network. In: Intelligent Sensors, Sensor
Networks and Information Processing, 2013 IEEE Eighth International Conference
on. IEEE, 2013, p. 7-12, 2013.
Levis, P., Lee, N., Welsh, M., and Culler, D. (2003). TOSSIM: Accurate and scalable
simulation of entire TinyOS applications. In Proceedings of the 1st International
Conference on Embedded Networked Sensor Systems, pages 126–137. ACM New
York, NY, USA.
Martocci, J., et al. Building Automation Routing Requirements in Low-Power and
Lossy Networks. Network Working Group. 2010. RFC 5867.
Makris, P., Skoutas, D. N., Skianis, C. (2013) “A Survey on Context-Aware Mobile and
Wireless Networking: On Networking and Computing Environments’ Integration”,
IEEE Communications Surveys and Tutorials, vol. 15, no. 1, pp. 362-386
Park, S., Savvides, A., and Srivastava, M. (2001). Simulating networks of wireless
sensors. In Proceedings of the 33nd Conference on Winter Simulation, pages 1330–
1338. IEEE Computer Society Washington, DC, USA
Kushalnagar, N., Montenegro, G., & Schumacher, C. 2007. RFC4919: IPv6 over low-
power wireless personal area networks 6LoWPANs: Overview, assumptions,
problem statement, and goals. Retrieved from http://tools.ietf.org/html/rfc4919
Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K.,
Struik, R., Vasseur, J., and Alexander, R. (2012). RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks. RFC 6550.
Martocci, J., et al. Building Automation Routing Requirements in Low-Power and
Lossy Networks. Network Working Group. 2010. RFC 5867.
Osterlind, F.; Dunkels, A.; Eriksson, J.; Finne, N.; Voigt, T. Cross-level sensor network
simulation with cooja. In: Local Computer Networks, Proceedings 2006 31st IEEE
Conference on. IEEE, 2006, p. 641-648, 2006.
Pister, K., et al. Industrial Routing Requirements in Low-Power and Lossy Networks.
Polley, J., Blazakis, D., McGee, J., Rusk, D., Baras, J., and Karir, M. (2004). Atemu: A
fine-grained sensor network simulator. In IEEE Communications Society Conference
on Sensor and Ad Hoc Communications and Networks. Citeseer.
661
Science, S. I. C. (2005). The Contiki Operating System.

Sharkawy, B.; Khattab, A.; Elsayed, K.M.F. Fault-tolerant RPL through context
awareness. In: Internet of Things (WF-IoT), 2014 IEEE World Forum on. IEEE,
2014. p. 437-441, 2014.
Sobral, J., Rabêlo, R., Oliveira, D., Lima, J., Araújo, H., e Holanda, R. (2015). A
framework for improving the performance of iot applications. In The 14 th
International Conference on Wireless Networks, 2015, pages 143-140, Las Vegas,
NV, USA.
Titzer, B. L., Lee, D. K., and Palsberg, J. (2005). Avrora: scalable sensor network
simulation with precise timing. In IPSN ’05: Proceedings of the 4th International
Symposium on Information Processing in Sensor Networks, page 67, Piscataway,
NJ, USA. IEEE Press.
Varga, A. et al. (2001). The OMNeT++ discrete event simulation system. In
Proceedings of the European Simulation Multiconference (ESM 2001), pages 319–
324.
Vasseur, J., et al. Routing metrics used for path calculation in low power and lossy
networks. Network Working Group . 2012. RFC 6551.
Welbourne, E., Battle, L., Cole, G., Gould, K., Rector, K., Raymer, S., Balazinska, M.,
e Borriello, G. (2009). Building the Internet of Things Using RFID: The RFID
Ecosystem Experience. Internet Computing, IEEE, 13(3):48 –55.
Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K.,
Struik, R., Vasseur, J., and Alexander, R. (2012). RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks. RFC 6550.
Zhang, C., Barnett, R., Landman, U. “Bonding, Conductance and Magnetization of
Oxygenated Au Nanowires” ed. Physical Review Letters, February 2008, Vol.: 100,
046801
662
Capítulo
3
Construção de Aplicações Baseadas em Física: uma
Introdução ao ODE
Danilo Borges da Silva1
Abstract
In the last years, with graphics processing power improvement, many graphics applica-
tions were mixed with physics to create virtual environments that are similar to the real
world. To empower the skills in building these applications, more quickly and intuitively,
physics engines were employed. This work aims to present the use of the Open Dynamics
Engine (ODE), a physics engine, to develop an interactive graphics application, similar
to a shooting game. For this, concepts of computer graphics and implementation will be
presented. The product of this work is an open source project that contains necessary
tools to develop applications that use physics with ODE.
Resumo
Atualmente muitas aplicações gráficas têm recorrido à física para criar ambientes virtu-
ais realistas, devido ao aumento no processamento gráfico nos últimos anos isso tem sido
potencializado. Para promover de forma mais rápida e intuitiva a construção dessas apli-
cações motores físicos são utilizados. Este trabalho tem como objetivo apresentar uma
introdução ao uso do motor físico Open Dynamics Engine para desenvolver uma aplica-
ção gráfica interativa, similar a um jogo de tiro ao alvo. Para isso, serão apresentados
conceitos de computação gráfica, para produzir os gráficos na tela, e como implementar
o uso desse motor físico. O produto deste trabalho é um projeto open source que contém
as ferramentas necessárias para o desenvolvimento de aplicações gráficas utilizando a
física para criação de um cenário com gravidade e tratamento de colisão.
3.1. Introdução
Atualmente muitas aplicações gráficas têm recorrido à física para criar ambientes virtuais
suficientemente realistas. Objetos que permanecem estáticas no ar ou que não colidem
1 [email protected]
663
entre si (se atravessam), dependendo da aplicação, podem ser consideradas ações não
fiéis, os famosos “glitches”. Observando isso, nota-se que, em qualquer aplicação gráfica
realista deseja-se o cumprimento de algumas leis físicas. Considere a título de exemplo o
movimento balístico de um projétil, como no jogo angry birds, baseado em física, onde
os pássaros são lançados como projéteis [Rodrigues e Carvalho 2013]. Nesse caso, para
simularmos seu movimento tem-se que levar em consideração a velocidade inicial do pro-
jétil e a ação da gravidade, além da colisão deste projétil com outros elementos presentes
no cenário. A simulação do movimento desse projétil (objeto) pode ser determinado de
várias formas, destacam-se duas: cinemática e dinâmica. Com essas duas formas pode-se
gerar o movimento do objeto por meio de interpolação – o método que permite construir
um novo conjunto de dados a partir de um conjunto discreto de dados pontuais previa-
mente conhecidos.
Nos movimentos baseados em cinemática desconsideram-se a massa e as forças
que agem no objeto, ou seja, podemos interpolar a posição do objeto simplesmente apli-
cando uma função que determina sua posição ao longo do tempo. Diferentemente, nos
movimentos baseados em dinâmica investiga-se as causas do movimento, as ações que
geraram o movimento, por isso leva-se em consideração a massa do objeto e as forças
de ação e reação (leis físicas). Quando trabalha-se com animação, ou simulação, de mo-
vimentos dinâmicos são vários os fatores que determinam a equação de movimento do
objeto, para determiná-la, na maioria dos casos, precisa-se recorrer a solucionadores nu-
méricos computacionais para calcular a velocidade e aceleração do objeto, pois estes ele-
mentos são necessários para apontar a posição do objeto no decorrer do tempo. Para sanar
o trabalho de determinar todas as equações de movimento dos objetos uma alternativa é a
utilização de motores físicos.
Os motores físicos são alternativas usadas por pesquisadores e desenvolvedores de
jogos, entre outros, para lidar com o movimento de objetos e de objetos articulados por
meio de juntas. Utilizando um motor físico como caixa-preta é possível determinar o mo-
vimento pretendido através de forças calculando internamente a aceleração, velocidade,
posição, orientação e forças de contato que lidam com a colisão dos objetos, facilitando
assim o trabalho ao construir aplicações dinâmicas.
O objetivo norteador deste trabalho é mostrar como configurar e utilizar um motor
físico vinculando-o a uma aplicação gráfica. Na Figura 3.1, pode-se observar uma imagem
do cenário da aplicação produzida neste trabalho. Diferente do lançamento do pássaro no
jogo angry birds onde o usuário pode alterar o ângulo de lançamento projétil (a esfera
amarela) rotacionando-se dois eixos. Isso se deve ao fato que a aplicação possui está em
um ambiente de três dimensões (3D). No decorrer do trabalho explico como foi o processo
de criação da aplicação que está disponível em um repositório público2 .
Este trabalho é produto de um minicurso arquitetado sob um ambiente de pro-
gramação com implementação de algoritmos, vendo-se isso tentei limitar os códigos a
algumas chamadas destacando-os em fonte diferenciada. Todo o corpo das funções e
dos códigos estão dentro do projeto hospedado nesse repositório público. Para melhor
entendimento deste material consulte também o projeto.
2 https://github.com/danilob/ShootPhysics
664
Figura 3.1. Sequência de imagens que exibe a ação do lançamento de uma esfera
sobre a torre de objetos cilíndricos (da esquerda para direita).
Nas seções a seguir falo sobre o panorama do uso de motores de física (Seção
3.2), exibindo sua principal contribuição destacando o motor de física Open Dynamics
Engine (ODE) que uso neste trabalho; na Seção 3.3, exibo o tipo de simulação física que
utilizaremos, pautada na mecânica de corpos rígidos; na Seção 3.4, discorro a respeito do
processo de criação de aplicações com física, sobre o viés de aplicações gráficas; a seguir,
na Seção 3.5, apresento o caso de estudo deste trabalho, a aplicação tiro ao alvo, com
alguns detalhes de implementação; e por fim, na conclusão (Seção 3.6) disponho algumas
das diversas aplicabilidades e trabalhos futuros possíveis com a utilização de ferramentas
que implementam a física, computacionalmente, por meio de motores.
3.2. Um Panorama do uso de motores de física

O motor de física, do inglês physics engine, é considerado uma caixa preta responsável por
simular as leis físicas de Newton baseados na clássica equação: F = ma, força é igual a
massa vezes a aceleração. Computacionalmente, o cálculo dessa equação envolve o uso de
métodos numéricos para determinar derivadas e integrais, além da resolução de equações
diferenciais [Baraff 2001]. Com o objetivo de mascarar a parte complexa, os cálculos
matemáticos pesados, de uma aplicação os motores físicos foram criados, deixando o
programador livre para desenvolver aplicações de alto nível sem ter a preocupação de
saber como internamente o motor físico trabalha, preocupando-se somente em adquirir o
resultado final. Ressalta-se que o uso de motores não é surgiu junto com a programação.
Em antigas aplicações gráficas o cálculo da física era realizado com aproximações
simplificadas para simular o comportamento dos objetos. Como as máquinas, por volta da
década de 90, tinham pouco poder de processamento usualmente os cálculos utilizavam
apenas ponto fixo para produzir um bom desempenho. Com a entrada de processadores
mais poderosos houve o aumento da complexidade física, os programadores passaram a
trabalhar em bibliotecas que cuidavam somente da simulação física para permitir o reuso
em outras aplicações, essas bibliotecas foram nomeadas motores físicos. Hoje existem
empresas especializadas em produzir esses motores como é o caso da Havoc3 , os seus
motores são utilizados principalmente em jogos, como a exemplo o jogo Assassin’s Creed
Syndicate.
Existem motores físicos que tratam diversos tipos de simulação: física, roupas,
comportamento, animação, criação de objetos e protótipos. Assim como existem motores
físicos proprietários temos os open-source como é o caso da Bullet, ODE, Bounce, entre
outros, para 3D e os motores Velocity Raptor, Box2D, ImpulseEngine, entre outros, para
3 https://www.havok.com/
665
2D; todos esses motores são escritos em linguagem C ou C++. Particularmente, neste
trabalho utilizo o ODE como motor físico, ferramenta criada por [Smith et al. 2005].
Entre as diversas aplicações que usam motores físicos pode-se observar que ela
está presente principalmente no desenvolvimento de jogos, além disso eles são necessá-
rios para produção de animações e desenvolvimento de protótipos. No desenvolvimento
de protótipos seu uso se faz crucial para a construção de um projeto. Criar um protótipo
sem antes ter a certeza se o mesmo é estável acarretaria em prejuízos consideráveis para
empresa que o desenvolve. Como exemplo, a Nasa antes de lançar qualquer robô/veículo
para o espaço cria um protótipo computacionalmente (na máquina) e executa diversos
testes simulando fisicamente seu comportamento, somente após esgotar uma quantidade
considerável de testes é que o protótipo passa a ser construído realmente. Com o surgi-
mento de motores físicos robustos começamos a presenciar também animações (filmes)
com bons gráficos quase que compatível com a realidade, além de efeitos visuais mais
fidedignos. Existe muita pesquisa associada a animação de personagens baseados em fí-
sica, instigados pela construção de controladores com baixo poder de processamento e
que permitam aplicações realistas como por exemplos os trabalhos realizados por [Coros
et al. 2010, Geijtenbeek et al. 2012, da Silva et al. 2017].
Vimos que um mundo de possibilidades se torna viável com a física, porém encontra-
se escasso o material disponível para aprender a utilizar motores físicos, principalmente
em português. Nas pesquisas que realizei não encontrei nenhum material físico, ou
mesmo digital (livros, ebooks), em português que mostre como utilizar um motor físico.
Os materiais que estão disponíveis para este fim encontram-se na forma de tutoriais espa-
lhados pela rede (internet) onde muitos estão em inglês [Baraff 2001, Millington 2007],
o que inviabiliza o acesso a esta informação para muitos. Talvez se os pesquisadores, e
estudantes, estivessem mais a par da escalabilidade de aplicações em se utilizar motores
físicos existiria um aumento na procura e possivelmente de material disponível para novos
entusiastas. Em paralelo ao objetivo norteador deste material quero semear conhecimento,
mostrando que a computação não está limitada ao uso ou construção de sistemas, o que
fortemente se prega nas acadêmias em nível de graduação. Existem múltiplas possibili-
dades de desenvolvimento basta conhecer as ferramentas certas para isto, ou criá-las.
Na próxima seção falo mais a respeito do tipo de simulação física que trataremos
neste trabalho.
3.3. Mecânica de Corpos Rígidos

Antes de adentrarmos na mecânica de corpos rígidos é importante compreender como
utilizar os motores físicos e como eles são utilizados para representar um objeto dentro
do ambiente virtual. Existem dois tipos de representação para um objeto, a representa-
ção gráfica e a representação física, que não estão associados diretamente desde que se
realize esta associação. No objeto físico a configuração de algumas propriedades se faz
necessária, como a massa, a forma de colisão (ex. cubo com cilindro, cubo com plano),
a geometria, etc. Configurado esses parâmetros esse objeto é criado no ambiente físico,
também chamado de mundo (world), e o motor passa a simular sua interatividade entre
os objetos nesse ambiente. Até então não há informação visual deste processo intera-
tivo, para isso se faz necessário vincular o objeto físico com o objeto gráfico, atualizando
666
a posição e orientação do objeto gráfico a partir de sua representação física. Em posse

da posição e da orientação do objeto físico pode-se desenhar o objeto no ambiente vir-
tual. Note que, nem sempre se desejada associar um objeto gráfico a um objeto físico, e
vice-versa, neste trabalho mostro em que momentos pode-se realizar esta escolha.
Um outro nome dado ao objeto físico é rigid body, tradução, corpo rígido, este
tipo de objeto vem da parte da mecânica que estuda o movimento dos corpos sólidos, que
nunca sofrem deformações. Isso significa que não importa que ações (forças e contato)
que esse corpo sofra sua forma (geometria) não é alterada. Outras propriedades de um
corpo rígido são: posição, orientação, matriz de inércia, dimensões, etc. É possível tam-
bém criar o objeto com uma velocidade inicial. Em tempo de execução pode-se aplicar
forças ao corpo rígido com o objetivo de realizar algum tipo de movimento. Não está no
escopo deste trabalho a utilização de juntas, mas é possível com os motores físicos a con-
figuração de diferentes tipos juntas conectando corpos rígidos. Para realizar o movimento
de estruturas articuladas se faz necessário o uso de controladores físicos – controladores
baseados em física que utilizam forças e/ou torques para produzir movimentos.
Neste trabalho, utilizo somente corpos rígidos e o contato entre os mesmos para
mostrar como utilizar o motor físico ODE na construção de uma aplicação gráfica fisica-
mente realista. Algumas etapas deste processo de construção serão exploradas a seguir.
3.4. Processo de criação de aplicações com física

Em qualquer projeto que venha a utilizar elementos físicos algumas premissas devem ser
alcançadas para o uso de motores físicos. As premissas que cito a seguir visam transmitir
para o usuário da aplicação uma realidade física na interação entre os objetos dentro do
ambiente virtual e físico, são elas: (1) configurar o motor (simulador) físico, (2) determi-
nar corretamente o modelo de fricção e as políticas de detecção de colisão, e (3) ligar o
objeto gráfico ao objeto físico. Essas três premissas trabalham em conjunto para obtenção
de uma aplicação onde os objetos virtuais interagem entre si em um ambiente fisicamente
dinâmico. Dividi as próximas subseções em três partes, na primeira descrevo como confi-
gurar o cenário e a criação dos objetos gráficos utilizando OpenGL, na segunda subseção
falo a respeito da configuração do simulador físico e da ligação entre o objeto rígido (fí-
sico) e o objeto gráfico, e na última subseção verifica-se o processo de fricção e forma de
colisão entre os objetos rígidos.
3.4.1. Configurações do cenário e criação de objetos

Imagine como se dá o processo de construção de um jogo, ou mesmo de um filme, na
idealização de um cenário. De forma similar, deve-se pensar em como devemos configurar
o ambiente da aplicação. É preciso analisar a forma de visualização do cenário, se será
dimensional (2D) ou tridimensional (3D) e como o usuário irá observar esse cenário, ou
seja, a determinação da câmera (1); e finalmente como os objetos estarão dispostos, suas
posições e orientações (2). Os objetos ao que me refiro são todos os elementos presentes,
e visuais, no ambiente, desde o solo, até as fontes de iluminação. A seguir mostro como
implementar cada configuração, (1) e (2), utilizando OpenGL.
667
3.4.1.1. Visualização e Projeção
A projeção está relacionada com a forma pela qual os objetos virtuais serão projetados
na tela de visualização, essa projeção será realizada por intermédio de uma matriz que
determina como cada pixel será projetado na tela. Pode-se definir a matriz de projeção
por meio da seguinte função OpenGL: glMatrixMode(GL_PROJECTION) (a). O
objetivo da função glMatrixMode() é informar que a matriz GL_PROJECTION está
aberta para alteração. Após abrir o modo de projeção (a), defini-se a matriz de projeção
tridimensional por meio da função gluPerspective (angle, aspect, near,
far) onde os parâmetros são podem ser verificados na Figura 3.2. Dentro do projeto
(repositório público) implementei a visualização ortogonal (2D) da aplicação, para exibir
uma visualização da cena similar ao jogo angry birds (Figura 3.3d). Para criar a matriz de
visualização ortogonal utilizei a função glOrtho(). Ambas as implementações estão
na classe Scene.
Para visualizar o cenário é preciso definir uma câmera. A configuração da câmera
é definida por meio de três vetores tridimensionais: up, at e eye. Esses vetores definem
o sistema de coordenadas da câmera, onde o vetor at aponta a posição para onde a câmera
deve olhar, o vetor eye defini a posição da câmera e o vetor up defini seu eixo.
A câmera em conjunto com a matriz de projeção são utilizadas para que o usuário
da aplicação possa observar o cenário como um todo. No OpenGL a câmera é definida
partir da seguinte função: gluLookAt (eye, at, up), onde cada um dos parâme-
tros representa um vetor composto por três valores reais.
aspect = w/h
Câmera angle w h
near
far
Figura 3.2. Definição visual dos parâmetros da função gluPerspective. Em

angle tem-se um valor do ângulo, em graus, da visualização da câmera; em
aspect tem-se a relação entre a largura (w) e altura (h) do plano de visualização,
em near tem-se o primeiro plano de corte, e em far o segundo plano de corte,
ou seja, tudo que não estiver entre near e far será desconsiderado na visuali-
zação do cenário. Usualmente defini-se um valor pequeno para near e um valor
suficientemente grande para far.
668
3.4.1.2. Modelagem dos Objetos
Podemos realizar a criação dos objetos do cenário com algumas primitivas simples, como
pontos, linhas e polígonos. A criação de um objeto feito com OpenGL consiste da com-
binação de simples primitivas gráficas [Wright et al. 2010]. O OpenGL fornece mecanis-
mos para desenhar pontos, linhas e polígonos, que são formados por um ou mais vértices.
Neste caso, é necessário passar uma lista de vértices, que pode ser feito entre duas cha-
madas de funções OpenGL: o glBegin() e o glEnd(). O glBegin() recebe um
parâmetro que identifica como será agrupada a lista de vértices que serão inseridos en-
tre essas as camadas, como exemplo têm-se os parâmetros: GL_POINTS, GL_LINES,
GL_QUADS.
Para criação de um paralelepípedo tridimensional, a exemplo, utiliza-se o parâ-
metro GL_QUADS. E dentro das camadas serão inseridos os vértices (glVertex3f())
para construção desse polígono, tomados de quatro em quatro vão formando cada face
do paralelepípedo. Optou-se por não utilizar as funções de definição das normais das
faces dos objetos. As normais são elementos essenciais para o cálculo de iluminação
dos objetos na determinação de sombreamento, porém neste trabalho utilizamos colora-
ção chapada utilizando a função glColor3f() para definir a cor dos objetos. A função
glColor3f() recebe três parâmetros, cada um de 0 a 1, que representam a contribuição
vermelha, verde e azul (RGB).
Pode-se também desenhar um objeto por meio do pacote GLU utilizando superfí-
cies quadráticas (quadrics). Por exemplo, podemos desenhar uma esfera utilizando a
seguinte função: gluSphere(*quadric, radius, slices, stacks). Onde
quadric é um parâmetro do tipo GLUquadric, radius é o raio da esfera, e slices
e stacks são a quantidade de linhas verticais e linhas horizontais respectivamente – se-
melhante aos meridianos e paralelos do planeta.
As funções de desenho definidas anteriormente mostram a construção de um ob-
jeto qualquer em sua origem. Essa origem é chamada de sistema de coordenadas local
do objeto. A partir deste sistema podemos colocar o objeto em coordenadas do mundo
ao aplicar operações com matrizes de transformação. Entre diversas matrizes as mais uti-
lizadas são: a matriz de translação (T), a matriz de rotação (R) e a matriz de escala (S).
Ambas na forma de matriz homogênea, com dimensão 4×4.
Para simplificar os cálculos com as matrizes o OpenGL oferece funções para rea-
lizar esses cálculos. A função glTranslatef() aplica uma matriz de translação aos
vértices, ou ao quadric, onde os parâmetros são as coordenadas de translação; a função
glRotatef() é responsável por aplicar uma matriz de rotação, tendo como parâmetros
um ângulo e um eixo (vetor 3D); e a matriz de escala glScalef() responsável por
criar a matriz de escala, também com três parâmetros. Na determinação dessas funções
o OpenGL executa internamente as operações de multiplicação com as matrizes, a ordem
em que elas aparecem influenciam no resultado final. Por isso, é conveniente utilizar a
seguinte ordem para o aparecimento dessas matrizes no código: T, R e finalmente S.
Praticamente todas as funções de desenho utilizadas na aplicação estão no names-
pace Draw, dentro da pasta graphics.
669
Entendidos os conceitos necessários para o desenho de um objeto nas próximas

seções explico como o simulador físico pode ser usado na aplicação.
3.4.2. Configuração do simulador físico

Com a minha experiência como pesquisador em simulação de personagens baseados em
física tenho a sensação que o ODE é um ótimo motor de física, e isso se reflete em
muitos trabalhos da literatura que o utilizam [Coros et al. 2010, Geijtenbeek et al. 2012].
Na aplicação criada neste trabalho, em particular, não quis tratar de personagens, o que
poderia acarretar em eu ter que esboçar mais informações a respeito das construção das
juntas e de controladores físicos para guiar o movimento do personagem. Como trata-
se de uma visão introdutória limitei-me a mostrar as configurações básicas do ODE, que
servem para uma aplicação mais robusta, e a conexão entre os objetos gráficos e os objetos
físicos.
O primeiro comando para se inicializar o simulador físico é a chamada da função
dInitODE(). Após a chamada dessa função é necessário criar o mundo, informar a
força da gravidade, que considerei como sendo de −9.8m/s2 , configurar dois parâmetros
ERP e CFM. ERP é um parâmetro que corrige o erro das juntas criadas. Essa função
diminui o erro de contato das juntas pois à medida que a simulação é repetida, o centro
da junta muda devido a erros de cálculo e assim por diante. Apesar de não termos juntas
entre os objetos são criadas juntas para determinar uma colisão, por isso esse parâmetro
é necessário. Já o parâmetro CFM, dito de forma sintética, torna a interação entre os
contatos mais rígida ou suave. Adotei os valores: ERP = 0, 2 e CFM = e−9 [Demura
2017]. Além disso é necessário criar o plano do solo. Com esses parâmetros o simulador
físico já está apto para o funcionamento, basta agora criar a função de atualização da
simulação.
A função de atualização, ou simplesmente passos de simulação, são as chamadas
às funções que executam todos os cálculos necessários para correção dos parâmetros físi-
cos dos objetos simulados. Nessa função faço a chamada ao método de colisão, e informo
o passo de simulação do motor físico, utilizei como passo de simulação o valor constante
de 0,0005. Ao final da função todas as juntas criadas na função de detecção de colisão
são destruídas (mais detalhes na próxima subseção). Quanto menor o passo de simulação
mais comportada a simulação física será. Para melhorar os cálculos chamo essa função
67 vezes antes do desenho de um quadro (imagem). Esses valores não são escolhidos ao
acaso. Espera-se que uma simulação física não extrapole a taxa de quadros de 30 frames
por segundo, ao multiplicar o passo da simulação (0,0005) com a quantidade de vezes que
a chamamos por frame (67) com 30 frames obtém-se o valor próximo a 1s (segundo) que
é justamente a taxa esperada. Informada a parte da configuração faz-se necessário agora
vincular o objeto gráfico ao objeto físico.
Para vincular um objeto gráfico (OG) ao objeto físico (OF) basta que seja infor-
mado ao OG os parâmetros utilizados no OF para podermos recuperar os dados que o
simulador físico pode proporcionar. Os principais parâmetros são: BodyID, o identifi-
cador do OF; GeomID, a geometria do OF, a forma do objeto (ex. esfera, cilindro); e a
massa do objeto (Mass). Informada a posição inicial do OF e sua orientação inicial (em
quatérnions) pode-se criar o OF e vinculá-lo ao OG com a função createObject()
670
presente no namespace Physics.
3.4.3. Modelo de fricção e colisão

Entre os modelos de fricção que o ODE implementa eu utilizei o modelo de fricção de
Coulomb no desenvolvimento da aplicação. Entende-se como fricção a concepção do
contato de atrito que se desenvolve na superfície de contato entre dois corpos. A força
de atrito (Fa ) entre dois corpos é proporcional à força normal atuante sobre ela (N), e é
independente da área desta superfície. A força de atrito é definida como:
Fa = µN (1)
No mundo real considera-se para o cálculo da força de atrito, Fa , toda a superfície

de contato. Entretanto, torna-se inviável computacionalmente utilizar todos os pontos
de contato entre as superfícies para o cálculo do atrito. Para isso, utilizei no ODE no
máximo quatro pontos de contato para o cálculo do atrito. Para informar ao ODE que
vamos utilizar o modelo de fricção de Coloumb é necessário configurar o modo de contato
da superfície como sendo dContactApprox1. Utilizei para o valor µ = 0, 8, este
parâmetro é chamado de coeficiente de atrito estático. Após o corpo entrar em movimento
surge um novo coeficiente de atrito, chamado de atrito dinâmico, que é menor que µ.
Para simular a colisão entre os objetos o ODE utiliza juntas de contato. Em cada
um contatos encontrados são criadas juntas que impedem a penetração entre as geome-
trias, ao final de um passo da simulação essas juntas são destruídas. Este ciclo de criação e
destruição das juntas se repete a cada passo de simulação. A função de cálculo da colisão
pode ser encontrada na função nearCallback() presente no namespace Physics.
Ressalta-se que o motor físico vai determinar se houve ou não algum contato de acordo
com os modelos de detecção de colisão entre as geometrias, esses modelos são determi-
nados na instalação da biblioteca ODE. Por exemplo, se por acaso não for configurado
um modelo de detecção padrão para colisão de cilindro com cilindro, este tipo de colisão
não acontecerá na aplicação. Parece contraditório o ODE não trazer essa configuração
nativamente na instalação, porém o ODE busca otimizar os cálculos, se o usuário não
irá utilizar algo ele simplesmente desconsidera. Por isso, é importante configurar o ODE
convenientemente para o tipo de aplicação que o usuário deseja. Neste trabalho, mostro
no arquivo README.md, presente no repositório, uma configuração que habilita todos os
tratamentos de colisão possíveis do ODE.
3.5. Estudo de caso: Tiro ao alvo

Para mostrar como configurar o ODE em uma aplicação gráfica escolhi uma aplicação
relativamente simples, uma espécie de tiro ao alvo. Nessa aplicação o usuário lança um
objeto (esfera), que parte de um cilindro, com o objetivo de acertar objetos cilíndricos
que estão dispostos sobre uma bancada. Para isso o usuário pode aumentar ou diminuir a
velocidade da esfera, e ajustar seu ângulo de lançamento. Na Figura 3.3, pode-se observar
a tela da aplicação. A criação e configuração de alguns dos elementos programados estão
dispostos a seguir. A aplicação foi construída utilizando QtCreator, com linguagem C++,
OpenGL e o simulador físico ODE.
671
(d)
(c)
(b)
(a)
Figura 3.3. Ambiente da aplicação. (a) trajetória da esfera, (b) o projétil lançado
(a esfera), (c) objetos cilíndricos dispostos sobre uma bancada e em (d) uma
visão ortogonal da cena com o marcador da velocidade inicial da esfera (no canto
inferior esquerdo).
3.5.1. Criação do Projeto Qt

Nesta seção descrevo como realizei a criação do projeto com a inserção dos gráficos, da
interatividade e da física. No projeto utilizei a plataforma de desenvolvimento QtCreator
3.0.1 com base no Qt 5.2.1, e as bibliotecas glut, glu, e ode. As primeiras duas bibliotecas
encontram-se no pacote OpenGL.
Na criação do projeto, escolhi o projeto default do Qt: “Application/Qt Widgets
Application”, após a criação do projeto default foram realizadas algumas configurações.
Como trata-se de um projeto com gráficos feitos com OpenGL tem-se a necessidade de
definir essa informação no descritor do projeto, o arquivo com extensão .pro. Dentro desse
arquivo na linha que se inicia com QT deve ser adicionado no final da linha a seguinte
palavra: “opengl”.
Na criação da janela de visualização, gerei a classe GLWidget que herda proprie-
dades da classe QGLWidget (herança). Algumas funções da classe QGLWidget devem
ser sobrecarregadas como: (1) initializeGL(), (2) resizeGL(int w,int h)
e (3) paintGL(). Essas três funções são responsáveis respectivamente por: (1) inicia-
lizar o ambiente OpenGL, configurando algumas propriedades, como a cor do ambiente;
(2) redimensionar a janela, definindo as matrizes de projeção e de visualização; e (3)
desenhar os objetos na janela, mostrando o comportamento dos objetos virtuais.
Partindo para a janela da aplicação feita com o Qt, arquivo com extensão .ui,
adicionei um objeto Widget e o expandi para ocupar toda a janela. Esse objeto tem
a função de mostrar tudo o que for desenhado em (3), para isso é preciso vincular esse
objeto a classe que implementa a função paintGL(). Para vincular esse objeto à classe
GLWidget é necessário selecionar a opção promover e especificar a classe base como
sendo a QWidget, e informar: o nome da classe a ser promovida, neste caso a classe
GLWidget; e a localização do arquivo header, .h, da classe GLWidget. Feitas essas
672
configurações todo o desenho realizado na classe GLWidget será exibido na janela da

aplicação Qt.
Na próxima subseção falo mais a respeito da comunicação entre os objetos gráfi-
cos e os objetos físicos, e a interatividade com o desenho na Widget.
3.5.2. Comunicação entre as Classes

Na Figura 3.4 pode-se observar as principais classes utilizadas no projeto. Além das clas-
ses descritas anteriormente teremos mais três elementos: Physics, Object e Scene.
Cada classe executa um papel importante para a concepção do resultado final do projeto.
Abaixo descrevo sucintamente a função de cada classe:
• O namespace Physics representa uma interface de comunicação para utilização

das funções obtidas com o ODE. Assim, as funções do ODE são utilizadas indire-
tamente.
• A classe Object define toda a estrutura do objeto com suas propriedades gráficas
e físicas. Nessa classe tem-se uma comunicação próxima com a Physics.
• A classe Scene organiza a simulação física, definindo suas propriedades básicas

(ex. ativação e criação dos objetos físicos e gráficos, passos de simulação) e é
responsável por invocar as atualizações de posição dos objetos e realizar as ações
no cenário (ex. lançamento dos projéteis).
Physics
Object
updateObject()
setScene()
GLWidget
Scene Janela QT
setObject()
Widget
paintGL()
setProperties()
Figura 3.4. Comunicação entre os processos: classes e funções. Os retângulos

com linhas pontilhadas representam as classes. As setas definem as principais
ações realizadas em por cada classe, a ponta da seta informa a classe alvo de
uma determinada ação.
Também foi utilizado neste projeto classes que cuidam de alguns cálculos mate-
máticos, como a classe Vec4 e a classe QuaternionQ presentes na pasta math. A
classe Vec4 representa um vetor com quatro parâmetros, que é utilizado para gravar a
673
posição dos objetos. A classe QuaternionQ representa um quatérnion, com quatro pa-
râmetros, utilizado para rotacionar os objetos. O ODE utiliza na maioria das funções a
rotação de objetos com quatérnions, por isso criei essa classe. É possível dentro dessa
classe converter outras formas de rotação (ângulos de Euler e eixo ângulo) para quatér-
nion, e vice-versa. A forma de representação por ângulos de Euler possui uma melhor
representação visual para determinar uma rotação, já a representação eixo ângulo é utili-
zada para aplicação da rotação através do OpenGL na função glRotatef().
Implementei o namespace Draw que cuida da parte de desenhar os gráficos pre-
sentes na aplicação. Entre esses gráficos estão os objetos (caixa, esfera e cilindro), a
trajetória da bala, o texto, o solo, e a sombra dos objetos projetados no solo (não realizei
a implementação de sombra sobre os objetos). Essa classe concentra os desenhos, que
são passadas principalmente pela classe Scene. E na classe Scene são configuradas as
matrizes de projeção e a câmera de visualização.
Pela classe GLWidget é possível rotacionar a câmera utilizando o mouse, pro-
porcionando ao usuário visualizar o cenário por outros ângulos. Para isso, são utilizados
os eventos do mouse e a classe Camera que realiza as operações de translação, rotação
e zoom da câmera de visualização. Essa classe é instanciada dentro da classe Scene e
manipulada pela classe GLWidget. Dentro da função de desenho da Scene (draw())
exibo a posição da câmera fazendo uma chamada ao método gluLookAt(eye, at,
up) presente no OpenGL enviando os parâmetros presentes na Camera.
Na Figura 3.4, pode-se observar que a classe Scene configurando na Physics
alguns parâmetros e é também responsável por fazer as chamadas de atualização do mo-
tor físico. Isso é possível por meio de dois parâmetros que a classe copia do motor:
o WorldID e o SpaceID. Esses parâmetros são copiados na inicialização do motor
físico, com a função initScene() presente na Physics. A criação do objeto tam-
bém é realizado pela classe Scene, e armazenado em uma lista de objetos, para ma-
nipulação e desenho. O objeto pode ser criado com propriedades físicas ou não, isso
é especificado por meio de um parâmetro booleano presente na função de criação do
objeto (createObject()). Caso o objeto possua propriedades físicas é obrigató-
rio especificar sua massa para que possa ser criado o objeto físico, os parâmetros o
WorldID e o SpaceID são copiados a partir da classe Scene. Note que tudo está
encadeado a esses dois parâmetros. Pela classe Object é possível adquirir a posição
e a orientação do objeto físico por meio das funções getPositionCurrent() e
getOrientationCurrent(), respectivamente, fazendo uma chamada a Physics
passando como parâmetro o BodyID, parâmetro esse que é capturado pela classe Object
na criação de um objeto com propriedades físicas.
Entendido como criar um objeto, é preciso que os quadros da janela sejam atuali-
zados com uma certa frequência, caso contrário veríamos a mesma imagem com o passar
do tempo. Para realizar a atualização da janela é necessário configurar um QTimer e
associar a função timeout() implementada na classe QTimer a uma função dentro
da classe GLWidget (simStep()) por meio de um connect. A função simStep()
fará a chamada a função que realiza a atualização dos parâmetros físicos dentro da Scene,
o simulationStep(), e chamará a função de desenho paintGL() dentro da classe
GLWidget. Como todo desenho será feito pela classe Scene dentro da função paintGL()
674
faz-se uma chamada a função de desenho draw() presente nessa classe.

Agora vamos entender como ocorrem as ações nos objetos inseridos na aplicação.
Temos as seguintes ações possíveis: (1) manipular o ângulo de lançamento da esfera, (2)
lançar uma esfera, e (3) mudar a velocidade da esfera. Todas as ações são manipuladas
via teclado. Em (1) utiliza-se as setas para cima e para baixo para rotacionar o eixo x
do cilindro, fazendo com que o cilindro aponte mais para cima ou para baixo; as setas
para direita ou para esquerda rotacionam o eixo y do cilindro, fazendo com que o cilindro
aponte mais para direita ou para esquerda. Ao pressionar a tecla o ângulo é incrementado,
ou decrementado, em uma unidade no eixo escolhido. Em (2) utiliza-se a barra de espaço
para lançar a esfera de acordo com a orientação do cilindro e a velocidade inicial da
esfera que pode ser modificada pela ação (3). Finalmente em (3) utilizando as teclas A ou
D pode-se, respectivamente, aumentar ou diminuir a velocidade da esfera.
Verifica-se que a ação mais importante da aplicação é a configuração da velocidade
de lançamento que deve ser configurada assumindo o espaço tridimensional. A velocidade
é configurada como sendo um vetor, decompondo a velocidade em dois pares de eixos.
Isso é realizado fazendo uma rotação do eixo inicial (0,0,1) (sentido para o qual o cilindro
aponta inicialmente), com o quatérnion que representa a rotação do cilindro. Para isso
é utilizada a função getVecRotation() que retorna o vetor de lançamento que é
multiplicado pela velocidade inicial, o resultado dessa multiplicação é então utilizado
para criação da esfera com velocidade inicial. Observe que o cilindro vermelho, não
possui elementos físicos, sendo um objeto puramente gráfico.
Nessa aplicação também mostro como utilizar um objeto físico sem exibi-lo na
janela. Isso é feito na projeção do lançamento da esfera, a linha pontilhada (Figura 3.5).
Essa projeção é feita lançando um objeto físico e extraindo sua posição a cada passo de si-
mulação, armazenando esta informação em um vetor, o critério de parada é uma distância
(a partir ponto de lançamento) ou quantidade de passos de simulação. Ao atingir o critério
de parada esse objeto é destruído. Depois de destruído utilizo as posições armazenadas no
vetor para desenhar uma parte da trajetória da esfera. Essa projeção é calculada sempre
que houver uma atualização da orientação do cilindro ou atualização na velocidade inicial
da esfera, como pode-se observar na Figura 3.5.
(a) (b)
Figura 3.5. Mudança na trajetória da esfera alterando a velocidade inicial. (a) 10

m/s e em (b) 60 m/s.
675
Como dito anteriormente, o objetivo dessa aplicação foi mostrar como construir
uma aplicação que utiliza um motor físico, para isso utilizei o ODE. O projeto criado
visa a possibilidade de expansão, talvez até mesmo criar um jogo, permitindo aos que
quiserem expandir esse código adicionando mais recursos e interatividade, objetivando
o aprendizado. Fiz o possível para comentar, em português, algumas rotinas/funções
utilizadas. A ideia é disseminar o conhecimento favorecendo o crescimento de aplicações
e estudos em computação com simulação física.
3.6. Conclusão
Neste trabalho foi apresentado a importância e aplicações dos motores físicos. Como pro-
duto mostrei a implementação de uma aplicação simples que utiliza o motor físico ODE.
Todos os códigos implementados estão disponibilizados no repositório público com com-
partilhamento livre (open source). Pode-se observar que é relativamente simples a vincu-
lação de um objeto gráfico a um objeto físico, em resumo essa vinculação se dá por meio
de atributos que são compartilhados entre os dois objetos permitindo assim a recuperação
dos dados de posição e orientação do objeto físico. Cabe agora fazer uso deste projeto
básico para expandir o conhecimento, produzindo outras aplicações e funcionalidades.
Neste projeto o namespace Physics funciona como uma interface de comuni-
cação entre o objeto físico e o objeto gráfico, caso o programador queira utilizar outra
biblioteca gráfica cabe reconfigurar o código dessa interface e as propriedades dos atribu-
tos compartilhados no objeto gráfico. Isso permite a refatoração simples da aplicação para
inserção de outros motores físicos sem a necessidade de reimplementar muitas rotinas.
Na interface da aplicação, produzida pelo Qt, limitei-me a utilizar a captura de
ações via teclado e mouse para manipulação do cenário. Pode-se também via interface do
Qt adicionar botões, menus e outros elementos para inserção e manipulação de objetos e
propriedades, basta criar conexões entre a ação de um desses elementos e uma função na
classe Scene, similar ao que é feito para atualizar a janela de visualização.
É enorme o campo da pesquisa em física para aplicações computacionais, vê-se
o seu uso principalmente no desenvolvimento de jogos e animação. Esta área de pes-
quisa procura incessantemente por meio da física produzir efeitos que se aproximem da
realidade em um curto espaço de tempo, o que ainda é um desafio. Os trabalhos futuros
visam ultrapassar esse desafio, isso é o que motiva a pesquisa em animação de perso-
nagens baseados em física. Existem atualmente vários eventos e periódicos que rece-
bem trabalhos nessa área, como é o caso do SCA (Symposium on Computer Animation),
EUROGRAPHICS, SIGGRAPH, e CGF (Computer Graphics Forum), entre outros. Em
virtude do que foi mencionado, verifica-se que existem enormes possibilidades de desen-
volvimento em pesquisa que podem ser exploradas.
Referências
1 RODRIGUES, M.; CARVALHO, P. S. Teaching physics with angry birds: exploring
the kinematics and dynamics of the game. Physics Education, IOP Publishing, v. 48, n. 4,
p. 431, 2013.
2 BARAFF, D. Physically based modeling: Rigid body simulation. SIGGRAPH Course
676
Notes, ACM SIGGRAPH, v. 2, n. 1, p. 2–1, 2001.
3 SMITH, R. et al. Open dynamics engine. 2005.
4 COROS, S.; BEAUDOIN, P.; PANNE, M. van de. Generalized biped walking control.
In: ACM SIGGRAPH 2010 papers. New York, NY, USA: ACM, 2010. (SIGGRAPH
’10), p. 130:1–130:9. ISBN 978-1-4503-0210-4.
5 GEIJTENBEEK, T.; PRONOST, N.; STAPPEN, A. F. van der. Simple data-driven

control for simulated bipeds. In: ACM SIGGRAPH/Eurographics Symposium on
Computer Animation. Aire-la-Ville, Switzerland, Switzerland: Eurographics Association,
2012. (SCA ’12), p. 211–219. ISBN 978-3-905674-37-8.
6 SILVA, D. B. da et al. Tunable robustness: An artificial contact strategy with virtual

actuator control for balance. Computer Graphics Forum, 2017. ISSN 1467-8659.
7 MILLINGTON, I. Game physics engine development. [S.l.]: Morgan Kaufmann

Publishers Amsterdam, 2007.
8 JR, R. S. W. et al. OpenGL SuperBible: comprehensive tutorial and reference. [S.l.]:

Pearson Education, 2010.
9 DEMURA, K. Tutorial: ERP and CFM. 2017. <http://demura.net/english/ode8>.

[Online; acessado em 23-Outubro-2017].
677
Capítulo
4
Processamento Digital de Imagens Médicas com
Python e OpenCV
Marcos Vinícius dos Santos Ferreira, Edson Damasceno Carvalho, Antonio

Oseas de Carvalho Filho e Alcilene Dalília de Sousa
Abstract
In the medical field, many anomalies are diagnosed from digital images. Early detection
of these abnormalities is fundamental for a more efficient treatment and with fewer risks to
the patient, besides increasing the chances of a more favorable prognosis. To improve me-
dical diagnosis through imaging, digital image processing studies requirements to extract
technical information to enhance the parameters of a more accurate diagnosis. Decision
support systems, called Computer Aided Detection / Diagnosis - CAD / CADx, are com-
putational tools to aid medical diagnosis through imaging, giving the expert a second
opinion for a more accurate diagnosis. Thus, it is proposed to present an introduction
to Digital Image Processing applied to Medical Imaging with the OpenCV library using
the Python language. It is intended to allow an introductory view of the PDI through the
content provided, providing a greater understanding of the learning with practical appli-
cations, arousing greater interest and new ideas for applications in the most varied areas
of knowledge.
Resumo
Na área médica, muitas anomalias são diagnosticados a partir de imagens digitais. A de-
tecção precoce dessas anomalias é fundamental para um tratamento mais eficiente e com
menos riscos ao paciente, além de aumentar as chances de prognóstico mais favorável.
Com o objetivo de melhorar o diagnóstico médico através de imagens, o processamento
digital de imagens estuda requisitos para extrair informações técnicas a fim de melhorar
os parâmetros para um diagnóstico mais preciso. Sistemas de apoio a decisão, chamados
de Computer Aided Detection/Diagnosis - CAD/CADx, são ferramentas computacionais
para auxiliar o diagnóstico médico através de imagens, proporcionando ao especialista
uma segunda opinião para um diagnóstico mais preciso. Assim, tem-se como proposta
678
apresentar uma introdução ao Processamento Digital de Imagens aplicado a Imagens

médicas com a biblioteca OpenCV usando a linguagem Python. Deseja-se permitir, atra-
vés do conteúdo ministrada, uma visão introdutória ao PDI, provendo um maior entendi-
mento no aprendizado com aplicações práticas, despertando um maior interesse e novas
idéias para aplicações nas mais variadas áreas do conhecimento.
4.1. Introdução
Com a popularização dos dispositivos eletrônicos para captura de imagens e vídeos, a
análise automática desses dados através de programas computacionais tornou-se essencial
nas mais variadas áreas de domínio da ciência. Para isso, algoritmos e representações
são desenvolvidos para permitir que uma máquina reconheça objetos, pessoas, cenas e
atividades.
O Processamento Digital de Imagens (PDI) estuda os aspectos visual de certas
feições estruturais para o analista humano e fornecer outros subsídios para a sua inter-
pretação, inclusive gerando produtos que possam ser posteriormente submetidos a outros
processamentos [Câmara et al. 1996]. A principal função do processamento digital de
imagens é fornecer ferramentas para facilitar a identificação e a extração de informações
contidas nas imagens [Silva 2001].
O PDI não é uma tarefa simples, na realidade envolve um conjunto de tarefas
interconectadas. Algumas etapas do processamento digital de imagens são:
1. Aquisição: É nessa etapa que as imagens são capturadas e representadas de forma

computacional para serem interpretadas na etapa seguinte.
2. Pré-Processamento: Essa etapa prepara a imagem para as fases seguintes que vi-
sam à identificação de estruturas de interesse e o relacionamento da estrutura detec-
tada com uma base de conhecimento.
3. Segmentação: Essa etapa consiste em técnicas que de alguma maneira consigam

formar padrões de agrupamento, gerando sub-regiões que possuem entre si alguma
similaridade.
4. Extração de Características: Esta etapa tem como objetivo representar, através de

valores, uma imagem ou partes dela. Estes valores são medidas fundamentais que
representam propriedades contidas nas imagens.
5. Reconhecimento e Interpretação: Nessa etapa, os valores obtidos na etapa de

extração de características são os insumos para que uma técnica de aprendizado de
máquina possa, então, discernir entre possíveis padrões contidos em um grupo de
imagens.
Aplicações com finalidades diversas têm sido desenvolvidas por vários grupos de
pesquisas, visando a auxiliar na composição de diagnósticos como uma forma de contri-
buir para a detecção precoce de doenças.
679
O objetivo deste capítulo é apresentar técnicas de processamento de imagens, es-

tabelecendo como foco principal as aplicações sobre imagens médicas, destinadas a cons-
tituírem fontes de dados para sistemas de auxílio ao especialista na tomada de decisão.
São apresentados conceitos sobre a aquisição de imagens médicas, técnicas de processa-
mento de imagens e seus efeitos sobre imagens médicas, além de exemplos de aplicações
reais de técnicas com o objetivo de auxiliar na detecção precoce de doenças.
As técnicas aqui apresentadas podem ser aplicadas a imagens provenientes de
qualquer modalidade. Por questões de delimitação de objeto de estudo, maior ênfase será
dada às imagens provenientes de Radiografia. Os exemplos apresentados considerarão
apenas imagens em tons de cinza, visto que grande parte das modalidades médicas con-
sidera escalas de cinza para representar as diferentes estruturas. No entanto, os conceitos
apresentados podem ser aplicados a imagens coloridas com algumas adaptações.
4.2. Informática Médica

A partir da problemática gerada por diversas doenças em nível mundial, uma gama de
técnicas que auxiliam o trabalho dos profissionais de saúde tem sido estudadas e imple-
mentadas nas mais diversas áreas do conhecimento. Na computação, podemos pontuar os
sistemas de auxílio ao especialista, que fornecem informações complementares de exames
médicos e são capazes de contribuir significativamente às interpretações e tomadas de de-
cisão de alto risco. Para construção destes sistemas são associadas técnicas relacionadas a
Processamento digital de imagens, Inteligência artificial, Aprendizado de máquina, dentre
outras áreas de pesquisa, apresentando respostas significativas às demandas apresentadas.
A Informática médica compreende um conjunto de soluções computacionais ca-
pazes de auxiliar no trabalho dos especialistas de saúde e na relação dos pacientes com
diversas doenças. Esta área de conhecimento perpassa desde os sistemas de auxílio ao
diagnóstico a aplicativos que realizam a prevenção ou acompanhamento de diversas doen-
ças. Dessa maneira, tendo em vista a relevância da saúde na vida das pessoas e sociedade,
todos os esforços neste sentido são significativos e satisfatórios.
Aplicações com finalidades diversas têm sido desenvolvidas por vários grupos de
pesquisas, visando a auxiliar na composição de diagnósticos como uma forma de con-
tribuir para a detecção precoce de doenças. O diagnóstico auxiliado por computador
é aquele no qual o radiologista usa os resultados de uma análise computadorizada de
imagens médicas como uma segunda opinião na detecção de lesões e na elaboração do
diagnóstico.
Sistemas de detecção/diagnóstico auxiliado por computador, são sistemas, mui-
tas vezes acoplados a equipamentos médicos, com a finalidade de auxiliar na tomada
de decisão a respeito de um diagnóstico. A importância desses esquemas é enfatizada
por [Chan et al. 1990], [Doi et al. 1991], [Ellis et al. 1993], [Giger e MacMahon 1996] e
[Petrick et al. 1996], que apresentam taxas de diagnósticos errados em programas de ras-
treamento e mostram que o uso de sistemas CAD/CADx pode melhorar o desempenho de
radiologistas no diagnóstico médico.
É extensa a lista de aplicações possíveis dos algoritmos de visão computacional,
que são particularmente relevantes na realização de tarefas insalubres e repetitivas que
680
de outra forma seriam delegadas a seres humanos. Por ter base conceitual genérica e
ampla, a ideia do CAD/CADx pode ser aplicada a todas as modalidades de obtenção de
imagem, incluindo radiografia convencional, tomografia computadorizada, ressonância
magnética, ultra-sonografia e medicina nuclear. Pode-se, também, desenvolver esquemas
CAD/CADx para todos os tipos de exame de todas as partes do corpo, como crânio, tórax,
abdômen, osso e sistema vascular, entre outros. Porém, os principais objetos de pesquisa
para o desenvolvimento de sistemas CAD/CADx têm sido as áreas de mamografia, para
a detecção precoce do câncer de mama, tórax, para a detecção de nódulos pulmonares
e Optical Coherence Tomography (OCT) e Heidelberg Retinal Tomography (HRT), para
diagnóstico precoce do glaucoma [de Azevedo-Marques 2001].
Através destes sistemas podemos observar uma contribuição significativa ao tra-
balho do especialista e, consequentemente, nos resultados para os pacientes. Um exem-
plo é a metodologia proposta por [Carvalho Filho 2016], para a classificação de nódulos
pulmonares pertencentes à base de imagem LIDC-IDRI. Foram utilizados os índices de
diversidade taxonômica e a distinção taxonômica da ecologia para descrever a textura de
nódulos e não-nódulos e para classificação foi utilizado a Máquina de Vetor de Suporte
- MVS. A metodologia foi empregada em 833 exames e obteve uma precisão média de
98,11% em sua classificação.
[Carvalho et al. 2017] propôs uma metodologia para o diagnóstico automático de
tecidos da mama em maligno e benigno. A metodologia utilizada no estudo foi: aquisição
de imagem oriundas da base DDSM, extração de características de textura baseado nos
índices de diversidade filogenética, classificação utilizando múltiplos classificadores, e
por fim, a validação da metodologia, utilizando de métricas estatísticas. A metodologia
foi empregada em 1155 exames e obteve uma acurácia de 94,8% em sua classificação.
[Claro 2015] desenvolveu um método para detecção automática de Glaucoma, que
é a segunda principal causa de cegueira no mundo e não possui cura. A metodologia
utilizada no estudo foi: aquisição de imagem, pré-processamento nas imagens da retina,
extração de características de cor e entropia na área alvo e logo após a seleção de atributos.
Os melhores resultados produziram uma sensibilidade de 93,7%, especificidade de 93,6%
e uma acurácia de 93,67%.
Os exemplos de aplicações da informática médica apresentadas utilizaram as téc-
nicas de PDI para a manipulação e análise das imagens. A seguir são apresentados os
passos desenvolvidos em um sistema completo de auxílio ao especialista, fornecendo
informações para compreender as técnicas específicas de manipulação de imagens, ou
construir novas abordagens e metodologias que contribuam para o contexto da informá-
tica médica.
4.3. Processamento Digital de Imagens

Uma imagem pode ser definida como uma função bidimensional, onde x e y são coordena-
das espaciais e a amplitude de f no par de coordenadas f (x, y) é denominado intensidade
ou nível de cinza. Quando x e y e a intensidade dos valores de f são finitos e discretos,
tem-se então uma imagem digital. Esses elementos possuem uma localização e um valor
particular, chamado de pixel [Sousa et al. 2011].
681
Para aplicações práticas, a imagem é uma função contínua, representada por me-
didas obtidas em intervalos regularmente espaçados. Os valores assumidos em cada ponto
medido são quantificados em um número pertencente a uma escala de diferentes cores.
Em imagens médicas, geralmente essas cores são relacionadas a níveis de cinza, sendo
atribuído o valor zero à cor mais escura (preto) e o valor máximo M à cor mais clara da
escala (branco). Dessa forma, pode-se representar uma imagem como uma matriz onde
cada ponto é um valor discreto, conforme mostra a Equação 1, onde n e m correspondem
à quantidade de colunas e linhas, respectivamente.
 
f (0, 0) f (0, 1) ... f (0, n − 1)

 f (1, 0) f (1, 1) ... f (1, n − 1) 

 . 
f (x, y) =   (1)

 . 

 . 
f (m − 1, 0) f (m − 1, 1) ... f (m − 1, n − 1)
Na Figura 4.1 ilustra a representação de uma imagem em tonalidade de cinza e a

outra colorida. Imagens em tonalidade de cinza apresentam somente um valor em cada
posição da matriz para representação dos pixeis, formando a imagem, como ilustrado na
Figura 4.1(a). Dada a junção das cores vermelho, verde e azul é possível formar combi-
nações entre elas para representar as demais cores. Visto isso, imagens digitais coloridas
apresentam 3 valores em cada posição da matriz, representando as cores vermelho, verde
e azul, para compor a cor de um pixel na escala RGB, como ilustra a Figura 4.1(b).
Figura 4.1. (a) imagem em níveis de cinza, (b) imagem no esquema de cores Red,
Green e Blue (RGB).
O objetivo de definir matematicamente a imagem é a possibilidade de manipular

o seu conteúdo a fim de transformá-la ou retirar dela informações importantes. Ao vasto
conjunto de operações que podemos aplicar em uma matriz que representa uma imagem
denominamos processamento de imagem.
O processamento e a análise de imagens é uma ciência que permite modificar,
analisar e manipular imagens digitais, originalmente contínuas, a partir de um computa-
682
dor. Os algoritmos de processamento de imagens são procedimentos passo-a-passo para

otimizar as operações de tratamento de imagens.
A função primordial do PDI de sensoriamento remoto é a de fornecer ferramen-
tas para facilitar a identificação e a extração da informação contidas nas imagens, para
posterior interpretação. Nesse sentido, sistemas dedicados de computação são utiliza-
dos para atividades interativas de análise e manipulação das imagens brutas. O resultado
desse processo é a produção de outras imagens, estas já contendo informações específicas,
extraídas e realçadas a partir das imagens brutas [Silva 2001].
O sistema visual humano possui uma notável capacidade de reconhecer padrões.
Contudo, ele dificilmente é capaz de processar o enorme volume de informação presente
numa imagem. Vários tipos de degradações e distorções, inerentes aos processos de aqui-
sição, transmissão e visualização de imagens, contribuem para limitar ainda mais essa
capacidade do olho humano.
O processamento de imagem digital vem para remover essas barreiras, ineren-
tes ao sistema visual humano, facilitando a extração de informações a partir de imagens.
Nesse contexto, o processamento digital deve ser encarado como um estágio preparatório,
embora quase sempre obrigatório, da atividade de interpretação das imagens de sensoria-
mento remoto.
Atualmente existem diversas bibliotecas para manipulação das operações de PDI,
como Insight Segmentation and Registration Toolkit (ITK), scikit-image, OpenCV, entre
outras. Para demonstração das operações básicas de PDI em imagens médicas utilizou-se
a biblioteca OpenCV, visto que a mesma compreende um conjunto de técnicas e ferra-
mentas de manipulação, análise de imagens e visão computacional, com código aberto e
multiplataforma [Bradski e Kaehler 2008].
O OpenCV foi projetado para eficiência computacional e com foco forte em apli-
cativos em tempo real. O OpenCV está escrito em C otimizado e pode aproveitar os pro-
cessadores multicore. Ele está disponível para desenvolvimento nas linguagens Python,
Ruby, Matlab, e outras. Na metodologia faz se uso da linguagem python para desenvolver
soluções com a biblioteca por ser uma linguagem de alto nível simples de compreender.
4.3.1. Base de Imagem

Tudo se inicia com a captura de uma imagem, a qual, normalmente, corresponde à ilu-
minação que é refletida na superfície dos objetos, realizada através de um sistema de
aquisição. Após a captura por um processo de digitalização, uma imagem precisa ser
representada de forma apropriada para tratamento computacional. Imagens podem ser
representadas em duas ou mais dimensões, de acordo com o problema abordado.
Desde que Röentgen, em 1895, descobriu a existência de uma radiação até então
desconhecida, capaz de atravessar materiais, ser parcial ou totalmente absorvida por eles e
fixar-se em anteparos, a dinâmica dos exames médicos sofreu drásticas mudanças. Com a
descoberta dos Raios-X, tornou-se possível a visualização de estruturas internas do corpo
e diagnosticar anomalias.
A partir daí, o avanço na aquisição, processamento e armazenamento de imagens
médicas vem permitindo o aperfeiçoamento de diagnósticos e tratamentos de doenças
683
de naturezas diversas. Cada modalidade de imagem médica atua de forma diferenciada.

Sua aquisição visa a ressaltar as diferenças entre os diversos tipos de tecidos existentes
na natureza e, especialmente, aqueles que compõem o corpo humano, fazendo com que
estruturas de interesse se sobressaiam e, assim, possam ser identificadas como eventuais
anomalias.
Algumas bases de imagens médicas são dispostas públicas com o objetivo de fa-
cilitar a pesquisa sólida no desenvolvimento de algoritmos computacionais para traze-
rem soluções auxílio do diagnóstico de patologias. Exemplos de bases são a RIM-ONE,
DRIONS-DB, DRISTHI GS1 para o glaucoma, as bases DDSM, MIAS e IRMA para o
câncer de mama e a base ISIC para o melanoma, que é o câncer de pele. Na Figura 4.2(a)
tem-se um exemplo de uma imagem médica da base ISIC, na Figura 4.2(b) uma imagem
da base DDSM, e na Figura 4.2(c) uma imagem da base DRISTHI.
Figura 4.2. Exemplos de Imagens Médicas.
Para realização dos testes práticos, será utilizado imagens da base RIM-ONE,
por a mesma possuir imagens que podem ser aplicadas todas as etapas de PDI para o
desenvolvimento de um sistema CAD/CADx. Para a concretização deste trabalho, foram
utilizadas 60 imagens, sendo 30 normal e 30 com presença de glaucoma. Todas as lesões
no banco de dados são demarcadas por médicos especialistas.
4.3.2. Pré-Processamento
As técnicas de pré-processamento têm a função de melhorar a qualidade da imagem.
Estas técnicas envolvem duas categorias principais: métodos que operam no domínio
espacial e métodos que operam no domínio da frequência. Técnicas de processamento no
domínio espacial baseiam-se em filtros que manipulam o plano da imagem, enquanto que
as técnicas de processamento no domínio da frequência se baseiam em filtros que agem
sobre o espectro da imagem. É comum para realçar determinadas características de uma
imagem, combinar vários métodos que estejam baseados nestas duas categorias.
4.3.3. Segmentação
A segmentação de imagem é um processo importante para a maioria das tarefas de análise
de imagens médicas. Ter uma segmentação boa irá beneficiar clínicos e pacientes, pois
fornecem informações importantes para visualização, planejamento cirúrgico e detecção
684
precoce da doença [Ng et al. 2006].

Para o desenvolvimento de sistemas CAD/CADx é necessário que as imagens pas-
sem por uma etapa de segmentação. Segmentar, em processamento digital de imagem,
significa subdividir uma imagem em suas partes ou objetos constituintes. A segmentação
envolve a divisão de imagens em subseções que são de particular interesse, como a defi-
nição de áreas de uma imagem apropriada para subsequentemente serem analisadas ou a
descoberta de círculos, linhas ou outras formas de interesse.
A segmentação pode parar quando esses objetos de interesse foram isolados. Os
algoritmos de segmentação para imagens monocromáticas geralmente são baseados na
descontinuidade das intensidades de imagem, como bordas em uma imagem ou em seme-
lhanças julgadas por critérios predefinidos [Patton et al. 2006].
A segmentação automática é uma das tarefas mais difíceis em processamento de
imagens. Esse passo determina o eventual sucesso ou fracasso na análise. De fato, a
segmentação efetiva quase sempre garante sucesso no reconhecimento. Por essa razão, um
cuidado considerável deve ser tomado para se melhorar as chances de uma segmentação
robusta [Gonzalez e Woods 2000].
No OpenCV a função utilizada para segmentação é cv2.threshold. O primeiro
argumento é a imagem de origem, que deve ser uma imagem em escala de cinza. O
segundo argumento é o valor de limiar que é usado para classificar os valores de pixel. O
terceiro argumento é o maxVal que representa o valor a ser dado se o valor do pixel for
maior que (às vezes menor do que) o valor do limite.
Considerando uma imagem bimodal, em palavras simples, a imagem bimodal é
uma imagem cujo histograma tem dois picos. Para essa imagem, podemos tirar aproxi-
madamente um valor no meio desses picos como valor limiar. Isso é o que a binarização
Otsu faz. Então, em palavras simples, ele calcula automaticamente um valor limiar do
histograma de imagem para uma imagem bimodal. Para imagens que não são bimodais,
a binarização não apresenta uma limiarização precisa.
O Código Fonte 4.1 mostra os passos para realizar a segmentação de imagens da
retina baseado no limiar de Otsu. Para isso, a função cv2.threshold() é usada, mas passa
um método extra, cv2.THRESH_OTSU. Para o valor limiar, simplesmente passa zero. Em
seguida, o algoritmo encontra o valor de limiar ideal e retorna como a segunda saída,
retVal.
1
i m p o r t g l o b a s g # p a c o t e p a r a o b t e r p a t h de a r q u i v o s em um d i r e t o r i o
3 i m p o r t cv2 # o p e n c v
from d e s c r i t o r _ t e x t u r a i m p o r t e x t r a i r _ c a r a c t e r i s t i c a s # s c r i p t de
e x t r a a o de f e a t u r e s
5 from c l a s s i f i c a d o r i m p o r t c l a s s i f i c a r # s c r i p t de c l a s s i f i c a c a o
7 def aquisicao_imagens ( path , extensao ) :

’’’
9 : param p a t h : caminho do d i r e t o r i o que contem a s i m a g e n s
: param e x t e n s a o : e x t e n s a o d a s i m a g e n s . EX : . png
11 : r e t u r n : l i s t a com o caminho de t o d a s a s i m a g e n s do d i r e t o r i o
’’’
685
13 l i s t a = g . glob ( pathname= p a t h + ’ ∗ ’+ e x t e n s a o )
return lista
15
17 d e f s o b r e p o r ( imagem , m a s c a r a ) :
’’’
19 : param imagem : imagem o r i g e m
: param m a s c a r a : imagem que contem a m a s c a r a a p o n t a n d o a r e g i a o de
interese
21 : r e t u r n : a imagem s o b r e p o s t a
’’’
23 f o r i in range ( mascara . shape [ 0 ] ) : # p e r c o r r e as l i n h a s
f o r j in range ( mascara . shape [ 1 ] ) : # p e r c o r r e as colunas
25 i f m a s c a r a [ i ] [ j ] == 0 :
imagem [ i ] [ j ] = 0
27 r e t u r n imagem
29
def segmentar_com_otsu ( path_img ) :

31 ’’’
: param p a t h _ i m g : caminho da imagem a s e r s e g m e n t a d a
33 : r e t u r n : r e t o r n a a imagem s e g m e n t a d a e a imagem o r i g e m n o s 3 c a n a i s
RGB
’’’
35
# l e a imagem em t o n s de c i n z a
37 img = cv2 . i m r e a d ( p a t h _ i m g , 0 )
# l e a imagem n o s t r e s c a n a i s
39 i m g _ c h a n n e l = cv2 . i m r e a d ( p a t h _ i m g )
# s e g m e n t a a imagem a t r a v e s de um l i m i a r o b t i d o p e l o a l g o r i t m o OTSU
41 r e t , i m a g e m _ s e g m e n t a d a _ p o r _ l i m i a r = cv2 . t h r e s h o l d ( img , 127 , 2 5 5 ,
cv2 . THRESH_OTSU )
# r e t o r n a a imagem o r i g i n a l e a s e g m e n t a d a
43 r e t u r n img_channel , imagem_segmentada_por_limiar
45
i f __name__ == ’ __main__ ’ :
47 # d i r e t o r i o onde contem a s i m a g e n s
d i r _ i n = ’ / home / p a v i c / P y c h a r m P r o j e c t s / PDI−M e d i c a l / d a t a / i m a g e n s /
normal ’
49 # d i r e t o r i o onde a s i m a g e n s s e g m e n t a d a s e s o b r e p o s t a s s e r a o s a l v a s
d i r _ o u t = ’ / home / p a v i c / P y c h a r m P r o j e c t s / PDI−M e d i c a l / d a t a / s e g m e n t a d a s
/ normal ’+ s t r ( ’ / ’ )
51
# v a r i a v e l p a r a e n c o n t r a r o nome da imagem
53 separador = dir_in . s p l i t ( ’ / ’ )
s e p a r a d o r = s e p a r a d o r [ l e n ( s e p a r a d o r ) −1]
55
# obtem uma l i s t a com o caminho de t o d a s a s i m a g e n s

57 caminho_imagens = a q u i s i c a o _ i m a g e n s ( path = d i r _ i n + ’ / ’ , extensao= ’ .
png ’ )
59 # c i c l o que r e a l i z a o p r o c e s s a m e n t o
f o r i i n caminho_imagens :
61
686
# s e g m e n t a a e s o b r e p o e a imagem
63 img_seg = segmentar_com_otsu ( path_img = i )
65 # obtem o nome da imagem

nome_img = i . s p l i t ( ’ / ’ + s e p a r a d o r + ’ / ’ ) [ 1 ]
67
# s a l v a a imagem
69 cv2 . i m w r i t e ( f i l e n a m e = d i r _ o u t +nome_img , img= s o b r e p o r ( i m g _ s e g [ 0 ] ,
img_seg [ 1 ] ) )
71 # r e a l i z a n d o a e x t r a c a o de c a r a c t e r i s t i c a s
e x t r a i r _ c a r a c t e r i s t i c a s ( p a t h _ n o r m a l = ’ / home / p a v i c / P y c h a r m P r o j e c t s /
PDI−M e d i c a l / d a t a / s e g m e n t a d a s / n o r m a l / ’ ,
73 p a t h _ d o e n t e = ’ / home / p a v i c / P y c h a r m P r o j e c t s /
PDI−M e d i c a l / d a t a / s e g m e n t a d a s / d o e n t e / ’ ,
p a t h _ a r q u i v o _ d e s c r i t o r = ’ / home / p a v i c /
P y c h a r m P r o j e c t s / PDI−M e d i c a l / d a t a / d e s c r i t o r / d e s c r i t o r e s . l i b s v m ’ ,
75 e x t e n s a o = ’ . png ’ )
77 #classificar
c l a s s i f i c a r ( p a t h _ a r q u i v o _ d e s c r i t o r = ’ / home / p a v i c / P y c h a r m P r o j e c t s / PDI
−M e d i c a l / d a t a / d e s c r i t o r / d e s c r i t o r e s . l i b s v m ’ )
Código Fonte 4.1. Segmentação de Imagens Médicas.
O glaucoma é uma anomalia que se dá pela lesão no nervo óptico, localizado no

centro da retina na estrutura do Disco Óptico (DO). Assim para ter um diagnóstico mais
promissor, é necessário isolar o DO do restante da imagem para ser analisada, pois ela é
a região de interesse. Na Figura 4.3 ilustra essa primeira etapa para isolamento do DO.
Na Figura 4.3(a) tem-se a imagem utilizada para teste. Na Figura 4.3(b) tem-se a imagem
segmentada pelo algoritmo Otsu e na Figura 4.3(c) tem-se a sobreposição da máscara com
a imagem original para isolamento da região de interesse, o DO.
Figura 4.3. Passos para isolamento da região de interesse.
4.3.4. Extração de Características

Na análise de imagens, visão computacional e reconhecimento de padrões, os sistemas
necessitam-se reconhecer elementos ou objetos de interesse nas imagens, para isso, são
estabelecidos parâmetros quantificáveis, que dependem de cor, posição, orientação, di-
mensões, textura, para poder ser realizado computacionalmente [CONCI et al. 2008].
A extração de características é uma forma utilizada para extrair dados em uma
687
imagem que possa caracterizar a mesma, onde, a partir de um conjunto grande de carac-
terísticas, seja extraída aquelas que são mais redundantes para o problema, formando um
conjunto mais reduzido de características por imagem digital. A extração de caracterís-
ticas tem como objetivo mensurar e quantificar padrões perceptíveis ou não visualmente,
com a finalidade de categorizar objetos nas imagens, de acordo com aspectos morfológi-
cos de interesse.
Na maioria das metodologias CAD/CADx, a etapa de extração de informações
é baseada em: 1) forma, que caracteriza a geometria dos objetos, como o tamanho, a
curvatura e a suavidade dos contornos e 2) na textura, que é caracterizada por variações
locais em valores de pixel que se repetem de maneira regular ou aleatória ao longo da
imagem.
A extração de características foi realizado por meio da textura das imagens base-
ado nos índices de diversidade filogenética. A filogenia é um ramo da biologia responsá-
vel pelo estudo das relações evolutivas entre as espécies, pela verificação dos relaciona-
mentos entre elas, a fim de determinar possíveis ancestrais comuns [Webb 2000].
Diversidade filogenética é uma medida de uma comunidade que incorpora as re-
lações filogenéticas das espécies [Magurran 2004]. A forma mais simples da aplicação
do índice de diversidade em imagens é quando a comunidade representa uma imagem ou
região da mesma, as espécies sendo os níveis de cinza, os indivíduos sendo os pixels e as
distâncias filogenética sendo os número de arestas entre duas espécies [Oliveira 2013]. A
Tabela 4.1 mostra a correspondência entre a biologia e a metodologia.
Tabela 4.1. Correspondência entre a biologia e a metodologia.

Biologia Metodologia
Comunidade Região de interesse da imagem
Espécies Níveis de cinza da imagem
Indivíduos Pixels da imagem
Distância filogenética Número de arestas entre duas espécies
Nesse trabalho são feitos cálculos dos seguintes atributos de textura: Phylogenetic
Diversity - PD (Equação 2) e Sum of Phylogenetic Distances - SPD (Equação 3).
∑Bi Li Ai
PD = B × (2)
∑Bi Ai
ΣΣm < n2 mna ma n

S (S − 1)
SPD = × (3)
2 ΣΣm < na ma n
Foram utilizados os índices de diversidade filogenética para descrever a textura

das regiões das imagens médicas. A análise de textura dessas regiões tem como intuito
encontrar padrões que serão utilizados para categorizar as imagens médicas. O Código
Fonte 4.2 mostra os passos para extração de características de textura, baseado nos índices
de diversidade filogenética.
688
import glob as g
2 i m p o r t cv2
from u t i l . u t i l i m p o r t getMaximum , getMinimum , n o r m a l i z e
4
d e f g e r a S V M f i l e ( r o t u l o , l i s t a _ f e a t , p a t h _ f i l e , modo ) :
6 ’’’
: param r o t u l o : c l a s s e que p e r t e n c e a s f e a t u r e s
8 : param l i s t a _ f e a t : l i s t a de c a r a c t e r i s t i c a s
: param p a t h _ f i l e : d i r e t o r i o do a r q u i v o onde s e r a s a l v o a s
caracteristicas
10 : param modo : modo de l e i t u r a do a r q u i v o
: r e t u r n : void
12 ’’’
a r q u i v o = open ( p a t h _ f i l e , modo )
14 featureFile = str ( rotulo ) + " "
arquivo . write ( f e a t u r e F i l e )
16 for i in range ( len ( l i s t a _ f e a t ) ) :
l i n h a = s t r ( s t r ( i + 1) + " : " + s t r ( l i s t a _ f e a t [ i ] ) + " " )
18 arquivo . write ( linha )
arquivo . write ( ’ \ n ’ )
20 arquivo . close ()
22 d e f d e s c r e v e r _ i n d i c e s ( c l a s s e , l i s t a , p a t h _ f i l e _ d e s c r i t o r , modo ) :
’’’
24 : param c l a s s e : c l a s s e a q u a l p e r t e n c e a image , 0 p a r a d o e n t e , e 1
para normal
: param l i s t a : l i s t a com o caminho de t o d a s a s i m a g e n s a s e r e m
processadas
26 : param p a t h _ f i l e _ d e s c r i t o r : caminho do a r q u i v o d e s c r i t o r que
armazena as f e a t u r e s
: param modo : modo de l e i t u r a do a r q u i v o d e s c r i t o r
28 : param s i z e : tamanho d a s l i s t a s
: param i n c : i n c r e m e n t o p a r a c a l c u l o da p o r c e n t a g e m
30 : r e t u r n : void
’’’
32 prodind = 0.0
dis = 0
34 valorMPD = 0 . 0
SPD = 0 . 0
36 S1 = 0 . 0
S2 = 0 . 0
38 PD = 0 . 0
soma1 = 0
40 somatorio = 0
MNND = 0 . 0
42 q = 0.0
44 # c a l c u l a os ndices para t o d a s as imagens

for i in range ( len ( l i s t a ) ) :
46 img = cv2 . i m r e a d ( l i s t a [ i ] , 0 )
min = getMinimum ( image =img )
48 max = getMaximum ( image =img )
50 s i z e H i s t o g r a m a = 256
689
h i s t = l i s t ( range ( sizeHistograma ) )
52 d i s t a n c e = l i s t ( range ( sizeHistograma ) )
b a c k g r o u n d = min
54
f o r b i n r a n g e ( img . s h a p e [ 0 ] ) :
56 f o r c i n r a n g e ( img . s h a p e [ 1 ] ) :
v a l u e = img [ b ] [ c ]
58 i f i n t ( value ) > 0:
h i s t [ v a l u e ] += 1
60
especie = 0
62 for d in range (0 , sizeHistograma ) :
i f i n t ( h i s t [ d ]) > 0:
64 e s p e c i e += 1
66 diagonal = 0.0
foraDiagonal = 0.0
68
f o r e i n r a n g e ( img . s h a p e [ 0 ] ) :
70 f o r f i n r a n g e ( img . s h a p e [ 1 ] ) :
i f i n t ( img [ e ] [ f ] ) ! = b a c k g r o u n d :
72 i f i n t ( e ) == i n t ( f ) :
_ v a l o r = img [ e ] [ f ] + min
74 d i a g o n a l += n o r m a l i z e ( _ v a l o r )
else :
76 _ v a l o r = f l o a t ( img [ e ] [ f ] + min )
f o r a D i a g o n a l += n o r m a l i z e ( _ v a l o r )
78 indices = []
i n d i c e s . append ( f l o a t ( ( ( e s p e c i e ∗ d i a g o n a l ) − f o r a D i a g o n a l ) / (
especie ∗ ( especie − 1) ) ) )
80 i n d i c e s . append ( f l o a t ( e s p e c i e ∗ i n d i c e s [ 0 ] ) )
82 PSV = i n d i c e s [ 0 ]
PSR = i n d i c e s [ 1 ]
84
for x in range (0 , sizeHistograma ) :
86 for y in range ( x + 1 , sizeHistograma ) :
i f x == 0 :
88 d i s t a n c e [ x ] = ( y − x + 1)
else :
90 d i s t a n c e [ x ] = ( y − x + 2)
92 prodind = ( distance [ x ] ∗ h i s t [ x ] ∗ h i s t [ y ] )
s o m a t o r i o += ( h i s t [ x ] ∗ h i s t [ y ] )
94
for q in range (x , y ) :
96 MNND = MNND + ( d i s t a n c e [ x ] ∗ h i s t [ q ] )
98 t = ( ( sizeHistograma − 1) / 2 . 0 ) #
t o t a l = sizeHistograma ∗ t #
100
for x in range (0 , sizeHistograma ) :
102 for y in range ( x + 1 , sizeHistograma ) :
i f x == 0 :
104 dis = (y − x) + 1
690
else :
106 dis = (y − x) + 2
108 p r o d i n d += ( d i s ∗ h i s t [ x ] ∗ h i s t [ y ] )
s o m a t o r i o += ( h i s t [ x ] ∗ h i s t [ y ] )
110
fo r i n d i c e in range ( x , ( y + 1) ) :
112 soma1 += h i s t [ i n d i c e ]
114 Ai = soma1 / ( ( y − x ) + 1 )
S1 += ( d i s ∗ Ai )
116 S2 += Ai
118 valorMPD += p r o d i n d
120 PD = S1 / S2
q = valorMPD / s o m a t o r i o
122 SPD = t o t a l ∗ q
124 feat = []
f e a t . a p p e n d ( PD )
126 f e a t . a p p e n d ( SPD )
128 geraSVMfile ( r o t u l o = c l a s s e , l i s t a _ f e a t = f e a t , p a t h _ f i l e =
p a t h _ f i l e _ d e s c r i t o r , modo=modo )
130 def e x t r a i r _ c a r a c t e r i s t i c a s ( path_normal , path_doente ,

path_arquivo_descritor , extensao ) :
"""
132 : param p a t h _ n o r m a l : d i r e t o r i o d a s i m a g e n s n o r m a i s
: param p a t h _ d o e n t e : d i r e t o r i o d a s i m a g e n s d i e n t e s
134 : param p a t h _ a r q u i v o _ d e s c r i t o r : d i r e t o r i o do a r q u i v o d e s c r i t o r
: param e x t e n s a o : e x t e n s a o d a s imagens , EX . . png
136 : r e t u r n : void
"""
138 l i s t a _ n o r m a l = g . glob ( path_normal + ’∗ ’+ e x t e n s a o )
l i s t a _ d o e n t e = g . glob ( p a t h _ d o e n t e + ’ ∗ ’+ e x t e n s a o )
140 TAM = l e n ( l i s t a _ n o r m a l ) + ( l e n ( l i s t a _ n o r m a l ) )
a = open ( p a t h _ a r q u i v o _ d e s c r i t o r , ’w ’ )
142 a . close ()
d e s c r e v e r _ i n d i c e s ( c l a s s e =0 , l i s t a = l i s t a _ n o r m a l , p a t h _ f i l e _ d e s c r i t o r
= p a t h _ a r q u i v o _ d e s c r i t o r , modo= ’ a ’ )
144 d e s c r e v e r _ i n d i c e s ( c l a s s e =1 , l i s t a = l i s t a _ d o e n t e , p a t h _ f i l e _ d e s c r i t o r
= p a t h _ a r q u i v o _ d e s c r i t o r , modo= ’ a ’ )
Código Fonte 4.2. Extração de Características de textura das Imagens.
4.3.5. Classificação
Classificação consiste em reconhecer novos objetos, a partir de descritores gerados dos
mesmos, tomando decisões a partir da extração de características do mundo real em ima-
gens, isso é feito por meio de indagações simples a respeitos dos parâmetros extraídos, ou
por meio de algoritmos de inteligência artificial [CONCI et al. 2008].
No processamento de imagens digitais, classificar uma imagem consiste em pegar
691
um conjunto de características extraídas de um grupo de imagens do objeto de interesse e

treinar um sistema para que possa reconhecer novos objetos a partir dessas características.
O reconhecimento de padrões ou características, usa alguns métodos ou técnicas,
desde as mais simples, baseadas em vizinhos mais próximos, funções discriminantes,
arvore de decisão, até as mais complexas, baseadas em redes baysianas, lógica fuzzy e
redes neurais, para a classificação de imagens de acordo com os descritores extraídos
[CONCI et al. 2008].
Usualmente são utilizados algoritmos de aprendizado de máquina supervisiona-
dos, ou seja, é preciso apresentar dados pré-classificados e ensinar o algoritmo a iden-
tificar diferentes objetos. Nesse caso, é necessário uma base de dados que contenha ao
menos parte dos dados previamente avaliados e rotulados por um especialista. Dessa
forma o algoritmo poderá aprender os padrões dos objetos de cada classe. Os algo-
ritmos de aprendizado de máquina supervisionados utilizado foi: Support vector ma-
chine (SVM) [Cortes e Vapnik 1995], AdaBoost [Freund et al. 1996] e Random Forest
(RF) [Breiman 2001].
O SVM [Cortes e Vapnik 1995], faz um mapeamento do espaço de entrada para
um espaço de dimensionalidade maior. Em seguida, é calculado um hiperplano de separa-
ção ótimo. O hiperplano é escolhido de modo a maximizar a distância de separação entre
as classes [Haykin 1994]. Diz-se que duas classes são linearmente separáveis se existe
um hiperplano divisório entre as amostras de classes diferentes.
O SVM é um algoritmo de aprendizado supervisionado, ou seja, possui as fases
de treinamento e teste. Na fase de treinamento, os atributos e as classes dos objetos são
as entradas do classificador e o objetivo é projetar os vetores de suporte. Os vetores de
suporte são utilizados para se obter o hiperplano de separação ótimo. Na fase de teste, o
hiperplano é utilizado para encontrar uma saída a partir de um vetor de entrada.
Para utilizar SVM para reconhecimento de padrões, o algoritmo requer a transfor-
mação de funções não-linearmente separáveis em funções linearmente separáveis. Para
isso, é necessário que seja aumentada a dimensionalidade do problema [Cover 1965]. As
funções que aumentam a dimensionalidade do espaço de entrada são chamadas funções
de kernel [Haykin 1994].
O AdaBoost [Freund et al. 1996], é um meta-algoritmo de aprendizagem de má-
quinas. Ele pode ser usado em conjunto com muitos outros tipos de algoritmos de apren-
dizagem para melhorar seu desempenho. O AdaBoost é adaptável no sentido de que
aprendentes fracos subsequentes são modificados em favor de instâncias mal classifica-
das por classificadores anteriores. O AdaBoost é sensível a dados ruidosos e outliers.
Entretanto para alguns problemas é menos suscetível a perda da capacidade de generali-
zação após o aprendizado de muitos padrões de treino (overfitting) do que a maioria dos
algoritmos de aprendizado de máquina.
O AdaBoost chama um classificador fraco repetidamente em iterações t = 1, ..., T .
Para cada chamada a distribuição de pesos Dt é atualizada para indicar a importância do
exemplo no conjunto de dados usado para classificação. A cada iteração os pesos de cada
exemplo classificado incorretamente é aumentado, ou alternativamente, os pesos classifi-
cados corretamente são decrementados, para que então o novo classificador trabalhe em
692
mais exemplos.
O algoritmo Random Forest é uma combinação de predições de diversas árvores
em que cada árvore depende dos valores de um vetor independente, amostrados aleatori-
amente e com a mesma distribuição para todas as árvores da floresta. Aqui, floresta é a
nomenclatura dada a uma coleção de árvores de decisão. Após a geração de um grande
número de árvores, as classes com maior número de votos são eleitas [Breiman 2001].
O Random Forest divide cada nó usando o melhor dentre um subconjunto de indi-
cadores escolhidos aleatoriamente naquele nó. Esta estratégia, apesar de um tanto contra-
ditória, funciona adequadamente em comparação com muitos outros classificadores, além
de ser robusto a superajuste nos parâmetros. Além disso, é de fácil utilização pois possui
apenas dois parâmetros: o número de variáveis no subconjunto aleatório em cada nó e o
número de árvores da floresta [Silva et al. 2017].
A partir de um vetor de atributos, são gerados outros vetores de atributos, que
são embaralhados em relação ao vetor original. É gerado um vetor para cada árvore do
Random Forest. Em seguida, os vetores de atributos são passados como parâmetro para as
árvores de decisão. Cada árvore irá gerar um resultado para a classificação e, os resultados
são combinados obtendo uma saída unificada [Silva et al. 2017].
A classificação de objetos em python pode ser realizada através da biblioteca
scikit-learn. Esta biblioteca permite a utilização de algoritmos de aprendizagem de má-
quina, clusterização, seleção de atributos, dentre outros. As etapas básicas para classifi-
cação são: divisão do conjunto de dados em treino e teste; criação de uma instância do
classificador utilizado; treino do classificador; predição utilizando os dados de teste; e cál-
culo da taxa de acerto seguindo alguma métrica de avaliação de desempenho. O Código
Fonte 4.3 mostra as etapas de classificação de um conjunto de dados para os classificado-
res SVM, AdaBoost e Random Forest.
1 from s k l e a r n . svm i m p o r t SVC
from s k l e a r n . e n s e m b l e i m p o r t R a n d o m F o r e s t C l a s s i f i e r
3 from s k l e a r n . m o d e l _ s e l e c t i o n i m p o r t t r a i n _ t e s t _ s p l i t
from s k l e a r n . e n s e m b l e i m p o r t A d a B o o s t C l a s s i f i e r
5 from u t i l . u t i l i m p o r t p l o t _ c o n f u s i o n _ m a t r i x , c o n f u s i o n _ m a t r i x
i m p o r t numpy a s np
7 from m a t p l o t l i b i m p o r t p y p l o t a s p l t
from v a l i d a c a o i m p o r t m a i n _ v a l i d a c a o
9
def get_data ( path_data ) :

11 """
f o r m a t a o s d a d o s do a r q u i v o d o s d e s c r i t o r e s
13 p a r a c o n v e r t e r em uma l i s t a de FEATURES e LABELS
"""
15 FEATURES = [ ] # l i s t a de c a r a c t e r i s t i c a s
LABELS = [ ] # l i s t a de r o t u l o s
17 f i l e _ d a t a = open ( p a t h _ d a t a , ’ r ’ )
for i in f i l e _ d a t a :
19 lista = str ( i ) . split ( ’ ’)
F = []
21 for j in range ( len ( l i s t a ) ) :
i f j == 0 :
23 LABELS . a p p e n d ( l i s t a [ j ] )
693
else :
25 if l i s t a [ j ] != ’ \ n ’ :
value = l i s t a [ j ] . s p l i t ( ’ : ’ ) [1]
27 F . append ( v a l u e )
FEATURES . a p p e n d ( F )
29 r e t u r n LABELS , FEATURES
31 def gerar_matrix_confusao ( y_test , y_pred ) :

# c a l c u l a a m a t r i x de c o n f u s a o
33 cnf_matrix = confusion_matrix ( y_test , y_pred )
t n , fp , fn , t p = c o n f u s i o n _ m a t r i x ( y _ t e s t , y _ p r e d ) . r a v e l ( )
35 np . s e t _ p r i n t o p t i o n s ( p r e c i s i o n = 2 )
37 c l a s s _ n a m e s = [ ] # r o t u l o s p a r a o g r a f i c o da m a t r i x de c o n f u s a o
c l a s s _ n a m e s . a p p e n d ( ’ Normal ’ )
39 c l a s s _ n a m e s . append ( ’ Doente ’ )
41 # g r a f i c o de m a t r i x de c o n f u s a o com d a d o s nao n o r m a l i z a d o s
plt . figure ()
43 plot_confusion_matrix ( cnf_matrix , c l a s s e s =class_names ,
t i t l e = ’ Confusion matrix , without
normalization ’ )
45
# g r a f i c o de m a t r i x de c o n f u s a o com d a d o s n o r m a l i z a d o s
47 plt . figure ()
plot_confusion_matrix ( cnf_matrix , c l a s s e s =class_names , normalize=
True ,
49 t i t l e = ’ Normalized confusion matrix ’ )
m a i n _ v a l i d a c a o ( t n , fp , fn , t p ) # e x i b i o s v a l o r e s de a c u r a c i a ,
sensibilidade e especificidade
51 p l t . show ( ) # e x i b e o g r a f i c o
53
def classificar_com_SVM ( X_train , X_test , y_train , y _ t e s t ) :
55 c_svm = SVC ( ) # c r i a uma i n s t a n c i a do modelo SVM
c_svm . f i t ( X _ t r a i n , y _ t r a i n ) # t r e i n a o modelo
57 y _ p r e d = c_svm . p r e d i c t ( X _ t e s t ) # f a z a p r e d i c a o s o b r e o s d a d o s de
teste
g e r a r _ m a t r i x _ c o n f u s a o ( y _ t e s t , y _ p r e d ) # e x i b e o g r a f i c o com a m a t r i x
de c o n f u s a o
59
61 def classificar_com_RandomForest ( X_train , X_test , y_train , y _ t e s t ) :

c_rf = RandomForestClassifier ()
63 c_rf . f i t ( X_train , y _ t r a i n )
rf_pred = c_rf . predict ( X_test )
65 gerar_matrix_confusao ( y_test , rf_pred )
67
def c l a s s i f i c a r _ c o m _ A d a B o o s t C l a s s i f i e r ( X_train , X_test , y_train , y _ t e s t
):
69 csf_ad = AdaBoostClassifier ()
csf_ad . f i t ( X_train , y _ t r a i n )
71 prediction = csf_ad . predict ( X_test )
gerar_matrix_confusao ( y_test , prediction )
694
73
75
d e f model ( LABELS , FEATURES ) :
77 TRAIN = 0 . 2
TEST = 1 − TRAIN
79
# f o r m a t a o s d a d o s de t e r i n o e t e s t e
81 X _ t r a i n , X _ t e s t , y _ t r a i n , y _ t e s t = t r a i n _ t e s t _ s p l i t ( FEATURES ,
LABELS , t e s t _ s i z e =TEST )
83 classificar_com_SVM ( X_train , X_test , y_train , y _ t e s t ) #

c l a s s i f i c a d o r SVM
classificar_com_RandomForest ( X_train , X_test , y_train , y _ t e s t ) #
c l a s s i f i c a d o r Random F o r e s t
85 c l a s s i f i c a r _ c o m _ A d a B o o s t C l a s s i f i e r ( X_train , X_test , y_train , y _ t e s t
) # classificador AdaBoostClassifier
87
def c l a s s i f i c a r ( p at h_ a rq u iv o_ d es c ri to r ) :
89 # obtem a l i s t a de l a b e l s e c a r a c t e r i s t i c a s
L, F = get_data ( path_arquivo_descritor )
91 # c r i a o modelo , c l a s s i f i c a e g e r a a s m a t r i z e s de c o n f u s a o
model ( L , F )
Código Fonte 4.3. Classificação de imagens utilizando os classificadores
Random Forest, AdaBoost e Máquina de Vetor de Suporte.
4.3.6. Validação
A fim de considerarmos a presença ou ausência de anomalias em imagens medicas, para
validação dos resultados, utiliza-se de métricas de avaliação baseadas em estatísticas
como, Sensibilidade [Martinez et al. 2003], Especificidade [Martinez et al. 2003] e Acu-
rácia [Metz 1986].
A matriz de confusão oferece uma hipótese das medidas efetivas do modelo de
classificação, mostrando o número de classificações corretas versus as classificações pre-
ditas para cada classe, sobre um determinado conjunto de exemplo, como mostra a Tabela
4.2.
Tabela 4.2. Matriz de Confusão

Doença
Resultado do Teste
Presente Ausente
Positivo Verdadeiro Positivo - VP Falso Positivo - FP
Negativo Falso Negativo - FN Verdadeiro Negativo - VN
A sensibilidade (S), Equação 4, é a capacidade de um teste diagnóstico identificar

os verdadeiros positivos nos indivíduos verdadeiramente doentes. Quando um teste é
sensível, raramente deixa de encontrar pessoas com a doença.
VP
S= (4)
V P + FN
695
Especificidade (E), Equação 5, é a capacidade de um teste diagnóstico identifi-

car os verdadeiros negativos nos indivíduos verdadeiramente sadios. Quando um teste é
especifico, raramente cometera o erro de dizer que pessoas sadias são doentes.
VN
E= (5)
V N + FP
Acurácia (A), Equação 6, é a proporção de acertos, ou seja, o total de verdadeira-
mente positivos e verdadeiramente negativos, em relação a amostra estudada.
V P +V N
A= (6)
V P +V N + FP + FN
O Código Fonte 4.4 mostra as etapas de validação dos resultados para Acurácia,
Sensibilidade e Especificidade, que são métricas de avaliação baseadas em estatísticas.
2 d e f a c u r a c i a ( vn , fp , fn , vp ) :
r e t u r n ( vp+vn ) / ( vp+vn+ f p + f n )
4
d e f e s p e c i f i c i d a d e ( vn , f p ) :
6 r e t u r n ( vn ) / ( vn+ f p )
8 d e f s e n s i b i l i d a d e ( fn , vp ) :
r e t u r n ( vp ) / ( vp+ f n )
10
12 d e f m a i n _ v a l i d a c a o ( vn , fp , fn , vp ) :
"""
14 : param vn : v e r d a d e i r o s p o s i t i v o s
: param f p : f a l s o s p o s i t i v o s
16 : param f n : f a l s o s n e g a t i v o s
: param vp : v e r d a d e i r o s p o s i t i v o s
18 : return :
"""
20 p r i n t ( ’ A c u r a c i a _ _ _ _ _ _ _ _ _ _ _ _ _ _ [ %.2 f%s ] ’ %(( a c u r a c i a ( vn , fp , fn , vp
) ∗ 1 0 0 ) , "%" ) )
p r i n t ( ’ E s p e c i f i c i d a d e _ _ _ _ _ _ _ _ [ %.2 f%s ] ’ %(( e s p e c i f i c i d a d e ( vn , f p )
∗ 1 0 0 ) , "%" ) )
22 p r i n t ( ’ S e n s i b i l i d a d e _ _ _ _ _ _ _ _ _ [ %.2 f%s ] ’ %(( s e n s i b i l i d a d e ( fn , vp )
∗ 1 0 0 ) , "%" ) )
Código Fonte 4.4. Validação da Classificação.
4.3.7. Resultados usando a base RIN-ONE

Nesta seção, são apresentados os resultados obtidos com a metodologia proposta. O sis-
tema CAD/CADx ideal tem um bom equilíbrio entre as três métricas utilizadas para ava-
liação (acurácia, sensibilidade e especificidade), uma vez que uma boa metodologia deve
ser capaz de classificar com sucesso os casos normal e doentes.
As imagens utilizada na pratica foram dividido em 70% treinamento, constituído
por 41 imagens e 30% das imagens para teste, constituído por 19 imagens. A Tabela 4.3
696
mostra os resultados da classificação obtidos para Acurácia, Sensibilidade e Especifici-

dade. O melhor caso foi obtido usando o RandomForest e o Adaboost, que obtiveram uma
acurácia de 100%, já o pior caso foi obtido com o SVM, apresentando uma acurácia de
42,11% na classificação de imagens da retina em normal ou glaucomatosa. A Figura 4.4
mostra a matriz de confusão obtido para o SVM, a Figura 4.5 mostra a matriz de confusão
para o RandomForest e a Figura 4.6 mostra a matriz de confusão para o Adaboost após a
classificação.
Tabela 4.3. Resultados da Classificação.

Classificador Acurácia (%) Sensibilidade (%) Especificidade (%)
SVM 42,11 0 100
RandomForest 100 100 100
Adaboost 100 100 100
De acordo com a Tabela 4.3, o SVM não apresentou uma taxa de acurácia muito
boa, caracterizando todos as imagens como glaucomatosas. O RandomForest e o Adabo-
ost conseguiram de forma eficiente, caracterizar as imagens em normal e glaucomatosas.
Figura 4.4. Matriz de Confusão da classificação do SVM.
697
Figura 4.5. Matriz de Confusão da classificação do RandomForest.
Figura 4.6. Matriz de Confusão da classificação do AdaBoost.
698
4.4. Conclusão
Neste capitulo foram mostrados conceitos de processamento de imagens e de visão com-
putacional. Os exemplos descritos foram implementados utilizando a biblioteca OpenCV
desenvolvida pela Intel. O OpenCV facilita a implementação de operadores simples até
o desenvolvimento de sistemas mais complexos na área de processamento de imagens e
visão computacional.
O primeiro desafio a ser considerado na construção de sistemas CAD/CADx é
obter uma alta taxa de acerto de casos verdadeiros-positivos, isto é, indicar a presença de
uma doença quando ela realmente existe, com uma baixa taxa de casos falsos-positivos,
quando o sistema indica a existência de uma doença, sem esta de fato existir.
Para se obter um bom desempenho em relação aos acertos, é necessário conhecer
profundamente o problema a ser detectado e a imagem médica que será utilizada para
o diagnóstico, considerando seu processo de formação, que exerce influência nas suas
características.
A utilização do OpenCV fornece enormes vantagens ao desenvolver sistemas que
incluem segmentação, quantificação e visualização de imagens médicas. Destacada-
mente, a grande velocidade na implementação de esquemas de visualização complexos
é um importante diferencial, pois agiliza processos que, se fossem desenvolvidos desde
o começo, levariam muito tempo. Além disso, a considerável quantidade de algoritmos
e técnicas que existe na biblioteca é de grande utilidade na resolução dos mais diversos
problemas em processamento digital de imagens e/ou visualização científica.
Referências
[Bradski e Kaehler 2008] Bradski, G. e Kaehler, A. (2008). Learning OpenCV: Compu-
ter vision with the OpenCV library. "O’Reilly Media, Inc.".
[Breiman 2001] Breiman, L. (2001). Random forests. Machine learning, 45(1):5–32.
[Câmara et al. 1996] Câmara, G., Souza, R. C. M., Freitas, U. M., e Garrido, J. (1996).
Spring: Integrating remote sensing and gis by object-oriented data modelling. Compu-
ters & graphics, 20(3):395–403.
[Carvalho et al. 2017] Carvalho, E. D., Carvalho Filho, A. O., Sousa, A. D., Barros, P.
V. S., e Drumond, P. M. L. L. (2017). Diferenciação de padrões de benignidade e malig-
nidade em tecidos da mama baseado na diversidade taxonômica. 17 WIM - Workshop
de Informática Médica / XXXVII Congresso da Sociedade Brasileira de Computação,
37:1911–1920.
[Carvalho Filho 2016] Carvalho Filho, A. O.; Silva, A. C. P. A. C. G. R. A. N. M. (2016).

Lung-nodule classification based on computed tomography using taxonomic diversity
indexes and an svm. Journal of Signal Processing Systems for Signal, Image, and
Video Technology, 83.
[Chan et al. 1990] Chan, H.-P., Doi, K., Vybrony, C. J., Schmidt, R. A., Metz, C. E.,
Lam, K. L., Ogura, T., Wu, Y., e MacMahon, H. (1990). Improvement in radiolo-
699
gists’ detection of clustered microcalcifications on mammograms: The potential of

computer-aided diagnosis. Investigative radiology, 25(10):1102–1110.
[Claro 2015] Claro, M. L.; Araújo, F. H. D. (2015). Uso de classificadores para a detec-
ção automática do glaucoma.
[CONCI et al. 2008] CONCI, A., AZEVEDO, E., e LETA, F. L. (2008). Computação
Gráfica: Teoria e Pratica., volume 2. Elsevier.
[Cortes e Vapnik 1995] Cortes, C. e Vapnik, V. (1995). Support-vector networks. Ma-

chine learning, 20(3):273–297.
[Cover 1965] Cover, T. M. (1965). Geometrical and statistical properties of systems of

linear inequalities with applications in pattern recognition. IEEE transactions on elec-
tronic computers, (3):326–334.
[de Azevedo-Marques 2001] de Azevedo-Marques, P. M. (2001). Diagnóstico auxiliado

por computador na radiologia. Radiologia Brasileira, 34(5):285–293.
[Doi et al. 1991] Doi, K., Giger, M., MacMahon, H., Hoffmann, K., Katsuragawa, S.,
Nishikawa, R., Yoshimura, Y., Sanada, S., Chen, X., Metz, C., et al. (1991). Computer-
aided diagnosis: present and future. by H. Abe, K. A tsumi, T. linuma, M. Saito and M.
Inoue, Elsevier Science Publishers BV, Amst erdam, pages 59–66.
[Ellis et al. 1993] Ellis, I., Galea, M., Locker, A., Roebuck, E., Elston, C., Blamey, R., e
Wilson, A. (1993). Early experience in breast cancer screening: emphasis on develop-
ment of protocols for triple assessment. The Breast, 2(3):148–153.
[Freund et al. 1996] Freund, Y., Schapire, R. E., et al. (1996). Experiments with a new
boosting algorithm. In Icml, volume 96, pages 148–156.
[Giger e MacMahon 1996] Giger, M. e MacMahon, H. (1996). Image processing and

computer-aided diagnosis. Radiologic Clinics of North America, 34(3):565–596.
[Gonzalez e Woods 2000] Gonzalez, R. C. e Woods, R. E. (2000). Processamento de

imagens digitais. Edgard Blucher.
[Haykin 1994] Haykin, S. (1994). Neural networks: a comprehensive foundation. Pren-

tice Hall PTR.
[Magurran 2004] Magurran, A. E. (2004). Measuring biological diversity. African Jour-

nal of Aquatic Science; v. 29, n. 2, p. 285-286.
[Martinez et al. 2003] Martinez, E. Z., Louzada-Neto, F., e Pereira, B. d. B. (2003). A

curva roc para testes diagnósticos. Cad. saúde colet.,(Rio J.), 11(1):7–31.
[Metz 1986] Metz, C. E. (1986). Roc methodology in radiologic imaging. Investigative

radiology, 21(9):720–733.
700
[Ng et al. 2006] Ng, H., Ong, S., Foong, K., Goh, P., e Nowinski, W. (2006). Medical
image segmentation using k-means clustering and improved watershed algorithm. In
Image Analysis and Interpretation, 2006 IEEE Southwest Symposium on, pages 61–65.
IEEE.
[Oliveira 2013] Oliveira, F. S. S. (2013). Classificação de tecidos da mama em massa e

não-massa usando Índice de diversidade taxonômico e máquina de vetores de suporte.
Dissertação de Mestrado. Curso de Pós-Graduação em Engenharia de Eletricidade da
Universidade Federal do Maranhão. São Luís - MA.
[Patton et al. 2006] Patton, N., Aslam, T. M., MacGillivray, T., Deary, I. J., Dhillon, B.,
Eikelboom, R. H., Yogesan, K., e Constable, I. J. (2006). Retinal image analysis:
concepts, applications and potential. Progress in retinal and eye research, 25(1):99–
127.
[Petrick et al. 1996] Petrick, N., Chan, H.-P., Sahiner, B., e Wei, D. (1996). An adaptive
density-weighted contrast enhancement filter for mammographic breast mass detec-
tion. IEEE Transactions on Medical Imaging, 15(1):59–67.
[Silva 2001] Silva, A. (2001). Curso processamento digital de imagens de satélite. XX

CBC–68p.
[Silva et al. 2017] Silva, R. R. V., Lopes, J. G. F. ., Araújo, F. H. D., Medeiros, F. N. S.,
e Ushizima, D. M. (2017). Visão computacional em python utilizando as bibliotecas
scikit-image e scikit-learn, volume 1. III Escola Regional de Informática do Piauí.
Livro Anais - Artigos e Minicursos, first edition.
[Sousa et al. 2011] Sousa, U. S. et al. (2011). Classificação de massas na mama a partir
de imagens mamográficas usando índice de diversidade de shannon-wiener.
[Webb 2000] Webb, C. O. (2000). Exploring the phylogenetic structure of ecological

communities: an example for rain forest trees. The American Naturalist 156.2, p.
145-155.
701
Capítulo
5
Produção de Objetos de Aprendizagem Baseados
em Vídeos Interativos voltados para o ambiente
TVDi
Alex de Souza Vieira, Franklhes Santos Carvalho, Adeilson Bezerra de Lima,

Lorena de Fátima de Almeida Oliveira, Manoel Ribeiro Filho e Carlos de
Salles Soares Neto
Abstract
This work aims to introduce to the participants some authoring tools and others virtual
resources that can be used on production of Learning Objects Based on Interactive Videos
(LOBIV) to the interactive Digital TV environment (TVDi). Initially the learning object
(LO) concept is presented, describing the current scenario and how this kind of objects
can be produced and used in the iDTV environment. This work has a practical appro-
ach where, from a reference LOBIV developed by these authors’ own, others people are
instructed to adopted and reproduce the production process this LOBIV.
Resumo
Este minicurso tem como objetivo apresentar aos participantes algumas ferramentas de
autoria e outros recursos virtuais que podem ser utilizados na Produção de Objetos de
Aprendizagem Baseados em Vídeos Interativos (OABVI) voltados para o ambiente da TV
Digital interativa (TVDi). Inicialmente é apresentado o conceito de objeto de aprendiza-
gem (OA), descrevendo o cenário atual e como objetos podem ser produzidos e utilizados
no ambiente da TVDi. O minicurso tem uma abordagem prática onde, a partir de um
OABVI de referência desenvolvido pelos proponentes, os participantes são orientados a
reproduzi-lo visando apropriarem-se do processo de produção do OABVI e, em seguida,
são convidados produzirem os seus próprios conteúdos interativos.
5.1. Introdução
O processo de ensino e aprendizagem tem sido impactado pela explosão de informações
hipermídias que são produzidas e disponibilizadas diariamente na internet. Tais informa-
ções são compostas muitas vezes por mídias de áudio, vídeo, textos, imagens e outras
702
mídias, cujo sincronismo entre elas possibilita dispor de uma experiência individualizada
ao usuário.
A geração de nativos digitais [Sobrinho 2017] é naturalmente atraída por esse tipo
de conteúdo, pois com o avanço de tecnologias como smartphones que são lançados no
mercado cada vez robustos em termos de processamento e com recursos de captura e re-
produção de vídeo, e de áudio, com excelentes níveis de qualidade. Além disso, as pessoas
dessa geração de nativos digitais têm acesso instantâneo a conteúdos interativos. Soma-se
a isso o acesso mais popularizado também à internet, conectando-os com uma infinidade
de conteúdos educacionais e, consequentemente tem-se uma revolução no processo de
ensino e aprendizagem.
A partir das ações realizadas neste minicurso, espera-se formar um conjunto de
novos multiplicadores desta proposta mediante a utilização da linguagem audiovisual
que cada vez mais presente em plataformas online de ensino como, por exemplo, Cour-
sera (https://www.coursera.org/),EDX (edx.org), Udemy (https://www.udemy.com), Mi-
riada (miriada.net), Eduk (https://www.eduk.com.br/),Udacity (https://br.udacity.com/),
Veduca (http://veduca.org) e inúmeros canais no Youtube (youtube.com).
É importante informar que Objetos de Aprendizagem são quaisquer tipo de enti-
dades físicas ou digitais que podem ser utilizados no processo de ensino [Busson 2016],
enquanto que Objetos de Aprendizagem Baseados em Vídeos Interativos ( OABVI )
[Edwin 2012] podem ser consideradas como um tipo de especialização dos OAs, cujo
sincronismo se baseia geralmente em uma mídia de vídeo.
Por meio de ferramentas de autoria são adicionados recursos de sincronismo com
(ou sem) interatividade às mídias de vídeo educativos, isto é, outras mídias como texto,
imagem, áudio, etc. - comumente presentes em OABVIs - podem ser sincronizadas junto
ao vídeo com o intuito de torná-lo não linear e proporcionar uma melhor experiência
de consumo aos usuários desse OABVI, empoderando-os ainda mais de um consumo
personalizado de informações.
Esses recursos consistem de programas de computadores ou aplicativos criados
em Nested Context Language (NCL) [Soares 2009] que são interpretados e exibidos pelo
middleware Ginga [Soares 2010], o qual pode estar presente em diferentes dispositivos
como, por exemplo, TV ou celular, representando uma forma diferente de se produzir e
consumir vídeos interativos, mais especificamente, Objetos de Aprendizagem Baseados
em Vídeos Interativos (OABVIs), por se tratarem de conteúdos inerentes a educação.
Por uma questão de organização didática e visando um melhor acompanhamento
do documento, o roteiro das principais atividades deste minicurso foi disposto conforme
é apresentado a seguir.
Parte 1: Introdução a OA/OABVI e ambientação sobre vídeos lineares e não-
lineares
- Objetos de Aprendizagem e Objetos de Aprendizagem Baseados em Vídeos In-
terativos
- Cenário Atual (ambientes para disponibilização e consumos de Objetos de Apren-
dizagem Baseados em Vídeos interativos para o ambiente TVDi)
703
- Vídeos lineares e não-lineares (Apresentação de exemplos do Youtube e Netflix)

Parte 2: Ferramentas de autoria
- Apresentação das ferramentas de autoria: Cacuriá e NCL Eclipse
- Apresentação de conjunto de características das ferramentas de autoria utilizadas
Parte 3: Desenvolvimento do OABVI Vida Maria
- Apresentação do vídeo Vida Maria: créditos e projeto do OABVI
- Demonstração do processo de criação do OABVI Vida Maria com ferramentas
de autoria
Parte 4: Considerações finais
- Apresentação de informações adicionais e percepções sobre as atividades desen-
volvidas durante o processo.
5.2. Ferramentas de Autoria para a criação de Objetos de Aprendizagem

Nesta seção encontram-se ferramentas de autoria Cacuriá e NCL Eclipse que foram uti-
lizadas no desenvolvimento deste minicurso. Cada uma delas é apresentada a seguir e,
ao final desta seção, é apresentada uma tabela com diferentes características observadas
entre elas.
5.2.1. Ferramentas de autoria Cacuriá
Figura 5.1. Interface da ferramenta Cacuriá
Essa ferramenta foi desenvolvida pelo Laboratory of Advanced Web Systems (LAWS),
da Universidade Federal do Maranhão (UFMA), e atualmente é mantida pelo Telemídia/Puc-
Rio. Essa ferramenta tem como foco principal a criação de OAs para a TVDi / Web e pos-
sibilita a criação de aplicativos multiplataforma [Damasceno 2014]. É possível instalar a
ferramenta acessando a página http://www.telemidia.puc-rio.br/tools/ca curia.html.
A interface dessa ferramenta é composta por seis visões para manipulação das suas
704
mídias como mostra a Figura 5.1, em quê a Visão de Menu (1) é usada para adicionar e
remover mídias e cenas, visualizar o projeto e publicar OAs; a Visão de Cenas (2) é usada
– como o nome sugere – para visualizar das cenas e indicar qual a cena que está em foco;
a Visão de Leiaute (3) é usada para visualizar o posicionamento e dimensionamento da
mídia de acordo com tempo; a Visão Temporal (4) é usada para executar e manipular o
tempo de cada cena; a Visão de Propriedades (5) é usada para visualização e edição das
propriedades da mídia em foco; e, por sua vez, a Visão de Biblioteca (6) é usada para
listar as mídias da cena atual.
5.2.2. Ferramentas de autoria Ncl-Eclipse

O NCL Eclipse [Azevedo 2009] é um software livre voltado para a criação de progra-
mas em NCL (Nested Context Language). Essa ferramenta se baseia principalmente na
metáfora textual para o desenvolvimento de aplicativos voltados ao ambiente TVDi. Foi
desenvolvida pelo LAWS/UFMA e, atualmente, é mantido em conjunto com o Laborató-
rio TeleMídia/PUC-Rio.
Figura 5.2. Interface do NCL Eclipse
A interface principal da ferramenta NCL Eclipse pode ser observada na Figura

5.2. Trata-se de um plugin que é adicionado ao Eclipse para possibilitar a edição de um
documento NCL. Na área de trabalho dessa ferramenta (Figura 5.2) o autor do documento
pode criar o seu próprio Objeto de Aprendizagem (OA) expressando, por meio de relações
de causalidade, o comportamento do aplicativo, isto é, o autor pode estabelecer relações
de condições e ações às mídias que compõem o documento NCL.
Dentre as diversas características que a ferramenta possui, existe um conjunto adi-
cional de funcionalidades que podem ser ativadas ou desativadas conforme sejam as pre-
ferências do autor do documento NCL. Esse conjunto de funcionalidades é apresentado
na Figura 5.3. De maneira geral, elas são úteis para facilitar o desenvolvimento por parte
do autor que consegue, por exemplo, pré-visualizar a mídia que está declarada no corpo
do documento ou ainda utilizar-se de auto complemento de código - o que lhe confere ce-
leridade na edição desse documento. Para instalar e conhecer mais a ferramenta é possível
acessar a página http://www.telemidia.puc-rio.br/ roberto/ncleclipse/pt-br/install.
705
Figura 5.3. Configurações adicionais da ferramenta NCL Eclipse
Para prover uma melhor organização do ambiente de desenvolvimento, o Eclipse é

dividido em unidades, onde uma perspectiva é um conjunto de visões e de editores. Visões
são geralmente usadas para navegar em arquivos e mudar suas propriedades. Enquanto
que um editor é utilizado para alterar o conteúdo de um arquivo específico [Azevedo 2008].
Figura 5.4. Organização do ambiente de desenvolvimento do Eclipse
Na Figura 5.4, em que mostra a interface do Eclipse, é possível identificar o con-

junto das Visões (1) e o Editor (2) - colocado no centro da tela do Eclipse e é através dele
que são desenvolvidos os projetos. As visões Problems (1 - esquerda) - caso o Eclipse
achar que seu código precisa de algum trabalho, ele deixará uma mensagem detalhada
nessa guia de problemas e Outliner (1- direita) - mostra a estrutura da classe selecionada,
são padrões do ambiente Eclipse e serão utilizadas no desenvolvimento do NCL Eclipse.
Adicionalmente aos Editores e as Visões, o Eclipse também provê outras áreas de visu-
alização entre as quais estão um grande número de menus e barras de ferramentas que
representam os vários comandos e ações disponíveis no sistema.
706
A seguir, a Tabela 5.1 apresenta um conjunto de características das ferramentas de

autoria utilizadas, as quais são gratuitas e para desktop.
Tabela 5.1. Comparativo entre as ferramentas de autoria utilizadas

Características Ferramentas de Autoria
Cacuriá NCL Eclipse
Objetivo Criação de OA por meio de Criação de programas utili-
um processo intuitivo e natu- zando linguagem textual.
ral.
Ambientes de apresentação Ginga e HTML Ginga
Possibilita sincronismo com/sem in- Sim Sim
teratividade
Metáfora de programação Visual Textual
Possibilita sincronismo simultâneo Não Sim
de vídeos
Possibilita sincronismo simultâneo Sim Sim
de texto
Possibilita sincronismo simultâneo Sim Sim
de áudios
Possibilita sincronismo simultâneo Não Não
de foto
Gera diagramas/ visões específicos Não Sim
de NCL
Nessa tabela os objetivos foram extraídos das páginas web oficiais dos autores das
ferramentas de autoria Cacuriá e NCL Eclipse. Em relação ao ambiente de apresenta-
ção, é possível conferir, na Tabela , que a ferramenta Cacuriá disponibiliza duas formas
para visualização do OA ou aplicativo que está sendo desenvolvido, enquanto que, com
a ferramenta NCL Eclipse, é possível obter uma pré-visualização do que está sendo feito
apenas se o middleware Ginga estiver instalado no dispositivo.
Ainda de acordo com a Tabela 5.1 é possível verificar que ambas as ferramentas
possibilitam a realização de sincronismo com ou sem interatividade, isto é, as duas fer-
ramentas possibilitam que o autor explore interatividade ou não em seu documento. Por
outro lado, as ferramentas se diferem quanto a metáfora de programação. Nesse quesito,
a ferramenta Cacuriá possui uma abordagem de programação visual - baseado em WY-
SIWYG (What You See Is What You Get) - em que o autor pode organiza as mídias nas
cenas do documento sem a necessidade de conhecer previamente alguma linguagem de
programação.
Em relação a possibilidade de realizar sincronismo simultâneo de mídias, ambas
as ferramentas permitem isso para diferentes mídias como, por exemplo, texto e imagem
(Tabela 5.1). Todavia, em relação à mídia de vídeo, a ferramenta Cacuriá não permite que
o autor trabalhe com mais de um vídeo simultaneamente, enquanto que a ferarmenta NCL
Eclipse empodera o autor do documento NCL de mais liberdade neste quesito.
Por fim, ainda na Tabela 5.1, é possível notar que nenhuma das duas ferramentas
é capaz de gerar diagramas (ou visões) específicos da NCL - o que poderia ser últil para a
fase de planejamento do aplicativo e, posteriormente, à sua documentação.
707
5.3. Desenvolvimento do OABVI Vida Maria (objeto de referência)

Nesta seção são apresentados os principais passos utilizados no processo de produção do
OABVI Vida Maria - que consiste em um objeto de aprendizagem produzido para ser
uma referência durante a sua reprodução pelos participantes. Nesse sentido, é feita uma
apresentação do vídeo Vida Maria, seguido do seu projeto quanto objeto de aprendizagem.
E também é realizada uma demonstração do processo de criação do OABVI Vida Maria
com ferramentas de autoria Cacuriá e NCL Eclipse.
5.3.1. Apresentação do vídeo Vida Maria

5.3.1.1. Créditos
Vida Maria é o título de um vídeo que foi premiado no 3o Prêmio Ceará de cinema e
vídeo, lançado em 2006, realizado pelo Governo do Estado do Ceará. O curta-metragem
foi produzido em computação gráfica 3D e mostra personagens e cenários modelados
com texturas e cores pesquisadas e capturadas no Sertão Cearense, no nordeste do Brasil.
A Figura 5.5 é um recorte de uma cena inicial dessa animação, que foi produzida pelo
animador gráfico Márcio Ramos.
Figura 5.5. Cena inicial do vídeo Vida Maria (sem a adição do aplicativo)
Essa animação narra a história de Maria José, uma menina de 5 anos de idade que
é induzida pela mãe a largar os estudos para começar a cuidar dos afazeres domésticos
e trabalhar na roça. Enquanto trabalha, ela cresce, casa-se, tem filhos, envelhece e a sua
morte recomeça um ciclo que continua a se reproduzir com as outras "Marias"(mulheres)
da família. A animação está disponível gratuitamente na internet desde o dia 01 de julho
de 2017 para o público.
O projeto do OABVI Vida Maria é fundamentado no vídeo Vida Maria, sendo
este último escolhido por ser uma narrativa linear - com começo, meio e fim imutáveis
- e conter diversas questões socioeducacionais que pudessem ser enriquecidas com sin-
cronismo (com e sem) interatividade reprodutíveis por diferentes ferramentas de autoria.
708
Assim, saltos temporais e informações adicionais foram utilizadas para compor o OABVI
de referência.
5.3.1.2. Projeto do OABVI
O OABVI Vida Maria - OABVI de referência deste trabalho - consiste de um aplicativo

TVDi para inserir informações adicionais ao vídeo Vida Maria, as quais foram extraí-
das de artigos e reportagens abordando a situação cotidiana de uma parcela população
nordestina.
E para ajudar no planejamento do OABVI Vida Maria, que transformaria o vídeo
Vida Maria em um aplicativo não-linear, foram combinados um diagrama de storyboard
interativo [Vieira 2016] e uma time code específicos para isso. O storyboard interativo
foi utilizado por oferecer uma representação espacial das principais mídias visuais e dos
momentos em que as ações com sincronismos deveriam acontecer, ou seja, esse diagrama
traz uma abordagem visual capaz de apresentar a disposição de um ou mais nós de mídia
(quer seja, por exemplo, um texto, foto ou vídeo), em uma ou mais região da tela do
dispositivo, através de snapshots que formam um mapa visual do esquema navegacional
das cenas.
Observando a Figura 5.6 (a), que representa o primeiro momento de sincronismo
com interatividade, é oferecida ao usuário a oportunidade de pular a parte de apresentação
do vídeo que contém informações sobre gravadoras, patrocinadores, etc., fazendo com que
seja apresentada a primeira cena da animação - Figura 5.6(b).
Caso o usuário não selecione o botão "pular introdução", com o ENTER do com-
putador ou OK do controle remoto, então esse botão fica disponível até os 27 segundos
iniciais , desaparecendo em seguida, e o vídeo continua sem ele.
Os instantes de tempo exatos em que cada mídia é apresentada na tela são listados
adiante na Tabela 2. Essa tabela consiste em um conjunto de âncoras temporais - com os
tempos iniciais e finais de cada mídia - e representa a time code utilizada no OABVI Vida
Maria que é descrita adiante com mais detalhes.
A Figura 5.6(c) apresenta o primeiro momento de sincronismo sem interatividade,
em que é apresentado ao usuário um balão de informações sobre aspectos relacionados ao
sertão da região nordeste e as dificuldades inerentes a ela. Esse balão de informações é,
na verdade, uma mídia de texto sobre uma mídia de imagem (uma forma geométrica).
A Figura 5.6(d) apresenta o segundo momento de sincronismo sem interatividade.
Nesse caso, a informação adicionada é sobre a falta de chuva no nordeste e as suas con-
sequências para quem vive nessa região. Essa informação é apresentada ao usuário no
exato momento em que a personagem principal do vídeo, mulher jovem, volta o seu olhar
para o céu, com poucas nuvens, na expectativa de chuva.
A Figura 5.6(e) apresenta o terceiro momento de sincronismo sem interatividade,
onde há um balão com informações sobre a taxa de natalidade na região nordeste e sua
importância para quem vive nela. Perceba que esta informação é exibida na base da tela,
pois é onde há poucas informações visuais concorrentes.
709
Figura 5.6. Projeto do OABVI usando storyboard interativo
O quarto momento de sincronismo sem interatividade - Figura 5.6(f) - é um balão

de comunicação com o índice de analfabetismo no país - apresentado por [Peres 2011]
. Essa informação é apresentada na tela após a personagem principal, mulher já idosa,
repreender a filha para que auxilie nas atividades domésticas ao invés de estar tentando
escrever o seu próprio nome em um caderno.
A Figura 5.6(g) é o último momento de sincronismo sem interatividade do OABVI
Vida Maria, em que aparece a imagem de um caderno com as tentativas incipiente de alfa-
betização de todas as mulheres ("Marias") da família e, neste momento, são apresentadas
ao usuário informações sobre a relação latifúndio-analfabetismo e concentração de renda
familiar na região nordeste, segundo [Peres 2011].
Por fim, na Figura 5.6(h), é apresentado o segundo momento de sincronismo com
interatividade representado pelo botão "Pular Créditos". Nesse momento, se o usuário
opta por não assistir aos últimos segundos do vídeo que apresenta informações sobre
equipe de produção, direção, etc., então ele pode selecionar o botão ENTER do computa-
dor ou OK do controle remoto para saltar essa parte do vídeo e finalizá-lo.
Para complementar o planejamento de sincronização das mídias do OABVI Vida
Maria, conferindo-lhe maior precisão temporal, é apresentada a Tabela 2 que contém um
mapeamento de todos os momentos de sincronismo que esse objeto deve conter. Essa
time code é um artefato que pode ser usado durante o processo produção do OABVI com
710
o intuito de facilitar o seu desenvolvimento. É válido informar que cada mídia (info) sem
interatividade apresentada na time code, da Tabela 2, possui um tempo de vida de 15
segundos, isto é, cada informação dessas é mantida por 15 segundos na tela a partir do
instante em que é exibida.
Para complementar o planejamento de sincronização das mídias do OABVI Vida
Maria, conferindo-lhe maior precisão temporal, é apresentada a Tabela 2 que contém um
mapeamento de todos os momentos de sincronismo que esse objeto deve conter. Essa
?time code é um artefato que pode ser usado durante o ?processo? produção do OABVI
com o intuito de facilitar o seu desenvolvimento e também conferir-lhe maior coesão
aos momentos de sincronização entre informação adicional e janela espaço-temporal das
mídias de vídeo.
É válido informar que cada mídia sem interatividade apresentada na time code
(Tabela 2) possui um tempo de vida de 10 segundos (terceira coluna), isto é, cada infor-
mação é mantida por 10 segundos na tela a partir do instante em que começa a ser exibida
(segunda coluna).
Tabela 5.2. Time Code – Vida Maria

Referência Instante inicial Instante Final
Informação "Pular abertura" 00:05 segundos 00:26 segundos
Início do título do vídeo 00:05 segundos —-
Informação 1 01:33 ( ou 93 segundos) 01:43 (ou 103 segundos)
Informação "Pular créditos" 07:32 segundos 07:42 (ou 462 segundos)
A primeira coluna, da Tabela 2, usa como referência os nomes das mídias que fo-
ram utilizadas empregadas no OABVI Vida Maria. Desse modo, visando tornar mais mais
compreensível o entendimento dessa tabela, apresenta-se a seguir uma breve descrição de
cada referência citada.
Informação "Pular abertura": representa a informação visual (um botão inte-
rativo) que indica para o usuário a possibilidade de saltar a parte inicial do vídeo Vida
Maria, a qual contém informações como, por exemplo, patrocínio e apoio na produção
desse vídeo. Essa mídia representa o primeiro momento de interatividade.
Início do título do vídeo: representa o momento seguinte a apresentação da aber-
tura e consiste no momento em que surge no vídeo, pela primeira vez, o título da anima-
ção.
Informação 1, Informação 2, Informação 3, Informação 4 e Informação 5:
são mídias textuais ou objetos de mídia contendo textos com informações sobre temas
como, por exemplo, educação, saúde, taxa de alfabetização e taxa de natalidade acerca da
região nordeste.
Informação "Pular créditos": refere-se ao segundo momento de sincronismo
com interatividade. É também uma mídia que permite ao usuário saltar a parte do vídeo
que contém informações sobre a direção do vídeo, produção, elenco, assistententes, etc.
711
5.3.2. Demonstração do processo de criação do OABVI Vida Maria com ferramen-

tas de autoria
Nesta seção apresentam-se os principais passos utilizados durante o processo de produção
do OABVI Vida Maria utilizando, como apoio, a ferramenta de autoria Cacuriá e, em
seguida, são apresentados os mesmos passos utilizando a ferramenta NCL Eclipse.
Todavia, por tratarem de atividades divididas basicamente em dois momentos dis-
tintos (sicronismo com interatividade e sincronismo com interatividade), e sendo as de-
mais repetições dessas atividades, então a seguir é apresentado um tutorial contendo uma
tríade de passos: exemplo de inserção de vídeo; exemplo de inserção de sincronismo com
interatividade; e exemplo de inserção de sincronismo sem interatividade. Desse modo o
leitor obtém rapidamente uma visão geral do grau de esforço despendido em cada ferra-
menta.
5.3.2.1. Passos básicos utilizando a ferramenta de autoria Cacuriá
Inserção do vídeo Vida Maria

Para inserir o objeto de mídia referente ao vídeo Vida Maria, basta que o autor
do documento clique no ícone inserir vídeo, indicado pela seta para cima, no canto es-
querdo superior da área de trabalho da ferramenta Cacuriá, conforme é apresentado na
Figura 5.7(a).
Em seguida, é preciso selecionar o vídeo da mídia desejada. Para isso, o autor
deve percorrer o diretório onde o vídeo se encontra e selecioná-lo. Note que o ícone
inserir vídeo é desabilitado logo após ser inserido, Figura 5.7(b), para reforçar que apenas
um vídeo pode estar presente ferramenta cena. Por fim, o resultado dessa inserção é
apresentado na tela da ferramenta - Figura 5.7 (b) - e já está pronto para exibição.
Figura 5.7. Inserindo um vídeo na ferramenta Cacuriá.
Exemplo de inserção de sincronismo com interatividade

Para inserir o objeto de mídia referente ao botão de interatividade - que no OABVI
de referência deste trabalho consiste de uma mídia de texto sobre uma mídia de imagem
chamada de forma- basta que o autor do documento clique no ícone inserir forma, des-
712
tacado pela seta branca, Figura 18(a), e, em seguida, selecione uma dentre as diversas
opções.
Figura 5.8. Inserindo botão de interatividade.
Em seguida, é preciso arrastar e redimensionar a forma que foi selecionada para

o canto direito inferior - conforme apresentado na Figura 5.8(b). Note que a forma usada
aparecerá na cor padrão da ferramenta (cor laranja). O autor do documento pode alterar
essa cor usando as propriedades da forma - indicado na Figura 5.8(c). O resultado dessa
inserção é apresentado na tela principal da ferramenta - Figura 5.8(d).
Em seguida, com a forma ainda selecionada, é necessário clicar na propriedade
Elo - Figura 5.9, para configurar principalmente o botão que aciona a ação interativa -
neste caso o ENTER ou OK - e configurar também um tempo específico do vídeo ao qual
o fluxo deve ser direcionado, caso o botão ENTER ou OK seja acionado.
Exemplo de inserção de sincronismo sem interatividade
Assim como foi feito para inserir a mídia referente ao botão de interatividade, tam-
bém é feita a inserção das informações adicionais. Isto é, basta que o autor do documento
repita os passos da opção de inserir forma - conforme é apresentado na Figura 5.10(a).
Em seguida, redimensionar esta forma para o centro superior - conforme apresentado na
Figura 5.10(b).
É preciso que o autor insira uma mídia do tipo texto sobre a forma usada, essa
opção está localizada no menu da ferramenta Cacuriá, destacado pela letra "T". Em se-
713
Figura 5.9. Especificando um momento de sincronismo com interatividade.
Figura 5.10. Inserindo informação adicional.
guida o autor digita a informação desejada e a arrasta para cima da forma que foi inserida
previamente. Por fim, o resultado dessa inserção é apresentado na tela da ferramenta -
Figura 5.10(c).
5.3.2.2. Passos básicos utilizando a ferramenta de autoria NCL Eclipse
Nesta seção considera-se que as mídias a serem utilizadas (vídeo Vida Maria, imagem
do botão de interatividade e balões de informação) já foram todas produzidas as configu-
rações do ambiente de desenvolvimento/apresentação já estão configurados e que alguns
elementos básicos do documento NCL já foram declarados (i.e. base de regiões, base de
descritores e base de conectores).
Inserindo o vídeo Vida Maria
Para inserir o vídeo Vida Maria, o autor do documento pode informar no contexto
principal dele - tag <body> - o elemento port (<port>) que deve ser o componente a ser
iniciado quando o documento for executado - nesse caso, a mídia a ser iniciada é a mídia
chamada de "videoPrincipal".
714
Figura 5.11. Trecho de código que inicia a apresentação do vídeo principal.
A Figura 5.11 mostra que Vida Maria (src="vidaMaria.mp4 ) é a mídia de vídeo

intitulada de "videoPrincipal- conforme pode ser visto no atributo id desta tag - utilizada
nesse documento NCL e que "descRegTelaCheia"é o descritor que aponta para a região
onde o vídeo deve ser apresentado. Note que há algumas áreas (elementos area) que com-
põem esta mídia. Tais áreas são utilizadas adiante como marcadores temporais quando as
mídias que contêm as informações adicionais devem ser exibidas, conforme a time code
da Tabela 2.
Inserindo botão de interatividade
Novamente, abstraindo algumas questões básicas relacionadas à configuração do
ambiente de execução/apresentação e, assumindo também que já foi realizada a decla-
ração das principais bases necessárias para a execução de um documento NCL, então o
autor do documento - após fazer a declaração dos principais elementos NCL - pode adi-
cionar um link que referencie uma instância do conector onBeginStart para efetuar o
relacionamento causal apresentada na Figura 5.12.
Figura 5.12. Link de sincronismo sem interatividade
A Figura 5.12 representa uma instância da relação onBeginStart fazendo com que,
quando começar o componente videoPrincipal (que representa o objeto de vídeo Vida
Maria), então o componente botaoPulaIntro que contém uma mídia de foto - uma alterna-
tiva equivalente à junção das mídias de texto e forma apresentado na Seção 1.3.2.1 - deve
ser iniciado. Em outras palavras, esse relacionamento (link) faz com que um botão de
interatividade seja apresentado na tela do aparelho do usuário quando o vídeo principal
começar. Os detalhes dessa implementação - inclusive o delay na exibição do referido
botão.
Dado que o botão pular introdução é apresentado então é possível que o usuário
possa acioná-lo usando a tecla ENTER, conforme é apresentado na Figura 5.13.
Esse link indica que se o botão ENTER for selecionado nos primeiros segundos
715
Figura 5.13. Link de sincronismo com interatividade
do vídeo, então as mídias que representam, respectivamente, o ícone pular introdução e

vídeo Vida Maria devem ter sua exibição paradas e o vídeo principal passa a ser exibido
a partir do momento 1 - correspondente à ação iniciar vídeo, da Tabela 2.
Inserindo informação adicional
Abstraindo, mais uma vez, algumas questões relacionadas à configuração do am-
biente de execução/apresentação e, novamente, assumindo que já foram declaradas as
principais bases necessárias para a execução do documento NCL, então o autor do do-
cumento - após feitas as declarações dos principais elementos NCL - pode escrever um
relacionamento causal, conforme apresentado na Figura 5.14.
Figura 5.14. Exemplo de sincronisco sem interatividade com uso de interface
O link apresentado na Figura 5.14 informa que, quando o componente videoPrin-

cipal começar, no momento 1 - aos 23 segundos, conforme Tabela 2 - então o componente
imagem2 que contém uma mídia de imagem (equivalente à união das mídias de texto e
mídia que representa o botão de interatividade) deve ser apresentado conforme as suas
especificações temporais (de início e fim) contidas na interface chamada de momento1.
5.4. Considerações finais

Há uma relação clara entre o conceito de nativos digitais, que se refere às pessoas que
nascem nessa geração onde há ampla disponibilidade e diversidade tecnologias, e os con-
teúdos multimídia e hipermídia que são atualmente consumidos via TV ou em diferentes
canais virtuais, através da internet, sendo a utilização da linguagem audiovisual uma das
principais características observadas na produção das informações produzidas e veicula-
das.
O público alvo desta proposta são principalmente discentes e docentes. Os discen-
tes (considerados como nativos digitais), por se tratarem de um público que se apropria
de diferentes recursos digitais com muita naturalidade e cujo comportamento diante de
conteúdos e mecanismo tradicionais de ensino sugere a utilização de novas estratégias.
716
Porém a estratégia adotada na realização deste minicurso se baseia no uso de fer-

ramentas que são de fácil aprendizagem e utilização, possibilitando que qualquer pessoa
considerada imigrante digital também se aproprie do mesmo conhecimento. Portanto,
docentes, educadores, arte-educadores e curiosos em geral são convidados a participarem
também dessa proposta.
Nesse sentido, a produção de OABVI se apresenta como uma alternativa capaz
de dialogar entre esses diferentes grupos, ratificando, assim, a importância da realização
desta proposta, que pode gerar novos OABVIs produzidos pelos próprios participantes .
Referências
[Azevedo 2008] Azevedo, R. G. A. (2008). NCL Eclipse: editor textual para desenvolvi-
mento de programas Hipermídia interativos em NCL. 2008,(Monografia apresentada
como requisito parcial para obtenção do título de Bacharel em Ciência da Computa-
ção).
[Azevedo 2009] Azevedo, R. G. A., T. M. M. S. C. S. N. (2009). Ncl eclipse: Am-

biente integrado para o desenvolvimento de aplicações interativas em nested context
language. In Salão de Ferramentas do Simpósio Brasileiro de Redes de Computadores
(SBRC). SBRC.
[Busson 2016] Busson, A. J. G., D. A. L. D. B. L. T. D. S. S. N. (2016). A hypermedia

authoring language for temporal synchronism of learning objects. In ACM, editor,
AProceedings of the 22nd Brazilian Symposium on Multimedia and the Web, pages
175–182. Publishing Press.
[Damasceno 2014] Damasceno, André Luiz de B., T. d. S. L. C. d. S. S. N. (2014). Ca-

curiá: Uma ferramenta de autoria multimídia para objetos de aprendizagem. In IAnais
dos Workshops do Congresso Brasileiro de Informática na Educação. Vol. 3. No. 1.
Workshops do Congresso Brasileiro de Informática na Educação.
[Edwin 2012] Edwin, M; Carlos, M. J. J. T. C. R. J. J. V. M. e. o. I. T. (2012). Multi-

platform learning system based on interactive digital television technologies, idtv. In
IEEE, editor, , I. T. Multiplatform learning system based on interactive digital televi-
sion technologies, IDTV. In: Informatica (CLEI), pages 1–10. XXXVIII Conferencia
Latinoamericana.
[Peres 2011] Peres, M. A. C. (2011). Velhice e analfabetismo, uma relação paradoxal: a

exclusão educacional em contextos rurais da região nordeste. In Sociedade e Estado.
2011, pages 631–62.
[Soares 2009] Soares, L. F. G. (2009). Programando em NCL 3.0 Desenvolvimento de

Aplicações para o Middleware Ginga. Campus, 2 edition.
[Soares 2010] Soares, Luiz F.; MORENO, M. S. N. C. M. M. (2010). Ginga-ncl: Decla-

rative middleware for multimedia iptv services. In IEEE, editor, IIEEE Communicati-
ons Magazine. Vol.48, No.6. June 2010. J.
717
[Sobrinho 2017] Sobrinho, M. E. (2017). Implementação e Avaliação de um Jogo Edu-

cativo para o Ensino de Geometria para alunos do 9o Ano do Ensino Fundamental.
[Vieira 2016] Vieira, A. de S., G. R. J. D. A. S. C. N. (2016). Utilização de modelos

mentais para representação de estruturas cognitivas de aplicativos tvdi. In ,XXVII Sim-
pósio Brasileiro de Informática na Educação. 2016, pages 736–746. XXVII Simpósio
Brasileiro de Informática na Educação.
718
Chapter
6
Uma Introdução ao Go: A Linguagem Performática
do Google
Diego F. Sousa, Leonardo A. G. Silva
Abstract
Over time, software development has been improving and the tools used for its composi-
tion evolve according to the needs that the technology tends to solve. We can then define
Programming Languages as the main artifact of this medium because it is the intermedi-
ate where the computer processes information in order to generate outputs for beneficial
use. In this scenario, the Go programming language has become a viable alternative for
the development of applications focused on high performance without losing readability
and simplicity. The sections in this chapter introduce language to its concepts and aspects
of greater relevance.
Resumo
Ao longo do tempo, o desenvolvimento de software foi se aprimorando e as ferramentas

utilizadas para sua composição evoluindo de acordo com as necessidades que a tecnolo-
gia tende a resolver. Podemos então definir as Linguagens de Programação como o prin-
cipal artefato deste meio por ser o intermédio onde computador processa informações
a fim de gerar saídas para o uso benéfico. Neste panorama, a linguagem de programa-
ção Go tem se tornado uma alternativa viável para o desenvolvimento de aplicações com
foco em alta performance sem perder legibilidade e simplicidade. As seções deste capí-
tulo introduzem a linguagem quanto aos seus conceitos e aspectos de maior relevância.
6.1. Introdução
O ato de criar um novo software pode requerer paciência, atenção e proatividade por parte
do desenvolvedor e, devido à isso, as Linguagens de Programação estão sempre se reno-
vando e buscando a maior proximidade com o programador tornando-se mais portáveis.
719
O maior exemplo disso são as linguagens rotuladas como de alto nível, das quais podemos
citar Python, PHP, Ruby, C++, Java, entre outras.
As linguagens de alto nível tem como característica principal o poder elevado de
abstração aproximando sua sintaxe à linguagem humana, diferentemente das linguagens
de baixo nível, que por sua vez se assemelham ao código utilizado por máquina [6].
Golang – como também é abreviada – fica entre as linguagens de alto nível, assim como
colabora para facilitar o desenvolvimento sem perder o alto desempenho [3].
As próximas seções deste capítulo detalham a linguagem desde seus conceitos
principais, passando pela instalação, preparação do ambiente e sintaxe básica. Alguns
elementos exclusivos da linguagem serão apresentados com devido foco ao decorrer das
seções.
6.1.1. Um pouco sobre Go

O problema do longo tempo de processamento recorrente em boa parte das Linguagens
de Programação atuais foi um dos principais motivos para a criação de Golang [4]. Os
grandes servidores da Google necessitavam de um grande poder de eficiência e produ-
tividade para tornar aplicações escaláveis e mais rápidas. Assim sendo, em novembro de
2009 deu-se inicio a linguagem Go dentro das dependências dos escritórios da Google.
Seu projeto de criação foi liderado por Rob Pike, Ken Thompson e Robert Griessemer
[5].
Uma das principais vantagens da linguagem está no poder de processamento que
permite aplicações trabalharem aproveitando o máximo do poder dos processadores multi-
core de forma mais otimizada [7]. Tal poder de processamento é oriundo das goroutines,
que são rotinas que se comunicam por channels, evitando, tanto o uso de memória com-
partilhada, como técnicas de sincronizações mais pesadas tal como "semáforos".
O Go, embora seja recente, dá suporte a várias bibliotecas para a criação de ferra-
mentas de comunicação em rede, servidores HTTP, expressões regulares e leitura/escrita
de arquivos. Por ser robusta exige um certo nível de atenção na sua codificação, caracterís-
tica que permite os desenvolvedores produzirem códigos mais limpos e padronizados [2].
No mercado atual Go já possui seu espaço, principalmente como uma possível sucessora
da linguagem C por suportar a demanda de trabalho em servidores e sistemas multi-thread
[1].
6.1.2. Go atualmente
Devido seu diferencial, Golang está em plena ascenção. O reflexo de seu crescimento é
representado pela sua utilização nos dias atuais, tanto por empresas internacionais como
nacionais. Além da própria Google, outras companhias usam Go em suas infraestruturas,
estando entre elas: Adobe, BBC, Canonical, Dell, DigitalOcean, Dropbox, Facebook,
IBM, Mozilla, SoundCloud, Twitter, Yahoo, entre outras.
No Brasil não é diferente, muitas companhias estão aderindo ao Go. Entre as
empresas e instituições com maior respaldo estão: Globo.com, Magazine Luiza, Mercado
Livre, Dafiti, PagSeguro, Pagar.me, Jusbrasil, Hotel Urbano, Walmart, Nuveo, Nic.br,
entre outras. A lista completa de companhias que usam Go pelo mundo está no repositório
720
oficial da linguagem no GitHub1 .
6.2. Instalando e configurando o Go

Para começar a programar na linguagem Go, além de ser necessário que seja feito o
download e instalação, é fundamental preparar do ambiente consistindo em modificar
algumas de suas variáveis. Devem ser adicionadas três novas variáveis ao sistema. Todos
os projetos criados em Go devem estar na pasta apontada pelo GOPATH2 . As subseções
abaixo apresentam o passo a passo para instalação em sistemas Linux e Windows.
6.2.1. Linux
Para efetuar a instalação no ambiente Linux, basta ir até o site oficial da linguagem na
seção de downloads3 e escolher a opção Linux. Após fazer o download, navegue pelo ter-
minal até a pasta onde está o arquivo compactado e descompacte-o com o comando sudo
tar -zxvf "nome_do_arquivo".tar.gz. Com a extração concluída, mova o
arquivo para o diretório /usr/local com o comando sudo mv go /usr/local.
Agora edite o arquivo /etc/profile adicionando as variáveis de ambiente
para o Go:
export GOPATH=$HOME/GO
export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
É necessário criar uma pasta dentro do diretório $HOME4 com o nome "GO" de
acordo com a variável de ambiente descrita em GOPATH e executar o comando source
/etc/profile para finalizar a instalação. O próximo passo é estender a pasta $GOPATH
criando as pastas pkg, bin e src. Preferencialmente crie seus programas dentro do di-
retório $GOPATH/src.
Por último, verifique a instalação executando o comando go version. O re-
torno deve ser algo como:
go version go1.8.3 linux/amd64
6.2.2. Windows
Para o Windows, o download do Go pode ser feito através do mesmo link3 . Selecione a
opção Windows e faça o download. No ato da instalação é importante que os arquivos se-
jam inseridos no diretório C:\Go. Feita a instalação, é necessário configurar as variáveis
de ambiente. No Windows é possível encontrá-la em dois lugares:
• "Painel de Controle" → "Sistema" → "Avançado" → "Variáveis de ambiente";
• "Configurações avançadas do sistema" → "Variáveis de ambiente".

1 https://github.com/golang/go/wiki/GoUsers
2 Diretório configurado para o desenvolvimento de aplicações em Go na máquina do usuário.
3 https://golang.org/dl/
4 Para descobrir onde fica o diretório $HOME execute o comando echo $HOME no terminal.
721
Na maioria dos casos a variável GOROOT já está automaticamente adicionada.

Caso contrário você deve adicioná-la apontando-a para o diretório C:\Go. Crie uma
pasta contendo as pastas bin, pkg e src para ser seu diretório de trabalho e adicione mais
duas variáveis: PATH para o caminho C:\Go\bin e a varíavel GOPATH direcionada
para seu diretório de trabalho.
Desenvolva seus programas sempre dentro da pasta $GOPATH/src. Por último
visualize sua instalação usando go version no Prompt de Comando ou CMD. A saída
deve ser essa:
go version go1.8.3 windows/amd64
6.3. Estrutura básica e sintaxe

Após a instalação e configuração já podemos criar nossos primeiros programas. Nesta
seção serão apresentados elementos que constituem a sintaxe básica de Go. Programas
em Go podem ser desenvolvidos em qualquer editor de texto que dê suporte a codificação
UTF-8. Todos os exemplos mostrados nas próximas seções tem foco na execução em
ambiente Linux.
6.3.1. Hello World

Para o primeiro contato com a linguagem, podemos iniciar com um tradicional Hello,
World. Portanto, salve um arquivo com título de sua preferência – sugerimos hello.go
– dentro da pasta src do diretório apontado pelo $GOPATH com o seguinte conteúdo:
1 package main
2
3 import "fmt"
4
5 func main() {
6 fmt.Println("Hello World!")
7 }
Para compilar o código acima, basta executar go run hello.go. A saída para
este programa será:
Hello World
Neste primeiro exemplo pode-se notar algumas caraterísticas da linguagem. A
primeira delas é que Go não possui ponto-e-vírgula ou quaisquer ponto e acentuações ao
final das instruções, diferentemente de linguagens como C ou Java. Outra característica é
que todo código em Go é dividido em três seções principais:
1. Declaração do pacote: Todo arquivo Go deve existir dentro de um pacote. Se o

pacote for o ponto de partida do projeto, deve ser chamado de main e deve conter a
função main – func main() –. A declaração do pacote deve estar no início do
código;
2. Declaração de dependências: A segunda seção é destinada as dependências de um
programa em Go, podendo elas serem opcionais. No nosso exemplo, usamos o fmt
722
para auxiliar na entrada e saída de dados pelo terminal;
3. Código: Por último, temos o código de fato. Nele é onde aplicamos a lógica e é a
parte central de um programa em Go.
A função main de um programa em Go não recebe parâmetros e nem retorna

valores, mais uma característica que a difere de linguagens como o Java ou C. Para
comando de entrada e saída podemos usar as funções provenientes do pacote fmt. O
fmt.Println() imprime o conteúdo seguido de quebra de linha, enquanto que fmt.P
rint() imprime apenas o conteúdo. Abordamos isso melhor na seção 6.3.2.1.
6.3.2. Variáveis
Go tem tipagem forte e estática, isso quer dizer que o tipo das variáveis declaradas du-
rante a execução de um programa não podem ser alterados. Apesar deste conjunto de
características, Go traz em sua sintaxe uma forma de declaração limpa, o que facilita e
torna rapido o desenvolvimento das aplicações. A declaração de variáveis em Go pode
ser feita de quatro maneiras principais, como apresenta o código abaixo:
1 package main
2
3 import "fmt"
4
5 func main() {
6 var variavel_a int // tipo 1
7 variavel_b := 5 // tipo 2
8
9 var variavel_c int = 45 // tipo 3
10 var x, y int = 1, 2 //tipo 4
11 }
O tipo 1 é usado quando não se sabe qual valor será alocado para a variável, en-
quanto o tipo 2 é uma maneira mais sucinta exclusiva do Go que força o tipo da variável
de acordo com o valor recebido (note que o tipo não foi declarado). É importante con-
siderar que o compilador só obtem sucesso em sua execução quando todas as variáveis
instanciadas são devidamente usadas. Outros tipos de declaração são os tipos 3 e 4. Entre
os tipos de variáveis suportados por Go estão bool, int (8, 16, 32, 64), float (32, 64),
string, byte, rune e complex (64, 128).
6.3.2.1. Entrada e saída com fmt
Com o pacote fmt é possível interagir com o usuário em modo texto no estilo input/out-
put. As funções principais de fmt tem por finalidade a entrada e saída de valores. O
código abaixo mostra as funções de saídas mais comuns:
1 package main
2
3 import "fmt"
723
4
5 func main() {
6 str := "Gopher"
7
8 fmt.Print("Ola ", str, "\n")
9 fmt.Println("Ola", str)
10 fmt.Printf("Ola %s\n", str)
11 }
As variações da função de impressão acima exibem a mesma saída:

Ola Gopher
Ola Gopher
Ola Gopher
Para receber uma entrada de valor, o pacote fmt nos disponibiliza a funcão Scan().
A leitura de um valor para uma variável é estabelecido colocando a variável precedida do
caractere & entre os parênteses de Scan(). Como exemplo temos:
1 var variavel string
2 fmt.Scan(&variavel)
6.3.3. Estrutura de seleção if/else

A estrutura de seleção if/else tem a função básica de tomar decisões perante a execução de
um programa. Em Go este tipo de estrutura difere em relação a outras linguagens, ela só
recebe valores lógicos verdadeiro ou falso. Isso influencia definitivamente a tipagem da
variável que o comando vai receber, ou seja, as expressões necessitam ser do tipo bool.
O código abaixo representa um modelo de uso do if/else:
1 idade := 22
2
3 if idade <= 18 {
4 fmt.Println("Menor ou igual a 18 anos")
5 } else if idade > 25 {
6 fmt.Println("Maior que 20 anos")
7 } else {
8 fmt.Println("Entre 19 e 25 anos")
9 }
6.3.4. Switch case

A estrutura switch case tem funcionalidade parecida com o if/else visto na subseção ante-
rior. Dependendo do caso, o switch case pode se adequar melhor ao programa, especial-
mente em casos de Menus e estruturas de decisões com muitas opções. O switch case é
orientado a casos tendo o default como caso escolhido quando nenhum dos outros forem
satisfeitos. A sintaxe do switch case segue o seguinte modelo:
1 t := time.Now()
724
2
3 switch {
4 case t.Hour() < 12:
5 fmt.Println("Bom dia!")
6 case t.Hour() < 17:
7 fmt.Println("Boa tarde.")
8 default:
9 fmt.Println("Boa noite.")
10 }
6.4. Coleções de dados

As coleções de dados são tipos de variáveis especiais que podem serem entendidas como
um conjunto ou listas de outras variáveis ou valores. Assim como em outras linguagens
– como a linguagem C com seus vetores – as coleções de dados são geralmente uma
sequencia de valores encadeados em ordem predefinida ou até mesmo apenas espaços
separados não alocados para que depois venham ser preenchidos.
Em Go os padrões para listas de dados são dois: arrays e slices. A grande difer-
ença entre eles está relacionada ao espaço de alocação de mémoria. Os arrays são instâ-
cias com tamanho fixo, já os slices são uma camada abstraída dos arrays que podem ser
alocados dinamicamente permitindo crescer de forma indefinida sendo mais flexíveis.
6.4.1. Arrays
Os Arrays são listas com valores do mesmo tipo, sendo que cada valor possui um índice
que indica a posição dentro da lista. A contagem dos índices são delimitados pelo tamanho
do array que deve ser fixo e invariável. O primeiro elemento do array possui índice 0,
e o último elemento é sempre len(array) - 1. Podemos declarar um array em Go
utilizando as seguintes formas:
1 var lista [3]int
2 pares := [3]int{2,4,6}
3 impares := [...]int{3, 5, 7}
4 nomes := [2]string{}
5
6 fmt.Println(colecao, pares, impares, nomes)
A saída para o código acima é: [0 0 0] [2 4 6] [3 5 7] [ ].

O tamanho de um array sempre deve ser especificado na sua declaração, como por
exemplo o array lista que foi fixado em [3]int, ou seja , seu tamanho é de 3 posições
inteiras. Podemos notar que para ele a saida foi [0 0 0], isso ocorre por que em Go
quando se é declarado um array sem valores definidos, estes assumem automaticamente
valor zero. Para vetores de outra tipagem esse valor atribuído automaticamente pode ser
gerado com outras representações:
• bool: false, valor booleano falso;

• int: 0;
725
• float: 0.0;
• strings: "";
• ponteiros, funções, interfaces, slices, maps e channels: nil.
Existe também a possibilidade de criar arrays multidimensionais em que os val-

ores são arrays dentro de arrays. Declaramos eles da seguinte forma:
1 var matrizA [2][2]int
2
3 matrizA[0][0], matrizA[0][1] = 7, 2
4 matrizA[1][0], matrizA[1][1] = 100, 90
5
6 matrizB := [2][2]int{{3, 2}, {-80, -1}}
7
8 fmt.Println("Matriz A:", matrizA)
9 fmt.Println("Matriz B:", matrizB)
A saída para o código acima é:

Matriz A: [[7 2] [100 90]]
Matriz B: [[3 2] [-80 -1]]
Como já foi mencionado, os arrays não são tão flexíveis como os slices – ex-
plicados na próxima subseção –, porém eles em sua importância dentro da linguagem Go.
Cabe ressaltar que é possível trabalhar com arrays de forma que eles sejam dinâmicos,
porém requer um esforço manual custoso demais tendo que verificar seus limites e criação
de arrays para cópias de valores, o que possivelmente deixará o código mais poluído.
6.4.2. Slices
Os slices são uma abstração que se baseiam em arrays para possibilitar mais flexibilidade
na coleção de dados encadeados. A principal característica de um slice é a ausência de
limites permitindo maior dinamicidade para a coleção de dados. Para declarar uma slice
podemos utilizar quase a mesma sintaxe de um array. A diferença é que não especifi-
camos seu tamanho:
1 var sliceA []int
2 sliceB := []int{10, 20, 30}
3 SliceC := []string{}
4
5 fmt.Println(sliceA, sliceB, sliceC)
A saída para o código acima é: [] [2 4 6] []

É possível também criar um slice com a função make(), que separa internamente
um espaço de memória para um array retornando uma referência para o slice. Sua sintaxe
pode ser escrita da seguinte forma:
1 lista := make([]int, 10)
726
2 lista2 := make([]int, 10, 30)

3
4 fmt.Println(lista, len(lista), cap(lista))
5 fmt.Println(lista2, len(lista2),cap(lista2))
A saída deste código é:

[0 0 0 0 0 0 0 0 0 0] 10 10
[0 0 0 0 0 0 0 0 0 0] 10 30
O primeiro parâmetro da função make() indica o tipo dos elementos que irão ser
criados, o segundo representa o tamanho inicial e o terceiro define a capacidade total de
memória reservada. No slice definido em lista é possível analisar que o tamanho inicial
e capacidade total são os mesmos pelo fato do limite não ter sido definido, enquanto que
em lista2, a capacidade é definida para um total de 30 posições.
6.4.3. Maps
Os maps são uma estrutura de conjunto de dados organizado em chave-valor. Em outras
linguagens como Ruby e Python, os maps se assemelham aos Dict’s e Hashes respecti-
vamente. Podemos declarar um map em Go usando a forma de declaração simples ou
usando a função make(), assim como nos exemplos usados para os slices. No exemplo
a seguir temos declarados maps com chaves do tipo int e valores strings.
1 map1 := map[int]string{}
2 map2 := make(map[int]string)
Automaticamente os maps tem tamanho indefinido. Porém é possível alocar a

quantidade de espaços necessários possíveis durante a execução do programa tornando
mais eficiente e fácil de se trabalhar com dados diferentes sem a necessidade de saber
tamanhos predefinidos. Recomenda-se sempre definir uma especificação de memória pas-
sando um segundo argumento à função make():
1 map3 := make(map[int]string, 2066)
As formas literais de inserir dados em um map seguem a seguinte abordagem:

1 timesDoPiaui := map[string]string{
2 "RIV": "River",
3 "PAR": "Parnahyba Sport Club",
4 "PEC": "Sociedade Esportiva de Picos",
5 }
6 timesDoPiaui["PEC"] = "Piaui Esporte Clube"
7
8 fmt.Println(timesDoPiaui)
O resultado do código acima é:

map[SEP:Sociedade Esportiva de Picos PEC:Piaui Esporte Clube
RIV:River PAR:Parnahyba Sport Club]
Podemos notar que na primeira indicação da chave "PEC" o valor especificado
727
foi Sociedade Esportiva de Picos, e logo após foi escrito o seguinte código:
timesDoPiaui["PEC"] = "Piaui Esporte Clube", ele permite que os val-
ores sejam atualizados diretamente no em uma chave especifica de um map. Logo após a
saída o valor que antes era Sociedade Esportiva Picos foi trocado por "Piaui
Esporte Clube".
6.4.4. Loops
A estrutura básica de repetição em Go é o comando for. Ele é comumente usado para fazer
iterações com listas, slice, maps e outros objetos iteráveis. Em sua forma mais comum
é especificado uma condição lógica e o bloco código se repetirá até que a condição seja
satisfeita com verdadeiro:
1 valor1, valor2 := 0, 20
2
3 for valor1 < valor2 {
4 valor1 += 1
5 }
O código acima será repetido em 20 iterações, ou seja, a variável valor1 que re-
cebe 0 na primeira linha será incrementado com mais um até que ele satisfaça a condição
for do valor1 ser menor que o valor2. Há a possibilidade de fazer iterações da forma
mais tradicional:
1 for i := 0; i < 10; i++ {
2 ...
3 }
O código acima também executa qualquer bloco de código até que a condição
de verdadeiro seja satisfeita, então o comando fará 10 iterações. Outra forma de fazer
uma iteração com for sobre determinado objeto iterável é constituída com o auxilio do
comando range:
1 for indice, valor := range slice {
2 ...
3 }
No código acima é retornado o índice de cada elemento do slice. Para obter acesso
e modificar valores desse slice podemos utilizar os índices. Dessa forma, basta omitir o
segundo valor na atribuição e acessar cada elemento através de seu índice:
1 numeros := []int{1, 2, 3, 4, 5}
2
3 for i := range numeros {
4 numeros[i] *= 2
5 }
6
7 fmt.Println(numeros)
A saída do código acima é: [2 4 6 8 10].
728
Como último exemplo, podemos usar o laço for como um loop infinito como o
while em outras linguagens:
1 for {
2 ...
3 }
Para a parada do loop basta instanciar algum comando de seleção como o if com break
interno.
6.5. Funções
Um dos pontos fortes da linguagem Go é a variedade de formas em que podemos es-
crever funções. Go permite que suas funções possam receber parâmetros, assim como
também retornar valores podendo ser múltiplos. Até este momento neste capítulo us-
amos funções, pois a rotina de um código em Go deve iniciar da função main(). Nas
subseções seguintes detalhamos alguns dos tipos de funções mais usados.
6.5.1. Funções básicas

Em Go o padrão básico de declaração das funções se dá com a palavra func seguido do
nome da função e dos possíveis valores de parâmetros. Um exemplo seria uma função
que imprima uma simples frase:
1 func imprimirString() {
2 fmt.Println("Imprimindo uma frase")
3 }
Agora iremos passar alguns argumentos para esta função, fazendo que ela imprima
um valor do tipo string e outro do tipo int:
1 func imprimirString(nome string, idade int) {
2 fmt.Printf("Ola, meu nome eh %s e eu tenho %d anos.\n",
3 nome, idade)
4 }
Caso os argumentos passados para a função sejam do mesmo tipo, é possível

agrupá-los em uma única especificação:
1 func intervalo(x, y int) {
2 for i := x; i < y; i++ {
3 fmt.Printf("%d ", i)
4 }
5 }
Para retornar valores em uma função é necessário definir seu tipo logo após a
passagem de parâmetros. Além disso, também é necessário fazer o uso do return:
1 func simplesSoma(x, y int) int {
2 return x + y
3 }
729
O retorno de funções em Go também podem retornar vários valores. Para que isso
seja possível devemos adicionar os tipos retornados na sequencia correta entre parênteses.
O return também deve estar de acordo:
1 func sucessorEAntecessor(x int) (int, int) {
2 return x + 1, x - 1
3 }
6.5.2. Retorno definido

Em Go é possível definir a variável de retorno de uma função logo na declaração. Para
que isso seja possível devemos usar a mesma variável de retorno definida para receber um
valor dentro da função e ainda usar o return sem especificar valores:
1 func simplesSoma(x, y int) (soma int) {
2 soma = x + y
3 return
4 }
6.5.3. Funções de argumentos variáveis

As funções de argumentos variáveis recebem como argumento um determinado tipo e
uma variável especificada. A ideia é permitir que sejam passados n argumentos para este
tipo de função para que trate esses valores como uma lista. Podemos assim iterá-los como
um array:
1 func numeros(lista ...int) {
2 for _, numero := range lista {
3 fmt.Println(numero)
4 }
5 }
6.5.4. Funções anônimas

Funções anônimas são funções que são criadas no momento em que são utilizadas. Elas
são alocadas para uma variável e são usadas com frequência quando se quer resolver
pequenos problemas. Por exemplo, podemos declarar uma função anônima para deixar
todas as letras de uma string em maiúsculo. Para o próximo código importamos o pacote
strings. Veja o exemplo:
1 func main() {
2 maiusculo := func(str string) string {
3 return strings.ToUpper(str)
4 }
5
6 nome := "Diego Fernando"
7
8 fmt.Println(nome)
9 fmt.Println(maiusculo(nome))
10 }
730
A saída deste código é:

Diego Fernando
DIEGO FERNANDO
6.5.5. Defer
O defer define uma função que sempre será executada ao fim de uma rotina atual. O
comando é ideal para programas em que se usa I/O onde deve haver abertura e fechamento
de arquivos ou conexões, pois garante a execução de determinada função ao final. O
exemplo a seguir apresenta a função defer que imprime a string Segunda acao logo
após a impressão de Primeira acao:
1 func main() {
2 defer func() {
3 fmt.Println("Segunda acao")
4 }()
5
6 fmt.Println("Primeira acao")
7 }
6.6. Tipos de dados

Além dos tipos de dados tradicionais, Go permite a criação de tipos personalizados de
dados. Este tipo de característica se torna importante, uma vez que recursos relativos
a Orientação a Objetos praticamente não existem em Golang. Apesar desse ponto, Go
compensa o uso da OO com recursos como funções que se estendem de tipos e interfaces,
que estão apresentados nesta seção.
6.6.1. Criando novos tipos

Para criar um novo tipo de dado basta acrescentar type antes de qualquer tipo primitivo.
Com a finalidade de ilustrar a criação de um novo tipo de dado, no código abaixo é
declarado o tipo de dado TimesDoPiaui baseado em um slice do tipo primitivo string.
Note que, tanto a instância, como a recepção dos valores são feitos de fato dentro da
função main().
1 package main
2
3 import "fmt"
4
5 type TimesDoPiaui []string
6
7 func main() {
8 times := make(TimesDoPiaui, 4)
9 times[0] = "River"
10 times[1] = "Parnahyba Sport Club"
11 times[2] = "Sociedade Esportiva de Picos"
12 times[3] = "Piaui Esporte Clube"
731
13
14 for i := 0; i < len(times); i++ {
15 fmt.Println(times[i])
16 }
17 }
Á primeira vista, esta estrutura pode não fazer muito sentido. Porém a grande
vantagem em usar tipos customizados é a possibilidade de estendê-lo. Usaremos como
exemplo uma função que mostre se o time "Parnahyba Sport Club" está no slice. Observe
que não passamos nenhum parâmetro, porém o Go entende que esta função é do tipo
TimesDoPiaui e a trata como um "método" para este tipo.
1 func (time TimesDoPiaui) TemPhb() {
2 for _, value := range time {
3 if value == "Parnahyba Sport Club" {
4 fmt.Println("Tem Parnahyba Sport Club!")
5 }
6 }
7 }
6.6.2. Structs
As structs ou tipos estruturados de dados seguem um princípio de criar tipos a partir
de conjuntos de outros tipos. É uma abstração muito utilizada em linguagens como C
e C++. Structs facilitam o agrupamento de dados criando a noção de registros. Com
fim de demonstrar um exemplo de struct, usaremos o mesmo tema da seção anterior
onde será um tipo estruturado de nome TimeDoPiaui onde teremos o atributos nome,
n_vitorias, n_derrotas e classificado.
1 package main
2
3 import "fmt"
4
5 type TimeDoPiaui struct {
6 nome string
7 n_vitorias int
8 n_derrotas int
9 classificado bool
10 }
11
12 func main() {
13 river := TimeDoPiaui{
14 nome: "River",
15 n_vitorias: 23,
16 n_derrotas: 6,
17 classificado: true,
18 }
19
732
20 fmt.Println(river)
21 }
A saída do código acima é: River 23 6 true. Podemos fazer uma função

que estende do tipo TimeDoPiaui e que imprima dados relativos ao time. Isso trará
mais possibilidades de reúso de código. Considerando a struct criada, instanciamos mais
outro time e criamos a função MostraSituação():
1 func main() {
2 river := TimeDoPiaui{
3 nome: "River",
4 n_vitorias: 23,
5 n_derrotas: 7,
6 classificado: true,
7 }
8
9 picos := TimeDoPiaui{
10 nome: "SEP",
11 n_vitorias: 18,
12 n_derrotas: 12,
13 classificado: false,
14 }
15
16 river.MostraSituacao()
17 picos.MostraSituacao()
18 }
19
20 func (t TimeDoPiaui) MostraSituacao() {
21 situacao := "nao esta"
22 if t.classificado {
23 situacao = "esta"
24 }
25
26 fmt.Printf("%s tem %d vitorias,"+
27 " %d derrotas e %s "+
28 "classificado.\n", t.nome,
29 t.n_vitorias,
30 t.n_derrotas,
31 situacao)
32 }
O resultado desta estrutura é:

River tem 23 vitórias, 7 derrotas e está classificado.
SEP tem 18 vitórias, 12 derrotas e não está classificado.
733
6.6.2.1. Manipulação de tipos de dados
Vimos na subseção anterior que podemos criar estruturas e interagir com elas por meio
de funções. Porém, a função MostraSituação() apenas faz uma exibição de val-
ores. Nesta seção evoluiremos a estrutura da seção anterior criando um slice para o tipo
TimeDoPiaui com as funções AdicionarTime(), RetirarTime() e Mostrar
Times().
É válido ressaltar que, assim como nas linguagens C e C++, Go usa ponteiros.
Em tipos estruturados, os ponteiros são necessários caso quisermos alterar elementos
de estruturas. Portanto para o exemplo projetado usaremos ponteiros nas funções de
AdicionarTime() e RetirarTime(), deste modo poderemos modificar a lista de
objetos.
Na mesma seção do código em que se encontra o type TimeDoPiaui struct,
incluiremos outro tipo que será um slice. Algo como:
1 type TimeDoPiaui struct {
2 nome string
3 n_vitorias int
4 n_derrotas int
5 classificado bool
6 }
7
8 type Times []TimeDoPiaui
Como a manipulação é feita no tipo Times, então as funções são estendidas neste
tipo. Na funções de adição e remoção usamos o comando append() para fazer recri-
ações modificadas do slice original. As funções ficam organizada deste modo:
1 func (t *Times) AdiconarTime(nome string,
2 n_vitorias int,
3 n_derrotas int,
4 classificado bool) {
5 novoTime := TimeDoPiaui{
6 nome,
7 n_vitorias,
8 n_derrotas,
9 classificado,
10 }
11
12 *t = append(*t, novoTime)
13 fmt.Printf("\n%s adicionado!", nome)
14 }
15
16 func (t *Times) RetirarTime(indice int) {
17 times := *t
18 time_retirado := times[indice]
19 *t = append(times[0:indice], times[indice+1:]...)
734
20 fmt.Printf("\n%s removido!", time_retirado.nome)

21 }
22
23 func (t Times) MostrarTimes() {
24 fmt.Println("\n\n**Times:**")
25 for i := 0; i < len(t); i++ {
26 fmt.Printf("%s, %d, %d, %t\n", t[i].nome,
27 t[i].n_vitorias,
28 t[i].n_derrotas,
29 t[i].classificado)
30 }
31 }
Com essa estrutura, podemos deixar a função main() mais limpa, assim deixando
apenas chamadas de funções nela, veja um exemplo:
1 func main() {
2 times := Times{}
3 times.AdiconarTime("River", 23, 7, true)
4 times.AdiconarTime("Parnahyba Sport Club", 25, 5, true)
5 times.AdiconarTime("SEP", 20, 10, false)
6 times.MostrarTimes()
7 times.RetirarTime(0)
8 times.MostrarTimes()
9 }
A saída do código criado seria algo como:

River adicionado!
Parnahyba Sport Club adicionado!
SEP adicionado!
**Times:**
River, 23, 7, true
Parnahyba Sport Club, 25, 5, true
SEP, 20, 10, false
River removido!
**Times:**
Parnahyba Sport Club, 25, 5, true
SEP, 20, 10, false
735
6.6.2.2. Interfaces
A melhor definição para interfaces é que elas são um "contrato" para outros tipos de
dados. Com interfaces é possível criar conjuntos de métodos que servem para n tipos
estruturados, pois ele consegue orientar uma mesma ação para tipos diferentes de dados,
mesmo que permitindo que o tipo possa ser direcionado a um método apropriado.
Vamos a um exemplo hipotético imaginando duas structs: TimeFutebol e
TimeBasquete. Apesar de serem tipos diferentes, as duas tem métodos estendidos
com a mesma finalidade que serve para fazer o calculo de pontos do time em determinado
campeonato baseado na quantidade de vitórias. Definimos regras de negócios diferentes
para basquete e futebol, onde, para o basquete cada vitória vale 2 pontos e para o futebol
cada vitória vale 3:
1 type TimeFutebol struct {
2 n_vitorias int
3 }
4
5 type TimeBasquete struct {
6 n_vitorias int
7 }
8
9 func (t TimeFutebol) PontosEmVitorias() int {
10 return t.n_vitorias * 3
11 }
12
13 func (b TimeBasquete) PontosEmVitorias() int {
14 return b.n_vitorias * 2
15 }
Após declarados os tipos estruturados, iremos escrever mais um tipo interface e

um método estendido do tipo interface recém criado:
1 type Time interface {
2 PontosEmVitorias() int
3 }
4
5 func Pontos(t Time) int {
6 return t.PontosEmVitorias()
7 }
A função Pontos() recebe como parâmetro uma interface podendo ser um tipo
TimeFutebol ou TimeBasquete. Já o retorno da função Pontos() é a chamada
do método PontosEmVitorias() em que foram feitas uma implementação para cada
tipo. Dependendo do tipo recebido a função Pontos() irá direcionar a chamada para o
método PontosEmVitorias() adequado.
A mágica acontece quando usamos o mesmo método para os dois tipos. Vejamos
como fica a função main():
736
1 func main() {
2 time_futebol := TimeFutebol{20}
3 time_basquete := TimeBasquete{20}
4
5 fmt.Println(Pontos(time_futebol))
6 fmt.Println(Pontos(time_basquete))
7 }
Nas instâncias acima, time_futebol e time_basquete tem a mesma quan-

tidade de vitórias (20), porém se executarmos essa função teremos a saída 60 40, ou seja
60 pontos para o time de futebol e 40 pontos para o time de basquete.
6.7. Tratamento de erros

O Go permite que funções retornem múltiplos valores, tal característica favorece o trata-
mento de erros. Existem divergências de opiniões com relação ao tratamento de erros em
Go, algumas delas estão ligadas a adaptação a forma que é feita. Por outro lado também
há quem diga que é uma maneira simples e elegante para tratar de exceções. Observe o
exemplo a seguir:
1 func Par(numero int) (bool, error) {

2 if numero < 0 {
3 return false, errors.New("Numero Invalido!")
4 }
5 if numero % 2 == 0 {
6 return true, nil
7 }
8 return false, nil
9 }
Podemos observar que a função leva um parâmetro int em seu escopo, ela verifica
se o número é par ou ímpar. Como retorno ela envia para a função principal (bool,
error), ou seja, um parâmetro de resposta correta ou errada se é um par ou ímpar
consecutivamente e um valor de erro de função.
Caso seja passado um número abaixo de 0 ela entrará no primeiro if e retornará
um false, err. Se for ímpar ela passará do primeiro e segundo if e retornara
false. Por último, caso entre no segundo if ela retorna true e om valor de erro
nil.
6.8. Concorrência
Todas as Linguagens de Programação tem foco em determinada resolução de problema.
Com Go não é diferente. Um dos pontos fortes da linguagem é a forma com que ela
lida com a programação concorrente. As goroutines, por exemplo, demostram que não
há dificuldade na implementação de processos independentes. As seguintes subseções
apresentam os elementos básicos da concorrência na linguagem Go.
737
6.8.1. Goroutines
As goroutines são similares as threads comuns, porém elas são gerenciadas pelo ambiente
de execução, ou seja, a linguagem decide quando elas iram ser interligadas as threads prin-
cipais do sistema. Por esse fator elas se tornam extremamente leves por ter um controle
sobre qual execução realmente é necessária estar sendo executada pelo Sistema Opera-
cional.
Para dar início a uma goroutine se utiliza uma palavra-chave go antes da chamada
da função. Isso permite que a execução do processo principal rode em parelelo a função
sem a necessidade de bloquear principal uma delas. A seguir a função sequencia()
recebe um número inteiro e imprime uma sequencia que vai do 0 até o valor passado como
argumento:
1 func sequencia(n int) {
2 for i := 0; i < n; i++ {
3 fmt.Printf("%d ", i+1)
4 time.Sleep(200 * time.Millisecond)
5 }
6 fmt.Printf(" ...Sequencia de %d terminou... ", n)
7 }
O código a seguir chama a função sequencia() instanciada duas vezes com

números diferentes:
1 func main() {
2 sequencia(5)
3 sequencia(10)
4 }
Ao executar a função main() a saida do código é:

1 2 3 4 5 ...Sequencia de 5 terminou... 1 2 3 4 5 6 7 8 9 10
...Sequencia de 10 terminou...
Agora façamos diferente, vamos usar a palavra-chave go para um das chamadas
da funções:
1 func main() {
2 go sequencia(5)
3 sequencia(10)
4 }
Logo a saida da função main() será:

1 1 2 2 3 3 4 4 5 5 6 ...Sequencia de 5 terminou... 7 8 9 10
...Sequencia de 10 terminou....
Notamos que já ocorreu uma diferença entre as saídas. A goroutine aberta para a
função imprimir foi executada em paralelo a função principal. Isso torna o programa mais
eficiente em recursos.
738
6.8.2. Waitgroups
Usando o mesmo exemplo da subseção anterior, façamos o seguinte experimento: ao
invés de acionar a goroutine levando o valor 5 como argumento, iremos então inverter
os valores das suas funções sequencia(), que agora contará com os valores 10 e 5,
respectivamente. O escopo da função main() agora é este:
1 func main() {
2 go sequencia(10)
3 sequencia(5)
4 }
Agora executando o código com os valores invertidos, temos:

1 1 2 2 3 3 4 4 5 5 ...Sequencia de 5 terminou...
Analisando a saída, percebemos que o paralelismo houve até a rotina principal ter-
minar. Isso quer dizer que não houve continuidade da goroutine da função sequencia(10).
Este comportamento acontece porque Go entende que as goroutines devem respeitar o
tempo de execução da rotina principal, ou seja, o processo main(). Para o processo
principal esperar o termino de todos os processos em paralelo, se faz necessário o uso de
waitgroups.
Modificaremos o código adequando-o para waitgroups. O primeiro passo deve ser
adicionar o pacote sync dentro das importações para utilizarmos seus módulos. Deve-
mos também instanciar uma variável global do tipo sync.WaitGroup. Faremos então
var group sync.WaitGroup. Reescreveremos a função main() com o uso de
group previamente instanciada. Fica dessa maneira:
1 func main() {
2 group.Add(1)
3 go sequencia(10)
4 sequencia(5)
5 group.Wait()
6 }
A função group.Add() especifica previamente quantos processos o programa

deve esperar para poder ser finalizado. Ao final das chamadas das funções usamos o
group.Wait(), que tem por finalidade permitir o processo principal esperar todas os
processos do grupo terminarem sua execução. Também teremos algumas modificações na
função sequencia():
1 func sequencia(n int) {
2 defer group.Done()
3 for i := 0; i < n; i++ {
4 fmt.Printf("%d ", i+1)
5 time.Sleep(200 * time.Millisecond)
6 }
7 fmt.Printf(" ...Sequencia de %d terminou... ", n)
8 }
739
Fizemos o uso do defer – explicado na seção 6.5.5 – para assegurar que a

função group.Done() seja executada ao fim da função sequencia(). Basicamente,
group.Done() tem por finalidade "avisar" o processo principal que a atual rotina ter-
minou e que o programa não precisa mais esperar por ela. Isso resolve o problema de-
scrido no início desta subseção.
6.8.3. Channels
As goroutines ultilizam de uma melhor abordagem em alta performance e eficiência no
uso de recursos de processamento. Porém a capacidade de executar diferentes goroutines
concorrentes pode ser uma situação muito complicada porque geralmente irá se fazer a
necessidade de fazer comunicações entre elas.
Os channels são responsáveis por abstrair essa comunicação. Ou seja, eles abrem
um canal para servir de ponte e conduzir as informações de qualquer tipagem em Go.
A função make() é responsável de criar um canal para trafegar os valores. Vamos ao
seguinte exemplo com um tipo int. Depois Utilizamos o operador <- – arrow operator
ou operador seta – para interagir com o cana criado. A seta permite a direção correta do
fluxo da comunicação, vamos enviar valores int para o canal ch:
1 ch := make(chan int)
2 ch <- 33
Podemos obter o valor enviado para o canal c da seguinte forma:
1 valor := <-c
A seguir está um exemplo mais completo para maior entendimento da real função
dos channels:
1 func main() {
2 ch := make(chan int)
3 go induzir(ch)
4 recebido := <-ch
5 fmt.Println(recebido)
6 }
7
8 func induzir(ch chan int) {
9 ch <- 33
10 }
Notamos que inicialmente instaciamos um canal ch que conduz informações do

tipo int e logo após passamos para esse canal um valor inteiro por meio do disparo da
goroutine induzir(). Isso bloqueia qualquer outra operação com o mesmo canal até
que a outra seja completada; permitindo uma sincronização automática entre as goroutines
sem mecanismos para travá-las. A variável recebido receberá o valor trafegado antes
pela função induzir(), que em seguida é impresso com valor 33.
740
6.9. Pacotes Go
A modularizarão do código permite ao desenvolvedor uma série de benefícios. A im-
portância de um projeto bem organizado reflete no tanto no poder de manutenção do
código, como na sua abstração. Para que esta característica se concretize, existem na
maioria das Linguagens de Programação a possibilidade da associação entre arquivos de
uma mesma pasta, ou até mesmo a criação de novos módulos. No Go esses módulos são
chamados de pacotes (packages). Abordaremos sua utilização nas seguintes subseções.
6.9.1. Criando um pacote Go

Se observarmos bem, desde o nosso primeiro exemplo – hello.go – deste capítulo, fize-
mos o uso de pacotes. Geralmente, a primeira linha de qualquer código Go contém
a declaração do pacote que representa o resto do código. Quando usamos a função
fmt.Println() também fazemos uma importação de um pacote. Neste caso importa-
mos o pacote fmt, que faz parte da biblioteca nativa do Go.
Para efetuar a criação de um pacote, primeiro devemos definir uma pasta para o
nosso projeto dentro de GOPATH/src. Com fim de exemplificar um modelo de estrutura,
criaremos um pacote chamado "meu-projeto" contendo um arquivo "main.go" e dentro do
arquivo "main.go", teremos a seguinte estrutura:
1 package main
2
3 import (
4 "fmt"
5 )
6
7 func main() {
8
9 }
Vamos agora construir nosso pacote criando outra pasta dentro de "meu-projeto".
Para este caso, a denominaremos como "operacoes". Dentro da pasta criaremos um ar-
quivo Go chamado "matematica.go" e nele vamos fazer duas funções: uma de soma de
dois números inteiros e outra para subtração desses números. O conteúdo seguirá a rep-
resentação abaixo:
1 package operacoes
2
3 func Soma(x, y int) int {
4 return x + y
5 }
6
7 func Subtracao(x, y int) int {
8 return x - y
9 }
Note que denominamos o nome do pacote logo no início com o package opera
coes. Este pacote atenderá por este nome quando for chamado externamente. As funções
741
de um pacote obrigatoriamente devem iniciar com letra maiúscula, pois esta característica
as deixam acessíveis fora do próprio arquivo. Voltaremos então para o arquivo main.go
onde já foi desenvolvida uma estrutura inicial. Agora podemos fazer a importação e a
utilização das funções do pacote recém-criado:
1 package main
2
3 import (
4 "fmt"
5 "meu-projeto/operacoes"
6 )
7
8 func main() {
9 fmt.Println(operacoes.Soma(10, 3))
10 fmt.Println(operacoes.Subtracao(10, 3))
11 }
Observe que a importação de um pacote segue o modelo da representação de um

caminho ou diretório. Desta forma, é possível importar pacotes em qualquer circunstância
desde de que criados dentro da pasta GOPATH/src.
6.9.2. Pacotes externos

Através de comandos via terminal, também é possível fazer uso de pacotes externos em
Go. O comando que executa esta ação é o go get. Para demonstrar sua aplicação, foi
criado um pacote chamado distanceToEnucomp disponível no GitHub5 . Basicamente, o
pacote criado é composto por três funções:
• Info(): Retorna uma string com a descrição do evento;
• ShortCourses(): Retorna uma array com os minicursos do evento;
• distanceTo(lat, lon): Levando como parâmetros latitude e longitude, re-

torna o cálculo da distância em linha reta para o local onde ocorreu o evento.
O comando para efetuar o download do pacote é:

go get github.com/diegofsousa/distanceToEnucomp
A importação e utilização do pacote segue o diretório onde foi instalado. O código
abaixo exemplifica o uso das funções:
1 package main
2
3 import (
4 "fmt"
5 "github.com/diegofsousa/distanceToEnucomp"
6 )
5 https://github.com/diegofsousa/distanceToEnucomp
742
7
8 func main() {
9 fmt.Println("Info do Evento:")
10 fmt.Println(distanceToEnucomp.Info())
11
12 fmt.Println("\nMinicursos do Evento:")
13 for _, value := range distanceToEnucomp.ShortCourses() {
14 fmt.Println(value)
15 }
16
17 fmt.Printf("\nA distancia ate o Evento eh de %f Km.\n",
18 distanceToEnucomp.DistanceTo(-7.079602, -41.433254))
19 }
As dependências externas podem refletir significamente no projeto. Dependendo

do caso, podem deixar o código mais enxuto. Porém, a linguagem Go é bem completa
em relação aos seus módulos nativos, o que influencia na não utilização de pacotes de
terceiros.
References
[1] CODAL. (2016) “Do You Need to Learn Google’s Programming Language?”,
https://medium.com/@gocodal/do-you-need-to-learn-googles-programming-
language-b7df74d6a06b, Outubro de 2017.
[2] Doxsey, C. “Introdução à linguagem Go: Crie programas escaláveis e confiáveis”,

Novatec Editora, 2016.
[3] Filipini, C. “Programando Em Go: CRIE APLICAÇOES COM A LINGUAGEM

DO GOOGLE”, https://books.google.com.br/books?id=fOA1vgAACAAJ, CASA
DO CODIGO.
[4] Marins, U. (2016) “Por que utilizar Go/Golang no seu backend?”,

https://tableless.com.br/por-que-utilizar-gogolang-no-seu-backend/, Outubro
de 2017.
[5] Patel, K. (2017) “Why should you learn Go?”,

https://medium.com/@kevalpatel2106/why-should-you-learn-go-f607681fad65,
Outubro de 2017.
[6] SEBESTA, Robert W. “Conceitos de linguagens de programação“. Bookman Edi-

tora, 2009.
[7] Youngman, N. (2012) “Why Go?”, https://nathany.com/why-go/, Outubro de 2017.
743
Capítulo
7
Uma Introdução à Robótica Móvel
Francisco Bruno de Sousa Rocha, Diego Porto Rocha, Ranulfo Plutarco Be-
zerra Neto, Karoline de Moura Farias e André Macedo Santana
Abstract
This short course aims to present an introduction of the main topics about Mobile Ro-
botics, focusing on the autonomous navigation of robots. Navigation is one of the major
challenges in this area and can be subdivided into five levels: Mapping Environments,
Localization, Path Generation, Trajectory Generation and Trajectory Execution. The re-
levance of this short course is to provide a greater interest in the field of Robotics as well
as to disseminate relevant concepts studied and researched by several universities, com-
panies and researchers around the world. From these concepts, the participant will learn
the main topics and studies currently carried out in the field of Autonomous Navigation
and thus will be able to study more advanced in the subject.
Resumo
Este minicurso tem como objetivo apresentar uma introdução dos principais tópicos que
permeiam a Robótica Móvel, tendo como foco a navegação autônoma de robôs. A na-
vegação é um dos grandes desafios desta área e pode ser subdividido em cinco níveis:
Mapeamento de Ambientes, Localização, Geração de Caminho, Geração de Trajetória e
Execução de Trajetória. A relevância deste minicurso é proporcionar um interesse maior
na área de Robótica bem como disseminar conceitos relevantes estudados e pesquisados
por diversas universidades, empresas e pesquisadores em todo mundo. A partir desses
conceitos, o participante aprenderá os principais tópicos e estudos realizados atualmente
no campo da Navegação Autônoma e assim estará apto a estudos mais avançados no
tema.
7.1. Introdução
A Robótica é uma área de pesquisa que trouxe diversos avanços para a sociedade, segundo
[Thrun et al. 2005] a Robótica é uma ciência que busca perceber e manipular o mundo
744
físico por meio de dispositivos mecânicos controlados por computador. Esses dispositivos
mecânicos são comumente chamados de robôs e qualquer sistema que vise este objetivo
é cunhado de sistema robótico. [Craig 2005] classifica os robôs em duas grandes classes:
robôs manipuladores e robôs móveis.
Os robôs manipuladores são comumente representados de maneira que se asseme-
lhem a braços mecânicos com muitos graus de liberdade capazes de realizar tarefas repeti-
tivas com muita velocidade e precisão no movimento. Esses robôs são um grande exemplo
de como a Robótica tem se tornado bem sucedida, isso pode ser comprovado pelo grande
investimento industrial na área, cerca de 2 bilhões de dólares [Siegwart et al. 2011]. Além
disso, é por meio desta tecnologia que a manufatura de produtos como smartphones e lap-
tops se tornou possível da maneira que ela é hoje. Apesar de todo esse sucesso, esses robôs
comerciais sofrem com um problema fundamental: a falta de mobilidade, que depende de
onde ele está fixado (Figura 7.1a).
A classe de robôs móveis é constituída por robôs que têm a capacidade de loco-
moção no espaço tridimensional (robôs aeroespaciais e subaquáticos) ou no espaço planar
(robôs terrestres), como visto em (Figura 7.1b). A aplicação prática dos robôs móveis
junto a diferentes atividades em nossa sociedade vem demonstrando o quão promissor é
o futuro desta área. Por exemplo, seu uso em aplicações domésticas (e.g. robô aspirador
de pó), industriais (e.g. transporte automatizado de cargas), militares (e.g. robôs para
desarmamento de bombas) e em segurança (e.g. robôs vigilantes) .
(a) Robô manipulador (b) Robô móvel
Figura 7.1: Exemplos de robôs.
Assim como os robôs manipuladores possuem um problema fundamental, os robôs

móveis também possuem: a autonomia. Um fator essencial para um sistema robótico é
torna-lo autônomo.
Robôs autônomos devem apresentar reações às mudanças do ambiente, compor-
tamento inteligente, integração entre vários sensores, resolução de múltiplas tarefas, ro-
bustez, capacidade de operar sem falha, programabilidade, modularidade, flexibilidade,
expansibilidade, adaptabilidade e raciocínio global.
Dentro do contexto da autonomia se destaca a Navegação, que pode ser definida
como procedimentos necessários para permitir que um sistema robótico saia de uma con-
745
figuração inicial e alcance uma configuração final percorrendo um determinado caminho

planejado, desviando de obstáculos quando existirem, obedecendo a restrição temporal
imposta para o cumprimento dessa tarefa.
O problema da Navegação vem sendo estudado por diversos pesquisadores no
mundo todo, e nas próximas seções serão detalhados as suas subdivisões e quais as prin-
cipais técnicas utilizadas para trabalhar com cada uma delas. Além disso, uma introdução
ao simulador robótico VREP [Robotics 2010] será apresentada, onde serão detalhados os
seus componentes e funcionalidades destacando o papel importante da simulação para o
ambiente de testes robóticos antes da aplicação em um robô real.
7.2. Navegação Autônoma

Para que um robô móvel possa alcançar seus objetivos, a aptidão de navegar em um deter-
minado espaço se torna essencial. O robô deverá se deslocar através do ambiente que se
encontra, evitando situações perigosas, tais como: colisões e regiões hostis do ambiente,
para alcançar suas metas.
A navegação robótica está diretamente ligada à capacidade do robô em determinar
sua posição em um mapa utilizando informações obtidas do ambiente e a partir dessa
informação planejar sua trajetória até seu destino. Um mapa, nesse contexto, remete a
uma descrição das características do ambiente onde o robô móvel se encontra.
Alsina [Alsina et al. 2002] divide o processo de navegação em cinco níveis hierár-
quicos: modelagem do ambiente, localização, geração de caminho (ou planejamento de
caminho), geração de trajetória e execução da trajetória. A Figura 7.2 ilustra a arquitetura.
Figura 7.2: Arquitetura de navegação de um sistema robótico.
• Modelagem do ambiente: neste nível o robô utiliza sensores para coletar informa-
746
ções e criar um modelo com as principais características estruturais do ambiente.

• Localização: é determinada a posição e orientação do robô no espaço, com base no
modelo obtido no nível de modelagem do ambiente.
• Geração de caminho: o robô calcula a curva geométrica que o leva de sua locali-
zação inicial à sua localização final, desviando dos obstáculos, quando existirem.
• Geração de trajetória: o caminho calculado no nível anterior é adaptado às restri-
ções temporais impostas. A partir daí são calculadas as velocidades que devem ser
aplicadas para que se possa percorrer o caminho no intervalo de tempo especificado.
• Execução de trajetória: os atuadores do robô são controlados de forma que a
trajetória percorrida por ele seja a mais próxima possível da calculada no nível
anterior.
O processo de Navegação Autônoma de robôs móveis combinado com técnicas de

inteligência artificial permite a criação de complexos e poderosos projetos robóticos. A
seção 7.2.1 irá abordar a primeira etapa do processo, o Mapeamento de Ambientes.
7.2.1. Mapeamento de Ambientes

O problema do mapeamento robótico é consiste em adquirir um modelo espacial do am-
biente de um robô. Para construir o mapa o robô deve possuir sensores que o habilitam a
perceber o mundo exterior [Thrun et al. 2005]. Para construir o mapa um sistema robó-
tico precisa determinar a posição e orientação (pose) do robô com algum referencial fixo
no mundo. O problema do mapeamento robótico é dividido em cinco problemas. Onde o
primeiro considera que o movimento do robô está sujeito há erros, pois todos os sensores
o estão e muitos são restritos a limitações de alcance [Thrun et al. 2005].
O segundo problema do mapeamento robótico advêm da alta dimensionalidade
das entidades que serão mapeadas, que pode necessitar de uma grande quantidade de me-
mória para o mapa ser armazenado. O terceiro diz respeito à correspondência ou problema
da associação de dados que determina se as medidas de um determinado sensor usando
diferentes leituras no tempo correspondem ao mesmo objeto no mundo. O quarto está re-
lacionado a ambientes dinâmicos que têm mudanças relativamente lentas como mudanças
estruturais de uma construção, outras mais rápidas como o estado de uma porta e outras
mais rápidas ainda como a localização de agentes em movimento no ambiente. O quinto
diz respeito a qual caminho o robô deve escolher para explorar o mapa. Todos estes aspec-
tos devem ser resolvidos para o correto mapeamento do ambiente, no entanto, na maioria
das vezes define-se no problema que o ambiente é estático para facilitar sua modelagem
e implementação [Meyer-Delius et al. 2010] [Hahnel et al. 2012].
No problema de mapeamento robótico o ambiente deve ser armazenado em uma
estrutura de dados e na literatura há três correntes de representação do ambiente: métrica
Figura 7.3a e 7.3b, topológica Figura 7.3c e híbrida que é composta pelas outras duas
[de Santana Souza et al. 2014].
Os mapas métricos podem ser construídos por grade de ocupação [Moravec and Elfes 1985]
(Figura 7.3a) ou por mapa de características [Crowley 1985] (Figura 7.3b). A represen-
747
(b) métrica com caracterís-

(a) métrica (c) topológica
ticas
Figura 7.3: Representações de um mapa [de Santana Souza et al. 2014].
tação por grade de ocupação consiste em usar um sensor para retornar a distância de um
obstáculo dentro de um ambiente fechado, assim, cada medida coletada traz uma infor-
mação associada sobre a existência ou não de um obstáculo, essa informação é então
projetada num mapa bidimensional considerando o conhecimento da pose do robô.
Um problema da representação métrica é o armazenamento das informações mé-
tricas que dependendo da dimensionalidade do ambiente e da resolução para representá-
lo, a quantidade dados pode ser muito grande.
No mapa de características são armazenados dados que descrevem alguma forma
geométrica que podem ser encontrados no ambiente a ser mapeado, como pontos, retas ou
figuras geométricas, por exemplo, triângulos, retângulos e círculos. Por isso, este tipo de
mapeamento é mais usado em ambientes indoor [Amigoni et al. 2004] [Pfister et al. 2003].
(a) (b) (c)
(d) (e)
Figura 7.4: Construção de um mapa topológico [de Santana Souza et al. 2014].
Os mapas topológicos são representados computacionalmente por um grafo, uma

estrutura de dados formada por nós, regiões com informações sensoriais homogêneas, que
são conectadas entre si por arestas (elos ou arcos). O grafo descreve os espaços livres para
execução de tarefas. Por isso, o mapa topológico é uma solução compacta para o armaze-
namento na memória e devido sua estrutura podem ser usados para resolução de proble-
mas de alto nível como planejamento de tarefas. A localização do robô no mapa é abstrata,
ou seja, não há como definir explicitamente qual a pose do robô, entretanto, pode-se afir-
mar em qual nó do grafo ou em qual região ele se encontra [de Santana Souza et al. 2014].
748
A Figura 7.4 [de Santana Souza et al. 2014] ilustra intuitivamente o processo de constru-
ção de um mapa topológico de um determinado ambiente representado por uma planta
baixa.
7.2.2. Localização
O problema da Localização, no que diz respeito a robôs móveis, trata-se de determinar
a pose do robô relativo a um determinado mapa do ambiente. Esse tipo de problema é
também conhecido como estimação da pose, sendo assim, a Localização pode ser vista
como um problema de transformação de coordenadas. Saber suas coordenadas permite
ao robô expressar a localização dos objetos baseada em sua pose. A pose é descrita da
seguinte forma xt = (x, y, θ )T , onde x, y são suas coordenas baseadas no mapa, e θ a sua
orientação também em relação ao mapa [Thrun et al. 2005].
O grande problema, em se tratando de localização de robôs móveis, é que a pose
não pode ser acessada diretamente, ou seja, não existe um sensor que possa calcular a
pose de forma precisa. Esse processo é realizado a partir da inferência dos dados retorna-
dos pelos sensores, e essa informação só é obtida após várias iterações onde os dados são
integrados a partir de uma medida de tempo. Nas próximas seções serão discutidas o es-
quema geral do processo de Localização, onde serão destacados a influência dos sensores,
os principais problemas envolvendo Localização, as principais técnicas de Localização
conhecidas na literatura e uma breve introdução ao SLAM (Simultaneous Localization
and Mapping).
7.2.2.1. Os desafios da Localização
Um dos cenários mais aprazíveis para o problema da Localização, como foi anterior-
mente mencionado, seria a existência de um sensor que conseguisse em uma única leitura
predizer a pose do robô independente do ambiente. Atualmente temos o GPS (Global Po-
sitioning System), que é capaz de informar o posicionamento de um dispositivo como um
smartphone em qualquer parte do planeta. A desvantagem desta tecnologia é que a sua
acurácia é dada em metros e o uso desse tipo de sensor em robôs pequenos em ambiente
indoor é impraticável devido ao erro atrelado a ele. O GPS ainda possui a limitação de
fornecer apenas a posição absoluta em relação à Terra, e, para o robô, mais do que conhe-
cer sua posição absoluta é necessário saber sua posição relativa aos objetos do ambiente,
para que possa interagir com eles[Siegwart et al. 2011].
[Borenstein and Feng 1996] classificam os métodos de localização em duas grande
categorias: métodos de localização relativa, que dão a pose do robô em relação a uma pose
inicial e métodos de localização absoluta, que dão a pose global do robô e não necessitam
das posições calculadas anteriormente.
O modelo mais simples de localização envolve apenas parâmetros internos do
robô, e por isso, não depende da obtenção de informações do ambiente ao seu redor. A
odometria é um exemplo desse modelo. O método da odometria consiste em determinar
a pose do robô por meio dos deslocamentos incrementais de suas rodas, medidos a partir
de um referencial fixo. A Figura 7.5 exemplifica como se dá esse processo. De acordo
com a imagem, é possível perceber que a posição atual do robô pode ser inferida a partir
749
dos deslocamentos realizados por ele até o momento atual.
Figura 7.5: Deslocamento de um robô medido por odometria
A forma mais comum de calcular o deslocamento do robô é por meio encoders,

que são sensores acoplados às rodas dos robôs que medem seu deslocamento por meio
da rotação de suas rodas. Assim como o GPS, esse tipo de sensoriamento também possui
erros, ou seja, ele fornece apenas uma estimativa da localização exata do robô em um
dado instante de tempo.
Os erros na odometria podem ser classificados como sistemáticos e não-sistemáticos.
Os sistemáticos são os causados por incertezas nos parâmetros do modelo cinemático do
robô (comprimento do eixo diferente nominal, desalinhamento das rodas, etc.). Já os
não-sistemáticos são imprevisíveis, como irregularidades no terreno que o robô atua e es-
corregamento das rodas. Uma estratégia para corrigir esses erros, é a utilização de outros
tipos de sensores em conjunto com os de odometria, a fim de zerar periodicamente os
erros odométricos.
Em se tratando de localização absoluta, destacam-se as técnicas baseadas em mar-
cos. [Borenstein and Feng 1996] definem marcos como elementos distintos que o robô
é capaz de reconhecer através de seus sensores. Eles podem ser artificiais, quando são
introduzidos no ambiente intencionalmente para auxiliar na localização do robô, ou na-
turais, quando já se encontram no ambiente. Geralmente os marcos estão em posições
fixas e conhecidas em relação ao referencial do ambiente. As informações dos sensores
são utilizadas para reconhecer os marcos e determinar as suas posições com relação ao
referencial do robô. Conhecendo a posição dos marcos com relação ao referencial do
ambiente e com relação ao referencial do robô, é possível determinar a pose do robô com
relação ao referencial do ambiente.
A Figura 7.6 exemplifica o esquema básico que está por trás da Localização. Se-
gundo esse modelo, este processo é dividido em uma fase de Predição e outra de Percep-
ção. Na fase de Predição, a pose do robô é estimada por meio de um sensor Intraceptivo,
que descreve o seu posicionamento relativo. Em Percepção, é feita uma correspondência
entre seus sensores Extraceptivos (posicionamento absoluto) e o Mapa do Ambiente em
que o robô se encontra. Feito isso, é analisado se há ou não correspondência, se sim,
a pose é atualizada para aquele instante de tempo, caso contrário, é realizada uma nova
750
Predição.
Figura 7.6: Fluxograma básico da localização de robôs móveis.
7.2.2.2. Principais Técnicas de Localização
Os sensores são a principal forma de os robôs perceberem o mundo. E como foi men-
cionado anteriormente, todo sensor possui um erro característico conhecido na literatura
como ruído. Um dos grandes problemas do ruído é que ele se acumula e se não for tratado,
gera uma localização errônea do robô. A forma mais eficaz de se tratar esse problema é
por meio da robótica probabilística. Esta abordagem consiste em representar uma deter-
minada configuração do robô por meio de uma distribuição probabilística que descreva,
com o máximo de fidelidade possível, a sua posição baseado no conjunto de todas as suas
possíveis poses.
A Figura 7.7 demonstra como a robótica probabilística funciona. O cenário des-
creve um robô se movimentando por um corredor com três portas, junto às imagens do
corredor há duas linhas que representam respectivamente o grau de confiança (bel(x)) do
estado corrente do robô (probabilidade do robô estar em uma determinada posição x), e
o p(z|x) é a probabilidade do robô estar no estado x dada uma medida z. Onde é consi-
derando um posicionamento unidimensional ao longo do eixo das abscissas e o valor da
confiança de uma probabilidade no eixo das ordenadas.
Os algoritmos de localização são uma variação do modelo da Figura 7.7, que por
sua vez é baseada no modelo do filtro de Bayes [Thrun et al. 2005]. Makov Localization
e EKF (Extended Kalman Filter) Localization são os principais exemplos de algoritmos
clássicos de Localização e mais detalhes sobre o seu funcionamento podem ser encontra-
dos em [Thrun et al. 2005] e [Siegwart et al. 2011].
751
(a) O robô se encontra em seu estado inicial, a possível

posição do robô é indeterminada
(b) Uma leitura sensorial do ambiente é realizada, elevando

a probabilidade do robô estar em uma posição próxima da
porta. As possíveis posições do robô são estimadas
(c) O robô realiza um deslocamento e a incerteza de sua

posição aumenta.
(d) Mais uma vez, uma leitura sensorial é realizada e a

confiança da posição do robô começa a convergir para um
único local
(e) O robô realiza mais um deslocamento e sua possível

posição está determinada
Figura 7.7: Exemplificação da robótica probabilística.
752
7.2.2.3. SLAM (Simultaneous Localization and Mapping)
O termo SLAM é uma abreviatura para processo que realiza Localização e Mapeamento
Simultaneamente [Smith and Cheeseman 1986][Leonard and Durrant-Whyte 1991], e pode
ser descrita com uma técnica para a construção de um mapa de um ambiente desconhecido
por um robô móvel que ao mesmo tempo utiliza as informações do mapa para calcular
sua pose.
Figura 7.8: Problema do SLAM.
Este problema é significantemente mais difícil que todos os outros discutidos até
aqui. Ele pode ser pensado como um “problema do ovo e da galinha” (chicken or egg
problem) pois: para a localização é necessário o conhecimento do mapa enquanto que
uma estimativa exata da pose do robô é necessária para construir esse mapa. A Figura 7.8
ilustra o problema de SLAM.
Algumas técnicas utilizadas para resolver esse problema são o SLAM com Ex-
tended Kalman Filter e o GraphSLAM, ambas abordagens podem ser encontradas em
[Thrun et al. 2005].
7.2.3. Geração de Caminho

A geração de caminho é um dos mais importantes tópicos para robôs autômatos móveis.
Sendo o caminho um plano geométrico de pontos em um dado espaço. O planejamento de
caminho consiste na determinação de um caminho que o robô deve fazer entre um ponto
inicial e final do ambiente de modo a passar sobre cada ponto. Buscando uma rota ótima
ou aproximadamente ótima sem colisão com obstáculos.
A Figura 7.9 mostra um exemplo de planejamento de caminhos. O robô deve
deslocar-se de um ponto inicial a um ponto final sem colidir com os obstáculos presentes
no ambiente.
O problema de geração de caminho cresce exponencialmente com o número de
graus de liberdade do robô. As soluções determinísticas e completas são, em geral,
computacionalmente impraticáveis para robôs com elevado número de graus de liberdade
[de Santana Souza et al. 2014].
Geração de caminho para robôs, é formalmente feita em uma representação cha-
mada espaço de configuração. Considerando um robô móvel movendo-se em um am-
753
Início
Destino
Caminho
Figura 7.9: Exemplo de planejamento de caminho.
biente onde o espaço contém obstáculos conhecidos. A meta da geração de caminho é

encontrar o caminho no espaço físico da posição inicial do robô à posição final, evitando
colisão com obstáculos [Siegwart et al. 2011].
O espaço de configurações é uma representação matemática que permite tratar o
robô como um ponto em um espaço. Por exemplo, um robô holonômico que se desloca
no plano possui um espaço de configurações de três dimensões, com duas dimensões
relacionadas à translação (x, y) e um a dimensão é usada para representar a orientação
do robô Ω [de Santana Souza et al. 2014]. Se definirmos o espaço de configuração dos
obstáculos O como um subespaço de C onde o robô se choca em algo, podemos calcular
o espaço livre F = C − O em que o robô pode mover-se com segurança.
Objetos
Figura 7.10: Representação por polígonos convexos no espaço.
A representação dos objetos no espaço podem ser feitas de diversas maneiras no

mapa. A representação por polígonos convexos no plano é mais usada na geração de ca-
minhos, um exemplo é mostrado na Figura 7.10. Uma representação que também pode
ser utilizada para modelar objetos no espaço é a por modelos semi-algébricos, um con-
junto de uniões e interseções de conjuntos algébricos (Figura 7.11). Estes modelos são
uma generalização da representação por polígonos convexos que determinam a interseção
de conjuntos definidos por primitivas polinomiais de grau 1, ou seja, retas (Figura 7.11a).
A vantagem desta representação é que os objetos modelados podem ser não convexos e
inclusive podem conter buracos em seu interior (Figura 7.11b).
Em robótica móvel, um tipo de representação frequente para o espaço de trabalho
é a grade de ocupação [de Santana Souza et al. 2014]. Neste tipo de representação, o
espaço é dividido em células e um número indica a probabilidade de ocupação, associado
a cada célula (Figura 7.12).
754
Objetos
Objetos
(b) Elipse com buraco no in-

(a) Polígono convexo.
terior.
Figura 7.11: Representação por primitivas semi-algébricas.
Figura 7.12: Grade de Ocupação.
A representação do ambiente do robô pode abranger de uma descrição geométrica

contínua até um mapa geométrico baseado em decomposição ou mesmo um mapa topo-
lógico descrito na Subseção 7.2.1. O primeiro passo para um sistema gerador de caminho
é transformar um possível modelo contínuo de um ambiente em um mapa discreto para o
algoritmo gerador de caminho escolhido. O geradores de caminhos são divididos em três
categorias [Siegwart et al. 2011]:
• Mapa de rotas: identifica um conjunto de rotas dentro de um espaço livre.
• Decomposição em células: discrimina células entre livre e ocupada.
• Campos potenciais: impõe uma função matemática sobre o espaço.
A abordagem do mapa de rotas captura a conectividade do do espaço livre do robô

em uma rede de curvas ou linhas 1D. uma vez construído, o mapa de rotas é usado como
uma rede de caminhos para planejar a locomoção do robô. A geração de caminho é assim
reduzida a conectar um ponto inicial a um final, ou seja, uma busca em uma serie de cami-
nhos da posição inicial do robô a posição final. O mapa de rotas é uma decomposição na
configuração do robô baseado na geometria dos obstáculos. Duas abordagens principais
para o mapa de rotas O grafo de visibilidade e o diagrama de Voronoi.
O grafo de visibilidade as rotas são as mais próximas possíveis dos obstáculos e
os caminhos resultantes são as soluções de tamanho mínimo. Um grafo de visibilidade
para um espaço de configuração poligonal consiste da ligação de arestas entre todos os
755
Obstáculos
Menor caminho Objetivo
Início
Figura 7.13: Exemplo de grafo de visibilidade.
pares de vértices que podem se ver. A tarefa do gerador de caminho é encontrar o menor
caminho entre a posição inicial até a posição final ao longo das rotas definidas pelo grafo
de visibilidade (Figura 7.13).
Contrastando com a abordagem do grafo de visibilidade, o diagrama de Voronoi é
um método completo de mapa de rotas que tende a maximizar a distancia entre um robô e
um obstáculo no mapa. O diagrama de Voronoi consiste de linhas construídas a partir de
todos os pontos que são equidistantes de dois ou mais obstáculos (Figura 7.14).
Figura 7.14: Exemplo de diagrama de Voronoi, onde start é o ínicio e goal é o objetivo
[Siegwart et al. 2011].
Na outra categoria da geração de caminho temos a decomposição em células. A

ideia é discriminar entre áreas geométricas, ou células, que estão livres e áreas que estão
ocupadas por objetos. Pode ser divididos em duas abordagens principais: decomposição
exata e decomposição aproximada. Em ambas, o espaço deve ser particionado em um
conjunto de células cujas as regiões interiores não se sobrepõe.
A decomposição em células exatas o limite das células são baseados na criticidade
geométrica (Figura 7.15). As células resultantes são completamente livres ou completa-
mente ocupadas, e assim o gerador de caminhos é uma rede completa, como um método
de mapa de rotas acima. Em uma abstração básica da decomposição a posição do robô
em cada célula livre não interessa, o que interessa é a habilidade do robô atravessar cada
célula livre adjacente.
Na decomposição celular aproximada o espaço de configurações é dividido su-
cessivamente em células denominadas vazias, cheias ou mistas. Células vazias não con-
têm obstáculos, células cheias estão completamente preenchidas por obstáculos, e células
mistas estão parcialmente preenchidas por obstáculos [de Santana Souza et al. 2014]. O
objetivo é dividir as células mistas até que sobrem apenas áreas ocupadas e livres ou até a
resolução máxima seja alcançada.
756
Figura 7.15: Decomposição em células exatas [Siegwart et al. 2011].
Por fim, a categoria campos potenciais da geração de caminho. Um potencial de

atração é adicionado ao destino e um potencial de repulsão é adicionado aos obstáculos.
Assim, o robô tende a ir ao encontro do ponto final enquanto automaticamente desvia dos
obstáculos. O gerador de caminho baseado em funções potenciais consiste em calcular o
movimento do robô a partir das orças de atração e repulsão que atuam nele. O movimento
continua até que a força resultante seja igual a zero, o que também garante um movimento
suave [de Santana Souza et al. 2014].
7.2.4. Geração de Trajetória

Na geração de trajetória, o caminho calculado no nível anterior é adaptado às restrições
temporais impostas, cinemática, capacidade de aceleração e desaceleração e posição do
robô, e a partir disso é gerado um caminho suave entre a posição atual do robô e o destino.
Com isso, a trajetória gerada é utilizada como referência para o percurso do robô até seu
destino, onde a medida que o robô se locomove valores de referência são passados para o
controlador para que o robô continue seguindo a trajetória traçada [Romero et al. 2014].
A Figura 7.16 ilustra um exemplo de trajetória gerada a partir do caminho planejado.
Início
Destino
Caminho
Trajetória
Figura 7.16: Trajetória gerada por meio do caminho obtido no planejamento.
7.2.5. Execução da Trajetória

Na execução de trajetória os atuadores do robô são controlados de forma que a trajetória
percorrida por ele seja a mais próxima possível da calculada no gerador de trajetória.
757
Dentre alguns sistemas de controle podemos citar o controlador proporcional integral

derivativo (PID) e controlador por inferência fuzzy [Leal et al. 2016]. Estes controladores
utilizam as informações de referência adquiridas na geração de trajetória para computar
os valores de tensão que serão aplicados aos atuadores do robô fazendo com que eles
saiam da posição atual e atinjam o ponto de referência mais próxima da trajetória com o
menor erro possível. A Figura 7.17 ilustra um exemplo de execução projetada a partir da
trajetória gerada.
Início
Destino
Figura 7.17: Execução da trajetória gerada.
7.3. Introdução ao uso do simulador V-REP

A simulação computacional permite que diversos testes sejam realizados sem a necessi-
dade de implantação do sistema em robô real garantindo, assim, uma maior economia de
recursos (inclusive financeiros). Visto que na simulação não há desgaste de componentes
do robô ou outro possível objeto físico utilizado em um teste real, torna-se desnecessário
a troca dos mesmos. Na simulação há uma economia de tempo, já que ela pode ser acele-
rada e também não há necessidade de se perder tempo recarregando as fontes de energia
do robô.
Figura 7.18: Robô sendo simulado na ferramenta V-rep.
A simulação garante uma maior segurança à integridade física do robô, dos objetos
758
do local em que ele está inserido e até mesmo de seres humanos ou outros seres vivos,
pois tudo acontece no computador, não há perigo de o robô se chocar com uma obstáculo
e danificar sua estrutura ou causar ferimentos a alguém em caso de erro. Ela permite o
aperfeiçoamento dos algoritmos testados na simulação, visto que podemos verificar se os
resultados são satisfatórios no simulador, antes de aplicar em um robô real.
A aplicação V-REP [E. Rohmer 2013] (Figura 7.18) é uma ferramenta que permite
que o usuário monte cenários com diversos objetos simuláveis como robôs, obstáculos e
sensores. Ele oferece vários modelos de robôs existentes no mundo real, como o NAO e o
Pioneer p3dx, disponíveis para uso bem como ferramentas para editá-los e sua funcionali-
dade ou para criar novos. O simulador permite a utilização de quatro bibliotecas conheci-
das de simulação das físicas do ambiente: ODE (Open Dynamics Engine) [Smith 2016],
Bullet [Coumans 2016], Vortex [Simulations 2016] e Newton [Jerez and Suero 2016].
7.3.1. Principais características do V-REP

O V-REP permite que cada modelo presente na simulação seja controlado individual-
mente através de scripts e os controladores podem ser escritos nas linguagens C/C++,
Python, Java, Lua, Matlab ou Octave. Outra característica importante é a capacidade de
importar elementos 3D modelados em outros editores, pois o V-REP é limitado quando
se trata de modelar estruturas 3D em seu editor interno. Os formatos suportados para
importação são OBJ, DXF, 3DS, STL e CSV.
A Figura 7.19, ilustra a interface principal do simulador V-REP. Nela se encontra
a cena, cenário da simulação, que é composta pelos objetos que serão simulados: robôs,
obstáculos, piso, luzes e câmera.
Figura 7.19: Interface do V-REP.
O V-REP se apresenta como uma poderosa solução gratuita, em sua versão para
estudantes, para a simulação de projetos robóticos. Apesar da proposta robótica do si-
mulador ele não se limita somente a este caso. É possível utilizar programas externos
ao simulador que através da API de comunicação do V-REP, podem interagir e realizar
simulações para didáticas em áreas como física e matemática.
759
7.4. Conclusão
A partir dos conteúdos apresentados, percebe-se que a Robótica é uma área rica em co-
nhecimento. Nesta breve introdução à Robótica Móvel, foram abordados os principais
tópicos da Navegação Autônoma, ou seja, o que é necessário para que um robô possa se
locomover autonomamente sem a interferência direta de um ser humano na tomada de
decisões. Todas as etapas necessárias para realização da Navegação: Mapeamento, Loca-
lização, Geração de Caminho, Geração de Trajetória e Execução da Trajetória, trabalham
utilizando algoritmos baseados em conceitos estatísticos e de otimização, cada etapa pode
ser subdividida em inúmeras outras com vários desafios a serem trabalhados e a união de
todas estas etapas, mesmo com todo o aparato literário disponível atualmente, não é uma
tarefa trivial. Além disso, a Robótica também encara o grande desafio do custo aquisi-
tivo dos robôs de alto nível. Atualmente várias propostas de arquiteturas e plataformas
de baixo custo vêm se tornando populares, grande parte delas permitem implementar as
funcionalidade necessárias para a Navegação. Esses sistemas de baixo custo, aliados ao
uso de simuladores permitem ampliar o interesse educacional pela Robótica.
O grande objetivo deste minicurso é despertar o interesse de novos estudantes e
pesquisadores para uma área tão desafiadora, quanto é a Robótica. Para os já familiariza-
dos com tema, espera-se que os conhecimentos aqui expostos possam ampliar ainda mais
o interesse pelo estudo e pesquisa em Robótica.
Referências
[Alsina et al. 2002] Alsina, P. J., Gonçalves, L. M. G., Medeiros, A. A. D., Pedrosa, D.
P. F., and Vieira, F. C. (2002). Navegação e controle de robôs móveis. XIV Congresso
Brasileiro de Automática.
[Amigoni et al. 2004] Amigoni, F., Gasparini, S., and Gini, M. (2004). Map building
without odometry information. In Robotics and Automation, 2004. Proceedings. ICRA
’04. 2004 IEEE International Conference on, volume 4, pages 3753–3758 Vol.4.
[Borenstein and Feng 1996] Borenstein, J. and Feng, L. (1996). Measurement and cor-
rection of systematic odometry errors in mobile robots. IEEE Transactions on robotics
and automation, 12(6):869–880.
[Coumans 2016] Coumans, E. (2016). Bullet. http://bulletphysics.org. Online; Acessado

em 25/10/2017.
[Craig 2005] Craig, J. J. (2005). Introduction to robotics: mechanics and control, vo-
lume 3. Pearson Prentice Hall Upper Saddle River.
[Crowley 1985] Crowley, J. (1985). Navigation for an intelligent mobile robot. IEEE
Journal on Robotics and Automation, 1(1):31–41.
[de Santana Souza et al. 2014] de Santana Souza, A. A., Santana, A. M., Gonçalves, L.
M. G., and de Medeiros, A. A. D. (2014). Mapeamento, volume 1, pages 161–175.
LTC.
760
[E. Rohmer 2013] E. Rohmer, S. P. N. Singh, M. F. (2013). V-rep: a versatile and scalable
robot simulation framework. In Proc. of The International Conference on Intelligent
Robots and Systems (IROS).
[Hahnel et al. 2012] Hahnel, D., Schulz, D., and Burgard, W. (2012). Temporary maps
for robust localization in semi-static environments. In Advanced Robotics, pages 579–
597.
[Jerez and Suero 2016] Jerez, J. and Suero, A. (2016). Newton dynamics.
http://newtondynamics.com. Online; Acessado em 25/10/2017.
[Leal et al. 2016] Leal, W., Medeiros, D., Silva, W. A. S., Machado, R., Neto, J. B., and
Rabelo, R. A. L. (2016). O estudo da aplicabilidade de controladores distintos para
um robô seguidor de parede autônomo em um ambiente estático. Revista de Sistemas
e Computação, 6(1):1–6.
[Leonard and Durrant-Whyte 1991] Leonard, J. J. and Durrant-Whyte, H. F. (1991). Mo-
bile robot localization by tracking geometric beacons. IEEE Transactions on robotics
and Automation, 7(3):376–382.
[Meyer-Delius et al. 2010] Meyer-Delius, D., Hess, J., Grisetti, G., and Burgard, W.
(2010). Mobile robot mapping in populated environments. In Intelligent Robots and
Systems (IROS), 2010 IEEE/RSJ International Conference on, pages 5750–5755.
[Moravec and Elfes 1985] Moravec, H. and Elfes, A. (1985). High resolution maps from
wide angle sonar. In Robotics and Automation. Proceedings. 1985 IEEE International
Conference on, volume 2, pages 116–121.
[Pfister et al. 2003] Pfister, S. T., Roumeliotis, S. I., and Burdick, J. W. (2003). Weighted
line fitting algorithms for mobile robot map building and efficient data representation.
In Robotics and Automation, 2003. Proceedings. ICRA ’03. IEEE International Con-
ference on, volume 1, pages 1304–1311 vol.1.
[Robotics 2010] Robotics, C. (2010). V-REP. http://www.coppeliarobotics.
com/. [Online; Acessado em 24/10/2017].
[Romero et al. 2014] Romero, R. A. F., Prestes, E., Osório, F., and Wolf, D. (2014). Ro-
bótica Móvel. LTC.
[Siegwart et al. 2011] Siegwart, R., Nourbakhsh, I. R., and Scaramuzza, D. (2011). In-
troduction to autonomous mobile robots. MIT press.
[Simulations 2016] Simulations, C. L. (2016). Vortex. http://www.cm-labs.com/. Online;
Acessado em 25/10/2017.
[Smith 2016] Smith, R. (2016). Open dynamic engine (ode). http://www.ode.org/. On-
line; Acessado em 25/10/2017.
[Smith and Cheeseman 1986] Smith, R. C. and Cheeseman, P. (1986). On the repre-
sentation and estimation of spatial uncertainty. The international journal of Robotics
Research, 5(4):56–68.
761
[Thrun et al. 2005] Thrun, S., Burgard, W., and Fox, D. (2005). Probabilistic robotics.
MIT Press.
762
Capítulo
8
Construindo Microsserviços em Ambiente de
Computação em Nuvem
Anderson Cavalcanti de Lima, Luciano de Aguiar Monteiro, Raphael

Rodrigues Hazin e Washington Henrique Carvalho Almeida
Abstract
In this work, a research was conducted on the topic of microservice that has been
adopted as a natural solution in the substitution of monolithic systems for applications
in the cloud computing environment. The construction of microservices must be based
on the standards adopted by the software industry. This chapter presents the results of
the research carried out. The presentation addresses security and privacy issues as well
as an architectural standard for deployment.
Resumo
Neste trabalho foi realizada uma pesquisa sobre o tema de microsserviço que tem sido
adotado como uma solução natural na substituição de sistemas monolíticos para
aplicações em ambiente de computação em nuvem. A construção de microsserviços
deve ser baseada em padrões adotados pela indústria de software. Este capítulo
apresenta o resultado da pesquisa realizada. Na apresentação são abordados questões
de segurança e privacidade bem como um padrão arquitetural para implantação.
8.1. Introdução
Microsserviço é uma tendência arquitetural e tem sido adotado como uma solução
natural na substituição de sistemas monolíticos. O conceito foi definido em 2014 por um
artigo escrito por Martin Fowler [Fowler 2014]. Microsserviços [Almeida et al. 2017]
são pequenos serviços autônomos que trabalham juntos e consiste em um estilo de
arquitetura de software na quais grandes e complexas aplicações são compostas por um
ou mais serviços.
Algumas tecnologias e padrões foram adotados para o desenvolvimento de

microsserviços em ambiente de computação em nuvem e a utilização de API (Aplication
Programing Interface) [Gadea et al. 2016] e REST (Representational State Transfer)
763
[Giessler et al. 2016] tem sido utilizados em grande escala para implementação desse
padrão. O objetivo deste trabalho é realizar uma apresentação sobre a arquitetura de
microsserviços levando em consideração aspectos de segurança, privacidade e
padronização em ambientes de computação em nuvem, o conteúdo está baseado na
pesquisa de mestrado do C.E.S.A.R1 realizada pelos autores e no artigo publicado no
The Twelfth International Conference on Software Engineering Advances – ICSEA
2017 com o título Survey on Microservice Architecture - Security, Privacy and
Standardization on Cloud Computing Environment.
8.2. Evolução da Engenharia de Software

A engenharia de software consiste em um processo, um conjunto de métodos e um
leque de ferramentas que possibilitam aos profissionais desenvolverem software de
qualidade [Pressman 2016]. Esta disciplina passou a ser reconhecida como uma área da
engenharia especificamente no ano de 1968, quando foi realizada a primeira conferência
de Engenharia de Software, em Garmisch na Alemanha, organizada com o propósito de
possibilitar a definição e o uso de princípios de engenharia para a construção de
softwares viáveis sob os aspectos relacionados à confiabilidade, eficiência e economia
[Mens 2007]. Buscava-se, assim, resolver os problemas apresentados até então no
desenvolvimento de software iniciado nas décadas de 1950 e 1960, denominados na
conferência de crise do software.
Essa visão levou à proposição, na década de 1970, do processo de software

denominado “modelo cascata” ou simplesmente waterfall. Esse modelo clássico de
processo de desenvolvimento de software, apesar de sua longevidade, tem sido usado
até hoje em muitas corporações. O modelo tem bons resultados quando utilizado no
desenvolvimento de sistemas para os quais os requisitos são conhecidos e bem definidos
no início do projeto e que se mostram estáveis ao longo do desenvolvimento do
software [Mens 2007].
O modelo cascata é caracterizado por um abordagem sequencial e bem-definida

das etapas de desenvolvimento de um software, iniciando pela especificação dos
requisitos e seguindo pelas etapas de planejamento, modelagem, construção,
disponibilização e suporte contínuo ao software desenvolvido. No entanto, nos últimos
anos a eficácia do modelo tem sido questionada, especialmente por enfrentar problemas
intrínsecos à realidade do desenvolvimento de software, que incluem o fato de que
projeto reais raramente seguem um fluxo sequencial [Pressman 2016]. Além disso, o
cliente normalmente não consegue estabelecer explicitamente todas suas necessidades
no início de um projeto de desenvolvimento de software. Por fim, nesse modelo, o
cliente só tem acesso ao software funcionando depois de muito tempo de espera, quando
estariam concluídas todas as etapas iniciais previstas para a sua construção.
Em meados da década de 1980, o modelo espiral foi proposto por Barry Boehm
para utilização no desenvolvimento de software no qual não havia o conhecimento
completo dos requisitos a serem implementados. O modelo espiral é considerado um
modelo incremental porque suas atividades são organizadas em ciclos com o objetivo de
construir uma parte do software a cada iteração, sendo evoluída nos ciclos subsequentes
1
Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R http://www.cesar.edu.br/
764
[O’Reagan 2016]. Cada iteração consiste em definir os objetivos do ciclo, identificar e

resolver os riscos associados, desenvolver e testar o software no escopo previsto para o
ciclo e planejar a próxima iteração.
Na década de 1990, a Rational Software, hoje parte da IBM, apresentou o

modelo Rational Unified Process (RUP), que utiliza a linguagem UML como
ferramenta para especificação e desenho de software, que, por sua vez, fornece meios
para a especificação, construção e documentação de sistemas orientados a objeto
[O’Reagan 2016]. O modelo RUP inclui ciclos, fases, fluxos de trabalho, mitigação de
riscos, controle de qualidade, gerenciamento de projeto e controle de configuração para
o desenvolvimento de software. Os requisitos são coletados na forma de casos de uso,
que descrevem as funcionalidades do sistema sob a perspectiva do usuário e são usados
para direcionar todo o processo de desenvolvimento do software. O modelo RUP prevê
que projetos complexos sejam divididos em mini-projetos, que devem,
obrigatoriamente, representar incrementos do produto de software final. Por essa razão,
o modelo RUP também é considerado iterativo e incremental.
Mais recentemente, tem crescido a popularidade entre os desenvolvedores de um

conjunto de práticas que integram o modelo conhecido por “metodologia ágil”. Apesar
de versões anteriores da metodologia terem sido introduzidas nas décadas de 1980 e
1990, o modelo ágil passou a ser mais amplamente conhecido após a publicação do
manifesto ágil em 2001 [O’Reagan 2016]. O modelo ágil atende mais prontamente aos
usuários do que nos demais modelos de desenvolvimento de software. As mudanças são
consideradas normais na construção de um software e o modelo defende que essas
mudanças devem ser bem recebidas e incorporadas ao software em desenvolvimento
por meio de um bom controle mudanças e uma boa comunicação. Além disso, as
iterações, denominadas “sprints”, são planejadas antes do início de cada ciclo, onde os
requisitos explicitados na forma de histórias de usuário são priorizadas pelo cliente e
assinaladas para o ciclo que se iniciará.
Ao final de cada iteração, é realizada uma apresentação ao cliente do incremento

de software produzido na etapa, de modo a validar as implementações e ter a
oportunidade de apresentar um feedback sobre o sistema construído até o momento.
Essa sistemática privilegia o acompanhamento dos trabalhos pelo cliente, evitando o
desvio da equipe em relação aos requisitos propostos pelos usuários do futuro sistema,
promovendo, assim, o atendimento às necessidades apresentadas à medida que o
software vai evoluindo em seu processo de desenvolvimento.
Outro aspecto importante a ser observado quanto à evolução do

desenvolvimento de software diz respeito a como eram organizados os dados e as
instruções que integravam o software desenvolvido.
A princípio, na época em que a codificação era feita em nível de código de

máquina, o programador implementava o software a ser construído manipulando
diretamente as instruções e dados primitivos no layout de memória física do computador
[Quin et al 2008]. Ao longo do tempo, com o desenvolvimento de linguagens de
programação que abstraíam a codificação a nível de linguagem de máquina, o código-
fonte do sistema era organizado em blocos contendo uma lista contínua de instruções,
765
que podiam “pular” de um ponto a outro por meio das instruções GOTO. Essa forma de
organizar as instruções dos programas era denominada programação não-estruturada.
A evolução das linguagens de programação permitiu a melhoria da forma de

desenvolvimento do software. As instruções passaram, então, a ser divididas em blocos
denominados procedimentos que eram executados a partir da chamada entre si. Essa
estratégia de organização do código era conhecida por programação estruturada e
passou a permitir uma abordagem “top-down” para desenvolvimento de softwares [Quin
et al 2008], que consistia na divisão de grandes e complexos softwares em módulos
especializados e, então, era realizado um detido trabalho de desenho e construção dos
procedimentos que compunham cada módulo.
A partir de então, a evolução da abordagem estruturada das linguagens de

programação permitiu que algumas técnicas possibilitassem aos engenheiros de
software encapsular em uma estrutura única os dados e as instruções relativas a uma
entidade específica do sistema. Surgiu, com essa abordagem, o paradigma orientado a
objetos (OO). As linguagens de programação orientada a objetos possuem, ainda, como
características peculiares as capacidades de derivação (herança) e polimorfismo,
incorporando grande poder de abstração às estruturas de código definidas nos
programas de computador construídos.
Esse conjunto de elementos, instruções e dados, e as estratégias para organizá-

los de modo a construir um software deram origem ao conceito de arquitetura de
software. Apesar do termo ter sido introduzido na década de 1960, com a publicação do
artigo “The Structure of the ‘THE’ Multiprogramming System” por Edsger Dijkstra em
1968, modelos mais formalizados que explicam a arquitetura de software só foram
objetos de publicações de pesquisas acadêmicas na década de 1990. Após o ano 2000, a
arquitetura de software passou de uma fase de desenho do software para ser o centro de
todo o processo de desenvolvimento do programa de computador.
8.3. Arquitetura de Microsserviços

Conforme visto na seção anterior, a evolução das arquiteturas de softwares buscou o
atendimento da complexidade das soluções que foram construídas perante os diversos
desafios na busca de entrega de sistemas cada vez mais adaptados a necessidade dos
usuários. Nesse período, a arquitetura de microsserviços acabou por ser um caminho
natural na evolução da engenharia de software perante as diversas tecnologias que
surgiram com o advento da internet e, mais recentemente, da computação em nuvem.
[Yale Yu et al. 2016] define microsserviço como um estilo de arquitetura que

coloca a ênfase na divisão do sistema em serviços pequenos e leves que são
propositadamente construídos para desempenhar uma função de negócios muito coesa e
é uma evolução do tradicional estilo de arquitetura orientada a serviços. Uma
arquitetura baseada em microsserviço tem um padrão para o desenvolvimento de
aplicações distribuídas, onde a aplicação é composta por uma quantidade menor de
componentes "independentes". Esses componentes são pequenos aplicativos
independentes.
766
As arquiteturas de software tratadas antes da expansão dos microsserviços têm

sido chamadas de arquitetura monolítica, na tabela 8.1 são demonstradas algumas
diferenças para melhor entendimento:
Tabela 8.1. Comparação Arquiteturas [Bakshi 2017].
Categoria Arquitetura Monolítica Arquitetura de Microsserviço
Código Uma base de código única para Múltiplas bases de código. Cada um tem
todo o aplicativo. sua própria base de código.
Legibilidade Muitas vezes confuso e difícil de Muito melhor legibilidade e muito mais
do Código manter. fácil de manter.
A implantação simples como cada
Implantações complexas com
Implantações microsserviço pode ser implantada
janelas de manutenção e horários de
individualmente, com um tempo de
indisponibilidade.
inatividade mínimo, se não zero.
Normalmente, totalmente Cada microsserviço pode ser
Linguagem desenvolvido em uma linguagem de desenvolvido em uma linguagem de
programação. programação diferente.
Requer que você dimensione toda a
Escala Permite que você escale os serviços com
aplicação mesmo que os pontos de
gargalos sem escalar a aplicação toda.
estrangulamento sejam localizados.
Segundo [Villamizar and Et al 2015] escalar aplicações monolíticas é um desafio

porque geralmente oferecem muitos serviços. Alguns deles são mais populares do que
outros. Se os serviços populares precisam ser dimensionados porque são altamente
exigidos, todo o conjunto de serviços também será dimensionado ao mesmo tempo, o
que implica que os serviços impopulares irão consumir uma grande quantidade de
recursos do servidor mesmo quando não forem utilizados.
A arquitetura baseada em microsserviços emergiu para simplificar esta realidade
e é uma evolução para os modelos de aplicativos. Conforme [Savchenko et al. 2015]
microsserviços são uma entidade orientada por software que possui os seguintes
recursos:
 Isolamento - de outros microsserviços, bem como do ambiente de execução
baseado em um recipiente virtualizado;
 Autonomia - microsserviços podem ser implantados, destruídos, movidos ou
duplicados de forma independente. Assim, os microsserviços não podem ser
vinculados a nenhum recurso local porque o ambiente do microsserviço pode
criar mais de uma instância do mesmo microsserviço;
 Interface aberta e padronizada - que descreve todos os objetivos específicos
com eficácia, eficiência e métodos de comunicação disponíveis (API ou
GUI);
 O microsserviço é de grão fino - cada microsserviço deve lidar com sua
própria tarefa.
767
A ideia de dividir um aplicativo em um conjunto de serviços menores e

interconectados (microsserviço) está recebendo muito interesse dos desenvolvedores de
aplicativos e provedores de serviços (por exemplo, Amazon , Netflix , eBay) [Almeida
et al. 2017]. Essa arquitetura tem um padrão para o desenvolvimento de aplicações
distribuídas, onde a aplicação é composta por uma quantidade menor de componentes
"independentes". Esses componentes são pequenas aplicações em si [Yale Yu et al.
2016].
Nesse contexto um microsserviço normalmente compreende três camadas como
uma aplicação típica de três camadas, consistindo em uma camada de interface, uma
camada de lógica comercial e uma camada de persistência de dados, mas dentro de um
contexto limitado muito menor. Isso define um amplo alcance das capacidades técnicas
que um microsserviço poderia possuir. No entanto, nem todos os microsserviços
fornecem todas as capacidades. Isso variaria de acordo com a forma como a função
fornecida deveria ser consumida. Por exemplo, um microsserviço usado principalmente
por provedores de API (Aplication Programing Interface) teria uma camada de interface
de comunicação, lógica de negócios e camadas de persistência de dados, mas não
necessariamente possui interfaces de usuário [Yale Yu et al. 2016].
8.3.1. API Proxy
Conforme [Yale Yu et al. 2016] para "desacoplar" o microsserviço de seus
consumidores, esse padrão de proxy é aplicado no nível de interface do microsserviço,
independentemente do componente "proxy da API". As organizações fornecerão API
para consumidores diferentes, alguns dos quais estão dentro e outros fora da empresa.
Esses microsserviços diferem em acordos de nível de serviço (SLA), requisitos de
segurança, níveis de acesso etc.
8.3.2. Enterprise API Registry
Os requisitos de "descoberta" dos microsserviços são atendidos através do uso do
serviço de registro da API. O objetivo é tornar visíveis as interfaces expostas pelo
microsserviço aos consumidores dos serviços dentro e fora da empresa. Um "Registro
da API da empresa" é um componente compartilhado em toda a empresa, cuja
localização deve ser conhecida e acessível. Seu conteúdo de informações é publicado
em um formato padrão, a informação deve estar em formato consistente e legível por
humanos e deve ter acesso controlado. Deve ter recursos de pesquisa e recuperação para
permitir aos usuários procurar detalhes sobre as especificações da API disponíveis em
tempo de design [Yale Yu et al. 2016].
8.3.3. Repositório Corporativo
O "repositório de microsserviço da empresa" seria um repositório compartilhado para
armazenar informações sobre microsserviços. Ele fornece informações como o status do
ciclo de vida do microsserviço, as versões, a propriedade comercial e de
desenvolvimento, informações detalhadas como seu objetivo, como ele atinge o
objetivo, as ferramentas, as tecnologias, a arquitetura, o serviço que ele fornece
qualquer API que consome, os dados persistiram e consultados e qualquer requisitos
não funcionais específicos. Na ausência de padrões bem definidos de repositório, a
empresa deve definir seus próprios artefatos de especificação padrão para
microsserviços [Yale Yu et al. 2016].
8.3.4. Implementação
768
A maioria dos esforços de desenvolvimento de aplicativos que se observa atualmente

usa um modelo de projeto onde o objetivo é entregar software considerado completo.
Após a conclusão do projeto de desenvolvimento, o software é entregue a uma equipe
de sustentação e evolução, ao tempo que a equipe do projeto que o construiu é
dissolvida.
Os proponentes do microsserviço tendem a evitar esse modelo, preferindo a
noção de que uma equipe deve possuir um produto ao longo de sua vida útil completa.
Uma inspiração comum para isso é a noção da Amazon de "você cria, você executa",
onde uma equipe de desenvolvimento assume toda a responsabilidade pelo software em
produção. Isso põe os desenvolvedores em contato no dia-a-dia com a forma como seu
software se comporta em produção e promove a aproximação com os usuários do
sistema, pois eles devem assumir, pelo menos, alguma carga de suporte [Almeida et al.
2017].
A mentalidade do produto relaciona-se com a ligação às capacidades
empresariais. Ao invés de olhar para o software como um conjunto de funcionalidades a
serem concluídas, há uma relação contínua onde a questão é como o software pode
ajudar seus usuários a aprimorar a capacidade do negócio.
Não há razão para que essa mesma abordagem não possa ser tomada com
aplicações monolíticas, mas a menor granularidade de serviços pode facilitar a criação
de relações pessoais entre desenvolvedores de serviços e seus usuários.
8.4 Padronização
Na estrutura centralizada, a padronização se torna quase natural, mas na implementação
de microsserviços essa filosofia muda. As equipes que criam microsserviços preferem
uma abordagem diferente aos padrões também. Em vez de usar um conjunto de padrões
definidos, escritos em algum lugar no papel, elas preferem a ideia de produzir
ferramentas úteis que outros desenvolvedores podem usar para resolver problemas
semelhantes aos que estão enfrentando. Essas ferramentas geralmente são colhidas de
implementações e compartilhadas com um grupo mais amplo, às vezes, mas não
exclusivamente, usando um GIT e GITHUB tornou-se o sistema de controle de versão
de fato de escolha. As práticas de código aberto estão se tornando cada vez mais
comuns internamente [Fowler, Marthin; Lewis 2014].
Um microsserviço é um aplicativo por conta própria para executar as funções
necessárias. Ele evolui de forma independente e pode escolher sua própria arquitetura,
tecnologia, plataforma e pode ser gerenciado, implantado e dimensionado de forma
independente com seu próprio ciclo de vida e metodologia de desenvolvimento. Esta
abordagem tira a construção da SOA e ESB e os desafios que acompanham, criando
"pontos de extremidade inteligentes" e tratando as camadas intermediárias como
recursos de rede cuja função é a transferência de dados [Yale Yu et al. 2016].
As aplicações que expõem interfaces que podem ser usadas por outras
aplicações para interagir são definidas como "interfaces de programação de aplicativos"
(API) [Krylovskiy et al. 2015]. As API de microsserviço, que são criadas usando
protocolos de comunicação na Internet como HTTP, aderem a padrões abertos como
REST e SOAP e usam tecnologias de troca de dados como XML e JSON [Almeida et
al. 2017].
769
Os aplicativos desenvolvidos em uma arquitetura monolítica executam múltiplas

funções, como o fornecimento de validação de endereços, catálogo de produtos,
verificação de crédito ao cliente, etc. Ao usar o padrão de arquitetura baseado em
microsserviço, as aplicações são criadas para funções específicas, como validação de
endereços, verificação de crédito ao cliente e pedidos on-line; Esses aplicativos são
agrupados para fornecer toda a capacidade para o serviço proposto. A abordagem do
desenvolvimento de aplicativos baseado na arquitetura microsserviço aborda os desafios
das aplicações e serviços "monolíticos"[Almeida et al. 2017].
8.4.1 REST
REPRESENTATION State Transfer (REST) consistindo de um conjunto de princípios
arquitetônicos que, quando seguidos, permitem a criação de um design de interface bem
definido. Aplicativos que usam princípios REST são chamados RESTFul. REST é
frequentemente aplicado para fornecer serviços a outros serviços (serviços da web) e ao
mesmo uso completo de mensagens [Almeida et al. 2017].
Para entender melhor o estilo arquitetônico, é importante destacar três conceitos
importantes: (i) recurso; (ii) operações e (iii) representações. O recurso é qualquer
informação disponibilizada aos clientes através de um identificador exclusivo (URI).
Também podemos definir o recurso como fonte de representações. As representações
são um conjunto de dados que explica o estado do recurso solicitado. URIs devem ter
um padrão de notação, ser descritivo e ter uma hierarquia previamente definida. O
mesmo recurso pode ser identificado por uma ou mais URIs, mas uma URI identifica
apenas um recurso [Almeida et al. 2017].
8.4.2. API
A Interface do Programa de Aplicação (API) é (a) autenticação básica, incluindo
registro de usuário de API com proteção de senha forte, (b) mecanismos de segurança
modernos, como segurança de nível de mensagem, assinatura web e criptografia web, e
(c) mecanismo de segurança dentro da API e seu serviços de backend como um terceiro
fator de segurança, como API baseada em token para autenticação de backend, infra-
estrutura de chave pública e protocolo de handshake de camada de transporte [Mollah
et al. 2017].
As API REST são desenvolvidas em muitas tecnologias e microsserviços
desenvolvidos usando diferentes tipos de linguagens de programação (Java, .NET, PHP,
Ruby, Phyton, Scala, NodeJs, etc.) e tecnologias persistentes (SQL, No-SQL, etc. ). Eles
podem ser gerenciados e expostos a clientes da web, que podem então acessar os
microsserviços e receber suas respostas através de um mecanismo de "livequery", pelo
qual as atualizações dos dados do banco de dados são comunicadas instantaneamente
aos clientes subscritores [Gadea et al. 2016].
O banco de dados NoSQL é usado nestas implementações. A natureza NoSQL
do banco de dados é essencial para fornecer a funcionalidade de escala, raspagem e
replicação esperada de arquiteturas modernas, bem como para suportar melhor os dados
hierárquicos necessários para a edição colaborativa de documentos [Almeida et al.
2017].
A popularidade da arquitetura baseada em microsserviço é evidente a partir do
relatório do portal de empregos populares, em que o número de oportunidades de
trabalho em tecnologias relacionadas com microsserviços, como JSON e REST cresceu
770
mais de 100 vezes nos últimos seis anos, enquanto que empregos em áreas de tecnologia
semelhantes como SOAP e XML permaneceram quase idênticos. As soluções para
microsserviços procuram implementar algoritmos simples que atendam necessidades
específicas com os elementos apresentados nesta seção [Almeida et al. 2017].
8.5 Ambiente de Computação em Nuvem
A arquitetura de desenvolvimento de microserviço está diretamente relacionada com
duas tecnologias Cloud Computing e Contêiner, cloud computing parte-se do
pressuposto que para proporcionar um ambiente seguro e descentralizado utilizam-se os
datacenters já existentes, considerando até mesmo o aspecto financeiro para
disponibilidade da aplicação.Cloud Computing é conceituado por [Veras 2012] como
um conjunto de recursos virtuais facilmente utilizáveis acessíveis, tais como hardware,
software, plataformas de desenvolvimento e serviços. Esta arquitetura possui 03 (três)
modelos disponíveis Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e
Infraestrutura como Serviço (IaaS), [Richter et al. 2017] descreve estes modelos como:
• SaaS –Tem como objetivo proporcionar um ambiente de nuvem para que

os consumidores disponibilizem suas aplicações;
• PaaS –Visa disponibilizar um ambiente completo em cloud de

desenvolvimento do ciclo de vida de um software;
• IaaS - Proporcionar uma infraestrutura de TI para processamento e

armazenamento de forma transparente para o consumidor.
Quanto aos aspectos que concernem ao modelo de implantação a arquitetura de

Cloud Computing pode ser classificada em Privada, Pública e Híbrida [Veras 2013]
aborda esta classificação da seguinte maneira:
• Privada - Compreende uma infraestrutura de Cloud Computing operada e

quase sempre gerenciada pela organização cliente;
• Pública - disponibilizada publicamente através do modelo pague-por-uso.
• Híbrida - a infraestrutura é uma composição de duas ou mais nuvens

(privadas, públicas ou comunitárias) que continuam a ser entidades únicas,
porém conectadas através de tecnologias proprietárias ou padronizadas que
propiciam a portabilidade dedados e aplicações.
8.5.1 Docker
Segundo abordado no tópico anterior o ambiente de rede mais adequado para

disponibilizar microserviços é em Cloud Computing, contudo quando se refere a
arquitetura do sistema operacional o mais empregado é o Contêiner através do Docker,
considerando os aspectos de facilidade de implantação e gerenciamento.
Conceitualmente segundo [Romero 2016] Docker é uma ferramenta para criar e

manter containers, ou seja, ele é responsável por armazenar vários serviços de forma
isolada do sistema operacional hospedeiro. O principal responsável por este isolamento
é o Linux Container (LXC) no qual [Smiler and Agrawal 2016] descreve como um
771
ambiente de virtualização leve fornecido pelo kernel do Linux para fornecer

virtualização ao nível do sistema sem executar um hypervisor.
O LXC ainda possui como componentes: CGROUP que tem como objetivo
limitar os recursos de hardware, como isolar a memória para cada contêiner,
NAMESPACE cria um grupo de processos proporcionando um isolamento de
aplicações e CHROOT disponibiliza um diretório raiz para cada contêiner, a imagem
8.1, apresenta esta arquitetura.
Imagem 8.1. Linux Container [Smiler and Agrawal 2016]
A biblioteca libvirt descrita na figura anterior disponibiliza um conjunto de

ferramentas para interagir com os recursos de virtualização do Kernel do Sistema
Operacional.
8.5.2 Amazon AWS
Os principais provedores de nuvem Google Cloud, Amazon e Azure possuem ambiente
de orquestração de contêiner, todavia o capítulo irá se resumir a apresentar a estrutura
de disponibilização de microserviço na Amazon AWS.
A Amazon oferece um conjunto de serviços que juntos formam uma confiável,
plataforma de computação escalável e barata [Bracci et al. 2012], conforme podemos
observar no site https://aws.amazon.com/pt/.
8.6 Implementação de Microsserviço
A implementação de microsserviços está atrelada ao negócio em que ele está inserido
dessa forma será feito uma breve apresentação do projeto para entendimento do
contexto geral da aplicação e da implementação adotada para o microsserviço a ser
apresentado.
Para disponibilização de um microsserviço com docker em ambiente cloud da
Amazon é necessário seguir os seguintes passos:
Cadastrar-se na AWS;
Instalar a AWS CLI;
772
Criar um repositório no ECS;

Instalar o Docker;
Criar uma imagem do Docker;
Enviar a imagem docker para o repositório;
Criar uma tarefa para disponibilizar um contêiner.
Não será abordado neste capítulo com maiores detalhes os aspectos referentes
aos passos citados anteriormente, considerando que a Amazon disponibiliza um manual
com toda a configuração, segue abaixo link de acesso:
http://docs.aws.amazon.com/pt_br/AmazonECR/latest/userguide/ecr-ug.pdf
8.6.1 Contexto de Negócio

Buscando promover a mobilidade urbana através dos mototaxis e facilitar a localização
dos provedores do serviço, em especial nos locais de difícil acesso, aumentando a
segurança para os clientes por terem a certeza de estar utilizando um serviço
normatizado com um motoqueiro habilitado e acrescentando agilidade no atendimento,
o MotoEasy tem por objetivo organizar este segmento que está em crescimento na área
de transporte de passageiros, disponibilizando uma ferramenta de comunicação mobile
entre o cliente e o mototaxi de maneira rápida e eficaz.
Através do aplicativo será possível ao passageiro solicitar um mototaxi e
acompanhar o percurso do profissional que aceitou o seu pedido, sendo informado antes
do início da corrida o valor a ser pago. O cliente poderá avaliar, ao final da corrida, o
serviço do profissional que o atendeu e incluir uns comentários a respeito do
profissional, esta avaliação busca informar ao mototaxista seus pontos positivos e
negativos.
O mototaxista terá a facilidade de receber em seu dispositivo mobile a
solicitação de corridas próximas ao local em que ele se encontra. Será possível também
a verificação de todas as corridas realizadas e de relatórios financeiros para o
mototaxista ter maior controle sobre o seu serviço, assim como a verificação dos
comentários e avaliações do seu perfil, permitindo-o melhorar seus serviços de acordo
com a opinião dos clientes.
8.6.2 Apresentação do microsserviço de localização
O Sistema MotoEasy faz uso constante de chamadas em APIS de localização
implantadas no nosso servidor de API.
Com a proposta da extração do serviço de localizações do servidor para um
microsserviço em separado, podemos balancear as requisições e até mesmo ganhar em
reaproveitamento de código, visto que agora se tem um serviço especialista em um local
especifico, podendo ser utilizado pelas mais diversas aplicações da solução e inclusive
facilitando o deploy caso seja necessário, onerando apenas uma parte do sistema, a
imagem 8.2 apresenta algumas telas do aplicativo.
773
Imagem 8.2. Telas do Aplicativo Moto Easy
Abaixo segue, imagem 8.3 e 8.4, um demonstrativo de como o servidor principal provia
o serviço antes da construção do microsserviço.
Imagem 8.3. Serviço de Localização
774
Imagem 8.4. Interface do Serviço de Localização

8.6.3. Refatoração do Projeto para inclusão do microsserviço
Neste capítulo o objetivo é extrair a funcionalidade de dentro do projeto principal,
criando um microsserviço em separado para isolar as requisições e melhorar a
disponibilidade do recurso. A ideia é mover a funcionalidade de busca de informações
entre dois pontos para um microsserviço, sendo este o único responsável pela chamada
dos métodos da API de mapas para obtenção dos dados.
Com essa extração, se consegue abstrair algumas informações técnicas da API
de mapas sendo esta do Google ou de qualquer outra API disponível para este fim,
conseguindo assim inclusive garantir a disponibilidade do serviço tentando em várias
APIS separadas caso necessário.
A linguagem utilizada para a refatoração do projeto foi a mesma do projeto

principal, JAVA, mas nada impede que esta funcionalidade seja criada em outra
linguagem visto que o protocolo de comunicação entre serviços ainda é o mesmo, ou
seja Rest.
Ferramentas necessárias para a construção do microsserviço em Java:
 Java SDK 32 bits ou 64 bits, conforme desejar
 Ide Java (No exemplo utilizamos o Netbeans)
Na implementação será utilizado o framework Rest (Jersey), um framework
bastante robusto, que está em constante evolução e com acesso a varias funcionalidades.
Para a criação do projeto vamos utilizar o gerenciador de dependências “Maven”, para
não precisarmos nos preocupar com as dependências do projeto. Com o Netbeans
aberto, imagem 8.5, escolhe-se a opção (Arquivo/Novo Projeto/ Maven / Aplicação
Web)
775
Imagem 8.5. Tela Novo Projeto
Imagem 8.6. Pasta de Códigos-Fontes

Após criado o projeto, deverá ser inserido no arquivo “pom.xml” as
dependências necessárias para a implementação do microsserviço, neste caso o Jersey
para a implementação dos recursos em Rest conforme imagem 8.7 abaixo.
776
Imagem 8.7. Arquivo pom.xml

Logo em seguida crie um pacote para armazenar informações de acesso a API
do Google, no exemplo foi criado o pacote infra. Dentro do pacote foi criada uma classe
para as informações do acesso, denominada “Urls.java”, imagem 8.8.
Imagem 8.8. Arquivo Urls.java

Para se obter as informações de distância entre dois pontos ou até mesmo
duração de uma viagem, se faz necessário a obtenção da chave de acesso da API do
Google através do site https://developers.google.com/maps/documentation/distance-
matrix/start?hl=pt-br#get-a-key, para poder fazer uso dos recursos da API “distance
matrix API”. Para obter a chave deve-se clicar no botão “obter uma chave” da página.
imagem 8.9.
777
Imagem 8.9. Api Google Maps

Crie um projeto para ser identificado pela Google, e clique na opção “Create and
Enable API”, imagem 8.10.
Imagem 8.10. Tela Create and Enable API

Logo em seguida o Google irá disponibilizar uma chave para uso na url de
chamada da API, onde passados os parâmetros, se obtém como retorno informações na
representação em JSON, imagem 8.11 abaixo.
Imagem 8.11. Chave Gerada
778
Obtidas as informações necessárias do Google, na classe anteriormente criada

define-se duas constantes, demonstrada na imagem 8.12:
CHAVE_API_MAPS – Chave obtida através da API do Google
URL_GOOGLE_MATRIX - Url na qual serão passados os parâmetros. Na url estará
contida como um dos parâmetros a chave da API do Google.
https://maps.googleapis.com/maps/api/distancematrix/json?origins=%1$s&destinations
=%2$s&mode=driving&language=pt-BR&key="+CHAVE_API_MAPS
Imagem 8.12. Código-Fonte da Aplicação

Agora deverá ser criado outro pacote para inserirmos os recursos do
microsserviço, no caso o recurso de geolocalização. Também serão criadas uma classe
concreta e uma interface para implementar os serviços da API, conforme imagem 8.13.
Imagem 8.13. Serviço de Localização

Na interface coloca-se a assinatura da API que irá ser exposta no microsserviço.
Neste caso, os parâmetros a serem passados pelo serviço serão os exigidos pelo Google
para a chamada do método, imagem 8.14.
Imagem 8.14. Assinatura da API
779
Na classe concreta “ServiceLocationResourceImpl.class”, deverá ser

implementada o serviço da interface, conforme demonstrado na imagem 8.15.
Imagem 8.15. Código-Fonte

Na classe que herda de Application, deverá haver a adição do recurso recém-
criado do servidor, no caso a classe concreta da interface de localização, a
“ServiceLocationResourceImpl.class”, imagem 8.16.
Imagem 8.16. Classe Concreta

Deverá ser criado o arquivo de configuração do servlet do servidor, ou seja, o
arquivo “web.xml”, conforme imagem 8.17.
780
Imagem 8.17. Menu

Ainda no web.xml, imagem 8.18, deverá ser incluído as configurações do
servlet, para apontar para a classe na qual carrega todas as configurações para o
servidor.
Imagem 8.18. Arquivo web.xml

Feitas as devidas implementações e configurações, basta construir o projeto e o
conteúdo gerado, no caso o arquivo .war deverá ser implantado em um servidor de
aplicação como o tomcat ou o glassfish.
8.6.4. Apresentação do sistema com o microsserviço de localização

Com a alteração proposta, extraímos a aplicação para um serviço em separado conforme
imagem 8.19 abaixo.
Imagem 8.19. Microsserviço de Localização
O serviço foi extraído da aplicação principal de APIS e criado uma aplicação

separada, sendo este especialista em localizações, imagem 8.20.
781
Imagem 8.20. Api Localização

A imagem 8.21 abaixo exibe um exemplo de como é feita a solicitação de
distância entre dois pontos, anteriormente provida pelo servidor de API e agora pelo
microsserviço Location.
Imagem 8.21. Arquivo JSON
Foi necessária a alteração no Android, nos aplicativos mototaxista e passageiro

para comportar o novo serviço, imagem 8.22.
Imagem 8.22. Declaração da URL no App

O sistema MotoEasy utiliza o serviço de localização para realizar algumas
atividades como calcular distância, tempo e até o valor da corrida a ser realizada pelo
passageiro. Abaixo segue o exemplo das aplicações do uso do microsserviço criado de
localização, imagem 8.23.
782
Exemplo de cálculo de tempo Exemplo de cálculo de Calculo de tempo de chegada

e valor da corrida do estimativa de chegada do do mototaxista até o
passageiro mototaxista. passageiro em tempo real
Imagem 8.23. Telas do App Moto Easy
8.7. Conclusões
A arquitetura de microsserviço é o padrão arquitetural em voga no mercado de software
atualmente, a constante necessidade de evolução das aplicações e sistemas tem levado
as empresas a migrar suas soluções monolíticas para essa nova arquitetura.
Quando um projeto de software se inicia atualmente as aplicações devem ser

pensadas para o ambiente de computação em nuvem e conforme foi demonstrando nesse
capítulo a construção dessas soluções pode cada vez mais resolver problemas do dia-a-
dia das organizações. Também foram demonstradas as estruturas e elementos
necessários para um patamar mínimo de organização das aplicações. Essas soluções
podem se tornar problemáticas, pois a complexidade de desenvolvimento é maior do
que nas arquiteturas que surgiram anteriormente, além das questões de segurança,
privacidade e padronização que são fundamentais para a sustentação de sistemas
robustos.
Conclui-se que o arcabouço necessário para a construção de microsserviços se

devidamente implementados poderão trazer ganhos para as organizações na entrega de
soluções cada vez mais alinhadas ao negócio e flexíveis a incorporação de mudanças.
8.8. Referências
Almeida, W. H. C., Monteiro, L. D. A., Hazin, R. R., Lima, C. De and Ferraz, F. S.
783
(2017). Survey on Microservice Architecture - Security , Privacy and

Standardization on Cloud Computing Environment. ICSEA 2017, n. c, p. 199–
205.
Bakshi, K. (2017). Microservices-based software architecture and approaches. IEEE

Aerospace Conference Proceedings,
Bracci, F., Corradi, A. and Foschini, L. (2012). Database security management for
healthcare SaaS in the Amazon AWS Cloud. Proceedings - IEEE Symposium on
Computers and Communications, p. 000812–000819.
Fowler, Marthin; Lewis, J. (2014). Microservices: a definition of this new architectural

term. https://martinfowler.com/articles/microservices.ml, [accessed on May 7].
Gadea, C., Trifan, M., Ionescu, D. and Ionescu, B. (2016). A reference architecture for
real-time microservice API consumption. Proceedings of the 3rd Workshop on
CrossCloud Infrastructures & Platforms - CrossCloud ’16, p. 1–6.
Giessler, P., Steinegger, R., Abeck, S. and Gebhart, M. (2016). Checklist for the API
Design of Web Services based on REST. v. 9, n. 3, p. 41–51.
Krylovskiy, A., Jahn, M. and Patti, E. (2015). Designing a Smart City Internet of Things
Platform with Microservice Architecture. Proceedings - 2015 International
Conference on Future Internet of Things and Cloud, FiCloud 2015 and 2015
International Conference on Open and Big Data, OBD 2015, p. 25–30.
Mollah, M. B., Azad, M. A. K. and Vasilakos, A. (2017). Security and privacy

challenges in mobile cloud computing: Survey and way ahead. Journal of
Network and Computer Applications, v. 84, p. 38–54.
Richter, D., Konrad, M., Utecht, K. and Polze, A. (2017). Highly-Available

Applications on Unreliable Infrastructure: Microservice Architectures in Practice.
2017 IEEE International Conference on Software Quality, Reliability and Security
Companion (QRS-C), p. 130–137.
Romero, D. [Ed.] (2016). Containers com Docker. 1. ed. São Paulo: Casa do Código.
Savchenko, D. I., Radchenko, G. I. and Taipale, O. (2015). Microservices validation:

Mjolnirr platform case study. 2015 38th International Convention on Information
and Communication Technology, Electronics and Microelectronics, MIPRO 2015
- Proceedings, n. May, p. 235–240.
Smiler, K. and Agrawal, S. [Eds.] (2016). Learning CoreOS. 1. ed.
Veras, M. (2012). Cloud Computing: Nova Arquitetura da TI. São Paulo: Brasport. v. 1
Veras, M. [Ed.] (2013). Arquitetura de Nuvem: Amazon Web Services (AWS). Rio de
Janeiro: .
Villamizar, M. and Et al (2015). Evaluating the Monolithic and the Microservice
784
Architecture Pattern to Deploy Web Applications in the Cloud Evaluando el

Patrón de Arquitectura Monolítica y de Micro Servicios Para Desplegar
Aplicaciones en la Nube. 10th Computing Colombian Conference, p. 583–590.
Yale Yu, Silveira, H. and Sundaram, M. (2016). A microservice based reference

architecture model in the context of enterprise architecture. 2016 IEEE Advanced
Information Management, Communicates, Electronic and Automation Control
Conference (IMCEC), p. 1856–1860.
785
Capítulo
9
Deep Learning: Uma Introdução às Redes Neurais
Convolucionais
Marcos Vinícius dos Santos Ferreira, Kelly Maria da Silva Oliveira, Antonio
Oseas de Carvalho Filho e Alcilene de Sousa
Abstract
Convolutional networks have played an important role in the history of deep learning.
They are a key example of a successful decomprehension application obtained by studying
the brain for machine learning applications. Convolutional networks were also some
of the first neural networks to re-solve important commercial applications and remain
at the forefront of today’s deep learning applications. In this chapter, deep learning
will be introduced into convolutional neural networks in theory and practice since the
understanding of how convolutional neural networks work with images are not trivial
tasks.
Resumo
As redes convolucionais têm desempenhado um papel importante na história do

aprendizado profundo. Elas são um exemplo chave de uma aplicação bem-sucedida de
compreensão obtidos pelo estudo do cérebro para aplicações de aprendizado de máqui-
nas. As redes convolucionais também foram algumas das primeiras redes neurais a re-
solver importantes aplicações comerciais e permanecem na vanguarda das aplicações
de aprendizado profundo hoje. Nesse capítulo será introduzido o aprendizado profundo
abordando as redes neurais convolucionais em teoria e prática visto que o entendimento
de como as Redes Neurais Convolucionais trabalham com imagens não são tarefas trivi-
ais.
9.1. Introdução
O Aprendizado de Máquina (AM), são explorações que estudam o desenvolvimento de
métodos capazes de extrair conhecimento a partir de amostras de dados. Existem diversos
algoritmos de aprendizado de máquina cuja finalidade é admitir que, após um determinado
786
treinamento com certo conjunto de dados cujas instâncias têm classificação conhecida,
uma máquina seja capaz de interpretar novos dados e classificá-los de maneira apropriada
a partir de uma generalização do que lhe foi oferecido [Libralão et al. 2003]. Existem três
paradigmas referentes à forma de aprendizagem:
• Aprendizado Supervisionado: utiliza supervisores para obter o melhor modelo

desejado na fase de treinamento, ou seja, agente externo que fornece à rede o com-
portamento desejado com intuito de obter a saída desejada.
• Aprendizado não supervisionado: permite que o algoritmo aprenda a reunir en-

tradas segundo alguma medida de similaridade entre as entradas, com intuito de
agrupá-las.
• Aprendizado por reforço: onde o aprendizado ocorre por meio de recompensas,

dependendo do desempenho apresentado.
As Redes Neurais Artificiais (RNAs) inspiram a criação de alguns algoritmos de

AM [Libralão et al. 2003]. Uma RNA é uma máquina projetada para modelar a maneira
que o cérebro realiza uma tarefa em particular ou função de interesse; a rede é normal-
mente implementada usando componentes eletrônicos ou é simulada por programação em
um computador digital. Conhecidos como nós, as redes neurais se utilizam de estruturas
que funcionam semelhantes a neurônios [Haykin 2001].
Uma rede neural é composta por um conjunto extremamente complexo de neurô-
nios e, entre eles, a comunicação é realizada através de impulsos. As redes neurais bi-
ológicas não transmitem sinais negativos, ao contrário das redes neurais artificiais, sua
ativação é medida pela frequência com que os pulsos são emitidos [Haykin 2001]. As re-
des naturais não são uniformes como as redes artificiais, e apresentam certa uniformidade
apenas em alguns pontos do organismo. Os principais constituintes de um neurônio são
ilustrados na Figura 9.1:
Figura 9.1. Neurônio Biológico. Fonte: [Morais 2017]
787
• Dendritos: responsáveis por receber os estímulos transmitidos pelos outros neurô-

nios;
• Corpo Celular: responsável por coletar e combinar informações vindas de outros

neurônios;
• Axônio: responsável por transmitir os estímulos para outras células (constituído de

uma fibra tubular que pode alcançar até alguns metros).
Um neurônio é uma unidade de processamento de informação que é fundamental

para a operação de uma rede neural [Haykin 2001]. A Figura 9.2 ilustra os elementos da
arquitetura mais comum de uma RNA.
Figura 9.2. Neurônio Artificial. Fonte: [Morais 2017]
• Entrada: a camada que produz a saída (resultado) decorrente do meio externo.
• Sinapses: ou elos de conexão, emulado através de pesos w1, w2,..., wn acoplados

as entradas dos neurônios responsáveis por fazer um valor excitatório ou inibitório.
• Bias: ou viés, cujo propósito é permitir uma melhor adaptação da função de ativa-
ção, ao qual possui dependência quanto a seu valor ser positivo ou negativo, e que
poderá aumentá-lo ou diminuí-lo.
• Somador: soma as entradas, ponderadas pelas respectivas sinapses de neurônio;
• Função de ativação: se refere a restrição do intervalo permissível de amplitude do

sinal de saída a valor finito.
• Saída: valor final produzido por um neurônio.
9.2. Convolutional Neural Network

A aprendizagem profunda ou Deep Learning é parte de uma família mais abrangente de
métodos de AM baseados na aprendizagem de representações de dados. Uma observação,
por exemplo, uma imagem, pode ser representada de várias maneiras, tais como um vetor
de valores de intensidade por pixel, ou de uma forma mais abstrata como um conjunto de
788
arestas, regiões com um formato particular, etc. Algumas representações são melhores
do que outras para simplificar a tarefa de aprendizagem. Uma das promessas da apren-
dizagem profunda é a substituição de características feitas manualmente por algoritmos
eficientes para a aprendizagem de características supervisionada ou semi-supervisionada
e extração hierárquica de características [Song e Lee 2013]. A Figura 9.3 faz um breve
resumo sobre o surgimento.
Figura 9.3. Linha do Tempo. Fonte [Beam 2017]
1943 - McCulloch e Pitts projetaram a estrutura que é conhecida como a primeira

rede neural, apresentaram um modelo de neurônio como uma unidade de processamento
binária e provaram que esta unidade era capaz de executar muitas operações lógicas.
1957 - Rosenblatt introduziu uma nova abordagem para o problema de reconheci-
mento de padrões com o desenvolvimento do Perceptron [Rosenblatt 1958]. Esta aborda-
gem era a mais simples configuração de RNA. Com apenas uma camada contendo apenas
um neurônio. Seu propósito inicial era implementar um modelo computacional inspirado
na retina, objetivando-se então um elemento de percepção eletrônica de sinais.
1960- Bernard Widrow e M. Holf, desenvolveram um novo tipo de elemento de
processamento de redes neurais chamado de Adaptive Linear Element (Adaline). A dife-
rença entre o Adaline e o Perceptron está no procedimento de aprendizagem [Haykin 2001].
1969 - Minsky e Papert analisaram matematicamente o Perceptron e demonstra-
ram que redes de uma camada não são capazes de solucionar problemas que não sejam
linearmente separáveis. Tal restrição implicava que padrões de entrada similares que
resultase em padrões de saídas similares, levaria o sistema à incapacidade de aprender
importantes mapeamentos. A função ou-exclusivo (XOR) é um exemplo clássico deste
caso.
1969 a 1982 - um período em que pouco se publicou.
1986 - Rumelhart, Hinton e Williams desenvolveram o algoritmo de treinamento
backpropagation que permitiu o treinamento eficientemente de redes com camadas in-
termediárias [Rumelhart et al. 1985]. Este algoritmo resultou nas RNAs mais utilizadas
atualmente, as redes Multi-Layer Perceptron (MLP), treinadas com o algoritmo backpro-
789
pagation. Nesta arquitetura existem múltiplas camadas de neurônios, sendo que cada um
deles está conectado a todos os neurônios da camada seguinte.
1995 – Ascensão da Support Vector Machines (SVM).
2006 – Hinton, Simon Osindero e Yee-Whye Teh publicaram um artigo em 2006
que foi visto como um avanço significativo o suficiente para reavivar o interesse em re-
des neurais. O artigo "Um Algoritmo de Aprendizado Rápido para Redes de Crença
Profunda"[Hinton et al. 2006], foi responsável por lgo que mais tarde se transformaria o
termo “Deep Learning”.
O Aprendizado Profundo permite modelos computacionais que compõem múlti-
plas camadas de processamento aprender representações de dados com múltiplos níveis
de abstração. Esses métodos melhoraram drasticamente o estado da arte no reconheci-
mento de fala, reconhecimento de objetos visuais, detecção de objetos e muitos outros
domínios, como descoberta de medicamentos e genômica. Um dos tipos mais ampla-
mente utilizados de Deep Learning são as redes neurais convolucionais ou Convolutional
Neural Network (CNN) proposta por [LeCun et al. 1990].
As CNNs são uma arquitetura treinável, biologicamente inspirada que possui a ca-
pacidade de aprendizado no que se refere a características invariantes [LeCun et al. 2010].
As CNNs são variantes de MLPs inspiradas biologicamente e que consistem em um con-
junto de camadas que extraem características de imagens de entrada, fazendo sucessivas
convoluções e redimensionando de modo que no final consiga ter apenas a marca da classe
a que a imagem de classe pertence.
A arquitetura de uma CNN é um paradigma extremamente versátil, porém con-
ceitualmente simples, que pode ser aplicada a uma extensa gama de tarefas perceptivas.
Embora a CNN tradicional treinada com a aprendizagem supervisionada seja muito eficaz,
o treinamento pode exigir uma grande quantidade de amostras de treinamento rotuladas
[LeCun et al. 2010].
Uma CNN é composta por uma ou mais camadas convolucionais, muitas vezes
seguidas de camadas de Pooling, e depois seguidas por uma ou mais camadas totalmente
conectadas como em uma rede neural multicamada padrão. A arquitetura de uma CNN foi
projetada para aproveitar a estrutura 2D de uma imagem de entrada, ou outra entrada 2D,
como um sinal de fala. Isto é conseguido com conexões locais e pesos ligados, seguidos de
alguma forma de agrupamento que resulta em características invariantes. Outro benefício
da CNN é que são mais fáceis de treinar e têm muitos parâmetros menos do que redes
totalmente conectadas com o mesmo número de unidades escondidas.
A CNN é uma rede neural que implementa várias camadas distintas, sendo que as
principais são as: convolucionais, de Pooling e totalmente conectadas ou Fully-connected.
A camada convolucional tem por funcionalidade extrair atributos dos volumes de entra-
das. A camada de Pooling é responsável por reduzir a dimensionalidade do volume re-
sultante após as camadas convolucionais, ajudando a tornar a representação invariante a
pequenas translações na entrada. Por fim, a camada totalmente conectado é responsável
pela propagação do sinal por meio da multiplicação ponto a ponto e uso de uma função
de ativação. A Figura 9.4 ilustra as três principais camadas da CNN descrita.
790
Figura 9.4. Arquitetura de uma CNN. Fonte: Modificada de [Spark 2017]
As CNNs se mostraram eficientes para a Processamento de Linguagem Natural

com excelentes resultados na análise semântica, recuperação de consulta de busca, mode-
lagem de sentenças, e outras tarefas tradicionais de Processamento da Linguagem Natural
[Kim 2014]. Desde então, uma série de empresas vêm vindo utilizando o aprendizado
profundo no centro de seus serviços. O Facebook usa redes neurais para seus algoritmos
de marcação automática, o Google para sua pesquisa de fotos, Amazon para suas reco-
mendações de produtos, Pinterest para sua personalização de feed doméstico e Instagram
para sua infraestrutura de pesquisa.
9.2.1. Camada Convolucional

A camada Convolucional é o bloco de construção central de uma rede neural convolu-
cional que faz a maior parte do levantamento pesado computacional. Nessa camada é
empregada a operação de convolução, que é o tratamento de uma matriz (I) por outra
(K) chamada kernel que tem por função aplicar filtros na matriz (I) para destacar/mapear
características. Nesse tratamento é feito a somatória do produto ponto a ponto entre os
valores da matriz kernel (K) e cada posição da matriz (I). A Figura 9.5 ilustra o exem-
plo descrito de uma convolução gerando outra matriz (I*K) com as características mais
relevantes.
Figura 9.5. Convolução entre as matrizes. Fonte: Modificada de [Spark 2017]
791
Existem três parâmetros que controlam o tamanho do volume resultante da ca-

mada convolucional: profundidade (depth), passo (stride) e zero-padding. Cada um dos
filtros será responsável por extrair características diferentes no volume de entrada. Por-
tanto, quanto maior o número de filtros maior o número de características extraídas, po-
rém a complexidade computacional, relativa ao tempo e ao uso de memória, também será
maior [Araújo et al. ].
9.2.2. Camada de Pooling

Após a camada de Convolução que faz um mapa de características, vem a camada de
pooling que modifica ainda mais a saída da camada. Essa camada é responsável por
reduzir a dimensionalidade de cada mapa de características, mas mantém as informações
mais importantes.
A operação de pooling pode ser de diferentes tipos: máximo, média, soma etc. No
caso máximo, tem-se o Max Pooling, definimos um bairro espacial (por exemplo, uma
matriz 2 × 2) e tire o maior elemento do mapa de recursos retificados dentro dessa janela.
Em vez de tomar o maior elemento, também poderíamos tomar a média (agrupamento
médio) ou a soma de todos os elementos nesta janela. Na prática, o Max-Pooling mostrou
funcionar melhor. Além de reduzir o tamanho da imagem, consequentemente reduzindo
o processamento para as próximas camadas, essa técnica também auxilia no tratamento
de invariâncias locais [Ferreira 2017]. A Figura 9.6 demostra como ocorre a operação de
-pooling em uma mapa de características.
Figura 9.6. Operação de Max-Pooling. Nós deslizamos a matriz de 2 × 2 por 2

células (também chamado de "stride") e leva o valor máximo em cada região.
Modificada de [Deshpande 2016b]
9.2.3. Camada Fully-connected

A camada Totalmente Conectada ou Fully-connected é um rede neural Multi Layer Per-
ceptron tradicional que usa geralmente uma função de ativação softmax na camada de
saída. O termo “Totalmente Conectado” implica que cada neurônio na camada anterior
está conectado a cada neurônio na próxima camada.
O resultado das camadas convolutivas e de pooling é a extração de característi-
cas de alto nível da imagem de entrada. O objetivo da camada Totalmente Conectada é
usar esses recursos para classificar a imagem de entrada em várias classes com base no
792
conjunto de dados de treinamento.
9.2.4. Arquiteturas
Nos últimos anos, as áreas de aplicação de redes neurais profundas foram rapidamente
expandidas. Várias trabalhos envolvendo arquiteturas com uma única abordagem para di-
ferentes problemas, entre as quais podemos destacar: AlexNet (2012), GoogleNet (2014),
VGGNet (2014), ResNet (2015).
9.2.4.1. AlexNet (2012)
Em 2012, Alex Krizhevsky, Ilya Sutskever e Geoffrey E. Hinton projetaram a AlexNet

[Krizhevsky et al. 2012]. Treinaram uma rede para classificar 1,2 milhões de imagens de
alta resolução no concurso ImageNet Large Scale Visual Recognition Competition (ILS-
VRC) 2010 em 1.000 possíveis categorias. A rede era composta por 5 camadas convolu-
cionais, camadas de max-pooling e três camadas totalmente conectada com dropout. O
concurso consiste em vários times que competem para saber quem implementa o modelo
mais eficiente para classificação, detecção e localização de objetos em imagens.
O ILSVRC 2012 ficou marcado como o primeiro ano no qual uma CNN atingiu o
primeiro lugar desse desafio, com uma taxa de erro de teste de top-5 vencedora de 15,3%,
em comparação com 26,2% alcançada pela segunda melhor entrada. A rede AlexNet
introduzida em Krizhevsky et al. (2012) foi um marco para a divulgação da CNN na
comunidade de visão computacional. Foi a primeira vez que um modelo foi executado tão
bem em um conjunto de dados ImageNet historicamente difícil, a mesma foi responsável
por influenciar dezenas de outras redes convolucionais para reconhecimento de padrões
em imagens.
9.2.4.2. ZF Net (2013)
Após o sucesso da AlexNet em 2012, vários modelos baseados em CNN foram submeti-
dos para o ILSVRC 2013. O vencedor em 2013 foi a rede construída por Zeiler e Fergus,
2013 com um modelo que obteve uma taxa de erro de 11,2%. Esta arquitetura foi con-
cebida a partir de modificações na arquitetura AlexNet, e desenvolveu algumas idéias
básicas sobre como o seu desempenho poderia ser melhorado. A maior contribuição de
Zeiler e Fergus foi o detalhamento do modelo proposto e o desenvolvimento da técnica
DeConvNet (Deconvolutional Network), que consiste na forma de visualização dos ma-
pas de características da rede [Zeiler e Fergus 2014]. A Figura 9.7 ilustra exemplos de
imagens de entrada e das regiões que ativam os filtros.
A ideia básica de como isso funciona é que, em todas as camadas da CNN treinada,
é anexado uma “DeConvNet” que possui um caminho de volta aos pixels da imagem. A
técnica permite operações reversas de pooling até o momento em que a imagem atinja seu
tamanho original. Esta operação possibilita a verificação de como cada camada presente
na CNN, ler a imagem de entrada e quais regiões ativam os filtros.
793
Figura 9.7. Exemplos de imagens de entrada e das regiões que ativam os filtros.
Modificada [Deshpande 2016a]
9.2.4.3. GoogLeNet (2015)
GoogLeNet proposto por [Szegedy et al. 2015], foi o primeiro modelo que introduziu a
ideia de que as camadas das CNNs poderiam ser executadas paralelamente. A arquitetura
do módulo Inception, uma rede de 22 camadas profundas, iniciou um patamar elevado
de classificação e detecção no que diz respeito a recursos de reconhecimento visual 3D
WideNet 2014 (ILSVRC14) da ImageNet, com uma taxa de erro de 5 maiores de 6,7%.
Figura 9.8. Arquitetura da GoogLeNet. Modificada [Deshpande 2016a]
Analisando a Figura 9.8, o módulo de inicialização permite que as execuções de

todas as operações sejam executadas em paralelo. Os módulos Inception ilustrados na
Figura 9.9 consistem de combinações paralelas de camadas com filtros convolucionais
794
de tamanho 1 × 1, 3 × 3 e 5 × 5. As camadas 1 × 1 fornecem um método de redução de

dimensionalidade.
Figura 9.9. Arquitetura do módulo Inception. Figura modificada de [Culurciello 2017]
Podemos destacar como a característica principal desta arquitetura, a melhor uti-

lização dos recursos computacionais dentro da rede. Com um design cuidadosamente
elaborado, que aumenta a profundidade e a largura da rede, melhorando o desempenho
da rede e diminuir o custo computacional. No ano seguinte, a rede conhecida como
Inception-v4 Szegedy et al. 2016, que consistia de alguns melhoramentos da GoogLeNet,
alcançou um top-5 erro de 3,08%.
9.2.4.4. VGG Net (2014)
Foi proposto por Simonyan e Zisserman, 2014 um modelo de CNN com até 19 camadas
que utilizava filtros 3 × 3 , obtiveram o segundo lugar do ILSVRC 2014 com taxa de erro
de 7,3% [Simonyan e Zisserman 2014]. Os autores concluíram que o modelo generaliza
bem uma ampla gama de tarefas e conjuntos de dados, combinando ou superando as
tubulações de reconhecimento mais complexas construídas em torno de representações
de imagem menos profundas. Os resultados confirmaram a importância da profundidade
nas representações visuais.
Foram testadas 6 arquiteturas diferentes, especificadas na Figura 9.10 , e a arqui-
tetura que apresentou o melhor desempenho foi a de rótulo D, que possuía 13 camadas
convolucionais, 5 de max-pooling e 3 totalmente conectadas.
9.2.4.5. Microsoft e ResNet (2016)
A rede ResNet proposta por [He et al. 2016], com 152 camadas era a rede mais profunda
já treinada no ImageNet. O sistema de rede residual profunda foi 8x vezes maior em pro-
fundidade que o VGG Net, utilizou o princípio de “aprendizagem residual” para orientar
os projetos de arquitetura de rede.
O desempenho dessa rede foi superior ao de seres humanos, conforme suas habili-
dades e área de conhecimento, normalmente obtém top-5 erro entre 5 e 10%. Tal façanha
795
Figura 9.10. Especificação das 6 arquiteturas da VGG testada, a D se sobressai.

Modificada de [Culurciello 2017]
resultou no 1o lugar na competição de classificação ILSVRC na ImageNet com 3,57% de

erro 5.
A ideia por trás dos blocos residuais é que uma entrada x passa por uma série de
operações de “convolução-relu-convolução”. O F(x) + x camada está adicionando, um
“novo conhecimento” a entrada x para a F(x) camada. Aqui, F(x) é o residual, como é
ilustrado na Figura 9.11.
Numa ResNet, a função F(x) funciona somente como um termo de regularização.
Portanto, o espaço de saída é somente uma alteração do espaço de entrada. Os autores
desta arquitetura entenderam que os mapas residuais são mais fáceis de serem otimizados
por meio dessa alteração no espaço de entrada.
9.3. Experimentos
Um dos primeiros problemas a ser tratado por CNN foi o reconhecimento de dígitos
em imagens. Para por em prática os conceitos visto sobre CNN afim de aumentar o
aprendizado, utilizaremos uma Rede Neural Convolucional Sequencial de 5 camadas para
796
Figura 9.11. Bloco residual. Modificada [Deshpande 2016a]
o reconhecimento de dígitos treinados no conjunto de dados MNIST [Deng 2012]. Para o

desenvolvimento escolheu-se construir com a API keras (Tensorflow backend)[ker 2017],
que é muito intuitivo. Em primeiro lugar, tem-se que preparar os dados (imagens de
dígitos manuscritos), em seguida é modelada, treinada e avaliada o modelo de CNN, para
por fim, fazer a predição dos dados de testes a partir dos pesos da rede treinada.
9.3.1. Preparação dos Dados

A primeira parte é a seleção de dados e tratamento para entrada na rede neural. Os dados
são lidos do arquivo train.csv que contém os valores dos pixeis de cada imagem junta-
mente com o rótulo de qual imagem pertence. Os dados são separados em:
• X_train: São os valores dos pixeis das imagens, que servem de entrada para a rede
neural aprender características e ajustar os pesos com o treinamento a partir desses
dados.
• Y_train: São os valores dos rótulos das imagens, ou seja, de 0 a 9, que servem
de saída desejada para a rede ajustar os pesos com o algoritmo backpropagation ao
longo das épocas no treinamento.
• X_test: São os valores dos pixeis das imagens, mas esses servem para teste, ou
seja, quando a rede esta treinada ela utiliza essas matrizes de pixeis para classificar
qual rótulo pertence. É utilizado exemplos diferentes dos treinados para testar a
capacidade de generalização da rede, o quanto ela consegue classificar amostras
diferentes das que foram treinadas.
• Y_test: São os valores dos rótulos das imagens, ou seja, de 0 a 9, mas esses também
são para teste, os chamadas rótulos verdadeiros, são os rótulos do conjunto de teste
797
X_test. Ele é utilizado para comparar com a saida da classificação da rede e calcular
a acurácia da classificação.
Após a separação para os dados de treinamento e teste, os dados são normalizados,

dado que a CNN trabalha melhor com valores no intervalo entre 0 e 1 e os valores dos
pixeis estarem entre 0 e 255. Em seguida os dados formatados são salvos para posteriores
operações, para diminuir processamento em posteriores operações de treinamento e em
seguida teste.
1 # pacotes essencias
import os
3 i m p o r t p a n d a s a s pd
i m p o r t numpy a s np
5 import seaborn as sns
from m a t p l o t l i b i m p o r t p y p l o t a s p l t
7 from k e r a s . u t i l s . n p _ u t i l s i m p o r t t o _ c a t e g o r i c a l # c o n v e r t t o one−h o t −
encoding
from s k l e a r n . m o d e l _ s e l e c t i o n i m p o r t t r a i n _ t e s t _ s p l i t
9
np . random . s e e d ( 2 )
11
13 # P r e p a r a c a o dos dados
15 # m a n i p u l a c a o de g r a f i c o s com m a t p l o i t
sns . s e t ( s t y l e = ’ white ’ , c o n t e x t = ’ notebook ’ , p a l e t t e = ’ deep ’ )
17
# n o r m a l i z a o s d a d o s e n t e 0 e 1 v i s t o que a CNN t r a b a l h a m e l h o r n e s s e
intervalo
19 def normalizacao ( data ) :
r e t u r n data / 255.0
21
23 def c r e a t e _ t r a i n _ d a t a ( ) :
25 # l e o s d a d o s de t r e i n o do a r q u i v o
t r a i n = pd . r e a d _ c s v ( o s . g e t c w d ( ) + " / MNIST / d a t a / i n p u t / t r a i n . c s v " )
27
# r o t u l o s para teinamento , saida desejada
29 Y_train = t r a i n [ " label " ]
31 # d e l e t a o s r o t u l o s de t r a i n
X _ t r a i n = t r a i n . drop ( l a b e l s =[ " l a b e l " ] , a x i s =1) # (42000 , 784)
33
# l i b e r a n d o mais espaco
35 del t r a i n
37 # e x i b e a q u a n t i d a d e de c l a s s e s que s e r a o e x i b i d a s
Y_train . value_counts ()
39 g = sns . countplot ( Y_train )
p l t . show ( )
41
# v e r i f i c a n d o os v a l o r e s n u l o s e a u s e n t e s
43 X _ t r a i n . i s n u l l ( ) . any ( ) . d e s c r i b e ( )
798
45
# Normaliza os dados
47 X_train = normalizacao ( X_train )
49
# muda a f o r m a em 3 d i m e n s o e s
51 X_tr ain = X_tr ain . v a l u e s . r esha pe ( −1 ,28 ,28 ,1) # (42000 , 28 , 28 , 1)
53
# C o d i f i c a a o de r o t u l o
55 Y _ t r a i n = t o _ c a t e g o r i c a l ( Y_train , num_classes =10)
57 # e x i b e g r a f i c a m e n t e a q u a n t i d a d e de i m a g e n s que contm c a d a c l a s s e
g = p l t . imshow ( X _ t r a i n [ 1 ] [ : , : , 0 ] )
59 p l t . show ( )
61 # s e t a sementes a l e a t o r i a s
random_seed = 2
63
# d i v i d e o s d a d o s de t r e i n o e v a l i d a c a o p a r a s e t a r no t r e i n a m e n t o
65 X_train , X_test , Y_train , Y_test = t r a i n _ t e s t _ s p l i t ( X_train ,
Y_train , t e s t _ s i z e =0.1 , r a n d o m _ s t a t e =random_seed )
67 # s a l v a o s d a d o s de treino e teste
np . s a v e ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / X _ t r a i n . npy ’ , X_train )
69 np . s a v e ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / X _ t e s t . npy ’ , X_test )
np . s a v e ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / Y _ t r a i n . npy ’ , Y_train )
71 np . s a v e ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / Y _ t e s t . npy ’ , Y_test )
73 r e t u r n X_train , X_test , Y_train , Y_test
75
# c a r r e g a o s d a d o s de t r e i n o a p a r t i r de a r q u i v o s s a l v o s
77 def l o a d _ t r a i n _ d a t a ( ) :
X _ t r a i n = np . l o a d ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / X _ t r a i n . npy ’ )
79 Y _ t r a i n = np . l o a d ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / Y _ t r a i n . npy ’ )
r e t u r n X_train , Y_train
81
def l o a d _ t e s t _ d a t a ( ) :
83 X _ t e s t = np . l o a d ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / X _ t e s t . npy ’ )
Y _ t e s t = np . l o a d ( o s . g e t c w d ( ) + ’ / d a t a _ n p y / Y _ t e s t . npy ’ )
85 r e t u r n X_test , Y_test
87 i f __name__ == ’ __main__ ’ :
create_train_data ()
Código Fonte 9.1. Preparação dos Dados.
9.3.2. Modelagem e treinamento da CNN

Usamos a API Keras, onde você tem apenas que adicionar uma camada de cada vez, a
partir da entrada. A primeira é a camada convolucional (Conv2D). É como um conjunto de
filtros aprendizes. Escolheu-se definir 32 filtros para as duas primeiras camadas conv2D
799
e 64 filtros para as duas últimas. Cada filtro transforma uma parte da imagem (definida
pelo tamanho do kernel) usando o filtro do kernel. A matriz do filtro do kernel é aplicada
em toda a imagem. Os filtros podem ser vistos como uma transformação da imagem.
A CNN pode isolar recursos que são úteis em todos os lugares a partir dessas imagens
transformadas (mapas de características).
A segunda camada importante na CNN é a camada de pooling (MaxPool2D). Esta
camada simplesmente atua como um filtro de amostragem descendente. Observa os 2
pixels vizinhos e escolhe o valor máximo. Estes são usados para reduzir o custo compu-
tacional e, em certa medida, também reduzem a superposição. Nós temos que escolher o
tamanho da pooling (ou seja, o tamanho da área agrupado a cada vez) mais a dimensão
da pooling é alta, mais importante é o downsampling. Combinou-se camadas convoluti-
vas e de agrupamento, pois a CNN é capaz de combinar recursos locais e aprender mais
recursos globais da imagem.
O Dropout é um método de regularização, onde uma proporção de nós na ca-
mada é ignorada aleatoriamente (definindo seus pontos como zero) para cada amostra de
treino. Isso gera aleatoriamente uma proposta da rede e força a rede a aprender recursos
de forma distribuída. Esta técnica também melhora a generalização e reduz a superpo-
sição. ’RELU’ é o retificador (função de ativação max (0, x). A função de ativação do
retificador é usada para adicionar não linearidade à rede.
A camada Flatten é usada para converter os mapas de recursos finais em um único
vetor 1D. Este passo de achatamento é necessário para que você possa usar camadas to-
talmente conectadas após algumas camadas convolutionais / maxpool. Combina todas as
características locais encontradas das camadas convolutivas anteriores. No final, usou-se
os recursos em duas camadas (densas) completamente conectadas, que é apenas um clas-
sificador de rede neural (ANN). Na última camada (Dense (10, activation = "softmax")),
a distribuição de saídas líquidas da probabilidade de cada classe.
# pacotes essencias
2 from k e r a s . c a l l b a c k s i m p o r t ReduceLROnPlateau , M o d e l C h e c k p o i n t
from k e r a s . l a y e r s i m p o r t Conv2D , MaxPool2D , Dropout , F l a t t e n , Dense
4 from k e r a s . m o d e l s i m p o r t S e q u e n t i a l
from k e r a s . o p t i m i z e r s i m p o r t RMSprop
6 from k e r a s . p r e p r o c e s s i n g . image i m p o r t I m a g e D a t a G e n e r a t o r
from m a t p l o t l i b i m p o r t p y p l o t a s p l t
8 from d a t a i m p o r t c r e a t e _ t r a i n _ d a t a
10 # f u n c a o que c r i a r a a r q u i t e t u r a da r e d e
d e f CNN( w e i g h t s _ p a t h =None ) :
12
model = S e q u e n t i a l ( ) # d e f i n e o model
14 # a d i c i o n a a s camadas de c o n v o l u c a o , max−p o o l i n g e D r o p o u t − camada
e x z t r a t o r a de c a r a c t e r i s t i c a s
model . add ( Conv2D ( f i l t e r s =32 , k e r n e l _ s i z e = ( 5 , 5 ) , p a d d i n g = ’ Same ’ ,
a c t i v a t i o n = ’ r e l u ’ , i n p u t _ s h a p e =(28 , 28 , 1) ) )
16 model . add ( Conv2D ( f i l t e r s =32 , k e r n e l _ s i z e = ( 5 , 5 ) , p a d d i n g = ’ Same ’ ,
activation=’ relu ’ ) )
model . add ( MaxPool2D ( p o o l _ s i z e = ( 2 , 2 ) ) )
18 model . add ( D r o p o u t ( 0 . 2 5 ) )
800
20 # a d i c i o n a a s camadas de c o n v o l u c a o , max−p o o l i n g e D r o p o u t − camada

e x z t r a t o r a de c a r a c t e r i s t i c a s
model . add ( Conv2D ( f i l t e r s =64 , k e r n e l _ s i z e = ( 3 , 3 ) , p a d d i n g = ’ Same ’ ,
22 model . add ( Conv2D ( f i l t e r s =64 , k e r n e l _ s i z e = ( 3 , 3 ) , p a d d i n g = ’ Same ’ ,
model . add ( MaxPool2D ( p o o l _ s i z e = ( 2 , 2 ) , s t r i d e s = ( 2 , 2 ) ) )
24 model . add ( D r o p o u t ( 0 . 2 5 ) )
26 # camadas de c l a s s i f i c a c a o
model . add ( F l a t t e n ( ) )
28 model . add ( Dense ( 2 5 6 , a c t i v a t i o n = " r e l u " ) )
model . add ( D r o p o u t ( 0 . 5 ) )
30 model . add ( Dense ( 1 0 , a c t i v a t i o n = " s o f t m a x " ) )
32 # c o n d i c a o p a r a l e i t u r a de p e s o s c a s o s e j a p a s s a d o p o r p a r a m e t r o
i f weights_path :
34 model . l o a d _ w e i g h t s ( w e i g h t s _ p a t h )
36 r e t u r n model
38
40 i f __name__ == ’ __main__ ’ :
42 model = CNN ( )
44 # Define o optimizador
o p t i m i z e r = RMSprop ( l r = 0 . 0 0 1 , r h o = 0 . 9 , e p s i l o n =1e −08 , d e c a y = 0 . 0 )
46
# Compila o model
48 model . c o m p i l e ( o p t i m i z e r = o p t i m i z e r , l o s s = " c a t e g o r i c a l _ c r o s s e n t r o p y " ,
m e t r i c s =[ " a c c u r a c y " ] )
50 model_checkpoint = ModelCheckpoint ( ’ d i g i t o s . hdf5 ’ , monitor = ’ l o s s ’ ,

s a v e _ b e s t _ o n l y =True )
52 # e p o c h s = 1 # numeros de e p o c a s − q u a n t i d a d e v e z e s que s e r e p e t e o
terinamento
b a t c h _ s i z e = 86 # tamanho do l o t e − q u a n t i d a d e de i m a g e n s a s e r e m
p r o c e s s a d a s por vez
54
# o n t e n d o o s d a d o s de t r e i n o e t e s t e
56 X _ t r a i n , X_val , Y _ t r a i n , Y_val = c r e a t e _ t r a i n _ d a t a ( )
58 # g e r a mais dados p a r a o t r e i n a m e n t o
datagen = ImageDataGenerator (
60 f e a t u r e w i s e _ c e n t e r = F a l s e , # s e t i n p u t mean t o 0 o v e r t h e
dataset
s a m p l e w i s e _ c e n t e r = F a l s e , # s e t e a c h s a m p l e mean t o 0
62 f e a t u r e w i s e _ s t d _ n o r m a l i z a t i o n = F a l s e , # d i v i d e i n p u t s by s t d o f
the dataset
s a m p l e w i s e _ s t d _ n o r m a l i z a t i o n = F a l s e , # d i v i d e e a c h i n p u t by i t s
std
64 zca_whitening=False , # a p p l y ZCA w h i t e n i n g
801
r o t a t i o n _ r a n g e =10 , # randomly r o t a t e images i n t h e range (

degrees , 0 to 180)
66 zoom_range = 0 . 1 , # Randomly zoom image
width_shift_range =0.1 , # randomly s h i f t images h o r i z o n t a l l y (
f r a c t i o n of t o t a l width )
68 h e i g h t _ s h i f t _ r a n g e =0.1 , # randomly s h i f t images v e r t i c a l l y (
f r a c t i o n of t o t a l height )
h o r i z o n t a l _ f l i p =False , # randomly f l i p images
70 v e r t i c a l _ f l i p =False ) # randomly f l i p images
datagen . f i t ( X_train )
72
# t r e i n a o model
74 h i s t o r y = model . f i t _ g e n e r a t o r ( d a t a g e n . f l o w ( X _ t r a i n , Y _ t r a i n ,
b a t c h _ s i z e = b a t c h _ s i z e ) , e p o c h s = e p o c h s , v a l i d a t i o n _ d a t a = ( X_val ,
Y_val ) ,
v e r b o s e =1 , s t e p s _ p e r _ e p o c h = X _ t r a i n .
shape [ 0 ] / / b a t c h _ s i z e , c a l l b a c k s =[ model_checkpoint ] )
76
# e x i b e p o r g r a f i c o s o s v a l o r e s de p e r d a no t r e i n a m e n t o
78 f i g , ax = p l t . s u b p l o t s ( 2 , 1 )
ax [ 0 ] . p l o t ( h i s t o r y . h i s t o r y [ ’ l o s s ’ ] , c o l o r = ’ b ’ , l a b e l = " T r a i n i n g l o s s
")
80 ax [ 0 ] . p l o t ( h i s t o r y . h i s t o r y [ ’ v a l _ l o s s ’ ] , c o l o r = ’ r ’ , l a b e l = "
v a l i d a t i o n l o s s " , a x e s = ax [ 0 ] )
l e g e n d = ax [ 0 ] . l e g e n d ( l o c = ’ b e s t ’ , shadow= T r u e )
82
ax [ 1 ] . p l o t ( h i s t o r y . h i s t o r y [ ’ a c c ’ ] , c o l o r = ’ b ’ , l a b e l = " T r a i n i n g
accuracy " )
84 ax [ 1 ] . p l o t ( h i s t o r y . h i s t o r y [ ’ v a l _ a c c ’ ] , c o l o r = ’ r ’ , l a b e l = " V a l i d a t i o n
accuracy " )
l e g e n d = ax [ 1 ] . l e g e n d ( l o c = ’ b e s t ’ , shadow= T r u e )
86 p l t . show ( )
Código Fonte 9.2. modeladagrm, treinamento e avalição da CNN
9.3.3. Predição
Após o treinamento, o aprendizado da CNN é salvo os pesos, para ser possível realizar a
predição apenas carregando os pesos sem a necessidade de treinar novamente para realizar
a classificação. Para realizar a predição, primeiramente é carregado os dados de teste os
quais já estão normalizados. Em seguida é carregado o modelo da CNN pelos pesos
salvos no treinamento. Após essas etapas a CNN faz a predição sobre os dados de teste
classificando entre os dígitos de 0 a 9, para que, com o resultado da classificação, seja
confrontado com o verdadeiro rótulo da imagem testada para calcular métricas estatísticas
como acurácia.
1 from k e r a s . o p t i m i z e r s i m p o r t RMSprop
from s k l e a r n . m e t r i c s i m p o r t c o n f u s i o n _ m a t r i x
3 from d a t a i m p o r t l o a d _ t e s t _ d a t a
from t r a i n i m p o r t CNN
5 i m p o r t numpy a s np
from MNIST . f u n c t i o n s i m p o r t p l o t _ c o n f u s i o n _ m a t r i x
7 from u t i l i m p o r t m a i n _ v a l i d a c a o
from s k l e a r n . m e t r i c s i m p o r t a c c u r a c y _ s c o r e
802
9
def load_model_network ( ) :
11
# c a r r e g a o s d a d o s de t e s t e p a r a a p r e d i c a o
13 X_test , Y_test = l o a d _ t e s t _ d a t a ( )
15 # c a r r e g a o modelo e o s p e s o s j a t r e i n a d o s
model = CNN( ’ d i g i t o s . h d f 5 ’ )
17 o p t i m i z e r = RMSprop ( l r = 0 . 0 0 1 , r h o = 0 . 9 , e p s i l o n =1e −08 , d e c a y = 0 . 0 )
model . c o m p i l e ( o p t i m i z e r = o p t i m i z e r , l o s s = " c a t e g o r i c a l _ c r o s s e n t r o p y " ,
m e t r i c s =[ " a c c u r a c y " ] )
19
# f a z a p r e d i c a o s o b r e a s i m a g n e s de t e s t e
21 Y_pred = model . p r e d i c t ( X _ t e s t )
23 # C o n v e r t e a s c l a s s e s d a s p r e d i c o e s p a r a v a l o r e s de 0 a 9
Y _ p r e d _ c l a s s e s = np . argmax ( Y_pred , a x i s = 1 )
25
# C o n v e r t e o s c l a s s e s c o r r e t a s d a s p r e d i c o e s p a r a v a l o r e s de 0 a 9
27 Y _ t r u e = np . argmax ( Y _ t e s t , a x i s = 1 )
29 # c a l c u l a a m a t r i z de c o n f u s a o
confusion_mtx = c o n f u s i o n _ m a t r i x ( Y_true , Y _ p r e d _ c l a s s e s )
31
# exibe a acuracia sobre a predicao realizada

33 p r i n t ( " ACUR CIA = %.2 f " %( a c c u r a c y _ s c o r e ( Y _ t r u e , Y _ p r e d _ c l a s s e s )
∗ 1 0 0 ) , "%" )
35 # e x i b e g r a f i c a m e n t e a m a t r i z de c o n f u s a o
p l o t _ c o n f u s i o n _ m a t r i x ( confusion_mtx , c l a s s e s =range (10) )
37
39
41
43
i f __name__ == ’ __main__ ’ :
45 """ """
load_model_network ( )
Código Fonte 9.3. predição dos dados de testes
Por fim, para melhor análise dos dados é gerada graficamente a matriz de confusão
o qual demostra a predição feita pela CNN. A Figura 9.12 ilustra a matriz de confusão
gerada pela classificação sobre o conjunto de dados de Teste. As linhas representam os
rótolos verdeiros sobre as imagens testadas, e as colunas representam os rótulos classifi-
cados pela CNN, mas é na diagonal que é representado a quantidade de predições feitas
pela CNN corretas. Na primeira linha, de 415 imagens do digito 0 testadas, a CNN clas-
sificou corretamente 409 como corretas, 1 como o dígito 2, duas como 3, duas como 6, e
uma como 9.
803
Figura 9.12. Matriz de Confusão.
9.4. Considerações Finais

As abordagens que usam CNNs para tarefas de classificação e detecção de objetos em
imagens se sobressaem no que diz respeito a Visão Computacional. Diversas aplicações
vem utilizando CNNs, após o ganho de popularidade em 2012 com a competição de reco-
nhecimento de objetos, a ImageNet. O objetivo do curso é desenvolver uma compreensão
clara sobre a motivação para as CNNs e Deep Learning. Conceitos inicias permitem uma
assimilição da teoria com aplicações, além de noções de como projetar um código ou
sistemas a partir do que foi visto.
É importante que o aluno não se limite apenas as CNNs no que diz respeito a Deep
Learning mas, que explore outros algoritmos e arquiteturas de redes como, por exemplo,
Redes Autocodificadoras e Redes Neurais Recorrentes, além de técnicas para treinamento
de redes profundas.
Referências
[ker 2017] (2017). Keras: The python deep learning library.
[Araújo et al. ] Araújo, F. H., Carneiro, A. C., e Silva, R. R. Redes neurais convolucionais
com tensorflow: Teoria e prática.
[Beam 2017] Beam, A. L. (2017). Deep learning 101 - part 1: History and back-
ground. https://beamandrew.github.io/deeplearning/2017/02/
23/deep_learning_101_part1.html.
[Culurciello 2017] Culurciello, E. (2017). Neural network architec-

tures. https://medium.com/towards-data-science/
neural-network-architectures-156e5bad51ba.
804
[Deng 2012] Deng, L. (2012). The mnist database of handwritten digit images for
machine learning research [best of the web]. IEEE Signal Processing Magazine,
29(6):141–142.
[Deshpande 2016a] Deshpande, A. (2016a). The 9 deep learning pa-
pers you need to know about (understanding cnns part 3). https:
//adeshpande3.github.io/adeshpande3.github.io/
The-9-Deep-Learning-Papers-You-Need-To-Know-About.html.
[Deshpande 2016b] Deshpande, A. (2016b). A beginner’s guide to
understanding convolutional neural networks part 2. https://
adeshpande3.github.io/adeshpande3.github.io/A-Beginner’
s-Guide-To-Understanding-Convolutional-Neural-Networks-Part-2/.
[Ferreira 2017] Ferreira, A. d. S. (2017). Redes neurais convolucionais profundas na
detecção de plantas daninhas em lavoura de soja. Master’s thesis.
[Haykin 2001] Haykin, S. (2001). Redes neurais: princípios e prática. Bookman Edi-
tora.
[He et al. 2016] He, K., Zhang, X., Ren, S., e Sun, J. (2016). Deep residual learning for
image recognition. In Proceedings of the IEEE conference on computer vision and
pattern recognition, pages 770–778.
[Hinton et al. 2006] Hinton, G. E., Osindero, S., e Teh, Y.-W. (2006). A fast learning
algorithm for deep belief nets. Neural computation, 18(7):1527–1554.
[Kim 2014] Kim, Y. (2014). Convolutional neural networks for sentence classification.
arXiv preprint arXiv:1408.5882.
[Krizhevsky et al. 2012] Krizhevsky, A., Sutskever, I., e Hinton, G. E. (2012). Imagenet
classification with deep convolutional neural networks. In Advances in neural infor-
mation processing systems, pages 1097–1105.
[LeCun et al. 1990] LeCun, Y., Boser, B. E., Denker, J. S., Henderson, D., Howard, R. E.,
Hubbard, W. E., e Jackel, L. D. (1990). Handwritten digit recognition with a back-
propagation network. In Advances in neural information processing systems, pages
396–404.
[LeCun et al. 2010] LeCun, Y., Kavukcuoglu, K., e Farabet, C. (2010). Convolutional
networks and applications in vision. In Circuits and Systems (ISCAS), Proceedings of
2010 IEEE International Symposium on, pages 253–256. IEEE.
[Libralão et al. 2003] Libralão, G. L., Oshiro, R. M., Netto, A. V., Carvalho, A., e Oli-
veira, M. (2003). Técnicas de aprendizado de máquina para análise de imagens oftal-
mológicas. São Paulo. Universidade de São Paulo.
[Morais 2017] Morais, L. (2017). Introdução Às re-
des neurais artificiais. http://www.lmtech.info/
index.php/tecnologia/inteligencia-artificial/
129-introducao-a-redes-neurais-artificiais.
805
[Rosenblatt 1958] Rosenblatt, F. (1958). The perceptron: A probabilistic model for in-
formation storage and organization in the brain. Psychological review, 65(6):386.
[Rumelhart et al. 1985] Rumelhart, D. E., Hinton, G. E., e Williams, R. J. (1985). Lear-
ning internal representations by error propagation. Technical report, California Univ
San Diego La Jolla Inst for Cognitive Science.
[Simonyan e Zisserman 2014] Simonyan, K. e Zisserman, A. (2014). Very deep convo-

lutional networks for large-scale image recognition. arXiv preprint arXiv:1409.1556.
[Song e Lee 2013] Song, H. A. e Lee, S.-Y. (2013). Hierarchical representation using
nmf. In International Conference on Neural Information Processing, pages 466–473.
Springer.
[Spark 2017] Spark, C. (2017). Deep learning for complete beginners: convolutional
neural networks with keras. https://cambridgespark.com/content/
tutorials/convolutional-neural-networks-with-keras/index.
html.
[Szegedy et al. 2015] Szegedy, C., Liu, W., Jia, Y., Sermanet, P., Reed, S., Anguelov, D.,
Erhan, D., Vanhoucke, V., e Rabinovich, A. (2015). Going deeper with convolutions.
In Proceedings of the IEEE conference on computer vision and pattern recognition,
pages 1–9.
[Zeiler e Fergus 2014] Zeiler, M. D. e Fergus, R. (2014). Visualizing and understanding

convolutional networks. In European conference on computer vision, pages 818–833.
Springer.
806
Capítulo
10
Introdução ao Desenvolvimento de Aplicativos
Android Utilizando Conceitos de Geolocalização
Vitório Silva Alves da Rocha e Ivan Costa do Nascimento Filho
Abstract
In Brazil, mobile devices have been gaining a lot of space in front of the population,
while the Android operating system is gaining more space in the market. A geolocation
is a mechanism widely used today, mainly to generate public utility and assist in deci-
sion making. This chapter aims to promote knowledge about the development of Android
applications using Geolocation mechanisms from a practical and theoretical content.
Resumo
No Brasil, os dispositivos móveis vêm ganhando grande espaço diante da população, ao

passo em que o sistema operacional Android conquista cada vez mais espaço no mercado.
A geolocalização é um mecanismo muito utilizado hoje em dia, principalmente para ge-
rar utilidade pública e auxiliar na tomada de decisão. Este capítulo tem como objetivo
promover o conhecimento sobre o desenvolvimento de aplicativos Android utilizando me-
canismos de Geolocalização a partir de um conteúdo prático e teórico.
10.1. Introdução
Nos últimos anos o número de smartphones cresceu, conforme mostrado nos relató-
rios da Ericsson de 2013 à 2016 [Ericsson 2013], [Ericsson 2014], [Ericsson 2015] e
[Ericsson 2016]. Somado a isso, o Android tornou-se o sistema operacional dominante
nesses aparelhos no mundo, ultrapassando o Windows [Stats 2017]. Isso significa mais
oportunidades para desenvolvedores de software que desejam atender a esse mercado.
No Brasil os dispositivos móveis também vêm ganhando grande espaço diante
da população. De acordo com a Opus Software1 , os brasileiros estão usando mais os
smartphones para acessar a Internet do que o computador pessoal. Aliando essas informa-
ções com o grande número de funcionalidades que esses aparelhos vêm disponibilizando
1 www.opus-software.com.br/estatisticas-uso-celular-brasil/
807
a cada nova geração, a quantidade de aplicações desenvolvidas para os smartphones tem

aumentado e, com isso, surgiram diferentes tipos de implementação de aplicativos. Uma
dessas abordagens de desenvolvimento se dá por meio da utilização do conceito de geo-
localização em aplicativos Android, que é o foco deste capítulo.
A geolocalização já é uma tecnologia muita usada nos dias atuais, seja por dis-
positivos de GPS(Global System Position) onde servem para indicar caminhos ou locais,
seja por empresas de e-commerce2 para identificar onde estão seus clientes e smartpho-
nes servindo para detectar a localização física do dispositivo. Em relação ao uso dessa
tecnologia em dispositivos mobile, é importante lembrar a quantidade de aplicativos que
se utilizam da geolocalização e também do seu potencial financeiro. Segundo a matéria
do G13 , as empresas que trabalham com localização faturaram juntas cerca de 63 bilhões
de reais no ano de 2016.
Aliando os sensores presentes nos aparelhos com as vantagens de uma conexão
à Internet, a API de Geolocalização desenvolvida pela empresa Google permite que de-
senvolvedores criem aplicativos que possam auxiliar a comunidade, por exemplo, mos-
trando a localização precisa de hotéis, restaurantes, postos de gasolina, dentre outros
[Djuknic and Richton 2001].
10.2. Android
A tecnologia Android surgiu em 5 de novembro de 2007, anunciada por um consórcio de
empresas na área de tecnologia chamado Open Handset Alliance (OHA)[Alliance 2007].
A plataforma surgiu com o objetivo de ser um padrão aberto para vários tipos de dispo-
sitivos, garantindo a interoperabilidade entre os aplicativos e o sistema operacional. Isso
proporciona que sistemas se comuniquem da forma mais transparente possível.
Como mencionado na introdução deste capítulo, o Android é um SO (Sistema
Operacional) criado inicialmente para smartphones, mas que atualmente já abrange ou-
tros tipos de dispositivos como televisores, receptores, relógios inteligentes, etc. Apesar
de ter sido lançado em 2007 pela OHA, o seu desenvolvimento foi iniciado muito an-
tes pela empresa Android Inc. no ano de 2003, sendo esta adquirida pela Google em
2005[Elgin 2005].
O Android já se encontra em sua versão 8.0 (Android Oreo), sendo a Google a
empresa responsável pelas atualizações. Embora seja alta a frequência de atualização do
SO, a maior parte dos usuários ainda estão concentrados em versões anteriores, conforme
mostra os gráficos presentes no site Android Developers4 .
10.3. Requisitos para o Desenvolvimento Android

Essencialmente, para o desenvolvimento Android é necessário apenas o Android SDK
(Software-Developing Kit), que nada mais é que um conjunto de ferramentas, uma lin-
guagem de programação suportada e um editor de texto. No entanto, programadores
2 Empresas que vendem produtos pela Internet.

3 https://g1.globo.com/economia/noticia/empresas-faturaram-r-63-bilhoes-em-2016-com-
geolocalizacao-na-america-latina-diz-pesquisa.ghtml
4 https://developer.android.com/about/dashboards/index.html
808
iniciantes preferem aderir ao uso de um IDE (Integrated Development Environment), ou

ambiente integrado de desenvolvimento, o qual já possui todas as ferramentas necessárias
para o desenvolvimento.
A depender da versão do SO no qual seu aplicativo vai rodar, deve-se utilizar
uma versão específica do Android SDK. Como exemplo, para a versão 4.4.4 do Android
(KitKat), é necessário ter no mínimo o SDK 19 instalado no seu computador. Até o
presente momento, a versão mais atual do SDK encontra-se na API 26 (Android 8.0).
10.3.1. Linguagens de Programação Oficiais

Existem diversas maneiras de desenvolver aplicativos Android. Abaixo estão listadas al-
gumas linguagens de programação com as quais é possível desenvolver. Para este capítulo
será utilizada apenas a Linguagem Java.
• Java: é a linguagem padrão de desenvolvimento Android, atualmente.
• Kotlin: é uma linguagem desenvolvida pela JetBrains e que vem recebendo suporte
da Google.
• LUA: é a linguagem de programação base do Corona SDK 5 que permite o desen-

volvimento híbrido de aplicações móveis.
• Javascript: em conjunto com HTML e CSS, é possível desenvolver de forma hí-

brida com a tecnologia Phonegap.
10.3.2. IDE Android Studio

Atualmente o Android Studio é o IDE oficial de desenvolvimento Android, segundo a
Google. Esse IDE substitui seu antecessor, o Eclipse. Neste capítulo será utilizado o
Android Studio.
10.4. Organização de Projetos Android

Quando se inicia um projeto no Android Studio a própria IDE já cria uma estrutura para
os arquivos, com o intuito de organizar códigos, imagens, ícones, e demais documentos
utilizados no projeto(Figura10.4).
10.4.1. Manifest
O manifest consiste de um arquivo .XML no qual estão contidas as informações essenciais
para a execução do aplicativo. O manifest é o primeiro arquivo que o sistema Android
interpreta, nele o sistema obtém as informações de funcionamento da aplicação como
qual tela o sistema deve executar quando o aplicativo é aberto; quais permissões são
requeridas pelo aplicativo (câmera, armazenamento, localização, Bluetooth, etc.); o nome
do aplicativo, dentre outras informações. Abaixo, um exemplo de arquivo manifest.
1 <?xml version="1.0" encoding="utf-8"?>
5 https://coronalabs.com/
809
Figura 10.1. Organização de arquivos
2 <manifest xmlns:android="http://schemas.android.com/apk/res/
android"
3 package="com.example.vitorio.exemplominicursoenuncomp2017">
4 <uses-permission android:name="android.permission.INTERNET"
/>
5 <uses-permission android:name="android.permission.CAMERA" />
6 <uses-permission android:name="android.permission.
ACCESS_FINE_LOCATION" />
7 <uses-permission android:name="android.permission.
ACCESS_COARSE_LOCATION" />
8
9 <application
10 android:allowBackup="true"
11 android:icon="@mipmap/ic_launcher"
12 android:label="@string/app_name"
13 android:roundIcon="@mipmap/ic_launcher_round"
14 android:supportsRtl="true"
15 android:theme="@style/AppTheme">
16 <activity android:name=".ActivityPrincinpal">
17 <intent-filter>
18 <action android:name="android.intent.action.MAIN
" />
19
20 <category android:name="android.intent.category.
LAUNCHER" />
21 </intent-filter>
22 </activity>
23 <meta-data
24 android:name="com.google.android.geo.API_KEY"
810
25 android:value="@string/google_maps_key" />
26
27 <activity
28 android:name=".Mapa"
29 android:label="@string/title_activity_mapa"/>
30 <activity android:name=".TelaCadastro"/>
31 </application>
32
33 </manifest>
• Use-permissions: são permissões dadas ao sistema do Android para que a aplica-

ção tenha acesso a serviços presentes no SO.
• Aplications: abrange vários subelementos do programa, sendo estes responsáveis

pelos componentes da aplicação, contendo também atributos que podem afetar os
elementos presentes no aplicativo como nome, ícone e execução.
• Intent-Filter: são declarações implícitas de "intent"que buscam realizar uma ação

(action) assíncrona pelo sistema.
• Action: trata-se de uma ação requisitada pelo intent. No código de exemplo, o

aplicativo requisita ao sistema que ao iniciar seja aberta primeiro a activity "Acti-
vityPrincipal".
10.4.2. Arquivos Java

Java é uma uma linguagem de programação e também uma plataforma computacional
lançada pela Sun Microsystems em 1995[Java 2017b]. Como plataforma, Java na versão
2 foi largamente utilizada no sistema operacional de dispositivos com diferentes capaci-
dades de processamento (Figura 10.2). Atualmente, como linguagem de programação,
Java é utilizada no desenvolvimento de sites e vários tipos de aplicações, tanto na indús-
tria quanto em ambientes acadêmicos [Java 2017a]. No desenvolvimento Android, Java é
a linguagem padrão.
Segundo o site Android Developers6 , site oficial de desenvolvedores Android, a
linguagem "nativa"para o desenvolvimento de aplicativos Android é o Java 8. Por ser uma
linguagem de programação orientada a objetos, Java trabalha com os conceitos de classes,
métodos, objetos, encapsulamento, etc. O paradigma de Orientação a Objetos é essencial
para os projetos de software, pois facilita o trabalho em equipe e diminui a complexidade
dos códigos.
Activity
Activity é uma entidade que representa uma tela dentro de um aplicativo. Nos projetos
atuais de Android, por padrão, cada activity é organizada por uma classe Java e um arquivo
.XML correspondente. A classe Java contém a logica da activity, enquanto que o arquivo
6 https://developer.android.com
811
Figura 10.2. Plataforma Java 2
XML contém os layouts, isto é, os elementos gráficos que aparecem na tela (botões,
campos de texto, imagens, dentre outros).
A classe Java correspondente à sua activity deve estender a classe "Activity"ou
"AppCompatActivity"do Android, a depender do grau de compatibilidade exigido no pro-
jeto. Ambas possuem uma variedade de métodos de callback que notificam o SO à me-
dida que certos eventos acontecem. Esses callbacks são ativados quando o sistema está
criando, interrompendo, retomando ou destruindo o processo no qual a activity existe. O
código abaixo é um exemplo de uma classe Java correspondente à uma activity.
1 public class ActivityTelaInicial extends AppCompatActivity {
2
3 @Override
4 protected void onCreate(Bundle savedInstanceState) {
5 super.onCreate(savedInstanceState);
6 setContentView(R.layout.activity_tela_inicial);
7 }
8 }
Ciclo de Vida da Activity
Qualquer activity em Android tem um ciclo de vida bem definido. O desenvolvedor pode
inserir ações e funcionalidades nos métodos que correspondem às fases do ciclo de vida,
porém cabe ao sistema decidir quando executá-los. Esses métodos são listados a seguir:
• onCreate(): é o callback invocado quando a activity entra no estado de "criada".

Esse método equivale à um construtor normal de uma classe Java, pois é aqui que o
desenvolvedor pode inicializar variáveis importantes. Além disso, esse método só
é executado uma única vez durante o ciclo de vida da activity.
812
• onStart(): é invocado pelo sistema quando a activity já está criada e possui o estado
de "iniciada". O método é responsável por tornar a activity visível ao usuário. Ele é
executado e finalizado rapidamente, o que faz a activity sair do estado de "iniciada"e
entrar em estado de "retomada", chamando assim o método onResume().
• onResume(): assim que a activity entra em estado de "retomada"ela é colocada

em primeiro plano. A activity permanece em primeiro plano até que outra activity
requisite foco.
• onPause(): a partir do momento que a activity está saindo do primeiro plano, devido
à algum evento, o método onPause() é invocado pelo sistema. Animações, áudios e
outras ações que não necessitam estar em execução são suspensas até que a activity
retome o foco.
• onStop(): é chamado sempre que a activity não está mais visível ao usuário. Isso
pode ocorrer porque outra activity foi criada e iniciada ou quando a activity em
questão já foi finalizada e está encerrando.
• onDestroy(): é invocado sempre que o método finish() é executado ou quando o

sistema está liberando espaço em memória.
10.4.3. Resources
A seção de Resources é composta por várias subpastas contendo arquivos importantes que
podem ser acessados pela activity, como imagens, textos, valores padrão de cores, estilos
gráficos, etc. Abaixo estão listadas as principais pastas do grupo Resources:
• Drawable: contém as imagens do projeto. Não apenas imagens nos formatos mais
conhecidos, mas também arquivos de XML estão presentes.
• Layout: contém todos os arquivos de layout do projeto. Geralmente estão armaze-

nadas a visão das activities.
• Values: contém os valores padrão de cores, estilos e textos (strings). Manter to-
dos os textos armazenados externamente ao código facilita na portabilidade e na
tradução para outras línguas.
10.5. Geolocalização
A geolocalização é um esquema que consiste em localizar um indivíduo ou objeto a partir
de suas coordenadas em um plano [QueConceito 2017]. Nos últimos anos, esse conceito
vem sendo usado em nosso dia a dia para diversas finalidades, seja para o entretenimento,
segurança, comunicação e até mesmo para a tomada de decisões [TecMundo 2017]. Um
exemplo típico é o GPS, que serve como meio de localizar um determinado lugar e guiar
o usuário até o local desejado.
813
API do Google Maps Android

A Google fornece um conjunto de métodos e ferramentas para a utilização de mapas
em aplicativos Android. Com essa API é possível visualizar e cadastrar locais a partir
de suas coordenadas de longitude e latitude. O usuário também é capaz de interagir
com os mapas por meio de marcadores e gestos providos pela própria API do Google
[GoogleDevelopers 2017].
10.6. Instalando o Android Studio

A instalação do Android Studio pode ser feita nos sistemas Windows, Linux e MAC.
O download dos arquivos necessários e um tutorial detalhado de instalação podem ser
encontrados no site oficial Android Developers. Antes de prosseguirmos com o projeto
no IDE, é necessário completar os seguintes passos:
• Instalar o Android Studio: a instalação é simples para o sistema Windows, de-

vendo apenas executar o arquivo .exe baixado e seguir os passos do próprio ins-
talador. Nos demais sistemas, o usuário deve navegar até o caminho "android-
studio/bin", executar o arquivo "studio.sh"e continuar a instalação normalmente.
• Instalar componentes do SDK: uma vez instalado o Android Studio, uma tela será
mostrada exigindo a instalação dos componentes do Android SDK que faltam.
10.7. Iniciando o Projeto

Nesta seção será ensinado como criar uma aplicação Android na forma de implementação,
passo-a-passo, o projeto apresentado a seguir está resumido, o projeto completo e mais
detalhado se encontra em um repositório da plataforma GitHub7 .
Criação do Projeto
Depois de instalado o IDE, conforme mostrado no tópico anterior, chegou a hora de criar
seu projeto Android. Após abrir o Android Studio pela primeira vez será exibida uma tela
com algumas opções. Clique na opção Start a new Android Studio project.
A próxima tela a ser exibida é onde definiremos o nome do aplicativo, seu domínio
e também onde o projeto será salvo. O nome do projeto não deve conter espaços em
branco. Após isso avance para próxima tela. Logo em seguida será exibido a tela onde
escolhemos os tipos de dispositivos que a aplicação atenderá, que em nosso caso será a
opção Telefone e Tablet (Phone and Tablet). Outra configuração importante é escolher
a versão mínima do SO para o qual você deseja que sua aplicação ofereça suporte, que no
nosso caso será a partir da API 16. Feito isso, clique em avançar.
O próximo passo será definir a activity que será criada inicialmente. Clicamos no
tipo Blank Activity e avançamos para escolher o nome da activity, de preferência digite
ActivityPrincipal. Dependendo do processamento de sua máquina, o projeto demorará
alguns minutos para ser criado.
7 https://github.com/svitorio/AndroidEnucomp2017
814
Depois de criado nosso projeto, observe a estrutura de sua aplicação, assim como
na figura 10.4. É de suma importância que você já tenha lido a parte referente à estrutura
do projeto, o que foi explicado logo no inicio deste capítulo.
Modificando a Tela Inicial

Agora iremos iniciar a aplicação: entre no diretório res->layout e abra o arquivo acti-
vity_principal.xml referente ao nome da activity que você criou e clique no botão TEXT
no canto inferior esquerdo da aba que está sendo exibida a tela inicial. Copie e cole o có-
digo abaixo no arquivo, substituindo o atual. Isso irá inserir uma interface gráfica na tela
do seu aplicativo contendo o nome do aplicativo e dois botões. Retorne para aba Design,
na qual é possível ver sua tela inicial criada.
2 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/
android"
3 xmlns:app="http://schemas.android.com/apk/res-auto"
4 xmlns:tools="http://schemas.android.com/tools"
5 android:layout_width="match_parent"
6 android:layout_height="match_parent"
7 android:orientation="vertical"
8 android:padding="12dp">
9
10 <TextView
12 android:layout_height="0dp"
13 android:layout_weight="5"
14 android:gravity="center"
15 android:textAppearance="@style/TextAppearance.AppCompat.
Display1"
16 android:text="@string/app_name_tela_principal"
17 android:textStyle="bold"/>
18
19 <LinearLayout
21 android:layout_height="0dp"
22 android:layout_weight="10"
23 android:orientation="vertical">
24
25 <Button
26 android:id="@+id/cadastroButton"
28 android:layout_height="wrap_content"
29 android:layout_weight=".5"
30 android:layout_gravity="center"
31 android:drawableLeft="@mipmap/ic_launcher"
32 android:text="Cadastrar Local"/>
33
34 <Button
35 android:id="@+id/mapaButton"
815
38 android:layout_weight=".5"
40 android:drawableLeft="@mipmap/ic_launcher"
41 android:text="Mostrar Mapa"/>
42 </LinearLayout>
43 </LinearLayout>
Agora vamos editar a classe Java da activity ActivityPrincipal: entre no diretório

Java e localize a classe, como mostra a Figura 10.4. Essa classe é responsável por invocar
as activities de Mapa e TelaCadastro. Substitua o conteúdo da classe atual com o código
abaixo.
1 public class ActivityPrincinpal extends AppCompatActivity {

2
3 private FragmentManager fragmentManager;

4 @Override
7 setContentView(R.layout.activity_princinpal);
8
9 findViewById(R.id.mapaButton).setOnClickListener(new View.
OnClickListener() {
10 @Override
11 public void onClick(View view) {
12 Intent intent = new Intent(ActivityPrincinpal.
this, Mapa.class);
13 intent.putExtra("coordenadas","0");
14 startActivity(intent);
15
16 }
17 }); findViewById(R.id.cadastroButton).
setOnClickListener(new View.OnClickListener() {
18 @Override
19 public void onClick(View v) {
20 Intent intent = new Intent(ActivityPrincinpal.
this, TelaCadastro.class);
21 intent.putExtra("nome","");
23
24 }
25 });
26
27 }
28 }
816
Classe Ponto
Agora vamos criar a Classe Ponto, a qual conterá três atributos: nome, latitude e longi-
tude. Para isso, clique no diretório Java com o botão direito e insira um nova classe com
o nome "Ponto". Abra a classe e em seguida modifique seu conteúdo pelo código abaixo.
1 public class Ponto {
2
3 private String nome;

4 private double latitude, longitude;
5
6 public Ponto(){}
7 public Ponto(String nome, double latitude, double longitude)
{
8 this.nome = nome;
9 this.latitude = latitude;
10 this.longitude = longitude;
11 }
12
13 public String getNome() {

14 return nome;
15 }
16
17 public void setNome(String nome) {

18 this.nome = nome;
19 }
20
21 public double getLatitude() {

22 return latitude;
23 }
24
25 public void setLatitude(double latitude) {

26 this.latitude = latitude;
27 }
28
29 public double getLongitude() {

30 return longitude;
31 }
32
33 public void setLongitude(double longitude) {

34 this.longitude = longitude;
35 }
36 }
Criando a Activity TelaCadastro

Para inserirmos um ponto no mapa é necessário receber os três atributos do usuário, para
isso criaremos uma interface para cadastrar os dados do ponto. Esses dados serão armaze-
nados localmente no banco de dados SLQlite, mas sua implementação não será abordada
a fundo neste capítulo.
817
Crie uma nova activity clicando em App->New->Activity->Empty Activity. Di-

gite o nome TelaCadastro e clique em finalizar. Agora abra o arquivo xml correspondente
à activity recém-criada no caminho res->layout->activity_tela_cadastro.xml. Substitua
seu conteúdo pelo código abaixo. Isso criará três campos de texto para receber os dados
do teclado.

2 <ScrollView xmlns:android="http://schemas.android.com/apk/res/
android"
3 xmlns:app="http://schemas.android.com/apk/res-auto"
4 xmlns:tools="http://schemas.android.com/tools"
6 android:layout_height="match_parent"
7 tools:context="com.example.vitorio.
exemplominicursoenuncomp2017.TelaCadastro">
8
9 <LinearLayout
10 android:orientation="vertical"
13 android:padding="12dp">
14
15 <TextView
18 android:text="Nome do Local:"
19 android:textAppearance="@style/TextAppearance.
AppCompat.Title"/>
20
21 <EditText
22 android:id="@+id/cadastroNomeLocal"
25 android:inputType="textCapWords"/>
26
27
28 <TextView
31 android:text="Latitude:"
AppCompat.Title"/>
33
34 <EditText
35 android:id="@+id/cadastroLatitude"
38 android:inputType="textUri"/>
39
818
40
41 <TextView
44 android:text="Longitude:"
AppCompat.Title"/>
46
47 <EditText
48 android:id="@+id/cadastroLongitude"
51 android:inputType="textUri"/>
52
53 <TableRow
54 android:layout_width="wrap_content"
55 android:layout_height="wrap_content">
56
57 <Button
58 android:id="@+id/botaoCadastrar"
62 android:layout_marginTop="12dp"
63 android:text="Cadastrar Local"/>
64
65 <Button android:id="@+id/botaoCoordenadas"
69 android:layout_marginTop="12dp"
70 android:text="Inserir Coordenads Mapa"/>
71
72 </TableRow>
73 </LinearLayout>
74
75 </ScrollView>
O próximo passo é abrir a classe Java correspondente à activity de cadastro e

alterar seu conteúdo com o código abaixo. Com esse código toda a validação e cadastro
no banco de dados são feitos.
1 public class TelaCadastro extends AppCompatActivity {
2
3 private EditText nomeEditText, longitudeEditText,

latitudeEditText;
4
5 @Override
819
8 setContentView(R.layout.activity_tela_cadastro);
9
10 findViewById(R.id.botaoCadastrar).setOnClickListener(new
View.OnClickListener() {
11 @Override
12 public void onClick(View v) {
13 cadastrar();
14 }
15 });
16 Intent intentm = getIntent();
17 String nome,latitude,longitude;
18
19 nomeEditText = (EditText) findViewById(R.id.

cadastroNomeLocal);
20 longitudeEditText = (EditText) findViewById(R.id.
cadastroLongitude);
21 latitudeEditText = (EditText) findViewById(R.id.
cadastroLatitude);
22
23 if(intentm.getStringExtra("nome").equals("")){
24 Log.i("tag","ta fazio");
25
26 findViewById(R.id.botaoCoordenadas).
setOnClickListener(new View.OnClickListener() {
27 @Override
28 public void onClick(View view) {
29 coordenadas(nomeEditText);
30 }
31 });
32 }else{
33 nome = intentm.getStringExtra("nome");
34 latitude = intentm.getStringExtra("latitude");
35 longitude = intentm.getStringExtra("longitude");
36 nomeEditText.setText(nome);
37 latitudeEditText.setText(latitude);
38 longitudeEditText.setText(longitude);
39 }
40 }
41
42 private void coordenadas(EditText nomeEditText) {

43 String nomeLocal = nomeEditText.getText().toString();
44 if (nomeLocal.equals("")) {
45 nomeLocal = "Sem Nome";
46 }
47 Intent intent = new Intent(TelaCadastro.this, Mapa.class
);
48 intent.putExtra("nome", nomeLocal);
49 intent.putExtra("coordenadas","1");
820
51 finish();
52 }
53
54 private void cadastrar() {

55 String nomeLocal = nomeEditText.getText().toString();
56 String longitude = longitudeEditText.getText().toString
();
57 String latitude = latitudeEditText.getText().toString();
58
59 if (nomeLocal.equals("")) {
60 nomeLocal = "Sem nome";
61 }
62
63 double longitudeFloat = 0, latitudeFloat = 0;

64
65 try {
66 longitudeFloat = Double.parseDouble(longitude);
67 Log.i("i","Antes:: "+longitudeEditText.getText().
toString()+"\nDepois:: "+latitudeFloat);
68 } catch (Exception ignored) {
69 longitudeEditText.setError("Longitude Invalida");
70 }
71 try {
72 latitudeFloat = Double.parseDouble(latitude);
73 } catch (Exception ignored) {
74 latitudeEditText.setError("Latitude Invalida");
75 }
76
77 DatabaseControl databaseControl = new DatabaseControl(

this);
78 databaseControl.insertData(new Ponto(nomeLocal,
latitudeFloat, longitudeFloat));
79 Toast.makeText(this, "Cadastro realizado!", Toast.
LENGTH_SHORT).show();
80 finish();
81 }
82 }
Criando a Activity Mapa

Após o usuário cadastrar Pontos no aplicativo, ele poderá visualizá-los em um mapa pro-
vido pela API do Google Maps. Crie a activity Mapa clicando com o botão direito em
App->New->Google->Google Maps Activity e nomeia de Mapa, depois de executado o
procedimento podemos notar que foi gerado três novos arquivos no projeto o Mapa.java,
o actvity_mapa.xml e o google_maps_api.xml.
Após ter executo a ação anterior, devemos modificar a classe Mapa.java a qual
contém toda a lógica para exibir o mapa. O código abaixo deve ser usado na sua classe.
1 public class Mapa extends FragmentActivity implements
821
OnMapReadyCallback,
2 GoogleMap.OnMapClickListener, LocationListener {
3
4 private GoogleMap mMap;

5 private LocationManager locationManager;
6 int escolha;
7 String nome;
8
9 @Override
12 setContentView(R.layout.activity_mapa);
13 SupportMapFragment mapFragment = (SupportMapFragment)
getSupportFragmentManager()
14 .findFragmentById(R.id.map);
15 mapFragment.getMapAsync(this);
16
17 Intent intent = getIntent();

18 escolha = Integer.parseInt(intent.getStringExtra("
coordenadas"));
19 nome = intent.getStringExtra("nome");
20 }
21
22 @Override
23 public void onMapReady(GoogleMap googleMap) {
24
25
26 try {
27 locationManager = (LocationManager)
getApplicationContext().getSystemService(Context.
LOCATION_SERVICE);
28
29 Criteria criteria = new Criteria();

30
31 String provider = locationManager.getBestProvider(

criteria, true);
32
33 Toast.makeText(getApplicationContext(), "Provider: "

+ provider, Toast.LENGTH_LONG).show();
34
35 mMap = googleMap;
36
37 mMap.setOnMapClickListener(this);
38
39 mMap.getUiSettings().setZoomControlsEnabled(true);
40
41 mMap.setMyLocationEnabled(true);
42 } catch (SecurityException ex) {
43
822
44 Log.e("TAG", "Error", ex);

45 }
46 mMap = googleMap;
47 final Location laslocation;
48 if (ActivityCompat.checkSelfPermission(this, Manifest.
permission.ACCESS_FINE_LOCATION) != PackageManager.
PERMISSION_GRANTED && ActivityCompat.
checkSelfPermission(this, Manifest.permission.
ACCESS_COARSE_LOCATION) != PackageManager.
PERMISSION_GRANTED) {
49
50 return;
51 }
52 laslocation = locationManager.getLastKnownLocation(
LocationManager.NETWORK_PROVIDER);
53 Toast.makeText(getApplicationContext(),"Lati:"+
laslocation.getLatitude()+"\nLong:: "+laslocation.
getLongitude(),Toast.LENGTH_SHORT).show();
54
55 DatabaseControl dc = new DatabaseControl(this);

56 ArrayList<Ponto> lista = new ArrayList<Ponto>();
57 lista = dc.carregaDados();
58
59 if(escolha==0) {
60 LatLng posicao=new LatLng(laslocation.getLatitude(),
laslocation.getLongitude());
61 mMap.moveCamera(CameraUpdateFactory.newLatLng(
posicao));
62 mMap.animateCamera(CameraUpdateFactory.newLatLngZoom
(posicao,(float)17.5));
63 for (int i = 0; i < lista.size(); i++) {
64 LatLng sydney = new LatLng(lista.get(i).
getLatitude(), lista.get(i).getLongitude());
65
66
67 MarkerOptions marker = new MarkerOptions();

68 marker.position(sydney);
69 marker.title(lista.get(i).getNome());
70 mMap.addMarker(marker);
71 }
72 } else if (escolha==1){
73 Toast.makeText(this, "Toque em Algum Ponto do Mapa?"
, Toast.LENGTH_SHORT).show();
74 }
75 else if (escolha==2){
76 Intent intent = getIntent();
77 double lat = Double.parseDouble(intent.
getStringExtra("latitude"));
78 double lon = Double.parseDouble(intent.
823
getStringExtra("longitude"));
79 LatLng posicao=new LatLng(lat,lon);
80 MarkerOptions marker = new MarkerOptions();
81 marker.position(posicao);
82 marker.title(intent.getStringExtra("nome"));
83 mMap.addMarker(marker);
84 mMap.moveCamera(CameraUpdateFactory.newLatLngZoom(
posicao, (float)17.5));
85 }
86 }
87 public void onMapClick(LatLng latLng) {
88
89 if(1 == escolha){
90 showMessageDialog(""+latLng.latitude,""+latLng.
longitude);
91 }
92 else {
93 Toast.makeText(getApplicationContext(),"Latitude: "+
latLng.latitude+"\nLongitude"+latLng.longitude,
Toast.LENGTH_LONG).show();
94 Log.i("Aaa","Latitude: "+latLng.latitude+"\
nLongitude"+latLng.longitude);
95 }
96 }
97 private void showMessageDialog(final String lat,final String
lon) {
98 AlertDialog alertDialog = new AlertDialog.Builder(this).
create();
99 alertDialog.setTitle("Coordeanadas");
100 alertDialog.setMessage("Tem certeza que sao essas as
Coordenadas?");
101 alertDialog.setButton(AlertDialog.BUTTON_POSITIVE, "
Comfirmar",
102 new DialogInterface.OnClickListener() {
103 public void onClick(DialogInterface dialog,
int which) {
104 Intent intentcad = new Intent(Mapa.this,
TelaCadastro.class);
105 intentcad.putExtra("latitude",lat);
106 intentcad.putExtra("longitude",lon);
107 intentcad.putExtra("nome", nome);
108 startActivity(intentcad);
109 dialog.dismiss();
110 onBackPressed();
111 finish();
112 }
113 });
114 alertDialog.show();
115 alertDialog.setButton(AlertDialog.BUTTON_NEGATIVE, "
824
Cancelar",
116 new DialogInterface.OnClickListener(){
117 public void onClick(DialogInterface dialog,
int which){
118 dialog.dismiss();
119 onBackPressed();
120 }
121 });
122 }
123
124 @Override
125 public void onLocationChanged(Location location) {
126
127 }
128
129 @Override
130 public void onStatusChanged(String s, int i, Bundle bundle)
{
131
132 }
133
134 @Override
135 public void onProviderEnabled(String s) {
136
137 }
138
139 @Override
140 public void onProviderDisabled(String s) {
141
142 }
143 }
Agora iremos autorizar a nossa aplicação a utilizar a API do Google Maps, entre no
google_maps_api.xml( res->values), e copie a cole a url gerada no seu navegador e siga
os procedimentos para ativar a API, após gerar uma chave retorne ao arquivo e substitua
a parte escrita "ADD_API_KEY_HERE"pela chave gerada, observe o exemplo abaixo:
1 <resources>
2
3 Copie e Cole essa URL no navegador:

4 https://developers.google.com/maps/documentation/android/
start#
get_an_android_certificate_and_the_google_maps_api_key
5
6 <string name="google_maps_key" translatable="false"

templateMergeStrategy="preserve">
7 ADD_API_KEY_HERE
8 </string>
9 </resources>
825
Salvando as Informações no Banco de Dados

Crie duas classes Java clicando com o botão direito na pasta java->new->Java Class. A
primeira deve se chamar CreateDatabase.java e a segunda DatabaseControl.java. Ambas
as classes servirão para criar e para controlar os métodos referentes ao Banco de Dados
utilizado para salvar os atributos dos Pontos cadastrados. Os códigos a serem usados estão
disponíveis abaixo.
1 public class CreateDatabase extends SQLiteOpenHelper {
2
3 private static final String NAME_DATABASE = "evento.db";

4 static final String TABLE = "local";
5 static final String NAME_LOCAL = "name_local";
6 static final String LATITUDE = "latitude";
7 static final String LONGITUDE = "longitude";
8 static final String ID = "_id";
9 private static final int VERSAO = 7;
10
11 public CreateDatabase(Context context) {

12 super(context, NAME_DATABASE, null, VERSAO);
13 }
14
15 @Override
16 public void onCreate(SQLiteDatabase db) {
17 db.execSQL("Create table "+TABLE+"("+ID+" integer
primary key autoincrement,"+NAME_LOCAL+" text not
null,"+LATITUDE+" double not null,"+LONGITUDE+"
double not null);");
18 }
19
20 @Override
21 public void onUpgrade(SQLiteDatabase db, int oldVersion, int
newVersion) {
22 db.execSQL("DROP TABLE IF EXISTS " + TABLE);
23 onCreate(db);
24 }
25 }
1 public class DatabaseControl {

2
3 private SQLiteDatabase db;

4 private CreateDatabase database;
5
6 public DatabaseControl(Context context) {

7 database = new CreateDatabase(context);
8 }
9 public String insertData(Ponto ponto) {
10 ContentValues valores;
11 long resultado;
12
826
13 db = database.getWritableDatabase();
14 valores = new ContentValues();
15 valores.put(CreateDatabase.NAME_LOCAL,ponto.getNome());
16 valores.put(CreateDatabase.LATITUDE, ponto.getLatitude()
);
17 valores.put(CreateDatabase.LONGITUDE, ponto.getLongitude
());
18
19
20 resultado = db.insert(CreateDatabase.TABLE, null,

valores);
21 db.close();
22
23 if (resultado ==-1)
24 return "Erro ao inserir registro";
25 else
26 return "Registro Inserido com sucesso";
27
28 }
29 public ArrayList<Ponto> carregaDados(){
30 Cursor cursor;
31 ArrayList<Ponto> list = new ArrayList<Ponto>();
32 String[] campos = {database.ID,database.NAME_LOCAL,
database.LATITUDE,database.LONGITUDE};
33 db = database.getReadableDatabase();
34 cursor = db.query(database.TABLE, campos, null, null,
null, null, null, null);
35
36 if(cursor.getCount() > 0){

37 cursor.moveToFirst();
38 do{
39 Ponto p = new Ponto();
40 p.setNome(cursor.getString(1));
41 p.setLatitude(cursor.getDouble(2));
42 p.setLongitude(cursor.getDouble(3));
43 list.add(p);
44
45 }while(cursor.moveToNext());
46 }
47
48 db.close();
49 return list;
50 }
51
52 public Cursor carregaDadoById(int id){

53 Cursor cursor;
54 String[] campos = {database.ID,database.NAME_LOCAL,
database.LATITUDE,database.LONGITUDE};
55 String where = CreateDatabase.ID + "=" + id;
827
57 cursor = db.query(CreateDatabase.TABLE,campos,where,
null, null, null, null, null);
58
59 if(cursor!=null){
60 cursor.moveToFirst();
61 }
62 db.close();
63 return cursor;
64 }
65 public void alteraRegistro(int id, String name,float lat,
float lon){
66 ContentValues valores;
67 String where;
68
69 db = database.getWritableDatabase();
70
71 where = CreateDatabase.ID + "=" + id;

72
73 valores = new ContentValues();

74 valores.put(CreateDatabase.NAME_LOCAL, name);
75 valores.put(CreateDatabase.LATITUDE, lat);
76 valores.put(CreateDatabase.LONGITUDE, lon);
77
78 db.update(CreateDatabase.TABLE,valores,where,null);
79 db.close();
80 }
81 public void deletaRegistro(int id){
82 String where = CreateDatabase.ID + "=" + id;
84 db.delete(CreateDatabase.TABLE,where,null);
85 db.close();
86 }
87 }
Executando Nosso Projeto

Antes de executar o projeto verifique no arquivo AndroidManifest.xml contem as permis-
sões necessárias. Agora que todo o projeto foi criado vamos executar nosso aplicativo. Há
duas formas de executar o projeto: rodar no emulador ou instalar em um dispositivo real.
Para executar, clique no menu Run->Run App. Uma janela será mostrada requisitando
onde instalar. Caso seu dispositivo Android esteja conectado no computador (via USB,
etc.) clique em OK, caso contrário visite o site Android Developers8 para solucionar
eventuais problemas. Após escolher o aparelho é só aguardar a instalação do apĺicativo.
8 https://developer.android.com/studio/run/index.html?utm_source=android-studio
828
Referências
[Alliance 2007] Alliance, O. H. (2007). Industry leaders announce open platform for
mobile devices.
[Djuknic and Richton 2001] Djuknic, G. M. and Richton, R. E. (2001). Geolocation and
assisted gps. Computer, 34(2):123–125.
[Elgin 2005] Elgin, B. (2005). Google buys android for its mobile arsenal.
[Ericsson 2013] Ericsson (2013). Ericsson mobility report: On the pulse of the networked
society. Technical report.
[GoogleDevelopers 2017] GoogleDevelopers (2017). Introduction to the google maps

android api.
[Java 2017a] Java (2017a). What is j2me or java me?
[Java 2017b] Java (2017b). What is java and why do i need it?
[QueConceito 2017] QueConceito (2017). Geolocalização.
[Stats 2017] Stats, S. G. (2017). Android overtakes windows for the first time. Technical
report.
[TecMundo 2017] TecMundo (2017). O que é geolocalização?
829
Capítulo
11
Monitoramento de tráfego em redes de Internet
das Coisas
Syllas Rangel C. Magalhães; Victória Tomé Oliveira; Francisco Evangelista

N. Filho; Wendley S. Silva
Resumo
De um modo geral, o conceito de Internet das Coisas (IoT) refere-se à interconexão de

objetos através da rede mundial de computadores (Internet), objetos que podem ser desde
dispositivos cotidianos, como os encontrados nas casas inteligentes, até equipamentos es-
pecíficos, como no caso de equipamentos para assistência médica. A massiva quantidade
de “objetos” nesse tipo de rede exige sistemas de comunicação cada vez mais robustos.
Recentes avanços nos sistemas de comunicações móveis e nas comunicações máquina-
a-máquina (M2M) prometem viabilizar a ascensão da IoT. Entretanto, devido ao alto
tráfego de dados e a enorme quantidade de dispositivos conectados, surgem alguns de-
safios como privacidade e segurança. Este minicurso apresentará uma forma simples de
analisar o tráfego de dados em uma rede IoT através do microcomputador single-board
Raspberry PI® , com foco na análise dos protocolos mais críticos para esse tipo de rede.
11.1. Introdução
Nos últimos anos houve um significativo crescimento da adoção de dispositivos sem fio,
tais como smartphones, tablets, câmeras, notebooks e sensores de saúde. As projeções
da empresa Cisco sugerem que esse crescimento continuará, e entre os anos de 2016 e
2021 ocorrerá um crescimento de 7,3 vezes na quantidade de dispositivos inteligentes
conectados [Cisco, 2017]. Tais dispositivos, associados com as novas tecnologias de co-
municação da Internet atual e futura, compõem o que muitas vezes é classificada como
Internet das Coisas (IoT, do inglês Internet of Things).
Conceituar Internet das Coisas não é uma tarefa fácil. O termo foi utilizado pela
primeira vez pelo britânico Ashton e seus colegas de laboratório, no trabalho “I made at
Procter & Gamble” publicado em 1999 [Ashton, 2009]. Contudo, IoT também pode ser
compreendida como uma infraestrutura de rede que liga objetos físicos e virtuais atra-
vés da captura de dados e comunicação a uma plataforma que possibilita a execução de
830
uma aplicação [Gubbi et al., 2013]. Essa infraestrutura de comunicação inclui a Internet,
outras redes existentes e em desenvolvimento.
Os sistemas IoT geralmente possuem a identificação específica do objeto e a capa-
cidade de interconexão como princípios para o desenvolvimento de serviços cooperativos
independentes. Em razão disso, algumas vezes os termos Machine-to-Machine (M2M) e
IoT são utilizados de forma intercambiável, no entanto, a característica diferencial e mais
importante de IoT é a informação que os objetos conectados podem fornecer, e como
essas informações podem ser combinadas e apresentadas por uma aplicação.
Neste trabalho, serão apresentadas as definições e motivações para as pesquisas
de Internet of Things, com atenção especial às aplicações, que serão descritas a fim de
despertar o interesse do participante acerca das técnicas utilizadas. Também serão discu-
tidos os elementos que compõem a IoT e os seus principais protocolos de comunicação.
A parte prática do minicurso ficará na Seção Análise de Tráfego, onde serão apresenta-
das as técnicas de monitoramento de tráfego em redes IoT, bem como será detalhada a
utilização de softwares para o monitoramento.
11.2. Elementos da IoT

Elementos de IoT (Internet of Things) podem ser definidos como componentes,
representados em blocos na Figura 11.1, que integram um ambiente de Internet of Things.
Compreendê-los é importante, pois contribui na real definição de Internet of Things, além
de fornecer uma ampla visão de suas funcionalidades.
Figura 11.1. Elementos de Internet of Things [Al-Fuqaha et al., 2015].
Como visto acima, um ambiente IoT, do mais básico ao mais complexo, é formado
por seis elementos: identification, sensing, communication, computation, services e se-
mantics [Al-Fuqaha et al., 2015]. Cabe ressaltar que alguns autores condensam os seis
elementos em três: hardware, middleware e presentation [Gubbi et al., 2013]. A seguir,
cada um desses blocos será analisado mais detalhadamente.
831
11.2.1. Identification
O processo de identificação (identification) é importante, pois é responsável por
atribuir um identificador aos objetos e serviços ofertados. Dessa forma, reconhecer que
determinada solicitação ocasionou uma tarefa qualquer torna-se um processo mais sim-
ples. Além disso, esse procedimento permite diferenciar o ID (nome) de um objeto de seu
endereço (valor atribuído dentro da rede de comunicação), o que permite solucionar até
mesmo problemas ocasionados pela utilização de redes públicas [Al-Fuqaha et al., 2015].
A etapa identification é equivalente, por exemplo, ao Electronic Product Code (EPC),
uCode e ao Digital Object Identifier (DOI), que são, respectivamente, padrões para iden-
tificar unicamente objetos físicos no mundo real, objetos/lugares no mundo real e docu-
mentos digitais. Para realizar esse processo em ambientes IoT, são utilizados, sobretudo,
cabeçalhos de protocolos, como por exemplo IPv4, IPv6 e 6LoWPAN [Ferreira, 2013].
11.2.2. Sensing
Comumente chamados de sensores ou atuadores, são dispositivos capazes de co-
letar os dados dos objetos contidos em uma rede de comunicação. Eles são capturados
e enviados de volta a um data warehouse (sistema de armazenamento de dados digitais),
banco de dados ou nuvem, para que possam ser armazenados, analisados e para que ações
necessárias sejam executadas. Atualmente, muitas empresas estão investindo em produtos
para realização dessa etapa, como a WeMo, ZigBee, entre outras.
11.2.3. Communication
O objetivo das redes de comunicação de Internet of Things é conectar diferen-
tes objetos, para que sejam capazes de fornecer serviços inteligentes. Comumente, es-
sas redes são de baixas frequências e operam em ambientes onde há perdas e ruídos
[Al-Fuqaha et al., 2015]. A etapa communication consiste em estudar a utilização de pro-
tocolos e tecnologias capazes de realizar as tarefas acima citadas, com perdas e ruídos re-
duzidos. Entre as tecnologias mais populares, encontram-se: WiFi, Bluetooh,
IEEE 802.15.4, Z-wave, NFC (Near Field Communication), UWB (Ultra-wide bandwish),
RFID (Radio-frequency identification) e LTE-advanced. As tecnologias utilizadas na re-
alização desse minicurso serão melhor descritas na Seção 11.3.
11.2.4. Computation
Essa etapa é definida como o “cérebro físico” da Internet of Things. É responsável
por realizar o processo descrito na Subseção 11.2.2. Atualmente, muitos microcontrola-
dores e Single Board Computers (SBCs) são capazes de simular ambientes IoT. Entre
os mais comuns estão: Arduino, Raspberry Pi® - utilizado na produção do minicurso -,
BeagleBone, Galileo Gen 2, entre outros. Além dos hardwares, os softwares também
se encontram mais refinados. Ações como sistemas operacionais com funcionalidades
nativas para ambientes IoT ou até mesmo empresas desenvolvendo softwares específicos
(Contiki RTOS, TinyOS, LiteOS, RiotOS e OAA) estão se difundindo. Cabe ressaltar
que a evolução dos serviços em nuvem também representou um grande avanço para a
Internet of Things, pois permitiu armazenamento e processamento em tempo real de um
volume considerável de dados, o que acarretou em mais informações para que os usuários
aperfeiçoem suas redes de comunicação IoT [Al-Fuqaha et al., 2015].
832
11.2.5. Services
Ambientes IoT podem ser classificados em quatro classes: identity-related ser-
vices, information aggregation services, collaborative-aware services e ubiquitous ser-
vices [Al-Fuqaha et al., 2015]. Essas classes definem as funcionalidades e aplicações de
uma rede de comunicação de Internet of Things, como, por exemplo: smart grids, smart
city, smart healthcare, industrial automation, entre outras. O bloco services diz respeito
ao que uma rede de comunicação IoT é capaz de aprovisionar. Explorar cada uma das
classes foge do escopo do minicurso. Entretanto, esses exemplos são suficientes para
entendermos o poder e importância da Internet of Things.
11.2.6. Semantics
A etapa de semântica (semantics) consiste em extrair conhecimento de uma rede
de comunicação de Internet of Things - composta por diversos componentes/objetos -,
para que as solicitações realizadas possam ser atendidas, ou seja, para fornecer os ser-
viços mínimos necessários. Um ambiente IoT realiza esse procedimento através da des-
coberta, utilização, análise e modelagem dos recursos fornecidos. Uma equivalência da
semantics seria a utilização de uma Inteligência Artificial (IA) na automatização de um
procedimento.
De forma análoga à definição de communication da Subseção 11.2.4, o processo
de semantics pode ser analisado como as sinapses do “cérebro físico”. Ademais, pode-
se citar algumas tecnologias utilizadas nessa etapa: Resource Description Framework
(RDF), Web Ontology Language (OWL), Efficient XML Interchange (EXI).
Por fim, na Tabela 11.1 é exibido um resumo do que foi exposto na Seção 11.1.
Tabela 11.1. Síntese da Seção 11.2 [Al-Fuqaha et al., 2015].

Elementos de Internet das Coisas Exemplos
Nomear EPC, uCode, DOI, etc.
Identification
Endereçar IPv4, IPv6, 6LoWPAN, etc.
Sensores, atuadores, dispositivos
Sensing
vestíveis, embarcados, etc.
WiFi, Bluetooh, IEEE 802.15.4, Z-wave,
Communication
LTE-advanced, UWD, RFID, etc.
Arduino, RaspBerry Pi® , BeagleBone,
Hardware
Computation Galileo Gen 2, Smartphones, Smarthings, etc.
Contiki RTOS, TinyOS, LiteOS, RiotOS,
Software
OAA, Nimbits, etc.
Services Smart grids, Smart homes, Smart city, etc.
Semantics RDF, EXI, OWL, etc.
833
11.3. Protocolos de IoT

Com o crescimento de redes de comunicação IoT, está havendo um aumento no
número de dispositivos conectados à Internet. Esse fenômeno ocorre, sobretudo pela
heterogeneidade dos dispositivos utilizados em ambientes IoT. Devido a isso, torna-se es-
sencial o estudo e desenvolvimento de protocolos que possam, por exemplo, suprir limita-
ções impostas pelos dispositivos, como ocorre em muitos casos. Diferentes grupos foram
criados para fornecer protocolos de apoio à Internet das Coisas, incluindo alguns lidera-
dos pela World Wide Web Consortium (W3C), Internet Engineering Task Force (IETF),
EPCglobal, Institute of Electrical and Electronics Engineers (IEEE) e o European Tele-
communications Standards Institute (ETSI) [Al-Fuqaha et al., 2015]. Na Tabela 11.2 são
exibidos alguns dos principais protocolos utilizados em ambientes IoT, separados em 4
grupos, como proposto em [Al-Fuqaha et al., 2015], denominados: protocolos de aplica-
ção, protocolos de descoberta de serviços, protocolos de infraestrutura e outros protocolos
influentes. Nas subseções a seguir, será apresentada uma visão geral de alguns destes pro-
tocolos, citando suas principais características e funcionalidades, de acordo com a classi-
ficação proposta. Dar-se-á uma atenção especial aos protocolos CoAP e MQTT, ambos
da camada de aplicação.
Tabela 11.2. Protocolos relacionados à IoT [Al-Fuqaha et al., 2015].

Protocolos de aplicação AMQP CoAP DDS HTTP REST MQTT XMPP
Protocolos de descoberta de serviços mDNS DNS-SD
Roteamento RPL
Camada
6LoWPAN IPv4/IPv6
de Rede
Camada
Protocolos IEEE 802.15.4
de Enlace
de infraestrutura
Camada
LTE-A EPCglobal IEEE 802.15.4 Z-Wave
Física/Dispositivo
Outros protocolos influentes IEEE 1888.3 IPSec IEEE 1905.1
11.3.1. Protocolos de aplicação

O protocolo HTTP é utilizado na Internet para prover o acesso à informação desde
1990, constituindo a base para a comunicação de dados na World Wide Web (WWW).
Embora tenha passado por algumas reformulações depois de sua criação, o HTTP foi
projetado para redes com computadores pessoais, com maior poder de processamento se
comparado aos dispositivos utilizados em redes IoT. As restrições impostas pelos equipa-
mentos utilizados em ambientes IoT limitam o uso do protocolo HTTP nesses. Sendo as-
sim, surgem alguns protocolos na camada de aplicação como alternativa ao HTTP, como,
por exemplo, o CoAP e MQTT, ambos projetados para troca de informação entre dis-
positivos com baixo poder computacional. Além destes, outros protocolos vêm sendo
utilizados em redes IoT, como é caso do XMPP, AMQP e DDS. A seguir, alguns destes
protocolos serão detalhados.
834
Tabela 11.3. Formada da mensagem CoAP [Shelby et al., 2014].

01 23 4 7 8 15 16 31
Ver T TKL Código ID da Mensagem
Token (caso exista, com TKL bytes) ...
Opções (caso existam) ...
1 1 1 1 1 1 1 1 Payload (caso exista) ...
11.3.1.1. Constrained Application Protocol (CoAP)
O Constrained Application Protocol (CoAP) foi proposto pelo IETF Constrai-

ned RESTful Environments (CoRE) working group, com o objetivo de otimizar o uso da
arquitetura REST (REpresentational State Transfer) em nós - por exemplo, microcon-
troladores de 8 bits com RAM e ROM limitadas - e redes (e.g. 6LoWPAN) com poder
computacional restrito [Kuladinithi et al., 2011] [Shelby et al., 2014]. A forma de inte-
ração do CoAP é semelhante ao modelo cliente/servidor no protocolo HTTP, entretanto,
ele também oferece recursos para M2M (Machine-to-Machine), como descoberta interna,
suporte multicast e trocas de mensagens assíncronas. Semelhante ao HTTP, uma solici-
tação CoAP é enviada por um cliente para solicitar uma ação usando Uniform Resource
Identifiers (URIs), que em seguida é respondido pelo servidor com um código de resposta
[Joshi and Kaur, 2015]. Ao contrário do REST (que utiliza HTTP sobre TCP), o CoAP
funciona sobre UDP por padrão, o que o torna mais adequado para as aplicações IoT.
Além disso, o CoAP modifica algumas funcionalidades HTTP para atender aos requisitos
de IoT, como baixo consumo de energia e operação na presença de links com perdas e
ruídos. No entanto, como o CoAP foi projetado com base em REST, a tradução entre os
protocolos HTTP e CoAP é facilitada.
O CoAP pode ser representado com duas camadas em sua arquitetura: uma res-
ponsável pela implementação dos mecanismos de requisição/resposta e a outra pela co-
municação e, opcionalmente, confiabilidade sobre UDP. Ele possui, ainda, quatro tipos
de mensagens: confirmable, non-confirmable, reset e acknowledgement. Uma mensagem
do tipo confirmable (CON) requer uma resposta do receptor com uma confirmação de
recebimento. Essa é contrária à mensagem non-confirmable (NON), que não garante o
recebimento no receptor, uma vez que este tipo de mensagem, como o próprio nome su-
gere, não exige confirmação. A mensagem de confirmação propriamente dita é chamada
de acknowledgement (ACK). Ela é transmitida em resposta a uma mensagem confirmable
recebida de forma correta. Por fim, a tipo reset (RST) é enviada basicamente em três
situações: quando ocorre erro na mensagem; quando a mensagem não é compreensível;
quando o receptor não está interessado na comunicação com o remetente.
As mensagens CoAP são codificadas em um formato binário simples. A primeira
parte da mensagem é um cabeçalho fixo de 4 bytes, que pode ser seguido por um token,
algumas opções e um payload, como ilustrado na Tabela 11.3. O cabeçalho fixo é divi-
dido em cinco partes: Ver (versão do protocolo), T (tipo de mensagem), TKL (tamanho
do campo Token), Código e ID da mensagem. Os três bits mais significativos do campo
código carregam a informação de qual classe a mensagem pertence, podendo indicar uma
requisição (0), uma resposta bem-sucedida (2), uma resposta de erro do cliente (4) ou
835
uma resposta de erro do servidor (5). Já os cinco bits menos significativos desse campo,
representam uma subclasse de mensagem. Por exemplo, para uma mensagem de requisi-
ção que utiliza o método GET, o campo código seria representado por “0.01”, em que o
primeiro dígito indica a classe (nesse caso requisição) e os dois dígitos depois do ponto
representam a subclasse (nesse caso GET) [Shelby et al., 2014]. Na tabela 11.4 estão
representados todos os códigos de resposta CoAP.
Tabela 11.4. Códigos de resposta CoAP [Shelby et al., 2014].

Código Nome Descrição
2.01 Created Resposta a uma requisição PUT ou POST (criado)
2.02 Deleted Resposta a uma requisição que torna um recurso indisponível
2.03 Valid Indica que a resposta identificada pela entity-tag é válida
2.04 Changed Resposta a uma requisição PUT ou POST (modificado)
2.05 Content Indica a presença do conteúdo requisitado em um GET
4.00 Bad Request Indica que o servidor não “entendeu” a requisição
4.01 Unauthorized O cliente não está autorizado a executar a ação solicitada
4.02 Bad Option O servidor não reconheceu uma ou mais opção crítica
4.03 Forbidden Acesso ao recurso é proibido
4.04 Not Found Não encontrado
4.05 Method Not Allowed Método não permitido
4.06 Not Acceptable O recurso de destino não possui uma representação aceitável
4.12 Precondition Failed Precondição falhou
4.13 Request Entity Too Large Entidade de requisição muito grande
4.15 Unsupported Content-Format Context-format não suportado
5.00 Internal Server Error Erro interno no servido
5.01 Not Implemented Não implementado
5.02 Bad Gateway Erro quando o servidor atuava como gateway ou proxy
5.03 Service Unavailable Serviço indisponível
5.04 Gateway Timeout Timeout quando o servidor atuava como gateway ou proxy
5.05 Proxying Not Supported Proxying não suportado
Na Figura 11.2 são exibidas duas situações de uma comunicação CoAP. Na es-
querda (Figura 11.2a) é mostrado um exemplo de uma transmissão de mensagem com
confirmação (ACK). Neste caso, o transmissor continua retransmitindo a mensagem de
acordo com um timeout padrão até que receba uma mensagem ACK com o mesmo ID
da mensagem enviada (neste caso 0x7d34). Já na Figura 11.2b é mostrado um exem-
plo simples de uma transmissão não confiável (sem confirmação), em que o transmissor
simplesmente envia uma mensagem e não requer nenhum tipo de confirmação. Em am-
bas as situações quando o destinatário não é capaz de processar a mensagem, ou seja,
nem mesmo é capaz de fornecer uma resposta de erro adequada, ele responde com uma
mensagem reset (RST).
Existem quatro métodos de requisição CoAP que foram definidos em
[Shelby et al., 2014], sendo eles GET (código 0.01), POST (código 0.02), PUT (código
0.03) e DELETE (código 0.04). As requisições podem ser realizadas em mensagens do
tipo confirmable (CON) ou non-confirmable (NON). No caso de a resposta a uma requi-
sição CoAP do tipo confirmable estar disponível imediatamente, esta é enviada junto à
mensagem de confirmação (ACK), ocasião em que é chamada de resposta piggy-backed.
Na Figura 11.3a são ilustradas duas situações onde ocorre uma resposta piggy-backed. Na
836
Figura 11.2. Comunicação CoAP com e sem confirmação de recebimento

[Shelby et al., 2014].
(a) Com confirmação (b) Sem confirmação
primeira, a requisição obteve uma resposta satisfatória e no segundo caso uma resposta
de 4.04 (Not found). Por outro lado, a Figura 11.3b mostra uma requisição GET do tipo
confirmable com respostas separadas. Neste caso, o servidor não estava disponível para
responder imediatamente a requisição. Dessa forma, para que o cliente fique ciente de
que a requisição foi recebida corretamente e pare de retransmitir a mensagem, é enviada
uma confirmação (ACK) vazia. Após algum tempo, quando a resposta estiver disponível,
o servidor a envia com solicitação de confirmação. Cabe ressaltar que, neste caso, a dis-
tinção entre as respostas esperadas pelo cliente é feita a partir do Token (não confundir
com ID da mensagem) que, apesar de ter sido abstraído nos exemplos anteriores, está
em todas as mensagens CoAP. No caso de uma requisição sem confirmação (NON), a
comunicação ocorrerá de forma parecida, porém todas as respostas também serão do tipo
non-confirmable (não existirão mensagens de ACK na comunicação).
Figura 11.3. Requisições CoAP [Shelby et al., 2014].
(a) Com resposta piggy-backed (b) Com respostas se-

paradas
Informações detalhadas sobre a arquitetura e funcionamento do protocolo CoAP

podem ser encontradas em [Shelby et al., 2014].
837
11.3.1.2. Message Queue Telemetry Transport (MQTT)
O MQTT é um protocolo de mensagens introduzido por Andy Stanford-Clark da

IBM e Arlen Nipper da Arcom (agora Eurotech) em 1999 e foi padronizado em 2013 pela
OASIS1 . Esse protocolo é otimizado para redes com capacidade de processamento limi-
tado, pequena capacidade de memória ou alta latência. Comparado ao HTTP, o MQTT
oferece várias vantagens aos aplicativos móveis: tempos de resposta mais rápidos, maior
produtividade, maior confiabilidade de mensagens, baixo uso de banda e baixo consumo
da bateria [Chen et al., 2014]. Desde a sua criação, o MQTT passou por algumas modifi-
cações significativas e atualmente está em sua versão 3.1.1.
O MQTT possui arquitetura cliente/servidor e utiliza, para troca de mensagens,
o paradigma publish/subscribe (pub/sub). Diferente do CoAP, neste protocolo todas as
“coisas” são clientes que se conectam a um servidor, denominado broker. O broker é
responsável por receber, enfileirar e disparar as mensagens recebidas dos publicadores
(publishers) para os assinantes (subscribers) [Desai, 2015]. Neste protocolo, a conexão
ao broker pode ser feita através do TCP, TLS ou WebSocket e toda a troca de mensagens
é baseada no conceito de tópico (topic), que nada mais é do que um endereço.
Na comunicação MQTT, inicialmente, os dispositivos se conectam ao broker e em
seguida podem se registrar em um ou mais tópicos do broker (subscribe) para obter todas
as informações que forem “publicadas” nestes tópicos. As informações, por sua vez, são
introduzidas pelos publicadores (publishers), que também precisam estar conectados ao
broker. Para exemplificar o funcionamento deste protocolo, imagine a seguinte situação:
um dispositivo A possui um sensor que mede constantemente a temperatura em determi-
nada região e precisa relatar periodicamente a outros dois dispositivos (B e C). Utilizando
a comunicação MQTT, este problema poderia ser facilmente resolvido como ilustrado na
Figura 11.4.
Figura 11.4. Exemplo de comunicação MQTT [Elaborada pelos autores].
(a) Conexão ao broker (b) Publicação da mensagem
Como mostrado na Figura 11.4a, inicialmente, todos os dispositivos precisam ini-

ciar uma conexão TCP com o broker e os dispositivos interessados na temperatura. Além
1 http://mqtt.org/faq
838
disso, precisam se inscrever no tópico “temperatura”. Dessa forma, toda vez que o dispo-
sitivo A publicar a temperatura no tópico de interesse, o broker se encarregará de enviar
a informação para todos os subscribers deste tópico. Na Figura 11.4b é mostrado um
exemplo de publish, em que o dispositivo A publica uma temperatura de 25 °C.
O protocolo MQTT funciona através da troca de uma série de pacotes de controle.
Um pacote de controle MQTT pode conter até três partes, sendo elas o cabeçalho fixo
(fixed header), o cabeçalho variável (variable header) e o payload, sempre nesta ordem
[Standard, 2014]. Todo pacote de controle MQTT deve conter, pelo menos, o cabeçalho
fixo. O tamanho deste cabeçalho varia de 2 a 5 bytes, onde o primeiro byte contém
o tipo de mensagem (do bit 7 ao 4) e algumas flags (do bit 3 ao 0), que, entre outras
informações, podem indicar o nível de QoS (qualidade de serviço) da transmissão (bits 1
e 2), divididos em três: (i) QoS 0, (ii) QoS 1 e (iii) QoS 2. Em (i) a mensagem é entregue,
no máximo, uma vez; já em (ii) a mensagem é entregue, pelo menos, uma vez; por fim,
em (iii), a mensagem é entregue exatamente uma vez. A segunda parte do cabeçalho fixo,
chamada “comprimento restante”, codifica a quantidade de bytes restantes no pacote (não
considera o tamanho do cabeçalho fixo) e contém entre 1 e 4 bytes. Neste caso, os sete
bits menos significativos de cada byte codificam a informação e o bit mais significativo
indica continuação, ou seja, caso seja “1”, indica que existe, pelo menos, mais um byte
de “comprimento restante”. Pode existir, ainda, um cabeçalho variável e um payload no
pacote, dependendo do tipo de mensagem. A estrutura básica de um pacote MQTT é
representada na Tabela 11.5.
Tabela 11.5. Estrutura de um pacote de controle MQTT [Al-Fuqaha et al., 2015].

7 6 5 4 3 2 1 0
Tipo do pacote Sinalizadores (Flags)
Comprimento restante (1∼4 bytes)
Cabeçalho variável (opcional)
Payload (opcional)
Apesar de existirem diversos tipos de pacotes MQTT, representados na Tabela 11.6,

muitas aplicações do protocolo podem ser realizadas apenas com os comandos CON-
NECT, PUBLISH, SUBSCRIBE e DISCONNECT [Chen et al., 2014]. O comando CON-
NECT deve, obrigatoriamente, ser o primeiro pacote enviado após o estabelecimento da
conexão da rede com o servidor. Além disso, esse deve ser enviado apenas uma vez. Caso
contrário, o cliente será desconectado. No pacote CONNECT deve ser enviado um identi-
ficador único para o cliente e, opcionalmente, informações como nome de usuário, senha,
Will topic (tópico que receberá a mensagem “Will” caso a conexão seja encerrada sem a
utilização do comando DISCONNECT), entre outras, desde que sinalizadas no cabeçalho
variável. Por outro lado, o comando DISCONNECT é utilizado quando o cliente quer
informar explicitamente sua desconexão ao servidor. Neste caso, a mensagem “Will”,
caso exista, deve ser descartada. Na Seção 11.4 serão dados mais detalhes dos pacotes
PUBLISH e SUBSCRIBE, bem como outros aspectos relevantes da comunicação neste
protocolo e exemplos práticos. Todas as flags e informações sobre os pacotes MQTT são
detalhadas em [Standard, 2014].
839
Tabela 11.6. Tipos de pacotes de controle do MQTT versão 3.1.1 [Standard, 2014].
Nome Código Direção de Fluxo Descrição
Reservado 0 Proibido Reservado
CONNECT 1 Cliente → Servidor Requisição de conexão
CONNACK 2 Cliente ← Servidor ACK de conexão
PUBLISH 3 Cliente Servidor Publicação de mensagem
PUBACK 4 Cliente Servidor ACK de publicação
PUBREC 5 Cliente Servidor Publicação recebida (QoS 2, parte 1)
PUBREL 6 Cliente Servidor Publicação liberada (QoS 2, parte 2)
PUBCOMP 7 Cliente Servidor Publicação completa (QoS 2, parte 3)
SUBSCRIBE 8 Cliente → Servidor Requisição de subscribe
SUBACK 9 Cliente ← Servidor ACK de subscribe
UNSUBSCRIBE 10 Cliente → Servidor Requisição de cancelamento de subscribe
UNSUBACK 11 Cliente ← Servidor ACK de cancelamento de subscribe
PINGREQ 12 Cliente → Servidor Requisição PING
PINGRESP 13 Cliente ← Servidor Resposta PING
DISCONNECT 14 Cliente → Servidor Solicitação de desconexão
Reservado 15 Proibido Reservado
11.3.2. Protocolos de descoberta de serviços

A alta escalabilidade do IoT requer um mecanismo de gerenciamento de recursos
que seja capaz de se registrar e descobrir recursos e serviços de forma autoconfigurada,
eficiente e dinâmica. Os protocolos mais dominantes nesta área são o DNS de multicast
(mDNS) e DNS Service Discovery (DNS-SD), que podem descobrir recursos e serviços
oferecidos pelos dispositivos IoT.
Embora esses dois protocolos tenham sido projetados originalmente para disposi-
tivos ricos em recursos, existem estudos de pesquisa que adaptam versões leves deles para
ambientes IoT.
11.3.3. Protocolos de infraestrutura

Os protocolos de infraestrutura são necessários para estabelecer a comunicação
subjacente necessária para as aplicações IoT. O roteamento é um elemento-chave da in-
fraestrutura IoT e muitos outros parâmetros desses sistemas, como confiabilidade, esca-
labilidade e desempenho, que dependem fortemente dessa tecnologia. Portanto, há uma
necessidade de mais investigação sobre melhorias e otimizações de protocolos de rotea-
mento para atender aos requisitos de IoT.
RPL, 6LowPAN, IEEE 802.15.4, BLE, EPCglobal, LTE-A, Z-Wave, são protoco-
los de infraestrutura de uma rede de IoT. Cada um contém particularidades, vantagens e
desvantagens. Neste trabalho, dar-se-á uma breve descrição dos protocolos 6LowPAN e
IEEE 802.15.4.
840
11.3.3.1. 6LoWPAN
O acrônimo 6LoWPAN significa IPv6 Over Low Power Wireless Personal Network.
Ele foi criado com a intenção de manter as especificações que nos permitem usar o IPv6
em redes IEEE 802.15.4, pois o IPv6 suporta uma alta quantidade de endereçamentos de
dispositivos, porém seu tamanho é de 128 bits, o que gera um grande problema, pois se o
dispositivo tiver uma baixa capacidade de memória e baixa potência ele não o suportará.
O 6LoWPAN contém RFC (Request For Comments). Cada RFC define standards
de métodos, comportamentos, pesquisas ou inovações capazes de definir a compressão,
encapsulação e fragmentação do cabeçalho dos pacotes IPv6 em frames IEEE 802.15.4,
permitindo que os mesmos sejam enviados e recebidos nessas redes [Ferreira, 2013].
Este protocolo se fundamenta na concepção de que a Internet é construída em IP,
ou seja, cada dispositivo deverá possuir um IP fazendo, assim, parte da Internet of Things
(IoT).
Cada rede de 6LoWPAN compartilha o mesmo prefixo de endereço. A capacidade
total de cada rede é de 64.000 dispositivos, devido aos limites impostos pelo endereça-
mento utilizado pelo IEEE 802.15.4, que usa 16 bits de endereços para cada dispositivo
na rede, obtendo uma identificação IPv6 única. O 6LoWPAN, sem dúvida, apresenta-se
como a melhor alternativa para a integração das WPANs à Internet e às redes IP.
11.3.3.2. IEEE 802.15.4
O protocolo IEEE 802.15.4, mais conhecido como ZigBee, foi criado pelo IEEE
em parceria com a ZigBee Alliance. Foi desenvolvido com a intenção de disponibilizar
uma rede de baixa potência de operação, que acarreta em um baixo consumo de energia
nos dispositivos, prolongando a vida útil das baterias desses dispositivos. IEEE 802.15.4
é um padrão que especifica a camada física e efetua o controle de acesso para redes sem
fio pessoais de baixas taxas de transmissão. A rede tem mais utilidade em dispositivos
que não precisam de taxas de transmissão de dados altíssimas.
Quando o protocolo IEEE 802.15.4 foi criado, suas principais aplicações eram:
controle remoto e automação. Hoje em dia, além dessas duas finalidades, ele também é
utilizado nas áreas de redes e de compartilhamento de dados. Suas principais caracterís-
ticas são:
• Diferentes frequências de operação e taxa de dados: 868 MHz e 20 Kbps; 915 MHz
e 40 Kbps; 2.4 GHz e 250 Kbps;
• Um mesmo dispositivo pode executar diferentes papéis em uma mesma rede;
• Configurações em diversas topologias de rede;
• Habilidade de se auto-organizar e auto-reestruturar – self-organizing e self-healing;
• Número elevado de dispositivos conectados à rede (máximo de 65.535 dispositivos

por cada equipamento coordenador);
841
• Alta durabilidade da bateria dos dispositivos;
• A capacidade de se comunicar de forma transparente com outros sistemas, ou seja,

interoperabilidade.
As comunicações por ZigBee são feitas na faixa das frequências ISM (Industrial
Scientific and Medical), são elas: 2.4 Ghz (mundialmente), 915 Mhz (na América) e
868 Mhz (na Europa). Nesse contexto, a taxa de transferência dos dados é de até 250kbps
na frequência de 2.4 Ghz operando com 16 canais; 40 kbps na frequência de 915 Mhz
operando com 10 canais; 20 kbps na frequência de 868 Mhz operando com 1 canal
[DesmontaCia, 2011].
O padrão IEEE 802.15.4 foi fragmentado em duas camadas: uma desenvolvida
pela IEEE (camada inferior) e outra pela ZigBee Alliance (camada superior), como pode
ser observado na Tabela 11.7.
Tabela 11.7. Camadas da tecnologia Zigbee [Vasques, 2010].

Usuário Aplicação
Suporte a Aplicação
ZigBee Alliance
Rede (NWK)/Segurança (SSP)
MAC
IEEE 802.15.4
PHY
Em redes de comunicações que utilizam o protocolo ZigBee o dispositivo fica por

longos períodos sem se comunicar com o outro. Seu tempo de acesso conectado é cerca
de 30 ms. Por conta dessa característica o protocolo IEEE 802.15.4 é mais econômico em
relação ao consumo de energia.
11.4. Análise de tráfego

As seções anteriores trouxeram uma visão geral sobre as bases da IoT, em especial
dos protocolos CoAP e MQTT. Esta seção, por outro lado, tem como objetivo mostrar ao
leitor na prática alguns dos conceitos vistos anteriormente, dando uma ênfase maior a aná-
lise de tráfego dos protocolos CoAP e MQTT. Para realizar os experimentos será utilizado
o microcomputador single-board Raspberry Pi 2 com sistema operacional Raspbian2 , em
sua versão com desktop. Entretanto, as práticas podem ser facilmente adaptadas a outros
sistemas operacionais, assim como a outros microcomputadores, ficando a cargo do leitor
realizar tais adaptações.
Com o intuito de se obter um cenário mais próximo de uma rede IoT real, em
que grande parte das “coisas” sofrem com severas restrições de poder computacional, em
alguns experimentos será utilizada a plataforma open-source Arduino3 . Toda a análise
de tráfego será feita com auxílio da ferramenta de análise de rede Wireshark4 , entretanto
outra ferramenta similar pode ser utilizada.
2 https://www.raspberrypi.org/downloads/raspbian/
3 https://www.arduino.cc/
4 https://www.wireshark.org/
842
11.4.1. Preparando o ambiente

Os requisitos para realizar os experimentos são descritos abaixo:
• 1 Rapberry Pi 2 ou 3 com SO Raspbian
• 1 Arduino Uno ou Mega
• 1 Arduino Ethernet Shield
• 1 Roteador Wireless
• Arduino IDE
• Wireshark versão 2.2.6 ou superior
• Conexão com a internet
Para a realização dos experimentos o primeiro passo é a instalação do analisador

de protocolos Wireshark. No Raspbian, abra o terminal e digite o seguinte comando:
$ s u d o a p t −g e t i n s t a l l w i r e s h a r k
Após a instalação do Wireshark, para o primeiro experimento, é necessário a ins-

talação de um servidor CoAP. Existem diversas implementações do protocolo CoAP5 ,
algumas bem completas, outras nem tanto. Para os experimentos a libcoap6 , implementa-
ção em C do protocolo CoAP, será utilizada. Para proceder com a instalação no Raspbian,
o primeiro passo é instalar as dependências, para isso, no terminal, digite o comando:
$ s u d o a p t −g e t i n s t a l l a u t o c o n f a u t o m a k e l i b t o o l
Após isso, deve-se realizar o download da libcoap, disponível no GitHub. Para

isso, ainda no terminal, digite:
$ g i t c l o n e h t t p s : / / g i t h u b . com / obgm / l i b c o a p . g i t
Após a conclusão do download, ainda no Raspberry, vá até o diretório criado

($ cd libcoap) e execute a seguinte sequência de comandos:
$ . / autogen . sh
$ . / c o n f i g u r e −−d i s a b l e −d o c u m e n t a t i o n
$ make
$ s u d o make i n s t a l l
Se tudo correr bem, neste ponto a implementação libcoap estará instalada e configurada.
Para o segundo experimento será necessária a instalação de um broker MQTT.
Assim como para o CoAP, existem diversas implementações do MQTT para diferentes
plataformas. Neste experimento será utilizada uma das implementações mais famosas
e estáveis do protocolo, o Mosquitto. O Mosquitto suporta as versões 3.1 e 3.1.1 do
5 http://coap.technology/impls.html
6 https://github.com/obgm/libcoap
843
MQTT e pode ser facilmente instalado no Raspberry Pi. Antes da instalação é importante
certificar-se que será instalada a versão mais recente do broker, para isso basta abrir o
terminal do seu Raspberry (ou fazer login via SSH) e digitar a seguinte sequência de
comandos:
$ s u d o wget h t t p : / / r e p o . m o s q u i t t o . o r g / d e b i a n / m o s q u i t t o −r e p o . gpg . key
$ s u d o a p t −key add m o s q u i t t o −r e p o . gpg . key
$ cd / e t c / a p t / s o u r c e s . l i s t . d /
$ s u d o wget h t t p : / / r e p o . m o s q u i t t o . o r g / d e b i a n / m o s q u i t t o − s t r e t c h . l i s t
$ s u d o a p t −g e t u p d a t e
A palavra “stretch” no quarto comando da sequência acima refere-se à versão do

Debian que está rodando no Raspberry. Antes da instalação do Mosquitto é necessário
atualizar (se já não estiverem) algumas dependências. Para isso, digite:
$ wget h t t p : / / s e c u r i t y . d e b i a n . o r g / d e b i a n −s e c u r i t y / p o o l / u p d a t e s / main / o /
o p e n s s l / l i b s s l 1 . 0 . 0 _1 . 0 . 1 t −1+d e b 8 u 6 _ a r m h f . deb
$ s u d o dpkg − i l i b s s l 1 . 0 . 0 _1 . 0 . 1 t −1+d e b 8 u 6 _ a r m h f . deb
$ wget h t t p : / / f t p . nz . d e b i a n . o r g / d e b i a n / p o o l / main / l i b w / l i b w e b s o c k e t s /
l i b w e b s o c k e t s 3 _ 1 . 2 . 2 − 1 _ a r m h f . deb
$ s u d o dpkg − i l i b w e b s o c k e t s 3 _ 1 . 2 . 2 − 1 _ a r m h f . deb
Feito isso, seu Raspberry já estará pronto para a instalação do broker, bastando
digitar:
$ s u d o a p t −g e t i n s t a l l m o s q u i t t o
11.4.2. Experimento 1: Análise de tráfego da comunicação CoAP

O objetivo deste experimento é mostrar como a comunicação em ambientes res-
tritos CoAP ocorre através da análise do tráfego na rede. Toda a análise será feita através
do microcomputador Raspberry Pi, com auxílio do software Wireshark. Na Figura 11.5
é mostrado o ambiente utilizado para a realização da prática. Entretanto, devido a ne-
cessidade de conectar o Arduino através da rede Ethernet, para a interconexão entre os
dispositivos foi utilizado um roteador (abstraído na Figura 11.5).
Figura 11.5. Cenário utilizado no experimento [Elaborada pelos autores].
844
Com o servidor CoAP instalado e corretamente configurado, para que seja possí-
vel verificar como a comunicação ocorre, a instalação de um cliente CoAP é necessária.
Existem diversos clientes CoAP para diferentes plataformas, dentre eles pode-se citar a
Aneska7 para plataforma Android, a própria libcoap (projetada para dispositivos com re-
cursos computacionais limitados) e o Copper8 (extensão para o Firefox que habilita o
acesso aos recursos CoAP diretamente do navegador). Além dessas, existem diversas
outras implementações deste protocolo. Com o intuito de tornar a comunicação mais pró-
xima da prática em uma rede IoT, uma implementação simples do protocolo CoAP para
a plataforma Arduino será utilizada como cliente. Para isso deve-se baixar a biblioteca
CoAP-simple-library disponibilizada no GitHub9 e instalá-la no Arduino IDE (a própria
página web do Arduino disponibiliza um tutorial passo a passo de como fazer a instala-
ção10 ). Todos os exemplos encontrados na biblioteca são direcionados para a utilização de
uma placa Arduino em conjunto com uma Arduino Ethernet Shield. Entretanto, como as
implementações do CoAP para Arduino ainda são bastante limitadas, o experimento não
se restringirá a esta plataforma. Para analisar outros aspectos relevantes da comunicação,
a extensão Copper, para Firefox, será utilizada em um notebook.
No Raspbian, para iniciar a captura com o Wireshark abra o terminal e digite
sudo wireshark, após isso uma tela como a da Figura 11.6 deve ser mostrada. Esco-
lha a interface na qual o Raspberry está conectado na rede e inicie a captura de pacotes.
Após iniciar a captura de pacotes no Wireshark abra novamente o terminal, nave-
gue até o diretório libcoap (criado no momento da instalação) e digite o seguinte comando:
cd libcoap/examples. Em seguida, para iniciar o servidor coap digite o seguinte
comando: ./coap-server, este comando irá iniciar o servidor coap de exemplo. Por
padrão o servidor é iniciado na porta 5683.
No servidor de exemplo da libcoap existem alguns “recursos” que podem ser re-
quisitados. No notebook abra o Firefox e, caso ainda não tenha a extensão Copper, siga os
procedimentos de instalação de add-ons11 no navegador e instale-a. Feito isso, na barra
de endereços digite: coap://IPdoRasp:5683/, em que “IPdoRasp” deve ser substi-
tuído pelo endereço IP da interface utilizada no Raspberry. Feito isso, deve aparecer uma
tela como a da Figura 11.7. Vale ressaltar que para a comunicação ocorrer, todos os nós
devem estar na mesma sub-rede.
O primeiro recurso a ser explorado é a descoberta de serviços e recursos, para isso
click em core, a barra de endereços deve mudar para algo como coap://192.168.0.2:5683/
.well-known/core, em seguida click em GET. Feito isso, todos recursos disponíveis no
servidor serão mostrados, neste caso os recursos disponíveis são o “/time”, que retorna
a data e a hora local do servidor, o “/async”, que simula uma requisição/resposta as-
síncrona e o “/”, que simplesmente retorna algumas informações relativas à biblioteca
libcoap com uma resposta piggy-backed. Neste momento alguns pacotes CoAP já foram
capturados pelo Wireshark, para filtrar apenas os pacotes CoAP, no Wireshark pressi-
7 https://play.google.com/store/apps/details?id=pl.sixpinetrees.aneska
8 http://people.inf.ethz.ch/mkovatsc/copper.php
9 https://github.com/hirotakaster/CoAP-simple-library
10 https://www.arduino.cc/en/Guide/Libraries
11 https://support.mozilla.org/en-US/kb/find-and-install-add-ons-add-features-to-firefox
845
Figura 11.6. Captura de tela do Wireshark no Raspberry [Elaborada pelos autores].
Figura 11.7. Captura de tela do Copper no Firefox [Elaborada pelos autores].
one as teclas “Ctrl+/”, esse comando levará o cursor até a barra de filtros, então digite
udp.port == 5683 ou simplesmente “coap”, ambos os filtros mostraram apenas os
pacotes CoAP que estão transitando pela rede. Na Figura 11.8 pode-se observar o fluxo de
mensagens CoAP na requisição, feita através do método GET, em “/.well-known/core”.
Alguns detalhes importantes da comunicação CoAP podem ser destacados a partir
da Figura 11.8:
• Toda mensagem possui um id (MID).
846
Figura 11.8. Captura de mensagens da descoberta de serviços CoAP [Elaborada

pelos autores].
• Toda mensagem do tipo CON espera uma confirmação de recebimento (ACK) com
o mesmo ID da mensagem enviada.
• Uma mensagem ACK pode, além de confirmar o recebimento da requisição, trans-

portar o conteúdo da resposta.
• Uma mensagem CoAP pode ser dividida em blocos caso a requisição ou resposta
sejam grandes.
Para realizar uma comunicação simples entre o Arduino e o servidor CoAP será
utilizado o código de exemplo “coaptest” da biblioteca CoAP-simple-library. No Arduino
IDE, após a correta instalação da biblioteca, será possível, no menu “Arquivo->Exemplos-
>CoAP simple library”, encontrar um código de exemplo chamado “coaptest”. Para que
seja possível observar a comunicação entre o Arduino e o Raspberry através do protocolo
CoAP é necessário realizar algumas modificações no código de exemplo. Para realizar a
comunicação de forma adequada, na linha 54, altere o “(XXX, XXX, XXX, XXX)” pelo
endereço IP do servidor CoAP. A função loop deve ficar como no Algoritmo 1. Após
as alterações, carregue o código para o microcontrolador e, com o Arduino devidamente
conectado à rede e à Arduino Ethernet Shield, observe o tráfego de mensagens CoAP no
Wireshark.
No Arduino IDE é possível ver as respostas do servidor através do monitor serial.
Para abrir o monitor serial, no Arduino IDE, basta clicar na lupa localizada no canto supe-
rior direito da tela ou através do atalho “CTRL+SHIFT+M”. Para que não ocorra nenhum
erro na interpretação dos dados é importante certificar-se de que o baud rate está em 9600.
Na Figura 11.9a é mostrado o resultado no serial monitor, nele pode-se perceber que a co-
municação ocorreu da forma esperada, já que a cada dez segundos o servidor CoAP está
respondendo a requisição do Arduino com a data e hora. Esta comunicação pode ser vista
por outra perspectiva, através do Wireshark, mostrado na Figura 11.9b. Enquanto no serial
847
Função loop do coaptest
52
53 void loop ( ) {
54 / / Envia r e q u i s i c a o
55 i n t msgid = c o a p . g e t ( I P A d d r e s s ( 192 , 168 , 0 , 2 ) , 5683 , " t i m e " ) ;
56
57 / / Aguarda 10 s e g u n d o s
58 d e l a y ( 10000 ) ;
59 coap . loop ( ) ;
60 }
Algoritmo 1: Função loop do exemplo coaptest após modificações.
monitor existem cinco resultados de data e hora, no Wireshark são mostradas dez mensa-
gens CoAP. Na mensagem número 8 o Arduino, com IP 192.168.0.100, realiza a primeira
requisição através do método GET com uma mensagem do tipo CON (que necessita de
uma confirmação), em seguida o servidor CoAP do Raspberry, com IP 192.168.0.2, envia
uma resposta piggy-backed, na mensagem número 9. Este padrão se repete durante todas
as outras requisições.
Figura 11.9. Captura de mensagens CoAP na comunicação entre o Arduino e o

Raspberry [Elaborada pelos autores].
(a) Com confirmação
(b) Sem confirmação
Outras formas de transmissão podem ser testadas de forma fácil através do Copper.
O cliente CoAP para Firefox permite o envio de todos os tipos de requisições definidas
para o protocolo, ficando a cargo do leitor realizar testes e analisar a coerência do fluxo
de mensagens com o conteúdo teórico exposto na Seção 11.3.
848
11.4.3. Experimento 2: Análise de tráfego da comunicação MQTT

O objetivo deste experimento é mostrar como a comunicação em ambientes res-
tritos MQTT ocorre através da análise do tráfego na rede. O Raspberry Pi será utilizado
como broker MQTT e será o responsável pela captura do tráfego, auxiliado pelo anali-
sador de protocolos Wireshark. Neste experimento será analisado o processo de comu-
nicação MQTT entre um smartphone (com sistema operacional Android) e um Arduino,
simulando um ambiente de IoT. Além disso, para analisar outros aspectos relevantes da
comunicação com o protocolo MQTT, será utilizado um cliente Mosquitto em um dispo-
sitivo com o sistema operacional Windows.
Após a instalação do Mosquitto no Raspberry Pi, como descrito na subseção Pre-
parando o ambiente, o servidor já estará rodando automaticamente na porta TCP padrão,
1883. O próximo passo é a preparação dos clientes. Existem diversos clientes MQTT para
diferentes plataformas, não sendo, portanto, obrigatória a utilização dos mesmos clientes
aqui descritos para a obtenção dos mesmos resultados. Para o envio de comandos da pla-
taforma Android para o Arduino será utilizado o cliente Android MQTT Dash (disponível
na Google Play Store12 ) e o cliente Arduino pubsubclient (disponível para download no
GitHub13 ). No Arduino IDE, após a instalação da biblioteca pubsubclient, acesse os ar-
quivos de exemplo e abra o exemplo mqtt_publish_in_callback da biblioteca instalada.
Altere os IPs nas linhas 23 e 24 de acordo com a faixa de endereços IP da sua rede, por
exemplo, para uma rede que utiliza endereços na faixa de “192.168.0.x” é possível utilizar
os valores mostrados no Algoritmo 2.
mqtt_publish_in_callback
23 I P A d d r e s s i p ( 192 , 168 , 0 , 100 ) ;

24 I P A d d r e s s s e r v e r ( 192 , 168 , 0 , 2 ) ;
Algoritmo 2: Linhas 23 e 24 do exemplo mqtt_publish_in_callback após modificações.
O endereço do “server”, na linha 24, deve ser substituído pelo endereço IP atri-
buído ao broker (neste caso o endereço do Raspberry Pi). Feito isso, inicie a captura de
pacotes no Wireshark (filtrando por “mqtt”), carregue as alterações para a placa Arduino
e ligue-a à rede através da Arduino Ethernet Shield. Neste momento, já será possível
observar alguns pacotes no Wireshark, como é mostrado na Figura 11.10.
Figura 11.10. Captura de pacotes após a conexão do Arduíno na Rede [Elaborada

pelos autores].
12 https://play.google.com/store/apps/details?id=net.routix.mqttdash&hl=pt_BR
13 https://github.com/knolleary/pubsubclient
849
O primeiro pacote MQTT capturado pelo Wireshark é a mensagem de solicitação

de conexão. Analisando melhor esta solicitação podemos perceber algumas informações
relevantes para a comunicação. A primeira informação importante que este pacote for-
nece é a versão do protocolo na qual a comunicação se estabelecerá. Como pode ser visto
em “Version: 4”, na Figura 11.11, o cliente está solicitando comunicação com a versão
3.1.1 do protocolo MQTT, que conforme especificado em [Standard, 2014] é represen-
tado pelo número 4. Caso o broker não seja capaz de se comunicar com esta versão do
MQTT, a solicitação de conexão é recusada. Entretanto, como pode ser visto na Figura
11.10 a conexão foi aceita (um pacote CONNACK foi recebido), indicando que o ser-
vidor é capaz de se comunicar através da versão especificada. A solicitação de conexão
deve conter, ainda, outras informações importantes, como usuário, senha, Client ID, Keep
Alive, entre outras. No exemplo não foi utilizado usuário e senha, entretanto, em uma
implementação prática a utilização destes campos é extremamente recomendada. Ainda
na Figura 11.11, é possível ver o campo Client ID, onde é informada uma identificação
para o dispositivo solicitante da conexão (neste caso ArduinoClient), esta deve ser única
para que não ocorram conflitos. Já no campo Keep Alive é informado o tempo máximo,
em segundos, entre o ponto em que o cliente acaba de transmitir um pacote de controle e
o ponto em que ele começa a enviar o próximo. Em caso de não existir nenhuma infor-
mação a ser transmitida, o cliente deve enviar periodicamente um pacote PINGREQ, de
modo que o tempo não seja excedido. Caso contrário o servidor irá interpretar como uma
falha de rede e desconectará o cliente.
Figura 11.11. Pacote de solicitação de conexão do Arduino [Elaborada pelos autores].
No dispositivo Android, já com o MQTT Dash instalado, o primeiro passo é criar

a conexão com o servidor. Para isso, abra o app e clique no botão (+), no canto supe-
rior direito, em seguida preencha as informações necessárias, sendo elas nome da co-
nexão (identificada pelo campo “name”) e endereço do broker (identificado pelo campo
“Address”). Os outro dados necessários, como porta e Client ID já são preenchido au-
tomaticamente com valores padrão. Existe ainda a possibilidade de informar o nome de
usuário e senha, entretanto como estes não foram configurados no servidor deverão ficar
em branco. Neste momento a conexão com o broker já pode ser estabelecida. Para tes-
tar a comunicação entre o cliente Android e o cliente Arduino será feita uma publicação
através do MQTT Dash no tópico “inTopic”, em que o cliente Arduino está inscrito. No
exemplo utilizado, o cliente Arduino irá republicar todas as informações que chegarem no
tópico “inTopic” para um tópico chamado “outTopic”. Para ver isto correndo na prática,
será criado um botão no MQTT Dash que a cada vez que é tocado faz uma publicação no
850
tópico “inTopic”. Para criar o botão basta acessar a conexão criada e clicar novamente no
botão (+), em seguida algumas opções serão exibidas, selecione a opção “Switch/button”
e dê um nome ao botão, em seguida, no campo “Topic (pub)” digite o tópico no qual o cli-
ente Arduino está inscrito, neste caso “inTopic”. Feito isso, clique no botão salvar (canto
superior direto) e em seguida pressione o botão criado. Neste momento a informação “0”
deverá ser publicada no tópico “inTopic”. Na Figura 11.12 é mostrado o fluxo de pacotes
MQTT gerado por este comando.
Figura 11.12. Comunicação entre o cliente Android e o cliente Arduino interme-

diada pelo broker [Elaborada pelos autores].
Como pode ser visto na Figura 11.12, a mensagem foi inicialmente publicada do
smartphone (IP 192.168.0.182) para o servidor (IP 192.168.0.2), em seguida o servidor
enviou a mensagem para todos os inscritos (subscribers) do tópico “inTopic”, que neste
caso é apenas o cliente Arduino (IP 192.168.0.100). O cliente Arduino, por sua vez, re-
publicou a mensagem para o servidor informando o tópico “outTopic”. Entretanto, como
não havia nenhum inscrito neste tópico nenhum novo pacote do tipo PUBLISH foi envi-
ado pelo broker, a não ser uma resposta a um pacote Ping Request, enviado pelo cliente
Arduino aproximadamente quinze segundos após o envio do último pacote de controle
(devido ao tempo de Keep Alive visto anteriormente). Perceba que em nenhuma das men-
sagens houve confirmação de recebimento, isso ocorre porque o nível de qualidade de
serviço utilizado na comunicação foi o QoS 0 (Fire and Forget). Para ilustrar os três ní-
veis de QoS providos pelo protocolo MQTT foi instalado um cliente Moquitto em um
ambiente Windows.
Na plataforma Windows, os procedimentos de instalação são um pouco diferen-
tes. Após a instalação do arquivo executável, que pode ser baixado no site oficial do
broker14 , será necessário seguir os procedimentos especificados em um arquivo chamado
“ readme-windows.txt”, localizado no diretório onde o software foi instalado. Após a
conclusão do processo de instalação o cliente MQTT já estará pronto para ser utilizado.
Para testar os três níveis de QoS providos pelo MQTT foram enviados três pacotes do tipo
PUBLISH para o broker através do comando “mosquito_pub -q <QoS> -h <endereço> -t
<tópico> -m <mensagem>”. Para o envio do primeiro pacote com o nível de QoS mais
baixo (QoS 0), por exemplo, no Prompt de Comando do Windows, dentro do diretório de
instalação do Mosquitto, foi utilizado o comando “mosquito_pub -q 0 -h 192.168.0.2 -t
teste -m “Teste de QoS”. Este comando está dizendo explicitamente para o cliente Win-
dows enviar um pacote MQTT do tipo PUBLISH com nível de QoS 0 para o endereço
“192.168.0.2” no tópico “teste” com a mensagem “Teste com QoS 0”. Além disso, im-
plicitamente outras informações estão sendo enviadas, como a porta TCP, que em caso de
não ser informada de forma explicita é utilizada a porta padrão 1883. Todos os parâmetros
14 https://mosquitto.org/download/
851
aceitos pelo broker podem ser visto através do comando “mosquitto_pub –help”. O fluxo
gerado pelo envio de um pacote PUBLISH para o mesmo tópico, no mesmo broker e com
a mesma mensagem, mudando apenas o nível de QoS é mostrado na Figura 11.13.
Figura 11.13. Captura de mensagens CoAP na comunicação entre o Arduino e o

Raspberry [Elaborada pelos autores].
(a) QoS 0 (no máximo uma entrega)
(b) QoS 1 (pelo menos uma entrega)
(c) QoS 2 (exatamente uma entrega)
Na primeira situação, em que o nível de QoS é igual a zero (Figura 11.13a), é pos-
sível perceber que nenhum retorno do broker foi recebido em relação ao comando publish.
Após a conexão ser estabelecida com o servidor (ser recebido o pacote Connect Ack) o
cliente Windows simplesmente envia o pacote a ser publicado e, em seguida, solicita a
desconexão, já que nenhum retorno é esperado. Já na segunda situação (Figura 11.13b),
com nível de QoS igual a um, é esperado um pacote de confirmação de recebimento da
publicação (Publish Ack). Nesta situação, caso o transmissor não receba uma mensagem
de confirmação dentro de um timeout padrão, o pacote publish é retransmitido periodica-
mente até que a confirmação seja recebida. Por fim, quando o nível de QoS mais alto é
utilizado (QoS 2) é garantida a entrega de um, e somente um, pacote do tipo PUBLISH.
Neste caso a confirmação de entrega é feita em três partes. Como ilustrado na Figura
11.13c, após o envio do pacote de publicação, o transmissor irá aguardar o recebimento
da primeira confirmação (Publish Received), ao receber este pacote, o transmissor envia
um segundo pacote (Publish Release) e novamente aguarda a confirmação do receptor,
que deve responder com um pacote Publish Complete, indicando que a publicação foi
bem sucedida.
852
11.5. Conclusão
Este capítulo apresentou as definições e motivações para as pesquisas de Internet
of Things (IoT), bem como um breve panorama histórico. O foco ficou para o monitora-
mento prático das redes de Internet das Coisas. Foram utilizados softwares sniffers para a
análise de tráfego em tempo real de um sistema de IoT, este prototipado usando Arduinos
e Raspberry.
Os trabalhos futuros poderão contemplar cenários mais desafiadores e realísticos,
com vários equipamentos transmitindo entre si, bem como novas práticas e estratégias
para análise de tráfego. Outros protocolos utilizados em sistemas IoT, alguns discutidos
superficialmente neste trabalho, também poderão ser abordados com mais detalhes.
Referências
[Al-Fuqaha et al., 2015] Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M.,
and Ayyash, M. (2015). Internet of things: A survey on enabling technologies, proto-
cols, and applications. IEEE Communications Surveys & Tutorials, 17(4):2347–2376.
[Ashton, 2009] Ashton, K. (2009). In the real world, things matter more than ideas. RFID
Journal.
[Chen et al., 2014] Chen, W.-J., Gupta, R., Lampkin, V., Robertson, D. M., Subrah-
manyam, N., et al. (2014). Responsive Mobile User Experience Using MQTT and
IBM MessageSight. IBM Redbooks.
[Cisco, 2017] Cisco (2017). Global mobile data traffic forecast update, 2016-
2021. http://www.cisco.com/assets/sol/sp/vni/forecast_
highlights_mobile/index.html.
[Desai, 2015] Desai, P. (2015). Python Programming for Arduino. Packt Publishing Ltd.
[DesmontaCia, 2011] DesmontaCia (2011). Zigbee ou ieee 802.15.4 – conheça a tec-

nologia a fundo. https://desmontacia.wordpress.com/2011/02/22/
zigbee-ou-ieee-802-15-4-conhea-a-tecnologia-a-fundo.
[Ferreira, 2013] Ferreira, S. (2013). Ipv6 nas redes de sensores sem fio.
https://comum.rcaap.pt/bitstream/10400.26/17524/2/
SergioFerreira_Tese_Mestrado_2012-2013.pdf.
[Gubbi et al., 2013] Gubbi, J., Buyya, R., Marusic, S., and Palaniswami, M. (2013). In-
ternet of Things (IoT): A vision, architectural elements, and future directions. Future
Generation Computer Systems, 29(7):1645–1660.
[Joshi and Kaur, 2015] Joshi, M. and Kaur, B. P. (2015). Coap protocol for constrained
networks. International Journal of Wireless and Microwave Technologies, 5(6):1–10.
[Kuladinithi et al., 2011] Kuladinithi, K., Bergmann, O., Pötsch, T., Becker, M., and
Görg, C. (2011). Implementation of coap and its application in transport logistics.
Proc. IP+ SN, Chicago, IL, USA.
853
[Shelby et al., 2014] Shelby, Z., Hartke, K., and Bormann, C. (2014). The constrained
application protocol (coap).
[Standard, 2014] Standard, O. (2014). Mqtt version 3.1.1. http://docs.

oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.
[Vasques, 2010] Vasques, B. L. R. P. (2010). Zigbee. https://www.gta.ufrj.

br/grad/10_1/zigbee/introducao.html.
854
Capítulo
12
Introdução a análise de dados com Python e Pan-
das
Abílio Soares Coelho
Abstract
Companies are investing in quantity and generation of information, but few companies are
devoting themselves to data analysis and focusing on better positioning in the market. Le-
verage a large mass of information generated in the planning stages can aid in reducing
losses and without increasing billing. Among the most diverse emerging areas of com-
puting, a particular theme has drawn attention and aroused community interest, a data
science, and the ability to extract valuable information from large masses of raw data.
This chapter is an introduction to the use of Pandas, a Python library for data analysis,
which plays a great role and has numerous functions for this purpose. They will be made
available through the transparency portal of the federal government for demonstration
and removal of important information.
Resumo
As organizações estão investindo milhões na geração e armazenamento de informações,

mas poucas empresas estão se dedicando com atenção à análise de dados e focando em
um posicionamento melhor no mercado. Aproveitar a grande massa de informações ge-
radas nas etapas de planejamento pode auxiliar na redução de perdas e no aumento de
faturamento. Dentre as mais diversas áreas emergentes da computação, um tema em es-
pecial tem chamado atenção e despertado interesse da comunidade, a ciência de dados é
capaz de extrair informações valiosas a partir de grandes massas de dados brutos. Este
capítulo trata de uma introdução a utilização do Pandas, uma biblioteca Python para
análise de dados, que desempenha um papel grandioso e possui inúmeras funções para
esse propósito. Serão utilizados dados públicos disponibilizados pelo portal da transpa-
rência do governo federal para demonstração e retirada de informações importantes.
855
12.1. Introdução
Estamos vivendo em um mundo globalizado e sedento por informação, hoje a maioria das
atividades cotidianas estão sendo monitoradas e consequentemente gerando dados, porém
segundo [Becker 2015] os dados são apenas a matéria-prima da informação, ou seja, os
dados precisam ser interpretados e assim gerar, de fato, a informação.
Segundo [Grus 2016] o mundo está soterrado por dados, desde uma compra que
um usuário realiza pela internet, um filme que é assistido online ou até os registros da lo-
calização de um smartphone geram dados que podem ser resposta para inúmeras questões
como por exemplo um sistema de recomendação. É exatamente aí onde entra a área de
ciência de dados, o cientista de dados é o profissional responsável por extrair informações
de dados brutos, [Grus 2016] define em forma de piada que um cientista de dados é um
profissional que sabe mais de estatística do que um cientista da computação e mais sobre
ciência da computação do que um estatístico. Este capítulo trata de uma introdução a
utilização do Pandas, uma biblioteca Python para análise de dados, que desempenha um
papel grandioso e possui inúmeras funções para esse propósito.
12.2. Python
A linguagem de programação Python embora simples e clara é uma linguagem extrema-
mente poderosa, segundo [Menezes 2016] é uma linguagem que vem crescendo em áreas
da computação, como inteligência artificial, banco de dados, biotecnologia, animação 3D,
aplicativos móveis, jogos e plataforma web. para [Oliphant 2007] Python se destaca como
uma plataforma de computação científica, e cita as seguintes razões:
• Linguagem de código aberto, nenhuma permissão adicional é necessária;
• Multiplataforma, não há necessidade de se preocupar em escrever programas com

portabilidade limitada;
• Possui sintaxe de fácil entendimento, mas que permite construções sofisticadas

como procedural, orientada a objetos e funcional;
• Possui um poderoso interpretador interativo, que permite o aumento da produtivi-

dade no processo de desenvolvimento e teste de códigos;
• Possui um grande número de bibliotecas, dos mais variados propósitos, disponíveis

para download;
• Possui uma comunidade atuante e participativa na resolução de dúvidas e problemas

referentes a Python.
12.2.1. Instalação
O interpretador Python não vem instalado por padrão no Microsoft Windows, já no Mac
OS X e Linux sua instalação é nativa, porém não conta com a sua versão mais recente.
Pode-se contornar este problema e instalar a versão atual das seguintes formas:
856
• Python.org: O interpretador Python está atualmente na versão 3.6.2, porém a ver-

são nativa no MAC OS X é a versão 2.7, uma maneira possível de realizar a insta-
lação da versão atual é fazendo o download da versão corrente no Python Software
Foundation1 .
• Anaconda2 : É uma plataforma de software que integra o Python com vários paco-
tes que podem ser úteis no desenvolvimento de aplicações científicas. Essa integra-
ção facilita a instalação e a manutenção desse software na sua máquina através do
conda, um aplicativo que ajuda a gerenciar a instalação e manutenção de pacotes.
No site do desenvolvedor está disponível o download para as principais plataformas.
Após instalado, o Anaconda ocupa aproximadamente 4GB de espaço em disco.
• Miniconda: Como o propósito deste capítulo é uma introdução à análise de dados,

é recomendado que o usuário instale o Miniconda3 . Para quem não tem disponí-
vel muito espaço em disco, é uma ótima opção, ocupa aproximadamente 400MB.
Além do interpretador Python e o ambiente de desenvolvimento IDLE, miniconda
instala também o conda, tornando-o bem intuitivo no gerenciamento e instalação
dos pacotes necessários.
12.3. Pandas
O Pandas4 é uma biblioteca licenciada com código aberto que oferece estruturas de dados
de alto desempenho e de fácil utilização voltado a análise de dados para a linguagem de
programação Python. É amplamente utilizado para a preparação e visualização de dados e
tem sido fundamental para impulsionar a utilização de Python na comunidade científica de
dados. Contém estruturas de dados de alto nível e ferramentas de manipulação projetadas
para tornar a análise de dados rápida e fácil em Python. O Pandas é construído em cima
do NumPy, responsável pelo alto desempenho, e facilita a sua utilização em aplicativos
baseados no NumPy.
12.3.1. Estrutura de Dados

Para trabalhar com Pandas, o usuário deve estar familiarizado com duas estruturas de
dados que são:
12.3.1.1. Séries
A estrutura Série, é um array unidimensional, semelhante a uma lista em Python, porém

criado sobre o numpy. Além da velocidade de processamento, a principal característica
que o difere de uma lista comum é que seus índices podem ser mutáveis, dependendo da
necessidade do programa.
A Figura 12.1 apresenta a criação e manipulação de uma série. A primeira linha
define a série s com 5 elementos, a segunda linha apresenta a série s, a quarta linha
1 Disponível em: http://www.Python.org
2 Disponível em: https://www.anaconda.com/download/
3 Disponível em: https://conda.io/miniconda
4 Disponível em: http://Pandas.pydata.org
857
Figura 12.1. Criação de uma série
apresenta o valor armazenado no índice 3 e a linha 6 altera os índices da série pelas

letras A,B,C,D,E. Logo em seguida a série é impressa novamente com os novos índices.
12.3.1.2. Dataframes
Segundo [McKinney 2012], um Dataframe representa uma estrutura de dados tabular, se-
melhante a uma planilha, contendo uma coleção de colunas ordenadas, cada uma das
quais pode ser um tipo de valor diferente (numérico, string, booleano, etc.) Para se criar
um Dataframe a partir das estruturas de dados nativas em Python, pode-se passar um dici-
onário de listas para seu construtor. Usando-se o parâmetro columns, define no construtor
como as colunas serão ordenadas. Por padrão, o construtor do Dataframe irá ordernar as
colunas em ordem alfabética.
Figura 12.2. Criação de um Dataframe
A figura 12.2 ilustra a criação e apresentação de um Dataframe contendo infor-

mações referentes à região nordeste. As 6 primeiras linhas representam a criação de um
dicionário chamado estados, a linha 7 representa, de fato, a criação do Dataframe nor-
858
deste, passando-se como parâmetro o dicionário e as colunas, a última linha apresenta na

tela os dados armazenados no Dataframe.
A primeira coluna da figura 12.2 apresenta os índices padrões, porém como exis-
tem campos que possuem identificadores únicos como é o caso de sigla, pode-se optar
por alterar os índices padrões pela coluna de sigas. A figura 12.3 ilustra essa modificação,
onde a primeira linha substitui os índices padrões pelos valores referentes na coluna sigla,
a segunda linha apaga a coluna sigla, para que não haja duplicidade de informações e por
último apresenta na tela como ficou o Dataframe nordeste.
Figura 12.3. Alteração dos índices de um Dataframe
12.3.2. Carregar Datasets

Geralmente é mais comum a necessidade de fazer a leitura de uma base de dados externa
para um Dataframe, o Pandas oferece alguns métodos para esse fim e serão descritos a
seguir:
• CSV: para ler um arquivo CSV basta chamar uma função nativa da biblioteca Pan-
das específica para esse fim, função read_csv.
• EXCEL: Pandas permite leitura e escrita no formato Excel. Ler a partir de arquivos
Excel requer a biblioteca xlrd, pode-se instalar via pip (pip install xlrd).
• db.py: é uma maneira mais fácil de interagir com bancos de dados. Facilita a pes-
quisa de tabelas, colunas, visualizações, etc. Ele coloca a ênfase na interação do
usuário, na exibição de informações e no fornecimento de funções auxiliares fáceis
de usar. Suporta PostgreSQL, MySQL, SQLite, Redshift, MS SQL Server e Oracle.
• Clipboard: tendo dados tabulados, então pode-se copiar para o clipboard e colar
direto no Dataframe. A função realiza um bom trabalho identificando qual é o
delimitador, mas pode-se usar o parâmetro sep para ser explicito.
• URL: Pode-se usar a biblioteca StringIO de Python para ler diretamente dados de
uma URL. StringIO permite tratar uma string como um objeto do tipo arquivo.
859
• pydataset: fornece acesso instantâneo a muitos conjuntos de dados diretamente do

Python, a versão atual conta com 757 datasets prontos para serem importados e
utilizados juntamente com o Pandas.
12.3.3. Filtros em Dataframes

Existem vários métodos para selecionar dados em um Dataframe. Quando se manipula
grande quantidade de dados a escolha do método influencia bastante, visto que alguns
métodos são mais eficientes que outros. [Pandas Library 2017] destaca os seguintes mé-
todos:
• Filtro booleano: É possível filtrar qualquer coluna a partir de uma comparação re-
lacional, por exemplo: pode-se recuperar apenas as capitais que tenham população
acima de 1 milhão no exemplo visto na figura 12.2;
• Método loc: É utilizado para seleção através de índices rotulados, mas também
aceita uma matriz booleana;
• Método iloc: É utilizado para seleção através de índices inteiros, mas também aceita
uma matriz booleana;
• Método ix: Pode decidir indexar posicionalmente ou através de etiquetas depen-
dendo do tipo de dados do índice. Está em desuso desde a versão Pandas 0.20.0.
12.3.4. Limpeza de Dados Perdidos

O problema de dados perdidos é de grande relevância para a análise de dados, pois deve-
se tomar uma decisão importante para não prejudicar as estatísticas das colunas. O Pandas
possui funções interessantes para tratar o problema de dados perdidos, as principais fun-
ções são:
• dropna: Utilizado para excluir linhas ou colunas que possuam dados perdidos;
• fillna: Utilizado para preencher dados perdidos com base em critérios. Exemplo:
Em uma coluna de idade de um Dataframe pode-se utilizar essa função para onde
tiver dado perdido substituir pela média das idades da coluna;
• isnull: Retorna objeto booleano indicando quais valores são nan5 ;
• notnull: Negação de isnull.
12.3.5. Operações no Dataframe

Séries e Dataframes formam o núcleo dos modelos de dados do Pandas em Python. Os
conjuntos de dados são lidos primeiro nos Dataframes e, em seguida, várias operações
(por exemplo, group by, agregações, etc.) podem ser aplicadas muito facilmente às suas
colunas.
A tabela 12.1 apresenta um pequeno resumo de alguns comandos úteis para ma-
nipulação de informações em um Dataframe.
5 acrônimo de not a number, equivalente a nulo
860
Tabela 12.1. Principais comandos em um Dataframe

Retorno Comando
Quantidade de linhas e colunas do Dataframe df.shape
Primeiros 5 registros do Dataframe df.head()
Últimos 5 registros do Dataframe df.tail()
Descrição do Index df.Index
Colunas presentes no Dataframe df.columns
Contagem de dados não-nulos df.count()
Criando uma nova coluna em um Dataframe df[’Nova Coluna’] = 0
Soma dos valores de um Dataframe df.sum()
Menor valor de um Dataframe df.min()
Maior valor de um Dataframe df.max()
Resumo estatístico do Dataframe df.describe()
12.3.5.1. Grouping
Segundo [McKinney 2012], categorizar um conjunto de dados e aplicar uma função a

cada grupo, seja uma agregação ou transformação, é muitas vezes um componente crítico
de um fluxo de trabalho de análise de dados. Após o carregamento, a fusão e a preparação
de um conjunto de dados, uma tarefa familiar é calcular as estatísticas do grupo ou possi-
velmente tabelas dinâmicas para fins de relatórios ou de visualização. O Pandas fornece
uma facilidade de agrupamento flexível e de alto desempenho.
Uma razão para a popularidade de bancos de dados relacionais e SQL (que sig-
nifica "linguagem de consulta estruturada") é a facilidade com que os dados podem ser
unidos, filtrados, transformados e agregados. No entanto, as linguagens de consulta como
o SQL são bastante limitadas nos tipos de operações de grupo que podem ser executadas.
Com a expressividade e o poder de Python e Pandas, pode-se realizar operações agrupa-
das muito mais complexas, utilizando qualquer função que aceite um objeto Pandas ou
uma matriz NumPy.
O método groupby do Pandas parte da estratégia básica de separar-aplicar-combinar
(split-apply-combine) em análise de dados. É uma boa representação de como você pensa
sobre um problema de dados. Quando ataca-se um problema de análise de dados, ge-
ralmente quebra-se ele em pedaços gerenciáveis, realiza várias operações sobre cada um
desses pedaços e depois reagrupa todos novamente (este é o essencial da estratégia split-
apply-combine).
12.3.5.2. Merge
Geralmente em uma análise, precisa-se fazer merge/join de dados que geralmente são
armazenados de forma relacional. Como a clausula JOIN no SQL, pandas.merge permite
que 2 Dataframes possam ser agrupados por meio de uma ou mais chaves. A função provê
uma série de parâmetros (on, left_on, right_on, left_index, right_index) permitindo que
você possa especificar sobre quais colunas ou índices deseja-se realizar o join. Por padrão,
861
pandas.merge opera como um inner join, que pode ser alterado usando o parâmetro how.
A partir do docstring: how : ’left’, ’right’, ’outer’, ’inner’, default ’inner’
• left: usa apenas chaves do frame da esquerda (SQL: left outer join)
• right: usa apenas chaves do frame da direita (SQL: right outer join)
• outer: usa a união das chaves de ambos frames (SQL: full outer join)
• inner: usa a interseção das chaves de ambos frames (SQL: inner join)
12.4. Matplotlib
É a biblioteca Python mais popular para a visualização de dados, geração de gráficos e
permite que seja facilmente criado gráficos, histogramas e outras visualizações profissi-
onais. Possui suporte a todos os sistemas operacionais e também pode exportar gráficos
para vetor comum.
Segundo [Matplotlib 2017], tenta facilitar coisas fáceis e difíceis. Pode gerar grá-
ficos, histogramas, espectros de poder, gráficos de barras, gráficos de erros, diagramas de
dispersão, etc., com apenas algumas linhas de código. Para o usuário avançado, possui
controle total de estilos de linha, propriedades de fontes, propriedades de eixos, etc., atra-
vés de uma interface orientada a objetos ou através de um conjunto de funções familiares
aos usuários do MATLAB.
12.5. Estudo de Caso

De acordo com [Brasil 2017], O Portal da Transparência do Governo Federal é uma ini-
ciativa da Controladoria-Geral da União (CGU), lançada em novembro de 2004, para
assegurar a boa e correta aplicação dos recursos públicos. O objetivo é aumentar a trans-
parência da gestão pública, permitindo que o cidadão acompanhe como o dinheiro pú-
blico está sendo utilizado e ajude a fiscalizar. Segundo o próprio site, em 2017, possui
uma média mensal de 1.794.455 acessos, porém não é tão simples assim fazer consultas
específicas no portal, para tanto existe um manual6 contendo 241 páginas que foi criado
com o intuito de facilitar a navegação no Portal. O objetivo é orientar o cidadão e os
agentes públicos a encontrarem as informações desejadas para conhecer a aplicação dos
recursos públicos federais e contribuir com o Governo em seu papel de fiscalização.
Esta seção apresenta um passo a passo, desde a instalação do ambiente virtual até
a apresentação dos dados, de gastos federais com diárias dos campi do Instituto Federal de
Educação, Ciência e Tecnologia do Maranhão - IFMA. O portal da transparência permite
o download de arquivos em formato .CSV, esses arquivos serão importados e manipulados
através de Python e biblioteca Pandas. Para todos efeitos, o sistema operacional adotado
nessa demonstração é o macOS High Sierra.
12.5.1. Instalação do Python

Segundo [Miniconda 2017], a maneira mais rápida de obter o gerenciador de pacotes
conda é instalar a Miniconda, uma mini versão da Anaconda que inclui o interpretador
6 Disponível em: http://www.portaldatransparencia.gov.br/manual/manualCompleto.pdf
862
Python, o conda e suas dependências. Se você preferir ter o conda e mais de 720 pacotes
de código aberto, recomenda-se a instalação da Anaconda.
Por questões de espaço em disco optou-se pela instalação do Miniconda, que
ocupa pouco mais de 400Mb de espaço em disco após instalado.
(a) Versão nativa do Python (b) Instalação do Miniconda
(c) Vesão do conda e os pacotes instalados por padrão
Figura 12.4. Processo de instalação Miniconda (a), (b) e (c)
A figura 12.4 apresenta um conjunto de imagens que ilustram a instalação do

Miniconda. Primeiramente a imagem 12.4(a) mostra que a versão do Python instalada
por padrão no macOS High Sierra é a versão 2.7.10, versão antiga do interpretador. Após
download no site do desenvolvedor, a imagem 12.4(b) apresenta, de fato a instalação
do Miniconda, onde após essa tela é apresentado os termos de licença e o restante da
instalação é bem intuitiva. Após a instalação do Miniconda, a imagem 12.4(c) mostra a
versão do gerenciador de pacotes conda e posteriormente os pacotes que já são instalados
por padrão, pode-se notar que a versão do interpretador Python foi atualizado para a
versão 3.6.1.
Após a instalação do miniconda é necessária a criação do ambiente virtual, que
é uma técnica bastante utilizada por programadores onde cria-se ambientes com total
863
independência dos outros. Isso permite que cada ambiente tenha autonomia para instalar
plug-ins e bibliotecas de forma que a configuração de um não impacte nos restantes.
(a) Criação do ambiente virtual (b) Ativação do ambiente enucomp
Figura 12.5. Criação e ativação do ambiente virtual (a) e (b)
A figura 12.5 apresenta duas imagens que ilustram a criação e ativação do am-
biente virtual. A imagem 12.5(a) mostra o comando para fazer a criação de um novo
ambiente, o parâmetro -n refere-se a name, onde passa-se como argumento o nome do
ambiente a ser criado. Após criado, para efeito de instalações e execuções referentes
a um ambiente, é necessário que o mesmo esteja ativo. A imagem 12.5(b) apresenta a
ativação do ambiente recentemente criado e após comando verifica-se que o ambiente
está ativo, representado pelo nome do ambiente entre parênteses antes do cursor, a partir
desse momento, qualquer processo de instalação ou execução realizado no terminal será
executado pelo ambiente ativo.
12.5.2. Instalação das bibliotecas necessárias

Após o Miniconda instalado, ambiente virtual criado e ativo, é necessária a instalação das
bibliotecas que serão utilizadas nessa demonstração.
A figura 12.6, apresenta duas imagens que ilustram a instalação e teste dos pacotes
instalados. A imagem 12.6(a) apresenta a utilização do gerenciador de pacotes conda
para instalar as bibliotecas necessárias para a realização da proposta. Nota-se que além da
biblioteca Pandas, é solicitada a instalação do matplotlib e seaborn, que são bibliotecas
responsáveis pela geração de gráficos e do jupyter que segundo [Grus 2016], fornece um
shell com muito mais funcionalidades que o padrão do Python, acrescenta várias novas
funções, além do mais, permite que se crie notebooks, combinando texto e código Python.
A imagem 12.6(b), mostra a realização de testes para verificação se tudo ocorreu como
previsto, como não é apresentado nenhum erro de importação então conclui-se que o teste
foi bem sucedido.
864
(a) Instalando as bibliotecas (b) Testando as bibliotecas
Figura 12.6. Instalação e testes das bibliotecas necessárias (a) e (b)
12.5.3. Download e importação dos dados externos

Com o objetivo de facilitar a consulta das informações disponíveis no Portal da Trans-
parência do Governo Federal e oferecer ao usuário uma forma rápida e prática de obter
e armazenar os dados, existe uma seção do Portal que disponibiliza as informações das
consultas em formato apropriado para download e armazenamento. O usuário poderá bai-
xar as informações constantes de cada consulta do site para fazer todos os cruzamentos e
análises que desejar e realizar estudos e pesquisas a partir desses dados.
Os arquivos são gerados com as mesma periodicidade em que as respectivas in-
formações são atualizadas no Portal. Assim, alguns arquivos têm atualização mensal, ou-
tros, semanal; e algumas diária. Outra diferença entre os arquivos é que alguns estão com
dados separados por ano e outros trazem a informação consolidado de um determinado
período. Essa diferença também reflete a forma como as informações estão disponíveis
nas consultas do Portal
A figura 12.7 apresenta o caminho a ser percorrido para a obtenção dos dados.
Pode-se identificar na imagem 12.7(a), um pequeno retângulo vermelho sobre o link
download de dados, após acessar esse link o usuário será redirecionado para a página
identificada pela imagem 12.7(b), como a proposta é fazer um acompanhamento das diá-
rias, o link a ser acessado está marcado com o retângulo vermelho, porém existem vários
outros tipos de acompanhamento que podem ser realizados. A imagem 12.7(c) apresenta
a identificação do arquivo a ser baixado, juntamente com o formato do mesmo, mostrando
todas as colunas existentes. Como é um arquivo atualizado mensalmente dispõe do ano
corrente e opções por exercícios de anos anteriores.
865
(a) Tela inicial do Portal da Transparência (b) Tela de downloads de dados
(c) Tela de download do arquivo de diárias
Figura 12.7. Download de dados externos (a), (b) e (c)
A figura 12.8 Apresenta um conjunto de três imagens referentes à importação dos

dados externos. A imagem 12.8(a) mostra o comando para iniciar o ambiente jupyter,
após esse comando o browser principal é automaticamente aberto, a tela inicial do jupyter
pode ser observada na imagem 12.8(b). Para se criar um notebook, é necessário clicar
no botão new e logo em seguida clicar na versão do interpretador Python a ser iniciado,
neste caso Python3. A imagem 12.8(c) apresenta, de fato, a criação de um Dataframe
chamado jan e utiliza a função pd.read_csv para importar os dados do arquivo passado
como parâmetro. Geralmente arquivos CSV são delimitados por "vírgulas", porém nesse
arquivo específico do Portal da Transparencia é delimitado por tabulação, por esse motivo
foi passado o argumento \t para o parâmetro delimiter. O último parâmetro passado, é
referente ao formato de texto que será importado, nesse caso, como os textos possuem
acentos o formato recomendado é o ISO-8859-1, se esse argumento não fosse passado,
os textos não seriam importados com acentos. Na próxima célula é possível verificar a
utilização da função columns, essa função retorna o cabeçalho de todas as colunas do
Dataframe.
866
(a) Iniciar jupyter (b) Tela inicial do jupyter
(c) Importação do arquivo de diárias
Figura 12.8. Importação de dados externos (a), (b) e (c)
12.5.4. Manipulação do Dataframe

Sabendo-se que o código do IFMA junto ao Portal da Transparência é 26408, primeiro é
necessário fazer uma seleção de todos os registros que aparecem com esse código, utiliza-
se a função loc e será retornado uma matriz booleana de todos os registros que possuem
esse valor no campo Código Órgão Subordinado. Após a seleção faz-se o agrupamento,
nesse caso utiliza-se apenas o campo Unidade Gestora, pois os valores de agregação serão
calculados sobre cada campus. Em seguida é, de fato, realizada a agregação, utilizando a
coluna Valor Pagamento, calcula-se a soma, mínimo, máximo e quantidade de diárias por
campus.
A figura 12.9 apresenta a manipulação dos dados para retirada da informação de
quanto cada campus do IFMA gastou com diárias e passagens. A imagem 12.9(a) identi-
fica qual é o código do IFMA junto ao portal da transparência. A imagem 12.9(b) apre-
senta o comando a ser executado para a geração da informação, onde primeiro faz-se uma
seleção de todas as linhas em que o Código do Órgão Subordinado seja igual a 26408, ge-
rando assim uma matriz booleana, que é passada como parâmetro para a função loc. Após
isso é feito o agrupamento através da coluna Nome da Unidade Gestora, que de fato, são
os executores da despesa. Para obter informações do agrupamento são realizadas algu-
mas funções aggregate, onde a primeira coluna calculada é a soma de todos os gastos por
867
(a) Código IFMA (b) Agrupamento de dados
(c) Geração do gráfico
Figura 12.9. Manipulação do Dataframe (a), (b) e (c)
campus, a segunda seria o valor mínimo de diária por campus, a terceira refere-se ao valor
máximo que um campus recebeu e a última coluna é referente a quantidade de diárias que
o campus recebeu no mês. A imagem 12.9(c) mostra o quanto é simples gerar um gráfico
utilizando o matplotlib. O próprio Pandas possui uma função que utiliza os recursos da
biblioteca de gráfico, ainda pode-se optar por qual tipo de gráfico utilizar através do parâ-
metro kind, Usuários mais experientes podem utilizar recursos da biblioteca seaborn para
deixar os gráficos com aspecto mais profissional.
12.6. Considerações finais

Neste capítulo foram apresentados conceitos gerais sobre a linguagem Python e a biblio-
teca Pandas, demonstrado o quanto é simples e rápida a sua utilização. Foi apresentado
um breve estudo de caso utilizando a tecnologia sobre dados abertos disponibilizados
pelo governo, porém Várias outras organizações fornecem dados como: dados eleitorais,
financeiros, estatísticos, etc. Muitas outras informações poderiam ter sido extraídas desse
exemplo, como agrupamento por servidor ou por e funções de agregações diversas, porém
como é apenas uma introdução ficará para trabalhos futuros.
868
Referências
[Becker 2015] Becker, J. L. (2015). Estatística básica: transformando dados em infor-
mação. Bookman Editora.
[Brasil 2017] Brasil (2017). Portal da transparência. Disponível em: http://www.

portaldatransparencia.gov.br. Acesso em: 18 Outubro 2017.
[Grus 2016] Grus, J. (2016). Data Scince do Zero: Primeiras regras com Python. Alta
Books Editora.
[Matplotlib 2017] Matplotlib (2017). Matplotlib. Disponível em: https://

matplotlib.org. Acesso em: 18 Outubro 2017.
[McKinney 2012] McKinney, W. (2012). Python for data analysis: Data wrangling with
Pandas, NumPy, and IPython. "O’Reilly Media, Inc.".
[Menezes 2016] Menezes, N. N. C. (2016). Introdução à programação com Python–2a

edição: Algoritmos e lógica de programação para iniciantes. Novatec Editora.
[Miniconda 2017] Miniconda (2017). Miniconda. Disponível em: https://

conda.io/docs/user-guide/install/index.html. Acesso em: 18 Ou-
tubro 2017.
[Oliphant 2007] Oliphant, T. E. (2007). Python for scientific computing. Computing in

Science & Engineering, 9(3).
[Pandas Library 2017] Pandas Library (2017). Python data analysis library. Dispo-
nível em: http://pandas.pydata.org/pandas-docs/stable/. Acesso
em: 18 Outubro 2017.
869

Anais - ENUCOMP - 2017 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Anais - ENUCOMP - 2017 PDF

Enviado por

Dados do documento

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

Anais - ENUCOMP - 2017 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ANAIS ELETRÔNICOS ENUCOMP 2017

1. Ciência da Computação. 2. Congressos. I. Rabêlo,

Em 2008, as instituições parnaibanas que atuam no ensino superior, técnico e profissional de

Prof. Rodrigo Augusto Rocha Souza Baluz (UESPI/Parnaíba)

Prof. Antônio Oseas de Carvalho Filho (UFPI/Picos)

Prof. Rodrigo Augusto Rocha Souza Baluz (UESPI/Parnaíba)

Prof. Athanio de Souza Silveira (IFPI/Parnaíba)

Prof. Sérgio Barros de Sousa (UESPI/Parnaíba)

COMISSÃO DAS SESSÕES TÉCNICAS DE ARTIGOS

Prof. Ricardo de Andrade Lira Rabelo (UFPI/Teresina)

COMISSÃO DE INSCRIÇÕES E CERTIFICAÇÃO

Prof. Francisco das Chagas Rocha (UESPI/Parnaíba)

Prof. Ricardo de Andrade Lira Rabelo (UFPI/Teresina)

Prof. Luciano Kelvin da Silva (UESPI/Parnaíba)

COMISSÃO DE ARTICULAÇÃO CARAVANAS

Profa. Cornélia Janayna Pereira Passarinho (UESPI/Parnaíba)

COMISSÃO DE DIVULGAÇÃO, CRIAÇÃO E ARTE

Prof. Francisco Gerson Amorim de Meneses (IFPI/Parnaíba)

COMISSÃO DA EXPO APP

Prof. Paulo César Coutinho (Polo Tecnológico de Parnaíba/SEBRAE)

Prof. Dr. Ricardo de Andrade Lira Rabêlo

Prof. Dr. Thiago Carvalho de Sousa

Prof. Dr. Gildário Dias Lima

Prof. Dr. Hermes Manoel Galvão Castelo Branco

Profa. Dra. Cornélia Janayna Pereira Passarinho

Prof. Dr. Fabio de Jesus Lima Gomes

Prof. Dr. Ariel Soares Teles

Prof. Dr. Marcos Antonio de Oliveira

Profa. Dra. Atslands Rego da Rocha

Prof. Dr. Ed Porto Bezerra

Prof. Dr. André Luiz de Oliveira

Prof. Dr. Fábio Levy Siqueira

Prof. Dr. Eduardo Takeo Ueda

Prof. Dr. Flávio Rubens de Carvalho Sousa

Prof. Dr. Eyder Franco Sousa Rios

Prof. Dr. Sérgio Barros de Sousa

Prof. Dr. José de Ribamar Martins Bringel Filho

Profa. MSc. Alcilene Dalília de Sousa

Prof. MSc. Romuere Rodrigues Veloso e Silva

Profa. MSc. Patricia Medyna Lauritzen de Lucena Drumond

Prof. MSc. Flávio Henrique duarte de Araújo

Profa. MSc. Patricia Vieira da Silva Barros

Prof. Dr. Francisco Airton Pereira da Silva

Profa. Dra. Samáris Ramiro Pereira

Prof. Dr. Gustavo Augusto Lima de Campos

Prof. Dr. Wladimir Araújo Tavares

Prof. Dr. Guilherme Guimarães Lage

Prof. Dr. Antônio Helson Mineiro Soares

Profa. Dra. Simone dos Santos Hoefel

Prof. Dr. Ivan Saraiva Silva

Prof. Dr. Daniel Barbosa

Prof. Paulo Sérgio Marques dos Santos

Prof. MSc. José de Oliveira Brito Neto

Prof. Dr. André Castelo Branco Soares

Prof. MSc. Guilherme Enéas Vaz Silva

Prof. Dr. Rodrigo de Melo Souza Veras

Prof. MSc. Pedro Almir Martins de Oliveira

Prof. Dr. Pedro de Alcântara dos Santos Neto

Prof. Dr. Kelson Rômulo Teixeira Aires