sistema de gestión de edificios - laboratorios.fi.uba.ar

MAESTRÍA ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Sistema de gestión de edificios

Autor:Esp. Ing. Matías Alvarez

Director:Mg. Ing. Diego Brengi (INTI, UNLaM, FIUBA)

Jurados:Mg. Ing. Ramiro Alonso (FIUBA)

Mg. Ing. Leonardo Carducci (FIUBA)Mg. Ing. Nicolás Dassieu Blanchet (FIUBA)

Este trabajo fue realizado en la ciudad de La Plata,entre Enero de 2020 y Agosto de 2020.

III

Resumen

En la presente memoria se detalla la implementación de un prototipo de unsistema de manejo de edificios. El desarrollo, realizado para la empresa WeHaus

S.A., contempla las etapas de monitoreo, supervisión y control de distintasvariables y dispositivos, ejecución de reglas y envío de alertas asociadas.

Para asegurar la calidad del sistema, se realizaron etapas de elicitación yespecificación de requerimientos, de diseño de arquitectura e implementación y

de diseño y ejecución de casos de prueba para validar y verificar el correctofuncionamiento del mismo. Asimismo, se emplearon conceptos de sistemas

críticos, sistemas de tiempo real y distribuidos.

V

Agradecimientos

A mis padres, Noemí y Sergio, y a mi hermana, Milagros, que me han acompa-ñado durante estos últimos años, y en particular durante la realización de estetrabajo, por su comprensión, apoyo y cariño.

A mis compañeros y profesores de la Maestría en Sistemas Embebidos por com-partir sus conocimientos y por su acompañamiento a lo largo del año.

Al Mg. Ing. Diego Brengi, por su orientación, seguimiento, supervisión y aportesdurante la realización del presente trabajo.

A todos ellos, muchas gracias.

VII

Índice general

Resumen III

1. Introducción general 11.1. Internet de las cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Sistema de gestión de edificios . . . . . . . . . . . . . . . . . . . . . 21.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5. Alcances y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Introducción específica 72.1. Funcionamiento general del sistema . . . . . . . . . . . . . . . . . . 72.2. Protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1. Protocolo MQTT . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2. Protocolo AMQP . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3. Protocolo Modbus . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3. Infraestructura de servicios . . . . . . . . . . . . . . . . . . . . . . . 202.3.1. Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.2. Bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3. Diseño e implementación 293.1. Diseño general del sistema . . . . . . . . . . . . . . . . . . . . . . . . 293.2. Diseño e implementación de firmware . . . . . . . . . . . . . . . . . 343.3. Diseño e implementación de infraestructura de servicios . . . . . . 44

4. Ensayos y resultados 534.1. Banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2. Ensayos de caja blanca . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3. Ensayos de caja negra . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4. Ensayos de integración y sistema . . . . . . . . . . . . . . . . . . . . 60

5. Conclusiones 635.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2. Conocimientos aplicados . . . . . . . . . . . . . . . . . . . . . . . . . 635.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A. Documento de Elicitación de Requerimientos 67

Bibliografía 79

IX

Índice de figuras

1.1. Evolución del número de dispositivos IoT conectados en el mundo1. 21.2. Características de un sistema de gestión de edificios.2 . . . . . . . . 3

2.1. Diagrama de bloques del sistema. . . . . . . . . . . . . . . . . . . . . 82.2. Diagrama de secuencia del caso de uso 1 del sistema. . . . . . . . . 92.3. Diagrama de secuencia del caso de uso 2 del sistema. . . . . . . . . 102.4. Modelo de publicación y suscripción de MQTT. . . . . . . . . . . . 122.5. Capas del estándar OSI del protocolo MQTT. . . . . . . . . . . . . . 122.6. Flujo de conexión en MQTT. . . . . . . . . . . . . . . . . . . . . . . . 132.7. Ejemplo de tópicos MQTT y uso de wildcards.3 . . . . . . . . . . . . 142.8. Calidad de servicio 0 en MQTT. . . . . . . . . . . . . . . . . . . . . . 142.9. Calidad de servicio 1 en MQTT. . . . . . . . . . . . . . . . . . . . . . 152.10. Calidad de servicio 2 en MQTT. . . . . . . . . . . . . . . . . . . . . . 152.11. Entidades en el modelo AMQP. . . . . . . . . . . . . . . . . . . . . . 162.12. Capas del estándar OSI del protocolo Modbus. . . . . . . . . . . . . 172.13. Unidad de datos del protocolo(PDU). . . . . . . . . . . . . . . . . . 182.14. Unidad de datos del protocolo sobre bus serie. . . . . . . . . . . . . 182.15. Secuencia de bits con control de paridad en modo RTU. . . . . . . . 182.16. Trama de un mensaje Modbus en modo RTU. . . . . . . . . . . . . . 192.17. Secuencia de bits con control de paridad en modo ASCII. . . . . . . 192.18. Trama de un mensaje Modbus en modo ASCII. . . . . . . . . . . . . 202.19. Estándar RS-485 con topología basada en 2 cables.4 . . . . . . . . . 202.20. Arquitectura de Docker.5 . . . . . . . . . . . . . . . . . . . . . . . . . 222.21. Placa de desarrollo CIAA-NXP.4 . . . . . . . . . . . . . . . . . . . . 242.22. Placas de desarrollo utilizadas en el proyecto. . . . . . . . . . . . . . 242.23. Tareas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.24. Diagrama Activity on Node de la planificación del proyecto . . . . 28

3.1. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . 313.2. Modelado de componentes del sistema embebido. . . . . . . . . . . 313.3. Esquema de tópicos utilizados en MQTT. . . . . . . . . . . . . . . . 323.4. Modelado conceptual de la base de datos. . . . . . . . . . . . . . . . 333.5. Diagrama entidad relación de la base de datos. . . . . . . . . . . . . 343.6. Arquitectura en capas del firmware del nodo maestro. . . . . . . . . 363.7. Arquitectura en capas del firmware del nodo esclavo. . . . . . . . . 363.8. Estructura del patrón Hardware Proxy. . . . . . . . . . . . . . . . . . 373.9. Diagrama de arquitectura basada por eventos. . . . . . . . . . . . . 373.10. Conceptos de POO en el modelado de los sensores. . . . . . . . . . 393.11. Arquitectura específica del nodo maestro. . . . . . . . . . . . . . . . 423.12. Arquitectura específica del nodo esclavo. . . . . . . . . . . . . . . . 423.13. Configuración de usuarios de RabbitMQ. . . . . . . . . . . . . . . . 463.14. Configuración de las colas de RabbitMQ. . . . . . . . . . . . . . . . 463.15. Configuración de los exchanges de RabbitMQ. . . . . . . . . . . . . 47

X

3.16. Nodos de análisis de reportes de NodeRed. . . . . . . . . . . . . . . 493.17. Nodos de de pedidos de información de NodeRed. . . . . . . . . . 493.18. Nodos de ejecución de reglas de NodeRed. . . . . . . . . . . . . . . 493.19. Dashboard de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . 513.20. Dashboard de administración. . . . . . . . . . . . . . . . . . . . . . . 513.21. Ejemplo de alerta via mail del dashboard. . . . . . . . . . . . . . . . . 52

4.1. Banco de pruebas para ensayos del protocolo Modbus. . . . . . . . 534.2. Salida del analizador lógico. . . . . . . . . . . . . . . . . . . . . . . . 544.3. Banco de pruebas para ensayos de integración y sistema. . . . . . . 544.4. Ejemplo de casos de test del firmware del nodo maestro. . . . . . . 564.5. Ejemplo de casos de test del firmware de los nodos esclavos. . . . . 574.6. Ejemplo de casos de test de los servicios. . . . . . . . . . . . . . . . . 584.7. Resultado de caso de prueba en MQTTBox. . . . . . . . . . . . . . . 594.8. Resultado de caso de prueba de consulta a PostgresDB en NodeRed. 594.9. Resultados del caso de prueba de consulta a InfluxDB en Grafana. . 604.10. Clientes conectados a MQTT. . . . . . . . . . . . . . . . . . . . . . . 604.11. Estado del broker MQTT. . . . . . . . . . . . . . . . . . . . . . . . . . 614.12. Errores arrojados por el sistema ante consultas a nodos no conec-

tados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.13. Valores de los sensores y actuadores en Grafana. . . . . . . . . . . . 61

XI

Índice de Tablas

1.1. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Colores del diagrama AoN . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1. Cobertura de tests unitarios . . . . . . . . . . . . . . . . . . . . . . . 55

1

Capítulo 1

Introducción general

En este capítulo se realiza una introducción a la Internet de las cosas y a los sis-temas de gestión de edificios. Asimismo, se mencionan algunos sistemas en elmercado, y por último se explica la motivación, alcance y objetivos del presentetrabajo.

1.1. Internet de las cosas

Internet de las cosas es, a grandes rasgos, el nombre que se le da a un conjunto detecnologías que apuntan a dar conectividad a objetos cotidianos de las personas, yde esta forma extender su potencial. Si bien este concepto ha ganado popularidaden el último tiempo es una idea que viene en desarrollo desde hace más de 30años. Tiene como objetivo permitir tanto la comunicación e interacción de estosobjetos entre sí, como así también el monitoreo, supervisión y control de estos deforma remota, siendo este último punto el más trascendente para el proyecto quese detalla en la presente memoria.

La capacidad de conectar sistemas embebidos con capacidades limitadas de CPU,memoria, costo y energía significa que IoT puede tener aplicaciones en casi cual-quier área. Abarca desde dispositivos como lámparas, cerraduras y termostatosen el hogar, hasta maquinaria industrial y sistemas de riego para agricultura, pa-sando por vehículos autónomos, sistemas de iluminación y sensores en la víapública, o bombas, alarmas de incendio y ascensores en edificios modernos.

Los beneficios que Internet de las Cosas ofrece tanto a empresas como a personasindividuales son numerosos. Desde un punto de vista económico, permite a lasempresas gestionar y controlar mejor sus procesos de forma remota y en tiemporeal, aumentando su eficiencia y posibilitando la toma de mejores decisiones yacciones preventivas como el mantenimiento de la maquinaria o sistemas insta-lados. En definitiva, esto conlleva un ahorro de costos y tiempo para la organiza-ción. En el caso de individuos particulares, los beneficios se traducen en mejorasde su calidad de vida y comodidad en el día a día mediante automatizaciones ensu entorno cotidiano.

La importancia de la Internet de las Cosas en el mundo de las empresas y las per-sonas, queda reflejado en el crecimiento exponencial de dispositivos IoT conecta-dos en el mundo, como se visualiza en la figura 1.1. Para este año, se encuentraprevisto que cerca de 31 mil millones de dispositivos IoT se encuentren en fun-cionamiento en el mundo, cifra que se extiende hasta los más de 75 mil millonespara dentro de 5 años. Esto se traduce en un mercado que crece rápidamente y

2 Capítulo 1. Introducción general

que ya implica más de USD 212.000.000.000 [1] al año, lo cual supone una granoportunidad para cualquier empresa.

FIGURA 1.1. Evolución del número de dispositivos IoT conectadosen el mundo1.

1.2. Sistema de gestión de edificios

Dentro de las posibles aplicaciones de Internet de las cosas se encuentran los sis-temas de gestión de edificios o BMS (Building Management Systems), que son redesintegradas de datos y sistemas de hardware y software para automatización, mo-nitoreo y control de climatización, iluminación, energía, sistemas de seguridad yotras funciones de un edificio que aseguran que este funcione con el máximo ni-vel de eficiencia y que minimizan el mal uso de la energía y los costos asociados.Estos sistemas, que generalmente utilizan arquitecturas jerárquicas propietariascomo los protocolos C-bus o Profibus, o abiertas como Internet, KNX, DeviceNet,LonWorks, BACNet o Modbus, tienen las siguientes funcionalidades principales:

Proveer información y control sobre parámetros o variables del edificio quese encuentren bajo supervisión, incluyendo estado actual, históricos y even-tos.

Detectar y anunciar alarmas o condiciones de alerta.

Monitorear y reportar el estado de funciones y nodos del sistema en sí.

Ejecutar acciones sobre las variables del edificio bajo supervisión de formatemporizada o ante ocurrencia de eventos.

Integrarse con otros sistemas tanto de hardware como software del edificio.

Los sistemas BMS, suelen trabajar en conjunto con otros subsistemas, como porejemplo sistemas de control de acceso, circuitos cerrados de televisión, sistemasde señalización y estacionamiento, entre otros como se puede visualizar en la

1Imagen tomada de [2]

1.2. Sistema de gestión de edificios 3

figura 1.2. De esta forma, tanto parámetros como datos de estos sistemas, son vi-sualizados y controlados desde una computadora o dispositivo móvil, facilitandola alerta temprana de posibles problemas en el edificio.

Como en el caso de Internet de las cosas, el mercado de los sistemas de gestiónde edificios crece a paso constante, manejando un total de USD 11.000.000.000 enel año 2019 y una expectativa de crecimiento anual entorno al 15 %[3] para lospróximos años.

FIGURA 1.2. Características de un sistema de gestión de edificios.2

Aunque estos sistemas son altamente dependientes del lugar de aplicación, entérminos generales, el valor que aportan se puede dividir en tres grandes grupos,según quien sea el beneficiario:

Beneficios para inquilinos u ocupantes:

• Mayor control sobre el confort del edificio.

• Mayor seguridad del edificio.

• Aumento de la eficiencia del edificio y por lo tanto reducción de costosde alquiler.

Beneficios para propietarios y administradores:

• Valorización del inmueble.

• Control y supervisión local o remoto del edificio.

• Monitoreo de los servicios del edificio de forma remota.

• Disposición de reportes o históricos.

Beneficios para personal de mantenimiento:

• Mayor disponibilidad de documentación y/o información de los equi-pos instalados.

2Imagen tomada de: Building Management Systems

https://www.deccontract.com.my/building-management-system/


• Mayor productividad en el uso del personal de mantenimiento.

• Detección temprana de problemas.

1.3. Estado del arte

En la actualidad existe una amplia variedad de sistemas ofrecidos por empresasmultinacionales como ABB, Schneider Electric o Honeywell, que se encuentranmás enmarcados dentro de los sistemas de automatización y control de edificios,o BACS (Building Automation and Control Systems) por sus siglas en inglés. Estossistemas, si bien presentan facilidad a la hora de agregar nuevos dispositivos a lared ya preexistente, suelen enfocarse en algunas de las variables a supervisar enel edificio, como HVAC (Heating, Ventilating and Air Conditioning) o iluminación,teniendo que soportar el protocolo que propone el fabricante. Más allá de esto,estos sistemas fueron tenidos en cuenta para la toma de decisiones entorno aldesarrollo del proyecto, y por ello se resumen algunas características de estos enla tabla 1.1.

TABLA 1.1. Comparación de equipos en el mercado.

Sistema Fabricante Conectividad Interfaz Monitoreo yConfiguración

BAC/S1.5.1 ABB KNX Display WebServerACX 5720 Schneider BACNet No aplica Software

Electric propietarioCiper Model 10 Honeywell BACNet No aplica WebServer

En cuanto a plataformas que ofrecen la etapa de procesamiento, análisis y vi-sualización de datos, se pueden mencionar algunas como ThingBoard, Ubidots,Amazon Web Services, Google Cloud Platform o Microsoft Azure. Estas plata-formas asumen que el cliente cuenta con el hardware necesario para enviarles lainformación relevante, y ellas se encargan de analizarla y presentarla de maneraconveniente mediante tableros o dashboards, que le permiten al usuario ver el es-tado e históricos de sensores, actuadores y nodos. Las principales desventajas deestas plataformas son la fuerte dependencia que generan y la poca adaptabilidadal sistema que uno diseña.

