Gerência de redes em malha sem fio: integrando o MAD ao MeshAdmin

(1)

Wilker de Oliveira Delfino

Gerência de Redes em Malha Sem Fio:

Integrando o MAD ao MeshAdmin

Niterói

(2)

Ficha catalográfica automática - SDC/BEE

Bibliotecária responsável: Fabiana Menezes Santos da Silva - CRB7/5274 D278g De Oliveira Delfino, Wilker

Gerência de Redes em Malha Sem Fio: Integrando o MAD ao MeshAdmin / Wilker De Oliveira Delfino ; Célio Vinicius Neves de Albuquerque, orientador. Niterói, 2018.

53 p. : il.

Trabalho de Conclusão de Curso (Graduação em Sistemas de Informação)-Universidade Federal Fluminense, Escola de Engenharia, Niterói, 2018.

1. Rede de comunicação de computadores . 2. Inteligência artificial. 3. Aprendizado de máquina. 4. Produção

intelectual. I. Título II. Neves de Albuquerque,Célio Vinicius , orientador. III. Universidade Federal Fluminense. Escola de Engenharia. Departamento de Ciência da Computação. CDD

(3)

-Wilker de Oliveira Delfino

Gerência de Redes em Malha Sem Fio:

Integrando o MAD ao MeshAdmin

Trabalho de Conclusão de Curso apresentado ao Curso de Bacharelado em Sistemas de In-formação, como parte dos requisitos necessá-rios para a obtenção do título de Bacharel em Sistemas de Informação.

Universidade Federal Fluminense

Instituto de Computacção

Sistemas de Informação

Orientador: Célio Vinicius Neves de Albuquerque

Niterói

(4)

(5)

Agradecimentos

Principalmente à minha mãe Marlene, sem a qual certamente não teria chegado até aqui. Que tem me dado todo o apoio o suporte necessário para trilhar e agora, concluir este caminho. Agradeço às minhas irmãs Maria Eduarda e Ruth Emanuelle, pelo suporte e apoio durante essa difícil fase da minha vida.

Agradecimento especial ao meu professor e também orientador Célio Vinícius pelo exce-lente trabalho tanto ensinando como também me orientando.

Ao Laboratório Mídiacom, e a seus professores sempre fazem o que está ao seu alcance para proporcionar a nós alunos sempre o melhor ambiente de trabalho possível.

Quero agradecer também à Universidade Federal Fluminense e ao Instituto de Computa-ção e seus excelentes professores que tanto me ensinaram e ajudaram a chegar até aqui.

(6)

Resumo

Redes em malha sem fio, ou Redes Mesh, são alternativas de baixo custo às tradicionais redes infraestruturadas, fibra ótica e satélite, para prover acesso a banda larga e outros serviços. Outras vantagens estão na facilidade e velocidade de implantação especialmente em locais carentes de infraestrutura, devido à sua natu-reza autoconfigurável e dispensa da necessidade de infraestrutura para transmissão de dados, que é feita em saltos através de seus múltiplos nós.

No entanto sua gerência é complicada devido ao dinamismo da rede causado pela mudança na qualidade dos enlaces e consequente alterações nas melhores rotas. Por conta disso foi desenvolvido um sistema para gerência de redes em malha sem fio, MeshAdmin(VALLE; MUCHALUAT-SAADE,2012) com o objetivo de atender aos requisitos necessários para a gerência deste tipo de rede como: Coleta de Dados, Armazenamento de Dados, Monitoramento, Controle de Usuários e Configuração da Rede. Sua construção é modular, de forma que novos módulos podem ser desen-volvidos e integrados a plataforma original.

O Módulo Autonômico de Diagnóstico, MAD(FERREIRA,2017), surgiu da neces-sidade da detecção e diagnóstico automatizado de falhas relacionadas à operação de redes Mesh alimentadas por energia solar, que podem ser implantadas em lo-cais de difícil acesso, como por exemplo a rede mesh implantada no projeto RE-MOTE(SIQUEIRA,2015) que desde o início de sua operação apresentou problemas como desalinhamento das antenas, sombra no painel solar, bateria defeituosa entre outros.

O objetivo deste trabalho é realizar a integração entre o Módulo Autonômico de Di-agnóstico, que emprega técnicas de mineração de dados e aprendizado de máquina e a plataforma de gerência de redes em malha sem fio(MeshAdmin) permitindo ao administrador da rede acompanhar em tempo real o diagnóstico de funcionamento da rede.

(7)

Abstract

Wireless Mesh Networks, are low cost alternatives to traditionals wired net-works, fiber optic and satellite, to provide broad access and other services.Other advantages are the ease and speed of deployment especially in locations lacking infrastructure, due to its self-configuring nature and exemption from the need for infrastructure for data transmission, which is made in jumps through its multiple nodes. However, its management is complicated due to the dynamism of the network caused by changes in the quality of the links and consequent changes in the best routes. Because of this a system was developed for managing wireless mesh networks, MeshAdmin(VALLE; MUCHALUAT-SAADE,2012), with the objective of meeting the necessary requirements for the management of this type of network as: Data Collection, Data Storage, Monitoring, User Control and Network Configuration.Its construction is modular, so that new modules can be developed and integrated into the original platform. The Módulo Autonômico de Diagnóstico, MAD(FERREIRA,

2017), It arose from the need for automated detection and diagnosis of failures re-lated to the operation of wireless mesh networks powered by solar energy,which can be deployed in difficult-to-reach locations such as the mesh network deployed in the REMOTE project(SIQUEIRA, 2015), which since the beginning of its operation has presented problems such as antenna misalignment, shadow on the solar panel, defective battery among others.The goal of this work is to integrate the Autonomic Module of Di-agnostic, which employs data mining and machine learning techniques and the wireless mesh network management platform (MeshAdmin), allowing the network administrator to monitor in real time the diagnosis of network operation.

(8)

Lista de ilustrações

Figura 1 – Interface Principal do MeshAdmin. Fonte: Captura de Tela da

Plata-forma. . . 16

Figura 2 – Arquitetura MeshAdmin. Fonte:(VALLE; MUCHALUAT-SAADE, 2012, p.37) . . . 17

Figura 3 – Painel do Administrador. Fonte: Captura de Tela da Plataforma. . . . 18

Figura 4 – Adição de novo Nó. Fonte: Captura de Tela da Plataforma. . . 19

Figura 5 – Exibição de métricas coletadas pelo Módulo de Coleta. Fonte: Captura de Tela da Plataforma. . . 20

Figura 6 – Etapas da Descoberta de Conhecimento. Adaptado de: https://www.researchgate.net/ figure/Knowledge-discovery-process_fig3_258386628. . . 21

Figura 7 – Matriz de Confusão para Classificador SVM. Adaptado de (FERREIRA, 2017, p.6) . . . 22

Figura 8 – Arquitetura Proposta . . . 24

Figura 9 – Ciclo de Diagnóstico MAD no MeshAdmin . . . 26

Figura 10 – Arquitetura do Django Celery utilizando o RabbitMQ. adaptado de: http://rodrigoreis.com/wp-content/uploads/image/ Imagens/django_celery_architecture.png 28 Figura 11 – DJCelery no painel de Administração Django . . . 29

Figura 12 – Resultado MAD com Diagnóstico a cada um minuto . . . 32

Figura 13 – Resultado MAD com Diagnóstico Individual . . . 33

Figura 14 – Resultado MAD com Diagnóstico positivo . . . 34

Figura 15 – Diagrama de Casos de Uso . . . 39

Figura 16 – Diagnóstico Completo da Rede . . . 41

Figura 17 – Diagnóstico de um Nó da Rede . . . 42

Figura 18 – Consulta ao Log de Diagnósticos dos Nós. . . 44

Figura 19 – Adição de Intervalo no DJCelery - Passo 1 . . . 48

Figura 22 – DJCelery Crontabs . . . 50

Figura 23 – Instalando o SVM via Weka CLI. Fonte: Captura de tela do Software Weka. . . 51

(9)

Lista de tabelas

(10)

Lista de abreviaturas e siglas

MAD Módulo Autonômico de Diagnóstico

SVM Support Vector Machines

