UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Monitoreo de variables ambientales paraprevenir incendios forestales

Autor:Ing. Elías Alejandro Año Mendoza

Director:Dr. Ing. Juan Augusto Maya (FIUBA)

Codirector:Esp. Ing. Julián Iglesias (FIUBA)

Jurados:Esp. Ing. Patricio Bos (FIUBA)

Esp. Ing. Sergio De Jesús Meleán (FIUBA)Esp. Ing. Marco Andrés Darino (FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires entre agostode 2016 y agosto de 2018.

III

Resumen

En la presente memoria se describe el desarrollo de una red de monitoreo devariables ambientales con el objetivo de alertar y prevenir sobre la ocurrencia de

incendios en zonas forestales. Este proyecto se llevó a cabo para la empresaComSi S.A. y tiene como producto final la implementación de una red de nodos

de sensado encargados de la transmisión de datos hacia una plataforma eninternet para su visualización en tiempo real.

Este proyecto fundamenta su aplicación dentro de los conceptos de redes de áreaamplia y baja potencia, LPWAN, con la finalidad de optimizar recursos de

transmisión en áreas remotas. Así mismo, para el desarrollo del proyecto setuvieron en cuenta procedimientos de programación por capas, definición de

reglas de compilación y protocolos de comunicación.

V

Agradecimientos

A mi familia por contar siempre con su incondicional apoyo.

A todo el equipo de trabajo de la empresa ComSi S.A. por su cordialidad, con-fianza y por permitirme llevar a acabo el proyecto.

A todos los que hacen posible la Carrera de Especialización en Sistemas Embebi-dos en la Universidad de Buenos Aires.

VII

Índice general

Resumen III

1. Introducción General 11.1. Monitoreo de variables ambientales . . . . . . . . . . . . . . . . . . 11.2. LPWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. LoRa y LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1. LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3.2. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.3. Clases de dispositivos LoRaWAN . . . . . . . . . . . . . . . 41.3.4. Métodos de Activación LoRaWAN . . . . . . . . . . . . . . . 4

1.4. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción Específica 72.1. Esquema general del sistema . . . . . . . . . . . . . . . . . . . . . . 72.2. Identificación de variables . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Viento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3. Humedad atmosférica . . . . . . . . . . . . . . . . . . . . . . 82.2.4. Humedad de los suelos . . . . . . . . . . . . . . . . . . . . . 82.2.5. Presencia de gases . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Diseño e Implementación 113.1. Diagrama general del sistema . . . . . . . . . . . . . . . . . . . . . . 113.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1. Nodo de comunicación . . . . . . . . . . . . . . . . . . . . . 12Placa base Comsi . . . . . . . . . . . . . . . . . . . . . . . . . 12Transmisor LoRa . . . . . . . . . . . . . . . . . . . . . . . . . 13Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Alimentación . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1. Software embebido . . . . . . . . . . . . . . . . . . . . . . . . 15Firmware nodos de comunicación . . . . . . . . . . . . . . . 15Recepción y transmisión de datos . . . . . . . . . . . . . . . 17Reglas de compilación . . . . . . . . . . . . . . . . . . . . . . 17Software del gateway single channel . . . . . . . . . . . . . . 19

3.3.2. Software de servidor de datos . . . . . . . . . . . . . . . . . . 21

4. Ensayos y Resultados 234.1. Pruebas de sensado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

VIII

Pruebas de sensado nodo 1 . . . . . . . . . . . . . . . . . . . 23Pruebas de sensado nodo 2 . . . . . . . . . . . . . . . . . . . 24Autonomía en nodos de comunicación . . . . . . . . . . . . 24

4.2. Pruebas de transmisión al gateway . . . . . . . . . . . . . . . . . . . 254.3. Pruebas en procesamiento de datos . . . . . . . . . . . . . . . . . . . 264.4. Comprobación de alarmas . . . . . . . . . . . . . . . . . . . . . . . . 274.5. Pruebas de visualización de información . . . . . . . . . . . . . . . 27

5. Conclusiones 295.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 295.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Bibliografía 31

IX

Índice de figuras

1.1. Monitoreo en la agricultura. . . . . . . . . . . . . . . . . . . . . . . . 11.2. Estructura de red LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Esquema general del sistema . . . . . . . . . . . . . . . . . . . . . . 7

3.1. Diagrama general del sistema . . . . . . . . . . . . . . . . . . . . . . 113.2. Arquitectura del nodo de comunicación . . . . . . . . . . . . . . . . 123.3. Placa base Comsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4. Transmisor LoRa Bee . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5. Sensores: (a)YL69, (b)AM2320, (c)MQ2, (d)Veleta, (e)Anemómetro . 143.6. Gateway single channel . . . . . . . . . . . . . . . . . . . . . . . . . 153.7. Modelo del firmware empleado en los nodos de comunicación . . . 163.8. Descarga del software del gateway single channel desde Github . . 203.9. Transmisión de datos a The Things Network . . . . . . . . . . . . . 203.10. Visualización resumen de variables ambientales . . . . . . . . . . . 213.11. Visualización detalle de variables ambientales . . . . . . . . . . . . 21

4.1. Pruebas de sensado en nodo 1 . . . . . . . . . . . . . . . . . . . . . . 234.2. Pruebas de sensado en nodo 2 . . . . . . . . . . . . . . . . . . . . . . 244.3. Máxima distancia en pruebas de transmisión . . . . . . . . . . . . . 254.4. Visualización de datos en el servidor de red . . . . . . . . . . . . . . 264.5. Pruebas de transmisión hacia el servidor de aplicación . . . . . . . 274.6. Visualización en la aplicación web . . . . . . . . . . . . . . . . . . . 284.7. Histórico del sensado de datos . . . . . . . . . . . . . . . . . . . . . 284.8. Aplicación web responsive . . . . . . . . . . . . . . . . . . . . . . . . 28

XI

Índice de Tablas

1.1. Resumen de tecnologías LPWAN . . . . . . . . . . . . . . . . . . . . 2

3.1. Tabla de conexión gateway single channel . . . . . . . . . . . . . . 153.2. Métodos de recepción y transmisión de datos . . . . . . . . . . . . . 17

4.1. Pruebas de transmisión . . . . . . . . . . . . . . . . . . . . . . . . . . 25

XIII

A Alejandro e Ysabel

1

Capítulo 1

Introducción General

En este capítulo se abordan los conceptos generales sobre el monitoreo de varia-bles ambientales, transmisión de datos LPWAN y se describen los objetivos, lamotivación así como el alcance del proyecto.

1.1. Monitoreo de variables ambientales

Dentro de los conceptos de ecología existen terminos tales como los factores am-bientales abióticos; estos pueden entenderse como componentes fisico-químicosque influyen en un determinado espacio donde habitan seres vivos. Estos facto-res o variables también pueden calificarse como elementos de la naturaleza quesirven para conocer el estado de un determinado ecosistema [1]. Cambios en va-riables tales como la temperatura, humedad del aire, concentración de gases, etc.pueden influir en el desencadenamiento de fenómenos que escapen del control ysean finalmente perjudiciales para el hombre y la naturaleza.

En los últimos años el uso de tecnologías para el monitoreo de variables am-bientales esta permitiendo una mayor eficiencia en la forma como se obtienenlos datos y como posteriormente sirven para tomar decisiones. La aplicación deeste tipo de monitoreo puede verse en áreas muy diversas como la agricultura,ganadería, silvicultura, etc. En la Figura 1.1 se muestra un ejemplo de monitoreoaplicado a la agricultura.

FIGURA 1.1: Monitoreo en la agricultura.

2 Capítulo 1. Introducción General

1.2. LPWAN

El termino LPWAN proviene del inglés, "Low-Power Wide-Area Network". Es untipo de transmisión inalámbrica para redes amplias con bajo consumo de potenciay baja tasa de transferencia. Las redes LPWAN pueden ser públicas o privadas,en el primer caso el propietario de los transmisores también tiene que contemplarla instalación de los gateways, en el segundo caso, un proveedor es el que seencarga de toda la infraestructura de los gateway para la transmisión de datosofreciendolo como servicio.

Actualmente existen diversas tecnologías dentro de LPWAN, siendo las principa-les: Sigfox, LoRaWAN y NarrowBand IoT. Un estudio comparativo realizado por"The Korean Institute of Communications Information Sciences"[4], señala que cadauna de estas tecnologías tiene características diferentes que pueden ser emplea-das dependiendo del campo de aplicación. El resumen del estudio comparativose detalla en la tabla 1.1.

TABLA 1.1: Resumen LPWAN por The Korean Institute of Commu-nications Information Sciences

Sigfox LoRaWAN NB-IoT

Modulación BPSK CSS QPSKFrecuencia Bandas ISM no licencia-

das (868 MHz en Euro-pa, 915 MHz en NorteAmérica, y 433 MHz enAsia)

Bandas ISM no licencia-das (868 MHz en Euro-pa, 915 MHz en NorteAmérica, y 433 MHz enAsia)

Bandas de frecuenciaLTE

Ancho de banda 100 Hz 250 kHz y 125 kHz 200 kHzData rate máximo 100 bps 50 kbps 200 kbpsBidireccional Limitado / Half-duplex Si / Half-duplex Si / Half-duplexMáximo mensajes/día 140 (UL), 4 (DL) Ilimitado IlimitadoMáximo tamaño pay-load

12 bytes (UL), 8 bytes(DL)

243 bytes 1600 bytes

Rango 10 km (urbano), 40 km(rural)

5 km (urbano), 20 km(rural)

1 km (urbano), 10 km(rural)

Inmunidad a Interferen-cia

Muy Alta Muy Alta Baja

Autenticación & encrip-tación

No soportada Si (AES 128b) Si (encriptación LTE)

Data rate adaptativo No Si NoHandover Los dispositivos finales

no se conectan una esta-ción base simple

Los dispositivos finalesno se conectan una esta-ción base simple

Los dispositivos finalesse conectan a una esta-ción base simple

Localización Si (RSSI) Si (TDOA) No (bajo especificación)Permite red privada No Si NoEstándar Sigfox Company cola-

bora con ETSI en la es-tandarización de las re-des basadas en Sigfox

LoRa-Alliance 3GPP

1.3. LoRa y LoRaWAN

1.3.1. LoRa

Entre sus características se destacan:

Modulación de radiofrecuencia de espectro ensanchado (CSS) patentadopor Semtech

1.3. LoRa y LoRaWAN 3

Pertenece a la capa física de la comunicación

Tiene alta tolerancia a las interferencias

Transmisión de largo alcance entre 10 a 20km

Baja transferencia de datos, hasta 255 bytes

Permite conexión punto a punto

Frecuencias de transmisión: 915Mhz, 868Mhz, 433Mhz

1.3.2. LoRaWAN

Entre sus características se tiene:

Protocolo de comunicación que usa la tecnología LoRa

Pertenece a la capa de red de la comunicación

Permite tener una topología de red tipo estrella

Usa encriptación AES-128

Permite 3 tipos de dispositivos: clase A, clase B, clase C

Permite la gestión de dispositivos

La arquitectura de una red LoRaWAN propone tener una serie de dispositivos onodos que se conectan a gateways los cuales envían los datos a un servidor dered. A partir del servidor de red por medio de una API se transmiten datos a losservidores de aplicación para mostrarlos finalmente a los usuarios. En la Figura1.2 se muestra una estructura de red LoRaWAN.

FIGURA 1.2: Estructura de red LoRaWAN

4 Capítulo 1. Introducción General

1.3.3. Clases de dispositivos LoRaWAN

Los dispositivos finales pueden ser de tres clases diferentes A, B y C. Cada unacon características diferentes de optimización:

Clase A: Permiten comunicación bidireccional donde el dispositivo inicia lacomunicación y espera una respuesta del gateway dentro de una ventanade tiempo, tras la respuesta salen del modo escucha. Esta clase es ideal paradispositivos que usan baterías por su bajo consumo de energía.

Clase B: Estos dispositivos permiten comunicación bidireccional con unaventana de tiempo predeterminada para la recepción de respuestas del ga-teway, pueden usar baterías o fuente externa dependiendo de los tiemposde escucha asignados. Esta clase es ideal cuando se requiera baja latencia.

Clase C: Esta clase de dispositivos pemiten comunicación bidireccional pe-ro ofrecen menor ahorro de energía debido a que siempre tienen la ventanade tiempo abierta, en esta clase es recomendable el uso de fuente de alimen-tación externa para mantener la transmisión. Esta clase es ideal cuando serequiera respuestas sin latencia.

1.3.4. Métodos de Activación LoRaWAN

Los dipositivos pueden conectarse a la red mediante dos métodos de activación:

Over-the-Air-Activation (OTAA): En este método el dispositivo transmiteun solicitud para unirse a la red con los parámetros: DevEUI (identificadorúnico del dispositivo), AppEUI (identificador de aplicación) y AppKey (cla-ve secreta AES-128). Como resultado al dispositivo se le asigna un DevAddr(dirección dentro de la red) de forma dinámica.

Activation-By-Personalization (ABP): En este método se escriben directa-mente las claves de sesión en el dispositivo para lo cual no es necesario unanegociación para unirse a la red. Para lograr esto el dispositivo transmitelos parámetros: DevAddr (dirección dentro de la red), NwkSKey (clave desesión de red), AppSKey (clave de sesión de aplicación).

1.4. Motivación

Actualmente el uso de tecnologías para la transmisión de datos dentro del con-texto de la Internet de las Cosas (IoT) esta bastante extendida, muchos de los dis-positivos que se utilizan para la transmisión de datos involucran bajas tasas detransferencia. Es así, que la implementación de soluciones que representen bajatasa de transferencia y bajo consumo de energía son una gran ventaja para adap-tarlas a diferentes necesidades y más concretamente a la prevención de incendiosforestales.

Según un informe de Beecham Research, titulado Informe de Mercado y Previsiónsobre las Redes WAN de Baja Potencia para Aplicaciones IoT[6] las redes WAN debaja potencia (LPWAN) son la mejor opción para aplicaciones M2M (Machineto Machine) y de IoT (Internet of Things). Las redes LPWAN parecen solventar

1.5. Objetivo 5

inconvenientes relacionados al bajo consumo de energía, coste reducido y trans-misiones a largo alcance[2].

1.5. Objetivo

Implementar un prototipo funcional de red del tipo LPWAN (Low Power WideArea Network), con tecnología LoRa que sirva para transmitir datos de variablesambientales con el fin de monitorear y prevenir incendios forestales.

1.6. Alcance

El proyecto contempla:

El desarrollo de los prototipos funcionales de los nodos de sensado de va-riables ambientales.

El desarrollo del prototipo funcional del colector de datos.

El desarrollo del software para el funcionamiento de los nodos y el colectorde datos.

El desarrollo de la fuente de alimentación de los nodos y el colector de da-tos.

El desarrollo de la plataforma para la recepción de datos.

La documentación del proceso de desarrollo.

El proyecto no contempla:

La selección del hardware base para los transmisores. Se trabajó con el hard-ware base proporcionado por el auspiciante.

La selección del hardware para la fuente de alimentación. Se trabajó con elhardware proporcionado por el auspiciante.

El desarrollo del hardware para el colector de datos.

La interpretación exhaustiva sobre los datos obtenidos.

7

Capítulo 2

Introducción Específica

En este capítulo se presentan aspectos del desarrollo de la red de sensores plan-teada, la descripción general del sistema, la identificación de las variables am-bientales, así como los requerimientos del proyecto.

2.1. Esquema general del sistema

El sistema propuesto se compone de una red de sensores distribuidos los cualesenvían lecturas de variables ambientales a un colector datos (gateway) que luegose transmiten a una plataforma en internet para su procesamiento e interpreta-ción.

Los nodos se comunican con el colector a traves de la red LoRa y la transmisióndel colector de datos hacia la plataforma de datos se realiza a través de una red deltipo 3G o Ethernet dependiendo de la disponibilidad. En la Figura 2.1 se muestrael esquema general del sistema.

FIGURA 2.1: Esquema general del sistema

8 Capítulo 2. Introducción Específica

2.2. Identificación de variables

Para la identificación de las variables se tomaron en cuenta investigaciones referi-das a las causas metererológicas de los incendios forestales[3] [5], que se describena continuación.

2.2.1. Temperatura

La temperatura tiene influencia importante en los incendios. En principio, lastemperaturas elevadas permiten que el material orgánico acumulado en los bos-ques se encuentre siempre disponible como potencial combustible. El materialacumulado recibe calor por radiación del sol, como consecuencia, se requiere me-nor calor para encenderlo. Altas temperaturas por tiempos prolongados permitenque el combustible se encienda con mayor facilidad aumentando la propagacióndel fuego.

2.2.2. Viento

El viento puede cambiar de dirección e intensidad en el día. Los cambios abrup-tos en el viento generalmente ocurren durante la tarde cuando las condicionesatmosféricas son más inestables. El viento provee de oxigeno al proceso de com-bustión, reduce la humedad de los suelos por incremento de la evaporación, y encaso de un incendio ejerce presión para direccionar al fuego ocasionando grandesllamaradas.

2.2.3. Humedad atmosférica

La cantidad de humedad atmosférica tiene relación directa con la cantidad dehumedad que hay en el combustible orgánico. Bajos niveles de humedad atmos-férica permiten que rápidamente se pueda iniciar un incendio o faciliten que elfuego se expanda. Es por esto que la humedad atmosférica funciona como uninhibidor de incendios. Si los niveles son cercanos al 100 % el material orgánicoreducira su inflamabilidad.

2.2.4. Humedad de los suelos

Las bajas condiciones en la humedad de los suelos y las altas temperaturas sonvariables que permiten que los incendios se originen con mayor facilidad. La ma-yoría de incendios ocurridos suceden en suelos secos y con temperaturas máselevadas de lo usual.

2.2.5. Presencia de gases

Para el monitoreo se considera que es importante conocer la presencia de gasescombustibles asi como de humo para alertar de la presencia de un incendio.

2.3. Requerimientos 9

Con base en las variables antes mencionadas se podrá adquirir los sensores nece-sarios para el proyecto.

2.3. Requerimientos

Se contemplaron los siguientes requerimientos que debe cumplir el proyecto:

1. Equipo prototipo para la toma de datos (Nodo de comunicación tipo 1)

a) Capaz de sensar variables ambientales de:

