Sistema ciber-físico en la nube para monitoreo de contaminación acústica urbana bajo plataforma IoT

Abstract

Palabras-clave: Contaminación acústica; Ciberfísico; IoT; LoRaWAN; AWS Abstract: The following paper presents the design of a cyber-physical acoustic monitoring system that can be implemented in the city of Lima and will have the function of warning users when noise reaches dangerous levels. [...]this paper presents the development of a prototype to check the connection between the physical and cyber systems and the correct reading of data from the selected sound sensor. Keywords: Noise pollution, Cyber-physical, IoT, LoRaWAN, AWS 1.Introducción Actualmente, la contaminación sonora urbana es uno de los principales problemas que afecta a la población de las grandes ciudades. LPWAN (Low Power Wide Area Networks): Este tipo de red nativa de IoT se ha popularizado bastante desde su lanzamiento por parte de la empresa SigFox en el 2012.

Headnote

Resumen: El presente trabajo expone el diseño de un sistema ciberfísico de monitoreo acústico que podrá ser implementado en la ciudad de Lima y tendrá la función de informar y advertir a los usuarios cuando los niveles de ruido puedan afectar a la salud de los peatones. El trabajo abarca el diseño del sistema físico que consta de Nodos Sensores y Gateways; el diseño de una arquitectura de software que permita la recolección, análisis y muestra de datos; asegurar la escalabilidad del sistema; y finalmente el desarrollo de un prototipo para comprobar la conexión entre los sistemas físico y ciber y la correcta lectura de datos del sensor de sonido seleccionado.

Palabras-clave: Contaminación acústica; Ciberfísico; IoT; LoRaWAN; AWS

Abstract: The following paper presents the design of a cyber-physical acoustic monitoring system that can be implemented in the city of Lima and will have the function of warning users when noise reaches dangerous levels. The work covers the design of the physical system, which consists of Sensor Nodes and Gateways. It also covers the design of a software architecture that allows the collection, analysis and sample of data to assure the scalability of the system. Finally, this paper presents the development of a prototype to check the connection between the physical and cyber systems and the correct reading of data from the selected sound sensor.

Keywords: Noise pollution, Cyber-physical, IoT, LoRaWAN, AWS

1.Introducción

Actualmente, la contaminación sonora urbana es uno de los principales problemas que afecta a la población de las grandes ciudades. Una prolongada exposición al ruido, dependiendo de su intensidad, puede producir vértigo, estrés, subida de presión, insomnio, pérdida parcial o total de la audición y dificultad para hablar (OEFA, 2016; Fielder & Zannin, 2015). Según el análisis de contaminación sonora llevado a cabo por (Albert & Decato, 2017) en zonas rurales y urbanas, los niveles de contaminación en zonas urbanas suelen ser 20 dB superior al de las zonas rurales. La gravedad de los daños a la salud aumenta mientras mayor sean los decibeles registrados; una persona realizando actividades rutinarias no debería estar expuesta a más de 70 decibles y se recomienda usar tapones u orejeras cuando se superan los 85 decibeles.

El estado peruano ha desarrollado procedimientos para el correcto sensado de los niveles acústicos de una zona. Sin embargo, estos trabajos requieren la presencia de trabajadores y el uso de equipos especiales que deben ser colocados de forma temporal en determinadas zonas de la ciudad. Estos estudios son realizados de forma poco frecuente por lo que a medida que haya pasado mayor tiempo entre un sensado y otro los resultados presentarán un mayor nivel de error (MINAM, 2013).

Como posible solución a este problema, en el presente trabajo se desarrollan los detalles más importantes del diseño e implementación de un prototipo de sistema de monitoreo IoT, que abarca tanto la parte física como la arquitectura ciber.

2.Marco Teórico

2.1.Medición del ruido

El ruido es una manifestación de las energías liberadas en distintas actividades que puede afectar el estado físico y mental de las personas, principalmente dañando su capacidad auditiva. Para medir un ruido se debe considerar principalmente su intensidad, la cual mide la cantidad de energía empleada para generarlo, esta se mide en decibelios (dB) y es la magnitud más importante en lo que se refiere a contaminación acústica. (Alonso, 2003).