1.4. Motivación

En Argentina, la instalación de sistemas de gestión de edificios comenzó a crecerdesde los 2000[4], con la instalación de sistemas simples y ya con el auge de lacertificación LEED [5] para edificios sustentables, este crecimiento se afianzó.

Si bien existe una gran oferta de este tipos de sistemas, como se mencionó en lasección 1.3, estos son todos importados, lo que conlleva un costo mayor. En ge-neral, solo integran dispositivos que utilicen el protocolo del fabricante, sin men-cionar, que solo suelen ser instalados en edificios en plena construcción donde su

1.5. Alcances y objetivos 5

uso fue proyectado desde el inicio. Esto deja fuera del mercado a aquellos edifi-cios en los que no se planificó, en primera instancia, la instalación y uso de estetipo de sistemas.

Teniendo en cuenta lo mencionado en la sección 1.2, sobre el tamaño del mercadode los sistemas de gestión de edificios y su crecimiento anual esperado, suma-do a lo expuesto en el párrafo anterior y en la sección 1.3 sobre el estado de lossistemas actuales, es que nace la idea de realizar un sistema de monitoreo, su-pervisión y control de distintas variables en edificios, con un esquema jerárquico,que promueva el uso de hardware nacional y que permita la instalación del sis-tema no solo en edificios en construcción, sino también en aquellos que lleven yatiempo en funcionamiento. Se buscó lograr dicho objetivo, al no solo proveer elnodo maestro de monitoreo y control sino también nodos esclavos que permitanla extensión del sistema incluyendo nuevos sensores, actuadores y dispositivosen general, que utilicen distintos protocolos.

En particular, interesó poder monitorear el estado de bombas, alarmas de incen-dio, de ascensores, detección de CO en estacionamientos, altura de columnas deagua en tanques, temperatura, humedad y calidad de aire, presencia de perso-nas en espacios comunes, características de la red eléctrica y grupos electrógenos,presión diferencial en escaleras y controlar la ventilación e iluminación del edi-ficio. Se buscó implementar una interfaz que permitiera visualizar informaciónrelevante sobre el sistema bajo control y permitiera la ejecución de reglas en elencendido del sistema de iluminación o ventilación, como asimismo la configu-ración de ciertos parámetros del sistema. Adicionalmente, se buscó poder alertara los usuarios del sistema, en particular al personal de mantenimiento y/o ad-ministración del edificio, sobre los eventos ocurridos en él. Por otra parte, resultade interés, almacenar información sobre el estado y funcionamiento propio delsistema instalado, para la detección y rastreo de problemas.

Debido a que los sistemas de gestión de edificios mencionados no suelen pre-sentar monitoreo remoto, es que se opta por desarrollar una infraestructura deservicios propia para dar soporte a lo mencionado en el párrafo anterior.

Por otra parte, el desarrollo de este sistema sirve como punto de partida parael desarrollo de un sistema más completo, que incluya el acceso a cámaras decircuito cerrado de televisión y equipos de control de acceso.

Por último, el proyecto busca visibilizar las plataformas de hardware abiertas,y por lo tanto el firmware del nodo maestro fue desarrollado sobre una de lasplataformas del Proyecto CIAA(Computadora Industrial Abierta Argentina), es-pecíficamente la versión CIAA-NXP.

1.5. Alcances y objetivos

1.5.1. Objetivos

El propósito de este proyecto es desarrollar un prototipo operativo de un sistemade control, monitoreo y supervisión de ciertas funciones y/o parámetros de los


edificios, con la capacidad de visualizar la información de interés en una compu-tadora o aplicación celular, ejecutar reglas y enviar alertas a los usuarios del sis-tema. Este desarrollo permitirá maximizar la eficiencia del edificio, al reducir elconsumo de energía y mejorar las condiciones de vida de quienes habitan en él.

1.5.2. Alcance

Para la realización de este trabajo se realizará un primer prototipo operativo de unsistema de gestión de edificios más enfocado en la programación de un sistemaembebido distribuido a través de una red Modbus [6] comandado remotamentemediante MQTT [7]. El presente proyecto incluye los siguientes aspectos:

Modelado del sistema

Adquisición de datos de una serie de sensores en cada nodo de la red.

Implementación de Modbus RTU en cada nodo esclavo de la red.

Implementación de Modbus RTU en el maestro de la red.

Transmisión de los datos al concentrador/maestro mediante Modbus RTU.

Transmisión de los datos desde el maestro por MQTT hacia algún servidoro broker.

Visualización de los datos adquiridos y parámetros de configuración en unaaplicación web.

Ejecución de reglas de forma local y remota.

Aplicación de algunos conceptos de sistemas críticos en el desarrollo de losesclavos y el maestro.

Realización de tests y documentación detallados.

En primera instancia se incluía la realización de PCB/s de prototipado para prue-bas, pero debido a la extensión del proyecto, la falta de ayuda económica para eldesarrollo de las mismas por parte de la empresa, se optó por dejar para unasegunda etapa.

7

Capítulo 2

Introducción específica

En el presente capítulo se explica el funcionamiento general del sistema imple-mentado y se brinda una introducción a diferentes tecnologías utilizadas en elproyecto. Se presentan además los requerimientos y la planificación del mismo.

2.1. Funcionamiento general del sistema

Como se mencionó en la sección 1.5.1, el propósito del presente proyecto es eldesarrollo de un prototipo operativo de un sistema de gestión de edificios.

Para que esto sea posible, se optó por el diseño de un sistema distribuido con losdistintos módulos diseñados e implementados que se observan en la figura 2.1,donde se presenta un diagrama en bloques.

El sistema consta de tres grandes bloques:

Nodo maestro: es el encargado de procesar comandos recibidos por MQTTy responder con la información que se haya consultado. En caso de requeririnformación de algún nodo, comanda dicha acción por Modbus. Asimis-mo recolecta información de un conjunto de sensores y comanda distintosactuadores y dispositivos.

Nodos esclavos: son los encargados de recolectar información de sensoresdel edificio, como también de comandar distintos actuadores y dispositivos.Reciben pedidos de lectura o escritura mediante el bus Modbus y envíanuna respuesta cuando corresponde.

Infraestructura de servicios: es el conjunto de servicios que da soporte a lacomunicación con el nodo maestro, reglas, alertas, almacenamiento, confi-guración e interfaz de visualización.

Un sistema distribuido, como el mencionado en la figura 2.1, es un sistema en elque los componentes de hardware o software se encuentran en dispositivos uni-dos mediante una red y se comunican únicamente mediante el paso de mensajes.Entre sus principales características se encuentran:

Ejecución concurrente.

Inexistencia de un reloj global y por lo tanto necesidad de coordinación y/osincronización.

Fallos independientes, es decir que si uno de los nodos del sistema falla noproduce la caída total del mismo.

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

FIGURA 2.1. Diagrama de bloques del sistema.

Por otro lado sus ventajas más sobresalientes son:

Sencillez en el intercambio de información al estar los nodos conectados enred.

Facilidad en el añadido de nuevos nodos al sistema, es decir su escalabili-dad.

La independencia en el fallo de los componentes minimiza el fallo de todoel sistema generalizado.

Con el fin de ilustrar el funcionamiento del sistema, se plantean dos casos de usotípicos: en primer lugar, la obtención de un cierto valor de algún sensor y poste-rior alerta al usuario, y en el segundo caso, la ejecución de una regla temporizada.Ambos casos de uso son propuestos en forma de diagrama de secuencia, como sevisualiza en las figuras 2.2 y 2.3.

En el primero de los casos, la secuencia comienza con el sistema de visualizacióny reglas enviando un mensaje de lectura del valor actual de un sensor de un nodoesclavo al nodo maestro. Este procesa el mensaje y determina la acción a ejecu-tar. Luego, envía la lectura del registro pertinente al esclavo indicado. Mientras,el esclavo que ejecuta una lectura cada cierto tiempo de los sensores que tieneconectado, recibe la lectura, obtiene el último valor leído y lo envía como una res-puesta al maestro. Este arma un mensaje a enviar al sistema de visualización yreglas, a partir de la respuesta del esclavo. Por último, en el sistema de visualiza-ción y reglas se almacena el valor en la base de datos, se compara dicho valor yen caso de superar el umbral indicado por el usuario, se envía un mail de alerta.

2.1. Funcionamiento general del sistema 9

FIGURA 2.2. Diagrama de secuencia del caso de uso 1 del sistema.

En el caso de uso 2, la secuencia comienza con el sistema de visualización y re-glas comparando que se haya cumplido el horario en que la regla debe ejecutarsey enviando un mensaje al nodo maestro que indica el comando de un actuador deun nodo esclavo. Nuevamente, el nodo maestro procesa el mensaje y determinala acción a ejecutar, que en este caso es una escritura de un valor en un actuadorde un esclavo. Paso siguiente, envía la escritura del registro pertinente al esclavoindicado, este lo recibe y ejecuta la acción. Luego, envía una lectura al actuadorpara confirmar que el comando del actuador fue ejecutado y envía una respues-ta al nodo maestro. Este arma un mensaje a enviar al sistema de visualización yreglas, a partir de la respuesta del esclavo. Por último, en el sistema de visualiza-ción y reglas se almacena el cambio de estado del actuador en la base de datos yse muestra el cambio al usuario.


FIGURA 2.3. Diagrama de secuencia del caso de uso 2 del sistema.

En ambos casos, ante la ocurrencia de errores, estos son enviados a la interfaz devisualización y reglas, que presenta los mismos en otro dashboard solo accesiblepor el administrador del sistema.

2.2. Protocolos de comunicación

Si bien en la actualidad existen múltiples tecnologías inalámbricas aplicables endispositivos de Internet de las Cosas, en el caso de los BMS, por su lugar de apli-cación, no terminan siendo la mejor opción.

En el caso del sistema mencionado en la sección 2.1, existen dos interfaces decomunicación, una entre el nodo maestro y el servidor, que puede ser local oremoto al edificio, y otra entre los nodos maestros y esclavos.

En el primer caso, la tecnología cableada más ampliamente difundida para re-des de área local, o LAN(Local Area Network), es Ethernet. El protocolo define lascaracterísticas de cableado y señalización de nivel físico, y los formatos de lastramas de datos en la capa de enlace de datos del estándar OSI(Open System Inter-connection). Sus características principales en el ámbito de aplicación de los BMSson:

Velocidades de entre 100 Mbit/s y 1000 Mbit/s a una distancia máxima de1000m.

Estabilidad de la señal.

Flexibilidad y seguridad.

2.2. Protocolos de comunicación 11

En el caso de la comunicación con un servidor remoto, se requiere tener accesoa Internet y por lo tanto es necesario conectarse también con un módem, que asu vez debe estar conectado a un proveedor de servicios de Internet (ISP, por sussiglas en inglés correspondientes a Internet Service Provider).

Necesariamente para poder conectarse a Internet, el nodo maestro debe imple-mentar el protocolo TCP/IP o UDP/IP, que determinan las características de lascapas de transporte y red del estándar OSI[8], respectivamente. La capa de apli-cación, ubicada en la parte superior del modelo, es la encargada de ofrecer a lasaplicaciones de usuario la posibilidad de comunicarse con otros dispositivos através de los servicios brindados por las demás capas. Entre los protocolos deaplicación, existen múltiples como HTTP, CoAP, DDS, STOMP, MQTT y AMQP,siendo estos dos últimos los utilizados en el sistema.

Ambos protocolos se basan en un modelo de publicaciones y suscripciones, enel que un cliente publica mensajes en un tema o tópico, y todos aquellos nodosque se encuentran suscriptos a ese tema reciben el mensaje publicado. MQTT esideal para aplicaciones de IoT, debido principalmente a que requiere un muy ba-jo ancho de banda, tiene un menor consumo de potencia que otras alternativas,y además es sencillo y ligero de implementar. Por otro lado, AMQP, mejora lafiabilidad y la interoperabilidad y extiende el concepto de publicaciones y sus-cripciones mediante el uso de colas, cubriendo escenarios mucho más complejosy amplios que MQTT, pero como contrapartida su implementación resulta másdifícil. En la sección 2.2.1, se explica con mejor detalle el funcionamiento de am-bos protocolos.

Para el caso de la interfaz de comunicación entre los nodos del sistema, tambiénexisten múltiples tecnologías, en este caso alámbricas, que son actualmente usa-das en sistemas BMS, como se mencionó en las secciones 1.2 y 1.3. Entre estas, sedestacan KNX, DeviceNet, LonWorks, BACNet y Modbus. En esta implementa-ción se optó por el uso de Modbus, por sus características más destacadas:

Tiene buena inmunidad al ruido.

Es un protocolo open source y gratuito.

Es fácil de implementar.

Requiere pocos recursos.

Modbus es un protocolo desarrollado por la empresa Modicon para uso industrialque permite la comunicación entre dispositivos de automatización. En la sección2.2.3, se detalla su funcionamiento.

2.2.1. Protocolo MQTT

MQTT o Message Queue Telemetry Transport, es un protocolo de transporte livianode mensajes basado en un modelo de publicaciones y suscripciones, como se ilus-tra en la figura 2.4. El protocolo MQTT funciona sobre TCP/IP o sobre otros pro-tocolos de red con soporte bidireccional y sin pérdidas de datos como se visualizaen la figura 2.5.


FIGURA 2.4. Modelo de publicación y suscripción de MQTT.

FIGURA 2.5. Capas del estándar OSI del protocolo MQTT.

En modelos del tipo publicación y suscripción, un dispositivo puede publicar unmensaje en un tema o tópico y/o suscribirse a un tópico particular para la recep-ción de mensajes. A diferencia de un modelo cliente/servidor típico, en dondeambas partes se comunican directamente, en este esquema se desacopla tanto elcliente que envía un mensaje, como él o los clientes que están suscriptos a dichotópico y reciben ese mensaje. La conexión entre ambas partes es manejada por unatercera parte llamada broker MQTT. El broker MQTT es el responsable de recibirtodos los mensajes, filtrarlos y distribuirlos según corresponda, es decir determi-nar qué cliente está suscripto a cada tópico y enviar los mensajes publicados enellos a estos suscriptores.


La conexión en MQTT es siempre entre un cliente y el broker, como se ilustra enla figura 2.6, es decir que los clientes nunca se conectan entre ellos directamente.Para iniciar una conexión, el cliente envía un mensaje CONNECT al broker y esteresponde con un mensaje CONNACK y un código de estado. Una vez que la co-nexión queda establecida, el broker la mantiene abierta hasta que el cliente envíaun comando de desconexión o la conexión se pierde por el motivo que sea. Lospuertos estándar son 1883 para comunicación no encriptada y 8883 para comuni-cación encriptada usando SSL/TLS.

Durante el handshake SSL/TLS, el cliente valida el certificado del servidor paraautenticarlo. El cliente puede también proveer un certificado al broker durante elhandshake, que el broker utilizará para autenticar al cliente. Si bien no es parte dela especificación, se ha vuelto habitual que los brokers admitan la autenticación declientes con certificados SSL/TLS. Debido a que el protocolo MQTT apunta a serun protocolo para dispositivos de IoT con recursos limitados, SSL/TLS puede noser siempre una opción y, en algunos casos, puede que no sea deseable. En talescasos, la autenticación se presenta como un nombre de usuario y una contraseñade texto simple que el cliente envía al servidor como parte de la secuencia depaquetes CONNECT/CONNACK. Algunos brokers aceptan clientes anónimos ypor lo tanto en estos casos, el nombre de usuario y la contraseña se dejan enblanco. En el caso del presente trabajo, se optó para una primer etapa utilizarautenticación mediante nombre de usuario y contraseña.

