CARRERA DE ESPECIALIZACIÓN ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Detector de ejes calientes para materialrodante

Autor:Mg. Ing. Fabián L. Sarmiento

Director:Dr. Ing. Pablo Gomez (FIUBA)

Jurados:Ing. Edgardo Comas (CITEDEF)

Esp. Ing. Alejandro Permingeat (FIUBA)Esp. Ing. Matías Alvarez (FIUBA)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires,entre marzo de 2019 y agosto de 2020.

III

Resumen

Esta memoria documenta el desarrollo e implementación de un sistema demedición de temperatura para las cajas de punta de eje o cojinetes, las cuales

forman parte de los sistemas críticos que componen el material rodante. En casode operar incorrectamente podrían producir mal funcionamiento del servicio,descarrilamientos, grandes pérdidas económicas e incluso de vidas humanas.

El sistema descripto en esta memoria permite la detección de fallas a través de lamedición de temperatura de las cajas de punta de eje del vehículo. En el diseño

implementado se aplicaron conocimientos en programación demicrocontroladores, protocolos de comunicación y uso de bibliotecas para

sistemas embebidos.

V

Índice general

Resumen III

1. Introducción General 11.1. Sistemas mecánicos del material rodante . . . . . . . . . . . . . . . . 11.2. Caja de punta de eje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Propósito del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Introducción Específica 92.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 92.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 9

2.2. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3. Elementos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1. Placas de desarrollo ESP32 . . . . . . . . . . . . . . . . . . . 10ESP32 cam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11ESP32 WROOM DevKitC . . . . . . . . . . . . . . . . . . . . 12

2.3.2. Sensor infrarrojo . . . . . . . . . . . . . . . . . . . . . . . . . 13Principios de la detección infrarroja . . . . . . . . . . . . . . 14Mlx90614 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Optris CTFast . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4. Protocolos de comunicación . . . . . . . . . . . . . . . . . . . . . . . 152.4.1. MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Modelo publicación/suscripción . . . . . . . . . . . . . . . . 17Tópicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Calidad del servicio (QoS) . . . . . . . . . . . . . . . . . . . . 18

2.4.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5. Herramientas y entornos de desarrollo . . . . . . . . . . . . . . . . . 20

2.5.1. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . 20Mosquitto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Node Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.2. Entornos de Desarrollo . . . . . . . . . . . . . . . . . . . . . . 20ESP-IDF (Espressif Devolopment IoT Framework) . . . . . . 20Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 21MicroPython IDE . . . . . . . . . . . . . . . . . . . . . . . . . 21

3. Diseño e Implementación 233.1. Elementos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1. Sensor IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.2. Placas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 26

VI

Conectividad WiFi . . . . . . . . . . . . . . . . . . . . . . . . 26Modos de consumo de energía . . . . . . . . . . . . . . . . . 26Captura de imágenes fotográficas . . . . . . . . . . . . . . . 27Costo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2. Descripción interna de la aplicación . . . . . . . . . . . . . . . . . . 283.2.1. ESP32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Publicación de tópicos MQTT . . . . . . . . . . . . . . . . . . 30Suscripción a tópicos . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.2. Configuración MySQL -Node Red . . . . . . . . . . . . . . . 30

4. Ensayos y Resultados 334.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3. Requisitos cumplidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5. Conclusiones 395.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 395.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Bibliografía 41

VII

Índice de figuras

1.1. Partes de un bogie1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Bastidor de la firma William Cook de un material rodante2. . . . . . 21.3. Vista frontal de una caja de punta de eje. . . . . . . . . . . . . . . . . 31.4. Detector de ejes calientes instalado en vía3. . . . . . . . . . . . . . . 4

2.1. Placa de desarrollo ESP32 cam de AI Thinker4. . . . . . . . . . . . . 112.2. Pinout de la placa ESP32 cam de AI Thinker5. . . . . . . . . . . . . . 122.3. Pines de propósito general de la placa de desarrollo ESP32 WROOM

DevKitC6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4. Funciones de los pines de la placa de desarrollo ESP32 WROOM

DevKitC1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5. Imagen que muestra el detector infrarrojo Mlx906147. . . . . . . . . 152.6. Detector infrarrojo de la marca Optris 8. . . . . . . . . . . . . . . . . 152.7. Topología del protocolo de comunicación MQTT9. . . . . . . . . . . 162.8. Capas del protocolo MQTT10. . . . . . . . . . . . . . . . . . . . . . . 172.9. Elementos que componen el modelo publicación/suscripción 11. . . 172.10. Proceso de comunicación del protocolo MQTT 12. . . . . . . . . . . 182.11. Trama MQTT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.12. Topología del protocolo de comunicación CoAP 13. . . . . . . . . . . 192.13. Flujo típico en Node Red. . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1. Arquitectura del HBD. . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2. Diagrama de bloques del proceso de medición del HBD. . . . . . . 253.3. Flujo suscripción a tópicos desde Node Red a mosquitto. . . . . . . 313.4. Configuración conexión a broker mosquitto. . . . . . . . . . . . . . . 313.5. Interfaz Gráfica de Usuario. . . . . . . . . . . . . . . . . . . . . . . . 32

4.1. Almacenamiento en la base de datos ESP32 de las temperaturasmedidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2. Almacenamiento de imágenes captadas por el cliente 1 (ESP32 cam)en la base de datos IMAGENES. . . . . . . . . . . . . . . . . . . . . 35

4.3. Dashboard medición de temperatura. . . . . . . . . . . . . . . . . . . 354.4. Publicación de datos a través del broker mosquitto. . . . . . . . . . . 364.5. Imagen recibida por la herramienta de desarrollo Node Red . . . . 36

IX

Índice de Tablas

1.1. Tabla comparativa de HBD en el mercado. . . . . . . . . . . . . . . . 51.2. Tabla comparativa de trabajos de investigación en HBD analizados

en esta memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1. Módulos de la familia ESP 32 14. . . . . . . . . . . . . . . . . . . . . 102.2. Características de la placa de desarrollo ESP32 cam15. . . . . . . . . 122.3. Características de la placa ESP32 WROOM16. . . . . . . . . . . . . . 132.4. Tabla comparativa de sensores IR empleados. . . . . . . . . . . . . . 162.5. Tabla comparativa de protocolos de comunicación analizados. . . . 19

3.1. Tiempo de respuesta del sensor IR. . . . . . . . . . . . . . . . . . . . 263.2. Especificaciones consumo de potencia RF. Unidades en mA17. . . . 273.3. Tabla comparativa del costo de las placas de desarrollo. . . . . . . . 283.4. Tabla configuración pines ESP32 cam18. . . . . . . . . . . . . . . . . 293.5. Eventos WiFi en ESP32 19. . . . . . . . . . . . . . . . . . . . . . . . . 30

XI

A Benja, María y Mile, los motores de mi vida

1

Capítulo 1

Introducción General

En el presente capítulo se brinda una breve definición de material rodante y sepresentan los principales sistemas mecánicos que lo componen. En particular, sedescriben las cajas de punta de eje y su importancia en el óptimo funcionamientodel material rodante.

1.1. Sistemas mecánicos del material rodante

Se conoce como material rodante a todos los tipos de vehículos dotados de ruedascapaces de circular sobre una vía férrea cuyo principal objetivo es el transportede cargas y pasajeros [1].

Las partes más importantes del material rodante ferroviario son las siguientes [1]:

Caja: dependiendo del tipo de vehículo (coche, vagón o locomotora), en suinterior se sitúan los viajeros, las mercancías o los motores.

Tren de rodadura - bogie: el tren de rodadura es el sistema que proporcio-na un movimiento seguro del vehículo a lo largo de la vía. Los trenes derodadura montados en una estructura separada que permita el movimientorelativo al cuerpo del vehículo son lo que se conoce como bogie (ver figura1.1). El tipo más común es el bogie de dos ejes, aunque también se encuen-tran muchos de tres y cuatro ejes, estos últimos en locomotoras [2].

Bastidor: es la estructura metálica o armazón formada por el bogie que sirvecomo elemento de fijación de los ejes, las ruedas, los motores de tracción ylas suspensiones, entre otras partes (ver figura 1.2).

Larguero: elemento longitudinal que forma parte de la estructura del basti-dor de un vehículo.

Traviesas extremas o cabeceros: elemento estructural situado en el extremodel bastidor de un vehículo que une los largueros de forma perpendiculara estos, y que soporta normalmente los aparatos de choque y tracción. Alconjunto de elementos que configuran la caja del vehículo sobre la traviesaextrema se lo denomina “testero”.