1) Temperatura ambiental

2) Humedad atmosférica

3) Humedad del suelo

4) Presencia de gases

5) Medir nivel de batería

b) Funcionar con batería recargable, cargador, celda solar

c) Permitir la transmisión haciendo uso de LoRa

d) Contar con ciclos de sensado y ciclos de transmisión predefinidos

2. Equipo prototipo para la toma de datos (Nodo de comunicación tipo 2)

a) Capaz de sensar variables ambientales de:

1) Temperatura ambiental

2) Humedad atmosférica

3) Velocidad del viento

4) Dirección del viento

5) Presencia de gases

b) Funcionar con batería recargable, cargador, celda solar

c) Permitir la transmisión haciendo uso de LoRa

d) Contar con ciclos de sensado y ciclos de transmisión predefinidos

3. Equipo colector de datos (Gateway)

a) Deberá contar con capacidad para comunicarse con los sensores ha-ciendo uso de métodos que permitan el bajo consumo de energía ytransmisión a largas distancias

b) Tener la capacidad para enviar datos a través de 3G o Ethernet hacia elservidor de aplicación

c) Tener la capacidad para el envío de alertas hacia el servidor de aplica-ción

4. Software de Nodo prototipo

10 Capítulo 2. Introducción Específica

a) Deberá ser capaz de transmitir los datos en un formato que sea fácil-mente enviado al colector

