universidade federal de santa catarina … · departamento de informÁtica e estatÍstica ......
TRANSCRIPT
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO
INE5434 – TRABALHO DE CONCLUSÃO DE CURSO II
Internet das Coisas: estudo do simulador COOJA
Rodrigo Boratti
Florianópolis – SC
2014/2
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO
Internet das Coisas: estudo do simulador COOJA
Rodrigo Boratti
07132056
Orientadora:
Profa. Dra. Carla Merkle Westphall
Florianópolis – SC
2014/2
Trabalho de conclusão de curso a
ser apresentado como requisito
parcial para a obtenção do grau de
Bacharel em Ciências da
Computação pela Universidade
Federal de Santa Catarina - UFSC
Resumo
A Internet começou por volta da década de 70 e ela era uma rede que
conectava universidades. Com o passar do tempo a Internet foi evoluindo
através de adaptações. Com essas adaptações começaram a surgir algumas
limitações e problemas nos aspectos de segurança, mobilidade, qualidade de
serviço e escalabilidade.
Hoje em dia, a Internet pode ser acessada por qualquer pessoa e em
qualquer lugar do mundo e com isso aumentando muito a demanda e
ocasionando um desempenho insatisfatório para algumas aplicações em uma
arquitetura muito adaptada.
Em um futuro breve será possível conectar objetos do dia a dia na rede.
A conexão desses objetos com a Internet é denominada Internet das Coisas
(do inglês, Internet of Things - IoT). Se isso acontecer, será necessária uma
"Nova Internet" para atender a esses requisitos. Diversos projetos de pesquisa
estão em andamento para propor como será a Internet do Futuro.
Este trabalho tem o objetivo de descrever a evolução da Internet, os
conceitos básicos sobre IoT, a descrição de alguns sistemas operacionais,
onde a IoT pode ser simulada por meio de um simulador e descrever sobre o
funcionamento do COOJA que é um simulador para o sistema operacional
Contiki.
Abstract
The Internet started around the 70s and she was a network that connected
universities. Over time the Internet has evolved through adaptations. With these
adjustments some limitations and problems in the aspects of security, mobility,
quality of service and scalability begun to emerge.
Nowadays, the Internet can be accessed by anyone, anywhere in the world and
thus greatly increasing the demand and causing poor performance for some
applications in a very tailored architecture.
In the near future it will be possible to connect everyday objects in the network.
The connection of these objects with the Internet is called Internet of Things
(English, Internet of Things - IoT). If this happens, a "New Internet" will be
needed to meet these requirements. Several research projects are underway to
propose how will the Future Internet.
This paper aims to describe the evolution of the Internet, the basics of IoT, the
description of some operating systems, where the IoT can be simulated by a
simulator and describe the functioning of COOJA which is a simulator for the
system Contiki operating.
Lista de Figuras
FIGURA 1: TRÊS PRINCIPAIS PARADIGMAS DA INTERNET DAS COISAS (ATZORI ET AL, 2010) ........................................... 22
FIGURA 2: COMPONENTES NA INTERNET DAS COISAS (COETZE E EKSTEEN, 2011). ................................................. 23
FIGURA 3: CAMADAS DA IOT [RAFIULLAH E SARMAD E RIFAQAT E SHAHID, 2010] ...................................................... 27
FIGURA 4: TELA DE LOGIN DO UBUNTU. ................................................................................................................ 42
FIGURA 5: ÁREA DE TRABALHO DO INSTANTCONTIKI2.7 .......................................................................................... 43
FIGURA 6: CRIANDO UMA NOVA SIMULAÇÃO PARTE 1. ............................................................................................ 44
FIGURA 7: CRIANDO UMA NOVA SIMULAÇÃO PARTE2.............................................................................................. 44
FIGURA 8: AMBIENTE DE SIMULAÇÃO DO COOJA. ................................................................................................. 45
FIGURA 9: CRIANDO UM NÓ DO TIPO SKY MOTE. ................................................................................................... 46
FIGURA 10: CRIANDO UM NÓ DO PROGRAMA CONTIKI A SER COMPILADO. .................................................................. 46
FIGURA 11: ADICIONANDO UM NÓ DO TIPO SKY MOTE TYPE #SKY1. ......................................................................... 47
FIGURA 12: ADICIONANDO E DEFININDO A POSIÇÃO DOS NÓS DO TIPO SKY MOTE TYPE #SKY1. ...................................... 47
FIGURA 13: PLUGINS: NETWORK; MOTE OUTPUT; TIMELINE; BREAKPOINTS; RADIO MESSAGES; SIMULATION SCRIPT EDITOR;
NOTES; BUFFER VIEW; MOTE RADIO DUTY CYCLE. ......................................................................................... 48
FIGURA 14: LAYOUT DA REDE. ........................................................................................................................... 49
FIGURA 15: SAÍDA SERIAL DOS NÓS. .................................................................................................................... 49
FIGURA 16: TIMELINE MOSTRANDO ALGUNS EVENTOS. ........................................................................................... 50
FIGURA 17: INTERFACE DO BREAKPOINTS ............................................................................................................. 50
FIGURA 18: INTERFACE DO RADIO MESSAGES. ....................................................................................................... 51
FIGURA 19: INTERFACE DO SIMULATION SCRIPT EDITOR. ......................................................................................... 51
FIGURA 20: INTERFACE DO BUFFER LISTENER. ....................................................................................................... 52
FIGURA 21: INTERFACE DO POWERTRACKER. ........................................................................................................ 52
FIGURA 22: SALVANDO UMA SIMULAÇÃO. ........................................................................................................... 53
FIGURA 23: CONTROLANDO CONTIKI, ATRAVÉS DA MANIPULAÇÃO DOS SEGMENTOS DE MEMÓRIA (OSTERLIND ET AL.,
2000). ................................................................................................................................................. 54
FIGURA 24: O TIPO DE NÓ FUNCIONA COMO UMA LIGAÇÃO PARA A BIBLIOTECA CONTIKI CARREGADA (OSTERLIND ET AL.,
2000). ................................................................................................................................................. 55
FIGURA 25: MAKE FILE DE UM HELLO WORLD. ...................................................................................................... 56
FIGURA 26: ARQUIVOS GERADOS APÓS A COMPILAÇÃO. .......................................................................................... 56
FIGURA 27: CRIANDO UM NÓ APARTIR DE UM ARQUIVO .SKY ................................................................................... 56
FIGURA 28: CÓDIGO DO HELLO-WORLD.C ............................................................................................................ 57
FIGURA 29: HELLO WORLD SIMULADO NO COOJA ................................................................................................. 59
FIGURA 30: INTÂNCIA DE UM RPL (MARTINS, 2013). ........................................................................................... 60
FIGURA 31: MAKEFILE DO RPL-COLLECT. ............................................................................................................. 61
FIGURA 32: ABRINDO UMA SIMULAÇÃO NO COOJA. ............................................................................................. 62
FIGURA 33: CENÁRIO DA REDE. .......................................................................................................................... 63
FIGURA 34: INICIAR COLETA DE DADOS DOS NÓS.................................................................................................... 63
FIGURA 35: ENVIANDO COMANDOS AOS NÓS. ...................................................................................................... 64
FIGURA 36: PACOTES RECEBIDOS POR CADA NÓ. ................................................................................................... 65
FIGURA 37: PACOTES RECEBIDOS POR TEMPO. ...................................................................................................... 65
FIGURA 38: PACOTES PERDIDOS POR TEMPO. ....................................................................................................... 66
FIGURA 39: ENERGIA CONSUMIDA POR CADA NÓ EM UM DETERMINADO TEMPO. ........................................................ 67
FIGURA 40: QUANTIDADE DE ENERGIA CONSUMIDA POR CADA COMPONENTE DE CADA NÓ. ........................................... 67
FIGURA 41: PORCENTAGEM DO CICLO DE TRABALHO DE CADA NÓ. ............................................................................ 68
FIGURA 42: EVENTOS OCORRIDOS EM CADA NÓ. ................................................................................................... 68
Lista de Tabelas
TABELA 1 – COMPARAÇÃO DE SISTEMAS OPERACIONAIS .......................................................................................... 34
Sumário
Lista de Figuras .............................................................................................................................. 5
Lista de Tabelas ............................................................................................................................. 6
Sumário ......................................................................................................................................... 7
1. Introdução ................................................................................................................................. 9
1.1. Motivação ........................................................................................................................... 9
1.2. Descrição do problema .................................................................................................... 10
1.3. Objetivos .......................................................................................................................... 10
1.4. Estrutura do trabalho ....................................................................................................... 10
2. Internet das Coisas .................................................................................................................. 12
2.1. Internet atual ................................................................................................................... 12
2.1.1. Funcionamento ......................................................................................................... 12
2.1.2. Evolução da Internet ................................................................................................. 15
2.1.3 Problemas ................................................................................................................... 18
2.2. Conceitos básicos de Internet das Coisas ........................................................................ 20
2.3. Protocolos e camadas da IoT ........................................................................................... 26
2.4. Aplicações da IoT .............................................................................................................. 28
2.5. Desafios da IoT ................................................................................................................. 30
3. Sistemas Operacionais para Internet das Coisas..................................................................... 31
3.1. Requisitos Necessários ..................................................................................................... 31
3.2. RIOT .................................................................................................................................. 34
3.3. Contiki .............................................................................................................................. 35
3.3.1. COOJA ........................................................................................................................ 35
3.4. TinyOS............................................................................................................................... 36
3.4.1. TOSSIM ...................................................................................................................... 37
3.5. Mantis OS ......................................................................................................................... 37
4. Desenvolvimento prático ........................................................................................................ 39
4.1 Introdução ......................................................................................................................... 39
4.2 Instalação da máquina virtual Contiki ............................................................................... 41
4.3 Funcionamento básico do COOJA ..................................................................................... 42
4.3.1 Inicialização do COOJA ............................................................................................... 42
4.3.2 Criando uma nova simulação no COOJA .................................................................... 43
4.3.3 Criando um tipo de nó ................................................................................................ 45
4.3.4 Adicionando um tipo de nó ........................................................................................ 47
4.3.5 Inicializando uma simulação ...................................................................................... 48
4.3.6 Plugins ........................................................................................................................ 48
4.3.7 Salvando, carregando e recarregando uma simulação .............................................. 52
4.4. Descrição de arquivos necessários para a compilação de simulações ............................ 53
4.4.1 Introdução .................................................................................................................. 53
4.4.2 Arquivos necessários .................................................................................................. 55
4.5. Exemplo de uma simulação: Hello World ........................................................................ 56
4.6. Funcionamento do protocolo RPL (Routing Protocol for Low-Power and Lossy Networks)
no COOJA ................................................................................................................................. 59
4.6.1 RPL .............................................................................................................................. 59
4.6.2 Exemplo do rpl no COOJA .......................................................................................... 61
4.7. Uso prático do COOJA ...................................................................................................... 69
5. Conclusões e trabalhos futuros .............................................................................................. 70
5.1 Conclusões......................................................................................................................... 70
5.2 Trabalhos futuros .............................................................................................................. 70
Referências bibliográficas ........................................................................................................... 72
9
1. Introdução
1.1. Motivação
A Internet das Coisas (IoT – Internet of Things) é um novo paradigma de
integração do mundo físico com o digital que vem aumentando sua importância
e abrindo espaço nas comunicações. A ideia básica desse conceito é a
presença de várias “coisas” ou objetos, tais como identificadores de rádio
frequência (RFID – Radio-Frequency Identification), sensores, telefones móveis
e outros dispositivos que, através de esquemas de endereçamento como
endereços IP da Internet, são capazes de interagir uns com os outros e
cooperar na execução de tarefas (Atzori et al. 2010) (França et al. 2011).
Com o crescimento do número de usuários que usam a Internet e o
surgimento da Internet das coisas (IoT), a Internet atual não seria capaz de
absorver a quantidade de dispositivos conectados à rede prevista pela IoT.
Pensando nisso, faz-se necessário o desenvolvimento de uma "Nova Internet"
capaz de conectar qualquer coisa à rede.
As tecnologias envolvidas para o desenvolvimento da IoT são as
interfaces e protocolos de comunicação eletrônica, microcontroladores,
comunicação sem fio, tecnologia de identificação RFID, tecnologias de
captação de energia, sensores, atuadores, tecnologia de localização e software
(Istepanian et al. 2011).
A IoT pode ser usada na medicina para monitorar doentes e agilizar
prestação de serviços de saúde em geral, na política, na sociedade, na
tecnologia de computação na nuvem, na robótica e nanotecnologia. São
previstas também aplicações em áreas diversas como aeroespacial, aviação,
telecomunicações, edifícios inteligentes, tecnologia médica, farmacêutica,
varejo, logística, petróleo e gás.
Uma tecnologia importante na construção da IoT é o padrão IEEE
802.15.4, um padrão para redes sem fio, de baixo consumo e baixa
capacidade. A IoT utilizará o protocolo 6LoWPAN e o IPv6 fornecerá
10
endereçamento e conectividade para os dispositivos embarcados (Castellani et
al. 2010).
1.2. Descrição do problema
A Internet atual ainda não suporta de forma ampla e bem sedimentada a
implantação da Internet das Coisas. Existem vários problemas tecnológicos nas
áreas de segurança, mobilidade, qualidade de serviço e principalmente
escalabilidade. É necessário o desenvolvimento de várias pesquisas para
melhorar o suporte para IoT (Atzori et al. 2010).
Atualmente a literatura sobre Internet das Coisas apresenta vários
trabalhos teóricos, mas os experimentos práticos são escassos. Já existem
alguns sistemas operacionais experimentais para IoT. Já é possível simular a
Internet das Coisas utilizando um simulador específico para um determinado
sistema operacional.
1.3. Objetivos
O objetivo geral desse trabalho é descrever o simulador COOJA.
Alguns objetivos específicos que podem ser citados são:
descrever as limitações da Internet atual para a implantação da
Internet das coisas (IoT);
estudar tecnologias envolvidas na IoT, como os sistemas
operacionais que já fornecem suporte para IoT; e,
mostrar exemplos de simulações que utilizam o COOJA .
1.4. Estrutura do trabalho
O trabalho é dividido em 5 capítulos. O primeiro capítulo apresenta a
introdução do trabalho, contemplando a motivação, a descrição do problema e
objetivos a serem atingidos. O segundo capítulo cita a evolução,
funcionamento, problemas da Internet atual e descreve os conceitos básicos,
11
protocolos e camadas, desafios da Internet das coisas e bem como suas
aplicações. O terceiro capítulo apresenta alguns sistemas operacionais para a
Internet das coisas: RIOT, Contiki, TinyOS e Mantis OS. O quarto capítulo
apresenta como fuciona o COOJA, quais os arquivos necessários para
compilar e fazer uma simulação e exemplos de simulações utilizando o
COOJA. O quinto capítulo apresenta a conclusão e trabalhos futuros.
12
2. Internet das Coisas
2.1. Internet atual
2.1.1. Funcionamento
A Internet como conhecemos hoje começou a ser desenvolvida na
década de 70 e naquela época servia para conectar redes militares. A
arquitetura dessa Internet tinha que atender alguns requisitos como: ter um
bom custo x benefício, saber quem é o responsável pelos recursos da Internet,
ser acessível a novas estações, gerenciar de forma distribuída os recursos da
rede, conectar redes e possibilitar o envio de dados de qualquer estação para
outra, as estações poderiam se comunicar sem existir um caminho entre elas e
possibilitar a interconexão de diferentes tipos de rede e diferentes tipos de
hardware (Moreira et al. 2009).
Para atender a todos esses requisitos foram adotados alguns princípios
e soluções como: o desenvolvimento de um modelo em camadas, conhecido
como modelo TCP/IP; a utilização de comutação de pacotes e do serviço de
entrega de melhor esforço; a transparência; a adoção do modelo fim-a-fim; a
entrega imediata de pacotes; a heterogeneidade de sub-rede; e o uso de
endereçamento global; o controle distribuído; o cálculo global do roteamento; a
divisão em regiões; a dependência mínima. A partir desses princípios e
soluções é que se desenvolveram os protocolos e a estrutura atual da Internet
(Moreira et al. 2009).
O modelo TCP/IP inicial é dividido em 5 camadas, cada uma delas com
especificações diferentes, com isso diminuí a complexidade do sistema. As
camadas são (Kurose et al. 2013) ( Tanenbaum et al. 2011):
• Camada de Aplicação - É na camada de aplicação que se encontram
aplicações de rede e seus protocolos. É nessa camada que se encontram os
protocolos: HTTP, que possibilita a requisição e transferência de documentos
pela Web; o SMTP que fornece transferência de mensagens de correio
13
eletrônico; o FTP que provê transferência de arquivos entre sistemas finais da
Internet e DNS (domain name system);
• Camada de Transporte - Essa camada transporta as mensagens da
camada de aplicação entre o cliente e o servidor de uma aplicação. Nessa
camada temos os protocolos: TCP, que fornece serviços orientados para
conexão para suas aplicações e um desses serviços é o controle de fluxo;
UDP, que fornece serviço não orientado para conexão a suas aplicações, este
serviço fornece segurança, mas sem controle de fluxo e congestionamento;
• Camada de Rede – Essa camada é responsável pela movimentação de
pacotes entre uma máquina e outra, esses pacotes são conhecidos como
datagramas. Nessa camada se encontra o protocolo IP, esse protocolo define
os campos no datagrama e também define o modo como os sistemas finais e
os roteadores agem nesses campos. Nessa camada também tem alguns
protocolos para roteamento, que servem para determinar as rotas entre a
origem e o destino que os datagramas devem seguir;
• Camada Enlace – Essa camada trata de enviar mensagens entre
computadores diretamente conectados, com níveis de confiabilidade
especificados. A camada de enlace é uma interface entre os hosts e os enlaces
de transmissão. Nessa camada se encontram os protocolos Ethernet e 802.11;
e,
• Camada Física - A camada física é responsável por movimentar os bits
indivíduais que estão dentro de um nó para o seguinte. Os protocolos dessa
camada dependem do enlace e do meio de transmissão do enlace.
Para enviar dados de uma estação para outra nesse modelo de
camadas, os dados passam pelas camadas de Aplicação, Transporte, Rede e
Interface de Rede no emissor e fazem o caminho inverso no receptor.
A comutação de pacotes tinha como objetivo criar uma rede mais
robusta. Essa robustez se dava através de caminhos alternativos entre a
origem e o destino, caso ocorresse uma falha na infraestrutura existente.
14
Com a técnica de comutação de pacotes, os dados são divididos em
tamanhos variados, chamados de pacotes e em cada pacote é definido o
endereço de destino a ser enviado pela rede. Para enviar os pacotes da origem
ao destino utiliza-se a disciplina de serviço de melhor esforço, onde os pacotes
são independentes uns dos outros e o caminho a ser percorrido por cada
pacote vai depender da fila de pacotes em cada nó da rede. Cada pacote pode
encontrar filas de tamanhos diferentes e com isso sofrer atrasos diferentes e
percorrerem caminhos diferentes entre a origem e o destino. Caso um pacote
chegue a um nó onde a fila de pacotes esta lotada, esse pacote é descartado.
O serviço de melhor esforço não garante atraso máximo e não garante a
entrega dos pacotes ao destino.
A Internet atual fornece transparência sintática, isso significa que os
pacotes são transmitidos da origem até o destino sem nenhuma modificação
desses pela rede (Moreira et al. 2009).
O principio fim-a-fim sugere que o núcleo da rede seja simples e que
tenha inteligência nas extremidades. A rede tem a função de encaminhar os
pacotes e os nós nas extremidades ficam responsáveis pela comunicação.
Garantindo assim uma rede simples e flexível e com maior robustez. Fica sob
responsabilidade dos nós da extremidade todo o controle de entrega e
retransmissão, o armazenamento de pacotes para recuperar perdas e o
controle de fluxo (Moreira et al. 2009).
O principio da entrega imediata é que os pacotes são entregues
imediatamente segundo a disciplina de melhor esforço, isto é, os pacotes são
entregues mesmo na ausência de falha ou sobrecarga na rede. Como na rede
não há armazenamento persistente, a conectividade deve ser contínua no
tempo, ou seja, não devem existir conexões intermitentes e não devem existir
atrasos indefinidos na entrega de um pacote.
O principio da heterogeneidade de sub-rede rege que tendo as
premissas mínimas de funcionalidade da camada de Interface de rede é
possível acomodar diversas tecnologias de sub-rede, interconectando uma
15
grande variedade de tecnologias com diferentes características, sem que
ocorram mudanças na rede.
Outro princípio é que exista um espaço de endereçamento global onde é
garantida a unicidade de cada um dos endereços. Cada nó na rede tem um IP
e a partir do IP é possível ter a localização global do nó, devido à hierarquia de
endereços (Moreira et al. 2009).
Segundo o principio de controle distribuído, não devem existir únicos
pontos de falha nos algoritmos de controle de rede. Esses algoritmos devem
estar distribuídos para garantirem a robustez da rede.
A Internet deve fazer um cálculo de rotas globais de forma hierárquica, a
fim de garantir que não ocorram loops no encaminhamento de pacotes, esse
cálculo é feito baseado apenas no endereço de destino.
A Internet está dividida em regiões, que podem ser vistas como a
interconexão de sistemas autônomos (Autonomous System – AS) e esses AS
são gerenciados por um provedor de serviço de Internet (Internet Service
Provider – ISP) e o ISP opera os backbones que conectam os clientes a outros
provedores de serviço.
O princípio da dependência mínima define que se tiver pelo menos um
conjunto mínimo de serviços de redes disponíveis é possível estabelecer uma
comunicação fim-a-fim.
2.1.2. Evolução da Internet
Apesar da Internet ter requisitos bem definidos, foram feitas mudanças e
adaptações, para que fosse possível atender às novas necessidades e
requisitos. Os princípios fim-a-fim e da transparência possibilitaram o
crescimento da Internet no passado, mas agora são restrições para o
crescimento do uso da rede.
A primeira adaptação ocorreu por volta da década 80, onde várias redes
locais foram conectadas a ARPANET e com isso aumentou a escala da rede.
Para dar suporte a esse aumento, foram criadas as sub-redes, AS e o DNS
(Domain Name Service). Já na década de 90 também foi preciso fazer uma
16
adaptação com relação ao aumento da escala de rede e para dar suporte com
relação a esse aumento, foi criado a CIDR (Classless Inter-Domain Routing).
A Internet que era composta por dois níveis, redes locais e a Internet
como um todo, passou para três níveis. Isso ocorreu porque empresas e
universidades que ocupavam mais de um prédio e um cabo de rede não eram
suficientes para cobrir a "área local" e com isso se fez necessário a subdivisão
de uma rede local. Assim, criou-se o conceito de máscara, utilizado até hoje na
Internet.
Com o aumento de número de usuários na década de 80 foi necessária
a divisão da rede em AS, fazendo com que a rede crescesse muito. Com o
aumento da rede foi preciso criar uma estrutura hierárquica, pois ocorreu uma
sobrecarga de informações entre os gateways a cada atualização de rota e
com a adição de novas redes as tabelas de roteamento aumentaram muito de
tamanho. Outro problema que surgia simultaneamente era o aumento da
quantidade de roteadores com implementações de diferentes empresas do
GGP (Gateway-to-Gateway Protocol), o que tornava a manutenção e o
isolamento quase impossível. A rede foi dividida em diversas regiões com
autonomia administrativa própria, chamadas de ASs. Os ASs do backbone
foram chamados de ASs folha (stubs) para diferenciar eles dos ASs que
interconectam redes locais com a Internet. Cada ASs folha tem pelo menos um
roteador especial conectado ao backbone da Internet e para conectar esses
roteadores especiais foi criado o EGP (Exterior Gateway Protocol). Para a
comunicação interna do AS, especificou-se a nomenclatura de IGP (Interior
Gateway Protocol) (Moreira et al. 2009).
O EGP utilizava um algoritmo de cálculo simples, que indicava o próximo
AS, mas apresentava problemas, como a formação de loops de roteamento,
visto que cada AS tem sua própria política e poderia utilizar métrica de rota
diferentes. Para que não ocorressem loops, o IETF (Internet Engineering Task
Force) criou BGP (Border Gateway Protocol). O BGP adotou um novo
algoritmo de cálculo de rotas, o vetor de caminhos. As rotas anunciadas
possuem todos os AS para se chegar ao destino. O BGP sofreu algumas
mudanças e atualmente se encontra na versão 4. A versão 4 trouxe suporte ao
17
CIDR (Classless Inter-Domain Routing architecture), para impedir o rápido
consumo de endereços na Internet e a explosão das tabelas de roteamento.
Outra adaptação importante aconteceu com a criação do DNS (Domain
Name Service). Foi criado o DNS por causa da dificuldade em localizar as
estações. O DNS possui uma estrutura hierárquica na qual há servidores raiz e
com isso indo contra a ideia inicial de que a rede não deveria ter pontos
centrais, estabelecendo um ponto único de falha.
Na década de 80 foram introduzidas técnicas de controle de
congestionamento no TCP. Essas técnicas introduziram os seguintes
princípios: o protocolo de transporte no nó de destino deve monitorar o
congestionamento e reduzir a taxa de transmissão quando necessário; a
transmissão de pacotes deve ser controlada por mensagens de
reconhecimento (acknowledgment); e deve existir buffer suficiente para que
uma estação opere o algoritmo de adaptação de congestionamento com o
controle do RTT (Round-Trip Time).
O protocolo IP também sofreu várias adaptações ao longo dos anos. A
primeira adaptação importante aconteceu na década de 80 com a criação do IP
multicasting. IP multicasting é um endereço IP que identifica um conjunto de
estações. Com a criação do IP multicasting era possível uma estação enviar
dados para um conjunto de estações, opondo-se ao conceito inicial de envio de
dados de uma estação para outra estação. Ao IP foi acrescido o IPv6 que tinha
como finalidade de aumentar o número de endereços disponíveis, simplificar o
cabeçalho do IP, permitir a identificação de fluxos e inserir mecanismos de
autenticação e privacidade na camada IP. A NAT (Network Address
Translation) foi criada para aumentar o número de estações na Internet, sem
precisar alocar novos endereços.
Com o crescimento de usuários na rede e a diversificação das
aplicações utilizadas criou-se a WWW (World Wide Web), e com a criação do
www aumentou o número de aplicações utilizadas e diversificou o tipo de
usuário da rede. Por meio do WWW a Internet deixou de ser apenas, logon
remoto, transferência de arquivos e troca de mensagens e passou a ser em
sua maioria tráfego web.
18
2.1.3 Problemas
A arquitetura da Internet já sofreu muitas adaptações e com isso não
consegue mais atender aos requisitos de novas aplicações e serviços. A
arquitetura atual apresenta diversos problemas com: Endereçamento;
Mobilidade; Segurança; Confiabilidade da Rede e Disponibilidade dos Serviços;
Diagnóstico de Problemas e Gerenciamento da Rede; Qualidade de Serviço
(Quality of Service - QoS); Escalabilidade; Modelo Econômico e Liberdade de
Inovação (Moreira et al. 2009).
Um dos principais problemas para a Internet do Futuro é o
endereçamento, visto que a Internet atual está com uma escassez de
endereços e semântica sobrecarregada do endereço IP.
Como a cada ano que passa mais e mais usuários se conectam à
Internet e com isso 32 bits para o endereçamento já não são suficientes. Para
solucionar este problema foi proposto o IPv6 que estendia o tamanho do
endereço de 32 para 128 bits. No entanto, a interoperabilidade entre IPv6 e
IPv4 e a dificuldade de se convencer os ASs, tem dificultado a implantação do
IPv6.
Hoje em dia, cada vez mais celulares estão conectados à Internet,
gerando um aumentando na quantidade de dispositivos móveis que estão
conectados à rede. Com isso, surge o problema de mobilidade e a necessidade
de modificação do projeto original da Internet: princípio fim-a-fim, conexão
ponto-a-ponto e entrega imediata.
A semântica do endereço IP tem a informação do endereço IP de
destino e sua localização, caso o IP seja modificado, por causa da mobilidade,
isso provocaria mudança de localização e, consequentemente, mudança de
endereço IP.
Outro fator crucial da Internet atual é com relação à segurança dos
usuários, dos provedores de serviços, das Indústrias e desenvolvedores de
aplicações. A arquitetura atual não possui nenhum mecanismo que proteja as
estações corretas e nenhum mecanismo que limite o comportamento das
19
estações finais maliciosas e não prevê nenhum tipo de proteção contra ataques
aos próprios elementos da rede.
Inicialmente a arquitetura da rede não possuía nenhum mecanismo de
segurança, visto que os usuários eram confiáveis e não possuíam
conhecimento técnico. Mas com a comercialização da Internet, muitos usuários
começaram a utilizar a Internet, trazendo inúmeras ameaças. Os problemas de
segurança não são causados apenas por usuários maliciosos, mas também por
usuários sem conhecimento técnico para manter sua máquina atualizada e livre
de ameaças. Nesses casos, a máquina desses usuários pode ser transformada
em um robô (bot) para realizar ataques distribuídos de negação de serviço ou
ainda transformá-la em um disseminador de vírus e outras pragas virtuais.
As estações finais são protegidas de ameaças através de firewalls e
como não há nenhum controle de segurança na rede, pode ocorrer consumo
da banda disponível com dados indesejados.
Os provedores de serviço de Internet (Internet Service Providers – ISPs)
teriam que prover um serviço de rede confiável, robusto e sempre disponível.
Porém a atual rede não possui a confiabilidade da rede telefônica. Com relação
a disponibilidade de serviço, a Internet teria que ter maior disponibilidade de
serviços do que a rede telefônica, visto que, a Internet foi projetada com muitas
redundâncias de caminhos entre os nós. Entretanto não é o que ocorre, porque
a Internet utiliza comutação de pacotes e os nós são equipamentos que
processam e armazenam a informação, com isso deixando o núcleo mais
complexo do que o da rede telefônica que utiliza comutação de circuitos, que
simplesmente conecta fisicamente a origem ao destino.
Na Internet atual falta um mecanismo para detectar se um problema
ocorreu na máquina do usuário ou se ocorreu um problema na rede. O
gerenciamento da Internet ainda é um grande desafio, e é feito de forma
distribuída e com inteligência apenas nas extremidades. Como a cada dia a
rede cresce cada vez mais, fica evidente a necessidade de melhorias ou
substituição nos sistemas de gerenciamento de rede com o intuito de reduzir
atrasos e custos de manutenção.
20
Na década de 80 foi criado um protocolo padrão para gerenciamento da
Internet, esse protocolo é SNMP (Simple Network Management Protocol). O
SNMP funciona com base em um modelo de informação no qual os dados
necessários para o gerenciamento são colocados em módulos chamados de
MIB (Management Information Base) pelo equipamento gerenciado. O SNMP
mesmo sendo muito utilizado, restringe-se a monitorar dispositivos de rede,
assim deixando de lado o problema de gerenciamento de aplicações ou
servidores. Como a rede mudou muito desde a criação do SNMP, as
funcionalidades do SNMP são insuficientes para atender às necessidades
atuais (Moreira et al. 2009).
Devido a restrições de gerenciamento e detecção de erros, acredita-se
que na Internet do Futuro a rede seja autoconfigurável baseada em políticas e
restrições administrativas. Assim a autonomia deve ser um conceito importante
na Internet do Futuro.
Hoje em dia com a transmissão de vídeos, voz e jogos online, fica
evidente a utilização de ferramentas para garantir a melhora na qualidade de
serviço (Quality of Service – QoS). Mas a arquitetura atual com suas várias
adaptações criaram diversas restrições à implantação dessas soluções.
Para melhorar a qualidade de serviço seria necessária a inserção de
equipamentos no interior da rede e isso iria contra o princípio fim-a-fim. Outro
princípio que seria afetado, o princípio de “melhor esforço”, pois para manter a
qualidade de serviço seria necessário um mecanismo para reserva de banda
ou mudança de prioridade de pacotes.
Com o aumento de usuários e dispositivos conectados à Internet, alguns
componentes da arquitetura atual estão sofrendo problemas de escalabilidade,
como é o caso do sistema de roteamento, que sofre com o aumento e as
atualizações da tabela de roteamento. Com o surgimento da Internet das
Coisas (Internet of Things - IoT), onde cada objeto do mundo real estará
conectado à rede, teríamos problema de escalabilidade visto que não
possuiríamos endereços IPs suficientes.
2.2. Conceitos básicos de Internet das Coisas
21
O termo Internet das Coisas (Internet of Things - IoT) foi utilizado pela
primeira vez por Kevin Ashton, em 1998. A IoT tem diversas definições na
literatura, isso ocorre devido ao fato de Internet das coisas ser sintaticamente
composta por dois termos: Internet e coisas. O primeiro termo tende para uma
visão voltada a rede de IoT e o segundo termo voltado para objetos
(Bandyopadhyay et al. 2011).
A definição de IoT segundo Lu (2010) é: As coisas têm identidades e
personalidades virtuais que operam em espaços inteligentes usando interfaces
inteligentes para se conectar e se comunicar no meio social, meio ambiente, e
contextos de usuário. Já a definição de IoT segundo Patrick (2009) é: A Internet
das coisas permite que as pessoas e coisas sejam conectados a qualquer
hora, em qualquer lugar, com qualquer coisa e qualquer um, de preferência
usando qualquer caminho/rede e qualquer serviço (Perera et al. 2013).
Como mostra na figura 1, a IoT pode ser vista por três principais
paradigmas: uma visão focada no termo orientado a “Internet” (middleware) e
observaram a IoT do ponto de vista de rede; outra visão foi focada no termo
orientado a “Coisas” (sensores), onde a pesquisa busca a integração de
objetos em uma estrutura comum; e uma terceira visão focou em questões
orientadas a semânticas (conhecimento), observando a IoT do ponto de vista
de comunicação entre dispositivos distintos. Visto isso, a IoT pode ser vista
como a intersecção desses três paradigmas (Atzori et al. 2010).
22
Figura 1: Três principais paradigmas da Internet das Coisas (Atzori et al, 2010)
A figura 2 mostra uma visão do ecossistema IoT. As coisas poderiam ser
marcadas por RFID (Radio Frequency Identification) ou QR (Quick Response)
e através de scanners, essas coisas seriam identificadas e as informações de
localização relevantes poderia ser comunicado. Da mesma forma, as coisas em
rede de sensores tornam-se menores, enquanto as redes de sensores agir
sobre o meio ambiente local, comunicar status e eventos para um serviço de
nível superior. Middleware e frameworks permitindo a aplicação e
desenvolvimento de serviços que utilizam dados recebidos das coisas, na
maioria das vezes vivem na nuvem (COETZEE et al. 2011).
23
Figura 2: Componentes na Internet das Coisas (COETZE E EKSTEEN, 2011).
Graças ao paradigma da IoT, qualquer objeto do mundo real, como por
exemplo: TV, embalagens de alimento, casa e carro, estará conectado à
Internet e por causa disso vai aumentar muito o trafego da rede. Esses objetos
seriam identificados e interligados à Internet para trocar informações e tomar
decisões para atingirem um objetivo em comum. Pela visão da IoT, qualquer
coisa pode se conectar a Internet, à qualquer hora e em qualquer lugar (França
et al. 2011).
O objetivo final da IoT é fazer com que as coisas se tornem
"inteligentes", isto é, ter um processador MCU (Microcontroller Unit)
24
incorporado e ter uma identificação única associados. Depois que as coisas se
tornarem "inteligentes", essas coisas seriam ligadas a internet e controladas
(Karimi et al. 2013).
Como os dispositivos vão estar conectados à rede, eles vão poder
acessar e tirar proveito de nós supercomputadores. Isto permite que um
dispositivo possa fazer análises mais sofisticadas, tomar decisões, muitas
vezes sem intervenção humana (Karimi et al. 2013).
As principais características descritas a seguir da IoT são: inteligência,
arquitetura, sistema complexo, considerações de tamanho, considerações de
tempo, considerações de espaço e tudo como serviço. Essas características
precisam ser consideradas no desenvolvimento de soluções para IoT em todas
as fases de concepção, desenvolvimento, implementação e avaliação (Perera
et al. 2013).
• Inteligência – O conhecimento é obtido através do recolhimento dos
dados pelo sensor e pode ser feito por coleta, modelagem e raciocínio do
contexto.
• Arquitetura - A Internet das coisas deve ser facilitada por uma
arquitetura híbrida. Principalmente haveria duas arquiteturas, uma dirigida a
evento e outra por tempo contínuo. Quando fosse por evento, os sensores só
capitariam dados quando um evento ocorresse e outro produziria dados de
forma contínua.
• Sistema complexo – A IoT compreende um grande número de coisas
(sensores e atuadores) que interagem de forma autônoma. Interações podem
diferir significativamente dependendo dos recursos do objeto. Alguns objetos
podem ter poucos recursos, como por exemplo, pouca memória e outros
objetos podem ter muita memória, que os torna mais inteligente.
• Considerações de tamanho – Se prevê que até 2020 tenha de 50-100
bilhões de dispositivos conectados à Internet. A IoT tem que facilitar a interação
desses dispositivos. O número de objetos vai aumentar cada vez mais e nunca
vai diminuir, consequentemente a quantidade de interações vai aumentar.
25
• Considerações de tempo – O processamento de dados em tempo
real é essencial, visto que, a IoT vai lidar com milhares e milhões de eventos
simultâneos e paralelos, devido a grande quantidade de interações.
• Considerações de espaço – A localização exata de um objeto será
fundamental.
• Tudo como serviço – Devido à popularidade da computação em
nuvem, consumindo recursos como serviço, infraestrutura como serviço,
programas como serviço.
As tecnologias que contribuíram para o desenvolvimento da IoT são:
Interfaces de máquina-a-máquina; protocolos de comunicação eletrônica; micro
controladores; comunicação sem fio; tecnologia RFID (Radio Frequency
Identification); tecnologias de captação de energia; sensores; atuadores;
tecnologia de localização e software (Istepanian et al. 2011).
O RFID é um microchip que identifica qualquer coisa e faz a
comunicação de dados via wireless. O RFID é uma etiqueta equivalente a um
código de barras eletrônico. As etiquetas RFID podem ser de dois tipos:
passivas e ativas. As RFID passivas não utilizam baterias, elas utilizam a
potência do leitor para comunicar seu ID para o leitor de RFID. Já as etiquetas
ativas possuem bateria própria e podem iniciar a comunicação (Gubbi et al.
2013).
Outro elemento importante são as RSSF (Rede de Sensores Sem Fio)
que servem para a comunicação sem fio e esses sensores são inteligentes e
possibilitam a coleta, processamento e análise de dados remotamente (Gubbi
et al. 2013).
Segundo Molla e Ahamed para se desenvolver uma rede de sensor de
middleware seriam necessários 10 itens: apoio abstração, fusão de dados,
restrições de recursos, topologia dinâmica, conhecimento de aplicações,
programação paradigma, adaptabilidade, escalabilidade, segurança e QoS
apoio (Perera et al. 2013).
Para o sucesso da IoT é necessário que os objetos sejam identificados
unicamente. Isso possibilitaria que bilhões de objetos fossem conectados à
26
rede e eles poderiam ser acessados remotamente através da Internet. Mas
existem pontos críticos para que esses objetos sejam identificados unicamente,
como por exemplo: unicidade, confiabilidade, persistência e escalabilidade. O
IPv4 atual, não daria suporte para identificar unicamente tantos objetos, já o
IPv6 conseguiria aliviar um pouco a identificação dos dispositivos. Outro ponto
a ser tratado pela IoT seria a questão do tráfego, já que teríamos muitos
dispositivos conectados à rede e com isso muita informação transitaria pela
rede (Gubbi et al. 2013).
Com relação aos dados, seria outro ponto crítico a ser tratado pela IoT,
visto que, teria que armazenar, saber de quem são e validar os dados. Outra
questão seria a segurança desses dados (Gubbi et al. 2013).
A visualização seria importante para a aplicação da IoT, pois através
dela será possível que usuários interajam com o ambiente. Essa interação se
torna prática com a utilização de telas sensíveis ao toque, celulares e uso de
tablets (Gubbi et al. 2013).
2.3. Protocolos e camadas da IoT
Uma tecnologia importante na construção da IoT é o padrão IEEE
802.15.4, um padrão para redes sem fio, de baixo consumo e baixa
capacidade. A IoT utilizará o protocolo 6LoWPAN e o IPv6 fornecerá
endereçamento e conectividade para os dispositivos embarcados (Istepanian et
al. 2011).
O protocolo 6LoWPAN significa “Internet Protocol version 6 over Low
power Wireless Personal Area Networks.” As caraterísticas que os dispositivos
precisam ter para funcionar nesse protocolo são: baixa capacidade de
processamento; baixa capacidade de memória; baixo gasto de energia; baixo
alcance do sinal e baixa taxa de transmissão (Eduardo et al. 2013).
Como mostra na figura 3, a IoT está dividida em 5 camada que são
descritas a seguir: camada de percepção; camada de rede; camada de
middleware; camada de aplicação; e a camada de negócios (Khan et al. 2012).
27
Figura 3: Camadas da IoT [Rafiullah e Sarmad e Rifaqat e Shahid, 2010]
Camada de percepção - É na camada de percepção que se encontram os
objetos físicos e os dispositivos de sensores. Os dispositivos de sensores
podem ser: RFID, código de barras e sensores infravermelho. Essa camada
fica responsável por identificar os objetos através dos dispositivos de sensores.
Dependendo do tipo de sensores, a informação pode ser sobre a localização, a
temperatura, entre outras informações. A informação recolhida é depois
passada para a camada de rede (Khan et al. 2012).
Camada de rede – A camada de rede também pode ser chamada de camada
de transmissão. Essa camada transfere as informações, obtidas pelos
sensores, para o sistema de processamento. Essa transferência de informação
se dá de forma segura. O meio de transmissão pode ser com ou sem fio e a
tecnologia pode ser 3G, UMTS, Wifi, Bluetooth, infravermelho, ZigBee, entre
28
outros. Assim, a camada de rede transfere as informações da camada de
Percepção para a camada Middleware.
Camada de Middleware – Os vários dispositivos sobre a IoT fornecem
diferentes serviços. Cada dispositivo se conecta e comunica apenas com os
outros dispositivos que implementam o mesmo tipo de serviço. Essa camada
fica responsável por gerenciar os serviços e tem uma ligação com o banco de
dados. Essa camada recebe as informações da camada de rede e as
armazena no banco de dados (Khan et al. 2012).
Camada de aplicação – Essa camada fornece gerenciamento global do
aplicativo com base nas informações processadas por objetos na camada
Middleware. É nessa camada que se encontram as diversas aplicações
implementadas pela IoT.
Camada de negócios – Essa camada é responsável pelo gerenciamento do
sistema global, incluindo as aplicações IoT e serviços. É nessa camada que
são construídos os modelos de negócios, os gráficos, os fluxogramas, entre
outros, isso tudo com base nos dados recebidos (Khan et al. 2012).
2.4. Aplicações da IoT
Com o surgimento da IoT pode ocasionar um impacto muito grande para
sociedade, ambiente, economia. A IoT pode ser introduzida em uma variedade
de domínios, como por exemplo: transporte, rastreamento de ativos, ambientes
inteligentes, energia, defesa e agricultura. Nesses vários domínios podemos ter
diversas aplicações da IoT. Essas aplicações podem ser classificadas com
base no tipo de disponibilidade da rede, a cobertura, a escala, a
heterogeneidade. Alguns exemplos de aplicações nos domínios: pessoal e
doméstico; empresa; utilitários e móvel; saúde.
29
Domínio pessoal e doméstico: A IoT pode ser aplicada para monitorar a
saúde de uma pessoa, outro exemplo de aplicação seria que um médico em
sua casa poderia monitorar um paciente sem precisar ir até a casa desse
paciente. Já no domínio doméstico a IoT poderia ser aplicada para que
pessoas pudessem controlar os eletrodomésticos, como por exemplo: ar
condicionado, máquinas de lavar, geladeiras e etc.
Empresa: A IoT pode ser aplicada para controlar o ambiente empresarial
como por exemplo: a iluminação. Outro exemplo importante onde a IoT
pode ser aplicada na empresa seria: na parte de segurança, automação,
controle de temperatura, etc.
Utilitários: A IoT pode ser aplicada em empresas de serviços públicos, como
por exemplo, um medidor inteligente para medir o fornecimento de água e
energia elétrica para gestão desses recursos, visando otimizar o custo
versus lucro. Na parte de vigilância também pode ser aplicada, com o intuito
de identificar atividades suspeitas e monitorar acesso não autorizado.
Móvel: A IoT pode ser aplicada para monitorar tempo de viagem entre a
origem e o destino, o comportamento de escolha de rota, comprimento de
fila. Pode ser aplicada também para monitorar o tráfego nas estradas.
Saúde: A IoT pode ser aplicada na saúde para rastreamento de objetos e
pessoas(funcionários e pacientes), identificação e autenticação de pessoas,
coleta automática de dados e sensoriamento. O rastreamento serviria para
localizar objetos e ter um controle de fluxo de trabalho em hospitais. Com
relação à identificação, um paciente é identificado para que não ocorram
acidentes, no caso de dar a medicação errada ou dar uma dose errada do
medicamento. Na parte de autenticação serve para dar acesso a locais
restritos. Com relação a coleta de dados, serve para reduzir o tempo de
processamento, automatização de processos e automatização de
30
atendimento. O sensoriamento serve para verificar as condições do
paciente.
Esses são alguns dos exemplos onde a IoT pode ser aplicada. Existem
outros como por exemplo: aeroespacial, aviação, telecomunicações, edifícios
inteligentes, farmacêutica, varejo, logística, produção, petróleo e gás.
2.5. Desafios da IoT
A IoT propõe que qualquer objeto do mundo real esteja conectado à
rede e para que isso ocorra a IoT tem que superar uma série de desafios, como
por exemplo: privacidade; normalização e interoperabilidade; e quantidade de
dados grande.
Com relação à privacidade, precisa ter segurança e controle de acesso e
o gerenciamento de identidade. A IoT tem o desafio de saber quem pode ver o
que e com que credenciais.
Outro desafio da IoT é com relação a normalização e a
interoperabilidade, visto que a normalização e interoperabilidade tem que
garantir que a IoT vai continuar a funcionar mesmo com novas aplicações e
que não vai ser preciso construir uma nova rede desde o inicio para suportar as
novas aplicações.
A IoT tem como desafio a questão do fluxo dos dados, visto que, vão ter
muitos objetos e pessoas conectados à rede e com isso vai existir uma
quantidade enorme de dados transitando pela rede.
31
3. Sistemas Operacionais para Internet das Coisas
A Internet das coisas se refere a objetos que são identificados
unicamente e são representados virtualmente na Internet. Identificação de
frequência de rádio (RFID) é normalmente pré-requisito para a Internet das
coisas. Se todos os objetos e pessoas fossem equipados com etiquetas de
rádio poderiam ser identificados por computadores. Mas a identificação única
pode ser feita através de outros meios, como código de barras e códigos
específicos.
A IoT ao combinar sistemas computacionais e sistemas de comunicação
com os elementos físicos passa a fazer parte de sistemas chamados CPS
(Cyber-Physical Systems). Sistemas CPS são sistemas físicos projetados para
que suas operações sejam monitoradas, coordenadas, controladas e
integradas por um núcleo de computação e comunicação. Podem ser
encontrados em diversas áreas como automotiva, processos químicos e
transporte. Esses sistemas são muitas vezes chamados simplesmente de
sistemas embarcados. Nos sistemas embarcados a ênfase tende a ser mais
sobre os elementos computacionais e menos sobre a ligação intensa entre os
elementos computacionais e físicos.
Pela necessidade de identificar “as coisas” combinando sistemas
computacionais com sistemas de comunicação, a IoT precisa de suporte para
redes de sensores sem fio e de sistemas operacionais especializados.
3.1. Requisitos Necessários
Vários são os requisitos necessários em um sistema operacional para IoT
(Baccelli et al. 2013):
Ter requisitos mínimos de memória e poder de processamento;
Habilidade para executar em um hardware restrito os componentes
como MMU (Memory Management Unit) ou FPU (Floating-Point Unit);
Suportar uma variedade de plataformas de hardware;
Ter um alto grau de eficiência de energia;
32
Ter uma interface de programação padrão;
Suportar linguagens de programação de alto nível;
Ter uma pilha de rede modular e adaptativa;
Confiabilidade.
As redes de sensores sem fio necessitam de conectividade, abstração
de hardware e gerência de recursos limitados. Além dos requisitos já citados,
os sistemas operacionais para IoT precisam de uma série de requisitos para
suprir as necessidades das redes de sensores sem fio. Esses requisitos são
[Wanner et al. 2008] listados a seguir.
Fornecer a funcionalidade básica de um sistema operacional: O
sistema operacional deve fornecer à rede de sensores sem fio serviços
tradicionais como: abstração de hardware, gerência de processos, serviços de
temporização e gerência de memória.
Fornecer mecanismos para a gerência de consumo de energia nos
nodos: Os sistemas operacionais devem prover mecanismos de gerência de
energia às aplicações e o sistema operacional deve utilizar os recursos de
hardware com o intuito de consumir o mínimo de energia possível para que se
possam executar as aplicações de maneira satisfatória.
Prover mecanismos para reprogramação em campo: Os requisitos e
os parâmetros das aplicações de sensoriamento podem mudar com o tempo,
com isso se faz necessária a reprogramação em campo, via rede de
comunicação. Um sistema operacional para rede de sensores ideal deve
fornecer algum mecanismo de reprogramação total ou parcial para aplicações
já instaladas.
Abstrair o hardware de sensoriamento heterogêneo de maneira
uniforme: Na rede de sensores há uma grande variedade de hardware. Então
uma aplicação desenvolvida em uma determinada plataforma, dificilmente será
portável para outra plataforma, a menos que os sistemas de suporte de tempo
de execução destas plataformas abstraiam e encapsulem adequadamente a
plataforma de sensoriamento.
33
Fornecer uma pilha de protocolos de comunicação configurável: O
sistema operacional deve fornecer mecanismo de configuração dos protocolos
de configuração da pilha de comunicação a ser utilizada na rede.
Principalmente a configuração dos protocolos de controle de acesso ao meio,
visto que é nessa camada de rede que ocorrem os impactos no desempenho e
no consumo de energia.
Operar com recursos limitados: Esse requisito é de extrema
importância, visto que tem que ocorrer baixo consumo de energia para redes
de sensores, sendo necessário um micro controlador de baixa potência para
executar as funções de processamento nos nodos. Esses micro controladores
são geralmente restritos em sua capacidade computacional e possuem
pequena quantidade de memória disponível. Um sistema operacional deve
entregar os serviços necessários à aplicação, sem consumir muito dos
recursos computacionais disponíveis.
Assim podemos observar que um sistema operacional para dispositivos
da Internet das coisas tem que encontrar o equilíbrio entre as restrições do
hardware e da usabilidade para desenvolvedores (Baccelli et al. 2013).
Na tabela 1 são comparados os sistemas operacionais: na questão de
requisitos mínimos em termos de memória ram e rom de uso para aplicação
básica; Contiki tem suporte parcial a liguagem C, pois utiliza um subconjunto da
programação em linguagem C, onde algumas palavras-chave não pode ser
usado, enquanto TinyOS não tem suporte e RIOT tem suporte total a
linguagem C; Contiki e tinyOS não possuem suporte a liguagem C++ e RIOT
possui suporte total dessa linguagem; Contiki e TinyOS são baseados em
modelo orientado a evento, de forma que todas as tarefas sejam executadas
dentro do mesmo contexto, embora eles oferecem multithreading parcial e
RIOT oferece multithreading total; Todos esses sistemas operacionais
possuiem MCU sem o gerenciamento de memória;
Sistema
Operacional
RAM
Min
ROM
Min
Suporta
C
Suporta
C++
Multi-
threading
MCU sem
MMU
34
Contiki <2KiB <30KiB Parcial Não Parcial Total
TinyOS <1KiB <4KiB Não Não Parcial Total
RIOT ~1.5KiB ~5KiB Total Total Total Total
Tabela 1 – Comparação de sistemas operacionais
Fonte: Adaptado de (Baccelli et al. 2013)
3.2. RIOT
RIOT começou a ser desenvolvido em 2008 e no início era um sistema
operacional para redes de sensores sem fio, chamado FeuerWare e o
monitoramento de bombeiros fazia parte do projeto FeuerWare. Os principais
objetivos desse projeto eram a confiabilidade e garantias em tempo real. Em
2010, foram incluídos novos protocolos IETF (Internet Engineering Task Force)
e para isso, o μkleos foi dividido a partir do repositório original FeuerWare. A
partir disso foi possível dar suporte aos protocolos 6LoWPAN, RPL, e TCP. Em
2013, RIOT se torna público. E seu nome que era μkleos passa a ser chamar
RIOT. A mudança de nome ocorreu para se evitar problemas com a ortografia
e com a pronúncia do nome do sistema operacional (Riot et al. 2013).
RIOT é executado em várias plataformas, como por exemplo: em
sistemas embarcados e bem como computadores comuns. RIOT suporta vários
drivers. O código dependente do hardware é reduzido ao mínimo e captado a
partir do próprio núcleo (Riot et al. 2013).
Características importantes da RIOT: ambiente de desenvolvimento
amigável, recurso amigável, facilidade em desenvolver aplicações para IoT. O
Sistema Operacional permite: programação em C ou C++; ferramentas de
desenvolvimento padrão com gcc, gdb; minimização de código dependente de
hardware; flexibilidade e robustez do código; ativando a eficiência energética
máxima, multi-threading; 6LoWPAN , IPv6, RPL , TCP e UDP; alocação de
memória estática e dinâmica; sistema de arquivos FAT; Wiselib apoio (C + +
algoritmo biblioteca, incluindo roteamento, clustering , localização, segurança e
mais algoritmos) (Riot et al. 2013).
35
3.3. Contiki
Contiki é um sistema operacional de código aberto que conecta micro
controladores de baixa potência à Internet. Contiki apoia plenamente o padrão
IPv6 e IPv4 e os últimos padrões wireless de baixo consumo: 6LoWPAN , RPL,
COAP. Contiki é executado em uma grande quantidade de dispositivos sem fio
de baixa potência (Contiki et al. 2013).
Com Contiki, o desenvolvimento de aplicações é rápido e fácil. As
aplicações podem ser desenvolvidas em C e através do Contiki é possível usar
o Cooja, um simulador de redes sem fio (Contiki et al. 2013).
Características importantes do Contiki: o Contiki foi projetado para
trabalhar ocupando pouco espaço de memória, com isso ele é altamente
eficiente de memória; rede IP completa, com protocolos como: UDP, TCP,
HTTP, 6LoWPAN, RPL, COAP e IPv6; opera em sistemas de baixo consumo
de energia; o sistema de compilação Contiki torna mais fácil: compilar
aplicativos para qualquer uma das plataformas Contiki disponíveis e com isso
facilita o teste de aplicativos em uma variedade de plataformas (Contiki et al.
2013).
3.3.1. COOJA
COOJA é um simulador baseado em Java, que foi projetado para redes
de sensores sem fio e o COOJA é executado no sistema operacional Contiki.
COOJA simula rede de nós sensores, onde cada nó pode ser de um tipo
diferente, diferindo tanto no software quanto no hardware. Muitas partes do
simulador podem ser facilmente substituídas ou estendidas com novas
funcionalidades. Exemplos de partes que podem ser estendidas incluindo na
simulação: meio rádio, hardware nó simulado, e plug-ins para simulação de
entrada e saída (Österlind et al. 2006).
Um nó simulado em COOJA tem três propriedades básicas: sua
memória de dados, o tipo de nó e seus periféricos de hardware. O tipo de nó
36
pode ser compartilhado entre vários nós e determina a propriedades comuns
de todos esses nós.
Todas as interações com simulações e nós simuladas são realizadas
através de plug-ins. Um exemplo de plug-in é um plug-in que possibilita que um
usuário inicie ou pause a simulação. Interfaces e plug-ins podem ser facilmente
adicionados ao simulador, com isso facilitando aos usuários a personalização
da sua simulação (Österlind et al. 2006).
3.4. TinyOS
TinyOS é um sistema operacional projetado para redes de sensores sem
fio que funciona ocupando pouco espaço de memória. Com esse sistema
operacional é possível criar aplicações da Internet das coisas e através do
simulador TOSSIM é possível simular a Internet das coisas (Lemos et al. 2010).
Características importantes do TinyOS: uma arquitetura baseada em
componentes; um modelo de concorrência simples baseado em tarefas e
eventos; operações divididas em fases.
A arquitetura baseada em componentes possibilita que os componentes
possam ser reutilizáveis e com isso cada aplicação pode escolher os
componentes que necessita.
Com relação à concorrência baseada em tarefas, as tarefas são
escalonadas e à medida que uma tarefa é escalonada, essa tarefa é executada
até terminar, isto é, uma tarefa não interfere na outra. Já os componentes
podem postergar a execução de tarefas.
Como não há preferência entre as tarefas, o código a ser executado por
elas deve ser curto, com o objetivo de evitar que uma tarefa postergue
indefinidamente outras tarefas.
O escalonador de tarefas utiliza a política FIFO (First In First Out) e o
escalonador é configurado para deixar a tarefa executar sempre que o
processador estiver disponível.
37
Já com relação à concorrência dos eventos, os eventos são executados
até terminarem, mas os eventos podem ter direito à preferência com relação a
tarefas e a outros eventos.
As operações de longa duração são divididas em fases, por que as
tarefas não têm direito de preferência uma sobre outra para serem executadas
pelo processador e com isso não acontece operações de bloqueio.
3.4.1. TOSSIM
TOSSIM é um simulador de eventos discretos do sistema operacional
TinyOS. Após compilada uma aplicação TinyOS é gerado o código para que se
possa escrever o script de simulação. Esses scripts podem ser escritos em
Python e C++ e através desses é possível simular nodos sensores, para testar
a aplicação (RODRIGUES, 2013).
Uma desvantagem desse simulador é que ele apenas simula a
plataforma de hardware MicaZ. Outra desvantagem desse simulador é que só é
possível simular nativamente somente uma rede utilizando um software por
vez, o que o torna inviável para simulação de 6LoWPAN e esse protocolo é
importante para a IoT (VITALI, 2012).
A principal diferença entre TOSSIM e COOJA é como os vários nodos
estão representados nos diferentes simuladores. Em TOSSIM, o problema de
simular vários nós é resolvido, alterando o código nó sensor. Todas as
variáveis são substituídas por matrizes, em que cada elemento de uma matriz
pertence a um nó correspondente. Isso é feito automaticamente quando o
código é compilado para o simulador ambiente, com o resultado que todos os
nós são simulados no mesmo processo. Em COOJA, o código executado
permanece inalterado, e quando simular vários nós, do mesmo tipo, todos
estes são executados um a um no mesmo processo (Osterlind, 2006).
3.5. Mantis OS
38
Mantis é um sistema operacional que funciona com múltiplas threads
que são capazes de realizar múltiplas tarefas em energia limitada. O sistema
operacional possibilita que as threads tenham o direito a preferência sobre
outras, ou seja, uma thread pode entrar em execução sem que outra tenha
terminado a tarefa. Como resultado, o sistema operacional pode responder
mais rapidamente a acontecimentos críticos (Duffy et al. 2006).
O escalonador de threads do Mantis OS utiliza o sistema de round-robin
com prioridade. Ao se iniciar o sistema operacional a thread idle é criada e
caso todas as threads estejam bloqueadas, a thread idle é executada (Wanner
et al. 2008).
O Mantis OS fornece uma interface unificada de comunicação na forma
de uma ou mais threads de usuário. Para as diversas interfaces de
comunicação o Mantis OS utiliza um formato de pacote unificado, onde a
camada de comunicação gerencia a sincronização e a buferização de pacotes.
39
4. Desenvolvimento prático
4.1 Introdução
Neste trabalho de conclusão de curso foi estudado e testado o ambiente
COOJA e o sistema operacional Contiki. Esses ambientes são usados para
desenvolver experimentos de simulação existentes na Internet das Coisas
(IoT).
O sistema operacional Contiki, descrito no capítulo 3, tem código aberto,
possui um maior grau de portabilidade entre plataformas e suporta IPv6, que é
necessário para a IoT (OSTERLIND et al., 2000).
Com o simulador COOJA é possível simular diferentes tipos de nodo da
rede, tanto em nível de hardware quanto de software. Diversas partes do
simulador podem ser substituídas ou estendidas, assim como o meio de
comunicação de rádio, o hardware simulado e plug-ins de entrada e saída de
dados (Österlind, 2006). Um exemplo de plug-in do COOJA é o Cooja Timeline,
que é um módulo que possibilita a visualização do tráfego da rede e do
consumo energético dos nodos sensores.
O COOJA suporta protocolos implementados em Java especificamente
para a simulação e o COOJA é um simulador flexível baseado na linguagem
Java, projetado para simular a IoT no sistema operacional Contiki. O sistema
operacional Contiki, descrito no capítulo 3, foi escolhido como ambiente de
execução da simulação.
Um nó sensor simulado no Cooja possui três propriedades básicas:
memória; tipo do nó sensor; hardware periféricos.
O tipo de nó sensor pode ser similar a outros nós da rede e determina
propriedades comuns para os nós deste tipo. Por exemplo, nós do mesmo tipo
executam o mesmo código de programa para hardware periféricos simulados.
Os nós de mesmo tipo são inicializados com a mesma configuração de
memória, mas com o passar do tempo da execução da simulação, as
memórias desses nós podem variar de acordo com a execução das funções da
40
rede. Nós de mesmo tipo, eventualmente vão possuir dados diferentes,
baseados nas diferentes entradas de dados que recebam (OSTERLIND et al.,
2000).
Contiki foi projetado especificamente para sistemas embarcados e redes
de sensores sem fio. Esse sistema operacional tem suporte ao protocolo de
Internet Ipv6 e mecanismos de comunicação via rádio de baixo consumo de
energia por meio de três pilhas de comunicação (SANT’ANNA, 2010):
• Rime: uma pilha de comunicação de formato simples que provê
comunicação primitiva e sobre esta pilha mais complexos protocolos de
comunicação são construídos (SANT’ANNA, 2010).
• µIP: é pilha TCP/Ipv4 mínima compatível com Request For Comments
(RFC) (SANT’ANNA, 2010).
• µIPv6: é a menor pilha TCP/IPv6 do mundo, também compatível com a
RFC (SANT’ANNA, 2010).
O sistema operacional Contiki suporta três tipos de protocolos de
controle de acesso ao meio (Media Access Control (MAC)). Os três tipos são:
NULL-MAC, X-MAC e Lower Power Probing (LPP). O X-MAC e LPP são
protocolos conservadores de energia e o NULL-MAC é o mais simples dos
protocolos MAC (SANT’ANNA, 2010). A implementação do protocolo X-MAC
disponível no Contiki possui dois importantes parâmetros. Esses parâmetros
são: On Time e Off Time. O On Time é o tempo de duração que o sensor
mantém o rádio ligado aguardando mensagens já o Off Time é o tempo de
duração entre dois On Time, na qual o rádio está desligado.
No COOJA é possível emular um nó sensor da plataforma Tmote Sky,
que é um disposistivo de baixo consumo de energia baseado nas
especificações IEEE 802.15.4. Este dispositivo possui os seguintes atributos:
• microcontrolador de 8MHz Texas Instruments MSP430 (10Kb RAM
(random Access Memory), 48Kb de memória interna Flash, 1MB memória
externa Flash).
• sensores de umidade, temperatura e luz.
41
• transmissores sem fio Chipcon IEEE 802.15.4 com velocidade de
processamento de 2.4GHz e velocidade de transmissão de 250Kbps
(SANT’ANNA, 2010).
4.2 Instalação da máquina virtual Contiki
A máquina virtual foi instalada em um computador:
- Intel core i5 2,6Ghz e 8GB de memória RAM, esse computador está
rodando Windows 7.
Essa máquina virtual contêm o ambiente de simulação COOJA. Segue
os passos para a instalação:
- Fazer o download VMWare Player e o download do Instant Contiki.
Instalar a VMWare Player (Contiki et al. 2013).
- Depois de baixado o arquivo InstanContiki2.7.zip e de descompactado,
dentro da pasta InstantContiki2.7 vai ter um arquivo chamado
Instant_Contiki_Ubuntu_12.04_32-bit, esse arquivo vai configurar o sistema
operacional Instant Contiki para rodar dentro da VMWare Player.
Da inicialização do Instant_Contiki_Ubuntu_12.04_32-bit, abre-se o
programa VMware Player e lá já vai estar o Instant_Contiki_Ubuntu_12.04_32-
bit configurado e pronto para ser inicializado. No Vmware Player execute o
InstantContiki2.7 e aguarde a inicialização da máquina virtual Ubuntu. Feito
isso, aparecerá a tela de login, como mostra na figura 4. A senha é user
(Contiki et al. 2013).
42
Figura 4: tela de login do ubuntu.
4.3 Funcionamento básico do COOJA
4.3.1 Inicialização do COOJA
Depois de feita toda a instalação do ambiente de trabalho, iniciaremos a
utilizar o COOJA. A inicialização dele pode ser feita de duas formas: na
primeira, abre-se um terminal e se localiza o diretório do cooja, com o seguinte
comando: cd contiki/tools/cooja e para iniciar utiliza-se o seguinte comando: ant
run; a segunda forma, como mostra na figura 5, seria abrir o executável Cooja
que aparece na área de trabalho da máquina virtual.
43
Figura 5: área de trabalho do InstantContiki2.7
4.3.2 Criando uma nova simulação no COOJA
Para se criar uma nova simulação, depois do programa aberto, vá no
menu file e aperte, irão aparecer algumas opções, aperte em new simulation,
como mostra a figura 6 (Contiki et al. 2013).
44
Figura 6: criando uma nova simulação parte 1.
A seguir irá abrir uma janela, como na figura 7. Nessa figura, temos as
opções: colocar o nome para a simulação; em radio medium, você vai
selecionar o meio de rádio que melhor se aplica para a sua simulação, para o
caso de IoT, selecionaremos Unit Disk Graph Medium (UDGM), que é uma
unidade simples que se pode mudar o alcance de transmissão do rádio,
pequenas distâncias; em mote startup delay(ms), serve para iniciar
aleatoriamente cada mote, para eles não iniciarem todos ao mesmo tempo;
Random seed é uma semente para o gerador de números aleatórios; na opção
new random seed on reload, você pode selecionar o box ao lado para obter
uma semente aleatória (SEHGAL, 2013). Quando você clicar no botão create,
irá aparecer o ambiente de simulação, como mostra na figura 8.
Figura 7: criando uma nova simulação parte2.
45
Figura 8: Ambiente de simulação do COOJA.
4.3.3 Criando um tipo de nó
Qualquer nó simulado em COOJA pertence a um tipo de nó. O tipo de
nó determina, entre outros, que tipo de aplicativo Contiki irá simular. Para criar
um nó, clica-se no menu motes, creating new mote type, sky mote, como
mostra a figura 9 (SEHGAL, 2013). Sky mote é um sensor sem fio de baixo
consumo de energia.
46
Figura 9: Criando um nó do tipo Sky mote.
Depois que clicar em Sky mote, irá aparecer uma nova janela, como
mostra na figura 10. Nessa janela, você fará uma descrição de qual tipo de nó
vai ser e também irá escolher qual programa contiki será compilado. O
programa contiki a ser compilado, é um arquivo com extensão .c. Depois de
selecionado o arquivo, aperta-se o botão compile, após compilado, aperta-se o
botão create, agora está pronto para adicionar um ou vários nós desse novo
tipo (SEHGAL, 2013).
Figura 10: Criando um nó do programa contiki a ser compilado.
47
4.3.4 Adicionando um tipo de nó
Após a criação de um tipo de nó é possível adicionar um ou mais nós
desse tipo, acessando através de motes, add motes, [sua descrição do tipo de
mote], como motra na figura 11.
Figura 11: Adicionando um nó do tipo Sky Mote Type #sky1.
Depois de apertar em Sky Mote Type #sky1, irá aparecer uma janela,
como mostra na figura 12, onde você poderá definir quantos nós você vai
querer adicionar, as posições desses nós, essas posições podem ser
aleatórias, linear, elipse e manual (VOIGT, 2009). Depois de definir quantos
nós e suas posições é só apertar em add motes.
Figura 12: Adicionando e definindo a posição dos nós do tipo Sky Mote Type
#sky1.
48
4.3.5 Inicializando uma simulação
Depois de criada uma nova simulação e adicionados os nós para serem
simulado, o ambiente COOJA terá alguns plugins abertos, esses plugins
podem ser acessados pelo menu tools, como mostra a figura 13. Para iniciar
uma simulação basta apertar o botão Start que se encontra no plugin
Simulation Control (VOIGT, 2009).
Figura 13: plugins: Network; Mote output; Timeline; Breakpoints; Radio
messages; Simulation script editor; Notes; Buffer view; Mote radio duty cycle.
4.3.6 Plugins
Os plugins são utilizados para interagir com uma simulação.
Frequentemente fornece ao usuário alguma interface gráfica para ser possível
observar algo interessante na simulação (OSTERLIND et al., 2000). A seguir
segue a descrição de alguns plugins.
- Network: Nesse plugin é possível visualizar o layout da rede, ou seja,
as posições dos nós, como mostra na figura 14 (VOIGT, 2009). No menu view
é possível determinar as informações na qual podem ser vistas no layout da
rede. No menu é possível você aproximar ou afastar a visualização da rede.
49
Figura 14: Layout da rede.
- Mote output: Na figura 15 é mostrada a interface do Mote output,
nessa interface aparecem as informações da saída serial de cada nó, isto é, a
saída do comando printf. No Filter, você pode filtrar qual nó você quer que a
interface mostre a saída. Como por exemplo, você deseja que a interface só
mostre a saída do nó 2, então você deve introduzir nesse campo ID: 2
(SEHGAL, 2013).
Figura 15: Saída serial dos nós.
- Timeline: Nesse plugin são mostrados os eventos que ocorrem em
cada nó sobre a linha do tempo de simulação. Esses eventos podem ser:
Tráfego de rádio; rádio ligado ou desligado; canal de rádio; LEDs; log de saída
e pontos de saída, isso é mostrado na figura 16 (SEHGAL, 2013). Um exemplo
é o evento relacionado com o rádio, onde o branco representa que o estado do
rádio trasceptor está desligado e acinzentado se estiver ligado. Eventos
relacionado com transmissão de rádio, onde o azul indica pacote transmitido,
50
verde indica pacote recebido e vermelho indica que pode ter ocorrido uma
interferência (VOIGT, 2009).
Figura 16: Timeline mostrando alguns eventos.
- Breakpoints: Com esse plugin é possível parar a simulação quando
um evento ocorre ou quando um evento de rádio ocorre, isso de forma geral.
Também é possível parar a simulação, quando a interface de um nó muda, dá
para selecionar uma ou mais interfaces, no qual se deseja parar quando ocorre
a mudança na(s) interface(s). Na figura 17 é possível visualizar a interface do
breakpoints.
Figura 17: Interface do breakpoints
- Radio messages: Com este plugin é possível visualizar os pacotes
recebidos e enviados por cada nó, o tempo em que foram produzidos e os
mesmos conteúdo do pacote em hexadecimal e de caracteres ASCII, como
mostra na figura 18.
51
Figura 18: Interface do radio messages.
- Simulation script editor: Com esse plugin é possível controlar e
automatizar a execução por meio de scripts, escritos em java script. Ele permite
iniciar e parar a simulação, pode definir o tempo limite de simulação, adicionar
e remover nós de forma dinâmica, capturar a saída dos nós sensores e
interagir com plugins COOJA. Na figura 19 é mostrado um exemplo desse
plugin.
Figura 19: Interface do simulation script editor.
- Notes: Nesse plugin é possível fazer algumas anotações temporárias
sobre a simulação (SEHGAL, 2013).
52
- Buffer view: Com esse plugin é possível vizualizar o que está
ocorrendo em cada buffer de cada nó, se está acontecendo uma leitura do
buffer ou uma escrita, como mostra na figura 20.
Figura 20: Interface do buffer Listener.
- Mote radio duty cycle: Essa interface mostra a porcentagem que cada
nó ficou ligado ou enviou uma menssagem (TX) ou recebeu uma mensagem
(RX) naquele exato momento, como mostra na figura 21.
Figura 21: Interface do PowerTracker.
4.3.7 Salvando, carregando e recarregando uma simulação
Quando salvamos uma simulação, os plugins que estão ativos também
serão salvos com a simulação, mas o estado atual da simulação não será
salvo, com isso os nós serão reiniciados quando essa simulação for carregada
de novo. Para salvar sua simulação, basta ir no menu file e apertar save
53
simulation as, como mostra na figura 22. A simulação é salva em um arquivo
com extesão .csc. Para carregar uma simulação, basta ir no menu file, open
simulation e apertar em browse e procurar um arquivo .csc ou apertar em umas
das simulações que foi aberta recentemente. Quando uma simulação é
carregada, todas as aplicações contiki são recompiladas (VOIGT, 2009). Já
para recarregar uma simulação basta apertar o botão reload que se encontra
no plugin simulation control.
Figura 22: Salvando uma simulação.
4.4. Descrição de arquivos necessários para a compilação de
simulações
4.4.1 Introdução
COOJA executa código nativo, fazendo chamadas Java Native Interface
(JNI) de ambiente Java para um Sistema Contiki compilado. O simulador Java
tem total controle sobre a mémoria de nós simulados (OSTERLIND et al.,
2000).
COOJA simula o sistema operacional executando o código do sistema
operacional nativo, no caso Contiki. Como todo o sistema operacional Contiki é
executado, incluindo quaisquer processos de usuário, com isso é possível
alterar a funcionalidade do núcleo Contiki. Isto é util, por exemplo, para testar e
avaliar mudanças na inclusão de bibliotecas do Contiki.
54
O sistema operacional Contiki é orientado a eventos, cada evento
tratado no sistema pode ser executado até a conclusão (OSTERLIND et al.,
2000). COOJA explora esta propriedade chamando o sistema Contiki
carregado de modo que cada nó simulado apenas lida com um evento de cada
vez.
Ao simular nós em código nativo, o tipo de nó atua como elo entre um nó
e o sistema Contiki compilado. O tipo de nó carrega a biblioteca compartilhada
compilada e toda a iteração entre o simulador e a biblioteca se dá dessa forma.
COOJA precisa de um único segmento de memória para copiar e
carregar a biblioteca Contiki, que são o segmento de dados e do BSS (Block
Storage System). Para nós de mesmo tipo, o segmento de texto é o mesmo,
então não precisa ser copiado, diferente do segmento de dados e do BSS que
precisam ser copiados, como mostra na figura 23 (OSTERLIND et al., 2000).
Uma visão geral de um nó simulado em COOJA é mostrado na figura 24.
Figura 23: Controlando Contiki , através da manipulação dos segmentos de
memória (OSTERLIND et al., 2000).
55
Figura 24: O tipo de nó funciona como uma ligação para a biblioteca Contiki
carregada (OSTERLIND et al., 2000).
4.4.2 Arquivos necessários
Para que um nó possa ser simulado no COOJA é necessário que o
código Contiki seja compilado (arquivo .c), e para conseguir compilar esse
arquivo .c é preciso ter um arquivo makefile na mesma pasta. O makefile define
as regras de compilação para o projeto. A figura 25, mostra um exemplo de um
makefile. Existem duas formas de executar esse arquivo, que são:
- Abra o terminal e vá até o diretório do projeto, onde se encontram os
arquivos .c e makefile. Estando no diretório do projeto é só digitar make e
apertar enter, nesse caso o arquivo será compilado com o TARGET = native,
mas você pode mudar para o TARGET que você desejar, como por exemplo:
ao invés de só digitar make, digita-se make TARGET = sky.
- A segunda forma seria, abrindo o COOJA, indo no menu motes, add
motes, creating new mote type, sky mote, como mostra a figura 9. Irá abrir uma
nova janela, nessa janela em browser você vai procurar o arquivo .c que você
deseja compilar e depois apertar o botão compilar.
56
Figura 25: Make file de um hello world.
Depois que os arquivos .c do projeto forem compilados, na pasta do
projeto serão criados mais alguns arquivos, como mostra na figura 26. Depois
que o arquivo é compilado ele cria o objeto, um arquivo de mapeamento de
memória do Contiki e um arquivo hello-world.sky, esse arquivo hello-world.sky
pode ser usado pelo COOJA para criar um nó desse tipo. No COOJA seguindo
os passos para a criação de um nó, na janela create mote type, você aperta em
browse e seleciona o arquivo .sky, com isso o botão create irá aparecer e daí é
só apertar esse botão, como mostra na figura 27.
Figura 26: Arquivos gerados após a compilação.
Figura 27: Criando um nó apartir de um arquivo .sky
4.5. Exemplo de uma simulação: Hello World
57
Para poder simular um hello world no COOJA, primeiro é necessário
compilar o arquivo hello-world.c no sistema operacional Contiki, para depois
simular um nó desse tipo no simulador. Então inicialmente vamos criar uma
pasta do projeto.
Nesse exemplo iremos criar a pasta do projeto no caminho:
home/contiki-2.7/examples/HelloWorld. Nessa pasta temos que criar dois
arquivos, que são: hello-world.c e o makefile, que tem as regras de compilação
do projeto. O makefile do hello-world é igual ao da figura 25.
Nesse makefile foi definida a localização da pasta onde se encontra o
código fonte Contiki, isso se dá pela definição da variável CONTIKI. Também é
definido o nome da aplicação, ou seja, do projeto. E também através do
comando Makefile.include, o sistema Contiki é incluído, com suas bibliotecas.
Agora vamos criar o arquivo hello-world.c, o código desse arquivo vai
ficar igual ao da figura 28.
Figura 28: Código do hello-world.c
Nesse código, temos dois include, o #include “contiki.h, contém todas as
declarações do sistema operacional Contiki e o outro include serve para poder
utilizar a função printf() dentro do programa. O código:
PROCESS(hello_world_process, “Hello world process”); declara um novo
processo Contiki, onde o primeiro parâmetro é a variável para o processo e o
segundo parâmetro é o nome para o processo. No código:
AUTOSTART_PROCESSES(&hello_world_process); especifica que o processo
58
deve ser iniciado na inicialização do sistema operacional Contiki, portanto,
quando o dispositivo de hardware que será o destino do código compilado é
ligado, o nosso processo também começa a ser executado (SENSTOOLS,
2014).
No código PROCESS_THREAD(hello_world_process, ev, data) abre a
definição do nosso processo. No primeiro parâmetro passamos a variável de
processo, o segundo parâmetro é de evento, ele pode ser usado pelo programa
para responder a eventos que ocorram no sistema operacional e o terceiro
parâmetro é usado para receber dados que estão vindo com esses eventos
(SENSTOOLS, 2014).
Dentro das linhas de código PROCESS_BEGIN() e PROCESS_END() é
que realmente vai se encontrar o que o programa deve fazer (SENSTOOLS,
2014). No nosso exemplo, ele só vai imprimir na tela “Hello, world”, no caso de
esse arquivo, depois de compilado, seja executado pelo terminal. Mas se
deseja simular esse código no COOJA.
Tendo esses arquivos (hello-world.c e makefile) prontos dentro da pasta
do projeto, vamos abrir o COOJA. Cria-se uma nova simulação, como já
explicado anteriormente. Cria-se um nó do tipo sky mote, como explicado
anteriormante. Nó do tipo sky mote, tem um processador que roda no máximo
8MHz , tem 10KB de ram, 1Mbit de memória flash e tem um Chipcon CC2420
rádio operando a 2.4GHz, com aproximadamente 100 metros de alcance.
Cada nó do tipo sky mote tem sensores para luz, umidade e temperatura
(CREW-PROJECT, 2014).
Após criado o nó do tipo sky mote, devemos adicionar nós desse tipo
para podermos simular, como já explicado anteriormente. Para nosso exemplo,
vamos adicionar 2 nós desse tipo. Após adicionarmos esses nós, vamos
executar a simulação, que é só pertar no botão start que fica no simulation
control. Na figura 29, é mostrada a interface do COOJA, após simular o hello
world.
59
Figura 29: hello world simulado no COOJA
Como podemos observar, que o programa hello-world compilado no
Contiki e simulado no COOJA faz com que os nós sejam iniciados com seus
respectivos endereços, são definidos seus ids, são definidos os canais de rádio
desses nós e também é iniciado o processo hello world, que tem como
finalidade imprimir o “hello world” na porta serial do nó. Essas informações
podem ser observadas no plugin output mote, como mostrado na figura 29.
4.6. Funcionamento do protocolo RPL (Routing Protocol for Low-Power
and Lossy Networks) no COOJA
4.6.1 RPL
O protocolo de roteamento para baixo consumo de energia e redes com
perdas (RPL) é um protocolo de roteamento para as redes IPv6, que foi
desenvolvido com foco em baixa potência e redes com perdas (SCHRICKTE,
2013). Esse protocolo define um roteamento eficiente de caminhos para os
60
padrões de tráfego multiponto para ponto, ponto para multiponto e ponto a
ponto (Martins, 2013). As redes 6LoWPAN são utilizadas em cenários no qual
existem centenas ou milhares de nós de comunicação onde a disponibilidade
de energia é limitada e a quantidade de perdas pode ser alta. O RPL foi criado
para funcionar mesmo com esses fatores (SCHRICKTE, 2013).
O RPL cria um grafo acíclico digirido orientado a destino, denominado
DODAG (destination oriented directed acyclic graphs), esse grafo tem uma
função objetivo e uma combinação de métricas e restrições (Martins, 2013).
Essas métricas e restrições podem ser específicos para cada rede, como por
exemplo, pode-se escolher caminhos diferentes, onde em tal caminho os nós
não sejam operados à bateria, intensidade do sinal, entre outros (SCHRICKTE,
2013). O grafo é criado através das trocas de mensagem entre os nós. Após
criado um grafo, esse grafo define os caminhos que os dados devem percorrer
e a topologia da rede, sendo que um mesmo nó pode pertencer a vários grafos.
A Figura 30 representa uma instância RPL, onde cada grafo é um
DODAG e a comunicação entre os pontos é feita subindo ou descendo a
estrutura do grafo até alcançar suas folhas.
Figura 30: Intância de um RPL (Martins, 2013).
As regras para definir um grafo e a topologia da rede são determinantes
para um melhor desempenho da rede e com isso permite o protocolo se
adaptar para cada situação. Uma rede pode ter múltiplas topologias. Assim,
uma rede pode escolher o melhor caminho para os dados e a topologia que
melhor se adapta aos requisitos do tráfego de dados.
61
O RPL opera na camada IP e com isso possibilita o roteamento entre
múltiplos tipos de camada de enlace, diferente de outras formas de roteamento,
que operam em camadas inferiores (SCHRICKTE, 2013).
4.6.2 Exemplo do rpl no COOJA
Para mostrar esse exemplo utilizarei uma simulação que já vem com o
sistema operacional contiki que foi baixado. Cenários de simulações já salvos
são arquivos .csc. A simulação desse exemplo encontra-se em: home/contiki-
2.7/examples/ipv6/rpl-collect. Nessa pasta se encontra o arquivo collect-tree-
sparse-lossy.csc que é a simulação que vamos abrir no COOJA (Contiki et al.
2013).
Nessa pasta rpl-collect também tem os arquivos makefile, como mostra
na figura 31, que vai servir para compilar os arquivos udp-sender.c e udp-
sink.c, os quais estão sendo utilizados nesta simulação. Esses dois arquivos
utilizam os arquivos collect-common.c e o collect-common.h, os quais arquivos
vão servir para mostrar alguns resultados de eventos que ocorrem na
simulação no COOJA.
Figura 31: makefile do RPL-collect.
O udp-sender.c da simulação representa os nós clientes e o udp-sink
representa o nó servidor. Todos esses arquivos explicados serão compilados
na hora em que abrirmos a simulação collect-tree-sparse-lossy.csc. Para abrir
62
esta simulação, basta ir no menu file, open simulation, browse, como mostra a
figura 32. Após apertar em browse, irá aparecer uma janela, onde você vai abrir
o arquivo collect-tree-sparse-lossy.csc que está na pasta rpl-collect.
Figura 32: abrindo uma simulação no COOJA.
Após abrir a simulação, o cenário da rede é mostrado na figura 33.
Nesse cenário temos 1 nó udp-sink, que é o servidor, representado pela cor
verde e 24 nós udp-sender, que são os clientes, representados pela cor
amarela.
63
Figura 33: Cenário da rede.
Após iniciarmos a simulação, devemos abrir a janela sensor data collect
with Contiki. Nessa janela iremos apertar no botão Start collect, que serve para
começar a coletar dados dos nós, como mostra na figura 34. Depois de um
tempo vamos apertar no botão send command to nodes, que serve para enviar
comandos aos nós, como mostra na figura 35.
Figura 34: Iniciar coleta de dados dos nós.
64
Figura 35: Enviando comandos aos nós.
Depois de 10 minutos de simulação, nessa janela sensor data collect
with Contiki, podemos pegar alguns resultados da simulação, o quais iremos
mostrar. Na aba network, received (per node), podemos observar a quantidade
de pacotes recebidos por cada nó, como mostra na figura 36.
65
Figura 36: Pacotes recebidos por cada nó.
Na aba network, received (Over time), mostra um gráfico de quantos
pacotes foram recebidos durante o período de tempo de simulação. Nessa
foram recebidos 162 pacotes durante 10 min, como mostra na figura 37.
Figura 37: Pacotes recebidos por tempo.
66
Na aba network, lost (over time), mostra um gráfico de quantos pacotes
foram perdidos durante o tempo de simulação. Nessa simulação foram
perdidos 71 pacotes durante 10 min, como mostra a figura 38.
Figura 38: Pacotes perdidos por tempo.
Na aba power, power history, mostra um gráfico de quanto de energia
um nó consumiu durante um determinado tempo, como mostra na figura 39.
67
Figura 39: Energia consumida por cada nó em um determinado tempo.
Na aba power, average power, podemos observar um gráfico que nos
mostra o quanto de energia foi consumida por cada componente de cada nó,
como mostra na figura 40.
Figura 40: Quantidade de energia consumida por cada componente de cada nó.
68
Na aba power, radio duty cycle, mostra um gráfico da porcentagem em
que o rádio ficou escutando ou ocorrendo uma transmissão de cada nó, como
mostra a figura 41.
Figura 41: Porcentagem do ciclo de trabalho de cada nó.
Na node info, você vai encontrar um variedade de informações, essas
informações são os eventos que ocorreram em cada nó, como mostra na figura
42.
Figura 42: Eventos ocorridos em cada nó.
69
4.7. Uso prático do COOJA
Com o próprio Contiki, no qual nós baixamos, vem uma pasta chamada
examples, que se encontra em: home/contiki-2.7/examples. Nessa pasta
existem alguns exemplos de simulação utilizando o COOJA, por exemplo:
usando ipv6 temos o rpl, rpl-udp, broadcast, unicast, entre outros.
Na dissertação de mestrado do Radoi (2011) foi utilizado o COOJA para
avaliar o desempenho de protocolos de roteamento em ligações com perdas
para a construção de redes inteligentes.
Já na dissertação de mestrado do Ali (2012) o COOJA foi utilizado para
a avaliação de desempenho de RPL em Contiki.
Outro exemplo de uso prático do COOJA foi apresentado na dissertação
de mestrado do Bitencourt (2013), onde ele estende o simulador COOJA
provendo uma nova versão que estima a energia consumida e disponível em
cada nó sensor e em toda a rede.
Rodrigues Filho (2013) em sua dissertação de mestrado utilizou o
COOJA junto com outros sofwares para simular uma arquitetura de redes de
sensores do Corpo Humano.
O COOJA foi utilizado para analisar o consumo de energia em redes de
sensores sem fio dotadas de serviços web na dissertação de mestrado de
Sant’anna (2010).
Como podemos observar já existem muitos usos práticos do COOJA,
isto é, serve para muitas aplicações, por exemplo,para observar o
comportamento da rede antes mesmo de implementá-las.
70
5. Conclusões e trabalhos futuros
5.1 Conclusões
A Internet atual precisa evoluir para suportar a IoT de forma mais
adequada já que o ambiente atual da Internet tem muitas adaptações.
A IoT tem como objetivo conectar qualquer objeto do mundo real para o
mundo digital. Sua implantação mais ampla ocasionará um impacto muito
grande para a sociedade, ambiente e economia, visto que poderemos ter
diversas aplicações da IoT nessas áreas.
Entretanto, diversas aplicações da IoT são compostas por milhares de
nodos, muitas vezes distribuídos sobre uma grande área geográfica. Por isso,
torna-se necessário o uso de um simulador de larga escala para testar novas
aplicações e protocolos.
Nesse trabalho foi apresentada a evolução da Internet e seus
problemas, o que é a IoT e como ela funciona. Também foi mostrado como
funciona o simulador COOJA que pode ser utilizado para simular a Internet das
coisas.
Como foi visto, COOJA possui uma variedade de plugins, que são
importantes para podermos observar os eventos que ocorrem durante a
simulação. A utilização da classe Collect view por parte dos nós implementados
no sistema operacional Contiki, possibilita a utilização de uma interface no
COOJA, no qual possamos observar alguns resultados como: pacotes
recebido, pacotes perdidos, histórico de energia consumida, entre outros.
Como podemos concluir COOJA é uma ferramente importante, pois
pode simular o protocolo IPv6 que é interessante para IoT, para poder conectar
muitos nós diferentes.
5.2 Trabalhos futuros
Os trabalhos futuros que poderiam ser desenvolvidos a partir do estudo
feito são os seguintes:
71
Como neste trabalho não foi elaborada uma simulação prática da IoT, seria
possível, por exemplo, simular no COOJA uma casa inteligente, toda
automatizada e conectada.
Outra abordagem interessante para se simular seria a questão de
segurança de objetos pessoais que estivessem conectados à rede, isto é, a
questão da privacidade.
72
Referências bibliográficas
ALI, Hazrat. A Performance Evaluation of RPL in Contiki: A Cooja Simulation based study. 2012. 91 f. Dissertação (Mestrado) - Curso de School Of Computing, Blekinge Institute Of Technology, Karlskrona, 2012 Andrew S. Tanenbaum, David Wetherall. Redes de computadores. 5. Ed. São Paulo:Pearson, 2011. 552 p. Baccelli, E., Hahm, O., Günes, M., Wählisch, M., & Schmidt, T. (2013, April). RIOT OS: Towards an OS for the Internet of Things. In The 32nd IEEE International Conference on Computer Communications (INFOCOM 2013). BITENCOURT, Hugo VinÍcius. IMPLEMENTAÇÃO DE UM ESTIMADOR DE CONSUMO E ENERGIA DISPONÍVEL PARA SIMULADORES DE RSSF. 2013. 132 f. Dissertação (Mestrado) - Curso de Engenharia Elétrica, Instituto de Ciências Exatas, Universidade Federal de Minas Gerais, Belo Horizonte, 2013.
Castellani, A.P.; Bui, N.; Casari, P.; Rossi, M.; Shelby, Z.; Zorzi, M., "Architecture and protocols for the Internet of Things: A case study," Pervasive Computing and Communications Workshops (PERCOM Workshops), 2010 8th IEEE International Conference on , vol., no., pp.678,683, March 29 2010-April 2 2010. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5470520&isnumber=5470493>. Acessado em: Julho 2013.
Charith Perera; Arkady Zaslavsky; Peter Christen; Dimitrios Georgakopoulos, The Internet of Things: A Survey, Volume 54, Issue 15, 28 October 2010, Pages 2787–2805. Disponível em:< http://www.sciencedirect.com/science/article/pii/S1389128610001568>. Acessado em: Outubro de 2013.
Coetzee, L.; Eksteen, J., "The Internet of Things - promise for the future? An introduction," IST-Africa Conference Proceedings, 2011, pp.1,9, 11-13 May 2011. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6107386&isnumber=6107324>. Acessado em: Julho 2013.
Contiki. Disponível em: http://www.contiki-os.org/index.html. Acessado em: Outubro de 2013. Cormac Duffy; Utz Roedig; John Herbertand Cormac J. Sreenan, A Performance Analysis of MANTIS and TinyOS, Disponível em:
73
http://www.ucc.ie/en/misl/publications/pub_date/pubs_2006/Technical_report_cs-2006-27-11.pdf. Acessado em: Outubro de 2013. CREW-PROJECT. Sensornode: TMote Sky. Disponível em: <www.crew-project.eu/portal/wilab/sensornode-tmote-sky>. Acesso em: 29 out. 2014. Debasis Bandyopadhyay, Jaydip Sem, Internet of Things - Applications and Challenges in Technology and Standardization, May 2011, Volume 58, Issue 1, pp 49-69. Disponível em:< http://link.springer.com/article/10.1007/s11277-011-0288-5>. Acessado em: Novembro de 2013. Eduardo Barasal Morales, 6LoWPAN Internet das coisas, Disponível em: <http://jsccs.no-ip.org/download.ashx?dec=1&url=uh4QwdELmSBMx9sKsDiLxSZOthbOtr0PmTxMmq0LvD4BvD3LwgNRtSBKwOZAvTxKvgZ7tcRJvSVFxgZOmS4LxSVIvSfAmDbEwdZFtdRgur0Iln3J0CNLxTb7v8VMtgs=B6X!>. Acessado em: Novembro de 2013. Emmanuel Baccelli; Oliver Hahm; Mesut G¨unes; Matthias W¨ahlisch; Thomas C. Schmidt, Operating Systems for the IoT – Goals, Challenges, and Solutions, Disponível em: http://www.agence-nationale-recherche.fr/Colloques/WISG2013/presentations/AAP11_SAFEST.pdf. Acessado em: Novembro de 2013.
Istepanian, R. S H, "The potential of Internet of Things (IoT) for assisted living applications," Assisted Living 2011, IET Seminar on , pp.1,40, 6-6 April 2011. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6183152&isnumber=6183132>. Acessado em: Julho 2013.
Jayavardhana Gubbi; Rajkumar Buyy; Slaven Marusi; Marimuthu Palaniswami, Internet of Things (IoT): A vision, architectural elements, and future directions, Volume 29, Issue 7, September 2013, Pages 1645–1660, Disponível em: <http://www.sciencedirect.com/science/article/pii/S0167739X13000241>. Acessado em: Setembro de 2013.
Jim F. Kurose, Keith W. Ross. Redes de computadores e a Internet: uma abordagem top-down. 6.ed. São Paulo: Pearson, 2013. 578 p. Kaivan Karimi; Gary Atkinson, What the Internet of Things (IoT) Needs to Become a Reality, Disponível em: <http://www.freescale.com/files/32bit/doc/white_paper/INTOTHNGSWP.pdf>. Acessado em: Novembro de 2013.
74
Khan, R.; Khan, S.U.; Zaheer, R.; Khan, S., "Future Internet: The Internet of Things Architecture, Possible Applications and Key Challenges," Frontiers of Information Technology (FIT), 2012 10th International Conference on , vol., no., pp.257,260, 17-19 Dec. 2012. Disponível em: <http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6424332&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6424332>. Acessado em: outubro de 2013. Lucas Francisco Wanner; Antônio Augusto Fröhlich, Suporte de Sistema Operacional para Redes de Sensores. Disponível em: <http://www.lisha.ufsc.br/pub/Wanner_WSO_2008.pdf>. Acessado em: Outubro de 2013. Luigi Atzori; Antonio Iera; Giacomo Morabito, The Internet of Things: A survey, Volume 54, Issue 15, 28 October 2010, Pages 2787–2805, Disponível em: <http://www.sciencedirect.com/science/article/pii/S1389128610001568>. Acessado em: Outubro de 2013. Lu Tan; Neng Wang, "Future internet: The Internet of Things," Advanced Computer Theory and Engineering (ICACTE), 2010 3rd International Conference on , vol.5, no., pp.V5-376,V5-380, 20-22 Aug. 2010
Marcelo D. D. Moreira; Natalia C. Fernandes; Luís Henrique M. K. Costa; Otto Carlos M. B. Duarte. Internet do Futuro: Um Novo Horizonte. Minicurso do SBRC 2009, 2009. Disponível em: <http://www.gta.ufrj.br/ensino/cpe728/MFCD09.pdf>. Acessado em: Julho de 2013.
Marcus Vinícius de Sousa Lemos; Líliam Barroso Leal, Relatório sobre o Sistema Operacional TinyOS e a Linguagem NesC, Disponível em: http://www.marvinlemos.net/wp-content/uploads/2010/10/relatorio_tecnico_tinyos.pdf. Acessado em: Outubro de 2013. Martins Straus. A Internet e a Rede das coisas: desafios e oportunidades. 2013. Trabalho final de disciplina de graduação. Disponível em: <http://grenoble.ime.usp.br/~gold/cursos/2013/movel/mono1st/2305-Straus.pdf>. Acesso em: 29 out. 2014. Osterlind, F.; Dunkels, A.; Eriksson, J.; Finne, N.; Voigt, T., "Cross-Level Sensor Network Simulation with COOJA," Local Computer Networks, Proceedings 2006 31st IEEE Conference on , vol., no., pp.641,648, 14-16 Nov. 2006, Disponível em: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4116633&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4116633. Acessado em: Outubro de 2013.
75
Österlind, Fredrik (2006) A Sensor Network Simulator for the Contiki OS. [SICS Report]. Patrick Guillemin and P. Friess, “Internet of things strategic research roadmap,” The Cluster of European Research Projects, Tech. Rep., September 2009, http://www.internet-of-things-research.eu/pdf/IoT luster Strategic Research Agenda 2009.pdf. Acessado em: Outubro de 2013. RADOI, Ion Emilian. Performance Evaluation of Routing Protocols in Lossy Links for Smart Building Networks. 2011. 83 f. Dissertação (Mestrado) - Curso de Computer Science, Departamento de School Of Informatics, University Of Edinburgh, Edinburgh, 2011. Riot. Disponível em: http://www.riot-os.org/. Acessado em: Outubro de 2013. RODRIGUES FILHO, Roberto Vito. Um Simulador para Arquitetura de Redes de Sensores do Corpo Humano Baseado na Plataforma SHIMMER.2013. 101 f. Dissertação (Mestrado) - Curso de Instituto de Informática, Universidade Federal de Goiás, Goiânia, 2013. SANT’ANNA, Felipe Azevedo. Análise do consumo de energia em redes de sensores sem fio dotadas de serviçaos web. 2010. 102 f. Dissertação (Mestrado) - Curso de Engenharia da Informação, Departamento de Centro de Matemática, Computação e Cognição, Universidade Federal do Abc, Santo André, 2010. SEHGAL, Anuj. Using the Contiki Cooja Simulator. 2013. Disponível em: <http://cnds.eecs.jacobs-university.de/courses/iotlab-2013/cooja.pdf>. Acesso em: 13 ago. 2013. SENSTOOLS. Contiki Application Examples. Disponível em: <http://senstools.gforge.inria.fr/doku.php?id=contiki:examples>. Acesso em: 29 out. 2014. SCHRICKTE, Luiz Fernando. PROJETO, IMPLEMENTAçãoO E AVALIAção DE DESEMPENHO DE NÓS E GATEWAY 6LOWPAN. 2013. 110 f. Dissertação (Mestrado) - Curso de Engenharia de Automação e Sistemas, Departamento de Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis, 2013.
Tiago França, Paulo Pires, Luci Pirmez, Flavia Delicato, Claudio Farias. Web das Coisas: Conectando Dispositivos Físicos ao Mundo Digital. Minicurso do SBRC 2011, 2011. Disponível em: <http://sbrc2011.facom.ufms.br/files/anais/files/mc/mc3.pdf>. Acessado em: Julho 2013.
76
VITALI, Maycon Maia. Segurança em Redes de Sensores Sem Fio: um ambiente de experimentação simulado para 6LoWPAN e um módulo de autenticação baseado em chaves pré-compartilhadas. 2012. 96 f. Dissertação (Mestrado) - Curso de Informática, Departamento de Informática, Universidade Federal do EspÍrito Santo, Vitória, 2012.
VOIGT, Thiemo. Contiki COOJA Hands-on Crash Course: Session Notes. 2009. Disponível em: <https://www.sics.se/~thiemo/seniot09cccc-notes.pdf>. Acesso em: 13 ago. 2014.
77
Apêndice
APÊNDICE A – Artigo
Internet das Coisas: estudo do simulador COOJA
Rodrigo Boratti, Carla Merkle Westphall
Departamento de Informática e Estatística (INE)
Universidade Federal de Santa Catarina (UFSC)
Caixa Postal 476 - 88.040-970 - Florianópolis - SC - Brasil
{[email protected], [email protected]}
Abstract. The Internet started around the 70s and it was a network that
connected universities. Over time the Internet has evolved through
adaptations. With these adjustments some limitations and problems in the
aspects of security, mobility, quality of service and scalability begun to
emerge. In the near future it will be possible to connect everyday objects in the
network. The connection of these objects with the Internet is called Internet of
Things (English, Internet of Things - IoT). If this happens, a "New Internet"
will be needed to meet these requirements. This paper aims to describe the
evolution of the Internet, the basics of IoT and the functioning of COOJA
which is a simulator for the Contiki operating system that can simulate the
IoT.
Resumo. A Internet começou por volta da década de 70 e ela era uma rede
que conectava universidades. Com o passar do tempo a Internet foi evoluindo
através de adaptações. Com essas adaptações começaram a surgir algumas
limitações e problemas nos aspectos de segurança, mobilidade, qualidade de
serviço e escalabilidade. Em um futuro breve será possível conectar objetos
do dia a dia na rede. A conexão desses objetos com a Internet é denominada
Internet das Coisas (do inglês, Internet of Things - IoT). Se isso acontecer,
será necessária uma "Nova Internet" para atender a esses requisitos. Este
trabalho tem o objetivo de descrever a evolução da Internet, os conceitos
básicos sobre IoT e o funcionamento do COOJA que é um simulador para o
sistema operacional Contiki e que pode simular a IoT.
1. Introdução
A Internet das Coisas (IoT – Internet of Things) é um novo paradigma de integração do
mundo físico com o digital que vem aumentando sua importância e abrindo espaço nas
comunicações. A ideia básica desse conceito é a presença de várias “coisas” ou objetos,
tais como identificadores de rádio frequência (RFID – Radio-Frequency Identification),
sensores, telefones móveis e outros dispositivos que, através de esquemas de
endereçamento como endereços IP da Internet, são capazes de interagir uns com os
outros e cooperar na execução de tarefas (Atzori et al. 2010) (França et al. 2011).
78
Com o crescimento do número de usuários que usam a Internet e o surgimento
da Internet das coisas (IoT), a Internet atual não seria capaz de absorver a quantidade de
dispositivos conectados à rede prevista pela IoT. Pensando nisso, faz-se necessário o
desenvolvimento de uma "Nova Internet" capaz de conectar qualquer coisa à rede.
As tecnologias envolvidas para o desenvolvimento da IoT são as interfaces e
protocolos de comunicação eletrônica, microcontroladores, comunicação sem fio,
tecnologia de identificação RFID, tecnologias de captação de energia, sensores,
atuadores, tecnologia de localização e software (Istepanian et al. 2011).
A IoT pode ser usada na medicina para monitorar doentes e agilizar prestação de
serviços de saúde em geral, na política, na sociedade, na tecnologia de computação na
nuvem, na robótica e nanotecnologia. São previstas também aplicações em áreas
diversas como aeroespacial, aviação, telecomunicações, edifícios inteligentes,
tecnologia médica, farmacêutica, varejo, logística, petróleo e gás.
Uma tecnologia importante na construção da IoT é o padrão IEEE 802.15.4, um
padrão para redes sem fio, de baixo consumo e baixa capacidade. A IoT utilizará o
protocolo 6LoWPAN e o IPv6 fornecerá endereçamento e conectividade para os
dispositivos embarcados (Castellani et al. 2010).
Esse artigo fala sobre os conceitos básicos da IoT, sobre os sistemas
operacionais para IoT e também um estudo sobre o simulador COOJA, que é um
simulador para o sistema operacional Contiki e que pode ser utilizado para simular a
IoT.
O texto do artigo está organizado em 6 seções. A seção 2 apresenta os principais
trabalhos relacionados. A seção 3 descreve os conceitos básicos da Internet das Coisas.
A seção 4 apresenta os sistemas operacionais para a IoT. A seção 5 apresenta um estudo
do simulador COOJA. A última seção apresenta as conclusões.
2. Trabalhos Relacionados
Na dissertação de mestrado do Radoi (2011) foi utilizado o COOJA para avaliar o
desempenho de protocolos de roteamento em ligações com perdas para a construção de
redes inteligentes.
Já na dissertação de mestrado do Ali (2012) o COOJA foi utilizado para a
avaliação de desempenho de RPL em Contiki.
Outro exemplo de uso prático do COOJA foi apresentado na dissertação de
mestrado do Bitencourt (2013), onde ele estende o simulador COOJA provendo uma
nova versão que estima a energia consumida e disponível em cada nó sensor e em toda a
rede.
Rodrigues Filho (2013) em sua dissertação de mestrado utilizou o COOJA junto
com outros sofwares para simular uma arquitetura de redes de sensores do Corpo
Humano.
O COOJA foi utilizado para analisar o consumo de energia em redes de sensores
sem fio dotadas de serviços web na dissertação de mestrado do Sant’anna (2010).
79
Como podemos observar já existem muitos usos práticos do COOJA, isto é,
serve para muitas aplicações, onde podemos notar o comportamento da rede antes
mesmo de implementá-las.
3. Internet das Coisas
3.1. Conceitos básicos de Internet das Coisas
O termo Internet das Coisas (Internet of Things - IoT) foi utilizado pela primeira vez
por Kevin Ashton, em 1998. A IoT tem diversas definições na literatura, isso ocorre
devido ao fato da Internet das coisas ser sintaticamente composta por dois termos:
Internet e coisas. O primeiro termo tende para uma visão voltada à rede de IoT e o
segundo termo voltado para objetos (Bandyopadhyay et al. 2011).
A definição de IoT segundo P. Guillemin and P. Friess é: A Internet das coisas
permite que as pessoas e coisas sejam conectados a qualquer hora, em qualquer lugar,
com qualquer coisa e qualquer um, de preferência usando qualquer caminho/rede e
qualquer serviço (Perera et al. 2013).
A IoT pode ser vista por três principais paradigmas: uma visão focada no termo
orientado a “Internet” (middleware) e observaram a IoT do ponto de vista de rede; outra
visão foi focada no termo orientado a “Coisas” (sensores), onde a pesquisa busca a
integração de objetos em uma estrutura comum; e uma terceira visão focou em questões
orientadas a semânticas (conhecimento), observando a IoT do ponto de vista de
comunicação entre dispositivos distintos. Visto isso, a IoT pode ser vista como a
intersecção desses três paradigmas (figura 1) (Atzori et al. 2010).
Figure 1. Três principais paradigmas da Internet das Coisas (Atzori et al, 2010)
As coisas poderiam ser marcadas por RFID (Radio Frequency Identification) ou
QR (Quick Response) e através de scanners, essas coisas seriam identificadas e as
informações de localização relevantes poderiam ser comunicadas. Da mesma forma, as
coisas em rede de sensores tornam-se menores, enquanto as redes de sensores agem
80
sobre o meio ambiente local, comunicar status e eventos para um serviço de nível
superior. Middleware e frameworks permitindo a aplicação e desenvolvimento de
serviços que utilizam dados recebidos das coisas, na maioria das vezes vivem na nuvem
(COETZEE et al. 2011).
As principais características da IoT são: Inteligência, arquitetura, sistema
complexo, considerações de tamanho, considerações de tempo, considerações de espaço
e tudo como serviço. Essas características precisam ser consideradas no
desenvolvimento de soluções para IoT em todas as fases de concepção,
desenvolvimento, implementação e avaliação (Perera et al. 2013).
As tecnologias que contribuíram para o desenvolvimento da IoT são: Interfaces
de máquina-a-máquina; protocolos de comunicação eletrônica; microcontroladores;
comunicação sem fio; tecnologia RFID (Radio Frequency Identification); tecnologias de
captação de energia; sensores; atuadores; tecnologia de localização e software
(Istepanian et al. 2011).
O RFID é um microchip que identifica qualquer coisa e faz a comunicação de
dados via wireless. O RFID é uma etiqueta equivalente a um código de barras
eletrônico. As etiquetas RFID podem ser de dois tipos: passivas e ativas. (Gubbi et al.
2013).
Outro elemento importante são as RSSF (Rede de Sensores Sem Fio) que
servem para a comunicação sem fio e esses sensores são inteligentes e possibilitam a
coleta, processamento e análise de dados remotamente (Gubbi et al. 2013).
Para o sucesso da IoT é necessário que os objetos sejam identificados
unicamente. Isso possibilitaria que bilhões de objetos fossem conectados à rede e eles
poderiam ser acessados remotamente através da Internet. Mas existem pontos críticos
para que esses objetos sejam identificados unicamente, como por exemplo: unicidade,
confiabilidade, persistência e escalabilidade. O IPv4 atual não daria suporte para
identificar unicamente tantos objetos, já o IPv6 conseguiria aliviar um pouco a
identificação dos dispositivos. Outro ponto a ser tratado pela IoT seria a questão do
tráfego, já que teríamos muitos dispositivos conectados à rede e com isso muita
informação transitaria pela rede (Gubbi et al. 2013).
Com relação aos dados, seria outro ponto crítico a ser tratado pela IoT, visto
que, teria que armazenar, saber de quem são e validar os dados. Outra questão seria a
segurança desses dados (Gubbi et al. 2013).
3.2. Protocolos e camadas da IoT
Uma tecnologia importante na construção da IoT é o padrão IEEE 802.15.4, um padrão
para redes sem fio, de baixo consumo e baixa capacidade. A IoT utilizará o protocolo
6LoWPAN e o IPv6 fornecerá endereçamento e conectividade para os dispositivos
embarcados (Istepanian et al. 2011).
O protocolo 6LoWPAN significa “Internet Protocol version 6 over Low power
Wireless Personal Area Networks.” As caraterísticas que os dispositivos precisam ter
para funcionar nesse protocolo são: baixa capacidade de processamento; baixa
capacidade de memória; baixo gasto de energia; baixo alcance do sinal e baixa taxa de
transmissão (Eduardo et al. 2013).
81
A IoT está dividida em 5 camadas que são: camada de percepção; camada de
rede; camada de middleware; camada de aplicação; e a camada de negócios (figura2)
(Khan et al. 2012).
Figure 2. Camadas da IoT (Rafiullah e Sarmad e Rifaqat e Shahid, 2010)
Camada de percepção - É na camada de percepção que se encontram os objetos
físicos e os dispositivos de sensores.
Camada de rede – Essa camada transfere as informações, obtidas pelos sensores,
para o sistema de processamento.
Camada de Middleware – Essa camada fica responsável por gerenciar os
serviços e tem uma ligação com o banco de dados. Essa camada recebe as informações
da camada de rede e as armazena no banco de dados (Khan et al. 2012).
Camada de aplicação – Essa camada fornece gerenciamento global do aplicativo
com base nas informações processadas por objetos na camada Middleware.
Camada de negócios – Essa camada é responsável pelo gerenciamento do
sistema global, incluindo as aplicações IoT e serviços. É nessa camada que são
construídos os modelos de negócios, os gráficos, os fluxogramas, entre outros, isso tudo
com base nos dados recebidos (Khan et al. 2012).
3.3. Aplicações da IoT
Com o surgimento da IoT pode ocasionar um impacto muito grande para sociedade,
ambiente, economia. A IoT pode ser introduzida em uma variedade de domínios, como
por exemplo: transporte, rastreamento de ativos, ambientes inteligentes, energia, defesa
e agricultura. Nesses vários domínios podemos ter diversas aplicações da IoT. Essas
aplicações podem ser classificadas com base no tipo de disponibilidade da rede, a
cobertura, a escala, a heterogeneidade.
Alguns exemplos de aplicações: A IoT pode ser aplicada para monitorar a saúde
de uma pessoa; um médico em sua casa poderia monitorar um paciente sem precisar ir
até a casa desse paciente; pessoas poderiam controlar os eletrodomésticos, como por
82
exemplo: ar condicionado, máquinas de lavar, geladeiras; na empresa na parte de
segurança, automação, controle de temperatura; na parte de vigilância também pode ser
aplicada, com o intuito de identificar atividades suspeitas e monitorar acesso não
autorizado; para monitorar o tráfego nas estradas.
3.4. Desafios da IoT
A IoT propõe que qualquer objeto do mundo real esteja conectado à rede e para que isso
ocorra a IoT tem que superar uma série de desafios, como por exemplo: privacidade;
normalização e interoperabilidade; e quantidade de dados grandes.
Com relação à privacidade, a IoT tem o desafio de saber quem pode ver o que e
com que credenciais. Com relação a normalização e interoperabilidade, a IoT tem que
garantir que a IoT vai continuar a funcionar mesmo com novas aplicações, isto é, a rede
vai continuar a funcionar mesmo que novas aplicações se conectem à rede.
A IoT tem como desafio a questão do fluxo dos dados, visto que vão ter muitos
objetos e pessoas conectados à rede e com isso vai existir uma quantidade enorme de
dados transitando pela rede.
4. Sistema operacionais
Pela necessidade de identificar “as coisas” combinando sistemas computacionais com
sistemas de comunicação, a IoT precisa de suporte para redes de sensores sem fio e de
sistemas operacionais especializados.
Vários são os requisitos necessários em um sistema operacional para IoT
(Baccelli et al. 2012): ter requisitos mínimos de memória e poder de processamento;
habilidade para executar em um hardware restrito os componentes como MMU
(Memory Management Unit) ou FPU (Floating-Point Unit); suportar uma variedade de
plataformas de hardware; ter um alto grau de eficiência de energia; ter uma interface de
programação padrão; suportar linguagens de programação de alto nível; ter uma pilha
de rede modular e adaptativa; confiabilidade.
4.1. RIOT
RIOT começou a ser desenvolvido em 2008 e no início era um sistema operacional para
redes de sensores sem fio, chamado FeuerWare. Em 2010 foram incluídos novos
protocolos IETF (Internet Engineering Task Force), a partir disso foi possível dar
suporte aos protocolos 6LoWPAN, RPL, e TCP. Em 2013, esse sistema operacional
passa a se chamar RIOT e se torna público (Riot et al. 2013).
Características importantes da RIOT: ambiente de desenvolvimento amigável,
recurso amigável, facilidade em desenvolver aplicações para IoT. O Sistema
Operacional permite: programação em C ou C++; ferramentas de desenvolvimento
padrão com gcc, gdb; minimização de código dependente de hardware; flexibilidade e
robustez do código; ativando a eficiência energética máxima, multi-threading;
6LoWPAN , IPv6, RPL , TCP e UDP; alocação de memória estática e dinâmica;
sistema de arquivos FAT; Wiselib apoio (C + + algoritmo biblioteca, incluindo
roteamento, clustering , localização, segurança e mais algoritmos) (Riot et al. 2013).
83
4.2. Contiki
Contiki é um sistema operacional de código aberto que conecta microcontroladores de
baixa potência à Internet. Contiki apoia plenamente o padrão IPv6 e IPv4 e os últimos
padrões wireless de baixo consumo: 6LoWPAN , RPL, COAP. Contiki é executado em
uma grande quantidade de dispositivos sem fio de baixa potência (Contiki, 2013).
Com Contiki, o desenvolvimento de aplicações é rápido e fácil. As aplicações
podem ser desenvolvidas em C e através do Contiki é possível usar o Cooja, um
simulador de redes sem fio (Contiki, 2013).
Características importantes do Contiki: o Contiki foi projetado para trabalhar
ocupando pouco espaço de memória, com isso ele é altamente eficiente de memória;
rede IP completa, com protocolos como: UDP, TCP, HTTP, 6LoWPAN, RPL, COAP e
IPv6; opera em sistemas de baixo consumo de energia.
4.3. TinyOS
TinyOS é um sistema operacional projetado para redes de sensores sem fio que funciona
ocupando pouco espaço de memória. Com esse sistema operacional é possível criar
aplicações da Internet das coisas e através do simulador TOSSIM é possível simular a
Internet das coisas (Lemos et al. 2010).
Características importantes do TinyOS: uma arquitetura baseada em
componentes; um modelo de concorrência simples baseado em tarefas e eventos;
operações divididas em fases
4.4. Mantis OS
Mantis é um sistema operacional que funciona com múltiplas threads que são capazes
de realizar múltiplas tarefas em energia limitada. O sistema operacional possibilita que
as threads tenham o direito à preferência sobre outras, ou seja, uma thread pode entrar
em execução sem que outra tenha terminado a tarefa. Como resultado, o sistema
operacional pode responder mais rapidamente a acontecimentos críticos (Duffy et al.
2006).
O escalonador de threads do Mantis OS utiliza o sistema de round-robin com
prioridade. Ao se iniciar o sistema operacional a thread idle é criada e caso todas as
threads estejam bloqueadas, a thread idle é executada (Wanner et al. 2008).
5. COOJA
Com o simulador COOJA é possível simular diferentes tipos de nodo da rede, tanto em
nível de hardware quanto de software. Diversas partes do simulador podem ser
substituídas ou estendidas, assim como o meio de comunicação de rádio, o hardware
simulado e plug-ins de entrada e saída de dados (Österlind, 2006).
COOJA é um simulador flexível baseado na linguagem Java, projetado para
simular a IoT no sistema operacional Contiki.
Um nó sensor simulado no Cooja possui três propriedades básicas: memória;
tipo do nó sensor; hardware periféricos (OSTERLIND et al., 2000).
84
O tipo de nó sensor pode ser similar a outros nós da rede e determina
propriedades comuns para os nós deste tipo. Por exemplo, nós do mesmo tipo executam
o mesmo código de programa para hardware periféricos simulados. Os nós de mesmo
tipo são inicializados com a mesma configuração de memória, mas com o passar do
tempo da execução da simulação, as memórias desses nós podem variar de acordo com
a execução das funções da rede. Nós de mesmo tipo, eventualmente vão possuir dados
diferentes, baseados nas diferentes entradas de dados que recebam (OSTERLIND et al.,
2000).
No COOJA é possível emular um nó sensor da plataforma Tmote Sky, que é um
disposistivo de baixo consumo de energia baseado nas especificações IEEE 802.15.4.
Este dispositivo possui os seguintes atributos:
• microcontrolador de 8MHz Texas Instruments MSP430 (10Kb RAM (random
Access Memory), 48Kb de memória interna Flash, 1MB memória externa Flash).
• sensores de umidade, temperatura e luz.
• transmissores sem fio Chipcon IEEE 802.15.4 com velocidade de
processamento de 2.4GHz e velocidade de transmissão de 250Kbps (SANT’ANNA,
2010).
5.1. Inicialização do COOJA
Depois de feito toda a instalação do ambiente de trabalho, iniciaremos a utilização do
COOJA. A inicialização dele pode ser feito de duas formas: a primeira, abre-se um
terminal e vá até o diretório do cooja, com o seguinte comando: cd contiki/tools/cooja e
para iniciar utiliza-se o seguinte comando: ant run; a segunda forma seria abrir o
executável Cooja que aparece na área de trabalho da máquina virtual (Contiki, 2013).
5.2. Criando uma nova simulação no COOJA
Para se criar uma nova simulação, depois do programa aberto, vá em file e aperte, irão
aparecer algumas opções, aperte em new simulation.
A seguir irá abrir uma janela. Nessa janela, temos a opções: de dar o nome para
à simulação, escolha o nome mais adequado a sua simulação; em radio medium, você
vai selecionar o meio de rádio que melhor se aplica para a sua simulação, para o caso de
IoT, selecionaremos Unit Disk Graph Medium (UDGM), que é uma unidade simples
que se pode mudar o alcance de transmissão do rádio, pequenas distâncias; em mote
sturtup delay(ms), serve para iniciar aleatoriamente cada mote, para eles não iniciarem
todos ao mesmo tempo; (SEHGAL, 2013) Random seed é uma semente para o gerador
de números aleatórios; na opção new random seedon reload, você pode selecionar o box
ao lado para obter uma semente aleatória. Quando você clicar no botão create, irá
aparecer o ambiente de simulação.
5.3. Criando um tipo de nó
Qualquer nó simulado em COOJA pertence a um tipo de nó. O tipo de nó determina,
entre outros, que tipo de aplicativo Contiki irá simular. Para criar um nó, clica-se no
menu motes, creating new mote type, sky mote (SEHGAL, 2013). Sky mote é um
sensor de baixo consumo de energia sem fio.
85
Depois que clicar em Sky mote irá aparecer uma nova janela. Nessa janela você
fará uma descrição de qual tipo de nó vai ser e também irá escolher qual programa
contiki será compilado. O programa contiki a ser compilado, é um arquivo .c
(SEHGAL, 2013). Depois de selecionado o arquivo, aperta-se o botão compile, após
compilado, aperta-se o botão create, agora está pronto para adicionar um ou vários nós
desse tipo que foi criado (SEHGAL, 2013).
5.4. Adicionando um tipo de nó
Após a criação de um tipo de nó é possível adicionar um ou mais nós desse tipo,
acessando através de motes, add motes, [sua descrição do tipo de mote].
Depois de apertar em Sky Mote Type #sky1, irá aparecer uma janela, onde você
irá poder definir quantos nós você vai querer adicionar, as posições desses nós, essas
posições podem ser aleatórias, linear, elipse e manual (VOIGT, 2009). Depois de definir
quantos nós e suas posições é só apertar em add motes.
5.5. Inicializando uma simulação
Depois de criada uma nova simulação e adicionado nós para ser simulado, o ambiente
COOJA terá alguns plugins abertos, esses plugins podem ser acessados pelo menu tools.
Para iniciar uma simulação basta apertar o botão Start que se encontra no plugin
Simulation Control (VOIGT, 2009).
5.6. Plugins
Os plugins são utilizados para interagir com uma simulação. Frequentemente fornece ao
usuário alguma interface gráfica para ser possível observar algo interessante na
simulação (OSTERLIND et al., 2000). A seguir seguem alguns plugins:
- Network: Nesse plugin é possível visualizar o layout da rede, ou seja, as
posições dos nós (VOIGT, 2009). No menu view é possível determinar as informações
na qual podem ser vistas no layout da rede. No menu é possível você aproximar ou
afastar a visualização da rede.
- Mote output: Nessa plugin aparecem as informações da saída serial de cada nó,
isto é, a saída do comando printf. No Filder, você pode filtrar qual nó você quer que a
interface mostre a saída. Como por exemplo, você deseja que a interface só mostre a
saída do nó 2, então você deve introduzir nesse campo ID: 2 (SEHGAL, 2013).
- Timeline: Nesse plugin são mostrados os eventos que ocorrem em cada nó
sobre a linha do tempo de simulação. Esses eventos podem ser: Tráfego de rádio; rádio
ligado ou desligado; canal de rádio; LED´s; log de saída e pontos de saída (SEHGAL,
2013). Um exemplo é o evento relacionado com o rádio, onde o branco representa que
o estado do rádio trasceptor está desligado e acinzentado se estiver ligado. Eventos
relacionado com transmissão de rádio, onde o azul indica pacote transmitido, verde
indica pacote recebido e vermelho indica que pode ter ocorrido uma interferência
(VOIGT, 2009).
- Breakpoints: Com esse plugin é possível parar a simulação quando um evento
ocorre ou quando um evento de rádio acontece, isso de forma geral. Também é possível
86
parar a simulação, quando a interface de um nó muda, dá para selecionar uma ou mais
interface, no qual se deseja parar quando ocorra a mudança na(s) interface(s).
- Radio messages: Com este plugin é possível visualizar os pacotes recebidos e
enviados por cada nó, o tempo em que foram produzidos e os mesmos conteúdo do
pacote em hexadecimal e de caracteres ASCII.
- Simulation script editor: Com esse plugin é possível controlar e automatizar a
execução por meio de scripts, escritos em java script. Ele permite iniciar e parar a
simulação, pode definir o tempo limite de simulação, adicionar e remover nós de forma
dinâmica, capturar a saída dos nós sensores e interagir com plugins COOJA.
- Notes: Nesse plugin é possível fazer algumas anotações temporarias sobre a
simulação (SEHGAL, 2013).
- Buffer view: Com esse plugin é possível vizualizar o que está ocorrendo em
cada buffer de cada nó, se está acontecendo uma leitura do buffer ou uma escrita.
- Mote radio duty cycle: Essa interface mostra a porcentagem que cada nó ficou
ligado ou enviou uma menssagem (TX) ou recebeu uma mensagem (RX) naquele exato
momento.
5.7. Salvando, carregando e recarregando uma simulação
Quando salvamos uma simulação, os plugins que estão ativos também serão salvos com
a simulação, mas o estado atual da simulação não será salvo, com isso os nós serão
reiniciados quando essa simulação for carregada de novo. Para salvar sua simulação,
basta ir ao menu file e apertar save simulation as (VOIGT, 2009). Após salvo, a
simulação é salva em um arquivo com extesão .csc. Para carregar uma simulação, basta
ir ao menu file, open simulation e apertar em browse e procurar um arquivo .csc ou
apertar em umas das simulações que foi aberta recentemente. Quando uma simulação é
carregada, todas as aplicações contiki são recompiladas (VOIGT, 2009). Já para
recarregar uma simulação basta apertar o botão reload que se encontra no plugin
simulation control.
5.8. Descrição de arquivos necessários para a compilação de simulações
Para que um nó possa ser simulado no COOJA é necessário que o código Contiki seja
compilado (arquivo .c), e para conseguir compilar esse arquivo .c é preciso ter um
arquivo makefile na mesma pasta. O makefile define as regras de compilação para o
projeto. Existem duas formas de executar esse arquivo, que são:
- Abre-se o terminal e vá até o diretório do projeto, onde se encontram os
arquivos .c e makefile. Estando no diretório do projeto é só digitar make e apertar enter,
nesse caso o arquivo será compilado com o TARGET = native, mas você pode mudar
para o TARGET que você desejar, como por exemplo: ao invés de só digitar make,
digita-se make TARGET = sky.
- A segunda forma seria, abrindo o COOJA, indo ao menu motes, add motes,
creating new mote type, sky mote. Irá abrir uma nova janela, nessa janela em browser
você vai procurar o arquivo .c que você deseja compilar e depois apertar o botão
compilar.
87
Depois que os arquivos .c do projeto forem compilados, na pasta do projeto
serão criados mais alguns arquivos. Depois que o arquivo é compilado ele cria o objeto,
um arquivo de mapeamento de memória do Contiki e um arquivo hello-world.sky, esse
arquivo hello-world.sky pode ser usado pelo COOJA para criar um nó desse tipo. No
COOJA seguindo os passos para a criação de um nó, na janela create mote type você
aperta em browse e seleciona o arquivo .sky, com isso o botão create irá aparecer e
depois é só aperta-lo.
6. Conclusão e trabalhos futuros
A Internet atual precisa evoluir para suportar a IoT de forma mais adequada já que o
ambiente atual da Internet tem muitas adaptações.
A IoT tem como objetivo conectar qualquer objeto do mundo real para o mundo
digital. Sua implantação mais ampla ocasionará um impacto muito grande para a
sociedade, ambiente e economia, visto que poderemos ter diversas aplicações da IoT
nessas áreas.
Entretanto, diversas aplicações da IoT são compostas por milhares de nodos,
muitas vezes distribuídos sobre uma grande área geográfica. Por isso, torna-se
necessário o uso de um simulador de larga escala para testar novas aplicações e
protocolos.
Nesse artigo foi apresentado o que é a IoT e como ela funciona. Também foi
mostrado como funciona o simulador COOJA que pode ser utilizado para simular a
Internet das Coisas.
Como foi visto, COOJA possui uma variedade de plugins, que são importantes
para podermos observar os eventos que ocorrem durante a simulação. A utilização da
classe Collect view por parte dos nós implementados no sistema operacional Contiki,
possibilita a utilização de uma interface no COOJA, no qual podemos observar alguns
resultados como: pacotes recebidos, pacotes perdidos, histórico de energia consumida,
entre outros.
Como podemos concluir COOJA é uma ferramente importante, pois pode
simular o protocolo IPv6 que é interessante para IoT, para poder conectar muitos nós
diferentes.
Alguns trabalhos futuros podem ser sugeridos: (a) Simular no COOJA uma casa
inteligente, toda automatizada e conectada; (b) Simular no COOJA a questão de
segurança de objetos pessoais que estivessem conectados à rede, isto é, a questão da
privacidade.
7. Referências
ALI, Hazrat. A Performance Evaluation of RPL in Contiki: A Cooja Simulation based
study. 2012. 91 f. Dissertação (Mestrado) - Curso de School Of Computing, Blekinge
Institute Of Technology, Karlskrona, 2012.
88
Castellani, A.P.; Bui, N.; Casari, P.; Rossi, M.; Shelby, Z.; Zorzi, M., "Architecture and
protocols for the Internet of Things: A case study," Pervasive Computing and
Communications Workshops (PERCOM Workshops), 2010 8th IEEE International
Conference on , vol., no., pp.678,683, March 29 2010-April 2 2010. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5470520&isnumber=54
70493>. Acessado em: Julho 2013.
Charith Perera; Arkady Zaslavsky; Peter Christen; Dimitrios Georgakopoulos, The
Internet of Things: A Survey, Volume 54, Issue 15, 28 October 2010, Pages 2787–
2805. Disponível em:<
http://www.sciencedirect.com/science/article/pii/S1389128610001568>. Acessado
em: Outubro de 2013.
Coetzee, L.; Eksteen, J., "The Internet of Things - promise for the future? An
introduction," IST-Africa Conference Proceedings, 2011, pp.1,9, 11-13 May 2011.
Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6107386&isnumber=61
07324>. Acessado em: Julho 2013.
Contiki. Disponível em: http://www.contiki-os.org/index.html. Acessado em: Outubro
de 2013.
Cormac Duffy; Utz Roedig; John Herbertand Cormac J. Sreenan, A Performance
Analysis of MANTIS and TinyOS, Disponível em:
http://www.ucc.ie/en/misl/publications/pub_date/pubs_2006/Technical_report_cs-
2006-27-11.pdf. Acessado em: Outubro de 2013.
Debasis Bandyopadhyay, Jaydip Sem, Internet of Things - Applications and Challenges
in Technology and Standardization, May 2011, Volume 58, Issue 1, pp 49-69.
Disponível em:< http://link.springer.com/article/10.1007/s11277-011-0288-5>.
Acessado em: Novembro de 2013.
Eduardo Barasal Morales, 6LoWPAN Internet das coisas, Disponível em:
<http://jsccs.no-
ip.org/download.ashx?dec=1&url=uh4QwdELmSBMx9sKsDiLxSZOthbOtr0PmTx
Mmq0LvD4BvD3LwgNRtSBKwOZAvTxKvgZ7tcRJvSVFxgZOmS4LxSVIvSfAm
DbEwdZFtdRgur0Iln3J0CNLxTb7v8VMtgs=B6X!>. Acessado em: Novembro de
2013.
Istepanian, R. S H, "The potential of Internet of Things (IoT) for assisted living
applications," Assisted Living 2011, IET Seminar on , pp.1,40, 6-6 April 2011.
Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6183152&isnumber=61
83132>. Acessado em: Julho 2013.
Jayavardhana Gubbi; Rajkumar Buyy; Slaven Marusi; Marimuthu Palaniswami, Internet
of Things (IoT): A vision, architectural elements, and future directions, Volume 29,
Issue 7, September 2013, Pages 1645–1660, Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0167739X13000241>. Acessado
em: Setembro de 2013.
89
Khan, R.; Khan, S.U.; Zaheer, R.; Khan, S., "Future Internet: The Internet of Things
Architecture, Possible Applications and Key Challenges," Frontiers of Information
Technology (FIT), 2012 10th International Conference on , vol., no., pp.257,260, 17-
19 Dec. 2012. Disponível em:
<http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6424332&url=http%3A%2
F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6424332>.
Acessado em: outubro de 2013.
Lucas Francisco Wanner; Antônio Augusto Fröhlich, Suporte de Sistema Operacional
para Redes de Sensores. Disponível em:
<http://www.lisha.ufsc.br/pub/Wanner_WSO_2008.pdf>. Acessado em: Outubro de
2013.
Luigi Atzori; Antonio Iera; Giacomo Morabito, The Internet of Things: A survey,
Volume 54, Issue 15, 28 October 2010, Pages 2787–2805, Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1389128610001568>. Acessado
em: Outubro de 2013.
Marcus Vinícius de Sousa Lemos; Líliam Barroso Leal, Relatório sobre o Sistema
Operacional TinyOS e a Linguagem NesC, Disponível em:
http://www.marvinlemos.net/wp-
content/uploads/2010/10/relatorio_tecnico_tinyos.pdf. Acessado em: Outubro de
2013.
Österlind, Fredrik (2006) A Sensor Network Simulator for the Contiki OS. [SICS
Report].
RADOI, Ion Emilian. Performance Evaluation of Routing Protocols in Lossy Links for
Smart Building Networks. 2011. 83 f. Dissertação (Mestrado) - Curso de Computer
Science, Departamento de School Of Informatics, University Of Edinburgh,
Edinburgh, 2011.
Riot. Disponível em: http://www.riot-os.org/. Acessado em: Outubro de 2013.
RODRIGUES FILHO, Roberto Vito. Um Simulador para Arquitetura de Redes de
Sensores do Corpo Humano Baseado na Plataforma SHIMMER.2013. 101 f.
Dissertação (Mestrado) - Curso de Instituto de Informática, Universidade Federal de
Goiás, Goiânia, 2013.
SANT’ANNA, Felipe Azevedo. Análise do consumo de energia em redes de sensores
sem fio dotadas de serviçaos web. 2010. 102 f. Dissertação (Mestrado) - Curso de
Engenharia da Informação, Departamento de Centro de Matemática, Computação e
Cognição, Universidade Federal do Abc, Santo André, 2010.
SEHGAL, Anuj. Using the Contiki Cooja Simulator. 2013. Disponível em:
<http://cnds.eecs.jacobs-university.de/courses/iotlab-2013/cooja.pdf>. Acesso em: 13
ago. 2013.
Tiago França, Paulo Pires, Luci Pirmez, Flavia Delicato, Claudio Farias. Web das
Coisas: Conectando Dispositivos Físicos ao Mundo Digital. Minicurso do SBRC
2011, 2011. Disponível em:
<http://sbrc2011.facom.ufms.br/files/anais/files/mc/mc3.pdf>. Acessado em: Julho
2013.
90
VOIGT, Thiemo. Contiki COOJA Hands-on Crash Course: Session Notes. 2009.
Disponível em: <https://www.sics.se/~thiemo/seniot09cccc-notes.pdf>. Acesso em:
13 ago. 2014.