SWMN Solar Wireless Mesh Network

Kbit/s Kilobits por segundo

Wi-Fi Wireless Fidelity

CPU Central Processing Unit

SNMP Simple Network Management Prococol

IETF Internet Engineering Task Force

(11)

Sumário

1 Introdução. . . 11

1.1 Objetivos do Trabalho de Conclusão de Curso . . . 14

1.2 Organização . . . 14

2 Trabalhos Relacionados . . . 15

2.1 Plataforma de Gerência de Redes em Malha sem Fio -MeshAdmin . . . 15

2.2 Módulo Autonômico de Diagnóstico - MAD . . . 20

3 Processo de Integração . . . 23

3.1 Arquitetura Proposta . . . 23

3.2 Casos de Uso . . . 24

3.3 Requisitos Funcionais . . . 24

3.4 Requisitos Não-Funcionais . . . 25

3.5 Arquitetura do Módulo Adicional Proposto . . . 25

3.6 Implementação . . . 27

4 Resultados Finais . . . 32

4.1 Teste 1 - Teste de diagnóstico completo da rede em intervalos predefinidos de 1 minuto, sem a interferência do administrador.. . . 32

4.2 Teste 2 - Teste de diagnóstico da rede para um nó a partir da tela inicial . 33 4.3 Teste 3 - Teste de diagnóstico da rede para nós utilizando o banco de dados de treinamento do modelo de classificação utilizado no MAD. . . 33

5 Conclusão . . . 35

5.1 Trabalhos futuros . . . 35

Referências . . . 36

Apêndices

38

APÊNDICE A Diagrama de Casos de Uso . . . 39

APÊNDICE B Casos de Uso . . . 40

APÊNDICE C Utilizando o DJCelery . . . 48

(12)

SUMÁRIO 10

C.2 Criando Horários Agendados para Tarefas Utilizando o Crontab . . . 48

APÊNDICE D Adição do SVM ao Weka . . . 51

(13)

11

1 Introdução

Uma rede de computadores é formada a partir da ligação de um ou mais compu-tadores entre si. Esta ligação pode feita utilizando diversas tecnologias para sua conexão física, como cabos coaxiais, de pares trançados e até mesmo através de ondas de rádio.

Elas são atualmente parte natural do dia a dia da maioria das pessoas, seja na conexão de seus computadores à Internet via banda larga, conexão discada através da linha de telefone, ou da conexão à rede wifi do shopping. E têm como principal objetivo a conexão a rede mundial de computadores, a Internet.

A Internet surgiu após a evolução da ARPAnet em criada 1969, uma das primeiras iniciativas de conexão de computadores em rede, e que tinha objetivo a interconexão de computadores militares e departamentos de pesquisas do governo americano, até se tornar uma rede pública no final da década de 1970.

Durante seu desenvolvimento muitos protocolos de comunicação foram criados, para garantir que os computadores pudessem comunicar-se entre si e entender uns aos outros. Como o protocolo TCP/IP, que é utilizado até hoje na Internet.

A conexão física desses computadores era feita através das redes de telefonia que tinham velocidade de 56 Kbit/s. Deste modo, a rede era criada através de cabos que conectavam os computadores.

Com a evolução da tecnologia, o modo de interconexão dos computadores em redes também evoluiu, passando das tradicionais conexões via cabo, como antigo padrão coaxial e conectores BNC e o atual padrão ethernet, que utiliza cabos metálicos de par trançado para a conexão, chegando até as populares conexões de rede sem fio. As redes sem fio, também conhecidas como Wireless Fidelity (Wi-Fi), utilizam ondas de rádio e o padrão IEEE 802.11 para a comunicação entre si.

Para que a comunicação entre computadores ligados a uma rede seja possível, são necessárias as definições de diversos padrões de comunicação, conhecidos como protocolos. Estes protocolos definem de que maneira ocorrerá a comunicação entre os participantes, como por exemplo, quando um deverá enviar ou receber dados.

Em uma rede um pouco mais complexa, como uma rede interna que se conecta a outra, como a Internet, as mensagens enviadas de um computador a outro passam através de vários roteadores, em um caminho com múltiplos saltos e, talvez vários caminhos possíveis. Para que a mensagem chegue corretamente ao destinatário é necessária a criação de um protocolo que possua mecanismos para indicar não apenas o caminho correto para a mensagem chegar ao destino mas também o melhor caminho até este destino. Estes tipos

(14)

Capítulo 1. Introdução 12

de protocolos são denominados protocolos de roteamento e podem ser baseados em várias métricas diferentes como o caminho com menor distância física, com o menor número de salto, menor tráfego no momento, entre outros.

A redes sem fio tradicionais são criadas por roteadores que implementam o padrão IEEE 802.11, e criam uma área de conexão que permite que dispositivos se conectem dentro da sua área de alcance, e que varia de acordo com a potência de transmissão do sinal. Estas redes ainda dependem, no entanto, de uma infraestrutura de ponto de acesso para que os dispositivos possam comunicar-se entre si, e com dispositivos em outras redes, como as redes cabeadas.

Quando dois computadores são conectados diretamente via rádio, sem o uso de pontos de acesso intermediários, é criada uma conexão do tipo ad-hoc. Neste tipo de rede os próprios nós da rede agem como roteadores, encaminhando os pacotes até o seu destino. Este tipo de rede geralmente é criada de maneira temporária e também dispensa a necessidade de uma rede infraestruturada para a sua criação.

As redes em malha sem fio, ou Redes Mesh, são redes formadas a partir da ligação entre dois ou mais roteadores Mesh que atuam em modo ad-hoc, chamados nós mesh. São tipicamente estacionários e formam o backbone da rede. Eles utilizam principalmente o padrão IEEE802.11 (Wi-Fi) para comunicação e também servem como pontos de acesso para os clientes convencionais (AKYILDIZ; WANG,2009). Além disso, esses nós também roteiam os pacotes, salto a salto, até seu destino. Este destino pode ser interno, alcançado através da própria rede mesh, ou externo, alcançado através de um nó gateway conectado a uma rede externa, como a Internet.

As redes mesh se diferem fundamentalmente na ausência de uma infraestrutura para a transmissão dos dados, ou seja, dispensam a necessidade de cabos metálicos, fibra ótica, ou enlaces via satélite. A transmissão dos dados é feita via rádio utilizando alguns dos rádios dos roteadores mesh para criar o enlace e os outros como ponto de acesso para os clientes, que também podem se conectar utilizando outras tecnologias como a Ethernet.

Desta maneira são facilmente implantadas, inclusive, em locais de difícil acesso ou que passaram por desastres naturais. Como por exemplo a rede mesh implantada no pro-jeto REMOTE (MíDIACOM,2007) que instalou 41 nós ao longo da linha de transmissão de energia que liga a Usina Hidrelétrica de Machadinho(RS) à subestação de Campos Novos(SC), e que passa pela mata e outros locais sem infraestrutura de telecomunicação. Esta rede é alimentada por painéis solares, evidenciando assim a flexibilidade e facilidade de implantação destas.

Falhas na rede são um problema comum em redes de computadores e podem se manifestar como defeito físico no cabos de rede, em placas de rede ou em dispositivos da rede como roteadores e impressoras de rede. À medida que a quantidade de dispositivos

(15)

aumenta, cresce também a complexidade da rede e a dificuldade gerenciar manualmente e detectar as falhas e outros problemas de performance.

Por conta disto, foram criadas ferramentas para gerência de redes onde uma en-tidade gerenciadora é uma aplicação geralmente administrada por um gerente de rede e que coleta dados da rede (KUROSE, 2005), processa, analisa a apresenta informações de gerência da rede, como informações sobre os dispositivos gerenciados (roteadores, hubs, modem, etc).

Estes dispositivos gerenciados podem integrar vários objetos gerenciados que são partes de hardware como as placas de interface rede e seus os parâmetros para configuração das peças de hardware e software como os protocolos utilizados.

Para que a coleta de dados seja possível é necessária a definição de um padrão, um protocolo de gerenciamento de rede. Este protocolo é utilizado para comunicação entre a entidade gerenciadora e o agente de gerenciamento de rede, que é um processo executado no dispositivo gerenciado.