Nivel de presión sonora (SPL): En la acústica, el nivel de presión sonora (también conocido como amplitud de onda), es la diferencia entre la presión mínima audible y la presión instantánea que generan las ondas sonoras, se expresa en decibelios (Ridao, 2009). El decibelio (dB) es la décima parte de un belio y es una unidad logarítmica, matemáticamente escalar y adimensional (Hidalgo, 2012). La siguiente ecuación muestra el cálculo del nivel de presión sonora:

Lp = 20 log(P/Po) dB, (1)

donde Lp es el nivel de presión sonora, P es la presión instantánea y P0 es la presión de referencia.

Esta medida es utilizada por los sonómetros para determinar los niveles de contaminación acústica ya que, a una distancia suficiente de la fuente de ruido, el cuadrado de esta medida es proporcional a la intensidad del sonido

Ponderación acústica: Si bien el oído humano tiene la capacidad de percibir sonidos entre 20 Hz y 20kHz, este no posee la misma sensibilidad para todo el rango de frecuencias. Debido a eso, considerando la sensibilidad en función de la frecuencia que capta el oído humano, se han establecido distintas curvas de ponderación. Las 3 principales curvas de ponderación que se utilizan para el análisis acústico son la A, B y C. Estas curvas tratan de replicar la respuesta del oído humano en frecuencia a distintos niveles de presión sonora, siendo la ponderación A la más baja y la ponderación C la más alta (Ridao, 2009).

2.2.Internet de las cosas (IoT)

Internet de las Cosas (IoT) consiste en la interrelación inteligente de personas, procesos, datos y objetos, lo que genera que las conexiones de red hallan ganado una gran inportancia y relevancia en estos tiempos. Esto se produce mediante la transformación de la información en procesos que crean mejores experiencias, nuevas funcionalidades y oportunidades económicas nunca antes vistas para personas, empresas y países (Cisco Website, 2020).

2.2.1. Tipos de redes IoT

Short Range Wireless Networks: Este tipo de comunicación de corto alcance requiere del despliegue de repetidores para hacerlos viables en estructuras actuales. Si bien han sido claves para el éxito inicial de IoT, su efectividad se ve bastante reducida cuando se realizan despliegues amplios de sensores. En esta categoría se encuentran tecnologías como ZigBee, Z-Wave, Bluethooth, Wifi, etc (IoT Factory, 2020; Cendón, 2017).

M2M (Machine to Machine): En la actualidad, cuando se requiere conocer la ubicación, el estado o directamente realizar interacción entre 2 dispositivos de forma global con cobertura geográfica nacional o incluso internacional la solución global es el uso de tarjetas Sim y redes GPRS/3G de operadores telefónicos locales. El problema con este tipo de red es su alto consumo energético, la necesidad de un pago mensual por suscripción y el alto costo de los equipos (IoT Factory, 2020).

LPWAN (Low Power Wide Area Networks): Este tipo de red nativa de IoT se ha popularizado bastante desde su lanzamiento por parte de la empresa SigFox en el 2012. Se caracteriza por su muy bajo consumo energético, su largo alcance y bajo costo de dispositivos. Actualmente existen 2 tecnologías que utilizan este sistema SigFox y LoRaWAN (IoT Factory, 2020; Cendón, 2017).

3.Diseño del sistema físico

3.1. Selección de red IoT

Para iniciar con el diseño del sistema se definió el tipo de red IoT a utilizar ya que cada una tiene características particulares que acotan el diseño de la solución final tanto en la parte física como en la ciber.

El sistema diseñado tiene las siguientes características:

* Los sensores deben ser capaces de operar en zonas donde no haya una red Wifi de internet.

* El rango de cobertura de la red debe ser amplio ya que se planea colocar los dispositivos en distintos puntos de la ciudad de Lima los cuales deben ser capaces de trasmitir la data a una misma base de datos.

* El consumo energético debe ser bajo ya que estos dispositivos estarán operando de manera continua.

* Los dispositivos deben ser de bajo costo ya que este sistema servirá de referencia a los departamentos estatales encargados del control de la contaminación acústica para que puedan realizar estudios especializados de forma más eficiente.

Basándonos en el análisis comparativo de las 3 principales redes IoT se ha optado por una red LPWAN (específicamente la tecnología LoRaWAN), ya que entre esta y SigFox solo Lora posee una cobertura que le permite ser utilizada en el Perú. Adicionalmente, un análisis realizado sobre redes de sensores LoRaWan demostró que este tipo de red logra cobertura hasta en zonas donde normalmente no llegan las redes 4G como lo son túneles o zonas donde las estructuras dificultan la llegada de estas redes (Wixted, Kinnaird, Larijani, Ahmadinia, & Strachan, 2016).