Suspensión: la caja transmite las cargas a las ruedas a través de la suspen-sión. La suspensión ferroviaria es doble: primaria y secundaria. La suspen-sión primaria tiene como misión absorber las irregularidades del carril ydeformaciones geométricas de la vía, está situada entre las cajas de grasasy el bastidor del bogie o, en el caso de los vagones de dos ejes, entre la cajade punta de eje y el bastidor del vehículo. La suspensión secundaria es la

2 Capítulo 1. Introducción General

encargada de absorber los movimientos verticales y laterales del bogie conrespecto al bastidor del vehículo.

Caja de punta de eje: son unos recipientes metálicos que contienen lubri-cantes y llevan encajado un rodamiento en el apoyo de las cargas sobre losejes. Información más detallada sobre este componente será dada en la sec-ción 1.2.

FIGURA 1.1. Partes de un bogie1.

FIGURA 1.2. Bastidor de la firma William Cook de un material ro-dante2.

Dentro de los elementos mecánicos descriptos en la sección 1.1, es de especialinterés para las empresas operadoras de servicios ferroviarios la fiabilidad de lacaja de punta de eje. Una de las herramientas empleadas para evaluar el estadoy fiabilidad de las cajas de punta de eje es la medición de temperatura a travésde sensores térmicos. En la sección 1.3 se hace mención a diferentes productos

1http://www.railsystem.net/bogie/2https://www.virtualmarket.innotrans.com/en/Bogie-Frames-and-sub-assemblies,p1507693

1.2. Caja de punta de eje 3

comerciales encontrados en el mercado y algunos trabajos académicos desarro-llados donde se busca hacer asequible la tecnología.

1.2. Caja de punta de eje

La caja de punta de eje, algunas veces llamada caja de grasa (ver figura 1.3), es unmecanismo que permite al juego de ruedas rotar, montando en ella el alojamientopara los rodamientos y también el montaje de la suspensión primaria para fijar eljuego de ruedas al bogie o la estructura del vehículo.

Por otro lado, la caja de punta de eje transmite fuerzas longitudinales, lateralesy transversales [2] desde el juego de las ruedas al resto de elementos del bogie.Están clasificadas de acuerdo con:

La posición en el eje dependiendo de si el montaje es interior o exterior.

El tipo de cojinete empleado. El cojinete es un elemento de máquina quesimultáneamente permite a un eje girar y soportar carga. Estos pueden serser cónicos, esféricos, planos.

FIGURA 1.3. Vista frontal de una caja de punta de eje.

La forma externa de la caja de punta de eje se determina por el método de cone-xión que hay entre la caja de punta de eje y el bogie. Con ello se busca lograr unadistribución de fuerzas uniforme en el rodamiento. La construcción interna de lacaja de punta de eje está determinada por el rodamiento y su método de sellado.

El mal funcionamiento de una caja de punta de eje es una anomalía que se generaen forma gradual, lo que permite su detección antes de que el daño causado seamuy significativo. Las cajas de punta de eje requieren de un método de inspecciónno destructivo y detección temprana de fallas. Si las fallas en punta de eje no sondetectadas a tiempo pueden producir demoras en el servicio, potenciales incen-dios y descarrilamientos. Las situaciones anteriormente expuestas se traducen enimportantes pérdidas económicas e incluso riesgo de vida.

Contar con un dispositivo que sea instalado en la vía y permita realizar la medi-ción de temperatura en tiempo real de la caja de punta de eje del material rodante

4 Capítulo 1. Introducción General

es una herramienta útil para la detección de posibles fallas. Esta detección se pue-de realizar con un “detector de ejes calientes” instalado en vía, que consiste en unconjunto de sensores infrarrojos los cuales captan las emisiones infrarrojas emiti-das por el cuerpo monitoreado y actúan sin necesidad de detener el tren, tanto dedía como de noche.

1.3. Estado del arte

El estándar Europeo UNE-EN 15437 “Aplicaciones ferroviarias. Monitorizaciónde la condición de las cajas de grasa. Requisitos de interfaz y diseño. Parte 1:Equipo al lado de la vía y cajas de grasa del material rodante“, define dos métodospara sistemas de monitoreo de cajas de punta de eje:

Monitoreo realizado por el sistema de abordo.

Supervisión efectuada por detectores ubicados a lo largo de la vía férrea(ver figura 1.4).

FIGURA 1.4. Detector de ejes calientes instalado en vía3.

En la actualidad existen diferentes compañías que se dedican a la fabricación ycomercialización de detectores de ejes calientes (Hot Box Detector, HBD) para ma-terial rodante. Los HBD encontrados en el mercado presentan características si-milares, tales como la utilización de sensores infrarrojos como elementos de me-dición, pero difieren en cuanto a la tecnología empleada respecto a la comuni-cación y transmisión de datos. Teniendo presente lo expuesto anteriormente, acontinuación se nombran algunas compañías y las características generales desus respectivos productos.

EKE Electronics desarrolló un sistema de monitoreo abordo [4], que se en-cuentra integrado al Train Control Monitoring System (TCMS) [5] del vehícu-lo. El dispositivo comercializado por esta compañía finlandesa es una so-lución de equipamiento embarcado que monitorea de manera continua elestado de la caja de punta de ejes e informa al TCMS [5], quien a su vezreporta al motorman en caso de anomalía.

ITSS Tech desarrolló un equipo de medición infrarroja (modelo Pegasus [3])que cuenta con herramientas de análisis gráfico, diagnóstico y sensores devibración.

3Imagen tomada de [3].

1.3. Estado del arte 5

Voestallpine Signalling, es una compañía de origen austríaco que ofrece en elmercado el sistema modular Phoenix HBD [6], que permite monitorear ejescalientes, ruedas calientes y frías. La solución ofrecida por esta compañíatrabaja sobre redes LAN y GSM.

En la tabla 1.1 se presenta un resumen con las principales características de estostres sistemas. Se puede observar que los desarrollos descriptos en dicha tablapresentan características similares con algunas variantes, tales como medicióncaliente y fría de las ruedas del tren.

TABLA 1.1. Tabla comparativa de HBD en el mercado.

Fabricante Modelo Descripción

Eke Electronic HBAD Monitoreo abordoComunicación con el TCMS

ITSS Tech PEGASUS Sensor de vibraciónHerramientas de análisis gráfico

Voestalpine Phoenix MDS Puntos de medición: 8HBD/HDW Medición de ruedas calientes y frías

Por otro lado, en el área de investigación los estudios de diseño de HBD y aplica-ciones al mundo ferroviario pueden ser clasificados en los siguientes grupos:

Análisis de riesgo y modelado probabilístico de HBD [7] [8].

Modelado de HBD en estado estable y transitorio [9].

Aplicaciones de HBD para operaciones de sistemas ferroviarios en Europa[10].

Algunos de los principales trabajos de investigación concernientes a estas áreasde estudio y analizados en esta memoria son los siguientes:

Gampze Garip et al. [11] presentan el diseño de un HBD, que consiste en unconjunto de sensores infrarrojos ubicados a ambos lados de la vía del tren,dos disparadores para detectar el acercamiento del vehículo y una terminal;esta se comunica con el dispositivo de medición a través de una línea decomunicación CANBUS (Controller Area Network).

Shöebel et al. [12] desarrollaron un sistema de medición del estado de frenosy ejes calientes llamado TK99, que fue instalado en diferentes puntos deAustria. El diseño propuesto en este trabajo de investigación consistió endos escáneres infrarrojos: uno de ellos monitorea la temperatura de la cajade punta de ejes y el otro sensa la temperatura de los discos de frenos; unaunidad de control, un equipamiento de transmisión de datos y una unidadde display.

Wu et al. [13] desarrollaron un sistema que detecta la temperatura y discri-mina los puntos calientes empleando técnicas de clasificación Bayessianas.El sistema consta de un equipo detector y una computadora terminal. Lacomunicación entre las partes se realiza a través del protocolo RS485.

En la tabla 1.2 se presenta un resumen de los diseños realizados en los trabajosmencionados.

6 Capítulo 1. Introducción General

TABLA 1.2. Tabla comparativa de trabajos de investigación enHBD analizados en esta memoria.

AutorN◦ puntos de

Puntos de mediciónmedición

Gampze Garip et al. 1Caja de

punta de ejes

Shöebel et al. 3

Caja depunta de ejes,ruedas y disco

de frenos

Wu et al. 1Detección de puntos

calientes de ejes empleandotécnicas Bayessianas

1.4. Propósito del proyecto

La principal motivación que sirvió como impulsor para llevar a cabo este trabajofue la necesidad manifestada por parte de la empresa estatal Trenes Argentinos,ante el Grupo de Investigación en Calidad y Seguridad de las Aplicaciones Ferro-viarias (GICSAFe), adscripto al Consejo Nacional de Investigaciones Científicas yTécnicas (CONICET), de contar con un HBD. Este diseño debe permitir medir einformar de manera remota y en tiempo real la temperatura de las cajas de puntade eje del material rodante en circulación. Esto brinda a las empresas operadorasdel país una herramienta adicional de mantenimiento preventivo.