FIGURA 2.6. Flujo de conexión en MQTT.

Los mensajes son la información que se quiere intercambiar entre los dispositivos,ya sean comandos o datos. En MQTT la palabra tópico refiere a una cadena de ca-racteres que el broker utiliza para filtrar mensajes para cada cliente conectado. Lostópicos consisten en uno o más niveles. Cada nivel de tópico está separado poruna barra. Existen algunos caracteres reservados que son utilizados como como-dines o wildcards que permiten la suscripción a múltiples tópicos, como el carácter’+’ y el carácter ’#’, que representan el wildcard de nivel único y de nivel múltiple,respectivamente. En cualquier caso, no es necesario que los clientes creen previa-mente el tópico antes de publicar o suscribirse a él. El broker acepta cada tópicoválido sin previa inicialización.


Ejemplos de tópicos y uso de los wildcards son provistos en la figura 2.7:

FIGURA 2.7. Ejemplo de tópicos MQTT y uso de wildcards.1

El último concepto importante dentro de MQTT, es la calidad de servicio o QoS(Quality of Service), que hace referencia a un acuerdo entre quien envía un mensajey quien es receptor del mismo, que define la garantía de entrega para un mensajeespecífico. Aunque los niveles más altos de QoS son más confiables, tienen mayorlatencia y ancho de banda, por lo que los clientes suscritos pueden especificar elnivel más alto de QoS que les gustaría recibir.

El mínimo nivel de QoS es cero. En esta calidad de servicio no hay garantía deentrega, como se ilustra en la figura 2.8. El que recibe no acusa recibo del mensajey este no se guarda ni es retransmitido.

FIGURA 2.8. Calidad de servicio 0 en MQTT.

El nivel 1 de QoS garantiza que un mensaje se entrega al menos una vez al re-ceptor. En la figura 2.9 se muestra como el broker almacena el mensaje hasta querecibe un paquete PUBACK del receptor que acusa recibo del mensaje. Es posibleque un mensaje se envíe o entregue varias veces.

1Imagen tomada y modificada de [9]



El nivel más alto de calidad de servicio es el nivel 2, que si bien es más segu-ro, también es más lento. La garantía es proporcionada por al menos dos flujosde solicitud/respuesta entre el broker y el receptor. Estos utilizan el identificadorde paquete del mensaje publicado originalmente para coordinar la entrega delmensaje, como se visualiza en la figura 2.10.


En el caso del presente proyecto, se utilizó el nivel de calidad de servicio 0.

Por último, cabe remarcar que para la implementación del stack TCP/IP y elprotocolo MQTT, con las características mencionadas, se utilizó la librería lwip(lightweight IP)[10], que es una implementación pequeña en tamaño del protocoloTCP/IP para sistemas embebidos que también incluye los protocolos de la capade aplicación MQTT, HTTP, entre otros.

2.2.2. Protocolo AMQP

AMQP o Advanced Message Queuing Protocol[11], es un protocolo de estándar abier-to de la capa de aplicaciones de un sistema de comunicación y al igual que MQTTfunciona sobre TCP/IP. Las características que definen al protocolo AMQP son laorientación a mensajes, encolamiento, enrutamiento, tanto punto a punto comopublicación/suscripción, exactitud y seguridad. El protocolo AMQP resuelve va-rios problemas al mismo tiempo, por un lado, el protocolo, en colaboración conun broker de mensajería, se encarga de una transmisión sólida de datos. Por otro,AMQP permite almacenar mensajes en una cola, lo que, a su vez, permite unacomunicación asíncrona, es decir transmisor y receptor no deben actuar al mismoritmo. El receptor del mensaje no tiene por qué aceptar, procesar la informacióndirectamente y confirmar la recepción al emisor, luego de que este la envía. En sulugar, recuperará el mensaje de la cola cuando tenga capacidad disponible paraello. Esto ofrece al productor, entre otras cosas, la posibilidad de seguir trabajan-do, evitando tiempos de inactividad. Asimismo, evita que los receptores pierdanmensajes por no estar disponibles al momento de la transmisión. En la figura 2.11se ilustra el funcionamiento del protocolo AMQP.


AMQP define una serie de entidades, siendo las siguientes las más relevantes:

El broker de mensajería: es quien distribuye el mensaje de acuerdo con reglasdefinidas en diferentes colas.

Usuario: es una entidad que, mediante la presentación de credenciales talescomo nombre de usuario y contraseña, puede ser autorizado a conectarse aun broker. Puede ser un consumidor o productor de mensajes.

Conexión: es una conexión física usando, por ejemplo, TCP/IP, que se en-cuentra ligada a cada usuario particular.

Canal: se trata de una conexión lógica unida a una entidad conexión. Asípues, la comunicación a través de un canal posee un estado y aquellos clien-tes que realicen operaciones concurrentes mediante una misma conexióndeben mantener un canal distinto para cada una de ellas.

FIGURA 2.11. Entidades en el modelo AMQP.

Otros conceptos importantes dentro de AMQP son:

Intercambiadores: los exchanges, por su nombre en inglés, son las entidadesa las que se envían los mensajes. Tienen nombre, tipo y una serie de pro-piedades que indican si el intercambiador es pasivo, perdurable o permiteautoborrado.

Colas: son las entidades que reciben y almacenan mensajes. Tienen nombrey propiedades pero no tienen tipo. Los clientes pueden suscribirse a las co-las, pudiendo recibir los mensajes que en ellas se guarden. La cola garantizaque los mensajes son entregados en el mismo orden en que llegaron.

Mensajes: estos no tienen nombre y son publicados en un intercambiador.Consisten en un encabezamiento y un cuerpo de contenido. Mientras queel cuerpo contiene datos opacos, el encabezamiento contiene una serie depropiedades que son opcionales.

Vinculación: un binding, por su nombre en inglés, es una relación entre unacola y un intercambiador que especifica cómo fluyen los mensajes desde elintercambiador a la cola. Algunas vinculaciones podrían utilizar una clavede enrutamiento opcional, para determinar la forma en que los mensajespasan a la cola, es decir actúa como un filtro.


A diferencia de MQTT, los niveles en los tópicos se separan con puntos y no conbarras. Asimismo el carácter del wildcard de único nivel es el ’*’ y no el ’+’.

2.2.3. Protocolo Modbus

El protocolo Modbus, como ya se ha mencionado, es un protocolo del tipo maes-tro esclavo de las capas 1, 2 y 7 del estándar OSI, como se muestra en la figura2.12.

FIGURA 2.12. Capas del estándar OSI del protocolo Modbus.

En una red Modbus, puede haber un maestro y hasta 247 esclavos conectados ensimultáneo al mismo bus. La comunicación es siempre iniciada por el maestro y,por lo tanto, los esclavos nunca transmitirán datos sin una solicitud previa. Lassolicitudes desde el nodo maestro a los esclavos pueden ser realizados de dosmodos:

Modo unicast: en este modo, el maestro direcciona a un único esclavo, queluego de recibir y procesar la solicitud, envía una respuesta al maestro. Esdecir, que en este modo, cada transacción consta de dos mensajes, una so-licitud del maestro y la correspondiente respuesta del esclavo. Para poderdireccionar de forma unívoca a un esclavo, este debe poseer una direcciónque puede tomar valores entre 1 y 247.

Modo broadcast: en este modo, en cambio, el maestro envía una solicitud atodos los esclavos de forma simultánea, sin recibir respuesta. Este tipo desolicitudes son necesariamente de escritura y deber ser aceptadas por todoslos esclavos. La dirección 0 se reserva para identificar intercambios en modobroadcast.


El protocolo Modbus define una unidad de datos de protocolo(PDU) muy simple,que es independiente de las capas de comunicaciones subyacentes y su forma esla que se visualiza en la figura 2.13.

FIGURA 2.13. Unidad de datos del protocolo(PDU).

A esta unidad de datos básica se le adicionan una serie de campos específicos delbus de comunicaciones utilizado, que en el caso del presente proyecto es un busserie. La unidad de protocolos de datos definida para este caso se ilustra en lafigura 2.14.

FIGURA 2.14. Unidad de datos del protocolo sobre bus serie.

El campo dirección contiene siempre la dirección del esclavo, tanto en la solici-tud enviada por el maestro, como en la respuesta del mismo esclavo. El campocódigo de función indica el tipo de acción a realizar. El campo data, que no siem-pre aparece, contiene los parámetros necesarios de la solicitud o respuesta. Porúltimo, el campo CRC o LRC, es una verificación por redundancia cíclica (CRC)o longitudinal (LRC), que se utiliza según si el modo de transmisión es RTU oASCII (American Standard Code for Information Interchange), respectivamente.

El protocolo Modbus tiene dos modos de transmisión serie que determinan cómose empaqueta y decodifica la información. Es importante destacar que todos losdispositivos dentro del mismo bus de comunicación deben estar configurados enel mismo modo y con los mismos parámetros.

Todo los dispositivos que utilicen el protocolo Modbus deben tener obligatoria-mente implementado el modo RTU (Remote Terminal Unit). Al comunicarse porel bus, utilizando este modo, cada byte transmitido, debe estar conformado pordos caracteres hexadecimales, de este modo se consigue una mayor densidad decaracteres para una misma velocidad de transmisión, que con el modo ASCII. Seutiliza un formato de 11 bits transmitidos por cada byte de data, como se muestraen la figura 2.15.

FIGURA 2.15. Secuencia de bits con control de paridad en modoRTU.


La trama posee un bit de inicio, 8 bits de datos, donde el menos significativo seenvía primero, un bit de control de paridad, que puede ser impar (por defecto),par o sin paridad y un bit de parada, que en el caso de utilizarse sin control deparidad se convierten en 2 bits de parada.

El mensaje Modbus es colocado por el transmisor dentro de una trama con inicioy fin conocidos, como la que se visualiza en la figura 2.16, para permitir al re-ceptor saber cuándo un mensaje está completo. Los mensajes parciales deben serdetectados y como consecuencia devolver un error como respuesta. En el modoRTU, las tramas están separadas por un intervalo de silencio de al menos 3,5 vecesel tiempo de un carácter. La trama completa debe ser transmitida como un flujoconstante de caracteres. Si se produce un silencio de al menos 1,5 veces el tiempode un carácter entre caracteres consecutivos, el mensaje se considera incompletoy debe descartarse.

FIGURA 2.16. Trama de un mensaje Modbus en modo RTU.

En el modo de transmisión ASCII, cada byte de un mensaje se envía como doscaracteres ASCII. Este modo se utiliza, generalmente, cuando las capacidades deldispositivo no le permiten cumplir con los requerimientos de temporización im-puestos por el modo RTU. En este caso, a diferencia del anterior, se utiliza unformato de 10 bits por cada bytes de datos transmitido, como se ilustra en la figu-ra 2.17.

FIGURA 2.17. Secuencia de bits con control de paridad en modoASCII.

La trama posee un bit de inicio, 7 bits de datos, donde el menos significativo seenvía primero, un bit de control de paridad, que puede ser impar (por defecto),par o sin paridad y un bit de parada, que en el caso de utilizarse sin control deparidad se convierten en 2 bits de parada.

Al igual que en el modo RTU, la trama debe tener un inicio y fin definidos, comola que se visualiza en la figura 2.18, para permitir al receptor saber cuándo unmensaje está completo. Los mensajes parciales deben ser detectados y debe serdevuelto un error como resultado. En modo ASCII, se delimita el inicio de tramacon el carácter “:” y el fin de trama con CRLF (carriage return – line feed). Un tiempomayor a un segundo entre caracteres podría indicar un error, pero el protocoloespecifica que este tiempo es configurable.


FIGURA 2.18. Trama de un mensaje Modbus en modo ASCII.

La guía de especificaciones[6] recomienda la utilización del estándar RS-485 contopología de 2 cables para la implementación de Modbus sobre bus serie, comose ilustra en la figura 2.19. Todos los dispositivos se conectan al mismo par decables, lo que implica que no puede haber dos o más dispositivos haciendo usodel bus de comunicaciones en simultáneo. Se recomienda, asimismo, el uso deresistencias de terminación, para minimizar las reflexiones que se producen.

FIGURA 2.19. Estándar RS-485 con topología basada en 2 cables.2

2.3. Infraestructura de servicios

Para la implementación de la infraestructura del servidor remoto, existen tresgrandes modelos:

Modelo de nube propia: en este caso, tanto hardware como software sonprovistos por quien desarrolla el sistema, aunque en algunos casos, se pue-den utilizar servicios de hosting de terceros que no agreguen ningún va-lor más allá del hosting mismo. En este tipo de modelo, todos los recursosdel sistema, funcionalidades y esquemas de escalabilidad son gestionadospor el desarrollador, lo que permite un mejor control sobre los aspectos dehardware y software, una mayor libertad en la elección de las herramien-tas a utilizar y mayor independencia de las tecnologías propietarias. Comocontrapartida, los costos operativos pueden verse aumentados, y es difícilgarantizar SLA (service level agreement) y QoS (Quality of service).


2.3. Infraestructura de servicios 21

Modelo de plataforma de terceros: es un modelo pensado para integrar dis-positivos que cumplan ciertas condiciones o restricciones, como por ejem-plo protocolos estándar de comunicación. Este tipo de modelos, permiteaprovechar funcionalidades y capacidades ya construidas, minimizar tiem-pos de salida al mercado y evita el mantenimiento y gestión de una infraes-tructura propia. Por otro lado, genera una fuerte dependencia de la plata-forma utilizada y la necesidad de integrarse a ciertos protocolos.

Modelo híbrido: en este caso, el software es provisto por el desarrolladordel sistema, pero corre sobre la infraestructura de un tercero. Quien admi-nistra todos los módulos y componentes de software corriendo en la infra-estructura es el desarrollador de los mismos. En algunos casos, puede existircierta integración con alguna funcionalidad del proveedor de la infraestruc-tura. Este tipo de modelo, permite cierto control sobre los componentes desoftware, a la vez que se puede hacer uso y aprovechamiento de ciertas ca-pacidades o funcionalidades ya provistas por el tercero, pero por otro lado,puede generar cierta dependencia de ciertos componentes sobre los cualesse tiene poco control.

Para el caso del presente proyecto, se optó por utilizar un modelo de nube propiacon el objetivo de migrar a un esquema híbrido en próximas etapas, utilizandoDocker para facilitar el despliegue de las aplicaciones. El funcionamiento de Doc-ker se describe en la sección 2.3.1.

2.3.1. Docker

Docker[12] es una plataforma de software que permite crear, probar e implemen-tar aplicaciones rápidamente, a través del empaquetamiento de software en uni-dades estandarizadas llamadas contenedores que incluyen todo lo necesario paraque el software se ejecute, incluidas bibliotecas, herramientas de sistema y códi-go. Con Docker, se puede implementar y ajustar la escala de aplicaciones rápi-damente en cualquier entorno con la certeza de saber que el código se ejecutará.Esta plataforma de código abierto hace uso de las funciones de aislamiento derecursos del kernel de Linux para poder dar lugar a contenedores independientes.Dentro de estos se ejecutará una única aplicación con sus respectivas dependen-cias, pero funcionando siempre con un único kernel, el de la máquina real, enlugar de virtualizar uno por cada contenedor. Esto se traduce en mejor porta-bilidad, compatibilidad, simplicidad y configuraciones más rápidas, seguridad,mayor ligereza y autosuficiencia con respecto a las máquinas virtuales típicas.