3.2. Topología LoRaWAN

LoRaWAN implementa una topología estrella-estrella, en la cual se utilizan varios Gateways para retransmitir los datos enviados por radiofrecuencia a un servidor principal por medio de internet. Los nodos de esta red no están conectados a un solo puerto, sino que la información enviada por un nodo es recibida por diferentes Gateways a la vez. Cada uno de estos Gateways reenviará la data desde el nodo hasta el servidor principal el cual normalmente estará en la nube.

La parte más compleja del proceso se ubica en el servidor de la red, ya que este se encarga de filtrar los elementos duplicados recibidos por varios Gateway, realizar funciones de seguridad, y la administración de la red (Perez, 2018). Cabe mencionar que para este proyecto se utilizara de servidor The Things Network (TTN), el cual es una red LoraWAN gratuita de código abierto.

3.3. Selección de componentes electrónicos

Tras un análisis comparativo de distintos hardware del mercado y tomando en cuenta características como consumo energético, costo, rendimiento y compatibilidad se seleccionaron los componentes mostrados en las tablas 1 y 2 con los que se espera conseguir una precisión de sensado de ruido de al menos + 5db.

3.3.1. Nodo Sensor

3.3.2. Gateway

3.4.Selección de componentes mecánicos

Para la selección de los componentes mecánicos mostrados en las tablas 3 y 4 se evaluaron las dimensiones y grados de protección (al menos IP65) que requieren los componentes electrónicos seleccionados para operar en la intemperie.

3.4.1. Nodo Sensor

3.4.2. Gateway

3.5. Diagramas de conexiones

En la figura 1 se muestran los diagramas de conexiones tanto del Gateway como del Nodo Sensor. Estos diagramas muestran detalladamente todas las conexiones del sistema. Sin embargo, para facilitar el montaje se han diseñado 2 PCBs que ya cuenten con la mayoría de las conexiones mostradas y solo se deberán conectar los componentes a través de conectores para PCB tipo hembra. En la figura 2 se muestran modelos 3D de la distribución de los componentes con las PCBs diseñadas.

3.6.Diagrama de flujo general

En la figura 3 se muestra el diagrama de flujo general del controlador del nodo sensor, en este se puede apreciar de forma resumida el proceso de verificación y obtención de datos para finalmente enviar solo la información necesaria al sistema ciber, minimizando el consumo de energía y el flujo de datos. No se verá un diagrama de flujo de los Gateway ya que serán considerados parte del sistema ciber. Estos siguen una programación preestablecida por el servidor TTN.

4.Diseño de arquitectura del sistema ciber

Para el diseño de la arquitectura se aplicó el método Attribute-Driven Design, el cual es un proceso iterativo de siete pasos para el diseño de arquitecturas de software (Kazman & Cervantes, 2015; Wojcik, Bachmann, Bass, Clements, Merson, Nord & Wood, 2006). En esta sección se muestra el diseño final tras el desarrollo del método.

4.1.Arquitectura propuesta

Tras el uso del método ADD para el desarrollo de arquitecturas de software se obtuvo el grafico de 6 capas mostrado en la figura 4, en este se utiliza AWS como servicio Cloud para recolectar, analizar y procesar la data obtenida del sistema.

Capa Input devices: representa el sistema fisco (Nodos Sensores como Gateways), donde toda la data obtenida de los sensores es recolectada por los Gateways y son enviadas al servidor TTN.

Capa Real - Time: Incluye el envío de la data recolectada en el servidor TTN hacia AWS IoT. Si es un nivel de presión sonora, se envía a la base de datos no relacional Dynamo DB para su análisis y muestra en tiempo real y también se envía a la capa Batch. Si la data fuese una alarma sobre algún tipo de falla con los sensores pasaría directamente a la capa de acción.

Capa Batch: En esta capa se almacenará en Amazon S3 toda la data de niveles de presión sonora recolectada por los sensores para un análisis más complejo.

Capa Ouput devices conections: Tiene 2 subgrupos: Bussines Integration que a través de AWS Lambda tomará acciones sobre la data recolectada y User Management donde Amazon Cognito controlará los tipos de accesos de los usuarios diferenciando el usuario común y el administrador