1.5. Objetivos y alcance

El objetivo principal del presente trabajo fue:

Diseñar e implementar un dispositivo HBD que permita la medición detemperaturas de forma remota de las cajas de punta de eje del materialrodante. Dicho dispositivo permitiría a las operadoras ferroviarias, parti-cularmente al personal de mantenimiento, realizar un óptimo diagnósticode las cajas de punta de eje del vehículo ferroviario e identificar las fallasantes de que ellas se presenten.

El alcance de este trabajo fue el siguiente:

Desarrollo de un prototipo de un dispositivo detector de ejes calientes.

Programación del software que permite el almacenamiento de imágenes,correspondientes a los vehículos evaluados, y la visualización de los datosadquiridos.

Pruebas de funcionamiento.

Documentación de referencia.

Manual de operación.

El presente trabajo no incluyó los ítems indicados a continuación:

Manual de repuestos del dispositivo.

1.5. Objetivos y alcance 7

Diseño e instalación del circuito alimentador del equipo de medición.

9

Capítulo 2

Introducción Específica

En este capítulo se hace una descripción de los requerimientos elicitados y semuestra el cronograma de actividades propuesto para este trabajo. Adicional-mente, se aborda una descripción detallada de las tecnologías y herramientas dedesarrollo empleadas en el diseño e implementación del prototipo propuesto.

2.1. Requisitos

En los siguientes párrafos se mencionan los requisitos funcionales y no funciona-les elicitados para el presente desarrollo.

2.1.1. Requisitos funcionales

A continuación se hace una descripción de los requerimientos funcionales delinstrumento.

1. El sistema debe medir la temperatura de las cajas de punta de eje del mate-rial rodante en un rango de 0◦ a 120 ◦C.

2. El sistema debe trabajar en un rango de temperatura ambiente de 0◦ a 50 ◦C.

3. El sistema debe mostrar en una terminal (computadora portátil) la tempe-ratura del eje medido.

4. El sistema debe permitir al operario ingresar el valor de la temperatura um-bral.

5. El sistema debe emitir una señal de advertencia, una vez que la temperaturamedida supera la temperatura umbral.

6. El sistema debe almacenar los datos y las imágenes captadas en una base dedatos del tipo SQL.

2.1.2. Requisitos no funcionales

Se entiende por requisitos no funcionales a aquellos que definen atributos delsistema. Los requisitos no funcionales a cumplimentar son los siguientes:

1. El sistema debe ser de fácil uso y entendimiento para el operador.

2. Cuando no es detectado ningún vehículo, el sistema debe entrar en mododormido, permitiendo de esa manera el ahorro de energía.

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

2.2. Planificación

En [14] se muestra la planificación de las actividades que fueron requeridas parael avance y desarrollo de este trabajo. Adicionalmente, se puede observar cadauna de las tareas, junto con su duración, fecha inicial y fecha final estimadas.

2.3. Elementos del sistema

En esta sección se hace una descripción de los elementos que componen el siste-ma. Los criterios de diseño y elección tanto de los materiales como de los paquetessoftware se mostrarán en el capítulo 3.

El sistema aquí desarrollado se encuentra integrado por los dispositivos indica-dos a continuación:

Placas de desarrollo ESP32: cam y WROOM DevKitC

Sensor infrarrojo

Pulsador on/off

Módulo microSD card

Por otro lado, las herramientas de desarrollo y/o programación que fueron nece-sarias para construir el software fueron las siguientes:

Node Red

Mosquitto

MySQL

Arduino IDE

2.3.1. Placas de desarrollo ESP32

El ESP32 es un System On Chip (SoC) diseñado por la compañía Espressif Systemspero fabricado por la firma TSMC. Al igual que la familia ESP8266, y del cual elESP32 es su sucesor directo, dispone de varios modelos con diferentes caracterís-ticas.

En la tabla 2.1 se pueden observar algunos módulos que han sido desarrolladospor Espressif Systems.

TABLA 2.1. Módulos de la familia ESP 32 1.

Módulo Chip FLASH RAM Ant

ESP32 WROOM 32 ESP32-DOWDQ6 4MB - MIFAESP32 WROOM 32D ESP32-DOWD 4MB - MIFAESP32 WROOM 32U ESP32-DOWD 4MB - U.FLESP32 SOLO1 ESP32-SOWD 4MB - MIFAESP32 WROOVER ESP32-DOWDQ6 4MB 4MB MIFAESP32 WROOVER ESP32-DOWDQ6 4MB 4MB U.FL

1Tabla tomada de [15]

2.3. Elementos del sistema 11

De la familia de los chips fabricados por Espressif y mostrados en la tabla 2.1, eneste trabajo se empleó el modelo ESP32 WROOM, que se encuentra embebido enla placa DevKitC. Por otro lado, la placa cam tiene incorpado el modelo ESP32-Sde AI-Thinker, que es equivalente al modelo ESP32-WROOM. Las característicasde las placas cam y DevKitC se describen en las siguientes secciones.

ESP32 cam

El ESP32 cam (ver figura 2.1) es una placa de desarrollo de bajo costo y consumode energía, con tecnología WiFi y Bluetooth de modo dual integrada. Esta tarje-ta de desarrollo cuenta con un microprocesador Tensilica Xtensa LX6 de doblenúcleo con frecuencia de reloj de hasta 240 MHz, una cámara OV2640 con flashintegrado, un slot para microSD card y varios pines de propósito general de en-trada/salida.

El ESP32 cam está integrado con un switch de antena balun para radiofrecuen-cia, amplificador de potencia, amplificador de recepción con bajo nivel de ruido,filtros y módulos de administración de energía.

FIGURA 2.1. Placa de desarrollo ESP32 cam de AI Thinker2.

Las principales características de la placa se muestran en la tabla 2.2. Debido a sucapacidad de memoria SRAM, su antena WiFi y su cámara de tamaño compacto,podría decirse que el ESP32 cam es una herramienta adecuada para el desarrollode este trabajo.

En la figura 2.2 se muestra el pinout de la placa de desarrollo ESP32 cam. Lospines 2, 4, 12 al 15 soportan Real Time Clock (RTC).

2https://www.diymore.cc/products/esp32-cam-wifi-wireless-module-esp32-serial-to-wifi-esp32-cam-spi-flash-bluetooth-development-board-with-ov2640-camera-module

3Tabla tomada de [16]

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

TABLA 2.2. Características de la placa de desarrollo ESP32 cam3.

Item Descripción

SPI flash 32MbitRAM 520KB SRAM +4M PSRAMBluetooth Estándares Bluetooth 4.2 BR/EDR and BLEWiFi 802.11 b/g/n/Comunicación UART, SPI, I

2C, PWM

Tarjeta TF 4GPuertos IO 9Baudrate 115200 baudiosAntena Antena PCB integrada, ganancia 2dBiTensión de trabajo 5 VCertificados de seguridad WPA/WPA2/WPA2-Enterprise/WPSTemperatura de operación -20 ◦C a 85 ◦C

FIGURA 2.2. Pinout de la placa ESP32 cam de AI Thinker4.

ESP32 WROOM DevKitC

La placa de desarrollo ESP32 WROOM DevKitC contiene un microprocesadordel tipo Tensilica Xtensa R© Dual-Core 32-bit LX6, módulo WiFi, Bluetooh/BluetoothLow Energy y otras características que se muestran en tabla 2.3. Cada núcleo quecompone este dispositivo puede ser controlado individualmente o pueden serprogramados para que trabajen de forma cooperativa. Adicionalmente, cuentacon pines adaptados e incluye interfaz USB que también sirve de alimentación ala placa. Por último incorpora dos pulsadores con reset y boot.

Las figura 2.3 y 2.4 muestran los pines de propósito general (GPIO) y especialesde la ESP32 WROOM.

4https://randomnerdtutorials.com/esp32-cam-ai-thinker-pinout/5Ver referencia de la tabla 2.1

2.3. Elementos del sistema 13

TABLA 2.3. Características de la placa ESP32 WROOM5.

Item Descripción

ROM 44KBytesRAM 520KB SRAMBluetooth Estándares Bluetooth 4.2 BR/EDR and BLEComunicación UART, SPI, I

2C, PWM

WiFi802.11 b/g/n

modo estación/softAP/SoftAP+station/P2PBaudrate 115200 baudiosTensión de trabajo 2.2 V a 3.6 VInterfaces JTAG/USBCertificados de seguridad WPA/WPA2/WPA2-Enterprise/WPSTemperatura de operación -20 ◦C a 85 ◦C