5. Software de Colector

a) Deberá ser capaz de procesar los datos de los nodos y enviarlos al ser-vidor de aplicación

6. Software de recepción de datos en plataforma (Servidor de aplicación)

a) Deberá ser capaz de tener un servicio abierto para la recepción de datosdel colector

b) Deberá ser capaz de grabar los datos recibidos a una base de datos

7. Software de visualización de datos

a) Deberá ser capaz de mostrar los datos de los nodos vía web

8. La documentación del proceso de desarrollo

a) Se proporcionará documentación para el desarrollador y usuario

11

Capítulo 3

Diseño e Implementación

En este capítulo se describen los detalles del hardware y software utilizados, laarquitectura del proyecto y la plataforma de adquisición de datos.

3.1. Diagrama general del sistema

El sistema se compone de una primera etapa de sensado de variables ambientales,una segunda etapa de transmisión al gateway o colector de datos, una tercera eta-pa de procesamiento de datos y una cuarta etapa de visualización de informaciónpor el usuario. Los detalles se pueden ver en la Figura 3.1

FIGURA 3.1: Diagrama general del sistema

Como se observa, la comunicación entre los nodos y el gateway (colector de da-tos) se realiza mediante LoRa, el gateway se comunica al servidor de red LoRa-WAN mediante ethernet o 3G. La información del servidor de red es enviada alservidor de datos para su procesamiento e interpretación y finalmente se mues-tran al usuario mediante una aplicación web.