Este protocolo é utilizado para que os agentes de gerenciamento de redes possam informar à entidade gerenciadora informações sobre eventos ocorridos tais como falha em dispositivos, informação sobre uso de CPU e consumo de memória além de outras métricas de utilização dos dispositivos da rede.

O protocolo mais popular e utilizado para gerenciamento de redes é Simple Network Management Prococol(SNMP)(CASE, 1990) e que encontra-se atualmente em sua ter-ceira versão, sendo utilizado como padrão para a gerência de redes complexas como a Internet e foi definido por pesquisadores do IETF.

A topologia dinâmica é uma característica intrínseca a redes em malha sem fio, onde a ligação entre dois nós pode ser interrompida a qualquer instante. Esta característica ao mesmo tempo que provê resiliência à rede, eleva a complexidade de sua gerência. Deste modo, foram propostos alguns frameworks para auxiliar na gerência de redes em malha sem fio.

Dentre os diversos frameworks foi desenvolvido o MeshAdmin(VALLE; MUCHALUAT-SAADE,2012) que utiliza uma verão mais leve do SNMP ideal para dispositivos restritos (Mini SNMP), monitora a rede periodicamente coletando métricas da rede como tensão e corrente no painel solar e bateria, uso do processador, além de coletar estatísticas de desempenho da rede, como pacotes enviados, atraso da rede, vazão, qualidade dos enlaces e etc.

Falhas como bateria defeituosa, painel solar sujo, antenas desalinhadas e etc, po-dem interferir no funcionamento da rede fazendo com que nós sejam desligados ou tornem-se inalcançáveis. Uma ferramenta detornem-senvolvida para auxiliar na gerência de redes é o Módulo Autonômico de Diagnóstico (MAD)(FERREIRA, 2017) que utiliza técnicas de

(16)

aprendizado de máquina e inteligência artificial para detectar falhas em rede sem fio ali-mentadas por painéis solares.

Apesar do MAD utilizar as métricas da rede coletadas pelo MeshAdmin para rea-lizar o seu diagnóstico, seu uso é totalmente manual, sendo necessário executar o sistema de diagnóstico separadamente. Ou seja, não há integração entre as duas ferramentas, que possibilite a execução do MAD e reporte o estado da rede diretamente da interface do MeshAdmin.

1.1 Objetivos do Trabalho de Conclusão de Curso

Este Trabalho de Conclusão de Curso tem como objetivo realizar a integração do Módulo Autonômico de Diagnóstico à Plataforma de Gerência de Redes em Malha sem Fio, permitindo desta maneira ao administrador da rede agendar horários para a execução do diagnóstico do estado da rede, execução em intervalos regulares, além de execução sob demanda, a critério do usuário. Para isto, o administrador terá um painel de administração à disposição onde poderá agendar a execução das tarefas, além de botões de ação na interface da plataforma de gerência que irá disparar os eventos necessários para o diagnóstico.

1.2 Organização

Este trabalho está organizado da seguinte forma. No capítulo 2 são apresentados de maneira mais aprofundada os trabalhos relacionados que são os alvos deste trabalho, apresentando detalhes sobre sua implementação, e a motivação para o desenvolvimento destes sistemas de gerência de redes. No capítulo 3 é apresentada a proposta de integração que é o objetivo deste trabalho, apresentando a nova arquitetura proposta, os casos de uso, além de detalhes da implementação como os softwares utilizados e estratégia de integração. No capítulo 4 são apresentados testes de uso do sistema para validação da integração realizada e no capítulo 5 temos a conclusão e proposta de trabalhos futuros.

(17)

15

2 Trabalhos Relacionados

2.1 Plataforma de Gerência de Redes em Malha sem Fio

-MeshAdmin

O MeshAdmin(VALLE; MUCHALUAT-SAADE,2012) foi desenvolvido como parte do módulo de Gerência para o projeto REMOTE que em 2009 implantou com sucesso uma rede em malha sem fio alimentada por painéis solares de aproximadamente 50km de extensão na linha de transmissão de energia entre a Hidrelétrica de Machadinho e a subestação de Campos Novos.

Esta rede foi implantada utilizando roteadores mesh de baixo custo especialmente desenvolvidos pela equipe do projeto, e tem como característica a adição de sensores que monitoram o estado do roteador, como temperatura, luminosidade, tensão na bateria e no painel solar. Estes roteadores foram projetados para trabalharem de forma autônoma, utilizando a energia solar como principal fonte de energia, utilizando baterias de chumbo-lítio para o armazenamento da energia e alimentação durante a noite e outros períodos de ausência ou insuficiência da luz solar.

O MeshAdmin foi desenvolvido de forma modular, desta maneira cada módulo do sistema é independente e responsável por realizar uma tarefa específica na gerência da rede.

Esta arquitetura facilita a criação de extensões que adicionem novas funções à plataforma de gerência, como por exemplo, a adição do Módulo Atonômico de Diagnóstico, que é o objeto deste trabalho.

(18)

Capítulo 2. Trabalhos Relacionados 16

Figura 1: Interface Principal do MeshAdmin. Fonte: Captura de Tela da Plataforma.

A atual arquitetura do MeshAdmin está definida da seguinte maneira:

∙ Painel de Configuração da Ferramenta ∙ Módulo de Coleta

– Informação de Nós – Informação de Enlaces

(19)

Figura 2: Arquitetura MeshAdmin. Fonte:(VALLE; MUCHALUAT-SAADE,2012, p.37)

∙ Módulo de Armazenamento de Dados ∙ Módulo de Alerta

∙ Módulo de Exibição

– Visualização da Topologia – Informações dos Nós – Visualização de Alerta

No painel de configuração (figura3) o administrador da rede tem a possibilidade de adicionar as redes mesh monitoradas, os nós existentes na rede, as métricas de roteamento e seus intervalos, além de poder editar as configurações destes itens.

Durante adição de nós (figura4) é necessário informar os seguintes parâmetros:

∙ Identificar do nó, que deve ser único na rede;

∙ Latitude e Longitude, que serão utilizados para posicionar o nó no mapa;

(20)

Figura 3: Painel do Administrador. Fonte: Captura de Tela da Plataforma.

∙ Discos e interfaces que serão monitorados; ∙ Rede mesh a qual o nó pertence;

∙ Tipo de alimentação utilizada pelo roteador, energia solar ou POE.

O módulo de coleta é responsável por coletar os dados de informação dos roteadores da rede. Ele utiliza o protocolo Mini SNMP Daemon para coletar métricas referentes aos nós da rede, como tensão na bateria, percentual de uso de CPU do roteador, espaço em disco, tensão no painel solar, entre outros. Este módulo coleta também, informações sobre os enlaces como os endereços, qualidade dos enlaces baseados nas métricas de qualidade definidas além dos nós alcançáveis na rede. Este protocolo foi escolhido pois se adequa bem a roteadores de baixo custo como o desenvolvido para o projeto REMOTE, e que tipicamente possuem recursos limitados de memória e de processamento em comparação a modelos comerciais mais caros.

As informações coletadas pelo módulo de coleta, são armazenadas pelo Módulo de Armazenamento de Dados que utiliza o Banco de Dados Relacional Postgres para realizar a persistência dos dados, ele armazena também os alertas gerados pelo módulo de alerta além dos Logs do execução das rodadas de coletas de dados.

O módulo de exibição é responsável por exibir as informações coletadas pelo mó-dulo de coleta permitindo a plotagem de gráficos como o da figura 5, visualização da topologia em tempo real e também a exibição dos alertas gerados pelo módulo de alerta.

(21)

Figura 4: Adição de novo Nó. Fonte: Captura de Tela da Plataforma.

O módulo de alerta notifica o administrador da rede sobre problemas encontrados, tais como um nó cadastrado que não pôde ser alcançado pelo módulo de coleta, divergência de configuração cadastrada no MeshAdmin e as encontrada nos roteadores e etc.

Ao planejar a implantação da rede é necessário definir qual, ou quais os nós da redes serão os gateways. Estes gateways são nós especiais na rede que têm como função servir como ponto de conexão às redes externas como por exemplo a Internet.