FIGURA 2.3. Pines de propósito general de la placa de desarrolloESP32 WROOM DevKitC6.

2.3.2. Sensor infrarrojo

Un detector infrarrojo (IR - infrared) es un dispositivo optoelectrónico que se em-plea para medir temperatura y detectar objetos calientes. Estos sensores se utili-zan en múltiples aplicaciones tales como: vigilancia de objetos y personas, medi-ciones de temperaturas remotas en aplicaciones industriales, entre otras.

6https://forum.fritzing.org/t/esp32s-hiletgo-dev-boad-with-pinout-template/53576Ver referencia 2.3

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

FIGURA 2.4. Funciones de los pines de la placa de desarrolloESP32 WROOM DevKitC1.

Principios de la detección infrarroja

La física de la detección infrarroja es gobernada por tres leyes:

Ley de radiación de Planck: todo objeto que posea una temperatura dife-rente al cero absoluto (0 ◦K) emite radiación [17].

Ley de radiación de Stefan-Boltzman: esta ley indica que la rapidez con lacual se irradia energía en forma de radiación electromagnética desde unasuperficie es directamente proporcional a la cuarta potencia de la tempera-tura absoluta del cuerpo radiante [18].

Ley de desplazamiento de Wien: establece que hay una relación inversaentre la longitud de onda en la que se produce el pico de emisión de uncuerpo negro y su temperatura [19].

En el mercado, existen diversos detectores IR, desde pirómetros, sensores de mo-vimiento hasta cámaras termograficas. Los sensores IR utilizados en diversas eta-pas de este desarrollo fueron:

Mlx90614

Optris CTFast

Mlx90614

Este sensor está compuesto por dos chips desarrollados y fabricados por Melexis:

Mlx81101

ASSP Mlx90302

El Mlx90614 (ver figura 2.5) cuenta con un amplificador de bajo ruido, un con-vertidor analógico digital de 17 bits y un procesador digital de señales. Por otrolado, este detector soporta el protocolo de comunicación SMBus, el cual es similaral I2C.

2.4. Protocolos de comunicación 15

FIGURA 2.5. Imagen que muestra el detector infrarrojo Mlx906147.

Optris CTFast

Este sensor es parte de la serie de alto rendimiento de la firma Optris, los cualesse utilizan principalmente en el área de la industria, investigación y desarrollopor su innovador puntero láser.

El CT Láser permite mediciones exactas de la temperatura en objetos desde 0,9mm a una distancia de 70 mm.

FIGURA 2.6. Detector infrarrojo de la marca Optris 8.

En la tabla 2.4 se pueden observar tanto las características del Mlx90614 como delOptris CTFast. Para este trabajo se decidió utilizar el sensor OptrisCTFast. Loscriterios considerados para la elección del sensor son presentados en el capítulo3.

2.4. Protocolos de comunicación

Para los sistemas embebidos con conectividad e intercambio de datos en la nu-be, los protocolos de comunicación más conocidos son MQTT (Message QueuingTelemetry Transport) y CoAP (Constrained Application Protocol). En este trabajo seempleó el protocolo de comunicación MQTT. En los siguientes párrafos se hace

7https://www.14core.com/wiring-the-mlx90614-infrared-contactless-temperature-measurement-sensor-with-microcontroller/

8https://www.optris.es/optris-ctlaser-lt-ltf

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

TABLA 2.4. Tabla comparativa de sensores IR empleados.

Descripción Mlx90614 Optris CTFast

Tensión de trabajo 5 VDC 8 a 36 VDC

Rango de temperatura Objeto −70 ◦C a 382 ◦C −50 ◦C a 975 ◦CTemperatura Ambiente −40 ◦C a 125 ◦C −20 ◦ a 120 ◦CResolución 0,02 ◦K 0,02 ◦KRespuesta en el tiempo 0,25 s 9 msSalidas PWM de 10 bits 0/4-20 mA, 0-5/10 VConexión USB No Sí

una descripción de los protocolos mencionados anteriormente y se muestran susprincipales características.

2.4.1. MQTT

MQTT es un protocolo publish/suscribe en el que los clientes envían y reciben men-sajes que son gestionados por un elemento central llamado broker o mediador. Porlo tanto, el protocolo MQTT presenta una topología de estrella (ver figura 2.7)donde hay uno nodo central. MQTT se encuentra situado por encima del proto-colo Transmission Control Protocol (TCP - ver figura 2.8). Dentro de las ventajas deeste protocolo se pueden mencionar su fácil implementación y la baja demandade recursos a nivel de procesamiento y ancho de banda.

FIGURA 2.7. Topología del protocolo de comunicación MQTT9.

9https://unelectronica.github.io/

2.4. Protocolos de comunicación 17

FIGURA 2.8. Capas del protocolo MQTT10.

Modelo publicación/suscripción

El modelo de publicación/suscripción, como se observa en la figura 2.9, es unparadigma de envío de mensajes asíncrono mediante el cual los usuarios quepublican información (productor) no la envían directamente a los usuarios quesolicitan esta información (consumidor), sino que lo hacen a través de un broker.

En este modelo un productor de la información anuncia la disponibilidad de uncierto tipo de datos en un canal. El consumidor interesado en la información sedebe suscribir a este canal y será informado en cada momento que el productorpublique nueva información.

Los principales elementos del modelo publicación/suscripción son los siguientes:

Productor de información

Consumidor de la información

Broker

FIGURA 2.9. Elementos que componen el modelo publicación/-suscripción 11.

Tópicos

Los tópicos son strings UFT-8, que usa el broker para dirigir los paquetes entre losdiferentes clientes conectados a él. Cuando un cliente publica un mensaje a untópico, el broker es el encargado de enviar ese mensaje a todos aquellos clientesque estén suscriptos.

El tópico debe contener como mínimo un carácter y puede tener o no distinciónde niveles que se separan mediante /", dando una estructura de jerarquía a lostópicos. Los tópicos son sensitive case, es decir, discriminan entre mayúculas yminúsculas [21].

A continuación se muestran algunos ejemplos de tópicos:

10https://aprendiendoarduino.wordpress.com/2018/11/19/mqtt/11Imagen tomada de [20]

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

myhome/groundfloor/livingroom/temperature.

esp32/temperature.

En el protocolo MQTT existen dos símbolos comodín que son el + y el #. El + actúacomo comodín a un nivel, por lo que si un nodo se suscribe a myhome/+/lightrecibría mensajes del primer y segundo tópico. Por otro lado, el # actúa comocomodín de manera multinivel, es decir, si un nodo efectúa una suscripción amyhome/#, dicho nodo recibiría los mensajes de todos los tópicos.

Comunicación

En el protocolo MQTT la comunicación se realiza en cuatro etapas (ver figura2.10):

FIGURA 2.10. Proceso de comunicación del protocolo MQTT 12.

Como se puede inferir de la figura 2.10, en el primer paso para establecer la comu-nicación, un cliente comienza creando una conexión TCP/IP con el broker conec-tándose a un puerto estándar o un puerto personalizado definido por los opera-dores del broker. Los puertos estándar son el 1883 para la comunicación no cifrada,el 8883 para la comunicación cifrada mediante SSL/TLS y el 9001 para websockets.Al crear la conexión, es importante destacar que el servidor puede continuar unasesión anterior si el cliente le proporciona un ID previamente existente [22].

Calidad del servicio (QoS)

La calidad del servicio es un acuerdo entre el productor y el consumidor de losmensajes, que define la garantía de entrega de un mensaje específico. En MQTTexisten tres niveles de mensajes:

Disparar y olvidar (QoS = 0): no hay garantía de entrega del mensaje.

Por lo menos una vez (QoS = 1): en este nivel se garantiza que el mensajeserá entregado por lo menos una vez al receptor.

Exactamente una vez (QoS = 2): este es el nivel de servicio más alto enMQTT. En este nivel, la latencia aumentará debido a que cada mensaje re-quiere dos handshakes completos de ida y vuelta del remitente al receptor(cuatro en total del publicador al suscriptor).

El protocolo MQTT presenta trece diferentes paquetes de control CONNECT,CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE,SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP y DISCONNECT.En el protocolo MQTT los mensajes presentan la siguiente trama (ver figura 2.11):

Encabezado fijo (2 bytes): tipo de paquete, longitud del payload, QoS.

Encabezado variable (longitud variable): depende del tipo de paquete, ID,tópico.

12https://iot-es.herokuapp.com/post/details/7

2.4. Protocolos de comunicación 19

Payload del mensaje.

FIGURA 2.11. Trama MQTT.

2.4.2. CoAP