12 Capítulo 3. Diseño e Implementación

3.2. Hardware

3.2.1. Nodo de comunicación

Como se explicó en la Sección 2.3 los nodos de comunicación pueden ser de dostipos, para esto la arquitectura general se compone de cuatro partes como se apre-cia en la Figura 3.2.

FIGURA 3.2: Arquitectura del nodo de comunicación

El detalle de las partes es como sigue:

Procesamiento: placa base ComSi

Comunicación: transmisor LoRa Bee

Sensores:

• Temperatura

• Humedad atmosférica

• Humedad del suelo

• Humo y gases de petroleo

• Veleta

• Anemómetro

Alimentación:

• Batería

Placa base ComSi

El auspiciante proporcionó el hardware para el desarrollo del proyecto. La placaconsta de un microcontrolador ATxmega64A3U con sistemas de regulación detensión, interfaces de comunicación e interface general de entrada y salida. Laplaca base esta desarrollada para propósito general dentro de la empresa ComSi.(Figura 3.3)

3.2. Hardware 13

FIGURA 3.3: Placa base ComSi

Transmisor LoRa

Para la transmisión se consideró el transmisor LoRa Bee (Figura 3.4) debido aque cumple con las necesidades básicas además de su bajo costo. Cuenta con lassiguientes características:

Basado en el chip SX1276

Comunicación SPI

Alimentación de 3.3v

Frecuencia de trabajo de 915 Mhz (Banda norte americana)

Modulación FSK, GFSK, MSK, GMSK, LoRaTM y OOK

Excelente inmunidad al ruido

Alta sensibilidad, menor a -148 dBm

Bit rate programable arriba de 300 kbps

FIGURA 3.4: Transmisor LoRa Bee

14 Capítulo 3. Diseño e Implementación

Sensores

Los sensores considerados pueden apreciarse en la Figura 3.5 y corresponden a:sensor de humedad del suelo (YL69), sensor de temperatura y humedad (AM2320),sensor de humo y gases inflamables (MQ2), veleta y anemómetro.

FIGURA 3.5: Sensores: (a)YL69, (b)AM2320, (c)MQ2, (d)Veleta,(e)Anemómetro

Alimentación

La sección de alimentación se compone de los siguientes elementos:

Batería de 12v 4Amp

Panel Solar 10watts 12v

Regulador de carga para panel solar 12v 4Amp

