Simular uma rede de sensores (Mesh) com protocolo Lora no software CupCarbon (Envio de Temperaturas) (Parte 2/2)
Parte 2/2
AIoT (Internet das Coisas) surgiu como a nova geração da Internet que permitiu a telemóveis e a dispositivos comunicarem entre si via web.É agora possível controlar ou monitorizar remotamente qualquer objecto como um robô, medidor de Glicemia, temperatura ambiente, Co2 de um local remoto, casas, carros, etc.
Esta segunda parte do artigo é dedicada à programação dos nodes e sink da rede mesh já pré configurada na primeira parte (Ver AQUI) e isso com um algoritmo simples (flooding). Um grande problema deste algoritmo é que ele gera um grande número de pacotes duplicados na rede, mas é de simples implementação.
Utilizaremos também o simulador CupCarbon para análise dos resultados obtidos.
“Programar” em SenScript
O CupCarbon permite configurar cada agente do simulador utilizando ficheiros script para programar as suas interacções.
Tais arquivos descrevem como um agente vai comunicar com os seus vizinhos e/ou com o seu ambiente. Contém todas as principais acções a serem executadas por um sensor durante a simulação.
Os scripts permitem variáveis não declaradas e sem tipo, mas podem ser inicializadas (com comando set). Para as variáveis string, não é necessário utilizar as aspas. Uma variável é utilizada pelo seu nome e o seu valor é determinado por $. (pode aprender mais AQUI)
Lista de comandos
Código SINK(Gateway)
Algoritmo :
VAR
node: inteiro (aleatório)
count: inteiro
d: arrayINICIO
ENVIA pedido inicial aleatórioESPERAR por mensagem no máximo 300000 ms
INCREMENTAR contador
LER mensagem
SE mensagem for do TIPO B
ENTÃO
receber nova temperatura
ENVIAR mensagem para reiniciar NODES
FIM //permite enviar novo pedido se o anterior não teve resposta
SE contador for maior que 20
ENTÃO
REINICIAR contador
ENVIAR mensagem para reiniciar NODES
ESPERAR 2000 ms
ENVIAR pedido de nova temperatura
FIMFIM ALGORITMO
A implementação deste algoritmo produziu o seguinte senScript. Repare que o gateWay vai receber Temperatura de node de forma aleatória. É enviado um pedido para um Node específico e o gateway espera pela resposta. Se a resposta não chegar em tempo útil (Nodes está offline por falha de bateria ou outro problema, ou já não existe na rede) o gateway irá enviar um novo pedido a outro Node escolhido de forma aleatória.
SenScript (sink):
atget id id
randb node 10 20
set count 0
data d $id A $node
send $dloop
wait 300000
read m
rdata $m rid type x y
inc countif ($type==B)
simulation 0 100
mark 1
println N: $count TEMP: $x
data r $id R $node
send $r
endif($count>20)
set count 0
data r $id R $node
send $r
delay 2000
randb node 10 20
data d $id A $node
send $d
end
Código NODE (unificado para todos os Nodes)
O código para os nodes é um pouco mais complexo porque se pretendeu nesta abordagem, unificar o mesmo. Todos os nodes têm o mesmo código e não scripts diferentes para cada um deles.
Algoritmo :
Var
recA: int
id: inteiroINICIO
ESPERAR por mensagem
LER mensagem
SE mensagem for do TIPO R e recA for 1
ENTÃO
DESMARCAR o sensor
REINICAR recA
IDENTIFICAR id do nó anterior
ENVIAR mensagem de RESET para todos
FIM SE mensagem for do TIPO A e recA for 0
ENTÃO
INICAR recA com 1
SE id de destino for id atual
ENTÃO
MARCAR Node
LER sensor temperatura
ENVIAR mensagem com Temperatura para todos
SE NÃO
ENTÃO
IDENTIFICAR id do nó que enviou
ENVIAR mensagem recebida para os seguintes
FIM
FIM SE mensagen for tipo B
ENTÃO
MARCAR sensor
ENVIAR mensagem PARA node ANTERIOR
FIMFIM ALGORITMO
A implementação do algoritmo originou O script SenScript seguinte. Repare que aqui a mensagem de RESET e de PEDIDO é enviada em broadcast (Ver mais AQUI) para todos os nodes.
“In computer networking, broadcasting refers to transmitting a packet that will be received by every device on the network.” ( Wikipedia)
Mas “receber” informação é passada unicamente para o node anterior (até chegar ao gateway que pediu a mensagem .. ). São utilizados mais recursos no envio, mas menores ao receber
SenScript (node):
atget id id
set recA 0
loop
wait
read m
rdata $m rid type info info2if(($type==R) && ($recA==1))
mark 0
set recA 0
set prev $rid
data r $id R $info
send $r
endif(($type==A) && ($recA==0))
set recA 1
if($info==$id)
mark 1
//ENVIA temperatura
areadsensor x
rdata $x a b c //println TEMP ENVIADA: $c
data d $id B $c
send $d $rid else
set prev $rid
data d $id A $info
send $d
end
endif($type==B)
simulation 0 100
mark 1
data d $id B $info $info2
send $d $prev
end
Resultados
Na configuração inicial obtemos todas as temperaturas dos 7 nodes. A figura 2 mostra a simulação deste algoritmo de comunicação
É visível como nodes não directamente ligados à gateway conseguem enviar a temperatura e o gateway efectivamente receber a mesma. Esta implementação simples pode ser utilizada em muitos mais nodes. Na figura 3 pode ver a simulação com uns 20 nodes e uma gateway. O mesmo código.
Da leitura da documentação é dito ser possível utilizar JAVA ou Python para programar as simulações. Para isso deve ser alterado o código Fonte do simulador, pode encontrar o mesmo no GitHub.
É também possível simular o consumo da bateria dos sensores. Ou até mesmo simular o carregamento das baterias por painel solar, simulando as horas de sol e a sua intensidade.
Os nodes por onde o pedido da temperatura “passa”, são marcados; para visualmente ser possível acompanhar o trajecto até à gateway.
Muitos mais nodes!!!
Na figura 3 podemos ver a simulação com uma centena de nodes emissores e um transmissor. Podemos programar eventos aleatórios em SenScript para , por exemplo, desligar nodes (simular falta de energia) e registar o comportamento do protocolo de comunicação.
CONCLUSÃO da parte 2 (simulação)
CupCarbon revelou-se um simulador excelente para testar novos algoritmos de comunicação (simples ou complexos). Com todas a funcionalidades necessárias aos testes que pretendemos realizar. Simples de instalar, com uma documentação bastante boa e com exemplos práticos disponíveis no site (AQUI).
O site dispõe igualmente de um forum, mas é muito pouco frequentado. O melhor é mesmo ler o PDF e abrir os exemplo.
