UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Sistema de monitoreo para control decadena de frío

Autor:Lic. Roberto Compañy

Director:Esp. Bioing. Jerónimo La Bruna (FIUBA)

Jurados:Esp. Ing. Leonardo Carducci (FIUBA)

Esp. Ing. Gonzalo Sanchez (FF.AA, FIUBA)Esp. Ing. Tomás Porreca (IUA)

Este trabajo fue realizado en la Ciudad de Mendoza, entre marzo de 2018 ydiciembre de 2018.

III

Resumen

La presente memoria describe el desarrollo e implementación de un prototipoque permite mejorar los controles sobre la cadena de frío de los medicamentos.Este prototipo ha sido diseñado para incluirse como un nuevo servicio a ofrecer

por el Colegio Farmacéutico de Mendoza para sus farmacias asociadas.

Para la realización del sistema se aplicaron conceptos de gestión de proyectos yen cuanto al desarrollo del código se utilizaron técnicas de ingeniería de software

como patrones de diseño, control de versiones de código, modularización,integración continua, protocolos de comunicación, test unitario, entre otros.

V

Agradecimientos

A mi esposa Carolina, por el sacrificio enorme que hizo por mi para poder com-pletar esta especialización.

A mi hermano Claudio, por su ayuda imprescindible para este trabajo.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 52.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Propuesta de implementación . . . . . . . . . . . . . . . . . . . . . . 52.3. Tecnología utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Diseño e Implementación 113.1. Componentes de la Solución . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Mensajería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.3. Concentrador . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.4. APP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.5. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.6. Software para simulación . . . . . . . . . . . . . . . . . . . . 19

4. Pruebas y Resultados 214.1. Simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1. Pruebas en nodo virtual . . . . . . . . . . . . . . . . . . . . . 214.1.2. Pruebas en gateway virtual . . . . . . . . . . . . . . . . . . . 224.1.3. Pruebas de comunicación entre gateway virtual y APP Server 23

4.2. Ensayos sobre dispositivos físicos . . . . . . . . . . . . . . . . . . . . 244.2.1. Pruebas de comunicación entre el Nodo y Gateway físicos . 26

4.3. Pruebas sobre sensores de temperatura . . . . . . . . . . . . . . . . 274.4. Prueba de estrés del sistema completo . . . . . . . . . . . . . . . . . 274.5. Resultados de pruebas en campo . . . . . . . . . . . . . . . . . . . . 28

5. Conclusiones 295.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Bibliografía 31

IX

Índice de figuras

1.1. Utilización de heladeras en farmacias . . . . . . . . . . . . . . . . . 2

2.1. Diagrama en bloque del sistema . . . . . . . . . . . . . . . . . . . . 72.2. Distribución de pines LPC1114 . . . . . . . . . . . . . . . . . . . . . 72.3. Entorno de trabajo MBED . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Diagrama activity on node . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1. Interacción simple de la mensajería . . . . . . . . . . . . . . . . . . . 123.2. Interacción compleja de la mensajería . . . . . . . . . . . . . . . . . 133.3. Interacción de la mensajería con retransmisión entre nodos . . . . . 133.4. Interacción de mensajes cuando el gateway se reconfigura . . . . . 17

4.1. Mensajes al simular el nodo virtual . . . . . . . . . . . . . . . . . . . 224.2. Mensajes al simular el gateway virtual . . . . . . . . . . . . . . . . . 234.3. Mensajes al simular el gateway virtual configurado con el APP Server 244.4. Primer prototipo del nodo . . . . . . . . . . . . . . . . . . . . . . . . 254.5. Modelo 3D del PCB diseñado . . . . . . . . . . . . . . . . . . . . . . 254.6. Raspberry Pi conectada con el módulo de radio frecuencia . . . . . 264.7. Prueba completa del sistema . . . . . . . . . . . . . . . . . . . . . . . 264.8. Reporte generado tras prueba de campo . . . . . . . . . . . . . . . . 28

XI

Índice de Tablas

3.1. Tipos de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1. Registro de lecturas con distintos sensores . . . . . . . . . . . . . . . 27

XIII

Dedicado a mis hijas, Virginia y Melina.

1

Capítulo 1

Introducción General

En este capítulo se expone la problemática que motivó la realización del presentetrabajo, los procedimientos utilizados por las farmacias para cumplir con el con-trol de la cadena de frío y el enfoque elegido para desarrollar un prototipo queofrece una solución integradora utilizando sistemas embebidos.

1.1. Motivación

Existen muchos productos que requieren de una cadena de frío para su manipu-lación, esto quiere decir que se debe establecer y controlar su temperatura desdeque salen de fábrica hasta que son transportados a su destino final. En esta ca-tegoría se encuentran los medicamentos, los cuales son muy costosos y algunosrequieren bajas temperaturas desde su fabricación hasta la dispensa, como son lasvacunas para garantizar su potencia inmunizante. Vale destacar que el consumi-dor de estos productos es el ser humano y, si no los recibe en buenas condiciones,se puede ver comprometida su salud.

Uno de los eslabones de esta cadena de frío son las farmacias, las cuales actual-mente usan heladeras comunes para conservar estos medicamentos. Para podercontrolar la temperatura interna, se instalan termómetros por dentro y periódi-camente se registra de forma manual la temperatura en una planilla. Para estoexisten normas [1] que detallan procedimientos y también un marco legal [2] quelo regula.

En la figura 1.1 se puede apreciar la forma de almacenar los medicamentos, en lacual es importante la ubicación de los mismos según la temperatura requerida.También se puede visualizar un mecanismo ante contingencias (como un cortede suministro eléctrico prolongado), en las cuales se deben bajar los paquetescongeladores del freezer al habitáculo para mantener el frío por más tiempo, yluego subir los medicamentos más críticos, como por ejemplo las vacunas.

Algo importante a destacar es que en el interior se encuentran distribuidos dostermómetros que tienen máximos y mínimos. Estos tienen la característica de de-jar una marca con la temperatura máxima y mínima registrada, además de indicarla actual. Justamente esto es para verificar si en algún momento se comprometióla cadena de frío.

La legislación provincial exige realizar las siguientes tareas:

El farmacéutico debe tomar 2 registros diarios de la temperatura de las he-laderas y verificar que se encuentren entre 2oC y 8oC.

2 Capítulo 1. Introducción General

FIGURA 1.1: Utilización de heladeras en farmacias

Debe contar con un plan de contingencia (falla de heladeras, corte de sumi-nistro eléctrico, entre otros).

Debe verificar la calibración de los termómetros periódicamente (ésta acciónse realiza durante las visitas del ente gubernamental de control, el que llevaun termómetro de referencia y verifica los instalados en las heladeras).

Teniendo en cuenta lo mencionado, se detectan los siguientes problemas:

La cantidad de veces diarias que se registra la temperatura no garantizaque se detecte a tiempo si la cadena de frío de los medicamentos se viocomprometida.