CoAP (ver figura 2.12) es un protocolo cliente-servidor que, a diferencia de MQTT,aún no está estandarizado al 100 %. Con CoAP, un nodo cliente puede comandara otro nodo vía un paquete CoAP. El servidor CoAP lo interpretará, extraerá lainformación del paquete y decidirá qué acción realizar dependiendo de su lógica.El servidor no necesariamente realizará la confirmación de la petición [23].

FIGURA 2.12. Topología del protocolo de comunicación CoAP 13.

En la tabla 2.5 se muestran las principales características de los protocolos MQTTy CoAP.

TABLA 2.5. Tabla comparativa de protocolos de comunicaciónanalizados.

Características MQTT CoAP

Protocolo base TCP UDPModelo usado para

Pub-Suscrip Preg.-Rta/Publ-Suscripla comunicaciónComunicación M:N 1:1Tamaño de

2 Bytes 4 BytescabeceraTipos de mensajes Asíncrono Asíncrono/Síncrono

SeguridadNo definida

DTLS o IPSecPuede usar TLS/SSL

Implementación Fácil de implementarPocas librerías

existentes y soporteNúmero de tipos

16 4de mensajesusados

13https://www.pickdata.net/es/noticias/mqtt-vs-coap-mejor-protocolo-iot

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

2.5. Herramientas y entornos de desarrollo

2.5.1. Herramientas de desarrollo

Para la programación de los diferentes sistemas embebidos y la interacción consu entorno, se emplean herramientas de desarrollo de software tales como PahoMQTT de Python, mosquitto para brokers y PostgreSQL, MySQL para base dedatos, entre otros. En el presente trabajo, se emplearon las herramientas que sedescriben a continuación:

Mosquitto

Mosquitto es un broker MQTT de código abierto, ampliamente utilizado debido asu ligereza, lo que permite fácilmente emplearlo en un gran número de ambien-tes, incluso si estos son de recursos muy limitados como los sistemas embebidos[24].

MySQL

Es un sistema de gestión de base de datos objeto del tipo relacional, es decir, utili-za tablas múltiples que se interconectan para almacenar la información y organi-zarla correctamente. También, cabe mencionar que MySQL es de código abiertoy distribuido bajo licencia BSD [25].

Node Red

Es una herramienta fundamentada en el paradigma de programación basada enflujo, la cual se encuentra desarrollada en Node.js y escrita en javascript. NodeRed dispone de un modelo de entradas y salidas para crear aplicaciones. Estaherramienta de desarrollo permite unir dispositivos hardware, Application Pro-gramming Interfaces (APIs) y servicios en línea [26].

En la figura 2.13 se muestra un flujo típico en Node Red.

2.5.2. Entornos de Desarrollo

En los siguientes párrafos se describen de los entornos de desarrollo que permitenprogramar el microcontrolador ESP32. En particular, en este trabajo se empleó elentorno de desarrollo Arduino IDE y los criterios de su elección se indican en elcapítulo 3.

ESP-IDF (Espressif Devolopment IoT Framework)

Este entorno de desarrollo, producido por Espressif Systems, está basado en ellenguaje C/C++. Cuenta con una gran cantidad de funciones definidas y un am-plio soporte del fabricante en la web. Adicionalmente, para el desarrollo de susfunciones emplea el código nativo de FreeRTOS.

Para llevar a cabo aplicaciones con este entorno, es indispensable instalar el tool-chain, que no es muy recomendable debido a las siguientes razones: dificultaddel manejo del terminal, lentitud de compilación y posterior flash del código en eldispositivo.

2.5. Herramientas y entornos de desarrollo 21

FIGURA 2.13. Flujo típico en Node Red.

Para un óptimo funcionamiento del toolchain es recomendable instalar un softwarede terceros como el Eclipse.

Arduino IDE

El Ambiente de Desarrollo Integrado Arduino (Arduino IDE) es un entorno dedesarrollo de código abierto, que soporta los lenguajes C/C++ usando reglas es-peciales de estructura de código.

Las aplicaciones desarrolladas en este entorno se caracterizan por tener tres partesdiferenciadas: una parte donde se llevan a cabo las inclusiones de bibliotecas ydefiniciones, dónde se pueden incluir constantes, variables y funciones; un setupque se inicia al arrancar el dispositivo y solo se ejecutará una vez, y por último, elloop donde se ejecuta el código de manera recurrente en bucle.

Entre las ventajas de este entorno de desarrollo se destacan las siguientes:

1. Interfaz amigable y facilidad de uso.

2. Dispone de un repositorio llamado gestor de librerías con todas las libreríasexistentes donde se puede descargar e instalar el código asociado fácilmentey utilizarse en la aplicación [15].

MicroPython IDE

MicroPython es una reimplementación del lenguaje de programación Python pa-ra microcontroladores y sistemas embebidos. Cabe mencionar que su principalventaja es la facilidad del lenguaje. Para desarrollar aplicaciones en sistemas em-bebidos con MycroPython se pueden emplear diferentes IDE’s tales como uPy-Craft, PyCharm o EspPy [15].

23

Capítulo 3

Diseño e Implementación

En este capítulo se hace una descripción detallada del hardware y software delHBD presentado en esta memoria. Adicionalmente, se muestran los criterios dediseño, la arquitectura y el funcionamiento del sistema.

3.1. Elementos del sistema

El HBD aquí desarrollado está compuesto por elementos de diversas tecnologías.Las características de dichos componentes, que fueron presentadas en la sección2.3, son: un pulsador on/off, que imita el comportamiento de un circuito de víaferroviario; un sensor IR del tipo CT de la marca Optris, dos placas de desarrolloESP32 (cam/cliente 1 y WROOM/cliente 2), un broker mosquitto, la herramientabasada en flujo Node Red y una base de datos del tipo SQL (ver figura 3.1).

FIGURA 3.1. Arquitectura del HBD.

Las funcionalidades de cada uno de los elementos del HBD se indican a conti-nuación:

Pulsador on/off: dispositivo cuya función principal es indicar al cliente 2, através de una señal en alto, la presencia del material rodante. Cabe mencio-nar que al emplear el pulsador on/off se busca simular el comportamientodel circuito de vía ferroviario.

Cliente 2: una que vez el material rodante es detectado por el circuito devía, que envía una señal en alto a la placa de desarrollo ESP32 WROOM, seactiva una interrupción dando inicio a la lectura de datos a través del ADC(conversor analógico digital, por sus siglas en inglés). Los datos leídos ca-da 9 ms son publicados con el tópico esp32/temperature con QoS 1 cada

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

vez que se excede el valor umbral establecido. Adicionalmente, las tempe-raturas son almacenadas en una microSD card e instanciadas en la base dedatos a través de la herramienta Node Red al cumplirse la condición de so-bretemperatura. De esta forma el HBD cuenta con un registro tanto físicocomo virtual de todas las temperaturas obtenidas por la ESP32. Los resulta-dos medidos son comparados con un valor umbral preestablecido. En casode detectarse cualquier valor superior al umbral, es activada una alarma yse envía una señal en alto al cliente 1.

Cliente 1: una vez recibida la señal por parte del cliente 2, se activa la cámaray se toma la fotografía del material rodante que se encuentre circulandoen ese momento. Posteriormente, la imagen tomada es almacenada en lamicroSD card y enviada a la base de datos utilizando el protocolo MQTT.

Sensor infrarrojo IR: realiza la lectura de temperatura de la caja de punta deejes.

Broker mosquitto: permite la comunicación entre los clientes 1 y 2 y NodeRed.

Node Red: esta herramienta de desarrollo permite leer y escribir a la basede datos.

Base de datos MySQL: permite el almacenamiento de forma virtual de lainformación recolectada (imágenes y temperaturas).

Un diagrama de bloques del proceso se puede ver en la figura 3.2.

En las siguientes secciones se mostrarán los criterios considerados para la eleccióndel sensor IR y las placas de desarrollo.

3.1.1. Sensor IR

Un parámetro importante para la selección del dispositivo de medición fue eltiempo de respuesta del sensor. Para ello, se tuvieron en cuenta los siguientesaspectos: la velocidad del material rodante, la cual varía de acuerdo con el tramode ruta en que se encuentre y la posibilidad de realizar al menos tres medicionessobre la zona de la punta de eje, cuyo diámetro es de 230 mm. En Argentina, loscasos comunes en cuanto a las velocidades de explotación ferroviaria son:

5 kmh−1, que es la velocidad permitida ingresando en la zona andén.

12 kmh−1, que es el común para todo tramo en zonas de precaución de vía(zona de cambios, mantenimiento, personal trabajando a un costado de lavía, etc.).

80kmh−1, que es la velocidad máxima permitida en vía.