Un sistema de contenedores se compone principalmente de cinco elementos, co-mo se ilustra en la figura 2.20:

El daemon o demonio es el proceso principal de la plataforma.

El cliente es el programa que constituye la interfaz y que permite al usuariointeractuar con el Demonio.

Una imagen es una plantilla utilizada para crear el contenedor para la apli-cación que se desea ejecutar. Una imagen puede ser creada mediante unarchivo de texto plano llamado dockerfile que contiene una serie de ins-trucciones para tal fin.


Los registros son los directorios donde se almacenan las imágenes, tanto deacceso público como privado.

Los contenedores son carpetas donde se almacena todo lo necesario (libre-rías, dependencias, binarios, etc) para que la aplicación pueda ejecutarse deforma aislada.

FIGURA 2.20. Arquitectura de Docker.3

Otros conceptos dentro del esquema docker son los volúmenes y los enlaces olinks. Los primeros son utilizados para el almacenamiento de data persistente delos contenedores y son dependientes de la estructura de directorios de la máquinadonde se ejecutan los contenedores. Dado que los contenedores no conocen dela existencia de otros contenedores es que se utilizan los enlaces, permitiendoconectar contenedores entre sí para el envío de información.

Docker presenta el problema de resultar engorroso cuantos más servicios se im-plementan puesto que necesita de una serie innumerable de comandos bash yscripts para poder correr los distintos contenedores. Es aquí donde surge la he-rramienta Docker Compose, que simplifica el uso de Docker. Permite mediantearchivos YAML poder instruir al motor de Docker a realizar tareas de forma pro-gramática. Una vez se tiene armado el archivo YAML, con un único comando sepuede inicializar, correr y parar todos los servicios que forman parte del sistema.

En el caso del presente proyecto, se implementan los siguientes servicios en con-tenedores Docker:

RabbitMQ: es el broker open source de mensajes más ampliamente difun-dido en el mundo e implementa los protocolos MQTT, AMQP y STOMP.Consta del servidor rabbitMQ de intercambio en sí mismo, gateways paracada uno de los protocolos mencionados, librerías de AMQP en distintoslenguajes y una plataforma de plugins para customización, donde destacael plugin "management", utilizado en este proyecto, que permite monito-rear, configurar y controlar el broker.


2.3. Infraestructura de servicios 23

NodeRed: es una herramienta de programación gráfica para la intercone-xión de dispositivos de hardware, APIs (Application Programming Interface)y servicios online. Más allá de ser una herramienta de programación gráfi-ca, permite la creación de nodos de forma programática e incluso progra-mar funciones enteras en javascript. La estructura mínima son los nodos, loscuales se arrastran a través de la interfaz gráfica y permiten hacer una tareaconcreta. Todos estos nodos se organizan en flujos que agrupan nodos quese conectan entre sí. Su principal característica es la facilidad y poco tiempocon el que nuevos nodos pueden ser creados y agregados a los servicios yaen funcionamiento.

Grafana: es una plataforma open source que permite la visualización de da-tos métricos. Permite la creación de distintos cuadros de mando y gráficos apartir de distintas fuentes de datos, como bases de datos de series de tiem-pos, entre otros.

2.3.2. Bases de datos

Una base de datos[14] es un conjunto de datos pertenecientes a un mismo con-texto almacenados sistemáticamente para su posterior uso. Las bases de datosse pueden clasificar según su modelo de administración de datos. Un modelode datos es un conjunto de herramientas conceptuales que permiten describir lainformación que es necesaria administrar para un sistema de información, las re-laciones existentes entre estos datos, la semántica asociada y las restricciones deconsistencia. Si bien existen múltiples modelos distintos, en esta sección solo sedetallaran las bases de datos relacionales y de series de tiempo, dado su uso en elproyecto.

Una base de datos relacional es un tipo de bases de datos que cumple con el mo-delo relacional, cuya idea principal es el uso de varias tablas para representarla información. Cada tabla se compone de filas, denominadas tuplas, y por co-lumnas. Cada fila representa un registro y cada columna un campo o atributo.Estas tablas se vinculan entre sí y establecen relaciones de integridad de los datosque las componen. En el caso del presente proyecto, se utilizó una base de datosPostgreSQL[15] para el modelado del sistema.

Una base de datos de series de tiempo es un bases de datos optimizada paramanejar datos de series de tiempo. Esto se traduce en que los datos, que puedeno no estar correlacionados, se agregan de forma secuencial. En el caso del presenteproyecto, se utilizó una bases de datos Influxdb[16] para el almacenamiento delos distintos valores y estados de los nodos, sensores, actuadores y dispositivosdel edificio.

En ambas bases de datos utilizadas para el proyecto, las cuales corren como ser-vicio en contenedores de Docker, se utiliza SQL[17] como lenguaje de consultasde bases de datos, el cual consta de dos partes, un módulo para definición demodelo de datos y otro para la operatoria normal de la base de datos.


2.4. Hardware

Como se mencionó en la sección 1.4, se buscó mediante el proyecto dar visibilidada las plataformas de hardware abiertas, y por lo tanto el firmware del maestrofue desarrollado sobre una de las plataformas del Proyecto CIAA (ComputadoraIndustrial Abierta Argentina)[18], específicamente la versión CIAA-NXP, que sevisualiza en la figura 2.21.

Para el caso de los nodos esclavos, se plantearon dos soluciones, una que utilizaun microcontrolador de bajo consumo de la familia Cortex M0+, y otra utilizandola EDU-CIAA. De esta forma, también se visualiza que el sistema es altamenteportable entre distintos nodos esclavos. Para el caso del nodo M0+, se utilizó laplaca de desarrollo FDRM-KL46Z[19]. En la figura 2.22, se visualizan ambas pla-cas de desarrollo.

FIGURA 2.21. Placa de desarrollo CIAA-NXP.4

(A) Placa de desarrollo EDU-CIAA-NXP.4 (B) Placa de desarrollo FDRM-KL46Z.5

FIGURA 2.22. Placas de desarrollo utilizadas en el proyecto.

Para el caso de la CIAA-NXP y EDU-CIAA se utilizo el proyecto firmware v2provisto por los autores del proyecto CIAA, y en el caso de la placa FDRM-KL46Zse utilizó el SDK (Software Development Kit) provisto por NXP Semiconductors.

4Imagen tomada de [18]5Imagen tomada de [19]

2.5. Requerimientos 25

En los tres casos, se utilizó freeRTOS[20] como sistema de tiempo real debido alas atractivas características que justifican su uso. Entre ellas, la de mayor utili-dad es la capacidad de gestionar la ejecución de múltiples tareas. Además, ofreceotras herramientas que resultan de gran utilidad, como temporizadores o colaspara comunicar tareas entre sí. También permite integrar con mayor facilidad li-brerías que implementen funcionalidades complejas como los protocolos MQTTy Modbus.

2.5. Requerimientos

A continuación se listan los requerimientos, de forma resumida, con los que seplanifico y desarrollo el proyecto, diferenciándolos según si se trata de requeri-mientos funcionales o no funcionales.

Requisitos funcionales:

1. Sistema de comunicación:

1.1 El sistema debe comunicarse mediante una red MODBUS RTU so-bre RS-485.

1.2 El maestro de la red MODBUS RTU debe poder comunicar pará-metros de configuración y acciones hacia los esclavos.

1.3 El maestro de la red MODBUS RTU debe poder leer parámetrosde configuración, estados y valores actuales de los nodos esclavosde la red.

1.4 El maestro de la red debe poder comunicar parámetros de con-figuración, estados y valores actuales con un servidor medianteMQTT.

1.5 El maestro de la red debe poder recibir parámetros de configura-ción desde un servidor mediante MQTT.

1.6 La información comunicada mediante MQTT debe poder ser di-reccionada de forma unívoca tanto a maestros como a esclavos.

2. Sistema de medición:

2.1 El nodo maestro de la red debe poder obtener valores de una se-rie de sensores, entre los que destacan, sensores de profundidad,sensores de presión diferencial, sensores de CO, multimedidores,entre otros a definir.

2.2 El nodo maestro de la red debe poder comandar una serie de ac-tuadores y dispositivos, entre los que destacan ventiladores y lu-ces.

2.3 El nodo maestro debe almacenar temporalmente los estados y va-lores medidos.

2.4 Los nodos esclavos de la red deben poder obtener valores de unaserie de sensores, entre los que destacan, sensores de profundidad,sensores de presión diferencial, sensores de CO, multimedidores,entre otros a definir.


2.5 Los nodos esclavos de la red debe poder comandar una serie deactuadores y dispositivos, entre los que destacan ventiladores yluces.

2.6 Los nodos esclavos deben almacenar temporalmente los estados yvalores medidos.

3. Sistema de visualización y configuración:

3.1 El sistema debe visualizar parámetros de configuración, estados yvalores actuales en una aplicación web o móvil.

3.2 El sistema debe permitir la modificación de parámetros de confi-guración o la ejecución de tareas específicas desde una aplicaciónweb o móvil.

Requisitos no funcionales:

1. Sistema de comunicación y medición:

1.1 El sistema debe ser de tiempo real, de forma tal de responder a loseventos del entorno en tiempo acotado.

1.2 El sistema debe ser portable y extensible, teniendo en cuenta quese trata de un sistema altamente dependiente del lugar de aplica-ción.

1.3 El sistema debe ser al menos parcialmente diseñado con conceptosde sistemas críticos, teniendo en cuenta el lugar de aplicación.

2. Sistema de visualización y configuración:

2.1 La aplicación web o móvil debe ser de fácil uso y entendimientopara el usuario.

Cabe destacar que estos requerimientos se encuentran extendidos y mejor deta-llados en el documento que se anexa en el apéndice A, que surgió de la etapa deelicitación de requerimientos, al comienzo del proyecto.

2.6. Planificación

Para llevar a cabo el proyecto se realizó una planificación de tareas y se estima-ron que tiempos debían emplearse para cada una de ellas. A su vez se analizaronqué tareas debían realizarse primero y cuáles eran sus dependencias. En la figura2.23 se muestra el listado de tareas y el tiempo estimado para cada una, mientrasque, en la figura 2.24 se muestra la información de la planificación de tareas enforma de diagrama de Activity on Node. En este tipo de diagramas, cada rectán-gulo o nodo representa una actividad, y las conexiones entre ellas representanuna dependencia temporal en la que una debe terminarse antes que la siguiente.Ademas, en este caso, mediante el uso de flechas de mayor grosor, se indica elcamino crítico. En la tabla 2.1 se explica el significado de cada color del diagrama.

2.6. Planificación 27

FIGURA 2.23. Tareas del proyecto

TABLA 2.1. Significado de los colores del diagrama AoN

Color Significado

Rojo 1. Gestión del proyectoCeleste 2. Diseño e Implementación de FirmwareVerde 3. Diseño e Implementación de Aplicación

de Visualización y ConfiguraciónVioleta 4. Diseño e Implementación de Hardware

PrototipoNaranja 5. Verificación y Validación


FIGURA 2.24. Diagrama Activity on Node de la planificación delproyecto

Por cuestiones ya mencionadas a lo largo de la presente memoria, las tareas co-rrespondientes a 4. Diseño e Implementación de Hardware Prototipo fueron pos-puestas para una etapa posterior.

29

Capítulo 3

Diseño e implementación

En este capítulo se detallan las consideraciones de diseño que se tuvieron en cuen-ta para realizar el sistema y se describe el desarrollo y funcionamiento del firm-ware y servicios implementados en el proyecto.

3.1. Diseño general del sistema

En el diseño del sistema implementado se buscó cumplir una serie de propieda-des que se plantean a continuación:

Disponibilidad: hace referencia a la capacidad del sistema para proporcio-nar servicios cuando estos son requeridos.

Fiabilidad: se refiere a la capacidad del sistema para proporcionar servicioscomo estos han sido especificados.

Seguridad: es la capacidad del sistema para funcionar sin fallos catastrófi-cos.

Mantenibilidad: se trata de la capacidad para poder modificar un software,corregir sus errores, mejorar sus prestaciones u otros atributos, o adaptarloa un entorno diferente.

El objetivo del cumplimiento de estas propiedades tiene que ver con la idea depoder utilizar el sistema en cualquier edificio, se encuentre en construcción o yaen funcionamiento, lo que implica la necesidad de poder integrarse a distintossensores, actuadores y dispositivos. Además, se buscó que el sistema pueda ex-tenderse cuando ya se encuentre instalado, realizando el menor esfuerzo posible.Esto permite que el sistema sea lo más genérico posible y funcione de la formaque se espera sin fallos.

Para ello se planteó un ciclo de vida de desarrollo de software en cascada, con fa-ses de elicitación1y especificación de requerimientos(ver apéndice A), diseño dearquitectura del software, implementación y documentación de los componen-tes del software mediante el uso de Doxygen[21], tests y ensayos de integracióny validación, que sobre todo permitieran garantizar la fiabilidad y mantenibili-dad del mismo. Asimismo, se utilizaron algunas técnicas o medidas menciona-das en la norma UNE-EN 50128[22], como por ejemplo diseño de la arquitecturadel software mediante modelado de datos, confección de diagramas de flujo, de

30 Capítulo 3. Diseño e implementación

secuencia y de bloques, uso de programación defensiva y programación con aser-ciones, técnicas de programación orientada a objetos como ocultamiento y encap-sulamiento de la información, enfoque modular, guías de estilos de codificación,análisis estático de código, tests unitarios y ensayos de caja negra.

El diseño del sistema se basó en una arquitectura distribuida con un esquemamaestro esclavo, con el objetivo de minimizar e independizar las fallas del siste-ma, de modo tal, que la falla de un nodo no signifique una caída total. Además,la interfaz de comunicación con el servidor externo se hizo mediante MQTT yAMQP para aumentar la disponibilidad de la información enviada, mediante elsistema de colas de este último protocolo. Por último, la mantenibilidad del sis-tema se buscó mediante la aplicación de patrones, conceptos de programaciónorientada a objetos y modularización al diseño del firmware, en conjunto con eluso de contenedores Docker para la implementación de los servicios remotos.

Extendiendo lo mencionado en la sección 2.1 sobre la arquitectura y funciona-miento del sistema implementado, se presenta la figura 3.1, donde se visualizanlos distintos componentes del sistema con mayor detalle, destacando la interac-ción entre los distintos servicios corriendo como contenedores de Docker, y la in-teracción entre los nodos y los servicios mediante los protocolos ya mencionados.Aquí también se resalta que se pueden agregar a la red Modbus otros dispositivosde terceros que soporten el protocolo.

El diseño del sistema comenzó con la modelización de los componentes más im-portantes del sistema embebido, que son los nodos, sensores y actuadores. Estosmodelos, que se visualizan en la figura 3.2, son los que se implementan en el firm-ware. Para facilitar la instalación, extensión y modificación del sistema, es que ladefinición particular de los datos de estos dispositivos se realiza en un archivode configuración del firmware por parte del desarrollador. En este archivo tam-bién se define el mapa de registros de Modbus que soporta el nodo que correel firmware. De esta forma, con la simple modificación de ese archivo, se pue-den implementar nodos con configuraciones de sensores y actuadores totalmentedistintas.