Cuando la farmacia cierra por tiempos más prolongados, como fines de se-mana largos o vacaciones, está más propensa a comprometer la cadena defrío ya que durante dicho periodo no se toman registros de temperatura.

1.2. Objetivos y alcance 3

Los productos industriales disponibles en el mercado1 no constituyen una solu-ción integradora ya que deben conectarse a otros sistemas y requieren el desarro-llo de las interfaces correspondientes.

En vista de lo anterior, se desarrolló un prototipo para ofrecer una solución in-tegradora que permita monitorizar el control de la cadena de frío de los medica-mentos cuando estos se encuentran en las farmacias. A su vez, el mismo se pensópara incluir como un nuevo servicio a ofrecer por COFAM (Colegio Farmacéuticode Mendoza2 ), con el objeto de mejorar los controles sobre la cadena de frío ensus farmacias asociadas y como estrategia para lograr un valor agregado sobre elresto.

Como principales ventajas se puede mencionar:

En caso de verse comprometida la cadena de frío, serán advertidos de formainmediata los responsables de la farmacia sin importar dónde se encuen-tren. En los casos más complejos, se podrá avisar a terceros para ir a retirarlos medicamentos y así evitar su pérdida.

Garantizar el control de la temperatura de las heladeras bajo un procedi-miento sistemático y automatizado.

Llevar un registro electrónico con la temperatura de las heladeras.

1.2. Objetivos y alcance

El objetivo principal fue desarrollar una solución completa, que permita por unlado: monitorear la temperatura interna de las heladeras en cada farmacia y tam-bién de forma centralizada; emitir alertas sonoras y visuales de forma local, ade-más de notificaciones por email cuando dicha temperatura esté fuera del rangoprevisto.

En la presente solución no se incluye el desarrollo de un dashboard web admi-nistrado que permita visualizar en línea, y de formar centralizada, el estado de lacadena de frío de cada farmacia, consultar el histórico de incidentes, entre otrascaracterísticas; ni tampoco el desarrollo del PCB para la electrónica.

1 http://srcsl.com/catalogo-de-productos/https://www.novus.com.br/catalogos/layout_folheto.asp?ProdutoID=739171

2 Organización sin fines de lucro que agrupa a farmacias y farmacéuticos.

5

Capítulo 2

Introducción Específica

En este capítulo se enuncian los requerimientos relevados para el desarrollo delsistema, se detalla el enfoque elegido para satisfacerlos, las tecnologías imple-mentadas y la planificación que guio el desarrollo del prototipo.

2.1. Requerimientos

Los requerimientos de la solución fueron:

Proveer un dispositivo sensor de temperatura que opere en el rango de 1oCa 10oC.

Sensar y registrar la temperatura periódicamente cada 1 minuto.

Proveer una interfaz para establecer un rango de alarma en grados centí-grados para cada sensor.

Generar alertas locales sonoras y visuales cuando la temperatura se encuen-tre fuera del rango establecido.

Notificar a COFAM periódicamente, cada 5 minutos, el estado del sistemade control de frío (sistema activo y temperaturas registradas).

Generar alertas vía email desde COFAM cuando la temperatura se encuen-tre fuera del rango establecido o se pierda la conexión con el sistema decontrol.

Permitir localmente la consulta de la temperatura de las heladeras y generarun reporte de los registros en un periodo de tiempo.

2.2. Propuesta de implementación

Para abordar una solución integral a la problemática planteada y satisfacer los re-querimientos enunciados, se propuso un sistema de varios componentes de hard-ware y software.

En cuanto al hardware, los componentes propuestos fueron:

Nodo: es el dispositivo que se ubica junto a la heladera y consta de: un mi-crocontrolador, un módulo de radiofrecuencia y sensores de temperatura.

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

Estos últimos se encuentran conectados con un cable extenso que les per-mite ubicarlos cómodamente dentro de la heladera. La alimentación es abaterías y al transmitir de forma inalámbrica, es de fácil instalación sin re-querir de una red eléctrica ni de datos. Además, cuenta con un buzzer eindicadores lumínicos para indicar las alertas.

Gateway: es un dispositivo con gran capacidad de procesamiento que porun lado cuenta con un módulo de radiofrecuencia para comunicarse conlos nodos, y por otro lado con una interfaz ethernet la cual le permite seraccedido desde la red local y también conectarse a Internet para comuni-carse con el servidor en COFAM. Este dispositivo registra las temperaturasrecibida de los nodos y permite la generación de reportes con dichos datos.

Servidor: ubicado en la infraestructura de COFAM, es un servidor web quealoja web services y base de datos para centralizar la información.

En cuanto al software, los componentes propuestos fueron:

Firmware: es el software que ejecuta el nodo y realiza propiamente la lec-tura de los sensores. Implementa una mensajería para comunicarse con elconcentrador.

Concentrador: es un sistema cliente-servidor que implementa dos interfacesde comunicación. Por un lado se comunica con los nodos y por otro lado conuna aplicación denominada APP Server. Este componente se ejecuta sobreel hardware denominado gateway.

APP Server: es un sistema web que recibe información del concentrador,la procesa y luego provee reportes para el farmacéutico. Este componentetambién se ejecuta sobre el hardware denominado gateway.

Web services: es un sistema web que recibe y registra de forma centraliza-ra la información por los APP Server de cada farmacia. En caso de existiralertas, este componente es quien envía los correos electrónicos.

En la figura 2.1 se presenta el diagrama en bloques del sistema, en donde se puedeobservar la interacción entre los distintos componentes físicos del proyecto.

2.3. Tecnología utilizada

Para el desarrollo de la solución, se articularon diversas tecnologías de hardwarey software que facilitaron la creación del prototipo.

Para tomar la decisión sobre qué componente o tecnología utilizar en cada caso,se tuvo en cuenta principalmente la experiencia ya obtenida en aplicaciones an-teriores y para casos puntuales se realizó un análisis previo con las alternativasdisponibles. Por ejemplo, para el caso del sensor de temperatura se analizó quefuera de bajo costo y con la precisión dentro del margen requerido.

A continuación se enuncian las tecnologías de hardware utilizadas:

Microcontrolador LPC1114

Para utilizar en el nodo se optó por el microcontrolador LPC1114 [3] porque sedispone de varias unidades del mismo, ha sido utilizado en proyectos anteriores,

2.3. Tecnología utilizada 7

FIGURA 2.1: Diagrama en bloque del sistema

y cumple con los requisitos mínimos requeridos para este componente. En la fi-gura 2.2 se muestra la distribución de los pines y las principales característicasson las siguientes:

Procesador ARM Cortex-M0.

Opera a frecuencias de hasta 50 MHz e incorpora un oscilador interno.

Memoria de programación flash en chip de 32 kB.

4 kB SRAM.

22 pines de E / S de propósito general (GPIO).

ADC de 10 bits con multiplexación de entrada entre 5 pines.