Capa Monitoring: En esta capa se encuentra el servicio de CloudWatch de Amazon el cual permite monitorear y administrar todos los servicios de la nube para tener un buen control del rendimiento del sistema.

5.Prototipo y pruebas del sistema

Las pruebas de alcance y funcionamiento del sistema estuvieron basadas en la elaboración de prototipos del Gateway y del Nodo Sensor. El Gateway como se ve en la figura 5a, está compuesto por un Raspberry Pi 3 Model B+ y en lugar del RAK2245 se utilizó un transceptor LoRa simple (el mismo utilizado en el nodo sensor). Este Gateway es de un solo canal lo cual limita bastante su capacidad de recibir información de múltiples nodos de manera simultánea, pero cumple su función como dispositivo de prueba.

El prototipo del nodo sensor, como que se ve en la figura 5b, solo cuenta con el sensor de sonido para la prueba del mismo, el transceptor LoRa y un pulsador que servirá para las pruebas de conexión del dispositivo por radiofrecuencia.

5.1.Programación del Gateway

Para la programación se utilizó de referencia la guía virtual elaborada por Chris Samuelson (Samuelson, 2017) y se editó para cumplir con las características requeridas por el sistema. En la figura 6, se aprecia el programa principal al cual se le configuraron los pines de la Raspberry Pi, ubicación, el servidor web y la frecuencia de transmisión y recepción. Luego de esto se registró el Gateway en el servidor TTN

5.2.Programación del Nodo Sensor

Antes de empezar la programación del Arduino se registró la aplicación que conecta los nodos a la red TTN, se le definió un ID y un servidor el cual es el mismo que nuestro Gateway. Una vez creada, se agregó un dispositivo al cual se le definió un ID y un EUI (código de 8 bytes que identificará el dispositivo). En el método de activación se seleccionó ABP (Activation by personalisation), con este método la data enviada por los sensores contendrá claves de identificación para poder ser recibidas por la red de forma segura.

Una vez completado el registro y habiendo copiado los códigos para el ABP se pasó a programar el Arduino y para ello se hizo uso de la librería "MCCI LoRaWAN LMIC". Esta librería es una adaptación para Arduino de la librería LMIC (LoRaWAN-MAC-in-C) de IBM la cual permite utilizar dispositivos LoRa y conectarlos a la red TTN. Para este prototipo se utilizó de base uno de los Sketch de ejemplo de esta librería, pero adaptado a las funciones de nuestro sistema. En la figura 7 se muestra el código que utiliza la comunicación por ABP, aquí se puede apreciar que es necesario colocar las 3 claves de acceso durante la configuración, esto permitirá que toda la información transmitida por el sensor sea recibida por la red y enviada a la aplicación creada para su uso.

5.3.Pruebas de conectividad del sistema

Con los prototipos armados se pasó a probar la conexión con la web; para esta primera prueba se simplificó el código para enviar el valor de 75.23 decibeles cada vez que se presione el pulsador en el prototipo del nodo sensor. En la figura 8 se ve que la data llega al servidor TTN, para esto el Nodo Sensor envió por radiofrecuencia la data, esta fue recibida por el Gateway y retransmitida por wifi hacia el servidor.

5.4.Pruebas del sensor de sonido

Para la prueba del sensor se utilizó un sonómetro con calibración vigente de la marca Hangzhou modelo AWA5661, este es un sonómetro clase 1 que cumple con la normativa internacional para sonómetros IEC61672 y es utilizado para mediciones de contaminación acústica industrial y urbana. Primero fue necesario calibrar el sensor del prototipo aplicando un factor al código de Arduino para que iguale su medición con la del sonómetro profesional.

El resultado de la calibración fue un factor de 2.87 para igualar ambas medidas a 8odB. Con este factor se hicieron las pruebas mostradas en la tabla 5 para mediciones de 65, 70, 75 y 85 dB con la finalidad comprobar si ambas medidas obtienen valores similares.

Como se aprecia en la tabla, la exactitud de la medición es + 2dB. Estos resultados son esperados ya que se utiliza un sensor de bajo costo el cual no posee la precisión para captar toda la gama de decibeles; además, el uso del factor de conversión genera que el error también se amplifique lo cual no permite medidas muy certeras. El error obtenido, sin embargo, cumple con las exigencias planteadas en el sistema y si bien no logra la precisión de un sonómetro profesional, permite identificar cuando hay presencia de contaminación sonora.