(22)

Figura 5: Exibição de métricas coletadas pelo Módulo de Coleta. Fonte: Captura de Tela da Plataforma.

Estes nós gateways também são os responsáveis por responderem às consultas re-alizadas pelo módulo de coleta e por conta do protocolo de roteamento utilizado (OLSR-ML)(PASSOS,2006), cada nó mantém uma visão completa da topologia da rede, dispen-sando assim a necessidade de consulta a todos os nós da rede pelo servidor. Isto ajuda a evitar que a rede seja inundada com pacotes de controle, requisitando a cada roteador o qualidade do seu enlace e a sua tabela de roteamento com os nós alcançáveis por este. Desta maneira a topologia e qualidade dos enlaces pode ser verificada instantaneamente sem causar impacto na rede causado por atividades de controle da rede. No entanto, as métricas como uso do processador, memória RAM, carga na bateria dentre outros, ainda precisa ser consultada diretamente nos diversos nós da rede, pelo roteador, processo este que é realizado a cada 10 minutos.

2.2 Módulo Autonômico de Diagnóstico - MAD

Durante a operação da Rede em Malha sem fio implantada pelo projeto REMOTE na rede de transmissão de energia que liga a usina Hidrelétrica de Machadinho a subesta-ção de Campos Novos, ocorreram diversas falhas na rede que necessitavam uma inspesubesta-ção manual, que é cara, requer mão de obra especializada e às vezes implica o desligamento da rede.

A dificuldade da inspeção era agravada pelo difícil acesso ao roteadores que estão instalados nas torres de transmissão de energia que cruzam a mata. Por conta disto, foi identificada a necessidade de uma maneira automatizada de diagnóstico de falhas, problema este que já é amplamente estudado.

(23)

Por conta da dificuldade de modelagem de Rede, seu comportamento, uso, mu-danças na topologia, foram descartados o uso de uma solução analítica e a aplicação de um modelo estatístico particular. Portanto, a abordagem utilizando inteligência artificial foi escolhida.

O Módulo Autonômico de Diagnóstico (MAD)(FERREIRA, 2017) é um sistema para detecção de falhas em redes em malha sem fio alimentadas por painéis solares e que emprega técnicas de aprendizado de máquina e mineração de dados para inferir o estado dos nós da rede. Diferente de outras soluções presentes na literatura, esta abordagem é completamente autonômica e tem como vantagem a dispensa da necessidade de um modelo analítico ou o conhecimento de um especialista para diagnóstico.

O MAD foi desenvolvido para atuar em redes mesh alimentadas por painéis solares que possuam módulo de sensoriamento para a coleta de dados. O módulo de sensoreamento da rede mesh sobre qual o MAD foi desenvolvido consiste de dois sensores de temperatura LM35, um sensor de luminosidade LDR de 5mm, além de medidas da tensão e voltagem para a bateria, painel solar e fonte de energia principal.

Os dados coletados por estes sensores são gerenciados pelo MeshAdmin, que faz a coleta a cada 10 minutos, e utilizados para alimentar o MAD na etapa de extração de dados pelo MAD. O MAD utiliza mineração de dados preditiva, que consiste na tentativa de prever o valor desconhecido de um atributo, baseado na análise histórica de uma base de dados de treinamento previamente armazenada.

A descoberta de conhecimento em uma base de dados ocorre através de cinco pas-sos: seleção dos atributos, pré-processamento (limpeza e enriquecimento dos dados), trans-formação (caso necessário), mineração e interpretação e avaliação dos resultados(FAYYAD, 1996).

Figura 6: Etapas da Descoberta de Conhecimento. Adaptado de: https://www.researchgate.net/ figure/Knowledge-discovery-process_fig3_258386628.

O MAD tem como objetivo inferir falhas nas seguintes categorias: Alto Uso do Processador, Alto consumo de memória RAM, Falha na bateria, baixa eficiência do Painel

(24)

Solar, desalinhamento nas antenas e defeitos nos conectores RF, há também a categoria para funcionamento normal. A escolha destas categorias é denominada dicionário de falhas e foram escolhidas de acordo com a experiência obtida pela equipe na manutenção de Redes Mesh.

Na abordagem utilizada (aprendizado de máquina), para realizar as inferências de diagnóstico é necessária a criação de uma base de dados de treinamento que irá conter as amostras de dados dos sensores capturados durante a ocorrência das falhas que se deseja diagnosticar. Assim, foram provocadas falhas na rede e coletados os dados para monitorar o efeito que estas causavam na rede.

Sobre esta base, foram testados alguns classificadores de diferentes modelos de classificação: modelos estatísticos, lineares, baseados em regras, baseados em instância e dividir para conquistar (WITTEN,2016). Os classificadores correspondes a estes modelos são respectivamente: Naive Bayes (RISH,2001), Máquina de vetores de suporte (Support Vector Mechines - SVM) (CHANG; LIN, 2011), Tabela de Decisão (KOHAVI, 1995), k-Nearest Neighbors(k-NN) (AHA, 1991) e o algoritmo C4.5 (QUINLAN,2014).

Figura 7: Matriz de Confusão para Classificador SVM. Adaptado de (FERREIRA,2017, p.6)

O classificador que teve a maior acurácia em cada métrica testada foi o SVM com parâmetros kernel linear e parâmetro C = 100, apesar de uma pequena confusão (menor que 8%) entre as classes de Baixa eficiência no Painel Solar e Defeito na Bateria, conforme pode ser vista na matriz de confusão na figura 7. Desta maneira, o SVM foi o escolhido para ser utilizado, pois ao serem listadas as duas prováveis causas a acurácia foi de 93,7%, provando assim ser possível utilizar este método para diagnosticar falhas em WMN.

(25)

23

3 Processo de Integração

3.1 Arquitetura Proposta

Após reuniões sobre o escopo do projeto, foram identificados alguns requisitos funcionais e não funcionais para a realização da integração entre os dois sistemas.Além disso ficou definido também que a integração entre os dois sistemas seria forte, de modo que todo o MAD seria completamente incorporado ao MeshAdmin.

Foi identificada a necessidade de um sistema de diagnóstico automatizado que pudesse identificar os problemas da rede, de maneira proativa sem a intervenção do admi-nistrador da rede, para que tão logo um problema seja detectado, ele seja informado via módulo de alerta. Desta maneira, é dispensada a necessidade do administrador da rede solicitar o diagnóstico de seu estado atual, de maneira explícita, deixando-o livre para realizar outras tarefas de gerência.

Esta maneira automática de diagnóstico, permite também a identificação e conse-quente aviso/informação de problemas quando o administrador da rede não está logado na plataforma. Como fora do horário de expediente, durante a madrugada, e etc. Assim, ele poderá ser notificado sobre problemas encontrados via email.

O sistema deve permitir também ao administrador, a execução a qualquer mo-mento do diagnóstico da rede, de maneira explícita, sem a necessidade de se esperar o período, intervalo ou hora predeterminada para a execução deste. Assim, o sistema atua de forma reativa, de acordo com necessidade do administrador.

O administrador da rede deve ser informado sobre a possível causa da falha na rede (caso detectada), falha esta que é inferida pelo MAD e será reportada ao módulo de alerta. Desta maneira o administrador será capaz de tomar as ações necessárias para tratar o problema encontrado.

Para atingir o objetivo de integração definido aqui, propõe-se a criação de um módulo adicional ao MeshAdmin que irá implementar o MAD e utilizar o seu modelo de classificação treinado. Isto permitirá ao administrador da rede iniciar o diagnóstico de forma ativa ou obtê-lo de forma passiva, além de permitir a configuração de parâme-tros de execução do MAD, como intervalo de diagnóstico ou horário programado para o diagnóstico.

(26)

Capítulo 3. Processo de Integração 24

Figura 8: Arquitetura Proposta

3.2 Casos de Uso

Os casos de uso identificados no Apêndice B irão resolver as necessidades identifi-cadas, como a necessidade do diagnóstico da rede ser executado de maneira explícita, ou seja, diante do comando do administrador. Mas também sem a intervenção do adminis-trador, de maneira automática, em horário predefinidos ou de maneira periódica.