Voltaje de alimentación de 3,3 V (1,8 V a 3,6 V).

Número de serie único del dispositivo para identificación.

Puertos UART, controlador SPI (con características SSP y capacidades FIFOy multiprotocolo) y una interfaz I2C entre otros.

FIGURA 2.2: Distribución de pines LPC1114

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

Modulo de radiofrecuencia NRF24l01

Para realizar las comunicaciones inalámbricas se eligió el transceptor NRF24l01[4] dadas sus buenas prestaciones y también porque su funcionamiento ya es fa-miliar. Este módulo resuelve por completo los problemas típicos de comunica-ción, como colisiones o paquetes incompletos, y las principales características sonlas siguientes:

Banda ISM de 2,4 GHz.

Interfaz SPI.

Velocidad de datos de hasta 2 Mbps.

Operación a muy baja potencia (11,3 mA TX a 0 dBm de potencia de salida /12,3 mA RX a una velocidad de datos de 2 Mbps). 900 nA estando apagadoy 22 mA en espera.

Distancia de alcance de hasta 40 mts en línea de vista.

Voltaje de alimentación de 1,9 V a 3,6 V.

Sensor de temperatura DS18B20

En cuanto al sensor, se optó por el DS18B20 [5], ya que se pueden conectar variosen línea utilizando el protocolo one wire, y opera en el rango de temperatura de−55 ◦C a 125 ◦C con una resolución de 9 a 12 bits configurable y una precisión de+/- 0.5 ◦C entre los −10 ◦C y 85 ◦C.

RaspBerry Pi

Para utilizar como gateway se optó por la RaspBerry Pi [6] dado su relación costo/ beneficio y que cuenta con la posibilidad de correr el concentrador y el APPServer sobre el mismo hardware. Sus principales características son:

Procesador quad-core ARM Cortex-A7 CPU.

Frecuencia de trabajo a A 900 MHz.

1 GB RAM.

100 Base Ethernet.

4 USB ports.

40 GPIO pins.

Micro SD card slot.

A continuación se enuncian las tecnologías de software utilizadas:

Plataforma de desarrollo mbed

Para el firmware se utilizó Mbed OS [7] que es una plataforma de prototipa-do rápido y experimentación para microcontroladores ARM Cortex-M3 y ARMCortex-M0 de 32 bits. Permite desarrollar de forma modular e incluye TLS, redes,almacenamiento y controladores. También provee una biblioteca de librerías enlínea en donde se encuentran las requeridas para este proyecto. En la figura 2.3se puede apreciar el entorno de trabajo que utiliza.

2.4. Planificación 9

FIGURA 2.3: Entorno de trabajo MBED

Raspbian OS

Se optó por el sistema operativo Raspbian [8] el cual se basa en la distribuciónDebian de GNU/Linux para correr sobre la RaspBerry PI. Consta de todas lascaracterísticas del sistema operativo en el cual se basa, y se encuentra optimizadopara la arquitectura de éste hardware. Además, cumple con las capas de softwarerequeridas para el gateway y el componente APP Server de este proyecto.

Java EE

La plataforma de programación Java EE [9] permite desarrollar y ejecutar soft-ware de aplicaciones en el lenguaje de programación Java. Utiliza arquitecturasde N capas distribuidas y se apoya ampliamente en componentes de softwaremodulares ejecutándose sobre un servidor de aplicaciones.

PrimeFaces

El framework PrimeFaces [10] es una biblioteca de componentes para JavaSer-ver Faces (JSF) de código abierto que cuenta con un conjunto de componentesenriquecidos que facilitan la creación de las aplicaciones web.

2.4. Planificación

La planificación de este proyecto se ordenó de la siguiente forma:

1. Planificación general: se realizó un análisis de beneficios frente a distintasalternativas, también un análisis de factibilidad, un relevamiento de interésgeneral sobre el proyecto y las primeras reuniones con el ente gubernamen-tal de control.

2. Investigación: se analizó y determinó que tipo de sensor se iba a utilizar ycomo implementar la redundancia.

3. Diseño y desarrollo: se ideó y codificó la mensajería a utilizar entre nodos,gateway y web services. También las piezas de software que corren sobre

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

cada componente y la interacción entre los mismo. Se contempló desde unprincipio que el desarrollo de cada uno se pueda hacer en paralelo.

4. Validación, integración y simulación: se realizaron pruebas de concepto yfuncionalidad sobre cada componente por separado. Se integraron todaslas piezas de software y se simuló el funcionamiento de todo el sistema enconjunto.

5. Procesos finales: se elaboró el manual de usuario, un diagrama de instala-ción y la presente memoria.

En la figura 2.4 se puede apreciar el activity on node, donde queda visualmenterepresentada la secuencia de las tareas y también aquellas que se pueden realizaren paralelo. La planificación como tal, permitió que ante el bloqueo en el desarro-llo del nodo, se continuara con el gateway y el servidor para recién luego volvera encarar el nodo. Desde un principio se advirtió que la mensajería, la cual se de-talla en la sección 3.1.1, era algo crucial para el desarrollo del sistema y por ellose planificó resolverlo en etapas tempranas.

FIGURA 2.4: Diagrama activity on node

11

Capítulo 3

Diseño e Implementación

En este capítulo se detalla el diseño de la arquitectura del sistema en todos suscomponentes. Se menciona el motivo de elección en cada caso y la implementa-ción correspondiente.

3.1. Componentes de la Solución

En cuanto al diseño del firmware y software, desde un principio se encaró todoel desarrollo para que pueda ser implementado en distintas plataformas (linux,windows, mbed OS y sAPI CIAA), ya que hay funcionalidades comunes tantopara el nodo como para el gateway, por ejemplo la gestión de la mensajería.

Teniendo en cuenta la implementación multiplataforma, en una primera instanciase desarrolló el código en C para facilitar la compilación. Pero se presentaronproblemas al integrar en linux las bibliotecas del NRF24L01+ y propiamente enla plataforma Mbed OS, ya que en ambos casos se utiliza C++. Por lo anterior,se recodificaron algunos módulos para que el proyecto pueda ser compilado enC++ e integrar las bibliotecas.

Para organizar la información de los logs, se implementaron distintos niveles dedebug de forma tal que se pueda configurar el nivel de detalle a mostrar.

La arquitectura del sistema contempla que las reglas de negocio se ejecuten en elgateway o en el APP Server, flexibilizando así la electrónica requerida y permi-tiendo adaptarlo para distinto hardware.

3.1.1. Mensajería

Para la interacción requerida por el sistema se desarrolló una mensajería apropia-da, la cual define los mensajes disponibles y la función que cumple cada uno. Paraesto, se tuvo en cuenta conceptos utilizados en distintos protocolos existentes, loque permitió hacerla más robusta y confiable. El tamaño máximo del mensaje secondicionó al payload de la trama que permite el driver del modulo de radio fre-cuencia (treinta y dos bytes), para simplificar la comunicación y no tener que unirpaquetes para luego procesarlos.