3.2.2. Gateway

Para el proyecto se consideraron dos tipos de gateway o colectores de datos: ungateway single channel desarrollado para pruebas y otro gateway multiple chan-nel proporcionado como servicio por un proveedor de LoRaWAN. Para el primercaso se consideraron las siguientes partes:

Placa Raspberry Pi 3 modelo B

Transmisor LoRa Bee

La conexión que se siguió para el gateway single channel se muestra en la Tabla3.1 y la Figura 3.6.

3.3. Software 15

TABLA 3.1: Tabla de conexión en gateway single channel

LoRa Bee Raspberry Pi 3Pin Descripción Pin Descripción

1 3.3V 1 3.3V10 GND 6 GND4 MISO 21 SPI-MISO11 MOSI 19 SPI-MOSI18 SCK 23 SPI-CLK17 NSS 22 GPIO 612 DIO 0 7 GPIO 75 RESET 11 GPIO 0

FIGURA 3.6: Gateway single channel

Para la transmisión de datos en cualquiera de estos gateways, solo fueron nece-sarios cambios mínimos en el firmware de los nodos de comunicación.

3.3. Software

3.3.1. Software embebido

Firmware nodos de comunicación

Para el desarrollo del firmware se consideró un modelo por capas basada en eluso de la biblioteca The IBM LoRaWAN C-library LMIC, que es una especificaciónpara lenguaje C que soporta LoRaWAN en bandas EU-868 y US-915 y que manejadispositivos clase A y B. En la Figura 3.7 se muestra el modelo de capas empleadopara el firmware. Se tuvo que portar la biblioteca LMIC así como implementar lacapa de abstracción de hardware (HAL) a la arquitectura del microcontrolador dela placa base ComSi.

Los detalles de las funciones importantes de la capa de abstracción de hardwarese muestran en el Algoritmo 3.1

16 Capítulo 3. Diseño e Implementación

FIGURA 3.7: Modelo del firmware empleado en los nodos de co-municación

1 # i f n d e f XMEGA_HAL_H_2 # def ine XMEGA_HAL_H_3

4 # include < s t d i o . h>5 # include <stdbool . h>6 # include <avr/ i n t e r r u p t . h>7 # include " inc/oslmic . h"8 # include " inc/lmic . h"9 # include " . . / u sar t/ inc/u sar t . h "

10 # def ine NUM_DIO 311 # def ine DIO0_PORT PORTC12 # def ine DIO0_PIN PIN5_bm13 # def ine DIO1_PORT PORTC14 # def ine DIO1_PIN PIN4_bm15 # def ine DIO2_PORT PORTB16 # def ine DIO2_PIN PIN5_bm17 # def ine RESET_PORT PORTB18 # def ine RESET_PIN PIN6_bm19

20 /∗SPI∗/21 # def ine NSS_PORT PORTD22 # def ine NSS_PIN PIN4_bm23 # def ine MOSI_PORT PORTD24 # def ine MOSI_PIN PIN5_bm25 # def ine MISO_PORT PORTD26 # def ine MISO_PIN PIN6_bm27 # def ine SCK_PORT PORTD28 # def ine SCK_PIN PIN7_bm29

30 # def ine SPI_DEBUG 131

32 /∗Funciones de HAL∗/33 void h a l _ i o _ i n i t ( ) ;34 void ha l_p in_rx tx ( u1_t val ) ;35 void h a l _ p i n _ r s t ( u1_t val ) ;36 void hal_ io_check ( ) ;

3.3. Software 17

37 void s p i _ i n i t _ p i n s ( ) ;38 void spi_enable_module ( ) ;39 void h a l _ s p i _ i n i t ( ) ;40 void hal_pin_nss ( u1_t val ) ;41 u1_t h a l _ s p i ( u1_t out ) ;42 u4_t h a l _ t i c k s ( ) ;43 s t a t i c s 4 _ t de l ta_ t ime ( u4_t time ) ;44 void hal_wai tUnt i l ( u4_t time ) ;45 u1_t hal_checkTimer ( u4_t time ) ;46 void i n t e r r u p t _ i n i t ( void ) ;47 void hal_disableIRQs ( )48 void hal_enableIRQs ( )49 void ha l_s l eep ( )50 void h a l _ i n i t ( )51 void h a l _ f a i l e d ( const char ∗ f i l e , u2_t l i n e ) ;52

53 # endi f

ALGORITMO 3.1: HAL para comunicación con LMIC

Recepción y transmisión de datos

El microcontrolador recibe y transmite datos mediante protocolos y métodos decomunicación que pueden identificarse en la Tabla 3.2. Se definieron periodos desensado de 3 minutos y periodos de transmisión de 15 minutos.

TABLA 3.2: Métodos de recepción y transmisión de datos

Dispositivo Función Método

AM2320 sensado protocolo I2CYL69 sensado lectura ADC 12 bitsMQ2 sensado lectura ADC 12 bitsAnemómetro sensado lectura de pulsos GPIOVeleta sensado lectura ADC 12 bitsLoRa comunicación protocolo SPI

Reglas de compilación

La compilación del firmware se realizó en un sistema operativo GNU/Linux paralo cual se tuvieron que implementar reglas de compilación, concretamente scriptsMakefile. Estos scripts facilitaron el proceso de compilación y enlace entre losdiferentes módulos de software que componen el firmware del nodo.

Se definió en principio un archivo de configuración, como se muestra en el Algo-ritmo 3.2.

1 PROJECT_PATH ?= p r o j e c t s $ (DS) lora_nodo2 ARCH ?= atxmega64a3u3 PROGRAMMER ?= avrispmkII4 MCU ?= x64a3u5 F_CPU ?= 32000000

ALGORITMO 3.2: Regla de configuración inicial: config.mk

18 Capítulo 3. Diseño e Implementación

También se definió una regla de compilación general, como se muestran en el Al-goritmo 3.3, que se comunica con scripts Makefile internos del proyecto