Teniendo en cuenta que se requiere tomar por lo menos tres muestras sobre lazona de caja de punta de eje, se pueden calcular los tiempos de respuesta nece-sarios del sensor IR. Los tiempos calculados para las velocidades de explotaciónferroviaria se muestran en la tabla 3.1.

En la tabla 2.4 se hace una comparación de las características de los sensores eva-luados en este trabajo. En una etapa inicial, se utilizó el Mlx90614 con una placade desarrollo EDU-CIAA. El Mlx90614 tiene un tiempo de respuesta de 0,9 s. Da-do que para este trabajo el tiempo de respuesta es un parámetro fundamental,

3.1. Elementos del sistema 25

Estado sleep

Pulsador activo?

Cliente 2 -- Preparado para medir

Recolección y evaluación de datos

Alguna sobretemperatura?

Activar cliente 1

Si

cliente 1 activo?

Tomar/Almacenar/Enviar imagen

Se guardó/almacenó/envío

imagen?

No

Si

Si

Si

Si

Si

No

Mensaje de error 2

No

Mensaje de error 1 No

FIGURA 3.2. Diagrama de bloques del proceso de medición delHBD.

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

TABLA 3.1. Tiempo de respuesta del sensor IR.

Vmax [kmh−1] Tiempo de respuesta [ms]

5 55,212 2380 3,45

y como se puede observar en la tabla 2.4, dicho tiempo es de 9 ms en el sensorIR Optris. Teniendo presente lo expuesto anteriormente, se optó por el sensor demenor tiempo de respuesta para el desarrollo del HBD. Posteriormente, se veri-ficó la velocidad del material rodante considerando el tiempo de respuesta delsensor IR elegido. Es decir, para un tiempo de respuesta de 9 ms, la velocidad delmaterial rodante debe ser de 30 kmh−1, la cual se encuentra dentro del rango develocidades de explotación ferroviaria.

3.1.2. Placas de desarrollo

Dentro de los criterios considerados para la elección de las placas de desarrollose pueden mencionar:

Conectividad WiFi.

Consumo de energía, siendo importante la ejecución del modo “sleep“.

Posibilidad de tomar y almacenar imágenes.

Costo.

Conectividad WiFi

Para poder transmitir los datos y las imágenes capturadas desde cada uno de losclientes al broker mosquitto, las placas de desarrollo deben contar con la posibili-dad de conectarse a internet a través de un punto de acceso de la red inalámbrica.Las placas de desarrollo ESP32 soportan la tecnología estándar WiFi 802.11 b/g/n(802.11 n a 2,4 GHz hasta 150 Mbit/s).

Modos de consumo de energía

De las placas analizadas en este trabajo, se encontró que la ESP32 fue la única pla-ca de desarrollo con esta funcionalidad. Las placas de desarrollo ESP32 presentandiversos modos de consumo de energía (ver tabla 3.2). Entre ellos:

Activo

Modem sleep

Deep sleep

Hibernación

En este trabajo se utilizó el modo deep sleep, ya que reduce el consumo de energíay permite extender la vida de la batería del equipo. En este modo la placa desac-tiva el WiFi, el System Clock, la unidad central del proceso y queda en suspenso.Por otro lado, quedan activos el co-procesador de ultra baja potencia (ULP por

3.1. Elementos del sistema 27

TABLA 3.2. Especificaciones consumo de potencia RF. Unidadesen mA1.

Modo Consumo

Transm. 802.11b DSS 1Mbps, POUT=+19.5dBm 240Transm. 802.11b OFDM 54Mbps, POUT=+16dBm 190Transm. 802.11g OFDM MCS7, POUT=+14dBm 180Rec. 802.11b/g/n 95 a 100Transm. BT/BLE,POUT = 0 dbm 130Rec. BT/BLE 95 a 100

sus siglas en inglés) y el RTC, para poder reiniciar la placa cuando haya finali-zado el tiempo de reposo. Este modo de operación es útil si se emplea el modo“despertar“ la CPU principal con una interrupción externa.

Para habilitar la placa de desarrollo a partir del modo ahorro de energía (modosleep) existen diversas fuentes, que se indican a continuación:

1. Timers

2. Touch pad

3. Wake Up “Externo“

El controlador del RTC contiene lógica para disparar el modo despertar cuandoun pin es configurado a un nivel lógico. Estos pines pueden ser 2, 12-15 para laplaca cam. Entre tanto, para la placa WROOM, además de los indicados anterior-mente, también se encuentran habilitados para tal fin los pines 25-27, 32-39.

En este trabajo se configuró la fuente externa Wake Up a través del pin 35 para laplaca WROOM y el pin 13 para la placa cam.

Captura de imágenes fotográficas

Para validar que las mediciones de temperatura correspondan al material rodan-te se utilizó una imagen fotográfica. De las opciones disponibles en el mercado,se encontró que la placa ESP32 cam reunía dicho requisito, ya que como se men-cionó en la sección 2.3 cuenta con una cámara y un slot para microSD card. Cabemencionar que en esta etapa también se evaluó la posibilidad de implementaresta funcionalidad a través de una placa de desarrollo Arduino Uno junto conlos módulos de la cámara OV7670, microSD card y el shield de WiFi. Esta últimapropuesta requiere de mayor conexionado, lo que aumenta la complejidad deldispositivo.

Costo

Otro parámetro que se tuvo en cuenta en el momento de la elección fue el costode la placa de desarrollo. En la tabla 3.3 se puede observar que no se encontróuna diferencia considerable en el costo entre las placas de desarrollo analizadas.

1Tabla tomada de [27]

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

TABLA 3.3. Tabla comparativa del costo de las placas de desarro-llo.

Modelo Costo (ARS$)

ESP8266 765ESP32 WROOM 1400ESP32 cam 1600Arduino Uno + Shield WiFi + Módulo cámara 4000EDUCIAA + Módulo cámara 6000

3.2. Descripción interna de la aplicación

En los siguientes párrafos se muestran partes del código empleado en esta memo-ria. Dado que para el manejo de la comunicación e interconexión con la red WiFiy el broker las placas de desarrollo de la familia ESP32 emplean las mismas biblio-tecas y funciones, se hace una mención general de las utilizadas en la aplicación.En primer lugar, cabe destacar que de los IDEs evaluados en la sección 2.3 (ESP-IDF, MicroPython y Arduino) para el desarrollo del software se eligió emplear elentorno de desarrollo Arduino IDE, que tienen como ventajas su facilidad de uso,amplia comunidad de usuarios, gran abanico de bibliotecas y API’s de terceros.

De los protocolos de comunicación evaluados en la sección 2.4, MQTT y CoAP(se encontró que MQTT) era el más adecuado para este trabajo, ya que permite lacomunicación entre el broker y muchos clientes. Entre tanto, CoAP solo permite lacomunicación uno a uno.

3.2.1. ESP32

El código principal para el ESP32 comienza con la importación de las bibliotecasnecesarias para el módulo microSD card, el servirdor NTP y la conexión WiFi.Posteriormente, para el ESP32 cam se realiza la configuración de los pines de lacámara, la microSD card y el tamaño de la memoria EEPROM a utilizar. Parapermitir la conexión interna entre la cámara y la placa de desarrollo, se debenconfigurar los pines para cada uno de ellos (ver tabla 3.4). Por otro lado, para laplaca ESP32 WROOM se configura el GPIO 5 como el pin para la microSD card.

Para llevar a cabo la conexión de la placa de desarrollo a la red WiFi y al brokermosquitto, se realizaron las definiciones indicadas en el código 3.1.

1 // Credencia les para conexion de l a ESP32 a l a red WiFi# def ine SSID_WIFI "−−−"

3 # def ine PASSWORD_WIFI "−−−"

5 // D e f i n i c i o n de l a d i r e c c i o n IP del broker# def ine MQTT_HOST IPAddress ( 1 9 2 , 168 , 1 , −−−)

7

//D e f i n i c i o n del puerto a emplear9 # def ine MQTT_PORT 1883

CÓDIGO 3.1. Definición de las constantes para conexión WiFi ymosquitto.

2Tabla tomada de [16]

3.2. Descripción interna de la aplicación 29

TABLA 3.4. Tabla configuración pines ESP32 cam2.

CAM ESP32 (PIN) SD ESP32 (PIN)

D0 5 CLK 14D1 18 CMD 15D2 19 DATA0 2D3 21 DATA1flash lámpara 4D4 36 DAT2 12D5 39 DATA3 13D6 34D7 35XCLK 0PCLK 22VSYNC 25HREF 23SDA 26SCL 27POWER PIN 32

Posteriormente, se creó un objeto para manejar el cliente MQTT y los timers parareconectar al broker mosquitto y al router cuando se produce una desconexión(ver código 3.2).