El mensaje se compone de un encabezado y un grupo. En el primero se describeinformación propia de la comunicación e identifica el grupo adjunto. El segundo,que se identifica con un GrupoID, está compuesto por uno o varios datos relacio-nados según la acción que realiza.

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

En la tabla 3.1 se mencionan los tipos de paquetes definidos, también quién loemite y lo recibe, y finalmente el identificador de grupo asignado.

TABLA 3.1: Tipos de mensajes

Mensaje Emisor Receptor GrupoID

Solicitar Configuración Nodo Gateway 2Establecer Configuración Gateway Nodo 3Datos Sensados Nodo Gateway 4Mensaje Recibido Gateway Nodo 1

A continuación se menciona la función que cumple cada mensaje:

Solicitar Configuración: es el primer mensaje generado por el nodo al ac-tivarse. Su objetivo es presentarse ante los gateway cercanos solicitando laconfiguración asignada.

Establecer Configuración: cuando el gateway recibe el mensaje «SolicitarConfiguración», genera un mensaje teniendo en cuenta los parámetros es-tablecidos y le devuelve la configuración correspondiente.

Datos Sensados: cada vez que el nodo realiza una lectura de los sensores,envía los datos al gateway configurado.

Mensaje Recibido: cuando el gateway recibe el mensaje «Datos Sensados»,confirma la recepción al nodo que lo envió.

En la figura 3.1 se puede apreciar cómo es la interacción y secuencia más simple.

FIGURA 3.1: Interacción simple de la mensajería

La mínima interacción de mensajes entre el nodo y el gateway es la siguiente: enel inicio de la comunicación, el nodo «Solicita Configuración» al gateway iden-tificándose con un número de serie interno; el gateway le responde «EstablecerConfiguración» con los datos correspondientes en donde lo identifica con un nú-mero de nodo; luego, el nodo se configura y a partir de ahí empieza a enviar«Datos Sensados» con la información obtenida del sensor; finalmente, el gatewayconfirma con «Mensaje Recibido» la recepción de cada uno de los mensajes reci-bidos.

Es de destacar que los únicos mensajes que se confirman con «Mensaje Recibido»son los que incluyen los datos sensados, y esto es para indicarle al nodo que no

3.1. Componentes de la Solución 13

los retransmita. El mensaje «Solicita Configuración» se confirma con el de «Esta-blecer Configuración» y, si este no le llegara al nodo, entonces vuelve a solicitarconfiguración.

Esta es la interacción de mensajes más simple, pero según el entorno se puederequerir reenvío de mensajes como se aprecia en la figura 3.2

FIGURA 3.2: Interacción compleja de la mensajería

La mensajería también contempla que los nodos pueden recibir mensajes de otrosnodos y luego retrasmitirlos al gateway. Esta característica permite que nodosmuy alejados del gateway, o que su visibilidad se vea muy obstruida, puedancomunicarse de igual manera utilizando otros nodos como retransmisores de susmensajes. Esta interacción se aprecia en la figura 3.3

FIGURA 3.3: Interacción de la mensajería con retransmisión entrenodos

Para evitar el reprocesamiento de un mensaje cuando este ha sido reenviado, sevalida la secuencia del mismo utilizando el atributo IDmensaje y, en caso de reci-birse uno que es anterior al último procesado, se descarta considerándolo un ecopor estar fuera de secuencia.

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

La misma mensajería se utiliza en los dos esquemas de comunicación, entre nodo-gateway y gateway-APP Server, para realizar el procesamiento en el gateway oAPP Server según convenga.

Para gestionar la mensajería, se aplicó el patrón de diseño Productor/Consumi-dor con el objeto de separar funcionalmente la recepción, el procesamiento y elenvío de los mensajes.

Las funciones encargadas de recibir, procesar y enviar mensajes se ejecutan enhilos separados, como se muestra en el algoritmo 3.1. Para comunicar estos pro-cesos se utilizaron dos colas circulares, como se muestra en el algoritmo 3.2