3.3 Requisitos Funcionais

Requisitos funcionais são requisitos básicos e essenciais, necessários para que um software atinja o objetivo desejado. Abaixo segue a lista dos requisitos funcionais identi-ficados durante a fase de planejamento.

∙ RF - 1 - O sistema deverá ser acoplado dentro do MeshAdmin;

∙ RF - 2 - O sistema deverá extrair do banco de dados do MeshAdmin as informações necessárias para realizar o diagnóstico.

∙ RF - 3 - O sistema deverá apresentar mensagem de erro no campo de mensagens ao administrador da rede, informando sobre a possível falha com maior probabilidade de estar ocorrendo.

∙ RF - 4 - O sistema deverá permitir diagnóstico de nós individuais da rede a qualquer momento pelo administrador do sistema.

(27)

∙ RF - 5 - O sistema deverá ter um botão para diagnóstico de toda a rede a qualquer momento pelo administrador do sistema.

∙ RF - 6 - O sistema deverá permitir a escolha de qualquer data.

∙ RF - 7 - O sistema deverá permitir a escolha de um intervalo predeterminado para a execução do diagnóstico.

∙ RF - 8 - O sistema deverá ser capaz de executar o diagnóstico sem a intervenção do administrador da rede.

∙ RF - 9 - O sistema deverá ser ser capaz de armazenar os diagnósticos já realizados. ∙ RF - 10 - O sistema deverá permitir a visualização de diagnósticos anteriores.

3.4 Requisitos Não-Funcionais

∙ RNF - 1 - O sistema deverá informar os problemas encontrados em tempo real. ∙ RNF - 2 - O sistema poderá ter um horário definido pelo usuário em que irá rodar

o diagnóstico.

∙ RNF - 3 - O intervalo padrão dos dados extraídos e da base e utilizados para realizar a inferência será o das últimas 24 hrs, intervalo que apresenta acurácia satisfatória(FERREIRA, 2017). O

3.5 Arquitetura do Módulo Adicional Proposto

Devido à abordagem de inteligência artificial utilizada, para que o MAD consiga inferir o estado atual da rede e classificá-la em alguma das classe de problemas, é necessário um conjunto mínimo de dados. Por conta disto, o módulo adicionional proposto será acoplado ao MeshAdmin e utilizará o módulo de armazenamento como fonte de dados para realizar a inferência.

Este módulo adicional será responsável por acoplar os seguintes recursos:

∙ Algoritmo para extração, seleção, pré-processamento e transformação dos dados do módulo de armazenamento;

∙ Algoritmo de classificação dos dados;

∙ Implementar a integração com o módulo de alerta; ∙ Suporte a inserção de períodos de tempo personalizados;

(28)

Figura 9: Ciclo de Diagnóstico MAD no MeshAdmin

Tabela 1: Mensagens adicionais propostas para o MeshAdmin

Nível Mensagem Função

Crítico <Classe do Problema> problem found in the last 24 hours of <data de diagnóstico>.

Informar o possível problema detec-tado no nó nas 24 horas anteriores à data solicitada.

Info No problems found in the last 24 hours of <data de diagnóstico>.

Informar o funcionamento normal do nó nas 24 horas anteriores à data so-licitada.

∙ Tarefa para execução do MAD de forma independente.

Na figura 9 podem ser observadas etapas necessárias para a realização do diag-nóstico completo desde a coleta dos dados até o armazenamento do diagdiag-nóstico gerado e posterior alerta. Em destaque as etapas que compõem as novas funcionalidades adiciona-das ao MeshAdmin.

Propõe-se também a adição de novas mensagens ao módulo de alerta do MeshAd-min. Esta mensagens serão provenientes do diagnóstico do MAD, e auxiliarão o admi-nistrador da rede na identificação de falhas e na tomada de decisão para início de ações corretivas rapidamente. Estas mensagens serão adicionadas nas categorias já existentes: Crítico, para quando o diagnóstico do MAD reportar uma possível falha identificada em um nó da rede e Info, para quando o diagnóstico do MAD reportar Funcionamento Nor-mal. As novas mensagens, os níveis em que se encaixam e a função a serem incorporadas ao MeshAdmin são demonstradas na Tabela 1onde <Classe do Problema> uma das clas-ses de problemas inferidas pelo MAD: Alto uso do processador, alto consumo de memória RAM, falha na bateria, baixa eficiência do painel solar, desalinhamento das antenas e defeito nos conectores do cabo RF, além do funcionamento normal.

(29)

3.6 Implementação

O MeshAdmin foi implementado em Django(DJANGO,2012), um framework para desenvolvimento web baseado em camadas que utiliza um padrão denominado Model-Viewer-Template - MVT e é escrito utilizando a linguagem de Programação Python. Um projeto Django pode ser composto por uma ou mais aplicações que podem ou não ser independentes entre si chamadas apps.

Cada novo app Django é gerado com arquivos padrão que são responsáveis pela de-finição dos dados (arquivo models.py), lógica da aplicação para exibição de dados(arquivo views.py), e admin.py que é responsável por registar o app e permitir a administração dos modelos de dados a partir do painel de administração do framework Django.

Devido à necessidade de um diagnóstico independente da ação do administrador e em intervalos regulares ou horário predefinidos por este, foi adicionado suporte à criação de fila tarefas e trabalhos assíncronos. Este serviço permite a adição de tarefas em segundo plano para serem executadas quando um determinada condição é satisfeita.

Para suportar este serviço foi utilizado o pacote Celery(CELERY,2012), e para sua fácil manipulação através do Django foi utilizado o DJCelery(DJCELERY, 2012). Desta maneira, o administrador pode facilmente adicionar novas tarefas, definir intervalos e horários específicos para a execução da tarefa de diagnóstico da rede.

O Celery é uma fila de tarefas assíncrona baseada na passagem de mensagens, e é utilizado para balancear a carga de trabalho entre diversas máquinas ou threads. Estas mensagens podem ser por exemplo, adicionar uma nova tarefa à fila de execução ou o recebimento de mensagem de resposta de tarefa executada com sucesso. No entanto, para enviar e receber mensagens é necessária a utilização de uma aplicação externa. O RabbitMQ Server foi utilizado como servidor de mensagens e é responsável pela gerência da fila de mensagens de tarefas.

(30)

Figura 10: Arquitetura do Django Celery utilizando o RabbitMQ. adaptado de: http://rodrigoreis.com/wp-content/uploads/image/ Imagens/django_celery_architecture.png

O Celery utiliza arquivos de tarefas chamados de tasks.py para a execução de tarefas de maneira assíncrona(em segundo plano) ou síncrona. Estas tasks contêm o código Python das tarefas que se deseja executar, sendo acionadas por alguma mensagem como por exemplo um horário programado. Com o pacote DJCelery, o administrador pode facilmente criar intervalos ou adicionar horários programados que serão utilizados nos agendamentos das tarefas a partir do Painel de Administração do Django. O processo para a criação pode ser consultado no Apêndice C.

Na figura 11 podem ser observadas as opções adicionadas pelo DJCelery, dentre as quais podemos destacar as seguintes:

1. Crontabs - é responsável pelo cadastro de intervalos periódicos utilizando uma no-tação Crontab simplificada.

2. Intervals - é responsável pelo cadastro de intervalos periódicos utilizando a notação de tempo em minutos, segundos ou dias.

3. Periodic Tasks - é responsável pelo agendamento das tarefas utilizando algum dos intervalos de tempo cadastrado anteriormente.

As opções Tasks e Workers são funcionalidades providas pelo DJCelery mas não utilizadas neste trabalho.

(31)

Figura 11: DJCelery no painel de Administração Django

A utilização do Celery trás diversas vantagens como previnir a má prática da cria-ção de Threads secundárias manualmente no servidor, deixando toda a parte de gerência como a criação, destruição, verificação de condições, retorno do trabalho e reexecução em caso de erro para o framework. Deste modo a complexidade do desenvolvimento diminui e consequentemente o introdução de erros no desenvolvimento. Outra vantagem é permitir que outras tarefas que necessitem de agendamento para serem executadas, sejam gerenci-adas pelo Celery, como por exemplo a própria tarefa do módulo coleta que é executada a cada 10 minutos e atualmente é cadastrada diretamente utilizando o crontab, ou alguma tarefa que venha a ser implementada no futuro.