1 TimerHandle_t mqttReconnectTimer ;TimerHandle_t wifiReconnectTimer ;

CÓDIGO 3.2. Objeto para manejar el cliente MQTT y los timersque permiten la reconexión a mosquitto y al router.

Para el manejo de la conexión al broker se emplearon las funciones que vienenintegradas en la librería Asyn Mqtt Client. Una de ellas es la función WiFiEvent(ver código 3.3) que es responsable del manejo de los eventos de WiFi (ver tabla3.5), tales como la conexión y desconexión con el router y mosquitto.

void WiFiEvent ( WiFiEvent_t event ) {2 switch ( event ) {

case SYSTEM_EVENT_STA_GOT_IP :4 connectToMqtt ( ) ;

break ;6 case SYSTEM_EVENT_STA_DISCONNECTED :

xTimerStop ( mqttReconnectTimer , 0 ) ; // asegura que no ser e e s t a b l e z c a l a conexion a l broker mientras se i n t e n t a r e c o n e c t a r al a red Wifi

8 xTimerStar t ( wifiReconnectTimer , 0 ) ;break ;

10 }}

CÓDIGO 3.3. Función WiFiEvent.

3Tabla tomada de [15].

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

TABLA 3.5. Eventos WiFi en ESP32 3.

Evento Descripción

SYSTEM_EVENT_STA_DISCONNECTEDDesconectado del AP co-mo estación

SYSTEM_EVENT_STA_GOT_IPAsignar una IP al dispo-sitivo desde el AP

Publicación de tópicos MQTT

Para llevar a cabo la publicación de las lecturas de datos (cliente2) o de imágenes(cliente1) según corresponda, se usa el método publish y el objeto mqttClient. Elmétodo publish presenta los siguientes argumentos [27]:

Tópico MQTT.

QoS.

Bandera de retención del mensaje.

Payload: según la placa de desarrollo, correspondería a la lectura de datosdel sensor o las imágenes captadas por la cámara.

A continuación se muestra el caso para la publicación de los datos de temperatu-ra:

1 u i n t 1 6 _ t packetIdPub1 = mqttCl ient . publ ish (MQTT_PUB_TEMP, 1 , true ,S t r i n g ( temp ) . c _ s t r ( ) ) ;

CÓDIGO 3.4. Método empleado para la publicación de un tópico.

Una de las principales características de las placas de desarrollo ESP32 es la posi-bilidad de implementar el modo de ultra-bajo consumo. Para poder habilitar lasplacas a partir del modo deep sleep, en este trabajo se configuró la fuente externaWake Up a través de la función: esp_sleep_enable_ext0_wakeup.

Suscripción a tópicos

En el proceso de suscripción desde Node Red a mosquitto, para recibir los datosde temperatura y las imágenes tomadas por los clientes, se implementó un dia-grama de flujo como el que se puede apreciar en la figura 3.3. Los parámetrosempleados en la configuración fueron los siguientes: QoS igual a 1, se configurael output para que sea de forma automática y se establece un tema en Topic, permi-tiendo de esa forma a mosquitto redireccionar el mensaje. El proceso de conexiónindicado anteriormente se puede observar en la figura 3.4.

Una vez efectuada la configuración de la ventana de mensajes se establece la di-rección IP y puerto de centro de mensajería de MQTT. Para esto se escribe ladirección pública del servidor que contiene la plataforma mosquitto y el puertodonde está corriendo el proceso.

3.2.2. Configuración MySQL -Node Red

Una de las características más destacadas de Node Red es la capacidad para agre-gar nuevos nodos, permitiendo de esta manera aumentar las posibilidades de

3.2. Descripción interna de la aplicación 31

FIGURA 3.3. Flujo suscripción a tópicos desde Node Red a mos-quitto.

FIGURA 3.4. Configuración conexión a broker mosquitto.

la aplicación desarrollada. Para este trabajo se utilizó un nodo que se encuentrafuera del paquete oficial. El nodo empleado fue Node-red-node-mysql, paqueteque permite realizar inserciones a colecciones específicas o realizar la lectura dela base de datos a través de Node Red.

La persistencia de la información en la base de datos se realizó a través de unnodo de función (ver figura 3.4), configurado de tal forma que permite insertar

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

los valores provenientes de los clientes 1 y 2 a la base de datos MySQL.

Los datos recibidos son mostrados en un cuadro de mando, como se puede ob-servar en la figura 3.5.

FIGURA 3.5. Interfaz Gráfica de Usuario.

33

Capítulo 4

Ensayos y Resultados

En este capítulo se documentan los resultados de las pruebas realizadas sobre elprototipo y sus componentes. Así mismo se especifica qué requisitos planteadosen el capítulo 2 lograron cumplirse con satisfacción.

4.1. Pruebas funcionales

Debido a la situación actual referente al COVID-19 las pruebas programadas parallevar a cabo en vía, fueron cambiadas por pruebas de simulación. Para ello laseñal del circuito de vía fue reemplazado por un pulsador on/off, y el sensoroptris CT, por un potenciómetro del tipo lineal de 1 kOhm.

Las pruebas llevadas a cabo en este trabajo son del tipo caja negra, es decir, aque-llas que buscan verificar las especificaciones del producto. Las pruebas consistie-ron en tratar de imitar la detección del material rodante; para ello se utilizó elpulsador on/off y la medición de temperatura a través de la variación del poten-ciómetro. Se estableció un umbral de la medición realizada y se efectuó la varia-ción del potenciómetro por arriba y por debajo del umbral establecido.

El orden lógico que se siguió para una correcta adquisición de los datos de tem-peratura e imágenes es el indicado a continuación:

Recibir la señal en alto una vez accionado el pulsador.

Obtener medición de la entrada analógica.

Lograr que los clientes 1 y 2 establezcan comunicación con el broker mos-quitto y con Node Red.

Capturar una imagen una vez superado un umbral preestablecido.

Lograr publicar mensajes MQTT.

Lograr instanciar los datos e imágenes en la base de datos.

4.2. Resultados

Se encontró que el dispositivo responde al oprimir el pulsador on/off, activandoel modo despertar del cliente 2 e iniciando el proceso de medición. Se varió lamedición por debajo del umbral preestablecido y se obtuvo un comportamientosatisfactorio del prototipo. Es decir, se almacenaron los datos tanto en la microSDcard como en la base de datos ESP32 (ver figura 4.1). Los valores medidos fueroncomparados con el valor umbral preestablecido. Cuando el valor fue superior al

34 Capítulo 4. Ensayos y Resultados

umbral, el cliente 1 fue activado. Posterior a su activación, este (el cliente 1) tomóy almacenó la imagen tanto en la microSD card en formato jpg como en la basede datos IMAGENES (ver figura 4.2), en formato blob (objeto binario grande porsus siglas en ingles).

FIGURA 4.1. Almacenamiento en la base de datos ESP32 de lastemperaturas medidas.

4.2. Resultados 35

FIGURA 4.2. Almacenamiento de imágenes captadas por el cliente1 (ESP32 cam) en la base de datos IMAGENES.

Otra parte del proceso se dio cuando Node Red recibió las lecturas captadas porel cliente 2 y las desplegó en forma de gauge en un dashboard (ver figura 4.3).

FIGURA 4.3. Dashboard medición de temperatura.

La figura 4.4 corresponde al proceso de comunicación establecido por el cliente 1y Node Red. Allí se puede observar el payload del mensaje, en este caso la imagentomada, la suscripción al tópico esp32/images y la QoS establecida, que para estetrabajo se fijó en 1.

36 Capítulo 4. Ensayos y Resultados

FIGURA 4.4. Publicación de datos a través del broker mosquitto.

Desde el lado de Node Red la imagen fue recibida (ver figura 4.5) y mostrada alusuario. En este caso se mostró una imagen del lugar donde se realizó el ensayo.

FIGURA 4.5. Imagen recibida por la herramienta de desarrollo No-de Red

Una vez que el valor de la medición volvió a estar por debajo del umbral, el cliente1 retornó a su estado deep sleep. El proceso finalizó cuando se liberó el pulsador,lo cual hizo que el cliente 2 volviera a su estado deep sleep.

4.3. Requisitos cumplidos

Llegado a este punto, se puede afirmar que de los requisitos propuestos en lasección 2 para este trabajo, se cumplieron los siguientes:

Si bien las pruebas de campo no pudieron llevarse a cabo, el sistema seencuentra preparado para realizar mediciones en un rango de temperaturadesde 0 ◦ hasta 120 ◦C.

4.3. Requisitos cumplidos 37

Los elementos que integran el sistema cuentan con la robustez necesariapara operar en el rango de temperaturas desde 0◦ hasta 50 ◦C.