6.Conclusiones

Se logró diseñar un sistema de monitoreo de contaminación acústica urbana que funciona con radiofrecuencia y bajo una plataforma IoT. Este dispositivo utiliza la tecnología de radiofrecuencia LoRa, la cual sustituye la comunicación directa a internet comúnmente utilizada en este tipo de aplicaciones. Gracias a esto, se presenta una solución novedosa de bajo consumo energético y computacional capaz de cubrir grandes zonas de la ciudad y enviar la data a una plataforma Cloud sin necesidad de depender de redes WIFI, la cual podrá ser implementada con el objetivo de monitorear y controlar este tipo de contaminación de forma más eficaz.

Según los cálculos realizados y basándonos en los requerimientos y especificaciones técnicas planteadas, los dispositivos de monitoreo son capaces de funcionar de forma continua a pesar de cortes temporales de energía o condiciones climáticas desfavorables gracias a la batería de respaldo y los sensores de lluvia y corriente instalados. Además, la instalación y mantenimiento de los mismos es bastante sencilla gracias al uso de las PCBs, lo cual permite una rápida escalabilidad.

Se logró implementar un prototipo del sistema con el que se probó la conectividad entre dispositivos, la capacidad del nodo sensor para capturar y procesar datos de contaminación sonora y la transmisión de los mismos hacia un servidor Cloud. Además, se realizó una comparación de las mediciones con un sonómetro profesional y el prototipo donde, tras una calibración, se obtuvieron valores que, si bien no logran la precisión del primero, cumplen con los requerimientos del proyecto.

References

Referencias

Albert, D. G., & Decato, S. N. (2017). Acoustic and seismic ambient noise measurements in urban and rural areas. Applied Acoustics - Elsevier, 119, 135-143.

Alonso, A. d. (2003). Contaminación acústica y salud. Madrid, España: Observatorio medioambiental.

Cendón, B. (2017). Las Redes Más Usadas En El IoT. Retrieved from: http://www. bcendon.com/las-redes-mas-usadas-en-el-iot/

Cisco Website. (2020). Cisco internet of things. Retrieved from: https://www.dsco. com/c/en/us/solutions/internet-of-things/overview.html

Fielder, P. E., & Zannin, P. H. (2015). Evaluation of noise pollution in urban traffic hubs-Noise maps and measurements. Environmental Impact Assessment Review - Elsevier, 51, 1-9.

Hidalgo, A. (2012). ¿Qué es el decibelio acústico? Retrieved from: http://www.cecorsl. com/2012/11/16/que-es-el-decibelio-acustico/

IoT Factory. (2020). Overview of IOT Networks. Retrieved from: http://iotfactory.eu/ iot-knowledge-center/overview-of-iot-networks/

Kazman, R., & Cervantes, H. (2015). ADD 3.0: Rethinking Drivers and Decisions in the Design Process. SATURN. Retrieved from: https://resources.sei.cmu.edu/asset_ files/Presentation/2015_017_101_438648.pdf

MINAM. (2013). Protocolo Nacional de Monitoreo de Ruido Ambiental. Lima. Retrieved from: http://www.minam.gob.pe/disposiciones/resolucion-ministerial-227-2013minam/

OEFA. (2016). La contaminacion sonora en Lima y Callao. Lima: Oficina de Comunicaciones y Atención al Ciudadano.

Perez, E. (2018). Medium LoRaWAN. Retrieved from: https://medium.com/pruebasde-laboratorio-de-la-modulaci%C3%B3n-lora/lorawan-d00f48384160

Ridao, Á. F. (2009). Medidas De Ruido . Granada, España. Retrieved from: https://www.ugr.es/~ramosr/CAMINOS/conceptos_ruido.pdf

Samuelson, C. (2017). Hackster.io. Retrieved from: https://www.hackster.io/ ChrisSamuelson/lora-raspberry-pi-single-channel-gateway-cheap-d57d36

Wixted, A. J., Kinnaird, P., Larijani, H. T., Ahmadinia, A., & Strachan, N. (2016). Evaluation of LoRa and LoRaWAN for wireless sensor networks. IEEE Sensors, 1-13.

Wojcik, R., Bachmann, F., Bass, L., Clements, P., Merson, P., Nord, R., & Wood, B. (2006). Attribute-driven design (ADD), version 2.0. Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst.