integración de amazon freertos al proyecto ciaa

MAESTRÍA EN SISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Integración de Amazon FreeRTOS alproyecto CIAA

Autor:Esp. Lic. Roberto Compañy (UCH)

Director:Mg. Ing. Sergio Scaglia (UM)

Jurados:Mg. Ing. Facundo Larosa (FIUBA, UTN-FRH)

Dr. Ing. Emanuel Irrazabal (UNNE)Mg. Ing. Diego Brengi (INTI, UNLaM, FIUBA)

Este trabajo fue realizado en la ciudad de Mendoza,entre marzo de 2019 y diciembre de 2020.

I

Resumen

Cada vez es más frecuente potenciar los sistemas embebidos con plataformas enla nube. Para ello se deben implementar mecanismos de seguridad en las

comunicaciones que minimicen las vulnerabilidades asociadas. El proyectoCIAA cuenta con una amplia y activa comunidad que podría beneficiarse

enormemente con la utilización de servicios por internet, como por ejemplo,Amazon Web Services (AWS). Es por ello que este trabajo se centra en facilitar

herramientas para proveer un flujo de integración ágil para la EDU-CIAA-NXPcon AWS, utilizando encriptación de extremo a extremo. Adicionalmente, se

desarrolla un caso de uso específico para demostrar los beneficios de aplicar esterecurso tecnológico en proyectos de IoT, utilizando inteligencia artificial para

reconocer sonidos.

Para la realización de este trabajo se aplicaron conceptos de gestión de latecnología y la innovación, procesamiento de señales e implementación de

sistemas operativos. En cuanto al desarrollo del código se utilizaron técnicas deingeniería de software como patrones de diseño, control de versiones de código,

modularización, integración continua, entre otras.

III

Agradecimientos

A mi esposa Carolina, por el sacrificio enorme que hizo por mi para poder com-pletar esta maestría.

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

A mi director y amigo Sergio, por su orientación y apoyo permanente.

V

Índice general

Resumen I

1. Introducción general 11.1. Seguridad para el conexionado de sistemas embebidos a Internet . 1

1.1.1. Principios del tráfico seguro con Internet . . . . . . . . . . . 11.1.2. Mecanismos de seguridad . . . . . . . . . . . . . . . . . . . . 11.1.3. Encriptación simétrica y asimétrica . . . . . . . . . . . . . . . 2

1.2. Principales plataformas de servicios en la nube . . . . . . . . . . . . 21.3. Computadora Industrial Abierta Argentina (CIAA) . . . . . . . . . 31.4. Motivación, objetivos y alcance . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción específica 72.1. Hardware de la EDU-CIAA-NXP . . . . . . . . . . . . . . . . . . . . 72.2. Estructura del Firmware_v3 del proyecto CIAA . . . . . . . . . . . 92.3. Amazon FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1. Utilización de interrupciones . . . . . . . . . . . . . . . . . . 102.3.2. Administración de la memoria . . . . . . . . . . . . . . . . . 10

2.4. LWIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5. WolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6. MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7. Componente IoT Core de AWS . . . . . . . . . . . . . . . . . . . . . 122.8. Filtros digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.9. Ubicoustics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Diseño e implementación 153.1. Componentes de la solución . . . . . . . . . . . . . . . . . . . . . . . 153.2. Configurar AWS IoT Core . . . . . . . . . . . . . . . . . . . . . . . . 163.3. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1. Integrar biblioteca LWIP y configurar sobre FreeRTOS . . . 183.3.2. Integrar bibliotecas WolfSSL y WolfMQTT . . . . . . . . . . 193.3.3. Implementar caso de uso propuesto . . . . . . . . . . . . . . 213.3.4. Diseñar y organizar las tareas FreeRTOS . . . . . . . . . . . . 24

3.4. Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.1. Procesar paquetes y generar archivo WAV . . . . . . . . . . 253.4.2. Análisis y mejoramiento de la señal . . . . . . . . . . . . . . 273.4.3. Aplicar modelos de IA . . . . . . . . . . . . . . . . . . . . . . 29

4. Pruebas, validación y resultados 334.1. Pruebas y validaciones sobre el sistema embebido . . . . . . . . . . 33

4.1.1. Integración biblioteca LWIP . . . . . . . . . . . . . . . . . . . 334.1.2. Integración bibliotecas WolfSSL y WolfMQTT . . . . . . . . 344.1.3. Muestreo de la señal analógica y transmisión a AWS IoT Core 35

4.2. Pruebas y validaciones sobre la aplicación . . . . . . . . . . . . . . . 35

VI

4.2.1. Generación de los archivos WAV . . . . . . . . . . . . . . . . 354.2.2. Pruebas de inferencia con IA . . . . . . . . . . . . . . . . . . 36

4.3. Caso de uso completo . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5. Conclusiones 415.1. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

A. Actualizar biblioteca FreeRTOS en Firmware_v3 43

B. Configuración optimizada de Mbed TLS 45

C. Formato de los archivos WAV 49

Bibliografía 51

VII

Índice de figuras

1.1. Handshake SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Plataformas en la nube. . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Hardware CIAA-NXP. . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Hardware EDU-CIAA-NXP. . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Diagrama en bloques EDU-CIAA-NXP. . . . . . . . . . . . . . . . . 82.2. Hardware soportado por Amazon FreeRTOS. . . . . . . . . . . . . . 13

3.1. Diagrama de interacción. . . . . . . . . . . . . . . . . . . . . . . . . . 163.2. Conexión EDU-CIAA-NXP con interfaz phy LAN8720. . . . . . . . 173.3. Desglose del esquema heap_4. . . . . . . . . . . . . . . . . . . . . . . 203.4. Análisis de dominio en frecuencia con smartphone. . . . . . . . . . 223.5. Diagrama de interacción de principales tareas FreeRTOS. . . . . . . 263.6. Micrófono de los sensores keyes. . . . . . . . . . . . . . . . . . . . . 283.7. Conexionado del micrófono, el amplificador y la EDU-CIAA-NXP. 283.8. Señal de agua corriendo pura y amplificada. . . . . . . . . . . . . . 293.9. DFT de señal de agua corriendo pura y amplificada. . . . . . . . . . 30

4.1. Prueba de eco desde la consola. . . . . . . . . . . . . . . . . . . . . . 344.2. FreeRTOS Task Aware Debugger for GDB - NXP. . . . . . . . . . . . 344.3. Consola de AWS IoT Core. . . . . . . . . . . . . . . . . . . . . . . . . 354.4. Señal senoidal de 8 kHz. . . . . . . . . . . . . . . . . . . . . . . . . . 364.5. Filtro pasa bajos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6. Resultado de inferencia sobre sonido de agua corriendo con y sin

amplificador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.7. Proceso de captura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.8. Porcentaje en recepción de paquetes. . . . . . . . . . . . . . . . . . . 394.9. Envío de respuesta desde la aplicación al sistema embebido. . . . . 40

IX

Índice de tablas

2.1. Regiones de memoria EDU-CIAA-NXP. . . . . . . . . . . . . . . . . 82.2. Estructura del Firmware_v3 de la CIAA. . . . . . . . . . . . . . . . . 9

3.1. Pruebas indispensables sobre el firmware y la aplicación. . . . . . . 183.2. Configuración de regiones según bibliotecas. . . . . . . . . . . . . . 21

C.1. Estructura de un archivo WAV. . . . . . . . . . . . . . . . . . . . . . 49

XI

Dedicado a mis hijas, Virginia y Melina.

1

Capítulo 1

Introducción general

En este capítulo se expone una introducción a las conexiones seguras en Internet.También se presentan las principales plataformas actuales que brindan serviciosen la nube. Finalmente, se enuncia la problemática que motivó la realización delpresente trabajo y el enfoque elegido para integrar el proyecto CIAA con serviciosen Internet.

1.1. Seguridad para el conexionado de sistemas embebidosa Internet

La conexión de un sistema embebido con la nube permite potenciarlo en distin-tos aspectos. Entre las diversas posibilidades, está la de ejecutar algún procesode cálculo que requiera mucho cómputo para el hardware reducido del que nor-malmente dispone un sistema embebido. Además, permite acceder a informaciónremota relevante para los fines del sistema, así como también enviar datos parasu monitoreo.

Estas ventajas tienen como contraparte el riesgo de la exposición a hackeos, entrelos que cabe mencionar la suplantación de identidad, el robo de información yel comúnmente denominado ”ataque de intermediario” [1]. Esto requiere imple-mentar mecanismos que neutralicen las vulnerabilidades garantizando la confi-dencialidad, integridad, autenticidad y no refutación de la información.

1.1.1. Principios del tráfico seguro con Internet

El tráfico con Internet es seguro en la medida que se pueda garantizar:

Confidencialidad: la información sensible sólo puede ser accedida por losusuarios o sistemas autorizados.

Integridad: la información es completa, exacta y no duplicada.

Autenticidad: la identidad de los usuarios o sistemas que tratan la informa-ción debe ser efectivamente corroborada.

No refutación: ningún usuario o sistema puede negar con posterioridad lainformación que suministró.

1.1.2. Mecanismos de seguridad

Para garantizar estos principios se utilizan certificados de seguridad denomina-dos Secure Sockets Layers (SSL), que son un estándar de seguridad global [2] que

2 Capítulo 1. Introducción general

permite la transferencia de datos cifrados a través de Internet. Son utilizados porlos sistemas para implementar seguridad en las comunicaciones mediante el usode criptografía y disminuir el riesgo de robo y manipulación de información porparte de hackeos.

Cada certificado SSL contiene una clave pública que se encuentra vinculada a unaclave secreta llamada privada. La clave pública se deja a disposición de todosaquellos que requieran iniciar una comunicación encriptada. La clave privadadebe permanecer sólo en poder del dueño del certificado y ésta le permitirá poderdecodificar la información encriptada con la clave pública.

1.1.3. Encriptación simétrica y asimétrica

Existen dos tipos de encriptación que funcionan de distintas maneras y a su vezpresentan una importante diferencia en la utilización de recursos [3], a saber:

Encriptación asimétrica: consiste en codificar la información utilizando laclave pública para que sólo sea decodificada con la clave privada. Este me-canismo es más lento y requiere más recursos que la encriptación simétrica.

Encriptación simétrica: es el proceso por el cual se codifica y decodifica lainformación utilizando la misma clave. Este mecanismo es más eficienteque el anterior pero cuenta con el inconveniente de gestión y distribuciónde claves secretas.

Para lograr iniciar una comunicación segura y eficiente se requiere complementarambos tipos, utilizando una encriptación asimétrica para intercambiar una clavesimétrica. Este procedimiento es denominado handshake [4]. En forma resumida,el proceso consiste, en primer lugar, en negociar los protocolos a utilizar. Luego,mediante encriptación asimétrica se deriva una clave simétrica, la que se utilizarásólo para esa sesión. En la figura 1.1 se ilustra un ejemplo de este proceso.

1.2. Principales plataformas de servicios en la nube

Existe una tendencia en la utilización de inteligencia artificial (IA) en el mundoy también en nuestro país [5]. En cuanto a la utilización de IA en sistemas em-bebidos, estos comenzaron a incluir hardware especial dedicado a ejecutarla [6].Cuando no se dispone del hardware adecuado, ya sea por poca memoria o faltade capacidad de cómputo, la aplicación de IA puede realizarse en la nube y de-volver el resultado al sistema embebido para que actúe a partir de él. También seutilizan plataformas cloud para interconectar los dispositivos denominados Inter-net de las cosas (IoT).

En la actualidad existen varias plataformas cloud que brindan un conjunto de ser-vicios de computación en la nube para hacer frente a las necesidades del negocioen lo que respecta al desarrollo de aplicaciones, almacenamiento y cómputo. Al-gunas de las que están bien consolidadas a nivel mundial son: Amazon Web Ser-vices, Microsoft Azure, Google Nest, Apple, Samsung, entre otras [7]. Todas estasplataformas proveen además servicios especiales para IoT, en donde se establece

0Imagen tomada de https://publib.boulder.ibm.com/tividd/td/TRM/GC32-1323-00/en_US/HTML/admin231.htm

https://publib.boulder.ibm.com/tividd/td/TRM/GC32-1323-00/en_US/HTML/admin231.htm

https://publib.boulder.ibm.com/tividd/td/TRM/GC32-1323-00/en_US/HTML/admin231.htm

1.3. Computadora Industrial Abierta Argentina (CIAA) 3

FIGURA 1.1. Handshake SSL.

un marco de trabajo definiendo los protocolos de aplicación y de red, sistemasoperativos, etc. Esto se puede apreciar en la figura 1.2.

FIGURA 1.2. Plataformas en la nube.

1.3. Computadora Industrial Abierta Argentina (CIAA)

El proyecto CIAA nació en 2013 como una iniciativa conjunta entre el sector aca-démico y el industrial con el objeto de renovar, impulsar y visibilizar el desarrollotecnológico nacional [8].

4 Capítulo 1. Introducción general

La primera versión de la CIAA se basó en un procesador de la empresa NXPSemiconductors, razón por la cual se la denominó CIAA-NXP [9]. Luego se de-sarrolló un hardware similar de menor costo, denominado EDU-CIAA-NXP [10]para utilizar en proyectos educativos. En las figuras 1.3 y 1.4 se puede apreciar elhardware de cada una.

FIGURA 1.3. Hardware CIAA-NXP.

FIGURA 1.4. Hardware EDU-CIAA-NXP.

1.4. Motivación, objetivos y alcance

Hasta la fecha, el proyecto CIAA no cuenta con mecanismos de seguridad parael tráfico de Internet en su firmware [11]. El presente trabajo tiene como propósitoproveerle herramientas que le permitan una integración ágil y segura a la nube.

Para lograr esto, se propuso desarrollar la integración de AWS en el firmwareutilizado por las CESE/MSE, de modo que corra tanto para el hardware de laCIAA-NXP como también de la EDU-CIAA-NXP. Así, dicho desarrollo permite

1.4. Motivación, objetivos y alcance 5

ser utilizado tanto en aplicaciones industriales como también en proyectos educa-tivos. En efecto, permite conectar el hardware a la nube cumpliendo los niveles deseguridad recomendados, y utilizar los servicios disponibles en la infraestructurade AWS para almacenar y procesar sus datos de forma escalable.

Para ejemplificar como se pueden potenciar los sistemas embebidos, se proveeun caso de uso que se conecta a AWS y, mediante la aplicación de modelos de IA,reconoce sonidos de agua corriendo capturados por la EDU-CIAA-NXP.

7

Capítulo 2

Introducción específica

En este capítulo se exponen las características del hardware EDU-CIAA-NXP yla estructura del Firmware_v3 del proyecto CIAA. También se identifican los mó-dulos de FreeRTOS parametrizados para utilizar en el proyecto. Finalmente, seenuncian los servicios en la nube, protocolos y frameworks requeridos para la rea-lización del presente trabajo.

2.1. Hardware de la EDU-CIAA-NXP

La EDU-CIAA-NXP se basa en el microcontrolador LPC4337 (Dual Core de 32 bitARM Cortex-M4F / Cortex-M0). Si bien no cuenta con una interfaz phy, como laCIAA-NXP [12], sí incluye el puerto Ethernet para la conexión a Internet. Parasu utilización, en este proyecto se optó por una interfaz phy LAN8720 que es lamisma utilizada en la CIAA-NXP y el Poncho Ethernet [13] para la EDU-CIIA-NXP. En la figura 2.1 se observa un diagrama en bloques de la EDU-CIAA-NXP.

La EDU-CIAA-NXP cuenta con los siguientes módulos:

2 puertos micro-USB (uno para aplicaciones y debugging, otro para alimen-tación).

4 salidas digitales implementadas con leds RGB.

4 entradas digitales con pulsadores.

1 puerto de comunicaciones RS 485 con bornera.

2 conectores de expansión:

• P1.

◦ 3 entradas analógicas (ADC con resolución 10 bit).

◦ 1 salida analógica (DAC).

◦ 1 puerto I2C.

◦ 1 puerto asincrónico full duplex (para RS-232).

◦ 1 puerto CAN.

◦ 1 conexión para un teclado de 3×4.

• P2.

0Imagen tomada de http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp


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

FIGURA 2.1. Diagrama en bloques EDU-CIAA-NXP.

◦ 1 puerto Ethernet (interfaz RMII).

◦ 1 puerto SPI.

◦ 1 puerto para display LCD con 4 bits de datos, enable y RS.

◦ 9 pines genéricos de I/O.

En cuanto a memoria, cuenta con 1 MB de flash y 136 kB de SRAM. Tanto la me-moria flash como la SRAM se encuentran divididas en varias regiones, como seaprecia en la tabla 2.1. Esto debe considerarse al configurarla para su utilización.

TABLA 2.1. Regiones de memoria EDU-CIAA-NXP.

Región Inicio Longitud Tamaño (kB)

MFlashA512 (rx) 0x1a000000 0x80000 512MFlashB512 (rx) 0x1b000000 0x80000 512RamLoc32 (rwx) 0x10000000 0x8000 32RamLoc40 (rwx) 0x10080000 0xa000 40RamAHB32 (rwx) 0x20000000 0x8000 32RamAHB16 (rwx) 0x20008000 0x4000 16RamAHB_ETB16 (rwx) 0x2000c000 0x4000 16

2.2. Estructura del Firmware_v3 del proyecto CIAA 9

2.2. Estructura del Firmware_v3 del proyecto CIAA

El Firmware_v3 es un proyecto en base a makefile que actúa como framework parael desarrollo de firmware destinados a sistemas embebidos en lenguajes C/C++.Soporta toolchain, bibliotecas y ejemplos para múltiples plataformas de hardware[11].

El toolchain soportado es gcc-arm-none-eabi, y las bibliotecas disponibles son:

CMSIS 5.4.0 (Core y DSP).

LPCOpen v3.02 para LPC43XX NXP.

LPCUSBlib.

sAPI v0.5.2.

Arduino (wiring).

Elm-Chan FatFS R0.13b.

FreeRTOS Kernel V10.0.1.

RKH 3.2.3.

La estructura del firmware se indica en la tabla 2.2.

TABLA 2.2. Estructura del Firmware_v3 de la CIAA.

Carpeta Contenido

Documentación Información del hardware soportado.Examples Ejemplos de códigos en ASM, C y CPP.Libs Bibliotecas de terceros.Scripts Archivos de configuración y script en bash para configurar

el framework.Templates Plantillas para algoritmos útiles.Test Algoritmos con código mínimos para probar el funciona-

miento básico del hardware.

Dentro de cada biblioteca ubicada en la carpeta Lib, se encuentra el código dela misma y además un archivo de configuración module.mk. En este archivo, seconfigura la ruta de los archivos *.h y *.c de la biblioteca y también se define unavariable que después le permite indicar al makefile si debe incluir dicha bibliotecao no en la compilación.

Una de las bibliotecas integradas al Firmware_v3 es LPCOpen en donde se defi-nen las particularidades del hardware utilizado. En esta se encuentra la definiciónde regiones de memorias enunciadas en la sección 2.1. También se encuentran losarchivos de linkeo y en el mismo se define la región RamLoc32 como memoriaprincipal para el firmware.

2.3. Amazon FreeRTOS

FreeRTOS [14] es un sistema operativo (SO) en tiempo real para microcontrola-dores. Se trata de un SO de código abierto que facilita la programación, imple-mentación, protección, conexión y administración de los dispositivos de borde


pequeños y de bajo consumo. FreeRTOS, distribuido bajo la licencia MIT, incluyeun kernel y un conjunto de bibliotecas de software en crecimiento apto para suuso en todos los sectores de la industria.

Desde 2017, Amazon FreeRTOS ha sido la extensión del proyecto FreeRTOS [15],por lo que se utilizan ambas denominaciones indistintamente. El proyecto Free-RTOS ahora incluye las bibliotecas de conectividad, seguridad e integraciones aIoT.

Amazon FreeRTOS consta del sistema operativo FreeRTOS y además proporcionabibliotecas adicionales. Algunas de éstas, son proporcionadas para implementarsocket seguros. Por otra parte, se utilizan las bibliotecas FreeRTOS+TCP / LWIPpara los servicios de red y la Mbed TLS para el cifrado [16]. Una característicanotable es el desacople de las bibliotecas, pudiéndose utilizar WolfSSL en lugarde Mbed TLS para el cifrado.

2.3.1. Utilización de interrupciones

FreeRTOS es un SO multitarea que le asigna un tiempo de ejecución a cada tareasegún una prioridad establecida. Para ello, utiliza un planificador que administrael tiempo de procesador de cada tarea. Para poder realizar un muestreo en tiemporeal que requiera cumplir con periodos de adquisición estrictos, se utilizan inte-rrupciones configuradas por timers del microcontrolador. Cuando se genera unainterrupción, se guarda el contexto de la tarea que se está ejecutando en ese mo-mento, y el planificador le asigna tiempo de procesador a la rutina configuradapara dicha interrupción.

2.3.2. Administración de la memoria

El kernel RTOS necesita RAM cada vez que se crea una tarea, cola, mutex, tem-porizador de software, semáforo o grupo de eventos. La RAM se puede asignardinámicamente de forma automática desde el heap de RTOS dentro de las funcio-nes de creación de objetos de la API de RTOS, o puede ser proporcionada por elprogramador [17].

Los objetos RTOS se pueden crear dinámicamente. Sería de esperar utilizar lasfunciones estándar de la biblioteca C como malloc() y free(). No obstante, este re-curso conlleva las siguientes complicaciones:

No siempre están disponibles en sistemas integrados.

Ocupan un valioso espacio de código.

No son seguras para subprocesos.

No son deterministas (la cantidad de tiempo necesario para ejecutar la fun-ción diferirá de una llamada a otra).

Por esta razón, no se suele recurrir a este recurso, y en su lugar se procura unaimplementación de asignación de memoria alternativa.

Un sistema en tiempo real puede tener requisitos de tiempo y RAM muy dife-rentes a los de otro, por lo que un único algoritmo de asignación de RAM soloserá apropiado para un subconjunto de aplicaciones. FreeRTOS ofrece varios es-quemas de administración de heap que varían en complejidad y características, asaber:

2.4. LWIP 11

heap_1: el más simple, no permite liberar memoria (es menos útil ya queFreeRTOS agregó soporte para asignación estática desde la versión 9 [18]).

heap_2: permite liberar la memoria, pero no fusiona los bloques libres ad-yacentes (ahora se prefiere la implementación de heap_4 más nueva).

heap_3: simplemente envuelve el estándar malloc() y free() para seguridadde subprocesos.

heap_4: fusiona bloques libres adyacentes para evitar la fragmentación. In-cluye la opción de ubicación de dirección absoluta.

heap_5: es similar a heap_4, con la capacidad de distribuir el heap en variasáreas de memoria no adyacentes.

2.4. LWIP

LWIP es una pequeña implementación independiente del protocolo TCP/IP di-señada para reducir el uso de RAM sin dejar de tener la pila completa de TCP/IP.Esto hace que LWIP sea adecuado para su uso en sistemas embebidos [19]. Paralograr este objetivo, el código de LWIP evita al máximo copiar información entrebuffers y en su lugar utiliza punteros. LWIP proporciona tres interfaces de progra-ma de aplicación (API) para utilizar en la comunicación con el código TCP/IP:

Core: basada en eventos y diseñada para usarse sin un sistema operativo.Esta API también es utilizada por la pila central para la interacción entre losdistintos protocolos.

Secuencial: proporciona una forma secuencial para que programas simplesutilicen la pila LWIP. Es muy similar a la API de socket de BSD (abrir-leer-escribir-cerrar).

Socket: API de compatibilidad destinada a proporcionar todas las funcionesnecesarias para ejecutar aplicaciones migradas de otras plataformas (Unix,Windows, etc).

2.5. WolfSSL

WolfSSL es una biblioteca SSL/TLS escrita en ANSI C, que permite implementarcriptografía en sistemas embebidos gracias a que es liviana y portable [20]. Pro-porciona una comunicación segura por Internet. Sus principales característicasson:

Tamaño de huella: 20-100 kB.

Memoria en tiempo de ejecución: 1-36 kB.

Portable: Capas de abstracción (SO, E/S personalizada y biblioteca C están-dar).

Criptografía: SSL versión 3.0 y TLS versiones 1.0, 1.1, 1.2 y 1.3 (cliente yservidor).

Funciones hash: MD2, MD4, MD5, SHA-1, SHA-224, SHA-256, SHA-384,SHA-512, BLAKE2b, RIPEMD-160, Poli1305.


Cifrados en bloque, en streaming y autenticados: AES (CBC, CTR, GCM,CCM, GMAC, CMAC), Camelia, DES, 3DES, IDEA, ARC4, CONEJO, HC-128, ChaCha20.

Algoritmos de clave pública: RSA, DSS, DH, EDH, ECDH-ECDSA, ECDHE-ECDSA, ECDH-RSA, ECDHE-RSA, NTRU.

WolfSSL permite configurar suites [21], que son combinaciones de algoritmos deautenticación, cifrado y código de autenticación de mensajes (MAC). Las suites seutilizan durante el protocolo de enlace TLS o SSL para negociar la configuraciónde seguridad de una conexión.

2.6. MQTT

MQTT es un protocolo de comunicación M2M (machine-to-machine) de tipo colade mensajes. Está basado en la pila TCP/IP como soporte para la comunicación.En este protocolo, cada conexión se mantiene abierta y se reutiliza en cada co-municación. En esto se diferencia, por ejemplo, de una petición HTTP 1.0, dondecada transmisión se realiza a través de una nueva conexión [22]. Este protocolo esutilizado en IoT, en la plataforma AWS (véase figura 1.2).

La biblioteca WolfMQTT es una implementación de cliente de MQTT, escrita en Cpara uso integrado. Es compatible con SSL/TLS a través de la biblioteca WolfSSL,por lo que puede proporcionar la seguridad de la que carece el protocolo MQTT[23].

2.7. Componente IoT Core de AWS

La infraestructura de AWS es una plataforma en la nube que ofrece una variedadde servicios distribuidos y disponibles en todo el mundo [24]. Entre los serviciosprovistos, se incluyen recursos de cómputo, almacenamiento, bases de datos, aná-lisis, IoT, entre otros [25].

Para proyectos de IoT, resulta más eficiente utilizar los servicios provistos paraeste fin dentro de la plataforma AWS, en lugar de configurar máquinas virtualese instalar programas contratando servicios de infraestructura. En AWS el serviciode IoT se administra desde el componente AWS IoT Core, que permite interactuarde forma segura entre las aplicaciones en la nube y los dispositivos conectados aInternet [26]. Para ello, los dispositivos deben implementar mecanismos de segu-ridad en las comunicaciones por Internet.

AWS desarrolló para el servicio IoT Core una configuración personalizada sobreel sistema operativo de tiempo real FreeRTOS, que implementa bibliotecas paraconectarse a Internet de forma segura. Actualmente soporta una cantidad limita-da de hardware, como se puede apreciar en la figura 2.2.

2.8. Filtros digitales

Previo a convertir una señal analógica en digital, lo más recomendable es em-plear un filtro desambigüedad. Esto es porque hay infinitas frecuencias que sonproductos de la original y también encuentran un valor en el muestreo. A esta

2.9. Ubicoustics 13

FIGURA 2.2. Hardware soportado por Amazon FreeRTOS.

situación se la denomina efecto ”alias”. En realidad, existen tanto filtros analógi-cos como digitales. Los primeros proporcionan resultados más óptimos, pues soncapaces de cortar efectivamente una señal a partir de determinada frecuencia. Noobstante, de no contar con filtros analógicos, se puede apelar a digitales luego deconvertir la señal.

Al aplicar un filtro digital se produce un retardo de grupo, dado que se requiereprocesar el valor actual de la señal junto a valores anteriores y por ello se debeesperar a obtener esa cantidad de muestras para procesarlas. El retardo dependedirectamente del orden "(L - 1) / 2", y lo que se busca al diseñar un filtro es quesu retardo de grupo sea constante. Cuando este retardo de grupo es variable, seproduce una distorsión de la señal que la modifica morfológicamente.

Una forma de aplicar filtros digitales es utilizando python con la biblioteca scipy.signal, como por ejemplo lfilter o, para dos pasadas, filtfilt [27]. También existenmétodos para aplicar la convolución y herramientas gráficas para diseñarlos.

PyFDA es una herramienta basada en GUI en Python / Qt para analizar y diseñarfiltros de tiempo discretos [28]. Entre algunas de sus características, se encuentransimular filtros, obtener los coeficientes, visualizar los ceros, etc.

2.9. Ubicoustics

Ubicoustics [29] es un framework escrito en python que utiliza las bibliotecas deTensorFlow y Keras para aplicar IA y reconocer sonidos. Dispone de una amplia


cantidad de modelos para predecir sonidos provenientes de diversas fuentes, co-mo por ejemplo:

Agua corriendo.

Descarga del inodoro.

Golpear una puerta.

Personas hablando.

Persona tosiendo.

Perro ladrando.

Taladro en uso.

Teléfono sonando.

Bebe llorando.

TensorFlow es una plataforma de código abierto para el aprendizaje automático.Cuenta con un ecosistema integral y flexible de herramientas, bibliotecas y recur-sos de la comunidad, aptos para impulsar un aprendizaje automático innovador,y compilar e implementar con facilidad aplicaciones con IA [30].

Keras es una biblioteca de alto nivel que facilita describir las capas que ejecutarála red neuronal con TensorFlow. Al ser una API diseñada para seres humanosy no para máquinas, reviste ciertas características: requiere pocas acciones delusuario para los casos de uso comunes, proporciona mensajes de error claros yprocesables y cuenta con suficiente documentación [31].

15

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

La solución cuenta con dos componentes que interactuan con una plataforma enla nube. En cuanto a la plataforma de servicios en la nube, se optó por utilizarAWS y su servicio de IoT Core. Este permite comunicarse, por un lado, con elfirmware desarrollado sobre la EDU-CIAA-NXP para capturar el sonido, y porotro lado, con la aplicación que implementa IA para inferir el sonido de aguacorriendo. En la figura 3.1 se aprecia un diagrama de dicha interacción.

Para el diseño del firmware, desde un principio se pretendió aprovechar las ca-racterísticas del hardware CIAA-NXP, y que se pueda adaptar al hardware EDU-CIAA-NXP de acuerdo a los objetivos planteados en la sección 1.4. Dado que todoel desarrollo se realizó sobre el hardware EDU-CIAA-NXP, el primer paso fue co-nectar la interfaz phy como se aprecia en la figura 3.2. Luego se realizaron lassiguientes tareas sobre el proyecto Firmware_V3:

Integrar la biblioteca LWIP.

Implementar LWIP sobre FreeRTOS.

Integrar la biblioteca WolfSSL.

Integrar la biblioteca WolfMQTT.

Implementar caso de uso propuesto.

Diseñar y organizar las tareas FreeRTOS.

En cuanto al diseño de la aplicación, se optó por analizar la señal con herramien-tas en python y el framework Ubicoustics para emplear modelos de IA. Para in-teractuar con AWS IoT Core, se utilizó el proyecto en C de WolfMQTT, que se valede la biblioteca WolfSSL para implementar seguridad en las comunicaciones. So-bre el proyecto mencionado, se desarrolló un módulo que genera un archivo WAVcon la información recibida desde la EDU-CIAA-NXP.

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. Entreestos, se aprovecharon los ya disponibles en las bibliotecas integradas.

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

FIGURA 3.1. Diagrama de interacción.

Algo que se tuvo en cuenta en el diseño de toda la solución fue elaborar un lista-do de pruebas indispensables a realizar sobre etapas puntuales en el desarrollo.En dicho listado, se indica la funcionalidad evaluada y el procedimiento para ve-rificarlo en cada caso. En la tabla 3.1 se detalla su contenido.

3.2. Configurar AWS IoT Core

Para realizar la configuración en la plataforma de AWS, lo que se hizo en primerlugar fue crear un objeto denominado CIAA en el servicio IoT Core. Luego secrearon los certificados ARN, que son los que identifica de manera inequívocaeste recurso. Finalmente se definió y asoció una política en donde se especificaqué se ha de permitir o bloquear sobre cada acción disponible de IoT [32].

Con el objetivo de acceder a los recursos de AWS, se crearon certificados SSL deCA para la autenticación del servidor [33]. Estos luego se descargaron y agrega-ron tanto en el firmware como en la aplicación para poder acceder a la plataformade AWS. Para configurarlos, se crearon variables constantes con el contenido de laclave privada y la pública provista en el certificado. Además, se establecieron losnombres de tópicos y objetos seteados en AWS. Esta configuración se visualiza enel código 3.1.

1 /* Configurat ion */2 # def ine APP_HARDWARE " wolf_aws_iot_demo "3 # def ine APP_FIRMWARE_VERSION LIBWOLFMQTT_VERSION_STRING4

3.2. Configurar AWS IoT Core 17

FIGURA 3.2. Conexión EDU-CIAA-NXP con interfaz phyLAN8720.

5 # def ine AWSIOT_HOST "a1hoXXXXXXXXXX− a t s . i o t . us−east −1.amazonaws . com"

6 # def ine AWSIOT_DEVICE_ID "CIAA"7 # def ine AWSIOT_SUBSCRIBE_TOPIC " $aws/things/"AWSIOT_DEVICE_ID"/IA/LED"8 # def ine AWSIOT_PUBLISH_TOPIC " $aws/things/"AWSIOT_DEVICE_ID"/IA/VOZ"9

10 # def ine MAX_BUFFER_SIZE 512 /* Maximum s i z e f o r network read/wri te c a l l b a c k s */

11 # def ine AWSIOT_QOS MQTT_QOS_112 # def ine AWSIOT_KEEP_ALIVE_SEC DEFAULT_KEEP_ALIVE_SEC13 # def ine AWSIOT_CMD_TIMEOUT_MS DEFAULT_CMD_TIMEOUT_MS14

15 # def ine AWSIOT_PUBLISH_MSG_SZ tamPaqueteX+30 // 30 bytes de recargamsg

16

17 s t a t i c const char * root_ca =18 "−−−−−BEGIN CERTIFICATE−−−−−\n"19 // * * * //20 "−−−−−END CERTIFICATE−−−−−" ;21

22 s t a t i c const char * device_priv_key =23 "−−−−−BEGIN RSA PRIVATE KEY−−−−−\n"\24 // * * * //25 "−−−−−END RSA PRIVATE KEY−−−−−" ;26

27 s t a t i c const char * d e v i c e _ c e r t =28 "−−−−−BEGIN CERTIFICATE−−−−−\n"\29 // * * * //30 "−−−−−END CERTIFICATE−−−−−" ;

CÓDIGO 3.1. Configuracion AWS.


TABLA 3.1. Pruebas indispensables sobre el firmware y la aplica-ción.

Identificador Funcionalidad evaluada Procedimiento que lo verifica

TEST_001 Conexionado del phyLAN8720.

Verificar indicadores lumínicos deactividad.

TEST_002 Integración biblioteca LWIP. Verificar archivos objeto de compi-lación. Realizar ping y esperar res-puesta.

TEST_003 Funcionamiento de LWIP so-bre FreeRTOS

Ejecutar TCPecho sobre LWIP y ve-rificar eco desde aplicación.

TEST_004 Iniciación WolfSSL. Verificar con logs de biblioteca.TEST_005 Iniciación WolfMQTT. Verificar con logs de biblioteca.TEST_006 Verificar tamaño de tareas

FreeRTOS.FreeRTOS Task Aware Debuggerfor GDB - NXP.

TEST_007 Muestrear valores conocidosen ADC.

Colocar 0 V, 2 V y 3.3 V y verificarlecturas ADC.

TEST_008 Transmitir paquete MQTT Preparar un paquete con valoresconocidos y verificar que se recibecompleto.

TEST_009 Muestrear señal acústica. Capturar el sonido de una palabray reproducirlo para verificar.

TEST_010 Muestrear señal acústica(Hz).

Inyectar el sonido de una señal se-noidal de 8 kHz y verificar con laDFT de la señal reconstruida.

TEST_011 Muestrear señal del sonidode la voz

Verificar porcentaje de predicciónpara persona hablando.

TEST_012 Muestrear señal del sonidodel agua sin amplificador

Verificar porcentaje de predicciónpara agua corriendo.

TEST_013 Muestrear señal del sonidodel agua con amplificador

Verificar porcentaje de predicciónpara agua corriendo.

3.3. Firmware

El desarrollo del firmware consistió primero en la integración y configuración debibliotecas. Luego se desarrolló el caso de uso propuesto que requirió el muestreode una señal analógica. Finalmente, se transmitió a AWS Iot Core.

3.3.1. Integrar biblioteca LWIP y configurar sobre FreeRTOS

Como se mencionó en la sección 2.2, para incluir una biblioteca al Firmware_v3se debe copiar el código de ésta en la carpeta Libs. Para incluir la biblioteca LWIPse realizaron dichos pasos y además se copió el archivo ”lpc_phy.h” en ”/libs/lpc_open/boards/edu_ciaa_nxp/inc” y ”lpc_phy_smsc87x0.c” en ”/libs/lpc_open/boards/edu_ciaa_nxp/src”. Finalmente en ”/libs/lpc_open/boards/edu_ciaa_nxp/inc/board.h” se definió la variable USE_RMII, y en ”/libs/lwip/mo-dule.mk” la variable USE_LWIP para habilitar el módulo en el proyecto. Se ob-servó que parte de la implementación para utilizar RMII estaba incluida en elproyecto Firmware_v3, y esto se debe a que en versiones anteriores sí estaba so-portado.

3.3. Firmware 19

Para integrar LWIP en un proyecto con FreeRTOS, se procedió primero a actua-lizar la biblioteca FreeRTOS a la última disponible (v10.3.0). El procedimientose detalla en el apéndice A, dado que es un paso opcional para la realizacióndel presente proyecto. Luego se adoptó el proyecto ”LWIP FreeRTOS TCP Echoexample” [34] de LPCOpen [35], que estaba implementado en LPCOpen v1, y seadaptó a la versión LPCOpen v3 del proyecto Firmware_v3.

3.3.2. Integrar bibliotecas WolfSSL y WolfMQTT

En un principio, y de acuerdo con el análisis y establecimiento de requisitos rea-lizado inicialmente, se intentó integrar la biblioteca Mbed TLS [36], incluida enel proyecto Amazon FreeRTOS. Sin embargo, esto no se logró debido a las limi-taciones de SRAM en la EDU-CIAA-NXP mencionadas en la sección 2.1. En elapéndice B se adjunta la configuración realizada que sería la óptima de MbedTLS para el hardware utilizado. Teniendo en cuenta esto, y que el objetivo de fon-do es contribuir al proyecto CIAA para incorporar SSL en el Firmware_v3 y asípoder conectarla de forma segura con la plataforma AWS, se optó por cambiar lalibrería Mbed TLS por WolfSSL. Al realizar dicho cambio, y contando ya con laexperiencia para administrar de distintas formas la SRAM de la EDU-CIAA-NXPutilizando FreeRTOS, se logró cumplir con dicho objetivo.

Para integrar las bibliotecas WolfSSL y WolfMQTT en el proyecto Firmware_v3,se realizaron los mismos pasos que los indicados en la sección 2.2. Con estas bi-bliotecas, también se tuvieron problemas debido a la limitada SRAM, pues todoel proyecto necesita más memoria que la disponible en cada región (véase tabla2.1). En efecto, aunque existan dos regiones adyacentes, no se pueden combinaren una sola [37].

FreeRTOS ofrece varios esquemas de administración de memoria como los men-cionados en la sección 2.3.2. Para el caso en el que se requiere más memoria que ladisponible en cada región de forma individual, se provee el esquema heap_5 conla capacidad de unificar en un heap varias regiones no adyacentes. En el código3.2 se ejemplifica cómo realizar dicha tarea con la distribución de SRAM presenteen el hardware utilizado y sin hacer uso de la memoria principal.

1 s t a t i c _ _ a t t r i b u t e _ _ ( ( used , s e c t i o n ( " . n o i n i t .$RAM2" ) ) ) u i n t 8 _ theap_RamLoc40 [ 4 0 * 1 0 2 4 ] ;

2 s t a t i c _ _ a t t r i b u t e _ _ ( ( used , s e c t i o n ( " . n o i n i t .$RAM3" ) ) ) u i n t 8 _ theap_RamAHB32 [ 3 2 * 1 0 2 4 ] ;

3 s t a t i c _ _ a t t r i b u t e _ _ ( ( used , s e c t i o n ( " . n o i n i t .$RAM4" ) ) ) u i n t 8 _ theap_RamAHB16 [ 1 6 * 1 0 2 4 ] ;

4 s t a t i c _ _ a t t r i b u t e _ _ ( ( used , s e c t i o n ( " . n o i n i t .$RAM5" ) ) ) u i n t 8 _ theap_RamAHB_ETB16 [ 1 6 * 1 0 2 4 ] ;

5