1Proceso mediante el cual se descubren las necesidades y propiedades de un sistema de infor-mación a partir de la comunicación con los usuarios y beneficiarios del sistema.

3.1. Diseño general del sistema 31

FIGURA 3.1. Arquitectura general del sistema

FIGURA 3.2. Modelado de componentes del sistema embebido.

De la figura 3.2 se desprende que un nodo puede tener de 1 a N sensores y ac-tuadores, como así también entradas en el mapa de Modbus que tienen asociadasfunciones para obtener y configurar los valores de estos. En la sección 3.2 se expli-ca con mayor detalle el uso de funciones virtuales y conceptos de programaciónorientada a objetos en los sensores y actuadores. Además, se destaca el uso de unafunción de control, a modo de callback, para el cual existe un puntero al actuadorasociado, dentro de los sensores.


Como se eligió el protocolo MQTT para la comunicación entre el nodo maestro yel conjunto de servicios, se definió un esquema de tópicos para poder comunicar-se entre sí. Este esquema se visualiza en la figura 3.3.

FIGURA 3.3. Esquema de tópicos utilizados en MQTT.

De la figura 3.3 se desprende que los tópicos están compuestos por siete niveles:

Sistema: este nivel es utilizado para determinar a que sistema se le envíanlos comandos, en caso de que se tengan múltiples sistemas conectados víaMQTT.

Versión: este nivel se utiliza para indicar la versión del esquema de tópicosutilizado. En caso de realizar modificaciones, los sistemas que utilicen elviejo esquema no se verían afectados.

MAC Address: es la dirección MAC (Media Access Control) del nodo maestrode la red. De esta forma se pueden diferenciar los distintos nodos maestrosexistentes que podrían o no estar en un mismo edificio.

Sentido: este nivel es usado para indicar el sentido de los mensajes, es decirmensajes que son enviados al nodo maestro con RQ y mensajes publicadospor este con NY. Los mensajes NY pueden ser mensajes de acknowledge, enlos casos de comandos CMD o CFG, o envíos de un valor específico en elcaso del comando DAT o ERR.

Comando: este nivel indica el comando que se debe ejecutar, siendo CFGpara configuración de nodos, sensores o actuadores, CMD para el comandode actuadores, DAT para la lectura de los distintos valores del mapa deModbus y ERR para el reporte de errores.

Modbus ID: como su nombre lo indica, es el ID del nodo dentro del protoco-lo Modbus. El ID 0 es utilizado para direccionar comandos al nodo maestro,el resto para los esclavos. No existen comandos de tipo broadcast.

3.1. Diseño general del sistema 33

Dirección del registro: es la dirección del registro Modbus a escribir o leer.

Los payloads consisten en valores separados por comas, que pueden representarel tamaño de un registro de Modbus o su valor. Como en el caso de la lectura sepueden leer múltiples registros, se proponen dos casos diferenciados. Para el casodel maestro es suficiente con indicar el tamaño total de bytes a leer a partir de ladirección indicada en el tópico, para que se devuelva un mensaje con todos losvalores separados por comas. En cambio, para los nodos esclavos se debe indicarlos tamaños de cada elemento a leer con el objetivo de tener mayor control sobreerrores posibles en la comunicación Modbus.

Como el sistema de reglas necesita conocer el mapa de Modbus y cierta informa-ción de cada nodo instalado en cada edificio, junto con algunos datos particularesde estos, se realizó un modelado conceptual de base de datos para el almacena-miento toda esta información y posterior consulta por parte de este sistema. Elmodelado resultante se visualiza en la figura 3.4.

FIGURA 3.4. Modelado conceptual de la base de datos.

Aquí es posible ver que el sistema puede soportar múltiples edificios con múlti-ples nodos, que pueden ser maestros o esclavos. Cada uno de estos nodos poseeun mapa Modbus que está formado por múltiples entradas. Cabe destacar queun mapa Modbus puede repetirse dentro de los distintos nodos, si es que estosutilizan la misma configuración de sensores y actuadores.


El diagrama de entidad-relación resultante del modelado anterior es el que sevisualiza en la figura 3.5. Este diagrama es el que finalmente se implementa enPostgresDB.

FIGURA 3.5. Diagrama entidad relación de la base de datos.

3.2. Diseño e implementación de firmware

La arquitectura del firmware se diseñó teniendo en cuenta algunos patrones dediseño de arquitectura y conceptos de programación orientada a objetos (POO)en C:

Capas: su principal objetivo es el desacople de las partes que componen elsistema, trayendo como principal ventaja la reducción de complejidad delas capas y la portabilidad del sistema. Este último punto resulta de su-ma importancia, dado que uno de los objetivos es que el sistema se puedainstalar en cualquier edificio. Esto puede implicar la necesidad de que elfirmware del maestro o de los esclavos corra sobre microcontroladores dedistintas familias.

Hardware Proxy Pattern: este patrón[23] crea un elemento de software res-ponsable del acceso a un elemento de hardware y del encapsulamiento dela implementación del código de dicho elemento. El proxy permite el accesoa servicios de lectura, escritura, inicialización, y configuración del elementode hardware. De esta forma permite el cambio del hardware subyacente deforma sencilla y transparente para el resto del sistema.

Arquitectura disparada por eventos: es un patrón[24] de arquitectura soft-ware que promueve la producción, detección, consumo de, y reacción a

3.2. Diseño e implementación de firmware 35

eventos. Un evento puede ser definido como “un cambio significativo enun estado“. Un sistema dirigido por eventos está compuesto típicamentede emisores de eventos, o agentes, y consumidores de eventos. Los consu-midores tienen la responsabilidad de llevar a cabo una reacción tan prontocomo el evento esté presente. La reacción puede o no, ser completamen-te proporcionada por el consumidor en sí mismo. Es decir, el consumidorpuede tener solamente la responsabilidad de filtrar, transformar y reenviarel evento a otro componente o puede proporcionar una reacción propia aalgún evento. Construir aplicaciones y sistemas alrededor de una arquitec-tura dirigida por eventos permite a estos ser construidos de una manera quefacilita un mayor grado de reacción, debido a que los sistemas dirigidos poreventos están más normalizados para entornos no predecibles y asíncronos.

Programación orientada a objetos: es un paradigma de programación[25]basado en tres características principales, encapsulamiento, herencia y poli-morfismo. La utilización de estos conceptos en C por sobre el desarrollo delfirmware directamente en C++, se debe a la idea de que el firmware pue-da ser implementado en distintos microcontroladores, tanto para los nodosmaestros como para los esclavos. De esta forma, en el caso de no existircompilador de C++ para ellos, o ser este muy ineficiente, se limitaría fuer-temente la portabilidad del sistema. Asimismo, tanto lwIP, freeModbus yfreeRTOS están programadas en C, por lo que resulta más conveniente pro-gramar el resto del firmware en el mismo lenguaje.

En las figuras 3.6 y 3.7 se visualizan las arquitecturas de los firmwares del nodomaestro y de los esclavos siguiendo el patrón de arquitectura en capas, donde,agrupados por color se pueden apreciar los distintos niveles de abstracción y,dentro de cada capa, los bloques funcionales que la integran:

Hardware: representa el hardware sobre el que corre el firmware del maes-tro o de los esclavos, los sensores, actuadores y dispositivos con los que elfirmware interactúa.

HAL (Hardware Abstraction Layer): permite el desacople de las capas su-periores del hardware. Aquí se encuentran los drivers del fabricante delmicrocontrolador, en el bloque funcional LPCOPEN o el SDK de la placaFDRM-KL46Z, los desarrollados para la plataforma particular en el bloqueBOARD, y los drivers propios que fueron diseñados para el sistema.

HIL (Hardware Independent Layer): incluye los módulos del RTOS, el stackTCP/IP, en el caso del maestro, y del protocolo Modbus.

App Layer: en el caso del maestro incluye tres aplicaciones, la del clien-te MQTT que recibe y publica mensajes en los tópicos mencionados en lasección 3.1, la del maestro del bus Modbus para la comunicación con losesclavos y la propia que se encarga de la lectura de sensores y actuaciónde distintos dispositivos conectados a él. En el caso de los nodos esclavos,como estos no se conectan a MQTT, solo poseen dos aplicaciones, la del es-clavo del bus Modbus y la propia para el manejo de sensores y actuadores.


FIGURA 3.6. Arquitectura en capas del firmware del nodo maes-tro.

FIGURA 3.7. Arquitectura en capas del firmware del nodo esclavo.


En la figura 3.8 se visualiza la estructura del patrón Hardware Proxy. Este patrónfue elegido, sobre todo, para poder cumplir con el requerimiento no funcional 1.2de la sección 2.5. De este modo es posible aplicar el sistema en cualquier edificioque utilice distintos tipos de sensores o actuadores, con cambios relativamentesencillos al firmware.

FIGURA 3.8. Estructura del patrón Hardware Proxy.

En la figura 3.9 se ilustra la estructura de una arquitectura disparada por eventos.

FIGURA 3.9. Diagrama de arquitectura basada por eventos.

Este tipo de arquitecturas está integrado por cuatro componentes principales. Seinicia con la detección de un hecho, su representación técnica en la forma de unevento y termina con un conjunto no vacío de reacciones a ese evento:

Generador del evento: el primer componente es el generador de eventos,que detecta un hecho y lo representa en forma de un evento. En este caso


podría tratarse de una interrupción (ISR) o callback por la ocurrencia de al-gún evento asincrónico del mundo externo, o alguno de los manejadores deeventos, que producen eventos para otros manejadores.

Canal del evento: es el mecanismo mediante el cual la información enviadapor un generador de eventos en forma de eventos, se transfiere al despa-chador de eventos. En la implementación de este proyecto, se utilizan comocanal tres colas de tipo FIFO provistas por el RTOS utilizado para asignarprioridad de ejecución a los eventos, según el manejador al cual van dirigi-dos.

Despachador de eventos: es donde se identifica el evento y se ejecuta elmanejador de eventos que es receptor de dicho evento.

Manejador de eventos: es quien ejecuta las acciones correspondientes deacuerdo al evento recibido. Corre dentro del hilo del despachador. Un ma-nejador puede manejar más de un evento, para los cuales tiene accionesdistintas. Todas las acciones son del tipo RTC (Run to Completion), de mo-do tal que no se ejecuta otra acción de la misma prioridad si la actual nofinalizó.

Asimismo, un evento puede estar hecho de dos partes, el encabezado y el cuerpo.El encabezado puede incluir información como el tipo de evento, fecha, hora, aquién va dirigido, entre otras cosas. El cuerpo del evento, generalmente, se en-cuentra formado por la información a transmitir al receptor del evento.

La característica más representativa de la implementación llevada a cabo para elproyecto es que se utilizan archivos de configuración, donde el usuario determinalas señales o tipos de eventos, y define los manejadores, permitiendo reutilizardicha implementación en posteriores proyectos. De hecho, la implementación sereutiliza con manejadores y señales distintas en el nodo maestro y en los esclavos.A modo de ejemplo se provee el extracto de código 3.1 con la definición las señalesy manejadores utilizados en el maestro.

1

2 /* Declarar debajo l o s módulos de l a a p l i c a c i ón */3 /* DEBEN e s t a r def in idos fuera de e s t e modulo */4 extern void controllerModuleHandler ( event_t * event ) ;5 extern void configuratorModuleHandler ( event_t * event ) ;6 extern void publisherModuleHandler ( event_t * event ) ;7 extern void loggerModuleHandler ( event_t * event ) ;8

9 /* *10 * @def MODULES_STUFF11 * @brie f D e f i n i c i ón de l o s módulos de l a a p l i c a c i ón y su prior idad12 */13 # def ine MODULES_STUFF \14 { \15 { . eventHandler = controllerModuleHandler , \16 . p r i o r i t y = MED_PRIORITY \17 } \18 , { . eventHandler = configuratorModuleHandler , \19 . p r i o r i t y = LOW_PRIORITY \20 } \21 , { . eventHandler = publisherModuleHandler , \22 . p r i o r i t y = LOW_PRIORITY \23 } \24 , { . eventHandler = loggerModuleHandler , \25 . p r i o r i t y = LOW_PRIORITY \


26 } \27 } ;28

29 /* *30 * @enum s i g n a l s _ t31 * @brie f D e f i n i c i o n de l a s p o s i b l e s señ a l e s de l a a p l i c a c i ón32 * @note D e f i n i r debajo de SIGNAL_INIT todas l a s señ a l e s n e c e s a r i a s33 */34 typedef enum35 {36 SIGNAL_INIT = 0x00 /**< Señ a l de I n i c i a l i z a c i ón de Modulo */37 , SIGNAL_TIMEOUT /**< Señ a l de Timeout para l o s sensores */38 , SIGNAL_PUB_ERR /**< Señ a l de p u b l i c a c i ón de e r r o r e s */39 , SIGNAL_ACK /**< Señ a l de p u b l i c a c i ón de ACK */40 , SIGNAL_DAT /**< Señ a l de l e c t u r a de d i s p o s i t i v o */41 , SIGNAL_CFG /**< Señ a l de Conf iguraci ón de d i s p o s i t i v o */42 , SIGNAL_CMD /**< Señ a l de Comando de actuador */43 , SIGNAL_LOG /**< Señ a l de log en l a SD */44 } s i g n a l s _ t ;

CÓDIGO 3.1. Señales y manejadores de eventos del nodo maestro.

En la figura 3.10 se ilustra, a modo de ejemplo, los conceptos de POO utilizadosen el modelado de los sensores.

FIGURA 3.10. Conceptos de POO en el modelado de los sensores.

Las características de la programación orientada a objetos mencionados en 3.2, seimplementaron dentro de este proyecto teniendo en cuenta las características dellenguaje C:

Encapsulamiento: es la habilidad de empaquetar datos y comportamientoen clases. Una clase es una especie de plantilla donde se definen atributosy funcionalidades de un tipo de objeto. Este es un concepto ampliamenteutilizado dentro de la programación en C, donde se tienen archivos .h y.c donde se definen estructuras (structs) que representan los atributos dela clase, y funciones que operan sobre estas estructuras, representando elcomportamiento de la clase. De esta forma la estructura queda encapsulada,


ya que el usuario no necesita acceder a los atributos internos, sino que lohace mediante el uso de las funciones mencionadas.

Herencia: es la capacidad de definir nuevas clases a partir de clases existen-tes, de forma tal de reutilizar código. En lenguaje C se puede implementarla herencia simple de forma muy sencilla, al embeber la estructura de la cla-se padre dentro de la estructura de la clase hija como primer atributo. Deesta forma, queda la memoria alineada de forma tal que es posible tratar acualquier puntero a la clase hija como puntero a la clase padre. Por lo tan-to, todas las funciones que representan el comportamiento de la clase padreson aplicables a la clase hija, es decir que no solo los atributos sino tambiénel comportamiento son heredados.

Polimorfismo: es la capacidad que tienen los objetos de una clase en ofrecerrespuesta distinta e independiente en función de los parámetros (diferentesimplementaciones) utilizados durante su invocación. De esta forma se pue-den tener, por ejemplo, dos clases de sensores distintas, que heredan de laclase padre ”sensor” y que al ejecutar la función de lectura dan respuestasdistintas. Existen tres tipos de polimorfismo: sobrecarga, paramétrico e in-clusión. Este último es el que se utiliza en el diseño del firmware y es el quese explica en el ejemplo dado en este párrafo. En C se puede implementarel polimorfismo mediante el uso de funciones virtuales. La forma en quese implementaron las funciones virtuales en el proyecto se muestra en laporción de código 3.2. Al visualizarla, se nota claramente que las funcio-nes de inicialización, lectura y obtención de valor pueden tener múltiplesimplementaciones distintas en las clases hijas, permitiendo escribir códigogenérico que manipule los sensores o actuadores de la misma forma, inde-pendientemente de cuáles sean los que realmente se implementan de formasubyacente.