1 DS ?= /2 inc lude conf ig .mk3 inc lude $ (PROJECT_PATH) $ (DS) Makefi le4

5 TARGET = $ (PROJECT_NAME)6 MODS_PATH = . $ (DS) modules7 MODS_HEAD = $ ( foreach MOD, $ (MODS) , −I $ (MODS_PATH) $ (DS) $ (MOD) $ (DS) inc )8 MODS_SRC = $ ( foreach MOD, $ (MODS) , $ ( wildcard $ (MODS_PATH) $ (DS) $ (MOD) $ (

DS) ∗ . c ) )9 FREQ_CPU = $ (F_CPU)UL

10

11 SRC = \12 $ ( $ (PROJECT_NAME)_SRC_PATH) $ (DS) main . c \13 $ (MODS_SRC) \14

15 WARNINGS = −Wall −Wextra16

17 CFLAGS = −Os −std=gnu99 − l p r i n t f _ f l t −Wl,−u , v f p r i n t f $ (MODS_HEAD) −I $ (PROJECT_INC_FILES ) \

18 $ (WARNINGS) −DF_CPU=$ (FREQ_CPU)19

20 CC = avr−gcc21 OBJCOPY = avr−objcopy22 AVRDUDE = avrdude23 OBJ = $ (SRC : . c = . o )24 ALL_CFLAGS = −mmcu=$ (ARCH) $ (CFLAGS)25

26 a l l : begin $ (TARGET) . e l f $ (TARGET) . hex27

28 # Define messages29 MSG_BEGIN = ====BEGIN COMPILATION====30 MSG_LINKING = =========LINKING=========31 MSG_BINARY = ====GETTING .HEX FILE====32

33 begin :34 @echo35 @echo $ (MSG_BEGIN)36

37 %.hex : %. e l f38 @echo39 @echo $ (MSG_BINARY)40 $ (OBJCOPY) − j . t e x t − j . data −O ihex $< $@41

42 %. e l f : $ ( OBJ )43 @echo44 @echo $ (MSG_LINKING)45 $ (CC) $ (ALL_CFLAGS) $ ( OBJ ) −−output $@ $ (LDFLAGS)46

47 %.o : %.c48 @echo " Compiling : $< . . . "49 $ (CC) −c $ (ALL_CFLAGS) $< −o $@50

51 %.d : %.c52 s e t −e ; $ (CC) −MM $ (ALL_CFLAGS) $< \53 | sed ’ s , \ ( . ∗\ ) \. o [ : ] ∗ , \ 1 . o \1.d : , g ’ > $@ ; \54 [ −s $@ ] || rm −f $@55

3.3. Software 19

56 −inc lude $ (SRC : . c = .d )57

58 c lean :59 f ind . −type f −name " ∗ . o " −exec rm −f { } \ ;60 f ind . −type f −name " ∗ . d" −exec rm −f { } \ ;61 f ind . −type f −name " ∗ . e l f " −exec rm −f { } \ ;62 f ind . −type f −name " ∗ . hex " −exec rm −f { } \ ;63

64 download :65 $ (AVRDUDE) −p $ (MCU) −c $ (PROGRAMMER) −P usb −U f l a s h :w: $ (TARGET) . hex

−e66

67 i n f o :68 @echo $ (SRC)69 @echo70 @echo $ (CFLAGS)71 @echo72 @echo $ ( OBJ )73 @echo74 @echo $ (ALL_CFLAGS)75 @echo76 @echo $ (TARGET) . e l f77 @echo78 @echo $ (MODS_HEAD)79 @echo80 @echo $ (MODS_SRC)81

82 .PHONY : a l l i n f o begin download

ALGORITMO 3.3: Regla de compilación general: Makefile

Software del gateway single channel

En una primera etapa se construyó un gateway single channel para realizar prue-bas de transmisión, para esto se consideró el desarrollo sobre una placa RaspberryPi 3 Modelo B con comunicación LoRaWAN y Ethernet. El software utilizado esPacket Forwarder[7], funciona sobre el sistema operativo Raspbian y transmitelos datos hacia la plataforma The Things Network[8].

Para configurar el servicio Packet Forwarder se descarga el software desde su re-positorio de Github y se configuran los parámetros dentro del archivo main.cpp talcomo se muestra en la Figura 3.8 y el Algoritmo 3.4. La idea general es contar conun gateway single channel operando en banda australiana de 915AU (915Mhz -928Mhz), debido a que nuestro proveedor de LoRaWAN también trabaja con labanda australiana.

En la etapa de producción se cuenta con un gateway multiple channel, de mayorcapacidad y que transmite a un servidor de red propietario del proveedor. Parala operación con este gateway no es necesario instalar algún software, solamen-te realizar configuraciones para la comunicación con los nodos y el servidor dedatos.

20 Capítulo 3. Diseño e Implementación

FIGURA 3.8: Descarga del software del gateway single channeldesde Github

1 // SX1272 − Raspberry connect ions2 i n t ssPin = 6 ;3 i n t dio0 = 7 ;4 i n t RST = 0 ;5

6 // Set spreading f a c t o r ( SF7 − SF12 )7 s f _ t s f = SF7 ;8

9 // Set c e n t e r frequency10 u i n t 3 2 _ t f r e q = 915000000 ;11

12 // def ine s e r v e r s13 // The Things Network : router . au . t he th i ngs . network14 # def ine SERVER1 " 5 2 . 6 2 . 8 3 . 2 5 0 "15 // The port on which to send data16 # def ine PORT 1700

ALGORITMO 3.4: Configuración de parámetros en archivo:main.cpp

Después de la compilación y la ejecución del comando: sudo ./single_chan_pkt_fwdse visualizan los datos transmitidos en The Things Network, como se muestra en laFigura 3.9.

FIGURA 3.9: Transmisión de datos a The Things Network

3.3. Software 21

3.3.2. Software de servidor de datos