Las temperaturas e imágenes adquiridas por el sistema son mostradas enuna computadora a través de un dashboard desarrollado empleando la he-rramienta Node Red.

Una vez detectado un valor de sobretemperatura se emite una señal de ad-vertencia que alerta sobre una anomalía en el elemento evaluado.

Las temperaturas e imágenes captadas son almacenadas tanto de forma lo-cal, a través de una microSD card, como de manera remota empleando elmotor de base de datos MySQL.

El sistema desarrollado detecta de forma remota y en tiempo real las tem-peraturas e imágenes captadas.

El sistema desarrollado logra un consumo de energía ultra-bajo a través delmodo deep sleep.

Por otro lado, se puede afirmar que se encuentra en desarrollo la interfaz gráficaque permitirá al usuario modificar los valores umbrales de temperatura. Para ellose debe contar con conocimientos en desarrollo web.

39

Capítulo 5

Conclusiones

En el presente capítulo se muestran las conclusiones obtenidas y se esbozan lasactividades a seguir.

5.1. Conclusiones generales

En este trabajo se diseñó e implementó un dispositivo HBD, que permite detectartemperaturas, libre de contacto y de manera continua, en cajas de punta de eje dematerial rodante al efectuar mediciones con tecnología infrarroja. Cabe mencio-nar que, si bien no pudieron llevarse mediciones en vía, debido al COVID-19, seeligió el sensor IR adecuado y el sistema embebido se encuentra preparado paraconectarse al dispositivo e implementar la lógica requerida. Adicionalmente, elHBD mostrado en este trabajo es una herramienta que permitirá a las operadorasferroviarias del país, especialmente el personal de mantenimiento de las empre-sas, efectuar una detección y evaluación temprana de fallas, minimizando y/oevitando las interrupciones del servicio y/o posibles accidentes.

En los diferentes capítulos de esta memoria, se abordaron con profundidad lasherramientas y conocimientos necesarios para la elección de los componenteselectrónicos que integran el prototipo y los sistemas de comunicación emplea-dos. Teniendo presente lo indicado anteriormente, a continuación se muestran enorden de desarrollo las tareas implementadas en el presente trabajo:

Se estudiaron el funcionamiento y las características eléctricas/electrónicasde los sensores infrarrojos y las placas de desarrollo de la familia ESP32,particularmente los modelos cam y WROOM.

Posteriormente, se encaró el estudio de los diferentes entornos de progra-mación para placas ESP32 y se eligió el Arduino IDE para tal fin.

Una vez determinados el sensor IR y las placas de desarrollo, junto con suentorno de programación, se abordó el estudio de los protocolos de comuni-cación; el adecuado para el sistema descripto en esta memoria el protocoloMQTT.

Para el almacenamiento de imágenes y temperaturas se eligió una base dedatos del tipo relacional. El motor de base de datos empleado para estetrabajo fue MySQL.

Para verificar el funcionamiento del diseño desarrollado en este trabajo, serealizó un conjunto de pruebas funcionales. Se pudo comprobar que el sis-tema responde ante el estímulo (activación del pulsador), es decir, lee y al-macena tanto de forma local como remota las temperaturas e imágenes.

40 Capítulo 5. Conclusiones

5.2. Próximos pasos

Una continuación natural de este trabajo sería llevar a cabo mejoras del sistemapropuesto aquí. Dentro de dichas mejoras se sugieren las siguientes:

1. Desarrollar una placa PCB que integre todos los componentes electrónicosdel sistema.

2. Implementar un servidor web, que permitiría una mayor interacción delusuario final y el sistema.

3. Llevar a cabo evaluaciones del sistema integrado en las vías de prueba deSOFSE.

41

Bibliografía

[1] A. Berbey; R. Caballero; J.D. Sanz Bobi; J. Brunel; K. Guerra; J. Flores 1; A.Samaniego; W. Orozco. «Trenes:material rodante del transporteferroviario». En: Prisma Tecnológico (2013).

[2] Peña Muñoz Alberto. Simulación de la dinámica de un vehículo ferroviariomediante herramientas de ingeniería asistidas por ordenador. 2016.

[3] ITSS. Pegasus HABD/HWD : Hot axle box/ Hot wheel detector. URL:http://www.itss.tech/pegasus-habd-hwd.

[4] Eke Electronics. Hot Axle Box Detection System (HABD). URL:https://www.eke-electronics.com/hot-axle-box-detection-system-habd.

[5] Rail Engineering. What is TCMS? URL:https://www.railengineer.co.uk/2015/08/11/what-is-tcms/.

[6] Voestalpine Company. Modular Diagnostic System - PHOENIX MDS. URL:https://www.voestalpine.com/signaling/en/products/Modular-Diagnostic-System-PHOENIX-MDS/.

[7] Sonja-Lara Bepperling y Andreas Schöbel. «Estimation of SafetyRequirements for Wayside Hot Box Detection Systems». En:FORMS/FORMAT. 2010.

[8] Joffrey Clarhaut, Etienne Lemaire y El-Koursi El-Miloudi. «Methodologyfor Assessing Safety Systems Application for a Railway Hot BoxProtection System». En: FORMS/FORMAT 2010 - Formal Methods forAutomation and Safety in Railway and Automotive Systems (2011). DOI:10.1007/978-3-642-14261-1_13.

[9] E. G. Menaker. «The Fundamentals of Infrared Hotbox Detection». En:IEEE Transactions on Applications and Industry 82 (1963).

[10] S. D. Milic y M. Z. Sreckovic. «A Stationary System of NoncontactTemperature Measurement and Hotbox Detecting». En: IEEE Transactionson Vehicular Technology 57 (2008).

[11] Gamze Garip y col. «Hot Box Detection System Design for Railway VehicleSafety». En: 2014.

[12] Andreas Schöbel, Manfred Pisek y Johannes Karner. «Hot box detectionsystems as a part of automated train observation in Austria». En:Universidad Carlos III de Madrid (2006).

[13] Ying Wang y ZhengRong Wu. «A Train Hot Bearing Detection SystemBased on Infrared Array Sensor». En: Atlantis Press, 2013/02,págs. 733-736. ISBN: 978-90-78677-63-5. DOI:https://doi.org/10.2991/isccca.2013.184. URL:https://doi.org/10.2991/isccca.2013.184.

[14] Fabian Sarmiento. Plan de Proyecto del Trabajo Final de Carrera deEspecialización de Sistemas Embebidos Fabian Sarmiento. URL:https://docs.google.com/document/d/1Z-4Q-diWUWuUquhRDrBZkXNYqz1GXm48JUqrz1vXZ80/edit?usp=sharing_eil&ts=5c8a86f9.

[15] Alvaro Benitez Herrán. Desarrollo de Aplicaciones para IoT con el móduloESP32. 2019.

42 Bibliografía

[16] Ai-Thinker ESP32 CAM Module. Rev. V1.0. Ai-Thiker Technology. 2017.[17] Wikipedia. Radiación térmica — Wikipedia, La enciclopedia libre. [Internet;

visitado 30-junio-2020]. 2020. URL:https://es.wikipedia.org/wiki/Radiaci%C3%B3n_t%C3%A9rmica.

[18] Ley de Stefan-Boltzmann. URL:http://fisiplus.blogspot.com/2014/11/ley-de-stefan-boltzmann_25.html.

[19] Wikipedia. Ley de desplazamiento de Wien — Wikipedia, La enciclopedia libre.[Internet; descargado 22-marzo-2020]. 2020. URL:https://es.wikipedia.org/w/index.php?title=Ley_de_desplazamiento_de_Wien&oldid=124428530.

[20] Alberto José Juan Torres. Uso de XMPP para el transporte de informacióncooperativa y de contexto. 2009.

[21] Frances Moreno Cerdá. Demostrador arquitectura publish/suscribe con MQTT.2018.

[22] Agustin Bassi. Introducción a MQTT. URL:https://iot-es.herokuapp.com/post/details/7.

[23] PickData. MQTT vs CoAP la batalla por ser el mejor protocolo IoT. 2020. URL: https://www.pickdata.net/es/noticias/mqtt-vs-coap-mejor-protocolo-iot.

[24] Eclipse Foundation. Eclipse Mosquitto. 2020. URL: https://mosquitto.org/.[25] Redrován Castillo Fausto Zea Ordoñez Mariuxi Molina Ríos Jimmy.

Administración de base de datos con PostgreSQL. 2017.[26] Salvador García Jiménez. Desarrollo de paneles de control para redes IoT

basados en Node Red. 2018.[27] Rui Santos y Sara Santos. Learn Esp32 with Arduino IDE. Random Nerd

Tutorials, 2019.