1

2 /* *3 * @def bool ( * sensorFuncPtr_t ) ( sensor_ t * )4 * @brie f D e f i n i c i ón de puntero a func i ón de sensor5 */6 typedef bool ( * sensorFuncPtr_t ) ( sensor_ t * ) ;7

8 /* *9 * @def bool ( * sensorParamFuncPtr_t ) ( sensor_ t * , u i n t 3 2 _ t * )

10 * @brie f D e f i n i c i ón de puntero a func i ón de sensor con pasa je de par ámetros

11 */12 typedef bool ( * sensorParamFuncPtr_t ) ( sensor_ t * , u i n t 3 2 _ t * ) ;13

14 /* *15 * @struct se ns or V tb l_ t16 * @brie f Tabla de punteros a func i ón de un sensor17 */18 typedef s t r u c t19 {20 sensorFuncPtr_t i n i t ; /**< Puntero a Función de I n i c i a l i z a c i ó

n*/21 sensorFuncPtr_t read ; /**< Puntero a Función de Lectura */22 sensorParamFuncPtr_t getValue ; /**< Puntero a Función de Reporte */23 } s en so rV tb l _ t ;24

25 /* *26 * @struct sensor_ t


27 * @brie f Es t ruc tura de un sensor28 */29 typedef s t r u c t30 {31 s en so rV tb l_ t * vptr ; /**< Mé todos ( Comportamiento ) de

un sensor */32 u i n t 8 _ t id ; /**< Id del sensor */33 sensorType_t type ; /**< Tipo del sensor */34 s e n s o r S t a t u s _ t s t a t u s ; /**< Estado del sensor */35 sensorControlCbFuncPtr_t controlCbPtr ; /**< Callback de c o n t r o l */36 a c t u a t o r _ t * a c t u a t o r ; /**< Actuador asociado a l a cb

de c o n t r o l */37 } sensor_ t ;38

39 bool s e n s o r _ i n i t ( sensor_ t * me)40 {41 bool r e t V a l = f a l s e ;42

43 i f (me)44 {45 r e t V a l = me−>vptr−> i n i t (me) ;46 }47

48 re turn r e t V a l ;49 }50

51 bool sensor_read ( sensor_ t * me)52 {53 bool r e t V a l = f a l s e ;54

55 i f (me)56 {57 r e t V a l = me−>vptr−>read (me) ;58 }59

60 re turn r e t V a l ;61 }62

63

64 bool sensor_getValue ( sensor_ t * me, u i n t 3 2 _ t * param )65 {66 bool r e t V a l = f a l s e ;67

68 i f (me)69 {70 r e t V a l = me−>vptr−>getValue (me, param ) ;71 }72

73 re turn r e t V a l ;74 }

CÓDIGO 3.2. Ejemplo de funciones virtuales.


Teniendo en cuenta todo lo mencionado durante esta sección, se presentan lasarquitecturas del nodo maestro y de los esclavos en las figuras 3.11 y 3.12, respec-tivamente.

FIGURA 3.11. Arquitectura específica del nodo maestro.

FIGURA 3.12. Arquitectura específica del nodo esclavo.

En la figura 3.11 se resaltan, en color naranja, las tres grandes tareas que compo-nen el firmware del maestro:

Tarea MQTT: es la encargada de inicializar el stack TCP/IP de la libreríalwIP, el cliente MQTT, conectarse al broker, suscribirse a la lista de tópicosdefinida por el usuario, que en este caso son los que se visualizan en lafigura 3.3 con sentido hacia el maestro, instanciar la callback de recepcióny de chequear el estado de la capa física de Ethernet. En la callback de re-cepción de MQTT, se detecta cuál de los tres posibles tópicos es, RQ/DAT,


RQ/CMD o RQ/CFG, se obtienen los parámetros recibidos en el payload yse envía a un evento a cada manejador particular. Asimismo, se envía unevento del tipo ACK al publisher, para que este publique en MQTT un men-saje de acknowledge, indicando la correcta recepción de un mensaje.

Despachador de eventos: es la tarea encargada de recibir los eventos de lastres colas existentes y ejecutar el manejador correspondiente, destacados encolor celeste:

• Logger: recibe eventos del tipo INIT y LOG. En el primer caso, inicia elperiférico SPI (Serial Peripheral Interface) y monta el filesystem en la SD(Secure Digital). En el segundo caso escribe en la SD el mensaje que vie-ne como cuerpo del evento. Este manejador es utilizado para guardarinformación en la SD que faciliten la trazabilidad de posibles erroresocurridos en la ejecución del firmware.

• Publisher: recibe eventos del tipo INIT, ACK, PUB_ERR y DAT. En elprimer caso, publica por MQTT un mensaje que indica que el maestrose ha conectado correctamente a MQTT. El segundo y tercer eventoson utilizados para publicar en MQTT mensajes de acknowledge y error,respectivamente. Por último, en el manejo del evento de tipo DAT, sedetecta si es una lectura de información general, de un sensor o deun actuador y a quien va dirigida, es decir si al nodo maestro o a losesclavos. Esta información es obtenida a partir de los niveles del tópicorecibido. En caso de ser una información del nodo maestro, obtienedicha información y la publica por MQTT, en cambio, si es informaciónde un esclavo, envía un mensaje por Modbus y queda a la espera dela respuesta. Si existe respuesta dentro del tiempo esperado, la publicaen MQTT, caso contrario, publica un mensaje de error.

• Controller: recibe eventos del tipo INIT, TIMEOUT y CMD. En el pri-mer caso inicializa todos los sensores y actuadores que estén conecta-dos al nodo. En el segundo caso, el evento es utilizado para ejecutaracciones periódicas. En este caso, ejecuta una lectura de los sensores yla callback de control asociada, si es que esta existe. Por último, el even-to de tipo CMD, es utilizado para ejecutar comandos en actuadores delnodo maestro o de los esclavos. Al igual que en el caso del publisher,el manejador detecta si el comando va dirigido al nodo maestro o aalgún esclavo, ejecutando la acción directamente en el primer caso, oenviando una escritura de registro al esclavo pertinente en el segundocaso. Si no hay respuesta por parte del esclavo se envía un evento detipo ERR al publisher.

• Configurator: recibe eventos del tipo CFG y el manejador funciona deforma muy similar al controller. Detecta si el registro a configurar esdel nodo maestro o de alguno de los esclavos y procede de la mismaforma.

Tarea Modbus: es la tarea encargada de hacer polling para ejecutar la MEF(Máquina de estados finitos) de la librería freeModbus[26] encargada de laimplementación del maestro del bus.


En la figura 3.12, se visualiza la arquitectura del firmware de los nodos esclavos.En principio, no hay tarea encargada de inicializar el stack TCP/IP ni de conec-tarse al broker MQTT y la tarea de Modbus en este caso se encarga de hacer pollingpara ejecutar la MEF del esclavo de Modbus. Asimismo, se instancia una callbackpara la recepción de los mensajes provenientes del maestro y ejecución de lecturaso escrituras asociadas. La tarea del despachador de eventos funciona exactamen-te de la misma forma, salvo por los manejadores que son distintos. El logger actúade la misma forma que en el caso del maestro, aunque no almacena errores re-lacionados a la conexión MQTT. Los manejadores controller y configurator son losencargados de ejecutar comandos o configurar ciertos registros, respectivamente,pero en este caso sí o sí sobre dispositivos propios. Por último, en casos de lectu-ra, la callback de Modbus directamente accede al valor y lo retorna en forma derespuesta por el bus.

Tanto en el caso del firmware del nodo maestro como en el de los esclavos existeuna tarea encargada de refrescar el watchdog implementado para retornar al siste-ma a un estado conocido en caso de un error irrecuperable. Asimismo, en amboscasos, el acceso a sensores, actuadores e información propia es mediante el usodel modelado de datos planteado en la sección 3.1 y con los conceptos de POOvistos en la sección 3.2.

3.3. Diseño e implementación de infraestructura de servi-cios

Como se mencionó en la sección 2.3.1, la interfaz de visualización, sistema dereglas y alertas, fue implementado mediante el uso de Grafana, NodeRed, Rab-bitMQ y las dos bases de datos mencionadas en la sección 2.3.2 (PostgresDB eInfluxDB) corriendo como contenedores de Docker. Para poder manejar de formamás sencilla tantos contenedores se utilizó la herramienta Docker Compose y seimplementó el archivo YAML de la porción de código 3.3.

1

2 version : "3.7"3

4 s e r v i c e s :5 grafana :6 container_name : grafana7 image: grafana/grafana8 r e s t a r t : unless−stopped9 ports :

10 - 3000 :300011 env_f i le :12 - . . / docker / s e r v i c e s / grafana / grafana . env13 volumes:14 - . . / docker / volumes / grafana / data :/var/ l i b /grafana15

16 influxdb :17 container_name : inf luxdb18 image: inf luxdb: l a t e s t19 r e s t a r t : unless−stopped20 ports :21 - 8086 :808622 - 2003 :200323 env_f i le :24 - . . / docker / s e r v i c e s / influxdb / influxdb . env

3.3. Diseño e implementación de infraestructura de servicios 45

25 volumes:26 - . . / docker / volumes / influxdb / data :/var/ l i b /inf luxdb27 - . . / docker / backups / influxdb / db:/var/ l i b /inf luxdb/backup28

29 nodered:30 container_name : nodered31 build : . . / docker/ s e r v i c e s /nodered /.32 r e s t a r t : unless−stopped33 env_f i le :34 - . . / docker / s e r v i c e s / nodered / nodered . env35 ports :36 - 1880 :188037 l inks :38 - influxdb : inf luxdb39 - rabbi t : r a b b i t40 volumes:41 - . . / docker / volumes / nodered / data :/data42

43 portainer :44 container_name : p o r t a i n e r45 image: p o r t a i n e r/ p o r t a i n e r46 r e s t a r t : unless−stopped47 ports :48 - 9000 :900049 volumes:50 - / var / run / docker . sock:/var/run/docker . sock51 - . . / docker / volumes / porta iner / data :/data52

53 postgres :54 container_name : postgres55 image: postgres56 r e s t a r t : unless−stopped57 env_f i le :58 - . . / docker / s e r v i c e s / postgres / postgres . env59 ports :60 - 5432 :543261 volumes:62 - . . / docker / volumes / postgres / data :/var/ l i b /p o s t g r e s q l/data63

64 rabbi t :65 container_name : rabbitmq66 image: rabbitmq:3.7.8 −management67 r e s t a r t : unless−stopped68 hostname: r a b b i t69 env_f i le :70 - . . / docker / s e r v i c e s / rabbitmq / rabbitmq . env71 ports :72 - 15672 :1567273 - 5672 :567274 - 1883 :188375 - 25672 :2567276 volumes:77 - . . / docker / volumes / rabbitmq / enabled_plugins :/ e t c /rabbitmq/

enabled_plugins78 - . . / docker / volumes / rabbitmq / data :/var/ l i b /rabbitmq

CÓDIGO 3.3. Archivo YAML utilizado para levantar loscontenedores de Docker.

En el código 3.3 es posible visualizar seis contenedores, cada uno con sus puertos,volúmenes y archivos de variables de entorno especificados y con la propiedadde reiniciarse cada vez que se detengan los servicios, a menos que el usuario


lo haya hecho de forma explícita. El servicio Portainer simplemente es utilizadopara llevar de forma gráfica el estado de los contenedores, siendo muy útil enetapa de desarrollo. Se utilizó la versión de archivo 3.7 que funciona con Docker18 o superior.

Asimismo, como se necesitaban ciertos paquetes que no vienen con la imagenoriginal de NodeRed y para no tener que instalarlos cada vez que se cambia decomputadora de desarrollo, se realizó el dockerfile del código 3.4 que instala to-dos los paquetes al momento de la descarga de la imagen desde el repositorio.

1

2 FROM nodered/node−red3 RUN npm i n s t a l l node−red−contr ib−amqp node−red−contr ib−inf luxdb node−red

−contr ib−re−postgres node−red−contr ib−s t a t e−machine node−red−contr ib−time−range−switch node−red−contr ib−weekday node−red−node−randomnode−red−node−email node−red−node−t w i t t e r

CÓDIGO 3.4. Dockerfile de la imagen de NodeRed.

Una vez que se tuvieron los servicios funcionando, se procedió a configurar lasplataformas para el funcionamiento del sistema. En primera instancia se confi-guraron las colas, bindings, exchanges y usuarios de RabbitMQ para que tanto elmaestro, el cliente de NodeRed y la herramienta de debugging MQTTBox se pu-dieran conectar al broker MQTT, como se visualiza en las figuras 3.13, 3.14 y 3.15.

FIGURA 3.13. Configuración de usuarios de RabbitMQ.

FIGURA 3.14. Configuración de las colas de RabbitMQ.


FIGURA 3.15. Configuración de los exchanges de RabbitMQ.

Cabe destacar que todos los usuarios tienen nombre y contraseña, incluyendoel usuario rabbitmq que es el administrador del sistema de colas. Sólo la colaDASHBOARD, que utiliza el protocolo AMQP, es creada manualmente. Las otras,son creadas automáticamente por RabbitMQ al momento de detectar un clienteconectado a MQTT. Lo mismo sucede con el exchange y los bindings creados. So-lamente el binding a la cola DASHBOARD es creado manualmente al asignarlela routing key "SB.V1..NY.#", el resto son creados con el tópico de suscripción delcliente. De este modo, mediante el uso del nodo AMQP en NodeRed es posibleconsumir todos los mensajes de notificación publicados por el nodo maestro, des-de la cola DASHBOARD.

El paso siguiente fue crear las tablas del modelo entidad-relación mencionadasen la sección 3.1 y se poblaron con datos relacionados a los ensayos descriptosen el capítulo 4. En el código 3.5 se muestran las instrucciones en SQL utilizadaspara la creación de las mismas.

1

2 CREATE TYPE " node_status " AS ENUM (3 ’NODE_OK’ ,4 ’NODE_NOT_RESPONDING ’5 ) ;6

7 CREATE TYPE " node_type " AS ENUM (8 ’MASTER_NODE_TYPE ’ ,9 ’SLAVE_NODE_TYPE ’

10 ) ;11

12 CREATE TYPE " map_type " AS ENUM (


13 ’NODE_MAP_TYPE ’ ,14 ’THIRD_PARTY_MAP_TYPE ’15 ) ;16

17 CREATE TABLE " bui lding " (18 " bui ld ing_id " SERIAL UNIQUE PRIMARY KEY,19 " country " varchar ,20 " c i t y " varchar ,21 " s t r e e t " varchar ,22 " number " in t ,23 " c r e a t e d _ a t " timestamp ,24 " updated_at " timestamp25 ) ;26

27 CREATE TABLE " node " (28 " node_id " in t ,29 " mac_address " varchar ,30 " type " node_type ,31 " s t a t u s " node_status ,32 " bui ld ing_id " in t ,33 " map_id " int ,34 " c r e a t e d _ a t " timestamp ,35 " updated_at " timestamp ,36 PRIMARY KEY ( " node_id " , " mac_address " )37 ) ;38