Los datos proporcionados por el servidor de red son enviados al servidor de datosmediante websockets. En el servidor de datos se encuentra instalada una plata-forma web que se encarga de almacenar y mostrar información sobre el estado delas variables ambientales (Figura 3.10).

El servidor es proporcionado por el auspiciante (ComSi S.A.) y el desarrollo dela web se asumió como parte del proyecto, aunque inicialmente no estaba dentrodel alcance, se llegó a un acuerdo para su construcción.

La plataforma esta compuesta de una base de datos PostgresSQL, una aplicaciónweb desarrollada con el framework web Yii2, y un servidor web Apache todoen un entorno GNU/Linux. La aplicación dispone de un resumen inicial de losestados de las variables ambientales por cada nodo de comunicación, también deun detalle e histórico por cada nodo (Figura 3.11).

FIGURA 3.10: Visualización resumen de variables ambientales

FIGURA 3.11: Visualización detalle de variables ambientales

23

Capítulo 4

Ensayos y Resultados

En este capítulo se describen las pruebas realizadas al prototipo propuesto. Semuestran los resultados de las pruebas a las distintas partes del sistema: sensadode variables ambientales, transmisión, procesamiento de datos y visualización dela información.

4.1. Pruebas de sensado

Se realizaron pruebas por tipo de nodo con ciclos de sensado de 3 minutos. Parala transmisión al gateway, estos datos posteriormente seran formateados adecua-damente.

Pruebas de sensado nodo 1

Este nodo esta encargado del sensado de las variables:

Temperatura

Humedad relativa

Humo y gases combustibles

Humedad del suelo

Nivel de batería

FIGURA 4.1: Pruebas de sensado en nodo 1

24 Capítulo 4. Ensayos y Resultados

Como se observa en la Figura 4.1 empezando de la izquierda como primera co-lumna se muestra la temperatura del ambiente (en grados celsius), la segundacolumna humedad relativa (en porcentaje), la tercera columna alarma del sensorde humo (NORMAL, cuando no existe presencia de humo y ALARMA cuandoexiste presencia de humo), en la cuarta columna el estado de la humedad del sue-lo (NORMAL, cuando la humedad del suelo tiene niveles adecuados y ALARMAcuando la humedad del suelo es muy baja), finalmente la quinta columna muestrael nivel de batería en porcentaje.

Pruebas de sensado nodo 2

Este nodo esta encargado del sensado de las variables:

Temperatura

Humedad relativa

Humo y gases combustibles

Velocidad del viento

Dirección del viento

Nivel de batería

FIGURA 4.2: Pruebas de sensado en nodo 2

Como se observa en la Figura 4.2 empezando des la izquierda como primera co-lumna se muestra la temperatura del ambiente (en grados celsius), la segundacolumna humedad relativa (en porcentaje), la tercera columna velocidad del vien-to (en kilómetros por hora), la cuarta columna la dirección del viento (N: norte,NE: nor-este, E: este, SE: sur-este, S: sur, SO: sur-oeste, O: oeste, NO: nor-oeste),finalmente la quinta columna muestra el nivel de batería en porcentaje.

Autonomía en nodos de comunicación

Considerando el consumo de los nodos de comunicación (tanto de sensado comode transmisión) se estimó una autonomía de 14.8 horas en el nodo de tipo 1, y de15.3 horas en el nodo de tipo 2.

4.2. Pruebas de transmisión al gateway 25

4.2. Pruebas de transmisión al gateway

Se realizaron pruebas desde varios puntos cercanos al gateway instalado en laempresa ComSi S.A. En la Tabla 4.1 se muestran los resultados obtenidos de laspruebas con un Spreading Factor 7 (SF7) en la transmisión.

Como se muestra en la Figura 4.3 se alcanzaron transmisiones de hasta 2.4km.

TABLA 4.1: Pruebas de transmisión

ID Dirección Distancia RSSI

1 Ruiz Huidobro y Washington 590.23m -103dbm2 Ruiz Huidobro y Melián 662.77m -103dbm3 Ruiz Huidobro y Roque Pérez 728.44m -103dbm4 Deheza y Conde 737.12m -91dbm5 Melián y Arias 476.03m -103dbm6 Posta y Correa 414.50m -94dbm7 Ramallo y Melián 525.95 m -107dbm8 Deheza y Superí 644.55m -101dbm9 Deheza y Conde 744.23m -109dbm10 Deheza y Quintana 1.06km -87dbm11 Deheza y Coneza 1.20km -93dbm12 Cramer y Arias 1.35km -95dbm13 Cramer y Ruiz Huidobro 1.40km -96dbm14 San Isidro y Ramallo 1.68km -96dbm15 Ramallo y Vuelta de Obligado 2.00km -79dbm16 Ramallo y Correa 2.18km -95dbm17 Ramallo y 3 de Febrero 2.40km -101dbm

FIGURA 4.3: Máxima distancia en pruebas de transmisión

Las pruebas se realizaron haciendo uso de un nodo de comunicación dentro deun auto en marcha transmitiendo cada medio minuto hacia un gateway Kerlinkmodelo Wirnet Station 923. De las pruebas se pudo concluir:

26 Capítulo 4. Ensayos y Resultados

En los puntos de prueba donde la línea de visión no es adecuada el nivel dela señal es baja a pesar que la distancia puede ser menor a los 800m.

En los puntos de prueba donde el relieve de la superficie es más elevado yla distancia es más alejada se obtuvieron valores adecuados de señal tal esel caso de los lugares ubicados cerca de las calles Deheza y Quintana.

La presencia de edificaciones dificulta la transmisión de datos.

Asi mismo se comprueba que los datos son enviados al servidor de red (Figura4.4)

FIGURA 4.4: Visualización de datos en el servidor de red

En el servidor de red los datos registrados tienen los siguientes campos:

Direction : Indica si es una transmisión (Up) o recepción de datos(Down)

Time: Hora de registro en el network server

FCNT: Contador de 16bits que sirve para el desencriptado

Port: Puerto del controlador de acceso

Status: Estado