No entanto, um ponto negativo ao utilizar estes pacotes extras para o gerencia-mento de tarefas é o augerencia-mento na dificuldade de gerência dos pacotes adicionais instalados, principalmente durante a etapa de instalação da plataforma e de upgrades de software, onde a incompatibilidade entre versões pode causar instabilidade no sistema.

O MAD utiliza uma abordagem de aprendizado de máquina para realizar o di-agnóstico da rede, e portanto necessita de um modelo de classificação. Para treinar o modelo que será integrado ao MeshAdmin, utilizou-se uma cópia do banco de dados de treinamento utilizado na criação do modelo original(FERREIRA, 2017)- a ferramenta weka(HALL,2009), e o classificador SVM para gerar o modelo. O processo de adição do SVM ao Weka pode ser visto no Apêndice D.

Após a criação do modelo, foi desenvolvido um app Django chamado MAD que implementa todas as etapas necessárias para o diagnóstico da rede (Extração dos Dados,

(32)

Seleção/ Limpeza/Transformação, Classificação) e se comunica com o módulo de alerta para concluir as etapas de Alerta e Armazenamento.

Foi realizada também uma expansão do app tools do MeshAdmin para integrar o MAD à mesma sessão na tela do MeshAdmin e iniciasse o MAD através deste.

Além dos arquivos padrão do Django, foram criados os seguintes arquivos adicio-nais:

∙ mad_module.py; ∙ mad_weka.py; ∙ tasks.py;

O arquivo mad_module.py é uma biblioteca que implementa as funções necessárias para as etapas de Extração, Seleção, Limpeza e Transformação dos dados extraídos do banco de dados, em um arquivo do tipo .arff. Este arquivo contém os dados formatados de maneira que pode ser interpretado pela ferramenta de mineração de dados Weka(HALL, 2009).

O Weka é um software que agrega uma coleção de algoritmos de aprendizado que máquina desenvolvido na Universidade de Waikato na Nova Zelândia. Ele contém diversos algoritmos para análise de dados e modelagem e é utilizado neste trabalho para a classificação dos dados extraídos pelo MeshAdmin utilizando o modelo gerado para o MAD.

O Weka originalmente é escrito em Java e para a integração ao módulo MAD desenvolvido em Python foi utilizado o pacote python-weka-wrapper (REUTEMANN, 2012) que permite o acesso à API Java do Weka no Python.

O arquivo mad_weka.py é um programa Python responsável por implementar as etapas de classificação e Armazenamento dos diagnósticos. Faz chamadas à biblioteca

mad_module.py informando o nó sobre o qual o diagnóstico será executado, além do

intervalo de início e fim dos dados a serem extraídos do banco, e por fim gera o arquivo normalizado com os dados extraídos. Este programa implementa as chamadas à API do Weka, carrega o arquivo .arrf que contém os dados formatados extraídos do banco, o arquivo de modelo de classificação gerado na criação do MAD, além de executar a classificação utilizando o Weka. Após a classificação, é chamada a função do módulo de Alerta que salva o diagnóstico no banco de dados e informa o diagnóstico através da view deste módulo.

O arquivo tasks.py é um arquivo de tarefa utilizado pelo Celery e utilizado para a execução programada, em intervalos predefinidos ou em horário predeterminado. Este arquivo de tarefa implementa uma tarefa de execução de diagnóstico da rede. Para isto,

(33)

ele instancia uma classe do tipo Mad_weka e executa o diagnóstico para cada nó existente na rede.

Esses diagnósticos são executados em segundo plano de maneira que dispensam a interação do administrador da rede com o sistema, além de deixar o servidor livre para realizar outras tarefas de gerência.

(34)

32

4 Resultados Finais

Para validar a integração da integração foram realizadas testes que abrangem os casos de uso identificados na etapa de análise. Desta maneira foram feitos seguintes testes:

1. Teste de diagnóstico completo da rede em intervalos predefinidos de 1 minuto, sem a interferência do administrador;

2. Teste de um diagnóstico da rede para um nó a partir da tela inicial;

3. Teste de diagnóstico da rede para alguns nós utilizando o banco de dados de trei-namento, desta maneira o diagnóstico de falha será positivo.

4.1 Teste 1 - Teste de diagnóstico completo da rede em intervalos

predefinidos de 1 minuto, sem a interferência do administrador.

Para a realização deste teste, primeiramente foi cadastrado o intervalo de 1 mi-nuto(escolhido apenas para fim de teste) para tarefas seguindo como exemplo o Caso de

Uso - UC 05: Cadastra Intervalo Predefinido e apêndiceC.1Criando Intervalos Predefini-dos. Após o cadastro do Intervalo, foi cadastrado uma tarefa do sistema para Diagnóstico

da rede utilizando o intervalo de 1 minuto pré-cadastrado, conforme o Caso de Uso - UC

06: Cadastra Tarefa de Diagnóstico.

Após o intervalo o resultado é exibido na aba ’MAD’ do módulo de alerta conforme a figura 12.

(35)

Capítulo 4. Resultados Finais 33

4.2 Teste 2 - Teste de diagnóstico da rede para um nó a partir da

tela inicial

Para realizar este teste foi tomado como exemplo o caso de uso Caso de Uso - UC 02: Verificar o estado de um nó da rede para os Nós ’id0’ e ’id2’ e selecionado as datas de ’21-06-2018’. Para estas datas, não foram encontrados problemas e portanto foi reportado a mensagem correspondente pelo módulo de alerta conforme pode ser observado na figura 13.

Figura 13: Resultado MAD com Diagnóstico Individual

4.3 Teste 3 - Teste de diagnóstico da rede para nós utilizando

o banco de dados de treinamento do modelo de classificação

utilizado no MAD.

Neste teste, foi selecionado uma data anterior do banco de dados de treinamento utilizado para treinar o modelo de classificação do MAD. Para a realização do teste, foi seguido como exemplo o Caso de Uso - UC 02: Verificar o estado de um nó da rede para os Nós ’id2’ e ’id0’ e como data escolhida ’01-02-2017’. Esta data do banco foi escolhida

(36)

Capítulo 4. Resultados Finais 34

por estar sendo utilizada a base de dados de treinamento do modelo de classificação do MAD, desta maneira já era sabido previamente ter ocorrido um problema e sua classe.). O resultado pode ser observado na figura14em que há diagnóstico positivo e é informado o nó e a classe do problema, além da data do ocorrido.

(37)

35

5 Conclusão

Falhas em redes de computadores no geral são um problema comum e impactam diretamente na qualidade dos serviços providos por esta. Redes mesh alimentadas por painéis solares são mais vulneráveis a falhas pois têm grande parte da sua infraestrutura de comunicação exposta ao clima, suas antenas, painéis solares e etc., e podem portanto sofrer problemas como obstrução das antenas, desalinhamento por conta dos fortes ventos, empoeiramento dos painéis solares, além de problemas comuns, como falha nos roteadores e desgaste da bateria.

Desta maneira, um sistema de diagnóstico autonômico, que dispense a necessidade de inspeção manual é necessário para que se possa reduzir os custos de operação da rede, além de permitir a atuação de maneira preventiva, reduzindo assim o tempo em que a rede fica fora do ar e evitando grandes impactos negativos nos serviços prestados por esta rede.

Com o sucesso da integração a plataforma MeshAdmin agora conta com mais uma ferramenta para gerência de redes mesh o que auxiliará ao administrador da rede manter a rede funcionando por mais tempo sem falhas, aumentando a confiabilidade da rede.

Esta nova ferramenta dará ao administrador a flexibilidade para ajustar os interva-los de diagnósticos conforme a necessidade específica para cada rede diferente monitorada, podendo levar em conta a criticidade da rede, histórico de falhas entre outros fatores.

5.1 Trabalhos futuros