39 CREATE TABLE "modbus_map" (40 " map_id " SERIAL UNIQUE PRIMARY KEY,41 " type " map_type ,42 " c r e a t e d _ a t " timestamp ,43 " updated_at " timestamp44 ) ;45

46 CREATE TABLE " entry " (47 " entry_ id " in t ,48 " entry_name " varchar ,49 " map_id " int ,50 " grp_id " in t ,51 " grp_name " varchar ,52 " addr " in t ,53 " s i z e " in t ,54 " c fg_value " in t ,55 " reserved " boolean ,56 " i s _ w r i t a b l e " boolean ,57 " c r e a t e d _ a t " timestamp ,58 PRIMARY KEY ( " entry_name " , " map_id " , " grp_id " , " grp_name " )59 ) ;60

61 ALTER TABLE " node " ADD FOREIGN KEY ( " map_id " ) REFERENCES "modbus_map" ( "map_id " ) ;

62

63 ALTER TABLE " entry " ADD FOREIGN KEY ( " map_id " ) REFERENCES "modbus_map" (" map_id " ) ;

64

65 ALTER TABLE " node " ADD FOREIGN KEY ( " bui ld ing_id " ) REFERENCES " bui lding "( " bui ld ing_id " ) ;

CÓDIGO 3.5. Instrucciones SQL para la creación de las tablas.

Luego, se configuraron los nodos de NodeRed para la comunicación con el maes-tro, envío de alertas, ejecución de reglas, y para el almacenamiento de los datos


en InfluxDB para posterior visualización en el dashboard. Los nodos se visualizanen las figuras 3.16, 3.17 y 3.18.

FIGURA 3.16. Nodos de análisis de reportes de NodeRed.

FIGURA 3.17. Nodos de de pedidos de información de NodeRed.

FIGURA 3.18. Nodos de ejecución de reglas de NodeRed.

Dentro de las funcionalidades que cubren los distintos nodos, se destacan tresgrandes grupos de funcionalidades:

Análisis de reportes del nodo maestro: contempla todos los nodos de la fi-gura 3.16, que consumen datos de la cola de AMQP y ejecutan algunas fun-ciones en javascript que realizan consultas a la base de datos en PostgresDBpara chequear que efectivamente lo recibido forma parte de algún sensor,actuador o nodo del edificio y luego guardan estos datos en la base de datosde series de tiempo, configuran valores si se trata de un reset o ejecutan elsistema de reglas asociado a la detección de algún evento particular y pos-terior envío de alertas. Asimismo, existe un caso particular, que consiste enla recepción y posterior almacenamiento de toda la información referida alos mensajes publicados con sentido al nodo maestro. Esto es realizado conel objetivo de llevar un gráfico en el dashboard en el que se pueda constatarque existe al menos una respuesta por parte del maestro ante cada mensa-je enviado y de esta manera verificar que el nodo maestro funciona de la


forma que se espera en todo momento. Un ejemplo de consulta a la basede datos en PostgresDB se muestra en la porción de código 3.6, en dondese obtienen todas las entradas de los mapas de Modbus de los nodos deledificio que representen un valor de un sensor o actuador.

Lectura de valores, eventos y resets: contempla todos los nodos de la figura3.17. Es una ejecución temporizada de consultas a la base de datos paraobtener los registros y sus tamaños de los distintos sensores y actuadores delos nodos del sistema y poder obtener valores, eventos y otros parámetrosque luego dispara el análisis del reporte del maestro. Cabe destacar que losresultados de las consultas a la base de datos, son serializados mediante eluso de timers para poder procesar de a un elemento a la vez y luego publicarel mensaje pertinente en MQTT.

Ejecución de reglas temporizadas: es el envío de comandos a los distintosactuadores cuando se cumple alguna regla temporizada. En este caso, losventiladores se prenden a las 07:00 hs y se apagan a las 19:00 hs todos losdías. Al igual que en el caso anterior, los resultados de las consultas a la basede datos son serializados con el mismo propósito.

1 −−Get values2 SELECT DISTINCT node_id , mac_address , entry_name , grp_name , grp_id , addr

, s i z e3

4 FROM node , entry , modbus_map5

6 WHERE node . bui ld ing_id = 1 AND7 node . map_id = modbus_map . map_id AND8 node . map_id = entry . map_id AND9 modbus_map . type = ’NODE_MAP_TYPE ’ AND

10 entry_name = ’ value ’11

12 ORDER BY node_id , addr ;

CÓDIGO 3.6. Consulta a PostgresDB.

Las tablas en InfluxDB almacenan datos como dirección MAC del nodo que re-porta, ID del nodo, tipo de tópico (RQ o NY), subtipo del tópico (CMD, CFG,DAT o ERR), tipo de sensor o actuador, id dentro del tipo, función del registro,timestamp y valor, que luego son consultadas por los distintos gráficos en el dash-board para la visualización de los valores de forma más armónica al usuario. Unejemplo de consulta a InfluxDB se visualiza en la porción de código 3.7, dondese obtiene el ultimo valor del sensor de profundidad y se realiza la cuenta queindica su datasheet para la conversión del valor a metros.

1

2 SELECT ( 7 0 0 0 . 0 − ( 5 0 0 0 . 0 − ( ( ( ( ( l a s t ( " value " ) * 2 0 . 0 ) / 1 0 2 3 . 0 ) −4 . 0 ) * 4 5 0 0 . 0 ) / 1 6 . 0 ) ) ) / 1000 .0

3

4 FROM "bms"5

6 WHERE ( "mac" = ’ 006037123456 ’ AND " nodeId " = ’ 0 ’ AND " group " = ’ADC_SENSOR ’ AND " groupId " = ’ 1 ’ AND " func " = ’ value ’ AND " topicType "

= ’NY’ AND " topicSubType " = ’DAT’ ) AND $ t i m e F i l t e r7

8 GROUP BY time (1 s ) f i l l ( n u l l )

CÓDIGO 3.7. Consulta a InfluxDB.


Por último, se diseñaron las interfaces del dashboard, la del usuario y la del admi-nistrador del sistema, a través de los bloques que este provee, y se configuraronlos umbrales para el envío de alertas vía correo electrónico. Ambas interfaces sevisualizan en las figuras 3.19 y 3.20.

En el dashboard de usuario se tienen distintos paneles con nombre del proyecto,hora actual, clima, alertas, valores instantáneos y registros históricos con cotaspara la visualización y envío de alertas vía mail. En el caso de la figura 3.19 solose visualizan el estado de las alertas y los valores actuales de los sensores depresión diferencial, profundidad, temperatura, humedad, y la simulación de unmultimedidor con la placa FDRM-KL46Z.

FIGURA 3.19. Dashboard de usuario.

En el dashboard de administración se tienen paneles para el control del correc-to funcionamiento del sistema. En particular, se visualiza información sobre losmensajes con sentido hacia y desde el maestro, los errores, el estado de los distin-tos sensores, actuadores y nodos, y los resets de estos últimos.

FIGURA 3.20. Dashboard de administración.


Un ejemplo de alerta enviado ante la detección de una alarma de una bombasimulada con los botones de la EDU-CIAA, se visualiza en la figura 3.21.

FIGURA 3.21. Ejemplo de alerta via mail del dashboard.

53

Capítulo 4

Ensayos y resultados

En este capítulo se detallan los ensayos realizados para comprobar el correctofuncionamiento del firmware de los nodos maestro y esclavos, como así tambiéndel sistema en general.

4.1. Banco de pruebas

En primer instancia se probó la comunicación Modbus, mediante el uso de unanalizador lógico. El banco de pruebas utilizado se presenta en la figura 4.1, quemuestra el banco de pruebas utilizado para los ensayos del protocolo. Las sali-das del analizador lógico se muestran en la figura 4.2. El uso de este banco depruebas, se debió a complicaciones al principio del desarrollo donde no se logra-ba comunicar de forma efectiva a las placas mediante los ports de freeModbusimplementados.

FIGURA 4.1. Banco de pruebas para ensayos del protocolo Mod-bus.

La salida del analizador lógico, que en este caso se trata de un analizador SaleaeLogic de 8 canales[27], corresponde a una prueba realizada en un ambiente con-trolado. Por experiencia con el uso de un sistema similar de la empresa que seconecta vía Modbus y que fue utilizado en edificios, es recomendable la utiliza-ción de cables de instrumentación mallados con certificación UL para la conexión

54 Capítulo 4. Ensayos y resultados

RS-485. La marca UL, certificación emitida por Underwriters Laboratories[28], esuno de los símbolos con mayor reconocimiento de que un producto cumple congarantía los estándares de seguridad y calidad.

FIGURA 4.2. Salida del analizador lógico.

Luego de algunas iteraciones, en las que se modificaron algunos aspectos del portde freeModbus realizado, junto con el timeout de espera de respuesta por partedel maestro, la comunicación quedó funcionando y se procedió a la conexión detodo el sistema como se visualiza en el banco de pruebas ilustrado en la figura4.3.

FIGURA 4.3. Banco de pruebas para ensayos de integración y sis-tema.

Durante los ensayos se usó un sensor de detección de CO (monóxido de carbono),conectado a un GPIO de entrada del maestro, un sensor de movimiento conecta-do de la misma manera, un sensor de presión diferencial conectado al ADC enmodo 4-20mA, un sensor de profundidad conectado del mismo modo y un sen-sor de temperatura y humedad conectado mediante I2C. Asimismo se utilizaronlos relés, botones y leds de ambas placas simulando el encendido de ventiladores,alarmas de ascensores, bombas y centrales de incendio y luces de los pasillos.

Este banco de pruebas fue el utilizado en los ensayos de integración y sistemaque se muestran en la sección 4.4.

4.2. Ensayos de caja blanca 55

4.2. Ensayos de caja blanca

Para corroborar el correcto funcionamiento de las técnicas implementadas sobresensores, actuadores y nodos, se procedió a realizar una serie de tests unitarios.Para ello, se utilizó ceedling[29] y gcov[30]. En la tabla 4.1 se incluyen los re-sultados de los ensayos de cobertura realizados sobre una parte del firmwareque interactúa con la configuración del nodo, sensores y actuadores. En total serealizaron 6 tests unitarios que resultaron aprobados y permitieron ensayar laejecución de las funciones específicas de sensores y actuadores mediante el usode polimorfismo, las callbacks de control y la ejecución de funciones de lecturao escritura de sensores, actuadores e información propia del nodo a partir de ladirección del mapa de modbus propio.

TABLA 4.1. Resultados de cobertura de los tests unitarios.

Archivo Líneas Ramas Llamadasejecutadas ( %) ejecutadas ( %) ejecutadas ( %)

node 30,43 100 100actuator 42,86 42,86 75sensor 37,21 44,44 100adc_sensor 10,59 7,69 100i2c_sensor 15,56 14,29 100onoff_sensor 25,86 36,36 100onoff_actuator 75 100 100node_config 66,67 71,43 75

La poca cobertura de las líneas y ramas ejecutadas, que se refleja en el bajo porcen-taje visto en la tabla 4.1 se debe a que ninguno de los setters y getters particularesde cada archivo fueron testeados, dada su simplicidad, ni tampoco se probaronlos casos donde el puntero al sensor o actuador pasado era NULL.

4.3. Ensayos de caja negra

Se realizaron ensayos de caja negra que permitieran verificar el correcto funcio-namiento del firmware y las conexiones MQTT y Modbus, y a su vez validar losrequerimientos. Para tal fin, se utilizó una plantilla de casos de prueba de la pá-gina web Software Testing Help [31], que permite indicar el test a realizar, quienlo diseñó, las pre y post-condiciones, los pasos a seguir, los datos necesarios parallevar a cabo el ensayo, los requerimientos que valida dicho test, entre otras cosas.Los tests a realizar se dividieron en tres módulos:

MN: incluye tests que apuntan a verificar y validar los requerimientos dela comunicación por MQTT con el maestro referidos a mensajes de lectura,configuración y comandos de sensores y actuadores propios de dicho nodomaestro. Asimismo, incluye ensayos asociados a los distintos manejadoresde eventos, la correcta ejecución del watchdog, las funciones de lectura ycontrol de los sensores y la inicialización del nodo y sus dispositivos conec-tados.


SN: incluye tests que apuntan a verificar y validar los requerimientos de lacomunicación por MQTT con el maestro referidos a mensajes de lectura,configuración y comandos de sensores y actuadores de los nodos esclavosy por lo tanto los requerimientos de comunicación vía Modbus entre ellos.Del mismo modo que en el módulo anterior, se ensayan aspectos relacio-nados a los manejadores de eventos, la lectura y control de los sensores,inicialización de los nodos, entre otros.

DPC: incluye tests que apuntan a verificar y validar los requerimientos aso-ciados al sistema de reglas, interfaz de visualización y almacenamiento dedatos y configuraciones.

En total se diseñaron noventa y un casos de test, por lo tanto solo se muestran deforma resumida y a modo de ejemplo algunos de los tests diseñados para cadamódulo en las figuras 4.4, 4.5 y 4.6.

FIGURA 4.4. Ejemplo de casos de test del firmware del nodo maes-tro.

En la figura 4.4 se detallan los siguientes casos:

MN-001: consiste en el envío de un pedido de datos al nodo maestro conuna dirección incorrecta dentro del mapa de Modbus del nodo. En este casose envía la lectura de un dato de tamaño un byte con dirección 5. Si bien estadirección está dentro de la máxima dirección del mapa Modbus del nodo,no coincide con la dirección de inicio de ningún dato válido del sistema. Enese caso se espera una respuesta de tipo ERR por parte del nodo con valor-1.

MN-002: consiste en el envío de un pedido de datos al nodo maestro conuna dirección que supera la máxima dirección posible de su mapa de Mod-bus. Al igual que en el caso anterior, se espera una respuesta de tipo ERRcon valor -1.

MN-003: se trata del envío de un pedido de datos al nodo maestro con unadirección que si bien existe, se encuentra reservada, es decir no es posibleleerla. En este caso se espera una respuesta de tipo ERR con valor -2.

MN-004: se trata del envío de un pedido de datos al nodo maestro de undato cuyo tamaño es incorrecto. Nuevamente, se espera una respuesta detipo ERR con valor -2.

4.3. Ensayos de caja negra 57

FIGURA 4.5. Ejemplo de casos de test del firmware de los nodosesclavos.

En general, los casos que apuntan ensayar la lectura y escritura de parámetrosde los esclavos, son muy similares a los del maestro, por eso en la figura 4.5 sedetallan casos distintos a los anteriores:

SN-020: consiste en la configuración de un dato del nodo esclavo 1 con unadirección incorrecta dentro del mapa Modbus de este. En este caso se envíala configuración de un dato de tamaño un byte con dirección 31. Si bien estadirección está dentro de la máxima dirección del mapa Modbus del nodo,no coincide con la dirección de inicio de ningún dato válido del sistema. Enese caso se espera una respuesta de tipo ERR por parte del nodo con valor1, que indica que el nodo no responde porque no reconoce el comando.

SN-021: consiste en la configuración de un dato del nodo esclavo 1 cuyotamaño es erróneo. Nuevamente se espera una respuesta de tipo ERR convalor 1.

SN-022: se trata de la configuración de un dato del nodo esclavo 1 de formacorrecta. En este caso, se espera una respuesta con el resultado de la lecturaque ejecuta el maestro sobre este valor configurado a modo de indicaciónde que el dato efectivamente fue bien configurado.

