WoCCES - SBRC 2016 - Universidade Federal da Bahia

Transcrição

Anais do WoCCES 2016
Workshop de Comunicação de
Sistemas Embarcados Crı́ticos
Editora
Sociedade Brasileira de Computação (SBC)
Organização
Adriano Mauro Cansian (UNESP)
Alex Sandro Roschildt Pinto (UFSC-Blumenau)
Daniel Fernando Pigatto (USP)
Kalinka Regina Lucas Jaquie Castelo Branco (USP)
Vandermi João da Silva (UFAM)
Michele Nogueira Lima (UFPR)
Fabı́ola Gonçalves Pereira Greve (UFBA)
Allan Edgard Silva Freitas (IFBA)
Realização
Universidade Federal da Bahia (UFBA)
Instituto Federal da Bahia (UFBA)
Promoção
Laboratório Nacional de Redes de Computadores (LARC)
c
Copyright 2016
da Sociedade Brasileira de Computação
Todos os direitos reservados
Capa: Gilson Rabelo (UFBA)
Produção Editorial: Antonio Augusto Teixeira Ribeiro Coutinho (UEFS)
Cópias Adicionais:
Av. Bento Gonçalves, 9500- Setor 4 - Prédio 43.412 - Sala 219
Bairro Agronomia - CEP 91.509-900 - Porto Alegre - RS
Fone: (51) 3308-6835
E-mail: [email protected]
Workshop de Comunicação de Sistemas Embarcados Crı́ticos (6: 2016: Salvador,
BA).
Anais / IV Workshop de Comunicação de Sistemas Embarcados Crı́ticos; organizado por Adriano Mauro Cansian, Alex Sandro Roschildt Pinto, Daniel Fernando
Pigatto, Kalinka Regina Lucas Jaquie Castelo Branco, Vandermi João da Silva,
Michele Nogueira Lima, Fabı́ola Gonçalves Pereira Greve, Allan Edgard Silva Freitas
- Porto Alegre: SBC, 2016
85 p. il. 21 cm.
Vários autores
Inclui bibliografias
1. Redes de Computadores. 2. Sistemas Distribuı́dos. I. Cansian, Adriano Mauro
II. Pinto, Alex Sandro Roschildt III. Pigatto, Daniel Fernando IV. Branco, Kalinka
Regina Lucas Jaquie Castelo V. Silva, Vandermi João da VI. Lima, Michele Nogueira
VII. Greve, Fabı́ola Gonçalves Pereira VIII. Freitas, Allan Edgard Silva IX. Tı́tulo.
ii
Sociedade Brasileira da Computação
Presidência
Lisandro Zambenedetti Granville (UFRGS), Presidente
Thais Vasconcelos Batista (UFRN),Vice-Presidente
Diretorias
Renata de Matos Galante (UFGRS), Diretora Administrativa
Carlos André Guimarães Ferraz (UFPE), Diretor de Finanças
Antônio Jorge Gomes Abelém (UFPA), Diretor de Eventos e Comissões Especiais
Avelino Francisco Zorzo (PUC RS), Diretor de Educação
José Viterbo Filho (UFF), Diretor de Publicações
Claudia Lage Rebello da Motta (UFRJ), Diretora de Planejamento e Programas
Especiais
Marcelo Duduchi Feitosa (CEETEPS), Diretor de Secretarias Regionais
Eliana Almeida (UFAL), Diretora de Divulgação e Marketing
Diretorias Extraordinárias
Roberto da Silva Bigonha (UFMG), Diretor de Relações Profissionais
Ricardo de Oliveira Anido (UNICAMP), Diretor de Competições Cientı́ficas
Raimundo José de Araújo Macêdo (UFBA), Diretor de Cooperação com Sociedades
Cientı́ficas
Sérgio Castelo Branco Soares (UFPE), Diretor de Articulação com Empresas
Contato
Av. Bento Gonçalves, 9500
Setor 4 - Prédio 43.412 - Sala 219
Bairro Agronomia
91.509-900 – Porto Alegre RS
CNPJ: 29.532.264/0001-78
http://www.sbrc.org.br
iii
Laboratório Nacional de Redes de Computadores (LARC)
Diretora do Conselho Técnico-Cientı́fico
Rossana Maria de C. Andrade (UFC)
Vice-Diretor do Conselho Técnico-Cientı́fico
Ronaldo Alves Ferreira (UFMS)
Diretor Executivo
Paulo André da Silva Gonçalves (UFPE)
Vice-Diretor Executivo
Elias P. Duarte Jr. (UFPR)
Membros Institucionais
SESU/MEC, INPE/MCT, UFRGS, UFMG, UFPE, UFCG (ex-UFPB Campus Campina
Grande), UFRJ, USP, PUC-Rio, UNICAMP, LNCC, IME, UFSC, UTFPR, UFC, UFF,
UFSCar, IFCE (CEFET-CE), UFRN, UFES, UFBA, UNIFACS, UECE, UFPR, UFPA,
UFAM, UFABC, PUCPR, UFMS, UnB, PUC-RS, UNIRIO, UFS e UFU.
Contato
Universidade Federal de Pernambuco - UFPE
Centro de Informática - CIn
Av. Jornalista Anibal Fernandes, s/n
Cidade Universitária
50.740-560 - Recife - PE
http://www.larc.org.br
iv
Organização do SBRC 2016
Coordenadores Gerais
Fabı́ola Gonçalves Pereira Greve (UFBA)
Allan Edgard Silva Freitas (IFBA)
Romildo Martins Bezerra (IFBA) - In Memoriam
Coordenadores do Comitê de Programa
Antonio Marinho Pilla Barcellos (UFRGS)
Antonio Alfredo Ferreira Loureiro (UFMG)
Coordenador de Palestras e Tutoriais
Francisco Vilar Brasileiro (UFCG)
Coordenador de Painéis e Debates
Carlos André Guimarães Ferraz (UFPE)
Coordenadores de Minicursos
Lau Cheuck Lung (UFSC)
Frank Siqueira (UFSC)
Coordenadora de Workshops
Michele Nogueira Lima (UFPR)
Coordenador do Salão de Ferramentas
Daniel Macêdo Batista (USP)
Comitê de Organização Local
Adolfo Duran (UFBA)
Allan Freitas (IFBA)
Antonio Augusto Teixeira Ribeiro Coutinho (UEFS)
Cátia Khouri (UESB)
Fabı́ola Greve (UFBA)
Flávia Maristela Nascimento (IFBA)
Gustavo Bittencourt (UFBA)
Ítalo Valcy (UFBA)
Jauberth Abijaude (UESC)
Manoel Marques Neto (IFBA)
Marco Antônio Ramos (UESB)
Marcos Camada (IF BAIANO)
Marcos Ennes Barreto (UFBA)
Maycon Leone (UFBA)
Rafael Reale (IFBA)
Renato Novais (IFBA)
Ricardo Rios (UFBA)
Romildo Bezerra (IFBA) - In Memoriam
Sandro Andrade (IFBA)
Vinı́cius Petrucci (UFBA)
v
Comitê Consultivo
Jussara Almeida (UFMG), Coordenadora
Elias Procópio Duarte Jr. (UFPR)
José Rezende (UFRJ)
Jacir Luiz Bordim (UnB)
Rafael Timóteo de Sousa Júnior (UnB)
William Ferreira Giozza (UnB)
Carlos André Guimarães Ferraz (UFPE)
José Augusto Suruagy Monteiro (UFPE)
vi
Mensagem da Coordenadora de Workshops
Os workshops são uma parte tradicional e importante do que hoje faz do SBRC o
principal evento da área no paı́s, sendo responsáveis por atrair uma parcela cada vez mais
expressiva de participantes para o Simpósio. Este ano demos continuidade à chamada
aberta de workshops, estimulando a participação da comunidade de Redes e Sistemas
Distribuı́dos a sugerir e fortalecer novas linhas de pesquisa, bem como manter em evidência
linhas de pesquisas tradicionais.
Em resposta à chamada, recebemos nove propostas de alta qualidade, das quais sete
estão sendo de fato organizadas nesta edição do SBRC em Salvador. Dentre as propostas
aceitas, quatro reforçaram workshops tradicionais do SBRC, considerados parte do circuito
nacional de divulgação cientı́fica nas várias subáreas de Redes de Computadores e Sistemas
Distribuı́dos, como o WGRS (Workshop de Gerência e Operação de Redes e Serviços), o
WTF (Workshop de Testes e Tolerância a Falhas), o WCGA (Workshop em Clouds, Grids
e Aplicações) e o WP2P+ (Workshop de Redes P2P, Dinâmicas, Sociais e Orientadas a
Conteúdo). Além disso, três propostas apoiam a consolidação de subáreas mais recentes,
tais como as propostas de organização do WPEIF (Workshop de Pesquisa Experimental
da Internet do Futuro), do WoSiDA (Workshop de Sistemas Distribuı́dos Autonômicos) e
do WoCCES (Workshop de Comunicação de Sistemas Embarcados Crı́ticos).
Esperamos que 2016 seja mais um ano de sucesso para os workshops do SBRC, contribuindo como importantes fatores de agregação para os avanços promovidos pela comunidade cientı́fica da área de Redes de Computadores e Sistemas Distribuı́dos no Brasil.
Aproveitamos para agradecer o inestimável apoio recebido de diversos membros da
comunidade e, em particular a cada coordenador de workshop, pelo brilhante trabalho, e
a Organização Geral do SBRC 2016 pelo profissionalismo e comprometimento.
A todos, um excelente SBRC em Salvador!
Michele Nogueira
Coordenadora de Workshops do SBRC 2016
vii
Mensagem dos Coordenadores do WoCCES 2016
O IV Workshop of Communication in Critical Embedded Systems (WoCCES) em conjunto com o 34o Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuı́dos
(SBRC 2016), em Salvador, BA, tem por objetivo atuar como um fórum para apresentações
técnicas de pesquisas em andamento e atividades relevantes nas áreas de comunicação
em sistemas embarcados crı́ticos, congregando pesquisadores e profissionais que atuam
ativamente nessas áreas. O workshop também procura estabelecer redes colaborativas
multi-institucionais e grupos de competência técnico-cientı́fica, bem como fortalecer atividades em andamento. Sendo assim, o Workshop se concentra em importantes inovações
e avanços recentes na especificação, projeto, construção e utilização da comunicação em
sistemas embarcados crı́ticos, sendo que o objetivo do mesmo é o de reunir pesquisadores
e profissionais da indústria e da academia e proporcionar-lhes uma oportunidade para
se informar sobre os últimos desenvolvimentos, implantações, tendências tecnológicas e
resultados de pesquisa, bem como iniciativas relacionadas com sistemas embarcados e
suas aplicações em uma variedade de ambientes industriais. Este ano o workshop conta
com uma palestra sobre “IoT - Aplicações em SmartCities e Implicações de Segurança”
apresentada pelo prof. Dr. Cesar Marcondes de Universidade de São Carlos (UFSCar) e
três seções técnicas. Esperamos que a palestra e as apresentações dos trabalhos nas seções
técnicas promovam discussões acaloradas entre os participantes do workshop, contribuindo
assim para o avanço da área.
Coordenadores do WoCCES 2016
viii
Comitê de Programa
Carlos Barros Montez (UFSC)
Célia Leiko Ogawa Kawabata (IFSP-São Carlos)
Denis Fernando Wolf (USP)
Edson dos Santos Moreira (USP)
Ellen Francine Barbosa (USP)
Fábio Dacêncio Pereira (UNIVEM)
Fernando Santos Osório (USP)
Gustavo Pessin (Vale)
Horácio Antonio Fernandes de Oliveira (UFAM)
Ivanovitch Medeiros Dantas da Silva (UFRN)
Jacir Luiz Bordim (UNB)
João Cunha (IPC - Portugal)
Luciana Martimiano (UEM)
Luiz Henrique Castelo Branco (IFSP-Araraquara)
Marco Vieira (UC - Portugal)
Marcos Fagundes Caetano (UNB)
Mario Antonio Ribeiro Dantas (UFSC)
Mário Meireles Teixeira (UFMA)
Paulo Portugal (UP - Portugal)
Raimundo Barreto (UFAM)
ix
Sumário
Sessão Técnica 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Um sistema para monitoramento de sinais fisiológicos baseado em hardware de baixo custo com acesso via WEB
Lucas F. Da Cruz (UFAM), Camila Bernardon (UFAM), Evelym V.M. dos Santos
(UFAM), Walter C. S. S. Simões (UFAM e UNINORTE) e Vandermi J. da Silva
(UFAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Um Survey de Seleção de Nodos Cooperantes em Abordagens de Comunicação Cooperativa em Redes de Sensores Sem Fio
Suelen M. Laurindo (UFSC), Carlos Montez (UFSC), Odilson T. Valle (IFSC) e
Ricardo Moraes (UFSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Uma propostas de arquitetura para robôs como um service (RAAS)
Edson de A. Silva (UFAM), Adilson T. da Cruz (UFAM), Gustavo L. P. da Silva
(UFAM), Vandermi J. da Silva (UFAM), Alex S. R. Pinto (UFSC) e Mario A. R.
Dantas (UFSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Avaliação de desempenho de procedimentos de handoff em redes IPv6 e
uma discussão sobre a viabilidade de aplicações em sistemas crı́ticos
Lucas Tognoli Munhoz (USP), Guilherme Caixeta de Oliveira (USP), Daniel Fernando Pigatto (USP) e Kalinka Regina Lucas Jaquie Castelo Branco (USP) . . . . 32
Sessão Técnica 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Análise de Metodologias de Implementação e Desempenho em FPGA dos
Algoritmos Criptográficos Leves Simon e Speck
Claudio Roberto Costa (UNIVEM), Fábio Dacêncio Pereira (UNIVEM), Edward
David Moreno (UFS) e Fernanda Mayumi Ohnuma Tachibana (UNIVEM) . . . . . 46
Sistema Inteligente baseado em IoT para Detecção e Diagnóstico de Falha
em Equipamentos de uso Doméstico
Jorge Seabra (UFAM), Mario Costa Jr (UFAM) e Mateus Lucena (UFAM) . . . . . 57
Sessão Técnica 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Um algoritmo de navegação não linear 3D para veı́culos aéreos não tripulados
Guilherme V. Pelizer (USP), Natássya B. F. Silva (USP) e Kalinka R. L. J. C. Branco
(USP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Análise de Perfil de Motoristas: Detecção de Eventos por meio de Smartphones e Aprendizado de Máquina
Jair Ferreira Júnior (UFPA e Instituto Tecnológico Vale) e Gustavo Pessin – (UFPA
e Instituto Tecnológico Vale) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
x
WoCCES 2016
Sessão Técnica 1
1
2
Um sistema para monitoramento de sinais fisiológicos
baseado em hardware de baixo custo com acesso via WEB
Lucas F. Da Cruz1, Camila Bernardon1, Evelym V.M. dos Santos1, Walter C. S.S.
Simões 1,2, Vandermi J. da Silva1
1
Instituto de Ciências Exatas e Tecnologia – Universidade Federal do Amazonas
(UFAM)
Itacoatiara – AM – Brasil
2
Tecnologia em Redes de Computadores – Centro Universitário do Norte
(UNINORTE) Caixa Postal 227 – 69020-220 – Manaus – AM – Brasil
{lucasfariasdacruz, camilabernardon.es,
evelym.vasconcelos}@gmail.com, [email protected],
[email protected]
Resumo. Médicos e equipes de saúde enfrentam alguns problemas durante o
acompanhamento de pacientes que necessitam de exames de coração. Neste
caso é necessário que o paciente utilize um dispositivo de medição durante
certo período de tempo e muitas vezes há a necessidade de mais funcionários
para auxiliar nos procedimentos, além da dificuldade para aplicar esses
exames em áreas não assistidas por grandes centros de saúde. Nesse contexto,
foi proposta uma arquitetura que integra hardware e software para permitir
que um sistema acesse os dados de dispositivos de coleta de sinais fisiológicos
e os disponibilize como um serviço WEB, esse serviço permitirá o
acompanhamento de pacientes remotamente com objetivo de minimizar as
idas do paciente ao hospital.
1. Introdução
Segundo a Organização Mundial de Saúde (OMS), as doenças cardiovasculares são
uma das maiores causas de mortes no mundo (Wajngarten, 2010), sendo a maioria delas
acometidas por idosos. O aumento desta doença ocorre muitas vezes pelo estilo de vida
do paciente e/ou pela falta de visitas ao médico, acarretando na descoberta da doença
quando a mesma já se encontra em estado avançado (Sutar, Kothari and Keskar, 2013).
Os pacientes cardíacos necessitam monitorar diariamente seus parâmetros
fisiológicos durante certo período de tempo para verificar se os padrões de batimentos,
pressão e oximetria, estão nos níveis adequados. Para realizar o monitoramento,
normalmente se utiliza equipamentos apropriados e funcionários especializados para
auxiliar no decorrer do acompanhamento, fazendo o paciente se deslocar de sua
residência em busca de um atendimento específico em Unidades Básicas de Saúde
(UBS) ou hospitais.
Atualmente, os equipamentos utilizados para o acompanhamento dos batimentos
cardíacos permanecem com o paciente, que armazena os dados do exame no próprio
dispositivo. Porém, um grande problema deste tipo de armazenamento é que o paciente
pode modificar as configurações sem a intenção, ou até mesmo por algum motivo o
aparelho desligar. Quando ocorre esse tipo de situação, é necessário que o exame seja
refeito, acarretando em atrasos na disponibilidade de aparelhos para outros pacientes.
Em pacientes idosos esse problema é frequente devido à carência de
acompanhamento por uma pessoa que saiba operar o aparelho, pelo fato de o próprio
3
paciente não ter o conhecimento para identificar quando o aparelho não está operando
de forma correta, ou até mesmo quando ele foi desligado.
Nesse contexto, uma arquitetura que aperfeiçoe a coleta de dados de batimentos
cardíacos e seu armazenamento, tende a melhorar a forma como os dados são
disponibilizados para a equipe médica e com isso permitir o acesso online por meio das
tecnologias de nuvem, possibilitando mais mobilidade para o paciente e para a equipe
médica que o acompanha.
A proposta de trabalho é minimizar os deslocamentos e aperfeiçoar o uso dos
equipamentos de medição de batimentos cardíacos principalmente para os exames
aplicados a idosos e desenvolver um sistema embarcado que realize a leitura por meio
de sensores para acompanhar o ritmo cardíaco de um paciente em tempo real utilizando
as tecnologias de nuvem e serviços WEB.
Foi proposta uma arquitetura para construção do sistema, dividida em três partes
que são: camada de coleta de dados, camada de serviços e camada de aplicação. O
sistema foi desenvolvido usando uma placa Arduino conectada a um sensor de
batimentos cardíacos, uma placa de desenvolvimento Intel Galileo Gen2, responsável
por processar e disponibilizar os dados e um smartphone para acessar os dados
processados.
2. Trabalhos Relacionados
Em Kemis et al. (2012), foi desenvolvido um aplicativo de monitoramento de saúde
para rede de sensores onipresentes, em que o sensor de pulso utiliza a placa Arduino
para enviar os dados para o servidor WEB utilizando o padrão 802.11. Os dados
coletados podem ser vistos à distância e analisados por um médico ou enfermeiro. O
sensor de pulso recolhe e analisa os sinais obtidos a partir dos dados brutos do ritmo
cardíaco e em seguida transfere os dados recebidos por meio da conexão Wifi para o
servidor no centro médico, no qual os dados são interpretados pelo software de
armazenamento. A desvantagem do trabalho apresentando por Kemis em relação ao
trabalho proposto neste artigo é o alto consumo de energia do dispositivo e a
necessidade de uma rede wifi para a coleta de dados dos dispositivos embarcados.
Em Zulkifli et al. (2012), os autores apresentaram um sistema, que utiliza a
topologia mesh como principal abordagem, preocupando-se com o monitoramento do
paciente condicionado a rede de malha sem fio. No desenvolvimento do projeto foi
utilizado dois oxímetros de pulso para obter os dados de frequência cardíaca do
paciente, onde ambos são ligados a um dispositivo de comunicação no padrão ZigBee
por meio do Arduino-Nano. Os dados obtidos pelo oxímetro são enviados ao
microcontrolador e em seguida são enviados via nó sensor para um nó receptor. Cada nó
na rede é responsável por dar continuidade na transmissão dos dados, que precisa ser
reprocessado pelo microcontrolador, dando uma identificação única para cada um deles.
No receptor os dados são apresentados por meio de uma interface que pode ser vista em
um computador. A principal desvantagem do trabalho está na visualização dos dados
centrado em um PC que não permite a visualização dos dados via WEB, o que torna o
sistema muito centralizado.
Em Watthanawisuth et al. (2010), foi desenvolvido um sistema de
monitoramento sem fio portátil, que apresenta um oxímetro de pulso composto por um
par de LEDs, que consistem de luz infravermelha e vermelha, e um fotodiodo que
detecta a luz, onde esses são embalados em uma fita de velcro que reverte o dedo do
paciente. O sistema é composto por um grupo desses sensores para medir a frequência
4
cardíaca e saturação de oxigênio no sangue dos pacientes que faz o monitoramento em
tempo real baseado na rede sem fio ZigBee. Os dados recebidos do oxímetro de pulso
são guardados e calculados por uma unidade microcontroladora e depois são
transferidos e armazenados no servidor que funciona em um computador. O principal
diferencial do trabalho é o gerenciamento de energia do dispositivo, no entanto, a
visualização dos dados continua centralizada em um computador não permitindo o
acesso externo.
Em Keerthika e Ganesan (2013), foi apresentado um sistema de
acompanhamento de saúde não invasiva, em que o sensor de oxímetro de pulso é
colocado no corpo humano, e recebe os dados de saturação de oxigênio no sangue
(SpO2). Os dados recebidos do sensor são enviados ao microcontrolador PIC
(Pheripheral Interface Controller), onde são tratados e o valor obtido é exibido em um
LCD (Liquid Crystal Display). Esses dados são transmitidos usando o MODEM GSM
(Global Sim Module), tendo um emissor e outro receptor. Na recepção, os dados são
armazenados no PC Servidor, onde são processados, e se a percentagem da Taxa de
Oxigênio for inferior a 80, um alerta SMS é dado ao paciente, se for inferior a 50 o
alerta é dado a médico para tratamento imediato, evitando doenças graves. A diferença
entre o trabalho de Keerthika e Ganesan (2013) e este trabalho é na comunicação entre
o servidor e o cliente que nesse caso utiliza a rede GSM com assinatura de pacotes de
dados.
Em Kini et al. (2015), foi apresentada uma rede de sensores sem fio que visa
monitorar remotamente os sinais vitais de um paciente, como batimento cardíaco,
temperatura do corpo e saturação de oxigênio no sangue (SpO2). Esses sinais são
processados por um Sensor Communication Module (SCM). O sistema é composto por
um conjunto de sensores e um dispositivo hub para dois pacientes diferentes. Os
sensores são usados para detectar diferentes parâmetros do corpo humano e o hub para
obter os dados dos sensores e formar um array de dados a ser transmitido. O hub é
composto pelo microcontrolador MSP430 G2 e o módulo de transmissão de dados
CC110L.
Tabela 1. Comparação entre os trabalhos relacionados e a proposta deste trabalho
Trabalhos
Tecnologia de rede
Gerenciamento
de consumo de
energia
Armazamento de
backup
Acesso remoto
aos dados
Kemis (2012)
Wifi 802.11
Não
Sim
Não
Zulkfli (2012)
XBee
Não
Sim
Não
Watthanawisuth
et al. (2010),
XBee
Sim
Não
Não
Keerthika e
Ganesan
(2013),
Redes GSM
Não
Não
Não
Kini (2015)
Redes Sub-1 Ghz
Sim
Não
Não
Este trabalho
XBee / Wifi 802.11
Não
Sim
Sim
Observando as funcionalidades apresentadas nos trabalhos relacionados,
conclui-se que há uma diversidade de tecnologias de rede utilizadas para coletar dados
de sensores, somente um trabalho se preocupa com o consumo de energia, somente o
trabalho presentado neste artigo permite o acesso remoto aos dados, o que é uma
contribuição significante.
5
3. Metodologia da pesquisa
A metodologia para o desenvolvimento deste trabalho consistiu em cinco fases
baseadas na pesquisa bibliogáfica e descritas a seguir: a revisão sistemática em busca de
trabalhos relacionados com o tema proposto, fase um. Nessa etapa foram escolhidos os
trabalhos que fazem parte do estado da arte e a identificação das técnicas de hardware e
software utilizadas, construção de uma arquitetura e de um protótipo para coleta de
dados de batimentos cardíacos utilizando equipamentos de baixo custo.
Na fase dois a avaliação dos dados coletados foi verificada para auxiliar na
avaliação da tecnologia de redes sem fio utilizadas na transmissão dos dados ao servidor
e para a construção da base de dados. A construção do serviço WEB embarcado na placa
de desenvolvimento Intel Galileo se deu na fase três. Na fase quatro foram construídos
ambientes de teste para testar os módulos usando uma rede local e também usando a
Internet. Na fase cinco, os resultados dos protótipos desenvolvidos foram comparados
com dois aplicativos similares disponíveis no mercado.
4. Arquitetura e construção do protótipo
A arquitetura do trabalho foi desenvolvida em camadas conforme apresentada na Figura
1 composta por três módulos que são: a coleta de dados, o tratamento de dados pelo
servidor, e o acesso aos dados, pela Internet e rede local. Para a coleta de dados foi
utilizado uma placa Arduino Nano com um módulo XBee e um sensor de batimentos
cardíacos. No módulo WEB foi utlizada uma placa Intel Galilleo com um Web Service
desenvolvido em C++ utilizando a IDE do Arduino, no protocolo HTTP que usa um
modelo de solicitações de respostas, ocorrendo quando o usuário faz uma solicitação ao
servidor que devolve uma resposta HTTP. Possibilitando uma resposta HTML5, JSON
e os dados sendo salvos em uma base de texto armazenada em um cartão de memória na
própria placa.
O acesso aos dados utilizando a rede sem fio foi feito por meio de um aplicativo
escrito em Android que permitiu que os dados fossem mostrados nos dispositivos a
partir da solicitação de um GET/POST no servidor WEB.
As tecnologias envolvidas nesta arquitetura são o Yocto Linux com o servidor
da WEB incorporado na placa do Galileo, os módulos ZigBee para conexão sem fio, o
sensor de pulso usado para dados coletados e armazenamento de dados JSON no
servidor Galileo.
Figura 1: A arquitetura do sistema.
6
4.1. Estudo de caso
O estudo de caso desenvolvido para esse trabalho consiste na construção de um
dispositivo de baixo custo para monitoramento cardíaco, onde a coleta de dados foi feita
por um sensor de pulso chamado Amped que foi conectado na placa Arduino Nano, o
sensor coleta os dados de batimentos cardíacos do usuário e os envia para o
microcontrolador. O tratamento é feito no intervalo de um segundo por amostragem, o
Arduino lê os dados e obtém-se a média dos batimentos cardíacos com base na fórmula
apresentada em Agarwal (2012). A comunicação entre as placas Arduino e Galileo Intel
foi feita usando um módulo XBee com base no protocolo IEEE 802.15.4. Os dados são
enviados pelos pinos 0 e 1 da placa Arduino e depois, o microcontrolador envia os
dados pelo portal serial do Xbee que transmite os dados para o Web Service embarcado
na placa Galileo.
A comunicação sem fio foi feita através de dois módulos XBee com rede sem
fio com padrão IEEE 802.15, um módulo está acoplado com o Arduino Nano e o outro
ligado na placa Galileo, conforme esquemático apresentado na Figura 2.
Figura 2: Comunicação sem fio Arduino Nano e Galileo Gen2.
A placa Galileo possui a funcionalidade de um servidor e é responsável por
armazenar os dados no formato JSON. Esses dados são lidos por uma aplicação móvel
instalado em um smartphone / tablet e assim os mesmos dados apresentados pelo
display na placa estão disponíveis através da rede para outros dispositivos.
4.2 Protótipos desenvolvidos
Foi desenvolvido um protótipo em Android para se comunicar com o servidor
WEB provido pela placa Intel Galileo. Esse protótipo comunica-se com o servidor e lê
um vetor de dados que recebe a taxa de batimentos cardíacos e apresenta no display do
smartphone ou tablet. Do lado servidor, os mesmos dados enviados ao
smartphone/tablet por meio de GET/POST, são também apresentados no display da
placa Galilleo, isso foi feito para observar o sincronismo dos dados coletados pela placa
e enviados para a rede. O algoritmo utilizado foi o de produtor consumidor com
semáforos para indicar quando o serviço WEB era solicitado e quando os dados eram
disponibilizados para a gravação no cartão de memória.
A Figura 3 (A) apresenta o aplicativo desenvolvido usando um tablet como base,
nele é possível cadastrar o usuário para que o mesmo acompanhe seus batimentos por
meio do dispositivo sem necessidade de observar o display do equipamento que faz a
coleta. Os dados apresentados no dispositivo móvel são o mesmo da última coleta feita
e armazenada no servidor. A Figura 3(B) mostra o sistema integrado com o coletor de
7
dados conecatdo via rede XBee e embarcado na placa Galileo a inteligência e
processamento dos dados do sensor de batimentos é feita no Arduino-Nano e os dados
são enviados via requisição para o servidor instalado na Galileo que dispnibiliza o
acesso externo. Pode ser observado que tanto no lado servidor quanto no lado cliente a
informação sobre os batimentos cardíacos são exatamente os mesmos.
Figura 3: Aplicativo para Android (A) e exibição do aplicativo Galileo (B).
5. Resultados
O resultado obtido por meio dos testes efetuados com o protótipo desenvolvido permitiu
avaliar o sistema como um todo, comparando os resultados com os de um smartwatch e
de um aplicativo desenvolvido para smartphone como descrito a seguir.
Primeiro foram coletados dez batimentos cardíacos de cada sistema e em
seguida foram comparados usando um gráfico de linhas para verificar se a apresentação
dos resultados dos batimentos tinham diferenças significantes entre os aplicativos. Para
esse teste, foi observada a coleta de dados de uma mesma pessoa em repouso. Foram
coletados trinta batimentos cardíacos no total, sendo dez do sistema apresentado neste
trabalho, dez do aplicativo para smartphone e dez do smartwatch. A partir desses dados
foi comparada a taxa de acertos do sistema proposto.
Segundo, já com os batimentos coletados foi feito uma analise estatística
descritiva que visa descrever e compreender os dados do sistema, utilizando média,
moda, mediana e desvio padrão. A média vai soma os resultados e dividir pelo número
total de resultados. A moda vai apresenta o batimento, mas frequente. Na mediana vai
apresenta o valor intermediário, onde vai utiliza o batimento mais baixo ao mais alto
onde vai soma e dividir por dois. Já o desvio padrão indica quando menor ele for mais
os dados estão proxima da media e quanto mais alto indica que os dados estão
espelhados por uma gama de valores.
A Figura 4 mostra o protótipo coletor de batimentos projetado usando um
Arduino Nano e o sensor Amped. O diferencial do protótipo é o uso da rede sem fio
com módulos XBee para proporcionar a comunicação entre as placas Arduino e Galileo.
Assim, é possível mais tarde reduzir o tamanho do dispositivo para, por exemplo,
prototipar uma pulseira eletrônica sem fio capaz de monitorar os batimentos cardíacos e
a temperatura de um paciente em observação.
8
Figura 4: Sensor de pulsações e microcontrolador.
A Figura 5 mostra o gráfico gerado comparando a taxa de acertos dos
batimentos cardíacos entre os sistemas. O sistema proposto neste trabalho obteve uma
taxa de acerto 5/10 indicando que a cada dez batimentos cinco são iguais aos outros
sistemas, nessa comparação os resultados são bem satisfatorio podendo ser observado
que não houve nenhuma grande variância dos dados.
Figura 5: Aplicação de testes de frequência cardíaca entre o protótipo do trabalho.
A tabela 2 apresenta dados estatísticos descritiva dos valores comparados no
gráfico mostrando média, moda, mediana e desvio padrão. Observando que dado o
desvio padrão do protótipo do trabalho obteve o maior número de batimentos disperso e
nenhum valor a se repete como mostra a moda. A média e a mediana do trabalho
proposto com o App Heart Rate e smartwatch observa-se que não ocorreu diferença
entre eles. E que o protótipo desenvolvido neste trabalho é perfeitamente viável.
Tabela 2. Apresenta dados estatísticos descritivos entre outro sistema e a proposta
deste trabalho
Sistema
Média
Moda
Mediana
Desvio padrão
Protótipo do trabalho
81,3
0
82
7,79
App Heart Rate
82,8
84
83
4,24
Smartwatch
77,8
77
77,5
3,94
9
6. Considerações Finais
Neste trabalho foi apresentado um sistema para o monitoramento de batimentos
cardíacos de baixo custo, utilizando microcontroladores, dispositivos móveis, redes de
sensores e rede local.
O sistema foi desenvolvido baseado em uma arquitetura cliente-servidor, realiza
o acesso a rede local e a Internet, possibilitando a visualização dos dados via aplicativo
móvel. O protótipo desenvolvido faz parte de um sistema maior que está sendo
construído pela equipe de pesquisa para aplicar futuramente em um sistema vestível
para coleta de dados de sinais vitais. O próximo passo da pesquisa será a modificação
da interface dos aplicativos e a integração de sensores de temperatura, pressão arterial e
acelerômetro para aumentar a quantidade de dados coletados e fazer novas inferências.
Agradecemos à Universidade Federal do Amazonas (UFAM) pela oportunidade e
apoio para desenvolver o projeto, Fundação de Amparo à Pesquisa do Estado do
Amazonas (FAPEAM) por ter disponíbilizado o equipamento necessário e a Intel pela
doação da placa Galileo Gen2 usada neste trabalho.
7. Referências
Agarwal, A.; Reddy, P. K.; Meena, S.; Shashidhara, H. L. (2012). “An embedded
system for determining arrhythmia”. Computing Communication & Networking
Technologies (ICCCNT), 2012 Third International Conference on. IEEE, pages 1 –
4, doi: 10.1109/ICCCNT.2012.6512436.
Christopher
Walken.
User
the
pulse
sensor
kit
available
<http://pulsesensor.com/pages/code-and-guide >. Access in: 10 abril de 2015.
in:
Keerthika, A.; Ganesan, R. (2013). “Pervasive Health Care System for Monitoring
Oxygen Saturation using Pulse Oximeter Sensor”. Information & Communication
Technologies (ICT), 2013 IEEE Conference on. IEEE, pages 819 – 823,
doi: 10.1109/CICT.2013.6558207.
Kemis, H.; Bruce, N.; Wang Ping; Antonio, T.; Gook, L. B.; Lee, H. J. (2012).
“Healthcare Monitoring Application in Ubiquitous Sensor Network: Design and
Implementation based on Pulse Sensor with Arduino”. Information Science and
Service Science and Data Mining (ISSDM), 2012 6th International Conference on
New Trends in. IEEE, pages 34 - 38.
Kini, V.; Patil, C.; Bahadkar, S.; Panandikar, S.; Sreedharan, A.; Kshirsagar, A. (2015).
“Low Power Wireless Health Monitoring System”. Advances in Computing,
Communications and Informatics (ICACCI), 2015 International Conference on.
IEEE, pages 980 – 986, doi: 10.1109/ICACCI.2015.7275738.
Lobo, I.,S., F.; Sistema para aquisição e transmissão da pulsação arterial via sms. 2014.
Sutar, R. G.; Kothari, A. G.; Keskar, A. G. (2013). “Development of an Embedded
System for Real Time Heart Rate Variability Analysis”. Communications and
Information Technologies (ISCIT), 2013 13th InternationalSymposium on. IEEE,
pages 288 – 292, doi: 10.1109/ISCIT.2013.6645866.
10
Wajngarten M. O coração no idoso. Jornal Diagnostico em Cardiologia.
Agosto/Setembro 2010.
Watthanawisuth, N.; Lomas, T.; Wisitsoraat, A.; Tuantranont, A. (2010). “Wireless
Wearable Pulse Oximeter for Health Monitoring using ZigBee Wireless Sensor
Network”. Electrical Engineering/Electronics Computer Telecommunications and
Information Technology (ECTI-CON), 2010 International Conference on. IEEE,
pages 575 – 579.
Zulkifli, N.S.A.; Harun, F.K.C.; Azahar, N.S. (2012).
“Centralized Heart Rate
Monitoring Telemetry System Using ZigBee Wireless Sensor Network” Biomedical
and Health Informatics (BHI), 2012 IEEE-EMBS International Conference on.
IEEE, pages 265 – 268, doi: 10.1109/BHI.2012.6211562.
11
Um Survey de Seleção de Nodos Cooperantes em Abordagens
de Comunicação Cooperativa em Redes de Sensores Sem Fio
Suelen M. Laurindo1 , Carlos Montez1 , Odilson T. Valle2 , Ricardo Moraes1
1
Programa de Pós-Graduação em Engenharia de Automação e Sistemas
Universidade Federal de Santa Catarina (UFSC)
Caixa Postal 476 – 88040-900 – Florianópolis – SC – Brazil
2
Instituto Federal de Santa Catarina (IFSC)
Campus São José – SC – Brazil
{suelen.m.l}@posgrad.ufsc.br, {montez}@ieee.org, {odilson}@ifsc.edu.br
{ricardo.moraes}@ufsc.br
Abstract. The cooperative diversity is a widely used technique to improve the
performance of communications in a Sensor Wireless Network (WSN). The relay selection is a decisive step in the application of this technique. This paper
proposes a classification taxonomy of the approaches of relay selection and presents a study of literature, describing the used techniques. The main goal of this
paper is to present a general guide to selecting the most appropriate technique
for the relay selection, according with the characteristics of the applications.
Resumo. A diversidade cooperativa é uma técnica muito utilizada para melhorar o desempenho das comunicações em uma Rede de Sensores Sem Fio (RSSF).
A seleção de nodos retransmissores é uma etapa decisiva na aplicação desta
técnica. Este artigo propõe uma taxonomia de classificação das abordagens
de seleção dos nodos cooperantes e apresenta um estudo da literatura, descrevendo as técnicas utilizadas. O objetivo principal deste artigo é apresentar um
guia geral para a seleção da técnica mais adequada para a seleção de nodos
cooperantes, de acordo com as características das aplicações.
1. Introdução
As primeiras concepções de Redes de Sensores Sem Fio (RSSF) ocorreram em 1998.
Estas redes são compostas de diversos dispositivos denominados de nodos, os quais são
dispositivos compostos por sensores, processador, memória, fonte de alimentação, rádio
e atuador [Yick et al. 2008]. Destaca-se ainda que os nodos são pequenos, simples e
apresentam limitações nos recursos computacionais e energéticos. As principais aplicabilidades estão relacionadas com o sensoriamento do ambiente e o repasse dos dados
recolhidos através da rede [Buratti et al. 2011].
Os nodos de uma RSSF utilizam radiofrequência para realizar a comunicação, que
é a tarefa responsável pelo maior consumo energético [Gungor and Hancke 2009]. Nesta
etapa, um nodo consome em média de 25 a 50mA quando está em operação. Já em seu
período inativo, quando este não está realizando comunicação, esse consumo diminui para
dezenas de µA [Valle 2014].
12
O alto consumo energético dos nodos é um problema, pois nem sempre é viável
realizar a troca de bateria, já que em aplicações de RSSF os nodos podem se encontrar
em áreas de difícil acesso. Por isso, é necessário utilizar os sensores de modo que nem
todos precisem estar ativos o tempo todo, assim o consumo de bateria de alguns nodos é
poupado, aumentando o tempo de vida da rede [Valle 2014].
Obstáculos entre os nodos podem gerar interferência ou perda de mensagens durante a comunicação, o que torna essa rede não confiável. Para minimizar este problema
pode ser utilizada cooperação entre os nodos [Valle 2014]. Técnicas de diversidade cooperativa têm sido propostas para melhorar o desempenho da rede sem aumentar a complexidade do hardware e ainda promover ganho de diversidade espacial no destino [Wang and
Syue 2009]. Estas técnicas permitem a criação de um sistema MIMO-virtual (multipleinput-multiple-output), já que a implantação de múltiplas antenas em RSSF geralmente
não é uma opção viável, principalmente devido ao tamanho dos nodos e dos recursos
energéticos limitados [Wang and Syue 2009].
Ambientes sem fio são projetados para que a transmissão envolva apenas um transmissor e um receptor, podendo o receptor ser o destino ou apenas o próximo nodo em uma
rede multi-hop [Khan and Karl 2014]. Já na diversidade cooperativa, considera-se a existência de nodos que irão cooperar com o par transmissor-receptor para que o nodo receptor
realmente receba o pacote enviado [Khan and Karl 2014]. Este comportamento fornecido
pela diversidade cooperativa permite um melhor aproveitamento da própria natureza das
transmissões sem fio [Liang et al. 2009], já que a transmissão normalmente é ouvida por
nodos vizinhos. Entretanto, em sistemas normais, estes nodos descartam os pacotes que
não são destinados a eles [Khan and Karl 2014].
Na retransmissão cooperativa, os nodos estão espacialmente distribuídos e cooperam retransmitindo mensagens, promovendo melhoria na comunicação [Himanshu et al.
2015]. Desta maneira, um nodo escuta o meio e obtêm todas as mensagens que consegue
ouvir e as envia para o coordenador. Assim, caso exista um obstáculo entre algum nodo
e o coordenador, as mensagens do nodo que não conseguiu comunicação direta serão
entregues ao coordenador por meio da cooperação de outros nodos [Valle 2014].
A Figura 1 apresenta uma transmissão utilizando diversidade cooperativa. Nesta
Figura é possível visualizar três passos, os nodos N1 e N3 desejam enviar uma mensagem
para o nodo coordenador. No passo 1, o nodo N1 envia uma mensagem m1 em broadcast,
que é recebida corretamente pelo nodo coordenador e que também é escutada pelo nodo
N2 . No passo 2, o nodo N3 envia uma mensagem m3 em broadcast, mas que por interferências não foi recebida corretamente pelo nodo coordenador. Entretanto, foi escutada
pelo nodo N2 . No passo 3, o nodo N2 , que escutou e armazenou as mensagens m1 e m3
retransmite estas para o coordenador. O coordenador já possui a mensagem m1 , e por
meio de técnicas de codificação de rede pode recuperar a mensagem m3 .
O desempenho da retransmissão cooperativa depende fortemente da eficiência do
processo utilizado para selecionar um ou mais nodos cooperantes [Jamal and Mendes
2010]. Utilizar todos os nodos como cooperantes permite obter uma grande diversidade
cooperativa, mas gera desperdícios de banda e aumenta a dificuldade de sincronização entre os nodos [Wang and Syue 2009]. Por isso um dos principais desafios na retransmissão
cooperativa é selecionar um nodo, ou conjunto de nodos, e assim, melhorar eficientemente
13
Figura 1. Transmissão com nodos cooperantes.
a transmissão de dados [Jamal and Mendes 2010].
O foco deste trabalho é apresentar uma visão geral dos diferentes algoritmos de
seleção de nodos cooperantes. As principais contribuições deste trabalho são: i) apresentar uma revisão geral do estado da arte das técnicas de seleção de nodos cooperantes em
abordagens de comunicação cooperativa em RSSF; ii) propõe uma taxonomia das abordagens de seleção dos nodos cooperantes; e iii) provê um pequeno tutorial para a seleção
adequada de técnicas de seleção de nodos cooperantes de acordo com as características
das aplicações.
O restante do trabalho está estruturado da seguinte forma: na Seção 2 é apresentada uma revisão do estado da arte sobre a seleção de nodos cooperantes, juntamente
com a taxonomia desenvolvida neste trabalho. Na Seção 3 são apresentadas as técnicas
descentralizadas citadas na taxonomia. Na Seção 4 são apresentadas as técnicas centralizadas citadas na taxonomia. Na Seção 5 é apresentada uma síntese do estado da arte e
finalmente na Seção 6 são apresentadas as conclusões.
2. Seleção de nodos Cooperantes
Em um sistema que utiliza cooperação em sua comunicação, os nodos transmitem seus
dados e cooperam transmitindo dados de outros nodos [Valle 2014]. Mas, simplesmente
inserir um número maior de sensores na rede e deixar que os nodos cooperantes sejam
escolhidos arbitrariamente apresenta baixa eficiência. Atualmente estudos estão sendo
realizados buscando encontrar a melhor técnica de seleção de nodos cooperantes [Wang
and Syue 2009].
O desempenho de sistemas que utilizam cooperação pode ser melhorado se os
nodos cooperantes forem otimamente selecionados. Este fato proporciona grande investigação no desenvolvimento de técnicas de seleção de nodos retransmissores [Etezadi et al.
2012]. Para realizar esta seleção é necessário considerar quais os critérios de seleção que
serão utilizados. Exemplo de critérios encontrados na literatura são: eficiência energética
de cada nodo, indicador da potência do sinal recebido (RSSI - Received Signal Strength
Indicator) em relação ao coordenador ou entre os próprios nodos, seleção por vizinhança
(Topologia), estado do canal (CSI - Channel State Information), relação sinal- ruído (SNR
- Signal-to-noise ratio), erros de transmissão (PER - Packet-Error-Rate) ou a combinação
destes parâmetros [Liu et al. 2015].
É importante ressaltar que os algoritmos encontrados na literatura podem ser
14
classificados em duas grandes categorias: centralizados e descentralizados. As técnicas centralizadas fornecem um bom desempenho, mas não são recomendadas para redes
de larga escala, pois o algoritmo de seleção será executado em um único nodo, e, para
isto, o nodo deverá obter todos os parâmetros dos outros nodos da rede. Entretanto para
receber estes parâmetros utilizará o meio de transmissão, o que comprometerá o monitoramento dos sensores, gerando sobrecarga. Já nas técnicas descentralizadas cada nodo
toma a decisão se será ou não cooperante, sem gerar sobrecarga na rede. Entretanto, diminui o desempenho da rede, pois nesta técnica as seleções de nodos retransmissores podem
falhar se ocorrer um processo de seleção mal sucedido [Feng et al. 2013]. Neste artigo
propõe-se a taxonomia apresentada na Figura 2 para a classificação dos métodos de seleção dos nodos cooperantes e nas próximas seções são descritos os trabalhos encontrados
na literatura com base nesta taxonomia.
Figura 2. Taxonomia seleção de nodos cooperantes.
3. Técnicas Descentralizadas
3.1. CSI - Channel State Information
De modo geral, nesta abordagem assume-se que os potenciais nodos cooperantes podem
ouvir a sequência de mensagens de Handshaking Request-to-Send (RTS) e Clear-to-Send
(CTS) (Figura 3 - Passo 1) entre o transmissor e o receptor indicando o início de uma
transmissão. Então, cada potencial nodo cooperante estima a condição do canal (CSI) do
nodo transmissor até o nodo cooperante (hs,i ) e do nodo cooperante até o destino (hi,d ).
A estimativa do CSI é baseada na variação da intensidade dos sinais de recebimento dos
frames RTS/CTS. Após estimar o CSI, cada nodo cooperante define um limite de tempo
15
Figura 3. Etapas para estimar a condição do canal.
Fonte: adaptado de [Chen et al. 2006].
com um valor inverso ao do valor estimado no CSI. Este valor funciona como um Backoff, assim, o nodo com menor tempo de espera torna-se o nodo cooperante. Os outros
nodos ainda estão em modo de escuta, assim o nodo selecionado como cooperante irá
enviar uma mensagem informando os outros nodos que o cooperante já foi selecionado
(Figura 3 - Passo 2). Para evitar casos onde nodos podem estar fora do alcance, os nodos
transmissor e o receptor podem anunciar que o nodo cooperante foi selecionado. E então o
nodo selecionado pode cooperar na transmissão (Figura 3 - Passo 3) [Bletsas et al. 2006].
3.2. Energia individual
A economia de energia é um fator importante quando se lida com dispositivos onde a
energia da bateria é limitada, como no caso dos nodos de uma RSSF. Os autores Chen et
al. (2006) propuseram uma seleção de nodos cooperantes power-aware (PARS) utilizando
como base o modelo oportunista de Bletsas et al. (2006), com o objetivo de maximizar
o tempo de vida da rede. A proposta destes é dividida em duas etapas. A primeira é a
alocação ótima de energia (OPA) e a segunda é a seleção de nodos cooperantes, como é
explicado abaixo:
Etapa 1 alocação ótima de energia (OPA): Todos os potenciais nodos cooperantes irão executar o algoritmo OPA utilizando como base as medições do canal obtidas por
meio das mensagens RTS/CTS, com o objetivo de diminuir o consumo total de energia da
transmissão, dada uma determinada taxa de transmissão. Como resultado do algoritmo,
cada nodo cooperante irá obter a energia de transmissão ótima tanto para o transmissor
quanto para cada nodo cooperante i. A solução obtida usando método de multiplicadores de Langrange1 é aplicada nos esquemas Amplify-and-Forward (AF) e Decode-andForward (DF).
Etapa 2 seleção de nodos cooperantes: A técnica proposta PARS realiza a seleção
dos nodos utilizando como base a ideia de temporizadores proposta na seleção oportunista de Bletsas et al. (2006). Entretanto, não utiliza diretamente as medições do canal
para estabelecer o limite do temporizador, mas sim o resultado do OPA, que é o consumo mínimo de energia necessário para a transmissão do par, nodo transmissor e nodo
cooperante, e também o nível de energia residual do nodo transmissor e de cada nodo
cooperante. Adicionalmente, os autores propuseram outros três critérios, onde cada um
1
O método dos multiplicadores de Lagrange permite encontrar extremos (máximos e mínimos) de uma
função de uma ou mais variáveis suscetíveis a uma ou mais restrições.
16
dos critérios corresponde a um conjunto de valores iniciais para o temporizador do nodo
origem e para o temporizador de cada potencial nodo cooperante.
O critério I tem como foco minimizar a energia total da transmissão e necessita
apenas dos resultados do OPA. Os critérios II e III tentam maximizar a energia residual
de cada nodo, ou seja, tentam manter de maneira aproximada a energia residual em cada
nodo. E assim como no método oportunista o nodo com o temporizador que expirar primeiro será selecionado como cooperante. Mas nesta abordagem, o nodo origem também
possui um temporizador e caso este expire primeiro significa que não há necessidade de
cooperantes. Quando um nodo é selecionado como cooperante, este notifica os outros
nodos da rede por meio de uma mensagem informando que um nodo cooperante foi selecionado.
3.3. Limite de SNR no destino
Os autores Amarasuriya et al. (2010) propuseram o esquema de seleção OT-MRS
(Output-Threshold Multiple Relay Selection). Este esquema permite selecionar mais de
um nodo cooperante se necessário. Considera-se uma rede com L + 2 nodos, na qual um
nodo é origem, um nodo é destino e L nodos são retransmissores. O esquema seleciona
os n primeiros Lc (o número de cooperantes é determinado com a normalização do limite
SNR) nodos cooperantes não ordenados (1 ≤ Lc ≤ L), onde combina o SNR das retransmissões com o SNR da transmissão do link direto para verificar se excede o limite SNR
predefinido. Este limite de SNR pode ser escolhido para ser o mínimo SNR requerido
para decodificar com sucesso um dado esquema de modulação. Este esquema é dividido
em duas fases:
1a fase: o destino D recebe o sinal transmitido pela origem durante a fase de
broadcast.
2a fase: o primeiro relay retransmite a versão amplificada da mensagem para o
destino D no primeiro time slot da fase de retransmissão (este esquema utiliza alocação de
canal por divisão de tempo com Lc time slots). Então, D combina este sinal com o sinal
recebido direto da origem (link direto) por meio do método de MRC (Maximum-Ratio
Combining). Se o SNR de saída do combinador for superior ao limite, não é necessário
que os outros nodos cooperantes retransmitam. Caso contrário, os nodos retransmissores
restantes serão selecionados nos time slots seguintes até que a saída cumulativa do SNR
seja superior ao limite.
4. Técnicas Centralizadas
4.1. Ganho de potência do canal com o nodo Controlador
Os autores Feng et al. (2013) propuseram um método centralizado chamado Centralized
Feedback-Based Relay Selection (FBRS), neste método o nodo origem envia uma mensagem em uma transmissão broadcast, para que todos os nodos possam ouvir. Os nodos
que conseguirem ouvir a mensagem irão enviar um símbolo piloto para o nodo destino
(Figura 4), pois este método utiliza o nodo destino como um controlador central que realiza a seleção do nodo cooperante. Este controlador irá escolher o nodo que apresente o
maior ganho de canal para ser o nodo cooperante.
O controlador irá obter a informação global dos canais, por meio dos símbolos
piloto enviados por cada nodo candidato a cooperante, os símbolos piloto são conhecidos
17
Figura 4. Transmissão do símbolo piloto.
Fonte: [Feng et al. 2013].
por todos os nodos da rede, e por meio destes o nodo destino pode obter as estimativas
dos canais, os autores assumem que por meio dos símbolos piloto o destino obtém conhecimento sobre o perfeito ganho de potência do canal. Então o nodo destino seleciona o
nodo cooperante que apresente o melhor ganho e notifica este, assim o nodo cooperante
retransmite a mensagem que a origem enviou.
4.2. Seleção Oportunista
Valle (2014) propôs uma seleção oportunista de nodos cooperantes baseada no histórico
de sucesso das transmissões e no LQI (Link quality indicator) entre cada nodo e o coordenador, valor este medido no coordenador. Para descobrir quais os melhores nodos coo; onde, i
perantes dentre os candidatos o autor propôs a seguinte equação: CNi = SRi +LQI
2
representa cada nodo na rede, SR é o índice histórico da taxa de sucesso nas transmissões
recentes e o LQI é o indicador de qualidade do enlace entre o nodo e o coordenador.
Os nodos que apresentarem os maiores CNi serão selecionados como cooperantes,
para determinar quantos nodos serão cooperantes o autor utilizou o percentual de perdas
de mensagens na rede, assim o número de cooperantes é determinado dinamicamente. O
coordenador notifica os nodos cooperantes por meio de uma mensagem especial na qual o
autor chamou de Blocop, e então os nodos selecionados como cooperantes irão armazenar
todas as mensagens que são enviadas por todos os nodos durante cada um dos T compartimentos (onde T é o número total de compartimentos no período de transmissão), após
o término dos T compartimentos, os nodos cooperantes irão codificar as mensagens que
estão em seus buffers e aguardarão até o seu compartimento para realizar a retransmissão
da mensagem.
18
4.3. SNR - Signal-to-noise ratio
Luo et al. (2015) propuseram um esquema de seleção de nodo cooperante baseado na
média do SNR do link do nodo candidato a cooperante até o nodo destino. Os autores
consideram que os nodos que receberam a mensagem do nodo origem e conseguiram
decodificá-las fazem parte do grupo decodificadores, que seria o grupo de candidatos a
nodos cooperantes. Para cada transmissão realizada pelo nodo origem, os nodos pertencentes ao grupo decodificadores devem enviar para o nodo origem o seu SNR médio até o
destino, assim o nodo origem irá selecionar o nodo com o maior SNR médio e irá informar
todos os nodos do grupo por meio de uma mensagem broadcast que o nodo cooperante foi
selecionado. Então o nodo cooperante irá retransmitir a mensagem para o nodo destino.
5. Síntese do Estado da Arte
Uma abordagem de seleção de nodos cooperantes adequada permite atingir um melhor
ganho de diversidade cooperativa, melhorando o desempenho da transmissão [Abdulhadi
et al. 2012]. Para a escolha adequada da abordagem a ser utilizada é necessário analisar
qual será a aplicação da rede, e assim tomar a primeira decisão: usar técincas centralizadas
ou descentralizadas. Se o número de nodos é pequeno ou a rede é estática, o efeito de
sobrecarga para sistemas centralizados torna-se insignificante [Feng et al. 2013], e assim
técnicas centralizados podem ser utilizadas. Por outro lado, se há muitos nodos na rede
ou a rede é dinâmica, as técnicas descentralizados são as abordagens mais recomendadas,
devido a menor quantidade de sobrecarga gerada. Nesse sentido, a taxonomia proposta
tem o objetivo de auxiliar os projetistas de sistemas a encontrar a técnica ou as técnicas
mais adequadas para o seu caso.
Baseado na taxonomia proposta selecionamos algumas características das técnicas
apresentadas, que podem ser vistas na Tabela 1 .
Tabela 1. Características das Técnicas de Seleção de Nodos Cooperantes.
Na Tabela 1 é possível verificar que as técnicas CSI, Energia Individual, Limite
de SNR no Destino e Seleção Oportunista apresentam a vantagem de não gerar elevado
overhead na rede e reduzem as falhas nas transmissões. As técnicas Limite de SNR no
Destino e Seleção Oportunista permitem que mais de um nodo cooperante seja selecionado, sendo que as demais selecionam apenas um cooperante. A técnica Energia Indivi19
dual proporciona a maximização da vida útil da rede e a técnica SNR também proporciona
redução nas falhas nas transmissões.
6. Conclusões
A seleção de nodos retransmissores é um ponto importante quando se trata de maximizar
o ganho de diversidade cooperativa em redes de sensores sem fio. Diferentes técnicas de
seleção de nodos cooperantes, cada uma delas com objetivos específicos, são propostas
na literatura. Este artigo apresentou um amplo estudo das técnicas de seleção de nodos
cooperantes, propondo uma taxonomia de classificação para a seleção de nodos retransmissores. Esta taxonomia é baseada em abordagens centralizadas e descentralizadas. Por
fim, destaca-se que foram apresentadas algumas características das técnicas estudadas, as
quais foram resumidas neste trabalho.
A seleção das técnicas deve ocorrer de acordo com as exigências estabelecidas
pelos projetistas da rede, levando em consideração as características de cada técnica e,
principalmente, a aplicação alvo. Como trabalhos futuros, pretende-se avaliar e propor
técnicas de seleção de nodos cooperantes para diversos tipos de aplicações. As técnicas
propostas considerarão um número maior de variáveis para a escolha dos nodos cooperantes, tais como: o número de nodos vizinhos, a energia restante dos nodos, etc.
7. Agradecimentos
Este trabalho teve o auxílio financeiro do Conselho Nacional de Desenvolvimento Cientifico e Tecnológico - CNPq - Brasil (400508/2014-1, 445700/2014-9) e CAPES.
Referências
Abdulhadi, S., Jaseemuddin, M., and Anpalagan, A. (2012). A Survey of Distributed
Relay Selection Schemes in Cooperative Wireless Ad hoc Networks. Wireless Personal
Communications, 63(4):917–935.
Amarasuriya, G., Ardakani, M., and Tellambura, C. ((2010)). Output-threshold multiplerelay-selection scheme for cooperative wireless networks. IEEE Transactions on Vehicular Technology, 59(6):3091–3097.
Bletsas, A., Khisti, A., Reed, D. P., and Lippman, A. (2006). A simple cooperative
diversity method based on network path selection. IEEE Journal on Selected Areas in
Communications, 24(3):659–672.
Buratti, C., Martalò, M., Ferrari, G., and Verdone, R. (2011). Sensor Networks with IEEE
802.15.4 Systems. Signals and Communication Technology. Springer Berlin Heidelberg, Berlin, Heidelberg, 1 edition.
Chen, Y., Yu, G., Qiu, P., and Zhang, Z. (2006). Power-Aware Cooperative Relay Selection Strategies in Wireless Ad Hoc Networks. IEEE 17th International Symposium on
Personal, Indoor and Mobile Radio Communications, pages 1–5.
Etezadi, F., Zarifi, K., Ghrayeb, A., and Affes, S. (2012). Decentralized Relay Selection
Schemes in Uniformly Distributed Wireless Sensor Networks. IEEE Transactions on
Wireless Communications, 11(3):938–951.
20
Feng, H., Xiao, Y., and Cimini, L. J. (2013). Spectral Efficiency of Centralized and
Decentralized Cooperative Networks with Relay Selection. In MILCOM 2013 - 2013
IEEE Military Communications Conference, volume 3, pages 7–12. IEEE.
Gungor, V. and Hancke, G. (2009). Industrial wireless sensor networks: challenges, design principles, and technical approaches. IEEE Transactions on Industrial,
56(10):4258–4265.
Himanshu, K., Ashutosh, R., and Rupali, A. (2015). Cooperative Communication: A
Review. IETE Technical Review, 5:1–10.
Jamal, T. and Mendes, P. (2010). Relay selection approaches for wireless cooperative
networks. In 2010 IEEE 6th International Conference on Wireless and Mobile Computing, Networking and Communications, pages 661–668. IEEE.
Khan, R. A. M. and Karl, H. (2014). MAC Protocols for Cooperative Diversity in Wireless
LANs and Wireless Sensor Networks. IEEE Communications Surveys and Tutorials,
16(1):46–63.
Liang, X., Balasingham, I., and Leung, V. C. M. (2009). Cooperative Communications
with Relay Selection for QoS Provisioning in Wireless Sensor Networks. In GLOBECOM 2009 - 2009 IEEE Global Telecommunications Conference, pages 1–8. IEEE.
Liu, L., Hua, C., Chen, C., and Guan, X. (2015). Relay Selection for Three-Stage Relaying Scheme in Clustered Wireless Networks. IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, 64(6):2398–2408.
Luo, J., Blum, R., Cimini, L., Greenstein, L., and Haimovich, A. (2005). Link-Failure
Probabilities for Practical Cooperative Relay Networks. In 2005 IEEE 61st Vehicular
Technology Conference, volume 3, pages 1489–1493. IEEE.
Valle, O. T. (2014). Codificação de Rede na Retransmissão Oportunista De Mensagens
Em Redes de Sensores Sem Fio. PhD thesis, Universidade Federal de Santa Catarina.
Wang, C.-L. and Syue, S.-J. (2009). An Efficient Relay Selection Protocol for Cooperative
Wireless Sensor Networks. In 2009 IEEE Wireless Communications and Networking
Conference, pages 1–5. IEEE.
Yick, J., Mukherjee, B., and Ghosal, D. (2008). Wireless sensor network survey. Computer Networks, 52(12):2292–2330.
21
UMA PROPOSTA DE ARQUITETURA PARA ROBÔS
COMO UM SERVIÇO (RAAS)
Edson de A. Silva1, Adilson T. da Cruz1, Gustavo L. P. da Silva1, Vandermi J. da Silva1,
Alex S. R. Pinto2, Mario A. R. Dantas2
1
2
Instituto de Ciências Exatas e Tecnologia – Universidade Federal do Amazonas
(UFAM)
Itacoatiara – AM – Brasil
Departamento de Informática e Estatística – Universidade Federal de Santa Catarina
(UFSC)
Florianópolis – SC – Brasil
{eas.inf, adilson.soft.cruz, gustavo.eng18}@gmail.com,
[email protected], {a.r.pinto, mario.dantas}@ufsc.br
Resumo. A Internet trouxe consigo uma gama de oportunidades de serviços
com inúmeras possibilidades de negócios. Juntamente com a Computação
em Nuvem (CN), o contexto de robôs como um serviço (RaaS) nasce como
oportunidade para novos nichos de mercado, podendo ser um fator de
redução de custos e serviços. Uma das vantagens na utilização da CN é
justamente a redução de custos, pois o provedor assume todo o custo com a
infraestrutura e manutenção dos equipamentos necessários ao provimento
de serviços. Para o funcionamento desse tipo de serviço é necessário que
novas arquiteturas sejam propostas para atender essa demanda de forma
satisfatória. O objetivo deste trabalho é propor uma arquitetura para o
controle remoto de um robô utilizando a internet como meio de
comunicação realizando um estudo de caso para comprovar sua efetividade.
A qualidade do serviço (QoS) de rede foi utilizada para demonstrar a
viabilidade do serviço de forma satisfatória e de forma segura. Os resultados
demonstraram que, no contexto de robôs como um serviço, a realização de
tarefas por meio de uma conexão remota pode ser viável de forma
satisfatória desde que alguns fatores sejam levados em consideração, como
a qualidade da rede.
1. Introdução
Com o advento da Internet, inúmeras possibilidades de produtos e serviços
surgiram como oportunidade de desenvolvimento tecnológico e nichos de mercado. Com
o avanço das tecnologias, novas oportunidades como o conceito de Computação em
Nuvem (CN) estão em ascensão, que segundo Yang e Huang (2012), se destina a
fornecer os recursos computacionais na aquisição via XaaS (X as a Service), onde X
pode ser qualquer coisa. Diante destes avanços, surgiu uma nova abordagem que
consiste na utilização da robótica como um serviço (RaaS – Robot as a Service). O
conceito de "robô-como-um-serviço" refere-se a robôs que podem ser combinados
dinamicamente para dar suporte à execução de aplicações específicas que segundo
(Koken, 2015) pode perfeitamente ser aplicado a policiais robôs (Wired, 2006), robôs
22
garçons para restaurante (Technovelgy, 2016), robôs animais de estimação (Aibo, 2016)
entre outras.
Uma das razões pela qual os robôs não são providos de inteligência está ligado
ao alto custo computacional e de armazenamento, pois isso afeta não só do ponto de
vista do preço do robô, mas também resulta na necessidade de espaço adicional e peso
extra, que restringem a sua mobilidade e habilidade (Tian, Chen e Fei, 2015). A CN pode
ser uma aliada no que diz respeito à redução destes custos, como por exemplo na
execução de cálculos que exigem maior poder computacional podendo ser deixados a
cargo da nuvem (Koken, 2015). Para obter todos os benefícios, é necessário criar novos
métodos de acessos e arquiteturas que beneficiem esse tipo de conexão no que diz
respeito a utilização de CN.
De acordo com (Yoshigae e Emil, 2011), comando remoto pode ser interpretado
como um processo de transmissão de dados que sejam capazes de induzir a alteração do
estado de um sistema em um local geograficamente distinto. Dentre as aplicações de
comando remoto está incluída o de robôs industriais, cuja importância se destaca pela
execução de trabalhos repetitivos ou cuja a execução torne-se uma ameaça à segurança
do operador.
Chase e Jorge (2010) afirmam que as funções relacionadas à mobilidade de um
robô móvel em seu ambiente são a navegação e a localização, que têm grande
importância no desenvolvimento de sistemas autônomos inteligentes. Essas duas
capacidades são essenciais para que o robô possa executar tarefas mais complexas no
ambiente em que atua. Yoshigae e Emil (2011) citam ainda que, a execução de um
projeto para o comando remoto de robôs mostra-se importante para a formação de
recursos humanos, bem como seu uso nas distintas áreas, seja na indústria, medicina,
controle e carregamento, onde estes são alguns exemplos de onde pode-se integrar robôs
para auxiliar nas tarefas realizadas pelo homem.
Diante do exposto e baseado nos trabalhos discutidos, o objetivo deste trabalho é
apresentar uma arquitetura demonstrando, por meio de um estudo de caso, o controle
remoto de um robô utilizando a Internet como meio de comunicação no contexto de
RaaS. Foram pré-definidas tarefas para que o usuário possa controlar o robô seguindo as
orientações e assim alcançar o objetivo. Para avaliação geral dos resultados foi adotado a
qualidade do serviço proposta por meio de métricas de avaliação de desempenho de rede
no trabalho de Silva e Alves Júnior, 2014.
O restante do trabalho está dividido na seguinte forma. Na seção 2 é apresentado
o conceito de Robot as a Service. Na seção 3 são demonstrados alguns trabalhos
relacionados ao tema proposto. Na seção 4 são apresentados detalhes da arquitetura
proposta. Com base na arquitetura, na seção 5 são discutidos a realização de um
experimento. Por fim a seção 6 apresenta as conclusões.
2. Robot as a Service
Desde a antiguidade a humanidade tende a criar soluções com objetivo de
diminuir a carga de serviço necessária a execução de tarefas cotidianas e repetitivas, as
quais podem trazer malefícios aos trabalhadores. A medida que se usa robôs em uma
ampla variedade de tarefas, o modelo de aplicações de robótica irão mudar de produto
23
para o modelo de serviço, semelhante aos serviços de utilidade pública, tais como água,
eletricidade, gás e telefonia (Du et al. 2011).
A Arquitetura Orientada a Serviço (SOA) considera um sistema de software um
conjunto de serviços de baixo acoplamento que se comunicam uns com os outros através
de interfaces padrão e através de protocolos de troca de mensagens. A CN torna possível
sair da computação baseada em desktop para o desenvolvimento baseado na Web, onde
os desenvolvedores usam uma plataforma que possibilita o desenvolvimento,
configuração de hardware / infra-estrutura (potência, capacidade de memória, largura de
banda de comunicação e processamento) e a execução da aplicação on line (Chen et al.
2010).
SOA tem sido encarado como uma abordagem adequada e eficaz para automação
industrial e de fabricação que, em última instância o usa para controlar e gerenciar as
células robóticas que são responsáveis por várias funções no processo de automação
(Borangiu, 2016; Veiga, 2007). Os benefícios da robótica em nuvem são inúmeras. Ao
aliviar as tarefas para a nuvem, seria possível construir baterias de robôs menores,
eficazes, enquanto a capacidade de memória e computação podem ser quase infinitas,
utilizando recursos da nuvem (Lorencik e Sincak, 2013).
Algumas das aplicações de RaaS citadas por (Doriya et al. 2012) são:
virtualização sobre robôs físicos; acesso a web pode ser dada para os robôs; redução do
custo de hardware robótico, pois a fabricação é mais barata, mais leve e robôs tendem a
ser "mais inteligentes"; pode ter funcionalidades como reconhecimento de objetos e de
voz por meio de serviços sob demanda; uma "base de conhecimento compartilhado"
pode ser criada para robôs e resultados e habilidades adquiridas podem ser publicadas ou
compartilhadas entre os robôs.
No entanto, quando os serviços de robôs são fornecidos através de redes de
internet, serviços confiáveis são necessários para lidar com a desconexão entre os
serviços e os robôs em redes wireless LAN, problemas de atendimento ao robô, erro de
sistema no robô, entre outros (Narita et al. 2013).
3. Trabalhos relacionados
Neste trabalho propõe-se uma arquitetura voltada ao controle de robôs para estruturar,
organizar e garantir a segurança dos dados, bem como o transporte de mensagem entre o
cliente/servidor. Para isso apresenta-se uma análise sobre algumas propostas que utilizam
o serviços de Web Service e serviços robóticos.
Kato et al. (2011), discorre sobre integração de serviços de robôs com serviços
em nuvem e sua comunicação com a Internet. Com esses recursos pode-se disponibilizar
serviços inovadores como navegação, construção de mapas, planejamento de trajetória,
localização, reconhecimento de objetos etc, combinando diferentes componentes para
finalidades heterogêneas para um mesmo cliente, já que, é determinado em Web Service.
Essas tecnologias usam o serviço de nuvem para armazenar dados, portanto pode-se
oferecer vários serviços de uma plataforma robótica. O recurso de RSi-Cloud é a
utilização de um protocolo de comunicação padrão, que é, Protocolo de Rede de
Serviços Roboticos (RSNP).
Em HU et al. (2012), os autores propõem uma arquitetura robótica em nuvem,
utilizando a combinação de robôs em nuvem formada maquina a máquina, comunicação
24
(M2M) entre todos os robôs conectados a nuvem. Utilizando-se o modelo de arquitetura
M2M para o armazenamento e utilização de recursos compartilhados, apoiando na
realização de tarefas e tomada de decisão bem como o compartilhamento de informações
para aplicações robóticas. HU et al. (2012), citam que o protocolo M2M incluem
roteamento que envolve a troca de mensagens periodicamente para que cada rota de um
destino possível na rede seja mantido. Este protocolo de encaminhamento Ad-hoc sofre
latência elevada por ter que estabelecer uma rota antes de uma mensagem ser enviada.
Este problema é significativo em redes moveis robóticas, e pode levar a uma degradação
grave do desempenho.
Nakagawa et al. (2012), aborda uma arquitetura de Protocolo de Rede de
Serviços Robóticos (RSNP) para integrar inúmeros dispositivos, inclusive serviços
robóticos. Neste quadro o mecanismo proposto é uma função de atribuição a robôs, que
descobre e atribui tarefas solicitadas por usuários finais aos robôs conectados a nuvem.
Pondera ainda que, não há nenhum mecanismo que implante serviços robóticos no
ambiente de nuvem como componentes de um serviço homogêneo. Nuvem Robótica é
uma plataforma que se move em função de robôs lado a lado, o que torna difícil a
implementação por partes de Engenheiros de Software inexperientes.
Narita et. al. (2013) cita que serviços robóticos baseados em nuvem vem se
tornando atrativo para muitos pesquisadores da área, muitos trabalhos já foram
realizados em função da temática. Narita et al. (2013), propõem um mecanismo de
integração Robotics Services Network Protocol (RSNP), como uma tecnologia de
mensagens confiável para serviços web. Adotando o WS-RM (WS-Realiable
Messaging), afim de integrar serviços de uma plataforma robótica com serviços de
Internet, propõem-se uma arquitetura baseada em nuvem para RSNP tendo em vista a
comunicação de um ponto. Desta forma, no lado cliente estipula-se um tempo limite para
ser atendido, em seguida a aplicação divide um arquivo em algumas partes, os envia ao
servidor usando mecanismos de mensagens confiáveis. Do lado do servidor, a aplicação
recebe o arquivo e o retorna em um único arquivo.
4. Modelo Proposto
O controlador do robô deve acessar a aplicação por meio de qualquer dispositvo
que tenha um browser e serviço de internet ativo. Porém o dispositvo cliente deve estar
na mesma VPN que o robô, e assim enviar os dados da aplicação para o servidor. Para
receber os dados da aplicação foi desenvolvida um interface Web conforme apresentado
na Figura 1.
25
Figure 1 – Arquitetura proposta.
As informações do dispositivo são enviadas para o servidor ao qual o robô esta
conectado, utlizando uma VPN, onde o servidor, por meio do protocolo HTTP, recebe
os dados (uma string de comandos) e as envia através do protocolo ZigBee (802.15.4)
para o robô, que os executa. Os comandos recebidos pelo robô são executados seguindo
a ordem a qual foram enviados pelo cliente da VPN. Foi necessário a utilização de um
programa em linguagem própria do Arduino para salvar os dados em um vetor de
comandos, e assim fazer com que sejam executados conforme o programa realiza a
leitura desse vetor.
5. Ambiente Experimental e Estudo de Caso
Para realização do trabalho proposto foi necessário os seguintes materiais e
métodos adotados:
1. Construção do protótipo de robô do tipo esteira;
Na construção do protótipo foi utilizado a plataforma Open Source Arduino na
versão Uno REV 3, placa XBee Shield V2, XBee Pro S2 e placa Dual Motor
Shield juntamente com a plataforma Tamya, esta última, por sua vez, fornece os
motores e base de um robô do tipo esteira. A Figura 2 apresenta o robô com
todos os componentes.
26
Figura 2 – Protótipo do robô.
2. Implementação de WebService para controle do robô;
O WebService foi implementado no Linux Ubuntu 14.10 Lts com o Lamp Server
para fornecer os serviços necessários a manipulação do robô a distância por meio
da aplicação desenvolvida na linguagem PHP conforme Figura 3. A aplicação
conta com as setas direcionais para movimentação do robô e botões para
obtenção de dados de sensores como luminosidade e temperatura.
Figure 3 – Aplicação para controle do robô.
3. Implementação de VPN para comunicação do usuário com o robô de forma
segura;
Com o intuito de proporcionar o acesso a aplicação para controle do robô, foi
necessário a criação de uma Rede VPN, pois desse modo garante-se a segurança
no tráfego das informações. A implementação da VPN foi por meio de um
serviço de rede virtual chamado LogMeIn Hamachi que conforme (Hamachi,
2016) é um serviço de rede virtual que pode ser configurado em minutos e
permite acesso remoto seguro à rede, em qualquer lugar que haja uma conexão à
Internet.
4. Avaliação dos resultados.
Para avaliação dos resultados a comunicação com o robô a rede foi monitorada
com a ferramenta IPERF que forneceu as informações de Largura de Banda,
Latência, Jitter e Perda de pacotes durante o teste.
27
5.1. Estudo de Caso
Com o intuito de validar a arquitetura proposta, utilizou-se alguns parâmetros de
rede definidos em Silva e Alves Júnior (2014), como a largura de banda, latência, perda
de pacotes e jitter. Os resultados são provenientes do controle do robô remotamente
para realização de uma tarefa previamente estabelecida que consistiu em percorrer um
labirinto, como mostra a Figura 4.
Figure 4 – Objetivo do robô.
A comunicação entre o usuário e o servidor foi realizada por meio de conexões
distintas de internet para simular uma conexão à distância. No teste foram utilizadas duas
conexões com a internet com largura de banda de 1Mbps não dedicada. Portanto durante
o teste a largura de banda média foi bem inferior ao máximo como mostra a Tabela 1.
Tabela 1. Resultados obtidos pelo IPERF
Intervalo
de Tempo
Dados
Transferidos
throughput
Largura de
Banda
Média
(TCP)
Cliente
300 seg.
10328 Kbytes
275 Kbits/sec
Servidor
300 seg.
22637 Kbytes
617 Kbits/seg
Jitter
(UDP)
16,403 ms
Datagramas
Perdidos/Tot
al (%)
(UDP)
9741/25510
(38%)
Em virtude do Jitter ser o desvio padrão do atraso de pacotes enviados em
sequência, esse dado foi computado apenas no lado do servidor por ser onde reside a
interface de comunicação com o protótipo. Da mesma forma os datagramas são
demonstrados na tabela. A arquitetura proposta considerou os controles direcionais do
robô e portanto não houve grande dificuldade na transferência, pois os pacotes de dados
transferidos são de cerca de 60 Kbytes em média.
A medida do Jitter realizada no servidor demonstrou uma variação no atraso de
entrega de 16,403 milissegundos ocasionando uma recepção não regular dos pacotes de
dados transferidos e que consequentemente culminou para o recebimento de 30
datagramas fora de ordem no teste. O tráfego de dados pode ser observado na figura 5.
28
Figura 5 – Tráfego de dados.
Do ponto de vista da qualidade de serviço da rede (QoS) a preocupação com a
perda de pacotes é normalmente no sentido de especificar e garantir limites razoáveis
(Taxas de Perdas) que permitam uma operação adequada da aplicação. Conforme
demonstrado, houve uma grande percentagem de perda de pacotes, que pode ser
creditado a má qualidade da conexão, o que provocou um atraso na resposta de alguns
comandos enviados ao robô.
6. Conclusões e Trabalhos Futuros
Os trabalhos realizados no contexto de robô como um serviço (RaaS)
demonstram uma tendência para evolução nas aplicações de RSSF e Robôs
proporcionando um novo paradigma no uso de recursos computacionais voltados para
esta tecnologia. Deste modo, a utilização destes conceitos pode trazer grandes benefícios
para sociedade como, por exemplo, a redução dos custos para implementação de robôs.
Outro exemplo de utilização deste tipo de arquitetura é a monitoração de áreas hostis, o
que torna o acesso ao local um risco a saúde.
Como pode ser observado nos resultados, para garantir um bom provimento de
serviços no controle do agente é necessária uma preocupação com a qualidade da rede
para obter um padrão aceitável no controle do mesmo. Além disso, a segurança das
informações e o controle do robô devem ser garantidos para que não violem dados
confidenciais e nem assumam o controle deste tipo de serviço indevidamente. De maneira
geral, o trabalho demonstrou que é possível provê esse tipo de serviço por meio de uma
conexão confiável e seguindo critérios de segurança para garantir ao cliente um serviço
aceitável.
29
7. Referências
Aibo. Robot Pets. Disponível em: http://en.wikipedia.org/wiki/AIBO, Acesso em
02.04.2016.
Borangiu, T., “Trends in Service Oriented Architectures for Robot-CNC Manufacturing
Control”, Disponível em: http://www.iit.bas.bg/PECR/59/10-31.pdf. Acesso em
03.04.2016.
Chase, Otavio A., Jorge, R. Brito de Souza. “Desenvolvimento de um Robo Movel NãoHomologo Para Navegacao Autonoma Em Ambientes Fechados Por WallFollowing”. Anais CBA – Congresso Brasileiro de Automação – 2010. Pages: 38333838.
Chen, Yinong; Du, Zhihui; Acosta, Marcos García. (2010) Robot as a Service in Cloud
Computing. Fifth IEEE International Symposium on Service Oriented System
Engineering.
Dias, Maxwel Macedo, Ramos, Edson M.L.S., Silva Filho, Luiz, Betini, Roberto C.
(2008) A Utilização de Software Livre na Análise de QoS em Redes IP Utilizando
Mineração de Dados, http://wsl.softwarelivre.org/2008/0001/37623_1.pdf
Doriya, Rajesh; Chakraborty, Pavan; Nandi, G. C. (2012) Robotic Services in Cloud
Computing Paradigm. International Symposium on Cloud and Services Computing.
IEEE.
Du, Zhihui; Yang, Weiqiang; Chen, Yinong; Sun, Xin; Wang, Xiaoying; Xu, Chen.
(2011) Design of a Robot Cloud Center. Tenth International Symposium on
Autonomous Decentralized Systems. IEEE.
Hu, Guoqiang. Peng, Wee Tay. Wen, Yonggang. “Cloud Robotics: Architecture,
Challenges and Applications”. Network, IEEE (Volume: 26, Issue: 3), May -June
2012. IEE, pp. 21 – 28.
Kato, Yuka. Izui, Toru. Tsuchiya, Yosuke. Masahiko, Narita. (2011). “RSi-Cloud for
Integrating Robot Services with Internet Services”. IECON 2011 - 37th Annual
Conference on IEEE Industrial Electronics Society. IEE, pages 2158 - 2163.
Koken, Busra. (2015) Cloud Robotics Platforms. Interdisciplinary Description of
Complex Systems, pág. 26-33, Yalova University.
Lorencik, D.; Sincak, P., (2013) Cloud Robotics: Current trends and possible use as a
service, in 11th IEEE International Symposium on Applied Machine Intelligence and
Informatics, Herlany, Slovakia, February.
Nakagawa. Sachiko, Igarashi. Noboru, Tsuchiya. Yosuke, Narita. Masahiko, Kato.
Yuka. “An Implementation of a Distributed Service Framework for Cloud-based
Robot Services”. IECON 2012 - 38th Annual Conference on IEEE Industrial
Electronics Society. IEEE, pages 4148 – 4153.
Narita, Masahiko. Okabe, Sen. Kato, Yuka. Murakwa, Yoshihiko. Okabayashi, Keiju.
Kanda, Shinji. “Reliable cloud-based robot services”. Industrial Electronics Society,
IECON 2013 - 39th Annual Conference of the IEEE, IEEE, pages 8317 – 8322.
30
Silva, Pedro H. D. da. Alves Júnior, Nilton. (2014) Ferramenta IPERF: geração e
medição de Tráfego TCP e UDP. Centro Brasileiro de Pesquisas Físicas. Nota
Técnica
Tas, Baris; Tosun, Ali Şaman. (2014) Coordinating Robots for Connectivity in Wireless
Sensor Networks. 11th International Conference on Mobile Ad Hoc and Sensor
Systems, IEEE.
Technovelgy. Robot Waiters. Disponível em: http://www.technovelgy.com/ct/ScienceFiction-News.asp?NewsNum=771, Acesso em 02.04.2016
Tian, Guohui Chen, Huanzhao. Lu, Fei. (2015) Cloud Computing Platform Based on
Intelligent Space for Service Robot. International Conference on Information and
Automation. IEEE.
Veiga, G., Pires, J.N., Nilsson, K., "On the use of SOA platforms for industrial robotic
cells", Proceedings of Intelligent Manufacturing Systems, IMS2007, Alicante, Spain,
June 2007, pp. 3-8.
Wired.
Robot
Cops
to
Patrol
Korean
Streets.
Disponível
em:
http://www.wired.com/gadgetlab/2006/01/robot_cops_to_p, Acesso em 02.04.2016.
Yang, Chih-Chin. Huang, J. T. (2012) The Era of Cloud Computer thru Bio-Detecting
and Open-Resources to Achieve the Ubiquitous Devices. International Symposium on
Computer, Consumer and Control.
Yoshigae, Nako Emil. Villani, Emilia. “Comando Remoto de Robôs Industriais”. Anais
do 14° Encontro de Iniciação Científica e Pós-Graduação do ITA – XIV ENCITA /
2008.
31
Avaliação de desempenho de procedimentos de
handoff em redes IPv6 e uma discussão sobre a
viabilidade de aplicação em sistemas crı́ticos
Lucas Tognoli Munhoz, Guilherme Caixeta de Oliveira,
Daniel Fernando Pigatto, Kalinka Regina Lucas Jaquie Castelo Branco
1
Instituto de Ciências Matemáticas e de Computação (ICMC) –
Universidade de São Paulo (USP)
Avenida Trabalhador São-carlense, 400 – Centro –
CEP: 13566-590 – São Carlos – SP – Brazil
{lucas.munhoz, guilherme.caixeta.oliveira}@usp.br
{pigatto, kalinka}@icmc.usp.br
Resumo. Em sistemas de tempo real, quando falhas de qualquer natureza
ocorrem, ativos de alto valor são colocados em risco e, em alguns casos, até
mesmo vidas humanas. Devido a essa alta criticidade, desenvolver melhorias para estes sistemas visando o aumento da segurança dos mesmos
se torna um tópico de importância na área. Esta pesquisa busca efetuar
uma revisão sobre procedimentos de handoff em redes IPv6 para auxiliar na
identificação daqueles que apresentam menor latência e baixa perda de pacotes durante a operação, visando um aumento da eficácia da comunicação
geral nestes sistemas. Para isso, algumas técnicas de handoff encontradas
na literatura são simuladas e, a partir dos resultados obtidos, comparações
de desempenho são apresentadas seguindo técnicas estatı́sticas especı́ficas
para avaliação de desempenho de sistemas computacionais. Por fim, uma
discussão sobre a aplicação destas técnicas em sistemas embarcados crı́ticos
é apresentada.
1. Introdução
Estudar o processo do handoff é de suma importância para todas as aplicações que
fazem uso de redes móveis (wireless), visto que é um ponto crı́tico em relação à
qualidade da conexão, seja pelo fato do algoritmo de handoff tomar a decisão de
permutar para uma rede de melhor qualidade ou mesmo a possibilidade da perda
de pacotes durante essa transição, fator essencial em aplicações crı́ticas. O objetivo
deste artigo é apresentar uma comparação entre dois algoritmos de handoff, mais
especificamente o procedimento de handoff no protocolo IPv6, com e sem a opção
de mobilidade.
Esta pesquisa contribui no cenário dos sistemas embarcados que utilizam o
IPv6 para se conectar em redes móveis, fornecendo dados e comparações que podem
ser utilizadas por profissionais da área. Foram analisados aspectos como tempo de
execução em cada etapa do processo e fatores que influenciam na tomada de decisão
do algoritmo, como potência de sinal e taxa de transmissão de dados.
32
O restante do artigo está organizado da seguinte maneira: a Seção 2 discute
os trabalhos relacionados usados como referências para essa pesquisa; a Seção 3
apresenta o MIPv6; já a Seção 4 descreve a metodologia de testes; a Seção 5 apresenta
as simulações realizadas; a Seção 6 mostra os resultados dos experimentos; a Seção 7
apresenta uma discussão voltada aos sistemas crı́ticos; e, por fim, a Seção 8 conclui
o trabalho.
[Mishra et al. 2003] publicaram um artigo em que efetua-se uma medição das latências de todos os estágios em um processo de handoff. Eles concluı́ram que o hardware usado (interface wireless), tanto na Unidade Móvel (UM) quanto nos Pontos
de Acesso (APs), influencia diretamente no tempo de latência do handoff, que diferentes UMs tratam a sequência de mensagens do processo de maneira ligeiramente
diferente e que a fase de busca toma cerca de 90% do tempo de handoff. No entanto, os autores não exploraram situações reais, o que, mesmo quanto simulado,
altera a percepção se contextualizada em determinados domı́nios. Neste artigo serão
discutidos os impactos do handoff em redes IPv6 quando observado no contexto de
VANTs.
[Vatn 2003] discutem os efeitos do handoff na transmissão de dados e, assim
como Mishra et al., concluem que a interface de rede utilizada afeta na latência
e a fase mais demorada do processo é a de busca. Eles também observam que é
possı́vel que a UM continue recebendo dados do AP antigo mesmo durante a fase de
busca. Por fim, concluem que o comportamento do handoff não depende somente
do hardware utilizado, mas também do fluxo de dados, como por exemplo, se a UM
está enviando ou apenas recebendo pacotes.
[Chuang and Lee 2011] discutem os problemas de latência apresentados pelo
Mobile IPv6 e pelo seu derivado PMIPv6, deixando clara a dificuldade de uso destes
mecanismos de handoff em sistemas de tempo real. Para solucionar este problema,
os autores propõem um novo esquema de handoff para redes PMIPv6 que reduz
a latência da operação e resolve o problema da perda. Este trabalho foi útil para
uma análise mais profunda do MIPv6 e observação de suas nuances para possı́vel
aplicação no contexto deste artigo.
Inspirando-se nos estudos apresentados nos trabalhos revisados, identificouse que uma comparação entre o protocolo IPv6 com e sem a opção de mobilidade no
contexto dos veı́culos aéreos não tripulados (VANTs) ainda não havia sido verificada.
Este trabalho apresentará um estudo neste sentido, tentando identificar diferenças
substanciais no protocolo. A seção ?? apresenta a ferramenta de simulação de redes
OMNeT++, a qual será utilizada nos experimentos.
3. MIPv6
Segundo [Duarte ], o MIPv6 (Mobile IPv6) é um protocolo que foi desenvolvido como
um subconjunto do Internet Protocol version 6 (IPv6) para dar suporte a conexões
móveis. MIPv6 é um update do padrão Mobile IP (RFC 6275, [Johnson et al. 2004]),
criado pela IETF, e foi desenvolvido para autenticar dispositivos móveis (conhecidos
como nós móveis) usando endereços IPv6.
33
Nos roteamentos tradicionais da rede IP, os endereços representam uma
topologia. Os mecanismos de roteamento foram feitos sob o princı́pio que cada
nó da rede sempre teria o mesmo ponto de entrada na Internet, e que cada nó de
endereço IP identificaria o enlace de rede onde ele está conectado. O MIPv6 permite
um nó móvel transparentemente manter as conexões quando ele move de um ponto
da rede a outro.
4. Metodologia
Como já mencionado anteriormente, duas simulações foram usadas para comparação
de dois processos distintos de handoff, sendo eles em redes IPv6 com e sem opção de
mobilidade. As próximas subseções descrevem os critérios utilizados e como foram
realizadas as coletas dos resultados.
4.1. Critérios e Coleta dos Resultados
A primeira preocupação com as simulações foi em manter a uniformidade entre
elas. Por exemplo, a velocidade com que a unidade móvel se moveria e a distância e
área de cobertura dos roteadores deveria ser a mesma na duas simulações, visando
o não comprometimento de qualquer resultado que poderia ser obtido. Os critério
utilizados como comparação entre os algoritmos são os seguintes: tempo do processo
e potência do sinal.
4.1.1. Tempo
O critério do tempo de execução é, talvez, o mais complexo e que melhor define a
diferença entre os processos. Para alguns algoritmos, é de extrema importância que
um processo de handoff se dê o mais rápido possı́vel, devido ao fato da unidade
móvel se desconectar do ponto de acesso para então enviar solicitações ao próximo
ponto de acesso. Segundo [da Silva and Colcher 2007], esse tempo desconectado de
qualquer link resulta em uma perda de pacotes de poderiam estar em tráfego naquele
instante. Por exemplo, se um transmissão de vı́deo em tempo real estava sendo feita
naquele momento, com certeza pacotes se perderão e isso acarretará problemas.
De acordo com [Nankani 2005] na Figura 1, o processo de handoff pode ser
dividido em 2 fases. Para uma análise mais profunda, será medido o tempo de cada
etapa separadamente, possibilitando uma comparação por fases do processo.
A primeira fase é a de busca. A fase de busca começa pela pesquisa de
APs próximos e disponı́veis. Depois de encontrados, o AP em melhores condições,
definidas de acordo com os critérios do próprio algoritmo em questão, é escolhido
para o MN realizar a conexão.
Uma subdivisão da fase de busca pode ser feita em duas etapas: delay de
escaneamento e delay de classificação. Ainda no delay de escaneamento, podem ser
medidos os tempos de escaneamento de cada canal, separadamente.
Em termos práticos, o evento inicial da fase de busca é o Beacon Timeout, ou
seja, o MN recebeu pelo menos três pacotes Beacon que foram considerados como
34
Figura 1. Fases do processo de handoff, adaptado de [Nankani 2005].
ruı́do (não havia potência satisfatória) e decidiu iniciar uma busca por novos pontos
de acesso por considerar conexão perdida. No próximo evento, o MN se desassocia
do AP1 e manda comando interno para sintonização do canal 0, para começar nova
busca. O delay de escaneamento termina no evento em que o rádio do MN acaba
de sintonizar no canal 0 e começará a busca efetiva.
O próximo passo é escanear cada canal em busca de um ponto de acesso. Esse
escaneamento se dá da seguinte maneira: o MN sintoniza em um certo canal e fica
”na escuta” por mensagens vindas de algum ponto de acesso naquela frequência, seja
um Beacon ou um Router Advertisement. Essa escuta dura um perı́odo de tempo
pré-estabelecido. Ao fim desse tempo, o MN sabe se há algum ponto de acesso
naquela frequência e pode incluı́-lo na lista de candidatos a novo AP. Quando um
canal foi escaneado e nenhuma mensagem foi detectada. O rádio avisa a camada de
gerenciamento que o tempo limite estourou e nenhum AP foi encontrado. É também
enviado a ordem para a troca de canal.
Passado o tempo mı́nimo de escaneamento e tendo identificado outro aparelho
na mesma frequência, o MN envia uma mensagem de Probe Request, solicitando
informações relacionadas ao tipo de transmissão em que o AP trabalha, como por
exemplo a taxa de transmissão. O AP, então, responde com o Probe Response. Com
posse desse pacote, o MN atualiza a lista de AP conhecidos e continua o processo de
escaneamento. Esse processo se repete por todos os 4 canais possı́veis. Ao acabar
o último canal, finaliza-se o delay de escaneamento. Para efeitos de pesquisa e
comparação, serão medidos os tempos de busca em cada canal, além da fase inicial
do escaneamento.
A última etapa da fase de Busca é o delay de classificação, no qual o MN
classifica todas os AP que foram encontrados na busca. Nessa fase ocorre o mesmo
problema da falta de informações do simulador. Apesar de ele tratar esses eventos
como instantâneos e concomitantes, eles não o são na realidade. Dessa forma, o
35
Delay de Classificação também ficou sem ser mensurado e, conforme explicado na
Seção Resultados, não implica em problemas para os resultados obtidos.
A próxima fase de um processo de handoff é a Fase de Execução. Nesse
perı́odo, o MN troca mensagens com o AP no intuito de se associar a ele. Algumas
dessas mensagens são a requisição de autenticação, resposta à essa requisição,
requisição e resposta de associação.
4.1.2. Tomada de Decisão
A potência do sinal recebido de um AP é um dos fatores decisivos em um processo
de handoff. É necessário que, ao tomar a decisão de qual ponto de acesso o nó
móvel vai se conectar, haja uma ponderação sobre o melhor sinal, que pode evitar,
na maioria dos casos, novos handoffs.
Alterar a polı́tica de tomada de decisão pode ser uma tarefa complicada, visto
que nem sempre é possı́vel obter acesso aos códigos que implementam o processo
direto em sistemas operacionais de tempo real. No simulador utilizado o problema
se repete e não é possı́vel alterar a polı́tica de tomada de decisão. Foram propostos,
então, alguns testes para verificar a influência de alguns fatores na tomada de decisão
do algoritmo que roda por trás do OMNeT++.
Para analisar sob esta outra perspectiva, foi proposto um novo cenário: incluir um novo AP à simulação “handoff ipv6”. Com isso, seria criada uma zona na
abrangência de sinal de três pontos diferentes e, alterando parâmetros de um dos
APs, seria possı́vel tirar conclusões de qual aspecto foi levado em consideração na
decisão.
Os dois aspectos propostos para essa pesquisa são Potência de Sinal e Taxa
de Transferência de dados. Basicamente, os três roteadores ficaram posicionados em
uma geometria triangular, com as mesmas distâncias entre os três, de acordo com a
Figura 2. Em cada teste, um AP teve seus parâmetros modificados, de uma maneira
que um dos seus recursos fosse menor do que o mesmo recurso do outro AP. Por
exemplo, se a taxa de transferência do AP2 é 2 Mbps, a do AP1 foi definida em 1
Mbps, da mesma forma que a sua potência de transmissão reduzida em um outro
teste. Os seguintes cenários foram propostos (ver Tabela 6.1):
1. AP1: 1 Mbps, 2 mW e AP2: 2 Mbps e 2 mW;
2. AP1: 2 Mbps, 2 mW e AP2: 2 Mbps e 1 mW;
Definidos os modelos e a forma como os testes seriam executados, o próximo
passo foi a execução das simulações e a coleta dos resultados, expostos no próximo
capı́tulo.
5. Simulações
5.1. MIPv6Network.ned
A rede MIPv6Network é parte do pacote de simulações-exemplo do pacote INET, ou
seja, ela vem configurada ao se instalar o pacote [INET ]. Essa simulação permite
36
Figura 2. Esquema de rede utilizado para testar a Tomada de Decisão do algoritmo
de handoff.
a análise de um processo de handoff em uma rede que se comunica por meio do
protocolo IPv6 com a opção de mobilidade, ou seja, ao trocar de link de acesso, o
nó móvel continua com o mesmo endereço IP.
A MIPv6Network é composta por 5 elementos básicos: nó móvel, pontos de
acesso, roteadores, HUB e hospedeiro fixo. Além deles, há dois elementos responsáveis pela configuração. Na Figura 3 é ilustrado o arquivo NED na forma gráfica.
Figura 3. Representação gráfica da rede MIPv6Network.
O Mobile Node é composto pelo módulo WirelessHost6. Ele faz o papel do
nó móvel, sempre conectado a um ponto de acesso e se movimentará entre as áreas
de cobertura desses APs. Os dois Access Points usados na simulação são iguais,
do módulo de mesmo nome. Eles são responsáveis por fornecer o rádio para os
roteadores, ou seja, prover uma comunicação sem fio entre nó móvel e nó fixo.
O primeiro roteador, módulo Router6, atuará como Home Agent. Como dito
anteriormente, tem a função de capturar os pacotes destinados a unidade móvel,
estando ela conectada a esse link ou não. O roteador denominado R 1 fará o papel
de Foreign Agent, ou seja, distribui os pacotes gerados pelo MN enquanto fora do link
inicial e atua recebendo os pacotes do túnel destinados ao MN. E o outro roteador,
juntamente com o HUB, faz o papel da internet em si, propiciando, por exemplo, o
túnel entre os dois roteadores que fornecem links.
37
5.2. handoff ipv6.ned
A simulação handoff ipv6.ned foi completamente desenvolvida pelo bolsista com o
intuito de atender aos requisitos da pesquisa, que pediam uma rede que usasse IPv6
e possibilitasse o estudo do handoff, sem a opção de IP Móvel. Sem o suporte à
mobilidade, ao trocar de link, a unidade móvel perde totalmente seu vı́nculo com o
endereço nativo, trocando inclusive de IP.
Na Figura 4 é ilustrada graficamente a simulação. Como é possı́vel observar,
a rede é formada por uma unidade móvel do tipo WirelessHost6 que, apesar de
oferecer suporte ao MIPv6, está com essa funcionalidade desabilitada.
Figura 4. Representação gráfica da rede handoff ipv6.
Assim como na rede MIPv6Network, são utilizados dois AccessPoints para
a comunicação sem fio dos roteadores. São dois roteadores independentes e que
fornecem links separados aos usuários. Essa é uma das formas de reforçar o não uso
da opção de mobilidade.
Além dos elementos da rede em si, foram utilizados outros dois módulos de
configuração: o ChannelControl, responsável pelo gerenciamento das comunicações
sem fio, incluindo distâncias e possı́veis interferências, e o flatNetworkConfigurator6,
que gerencia questões de endereços e tabelas de roteamento.
6. Resultados
6.1. Tempo
Como já citado na seção “Metodologia”, o tempo que o nó móvel leva para interpretar
3 perdas de Beacon e resolve iniciar uma nova busca não pode ser calculado com
o simulador. Dessa maneira, ele será desprezado para efeitos de comparação, uma
vez que, como também explicado anteriormente, isso não afeta a integridade dos
resultados.
A Tabela 1 mostra os tempos medidos para o escaneamento total dos canais
de frequência no processo de handoff nas duas simulações testadas. Os tempos para
cada canal não aparecem na tabela por serem tempos pré-estabelecidos.
O fator que se mostrou mais decisivo no tempo efetivo do processo foi a
quantidade de escaneamentos que o MN teve de realizar antes de encontrar um AP
38
Tempo Total de Escaneamento
1a Repetição
handoff ipv6
MIPv6Network
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
1
2
3
4
1
2
3
4
1
1
2
6
1
1
2
6
s
s
s
s
s
s
s
s
400
400
650
400
400
400
650
400
2a Repetição
ms
ms
ms
ms
ms
ms
ms
ms
1
1
2
6
1
1
2
6
s
s
s
s
s
s
s
s
400
400
650
400
400
400
650
400
ms
ms
ms
ms
ms
ms
ms
ms
Média
1
1
2
6
1
1
2
6
s
s
s
s
s
s
s
s
400
400
650
400
400
400
650
400
ms
ms
ms
ms
ms
ms
ms
ms
Número de
Escaneamentos
1 escaneamento
1 escaneamento
2 escaneamentos
5 escaneamentos
1 escaneamento
1 escaneamento
2 escaneamentos
5 escaneamentos
Tabela 1. Tempo de escaneamento total para os 8 cenários testados.
disponı́vel. Essa diferença é notada nos cenários em que não há intersecção entre
as áreas de cobertura de sinal (Cenários 1 e 2) em relação aos que não o possuem
(Cenários 2 e 3). No caso de não haver intersecção, ao perder o sinal do primeiro
AP o MN inicia uma busca em todos os canais e, se esse espaço de tempo não foi
suficiente para entrar na célula do outro AP, o MN terá que realizar outras buscas
completas até que o faça. Repetir essas buscas é um processo extremamente custoso
e que compromete a eficiência do handoff, pois cada busca adicional leva 1,25 s.
Em um cenário de altas taxas de transmissão, por exemplo em um streamming, sofrer essa penalidade de uma nova busca pode comprometer totalmente o
serviço, pois seriam mais 1,25 s desconectados do AP, com a perda de milhares de
pacotes de informação.
Ainda em relação à Tabela 1, pode-se observar que a velocidade de deslocamento de um nó móvel influencia diretamente no tempo de handoff de uma situação
em que não há intersecção de células. Como o MN consegue passar mais rápido
pela área sem sinal, ele precisa realizar menos escaneamentos e, consequentemente,
se conectar mais rápido ao novo AP.
Na segunda fase do processo de handoff é realizada a autenticação e associação do MN com o AP. Os tempos do Delay de Autenticação são mostrados na
Tabela II e os do Delay de Associação estão na Tabela III.
handoff ipv6
MIPv6Network
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
1
2
3
4
1
2
3
4
1a Repetição
2 ms 375 us 943 ns
2 ms 376 us 59 ns
2 ms 376 us 188 ns
2 ms 403 us 214 ns
2 ms 349 us 88 ns
2 ms 403 us 226 ns
2 ms 402 us 582 ns
2 ms 402 us 609 ns
Autenticação
2a Repetição
2 s 375 us 943 ns
2 ms 376 us 59 ns
2 ms 376 us 188 ns
2 ms 403 us 214 ns
2 ms 349 us 88 ns
2 ms 403 us 226 ns
2 ms 402 us 582 ns
2 ms 402 us 609 ns
Média
2 ms 375 us 943 ns
2 ms 376 us 59 ns
2 ms 376 us 188 ns
2 ms 403 us 214 ns
2 ms 349 us 88 ns
2 ms 403 us 226 ns
2 ms 402 us 582 ns
2 ms 402 us 609 ns
Tabela 2. Tempos dos Delays de Autenticação para os 8 cenários testados.
A outra fase do handoff que exerce influência sobre o tempo total é o processo de Autenticação/Associação. No caso da Autenticação, nota-se uma diferença
na casa de microssegundos entre todos os cenários testados. Em dois cenários o
protocolo IPv6 sem opção de mobilidade levou vantagem sobre o MIPv6, cenários 2
e 3, e houve vantagem do MIPv6 nos outros dois. Essas combinações de resultados
não permitem uma afirmação concreta sobre a influência da velocidade ou da área
de cobertura do sinal sobre os resultados, visto que em cada situação um algoritmo
diferente levou vantagem. Na fase de Associação o MIPv6 levou vantagem em três
cenários, perdendo apenas no caso da velocidade de deslocamento baixa e sem intersecção das células. Esse resultado indica que algum mecanismo do MIPv6 pode
facilitar a Associação do MN.
Por fim, a Tabela IV ilustra os tempos totais do processo de handoff em
39
handoff ipv6
MIPv6Network
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
1
2
3
4
1
2
3
4
1a Repetição
1 ms 523 us 971 ns
1 ms 506 us 29 ns
1 ms 497 us 94 ns
1 ms 507 us 70 ns
1 ms 479 us 44 ns
1 ms 497 us 113 ns
1 ms 496 us 805 ns
1 ms 523 us 387 ns
Associação
2a Repetição
1 ms 523 us 971 ns
1 ms 506 us 29 ns
1 ms 497 us 94 ns
1 ms 507 us 70 ns
1 ms 479 us 44 ns
1 ms 497 us 113 ns
1 ms 496 us 805 ns
1 ms 523 us 387 ns
Média
1 ms 523 us 971 ns
1 ms 506 us 29 ns
1 ms 497 us 94 ns
1 ms 497 us 94 ns
1 ms 479 us 44 ns
1 ms 497 us 113 ns
1 ms 496 us 805 ns
1 ms 523 us 387 ns
Tabela 3. Tempos dos Delays de Associação para os 8 cenários testados.
todos os oito cenários testados.
handoff ipv6
MIPv6Network
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
Cenário
1
2
3
4
1
2
3
4
Tempo Total do Handoff
(média)
1 s 403 ms 899 us 971 ns
1 s 403 ms 882 us 88 ns
2 s 653 ms 873 us 282 ns
6 s 403 ms 910 us 278 ns
1 s 403 ms 828 us 132 ns
1 s 403 ms 900 us 339 ns
2 s 653 ms 899 us 207 ns
6 s 403 ms 925 us 996 ns
Tabela 4. Tempos totais do processo de handoff para os 8 cenários testados.
Analisando a Tabela IV, tem-se um panorama geral sobre os tempos efetivos
de handoff em todos os casos testados. Pode-se observar a predominância do tempo
de escaneamento em relação aos Delays de Autenticação e Associação, que pode
chegar a ser entre 300 e 2000 vezes maior. É válido ressaltar a vantagem do IPv6
sem mobilidade em três dos cenários, o que o qualifica como mais rápido.
Poucos microssegundos, menos de 100 em todos os casos, não são capazes
de afetar de maneira considerável a quantidade de bits recebidos. Por exemplo, em
uma transmissão de 2 Mbps, são enviados cerca de 2 bits por milisegundo (ms), ou
0,002 bit por microsegundo (µs). Diferenças de 100 µs resultariam na perda de 0,2
bit, o que é irrisório em vista da quantidade de informação transmitida.
6.2. Tomada de Decisão
No primeiro cenário analisado para teste de tomada de decisão, os dois APs foram
configurados para emitir sinais com a mesma potência, mas o AP1 estava com metade
da taxa de transmissão de dados do AP2. Ao fim do escaneamento, o algoritmo de
handoff optou por se conectar ao AP1, conforme mostra a Figura 5.
Figura 5. Fase de Classificação do processo de handoff no Cenário 1.
O outro cenário analisado continha os dois pontos de acesso com a mesma
taxa de transmissão de dados, porém um deles emitia uma potência de sinal muito
menor que o outro. O algoritmo optou por se associar ao AP1, como indica a
Figura 6.
40
Figura 6. Fase de Classificação do processo de handoff no Cenário 2.
Em relação aos testes sobre Tomada de Decisão, a principal conclusão tirada
é que o fator predominante na escolha de um AP para se conectar é a potência
de sinal recebida pelo MN no momento do escaneamento. No teste realizado no
Cenário 1, em que os dois APs possuem a mesma potência de sinal e o AP1 metade
da taxa de transferência do AP2, o AP1 foi escolhido. Isso pode ser explicado pela
dificuldade em se obter simetria total para o problema: por mais que os AP estejam
igualmente distribuı́dos, ao receber o pacote com a informação sobre a potência de
sinal de cada AP, o MN já se deslocou, o que resulta em pequenas diferenças, como
na Figura 5. A predominância da qualidade de sinal explica o motivo do AP1 ter
sido escolhido, apesar da baixa taxa de transmissão.
O experimento no segundo cenário apenas confirma a conclusão citada acima.
Em diferenças grandes de potência de sinal, o AP escolhido foi sempre aquele que
oferece um sinal de maior qualidade.
É importante esclarecer que os testes realizados para observar tomada de
decisão foram realizados em apenas um dos protocolos citados nesse trabalho, o
MIPv6. Essa escolha foi feita devido ao algoritmo de tomada de decisão ser vinculado
ao simulador em si, e não aos protocolos usados. Dessa forma, para qualquer handoff,
em qualquer simulação do OMNeT++, o algoritmo de tomada de decisão será o
mesmo. O propósito destes testes foi conhecer esse algoritmo, para complementar
o estudo sobre o procedimento de handoff, e também para obter conclusões que
tangenciam os estudos em VANTs, os quais serão apresentados na seção 8.
7. Uma discussão voltada aos sistemas crı́ticos
Como foi possı́vel perceber com os resultados apresentados e discutidos, há uma
pequena vantagem do IPv6 sem mobilidade quando comparado ao MPIv6, especificamente no que se refere ao tempo de execução do handoff. Considerando o cenário
dos sistemas de tempo real, essa pequena diferença, apesar de parecer insignificante,
é de grande relevância. Em algumas aplicações, como na aviação, sistemas embarcados crı́ticos devem apresentar taxas de falha baixas como uma falha grave a cada 105
até 109 horas de operação [Branco 2012]. Considerando que atrasos na comunicação
possam levar a falhas, tal diferença se torna significante.
Tomando como exemplo cenários onde veı́culos terrestres ou aquáticos operam missões em áreas isoladas e VANTs são usados para sobrevoar e coletar/fornecer informações para as redes de veı́culos terrestres e aquáticos em operação.
Os sobrevoos nem sempre poderão ser realizados mais de uma vez dependendo das
condições de acesso ao local e, em alguns casos, a autonomia de voo dos VANTs
41
pode ser um limitador de tempo, exigindo que o sobrevoo seja realizado com velocidades maiores e sem a possibilidade de sobrevoar novamente uma mesma região.
Neste caso, o tempo de handoff existente na conexão entre os veı́culos terrestres
e aquáticos com o VANT poderá impactar significativamente no sistema como um
todo.
8. Conclusões
Nesta pesquisa foi realizado um estudo comparativo entre dois processos de handoff
baseados no protocolo IPv6, com e sem a opção de mobilidade (MIPv6). Alguns
parâmetros, como tempo de execução e tomada de decisão, foram levados em conta
para análise de desempenho das simulações propostas.
Os resultados mostram uma leve vantagem do IPv6 sem mobilidade em relação ao MPIv6 no que se refere ao tempo de execução do handoff. Considerando
o cenários dos sistemas de tempo real, essa pequena diferença, apesar de parecer
insignificante, é extremamente relevante, como discutido na seção 7.
Apesar de os testes terem sido realizados em um simulador totalmente determinı́stico e o algoritmo de tomada de decisão ser o mesmo em ambos os modelos
testados, esta pesquisa apresentou resultados que ajudam pesquisadores e desenvolvedores a terem um ideia do comportamento de sistemas embarcados que utilizam
o protocolo IPv6 frente a uma situação de handoff.
Trabalhos futuros deverão incluir experimentos com protótipos reais de sistemas embarcados crı́ticos rodando sistemas operacionais de tempo real. O uso de
sistemas operacionais voltados às necessidades destes sistemas deverão melhorar o
desempenho também da comunicação.
References
Branco, K. R. L. J. C. (2012). Contribuições na área de Sistemas Distribuı́dos e
Redes de Computadores e suas aplicações em Sistemas Embarcados Crı́ticos. PhD
thesis, Universidade de São Paulo.
Chuang, M.-C. and Lee, J.-F. (2011). Fh-pmipv6: a fast handoff scheme in proxy
mobile ipv6 networks. In Consumer Electronics, Communications and Networks
(CECNet), 2011 International Conference on, pages 1297–1300. IEEE.
da Silva, A. O. and Colcher, S. (2007). Evolução da otimização do handoff no mobile
ip. Monografia, Pontifı́cia Universidade Católica, Departamento de Informática.
Duarte, O. C. M. B. Notas de aula - Redes de Computadores I - MIPv6. Available
at http: // www. gta. ufrj. br/ grad/ 02_ 2/ MIPv6/ .
INET. Network MIPv6 Documentation. Available at http: // inet. omnetpp.
org/ doc/ INET/ neddoc/ index. html? p= inet. examples. mobileipv6.
mIPv6Network. html .
Johnson, D., Perkins, C., and Arkko, J. (2004). Mobility support in ipv6. Technical
report.
42
Mishra, A., Shin, M., and Arbaugh, W. (2003). An empirical analysis of the ieee
802.11 mac layer handoff process. ACM SIGCOMM Computer Communication
Review, 33(2):93–102.
Nankani, A. (2005). Horizontal Handoffs within WLANs. PhD thesis, Master Thesis,
Department of Microelectronics and Information Technology, Royal Institute of
Technology (KTH) Sweden ftp://ftp. it. kth. se/Reports/DEGREE-PROJECTREPORTS/28 August.
Vatn, J.-O. (2003). An experimental study of ieee 802.11 b handover performance
and its effect on voice traffic. Technical report, Citeseer.
43
WoCCES 2016
44
45
Análise de Metodologias de Implementação e Desempenho
em FPGA dos Algoritmos Criptográficos Leves Simon e
Speck
Claudio Roberto Costa1, Fábio Dacêncio Pereira2, Edward David Moreno3,
Fernanda Mayumi Ohnuma Tachibana4
Centro Universitário Eurípides de Marília (UNIVEM) - Computing and Information
Systems Research Lab (COMPSI) - Marília-SP, Brasil1,2,4, Universidade Federal de
Sergipe (UFS) - Departamento de Computação (DCOMP) - Aracaju-SE, Brasil3
[email protected], [email protected],
[email protected], [email protected]
Abstract. This work consists of research, implementation and comparison of
two algorithms of lightweight block ciphers Simon and Speck regarding the area
and performance when projected on FPGA. Were adopted different
architectures for these algorithms, in a first implementation is considered the
smallest area, the second has a higher frequency and the third has a lower
frequency. At the end is generated a relation throughput/area to assess the best
cost benefit among architectures.
Resumo. Este trabalho consiste na pesquisa, implementação e a comparação
de dois algoritmos de criptografia de cifras de blocos leves Simon e Speck em
relação a área e desempenho quando projetados em FPGA. Foram adotadas
diferentes arquiteturas para estes algoritmos, sendo que em uma primeira
implementação é considerada a menor área, segunda possui maior frequência
e a terceira possui menor frequência. Ao final é gerada uma relação vazão/área
para avaliar o melhor custo benefício entre as arquiteturas.
1. Introdução
A quantidade de informações que estão em transmissão ou armazenadas em sistemas
computacionais é significantemente crescente. Técnicas de segurança como a
criptografia, assegura alguns serviços de proteção sobre essas informações, como:
confidencialidade, integridade e autenticidade. [Menezes, Oorschot and Scott 1996]
No entanto existem vários algoritmos de criptografia, com graus de complexidade
diferente e exigências distintas relacionado ao esforço computacional. Sendo assim, como
adotar o método mais adequado para proteger as informações?
Para isso é usual separar as informações de dados, onde as informações são
definidas como objetos, contendo valor ou significado para que sejam protegidas, assim,
os demais objetos não necessitam de um grau de proteção por meio da criptografia.
Atualmente as informações são classificadas conforme os critérios de cada
organização ou pessoa. O tipo de serviço de proteção mais utilizado para a segurança
desses dados é a confidencialidade, resultando em um esquema de classificação por níveis
críticos de proteção sendo elas: informação confidencial, restrita, uso interno e pública.
[ISSO/IEC 27001 2005]
46
No esquema de classificação acima, apenas uma parte do conteúdo digital são
classificados como informações e são protegidas por algoritmos de criptografia. Contudo,
basta que no processo de identificação dos dados e informações ocorram erros, equívocos
ou descuido para que estas sejam categorizadas erroneamente e consequentemente não
recebam a proteção adequada por meio da criptografia.
Ao longo dos anos surgiram vários algoritmos criptográficos de cifras de blocos
leves para atender a necessidade de proteção dessa grande massa de dados em transmissão
ou armazenados em sistemas computacionais sem degradar o desempenho
computacional, tais como: Simon [Beaulieu et al. 2013], Speck [Beaulieu et al. 2013],
Tea [Wheeler and Needham 1995], Twine [Sukaki et al. 2011], LBlock [Wu and Zhang
2011], LED [Guo, Peyrin, Poschmann and Robshaw 2011], entre outros.
Neste artigo apresentamos dois algoritmos de cifras de blocos leves, Simon e
Speck [Beaulieu et al. 2013], ambos se adéquam a uma grande variedade de aplicações
como: Internet of Things – IoT (Internet das coisas), computação pervasiva e/ou ubíqua,
sistemas embarcados ou em cenários onde o hardware disponível é limitado em relação a
capacidade de processamento, memória e consumo de energia.
Os algoritmos Simon e Speck são explorados neste trabalho abordando diferentes
metodologias de implementação em circuitos programáveis FPGA com o objetivo de
analisar aspectos que circundam a relação entre desempenho e área.
2. Contextualização (Lightweight Block Ciphers)
No ano 1977, o NBS (National Bureau of Standards) estabeleceu o primeiro algoritmo
criptográfico padrão com base em cifras simétricas de blocos, o Data Encryption
Standard – DES. Esse algoritmo possui características de cifra em bloco, baseados na
função de Feistel e em redes de substituição-permutação, atualmente base de algoritmos
criptográficos leves.
Figura 1. Classificação por estrutura dos algoritmos considerados como cifras
leves
47
A cifra de bloco é uma função que mapeia blocos de n-bits de texto não cifrado para
blocos de n-bits de texto cifrado, sendo n o comprimento do bloco. A função é
parametrizada por k-bits da chave K contendo o mesmo tamanho do bloco, assim evitando
a expansão dos dados. [Handbook of Applied Cryptography, 2001]
As cifras de blocos leves operam em blocos de tamanhos fixos, onde a variação
depende do algoritmo. Geralmente de tamanho 64 e 128 bits, elas podem ser classificadas
como: “Redes de Substituição-Permutação” e “Redes de Feistel”, o segundo é utilizado
nos algoritmos Simon e Speck, como pode ser observado na figura 1.
Com pode ser observado na figura 1, recentemente, novos algoritmos de cifra
leves foram criados, como é o caso do Simon e Speck, e também outros como: Simeck,
RoadRunnner, Rectangle, Pride, Chaskey. Isso realça a demanda deste tipo de proteção
no cenário atual dos sistemas computacionais.
2.1. Cifras Feistel (base Simon e Speck)
A maioria dos algoritmos de cifras de blocos possuem uma estrutura descrita em 1973
por Horst Feistel, desenvolvedor de cifras da IBM [Feistel 1973]. Os passos do bloco de
Feistel é descrito abaixo:

As entradas dos algoritmos são divididas em duas partes iguais Left e Right;

Para gerar o texto cifrado, as duas partes sofrem processamento de n iterações;

Cada iteração recebe Left-1 e Right-1, elas são derivadas da iteração anterior,
além disso, uma sub-chave Ki é derivada da chave inicial K;

Através de um algoritmo gerador de chaves, sub-chaves distintas são geradas;

Todas as iterações têm a mesma estrutura e são chamadas de round (rodadas);

Para cada round, aplica-se uma função denominada round function, esta realiza
operações de XOR bit a bit, como demonstra a figura 2:
3. Trabalhos Correlatos
Esta seção tem como objetivo abordar artigos encontrados no estado da arte, os quais
tratam sobre implementações dos algoritmos de cifra leve Simon e Speck, ambos com
ênfase na plataforma FPGA. São apresentados três trabalhos, onde todos eles apresentam
resultados de suas implementações, onde são comparados o desempenho dos algoritmos
por meio do impacto de área e vazão de cada um.
3.1 “Simon and Speck Block Ciphers for the Internet of Things”
No trabalho de BEAULIEU et al. (2015) foram realizadas implementações dos algoritmos
Simon e Speck em plataformas como circuitos integrados de aplicação especifica
(ASICs), FPGAs e microcontroladores, com a finalidade de mensurar o desempenho
destes em diversos cenários para aplicação deste tipo de segurança direcionado à Internet
das coisas (IoT).
A implementação feita em ASICs do algoritmo Simon utiliza menor área quando
comparadas com outras cifras de bloco leve contendo o mesmo tamanho do bloco e chave.
A lógica necessária para calcular um bit por rodada é pequena, quando a escala da
48
implementação é igual ou superior a dois bits, podem ser atualizadas em apenas um ciclo
de relógio com impacto mínimo sobre a área.
Por conseguinte, a implementação do algoritmo Speck nesta mesma plataforma
não traz tanta diferença relacionado ao desempenho de Simon. Uma das principais
diferenças entre estes é que Speck substitui as portas lógicas AND por somador completo
e adiciona multiplexadores para atualização dos estados.
Segundo BEAULIEU et al. O artigo coloca em destaque os resultados obtidos nas
implementações através de simulações com linguagem VHDL, relacionando-os a outros
algoritmos encontrados no estado da arte. Com a velocidade do relógio à 100 kHz, foram
comparados com outros algoritmos que correspondem com o mesmo tamanho de bloco,
tamanho de chave, velocidade e testados em plataformas ASICs, os quais podem ser
encontrados no estado da arte no cenário de cifras de bloco leve.
Nas implementações seguintes, realizadas nas plataformas FPGAs na linguagem
VHDL e microcontroladores na linguagem Assembly e C, foram comparadas novamente
com outros algoritmos criptográficos contidos no estado da arte, onde ao observar os
resultados deixa evidente sua eficiência em relação aos outros. Apesar dos algoritmos
serem implementados em diversas plataformas, tanto em hardware quanto em software,
Simon e Speck não apresentaram dificuldades em adaptação, diferentemente, como por
exemplo, o algoritmo de cifra leve PRESENT.
Entre as implementações realizadas em três plataformas diferentes no trabalho de
BEAULIEU et al., destacamos as implementações em FPGA relacionadas na tabela 1
com o intuito de parametrizar os resultados com o nosso trabalho.
Tabela 1.Comparações de performance entre algoritmos de diferentes autores em FPGA
Tamanho
Álgoritmo
Área (Slice
LUTs)
Vazão (Mbits/s)
64/128
Simon
Simon
Speck
Speck
Simon
Simon
Simon (DPA)
Simon
Simon
Speck
Speck
Speck
24
138
34
153
28
36
87
197
375
36
232
401
9.6
512
7.0
416
5.7
3.6
3.0
567
867
5.0
455
920
128/128
Logo os autores, concluem que os algoritmos Simon e Speck possuem vantagens
não apenas comparado ao desempenho em plataformas diferentes, mas também, pela sua
flexibilidade. Possuindo versatilidade, além de sua simplicidade, faz com que esses dois
algoritmos sejam ideais para uso em redes heterogêneas, onde permitem ser otimizados
para uma aplicação especifica.
3.2. “Simple SIMON FPGA implementations of the Simon 64-128 block cipher”
No trabalho de WETZELS J. e BOKSLAG W. (2015) foram realizadas implementações
do algoritmo de criptografia de cifra leve Simon 64/128 na plataforma Xilinx Spartan-6
FPGA series com diferentes tipos de arquitetura em circuitos combinacionais, são elas:
49

Round Function: A arquitetura apresentada é um circuito combinacional que
expressa a rodada de função como um componente independente;

Arquitetura iterativa: Trata-se de uma arquitetura iterativa, onde o circuito
combinacional da rodada de função projetada anteriormente, é acoplada a um
único registrador e multiplexador, conectados a um sinal no qual alimenta a chave
da rodada. Devido a interligação desses componentes, a execução da encriptação
completa sobre o texto plano torna-se possível, pois todas as rodadas necessárias
são calculadas de forma iterativa;

Arquitetura de desdobramento de laço: É conhecido como uma técnica onde há a
redução de instruções dentro dos laços para otimizar a velocidade de execução do
programa. Este tipo de arquitetura dá a liberdade para escolher entre ser parcial
ou completa, onde deve-se considerar a vazão e a área utilizada. Afim de alcançar
o rendimento máximo que o FPGA pode oferecer, os autores optaram por utilizar
a arquitetura completa;

Arquitetura Inner-round pipelining: Possui como base a arquitetura iterativa, a sua
rodada de função é dividida em subfunções independentes, onde registradores são
utilizados para armazenar resultados parciais entre essas subfunções;

Arquitetura Outer-round pipelining: Possui como base a arquitetura de
desdobramento de laço, onde o designer determina a quantidade de rodadas que
vão utilizar a técnica de desdobramento de laço sem ultrapassar o limite de área e
circuitos combinacionais que a arquitetura possui;

Arquitetura Mixed Inner-Outer-round pipelining: Possui como base as
arquiteturas Outer-round e Inner-round pipelining, onde o designer pode escolher
entre usar parcialmente ou totalmente a arquitetura outer-round pipelining,
substituindo a rodada da função por outra otimizada encontrada na arquitetura
inner-round pipelining.
O artigo expõe a tabela 2, resultados das implementações obtidas através de
simulações no FPGA, com linguagem VHDL, relacionando área e vazão consumida por
cada algoritmo.
Tabela 2. Comparações de área e vazão entre algoritmos em FPGA
Arquitetura
Vazão
(Mbits/s)
Round Function
Iterativa
Iterativa
Iterativa
Desdobramento de laço (K = 44)
Outer-round pipelining (K = 44)
Mixed Inner-Outer-round pipelining
(Ki = 2, K0 = 44)
24
148
105
113
2952
1149
2161
Área
(Slice
LUTs)
0
201
202
199
0
2752
5568
Área/Vazão
Slice
LUTs/(Mbits/s)
32
353
329
328
8096
4096
6459
Em conclusão os autores acentuam que devido ao prazo de projeto, não foi
possível a validação correta das arquiteturas Inner-round pipelining, Mixed Pipelining,
assim considera-se provisoriamente o resultado exposto no artigo.
50
Nenhuma arquitetura proposta foi otimizada relacionado ao desempenho e
confiabilidade como foi realizado em trabalhos correlatos citados no artigo, logo, foi
proposto para trabalhos futuros pelos autores.
3.3. “SpecTre: A Tiny Side-Channel Resistant Speck Core for FPGAs”
No trabalho de CHEN et al.(2015) Foram realizadas duas implementações do algoritmo
de criptografia de cifra leve Speck 128/128 na plataforma Xilinx Spartan-3 FPGA series,
utilizando a linguagem de descrição de hardware Verilog para aplicação deste tipo de
criptografia no cenário de Internet das coisas (IoT).
As duas implementações baseiam-se em trabalhos de criptografias onde os
registradores são implementados na forma de serialização de bits na transmissão de dados
para outros componentes que compõe arquitetura, sendo apenas a chave disposta
paralelamente durante a execução das rodadas.
Porém, a diferença entre os dois algoritmos é que a segunda implementação, afim
de aumentar sua confiabilidade, acrescentou a criptografia limiar. Esse criptosistema
aplica os conceitos de partilha XOR-secreto baseado em computação multipartidária
comprovadamente seguro contra-ataques de canal lateral. Foram feitos análise de
consumo de energia e a resistência à ataques de canal lateral.
Os resultados das implementações na plataforma FPGA são relacionados na tabela
3, associados a resultados de desempenho de outros algoritmos encontrados no estado da
arte, onde a implementação dos autores encontra-se em destaque.
Tabela 3. Comparações de área e vazão entre algoritmos encontrados no estado da arte
em FPGA
Cifra
Área (Slice LUTs)
Vazão
(Mbits/s)
Plataforma
Criptografia
limiar;
TI-Speck128/128
TI-Simon128/128
99
87
9.68
3.0
Xc3s50
Xc3s50
Cifras de bloco
desprotegido;
Speck128/128
Simon128/128
43
36
10.05
3.6
Xc3s50
Xc3s50
4. Arquiteturas Propostas Para Simon e Speck
Nesta seção é discutido os tipos de arquiteturas e suas especificações utilizadas e o que é
esperado nas criptografias leves Simon e Speck. As arquiteturas foram projetadas com
Field Programmable Gate Array (FPGA), particularmente na família Xilinx Artix7 XC7A100T, Xilinx ISE 14.2, utilizando a linguagem de descrição VHDL. As
arquiteturas implementadas são categorizadas em: Sync Single Rounds, Sync Full Rounds
e Async Full Rounds.

Sync Single Rounds (SSR): Na arquitetura composta por sinais, a utilização de
laços repetitivos não é possível, pois os valores dos sinais só são atualizados ao
término de cada iteração (clock), resultando no aumento significativo de iterações,
porém tem-se um ganho em relação à área utilizada dentro do circuito e a
frequência de operação;
51

Sync Full Rounds (SFR): Na arquitetura composta por variáveis, os valores dos
cálculos necessários para executar o algoritmo são atualizados instantaneamente,
isso possibilita a utilização de laços repetitivos (for), fazendo com que apenas uma
única iteração do circuito (clock) seja realizado na geração das chaves e nas
operações de cifrar e decifrar. No entanto, esse tipo de metodologia consome uma
maior área do circuito digital;

Async Full Rounds (AFR): A arquitetura é composta de circuitos combinacionais
onde ocorre a associação de portas lógicas e suas operações podem ser
especificadas por meio de um conjunto de equações Booleanas, esta é utilizada
para realizar as operações do round function e da geração das chaves. Esta
arquitetura também contém uma memória onde são armazenadas as chaves
geradas e os resultados das operações realizadas por cada round realimentando os
rounds seguintes. O tempo de iteração de cara round está associado diretamente
ao tempo de atraso de propagação dos valores entre as portas lógicas, das entradas
até a saída.
Para a avaliação da vazão de cada arquitetura em ambos os algoritmos, é realizado
o cálculo a partir da divisão do tempo base (1 segundo), pelo período de execução que é
o tempo de propagação da lógica do circuito implementado, multiplicado pela quantidade
iterações necessárias para cada implementação e por fim multiplicado pelo tamanho da
palavra (32 bits). Esse cálculo é representado na equação 1.
𝑉𝑎𝑧Ã𝑜 =
1
𝑃𝑒𝑟Í𝑜𝑑𝑜∗𝑄𝑡𝑑𝑒 𝐼𝑡𝑒𝑟𝑎ÇÕ𝑒𝑠
∗ 32 (1)
𝑉𝐴 =
Á𝑟𝑒𝑎
𝑣𝑎𝑧Ã𝑜
(2)
Obtido a vazão, uma relação entre vazão e área (equação 2) é realizada para
comparar o desempenho entre os algoritmos. A variável área é situada pela a quantidade
de SliceLUTs consumida por cada implementação.
Nas seções 5 e 6 são apresentados e especificados os algoritmos Simon e Speck
implementando utilizando as arquiteturas propostas, assim como a análise de desempenho
de área e vazão.
5. Algoritmo SIMON
O bloco de cifra do algoritmo Simon é composto por uma palavra de n bits (portanto um
bloco 2n-bits), este é denotado como Simon2n, onde n pode ser 16, 24, 32, 48 ou 64.
Simon2n possui m palavras chaves (mn-bit) que se refere a como Simon2n/mn. Por
exemplo, Simon64/128 refere-se à versão de Simon em blocos de texto simples de 64
bits, usando uma chave de 128 bits. [Beaulieu et al. 2013]
Esse algoritmo utiliza as operações XOR (⨁) bit a bit, AND (&) bit a bit e
descolamento circular de bits (Sn) nas suas rodadas de encriptação (3) e decriptação (4),
onde l e r são as duas partes que compõem o texto plano (esquerda e direita
respectivamente) e k é a chave da rodada.
A função de encriptação pode ser expressada como:
R (l, r, k) = ((S1 (l) & S8 (l)) ⊕ S2 (l) ⊕ r ⊕ k , l) (3)
E a função de decriptação:
R-1 (l, r, k) = (r, (S1 (r) & S8 (r)) ⊕ S2 (r) ⊕ l ⊕ k) (4)
52
Para as operações de cifração e decifração são necessárias T (T depende do
tamanho de n) rodadas, e consequentemente a geração das chaves para cada rodada a
partir da expansão da chave inicial. Exceto a chave da rodada, todas as rodadas de Simon
são exatamente as mesmas, e as operações são perfeitamente simétricas em relação ao
mapa de deslocamento circular em n-bits palavras.
Portanto, neste artigo é apresentado a implementação deste algoritmo em VHDL
de Simon32/64, com T = 32 (quantidade de rodadas), em três vertentes, utilizando as
arquiteturas SFR, SSR e AFR apresentadas na seção 4, sucedendo a comparação destes
sobre a área e desempenho.
Na tabela 5 tem-se informações sobre desempenho, área e a quantidade de
iteração das arquiteturas descritas em VHDL e implementadas em FPGA, destacando-se
frequência máxima do circuito e seu consumo de área medido em SliceLUTs.
Tabela 5. Estatística: Área e Desempenho de Simon
Desempenho
Período
Frequência
(ns)
(MHz)
41,499
24,096
2,719
367,796
26,087
38,333
SIMON
SFR
SSR
AFR
Área
Slice LUTs
N° de Iterações
Cifração
1504
973
2465
1
65
1
Como pode ser observado na tabela 6, a área consumida pela arquitetura SFR é
35,30% maior que SSR. Já na arquitetura SSR, a frequência é 15 vezes maior que SFR.
A arquitetura AFR consome uma área 39% maior que SFR e 60% maior que SSR; sua
frequência é 1,5 menor que a arquitetura SFR e 9 vezes maior que SSR. Para gerar uma
comparação entre as arquiteturas, é proposta a análise da relação área/vazão, apresentada
na tabela 6.
Tabela 6. Relação Área / Vazão
SIMON
SFR
SSR
AFR
Vazão
Área/Vazão
Mbits/s
771
175
1.226
Slice LUTs/(Mbits/s)
1,95
5,56
2,01
O resultado exibido na tabela 6, mostra que a relação da arquitetura SFR possui
área/vazão 275% melhor que SSR. A arquitetura AFR possui uma relação área/vazão
267% melhor que SSR e 3% inferior a SFR.
6. Algoritmo SPECK
O algoritmo de Speck foi otimizado para desempenho em implementações em software.
Representado usualmente pelo tamanho do bloco (2n) e o tamanho da chave (mn), onde
n é o tamanho da palavra. A notação para as diferentes variantes Speck é análoga a
utilizada por Simon. Por exemplo, quando Speck24/48 refere-se à versão de Speck com
blocos de texto simples de tamanho 48 bits e utilizando uma chave de 48 bits. [Beaulieu
et al. 2013]
Esse algoritmo utiliza em suas operações de criptografia (6) e geração de chaves
as operações de XOR (+) bit a bit, adição modular de 2n (+) e descolamento circular de
53
bits (Sn) durante suas rodadas. Na sua operação de decriptografia (7) ao invés de adição
modular é utilizado a subtração modular. Cada rodada de Speck depende do mapa (5):
𝑅𝑘 ∶ 𝐺𝐹(2)𝑛 × 𝐺𝐹(2)𝑛 → 𝐺𝐹(2)𝑛 × 𝐺𝐹(2)𝑛 (5)
Definido por:
𝑅𝑘 (𝑥, 𝑦) = ((𝑆 −𝛼 𝑥 + 𝑦) ⨁ 𝑘, 𝑆𝛽 𝑦 ⨁ (𝑆 −𝛼 𝑥 + 𝑦) ⨁ 𝑘) (6)
A função inversa para a decriptografia é:
𝑅𝑘−1 (𝑥, 𝑦) = (𝑆 𝛼 ((𝑥⨁𝑘) − 𝑆 −𝛽 (𝑥⨁𝑦) ), 𝑆 −𝛽 (𝑥⨁𝑦) (7)
Para os blocos de tamanho 32, os valores de rotação são 𝛼=7 e𝛽=2, para os outros
tamanhos de blocos 𝛼=8 e 𝛽= 3.
Neste artigo é apresentado a implementação em VHDL de Speck32/64, com T =
22 (quantidade de rodadas), utilizando o mesmo cenário em que ocorreu a implementação
do algoritmo Simon, foram coletados os dados referentes ao número de iterações, a
quantidade de SliceLUTs, o período mínimo e a frequência máxima, para gerar uma
comparação entre as implementações, é proposta a análise da relação área/vazão. Estas
informações foram relacionadas na tabela 8.
Tabela 8. Análise Área e Desempenho de Speck
SPECK
SFR
SSR
AFR
Desempenho
Período
Frequência
(ns)
(MHz)
75,746
13,202
4,012
249,258
36,522
27,38
Área
SliceLUTs
N° de Iterações
Cifração
2238
752
485
1
45
1
Como pode ser observado na tabela 8, a área consumida pela arquitetura SFR é
297% maior que SSR e 461% maior que AFR. A frequência da arquitetura SSR é 18 vezes
maior que SFR e 9 vezes maior que AFR.
A tabela 9 demostra a relação entre vazão e área, para comparar o desempenho
dos algoritmos. Para a área é utilizado a quantidade de SliceLUTs.
Tabela 9.Relação Área/ Vazão
SPECK
Vazão
Mbits/s
Área/Vazão
Slice LUTs/(Mbits/s)
SFR
422
5,3
SSR
177
4,24
AFR
876
0,55
O resultado exibido na tabela 9, expõe que a arquitetura SFR contém uma relação
de área/vazão 25% inferior quando comparado com a arquitetura SSR. A arquitetura AFR
é 963% e 770% superior a SFR e SSR respectivamente.
54
7. Conclusão
Conclui-se que ambos os algoritmos utilizando a arquitetura AFR, possuem uma relação
área/vazão melhor quando comparados com as arquiteturas SFR e SSR, com exceção de
Simon (SFR).
Ainda é possível comparar os dados estatísticos dos algoritmos Simon e Speck. A
implementação do algoritmo Simon utilizando SFR, tem uma relação de área/vazão de
1,95, o qual é 271,79% melhor do que Speck com 5,3. A arquitetura de Speck (SSR), tem
relação de área/vazão de 4,24, o qual é 26% melhor que a versão Simon com 5,37. A
arquitetura de Speck com AFR tem uma relação de área/vazão de 0,55, o qual é 365%
melhor do que Simon com 2,01, como pode ser observado na tabela 10.
Tabela 10.
Algorit.
Simon(SFR)
Freq.
24,096
Análise Simon e Speck
LUTs
1504
Vazão
771
Área/Vazão
1,95
Simon(SSR)
367,796
973
175
5,56
Simon(AFR)
38,333
2465
1.226
2,01
Speck(SFR)
Speck(SSR)
Speck(AFR)
13,202
249,258
27,38
2238
752
485
422
177
876
5,3
4,24
0,55
No entanto, dependendo do cenário onde será realizada a aplicação da solução,
pode-se escolher entre a melhor implementação conforme os requisitos relacionadas ao
desempenho ou área. Por ter uma vazão relativamente alta é possível cifrar dados e
informações em sistemas computacionais, assim mesmo que alguma informação seja
classificada como dados, ela estará protegida por criptografia. E como próximos passos
será gerado consumo de energia dessas arquiteturas na plataforma FPGA.
Referências
Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S., Weeks, B., and Wingers, L. The
Simon and Speck Families of Lightweight Block Ciphers. Cryptology ePrint Archive,
Report 2013/404 (2013). https://eprint.iacr.org.
Handbook of Applied Cryptography, 2001 www.cacr.math.uwaterloo.ca/hac/
H. Feistel, "Cryptography and Computer Privacy," Scientific American, v. 228, n. 5, May
73, pp. 15-23.
Wheeler, D., Needham, R. TEA, a Tiny Encryption Algorithm. In Preneel, B. (ed.) FSE
1994, LNCS vol. 1008, pp. 363{366, Springer, Heidelberg (1995).
Suzaki, T., Minematsu, K., Morioka, S., Kobayashi, E. TWINE: A Lightweight,Versatile
Block Cipher.
Wu, W., Zhang, L. LBlock: A Lightweight Block Cipher. In ACNS 2011, LectureNotes
in Compute Science, No. 6715, 327-344. Springer-Verlag (2011).
Guo, J., Peyrin, T., Poschmann, A., Robshaw, M. The LED Block Cipher. In Preneel, B.
and Takagi, T. (eds.) CHES 2011, LNCS vol. 6917, pp. 326{341, Springer, Heidelberg
(2011).
55
Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, Handbook of Applied
Cryptography, CRC Press, ISBN: 0-8493-8523-7, 1996.
ISO/IEC 27001, Information Security Management System (ISMS), 2005.
Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S., Weeks, B., and Wingers, L. Simon
and Speck: Block Ciphers for the Internet of Things. NIST Lightweight Cryptography
Workshop, 20-21 July 2015.
Wetzels J., Wouter B. Simple SIMON FPGA implementations of the Simon 64/128 block
cipher. Cryptographic Engineering – Kerckhoffs Institute, 2015.
Chen C., Inci M.S., Taha M., Eisenbarth T. SpecTre A Tiny Side-Channel Resistant.
Cryptology ePrint Archive, Report 2015/691 (2015). https://eprint.iacr.org/2015/691.
56
Sistema Inteligente baseado em IoT para Detecção e
Diagnóstico de Falha em Equipamentos de uso Doméstico
Jorge Seabra, Mario Costa Jr, Mateus Lucena
Universidade Federal do Amazonas (UFAM)
Manaus – AM – Brasil
{[email protected], marioacjr}@gmail.com, [email protected]
Resumo. O desenvolvimento dos aparelhos domésticos utilizados no dia a dia
está direcionado para a terceira onda da internet, a internet das coisas (IoT).
No entanto, o mal desempenho no funcionamento destes aparelhos, é
identificado somente pelos próprios usuários. Neste trabalho será descrito um
sistema inteligente, de baixo custo, que monitora em tempo real o
comportamento das grandezas elétricas de dispositivos de uso doméstico que
serão analisadas com o objetivo de informar ao usuário eventuais falhas no
seu funcionamento. O sistema é capaz de identificar tanto o mal
funcionamento instantâneo como antecipar a necessidade de manutenção
preventiva. A interface com o usuário se dará por meio do desktop, tablets,
smartphones, TV Digital.
1. Introdução
A supervisão das grandezas elétricas dos equipamentos domésticos ocupa um
papel chave em manter os níveis de desempenho, confiabilidade e segurança desejados.
Porém, esta supervisão é praticamente realizada exclusivamente por técnicos
especialistas, indispensáveis hoje em dia nos diagnósticos das falhas [1]. Inserido neste
contexto, propõe-se um sistema inteligente que irá monitorar de forma contínua as
condições ideais de funcionamento de dispositivos domésticos evitando desperdícios
com energia elétrica e prevendo manutenções, entre outros serviços.
Os custos reduzidos para utilização das placas micro processadas, sensores e
atuadores, viabilizam as medições em tempo real das grandezas elétricas, mecânicas e
físicas (sistema dinâmico) [2]. Adicionalmente, propostas de normatização da internet
das coisas (IoT) viabilizaram a sua conexão, via a Internet, em sistemas informatizados
que possibilitam o desenvolvimento de métodos inteligentes capazes de tratar estas
novas informações. O processo da detecção de falha envolve a monitoração do estado
atual do sistema por meio das leituras feitas em sensores instalados nos dispositivos e
que serão comparados com um padrão de operação. As diferenças identificadas entre
condições padrões e condições reais será denominado desvio ou resíduo. O tratamento
deste resultado será referência para a condição do bom funcionamento do aparelho
doméstico no sistema inteligente.
De fato, através da IoT, será possível conectar-se ao sistema inteligente de
qualquer lugar do mundo. Assim, pode-se monitorar as grandezas elétricas dos
aparelhos em tempo real e eventualmente identificar distúrbios que indiquem o mal
funcionamento dos mesmos. O sistema irá avaliar o nível de relevância das falhas
através de um classificador, e após esta seleção, irá armazenar em um banco de dados, o
histórico de todas as falhas dos eventos referente ao aparelho monitorado e os dados
estarão disponíveis no servidor local ou em um servidor em nuvem.
57
2. Proposta Conceitual
O monitoramento em tempo real dos indicadores de desempenho dos aparelhos
domésticos conectados à internet possibilitará inúmeras oportunidades na redução dos
custos com manutenção efetiva e desperdício de energia elétrica em empresas e
residências. Sabe-se que, quando um sistema funciona fora de suas condições ideais, ou
seja, com algum tipo de defeito ou até mesmo com alguma falha pequena, imperceptível
para o ser humano, este sistema tende a consumir mais energia e consequentemente
aumentar o custo de sua operação. Considerando todos esses fatores, sistemas de
detecção e diagnóstico de falhas oferecem facilidades para o gerenciamento de
aparelhos domésticos.
A detecção de falhas é realizada por meio do registro de informações, do
reconhecimento e da indicação de anormalidades no comportamento do sistema para um
determinado tempo de análise[3]. Essa operação pode ser feita por meio de diversas
formas, desde o simples acompanhamento de alguma variável do sistema, até a análise
da diferença (chamada de resíduo) entre o valor medido de uma variável e o seu
respectivo valor estimado. O diagnóstico de falhas pode determinar o tipo, a localização,
o tamanho (magnitude), a causa, o instante e o comportamento da variável com o
tempo[4]. A etapa de correção das falhas consiste da tomada de ações apropriadas de
forma automática ou não, para restabelecer a capacidade de desempenhar a função
esperada.
A necessidade de lidar com um grande número de dados de falha ou com a ausência
de dados bem definidos, aliada ao aumento da complexidade dos equipamentos e das
exigências de segurança pessoal e ambiental, tem levado à utilização de técnicas cada
vez mais sofisticadas[5]. A técnica a ser adotada é a Dissociação Base para a Detecção e
Diagnóstico de Falha – (DDF), que simplifica a detecção das falhas para o tratamento
das variáveis envolvidas simultaneamente.
A figura 1, apresenta o fluxo entre os dados coletados no equipamento, a placa que
recebe os dados dos sensores, o tratamento dos dados no SSI e a conexão com os
usuários.
Figura 1: Fluxo do Sistema Inteligente - SSI
58
Equipamento Doméstico – Trata-se do objeto a ser monitorado, e a princípio pode ser
qualquer dispositivo doméstico. Ênfase será dada em dispositivos que não tenham
conexão nativa à Internet por exemplo ar condicionado, geladeira, e outros aparelhos
domésticos tradicionais.
Coletor de Dados de Tempo Real (CDTR) – Este dispositivo micro controlado é
responsável por coletar os dados referentes ao funcionamento do dispositivo doméstico
em tempo real. Estas grandezas elétricas são obtidas através de sensores não invasivos
apropriados conectados ao DCRT. Os dados obtidos irão compor a base de informações
necessárias para a identificação do estado atual do dispositivo doméstico e estarão
disponibilizados no servidor do Sistema Inteligente (SSI).
Servidor Sistema Inteligente – O processo da detecção e diagnóstico de falha (DDF)
envolve a monitoração do estado atual do sistema e a comparação deste estado com uma
referência de estado padrão de operação. Os parâmetros de operação de cada fabricante
são distintos e em geral são disponibilizados em bancos de dados corporativos (Dados
fabricante). De fato, estes dados particulares para cada fabricante resultam em um
tratamento diferenciado para as variáveis de referência para o diagnóstico das falhas dos
dispositivos. Estas regras de operação são relevantes para que o sistema inteligente
possa aprender o comportamento das variáveis envolvidas. Após o decorrer do tempo
necessário para a identificação do estado de operação do equipamento em regime
permanente, faz-se necessário a observação do comportamento das grandezas elétricas
monitoradas com medidas mais precisas em função do regime permanente. Para os
casos das ocorrências de falhas diagnosticadas e que representem riscos na operação, o
sistema será desligado automaticamente. A Figura 2 ilustra, por exemplo, uma variável
que apresenta falha quando os dados medidos em qualquer condição de operação
excedem os limites pré-definidos.
Figura 2: Variável monitorada - Detecção da falha
59
Para cada tipo de falha, o sistema inteligente armazena os resíduos no banco de
dados (Histórico falha). A falha é diagnosticada pelo uso do classificador e do tomador
de decisão do DDF que identificará o grau da relevância da falha comparando com
informações armazenadas no banco de dados do fabricante e banco de dados com o
histórico das falhas. A figura 3 mostra o comportamento da grandeza monitorada nos
diferentes estados, no início da operação (Transiente), em operação (Regime
Permanente) e fora da operação (Desligado).
Figura 3: Comportamento da grandeza monitorada
monitoramento da grandeza Figura.4, ilustra em tempo real a
operação do equipamento com a visualização amigável das condições: falha /
normalidade.
O resultado do
Figura 4: Equipamento monitorado: Falha / normalidade
60
Usuários - O usuário poderá inserir informações que possam alimentar a base de dados
existente, auxiliando a identificar novas probabilidades de falha em algum outro
momento com a permissão do administrador do SSI. Para os casos em que o sistema
não identifique a falha a partir da combinação dos resíduos existentes, a configuração da
nova combinação é inserida no banco de dados de falha, que alimenta o classificador e
tomador de decisão do DDF.
3. Estudo de Caso
Para o estudo de caso prático, foram instalados sensores em um aparelho de ar
condicionado compacto de uso doméstico em um ambiente com dimensões compatíveis
com sua capacidade figura.5. As grandezas elétricas, físicas e mecânicas monitoradas
foram: tensão elétrica, corrente de partida do compressor, corrente total do conjunto em
regime permanente, temperatura de saída do ar condicionado, temperatura interna do
ambiente, temperatura de retorno do ambiente, temperatura externa do ambiente, nível
de vibração do ar condicionado.
Figura.5: Sistema Inteligente instalado no ar condicionado
Os resultados preliminares conforme o Grafico.1, apresentaram índices de
confiabilidade bastante satisfatórios após realizarmos simulações com alterações
premeditadas com intuito de avaliar a performance do sistema inteligente de detecção e
diagnóstico de falhas para o aparelho de ar condicionado. Verificou-se que o sistema é
capaz de monitorar em tempo real as variáveis selecionadas e que realizou o tratamento
das falhas, conforme a especificação proposta ao sistema inteligente (SSI).
61
Gráfico 1: Leituras dos sensores em tempo real
Figura. 6 Sensores não invasivos – coleta de dados
A figura.6, ilustra os componentes do SSI que executam leituras e a placa
utilizada para comunicação para os testes preliminaris.
62
Figura 7: Visão geral do sistema SSI, plataforma de serviços e usuários
4. Conclusão
Uma vez conhecido o comportamento do equipamento monitorado, o sistema
inteligente (SSI) atua nos parâmetros mais rigorosos e precisos minimizando o erros nos
diagnósticos das falhas conforme foi verificado no estudo de caso.
O sistema inteligente irá agregar ao legado dos aparelhos de uso doméstico a
tecnologia da internet das coisas (IoT). O usuário desprovido do conhecimento técnico
poderá utilizar o sistema inteligente proposto para identificar falhas que hoje somente
os técnicos especialistas analisam. Com os recursos do sistema inteligente, as
ocorrências das falhas podem ser diretamente enviadas para o usuário ou para uma
empresa que irá executar o reparo do aparelho. Os casos em que a falha represente risco
eminente, o sistema poderá desabilitar o aparelho automaticamente evitando possíveis
danos tais como: riscos de incêndio, aumento do consumo de energia elétrica, entre
outros fatores não desejáveis.
63
Referências
[1] D.J. Cook et al., "MavHome: An agent-based smart home", IEEE Int. Conf. on
Pervasive Computing and Communications (PerCom). 2013, Vol. 1, pp. 521-524.
[2] T. Niemirepo; M. Sihvonen; V. Jordan; J. Heinilä, “Service Platform for
Automated IoT Service Provisioning”, 9th Int. Conf. on Innovative Mobile and
Internet Services in Ubiquitous Computing (IMIS), 2015, pp. 325-329.
[3] J. Yun, I.Y. Ahn, N.M. Sung, and J. Kim, “A device software platform for
consumer electronics based on the internet of things.” IEEE Transactions on
Consumer Electronics, Vol. 61, Issue: 4, 2015, pp. 564-571.
[4] J. Castillo and T. Edgar, “Model Based Fault Detection and Diagnosis.” TWCCC –
Texas – Wisconsin – California Control Consortium, Texas, 2010, pp 1-10.
[5] H. Li and J.E. Braun, “A Methodology for Diagnosing Multiple-Simultaneous
Faults in Rooftop Air Conditioners”. Int. Refrigeration and Air Conditioning Conf.,
2004, pp. 1-11.
64
WoCCES 2016
65
66
Um algoritmo de navegação não linear 3D para veículos
aéreos não tripulados Guilherme V. Pelizer1, Natássya B. F. Silva1, Kalinka R. L. J. C. Branco1
1
Instituto de Ciências Matemáticas e de Computação – Universidade de São Paulo
(USP) Caixa Postal 668 – 13.560970 – São Carlos – SP – Brasil
[email protected], {ays,kalinka}@icmc.usp.br
Abstract. Unmanned Aerial Vehicle automatic pilot allows them to work
autonomously by keeping the aircraft in predefined flight conditions and by
executing navigation tasks, like path following. A nonlinear algorithm,
named NonLinear Guidance Law (NLGL), uses a nonlinear control law to
provide path following for 2D scenarios. However, is important to consider
the complete motion in the three dimension space for aircraft. Therefore, this
paper proposes a new nonlinear guidance algorithm, based on NLGL, to
provide path following in the 3D scenario. The simulation results,
implemented with the aircraft kinematic motion, show that the new algorithm
performs properly when the parameters are correctly set. Resumo. O piloto automático dos Veículos Aéreos Não Tripulados (VANTs) é
o que permite que essas aeronaves funcionem de modo autônomo, mantendo
as em condições de voo preestabelecidas e executando tarefas de navegação,
como o seguimento de trajetórias. Existe atualmente um algoritmo de
navegação não linear, chamado NonLinear Guidance Law (NLGL), que
utiliza uma lei de controle não linear para o seguimento de trajetórias, porém
para cenários 2D. Mas no caso de aeronaves, é interessante considerar seu
movimento completo nas três dimensões espaciais. Logo, nesse artigo é
proposto um novo algoritmo de navegação não linear, baseado no NLGL,
para o seguimento de trajetórias no cenário 3D. Os resultados das
simulações, implementadas com o movimento cinemático de aeronaves,
demonstram o bom funcionamento desse algoritmo quando os parâmetros são
setados corretamente. 1. Introdução
Veículos Aéreos Não Tripulados (VANTs) são aeronaves que não possuem um piloto
humano a bordo e que são capazes de voar sendo pilotadas remotamente ou por meio de
um sistema autônomo [1]. VANTs podem ser usados em diversas aplicações, como
monitoramento ambiental, de estruturas e de plantações, mapeamento de vias, detecção
de incêndios, procura e resgate e rastreamento [Austin 2010], [Zhang e Kovacs 2012].
O funcionamento de um VANT é baseado em um conjunto de hardware e
software que permite que o voo e a missão sejam préprogramados antes da decolagem.
O sistema autônomo, também conhecido como piloto automático, é o que permite que
esses sistemas funcionem de modo autônomo. Esse sistema é responsável por manter as
67
condições de voo e pela execução de tarefas de navegação, como o seguimento de
trajetórias [Valavanis 2007]. Esse conjunto de hardware e software pode ser dividido
em duas partes: o sistema de controle e o sistema de navegação.
O piloto automático recebe informações dos sensores da aeronave a respeito de
sua posição espacial, velocidade e atitude. Com esses dados, o sistema de navegação
gera instruções de qual estado deve ser seguido para que o veículo continue na trajetória
programada. Essas instruções são então usadas pelo sistema de controle que envia
comandos aos atuadores (superfícies de controle e aceleração do motor) para seguir a
trajetória [Elkaim et al. 2015].
Uma das principais tarefas do sistema de navegação é o seguimento de
trajetórias. Existem diversos algoritmos que tentam resolver essa tarefa para VANTs,
como o CarrotChasing [Sujit et al. 2014], o Pure Pursuit and LOS Guidance (PLOS)
[Kothari et al. 2010] e o Vector Field (VF) [Nelson et al. 2007]. Porém, esses
algoritmos não levam em consideração as não linearidades das equações de movimento
das aeronaves. Uma solução para esse problema é o algoritmo de navegação não linear, ou Non
linear Guidance Law (NLGL) [Park et al. 2007], que apresenta uma lei não linear para o
seguimento de trajetórias para aeronaves no cenário 2D, utilizando também o conceito
de pontos virtuais. O trabalho de Sujit et al. [Sujit et al. 2014] apresenta uma comparação desse
algoritmo com outros algoritmos presentes na literatura para o cenário 2D para VANTs
e ressaltam a boa performance do NLGL. Porém, o grande diferencial de aeronaves não
tripuladas é a possibilidade de movimentarse nas três dimensões espaciais, mas para
isso é necessário estender os algoritmos de seguimento de trajetórias para o cenário 3D.
O objetivo desse artigo é apresentar o desenvolvimento de um algoritmo de
navegação não linear, baseado no NLGL, que permite o seguimento de trajetórias no
cenário 3D. Para comprovar o funcionamento do novo algoritmo foram realizadas
simulações que consideram o modelo cinemático 3D de uma aeronave, variandose os
parâmetros do algoritmo para também fornecer um entendimento a respeito destes.
Também são apresentados os resultados das simulações do NLGL para o cenário 2D
para efeito de comparação. O restante do artigo está organizado da seguinte forma: a Seção 2 descreve o
funcionamento do NLGL para o cenário 2D; enquanto que a Seção 3 apresenta o
desenvolvimento do novo algoritmo de navegação não linear para o cenário 3D; as
Seções 4 e 5, descrevem, respectivamente, os resultados das simulações dos algoritmos
para os cenários 2D e 3D; finalmente, a Seção 6 apresenta a conclusão. 2. Algoritmo de Navegação Não Linear 2D
O algoritmo Nonlinear Guidance Law (NLGL) utiliza o conceito de pontos virtuais, que são pontos inseridos na trajetória para que a aeronave o siga. Com isso, a aeronave se aproxima da trajetória e, eventualmente, acaba seguindoa corretamente. 68
O ponto virtual p pv =( x pv , y pv ) é calculado de acordo com a intersecção entre a trajetória retilínea e um círculo de raio R . A lei de controle para a obtenção da taxa de variação do ângulo de heading, r d , é dada por (1) [Park et al. 2007].
2 v 2 sen( η)
(1)
R
sendo η o ângulo que direciona a aeronave até a trajetória e v a velocidade da aeronave. rd =
O algoritmo completo pode ser visto no Algoritmo 1, no qual W i e W i +1 são, respectivamente, os waypoints ultrapassado e próximo que definem a reta da trajetória,
p=( x , y ) a posição da aeronave naquele instante e ψ o ângulo de heading.
Algoritmo 1: Algoritmo NLGL
1. Inicializar: W i=( x i , y i ) , W i +1=(x i+1 , y i +1) , p=( x , y ) , ψ , R ,
v .
2. α=atan 2( y i+1− y i , x i+1−x i )
3. Determinar p pv =( x pv , y pv ) , que é a intersecção entre a circunferência de raio R e a reta entre os pontos W i e W i +1 .
4. β=atan 2( y pv − y , x pv −x)
5. η=ψ−β
2 v 2 sen( η)
6. r d =
R
3. Algoritmo de Navegação Não Linear 3D
O algoritmo de navegação não linear 3D foi criado com base em uma analogia com o
algoritmo NLGL apresentado na Seção 2. Essa analogia é realizada após a rotação
C (α) (2) no plano horizontal da trajetória, sendo α o ângulo de inclinação da reta
que define a trajetória [Breivik e Fossen 2005]. cos (α) −sen (α) 0
C (α)= sen(α) cos (α) 0
1
0
0
(
)
(2)
Logo, nesse novo algoritmo são calculados dois pontos virtuais, o
p pv , y =( x pv, y , y pv , y , 0) , calculado na intersecção entre a trajetória retilínea e um
círculo de raio R y definido no plano horizontal, e o ponto p pv , z=( x pv , z , 0, z pv , z) ,
calculado na intersecção entre a trajetória retilínea após a rotação e um círculo de raio
R z definido no plano vertical. Em seguida são aplicadas as leis de controle dadas por
(3) e (4) para se obter a taxa de variação do ângulo heading e a taxa de variação do
ângulo pitch.
2 v 2 sen( ηheading )
rd =
Ry
69
(3)
2
2 v sen (ηpitch )
(4)
q d=
Rz
sendo ηheading o ângulo que direciona a aeronave até a trajetória no plano horizontal,
η pitch o ângulo que direciona a aeronave até a trajetória no plano vertical, e v a
velocidade da aeronave. O algoritmo completo é apresentado no Algoritmo 2, , no qual W i e W i +1 são,
respectivamente, os waypoints ultrapassado e próximo que definem a reta da trajetória e
p=( x , y , z) a posição da aeronave naquele instante.
Algoritmo 2: Algoritmo de navegação não linear 3D 1. Inicializar: W i=( x i , y i , zi ) , W i +1=(x i+1 , y i +1 , z i+1 ) , p=(x , y , z) , ψ ,
θ , Ry , Rz , v .
2.
α=atan 2( y i+1− y i , x i+1−x i )
3. Determinar p pv , y =( x pv , y , y pv , y , 0) , que é a intersecção entre a circunferência de raio R y e a reta entre os pontos ( x i , y i , 0 ) e
( x i+1 , y i+1 ,0 ) .
4.
W Ri =C (α )W i
5.
W i +1=C(α)W i+ 1
R
6. Determinar p pv , z =( x pv , z , 0, z pv , z) , que é a intersecção entre a circunferência
R
R
de raio R z e a reta entre os pontos ( x iR ,0, z Ri ) e ( x i+1
, 0, z i +1 ) .
7.
βheading=atan 2( y pv , y − y , x pv, y −x)
8.
β pitch=atan 2(z−z pv , z , x pv , z−x )
9.
ηheading=ψ−βheading
10. η pitch=θ−β pitch
2 v 2 sen( ηheading )
11. r d =
Ry
2 v 2 sen(ηpitch )
12. q d=
Rz
4. Resultados da simulação 2D
A comprovação do funcionamento do algoritmo NLGL apresentado na Seção 2 foi
realizada por meio de simulações no Matlab utilizando a modelagem cinemática 2D do
movimento de uma aeronave, representada por (5)(7) [Sujit et al. 2014]. 70
ẋ=v cos ( ψ)
(5)
ẏ=v sen( ψ)
(6)
r= ψ̇
(7)
onde a posição da aeronave é dada por p=( x , y ) , v é a intensidade da velocidade
considerada constante, r é a taxa de variação do ângulo heading e ψ é o ângulo
heading. Como a taxa de variação do ângulo heading é fornecida pelo algoritmo de
navegação de seguimento de trajetória a cada iteração, é possível calcular ψ
realizando sua integração. Em seguida, calculase as velocidades dado o valor do
heading e obtémse as posições pela suas integrações. Durante toda a simulação a intensidade da velocidade v é mantida constante e
igual a 15 m/s. Também é considerada a limitação física da aeronave para realizar
curvas com |r|< r max , sendo r max =0.33 rad/s [Sujit et al. 2014].
As simulações foram realizadas variandose o parâmetro R para observar o seu
efeito no seguimento da trajetória, conforme pode ser visto na Figura 1. Figura 1. Trajetórias 2D das simulações do algoritmo NLGL variando o
parâmetro R .
É possível observar que o algoritmo funciona corretamente e que quanto maior o
valor de R mais lentamente a aeronave converge para a trajetória, porém para os
valores de R muito baixos não é possível calcular a intersecção do círculo com a reta
que define a trajetória e o algoritmo deixa de funcionar. Nesse caso, o melhor valor
para o parâmetro R é 10 metros, já que é o que mais se aproxima com a trajetória
desejada. 71
5. Resultados da simulação 3D
Já a comprovação do novo algoritmo de navegação não linear 3D apresentado na Seção
3 foi realizada utilizando a modelagem cinemática 3D do movimento da aeronave,
representada por (8)(12) [Titterton e Weston 2004], também implementada no Matlab.
ẋ=v cos (ψ) cos(θ) (8)
ẏ=v sen(ψ)cos (θ) (9)
ż=−v sen (θ)
(10)
r= ψ̇
(11)
q=θ̇
(12)
onde a posição da aeronave é dada por p=( x , y , z) , v é a intensidade da
velocidade considerada constante, r é a taxa de variação do ângulo heading, q é a
taxa de variação do ângulo pitch, ψ é o ângulo heading e θ é o ângulo pitch.
Nas simulações para esse modelo também é considerado que as taxas de variação
dos ângulos heading e pitch são fornecidas pelo algoritmo de navegação não linear 3D e
a partir das suas integrações são obtidos os ângulos ψ e θ . Em seguida são
calculadas as velocidades para cada eixo e a partir da suas integrações são obtidas as
posições da aeronave a cada instante. Durante toda a simulação a intensidade da velocidade v é mantida constante e
igual a 15 m/s. Também é considerada a limitação física da aeronave para realizar
curvas tanto em relação ao heading quanto ao pitch, com |r|< r max e |q|<q max , sendo
r max =0.33 rad/s e q max=0.19 rad/s [Sujit et al. 2014].
As simulações foram realizadas variandose o parâmetro R y e R z para observar
os seus efeitos no seguimento da trajetória. A Figura 2 mostra as trajetórias resultantes
para diferentes valores de R y e fixandose R z=20 m e a Figura 3 mostra as
trajetórias resultantes para diferentes valores de R z e fixandose R y =20 m. É possível observar que o algoritmo funciona corretamente e que o comportamento
da mudança é o mesmo que acontece na análise do NLGL para o cenário 2D. Quanto
maior o valor de R y ou R z mais lentamente a aeronave converge para a trajetória,
porém para os valores muito baixos não é possível calcular a intersecção dos círculos
com a reta que define a trajetória e o algoritmo deixa de funcionar. Nesse caso, o
melhor valor para os parâmetros R y e R z são 20 metros, já que é o caso em que a
trajetória resultante mais se aproxima da trajetória desejada. 72
Figura 2. Trajetórias 3D das simulações do algoritmo de navegação não linear
3D variando o parâmetro R y e R z=20 m.
Figura 3. Trajetórias 3D das simulações do algoritmo de navegação não linear
3D variando o parâmetro R z e R y =20 m.
73
6. Conclusão
Foram apresentados os resultados de simulações para dois algoritmos de navegação para
o seguimento de trajetórias. O Nonlinear Guidance Law (NLGL) que utiliza uma lei de
controle não linear e permite que uma aeronave siga uma trajetória 2D corretamente e
um novo algoritmo de navegação não linear 3D, baseado no primeiro, mas que permite
que a aeronave siga uma trajetória 3D. A grande vantagem do uso do algoritmo de
navegação não linear 3D é contemplar todas as possibilidades de voo de uma aeronave,
que pode se mover em três coordenadas espaciais. Também foram comparados os comportamentos dos algoritmos para diferentes
valores dos seus parâmetros, demonstrando que quanto maior for o raio do círculo
usado para determinarse o ponto virtual, mais lentamente o algoritmo convergirá.
Porém, existe também uma limitação inferior para o valor desse raio, já que se for muito
pequeno não será possível encontrar uma intersecção com a trajetória. No caso do
NLGL o melhor valor, entre os avaliados, para o parâmetro R é de 10 metros,
enquanto que no caso do novo algoritmo de navegação não linear 3D, o melhor valor,
entre os avaliados, para ambos os parâmetros R y e R z é de 20 metros. Como trabalho futuro pretendese reproduzir os experimentos em ambientes mais
realísticos, como plataformas de HardwareintheLoop com o auxílio de um simulador
de voos. Agradecimentos
Os autores gostariam de agradecer à FAPESP pelo apoio financeiro concedido pelos
processos 2012/136411 e 2015/212492.
Referências
Austin, R. (2010) “Unmanned Aircraft Systems: UAVS Design, Development and
Deployment” Aerospace Series, Wiley. Breivik, M. e Fossen, T. I. (2005) “Principles of GuidanceBased Path Following in 2D
and 3D”, In: 44th IEEE Conference on Decision and Control, 2005 European Control
Conference. CDCECC '05., pp. 627634. doi: 10.1109/CDC.2005.1582226
Elkaim, G. H., Lie, F. A. P. e GebreEgziabher, D. (2015) “Principles of Guidance,
Navigation, and Control of UAVs”, In: Handbook of Unmanned Aerial Vehicles,
Editado por Kimon P. Valavanis e George J. Vachtsevanos, Springer Netherlands, p.
347380. doi: 10.1007/9789048197071_56
Kothari, M., Postlethwaite, I. e Gu, D. W. (2010) “A suboptimal path planning
algorithm using rapidlyexploring random trees”, In: International Journal of
Aerospace Innovations, vol. 2, no. 1, pp. 93–104.
Nelson, D. R., Barber, D. B., McLain, T. W. e Beard, R. W. (2007) “Vector field path
following for miniature air vehicles”, In: IEEE Transactions on Robotics, vol. 23, no.
3, pp. 519–529, 2007.
74
Park, S., Deyst, J. e How, J. P. (2007) “Performance and Lyapunov Stability of a
Nonlinear Path Following Guidance Method”, In: Journal of Guidance, Control, and
Dynamics, vol. 30, no. 6 , pp. 17181728. doi: 10.2514/1.28957 Sujit, P. B., Saripalli, S. e Sousa, J. B. (2014) “Unmanned Aerial Vehicle Path
Following: A Survey and Analysis of Algorithms for FixedWing Unmanned Aerial
Vehicless”, In: IEEE Control Systems, vol. 34, no. 1, pp. 4259. doi:
10.1109/MCS.2013.2287568
Titterton, D. e Weston, J. L. (2004) “Strapdown Inertial Navigation Technology” IET.
Valavanis, K. P. (2007) “Advances in Unmanned Aerial Vehicles: State of the Art and
the Road to Autonomy”, Springer Publishing Company, Incorporated, 2007.
Zhang, C. e Kovacs, J. M. (2012) “The application of small unmanned aerial systems
for precision agriculture: a review” In: Precision Agriculture, vol. 13, no. 6, p. 693–
712. Springer US. doi: 10.1007/s1111901292745
75
Análise de Perfil de Motoristas: Detecção de Eventos por meio
de Smartphones e Aprendizado de Máquina
Jair Ferreira Júnior1,2 , Gustavo Pessin1,2
Instituto de Ciências Exatas e Naturais
Universidade Federal do Pará (UFPA) – Belém, PA, Brasil
1
Laboratório de Computação Aplicada
Instituto Tecnológico Vale – Belém, PA, Brasil
2
[email protected], [email protected]
Resumo. O comportamento do motorista influencia fortemente a segurança no
trânsito, o consumo de combustível e a emissão de gases poluentes. A Análise
de Perfil de Motoristas (APM) é uma ferramenta que visa entender e potencialmente influenciar positivamente o comportamento de motoristas. Usualmente,
tarefas de APM envolvem coletas automatizadas de dados de condução e aplicação de modelos computacionais a fim de gerar classificações que caracterizem
o perfil de agressividade de condutores. Diferentes sensores e métodos de classificação têm sido empregados nesta tarefa, entretanto, soluções de baixo custo
e alto desempenho ainda são alvos de pesquisa. Neste artigo é realizada uma
investigação com diferentes sensores, presentes em um smartphone Android, e
diferentes algoritmos de classificação, a fim de avaliar qual conjunto de sensor/método permite a classificação com maior acuracidade. Os resultados mostram que combinações específicas de sensores e métodos inteligentes permitem
melhorar o desempenho das classificações.
1. Introdução
O comportamento do motorista influencia fortemente a segurança no trânsito
[Xiaoqiu et al. 2011] e é causa da grande maioria dos acidentes [Evans 2004]. O custo
econômico total destes acidentes — apenas nos Estados Unidos em 2010 — foi estimado
em mais de $240 bilhões, decorrentes de cerca de 32 mil mortes, 3,9 milhões de feridos
e 24 milhões de veículos danificados [Blincoe et al. 2015]. Adaptações neste comportamento podem aumentar a segurança e diminuir o consumo de combustível/energia e
emissão de gases dos veículos [N. Haworth 2001, Van Mierlo et al. 2005]. A Análise de
Perfil de Motoristas (APM) é uma das ferramentas que visa entender e potencialmente influenciar positivamente o comportamento de condutores, podendo promover uma forma
de dirigir mais eficiente do ponto de vista energético e também mais segura.
A APM consiste na utilização de sensores para coleta automatizada de dados de
condução de veículos (e.g., velocidade, aceleração, frenagem, esterçamento, localização)
e aplicação de um modelo computacional de análise a fim de gerar uma pontuação ou
classificação que caracterize a forma de dirigir do motorista. Esta pontuação representa o
seu grau de risco ou segurança em um trajeto. A coleta de dados de direção em APM pode
ser realizada por diversos tipos de sensores, desde os presentes nos atuais smartphones,
76
até equipamentos específicos para esse fim, como câmeras de monitoramento, caixas telemáticas1 e adaptadores OBD (On-Board Diagnostic)2 .
Atualmente, os smartphones são equipados com diversos sensores utilizados em
soluções APM. Estes sensores incluem, entre outros, GPS (Global Positioning System),
acelerômetro, giroscópio e magnetômetro de 3 eixos (lateral, longitudinal e vertical).
Experimentos [Paefgen et al. 2012, Skog et al. 2013, Handel et al. 2014] demonstraram
que, no contexto de APM, os dados fornecidos por estes sensores estão fortemente correlacionados com medições de referência de caixas telemáticas instaladas fixamente nos
veículos e, apesar de haver espaço para melhorias, os smartphones se provaram uma forma
acessível e interessante de instrumentar um veículo para coleta de dados. A relevância da
APM têm crescido nos últimos anos em diversos domínios de aplicação. Na gestão de
frotas, há interesse em informações detalhadas e precisas sobre o uso dos veículos. No
domínio de telemática de seguros, planos do tipo Usage-Based Insurance (UBI) têm como
objetivo calcular o bônus de seguro em função do perfil individual de condução do motorista, ao invés de recorrer a estatísticas baseadas em grupos, como idade, sexo e estado
civil. Adicionalmente, a pontuação do motorista está relacionada com quão ecológica é
sua forma de dirigir [Van Mierlo et al. 2004]. Neste caso, o principal objetivo é incentivar os motoristas a buscar uma boa pontuação para otimizar o consumo de combustível e
energia de seus veículos, gerando economia. Por fim, é possível também prevenir a ocorrência de acidentes ao fornecer feedback ao motorista. Tal feedback é mais útil e eficaz
quando ocorre em tempo real, notificando-o, por exemplo, sempre que acelerar demais ou
quando sua pontuação refletir uma direção agressiva.
Diversos trabalhos de APM podem ser encontrados na literatura. Dentre estes,
podemos citar [Johnson and Trivedi 2011, Castignani et al. 2013, Saiprasert et al. 2014,
Castignani et al. 2015] que utilizam uma fusão de dados dos sensores do smartphone
para identificar eventos de direção agressivos (e.g., curvas, acelerações e freadas agressivas) e, consequentemente, classificar a forma de dirigir do motorista. Outro trabalho
[Araujo et al. 2012] utiliza dados de sensores do próprio veículo para fornecer dicas de
direção e avaliar a eficiência de consumo de combustível em função da forma de dirigir do
motorista. Os algoritmos de aprendizado de máquina empregados nestes trabalhos se resumem à lógica fuzzy ou variações de Dynamic Time Warping3 (DTW). Adicionalmente,
a maioria dos trabalhos usa detecção de eventos agressivos como base para a classificação
de perfis de direção e peca ao não fornecer uma avaliação quantitativa da metodologia
empregada.
Portanto, este artigo tem como objetivo a avaliação quantitativa das performances
de combinações de algoritmos de aprendizado de máquina e sensores de smartphone Android, na tarefa de detecção de eventos de direção. Assim, ao final desta avaliação, será
possível identificar qual combinação de sensor, seu(s) eixo(s) e algoritmo melhor detecta
um determinado tipo de evento agressivo. O restante do artigo é organizado da seguinte
forma: a Seção 2 resume alguns trabalhos relacionados com APM. A Seção 3 descreve
1
A “caixa telemática” é um equipamento de medição fixamente instalado no veículo que pode ter sensores próprios ou se conectar aos sensores internos do veículo através do barramento CAN.
2
O OBD é um sistema que confere aos veículos atuais a capacidade de se auto-diagnosticar e fornecer
dados (e.g., velocidade) em tempo real via uma porta de comunicação padronizada.
3
Dynamic Time Warping é uma técnica utilizada para encontrar padrões em séries temporais e foi originalmente empregada no problema de reconhecimento de fala [Sakoe and Chiba 1978].
77
a metodologia da avaliação realizada, seguida de seus resultados na Seção 4. Por fim, na
Seção 5 são apresentadas as conclusões e trabalhos futuros.
Esta seção descreve resumidamente alguns trabalhos recentes da literatura relacionados
com APM. É importante ressaltar que várias soluções comerciais de APM estão disponíveis atualmente. A maioria delas aplicada aos domínios de telemática de seguros e gestão
de frotas. Exemplos incluem Aviva Drive, Greenroad, Snapshot e SeeingMachines. Entretanto, uma análise técnica destas soluções é inviável já que seus métodos de coleta e
modelos de análise de dados não são publicamente disponíveis.
O trabalho [Johnson and Trivedi 2011] apresenta o aplicativo MIROAD para
iPhone que faz uma fusão do magnetômetro, acelerômetro, giroscópio e GPS do
smartphone para identificar eventos de direção agressivos e, consequentemente, classificar a forma de dirigir como agressiva ou não-agressiva. Estes eventos são detectados
por um único classificador baseado no algoritmo DTW. Todo o processamento é feito em
tempo real no próprio smartphone, sem necessidade de equipamentos externos. A análise experimental executada mostrou que 97% dos eventos agressivos foram corretamente
identificados. O trabalho [Araujo et al. 2012] propõe um aplicativo de smartphone para
avaliar a eficiência de consumo de combustível em função da forma de dirigir do motorista. O aplicativo também fornece dicas de direção em tempo real do tipo “troque de
marchas mais cedo” e “aceleração muito alta”. O processamento é feito localmente no
smartphone e em tempo real. O aplicativo não utiliza nenhum sensor do smartphone. Ao
invés disso, coleta dados de velocidade, aceleração, altitude, sinal do acelerador, consumo
instantâneo de combustível e RPM (Rotações Por Minuto) dos sensores do próprio veículo
por meio de um adaptador OBD Bluetooth e do aplicativo Torque Pro para smartphones.
Após a coleta, é realizada uma extração de características e três classificadores (h1 , h2
e h3 ) são aplicados. h1 é um discriminante linear que identifica a “Condição de Direção” como urbana, auto-estrada ou mista. h2 e h3 são sistemas fuzzy que fornecem,
respectivamente, a “Avaliação do Consumo de Combustível” e a “Dica de Direção”. Uma
avaliação preliminar da aplicação foi realizada através de uma viagem de pouco mais de
uma hora. Nesta avaliação, h1 reconheceu corretamente as diferentes condições de direção presentes, o classificador h2 informou a melhor avaliação na maior parte do tempo e o
classificador h3 forneceu dicas para trocar de marcha mais cedo e acelerar mais delicadamente sempre que o motorista acelerava de forma mais intensa. Não há menção à eficácia
dos classificadores h2 e h3 na referida avaliação preliminar.
O artigo [Castignani et al. 2013] propõe um mecanismo de avaliação de motoristas baseado em lógica fuzzy que utiliza o acelerômetro, magnetômetro e sensor de
gravidade de smartphones Android como entrada, classifica o motorista nos estilos de direção Normal, Moderado e Agressivo, e calcula seu score de direção de 0 (melhor) a 100
(pior). A classificação e o score não são calculados em tempo real, visto que os dados
de sensores são coletados pelo aplicativo UBI-Meter e armazenados no smartphone para
posterior envio a um servidor remoto na Internet que agrega dados de diversos motoristas
e os analisa. Foi realizado experimento com 5 motoristas, totalizando 2360 km, 33 horas
e 87 viagens. Neste experimento, os scores gerais dos motoristas 1 ao 5 foram 68,57,
83,46, 82,72, 77,15 e 60,12. A eficácia do mecanismo no experimento não é informada.
78
O objetivo do trabalho [Saiprasert et al. 2014] é utilizar o GPS, acelerômetro e
magnetômetro dos smartphones para classificar a forma de dirigir de motoristas nos perfis de segurança muito seguro, seguro, agressivo, e muito agressivo. Esta classificação é
realizada por meio da detecção, em tempo real, de eventos de condução relevantes que podem ocorrer durante uma viagem. A detecção é feita por um algoritmo de reconhecimento
de padrões [Saiprasert et al. 2013] baseado na técnica de DTW. Os eventos detectados por
este algoritmo são frenagem agressiva, aceleração brusca, curva acentuada, mudança de
faixa agressiva e velocidade excessiva. Na extensa análise experimental realizada (30
viagens em rota de 315 km e 30 viagens em outra rota de 780 km), a grande maioria
dos motoristas foi classificada nos perfis intermediários seguro (28 viagens) e agressivo
(17 viagens). Poucos foram classificados nos perfis muito seguro (3 viagens) e muito
agressivo (8 viagens). O artigo não menciona a eficácia de seu método no experimento
realizado.
O artigo [Castignani et al. 2015] apresenta o SenseFleet, uma plataforma de APM
baseada em smartphone Android. O aplicativo coleta dados do acelerômetro, magnetômetro, sensor de gravidade e GPS do smartphone com o objetivo de detectar eventos de risco
(velocidade, aceleração, frenagem e esterçamento excessivos) ocorridos durante uma viagem. Uma nova pontuação do motorista é gerada a cada viagem percorrida em função
da detecção destes eventos, podendo variar entre 0 (pior) a 100 (melhor) pontos. Tal detecção é realizada por um sistema fuzzy cujos limites são obtidos dinamicamente através
de um processo de calibragem executado na primeira vez que o aplicativo é utilizado em
uma nova combinação de motorista, smartphone e veículo. Todo o processamento é feito
em tempo real no próprio aplicativo, independentemente do modelo de smartphone e veículo. Adicionalmente, os eventos detectados, os dados coletados e as pontuações podem
ser enviados a um servidor central que agrega informações de diversos motoristas e viagens para futura análise e geração de relatórios. Diversos experimentos foram realizados
pelos autores. Em um deles foi observada uma taxa pouco maior que 90% de eventos corretamente identificados. Em outro experimento que utilizava dois smartphones bastante
diferentes instalados no mesmo veículo, foi constatado que a detecção de eventos segue
praticamente o mesmo padrão, independentemente do dispositivo utilizado.
Ao analisar os trabalhos apresentados nos parágrafos anteriores, podemos identificar as seguintes características comuns: (i) os trabalhos utilizam uma fusão de dados de vários sensores como entrada para os modelos de detecção de eventos; (ii) a
maioria dos trabalhos [Araujo et al. 2012, Castignani et al. 2013, Castignani et al. 2015]
emprega lógica fuzzy e o restante [Johnson and Trivedi 2011, Saiprasert et al. 2014] utiliza DTW; (iii) a maioria dos trabalhos usa os sensores disponíveis em smartphones
como meio de coleta de dados, ao invés dos sensores do próprio veículo (via interface OBD) ou caixas telemáticas; e (iv) a maioria dos trabalhos não menciona a eficácia quantitativa das metodologias propostas, tornando difícil avaliá-las. Isso ocorre em
[Castignani et al. 2013, Saiprasert et al. 2014] e parcialmente em [Araujo et al. 2012].
3. Metodologia
A avaliação proposta neste trabalho tem como objetivo identificar as triplas {sensor,
eixo(s), algoritmo de aprendizado} capazes de melhor detectar um determinado tipo de
evento de direção. Para tanto, modelamos a avaliação como um problema de aprendizado
supervisionado no qual as classes são os tipos de eventos, e os dados dos sensores dão
79
origem a vetores de atributos que formam os datasets. Ao aplicar diversos algoritmos
de classificação, obtemos os scores ROC [Fawcett 2006] para cada classe e dataset. Este
score varia de 0,5 (pior resultado) a 1,0 (melhor resultado) e será utilizado para determinar
a eficácia do algoritmo de classificação dados um tipo de evento de direção (classe), um
sensor e seu(s) eixo(s).
Utilizamos os seguintes sensores de smartphone Android nesta avaliação: aceleração linear (AclLin), magnetômetro (Mag), gravidade (Grav), vetor de rotação (VRot),
acelerômetro (Acel) e giroscópio (Gir). O acelerômetro mede a força da aceleração causada pelo movimento do telefone. O sensor de aceleração linear funciona como o acelerômetro, mas excluindo a aceleração da gravidade. O giroscópio mede o grau de rotação
em torno dos eixos do dispositivo. O magnetômetro mede a força do campo magnético,
funcionando como uma bússola. O sensor de vetor de rotação representa a orientação do
smartphone como uma combinação da rotação de um ângulo θ sobre um eixo (x, y ou z).
Por último, o sensor de gravidade fornece um vetor tridimensional indicando a direção e
magnitude da gravidade.
Os dados fornecidos pelos sensores do smartphone são uma série temporal com
precisão de nanosegundos e taxas de amostragem de ~100 Hz ou ~240 Hz, dependendo
do sensor. Todos os sensores utilizados, exceto o de vetor de rotação, fornecem amostras
com três valores (x, y e z) referentes ao sistema de coordenadas do dispositivo exibido na
Figura 1(a). Já o sensor de vetor de rotação fornece amostras com quatro valores (componentes escalar, x, y e z) referentes ao sistema de coordenadas da Terra exibido na Figura
1(b). Cada sensor dá origem a um dataset contendo dados de todas as suas coordenadas,
mais um dataset para cada coordenada isoladamente. Por exemplo, o acelerômetro dá
origem a quatro datasets: acelerômetro (com dados de x, y e z juntos), acelerômetro_x,
acelerômetro_y e acelerômetro_z. Portanto, esta avaliação foi realizada em um total de
25 datasets. Detalhes sobre os vetores de atributos criados serão apresentados na Seção
3.1.
(a)
(b)
Figura 1. Sistema de coordenadas relativo ao smartphone (a) utilizado por todos
os sensores desta avaliação, exceto pelo de vetor de rotação que usa o sistema
de coordenadas relativo à Terra (b).
Os algoritmos de classificação usados nesta avaliação são o Multi Layer Perceptron (MLP), Bagging de “Reduced Error Pruning Trees” (REPTrees) e Support Vector Machines (SVM). Utilizamos as implementações destes algoritmos no popular framework de mineração de dados e aprendizado de máquina WEKA [Hall et al. 2009] e
LIBSVM [Chang and Lin 2011]. Configuramos os algoritmos com os parâmetros padrão
do WEKA, conforme Tabela 1.
80
Tabela 1. Algoritmos e suas configurações no WEKA.
Algoritmo
Multi Layer Perceptron (MLP)
Bagging de REPTree
Support Vector Machines (SVM)
Configuração
-L 0.3 -M 0.2 -N 500 -V 0 -E 20 -H a
-P 100 -I 10 -W weka.classifiers.trees.REPTree -- -M 2 -V 0.001 -N 3 -L -1
-S 0 -K 2 -D 3 -G 0.0 -R 0.0 -N 0.5 -M 40.0 -C 1.0 -E 0.001 -P 0.1
Cada algoritmo de classificação é treinando e avaliado com os datasets por meio de
validação cruzada de 10 subconjuntos. Como possuímos 25 datasets e 3 algoritmos, avaliamos (25 ∗ 3) = 75 combinações de {sensor, eixo(s), algoritmo de aprendizado}, obtendo
o ROC Score para cada tipo de evento de direção. As classes de aprendizado desta avaliação foram baseadas nos tipos de eventos de direção detectados em [Saiprasert et al. 2014].
Com o objetivo de obter leituras de sensores do smartphone para estes eventos, realizamos um experimento no qual estas manobras de direção foram executadas em um veículo
real durante duas viagens com duração de aproximadamente 5 minutos cada, enquanto
um aplicativo Android capturava dados dos sensores do smartphone. Os tempos iniciais
e finais dos eventos foram registrados para servir como ground-truth. Os tipos de eventos de direção e seus números de amostras no experimento são: Aceleração Agressiva
(2 eventos), Freada Agressiva (3 eventos), Curva Agressiva à Direita (4 eventos), Curva
Agressiva à Esquerda (2 eventos), Troca de Faixa Agressiva à Direita (2 eventos), Troca
de Faixa Agressiva à Esquerda (2 eventos) e Evento não agressivo (9 eventos). O último
tipo de evento agrupa manobras executadas de forma não agressiva (e.g. curva suave,
aceleração suave).
Realizamos o experimento nas seguintes condições: (i) o veículo foi um Honda
Civic 2011; (ii) o smartphone foi um Samsung Galaxy S6 afixado na posição vertical no
para-brisas do veículo por meio de suporte apropriado; (iii) o mesmo motorista com 20
anos de experiência conduziu o veículo em ambas as viagens; (iv) a via era asfaltada,
seca, com poucos buracos e de trânsito leve; (v) o clima era ensolarado; e (vi) a taxa de
amostragem dos sensores de aceleração linear, gravidade, vetor de rotação e magnetômetro era de ~100 Hz, enquanto que a do acelerômetro e giroscópio era de ~240 Hz. O
gráfico da Figura 2 exibe os dados dos eixos do sensor de aceleração linear durante um
evento de troca de faixa agressiva à direita coletado no experimento. Nota-se o formato
característico do eixo x.
3.1. Vetor de Atributos
Cada sensor origina um dataset bruto contendo basicamente o instante da coleta (em nanosegundos) e os valores dos eixos dos sensores naquele momento. Estes dados brutos
são tratados antes de serem submetidos aos classificadores. Este tratamento consiste em
gerar uma janela móvel de 7 segundos deslizando em incrementos de 1 segundo sobre
a série temporal. O tamanho da janela foi experimentalmente definido em 7 segundos
devido ao fato de que, ao analisar a ground-truth do experimento, percebemos que os
eventos de direção duram entre 2 (para os mais agressivos) e 6 (para os não agressivos)
segundos. Portanto, com essa duração, a janela captura completamente qualquer evento
de direção coletado no experimento.
A janela é expressa por um vetor de atributos. Para calcular este vetor, consideramos t0 o conjunto de amostras do segundo atual da série temporal, t−1 o con81
Figura 2. Eixos x, y e z do sensor de aceleração linear em um evento de troca de
faixa agressiva à direita. Nota-se o formato característico do eixo x.
junto de amostras do segundo anterior, e assim por diante, até t−6 . Calculamos então
as médias (M0 = M[t0 ] , M−1 = M[t−1 ,t0 ] , ..., M−6 = M[t−6 ,t0 ] ), medianas (M N0 =
M N[t0 ] , M N−1 = M N[t−1 ,t0 ] , ..., M N−6 = M N[t−6 ,t0 ] ) e desvios padrões (DP0 =
DP[t0 ] , DP−1 = DP[t−1 ,t0 ] , ..., DP−6 = DP[t−6 ,t0 ] ) acumulados. Adicionalmente, as tendências de crescimento ou diminuição das médias das amostras de cada segundo em relação às do segundo atual (t0 ) são calculadas pelas suas proporções da seguinte forma:
Mt
Mt
Mt
T−1 = M−1
, T−2 = M−2
, ..., T−6 = M−6
. A classe é então adicionada ao vetor quando
t0
t0
t0
os tempos inicial e final do evento (obtido por meio da ground-truth) estiverem ambos
entre t−6 e t0 da janela. Caso contrário, o vetor de atributos não é gerado para esta janela em particular. A Figura 3 exibe a estrutura do vetor de atributos para um eixo da
série temporal. Quando o dataset possuir diversos eixos, os vetores de cada eixo (sem as
classes) são concatenados horizontalmente e a classe é adicionada como último campo
do vetor resultante. Por fim, como os vetores de atributos são atemporais, agrupamos os
vetores de várias viagens em um único dataset para o mesmo sensor e eixo(s).
Figura 3. Vetor de atributos representando uma janela deslizante de 7 segundos
(de t−6 a t0 ) da série temporal para um eixo de um sensor.
4. Resultados
Executamos os 3 algoritmos de classificação da Tabela 1 sobre os 25 datasets contendo
os vetores de atributos descritos na Seção 3.1 e extraímos as triplas {sensor, eixo(s), algoritmo de aprendizado} de maiores ROC Scores médios para cada evento de direção. Cada
tripla foi executada com 10 sementes aleatórias diferentes. Os resultados da avaliação
podem ser vistos na Figura 4.
82
Figura 4. ROC Scores de 10 execuções das 3 melhores triplas {sensor, eixo(s),
algoritmo} para cada tipo de evento de direção. O melhor algoritmo de detecção
entre os avaliados é o MLP e o melhor sensor é o acelerômetro, exceto para o
evento de aceleração agressiva.
Ao agrupar os resultados por eventos, notamos que a aceleração agressiva é melhor detectada com o magnetômetro em conjunto com os algoritmos MLP ou SVM que
obtiveram a mesma performance máxima. Na freada agressiva, a melhor tripla foi {acelerômetro, todos os eixos, MLP}. Para a curva agressiva à direita, o algoritmo MLP foi
o melhor classificador, obtendo a mesma performance máxima com o giroscópio (eixo y
apenas) e acelerômetro. O mesmo ocorreu com a curva agressiva à esquerda que também foi melhor detectada pelo MLP, obtendo performance máxima com o giroscópio,
acelerômetro e sensor de aceleração linear. A troca de faixa agressiva à direita foi melhor
detectada pela tripla {giroscópio, todos os eixos, MLP} que obteve o ROC Score máximo.
A troca de faixa agressiva à esquerda foi melhor detectada pela tripla {acelerômetro, y,
MLP}, mas seguida de perto por {sensor de vetor de rotação, todos os eixos, MLP}. O
evento não agressivo foi melhor classificado pela tripla {acelerômetro, y, MLP}. Por fim,
ao analisar os resultados, notamos que o algoritmo MLP em conjunto com o acelerômetro
83
figuram entre as 3 melhores performances na grande maioria dos eventos, com exceção
do evento de aceleração agressiva cujos melhores resultados não incluem o acelerômetro.
5. Conclusões e Trabalhos Futuros
Apresentamos neste trabalho uma avaliação quantitativa das performances dos algoritmos
MLP, SVM e Bagging de REPTree na detecção de eventos de direção utilizando dados
de sensores de smartphones Android. Obtivemos amostras de 7 tipos de eventos de direção por meio de um experimento no qual os dados de 6 sensores foram registrados
durante a execução dos referidos eventos em um veículo real. Os tempos iniciais e finais
de cada evento executado foram registrados para compor a ground-truth do experimento.
Os resultados de 10 execuções dos algoritmos de aprendizado para cada combinação de
sensor e eixo(s) mostram (i) quais combinações de sensor, eixo(s) e algoritmo de aprendizado melhor detectam cada tipo de evento de direção; (ii) que o algoritmo MLP obteve
as melhores performances; e (iii) que o acelerômetro se mostrou o sensor com melhores
performances, exceto para o evento de aceleração agressiva.
Como trabalhos futuros, esperamos realizar experimentos com viagens mais longas, com motoristas e modelos de smartphones diferentes e em condições de via, clima e
temperatura distintos para obter um conjunto maior e mais diversificado de amostras dos
eventos de direção. Também esperamos comparar algoritmos de aprendizado de máquina
adicionais, incluindo os baseados em lógica fuzzy e DTW. Por fim, pretendemos utilizar os melhores algoritmos e sensores identificados diretamente em um aplicativo para
smartphone Android a fim de detectar os eventos de direção em tempo real e, consequentemente, classificar o perfil de agressividade de direção do motorista.
Agradecimentos
Agradecemos ao Prof. Dr. Cleidson de Souza e aos colegas Sérgio Viademonte, Carolina Quintão e Adalberto Silva Júnior pelas conversas, perguntas, sugestões, inspirações
e ajuda na implementação deste trabalho. Agradecemos ao apoio financeiro recebido
através da Chamada 59/2013 MCTI/CT-Info/CNPq, processo 440880/2013-0.
Referências
Araujo, R., Igreja, A., de Castro, R., and Araujo, R. (2012). Driving coach: A smartphone
application to evaluate driving efficient patterns. In Intelligent Vehicles Symposium
(IV), 2012 IEEE, pages 1005–1010.
Blincoe, L., Miller, T. R., Zaloshnja, E., and Lawrence, B. A. (2015). The Economic and
Societal Impact of Motor Vehicle Crashes, 2010 (Revised). Technical report.
Castignani, G., Derrmann, T., Frank, R., and Engel, T. (2015). Driver behavior profiling
using smartphones: A low-cost platform for driver monitoring. Intelligent Transportation Systems Magazine, IEEE, 7(1):91–102.
Castignani, G., Frank, R., and Engel, T. (2013). Driver behavior profiling using
smartphones. In Intelligent Transportation Systems - (ITSC), 2013 16th International IEEE Conference on, pages 552–557.
Chang, C.-C. and Lin, C.-J. (2011). LIBSVM: A library for support vector machines.
ACM Transactions on Intelligent Systems and Technology, 2:27:1–27:27. Software
available at http://www.csie.ntu.edu.tw/~cjlin/libsvm.
84
Evans, L. (2004). Traffic safety. Science Serving Society.
Fawcett, T. (2006). An introduction to roc analysis. Pattern Recogn. Lett., 27(8):861–874.
Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., and Witten, I. H. (2009).
The weka data mining software: An update. SIGKDD Explor. Newsl., 11(1):10–18.
Handel, P., Ohlsson, J., Ohlsson, M., Skog, I., and Nygren, E. (2014). Smartphone-based
measurement systems for road vehicle traffic monitoring and usage-based insurance.
Systems Journal, IEEE, 8(4):1238–1248.
Johnson, D. and Trivedi, M. (2011). Driving style recognition using a smartphone as a
sensor platform. In Intelligent Transportation Systems (ITSC), 2011 14th International
IEEE Conference on, pages 1609–1615.
N. Haworth, M. S. (2001). Driving to Reduce Fuel Consumption and Improve Road
Safety. Road Safety Research, Policing and Education Conference, 2001, Melbourne,
Victoria, Australia, (5):7.
Paefgen, J., Kehr, F., Zhai, Y., and Michahelles, F. (2012). Driving behavior analysis
with smartphones: Insights from a controlled field study. In Proceedings of the 11th
International Conference on Mobile and Ubiquitous Multimedia, MUM ’12, pages
36:1–36:8, New York, NY, USA. ACM.
Saiprasert, C., Pholprasit, T., and Pattara-Atikom, W. (2013). Detecting driving events
using smartphone. In Proceedings of the 20th ITS World Congress.
Saiprasert, C., Thajchayapong, S., Pholprasit, T., and Tanprasert, C. (2014). Driver behaviour profiling using smartphone sensory data in a v2i environment. In Connected
Vehicles and Expo (ICCVE), 2014 International Conference on, pages 552–557.
Sakoe, H. and Chiba, S. (1978). Dynamic programming algorithm optimization for spoken word recognition. Acoustics, Speech and Signal Processing, IEEE Transactions
on, 26(1):43–49.
Skog, I., Handel, P., Ohlsson, M., and Ohlsson, J. (2013). Challenges in smartphonedriven usage based insurance. In Global Conference on Signal and Information Processing (GlobalSIP), 2013 IEEE, pages 1135–1135.
Van Mierlo, J., Maggetto, G., van de Burgwal, E., and Gense, R. (2004). Driving style and
traffic measures - influence on vehicle emissions and fuel consumption. 218(D1):43–
50+.
Van Mierlo, J., Maggetto, G., Van de Burgwal, E., and Gense, R. (2005). Driving style and
traffic measures-influence on vehicle emissions and fuel consumption. Proceedings of
the Institution of Mechanical Engineers, Part D: Journal of Automobile Engineering,
218(1):43–50.
Xiaoqiu, F., Jinzhang, J., and Guoqiang, Z. (2011). Impact of driving behavior on the
traffic safety of highway intersection. In Measuring Technology and Mechatronics Automation (ICMTMA), 2011 Third International Conference on, volume 2, pages 370–
373.
85

WoCCES - SBRC 2016 - Universidade Federal da Bahia

Transcrição

Documentos relacionados

(ANTONIO BOY) CPF: 719.746.107-30 Serra, 13 de julho de 2016 DE

termo de dispensa de licitação 022/2016

Decreto N.º 024 de 01 de abril de 2016 ? Nomeia Assessores

Best of ASCO - Instituto de Oncologia Kaplan

EXTRATO DE CONTRATO Nº 92/2016 CONTRATADA CHIQUITO E

autorização - Anime Friends

Gestão Fiscal - Câmara Municipal de Heliodora

VLADIMIR DE SÁ BARROS GUERREIRO Membro CLAUDIA

final-four - taça da madeira - juniores

CANDIDATOS CLASSIFICAÇÃO GLAUCIA ANTONIA CARNEIRO