Data Rate: Especifica los parámetros que se utilizaron para la transmisión

RSSI: Fuerza de señal

Decrypted: Muestra si el server network pudo desencriptar el dato

Data: Dato transmitido, la codificación tiene formato base64

4.3. Pruebas en procesamiento de datos

La primera parte de la prueba consiste en asegurar que los datos sean enviadosdesde el servidor de red hacia el servidor de datos. La transmisión se realiza me-diante un websocket que permite comunicaciones asíncronas, con el objetivo detener datos en tiempo real.

4.4. Comprobación de alarmas 27

Se configuró el servidor de red para que se reenvíe la información del sensadode los nodos al servidor de datos que atiende como socket server. Tal como semuestra en la Figura 4.5 los datos tienen formato json.

FIGURA 4.5: Pruebas de transmisión hacia el servidor de aplica-ción

Los datos son procesados para mostrarlos por la aplicación web y luego son al-macenados en una base de dato PostgreSQL para analizarlos y realizar alertasbasadas en los históricos.

4.4. Comprobación de alarmas

Las alarmas que se configuraron pueden ser de dos tipos: reactivas y basadas enlos históricos. Para el primer caso se consideró principalmente la alarma de pre-sencia de humo, para lo cual se envía un correo electrónico al usuario cuando elsensor de humo encuentra niveles elevados de humo. En el segundo tipo se consi-dera una evaluación de cada tres días del promedio de los datos de: temperatura,humedad atmosférica, velocidad del viento y niveles de humedad del suelo. Sidurante tres días se obtuvieron valores de temperatura mayores o iguales a 30◦C,humedad atmosférica menores o iguales al 50 %, velocidades del viento mayoresa 40km/h y niveles de humedad del suelo muy baja; se considerará una alarma yserá enviada por correo al usuario.

4.5. Pruebas de visualización de información

Con los datos obtenidos en el servidor de aplicación, se puede comprobar que elusuario puede acceder a los datos desde la web (Figura 4.6). La aplicación tam-bién cuenta con un histórico que puede ser descargado en formato excel (Figura4.7) y se pudo comprobar que tiene característica responsive, permitiendo ser vis-ta desde dispositivos móviles (Figura 4.8).

28 Capítulo 4. Ensayos y Resultados

FIGURA 4.6: Visualización en la aplicación web

FIGURA 4.7: Histórico del sensado de datos

FIGURA 4.8: Aplicación web responsive

29

Capítulo 5

Conclusiones

En este capítulo se detallan las conclusiones generales y los próximos pasos allevar a cabo en este proyecto.

5.1. Conclusiones generales

El prototipo permitió validar todas las etapas del sistema de monitoreo y se al-canzaron los siguientes logros:

Conocer más sobre los protocolos de comunicación entre dispositivos.

Adaptar la biblioteca de comunicación LoRa a una arquitectura de micro-controlador específica.

Profundizar en el desarrollo de sistemas embebidos con el uso de herra-mientas de software libre u open source.

Desarrollar una web que permita visualizar y alertar sobre posibles incen-dios forestales.

Aplicar los conocimientos adquiridos durante la carrera de especializaciónen sistemas embebidos.

5.2. Próximos pasos

Se propone realizar mejoras al proyecto, básicamente en los siguientes puntos:

Obtener mayor conocimiento sobre incendios forestales consultando a enti-dades especializadas en el país para mejorar las alertas de incendios.

Agregar funcionalidad de comunicación bidireccional de manera que pue-da ejecutarse tareas enviadas por el colector de datos.

Agregar donde se necesite, nodos de alta frecuencia de transmisión paramejorar el sensado de variables ambientales integrandolas a la red de mo-nitoreo.

Agregar funcionalidad al nodo para que pueda almacenar los datos de sen-sado en caso de perder comunicación con el gateway y pueda enviarloscuando recupere la comunicación.

31

Bibliografía

[1] Lundquist John, Camp Ann, Tyrrell Mary, Seybold S.J., CannonPhil, Lodge Deborah. Earth, wind and fire: Abiotic factors and the impacts ofglobal environmental change on forest health. 2011. URL:https://www.researchgate.net/publication/286345385_Earth_wind_and_fire_Abiotic_factors_and_the_impacts_of_global_environmental_change_on_forest_health (visitado 01-06-2018).

[2] Interxion. El imparable auge de las redes LPWAN amenaza a las redes móvilestradicionales. 2016. URL:http://www.interxion.com/es/blogs/2016/07/el-imparable-auge-de-las-redes-lpwan-amenaza-a-las-redes-moviles-tradicionales/.

[3] José de Jesús Návar Cháidez. Modelación del contenido de agua de los suelos ysu relación con los incendios forestales en la Sierra Madre Occidental de Durango,México. 2011. URL:http://www.scielo.org.mx/scielo.php?script=sci_arttext&pid=S1405-04712011000300005.

[4] Kais Mekki y col. A comparative study of LPWAN technologies for large-scaleIoT deployment. 2018. URL:https://www.sciencedirect.com/science/article/pii/S2405959517302953.

[5] Marcos Ramos Rodríguez y col. RELACIÓN ENTRE VARIABLESMETEOROLÓGICAS E INCENDIOS FORESTALES EN LA PROVINCIAPINAR DEL RÍO, CUBA. 2017. URL:https://www.researchgate.net/publication/320207076_RELACION_ENTRE_VARIABLES_METEOROLOGICAS_E_INCENDIOS_FORESTALES_EN_LA_PROVINCIA_PINAR_DEL_RIO_CUBA.

[6] Beecham Research. Low Power Wide Area Networks for IoT Applications MarketReport & Forecast. 2015. URL: http://www.beechamresearch.com/files/BR%20LPWAN%20EXEC%20Summary.pdf.

[7] Single Channel LoRaWAN Gateway. 2018. URL:https://github.com/tftelkamp/single_chan_pkt_fwd.

[8] The Things Network. 2018. URL: https://www.thethingsnetwork.org/.