1 . . .2 i f ( p thread_create (&pt_comunicacion_consumidor , NULL,

comunicacion_consumidor , NULL) != 0 ) {3 p r i n t f ( "ERROR: No se pudo c r e a r e l pthread para ’

comunicacion_productor ’\ r\n" ) ;4 re turn 5 ;5 }6

7 i f ( p thread_create (&pt_comunicacion_productor , NULL,comunicacion_productor , NULL) != 0 ) {

8 p r i n t f ( "ERROR: No se pudo c r e a r e l pthread para ’comunicacion_productor ’\ r\n" ) ;

9 re turn 5 ;10 }11

12 i f ( p thread_create (& pt_comunicacion_procesar , NULL,comunicacion_procesar , NULL) != 0 ) {

13 p r i n t f ( "ERROR: No se pudo c r e a r e l pthread para ’pt_comunicacion_procesar ’\ r\n" ) ;

14 re turn 5 ;15 }16 . . .

ALGORITMO 3.1: Creación de hilos

1 . . .2 i f ( l e e r B u f f e r ( buf fer_rx , paquete_recibido , L_PAQUETE) ) {3 i f ( mensajeria_desarmar ( &paq , paquete_rec ib ido ) ) {4 p r i n t f ( "NO OK mensajeria_desarmar : r= %d \n\n" , r ) ;5 continue ; // no proceso6 } e l s e7 i f ( debug > 1)8 p r i n t f ( "OK mensajeria_desarmar : paq . Encabezado . Ident i f icadorGrupo

= %d \n\n" , paq . Encabezado . Ident i f icadorGrupo ) ;9

10 i f ( paq . Encabezado . VersionFirmware != _VersionFirmware )11 continue ;12 . . .

ALGORITMO 3.2: Comunicación entre procesos

En la librería de la mensajería se definieron funciones globales para armar y des-armar los mensajes, las cuales se llaman después de recibir y antes de enviar unpaquete; y estas validan, entre otras cosas, que la versión del paquete y el firm-ware estén soportados.

De forma privada, se definieron funciones para armar y desarmar el encabezadoy también para cada uno de los grupos definidos. Todas las funciones devuelvenun código de error en el caso que se produzca un problema, como por ejemplo delongitud incorrecta o grupos inválidos.

3.1. Componentes de la Solución 15

3.1.2. Firmware

Los nodos implementan un estado el cual puede ser: enINICIADO, enCONFIGU-RANDO, enCONFIGURADO y enSENSADO. La transición entre éstos se realiza através de una máquina de estados y, para cada uno ellos, existen distintas accionesha realizar. Independientemente de lo anterior, la acción de retrasmitir mensajespendientes se realiza en todos los estado.

Existe una cola de los mensajes enviados porque, en el caso de no recibir con-firmación periódicamente, los mensajes se siguen retrasmitiendo. Esta cola tieneuna dimensión establecida y, en el caso de llenarse, el nodo se resetea y vuelve apedir configuración. Esto puede suceder cuando el gateway se desconecta y dejade confirmar los mensajes. En el algoritmo 3.3 se puede apreciar la función pararegistrar mensajes en la cola.

1 i n t 8 _ t2 comunicac ion_reg is t rar ( i n t 1 6 _ t IDMensaje ,

i n t 8 _ t segActuales , char ∗ paquete_enviado )3 {4 i n t 8 _ t resu l tado = 1 0 ; // Cola de mensajes

pendientes l l e n o5

6 i n t 8 _ t i =0 ;7 while ( i < L_COMUNICACION_PENDIENTES ) {8 // p r i n t f ( " i = %d \n\n " , i ) ;9 i f ( mensajesPendientes [ i ] . IDMensaje == 0 ) {

10 mensajesPendientes [ i ] . IDMensaje = IDMensaje ;11 mensajesPendientes [ i ] . segTrasmitido = segActuales ;12 strncpy ( mensajesPendientes [ i ] . paquete_enviado ,

paquete_enviado , 33) ;13 resu l tado = 0 ;14 break ;15 } e l s e {16 i f ( mensajesPendientes [ i ] . IDMensaje == IDMensaje ) {17 resu l tado = 1 1 ; // Mensaje ya guardado en l a

co la18 break ;19 }20 }21 i ++;22 }23

24 re turn resul tado ;25 }

ALGORITMO 3.3: Registrar mensajes en la cola

El procesamiento del mensaje, indistintamente del estado en el que se encuentreel nodo, sigue la siguiente secuencia de funciones:

1. comunicacion_no_para_mi: se analiza si el destinatario del mensaje es el nodoque lo está procesando, para esto se vale de la configuración nodoID. En elcaso que no sea así, se disminuye el timeout del mensaje y se reenvía.

2. comunicacion_mensaje_recibido: si se trata de una confirmación «Mensaje Re-cibido», se quita de la cola de mensajes enviados para luego no retrasmitirlo.

De acuerdo el estado en el que se encuentra el nodo, se realizan las siguientesacciones:

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

enINICIADO: se enviá el paquete «Solicitar Configuración» y se encola pararetrasmitirlo hasta que se reciba la configuración.

enCONFIGURANDO: si se recibe el mensaje «Establecer Configuración» seconfigura el nodo, se inicializa el hardware en donde se detectan los senso-res conectados y se configura para trasmitir según los intervalos de tiempoestablecido. Luego se cambia al estado enCONFIGURADO.

enCONFIGURADO: se chequean cada uno de los sensores conectados paradeterminar si en alguno corresponde tomar una lectura, en tal caso se pasaal estado enSENSADO.

enSENSADO: se analizan los sensores que tienen lecturas pendientes detrasmitir y se genera un mensaje «Datos Sensados» por cada uno. Luegose vuelve al estado enCONFIGURADO.

Finalmente, de forma periódica y según el tiempo establecido se revisa la colade los mensajes enviados para retrasmitir los mensajes que no fueron confirma-dos. Esto se realiza en la función comunicacion_tomar_pendientes() y el algoritmoutilizado se puede ver en 3.4

1 i n t 8 _ t2 comunicacion_tomar_pendientes ( i n t 8 _ t segActuales

, char ∗ paquete_pendiente )3 {4 i n t 8 _ t resu l tado = 1 3 ; // No hay mensajes

pendientes5

6 i n t 8 _ t i =0 ;7 while ( i < L_COMUNICACION_PENDIENTES ) {8 i f ( mensajesPendientes [ i ] . IDMensaje != 0 ) {9 i n t 8 _ t d i f e r e n c i a = ( mensajesPendientes [ i ] . segTrasmit ido >

segActuales ) ? mensajesPendientes [ i ] . segTrasmitido − segActuales :segActuales − mensajesPendientes [ i ] . segTrasmitido ;

10 i f ( d i f e r e n c i a >= _ s e g R e t r a s m i t i r ) {11 strncpy ( paquete_pendiente , mensajesPendientes [ i ] .

paquete_enviado , 33) ;12 mensajesPendientes [ i ] . segTrasmitido = segActuales ;13 resu l tado = 0 ;14 break ;15 }16 }17 i ++;18 }19

20 re turn resul tado ;21 }

ALGORITMO 3.4: Revisar cola de mensajes pendientes

Se consideró utilizar al menos tres sensores como redundancia para detectar cuan-do fallan. De esta forma, si uno de los sensores indica un valor muy distinto a losotros dos entonces se puede asumir que está dañado. Luego en el reporte genera-do, se indica un promedio de los tres cuando registran temperaturas similares. Seadvierte que al no utilizarse distintas tecnologías, los tres podrían ser afectadospor ejemplo por interferencia electromagnética.

3.1. Componentes de la Solución 17

3.1.3. Concentrador

En el gateway se ejecuta el concentrador que tiene dos extremos de comunica-ción, por un lado intercambia mensajes con los nodos a través del módulo deradiofrecuencia; y por otro lado mantienen una conexión de red por socket TCPcon el APP Server por donde reciben la configuración establecida por el usuario ytambién notifican las temperaturas sensadas.

A diferencia de los nodos, los gateway no retrasmiten mensajes que no son paraellos y esto es porque se asume que si el nodo ya recibió la configuración de un ga-teway, quiere decir que se puede comunicar. Cuando por algún motivo esto no secumpla, por ejemplo cambia el entorno luego que el nodo se configuró, entonceslos mensajes dejaran de ser confirmados y este último terminará reiniciándose

De acuerdo el estado en el que se encuentra el gateway, se realizan las siguientesacciones:

egINICIADO: cuando se inicia el gateway, se puede dar la posibilidad quevenga de un reinicio involuntario y por ello es que se envía el mensaje «Es-tablecer Configuración» sin definir un nodo de destino y eso es interpretadopor los nodos que tienen ese gateway asignado que deben configurarse, lue-go pasa al estado egPROCESANDO. Esta secuencia se visualiza en la figura3.4

egPROCESANDO: este es el estado normal en el que se encuentra un gate-way y los tipos de mensajes que espera son los de «Solicitar Configuración»y «Datos sensados». Para el caso del primero, prepara el mensaje y le en-vía la configuración correspondiente. Para el caso del segundo, confirmala recepción del mensaje y luego lo envía al APP Server para registrar esatemperatura y que luego sea informada a COFAM.

FIGURA 3.4: Interacción de mensajes cuando el gateway se recon-figura

Como ya se mencionó, el otro canal de comunicación que tiene el gateway es conel APP Server y es responsabilidad del gateway reconectar si se pierde el vínculo.En el algoritmo 3.5 se visualiza el bucle para siempre reconectar si fuera necesario.

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

1 void∗2 comunicacion_APPserver ( void∗ parametros )3 {4 char tmp [L_PAQUETE] = " " ;5 while ( 1 ) {6 i f ( handlerSig != 0 && handlerSig != 100 )7 break ;8

9 i f ( handlerSig == 100 )10 handlerSig = 0 ;11

12 p r i n t f ( " Creando conexion con e l APP Server \r\n" ) ;13 i f ( tcp_openClient ( _PUERTO_, _IP_ ) ) {14 p r i n t f ( "ERROR tcp_openClient \r\n" ) ;15 usleep (1000000) ;16 continue ;17 }18 i f ( tcp_connect ( ) ) {19 tcp_closeFD ( ) ;20 tcp_closeSOC ( ) ;21 p r i n t f ( "ERROR tcp_connect \r\n" ) ;22 usleep (1000000) ;23 continue ;24 }25 . . .

ALGORITMO 3.5: Reconexión automática con APP Server

3.1.4. APP Server

El APP Server corre sobre la plataforma Java EE y para el entorno web se utili-za el framework PrimeFaces sobre Java Server Faces. Este componente es quienprocesa y presenta la información para generar el reporte.

Se aplicó un diseño de desarrollo en capas1 en cuanto a la arquitectura en general,y para gestionar la mensajería se aplicó el patrón de diseño Productor/Consumi-dor en combinación con el patrón Observer sobre un objeto del tipo lista parasincronizarlos.

Este componente es el responsable de crear el socket servidor y quedar a la esperade las conexiones de los gateway. Se consideró que pueden existir varios gatewaypor lo que a medida que se van conectando, los registra en una lista apropiada ysigue a la escucha de otros nuevos. Los gateway, luego de establecer la conexión,empiezan a replicar hacia el APP Server todos los mensajes recibidos y enviados.

Los mensajes se procesan para identificar a los gateway y nodos disponibles, lue-go por cada mensaje de «Datos sensados» se registra y vincula en el nodo co-rrespondiente. Estos datos luego se trasmiten a COFAM consumiendo los webservices.

Para este componente se optó por la RaspBerry Pi, en donde se instaló el Raspbianpara correr dos piezas de software: una es un programa ad hoc compilado enC++ que se comunica con el módulo de radio frecuencia y queda a la espera delos paquetes para procesar la mensajería. Al mismo tiempo, se comunica con otroprograma desarrollado en Java que también corre en la RaspBerry Pi y utiliza

1 Separación lógica de la capa presentación, reglas de negocio y datos.

3.1. Componentes de la Solución 19

socket TCP. Este último software, además implementa Java Server Page y proveede una interfaz web para configurar los nodos y también imprimir el registro delecturas. A su vez, este componente es quien consume los web services de otrosistema denominado servidor ubicado en la infraestructura de COFAM.

La interfaz web permite consultar en línea, y de forma local en la farmacia, los re-gistros de temperatura informados por todos los sensores disponibles. Tambiénpermite generar un reporte para imprimir con datos filtrados de acuerdo a unaconsulta entre fecha y hora, e indicando un único valor de temperatura por uni-dad de tiempo, que es el promedio del valor registrado por todos los sensores deun mismo nodo.

3.1.5. Servidor

En la infraestructura de COFAM se encuentran corriendo los web services queregistran las temperaturas de cada farmacia y las compara con sus registros an-teriores. En el caso que los registros estén fuera del rango establecido o detecte lafalla de algún sensor, se generan las alertas correspondientes y se envía vía emaila las casillas de correo configuradas.

Algo importante a tener en cuenta es que este sistema está soportado por una pla-taforma muy estable con una alta tasa de disponibilidad, y paralelamente hay unservicio que periódicamente está monitoreando los registros recibidos por sen-sor. En el caso que se detecta que se dejaron de recibir, también genera la alertacorrespondiente.

3.1.6. Software para simulación

Valiéndose del desarrollo multiplataforma encarado para toda la solución, sedesarrolló otra pieza de software que permitió poder validar la funcionalidadde todo el sistema de una forma más controlada. Se desarrollaron drivers virtua-les para simular los sensores y la comunicación por radio frecuencia, logrando asíprobar el comportamiento de los componentes y su interacción, sin adentrarse enproblemas de hardware o drivers.

Dicha aplicación recibe como parámetros el tipo de componente que va a simulary cual será la interfaz a utilizar. En cuanto a ésta última, se desarrolló una deno-minada Teclado/Pantalla, en la cual se ingresa por teclado el mensaje a recibir por elcomponente configurado como si lo recibiera por el módulo de radio frecuencia,de igual manera, lo que se envíe por el mismo módulo se visualiza por pantallaen lugar de transmitirse.

La implementación de los drivers virtuales en la mensajería se realizó en el códigode forma transparente. Para lograr esto, se utilizaron punteros a función en laconfiguración del buffer como se muestra en el algoritmo 3.6

1 void2 c o m u n i c a c i o n _ i n i c i a l i z a r _ b u f f e r ( i n t (∗ _pFuncion_read ) ( char ∗ buffer ,

i n t bytes ) , i n t (∗ _pFuncion_write ) ( char ∗ buffer , i n t bytes ) ,b u f f e r C i r c u l a r _ t ∗ _buf fer_ tx , b u f f e r C i r c u l a r _ t ∗ _ b u f f e r _ r x )

3 {4 pFuncion_read = _pFuncion_read ;5 pFuncion_write = _pFuncion_write ;

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

6

7 b u f f e r _ t x = _ b u f f e r _ t x ;8 buf fer_ tx −>e s c r i t u r a = 0 ;9 buf fer_ tx −>l e c t u r a = 0 ;

10

11 b u f f e r _ r x = _ b u f f e r _ r x ;12 buffer_rx−>e s c r i t u r a = 0 ;13 buffer_rx−>l e c t u r a = 0 ;14

15 . . .

ALGORITMO 3.6: Inicialización del buffer

21

Capítulo 4

Pruebas y Resultados

En este capítulo se detalla cómo se llevaron a cabo las simulaciones, las pruebasrealizadas sobre el sistema y también los resultados obtenidos de los mismos.

4.1. Simulación

La simulación del sistema consistió en evaluar por separado cada característicadel mismo, y luego de forma incremental, se fueron probando de a uno cadacomponente hasta completar todo el sistema.

Para realizar la simulación de los componentes, se utilizó la aplicación ya men-cionada en el capítulo 3, donde en una terminal se ejecuta como nodo y en otracomo gateway. Luego, la salida de uno se copia en la entrada del otro para verla interacción. Una de las pruebas consistió en omitir copiar la confirmación demensajes para evaluar el comportamiento en tal situación.

En cuanto a las lecturas obtenidas por el sensor, se utilizó el driver virtual paradevolver siempre el mismo valor y luego una secuencia de valores establecidosque simulaban distintas situaciones.

Antes de correr la simulación de cada componente, se elaboró una lista con elcomportamiento y la respuesta esperada de acuerdo al escenario configurado.

Comprobado lo anterior, se reemplazaron los drivers virtuales por los reales delos componentes como el DS18B20 y NRF24L01+, y finalmente se verificó de nue-vo todo el sistema.

4.1.1. Pruebas en nodo virtual

En la ejecución del nodo se espera que ejecute la siguiente secuencia y envíe losmensajes de estado por el puerto de debug:

1. Inicio: mostrar mensaje de versión de compilación.

2. Estado enINICIADO: se prepara, envía y registra el mensaje «Solicitar Con-figuración».

3. Estado enCONFIGURANDO sin respuesta: hasta que no se reciba configu-ración, se deben reenviar los paquetes pendientes.

4. Estado enCONFIGURANDO con respuesta: cuando se reciba el mensaje «Es-tablecer Configuración», se debe establecer la configuración recibida.

22 Capítulo 4. Pruebas y Resultados

5. Estado enCONFIGURADO: cuando el nodo se encuentra configurado, deberevisar el intervalo de trasmisión de cada sensor y tomar lectura si corres-ponde.

6. Estado enSENSADO: mientras existan lecturas registradas en los sensores,se debe preparar, enviar y registrar el mensaje «Datos Sensados» por cadauno.

7. Estado enCONFIGURADO sin respuesta: mientras existan mensajes sin con-firmar, se deben reenviar de acuerdo al intervalo configurado.

8. Estado enCONFIGURADO con respuesta: cuando se recibe confirmación dealgún mensaje, se debe quitar de la lista de pendientes para no retrasmitir.

Se ejecutó la aplicación con los parámetros para iniciar como nodo y con la inter-faz Teclado/Pantalla. El resultado obtenido se corresponde en secuencia y mensajescon los esperados como se aprecia en la figura 4.1

FIGURA 4.1: Mensajes al simular el nodo virtual

4.1.2. Pruebas en gateway virtual

En la ejecución del gateway se espera que ejecute la siguiente secuencia y envíelos mensajes de estado por la consola:

1. Inicio: mostrar mensaje de versión de compilación.

2. Estado egINICIADO: se prepara y envía, pero no registra, el mensaje «Es-tablecer Configuración» sin definir un nodo de destino para reconfigurarnodos asignados por si se viene de un reinicio.

4.1. Simulación 23

3. Estado egPROCESANDO sin mensajes: mientras no se reciban mensajes, elgateway no debe realizar ninguna acción.

4. Estado egPROCESANDO con mensajes: cuando se recibe el mensaje «Soli-citar Configuración», se prepara y envía, pero no registra, el mensaje «Es-tablecer Configuración» al nodo que lo solicitó. Si se se recibe el mensaje«Datos Sensados», se prepara y envía, pero no registra, el mensaje «Mensa-je Recibido» al nodo que lo envió.

Se ejecutó la aplicación con los parámetros para iniciar como gateway y con la in-terfaz Teclado/Pantalla. El resultado obtenido se corresponde en secuencia y men-sajes con los esperados como se aprecia en la figura 4.2

FIGURA 4.2: Mensajes al simular el gateway virtual

4.1.3. Pruebas de comunicación entre gateway virtual y APP Server

Durante la ejecución de un gateway que se conecta a un APP Server, se espera querealice las siguientes acciones:

Tratar de iniciar conexión con el APP Server y en caso fallido o por descone-xión, reintentar conectar periódicamente.

Independientemente de su estado, todo mensaje recibido y enviado por elmódulo de radio frecuencia se debe retrasmitir también al APP Server.

En la ejecución del APP Server se espera que ejecute la siguiente secuencia y envíelos mensajes de estado por la consola:

1. Mostrar mensaje de versión de compilación.

2. Abrir puerto TCP y esperar conexiones de los gateway.

3. Registrar cada conexión de gateway que se conecta y quitarla cuando sedesconecta.

24 Capítulo 4. Pruebas y Resultados

4. Registrar cada mensaje recibido.

5. Procesar los mensajes y registrar nodos, sensores y lecturas correspondien-tes.

Se ejecutó la aplicación con los parámetros para iniciar como gateway, con la in-terfaz Teclado/Pantalla y conexión a APP Server. También se inició el APP Server yel resultado obtenido se corresponde en secuencia y mensajes con los esperadosde ambas aplicaciones como se aprecia en la figura 4.3

FIGURA 4.3: Mensajes al simular el gateway virtual configuradocon el APP Server

4.2. Ensayos sobre dispositivos físicos

Lo primero que se abordó, fue la integración de las bibliotecas del sensor y el mó-dulo de radio frecuencia en la plataforma mbed. Se realizaron pruebas con dis-tintas configuraciones hasta encontrar la óptima para los requisitos del sistema.Luego se integró el código de la aplicación configurado como nodo y se incluyóla inicialización de los drivers.

Una vez compilado el código del nodo se continuó con el gateway, para lo cual seconfiguró el puerto SPI en el raspbian utilizado por la RaspBerry Pi. Se tomó laaplicación ya desarrollada y se le integró el driver del módulo de radio frecuencia.Finalmente se instaló el software del APP Server en el raspbian y se verificó sucorrecta ejecución.

En la figura 4.4 se puede apreciar el primer prototipo del nodo y en la figura 4.5se visualiza el modelo 3D del PCB. En la figura 4.6 se aprecia la Raspberry Piconectada con el módulo de radiofrecuencia.

4.2. Ensayos sobre dispositivos físicos 25

FIGURA 4.4: Primer prototipo del nodo

FIGURA 4.5: Modelo 3D del PCB diseñado

26 Capítulo 4. Pruebas y Resultados

FIGURA 4.6: Raspberry Pi conectada con el módulo de radio fre-cuencia

4.2.1. Pruebas de comunicación entre el Nodo y Gateway físicos

Una vez verificado todo, se grabó el firmware en el nodo, se corrió el software enel gateway y se visualizo la interacción utilizando el puerto serie del nodo y unaconsola ssh con raspbian como se aprecia en la figura 4.7

FIGURA 4.7: Prueba completa del sistema

4.3. Pruebas sobre sensores de temperatura 27

4.3. Pruebas sobre sensores de temperatura

A diferencia de los otros componentes del sistema, no se había experimentadoaún con el sensor de temperatura DS18B20, por ello se consideró relevante reali-zar comparaciones entre las lecturas obtenidas desde éste y las de otros ya cono-cidos, como el LM35 y el incluido dentro de la MPU9250.

Se colocaron los tres sensores en paralelo bajo las mismas condiciones ambienta-les y se registró las lecturas de cada uno como se aprecia en la tabla 4.1

TABLA 4.1: Registro de lecturas con distintos sensores

Marca temporal (seg) MPU9250 (◦C) LM35 (◦C) DS18B20 (◦C)

0 22,91 24,3 23,110 22,94 24,3 23,220 22,98 24,4 23,230 23,01 24,4 23,240 23,07 24,1 23,550 23,07 24,1 23,160 23,09 24,1 23,270 23,15 24,0 23,080 23,15 24,9 23,190 23,16 25,1 23,0100 23,16 24,7 23,9110 23,15 24,7 23,0120 23,14 24,8 23,1130 23,15 24,9 23,1140 23,15 24,9 23,1150 23,16 24,9 23,2160 23,21 25,1 23,2170 23,22 24,9 23,2180 23,22 24,8 23,3

Al realizar esta comprobación entre distintos sensores, se detectó que el DS18B20casi no requiere de un tiempo inicial para estabilizarse y registrar de forma efi-caz la temperatura desde un comienzo. También se verificó su comportamientoindividual ante cambios de temperatura provocados.

Por último, se realizó una prueba colocando tres sensores DS18B20 en paralelo ybajo las mismas condiciones ambientales, en donde se pudo constatar que dichoscomponentes iguales registran temperaturas similares dentro de su margen detolerancia.

4.4. Prueba de estrés del sistema completo

Consistió en tres pruebas:

Primero probar 2 nodos funcionando en simultáneo con un gateway y ve-rificar que los mensajes se procesaban correctamente en cada componente.

28 Capítulo 4. Pruebas y Resultados

También es este punto, se analizó el log para detectar paquetes perdidosutilizando la característica idMensaje incorporada en la mensajería.

Luego se iniciaron cinco gateway verificando que el APP Server los identifi-caba de forma unívoca y mantenía una conexión con cada uno.

Finalmente, se dejo en funcionamiento el sistema completo durante 2 díasobservando si se generaba algún bloqueo en un componente y si el compor-tamiento era el esperado durante todo el transcurso de la prueba.

4.5. Resultados de pruebas en campo

Se dejó funcionando el sistema en una heladera de prueba, donde se instaló elnodo a su costado y se colocaron tres sensores juntos en su interior. Se conectóel gateway con el APP Server y se monitoreó su funcionamiento durante el pe-riodo de una hora. Al finalizar la prueba, se generaron reportes de las lecturasregistradas.

Los resultados obtenidos fueron aceptables y el sistema se comportó estable du-rante toda la prueba de campo. En la figura 4.8 se puede observar el reporte ob-tenido tras finalizar la prueba.

FIGURA 4.8: Reporte generado tras prueba de campo

29

Capítulo 5

Conclusiones

5.1. Trabajo realizado

El desafío más interesante al desarrollar este proyecto fue articular todas las pie-zas de software y la interacción con el hardware para completar el circuito dela solución propuesta. El uso de patrones de diseño, integración continua y testunitarios permitió desarrollar software de alta calidad en poco tiempo.

Fue muy valioso poder compartir experiencias e ideas con los profesores y entrecompañeros. Así pudo visualizarse otras soluciones a la problemática planteada,como podría ser un prototipo constituido simplemente por un ESP y sensores,utilizando la red wifi de la farmacia y evitando la necesidad de un gateway. Estaalternativa constituiría una solución más económica si se trata de un solo nodo,ya que por ejemplo no necesita la RaspBerry, aunque se advierte que se está sa-crificando poder de cómputo para futuros servicios.

También fue muy productivo tener la posibilidad de aplicar los trabajos finales dealgunas materias como parte de este proyecto. De esta forma se aprovecho mejorel tiempo y se logró mejorar distintos aspectos en el desarrollo de la solución,a saber: realización de test unitarios, optimización en el uso de los protocolos,diseño del PCB, entre otros.

Cabe mencionar que el único inconveniente significativo fue que al compilar elfirmware, éste sobrepaso la flash disponible para el microcontrolador en uso y sesolucionó, aunque quedó al límite, utilizando release anteriores de la librería delsensor y también del mbed OS.

5.2. Trabajo futuro

Como continuación del presente proyecto, se propone dotar de otras funciona-lidades a los nodos, como por ejemplo registrar cada vez que arranca y para elmotor de la heladera para que, según la cantidad de arranques por hora y el tiem-po que permanece en marcha, determinar si el funcionamiento es el adecuado orequiere un mantenimiento dada la perdida de frío (como suele suceder ante lafalta de gas o el deterioro en los fuelles de las puertas).

También sería interesante el desarrollo de un dashboard web administrado desdeCOFAM, que permita visualizar en línea el estado de la cadena de frío de cadafarmacia, consultar el histórico de incidentes, entre otras características.

30 Capítulo 5. Conclusiones

Además, se puede trabajar de forma cooperativa con el ente gubernamental decontrol para asesorarlos y con el tiempo homologar los reportes generados porel sistemas. Para ésto último, se advierte la necesidad de cumplir las normas yregulaciones que indique la ANMAT, además de que también sea contempladoen la legislación vigente. Esto permitiría reemplazar el método actual del controlde cadena de frío utilizado en las farmacias, por uno mas acorde a las tecnologíasvigentes.

Finalmente, este proyecto también dota a las farmacias de una infraestructura quesirve de base para nuevos proyectos con objetivos diferentes. Se puede aprove-char las características de nodos con microcontroladores conectados a un gatewaycon sistemas robustos de procesamiento, y entonces, por ejemplo, se podría desa-rrollar una alarma monitoreada con una mínima inversión.

31

Bibliografía

[1] IRAM 37018-1. Conservación de la Cadena de Frío y Almacenamiento.Disponible: 2018-11-12. 2018. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

[2] Ley 26492/09. Ley 26492 cadena frío. Disponible: 2018-11-12. 2018. URL:http://www.anmat.gov.ar/webanmat/Legislacion/Medicamentos/Ley_26492_cadena_frio.pdf.

[3] NXP. LPC111X. Disponible: 2018-11-14. 2018. URL:https://www.nxp.com/docs/en/data-sheet/LPC111X.pdf.

[4] NORDIC SEMICONDUCTORES. nRF24L01+. Disponible: 2018-11-14.2018. URL: http://www.nordicsemi.com/eng/content/download/2730/34105/file/nRF24L01_Product_Specification_v2_0.pdf.

[5] DALLAS SEMICONDUCTOR. ds18b20. Disponible: 2018-11-14. 2018. URL:https://www.datasheetspdf.com/pdf/1011203/DallasSemiconductor/DS18B20/1.

[6] Raspberry Pi. Computador de placa única. Disponible: 2018-11-19. 2018. URL:https://www.raspberrypi.org/documentation/hardware/computemodule/datasheets/rpi_DATA_CM_1p0.pdf.

[7] NXP. Plataforma MBED. Disponible: 2018-11-19. 2018. URL:https://www.mbed.com/en/platform/mbed-os/.

[8] Raspbian. sistema operativo GNU/Linux. Disponible: 2018-11-19. 2018. URL:https://es.wikipedia.org/wiki/Raspbian.

[9] Oracle. Java Platform Enterprise Edition. Disponible: 2018-11-19. 2018. URL:https://es.wikipedia.org/wiki/Java_EE.

[10] Primefaces. Framework Primefaces. Disponible: 2018-11-15. 2018. URL:https://www.primefaces.org/.