Neste trabalho não foram realizados testes para verificar o nível de estresse sobre o servidor que hospeda a plataforma MeshAdmin causado pelo diagnóstico de toda a rede completa para mais que 5 nós. Portanto acredito que pode ser interessante o estudo sobre uma rede como a do projeto REMOTE que possui 41 nós. Além disso, pode-se estudar também o período de tempo ideal para o diagnóstico programado de toda a rede, a fim de estimá-lo, como talvez intervalos de uma hora, ou doze horas, ou até mesmo diário.

(38)

36

Referências

AHA, D. W.; KIBLER, D.; ALBERT, M. K. Instance-based learning algorithms.

Machine learning, Springer, v. 6, n. 1, p. 37–66, 1991. Citado na página 22.

AKYILDIZ, I. F.; WANG, X. Wireless mesh networks. [S.l.]: John Wiley & Sons, 2009. Citado na página 12.

CASE, J. D.; FEDOR, M.; SCHOFFSTALL, M. L.; DAVIN, J. Simple network

management protocol (SNMP). [S.l.], 1990. Citado na página 13.

CELERY. 2012. Acessado: 25 jun. 2018. Disponível em:

<http://docs.celeryproject.org-/en/2.4-archived/>. Acesso em: 25 jun. 2018. Citado na página 27.

CHANG, C.-C.; LIN, C.-J. Libsvm: a library for support vector machines. ACM

transactions on intelligent systems and technology (TIST), Acm, v. 2, n. 3, p. 27, 2011.

Citado na página 22.

DJANGO. Django - (Version 1.4). 2012. Disponível em: <https://djangoproject.com>. Citado na página 27.

DJCELERY. 2012. Acessado: 25 jun. 2018. Disponível em:

<http://docs.celeryproject-.org/projects/django-celery/en/2.4/>. Acesso em: 25 jun. 2018. Citado na página 27.

FAYYAD, U.; PIATETSKY-SHAPIRO, G.; SMYTH, P. The kdd process for extracting useful knowledge from volumes of data. Communications of the ACM, ACM, v. 39, n. 11, p. 27–34, 1996. Citado na página 21.

FERREIRA, V.; CARRANO, R.; SILVA, J.; PASSOS, D.; ALBUQUERQUE, C. de. Fault detection and diagnosis for solar-powered wireless mesh networks using machine learning. In: IEEE. International Symposium on Integrated Network Management, 2017

IFIP/IEEE. [S.l.], 2017. Citado 8 vezes nas páginas 4,5, 6,13, 21, 22,25 e29.

HALL, M.; FRANK, E.; HOLMES, G.; PFAHRINGER, B.; REUTEMANN, P.; WITTEN, I. H. The weka data mining software: an update. ACM SIGKDD explorations

newsletter, ACM, v. 11, n. 1, p. 10–18, 2009. Citado 2 vezes nas páginas 29e 30.

HERTZOG, R.; MAS, R. The Debian Administrator’s Handbook, Debian Wheezy from

Discovery to Mastery. [S.l.]: Lulu. com, 2014. Citado 2 vezes nas páginas 48e 50.

KOHAVI, R. The power of decision tables. In: SPRINGER. European conference on

machine learning. [S.l.], 1995. p. 174–189. Citado na página 22.

KUROSE, J. F. Computer networking: A top-down approach featuring the internet, 3/E. [S.l.]: Pearson Education India, 2005. Citado na página 13.

MíDIACOM, L. REMOTE - Rede de Monitoramento para linhas de Transmissão de

Energia. 2007. Acessado: 25 jun. 2018. Disponível em:

<http://www.midiacom.uff.br-/midiacom/index.php/pt-BR/projetos/redes-sem-fio/remote>. Acesso em: 25 jun. 2018. Citado na página 12.

(39)

Referências 37

PASSOS, D.; TEIXEIRA, D. V.; MUCHALUAT-SAADE, D. C.; MAGALHÃES, L. C. S.; ALBUQUERQUE, C. Mesh network performance measurements. In: International

Information and Telecommunicatios Technologies Symposium (I2TS). [S.l.: s.n.], 2006. p.

48–55. Citado na página 20.

QUINLAN, J. R. C4. 5: programs for machine learning. [S.l.]: Elsevier, 2014. Citado na página 22.

REUTEMANN, P. "fracpete". Weka Wrapper. 2012. Acessado: 25 jun. 2018. Disponível em: <https://pypi.org/project/python-weka-wrapper/>. Acesso em: 25 jun. 2018. Citado na página 30.

RISH, I. An empirical study of the naive bayes classifier. In: IBM. IJCAI 2001 workshop

on empirical methods in artificial intelligence. [S.l.], 2001. v. 3, n. 22, p. 41–46. Citado

na página 22.

SIQUEIRA, B.; PASSOS, D.; MUCHALUAT-SAADE, D. C.; ALBUQUERQUE, C. Libr: Id-based routing for linear wireless mesh networks. In: IEEE. Consumer

Communications and Networking Conference (CCNC), 2015 12th Annual IEEE. [S.l.],

2015. p. 461–466. Citado 2 vezes nas páginas 4e 5.

VALLE, R. D. T. do; MUCHALUAT-SAADE, D. C. Meshadmin: An integrated platform for wireless mesh network management. In: IEEE. Network Operations and Management

Symposium (NOMS), 2012 IEEE. [S.l.], 2012. p. 293–301. Citado 6 vezes nas páginas 4, 5, 6,13, 15e 17.

WITTEN, I. H.; FRANK, E.; HALL, M. A.; PAL, C. J. Data Mining: Practical machine

(40)

(41)

39

APÊNDICE A – Diagrama de Casos de Uso

(42)

40

APÊNDICE B – Casos de Uso

Caso de Uso - UC 01 Diagnosticar Estado da Rede Lista de Atores: Administrador da Rede

Ator Primário: Administrador da Rede

Visão Geral: O administrador da rede deseja executar o módulo de diagnóstico para inferir o estado atual da rede para identificar possíveis problema.

Referências Cruzadas:

∙ Requisitos:RF - 1, RF - 2, RF - 3, RF - 5, RF - 6, RF - 9, RNF - 3, RNF - 1 Precondições: Administrador está logado no sistema

Pós-condições: Informar o estado atual da rede. Cenário Típico:

1. O administrador identifica o campo para inserção de data como na figura 16.

2. O administrador informa a data desejada para análise.

3. O administrador seleciona ‘ALL’ no campo de inserção de Nó da rede.

4. O administrador clica em ’Diagnose’.

5. O administrador verifica o estado atual da rede no campo Alerts na aba ’All’ ou na Aba ’Mad’.

(43)

APÊNDICE B. Casos de Uso 41

Figura 16: Diagnóstico Completo da Rede

Caso de Uso - UC 02: Verificar o estado de um nó da rede Lista de Atores: Administrador da Rede

Visão Geral: O administrador da rede deseja executar o módulo de diagnóstico para inferir o o estado atual de um nó da para identificar possíveis problema.

∙ Requisitos:RF - 1, RF - 2, RF - 3, RF - 4, RF - 5, RF - 6, RF - 9, RNF - 3, RNF - 1 Precondições: Administrador está logado no sistema.

(44)

1. O administrador identifica o campo para inserção de data como na imagem 17.

3. O administrador seleciona o Nó desejado no campo de inserção de Nó da rede.

5. O administrador da rede verifica o diagnóstico para o Nó selecionado co campo

Alerts na aba ’All’ ou na Aba ’Mad’.

Figura 17: Diagnóstico de um Nó da Rede

Caso de Uso: - UC 03: Verificar o estado de um nó em uma data anterior Ator Primário: Administrador da Rede

Visão Geral: O administrador da rede deseja executar o módulo de diagnóstico para inferir o o estado atual da um nó da rede para descobrir a causa de algum problema em uma data anterior.

(45)

∙ Requisitos: RF - 1, RF - 2, RF - 3, RF - 4, RF - 5, RF - 6, RF - 9, RF - 10, RNF - 3 Precondições: Administrador está logado no sistema.

1. O administrador identifica o campo para inserção de data.

3. O administrador seleciona o nó desejado no campo de inserção de Nó da rede.

5. O administrador da rede verifica o diagnóstico para o Nó selecionado co campo

Alerts na aba ’All’ ou na Aba ’Mad’.