SN-023: es un caso muy similar al SN-021, pero se intenta configurar unvalor de un sensor de un nodo esclavo. La respuesta esperada es la mismaque en dicho caso.

En la figura 4.6 se detallan los siguientes casos:

DPC-001: consiste en la recepción de un mensaje de reset desde la cola deRabbitMQ para luego ejecutar una consulta a la base de datos en Post-gresDB que devuelva todas las entradas de los nodos maestro y esclavosque sean configurables, junto con su valor de configuración para luego for-mar los mensajes MQTT pertinentes y enviarlos. El resultado esperado delensayo son N mensajes de MQTT de la forma SB/V1/006037123456/RQ/CFG/nodeid/addr con payload "size,valor".


FIGURA 4.6. Ejemplo de casos de test de los servicios.

DPC-002: caso similar al anterior, pero periódico donde solo se ejecutan con-figuraciones de la fecha y hora de los nodos para evitar corrimientos de losrelojes.

DPC-003: consiste en la consulta a la base de datos de PostgresDB para ob-tener aquellos registros de los mapas de Modbus de los nodos que repre-senten un valor de un sensor o función particular. El resultado esperado delensayo son N mensajes de MQTT de la forma SB/V1/006037123456/RQ/DAT/nodeid/addr con payload "size".

En el diseño de las pruebas como fue posible visualizar en alguna de las figuras,se utilizó la técnica de inyección de fallas para evaluar la respuesta del sistemafrente a casos donde los mensajes enviados por MQTT fueran incorrectos. El en-sayo consiste en enviar a leer, configurar o comandar un registro cuya direccióny/o tamaño son equivocados y verificar que el sistema responde con los mensa-jes de error adecuados. También se utilizaron valores en los extremos para verifi-car que el sistema funciona de forma adecuada. Todas las pruebas que incluyencomunicación mediante MQTT fueron realizados de forma manual mediante lautilización de un broker de la empresa y la herramienta de debug MQTTBox. Lostests sobre el sistema de reglas y la interfaz de visualización, es decir NodeRedy Grafana, se realizaron con la consola de debug del primero y los paneles delsegundo, habiendo precargado los datos mediante el uso de SQL, en cada caso.Ejemplos de las salidas de MQTT y las distintas consultas a las bases de datos sevisualizan en las figuras 4.7, 4.8 y 4.9.

En primer lugar, en la figura 4.7, se visualiza el mensaje de reset por parte delnodo maestro al anunciar su dirección MAC. Luego, en la parte derecha se ventodos los mensajes RQ con sentido al nodo y en la izquierda todas las respuestasde este, es decir los mensajes NY. El primer mensaje RQ enviado es para obtenerel último valor leído del sensor de humedad y recibe como respuesta un valor de69.61 %, el segundo manda a obtener el último valor leído del sensor de tempera-tura recibiendo un valor de 16,95 °C y por último se manda a leer el valor de unsensor conectado al ADC del esclavo 1 que arroja un valor 0.

4.3. Ensayos de caja negra 59

FIGURA 4.7. Resultado de caso de prueba en MQTTBox.

FIGURA 4.8. Resultado de caso de prueba de consulta a Post-gresDB en NodeRed.

En la figura 4.8 se visualiza la salida de debug de la consulta a la base de datos,el primer dato como respuesta a la misma y el tópico y payload armados luego deprocesar dicha respuesta, que luego es enviado por MQTT.


FIGURA 4.9. Resultados del caso de prueba de consulta a InfluxDBen Grafana.

En la figura 4.9 se ven de forma gráfica los valores obtenidos al ejecutar la consultaa InfluxDB de los datos del sensor de temperatura.

4.4. Ensayos de integración y sistema

Por último, se procedió a ensayar el sistema en su totalidad, accediendo a la in-fraestructura de servicios propia y ya con los sensores y actuadores conectados.En las figuras 4.10 y 4.11, se visualizan los distintos componentes del sistemaconectados al broker MQTT de RabbitMQ y el estado del mismo, con el flujo demensajes de MQTT.

FIGURA 4.10. Clientes conectados a MQTT.

En los ensayos se probó el sistema conectado a un esclavo y sin conectar paraverificar el reporte de los distintos mensajes de error en el dashboard de adminis-tración, como se visualiza en la figura 4.12.

4.4. Ensayos de integración y sistema 61

FIGURA 4.11. Estado del broker MQTT.

FIGURA 4.12. Errores arrojados por el sistema ante consultas a no-dos no conectados.

En la figura 4.12 se visualiza, como ante la consulta de los distintos sensores delnodo 1, marcados en la referencia como "1:TIPO_SENSOR, id", el nodo maestrodevuelve un valor 1 indicando que el esclavo con id 1 no responde a las consultaspor Modbus. Lo mismo ocurre en el caso del nodo con id 2.

Asimismo, en la figura 4.13 se visualizan los valores arrojados por el sistema pa-ra los sensores de temperatura, humedad, presión diferencial, profundidad y lasimulación de una alarma de incendios y un ventilador con los botones de laEDU-CIAA y los relés de la CIAA-NXP, respectivamente.

FIGURA 4.13. Valores de los sensores y actuadores en Grafana.

63

Capítulo 5

Conclusiones

En este capítulo se realiza un resumen sobre los conocimientos aplicados, el tra-bajo realizado hasta el momento y se detallan los pasos a seguir próximamente.

5.1. Trabajo realizado

En la presente memoria se documentó la implementación de un prototipo de sis-tema de gestión de edificios. Particularmente se implementó el monitoreo, super-visión y control de temperatura, humedad, presión diferencial, altura de colum-nas de agua, detección de CO, alarma de incendios y medición de característicasde la red eléctrica del edificio, entre otros.

Se desarrolló e implementó satisfactoriamente un prototipo de firmware e infra-estructura de servicios propia, con una arquitectura maestro-esclavo. La imple-mentación no solo permite ahorrar costos de instalación, sino que también per-mite la fácil incorporación de nuevos nodos al sistema con nuevas características,aumentando la capacidad de operación del sistema en cualquier momento. Pre-senta una interfaz de visualización y un sistema reglas y alertas que facilitan ladetección de problemas y el mantenimiento preventivo.

Desde el punto de vista del aseguramiento de la calidad, se realizó una extensadocumentación del plan de trabajo, requerimientos, diseño e implementación defirmware y tests realizados.

Se cumplieron los requisitos en su totalidad, quedando para una segunda etapalas tareas de diseño e implementación de un prototipo de hardware, como asi-mismo pruebas en planta.

Por lo tanto, se concluye que los objetivos planteados al comienzo del trabajohan sido alcanzados satisfactoriamente, habiéndose cumplido con los criteriosde aceptación del sistema final y se han obtenido conocimientos valiosos para laformación profesional del autor.

5.2. Conocimientos aplicados

Durante el desarrollo de este Trabajo Final se aplicaron conocimientos adquiridosa lo largo de los dos años de la Maestría en Sistemas Embebidos. Todas las asigna-turas cursadas aportaron conocimientos necesarios y experiencia para la práctica

64 Capítulo 5. Conclusiones

profesional en el área de los Sistemas Embebidos. Sin embargo, se resaltan a con-tinuación aquellas materias de mayor relevancia para este trabajo:

Gestión de Proyectos en Ingeniería y Gestión de la Tecnología y la Innova-ción: la elaboración de un Plan de Proyecto para organizar el Trabajo Final,facilitó la realización del mismo y evitó demoras innecesarias.

Sistemas Críticos: se aplicaron conceptos de la norma UNE-EN 50128 e IEEE830.

Certificación de sistemas electrónicos: se analizó la certificación UL paracableado de instrumentación ante problemas detectados con un sistema si-milar.

Sistemas Embebidos Distribuidos: se aplicaron conceptos de IoT, edificiosinteligentes e infraestructura de servicios.

Procesamiento de señales: resultaron de utilidad los conceptos de señalescontinuas y discretas y sistemas lineales e invariantes en el tiempo.

Ingeniería de Software en Sistemas Embebidos. se utilizaron técnicas de eli-citación y especificación de requerimientos, patrones de diseño de arqui-tectura, documentación de código fuente, arquitectura y tests, análisis decódigo estático y se utilizó Git como sistema de control de versiones.

Sistemas Operativos de Tiempo Real (I y II): se utilizaron los conocimien-tos adquiridos aplicando FreeRTOS como sistema operativo para el sistemadesarrollado.

Protocolos de Comunicación: se aplicaron los conocimientos obtenidos, es-pecíficamente en los protocolos UART, SPI e I2C y permitió una mejor ymás fácil comprensión sobre la información recopilada acerca de ethernet,el stack TCP/IP lwIP, MQTT, AMQP, RS-485 y Modbus.

Testing de Software Embebido: se aplicaron los conocimientos adquiridosdurante la materia, sobre todo en las áreas de testing unitarios y ensayos desistema y de aceptación.

5.3. Trabajo Futuro

Resulta imprescindible identificar el trabajo futuro, para dar continuidad al es-fuerzo realizado hasta el momento y poder realizar un producto comercialmenteatractivo. A continuación se listan las líneas de trabajo más trascendentes:

Diseñar e implementar un prototipo de hardware tanto para nodos maes-tros como esclavos.

Modificar la librería de MQTT, para incluir certificados SSL, mediante el usode embedded TLS, como asimismo agregar estos certificados a los serviciosde RabbitMQ, NodeRed y Grafana.

Agregar la posibilidad de actualizar el firmware del maestro de forma re-mota.

5.3. Trabajo Futuro 65

Extender el firmware actual para monitorear y controlar sistemas de cale-facción e implementar los protocolos necesarios para integrar sistemas decontrol de accesos actualmente en el mercado.

Diseñar e implementar una aplicación web que suplante el uso de NodeRedque sea más amigable al usuario sin conocimientos de informática o progra-mación, más escalable, pero manteniendo el valor que aporta NodeRed encuanto a facilidad de configuración.

Diseñar e implementar una aplicación de backoffice donde se tenga acce-so a todos los dispositivos de todos los edificios instalados de forma mássencilla.

Asimismo, en un orden de prioridad menor, sería deseable agregar otros proto-colos de comunicación entre los nodos, como por ejemplo BACNet.

67

Apéndice A

Documento de Elicitación deRequerimientos

Esta sección ha sido removida para publicación online ya que el

presente trabajo tiene fines comerciales.

69

Bibliografía

[1] Statista Inc. Global IoT end-user spending worldwide 2017-2025. Visitado el2020-06-29. 2020. URL:https://www.statista.com/statistics/976313/global-iot-market-size/.

[2] Patricio Eleisegui. «Crece con fuerza en la Argentina el fenómeno de lascasas y edificios inteligentes». En: La Vanguardia (2008).

[3] Verified Market Research. Building Management System Market Size AndForecast. Visitado el 2020-06-29. 2018. URL:https://www.verifiedmarketresearch.com/product/building-management-system-market/.

[4] Miriam Barchilón. «Internet de las cosas: cuando todo está conectado». En:iProfesional (2019).

[5] Argentina Green Building Council. LEED. Visitado el 2020-06-29. 2014.URL: http://www.argentinagbc.org.ar/leed/.

[6] Modbus Org. MODBUS over Serial Line Specification and ImplementationGuide V1.02. Visitado el 2020-06-30. 2006. URL:https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf.

[7] Mqtt Org. MQTT Version 3.1.1 OASIS Standard. Visitado el 2020-06-30.2014. URL:http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.

[8] HUBERT ZIMMERMANN.[9] HiveMQ. MQTT Essentials: topics and Best Practices. Visitado el 2020-07-03.

2020. URL: https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/.

[10] Savannah. lwIP - A Lightweight TCP/IP stack - Sumario. Visitado el2020-06-30. 2019. URL: https://savannah.nongnu.org/projects/lwip/.

[11] Amqp Org. AMQP V1.0. Visitado el 2020-06-30. 2011. URL:https://www.amqp.org/sites/amqp.org/files/amqp.pdf.

[12] Docker Inc. Docker docs. Visitado el 2020-07-03. 2020. URL:https://docs.docker.com/.

[13] Raquel Perez.[14] Rodolfo Bertone. Introducción a las Bases de Datos - Fundamentos y Diseño.

Prentince Hall, 2011, págs. 1-8, 203-211.[15] The PostgreSQL Global Development Group. PostgreSQL: The World’s Most

Advanced Open Source Relational Database. Visitado el 2020-07-03. 2020. URL:https://www.postgresql.org/.

[16] Influx Data Inc. Influx Data. Visitado el 2020-07-03. 2020. URL:https://www.influxdata.com/.

[17] W3Schools. SQL Introduction. Visitado el 2020-07-03. 2020. URL:https://www.w3schools.com/sql/sql_intro.asp.

[18] Proyecto CIAA. Computadora Industrial Abierta Argentina. Visitado el2020-07-01. 2014. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

https://www.statista.com/statistics/976313/global-iot-market-size/

https://www.verifiedmarketresearch.com/product/building-management-system-market/

https://www.verifiedmarketresearch.com/product/building-management-system-market/

http://www.argentinagbc.org.ar/leed/

https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

https://savannah.nongnu.org/projects/lwip/

https://www.amqp.org/sites/amqp.org/files/amqp.pdf

https://docs.docker.com/

https://www.postgresql.org/

https://www.influxdata.com/

https://www.w3schools.com/sql/sql_intro.asp

http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start

70 Bibliografía

[19] NXP Semiconductors. FRDM-KL46Z: Freedom Development Platform forKinetis® KL3x and KL4x MCUs. Visitado el 2020-07-01. 2020. URL:https://www.nxp.com/design/development-boards/freedom-development-boards/mcu-boards/freedom-development-platform-for-kinetis-kl3x-and-kl4x-mcus:FRDM-KL46Z.

[20] Amazon Web Services Inc. FreeRTOS Real-time operating system formicrocontrollers. Visitado el 2020-07-01. 2020. URL:https://www.freertos.org/.

[21] Doxygen. Doxygen. Visitado el 2020-07-15. 2020. URL:https://www.doxygen.nl/index.html.

[22] Asociación Española de Normalización y Certificación. UNE-EN 50128.Asociación Española de Normalización y Certificación, 2012.

[23] Bruce Powel Douglass. Design Patterns for Embedded Systems in C: AnEmbedded Software Engineering Toolkit. Newnes, 2011, págs. 85-95.

[24] Leandro Francucci.[25] Leandro Francucci.[26] Embedded Experts. FreeMODBUS A portable MODBUS ASCII/RTU and

TCP implementation. Visitado el 2020-07-01. 2020. URL:https://www.embedded-experts.at/en/freemodbus/about/.

[27] Saleae Inc. Saleae - Especificaciones técnicas. Visitado el 2020-07-15. 2020.URL: https://www.saleae.com/es/.

[28] Underwriters Laboratories.[29] ThrowTheSwitch Org.[30] GNU.[31] Software Testing Help. Sample Test Case Template with Test Case Examples.

Visitado el 2020-07-13. 2018. URL:https://www.softwaretestinghelp.com/test-case-template-examples/.

https://www.nxp.com/design/development-boards/freedom-development-boards/mcu-boards/freedom-development-platform-for-kinetis-kl3x-and-kl4x-mcus:FRDM-KL46Z



https://www.freertos.org/

https://www.doxygen.nl/index.html

https://www.embedded-experts.at/en/freemodbus/about/

https://www.saleae.com/es/

https://www.softwaretestinghelp.com/test-case-template-examples/

sistema de gestión de edificios - laboratorios.fi.uba.ar

Documents