6 s t a t i c HeapRegion_t xHeapRegions [ ] =7 {8 { &heap_RamLoc40 [ 0 ] , s i z e o f ( heap_RamLoc40 ) } ,9 { &heap_RamAHB32 [ 0 ] , s i z e o f (heap_RamAHB32) } ,

10 { &heap_RamAHB16 [ 0 ] , s i z e o f (heap_RamAHB16) } ,11 { &heap_RamAHB_ETB16 [ 0 ] , s i z e o f ( heap_RamAHB_ETB16 ) } ,12 { NULL, 0 } // << Terminates the array .13 } ;14

15 i n t main ( void )16 {17 /* . . . . */18 vPortDefineHeapRegions ( xHeapRegions ) ;


19 /* . . . . */20 }

CÓDIGO 3.2. Implementación de heap_5.

Al configurar el esquema mencionado, se presentaron problemas para reservar yliberar memoria dinámica de forma sucesiva. Debido a la falta de tiempo en larealización del presente trabajo, no se pudo preparar una aplicación por separa-do para demostrar dicho problema. Como solución, se ideó un nuevo esquema deadministración de memoria basado en el heap_4, en donde se personalizaron lasfunciones pvPortMalloc() para cada región de memoria. En la figura 3.3 se apre-cia el desglose de este esquema dentro de la estructura del Firmware_v3. Luego,para poder incluirlos en el makefile, se modificó el archivo de configuración mo-dule.mk de la biblioteca FreeRTOS, como se indica en el código 3.3.

FIGURA 3.3. Desglose del esquema heap_4.

1 i f e q ( $ (USE_FREERTOS) , y )2

3 BOARD ?= edu_ciaa_nxp4

5 FREERTOS_BASE= l i b s / f r e e r t o s6 SRC+=$ (FREERTOS_BASE) /MemMang/heap_$ (FREERTOS_HEAP_TYPE) a . c7 SRC+=$ (FREERTOS_BASE) /MemMang/heap_$ (FREERTOS_HEAP_TYPE) b . c8 SRC+=$ (FREERTOS_BASE) /MemMang/heap_$ (FREERTOS_HEAP_TYPE) c . c9 SRC+=$ (FREERTOS_BASE) /MemMang/heap_$ (FREERTOS_HEAP_TYPE) d . c

CÓDIGO 3.3. Archivo de configuración biblioteca FreeRTOS.

A partir de esto, las bibliotecas integradas se configuraron para utilizar regionesespecíficas de memoria, como se indica en la tabla 3.2. Para lograrlo, se redefinie-ron las funciones reservar y liberar memoria, malloc() y free(), como se aprecia enel código 3.4.

1 # i f n d e f __LWIPOPTS_H_2 # def ine __LWIPOPTS_H_3 /* . . . . */4 /* Needed f o r malloc/ f r e e */5 # include " FreeRTOS . h"6 # def ine malloc pvPortMalloc27 # def ine f r e e vPortFree28 /* . . . . */9 # endi f /* __LWIPOPTS_H_ */

CÓDIGO 3.4. Redefinir malloc() y free() en lwipopts.h para LWIP.

3.3. Firmware 21

TABLA 3.2. Configuración de regiones según bibliotecas.

Asignación Regiones Función reservar Función liberar Heap

Firmware RamLoc32 (principal)FreeRTOS

RamLoc40 pvPortMalloc vPortFree heap_4aWolfSSLWolfMQTTLWIP RamAHB32 pvPortMalloc2 vPortFree2 heap_4bbuffer1 16 kB RamAHB16 pvPortMalloc3 vPortFree3 heap_4cbuffer2 16 kB RamAHB_ETB16 pvPortMalloc4 vPortFree4 heap_4d

Finalmente, para utilizar la biblioteca WolfSSL se requirió realizar una configura-ción de suites, como se indicó en la sección 2.5. Los valores establecidos fueronlos siguientes:

FREERTOS: correr sobre FreeRTOS.

WOLFSSL_LWIP: implementar LWIP.

NO_FILESYSTEM: no utilizar sistema de archivos.

NO_ASN_TIME: no utilizar validación ASN_TIME.

NO_DEV_RANDOM: no posee implementación de RNG propia.

HAVE_DH: configuro suite DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-PSK-AES128-CBC-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:EDH-RSA-DES-CBC3-SHA.

3.3.3. Implementar caso de uso propuesto

Con el objeto de brindar un ejemplo claro de cómo potenciar los sistemas embe-bidos con servicios en la nube, se propuso como caso de uso identificar un sonidomediante la aplicación de modelos de IA, como se enunció en la sección (1.4).Dentro de este campo el tamaño de los modelos es significativo: cuanta mayorprecisión tienen más grandes son. Los utilizados en el presente proyecto pesanmás de 850 MB y, en el caso de ejecutarlo en un sistema embebido, se requiereesa capacidad de SRAM en el hardware. Además de lo mencionado, el procesode inferir requiere alta carga de cómputo.

Debido a lo expuesto, el proceso de cómputo e inferencia no se llevó a cabo en elsistema embebido sino en la denominada aplicación. Por otro lado, en el sistemaembebido se realizó: la captura del sonido, el empaquetado de la información yla transmisión a la nube.

Para capturar el sonido, dado que es una señal analógica, se realizó un muestreoutilizando el ADC incorporado en la EDU-CIAA-NXP, enunciado en la sección2.1. En primer lugar se analizó cuál es el rango de frecuencia del sonido buscado,agua corriendo, y para ello se utilizó una aplicación sobre un smartphone, como seaprecia en la figura 3.4. El ejemplo tomado fue registrar el sonido que hace unacanilla abierta y las frecuencias predominantes se encontraron por debajo de los8 kHz. De acuerdo con el teorema de Nyquist-Shannon [38], se determinó que elmuestreo debe ser de por lo menos 16 kHz.


FIGURA 3.4. Análisis de dominio en frecuencia con smartphone.

Teniendo en cuenta la memoria disponible (véase tabla 2.1) y la resolución de 10bits del ADC, que requiere 2 bytes, el tiempo de muestreo es aproximadamentede 1 segundo dado que:

16 kHz = 16.000 muestras por segundo.

RamAHB16 de 16 kB + RamAHB_ETB16 de 16 kB = 32 kB de almacena-miento.

La resolución del ADC requiere 2 bytes.

2 bytes * 16.000 muestras = 32.000 B <= 32 kB SRAM disponible.

En cuanto al muestreo, se deben utilizar interrupciones para cumplir con perio-dos de adquisición estrictos, como se mencionó en la sección 2.3.1. Para esto seredefinió la función TIMER0_IRQHandler() y se configuró la interrupción paraejecutarse cada 16128 Hz. Dado que esta función se ejecuta dentro de una inte-rrupción, en ella sólo se implementa un semáforo para luego, en una tarea deFreeRTOS, realizar la lectura del ADC.

Para utilizar las dos regiones de memoria disponibles en la EDU_CIAA_NXP,se crearon dos buffers en donde se reserva memoria dinámica con las funcionespvPortMalloc3 y pvPortMalloc4, como se indica en la tabla 3.2. Para el almacena-miento de los datos en las buffers, se definió una estructura del tipo vector shortint. El tamaño del vector está condicionado a un máximo de 8.192 posiciones yaque 2 bytes * 8192 = 16 Kb. Sin embargo, al reservar memoria dinámica con lafunción pvPortMalloc() de FreeRTOS, se reserva adicionalmente 8 bytes para suencabezado. Por lo anterior, el tamaño máximo del vector ahora es 8.184 (8.192- 8). En cuanto al empaquetado de la información, se decidió utilizar un mensa-je en formato JSON [39], que permite ser visualizado de forma clara sin ningúninterprete y directamente desde la consola de AWS IoT Core. Para el tamaño delpaquete, se definió enviar 128 valores y se ajustó esta cifra al tamaño del vectorpara que en el buffer quepan paquetes enteros. En el código 3.5 se aprecia el ta-maño de las variables definidas y el empaquetado de los datos. En el código 3.6se muestra el armado del payload MQTT que se transmite a AWS IoT Core.

1 # def ine tamVectorX 8192 −128 //8192−8 // FreeRTOS n e c e s i t ar e s e r v a r mas memoria ademas para e l encabezado ( 8 ) / Resto 128 paraq u i t a r un paquete entero

2 typedef s t r u c t paquete {

3.3. Firmware 23

3 unsigned shor t i n t valor [ tamVectorX ] ; // 2 bytes * 8192 = 16Kb .4 } paquete ;5

6 /* . . . . */7

8 bu f fe r1 = pvPortMalloc3 ( s i z e o f ( paquete ) ) ;9 i f (NULL == bu f f er 1 )

10 p r i n t f ( "E R R O R : No se pudo r e s e r v a r a l bu f f e r 1\r\n" ) ;11 memset ( buffer1 , 0 , s i z e o f ( paquete ) ) ;12

13 bu f fe r2 = pvPortMalloc4 ( s i z e o f ( paquete ) ) ;14 i f (NULL == bu f f er 2 )15 p r i n t f ( "E R R O R : No se pudo r e s e r v a r a l bu f f e r 2\r\n" ) ;16 memset ( buffer2 , 0 , s i z e o f ( paquete ) ) ;17

18 /* . . . . */19

20 unsigned i n t i n d i c e b u f f e r 1 = 0 ;21 unsigned i n t i n d i c e b u f f e r 2 = 0 ;22

23 /* . . . . */24

25 i f ( i n d i c e b u f f e r 1 < tamVectorX )26 buffer1 −>valor [ i n d i c e b u f f e r 1 ++] = adcRead ( CH1 ) ;27 e l s e28 buffer2 −>valor [ i n d i c e b u f f e r 2 ++] = adcRead ( CH1 ) ;29

30 i f ( i n d i c e b u f f e r 2 >= tamVectorX ) {31 gpioWrite ( LEDR, OFF ) ;32 i n d i c e b u f f e r 1 = 0 ;33 i n d i c e b u f f e r 2 = 0 ;34 xSemaphoreGive ( d a t o s _ l i s t o s ) ; // S i b u f f e r e s t a l leno ,

se h a b i l i t a semaforo para enviar datos y no se h a b i l i t a e l delb u f f e r . . .

35 } e l s e36 xSemaphoreGive ( sem_buffer ) ; // Sigo capturando . . .37

38 /* . . . . */

CÓDIGO 3.5. Empaquetado de la información.

1 /* . . . . */2 do {3 rc = mqtt_mef(&mqttCtx ) ;4 i f ( mqttCtx . s t a t != WMQ_DISCONNECT ) {5 i f ( xSemaphoreTake ( d a t o s _ l i s t o s , 1/portTICK_PERIOD_MS ) ==

pdPASS ) { //pdPASS //pdFALSE6 gpioWrite ( LEDB, ON ) ;7

8 i n t i =0 ;9 memset ( paqueteMQTT , 0 , s i z e o f ( paqueteMQTT [ tamPaqueteX ] ) ) ;

10 f o r ( i =0 ; i <128 ; i ++) {11 i f ( i n d i c e b u f f e r 1 < tamVectorX )12 s p r i n t f ( valor , " %04d" , buffer1 −>valor [ i n d i c e b u f f e r 1 ++] ) ;13 e l s e14 s p r i n t f ( valor , " %04d" , buffer2 −>valor [ i n d i c e b u f f e r 2 ++] ) ;15 s t r n c a t ( paqueteMQTT+ i * 4 , valor , 4 ) ;16 }17 numPaquete++;18 XSNPRINTF( ( char * ) mqttCtx . app_ctx ,

AWSIOT_PUBLISH_MSG_SZ, " {\" paq \ " : \" %03d\" ,\"msg \ " : \" %s \" } " ,numPaquete , paqueteMQTT ) ;

19 mqttCtx . s t a t = WMQ_PUB;


20

21 i f ( i n d i c e b u f f e r 2 >= tamVectorX ) {22 gpioWrite ( LEDB, OFF ) ;23 i n d i c e b u f f e r 1 = 0 ;24 i n d i c e b u f f e r 2 = 0 ;25

26 numPaquete = 0 ;27 } e l s e28 xSemaphoreGive ( d a t o s _ l i s t o s ) ; // S i todavia

quedan datos en e l buffer , doy de nuevo e l semaforo d a t o s _ l i s t o s29

30 /* . . . . */

CÓDIGO 3.6. Payload MQTT enviado a AWS IoT Core.

3.3.4. Diseñar y organizar las tareas FreeRTOS

Se tuvieron en cuenta patrones de diseño al utilizar las bibliotecas implementa-das. Por ejemplo: se implementó Singleton como patrón estructural para LWIP,WolfSSL y WolfMQTT, ya que por razones de recursos fue conveniente imple-mentar sólo una instancia de conexión por socket con LWIP y una sesión paraSSL y MQTT. Se implementó máquina de estados finita para el procesamiento deMQTT y el patrón de interrupción para resolver la concurrencia en el muestreode la señal.

En FreeRTOS se crearon tareas para desacoplar la funcionalidad inherente a cadaproceso. Se utilizaron semáforos binarios de FreeRTOS para coordinar la secuen-cia en la ejecución de las tareas, en conjunto con indicadores LED del hardwarepara indicar hitos puntuales, a saber:

Funciones para manejo de interrupciones.

• void GPIO0_IRQHandler(void): función para atrapar la interrupcióncuando se presiona el pulsador.

• void TIMER0_IRQHandler(void): función para atrapar la interrupcióndel timer utilizada en el muestreo.

Tareas FreeRTOS.

• void estoyVivo(void* taskParmPtr): utilizada para debug durante el de-sarrollo del firmware para indicar posible bloqueo del FreeRTOS.

• void LWIP_Init(void* taskParmPtr): inicializa la biblioteca LWIP y es-tablece los parámetros de la red.

• void conectarWolfSSL(void* taskParmPtr): inicia la conexión SSL utili-zando LWIP y luego crea una la sesión MQTT.

• void taskButtonDown(void* taskParmPtr): utilizada en conjunto conGPIO0_IRQHandler cuando se presiona el pulsador.

• void taskTimer0(void* taskParmPtr): utilizada en conjunto conTIMER0_IRQHandler cuando se dispara el timer.

Semáforos.

• sem_link: lo libera LWIP cuando se establece una conexión y habilita aconectar con SSL e iniciar MQTT.

3.4. Aplicación 25

• sem_mqtt: se libera cuando MQTT establece una conexión y habilitapara leer datos.

• sem_buffer: se deja dado al inicio y se utiliza luego para indicar cuandoel buffer está lleno.

• datos_listos: se utiliza para indicar que los datos muestreados estáncompletos y listos para transmitir en ambos buffer.

• button_Down: lo habilita GPIO0_IRQHandler cuando se presiona elpulsador para indicar que inicie el muestreo de la señal.

• sem_Timer0: lo habilita TIMER0_IRQHandler cuando se ejecuta la in-terrupción para sincronizar con la tarea de FreeRTOS que muestrea.

Indicadores LED.

• LED2: se enciende cuando obtiene la conexión TCP-IP con LWIP.

• LED1: titila al establecer la sesión MQTT y se mantiene encendido aldesconectarse.

• LEDR: se enciende mientras se realiza el sampleo.

• LEDB: se enciende cuando envía un mensaje MQTT.

• LEDG: se enciende cuando recibe un mensaje MQTT.

• LED3: se enciende cuando la respuesta es ”agua corriendo”.

En la figura 3.5 se aprecia la dependencia e interacción de las funciones principa-les.

3.4. Aplicación

Para el desarrollo de la aplicación, se tomó como base el proyecto WolfMQTT [40],que es multiplataforma. Fue preciso configurarlo para ejecutarlo en Windows.Luego se incorporó un módulo para procesar los mensajes MQTT y generar unarchivo WAV con la información recibida. Sobre el archivo de sonido, se aplicaronfiltros digitales para optimizar la señal. Finalmente, se utilizó un framework enpython para inferir el sonido de agua corriendo.

3.4.1. Procesar paquetes y generar archivo WAV

El proyecto WolfMQTT implementa una máquina de estados para procesar losmensajes MQTT. Dentro del estado que procesa un nuevo mensaje, se interpretócada paquete para, en un primer lugar, crear el encabezado del archivo WAV,luego agregar el contenido del archivo en formato binario, y finalmente cerrarel archivo en el filesystems del sistema operativo. En el apéndice C se adjunta laestructura del formato de los archivos WAV.

La aplicación recibe un mensaje en formato JSON con dos campos, ”paq” y ”msg”.En el primero se indica el número de paquete y en el segundo se proveen los”128” valores obtenidos por el ADC, como se indicó en la sección 3.3.3. Cuandoel número de paquete es ”1”, se genera el encabezado del archivo de sonido WAVutilizando los parámetros de muestreo aplicados en el firmware. Se utilizan los


FIGURA 3.5. Diagrama de interacción de principales tareasFreeRTOS.

valores en el campo ”msg” para generar la sección data del archivo WAV. En elcódigo 3.7 se aprecia la generación del archivo WAV.

1 void abrirArchivoAudio ( void ) {2 char cadena [ 5 ] ; // 5 bytes incluyendo f i n de

cadena3 unsigned i n t nn ; // 4 bytes4 unsigned shor t i n t n ; // 2 bytes5

6 archivo = fopen ( " captura . wav" , "wb" ) ;7 i f ( archivo != NULL) {8 s t rcpy ( cadena , " RIFF " ) ; f w r i t e ( cadena , 4 , 1 , archivo ) ;

// 4 bytes Contiene l o s codigos ASCII de l a s l e t r a s : ’R ’ , ’ I ’ , ’ F ’y ’ F ’ . RIFF s i g n i f i c a formato de archivo para e l intercambio derecursos ( Resource Interchange F i l e Format ) .

9 nn = 44 − 8 + (1 * 16128 * 2 ) ; f w r i t e (&nn , 4 , 1 , archivo ) ; //4 bytes Entero p o s i t i v o de 32 b i t s que almacena e l tamano en bytesdel r e s t o del archivo . Es decir , tamano t o t a l del archivo −8 (4

bytes de RIFF , y 4 bytes de e s t e numero ) .10 s t rcpy ( cadena , "WAVE" ) ; f w r i t e ( cadena , 4 , 1 , archivo ) ;

// 4 bytes Estos 4 bytes indican que e l archivo almacena audio ,cont ienen l o s codigos ASCII de l a s l e t r a s : ’W’ , ’A ’ , ’V ’ y ’E ’ .

11 s t rcpy ( cadena , " fmt " ) ; f w r i t e ( cadena , 4 , 1 , archivo ) ;// 4 bytes Estos 4 bytes cont ienen l o s c a r a c t e r e s ’ f ’ , ’m ’ , ’ t ’ y ’

’ , indican que hay una subseccion de ’ ’WAVE’ ’ denominada ’ ’ fmt ’ ’Esta subseccion almacena l a s c a r a c t e r i s t i c a s de l a grabacion .

3.4. Aplicación 27

12 nn = 1 6 ; f w r i t e (&nn , 4 , 1 , archivo ) ; //4 bytes Entero p o s i t i v o de 32 b i t s que i n d i ca e l tamano en bytes

del r e s t o del bloque . En caso de se r un numero impar , sera n e c e s a r i ocons iderar l a e x i s t e n c i a de un byte de r e l l e n o .

13 n = 1 ; f w r i t e (&n , 2 , 1 , archivo ) ; //2 bytes Entero p o s i t i v o de 16 b i t s que i n d i ca e l t i p o de grabacion

. Un 1 s i g n i f i c a PCM.14 n = 1 ; f w r i t e (&n , 2 , 1 , archivo ) ; //

2 bytes Numero de cana les . Cuando se usa un canal se habla de unagrabacion mono o monoaural ; mientras que a l uso de dos cana les se l e

sue le l lamar e s t e r e o .15 nn = 16128 ; f w r i t e (&nn , 4 , 1 , archivo ) ; //

4 bytes Frecuencia de muestreo expresada en Hz .16 nn = 16128 * 2 ; f w r i t e (&nn , 4 , 1 , archivo ) ; //

4 bytes Numero promedio de bytes por segundo . Los programas parareproducir audio suelen est imar e l tamano de su b u f f e r usando e s t edato .

17 n = 2 ; f w r i t e (&n , 2 , 1 , archivo ) ; //2 bytes Alineamiento , corresponde con e l numero bytes usados en e larchivo por cada muestra ( s i es e l caso , se consideran ambos

cana les ) .18 n = 1 6 ; f w r i t e (&n , 2 , 1 , archivo ) ; //

2 bytes B i t s por muestra . S i n=16 −> nn=16128;19 s t rcpy ( cadena , " data " ) ; f w r i t e ( cadena , 4 , 1 , archivo ) ;

// 4 bytes Estos 4 bytes cont ienen l o s codigos ASCII de l a s l e t r a s :’d ’ , ’ a ’ , ’ t ’ y ’ a ’ , indican que a cont inuacion estan l o s datos .

20 nn = 16128 * 2 ; f w r i t e (&nn , 4 , 1 , archivo ) ; //4 bytes Entero p o s i t i v o de 32 bytes que i n d i ca e l espac io en bytesque ocupan l o s datos .

21 }22 }23

24 void grabarArchivoAudio ( char * muestra ) {25 i f ( archivo != NULL) {26 char valor [ 5 ] ;27 shor t i n t s ; // 2 bytes28 i n t i , pos = 0 ;29 f o r ( i = 0 ; i < 1 2 8 ; i ++) {30 strncpy ( valor , muestra + pos , 4 ) ; va lor [ 4 ] = ’ \0 ’ ;31 s = ( shor t i n t ) a t o i ( va lor ) ;32 f w r i t e (&s , 2 , 1 , archivo ) ; // n bytes de datos33 pos = pos + 4 ;34 }35 }36 e l s e37 p r i n t f ( " Archivo NO creado\r\n" ) ;38 }

CÓDIGO 3.7. Generación del archivo WAV.

3.4.2. Análisis y mejoramiento de la señal

Para capturar el sonido ambiente se utilizó el micrófono de los sensores keyescomo el de la figura 3.6. Si bien este sensor está diseñado para detectar sonidosfuertes, se pudo regular y capturar el sonido cuando este se encuentra cerca delmicrófono. Se utilizó un osciloscopio para visualizar la forma de la señal leídapor el ADC.

Teniendo en cuenta que la señal generada por el micrófono es muy débil, se uti-lizó un amplificador operacional LM358P en una etapa previa a la lectura del


FIGURA 3.6. Micrófono de los sensores keyes.

ADC. En la figura 3.7 se aprecia el conexionado del micrófono, el amplificador yla EDU-CIAA-NXP.

FIGURA 3.7. Conexionado del micrófono, el amplificador y laEDU-CIAA-NXP.

Se capturaron sonidos de voz y de agua corriendo primero sin utilizar el ampli-ficador y luego utilizándolo. A los correspondientes archivos WAV generados enla aplicación, se denominó señal pura cuando no se utilizó el amplificador y se-ñal amplificada cuando sí se utilizó. En la figura 3.8 se aprecia la señal pura yamplificada de sonido de agua corriendo.

Se observó que en el dominio del tiempo la señal amplificada presentaba un cor-te abrupto cerca del valor 800 en la resolución del ADC, que se corresponde conaproximadamente 2,5 V. Utilizando python, se analizaron ambas señales y se ob-servó, mediante el cálculo de la DFT, que eran similares en el dominio de la fre-cuencia. En la figura 3.9 se aprecia la DFT de la señal pura y amplificada de sonido

3.4. Aplicación 29

FIGURA 3.8. Señal de agua corriendo pura y amplificada.

de agua corriendo.

Dado que la varianza es un indicador para saber cuánto ruido presenta la señal,se calculó tanto para la pura como para la amplificada. También se diseñaronfiltros pasa bajos y pasa banda utilizando la herramienta pyFDA. Los resultadosde estas pruebas y sus conclusiones se presentan en el capítulo 4.

3.4.3. Aplicar modelos de IA

Para inferir el sonido buscado por medio de IA, se utilizó el framework Ubi-coustics. Este cuenta con scripts para aplicar los modelos en vivo utilizando elmicrófono o bien sobre un archivo de sonido. En el presente trabajo se empleóeste último script aplicando los modelos sobre el archivo WAV generado con lainformación recibida desde la EDU-CIAA-NXP.

Dado que el framework cuenta con una amplia cantidad de modelos para pre-decir sonidos provenientes de diversas fuentes (véase sección 2.9), permite con-figurar contextos que agrupan sonidos específicos. En el código 3.8 se aprecianalgunos de estos contextos, como por ejemplo: baño, cocina, oficina, exterior, en-tre otros. Para este trabajo no se configuró un contexto específico, de forma tal


FIGURA 3.9. DFT de señal de agua corriendo pura y amplificada.

que la señal se comparó con todos los modelos disponibles. Asimismo, se obtuvocomo resultado una alta predicción de que la fuente del sonido es agua corriendo.

1

2 bathroom = [ ’ water −running ’ , ’ f l u s h ’ , ’ toothbrush ’ , ’ shaver ’ , ’ hair −dryer ’ ]

3 ki tchen = [ ’ water −running ’ , ’ chopping ’ , ’ cooking ’ , ’ microwave ’ , ’ blender’ , ’ hazard−alarm ’ , ’ dishwasher ’ , ’ speech ’ ]

4 bedroom = [ ’ alarm−clock ’ , ’ snore ’ , ’ cough ’ , ’ baby−cry ’ , ’ speech ’ ]5 o f f i c e = [ ’ knock ’ , ’ typing ’ , ’ phone−ring ’ , ’ door ’ , ’ cough ’ , ’ speech ’ ]6 entrance = [ ’ knock ’ , ’ door ’ , ’ doorbe l l ’ , ’ speech ’ , ’ laugh ’ ]7 outdoor = [ ’dog−bark ’ , ’ cat −meow ’ , ’ engine ’ , ’ car −horn ’ , ’ speech ’ , ’

hazard−alarm ’ ]8 everything = [9 ’dog−bark ’ , ’ d r i l l ’ , ’ hazard−alarm ’ , ’ phone−ring ’ , ’ speech ’ ,

10 ’vacuum ’ , ’ baby−cry ’ , ’ chopping ’ , ’ cough ’ , ’ door ’ ,11 ’ water −running ’ , ’ knock ’ , ’ microwave ’ , ’ shaver ’ , ’ toothbrush ’ ,12 ’ blender ’ , ’ dishwasher ’ , ’ doorbe l l ’ , ’ f l u s h ’ , ’ hair −dryer ’ ,13 ’ laugh ’ , ’ snore ’ , ’ typing ’ , ’hammer ’ , ’ car −horn ’ ,14 ’ engine ’ , ’ saw ’ , ’ cat −meow ’ , ’ alarm−clock ’ , ’ cooking ’15 ]

CÓDIGO 3.8. Configuración de contextos framework Ubicoustics.

3.4. Aplicación 31

Finalmente, la respuesta obtenida junto a su predicción asociada es enviada porMQTT a la EDU-CIAA-NXP, la que reacciona encendiendo un LED en el caso deque se corresponda con agua corriendo. En el código 3.9 se aprecia la configura-ción realizada.

1

2 bathroom = [ ’ water −running ’ , ’ f l u s h ’ , ’ toothbrush ’ , ’ shaver ’ , ’ hair −dryer ’ ]

3

4 /* * * * */5 # ##########################6 # Load Model7 # ##########################8 MODEL_PATH = " models/example_model . hdf5 "9 contex t = u b i c o u s t i c s . everything

10 context_mapping = u b i c o u s t i c s . context_mapping11 s e l e c t e d _ f i l e = ’ captura . wav ’12 s e l e c t e d _ c o n t e x t = ’ everything ’13

14 /* * * * */15

16 # ##########################17 # Esperar captura18 # ##########################19 subprocess . run ( [ ’ awsiot . exe ’ ] )20

21 # ##########################22 # G r a f i c a r captura23 # ##########################24 # Leer25 muestreo , sonido = waves . read ( s e l e c t e d _ f i l e )26 # G r a f i c a r27 p l t . p l o t ( sonido )28 p l t . show ( )29

30 # ##########################31 # Read Wavfile and Make P r e d i c t i o n s32 # ##########################33 x = wavfi le_to_examples ( s e l e c t e d _ f i l e )34 with graph . a s _ d e f a u l t ( ) :35

36 x = x . reshape ( len ( x ) , 96 , 64 , 1 )37 p r e d i c t i o n s = model . p r e d i c t ( x )38

39 f o r k in range ( len ( p r e d i c t i o n s ) ) :40 p r e d i c t i o n = p r e d i c t i o n s [ k ]41 m = np . argmax ( p r e d i c t i o n )42 r t a = " P r e d i c t i o n : %s ( %0.2 f ) " % ( u b i c o u s t i c s . to_human_labels [

l a b e l [m] ] , p r e d i c t i o n [m] )43 subprocess . run ( [ ’ awsiot . exe ’ , r t a ] )

CÓDIGO 3.9. Configuración Ubicoustics utilizada en el proyecto.

33

Capítulo 4

Pruebas, validación y resultados

En este capítulo se detallan los resultados esperados y obtenidos sobre etapaspuntuales en el desarrollo. También se indican las herramientas y metodologíaempleadas en cada caso. Finalmente, se expone el caso de uso completo integran-do todos los componentes del proyecto.

4.1. Pruebas y validaciones sobre el sistema embebido

En la sección 3.1 se elaboró un listado de pruebas a realizar sobre etapas puntua-les del desarrollo. La primera prueba consistió en verificar los indicadores lumí-nicos del phy al conectarlo con la EDU-CIAA-NXP (TEST_001). A continuaciónse exponen las pruebas y resultados obtenidos sobre el firmware del sistema em-bebido.

4.1.1. Integración biblioteca LWIP

Al incluir bibliotecas al makefile del Firmware_v3, se verificó primero que se ge-neren los archivos objetos que luego deben ser linkeados al crear el binario. Estosarchivos se crean dentro de la carpeta ”out” de cada proyecto. Se verificó la res-puesta ping del sistema (TEST_002) tras el establecimiento de los parámetros dered por parte de la tarea LWIP_Init.

Se ejecutó el proyecto TCPEcho en el sistema embebido y, desde una notebook,en la misma red se conectó un socket por el puerto 7. Luego, se verificó el eco decaracteres ascii enviados (TEST_003). El código 4.1 es el encargado de generar eleco desde el sistema embebido, y en la figura 4.1 se aprecia una captura del ecodesde la consola.

1 while ( ( e r r = netconn_recv ( newconn , &buf ) ) == ERR_OK) {2 do {3 netbuf_data ( buf , &data , &len ) ;4 u16_t i ;5 f o r ( i =0 ; i <len ; i ++) {6 i f ( ( ( ( char * ) data ) [ i ] >= ’ a ’ ) && ( ( ( char * ) data ) [ i ] <= ’

z ’ ) ) {7 ( ( char * ) data ) [ i ] −= ’ a ’ ;8 ( ( char * ) data ) [ i ] += ’A ’ ;9 }

10 }11 e r r = netconn_write ( newconn , data , len , NETCONN_COPY) ;

CÓDIGO 4.1. Generación de eco desde el sistema embebido.

34 Capítulo 4. Pruebas, validación y resultados

FIGURA 4.1. Prueba de eco desde la consola.

4.1.2. Integración bibliotecas WolfSSL y WolfMQTT

Luego de integrar las bibliotecas WolfSSL y WolfMQTT, se habilitó el log utili-zando el #define del archivo settings.h. En el mismo #define se indica el nivelde detalle del log. Para algunas pruebas se definió WOLFSSL_DEBUG_TLS, quepermitió entrar en detalle sobre la comunicación TLS (TEST_004 y TEST_005).

La reducida memoria SRAM de la EDU-CIAA-NXP presentó inconvenientes alincorporar las bibliotecas requeridas: FreeRTOS, LWIP, WolfSSL y WolfMQTT. Seutilizó la función xPortGetFreeHeapSize() luego de crear cada tarea dentro deFreeRTOS, y el plugin para Eclipse ”FreeRTOS Task Aware Debugger for GDB -NXP”, que indica la memoria ocupada por cada tarea en tiempo de ejecución. Estocontribuyó a la optimización de la memoria asignada (TEST_006). En la figura 4.2se aprecia el uso de memoria por cada tarea.

FIGURA 4.2. FreeRTOS Task Aware Debugger for GDB - NXP.

4.2. Pruebas y validaciones sobre la aplicación 35

4.1.3. Muestreo de la señal analógica y transmisión a AWS IoT Core

Al realizar el muestreo de la señal, lo primero que se verificó fue el correcto fun-cionamiento del ADC para valores conocidos en el rango de tensión operable.Para esto se utilizó la tensión propia disponible en los conectores de expansiónde la EDU-CIAA-NXP, con los pines GND y +3.3 V. Para lograr un valor interme-dio se utilizó un puente resistivo con resistencias de 5 kOhms que produjo unatensión resultante de 1.64 V y el valor 511 en la lectura del ADC. En el firmwarese utilizaron las funciones de lectura del ADC para verificar los valores corres-pondientes entre 0 y 1023 (TEST_007).

Para probar el correcto armado de los paquetes y su transmisión a AWS IoT Core,se simuló la lectura del ADC inyectando valores secuenciales desde 0 hasta 1023.Para esto, se utilizó la interrupción del timer configurado a 16.128 Hz y se asigna-ron los valores en ambos buffers hasta completarlos. Luego, se transmitieron porMQTT los valores almacenados en los buffers, armando paquetes como se indicóen la sección 3.3.3. Finalmente, desde la consola de AWS IoT Core se suscribióal tópico utilizado y se verificó que la información se recibía de forma comple-ta y ordenada (TEST_008). En la figura 4.3 se puede apreciar la visualización depaquetes desde la consola de AWS IoT Core.

FIGURA 4.3. Consola de AWS IoT Core.

4.2. Pruebas y validaciones sobre la aplicación

Sobre la aplicación también se realizaron pruebas, empezando por generar un ar-chivo WAV del sonido de la palabra ”hola” capturada por la EDU-CIAA-NXP. Elarchivo se ejecutó con un reproductor de sonido de la notebook y se escuchó co-rrectamente por los parlantes (TEST_009). A continuación se exponen las pruebasy resultados obtenidos sobre la aplicación.

4.2.1. Generación de los archivos WAV

Se utilizó una aplicación de smartphone para generar una señal acústica senoidalde 8 kHz, que se capturó y transmitió con la EDU-CIAA-NXP. Con la aplicación


se creó un archivo WAV y se utilizó python para calcular la DFT. En la figura4.4 se aprecia la señal capturada en el dominio del tiempo y de la frecuencia. Alobservar la DFT se identificó la frecuencia predominante esperada (TEST_010).

FIGURA 4.4. Señal senoidal de 8 kHz.

Se utilizó la herramienta pyFDA para diseñar filtros pasa bajos y pasa banda.Luego se exportaron los coeficientes y se realizó la convolución del filtro con laseñal. En la figura 4.5 se aprecia la respuesta en frecuencia del filtro y la señalfiltrada con pasa bajos. Sin embargo, no fue posible generar un archivo WAV dela señal filtrada porque se presentaron errores en la conversión.

4.2.2. Pruebas de inferencia con IA

Utilizando la captura de la palabra ”hola” en la prueba inicial, se aplicaron losmodelos del framework Ubicoustics para inferir el origen del sonido. Se obtuvouna predicción del 87 % asociado a ”persona hablando” (TEST_011).

Se aplicaron los modelos de inferencia con IA a las capturas con y sin amplifica-dor de sonido de agua corriendo indicados en la sección 3.4.2. Se obtuvo comoresultado un 69 % de predicción para la captura sin amplificador y un 91 % para

4.3. Caso de uso completo 37

FIGURA 4.5. Filtro pasa bajos.

la captura con amplificador (TEST_012 y TEST_013). Este resultado llamó la aten-ción ya que la captura con amplificador presentaba mayor ruido al calcular lasvarianzas. En la figura 4.6 se aprecia el resultado obtenido.

4.3. Caso de uso completo

A continuación se detalla el proceso completo desde el muestreo y transmisiónpor parte de la EDU-CIAA-NXP, pasando por el procesamiento en la aplicación yfinalmente recibiendo la respuesta en el sistema embebido.

Para evitar derramar líquidos cerca de la electrónica del sistema embebido, seutilizó un smartphone para capturar el sonido de agua cayendo desde una ca-nilla abierta, y luego se reprodujo cerca del micrófono del sistema embebido. Enla figura 4.7 se aprecia este proceso de captura desde el sistema embebido y lainteracción en los LED como se indicó en la sección 3.3.4.

Previamente a ejecutar el muestreo, se inició la aplicación para subsribirse al tópi-co MQTT y estar a la espera de recibir la información. Una vez que se comienzan


FIGURA 4.6. Resultado de inferencia sobre sonido de agua corrien-do con y sin amplificador.

a recibir los datos, esto se visualiza en el log de la aplicación con un porcentajerecibido que se calcula según la cantidad de paquetes. Una vez recibidos todoslos paquetes, en la aplicación se visualiza la captura de la señal en el dominio deltiempo. En la figura 4.9 se aprecia este proceso.

Finalmente, se utiliza el framework Ubicoustics para predecir la fuente del sonidoy se envía la respuesta por MQTT al sistema embebido. En la figura 4.9 se apreciaeste proceso final de la aplicación y la reacción de la EDU-CIAA-NXP utilizandoel log.

4.3. Caso de uso completo 39

FIGURA 4.7. Proceso de captura.

FIGURA 4.8. Porcentaje en recepción de paquetes.


FIGURA 4.9. Envío de respuesta desde la aplicación al sistema em-bebido.

41

Capítulo 5

Conclusiones

5.1. Trabajo realizado

El desafío más interesante al desarrollar este proyecto fue integrar todas las bi-bliotecas y lograr hacerlas funcionar con las particularidades de SRAM disponi-bles en la hardware de la EDU-CIAA-NXP. El uso de patrones de diseño, modu-larización e integración continua permitió desarrollar un software de alta calidaden el plazo permitido para completar la maestría.

Lo aprendido en la materia "Procesamiento de señales"fue muy valioso ya quepermitió analizar una señal real y visualizarla tanto en el dominio del tiempo co-mo en el de la frecuencia. También proveyó herramientas para conocer la relaciónseñal/ruido y los efectos sobre la morfología de la señal al utilizar un preampifi-cador.

Fue necesario realizar varias iteraciones en el ciclo de vida del desarrollo del pro-yecto, volviendo a la investigación y el análisis para sortear los problemas noprevistos. Entre estos se destacó la falta de memoria SRAM, la que afectó el ca-mino crítico en la elaboración del proyecto. Si bien en la planificación se identificóel riesgo de no lograr integrar las bibliotecas requeridas, no se previó que este po-día ser por falta de memoria debido a la segmentación de la SRAM.

Cabe mencionar que se produjeron inconvenientes significativos, como el de nolograr hacer funcionar el esquema de memoria heap_5 y la integración de la bi-blioteca Mbed TLS. Sin embargo, estos problemas se pudieron subsanar impro-visando un desglose del esquema de memoria heap_4 y la implementación desockets seguros con WolfSSL. Gracias a estos ajustes en el desarrollo del trabajo,se logró:

Integrar las bibliotecas requeridas para conectar el Firmware_v3 con servi-cios en la nube utilizando protocolos seguros.

Muestrear la señal de audio buscada, empaquetar los datos y transmitirlospor MQTT al servicio IoT Core de Amazon.

Desde el lado de la aplicación, procesar y reconstruir la señal de audiocreando un archivo WAV.

Analizar la señal tanto en el dominio del tiempo como en el de la frecuencia.

Aplicar modelos de IA para inferir sobre la señal capturada por la CIAA ypredecir el origen del sonido.

42 Capítulo 5. Conclusiones

Transmitir la respuesta de predicción a la CIAA y esta reaccionó cuando seasoció con agua corriendo.

Generar documentación de referencia para integrar bibliotecas al proyectoFirmware_v3.

Se considera haber realizado un aporte al proyecto CIAA y su comunidad, al per-mitir una rápida integración de la EDU-CIAA-NXP y CIAA-NXP con serviciosen la nube. Al abordar ambos hardwares, el resultado de este trabajo provee he-rramientas con fines académicos y para la industria.

5.2. Próximos pasos

Como continuación del presente trabajo, se propone investigar el funcionamientodel esquema de memoria heap_5 y reemplazarlo por la solución aplicada en estetrabajo. Como así también, integrar las bibliotecas Mbed TLS y FreeRTOS Pluspara disponer de alternativas a WolfSSL y LWIP.

También se considera interesante optimizar los mensajes MQTT para enviar enformato binario grandes volúmenes de datos y así reducir el tiempo de transmi-sión desde la CIAA.

Además de estas propuestas en el firmware del proyecto CIAA, se sugiere agregarmemoria SRAM al hardware de la EDU-CIAA-NXP, y evaluar módulos especialescomo los chips de seguridad que incluyen funciones para RNG y almacenamientode claves.

43

Apéndice A

Actualizar biblioteca FreeRTOSen Firmware_v3

Firmware_v3 es el framework oficial para desarrollo en la EDU-CIAA-NXP. Ensu versión r1.3, incluye la biblioteca FreeRTOS Kernel V10.0.1. En el sitio oficialGitHub [41] de FreeRTOS se puede descargar la versión V10.3.0 y estos son lospasos para actualizar esta biblioteca en Firmware_v3:

1. El código debe ser descargado desde GitHub y descomprimirlo localmente.

2. El contenido ubicado en la raíz de FreeRTOS-Kernel se debe copiar y reem-plazar por el de la carpeta ”/Firmware_v3/libs/freertos/source/” (puedehaber diferencias; por ejemplo, no están en FreeRTOS-Kernel los archivos”static_provider.c” ni ”hook.c” y ”croutine.c” no está en Firmware_v3).

3. En caso de que se modifique algún esquema de memoria en el proyecto deGitHub, la carpeta ”/Firmware_v3/libs/freertos/source/MemMang/” sedebe actualizar.

4. El contenido ubicado en ”/FreeRTOS-Kernel/include/” se debe copiar yreemplazar por el de la carpeta ”/Firmware_v3/libs/freertos/include/”.

5. El contenido de la carpeta ”/Firmware_v3/libs/freertos/include/private/”se debe eliminar.

Después de actualizar, en ”/Firmware_v3/libs/freertos/source/” deben quedardel proyecto Firmware_3 los archivos ”hooks.c”, ”redlib_memfix.c” y ”static_provider.c”. Tener en cuenta el nuevo FreeRTOSConfig.h [42] para utilizar en ca-da proyecto.

45

Apéndice B

Configuración optimizada deMbed TLS

La biblioteca Mbed TLS se puede descargar desde su sitio oficial de Mbed [36]o desde el repositorio de GitHub [43]. Para incorporar la biblioteca al proyectoFirmware_v3, se debe copiar dentro de la carpeta ”Firmware_v3/libs/” y confi-gurar ”module.mk”. Mbed TLS tiene un archivo de configuración ”config.h” paraestablecer #define que alteran su huella y modifica su funcionalidad. La configu-ración óptima de la biblioteca Mbed TLS v2.16.0 para la EDU_CIAA_NXP es lasiguiente:

MBEDTLS_HAVE_ASM

MBEDTLS_PLATFORM_MEMORY

MBEDTLS_DEPRECATED_REMOVED

MBEDTLS_CIPHER_MODE_CBC

MBEDTLS_CIPHER_MODE_CFB

MBEDTLS_CIPHER_MODE_CTR

MBEDTLS_CIPHER_PADDING_PKCS7

MBEDTLS_CIPHER_PADDING_ONE_AND_ZEROS

MBEDTLS_CIPHER_PADDING_ZEROS_AND_LEN

MBEDTLS_CIPHER_PADDING_ZEROS

MBEDTLS_REMOVE_ARC4_CIPHERSUITES

MBEDTLS_ECP_DP_SECP256R1_ENABLED

MBEDTLS_ECP_NIST_OPTIM

MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED

MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED

MBEDTLS_GENPRIME

MBEDTLS_NO_PLATFORM_ENTROPY

MBEDTLS_ENTROPY_FORCE_SHA256

MBEDTLS_PK_RSA_ALT_SUPPORT

MBEDTLS_PKCS1_V15

46 Apéndice B. Configuración optimizada de Mbed TLS

MBEDTLS_SELF_TEST

MBEDTLS_SSL_ALL_ALERT_MESSAGES

MBEDTLS_SSL_ENCRYPT_THEN_MAC

MBEDTLS_SSL_EXTENDED_MASTER_SECRET

MBEDTLS_SSL_MAX_FRAGMENT_LENGTH

MBEDTLS_SSL_PROTO_TLS1_2

MBEDTLS_SSL_ALPN

MBEDTLS_SSL_SERVER_NAME_INDICATION

MBEDTLS_THREADING_ALT

MBEDTLS_VERSION_FEATURES

MBEDTLS_X509_CHECK_KEY_USAGE

MBEDTLS_X509_CHECK_EXTENDED_KEY_USAGE

MBEDTLS_AES_C

MBEDTLS_ASN1_PARSE_C

MBEDTLS_ASN1_WRITE_C

MBEDTLS_BASE64_C

MBEDTLS_BIGNUM_C

MBEDTLS_CIPHER_C

MBEDTLS_CTR_DRBG_C

MBEDTLS_ECDH_C

MBEDTLS_ECDSA_C

MBEDTLS_ECP_C

MBEDTLS_ENTROPY_C

MBEDTLS_GCM_C

MBEDTLS_MD_C

MBEDTLS_OID_C

MBEDTLS_PEM_PARSE_C

MBEDTLS_PK_C

MBEDTLS_PK_PARSE_C

MBEDTLS_PK_WRITE_C

MBEDTLS_PLATFORM_C

MBEDTLS_RSA_C

MBEDTLS_SHA1_C

MBEDTLS_SHA256_C

Apéndice B. Configuración optimizada de Mbed TLS 47

MBEDTLS_SSL_CLI_C

MBEDTLS_SSL_TLS_C

MBEDTLS_THREADING_C

MBEDTLS_VERSION_C

MBEDTLS_X509_USE_C

MBEDTLS_X509_CRT_PARSE_C

MBEDTLS_SSL_MAX_CONTENT_LEN 8192

MBEDTLS_ENTROPY_HARDWARE_ALT

MBEDTLS_AES_ROM_TABLES

49

Apéndice C

Formato de los archivos WAV

Debido a su simplicidad, el formato WAV resulta conveniente para hacer ejerci-cios de procesamiento digital de señales. La estructura de los archivos WAV secompone de varias secciones y pueden contener el audio en diversas formas. Enla tabla C.1 se puede apreciar la estructura de un archivo WAV.

TABLA C.1. Estructura de un archivo WAV.

SecciónTamaño(bytes)

Descripción

RIFF4 Contiene los códigos ASCII de las letras: ’R’, ’I’, ’F’ y ’F’:

Indica ”Resource Interchange File Format”.4 Entero positivo de 32 bits que almacena el tamaño en bytes

del resto del archivo. Es decir, tamaño total del archivo – 8(4 bytes de RIFF, y 4 bytes de este número).

WAVE

4 Contiene los códigos ASCII de las letras: ’W’, ’A’, ’V’ y ’E’.4 Contiene los códigos ASCII de las letras: ’f’, ’m’, ’t’ y ’ ’:

Indican una subsección FMT de ”WAVE”.4 Entero positivo de 32 bits que indica el tamaño en bytes

del resto del bloque. En caso de ser un número impar, seránecesario considerar la existencia de un byte de relleno.

2 Entero positivo de 16 bits que indica el tipo de grabación.Un 1 significa PCM.

2 Número de canales.4 Frecuencia de muestreo expresada en Hz.4 Número promedio de bytes por segundo utilizado para es-

timar el tamaño del buffer.2 Alineamiento, corresponde con el número de bytes usados

en el archivo por cada muestra (si es el caso, se consideranambos canales).

2 Bits por muestra.

data4 Contiene los códigos ASCII de las letras: ’d’, ’a’, ’t’ y ’a’:

inicio sección de datos.4 Indica el espacio en bytes que ocupan los datos.n Datos.

51

Bibliografía

[1] es.ryte.com/wiki/. Ataque de intermediario. Disponible: 2020-11-04. URL:https://es.ryte.com/wiki/Man-In-The-Middle.

[2] IETF. SSL RFC5246. Disponible: 2020-11-11. URL:https://tools.ietf.org/html/rfc5246.

[3] Mozilla DOCS. Encriptacion simetrica y asimetrica. Disponible: 2020-11-11.URL: https://developer.mozilla.org/es/docs/Archive/Security/Encriptaci%C3%B3n_y_Desencriptaci%C3%B3n.

[4] IETF. Apretón de manos SSL. Disponible: 2020-11-11. URL:https://tools.ietf.org/html/rfc4680.

[5] iprofesional. Tendencia uso IA. Disponible: 2020-11-11. URL:https://campus.iprofesional.com/tecnologia/323081-inteligencia-artificial-40-de-empresas-grandes-ya-invierten-en-ella.

[6] infoplc. Hardware para IA. Disponible: 2020-11-11. URL:https://www.infoplc.net/noticias/item/106296-co-creacion-acelerar-inteligencia-artificial-sistemas-integrados.

[7] Kinsta. Cuota mercado plataformas en la nube. Disponible: 2020-11-11. URL:https://kinsta.com/es/blog/cuota-de-mercado-de-la-nube/.

[8] Proyecto CIAA. Computadora Industrial Abierta Argentina. Visitado el2016-06-25. 2014. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

[9] CIAA. CIAA-NXP. Disponible: 2020-11-11. URL:http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:hardware:ciaa_nxp:ciaa_nxp_inicio.

[10] CIAA. EDU-CIAA-NXP. Disponible: 2020-11-11. URL:http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp.

[11] CIAA. Firmware V3. Disponible: 2020-11-11. URL:https://github.com/epernia/firmware_v3/blob/master/documentation/firmware/readme/readme-es.md.

[12] CIAA. CIAA-NXP: Ethernet. Disponible: 2020-11-11. URL:http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:hardware:ciaa_nxp:ethernet_nxp.

[13] Comunidad CIAA. Poncho Ethernet. Disponible: 2020-11-11. URL:http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=repo:ponchos:ethernet.

[14] AWS. Amazon FreeRTOS. Disponible: 2020-11-11. URL:https://aws.amazon.com/es/freertos/.

[15] AWS. Amazon FreeRTOS licencia. Disponible: 2020-11-11. URL:https://github.com/FreeRTOS/FreeRTOS/blob/lts-development/FreeRTOS/License/license.txt.

[16] AWS. Socket seguros FreeRTOS. Disponible: 2020-11-11. URL: https://docs.aws.amazon.com/freertos/latest/userguide/secure-sockets.html.

https://es.ryte.com/wiki/Man-In-The-Middle

https://tools.ietf.org/html/rfc5246

https://developer.mozilla.org/es/docs/Archive/Security/Encriptaci%C3%B3n_y_Desencriptaci%C3%B3n

https://developer.mozilla.org/es/docs/Archive/Security/Encriptaci%C3%B3n_y_Desencriptaci%C3%B3n

https://tools.ietf.org/html/rfc4680

https://campus.iprofesional.com/tecnologia/323081-inteligencia-artificial-40-de-empresas-grandes-ya-invierten-en-ella

https://campus.iprofesional.com/tecnologia/323081-inteligencia-artificial-40-de-empresas-grandes-ya-invierten-en-ella

https://www.infoplc.net/noticias/item/106296-co-creacion-acelerar-inteligencia-artificial-sistemas-integrados

https://www.infoplc.net/noticias/item/106296-co-creacion-acelerar-inteligencia-artificial-sistemas-integrados

https://kinsta.com/es/blog/cuota-de-mercado-de-la-nube/

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

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:hardware:ciaa_nxp:ciaa_nxp_inicio

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:hardware:ciaa_nxp:ciaa_nxp_inicio



https://github.com/epernia/firmware_v3/blob/master/documentation/firmware/readme/readme-es.md

https://github.com/epernia/firmware_v3/blob/master/documentation/firmware/readme/readme-es.md

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:hardware:ciaa_nxp:ethernet_nxp

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:hardware:ciaa_nxp:ethernet_nxp

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=repo:ponchos:ethernet

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=repo:ponchos:ethernet

https://aws.amazon.com/es/freertos/

https://github.com/FreeRTOS/FreeRTOS/blob/lts-development/FreeRTOS/License/license.txt

https://github.com/FreeRTOS/FreeRTOS/blob/lts-development/FreeRTOS/License/license.txt

https://docs.aws.amazon.com/freertos/latest/userguide/secure-sockets.html

https://docs.aws.amazon.com/freertos/latest/userguide/secure-sockets.html

52 Bibliografía

[17] AWS. Administración de memoria en FreeRTOS. Disponible: 2020-11-11. URL:https://docs.aws.amazon.com/es_es/freertos/latest/userguide/dev-guide-freertos-kernel.html.

[18] AWS. Administración de memoria en FreeRTOS estática y dinámica.Disponible: 2020-11-11. URL:https://www.freertos.org/Static_Vs_Dynamic_Memory_Allocation.html.

[19] Adam Dunkels. Biblioteca LWIP. Disponible: 2020-11-11. URL:https://www.nongnu.org/lwip/2_0_x/index.html.

[20] WolfSSL. Biblioteca WolfSSL. Disponible: 2020-11-11. URL:https://www.wolfssl.com/docs/.

[21] WolfSSL. Suites WolfSSL. Disponible: 2020-11-11. URL:https://www.wolfssl.com/docs/wolfssl-manual/ch4/.

[22] IBM. MQTT. Disponible: 2020-11-11. URL:https://developer.ibm.com/es/technologies/iot/articles/iot-mqtt-why-good-for-iot/.

[23] WolfSSL. WolfMQTT. Disponible: 2020-11-11. URL:https://www.wolfssl.com/products/wolfmqtt/.

[24] AWS. Infraestructura AWS. Disponible: 2020-11-11. URL:https://aws.amazon.com/es/about-aws/global-infrastructure/.

[25] AWS. Servicios AWS. Disponible: 2020-11-11. URL:https://aws.amazon.com/es/products/.

[26] AWS. IoT Core AWS. Disponible: 2020-11-11. URL:https://aws.amazon.com/es/iot-core/.

[27] SciPy.org. Python Scipy Signal. Disponible: 2020-11-18. URL:https://docs.scipy.org/doc/scipy/reference/signal.html.

[28] pypi.org/proyect/pdyfda. pyFDA. Disponible: 2020-11-18. URL:https://pypi.org/project/pyfda/.

[29] Ubicoustics. Ubicoustics. Disponible: 2020-11-04. URL:https://github.com/FIGLAB/ubicoustics.

[30] Google. TensorFlow. Disponible: 2020-11-04. URL:https://www.tensorflow.org/.

[31] Google. Ubicoustics. Disponible: 2020-11-04. URL: kerashttps://keras.io/.[32] Amazon AWS. Políticas IoT. Disponible: 2020-11-18. URL:

https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-actions.html.

[33] Amazon AWS. AWS Certificados CA. Disponible: 2020-11-18. URL:https://docs.aws.amazon.com/iot/latest/developerguide/server-authentication.html?icmpid=docs_iot_console#server-authentication-certs.

[34] FreeRTOS. FreeRTOS Plus TCP/TCP - Echo Clients. Disponible: 2020-11-16.URL: https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_Echo_Clients.html.

[35] LPCOpen. LPCOpen LWIP - Echo Clients. Disponible: 2020-11-16. URL:http://67.222.144.123/lpcopen/v1.03/lpc18xx__43xx_2examples_2lwip_2lwip__tcpecho__freertos_2lwip__tcpecho__freertos_8c_source.html.

[36] arm MBED. Mbed TLS. Disponible: 2020-11-16. URL:https://tls.mbed.org/.

[37] mcuoneclipse.com. Utilizando multiples regiones en heap de FreeRTOS.Disponible: 2020-11-16. URL:https://mcuoneclipse.com/2017/09/18/using-multiple-memory-regions-with-the-freertos-heap/.

https://docs.aws.amazon.com/es_es/freertos/latest/userguide/dev-guide-freertos-kernel.html

https://docs.aws.amazon.com/es_es/freertos/latest/userguide/dev-guide-freertos-kernel.html

https://www.freertos.org/Static_Vs_Dynamic_Memory_Allocation.html

https://www.nongnu.org/lwip/2_0_x/index.html

https://www.wolfssl.com/docs/

https://www.wolfssl.com/docs/wolfssl-manual/ch4/

https://developer.ibm.com/es/technologies/iot/articles/iot-mqtt-why-good-for-iot/

https://developer.ibm.com/es/technologies/iot/articles/iot-mqtt-why-good-for-iot/

https://www.wolfssl.com/products/wolfmqtt/

https://aws.amazon.com/es/about-aws/global-infrastructure/

https://aws.amazon.com/es/products/

https://aws.amazon.com/es/iot-core/

https://docs.scipy.org/doc/scipy/reference/signal.html

https://pypi.org/project/pyfda/

https://github.com/FIGLAB/ubicoustics

https://www.tensorflow.org/

keras https://keras.io/

https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-actions.html

https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-actions.html

https://docs.aws.amazon.com/iot/latest/developerguide/server-authentication.html?icmpid=docs_iot_console#server-authentication-certs



https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_Echo_Clients.html

https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_Echo_Clients.html

http://67.222.144.123/lpcopen/v1.03/lpc18xx__43xx_2examples_2lwip_2lwip__tcpecho__freertos_2lwip__tcpecho__freertos_8c_source.html

http://67.222.144.123/lpcopen/v1.03/lpc18xx__43xx_2examples_2lwip_2lwip__tcpecho__freertos_2lwip__tcpecho__freertos_8c_source.html

https://tls.mbed.org/

https://mcuoneclipse.com/2017/09/18/using-multiple-memory-regions-with-the-freertos-heap/

https://mcuoneclipse.com/2017/09/18/using-multiple-memory-regions-with-the-freertos-heap/

Bibliografía 53

[38] Nyquist-Shannon. Teorema de Nyquist-Shannon. Disponible: 2020-11-16.URL: https://www.elettroamici.org/es/teorema-di-nyquist-shannon/.

[39] developer.mozilla.org. Formato JSON. Disponible: 2020-11-16. URL: https://developer.mozilla.org/es/docs/Learn/JavaScript/Objects/JSON.

[40] WolfSSL. Proyecto WolfMQTT. Disponible: 2020-11-18. URL:https://www.wolfssl.com/products/wolfmqtt/.

[41] Amazon FreeRTOS. FreeRTOS-Kernel. Disponible: 2020-11-18. URL:https://github.com/FreeRTOS/FreeRTOS-Kernel/.

[42] Amazon FreeRTOS. FreeRTOSConfig.h. Disponible: 2020-11-18. URL:https://www.freertos.org/a00110.html.

[43] arm MBED. GitHub Mbed TLS. Disponible: 2020-11-16. URL:https://github.com/ARMmbed/mbedtls.

https://www.elettroamici.org/es/teorema-di-nyquist-shannon/

https://developer.mozilla.org/es/docs/Learn/JavaScript/Objects/JSON

https://developer.mozilla.org/es/docs/Learn/JavaScript/Objects/JSON

https://www.wolfssl.com/products/wolfmqtt/

https://github.com/FreeRTOS/FreeRTOS-Kernel/

https://www.freertos.org/a00110.html

https://github.com/ARMmbed/mbedtls

integración de amazon freertos al proyecto ciaa

Documents