Fluxos Alternativos

1. O administrador da rede identifica a aba MAD no módulo de alerta.

2. O administrador clica na aba MAD.

3. O administrador da rede identifica o diagnóstico para o tempo e o nó da rede desejado, no registro de diagnósticos.

(46)

Figura 18: Consulta ao Log de Diagnósticos dos Nós

Caso de Uso: - UC 04: Efetuar o diagnóstico da rede automaticamente em intervalos predefinidos

Visão Geral: O administrador da rede deseja executar o módulo de diagnóstico para inferir o o estado da rede em intervalos regulares, para identificar possíveis problemas assim que ocorram.

∙ Requisitos: RF 1, RF 2, RF 3, RF 6, RF 7, RF 8, RF 9 RNF 3, RNF -2, RNF - 1

∙ Casos de uso relacionados: UC - 5 - Cadastra Intervalo predefinido.

(47)

1. O administrador identifica o campo para inserção de data.

3. O administrador seleciona o nó desejado no campo de inserção de Nó da rede.

4. O administrador clica em Diagnosticar.

Fluxo alternativo:

1. O administrador da rede identifica a aba MAD no módulo de alerta.

2. O administrador clica na aba MAD.

3. O administrador da rede identifica o diagnóstico para o tempo e o nó da rede desejado, no registro de diagnósticos.

Caso de Uso: - UC 05 Caso de Uso: Cadastra intervalo Predefinido Ator Primário: Administrador da Rede

Visão Geral: O administrador cadastra um horário específico para a execução do diagnóstico de forma automática

∙ Requisitos: RF - 1, RF - 2, RF - 6, RF - 7, RF - 8, RF - 9 RNF - 3, RNF - 2 ∙ Casos de uso relacionados:

Precondições: Administrador está logado no sistema

Pós-condições: Pós-condições: Horário cadastrado é salvo no sistema. Cenário Típico:

1. O administrador identifica o botão “Administration”.

2. O administrador clica no botão “Administration” para acessar o painel de administração.

(48)

4. O administrador clica em “Intervals”.

5. O administrador identificar o botão “add interval”.

6. O administrador preenche o campo “Every” com um valor correspondente ao intervalo desejado.

7. O administrador seleciona a unidade de tempo desejada no campo “Period”.

8. O administrador clica em “Save”.

Caso de Uso: - UC 06 Caso de Uso: Cadastra Tarefa de Diagnóstico para Execução em Intervalo Predefinido

Visão Geral: O administrador cadastra uma nova tarefa de diangóstico da rede para execução de forma automática

∙ Requisitos: RF - 1, RF - 2, RF - 6, RF - 7, RF - 8, RF - 9 RNF - 3, RNF - 2 ∙ Casos de uso relacionados:

Precondições: Administrador está logado no sistema

Ter executado o caso de uso UC 05 Caso de Uso: Cadastra Intervalo Predefinido

Pós-condições: Pós-condições: Tarefa é agendada no sistema Cenário Típico:

1. O administrador identifica o botão “Administration”.

2. O administrador clica no botão “Administration” para acessar o painel de administração.

3. O administrador identifica o botão “Tasks” no grupo de botões Djcelery.

4. O administrador clica em “Periodic Tasks”.

5. O administrador identificar o botão “add Periodic Tasks”.

6. O administrador preenche o campo “Name” com um nome para a tarefa.

7. O administrador seleciona a tarefa "mad.tasks.diagnose_Network no campo “Task (registered)”.

(49)

8. O admnistrador na seção "Schedule"escolhe o intervalo de tempo no campo "Iterval"ou a entrada contrab correspondente ao agendamento desejado no campo "Crontab".

(50)

48

APÊNDICE C – Utilizando o DJCelery

O DJCelery é uma aplicação Python que faz a integração da fila de tarefas Celery ao Painel de Administração do Django, permitindo assim sua manipulação de maneira mais fácil. A seguir demonstra-se a criação de horários e intervalos predefinidos para a execução de tarefas utilizando o DJCelery.

C.1 Criando Intervalos Predefinidos

A após acessar o Painel de Administração Django clicar em Add na linha Invervals como mostra a figura 19 e preencher o campo Every com o intervalo e Period com a unidade de tempo como na figura 20. Após clicar em Save será redirecionado para os intervalos já criados, figura 21.

C.2 Criando Horários Agendados para Tarefas Utilizando o Crontab

O cron é um serviço responsável por executar tarefas agendadas e recorrentes (HERTZOG; MAS,2014) podendo ser programado para executar com intervalos regulares como por exemplo, a cada duas horas ou toda semana, ou em dia e horário específicos

(51)

APÊNDICE C. Utilizando o DJCelery 49

Figura 20: Adição de Intervalo no DJCelery - Passo 2

(52)

APÊNDICE C. Utilizando o DJCelery 50

como por exemplo, às 22:45 do dia 13 de maio de 1990.

Uma das maneiras de se executar comandos ou tarefa utilizando o cron é criando uma entrada no arquivo crontab que será executada quando a condição for satisfeita.

Através do DJCelery é possível criar agendamentos utilizando o mesmo estilo do crontab desta maneira promovendo uma flexibilidade maior no agendamento das tarefa. No entanto as possibilidades ainda são um pouco limitadas. Ao contrário do arquivo cron original dá suporte a definição de intervalos considerendo minuto, hora, dia do mês, mês, e dia da semana, como no exemplo abaixo:

#imprime hello world sempre que for 19H:25M 25 19 * * * echo "Hello World"

O Celery trabalha apenas com minutos, hora e dia da semana como pode ser visto na figura 22e seu preenchimento segue a mesma regra do crontab.

Figura 22: DJCelery Crontabs

Cada campo pode ser preenchido da seguinte maneira conforme é dito em (HERT-ZOG; MAS,2014) "a-b descreve o intervalo de todos os valores entre a e b. A sintaxe a-b/c

descreve o intervalo com um incremento de c (exemplo: 0-10/2 significa 0,2,4,6,8,10). Um asterisco * é um coringa, representando todos os valores possíveis."

(53)

51

APÊNDICE D – Adição do SVM ao Weka

O classificador SVM não estava presente por padrão no Weka. Portanto para adicioná-lo e poder gerar o modelo treinado para classificação dos dados é necessário realizar os seguintes passos:

∙ Iniciar o Weka;

∙ Clicar em ’Simple CLI’

∙ Digitar ’java weka.core.WekaPackageManager -install-package LibSVM’ ∙ Teclar ’Enter’

(54)

APÊNDICE D. Adição do SVM ao Weka 52

Figura 24: SVM disponível no Weka. Fonte: Captura de tela do Software Weka.

Para que seja possível utilizar o SVM utilizando o Python, é necessário a instalação co pacote python-weka-wrapper, a versão utilizada foi a 0.3.11. Para instalá-lo no sistema siga os seguntes passos.

∙ Para instalar utilizando o gerenciador de pacotes Python digite: ’sudo pip install python-weka-wrapper’

∙ Copie o arquivo ’LibSVM.jar’ do diretório ’ /wekafiles/packages/LibSVM/’ para o diretório ’/usr/lib/python2.7/site-packages/weka/lib’

∙ Copie o arquivo ’libsvm.jar’ do diretório ’ /wekafiiles/packages/LibSVM/lib’ para o diretório ’/usr/lib/python2.7/site-packages/weka/lib’

Desta maneira o Classificador SVM estará dispon´vel para ser utilizado através do Python-weka-wrapper.

(55)

53

Formulário de Identificação

Exemplo de Formulário de Identificação, compatível com o Anexo A (informativo) da ABNT NBR 10719:2011. Este formulário não é um anexo. Conforme definido na norma, ele é o último elemento pós-textual e opcional do relatório.

Dados do Relatório Técnico e/ou científico

Título e subtítulo Classificação de segurança

No.

Tipo de relatório Data

Título do projeto/programa/plano No. Autor(es)

Instituição executora e endereço completo Instituição patrocinadora e endereço completo Resumo

Palavras-chave/descritores

Edição No. de páginas No. do volume No de classificação

ISSN Tiragem Preço

Distribuidor Observações/notas