Validaci on Hardware de plataforma para IoT en el Edge y porting de Contiki …oa.upm.es/65537/1/TFM_PABLO_MERINO_CALERO.pdf · 2020. 11. 24. · Tras la intro-ducci on se presenta

Validacion Hardware de plataforma para IoTen el Edge y porting de Contiki-NG

Trabajo Fin de Master

Pablo Merino CaleroJulio 2019

Jorge Portilla BerruecoGabriel Mujica Rojas

Resumen

Hoy en dıa, la tecnologıa se adentra cada vez mas en el mundo de lo interconectado. Es cadavez mas normal encontrar dispositivos hasta ahora comunes, conectados a la red tanto de formalocal como de forma global. Estos dispositivos pertenecen a lo que se conoce como Internet ofThings (IoT).Este sector, en continuo crecimiento, es el seno de multitud de nuevas oportunidades y proyec-tos que tratan de explotar su potencial. Uno de estos proyectos es SCOTT (Secure ConnectedTrustable Things), un proyecto internacional enfocado a la integracion de la tecnologıa IoT enla sociedad para su uso en el dıa a dıa. SCOTT se compone de multiples frentes de accion,denominados dominios.Uno de esos dominios es el Rail, cuyos objetivos incluyen la modernizacion y mejora de la redferroviaria europea, aprovechandose de las nuevas tecnologıas disponibles. Una de sus iniciativasconsiste en el despliegue de una red de sensores inalambricos como parte de la infraestructurade la red ferroviaria, de modo que se mejore el desempeno respecto al sistema empleado actual-mente, reduciendo la distancia mınima de seguridad entre trenes y los tiempos de respuesta delbucle de control, a la vez que auna los sistemas on-rail y los sistemas on-track en una unicainfraestructura unificada.Para lograr esta meta, en el Centro de Electronica Industrial de la Universidad Politecnica deMadrid (CEI-UPM) se ha desarrolado una plataforma hardware modular, versatil y enfocadaal bajo consumo de energıa, cuya finalidad es ser los nodos que formen la red de sensores, si-guiendo el estandar IEEE 802.15.4. Dicha plataforma necesita ser caracterizada y validado sufuncionamiento, antes de poder ser desplegada. Del mismo modo, cualquier sistema operativoque vaya a funcionar en la plataforma debera ser adaptado y portado a la misma para poderser utilizado.El presente Trabajo Fin de Master trata sobre la verificacion y validacion de dicha plataforma,como paso fundamental previo a su despliegue y explotacion, ası como el porting de Contiki-NG,un sistema operativo especializado en dispositivos con limitacion de recursos y enfocado a IoT,y que incorpora soporte para redes IEEE 802.15.4. Ademas de estas dos tareas principales, elpresente trabajo incluye una serie de pruebas sobre el sistema con la finalidad de conocer elconsumo y poner a prueba la red.El trabajo se divide en 7 secciones, comenzando con una introduccion al mismo. Tras la intro-duccion se presenta el estado del arte, en el que se incluye el marco teorico del proyecto.A continuacion se da paso al cuerpo del trabajo, con una seccion dedicada a la validacion de laplataforma hardware y otra que detalla el porting realizado sobre el sistema operativo Contiki-NG para la plataforma. Tras este bloque central se encuentra la seccion dedicada a las pruebasde consumo y de red realizadas sobre el sistema.Por ultimo, se dedica una seccion a las conclusiones y lıneas futuras del proyecto, tras lo quese incluye una seccion final dedicada a la planificacion y presupuesto del mismo.

Indice

Resumen 3

1. Introduccion 91.1. Alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2. Sobre el proyecto SCOTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Estado del arte 132.1. Internet de las Cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2. El modelo de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3. Capa fısica: IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4. Fragmentacion con 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5. El rutado en una red de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6. Uso de JSON y MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3. La plataforma Cookie 273.1. La plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2. Pruebas de validacion del Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1. Alimentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.2. Sensor de temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.3. Sensor inercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.4. Medidor de consumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.5. Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4. Contiki-NG 474.1. El Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2. La integracion de Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.1. El porting inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.2. La adaptacion final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.3. Integracion con Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5. Pruebas experimentales 595.1. Pruebas de consumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2. Pruebas de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3. Pruebas de red: integracion con Python . . . . . . . . . . . . . . . . . . . . . . . 64

6. Conclusiones y lıneas futuras 69

7. Planificacion del proyecto 737.1. Estructura de Descomposicion del Proyecto . . . . . . . . . . . . . . . . . . . . . 737.2. Planificacion temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.3. Presupuesto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Indice de figuras

1. Proyecto SCOTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112. El esquema tradicional de capas en IoT . . . . . . . . . . . . . . . . . . . . . . . 133. Numero de dispositivos IoT conectados y prevision 2015-2025 . . . . . . . . . . . 154. El modelo de capas OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165. Comparativa modelo OSI convencional y aplicado a IoT . . . . . . . . . . . . . . 186. El formato de un frame en 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . 197. Modulacion PSK: senales moduladora, portadora y modulada . . . . . . . . . . . 198. Constelacion de O-QPSK (codificacion Gray) . . . . . . . . . . . . . . . . . . . . 209. Compresion de encabezados en 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . 2110. Intercambio de mensajes de control ICMPv6 en RPL . . . . . . . . . . . . . . . . 2211. Algoritmo de obtencion de CRC mediante anexion de ceros . . . . . . . . . . . . 2412. La plataforma Cookieboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2713. Esquema funcional de la Cookieboard . . . . . . . . . . . . . . . . . . . . . . . . 2814. Pinout de las E/S del EFR32 en la Cookie . . . . . . . . . . . . . . . . . . . . . . 2915. Pinout del EFR32 en la Cookie traducido a codigo (bspconfig.h) . . . . . . . . . 3016. Pinout del EFR32 en la Cookie traducido a codigo (hal-config-board.h) . . . . . 3117. Funcion de inicializacion BOARD init, en board cookie.c . . . . . . . . . . . . . . 3218. Board cookie.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3319. Funciones de board cookie.c (1/3) . . . . . . . . . . . . . . . . . . . . . . . . . . 3320. Funciones de board cookie.c (2/3) . . . . . . . . . . . . . . . . . . . . . . . . . . 3421. Funciones de board cookie.c (3/3) . . . . . . . . . . . . . . . . . . . . . . . . . . 3522. Metodos de alimentacion de la Cookie . . . . . . . . . . . . . . . . . . . . . . . . 3623. Setup del banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3724. Herramienta Simplicity Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3725. Lista de comandos del si7021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3826. Prueba de sensor termico en bare metal : funcion main . . . . . . . . . . . . . . . 3927. Prueba de sensor termico en bare metal : funcion de medida (fragmento) . . . . . 4028. Funcion de inicializacion generica initBoard . . . . . . . . . . . . . . . . . . . . . 4029. Prueba de radio en bare metal : main y funcion de envıo . . . . . . . . . . . . . . 4330. Prueba de radio en bare metal : funcion de recepcion . . . . . . . . . . . . . . . . 4331. Prueba de radio en bare metal : LEDs indicadores . . . . . . . . . . . . . . . . . . 4432. Prueba de radio en bare metal : lectura del terminal . . . . . . . . . . . . . . . . . 4433. Logos de Contiki-NG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4734. Contextos de ejecucion en Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . 4835. Arquitectura de software en aplicaciones IoT . . . . . . . . . . . . . . . . . . . . 5036. Sistema de archivos en Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5137. Makefile de un proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5238. Arbol de dependencias de Makefiles en Contiki . . . . . . . . . . . . . . . . . . . 5339. Platform.c para la plataforma Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 5440. El archivo board.h (fragmento) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5541. Alteraciones sobre Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5642. Variables de entorno en Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5743. Makefile modificado del proyecto udp-client/udp-server . . . . . . . . . . . . . . 5744. Mensaje de arranque de Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5845. Modos de bajo consumo del EFR32 . . . . . . . . . . . . . . . . . . . . . . . . . . 6046. Disparo de consumo en el momento de una transmision saliente de radio . . . . . 6147. Consumo de los diversos modos de la Cookie (mA) . . . . . . . . . . . . . . . . . 6248. Callback de recepcion del servidor udp . . . . . . . . . . . . . . . . . . . . . . . . 6349. Datos obtenidos, leıdos directamente en pantalla . . . . . . . . . . . . . . . . . . 64

50. Consola de Python, recepcion de datos . . . . . . . . . . . . . . . . . . . . . . . . 6551. Archivo JSON de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6652. Archivo JSON generado en el proyecto (fragmento) . . . . . . . . . . . . . . . . . 6653. Envıo de MQTT en el proyecto (fragmento) . . . . . . . . . . . . . . . . . . . . . 6754. Maquina de estados del cliente MQTT . . . . . . . . . . . . . . . . . . . . . . . . 6755. Soporte de RIOT-OS para el EFR32 . . . . . . . . . . . . . . . . . . . . . . . . . 7056. Arranque tıpico de un procesador EFR32 . . . . . . . . . . . . . . . . . . . . . . 7057. EDP: nivel superior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7358. EDP: gestion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7459. EDP: formacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7460. EDP: herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7461. EDP: desarrollo del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7562. EDP: redaccion del TFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7563. Diagrama de Gantt del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Validacion Hardware de plataforma IoT y porting de Contiki-NG

1. Introduccion

Hoy en dıa, la tecnologıa se adentra cada vez mas en el mundo de lo interconectado. Es cadavez mas normal encontrar dispositivos hasta ahora comunes, conectados a la red tanto de formalocal como de forma global. Cosas como, por ejemplo, dejar preparada la lavadora en casa yenviarle un aviso cuando quede una hora para llegar del trabajo de modo que se encienda sola,poder programar el horno de manera anticipada, poder lanzar una orden de compra cuandose acaba el detergente solo pulsando un boton en la despensa o recibir automaticamente en eltelefono movil la clave de conexion de la red WiFi del recinto al asistir a un evento, solo condirigir la camara hacia un sımbolo en el folleto del mismo.Todos estos casos tienen algo en comun: cada uno de estos dispositivos dispone de una interfazde red, un nexo que les permite conectarse a otros dispositivos e interactuar con ellos. Es estacapacidad de relacionarse, de manera mas rudimentaria o mas compleja en cada caso, lo queles ha dado el nombre de dispositivos “inteligentes” (Smart Things).Muchas veces, al hablar de dispositivos inteligentes uno se imagina maquinas propias de histo-rias de ciencia ficcion, dotadas de una gran autonomıa y con funciones mucho mas generales yabstractas de lo que son en realidad. En la mayorıa de los casos, estos dispositivos inteligentestienen una funcionalidad muy limitada, enfocada al objetivo concreto para el que fueron di-senados.Dentro de la amplia definicion de Smart Things se incluyen dispositivos de todo tipo: aquelloscon acceso a la red electrica, dispositivos alimentados por baterıa o incluso dispositivos sinbaterıa que recolectan energıa del entorno mediante harvesting. Incluso existen dispositivos pu-ramente pasivos, cuya unica energıa es extraıda de la propia senal que les ordena actuar (comolas etiquetas RFID pasivas).Todos estos dispositivos inteligentes forman parte de lo que ha llegado a conocerse como In-ternet of Things, o IoT. El caso mas conocido y, tal vez, el mas comun dentro del espectro dedispositivos IoT es el de pequenas plataformas embebidas construidas alrededor de un micro-procesador (System on Chip, SoC), dotadas de capacidad de comunicacion, ası como una mayoro menor versatilidad en cuanto a potencia de procesamiento y variedad de sensores. Plataformasde proposito general como Arduino [2] o Raspberry Pi [35], o mas especıficas para su uso comonodos sensores, como TelosB [1] o Waspmote [28], son algunos de los ejemplos comerciales masconocidos en este sector.Ademas de estas dos vertientes mas clasicas, se esta produciendo la aparicion de plataformasque combinan prestaciones en potencia, conectividad y bajo consumo, gracias a la mejora enel rendimiento y reduccion del consumo que ha venido de la mano de las nuevas arquitecturas,siendo una de las mas empleadas la arquitectura ARM [34]. Esto permite crear sistemas poten-tes con un consumo de energıa muy reducido, capaces de adaptarse a la aplicacion especıficaque se requiera desde la gran versatilidad de la que parten.En el seno de esta nueva ola se ubica la familia de plataformas Cookies desarrollada en el Cen-tro de Electronica Industrial de la Universidad Politecnica de Madrid (CEI-UPM) durante losultimos anos, una solucion de sistemas embebidos basada en la modularidad y capacidad deacoplamiento de distintas placas entre sı mediante sus conectores verticales. La potencia de laplataforma Cookie radica en su versatilidad, teniendo placas enfocadas al procesamiento conFPGAs, placas de alimentacion, placas centradas en la conectividad, etc. Dentro de esta familiade dispositivos se ha desarrollado una placa IoT con capacidad de conexion IEEE 802.15.4 [17],equipada con una serie de sensores y herramientas para el control del consumo, y construidaalrededor de un SoC de arquitectura ARM de la ultima generacion.El desarrollo de una nueva plataforma trae consigo una serie de tareas, consecuencia del mismo.Estas tareas incluyen la verificacion y validacion de su funcionamiento, ası como la adapta-cion de software existente para otros dispositivos de modo que pueda ser utilizado en la nuevaplataforma.

Pablo Merino Calero 9

Capıtulo 1. Introduccion

1.1. Alcance y objetivos

El presente Trabajo Fin de Master engloba la actividad realizada en el Centro de ElectronicaIndustrial de la Universidad Politecnica de Madrid (CEI-UPM), desde el mes de septiembre de2018 hasta la realizacion y entrega de este trabajo en Julio de 2019. Dicha actividad tiene comoobjetivo la preparacion de la nueva plataforma desarrollada en el centro como resultado deltrabajo anterior de otro alumno para su uso futuro. Esta preparacion incluye la validacion delhardware de la plataforma, ası como la adaptacion del sistema operativo Contiki-NG [5] parala misma, a partir de un porting parcial existente para una placa comercial basada en el mismomicroprocesador. Por ultimo, se ha realizado una serie de pruebas adicionales para conocer elconsumo de la plataforma y probar el funcionamiento de la radio.Por tanto, en el desarrollo del trabajo se distinguen principalmente tres actividades, que co-rresponden a los objetivos del trabajo y dentro de las cuales se puede englobar el esfuerzorealizado:

Verificacion y validacion del funcionamiento de la plataforma hardware, como se puedever en la seccion 3.

Porting del sistema operativo Contiki-NG a la plataforma, que se incluye en la seccion 4.

Realizacion de pruebas de consumo y de red sobre el sistema, que pueden encontrarse enla seccion 5.

A lo largo de este trabajo se genero una serie de documentos adicionales, como una guıa para laintegracion de Contiki con el entorno Eclipse o un artıculo academico que serıa enviado de caraal congreso 17th ACM Conference on Embedded Networked Sensor Systems (SenSys 2019), cuyoestado de aceptacion o rechazo es todavıa desconocido a la fecha de finalizacion de este TFM(Julio de 2019), ası como otro artıculo en desarrollo centrado en el desempeno de la plataformay una caracterizacion mas en detalle de la misma.

1.2. Sobre el proyecto SCOTT

Todo el trabajo mencionado se engloba dentro del marco del proyecto SCOTT (SecureConnected Trustable Things), proporcionando un caso de uso para la plataforma y la integraciondel sistema operativo que se presentan. El proyecto SCOTT es un proyecto respaldado por laECSEL Joint Undertaking (Electronic Components and Systems for European Leadership), con57 entidades colaboradoras y presencia en 11 paıses de Europa ademas de Brasil.Desde una perspectiva mas elevada, SCOTT busca facilitar la integracion del Internet de lasCosas en la vida cotidiana e impulsar las tecnologıas inalambricas para su implantacion en elmercado, tratando de solventar el principal problema a dıa de hoy en estas tecnologıas: la faltade fiabilidad y de seguridad.Desde una perspectiva mas cercana, este trabajo se encuentra dentro del dominio Rail de

SCOTT. El objetivo que se persigue en este dominio Rail del proyecto es la implantacion deuna red de sensores inalambrica como parte de una infraestructura en el sistema ferroviariode modo que se mejore el desempeno respecto al sistema actual. Actualmente, la limitacionde los sistemas ETCS (European Train Control System) empleados es la distancia a la que unsistema de control puede manejar el sistema de trenes de forma segura, y el tiempo de ciclo delbucle de control. Otros problemas existentes son la fiabilidad del enlace de datos en el sistemade comunicaciones, ası como la infraestructura a lo largo de la vıa. La finalidad de SCOTT esconseguir una infraestructura todo en uno que aune los sistemas on-rail con los sistemas on-track, actualmente independientes. Tambien busca lograr un sistema distribuido en los trenes,siendo de esta forma mas rapido en el control y mas eficiente que los sistemas centralizados. Ellogo del proyecto SCOTT y un pequeno esquema del sistema de trenes planteado se muestra

10 Escuela Tecnica Superior de Ingenieros Industriales (UPM)


(a) Logo SCOTT

(b) Esquema ferroviario en SCOTT

Figura 1: Proyecto SCOTT

en las figuras 1a y 1b (fuente: [48]).La finalidad de este trabajo dentro del proyecto SCOTT es el despliegue de una red de sensoresen el sistema de trenes, de modo que sea posible obtener informacion sobre el estado de losmismos a nivel interno (condiciones del habitaculo) o externo (mediante sensores como LIDARo RADAR, lograr el acoplamiento virtual entre vagones sin necesidad de conexion fısica entreellos). Dicha informacion podra ser procesada in situ o enviada a la nube posteriormente,dependiendo de su naturaleza y de la necesidad conforme a la aplicacion.


Capıtulo 1. Introduccion



2. Estado del arte

Este trabajo se enmarca dentro del contexto del Internet of Things (IoT). Al ser un ambitotan amplio, antes de hablar del caso particular de la aplicacion en la que se desarrolla el trabajose va a resumir el contexto en el que se desenvuelve y las opciones disponibles para dichaaplicacion.

2.1. Internet de las Cosas

Por IoT se entiende cualquier dispositivo, sea este mas o menos complejo, con capacidad deconectarse a otros dispositivos. La principal caracterıstica del IoT es que se ha pasado de una redque conecta principalmente personas a una red que conecta dispositivos. En el enfoque clasicode Internet, la fuente de estımulos que motiva las comunicaciones es una persona detras de suordenador. En el enfoque de IoT, esta fuente de estımulos se amplıa, pudiendo ser cualquiercosa: desde esa misma persona con su ordenador a un sensor en mitad del desierto.Desde el punto de vista de la infraestructura, en la literatura se tiende a distinguir de formatradicional entre tres zonas en el IoT, segun se encuentre mas lejos de aquello que genera losdatos: Edge, Fog y Cloud. En la figura 2 (fuente: [11]) se puede ver el esquema clasico quemuestra las tres capas.

Figura 2: El esquema tradicional de capas en IoT

El Edge es la capa en contacto con la fuente de estımulos a medir. Por lo general sondispositivos pequenos, de potencia reducida y proposito muy especıfico, dedicados a unatarea (por ejemplo, medir las condiciones de un aula y transmitirlas a otro nodo encargadode procesar la informacion). Suelen desplegarse en gran numero respecto a los elementosen las otras dos capas.

La Fog es el elemento intermedio en el IoT. Son dispositivos mas potentes que los nodosde las WSN, que hacen de nexo de union entre la mirıada de dispositivos del Edge y el


Capıtulo 2. Estado del arte

resto del mundo (la nube). Por lo general su funcion es conectar las dos capas extremasentre sı, haciendo normalmente un cierto procesamiento de la informacion para facilitarsu transmision.

La nube (Cloud) tal vez sea el termino mas conocido para el publico. La nube se componede numerosos servidores, agrupados en grandes centros de datos, con una gran capacidadde computacion. Es la capa mas alejada de la fuente de estımulos, con el menor numerode dispositivos pero con la mayor potencia de procesamiento.

Sobre este esquema basico hay variantes en la concepcion de la arquitectura y en la nomencla-tura, dependiendo del autor. Hoy en dıa se habla del Extreme Edge [14] como la capa lımitedel Edge, siendo un subconjunto de este. Algunos autores hablan de la capa lımite del Edgecomo un concepto independiente, separando los dispositivos IoT con mayores capacidades deaquellos dispositivos de reducido tamano, de ultra bajo consumo o consumo nulo, autoabas-tecidos mediante energy harvesting, y a los que se refieren como Smart Dust. Otros autoresle dan el nombre de Mist a esta capa inferior del Edge. El uso de un termino u otro ha idoevolucionando con el paso de los anos con las variaciones de popularidad en la literatura y laprensa especializada. Estos cambios de nombre responden mas a una cuestion de moda entrela comunidad y a la necesidad de ofrecer una imagen de tecnologıa puntera y novedosa de caraal publico que a una diferencia real entre los terminos. En el fondo, el Extreme Edge englobatodos estos conceptos y es la opcion mas aceptada.A la par con la evolucion y las modas antes mencionadas, tambien ha ido evolucionando el focode atencion en cuanto al lugar donde se procesa la informacion. Desde el planteamiento originalen el que el Edge capta los datos, la Fog los transmite y la nube los procesa, los anos y lasnuevas tecnologıas han impuesto una serie de cambios.Al principio, cuando el IoT era algo todavıa por desarrollar, los nodos router del Fog y losservidores de la nube eran capaces de procesar el flujo de informacion. Conforme el numerode Smart Things ha ido aumentando, la cantidad de datos generados es mucho mayor. Ramascomo el Big Data estan en auge por este mismo motivo. A dıa de hoy, la nube todavıa es capazde absorber toda esta carga computacional pero, dado el crecimiento exponencial del numerode dispositivos IoT (se puede apreciar en la figura 3, fuente: [18]), es incierto hasta cuandoseguira ası. Al tener cada vez mas datos que mover y procesar, se preve que llegue el momentoen el que no se pueda soportar un flujo tan grande de datos “crudos”. Por ello, se esta viendola evolucion hacia modelos de Fog Computing donde la computacion no recae solo en la nube,sino que los dispositivos Fog tambien soportan una parte de la carga.Por otra parte, y compartiendo en cierto modo el mismo objetivo de offloading de la nube, la

evolucion de los dispositivos del Edge hacia procesadores mas potentes, con mayor memoria ycapacidades de computo muy superiores a las de hace escasos anos, ha llevado al mundo del IoThacia la posibilidad del Edge Computing, esto es, que sean los propios nodos del nivel inferiorlos que no solo se limiten capturar los datos, sino que los procesen por sı mismos en mayor omenor medida y envıen los resultados ya procesados hacia las capas superiores.Por supuesto, ninguna de estas soluciones es radical, nada es blanco o negro. El desarrollo realdel IoT es un espectro con todo tipo de combinaciones posibles entre lo anteriormente mencio-nado. Desde el punto de vista de las tecnologıas empleadas, el mundo del IoT esta en constanteavance en estos dıas, extendiendose principalmente en 5 direcciones [45]:

RFID: esta tecnologıa se basa en el uso de radiofrecuencias para transmitir datos. Lasfrecuencias de funcionamiento y los modos de emparejamiento entre dispositivos varıandesde los 125 kHz hasta los 5.8 GHz, distinguiendo entre LF, HF, UHF y SHF (baja, alta,ultra alta y super alta frecuencia).

IEEE 802.11: la tecnologıa WiFi que se utiliza a diario.



Figura 3: Numero de dispositivos IoT conectados y prevision 2015-2025

Codigos de barras y codigos QR: una forma de comprimir informacion y hacerla accesible.Entre sus usos destacan publicidad, pagos por movil, realidad aumentada o control deaccesos. Aunque su principal falla actualmente es la seguridad, se esta mejorando en esteaspecto e incluso se han propuesto soluciones de seguridad y sistemas de autenticacionbasados en QR [21]

Bluetooth (IEEE 802.15.1) y su variante de bajo consumo, Bluetooth Low Energy (BLE).Esta ultima esta cobrando fuerza ultimamente en aplicaciones donde el consumo debe serel mınimo posible debido a limitaciones del dispositivo. El protocolo Bluetooth opera enla banda ISM (Industrial, Scientifical and Medical) de 2.4 GHz.

IEEE 802.15.4: es la base de protocolos como Zigbee, ISA100.11a, WirelessHART, 6LoW-PAN, MiWI o Thread [19]. El estandar IEEE 802.15.4 proporciona un marco sobre el quepoder basarse y desarrollar. Con banda estandar a 2.45 GHz a nivel mundial y variantesen Europa (868 MHz) y EEUU (915 MHz), el IEEE 802.15.4 define la capa fısica y deacceso a medio (parte de la capa de enlace de datos) de las LR-WPAN (redes inalambricasde area personal de baja transmision de datos, Low Rate WPAN), existiendo diferentesalternativas para la implementacion de las capas superiores del modelo OSI, que se puedenapreciar en la figura 4.

2.2. El modelo de comunicaciones

El modelo OSI (Open System Interconnection) de capas de la figura 4 (fuente: [49]) es elmodelo de comunicaciones mas empleado. Engloba todas las capas desde el nivel fısico hasta laaplicacion que maneja el usuario final en su dispositivo. Mas adelante se vera una version deeste modelo aplicada al caso particular de IoT, comparando este caso con el de un PC conectadoa Internet por la red WiFi que se encuentra hoy en dıa en cualquier hogar.En el modelo OSI se distinguen 7 capas diferentes, aunque a menudo los protocolos se utilizan



Figura 4: El modelo de capas OSI

de forma conjunta y esta separacion se vuelve algo difusa, como en el caso de TCP/IP, o unprotocolo creado para una cierta funcion abarca mas de una capa por sı solo, incluyendo otrossub-protocolos asociados, como ContikiMAC [9] (el stack que implementa Contiki) en el quetambien hay parte dedicada al control de la radio, que deberıa ser algo propio de la capa fısica.En un caso general, estas capas son:

Fısica: dependiente de la propia estructura fısica de lo que se utilice para la comunicacion.Ej. cable (Ethernet, IEEE 802.3), Wi-Fi (WLAN, IEEE 802.11), radio (WPAN, IEEE802.15), etc.

Enlace de datos: permite establecer una conexion entre dos nodos conectados directamentea nivel fısico. Tambien permite controlar como sera el flujo de datos entre ambos. Incluyedos subcapas:

• Capa de acceso al medio (MAC): controla el uso del medio compartido y el derechoa transmitir en cada momento.

• Capa de control de enlace logico (LLC): responsable de comprobar errores en el envıoa nivel fısico, sincronizacion, etc.

Un ejemplo de protocolo de esta capa es Ethernet o el Point-to-Point Protocol (PPP).

Red: permite conectar redes diferentes, de modo que nodos pertenecientes a distintasredes puedan comunicarse entre sı. El protocolo mas utilizado es el Internet Protocol, IP.Antiguamente se utilizaba IPv4, pero dado que el numero de direcciones disponibles (232,poco mas de 4 billones) se estaba agotando rapido, se paso a IPv6. Con IPv6 el numerode direcciones disponibles es de 2128 (340.28 sextillones).



Transporte: aquı es donde se asegura la recepcion del mensaje, en las capas anteriores nohabıa forma de asegurar la fiabilidad de la conexion de extremo a extremo. A los protocolosque se centran en asegurar la fiabilidad de la conexion se les dice orientados a la conexion(connection-oriented), existiendo tambien protocolos “sin conexion” (connectionless). Demanera muy resumida, un ejemplo de la utilidad del primero serıa una conexion 1 a 1,mientras que el segundo resultarıa mas adecuado para transmitir a multiples receptores.Ejemplos de esta capa son el Transmission Control Protocol (TCP, connection-oriented)o el User Datagram Protocol (UDP, connectionless).

Sesion: permite mantener virtualmente la conexion entre dos nodos a lo largo de variasconexiones reales, manteniendo ası un dialogo entre ellos (una sesion).

Presentacion: es una capa de formato. Permite que las capas inferiores puedan transmitirdatos de forma generica, independientemente de la aplicacion. Es la que se encarga detraducir datos que la red puede transmitir a datos que la aplicacion puede mostrar alusuario, y viceversa. Tambien recibe el nombre de capa de sintaxis.

Aplicacion: la capa mas cercana al usuario final. El usuario interactua con la aplicacionsoftware correspondiente, y dicha aplicacion interactua con esta capa para las comunica-ciones.

El concepto de capas en el modelo es literal, ya que se va encapsulando realmente el mensaje (lacarga) que se desea enviar de forma sucesiva, anadiendo en cada paso un nuevo encabezado almensaje y pasando a ser este conjunto la nueva carga para la capa inferior. Al recibir el mensaje,se realiza el mismo procedimiento en orden inverso: cada capa va leyendo la informacion de suencabezado y pasando su carga a la capa superior.En el contexto de IoT, los nodos tienen recursos limitados y se encuentran en un entorno ruidosoy muy alejado de lo idoneo desde el punto de vista de las comunicaciones. Esto implica que no sepodra asegurar a ciencia cierta si un mensaje llegara a su destino, teniendo lo que se denominauna LLN (Low power, Lossy Network). En las capas mas bajas (fısica, enlace de datos y red) nose asegura la fiabilidad de la conexion extremo a extremo, mas alla de la comprobacion en cadasalto a nivel de capa de enlace de datos, quedando esta tarea en la capa de transporte. Unacomparativa entre el modelo de capas OSI generico utilizado en Internet y el modelo especıficoempleado comunmente en IoT puede verse en la figura 5 (fuente: [29]).

Por esto, un protocolo de transporte ampliamente empleado para aplicaciones IoT es UDP,ya que no requiere confirmacion de la llegada del paquete por parte del receptor. El uso deprotocolos connection-oriented como TCP llevarıa a tener el doble de mensajes en una red depor sı poco fiable, sobrecongestionando la red y consumiendo recursos de una forma facilmenteevitable. El ejemplo de la figura muestra el uso del Constrained Application Protocol (CoAP)en la capa de aplicacion, pero realmente podrıa utilizarse cualquier protocolo ligero enfocadoa sistemas con recursos limitados. Otro ejemplo serıa el protocolo MQTT (Message QueueingTelemetry Transport), un protocolo sencillo de publicacion de mensajes cliente-servidor.En una gran cantidad de aplicaciones en el ambito de IoT y, en concreto, en el caso tratadoen este trabajo, los protocolos empleados en cada capa son los que muestra la figura 6 (fuente:[32]). La figura muestra la carga de las capas superiores (aplicacion), a la que se anade elencabezado de UDP, el de IPv6 y el de 6LoWPAN. La capa MAC no solo anade un encabezadoa su carga sino que tambien anade un final de mensaje (footer), que contiene la informacionpara el chequeo de redundancia (CRC). Con esto se asegura que la transmision del paquete nodoa nodo es correcta, al poder efectuar la comprobacion del CRC que se calcula en la recepcioncontra el CRC del mensaje. Si no coinciden, la trama se considera incorrecta y se descarta.



Figura 5: Comparativa modelo OSI convencional y aplicado a IoT

2.3. Capa fısica: IEEE 802.15.4

Como se menciono anteriormente, el estandar IEEE 802.15.4 [17] define la capa fısica y lacapa de acceso al medio. Se utilizara en este trabajo la banda de frecuencias de 2400-2483.5MHz, que es la banda estandar a nivel internacional, teniendo hasta 16 canales definidos en estafranja. Para el envıo de mensajes se utiliza la modulacion O-QPSK: Offset-Quadrature PhaseShift Keying, modulacion por desplazamiento de fase en cuadratura, cuadrafasica o cuaternaria,con offset o desplazamiento.La modulacion consiste en una senal portadora usada como base sobre la que se impone otra,la senal moduladora, que contiene la informacion a transmitir. De la alteracion de la senalportadora por el efecto de los datos que se desea transmitir se obtiene la senal modulada, quees la que posteriormente es enviada.La modulacion en fase (PSK, figura 7, fuente: [30]) se basa en utilizar la fase de la senal, y no

su amplitud (ASK) o su frecuencia (FSK), para transmitir la informacion. En funcion del tipode senal moduladora utilizada, la senal resultante tendra un aspecto u otro. En el caso de lamodulacion por desplazamiento de fase (PSK: Phase Shift Keying), la senal moduladora no escontinua (analogica) sino discreta (digital), de modo que la cantidad de posiciones o estados enlos que se puede encontrar la fase es finita.Es comun representar los estados de la senal como puntos en el plano complejo, en los llamadosdiagramas de constelacion. Estos diagramas funcionan como cualquier plano complejo, siendola distancia al origen el modulo de la senal y el angulo medido desde el eje horizontal hasta larecta que une el origen y el punto su fase. Los ejes se denominan en fase (I) y en cuadratura(Q).Cada estado de la senal, llamado sımbolo de la constelacion, recibe un codigo de bits. Como enQPSK hay cuatro fases, se tendran 4 sımbolos distintos (figura 8, fuente: [8]), pudiendo codificar2 bits de esta forma (00, 01, 11 y 10). Para tratar de minimizar los posibles bits erroneos, escomun emplear codificacion Gray [31], en la que entre un sımbolo y los adyacentes solo cambiaun bit.



Figura 6: El formato de un frame en 6LoWPAN

Figura 7: Modulacion PSK: senales moduladora, portadora y modulada

Al realizar una transmision puede suceder que varios nodos quieran transmitir a la vez. Eneste caso, los mensajes se cruzaran en el medio compartido y se corromperan. Para evitar laperdida del mensaje, el estandar IEEE 802.15.4 recurre al protocolo CSMA-CA (Carrier-SenseMultiple Access with Collision Avoidance). Antes de enviar un mensaje, el nodo “escuchara” elmedio para comprobar si hay alguien transmitiendo en ese momento. Pese a esto, puede darseel caso de varios nodos queriendo transmitir a la vez tras detectar que el medio estaba libre,coincidiendo en el momento del envıo. Al intentar transmitir un mensaje con CSMA-CA, si haymas de un nodo enviando a la vez, todos “retroceden”(backoff ), interrumpiendo la transmisiony esperando a enviar su mensaje mas tarde. Para ello, el algoritmo emplea dos variables, NB(no de backoffs) y BE (backoff exponent). El nodo volvera a intentar transmitir tras un tiempo,esperando un numero N de perıodos de backoff, siendo N un entero generado aleatoriamentey comprendido entre 0 y 2BE-1. Si al volver a intentarlo se encuentra de nuevo con el mismoproblema, volvera a hacer otro backoff y tratara de enviar su mensaje mas tarde, hasta que elnumero de reintentos NB llegue al maximo fijado por el protocolo. Si se alcanza ese maximo ytodavıa no ha podido enviar el mensaje, considera que ha habido un error al acceder al medio.La transmision incluye un perıodo durante el que el emisor pasa a modo recepcion y espera unacknowledgement de vuelta, antes de dar el envıo por finalizado y pasar al siguiente paquete.Para medir la calidad de la transmision, normalmente se utilizan dos indicadores: el RSSI(Received Signal Strength Indicator) y LQI (Link Quality Indicator). El RSSI es una medidaarbitraria, normalmente en los rangos 0-100 o 0-255, y expresa la potencia con la que se recibela senal. Debido a la atenuacion que sufre la senal en el medio y a la potencia de emisionrelativamente baja, resulta evidente que la senal llegara con menor potencia que aquella con la



Figura 8: Constelacion de O-QPSK (codificacion Gray)

que salio. El valor de dBm es un indicador absoluto de la potencia recibida, medida respecto auna potencia de 1 mW, mientras que el RSSI es un ındice relativo y puede variar dependiendode cada dispositivo y como lo decida calcular el fabricante, ası como del rango de valores quedecida emplear. Se pueden medir valores de dBm positivos, debido a algun posible offset o a laforma de medirlo en cada caso, pero normalmente toma valores negativos o 0. Aunque en teorıason conceptos distintos, en la practica se suele terminar mezclando RSSI y dBm como una unicamedida que permite estimar de manera aproximada la potencia de la senal, dando directamentecomo RSSI el valor en dBm y sabiendo que cuanto mas alto es el valor negativo, mayor ha sidola perdida de potencia en la transmision y peor es la senal recibida. Por tanto, cuanto mayorsea el valor obtenido (numero negativo mas cercano a cero, menor en valor absoluto) se tendrauna mejor potencia, siendo un valor de 0 dBm algo ideal e imposible de obtener en la realidad.Un valor de -20 o -30 dBm es muy bueno, -50 dBm es el valor mas normal, -70 dBm es el lımitede lo aceptable y con -90 dBm es practicamente imposible establecer una comunicacion.El LQI mide la calidad y/o fuerza de la senal. Es un valor de 0 a 255 (0x0 a 0xFF), que seobtiene a partir de la medida de energıa detectada por el receptor, de la relacion senal/ruido(SNR, Signal-to-Noise Ratio) o de una combinacion de ambas. Segun el estandar [17], los valoresextremos corresponden a la peor y mejor calidad de senal posibles, y el resto de valores de LQIse distribuye uniformemente en el rango entre ellos, debiendo existir al menos 8 niveles de LQIdiferenciables. De forma resumida, un LQI mayor indica una mejor calidad y fuerza de senal.En cuanto a la informacion que se desea transmitir, el estandar del IEEE 802.15.4 imponeotra restriccion. Al tratarse de un medio lossy, propenso a perdidas y poco fiable, es razonabletener un lımite en la longitud de los paquetes a enviar. Por tanto, existe un tamano maximode los paquetes, o Unidad Maxima de Transmision (MTU), fijado por el estandar. Este tamanomaximo es de 127 bytes. El problema aparece cuando IPv6 obliga a soportar MTUs de al menos1280 bytes, llegando la carga (payload) normalmente hasta los 64 kB, ademas de la posibilidadde transmitir jumbogramas (paquetes jumbo, de gran tamano), que pueden llegar a longitudesde hasta 4 GB menos 1 byte en la carga.

2.4. Fragmentacion con 6LoWPAN

Con esto, surge la necesidad de trocear el paquete a transmitir y enviarlo por partes. Esaquı donde aparecen protocolos de fragmentacion y desfragmentacion, como 6LoWPAN (IPv6over Low-Power Wireless Personal Area Networks). El protocolo 6LoWPAN es un desarollodel IETF (Internet Engineering Task Force), definido originalmente en la RFC 4944 [36], quefue posteriormente actualizada en la RFC 6282 [38] al incluir la compresion de encabezados ycomplementada por la RFC 6775 [41], centrada en el descubrimiento de nodos vecinos, ademasde consideraciones adicionales en la RFC 8025 y la RFC 8066.El paquete se fragmenta en distintos trozos, siendo necesario imponer un orden para poderdesfragmentarlo y recomponerlo en destino. Ademas de esta trazabilidad en los fragmentos,



6LoWPAN presenta otra ventaja en forma de ahorro de espacio: la compresion de encabezados.Las capas que recibe el stack de 6LoWPAN (IPv6 y el protocolo de transporte elegido, porejemplo, UDP) tienen encabezados relativamente grandes y pesados, algo que resulta difıcil demover tal cual si se quiere respetar el tamano lımite impuesto por la capa fısica. Para ello, es ca-paz de comprimir dichos encabezados reduciendo la cantidad de bytes que envıa. Normalmentese utiliza IPHC (IP Header Compression) para los encabezados de IP y su metodo asociado,NHC (Next Header Compression) para los de TCP/UDP. La ventaja de esta compresion, deno-minada stateless, es que es independiente de las circunstancias de la transmision o de factoresexternos al propio paquete: toda la informacion necesaria para descomprimir el encabezadoesta contenida en el propio paquete enviado, y por tanto cada paquete se puede comprimir ydescomprimir de forma independiente sin necesidad de otros paquetes o datos adicionales.En la figura 9 (fuente: [50]) se muestra la potencia de compresion de encabezados que brinda6LoWPAN. En ella se puede ver que campos del encabezado se omiten porque se pueden extraerdel encabezado de la capa de enlace de datos, que campos se omiten porque se sobreentienden yque datos se comprimen y se envıan en forma compacta. Por ejemplo, la version IP es siempre 6ası que se sobreentiende y se omite. Como el uso de 6LoWPAN se limita siempre a una mismared local, muchos parametros van a ser comunes para toda la red, ahorrando espacio al com-primir el encabezado. El tamano del mensaje IP enviado se puede extraer del encabezado de lacapa de enlace de datos, ası como las direcciones IP (128 bits al ser IPv6) de origen y destino,ya que el prefijo de la direccion (64 bits) es el mismo para toda la red y la ID de interfaz (IID,64 bits) se obtiene a partir de la interfaz de red dada por el IEEE 802.15.4 y tambien es unica,identica para toda la red. En el ejemplo de la figura, se pasa de 48 bytes de encabezados IP yUDP a solo 7 bytes, sin perder informacion.

Figura 9: Compresion de encabezados en 6LoWPAN

2.5. El rutado en una red de sensores

Con esto se tiene una idea de como se realiza una transmision nodo a nodo, y de como semaneja el contenido de los paquetes en los mensajes de extremo a extremo. Pero, en una redque engloba varios nodos y tıpicamente con una topologıa semejante a una malla (mesh) o unentramado tipo arbol, es necesario emplear un protocolo para establecer las rutas que deberecorrer un mensaje de extremo a extremo si ambos extremos no son nodos en el alcance de laradio emisora, capaces de un envıo directo. Para el rutado en la LLN se utiliza el protocolo RPL(IPv6 Routing Protocol for Low-power and Lossy Networks), cuya especificacion se encuentra



en la RFC 6550 [39].En contraposicion a protocolos mesh como AODV (Ad hoc On-Demand Distance Vector Rou-ting, utilizado por ejemplo en Zigbee), donde se tiene una verdadera malla sin una orientacionen particular, RPL sigue una estructura de arbol. RPL establece como se van a relacionar entresı los nodos de la red, formando para ello grafos, llamados grafos acıclicos orientados o DODAG(Destination Oriented Directed Acyclic Graph). En una instancia RPL se va a crear una estruc-tura de nodos formando el DODAG, a partir de un nodo raız (root) que hara de coordinadorde la red. De este modo, cada nodo va a obtener un rango en funcion de su relacion con el root.El rango de los nodos se asigna en funcion de la funcion objetivo (OF), que lleva asociadauna metrica utilizada para estimar el coste para acceder a un nodo. De este modo, se pue-de seleccionar una ruta u otra buscando el mınimo coste. El uso de una funcion objetivo uotra dependera de la aplicacion. La funcion objetivo mas empleada es la de mınimo rango conhisteresis (MRHOF, Minimum Rank with Hysteresis Objective Function), definida en la RFC6719 [40] que puede utilizar cualquier metrica que funcione aditivamente (numero de saltos, la-tencia, ETX, etc.). Normalmente se emplea ETX (expected transmission count) como metrica,que se computa como un numero real en punto fijo con un divisor de 128, lo que le confiere unapropiedad curiosa en relacion al incremento mınimo de rango por salto. La RFC 6550 fija unvalor por defecto de 256 para el salto mınimo, siendo este valor por defecto modificable segun lanecesidad. La RFC 6719 aconseja elegir con cuidado este salto mınimo, especialmente cuando seuse ETX como metrica. El stack de RPL de algunos sistemas operativos, como Contiki, empleaun valor de incremento mınimo del salto de 128, de modo que el valor del coste ETX de unaruta desde el nodo root hasta un nodo cualquiera coincidira con el rango de ese nodo.El DODAG se va reconstruyendo de forma dinamica con el paso del tiempo, al anadir o eliminarnodos de la red, reoptimizandose como respuesta a los cambios. Para esto, se crea una nuevaversion del DODAG recalculando los costes de las rutas cuyos nodos hayan sido alterados, y sedesecha la version anterior. Es el nodo root el que ordena esta reparacion global e incrementala version del DODAG. Los demas nodos, al recibir el mensaje con una version superior de suDODAG, ignoran las rutas y costes asociados a la anterior y recalculan para conectarse a lanueva, pudiendo ası cambiar su posicion y rango en la red.De forma resumida, la red se establece y se mantiene mediante tres tipos de mensajes de control,

Figura 10: Intercambio de mensajes de control ICMPv6 en RPL

empleando para ello un subset de mensajes del protocolo ICMPv6 (Internet Control MessageProtocol for IPv6 ). El Objeto de Informacion del DODAG (DIO) es el mensaje que contiene lainformacion del DODAG, un miembro de la misma (el root o un nodo unido a la red) lo enviara



para compartir los datos del DODAG y permitir a otros nodos unirse, bien tras una solicitud obien de forma periodica. Un nodo puede solicitar esta informacion por su cuenta, pidiendo unDIO por parte de los nodos pertenecientes a la red. Esto se hace con una Solicitud de Infor-macion del DODAG (DIS). El tercer tipo de mensaje, el Objeto de Actualizacion de Destino(DAO), lo envıan los nodos en sentido ascendente (hacia el root) para poder tener informacionactualizada sobre sus nodos padre. Cada nodo conoce la ruta ascendente a su nodo padre, perola ruta descedente a sus hijos puede no ser conocida por cada nodo padre, quedando la tareade conocer las rutas descendentes en manos del root. Dependiendo de si se utiliza RPL en elModo de OPeracion (MOP) de almacenamiento o no-almacenamiento (Storing o non-Storing,segun los nodos guarden la informacion de sus nodos hijos o no), enviaran el DAO a su nodopadre o al root, respectivamente. Opcionalmente, puede darse un cuarto tipo de mensaje, elacknowledgement en respuesta a un DAO recibido (DAO-ACK). Estos mensajes de control sepueden ver en el esquema de la figura 10 (fuente: [15]).Como se puede entender a la vista del funcionamiento de la red y su mantenimiento, se puedegenerar una cantidad considerable de trafico en el medio. Para tratar de reducir dicho trafi-co, mejorar la robustez del sistema y reducir el consumo de energıa, RPL utiliza el algoritmoTrickle, detallado en la RFC 6206 [37]. Este algoritmo nos permite ajustar las ventanas detransmision de forma dinamica, dependiendo de la congestion del medio. De este modo, si nohay apenas cambios en la red y, por tanto, la informacion de la misma practicamente no varıa,no sera necesario enviar muchos mensajes dedicados al mantenimiento y actualizacion de lared. En este caso, el algoritmo hara que la frecuencia de envıo de dichos mensajes se reduzca,espaciando mas los envıos.

2.6. Uso de JSON y MQTT

Como se detallo en la introduccion (seccion 1), este trabajo se enmarca dentro del proyectoSCOTT. Ademas de la validacion de la plataforma y del porting del sistema operativo descritosen las secciones 3 y 4, y las pruebas de caracterizacion de la seccion 5, la plataforma se emplearapara una aplicacion en particular: la toma de medidas del interior del tren, su procesado y envıoa la nube. Esto ya se vera en mayor detalle en las pruebas (apartado 5.3), y aquı solo se detallarael marco teorico de los formatos y protocolos utilizados: JSON [42] y MQTT [20].JSON (JavaScript Object Notation) es un formato de texto para el envıo de informacion. Comosu propio nombre indica, nacio como un componente mas de JavaScript, aunque al extendersesu uso de forma global paso a utilizarse simplemente como formato de texto independiente, sinasociarse a ningun lenguaje en particular. De hecho, la especificacion de JSON admite ciertoscaracteres que JavaScript no permite. A menudo se anuncia como la alternativa a XML de bajooverhead. Entre sus ventajas destacan que es facil de leer y escribir para las personas y es facilde analizar para las maquinas. Utiliza convenciones tıpicas de los lenguajes de programacionC/C++ y aquellos derivados o inspirados en ellos, lo que hace mas sencillo su uso. JSON sebasa en un modelo clave - valor, donde cada clave es un identificador unico. JSON distinguedos tipos de estructuras tıpicas:

Una pareja nombre - valor (o un conjunto de parejas). JSON llama a esto objetos.

Una lista ordenada de valores. JSON llama a esto arrays.

Este tipo de estructuras es universal y cualquier lenguaje de programacion las soporta, llamando-las de una u otra forma. Por esto, es sencillo transformar cualquier elemento de esos lenguajesa JSON o viceversa, para transmitir los datos en un formato que no dependa de un lenguajeconcreto sino que sea comun para todos. Este paso de transformacion de elementos estandardel lenguaje que sea a formato serie (JSON o cualquier otro) se llama serializacion, y el pasode convertir un JSON a otro formato distinto se denomina deserializacion.Por otro lado, MQTT es un protocolo de transporte de mensajes simple, ligero y orientado a



sensores o pequenos dispositivos moviles. Segun los propios desarrolladores, es un protocolo deconexion M2M (machine-to-machine) para IoT. Las aplicaciones MQTT son ligeras, con uncodigo muy reducido, y se basan en un modelo de publicacion - suscripcion. Los nodos, biengeneradores de datos o clientes que requeriran esos datos, se conectan a un nodo central llama-do broker, que hace las veces de servidor. Para ello, los nodos pueden publicar mensajes en untema o topic, o suscribirse a los topics que necesiten para estar al tanto de los nuevos mensajespublicados.Estos topics tienen una estructura jerarquica, pudiendo tener distintos sub-topics anidados den-tro de un topic de nivel superior, mas generico. Por ejemplo, si todas las luces de la casa estan enel topic casa/luces/, las de la terraza de la cocina podrıan estar en casa/luces/cocina/terraza.De este modo, un cliente podrıa suscribirse a la informacion de la luz de la terraza, de la cocinaentera o a todas las luces de la casa.MQTT incluye dos operadores, + y #, que sustituyen un nivel (o mas) de la jerarquıa. De estemodo, suscribirse a casa/luces/+/terraza darıa al nodo acceso a las publicaciones en cualquiertopic dentro de la casa/luces que tenga un subnivel llamado terraza, por ejemplo, si hay unaterraza en el salon (casa/luces/salon/terraza) y otra en la cocina (casa/luces/cocina/terraza)serıa capaz de ver las publicaciones correspondientes a las dos. Y el caso casa/luces/# le darıaacceso a todo lo que cuelgue de casa/luces, incluyendo cualquier numero de subniveles de topics.

Figura 11: Algoritmo de obtencion de CRC mediante anexion de ceros

Como parte de la necesidad de asegurar la fiabilidad de las transmisiones entre el clienteMQTT y el broker, se calcula tanto en el envıo como en la recepcion el CRC (Cyclic RedundancyCheck) del mensaje. El CRC se verifica comparando el valor calculado a partir la carga delmensaje en el lado del emisor antes de ser enviado con el obtenido en el lado del receptor a



partir de los datos recibidos, aceptando o rechazando el mensaje. Para ello, se utiliza el llamadoCRC-32, uno de los tipos mas usados de CRC, empleado por ejemplo en Ethernet (IEEE 802.3).Se pueden calcular multiples codigos CRC para un mismo mensaje. Por ejemplo, en mensajescuya carga consista en varios bloques que despues deban ser procesados, como podrıa ser el casode nodos que agrupen la informacion medida por varios sensores y la envıen de forma conjunta.En este ejemplo, es importante tanto la integridad del mensaje entero como de cada uno de loscampos, pudiendo ası detectar donde se ha dado la perdida de informacion.El empleo de CRC para la verificacion de mensajes esta muy extendido como metodo para lasuma de verificacion (checksum) frente a otros metodos existentes debido a que es muy facil deimplementar en hardware, ya que se basa en operaciones sobre el mensaje a nivel de bits, y esmuy eficaz para detectar errores en la transmision, debidos al ruido o a perdidas de senal. Suinvencion data de 1961, siendo el CRC-32 del ano 1975. Se llama verificacion de redundanciacıclica porque lo que se genera es informacion redundante del propio mensaje, y su algoritmo sebasa en ciclos (desplazamientos circulares del codigo). El uso de CRC solo verifica la integridaddel mensaje, no que sea correcto o no.Un CRC-n (de n bits) se llama ası porque se obtiene a partir de un polinomio (llamado polinomiogenerador) de grado n, teniendo n+1 terminos. Es decir, para codificarlo se utilizaran n+1 bits.Un ejemplo es el bit de paridad, que no deja de ser un CRC-1. El algoritmo de obtencion delCRC se basa en divisiones, desplazamientos y OR exlusivo (XOR) de bits para negar bit a bit,y puede encontrarse en la literatura [23, 13] o mediante una simple busqueda [47] en Internet.En el caso del CRC-32, el polinomio generador es 100 1100 0001 0001 1101 1011 0111, o como seve mas comunmente en hexadecimal, 0x04C11DB7. Existen herramientas online para calcularel CRC y poder comprobar los resultados obtenidos, y muchos lenguajes de programacionincluyen de serie funciones para calcular automaticamente el CRC, como es el caso de crc32()perteneciente al modulo binascii de Python. El metodo mas utilizado para la generacion deCRC es mediante anexion de ceros, algoritmo que puede verse en la figura 11 (fuente: [7]).





3. La plataforma Cookie

Como se ha mencionado en la seccion 1, la idea general detras de este trabajo es el desplie-gue de una red de sensores inalambrica en la infraestructura de la red ferroviaria. Para estafinalidad, se decidio disenar directamente los nodos que conformarıan dicha red en lugar deoptar por el uso de nodos comerciales disponibles en el mercado.Este diseno de la plataforma fue realizado como parte de un trabajo anterior en el CEI a partirde componentes comerciales desplegados sobre una PCB, y el primer objetivo de este trabajoconsiste en la verificacion y validacion del funcionamiento de dicha plataforma, partiendo paraello de la validacion del correcto funcionamiento de cada componente, tanto a nivel fısico (com-probar que el componente este bien montado y no sea defectuoso) como a nivel de funcionalidad(si el circuito disenado no tiene errores y realmente realiza su funcion en la plataforma).El nombre que se le dio a la plataforma (ver figura 12) es Cookie Node o simplemente Cookie,nombre generico que suelen recibir las placas desarrolladas en el centro. Este modelo en concretoha sido bautizado como Cookieboard.

Figura 12: La plataforma Cookieboard

3.1. La plataforma

El diseno de la placa esta inspirado en un modelo comercial de Silicon Labs, la ThunderboardSense 2, que se ha tomado como referencia y con la que comparte algunas caracterısticas. Sediferencia de esta en que la Cookie solo posee los dos sensores mencionados mas adelante, mien-tras que la Sense 2 viene equipada con mas sensores: intensidad lumınica, presion barometrica,etc. Ademas de eso, la Cookie esta equipada con una serie de extras que la Sense 2 no tiene,como el criptochip o los medidores de consumo.La placa incluye:

Un microprocesador EFR32MG12P432F1024GL125 de Silicon Labs. Los EFR32 son unafamilia de microprocesadores ARM de 32 bits bastante empleados en redes de sensoresinalambricas.

Un sensor de temperatura y humedad relativa si7021. La comunicacion entre el procesadory el sensor se realiza a traves de I2C.

Una unidad de medida inercial (IMU) con un sensor inercial icm20648, que realiza fun-ciones de acelerometro y giroscopio. La comunicacion entre el procesador y el sensor se


Capıtulo 3. La plataforma Cookie

realiza mediante SPI.

Un chip de encriptacion ATECC508A de Microchip, encargado de almacenar la clave deencriptado privada en su interior. El microprocesador se comunica con este criptochipmediante I2C.

Un cabezal J-Link EDU Mini, utilizado para depurar y cargar codigo en la Cookie a travesde una placa de depuracion de Silicon Labs. Los datos recibidos entran al procesador atraves del puerto UART.

Un controlador puente USB-to-UART USBXpress CP2102N de Silicon Labs que poseeambas interfaces, y transforma los datos recibidos desde el exterior a traves del puerto USBtipo C a datos que envıa por el UART, el mismo que conecta al cabezal de depuracion.Este elemento es otra de las diferencias respecto a la Thunderboard.

Un circuito detector de carga por USB, capaz de distinguir si se alimenta la Cookiedirectamente por USB o si se hace desde una baterıa o a traves del debugger. Conecta conla senal USB PGOOD en el pin PC6 del procesador, que se puede ver en la figura 14.

Un ADC de 12 bits de resolucion conectado a los amplificadores operacionales del circuitode medida de consumo, capaz tambien de gestionar entradas analogicas.

Un circuito de medida de consumo del microprocesador y otro de los sensores, con un parde amplificadores operacionales conectados al ADC.

Un set de power switches con los que poder controlar via software la alimentacion de lossensores, del medidor de consumo y del chip de encriptacion de forma independiente.

La figura 13 muestra un esquema a nivel funcional de los elementos mencionados arriba. Ladisposicion de los mismos en el esquema es, a grandes rasgos, parecida a la disposicion real enel layout de la placa.

Figura 13: Esquema funcional de la Cookieboard

Como menciona Hyung Sin-Kim en [22], la tendencia en el diseno de nodos inalambricosha evolucionado desde procesadores mas sencillos a sistemas en chip (System on Chip, SoC),bloques que integran un procesador potente, el chip de radio con su coprocesador y otros dispo-sitivos auxiliares en un unico modulo unificado. El EFR32 [26] es uno de estos SoC, integra unmicroprocesador de 32 bits a 38.4 MHz, 1024 kB de Flash, 256 kB de RAM y 65 E/S digitales,ası como un chip de radio IEEE 802.15.4 preparado para bandas de 2.4 GHz y sub-GHz.



A la hora del diseno del circuito alrededor del microprocesador, se intento mantener el pinoutoriginal de la Thunderboard en la medida de lo posible para los elementos comunes a ambasplataformas, facilitando de este modo el diseno de la placa, ası como el porting de software a lamisma y minimizando los cambios en la configuracion de hardware. De este modo, parte de laAPI original de Silicon Labs para su plataforma pudo ser importada para su uso en la Cookiecon la mınima cantidad de alteraciones. Esto serıa la base sobre la que se trabajarıa en paralelopara realizar el porting de Contiki-NG a la plataforma, que es una parte fundamental de esteTrabajo de Fin de Master.Como ya se ha comentado, debido a la semejanza entre la Cookie y la Thunderboard a nivel depinout, los cambios en este aspecto han sido minimizados en la medida de lo posible respecto alport original de Joakim Eriksson [12]. Los principales cambios en este sentido han correspondidoa la reubicacion de puertos dedicados a perifericos que la Cookie no posee, y su adaptacion paraeste caso.Para tener una idea aproximada se puede tomar como punto de partida el pinout del EFR32

Figura 14: Pinout de las E/S del EFR32 en la Cookie



en la Thunderboard Sense 2 y modificar a partir de el. Solo se conservara de forma ıntegra lospuertos que se aprecian en la parte superior (puertos A y F), dedicados a la interfaz con eldebugger, a la conexion UART y a las distintas senales de habilitacion, las cuales controlaranen este caso los power switches en la Cookie. Del resto se aprovechara la conexion SPI (PK0,1 y 2, y PF7), que se utilizara para comunicarse con el sensor inercial, y el I2C0 (PC10 y 11),para acceder al sensor termico y al chip de encriptacion, ası como los pines sueltos dedicadosal PTI y al oscilador de cristal de baja frecuencia para la senal de reloj. El pinout del EFR32en el esquematico de la Cookie puede verse en la figura 14.Este pinout se refleja en el codigo en toda una serie de definiciones de macros asociadas, reco-

(a) bspconfig.h (1/2)

(b) bspconfig.h (2/2)

Figura 15: Pinout del EFR32 en la Cookie traducido a codigo (bspconfig.h)

pilada en los archivos bspconfig.h (figuras 15a y 15b) y hal-config-board.h (figuras 16a y 16b),ademas de modificaciones menores en archivos como hal-config.h que no han sido incluidas enla memoria. Se ha reducido la inclusion de codigo en la medida de posible, intentando incluirsolo las partes en las que haya habido una modificacion directa o hayan sido escritas desde cero,y se consideren de relevancia para el objetivo del trabajo.El resto de pines pueden ser utilizados para depurar senales internas desde fuera, conectandose



(a) hal-config-board.h (1/2)

(b) hal-config-board.h (2/2)

Figura 16: Pinout del EFR32 en la Cookie traducido a codigo (hal-config-board.h)

mediante los conectores verticales a ambos extremos de la Cookie con una placa de depuracionque exponga estos pines al exterior, o bien para unirse a otros modulos compatibles. Esta mo-dularidad es algo inherente a todas las Cookies desarrolladas en el CEI, pudiendo ensamblardiversas placas una sobre otra y comunicandose mediante estos conectores verticales. Estos co-nectores se pueden ver en la figura 12 y en el esquema de la figura 13, en la seccion anterior.En las figuras 15 y 16 se puede apreciar la configuracion del pinout de los diferentes modu-los del EFR32 en la plataforma, como la unidad de medida inercial (referida en el codigocomo IMU, y los pines del SPI), las diferentes senales de habilitacion (PCOM ENABLE,TEMP ENABLE, IMU ENABLE y CRYP ENABLE), la ubicacion del USART0, el puertoanalogico (BOARD APORT1) desde el que el medidor de consumo leera las tensiones, losLEDs (GPIO LED0 y GPIO LED1), el cristal oscilador externo de baja frecuencia (LFXTAL Py LFXTAL N) o los pines habilitados para recibir las interrupciones externas provenientes dela unidad de medida inercial (EXTI IMU INT1 y EXTI IMU INT2).Con estos cambios ya es posible utilizar la API de Silicon Labs, Simplicity Studio, y programardirectamente la Cookieboard en bare metal. De hecho, las pruebas de validacion de la seccion3.2 se realizaron de esta manera, operando directamente a bajo nivel sobre la placa.Aparte de la adaptacion del pinout, se tuvo que realizar una serie de modificaciones para poderutilizar la API de Silicon Labs en la plataforma. Un ejemplo son los ficheros board cookie.h



(figura 18) y board cookie.c (figuras 17, 19, 20 y 21). Estas figuras muestran las funciones deinicializacion de la placa y de manejo de los perifericos de la Cookie, en la capa de softwarede nivel intermedio entre la capa que interactua directamente a bajo nivel con los pines delprocesador y la capa de funciones de alto nivel.

Figura 17: Funcion de inicializacion BOARD init, en board cookie.c

La funcion BOARD init() inicializa la placa, establece que pines seran entradas o salidas yhabilita el reloj de las E/S. En diversos proyectos, el codigo de inicializacion siempre acabarallamando a esta funcion en algun momento.Las funciones BOARD imuEnable(bool) y BOARD TempEnable(bool) habilitan o deshabilitanlos dos sensores, actuando sobre la senal de habilitacion correspondiente en cada caso y confi-gurando o apagando los pines del I2C en el caso del sensor termico.



Figura 18: Board cookie.h

Figura 19: Funciones de board cookie.c (1/3)

Por ultimo, el handler generico de interrupciones ha sido modificado de forma que respondaa los dos pines de entrada de interrupcion del sensor inercial, llamando a la funcion callbackespecıfica que corresponda en cada caso. Esto lleva a tener tambien funciones de inicializaciony limpieza de ambas interrupciones (Set y Clear).







3.2. Pruebas de validacion del Hardware

En esta seccion se va a detallar la serie de pruebas realizadas sobre la plataforma, ası comolos resultados de las mismas o las mediciones que se han llevado a cabo.

3.2.1. Alimentacion

La primera prueba realizada sobre las placas fue conectarlas a la alimentacion y comprobar elcorrecto funcionamiento del circuito de alimentacion. En este sentido, existen tres alternativas:

Alimentacion a traves de un debugger externo (1).



Alimentacion directa mediante el USB tipo C (2).

Alimentacion desde baterıa (3).

Esta primera toma de contacto, pese a su sencillez, es realmente importante, ya que al recibir lasplacas desde el fabricante no se tenıa una certeza absoluta sobre los posibles fallos en el disenodel circuito, pudiendo quemar directamente la placa en el peor de los casos. En la figura 22a sepuede apreciar cada tipo de alimentacion por cable, y en la 22b el conector para la baterıa asıcomo una de las baterıas utilizadas.Para alimentar la placa, cargar el codigo de las aplicaciones desarrolladas en el procesador

(a) Vista superior

(b) Vista inferior

Figura 22: Metodos de alimentacion de la Cookie

y depurar durante las pruebas se empleo un kit de desarrollo de Silicon Labs, que incluye unprocesador EFM32PG12 Pearl Gecko, junto con el adaptador de depuracion que le ofrece unasalida J-Link EDU Mini con la que conectarse a la Cookie. La disposicion de nuetro banco depruebas es la mostrada en la figura 23. El kit de desarrollo se conecta al ordenador medianteUSB, haciendo de intermediario entre este y la placa. Antes de probar ningun software sobrela placa es necesario configurar la placa de desarrollo para que se limite a actuar como puenteentre el ordenador y la Cookie, de modo que al cargar un binario desde la herramienta softwareno se dirija al EFM32PG12 sino al EFR32 de la placa.La herramienta software empleada para las pruebas es el entorno de desarrollo de Silicon Labs,

Simplicity Studio, en su ultima version disponible. Conectando la placa de desarrollo medianteel USB, el entorno la reconoce automaticamente (ver figura 24a), mostrando la configuracionactual y las opciones disponibles para la misma. En las opciones se puede configurar el micro-procesador en uno de estos modos: MCU, si se pretende cargar codigo directamente al PearlGecko del kit de desarrollo, o OUT, si debe limitarse a un comportamiento pasivo y actuarcomo puente entre el entorno de desarrollo y lo que se conecte al otro lado del conector Mini.Es este ultimo modo el que se elegira, y al conectar la Cookie al kit de desarrollo la herramienta



Figura 23: Setup del banco de pruebas

mostrara que un procesador EFR32 ha sido conectado. En la pantalla del kit de desarrollo enla figura 23 se puede leer que se encuentra en el modo “Debug Mode: OUT”mencionado.Una vez comprobada la alimentacion y configurado el entorno de trabajo, el siguiente paso fue

(a) Deteccion automatica del adaptador conectado

(b) Opciones de configuracion

Figura 24: Herramienta Simplicity Studio

probar el correcto funcionamiento del microprocesador, adquiriendo de paso una mayor fami-liaridad con la estructura del codigo y las funciones del EFR32. Esta prueba fue simplementeactuar directamente sobre los pines de los LEDs usando un temporizador. De este modo seprobo tanto el acceso directo a pines de E/S a bajo nivel como las funciones de la API paramanejar los LEDs desde un nivel superior de abstraccion, ası como el manejo del temporizadorpor parte del procesador, la habilitacion de relojes desde el oscilador (cristal externo al EFR32)y los divisores de frecuencias asociados.Una vez cargado el codigo en la placa a traves del debugger, puede alimentarse por el metodoque se prefiera. Con el UART mapeado y configurado correctamente en el codigo se puedenver los mensajes de depuracion que genera la Cookie a traves el USB a la vez que la alimenta,necesitando simplemente un terminal para establecer una conexion con la placa y poder leerlos.De este modo, aunque la depuracion paso a paso no este disponible por esta vıa todavıa esposible depurar el codigo cargado mediante mensajes y sin necesidad de usar Simplicity Studio,si por ejemplo se esta utilizando para cargar otra Cookie, o si se esta utilizando Contiki desdeuna maquina virtual, como se vera en la seccion 4.



3.2.2. Sensor de temperatura

Una vez demostrado que el procesador funcionaba correctamente, se paso a comprobar elsensor de temperatura y humedad relativa si7021, validando de este modo su funcionamientomediante ordenes al sensor a traves de escrituras y lecturas sobre sus registros usando el pro-tocolo I2C (Inter-Integrated Circuit Protocol). La conexion I2C utiliza solo dos cables, siendode las opciones mas sencillas disponibles desde el punto de vista del hardware. La carga decomplejidad por tanto se traspasa al software, ya que el protocolo para enviar mensajes algomas complejo que el empleado en SPI o en comunicacion directa por UART asıncrono. Utilizaun cable para envıo/recepcion de datos (senal SDA) y otro como reloj (senal SCL) para llevara cabo la comunicacion de forma ordenada. La comunicacion, por tanto, es en serie (solo 1 bita la vez, uno detras de otro). El nuevo dato se carga en el SDA cuando SCL baja a 0, y semuestrea (se envıa) cuando SCL sube a 1.De forma general para cualquier conexion I2C [46], desde el maestro se inicia la transmision conla senal de inicio: bajar a 0 el SDA mientras se tiene a 1 el SCL. Entonces envıa la direcciondel registro del dispositivo esclavo donde se desea actuar en 7 bits, y un ultimo bit R/W (lec-tura/escritura) para indicarle si se se quiere leer el contenido del registro o modificarlo. Trasestos 8 bits siempre se le da control del SDA al esclavo y viene un noveno bit de ACK/NACK.Tras eso, el maestro sigue generando los pulsos de reloj en SCL y los datos se siguen enviandopor SDA desde el maestro o el esclavo, segun el caso. La transmision se detiene al darse lacondicion de parada: el SCL sube a 1 y despues el SDA sube tambien a 1. Con esto se consideraterminada la comunicacion, hasta que se de orden de iniciar una nueva bajando el SDA a 0.El lımite de direcciones que se pueden generar con 7 bits y por tanto de dispositivos accesiblespor I2C es 128, aunque hay un modo alternativo de funcionamiento en el protocolo que utiliza10 bits para el direccionamiento.

Figura 25: Lista de comandos del si7021

En este sensor, o bien se envıa la informacion con la que modificar el registro o bien se pasaa leer el contenido del mismo. Conociendo el funcionamiento general del protocolo y el set decomandos predefinidos del sensor se interactua con el. La lista de comandos posibles del sensor,obtenida del datasheet del mismo [27], puede verse en la figura 25. A alto nivel, las funciones



para el manejo del sensor siempre actuan de la misma manera: se envıa el comando y unaserie de datos, indicando las longitudes de ambos parametros. A un nivel inferior, la interaccioncon el sensor se realiza a traves de una estructura creada para almacenar los datos y las flagsnecesarias. A la transmision I2C se le proporciona un puntero al puerto I2C de destino y otroa la estructura de datos donde se encuentre el contenido del envıo, su longitud, la direccion dedestino, si es envıo o recepcion, etc.

Figura 26: Prueba de sensor termico en bare metal : funcion main

El sensor puede recibir peticiones para obtener la medida de humedad, de temperatura ode ambas a la vez. Dado que al medir la humedad relativa el sensor realiza una medicion de latemperatura para aplicar un factor de correccion al valor de humedad obtenido, normalmentese tomara la medida de ambas a la vez mediante una combinacion 0xF5 + 0xE0, ahorrandotiempo. El comando 0xE0 existe unicamente para esto, su funcion es devolver el valor de tem-peratura almacenado tras la ultima medida tomada para la correccion de la humedad sin tenerque realizar expresamente una nueva medicion. La diferencia entre 0xE5 y 0xF5 es si el esclavo(el sensor) retiene o no el reloj en 0. En ocasiones, la diferencia de velocidades entre el esclavo,que suele ser mas lento, y el maestro, que es quien regula el reloj, lleva a que el esclavo notenga tiempo suficiente para procesar y enviar los datos solicitados tan rapido como querrıael maestro, bien porque realice operaciones mas lentas, porque tenga que acceder a memoriaexterna, etc. Por tanto, el esclavo puede retener el reloj para que le de tiempo a procesar todoy que el maestro no le envıe nuevas peticiones, procedimiento llamado clock stretching (trabajaası en el Hold Master Mode), o puede dejar que el maestro haga lo que quiera pero rechazarnuevas peticiones de lectura que le lleguen mientras este ocupado (en el No Hold Master Mode).El maestro sabra en que modo funciona el sensor y podra actuar en consecuencia.El codigo empleado para esta prueba se presenta en la figuras 26. Se inicializan el procesador y



la placa, configurando lo neesario para utilizar los perifericos y mostrar por pantalla los resul-tados, y tras eso se inicializan el sensor termico y la conexion I2C para comunicarse con el. Conesto hecho, se puede llamar a la funcion de medida SI7021 measure de la API del sensor quedara la medida de temperatura y humedad relativa a la vez (combinacion 0xF5 + 0xE0 antesmencionada).El resultado obtenido se puede extraer y utilizar externamente o simplemente mostrarlo porpantalla, como se hizo en la prueba. En este caso, se modifico la propia funcion de medidapara que imprimiera por pantalla las variables medidas directamente como se ve en la capturade la figura 27. La funcion initBoard() (figura 28) es una funcion de inicializacion generica delprocesador, proporcionada por Silicon Labs. Esta funcion generica es la que llama a la funcionde inicializacion especıfica de la plataforma, BOARD init(), mostrada anteriormente (figura 17).

Figura 27: Prueba de sensor termico en bare metal : funcion de medida (fragmento)

Figura 28: Funcion de inicializacion generica initBoard

Se probo a variar bruscamente las condiciones del entorno para apreciar mejor la variacionen las mediciones del sensor. Los valores obtenidos del sensor se adaptan al formato deseadopara poder mostrarlos en pantalla tras enviarlos al ordenador mediante el UART empleado paradepuracion, como sucedio en las pruebas de validacion, o se envıan a otro nodo para su procesadoposterior y su uso en la aplicacion correspondiente, como sucedio en las pruebas posteriores.Del mismo modo, se vario la frecuencia de obtencion de medidas para probar la capacidad derespuesta del sensor, aunque de cara a posibles aplicaciones mas o menos demandantes en esteaspecto no se preve que la frecuencia de medicion sea un factor a tener en cuenta.La tarea de comprobar el funcionamiento del chip de encriptacion ATECC508A recayo en uncompanero del departamento, por lo que no se hablara de ello aquı. Cabe mencionar que elcriptochip utiliza la misma conexion I2C que el sensor de temperatura, cuya funcionalidad yaha sido comprobada.



3.2.3. Sensor inercial

De una forma analoga se comprobo el funcionamiento del sensor inercial icm20648 y laconexion por SPI (Serial Peripheral Interface): se realizo una calibracion y medida, sometiendoal sensor a diversos esfuerzos en sus distintos ejes y realizando las mediciones oportunas. Laconexion por SPI se basa en el uso de 4 cables: un cable de envıo del maestro al esclavo (MOSI),uno de recepcion de mensajes que envıe el esclavo (MISO), uno para la senal de reloj (SCLK)y otro que lleve la senal de habilitacion para activar o desactivar el esclavo (CS). El protocoloes algo mas sencillo que el de I2C, ya que se dispone de cables de un unico sentido y senalesdedicadas para cada uso. En el fondo, utilizar un SPI no es mas que transmitir por un UARTde forma sıncrona (USART) con un direccionamiento muy basico. Desde el punto de vista delmaestro, las senales MOSI y MISO son respectivamente el TX y RX del UART, pudiendoconfigurarse como conexion asıncrona o sıncrona, anadiendo una senal de reloj. Si a esto se leanade el selector de esclavo como senal de habilitacion (o el uso de multiples CS para podersoportar mas de un dispositivo conectado al maestro) y un protocolo asociado (una serie dereglas de uso), se obtiene un SPI.En una comunicacion SPI, con cada flanco de subida (o bajada, segun se configure) del reloj elreceptor correspondiente lee un dato de la senal de datos entrante. En el caso de un dispositivomaestro enviando a un esclavo, es relativamente sencillo porque el reloj lo genera el mismo. Siel maestro necesita que el esclavo responda algo (por ejemplo, si se pide al sensor que midaalgo y devuelva el valor de la medida), el maestro sabe de antemano como de larga va a ser esarespuesta, y tras enviar la solicitud seguira generando ciclos de reloj durante esa duracion paraque el esclavo le envıe su respuesta.Teniendo esto en cuenta, a nivel funcional el procedimiento es similar al empleado para el sensorde temperatura, escribiendo en un registro dado y leyendo otro que almacena la medida deseada.Entrando a un nivel inferior, en el sensor existen diversos bancos de registros. Al enviar unaorden de lectura o escritura, lo primero que se necesita es especificar el banco y registro al quese dirigira. Para ello, se entrega una direccion de 2 bytes y un byte de datos con el contenido aescribir en el registro seleccionado. Los primeros 8 bits son la direccion y los siguientes 8 son elbanco. Para la lectura se indica de nuevo una direccion de 2 bytes, seguido del numero de bytesa leer y un puntero a donde va a guardar los datos leıdos. Yendo a un nivel todavıa mas bajo,cada operacion de lectura o escritura se descompone en cuatro pasos: habilitar el CS, enviar unbyte por el SPI, recibir lo que llegue y deshabilitar el CS. Esta es la base de cualquier operacion.Por tanto, para leer un registro dado primero se hara este ciclo sobre el registro de seleccionde banco (un registro de direccionamiento), donde se indicara a que destino se dirigira masadelante, luego se escribira sobre el registro en cuestion del banco ya seleccionado previamenteel comando correspondiente a una lectura, y se preparara para recibir el contenido del registrodeseado.Las pruebas incluyeron comunicacion con el sensor y medicion de las senales transmitidas atraves del SPI, inicializacion y calibracion del sensor y toma de medidas de aceleracion y rotacionen las tres direcciones. El icm20648 es tanto acelerometro como giroscopio, de modo que es capazde tomar medidas de aceleracion lineal y rotacion en sus 3 ejes. Como curiosidad y un pequenopaso hacia la integracion, se probo a comparar los resultados de las mediciones con ciertosvalores arbitrarios y encender los LEDs si la aceleracion sufrida era superior a un lımite fijadopreviamente, creando de este modo un detector de movimientos bruscos.

3.2.4. Medidor de consumo

La Cookie incluye dos circuitos para la medida del consumo, tomando la tension de entradaal procesador y al bloque de islas de consumo (el sensor termico, el sensor inercial y el chipde encriptacion) como entradas a los amplificadores operacionales y conectando la salida a dosde los pines de entrada analogica del procesador. De este modo, configurando el ADC para



tomar una u otra senal como entrada, se tiene una senal digital que da la medida de tensioncorrespondiente. Los amplificadores operacionales de ambos circuitos tienen una ganancia de200, y el ADC tiene 12 bits de resolucion (0 - 4095). A su vez, los puntos de salida de losoperacionales son accesibles desde el exterior, gracias a dos Test Points colocados en la placapara tal finalidad.Con esto en cuenta se puede medir internamente la tension en dichos puntos y saber la tensioncon la que se alimentan el procesador y el bloque de sensores, mostrandola por pantalla. Asu vez, se puede medir la misma tension externamente mediante un osciloscopio y compararambos resultados para determinar la bondad de la medida del microprocesador sobre su propioconsumo.Ademas, como ambas tensiones caen sobre resistencias shunt conocidas, es posible conocer real-mente el consumo de ambos elementos (el microprocesador y el bloque de islas de consumo) yno solo su tension de entrada. Este resultado se puede comparar con el calculado a partir delos datos obtenidos externamente, o con el resultado de la herramienta de medida de consumoincluida en Simplicity Studio. Las pruebas de validacion en este aspecto se limitaron a com-probar el correcto funcionamiento de los medidores de consumo y el ADC, pero el potencialde esta capacidad de automedicion de la Cookie no se limita a estas pruebas, abriendo nuevasopciones desde el punto de vista del control del consumo para lograr un ahorro de energıa. Cabedestacar en este punto que el consumo de los nodos IoT es uno de los mayores obstaculos en eldesarrollo de esta tecnologıa, y uno de los principales frentes abiertos en este campo.Estos resultados permiten conocer el impacto de activar o desactivar ciertos elementos de laplaca sobre el consumo de la misma, gracias al conjunto de power switches que posee la placa,ası como de los diferentes modos de bajo consumo del procesador. Estas pruebas mas avanza-das, cruzando los modos de consumo del procesador con las configuraciones de bajo consumode la placa mediante el encendido o apagado de sensores, fueron realizadas con el fin de serincluidas como parte de un estudio, con vistas a ser enviado y presentado en el Sensys 2019(ACM Conference on Embedded Networked Sensor Systems), cuya resolucion de aceptacion orechazo todavıa no es conocida en el momento de finalizacion de este Trabajo de Fin de Master.Dichas pruebas experimentales y sus resultados se comentan mas adelante en el apartado 5.1.

3.2.5. Radio

Posteriormente se probo la radio IEEE 802.15.4 para establecer una comunicacion entre dosCookies. Para ello es necesario configurar los parametros de la radio de acuerdo al estandar ya las condiciones en las que se desea transmitir: el canal a emplear, la potencia de transmision,etc. Con esto, se ordena a los nodos transmitir un pequeno paquete cada cierto tiempo, porejemplo, un contador del numero de paquetes enviados hasta el momento. Para el envıo seemplean las funciones de la API de Silicon Labs para manejar directamente la radio. En cuantoa la recepcion, se utiliza una funcion callback para recibir los paquetes de radio entrantes yalmacenarlos en un buffer, que luego se podran mostrar por pantalla en el nodo receptor. Porsupuesto, la comunicacion probada fue simplemente un envıo y recepcion nodo a nodo, y nouna red de nodos mas compleja. Mas adelante se utilizara un sistema operativo que incorporaun stack de red para coordinar una red de nodos.Por tanto, no se llega hasta capas tan altas en el modelo OSI. Se emplea hasta la segundacapa (capa de enlace de datos) para enviar paquetes sencillos. Se aprovecha la API de manejode radio de Silicon Labs, denominada RAIL (Radio Abstraction Interface Layer), que otorgafunciones sencillas para controlar la capa fısica y MAC. El software de Silicon Labs incluyeuna herramienta de configuracion de los parametros de radio. El protocolo utilizado es IEEE802.15.4, empleando para el mensaje la banda de 2.4 GHz.



Figura 29: Prueba de radio en bare metal : main y funcion de envıo

Figura 30: Prueba de radio en bare metal : funcion de recepcion



Se inicializa la radio, configurando los parametros deseados (la frecuencia base, el espaciadoentre canales, el offset inicial, el numero de canales, la potencia de envıo, etc.), se ordena la ca-libracion de la radio y se procede a enviar paquetes simples a los nodos cercanos. Las funcionesde RAIL tambien ayudan a configurar el lado del receptor, estableciendo las interrupciones quese dispararan al llegar un mensaje por la radio y lanzaran la funcion callback correspondientepara recibirlo y procesar el contenido.

Figura 31: Prueba de radio en bare metal : LEDs indicadores

Figura 32: Prueba de radio en bare metal : lectura del terminal

El codigo empleado para este ejemplo se puede apreciar en las figuras 29, 30, 31 y 32.Este codigo esta pensado para utilizar dos Cookies de forma conjunta. Un nodo enviara un



paquete con su mensaje cada 200 ms, a la vez que esta a la espera de posibles mensajes de radioentrantes. Con cada envıo que realice conmutara uno de los LEDS para avisarnos.Al recibir un paquete entrante, la funcion callback extraera los datos del paquete, mostrara porpantalla el mensaje recibido junto con el RSSI y LQI del mensaje y conmutara el otro LED. Alextraer el RSSI y LQI del mensaje se obtiene mas informacion de la calidad de la senal, algo quesera util de cara a poder estimar rangos efectivos de comunicacion entre las Cookies dentro delos cuales se mantenga una potencia de senal y una calidad aceptables. El mensaje enviado fueun clasico “Hola mundo”. Todas estas pruebas de validacion iniciales se realizaron directamentesobre el microprocesador, sin un sistema operativo (bare metal). A su vez, se trabajo en paraleloen el port de Contiki-ng a la plataforma.

3.3. Problemas encontrados

Durante las pruebas de validacion surgieron varios problemas, que finalmente se fueronsolucionando. La dificultad de estos problemas radica en que en el momento no habıa certezade si el origen de los fallos era un error en el diseno de la placa, un error en la adaptacion delsoftware o algo mas, al no disponer de experiencia previa con ninguna de las tres cosas.El primer problema destacable que se encontro durante la validacion fue con el SPI, a la horade probar el sensor inercial. Al tratar de comunicarse con el sensor para su inicializacion, loprimero que se debe hacer es enviar una orden de lectura al registro WHO AM I del sensor,que contiene la ID del dispositivo. De este modo, la API sabe que el dispositivo es el correctoy puede empezar a trabajar. El problema vino al leer el registro, obteniendo solo ceros comorespuesta. Temiendo que el componente estuviera defectuoso, se probo a leer distintos registros yanalizar todas las posibles causas. Se barajo entre las posibles causas un mal funcionamiento delsensor, discrepancias entre los valores esperados por la API y los valores reales del componentesi la version del componente es distinta (si la serie del componente se acabo y en fabricacion semonto la siguiente version en las placas, por ejemplo, como ocurre con el chip de encriptacion),o errores en el codigo derivados de la particularizacion para la Cookie, que repercutan en estaprueba pero no hayan sido detectados en las anteriores (como un mapeado erroneo de los pinesdel SPI).La ultima opcion barajada fue un error en el diseno del circuito, que se demostro cierta trasuna serie de pruebas. En los planos de la Cookie habıa colocada una resistencia entre el MISO yla lınea de masa, cuya existencia responderıa a alguna funcionalidad considerada originalmenteque se desecharıa posteriormente, y que en principio se creıa eliminada tras alguna de lasrevisiones y modificaciones del diseno pero finalmente no habıa sido retirada. Dicha resistenciacortocircuitaba la senal del MISO a tierra, siendo imposible medir nada distinto de cero. Unavez retirada la resistencia y solucionado el problema, se pudo validar el funcionamiento delsensor inercial sin mayor problema.Otro problema encontrado surgio a la hora de integrar ambos sensores (termico e inercial) en unmismo codigo para poder probarlos de forma conjunta. Partiendo de que cada uno funcionabacorrectamente por separado, el problema vino cuando al inicializar el sensor inercial medianteSPI el sensor de temperatura dejaba de funcionar correctamente y se volvıa incapaz de darningun dato coherente.De nuevo se reviso el codigo en busca de funciones para el manejo de un sensor que pudieranafectar al otro, o casos en los que un sensor no solo modificara el preescalado de la senal de relojque de la que obtenıa su CLK sino que tambien alterara la senal del otro, al ser la fuente dereloj la misma para ambos, y el otro sensor no supiera que le venıa del reloj al haberle alteradola frecuencia. Se plantearon hipotesis de todo tipo para intentar encontrar la causa del error yaque, a la hora de validar, no se disponıa de informacion fiable al 100 % de que algo funcionarabien, fe forma que se pudiera descartar como fuente de errores.Finalmente, se descubrio que el problema provenıa del diseno. Originalmente se planteo poder



hacer uso del icm20648 a traves de su interfaz SPI y de su interfaz I2C, ya que el dispositivoadmite ambas alternativas. Al final se considero que se utilizarıa solo la interfaz SPI, ya que elicm20648 disponıa de ella de forma exclusiva, y se dejarıa el I2C para los otros sensores, perolas vıas que conectaban el I2C del icm20648 con el puerto I2C del microprocesador seguıanallı, conectadas mediante dos resistencias del MOSI y SCLK del SPI al SDA y SCL del I2C,respectivamente. Por tanto, cada vez que se realizaba una operacion sobre el sensor inercialel de temperatura recibıa datos extranos y se desconfiguraba, siendo imposible hacer nadacon el despues. La solucion fue, de nuevo, desoldar ambas resistencias, limitando esta vez laconectividad del sensor inercial pero asegurando el funcionamiento de los dos y la capacidad deutilizar ambos a la vez.



4. Contiki-NG

El siguiente paso natural en el proyecto una vez validada la plataforma hardware es laadaptacion del software que ira embebido en la misma. En esta seccion se hablara sobre elsistema operativo utilizado, los cambios realizados para portarlo a la Cookie y algunas pruebasllevadas a cabo sobre el.Contiki es un sistema operativo disenado para redes de sensores inalambricas, con especialinteres en aquellos dispositivos con recursos limitados y de menor potencia. Es un sistemarelativamente ligero y que incluye de serie una implementacion de 6LoWPAN y RPL [3], ademasde su propia capa de acceso a medio (ContikiMAC [9]). Implementa tambien un protocolo decontrol del ciclo de trabajo de la radio (Radio Duty Cycle, RDC) para reducir el consumo de lamisma, ya que la radio es uno de los principales factores de consumo de energıa en dispositivosIoT.

4.1. El Sistema Operativo

Contiki-OS es un sistema operativo desarrollado por el Swedish Institute of Computer Scien-ce (SICS). El sistema debe su nombre a la expedicion Kon-Tiki que el explorador noruego ThorHeyerdahl [4] realizo en balsa en 1947 a traves del Pacıfico con cinco companeros, desde Su-damerica hacia el archipielago de la Polinesia. A su vez, dicha expedicion [24] recibio el nombredel dios inca del sol, Viracocha, que entre los varios nombres que recibıa incluıa el de Kon-Tiki.Contiki-NG es una variante de Contiki-OS, enfocada a las nuevas plataformas que han idosurgiendo en los ultimos anos. Simplifica ciertas cosas de Contiki, implementa nuevos procedi-mientos y revisa algunos protocolos que han evolucionado con el paso del tiempo. En general,el desarrollo del proyecto Contiki-OS esta paralizado, pasando el equipo del SICS a centrarseen Contiki-NG. El logo tradicional de Contiki-NG y el nuevo, utilizado desde mayo de 2019, semuestran en las figuras 33a y 33b.Algun ejemplo de estos nuevos procedimientos es el protocolo de rutado que Contiki-NG utiliza

(a) Logo de Contiki-NG (anti-guo)

(b) Logo de Contiki-NG (actual)

Figura 33: Logos de Contiki-NG

por defecto, RPL-lite, que es una evolucion del RPL que utilizaba Contiki-OS, el cual ha pasadoa llamarse RPL-Classic en Contiki-NG [5]. La diferencia son algunos parametros de configura-cion, donde RPL-lite ha intentado simplificar y aligerar el protocolo. Como este ejemplo, haymas diferencias entre Contiki-OS y Contiki-NG. Los desarrolladores mantienen el repositoriocon el codigo del SO en constante actualizacion, simplificando procedimientos para facilitar sucomprension o ahorrar codigo o recursos, reestructurando el sistema de archivos para optimi-


Capıtulo 4. Contiki-NG

zarlo y eliminando funciones obsoletas, o desarrollando nuevas funcionalidades para el sistema.Por supuesto, la compatibilidad en los protocolos siempre es una restriccion a la que se cinenlos desarrolladores de cualquier sistema, de modo que RPL-Classic y RPL-Lite son compatiblesentre sı, ası como con la implementacion del protocolo RPL de otras plataformas.De aquı en adelante, todo lo relacionado con el sistema operativo se referira a Contiki-NG,que es la version utilizada, y no necesariamente al Contiki-OS original. Por tanto, se utilizarasimplemente Contiki para referirse a Contiki-NG.La principal caracterıstica de Contiki es que se trata de un sistema operativo basado en even-tos, que a su vez implementa un sistema de protothreads. De este modo, consigue realizar uncambio de contexto relativamente rapido y reduce en gran manera el overhead de memoriarespecto a sistemas “puros” basados en threads o en eventos. A los programas se les denominaprocesos. Los procesos se componen de dos partes: el bloque de control del proceso y su threadcorrespondiente. En el bloque de control se define la estructura del proceso, como su estado,un puntero al mismo y el nombre que se le da. El thread del proceso contiene el codigo delmismo, con un begin y un end. Esta estructura es semejante a la definicion y la declaracion delas funciones convencionales de C.El codigo en Contiki puede ejecutarse en dos contextos: cooperativo o preventivo (ver figura

Figura 34: Contextos de ejecucion en Contiki

34). En el contexto cooperativo, el codigo se ejecuta de forma secuencial y debe completarseantes de pasar al siguiente proceso. Este serıa el modo normal de ejecucion, que deben seguirtodos los procesos. El modo preventivo o apropiativo lo utilizan las interrupciones de los driversde sensores, o ciertas tareas de tiempo real que hayan sido planeadas para un determinadomomento. El codigo que opera en este modo es capaz de detener el codigo cooperativo, realizarsus funciones y reanudar el codigo cooperativo donde estaba.El concepto de protothreads o protohilos es la solucion a la que llegaron los desarrolladoresde Contiki para poder tener al sistema ejecutando otras tareas en lo que el programa esperaa algo, sea un evento temporizado, una interrupcion externa, etc. Con esto se intenta adaptarel modelo de funciones de C que se conoce de otros sistemas al funcionamiento de un thread,pero sin el overhead de memoria de estos (en un thread convencional al saltar a otro thread seguarda todo el contexto para cuando haya que recuperarlo a la vuelta).Los eventos pueden ser sıncronos o asıncronos. Los eventos asıncronos se publican y van a unacola de eventos en el kernel de Contiki, pudiendo dirigirse a un proceso en particular o a todosde forma general. En el primer caso, el kernel llama a ese proceso para entregar el evento. En elsegundo, va llamando a los procesos involucrados de forma sucesiva, uno por uno. Los eventossıncronos se entregan directamente al ser publicados, pero solo pueden dirigirse a un proceso.Su funcionamiento es similar a una llamada a una funcion: el proceso invocado realizara la fun-



cion correspondiente y el proceso que publico el evento quedara bloqueado hasta que termine,reanudando su funcionamiento al acabar.Ademas de la publicacion (post) de procesos, existe otra forma de llamar a los procesos: elsondeo (poll). Hacer polling a un proceso hace que el scheduler lo programe para ser lanzadolo antes posible. Es el metodo utilizado para llamar a un proceso desde una interrupcion.En cuanto al codigo de las aplicaciones desarrolladas en Contiki, no deja de ser un sistema ba-sado en C. Hay una funcion main() definida en los archivos del sistema operativo, que siemprese ejecutara. Esta funcion llamara a la inicializacion del microprocesador y de la plataforma,para despues lanzar la aplicacion concreta que se desee ejecutar. Contiki se basa en una es-tructura de Makefiles a la hora de compilar y enlazar los archivos antes de crear el ejecutableque se cargara en el procesador. Estos Makefiles se iran llamando entre sı de forma jerarquica,cumpliendo cada uno una funcion especıfica. Se vera esta estructura en la seccion 4.2.2 masadelante, con un ejemplo concreto del porting realizado.

4.2. La integracion de Contiki

Una vez conocido que es Contiki y teniendo una idea aproximada de su funcionamiento, sepasara a explicar el trabajo realizado para portar el sistema operativo a la plataforma Cookie,desde el porting inicial a las modificaciones realizadas sobre el. En este porting inicial cabedestacar y agradecer la experiencia de Fernando Villa (CEI-UPM) y Ramiro Iglesias (UPM) entemas relacionados, que directa o indirectamente facilitaron en cierta medida la labor que serealizo en dicho porting y se describe a continuacion.

4.2.1. El porting inicial

Antes de pensar en portar el sistema operativo a la plataforma, primero se aseguro que lacapa en contacto directo con el hardware funcionara adecuadamente y la adaptacion de la APIal hardware fuera correcta, que es la base de la que se partirıa a la hora de adaptar el SO. Estaadaptacion del hardware es la descrita en la seccion 3.1.Ahora se procedera a portar el sistema operativo. Para esto se parte de un port [12] de JoakimEriksson de Contiki-NG al EFR32 y la plataforma Thunderboard, del cual se ha adaptado lonecesario para adecuarlo a la plataforma Cookie y se han ampliado las partes que estuvieranincompletas.El primer paso llevado a cabo fue crear una maquina virtual, donde se cargo una imagen delultimo Ubuntu disponible. Sobre esto se descargo el codigo de Contiki desde su github, ası comoel port de Eriksson para las carpetas correspondientes (/arch/cpu/, /arch/platform/). ComoContiki recurre a las bibliotecas del fabricante para las funciones de bajo nivel (la llamadacapa de abstraccion de hardware, HAL), es necesario traerlas desde Simplicity Studio. En [51],Nguyen muestra la arquitectura de software tıpica en IoT, como se aprecia en la figura 35(fuente: [33]). Lo que Contiki adapta para el caso de cada plataforma y procesador es una capaintermedia entre la capa de alto nivel con la que el usuario interactua, propia del kernel del SO,y la HAL, propia de la API de cada fabricante. Sobre esto, fueron necesarios algunos retoques,como rellenar manualmente algunos “TO-DO” del port o conectar entre sı ciertas partes de estacapa de enlace de software intermedio de Contiki.Los pasos a seguir fueron los descritos a continuacion. Del Github de Contiki-NG se descarga

mediante un git-clone la ultima version del branch “master”. Ya es posible probar un “hola,mundo” en nativo si ası se desea, de la forma:cd /home/user/eclipse-workspace/contiki-ng/examples/hello-worldmake TARGET=native hello-world./hello-world.nativeCon esto hecho, ya se tiene una base sobre la que realizar el resto de retoques necesarios parapoder trabajar con Contiki en la Cookie.



Figura 35: Arquitectura de software en aplicaciones IoT

4.2.2. La adaptacion final

Antes de nada, se instalara el compilador para ARM desde el repositorio, y el paquete deJ-Link para el sistema correspondiente desde la web de Segger [44]. En este caso, el ultimodisponible era el JLink Linux V640 x86 64.deb.El sistema de archivos en Contiki es el mostrado en la figura 36. El directorio Contiki-NG agru-pa distintas subcarpetas: /os/ incluye todos los componentes del kernel del sistema operativo,desde la gestion del almacenamiento o los servicios basicos del SO hasta el stack de red. Lacarpeta /arch/ engloba todo el codigo relacionado con las diferentes arquitecturas que puedenejecutar Contiki, incluyendo las diversas plataformas a las que da soporte (subcarpeta /plat-form/), elementos hardware especıficos soportados como ciertos sensores (subcarpeta /dev/) yel soporte a bajo nivel para los diversos procesadores que estan en dichas plataformas (dentrode /cpu/). La carpeta /tools/ contiene las herramientas auxiliares que incluye la distribucionde Contiki, como Tunslip para establecer una interfaz de red virtual entre el equipo y la Cookiecorriendo Contiki, o el simulador de redes Cooja para poder compilar y probar el codigo creadopara los nodos en un entorno virtual, pudiendo simular ası el funcionamiento de una red denodos. En /examples/ se pueden encontrar ejemplos de codigo que trae Contiki, para probarlos diferentes servicios que incluye o el stack de red, y poder utilizarlos como base para futurasaplicaciones.A esto se le anadira la capa de abstraccion de hardware antes mencionada, que para el casodel EFR32 de Silicon Labs es la carpeta gecko sdk suite de la figura. Esta carpeta, importadadirectamente desde las bibliotecas de SDKs de Simplicity Studio, contiene todas las funcionesde bajo nivel propias del microprocesador. En este caso, la version v2.4 era la ultima disponible.Asimismo, se copiara elport de Eriksson desde su Github a las subcarpetas /cpu/ y /platform/dentro de la carpeta /arch/.Algunas modificaciones sobre esto fueron necesarias, como cambiar algunos paths en ciertosarchivos, ya que los destinos que se buscaban ya no estaban ubicados donde se encontraban ori-ginalmente al haber movido los archivos. Pese a que normalmente Contiki utiliza paths relativosen su codigo, al mover determinados directorios la estructura de carpetas variaba ligeramente,alterando la ruta y obligando a la realizacion de correcciones. Ademas, los archivos importados



Figura 36: Sistema de archivos en Contiki

desde Simplicity Studio no tienen por que seguir estar regla, ya que la forma de manejar lasinclusiones en el entorno de desarrollo (que, en el fondo, es una version de Eclipse especıficapara dispositivos de este fabricante) es distinta a la de Contiki, que se suele compilar mediantelınea de comandos. Mas adelante tambien se cambiara eso.Tras recibir una serie de mensajes de error y buscar la fuente de los mismos, se redujo el pro-blema a solo cuatro archivos que modificar. Estos archivos fueron rail.h, pa conversions efr32.c,pa conversions efr32.h y em mpu.h. En los tres primeros, la fuente de error venıa al intentarincluir un archivo propio de la API de Silicon Labs, rail chip specific.h. Cambiando el path rela-tivo erroneo por un path absoluto o corrigiendolo se soluciono el error. El cuarto archivo incluıaun mensaje de #Warning avisando de que la API del microprocesador podıa estar obsoleta, yal tratar de compilar lo tomaba como un error y resultaba imposible la compilacion. Realmenteno habıa ningun error mas alla del propio mensaje, y comentandolo se soluciono este ultimoproblema.Ahora deberıa ser posible cargar algo de Contiki a una Thunderboard, gracias al porting deJoakim Eriksson, las bibliotecas del fabricante y las modificaciones realizadas. Se harıa de lasiguiente forma (todo es una unica linea):sudo make hello-world.upload BOARD=sense2 TARGET=efr32tbGECKO SDK PATH=“/home/user/eclipse-workspace/contiki-ng/gecko sdk suite/” GECKO SDK VERSION=“v2.4”Y es posible conectarse a la Thunderboard para ver lo que muestra mediante un login:sudo make login BOARD=sense2 TARGET=efr32tbGECKO SDK PATH=“/home/user/eclipse-workspace/contiki-ng/gecko sdk suite/”GECKO SDK VERSION=“v2.4”Cabe destacar que para cualquier cosa es necesario tener permisos de superusuario.A la hora de compilar cualquier cosa para Contiki mediante lınea de comandos, es necesarioindicarle expresamente las variables de entorno TARGET, BOARD, GECKO SDK PATH yGECKO SDK VERSION. Una forma de ahorrarse este trabajo serıa anadir condiciones en elMakefile correspondiente al proyecto para que asuma por defecto los valores deseados sin nece-



sidad de indicarselos de forma explıcita.De momento, Contiki ni siquiera es consciente de que la Cookie exista. Sabe que el EFR32es un procesador valido y sabe que la Thunderboard es una plataforma valida, pero para eltodavıa no existe la Cookie. Del mismo modo que para cargar codigo bare metal en la Cookiees necesario retocar ciertos archivos (seccion 3), tambien habra que hacerlo para que Contiki lareconozca como una plataforma mas.Para cargar algo con Contiki es necesario saber con que placa se trabaja y que microprocesadorlleva. Como el EFR32 es el mismo y ya esta portado, no hace falta tocar nada de arch/cpu/efr32,pero la plataforma es nueva. Se creara en arch/platform una nueva carpeta (una nueva plata-forma), a la que se llamara cookieboard. Para cualquier plataforma, la informacion mınima queContiki necesita la encontrara en los siguientes archivos:

Makefile.cookieboard (o Makefile.xxxxxx para la plataforma que sea). El Makefile le in-dicara a Contiki que buscar y donde buscarlo, y es la base del sistema de compilacion yenlazado de Contiki.

Contiki-conf.h, que define algunos valores que Contiki va a necesitar.

Platform.c, que contiene las funciones de arranque de la placa y la inicializacion de algunosde sus parametros.

Board.c y board.h, que contienen funciones de manejo de algunos sensores y perifericosde la plataforma en cuestion.

Leds-arch.c, con funciones para el manejo de los LEDs de la placa.

Para cualquier proyecto de Contiki, siempre habra un archivo Makefile perteneciente al propioproyecto (figura 37). En este Makefile se indicara cuales de los modulos adicionales de Contikise desea anadir al codigo para utilizar ese servicio en el proyecto, en este ejemplo incluye elmodulo Shell. Este Makefile da el path a la carpeta donde se encuentra el sistema operativo, y ledice al linker que otros Makefiles debe incluir. En el caso mostrado, llamara a Makefile.include,que se encuentra en el path indicado arriba.A su vez, ese Makefile.include contiene codigo relativo a la configuracion del sistema operati-

Figura 37: Makefile de un proyecto

vo, y servira de base para llamar a otros Makefiles mas especıficos. Llamara a Makefile.tools(propio de Contiki, gestiona las herramientas del SO), Makefile.(TARGET).defines en caso deque exista un .defines en la plataforma (no existe en el caso de la Cookie, de existir se llamarıaMakefile.cookieboard.defines), Makefile.idenfify-target, que se redirigira al Makefile.native si nohay TARGET definido o al Makefile.(TARGET), en este caso Makefile.cookieboard (propio



de la plataforma, uno de los archivos mencionados arriba). Tambien se incluiran los Makefileespecıficos de los modulos que se deseaba incluir, el Makefile.customrules-(TARGET), si la pla-taforma utilizada tiene reglas especıficas para el linkado que sea necesario senalar expresamente,el Makefile.help (tambien propio de Contiki) y el Makefile.embedded, con algunas generalidadesnecesarias si el codigo va a ir a una plataforma embebida y no al sistema nativo.Cada uno de estos Makefiles delimitara un ambito en particular a la hora de realizar el linkado,

Figura 38: Arbol de dependencias de Makefiles en Contiki

y se iran encadenando mediante llamadas de unos a otros para reunir de este modo todos losarchivos objeto que sean necesitarios para crear el binario que se cargara en la Cookie. Estearbol de llamadas entre Makefiles es caracterıstico de Contiki y se muestra para el ejemplode la Cookie en la figura 38. Se pueden aprovechar estos Makefiles para definir variables deentorno que se necesiten, como en el caso de las variables TARGET y BOARD mencionadasanteriormente.El Makefile.cookieboard define que archivos fuente necesitara cualquier proyecto que tenga comoobjetivo la Cookie, ası como los directorios en los que poder encontrarlos. En el, habra que darel valor de la variable de entorno BOARD para que el sistema operativo sepa que la plataformaexiste. Tambien se anadiran como archivos fuente los mencionados arriba (platform.c, board.cy leds-arch.c), con el path hasta ellos, y se incluira el Makefile de la placa en particular dentrode la plataforma, en caso de existir (por ejemplo, dentro de la plataforma Zoul de Zolertiaexisten las placas Firefly, reMote revA, reMote revB, etc). En el caso de la Cookie, no existeeste subnivel adicional ya que TARGET y BOARD coinciden.Este Makefile.cookieboard llamara a los Makefiles relativos al microprocesador, en este casoMakefile.efr32 en la carpeta arch/cpu/efr32. El del EFR32 incluira archivos fuente relativos aelementos del microprocesador, como debug-uart.c, efr32-radio.c o clock.c para el manejo deluart de depuracion, la radio o el reloj, respectivamente. Ademas, aquı se define la variable deentorno GECKO SDK VERSION, se fijara el valor por defecto en caso de que no se especifiqueuno para que sea la version existente del gecko sdk (en este caso, la v2.4). Por ultimo, desde



aquı se llamara al Makefile generico de los Cortex-M4, Makefile.cm4, que a su vez llamara algenerico de los Cortex-M, Makefile.cortex-m, y este al Makefile.arm. Como se puede ver, lajerarquıa de llamadas establece que cada inclusion tenga su lugar establecido, en funcion delambito al que pertenezca.El archivo Contiki-conf.h contiene algunas macros y flags del sistema para indicarle si la pla-taforma tiene o no determinados perifericos, especificar la frecuencia del reloj, etc. En el casode la Cookie, con copiarlo de la Thunderboard (delport de Joakim Eriksson) es suficiente, yaque los valores son los mismos. Del mismo modo, copiando el archivo Leds-arch.c de la carpetacorrespondiente a la Thunderboard no es necesario realizar ninguna modificacion.Para el platform.c de la Cookie, se copiara el platform.c de la Thunderboard y se realizaran unas

Figura 39: Platform.c para la plataforma Cookie

pequenas modificaciones. Se pretende evitar que Contiki intente utilizar los sensores de la Thun-der porque directamente no los encontrara, ası que se comentara la inclusion de lib/sensors.hy se anadira una al board.h de la plataforma, donde estan definidas ciertas funciones y macrosde la placa necesarias para el sistema. El resultado se aprecia en la figura 39.Este board.h mencionado es otro de los archivos copiados de la carpeta de la Thunder a laarch/platform/cookieboard y modificados para adaptarse a la plataforma Cookie. No se en-trara en mayor detalle en la exaplicacion de las modificaciones ya que la funcion de este archivoes la misma que la de los bspconfig.h, hal-config.h y hal-config-board.h vistos anteriormente. Ladiferencia entre ambas radica en que en esos tres archivos se encuentran las macros que utilizala API de Silicon Labs y en board.h las que utiliza Contiki. Por tanto, habra muchos elementosdefinidos con mas de un nombre apuntando al mismo valor, como los valores de los registrosque acceden a los puertos de E/S. Las funciones nativas de Contiki utilizaran uno de ellos y lasimportadas de la biblioteca del fabricante utilizaran el otro. Parte de este board.h se muestraen la figura 40, y puede compararse con la figuras 15a, 15b, 16a y 16b vistas anteriormente.El hecho de tener nomenclatura por duplicado para muchas cosas sugiere la posibilidad de



Figura 40: El archivo board.h (fragmento)

unificarla por comodidad en su uso y mayor simplicidad del codigo para hacerlo mas facil deentender. Esto implicarıa o bien modificar los archivos importados de las bibliotecas de SiliconLabs o bien los archivos propios del sistema operativo. La primera de estas dos opciones noparece muy adecuada, ya que las bibliotecas importadas ascienden a un total de mas de 31.000archivos y la busqueda serıa totalmente manual. La segunda alternativa es todavıa peor, ya queaunque el numero de archivos a examinar es probablemente menor al considerar solo las partesrelativas a la plataforma Cookie, modificar el SO supondrıa anclarse a la version actual y serincapaces de modificar los archivos para actualizar a futuras versiones del sistema. Por ello, seha descartado realizar modificaciones adicionales sobre el sistema de archivos en este sentido.Una vez llegados a este punto, es posible desarrollar aplicaciones sencillas sobre Contiki para laplataforma. Para aplicaciones mas complejas con codigo fuente distribuido entre varios ficheros,sera necesario modificar el Makefile del proyecto, como se vera mas adelante.

4.2.3. Integracion con Eclipse

Como paso final de la integracion, y para facilitar el trabajo de quien tenga que desarro-llar codigo en Contiki en un futuro, se va a integrar Contiki con el entorno de desarrollo deEclipse [10] para poder crear proyectos desde Eclipse en lugar de utilizar la consola, lo cual esmuy util desde el punto de vista del desarrollador. Para ello, asumiendo que ya se encuentrainstalado, se arranca Eclipse y dentro de File - Import se selecciona (C/C++) Existing Codeas Makefile Project. Se nombra al proyecto “contiki-ng”, dandole la ubicacion de la carpeta deContiki y seleccionando lenguaje C y toolchain ARM Cross GCC. Este sera el proyecto base,que contendra el nucleo de Contiki, y el resto de proyectos se apoyaran en el para hacer unacompilacion cruzada entre ellos.Ahora se repetira el proceso para el proyecto que se desee generar, por ejemplo un “Hola, mun-do”. Se fija la ubicacion del proyecto y se le da nombre. Se van a definir las variables de entorno



que antes se fijaban manualmente para que Eclipse las almacene por su cuenta, y a cambiar elcomando de build por uno que incluya dichas variables.Para ello, dentro de las propiedades del proyecto, en C/C++ Build, se cambiara el comandoutilizado para construir el proyecto por lo siguiente:make $BOARD $TARGET $GECKO SDK PATH $CONTIKI APPO, si se desea, se puede hacer que Eclipse genere directamente el binario y lo cargue en laCookie automaticamente al construir el proyecto. Para ello se debe cambiar $CONTIKI APPpor $CONTIKI APP.upload en el comando. Por otro lado, en el directorio donde construira elproyecto (Build Location) pondra $CONTIKI BUILD LOC. Asimismo, en Behavior se fija elnombre del archivo a construir a $CONTIKI APP.bin, de modo que tras estos pasos el proyectoen Eclipse tendra el aspecto que muestra la figura 41.Las variables de entorno son las utilizadas anteriormente: TARGET, BOARD y GECKO SDK PATH.

Figura 41: Alteraciones sobre Eclipse

Sus valores seran los de antes. A estas variables se anadiran las dos nuevas recien creadas,CONTIKI APP y CONTIKI BUILD LOC, cuyos valores seran respectivamente el nombre delproyecto y la ubicacion del mismo. Estas variables se definen en Build Variables, y se obtienenlos resultados que se muestran en la figura 42.Tras esto, solo queda indicarle a Eclipse donde puede encontrar las bibliotecas que vaya a

incluir y los archivos fuente del proyecto. Para los archivos fuente, en Paths and Symbols se leenlazara a las carpetas arch, os y v2.4 de Contiki, aparte de la ubicacion del propio proyecto que



Figura 42: Variables de entorno en Eclipse

ya estaba. Con esto se esta vinculando el proyecto a esos directorios, por lo que los archivos quese modifiquen en el proyecto seran los originales y no una copia local de los mismos. Para lasinclusiones, se le indicara el path a estos tres directorios y a la ubicacion donde estan instaladaslas toolchain de ARM. De esta forma, Eclipse sera capaz de encontrar todo lo que necesita paraconstruir el proyecto.En proyectos relativamente sencillos, en los que todo el codigo este en el propio archivo fuentedel proyecto, el paso anterior no sera necesario. Pero en proyectos mas complejos donde el codi-go se encuentre distribuido en distintos archivos fuente o necesite utilizar funciones externasque haya que incluir, sera necesario indicar que archivos adicionales debe incluir y donde podraencontrarlos. Eclipse ya sabe donde va a estar todo, pero es necesario hacerselo saber tambiena Contiki. Por esto, el ultimo paso restante es modificar los Makefiles del proyecto y anadir losarchivos y ubicaciones necesarias. Enlazando con el apartado anterior, donde se mencionabaeste aspecto, se procedera a modificar el archivo Makefile.

Figura 43: Makefile modificado del proyecto udp-client/udp-server



Figura 44: Mensaje de arranque de Contiki

Para ello se anadiran los archivos y ubicaciones a las macros que Contiki usa a tal efecto:PROJECT SOURCEFILES y PROJECTDIRS. Funcionan del mismo modo que MODULES,visto anteriormente, con el que se vincula a esta macro una lista de los modulos de Contikinecesarios para el proyecto. En el Makefile del proyecto es posible incluir mas elementos en estaslistas, y al procesar el Makefile.include el sistema leera la lista de PROJECT SOURCEFILESy anadira al proyecto todo lo que este en ella, buscandolo en la lista de ubicaciones dadapor PROJECTDIRS. A modo de ejemplo, para el proyecto de udp-server y udp-client quese muestra mas adelante se necesitara incluir, entre otros, los archivos fuente relativos a lossensores, obtenidos de las bibliotecas de Silicon Labs. Se puede apreciar en la figura 43 comose incluyen los ficheros fuente de los sensores.En este Makefile ademas se anade la opcion CFLAGS += -lm, que anade como opcion delcompilador (CFLAGS) el uso de la biblioteca libm, que no viene incluida por defecto. El motivode esto responde a razones historicas [16]. La biblioteca estandar de C, libc, viene precargada enel compilador (gcc) de modo que se pueden incluir las bibliotecas que la componen simplementeindicandoselo al preprocesador con un #include. Sin embargo, como las operaciones con floateran mucho mas pesadas y demandaban mas recursos, los desarrolladores no querıan incluirmath.h por defecto si no era necesario. Por esto, math.h no esta incluida en la bibliotecaestandar libc sino en libm, y para poder utilizarla en el codigo de los proyectos es necesarioenlazarla mediante el flag -lm.De este modo, se tiene todo lo necesario para compilar un proyecto de Contiki desde Eclipse ycargarlo directamente en la Cookie. La figura 44 muestra el mensaje de arranque generico deContiki, visto desde un terminal conectado a una de las Cookies utilizadas.



5. Pruebas experimentales

Ademas de las pruebas de validacion del hardware presentadas en la seccion 3.2 y las prue-bas con Contiki para comprobar el porting, se realizaron mas pruebas experimentales sobre laplataforma, bien debido al proyecto del que forma parte el trabajo o bien de cara a ser incluidoen artıculos academicos.

5.1. Pruebas de consumo

La primera de las pruebas experimentales realizadas consiste una serie de pruebas de con-sumo sobre la placa para determinar el impacto de los distintos modos de bajo consumo delprocesador y el uso de los power switches que controlan el encendido o apagado de los periferi-cos.Los modos de bajo consumo del EFR32 son (figura 45, fuente: [25]):

EM0 - Active/Run Mode: el modo normal de ejecucion.

EM1 - Sleep Mode: la rama de reloj de la CPU se deshabilita. Aun se puede acceder amemoria vıa DMA (Direct Memory Access) y se pueden manejar los perifericos a travesdel PRS (Peripheral Reflex System).

EM2 - Deep Sleep Mode: no solo esta deshabilitado el reloj de la CPU, sino tambien lososciladores de alta frecuencia (cristal, HFXO y RC, HFRCO). Los osciladores de bajafrecuencia (LFXO y LFRCO, 32 kHz) siguen activos.

EM3 - Stop Mode: todos los osciladores de alta y baja frecuencia estan deshabilitados,salvo el de ultra baja frecuencia (ULFRCO) y, opcionalmente, los auxiliares.

EM4S - Shutoff Mode: todos los osciladores estan deshabilitados, no hay retencion de laRAM y el procesador esta apagado, salvo por la logica de recuperacion. La unica formade despertar al procesador es mediante un reinicio.

EM4H - Hibernate Mode: similar al modo EM4S, pero proporciona mas opciones para ladespertar al procesador. En el modo EM4H se puede tener el RTCC (Real Time Clock andCalendar) corriendo con el ULFRCO, mientras que en el EM4S no es posible. Ademas,permite cierta retencion de la memoria RAM, algo que no se tiene en el EM4S.

Al margen de estos modos de bajo consumo y de forma paralela, se puede hacer uso de los powerswitches antes mencionados. Mediante el uso de estos interruptores sobre las llamadas islas deconsumo (el sensor termico, el sensor inercial y el cryptochip) y los modos de bajo consumodel EFR32 de forma conjunta, se llega a un codigo de caracteres. Para las pruebas solo se hatenido en cuenta hasta el modo EM2, ya que del EM2 al EM3 no cambiara nada (la diferenciaentre estos modos es el uso de los osciladores de baja frecuencia, y en las pruebas no se estautilizando ningun periferico o funcionalidad del procesador que dependa de dichos osciladores)y los modos EM4S y EM4H se han ignorado porque solo se puede salir de ellos mediante unreinicio, y esto se aleja de la funcionalidad real que se espera de la plataforma.Por otra parte, cada isla de consumo se representa con un ‘1’ o un ‘0’ segun se encuentrehabilitada o no. En el codigo empleado, el primer 1/0 corresponde al sensor de temperatura,el segundo al chip de encriptacion y el tercero al sensor inercial. Con esto, se representa cadacombinacion como EM - . Por ejemplo, estar en el modo EM1 y tener habilitados el sensorde temperatura y el sensor inercial se representarıa como EM1-101. Las posibles combinacionesde modos son las mostradas en la tabla 1.Las pruebas de consumo se realizaron en bare metal, de modo que el consumo medido no se

viera condicionado por el uso de un sistema operativo u otro. Para la realizacion de las pruebas


Capıtulo 5. Pruebas experimentales

Figura 45: Modos de bajo consumo del EFR32

Cuadro 1: Modos combinados de bajo consumo en la Cookie

EM0 EM1 EM2

Todas las islas deshabilitadas EM0-000 EM1-000 EM2-000Temp habilitado EM0-100 EM1-100 EM2-100Cryptochip habilitado EM0-010 EM1-010 EM2-010Inercial habilitado EM0-001 EM1-001 EM2-001Temp + Crypto habilitados EM0-110 EM1-110 EM2-110Temp + Inercial habilitados EM0-101 EM1-101 EM2-101Crypto + Inercial habilitados EM0-011 EM1-011 EM2-011Todas las islas habilitadas EM0-111 EM1-111 EM2-111

se activo o desactivo el componente correspondiente en cada caso pero no se hizo nada con el,simplemente se mantuvo en estado de espera, de modo que el consumo aportado al habilitarcada componente es algo estacionario, fijo, y no se observaran los picos de consumo que sedarıan en el momento de la medicion. Por el mismo motivo de evitar anormalidades debidas asubidas puntuales de consumo, la radio se encuentra apagada en las pruebas. Como respaldoa esta afirmacion, la figura 46 muestra la medida del pico de consumo correspondiente a unatransmision saliente de radio, y es un ejemplo de lo que se pretende evitar en las medidas. Conestas pruebas experimentales se busca conocer el consumo medio, estable, y no comprobar silos posibles picos puntuales de consumo corresponden con el valor de pico del datasheet delcomponente en cuestion.Con esto, los resultados obtenidos son los mostrados en la tabla 2. Se puede ver que el maximo

consumo medido corresponde al caso EM0-111, es decir, si el procesador se encuentra en modoactivo y estan activadas todas las islas de consumo. El extremo opuesto corresponde, como erade esperar, al modo EM2-000: todas las islas deshabilitadas y el procesador en modo Deep Sleep.En cuanto a la serie de casos intermedios, en general se aprecia un descenso aproximado de 1.5mA al bajar del modo activo (EM0) al modo Sleep (EM1), y de 3.6 mA al bajar de este almodo Deep Sleep (EM2). La grafica de la figura 47 representa estos resultados de forma visual.



Figura 46: Disparo de consumo en el momento de una transmision saliente de radio

En cuanto al impacto de los sensores, se puede apreciar que el consumo del sensor inerciales significativamente superior (unas 10 veces mayor) que el del sensor termico o del chip deencriptacion.A la vista de estos resultados, se puede apreciar que los valores medidos son superiores a los

Cuadro 2: Consumo en los diversos modos de la Cookie (mA)

EM0 EM1 EM2

Todas las islas deshabilitadas 11,93 10,43 6,80Temp habilitado 11,94 10,44 6,81Cryptochip habilitado 11,99 10,45 6,82Inercial habilitado 12,44 10,89 7,33Temp + Crypto habilitados 11,99 10,45 6,83Temp + Inercial habilitados 12,51 10,87 7,34Crypto + Inercial habilitados 12,45 10,95 7,35Todas las islas habilitadas 12,52 10,97 7,37

que muestra la literatura para otras plataformas [22]. Si bien en parte es de esperar ya que laCookie tiene en general un procesador superior, una mayor cantidad de perifericos y toda unaserie de circuitos auxiliares que las otras plataformas no poseen, los resultados siguen siendotal vez demasiado altos para lo esperado.Estas pruebas de consumo fueron incluidas en un artıculo enviado al 17th ACM Conference onEmbedded Networked Sensor Systems (SenSys 2019).



Figura 47: Consumo de los diversos modos de la Cookie (mA)

5.2. Pruebas de red

Al margen de las pruebas iniciales sobre la radio, realizadas en bare metal, se ha realizadouna serie de pruebas experimentales mas completas, de forma que simulen las condiciones quesufrirıa la plataforma en un despliegue real. El objetivo de estas pruebas es probar la capacidaddel stack de red de Contiki, corriendo en las Cookies, para crear y mantener una red de nodosconectados mediante 6LoWPAN y rutada mediante RPL.Para estas pruebas se parte de dos aplicaciones de ejemplo que incluye Contiki para probarRPL, adaptando lo necesario para la plataforma. Dichos ejemplos son udp-client y udp-server,en /contiki-ng/examples/rpl-udp/. Se trata de dos versiones de un mismo codigo para ser eje-cutadas en al menos dos placas distintas. Una de ellas, el udp-client, hara de cliente de una redRPL, enviando paquetes UDP de ejemplo cada cierto tiempo al servidor. Se puede tener masde un cliente en la red, pero el servidor sera unico. El otro nodo, udp-server, tomara el rol deservidor y root de dicha red. Su trabajo sera crear un DODAG, establecerse como DODAG rooty anunciarse como tal al resto del mundo. El nodo cliente, al recibir noticias de que hay unared RPL disponible, se querra conectar a ella. Tras conectarse, procedera a enviar mensajes deejemplo al root de forma regular cada cierto tiempo. El nodo servidor actuara como sumideropara los mensajes enviados por el resto de nodos. Sobre estos ejemplos se modifico el codigo demodo que el mensaje enviado sea sustituido por uno con cierta utilidad real.Los nodos cliente inicializan los sensores termico e inercial, ası como la radio para realizar elprocedimiento de conexion descrito anteriormente. Con una frecuencia dada, cada nodo clienterealiza una medicion de humedad relativa, temperatura, aceleracion lineal y rotacion (ambas enlos 3 ejes del sensor). Con estos 8 valores medidos, compone un paquete comun concatenandolosde acuerdo a un formato escogido de forma arbitraria. El unico requisito es que el formato seaconsistente entre el nodo emisor y el receptor, de modo que se eligio un formato comodo de laforma que se presenta en la tabla 3. Con esto, y contando con que el formato de cada valorocupa 4 bytes (uint32 t para la humedad, int32 t para la temperatura y float para aceleracionesy rotaciones) y que por comodidad se enviaran los caracteres tambien como numero de 4 bytes(forzando el formato a uint32 t), se tendra un mensaje de 48 bytes para enviar.



La razon para forzar los caracteres tambien a bloques de 4 bytes fue que inicialmente se altero

Cuadro 3: Formato de envıo en los mensajes de prueba

“H” hume “T” temp “A” acel0 acel1 acel2 “G” giro0 giro1 giro2

4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B 4B

el formato de envıo de UDP en el stack de red para tener 4 bytes como unidad mınima, a modode prueba, teniendo de este modo la funcion de envıo y el callback de recepcion con una unidadnatural de 4 bytes, y pudiendo por tanto sacar el paquete a la salida dato a dato de formasencilla. Posteriormente se reparo en que era totalmente innecesario, dejando las funciones delstack de Contiki en su formato original y adaptando el codigo de acuerdo a eso. Tras este pro-ceso, el formato de los caracteres simplemente se quedo en 4 bytes.El setup para las pruebas fue el siguiente: se dispone de un nodo udp-server conectado a un

Figura 48: Callback de recepcion del servidor udp

terminal, para poder visualizar por pantalla todo lo recibido. A cierta distancia y repartidosde forma mas o menos aleatoria, se disponen otros 5 nodos udp-client. Estos nodos cliente seconectaran a la red del nodo servidor, bien directamente o a traves de otros nodos intermedios,y le enviaran paquetes en el formato establecido.El nodo root lee el paquete recibido y extrae cada parte del mensaje, empleando los caracterescomo indicadores de lo que vendra a continuacion. De este modo, puede separar la medida decada sensor de acuerdo a la funcionalidad deseada.



Para las pruebas se programo un envıo cada 2.3 segundos. Tras 2 segundos de espera con unLED encendido, se procede a un ciclo de medida y envıo. Durante este instante (0.3 s) cambiaal otro LED. Tras esto, vuelve a esperar 2 segundos hasta el siguiente ciclo. De este modo sepuede ver facilmente si el codigo esta ejecutando o no a simple vista, util al tener varios nodosdesplegados de forma simultanea y sin la necesidad de estar conectados a terminales.Se modifico el nodo receptor de tal manera que mostrara el mensaje recibido en un formatodeterminado, de modo que se pudiera leer el mensaje o extraer la informacion deseada de el enun futuro. El callback de recepcion se muestra en la figura 48. Al recibir un paquete se copia aun buffer llamado “recepcion”, sobre el cual se distingue segun los caracteres y se presenta deforma mas legible.La idea tras esto es enviar la informacion por la conexion serie y poder procesar los datos en otrodispositivo conectado. Inicialmente y a modo de prueba, los datos se sacaron por un terminalobteniendo la salida mostrada en la figura 49.Los datos de humedad relativa ( %)y de temperatura (◦C) se multiplicaron por 1000 y se de-

Figura 49: Datos obtenidos, leıdos directamente en pantalla

jaron como numero entero, de modo que los valores mostrados junto a H y T en realidad sonmil veces el valor medido realmente. Es decir, en ese momento las condiciones ambiente eran29.748 ◦C y un 21.366 % de humedad. En cuanto al resto de medidas, la aceleracion mostradaen pantalla esta expresada en mG (1000 mG = 1 G = 9.8 m/s2), mientras que la rotacion direc-tamente se da en ◦/s. La razon de esto es que Contiki es incapaz de hacer un print de valoresen coma flotante. Por esto, se transformaron los valores sabiendo que en la recepcion habra queprocesarlos de vuelta. En el ejemplo mostrado en la figura 49, la placa que enviaba los datosestaba quieta sobre la mesa. Ademas de los datos medidos, tambien se extrae del paquete ladireccion IP del nodo que los envıa, de modo que sea posible almacenar la informacion de cadanodo por separado, promediar los datos o distinguir las medidas en funcion de su origen, si lasCookies se encuentran en zonas con condiciones diferentes (ej. interior y exterior de una sala ode una cabina).

5.3. Pruebas de red: integracion con Python

Como se dijo anteriormente, este trabajo se engloba dentro del proyecto SCOTT. La finali-dad de este trabajo dentro del marco del proyecto es disponer de una red de nodos sensores queenvıe informacion a un nodo sumidero, el cual sea capaz de recibir y procesar todos esos datosy enviarselos a otro dispositivo mediante una conexion serie. Este dispositivo sera un ordenadoro una placa distinta de la familia Cookie, con capacidad de conexion a internet y que haralas veces de puente entre el Edge y la nube, destino al que se enviaran los datos para su usoexterno. La particularidad de este dispositivo es que pueda correr un sistema operativo Linux,de forma que para la red de sensores es irrelevante la identidad del nodo (Cookie o PC).Este nodo Linux ejecutara un script en Python que lea los paquetes recibidos a traves del puer-to serie, extraiga los datos de interes del paquete y los serialice, transformandolos a formato



Figura 50: Consola de Python, recepcion de datos

JSON, y tras eso los envıe mediante un cliente MQTT hacia un servidor en la nube.La razon para utilizar Python es, por un lado, su relativa sencillez sintactica y facilidad de lec-tura desde la perspectiva humana y, por otro lado, la existencia de modulos predefinidos paratrabajar con JSON y para implementar un cliente MQTT de forma sencilla. Un primer paso esrecibir los datos que envıen las Cookies de la red de sensores. La Cookie receptora se conecta atraves del puerto USB al ordenador. Al recibir el ordenador un mensaje por el buffer serie, sealmacena en forma de cadena de caracteres y se filtra de acuerdo a lo deseado. En el caso de laspruebas, por ejemplo, se desea conocer la direccion IPv6 del nodo de origen. El nodo receptortoma los metadatos del paquete, extrae la direccion IPv6 y la manda a la conexion serie conun ”Paquete de: ”. El script de lectura buscara esa cadena ”Paquete de:”para ubicar suposicion en la cadena de texto entrante y encontrar la informacion relevante a partir de dichaposicion. Ası, almacenara esa informacion y la procesara posteriormente. La salida del scriptde lectura en la consola de Python se muestra en la figura 50, para el caso de simplemente leerlos mensajes recibidos, extraer ciertas secciones y mostrarlas por pantalla. El script filtrara elresto del mensaje recibido, extrayendo solo los elementos deseados (la direccion IP y los valoresmedidos).El segundo paso es generar un archivo JSON a partir de los valores extraıdos. El formato JSONes uno de los mas comunes y ampliamente utilizados en aplicaciones IoT. Un ejemplo muy sen-cillo en este caso es el mostrado en la figura 51. En ella se muestra el archivo “valores.json”, quese ira generando y sobreescribiendo con cada paquete recibido y almacenara los valores medidospor uno de los nodos, obtenidos directamente al leer desde la conexion serie. Como se puedever, el archivo consiste en una unica lınea de texto con todos los caracteres dispuestos en serie.



Figura 51: Archivo JSON de ejemplo

En su aplicacion real en el proyecto, esta serializacion a JSON lleva una extension algo masrica que el ejemplo mostrado, ası como una estructura mas estricta en cuanto a los camposincluidos, siempre siguiendo el formato dictado por la ontologıa del proyecto. Dicho formatoincluira datos del nodo root,la ID del nodo que ha enviado cada paquete y una conversion delos datos de nuevo a formato float, que es el adecuado para expresar las magnitudes empleadas.En el apartado anterior ya se hablo de la transformacion de estos valores a formato entero alno poder utilizarlos directamente en Contiki en formato de coma flotante.Como parte del procesado de esos datos, el script tambien calculara el CRC de los valores de

Figura 52: Archivo JSON generado en el proyecto (fragmento)

cada nodo (en la estructura de “clave”: valor antes mencionada), de los valores de todo el pa-quete y de la cadena serializada JSON entera. La figura 52 muestra el contenido de un nodo enun archivo JSON generado mediante el script, una vez modificado el formato de visualizacionen un editor de textos para facilitar su lectura. Realmente, el archivo es una lınea unica decaracteres serializados. En la captura se puede ver un nodo con tres sensores: aceleracion en lostres ejes, temperatura y humedad.



El tercer paso es enviar estos paquetes empleando MQTT, bien sea a un broker local o a lanube. De este modo, se puede tener un topic general para los valores medidos, uno por cadanodo o por cada tipo de medicion (humedad, temperatura, aceleracion, rotacion). Esta decisiondepende de las necesidades del usuario al otro lado del servidor.El script de Python implementara un cliente MQTT para correr en el nodo Linux, recibien-

Figura 53: Envıo de MQTT en el proyecto (fragmento)

do paquetes generados en el paso anterior y enviandolos al topic correspondiente. Primero, seconfigura el cliente y se conecta al broker. Una vez conectado, se suscribe a los topics que sehayan estipulado. Tras eso, publica los mensajes con los JSON generados en un topic dado. Enel ejemplo mostrado en la figura 53, el topic al que se debe enviar se calcula sobre la marcha apartir del propio paquete (lo que en la figura se muestra como CRCPayload).El cliente MQTT debera pasar por una serie de etapas para establecer la conexion con el bro-ker, al tratarse de un broker privado y llevar asociada una serie de medidas de seguridad, tantoen los certificados necesarios para establecer la conexion o el filtrado de clientes mediante sudireccion IP como en los propios paquetes, llevando un formato especıfico y basandose en lacomprobacion de los CRC de cada nodo por separado, del conjunto de nodos, de la carga totalenviada en el mensaje y del propio topic en el que se publica. Al otro lado de la conexion serecalculara cada uno de estos CRC y se comparara con el CRC enviado, para aceptar o rechazarel mensaje.Esta serie de etapas de la conexion al broker se puede resumir en la maquina de estados de la

Figura 54: Maquina de estados del cliente MQTT

figura 54. Considerando como sistema al conjunto de la red de sensores, el nodo cliente MQTT



y la conexion hasta el broker, en el funcionamiento del mismo se distinguen dos procesos prin-cipales: inauguracion del sistema (etapas 0, 1 y 2) y operacion normal (etapa 3).En la etapa 0 el cliente se suscribe a los tres topics indicados, siendo los tres por los que lellegaran las respuestas del broker en las etapas sucesivas. Al suscribirse correctamente, reci-bira un mensaje de respuesta publicado desde el otro lado por el topic 101/100/... (el resto decampos no es importante), el llamado Send Train Consist Data. Tras recibir este mensaje, sedispondra a enviar un paquete JSON concreto, el Send Train Consist Data Package, al topic101/103/0/0/100/109/100/*/* (los ultimos dos campos corresponden al CRC del propio topicy al CRC de la carga, el CRCPayload descrito anteriormente. Para confirmar la recepcion delpaquete y poder pasar a la siguiente etapa, el cliente debe recibir una confimacion (CompositionConfirmation Request) por el topic 101/108/..., y publicar a continuacion el paquete de Com-position Confirmation en el 101/109/0/0/100/109/100/*/* (de nuevo, los dos ultimos camposse calculan en el proceso). El franqueo de esta etapa 2 a la etapa 3 de operacion normal sucedesiempre, de manera incondicional. Durante este proceso de inauguracion, en cualquier momen-to puede llegar un mensaje de reinicio del sistema, en cuyo caso se volverıa a la etapa 0. Estereinicio solo podrıa solicitarse durante la inauguracion.Una vez realizado este procedimiento, la inauguracion del tren se considera finalizada con exi-to y se procede a la operacion normal, en la que la red de sensores mide las condiciones delhabitaculo y genera paquetes JSON que el cliente MQTT envıa cada 0.25 segundos al broker,publicandolos en el topic 100/106/0/0/100/109/100/*/*. Durante este tiempo, el cliente puederecibir peticiones asıncronas para enviar paquetes adicionales con datos de los sensores, ademasdel envıo periodico normal. Tambien puede recibir una orden de fin de mision (end mission),tras la que se llegarıa a un estado de parada desde el que se podrıa regresar a la etapa 0.



6. Conclusiones y lıneas futuras

El objetivo del presente trabajo era la validacion del hardware de la plataforma Cookie y elporting de Contiki-NG a la misma. De la investigacion desarrollada, la implementacion realizaday los resultados obtenidos en las pruebas llevadas a cabo se extraen las siguientes conclusionesen relacion a los objetivos propuestos:

Salvo algunos detalles menores ya mencionados, la validacion del hardware se completo deforma satisfactoria y los resultados obtenidos en las pruebas de validacion se correspondencon lo esperado. Los problemas encontrados durante la validacion fueron solventados enel proceso, llegando a un comportamiento del hardware estable y totalmente funcional,acorde con lo deseado.

El porting del sistema operativo a la plataforma y las pruebas posteriores sobre el mismose completaron de la forma esperada, siendo capaces de operar la plataforma a travesdel sistema operativo y aprovechar las capacidades que ofrece el mismo. En este aspecto,se logro de forma adicional la integracion del sistema operativo con el entorno Eclipse,facilitando ası la labor posterior de desarrollo de software sobre el sistema, tanto en elambito de este trabajo como de cara al futuro, de forma general.

Las pruebas experimentales ayudaron a profundizar en mayor medida en la integracionhardware-software y probar el desempeno de la plataforma bajo el sistema operativo. Eneste sentido, los resultados fueron en general satisfactorios, si bien es cierto que ciertosaspectos son mejorables frente a los competidores tanto a nivel de hardware como desistema operativo. Entre estos aspectos susceptibles de mejora se encuentran el consumode energıa de la plataforma en modos de bajo consumo o la estabilidad de la red en loreferente al rutado con RPL.

Entre las posibles lıneas futuras se incluye la posibilidad de mejora en ciertos aspectos desarro-llados en el trabajo, tanto a nivel de sistema operativo e implementacion software como en lacaracterizacion del hardware de forma mas exhaustiva de cara a aplicaciones reales, ası comola opcion de implementar diferentes alternativas en cuanto al sistema operativo que se ejecuteen la plataforma.En cuanto a la integracion del sistema operativo con Eclipse, de cara al futuro podrıa sustituirseel uso de variables de entorno en Eclipse por macros de Contiki incluidas en el Makefile, paraaquellos valores que sean dependientes de la plataforma y no del proyecto. De hecho, dado elproceso de construccion de los proyectos en Contiki, existe la posibilidad de crear Makefilespropios comunes a todos los proyectos, dedicados expresamente a incluir estos aspectos. Deeste modo, el proceso de creacion es mas limpio y de cara al desarrollador de aplicaciones sesimplifica el trabajo previo al propio desarrollo del proyecto.Por otra parte, se plantea la posibilidad de utilizar otros sistemas operativos en la plataforma ycomparar su desempeno con Contiki. Ya en [22] se veıa que, para distintas plataformas basadasen microprocesadores de 32 bits, el consumo medio en modo de espera medido bajo Contikiera varias veces superior al registrado al correr RIOT. Esto es debido al propio tick de sistemaque implementa Contiki: al ser un sistema basado en eventos, lleva un reloj interno que obligaal sistema a despertarse cada cierto tiempo, mientras que RIOT, al ser un sistema operativotickless, no presenta este comportamiento. De este modo, las medidas obtenidas fueron muchomas bajas. Por esto se plantea el desarrollo de un porting de RIOT para la Cookie, dado que yaexiste un porting para el EFR32 [43], como se muestra en la figura 55. La literatura existentehace pensar que es posible mejorar el consumo de la placa si se hace correr en ella un sistemaoperativo capaz de aprovechar mejor sus capacidades.Otra lınea futura a tener en cuenta es la carga de un bootloader en la Cookie de modo quesea posible cargar codigo a traves del conector USB. Actualmente, la unica forma de cargar


Capıtulo 6. Conclusiones y lıneas futuras

Figura 55: Soporte de RIOT-OS para el EFR32

codigo en la placa y depurar es a traves de una placa de depuracion de Silicon Labs, conectadaal cabezal J-Link de la Cookie. La idea de cara al futuro es poder comunicarse con la Cookie,cargar codigo y depurar sin necesidad de utilizar un intermediario.Esto es actualmente un trabajo en curso, se desconoce cual es el bootloader que tiene instaladopor defecto el EFR32, pero se han investigado los diversos proyectos predefinidos de bootloaderque incluye Simplicity y es posible el uso de un bootloader que acepte carga de codigo vıa USBantes de pasar el contador de programa al bloque de codigo de la aplicacion principal. Un dia-grama del proceso de arranque en los procesadores de Silicon Labs de la familia del EFR32 semuestra en la figura 56.

Figura 56: Arranque tıpico de un procesador EFR32

La estructura mas empleada por Silicon Labs es una primera etapa bootloader o elementoseguro (suele estar bastante protegido, llevando un cifrado, etc.), seguido de un bootloader prin-cipal, tras el cual el contador de programa salta al codigo de la aplicacion.Por ultimo, en cuando a las pruebas experimentales, queda pendiente para el futuro la reali-zacion de pruebas de estres sobre la red inalambrica. En este sentido, todavıa no se conoce lacapacidad de los nodos para soportar niveles altos de trafico en la red. El siguiente paso logicoen la caracterizacion de los nodos es someterlos a situaciones de congestion de la red y deter-minar el punto a partir del cual colapsaran, de modo que se conozca el margen de seguridad



del que se dispone de cara a futuros despliegues.


Capıtulo 6. Conclusiones y lıneas futuras



7. Planificacion del proyecto

A continuacion se explican los aspectos organizativos relativos a este trabajo, desde el costedel mismo a la distribucion de las tareas en el tiempo a lo largo de los pasados meses.Se detallara la planificacion del proyecto con la ayuda de la EDP y el diagrama de Gantt,incluyendo las actividades realizadas a lo largo del proyecto y el tiempo empleado en cada unade ellas.

7.1. Estructura de Descomposicion del Proyecto

La Estructura de Descomposicion del Proyecto (EDP) es una descomposicion jerarquica deltrabajo que sera ejecutado a lo largo del proyecto, con el fin de lograr los objetivos del mismo.En ella se organiza y define el alcance del proyecto. Divide el trabajo en porciones pequenas yde facil manejo, donde cada nivel descendente representa una definicion en mayor detalle deltrabajo del proyecto. El trabajo comprendido dentro de los paquetes de trabajo, el nivel masbajo de la EDP, puede programarse y ser supervisado y controlado. La EDP se presenta enlas figuras 57, 58, 59, 60, 61 y 62. Debido a problemas de espacio en el caso de mostrar laEDP completa en una sola vista, se ha dividido en los distintos diagramas partiendo del nivelsuperior, correspondientes a las tareas de primer nivel. Las tareas se han agrupado atendiendoa su naturaleza, en los cinco grupos siguientes:

Gestion del proyecto: comprende la definicion del alcance y los objetivos del proyecto,reuniones de planificacion con el tutor del trabajo y actividades derivadas de estas.

Formacion: incluye el estudio de las diversas areas de conocimiento necesarias para larealizacion del proyecto.

Herramientas: comprende la instalacion y aprendizaje para el manejo de las distintasherramientas software empleadas en el proyecto.

Desarrollo del trabajo: las actividades relacionadas directamente con el desarrollo delproyecto, incluyendo el analisis y porting del sistema operativo, la validacion del hardwareo la realizacion de las pruebas.

Redaccion del TFM: comprende las tareas de documentacion del trabajo y la redaccionde la memoria del mismo.

Figura 57: EDP: nivel superior


Capıtulo 7. Planificacion del proyecto

Figura 58: EDP: gestion del proyecto

Figura 59: EDP: formacion

Figura 60: EDP: herramientas



Figura 61: EDP: desarrollo del trabajo

Figura 62: EDP: redaccion del TFM

7.2. Planificacion temporal

Para mostrar la duracion de las tareas de las tareas del proyecto y su distribucion en eltiempo, se hara uso del diagrama de Gantt. El diagrama de Gantt es un metodo grafico deprogramacion de tiempos en proyectos, con la finalidad de representar el tiempo de dedicaciona cada una de las actividades del proyecto. Debido a la relativa sencillez a la hora de interpretar eldiagrama, es la herramienta mas comunmente empleada a la hora de representar la distribuciontemporal.El presente trabajo comienza el dıa 1/10/2018, con la incorporacion al proyecto SCOTT, ytermina el 21/6/2019. El diagrama con la planificacion del trabajo a lo largo de estos mesesse presenta en la figura 63, y ha sido realizado con la ayuda de la herramienta web GanttPro,disponible para su uso de forma grauita.



Figura 63: Diagrama de Gantt del proyecto



7.3. Presupuesto del proyecto

El presupuesto necesario para la realizacion del proyecto se adjunta en la tabla 4, en la quecada recurso utilizado aparece segun las unidades u horas empleadas, su coste unitario y elsubtotal resultante, desglosado con y sin IVA.Para la realizacion de las distintas pruebas se llego a emplear un total de hasta 5 Cookies deforma simultanea, dependiendo de la prueba.El software utilizado en el proyecto esta disponible de forma gratuita en la red bajo diversaslicencias. Esto abarca desde el software de virtualizacion VMWare Workstation 15 Player paracrear la maquina virtual (modelo Freemium, gratuito en su version basica y de pago en la pro-fesional) o el sistema operativo Ubuntu 18.04.2 LTS de 64 bits (GNU General Public License,GPL) que se ejecuta en la misma, ası como el codigo de Contiki-NG (Berkeley Software Distri-bution, BSD) que utilizan las Cookies o el entorno Eclipse (Eclipse Public License, EPL) sobreel que se ha desarrollado la mayor parte del proyecto.En cuanto al material auxiliar como equipos informaticos o aparatos de medicion, equipos desoldadura, etc., se han empleado los equipos ya existentes en el CEI y no ha sido necesaria lacompra de equipos adicionales expresamente para el proyecto.Se ha estimado el coste asociado al consumo electrico de los equipos informaticos y aparatoselectronicos empleados teniendo en cuenta un coste medio aproximado de 0.10667 e/kWh, ob-tenido en [6] para el dıa 19/06/2019. En cuanto al consumo de los equipos, se ha estimado unconsumo aproximado de 250 W. Para estimar tanto el coste asociado al consumo electrico comoel coste de los recursos humanos empleados, se considera un perıodo del 1/10/2018 al 21/6/2019,lo que supone un total de 179 dıas laborables a 8 horas diarias de jornada, resultando en untotal orientativo de 1432 horas. Este total incluye tanto las horas dedicadas a la realizacion delproyecto SCOTT como aquellas destinadas al presente Trabajo de Fin de Master.Por ultimo, es necesario mencionar que no se ha tenido en cuenta ningun gasto de amortizacionrelativo al equipo informatico empleado ni a las Cookies. En el primer caso, este concepto se hadespreciado directamente. En el segundo, se ha considerado una perdida de valor ya incluidaen el coste total de las placas.

Concepto Uds. Coste/ud. Subtotal s/IVA IVA (21%) Subtotal

Licencias - - - - 0Cookies 5 (u) 67,58 e/u 279,26 58,64 337,9

Consumo equipos 358 (kWh) 0,10667 e/kWh 31,56 6,63 38,19Proyectante 1432 (h) 8,50 e/h 10059,50 2112,5 12172

Total 12548,09 e

Cuadro 4: Presupuesto del proyecto

Por tanto, el presupuesto total de este Trabajo de Fin de Master asciende a 12548,09 e.Cabe destacar el uso de software libre, que reduce los costes en este aspecto a cero.




Referencias

[1] Advanticsys - TelosB. url: https://www.advanticsys.com/shop/mtmcm5000msp-p-14.html.

[2] Arduino website. url: https://www.arduino.cc/.

[3] Beyond Interoperability – Pushing the Performance of SensorNetwork IP Stacks. url:http://dunkels.com/adam/ko11beyond.pdf.

[4] Contiki: origen del nombre. url: https://en.wikipedia.org/wiki/Contiki.

[5] Contiki-ng documentation. url: https://github.com/contiki-ng/contiki-ng/wiki.

[6] Coste medio del kWh. url: https://tarifaluzhora.es/.

[7] CRC Basics (Digikey). url: https://www.digikey.com/eewiki/display/microcontroller/CRC+Basics.

[8] Y. Du y K.T. Chan. “System Performance of Concatenated STBC and BlockTurboCodes in Dispersive Fading Channels”. En: EURASIP Journal on Applied Signal Pro-cessing (2005), pags. 844-851. doi: 10.1155/ASP.2005.844. url: https://pdfs.

semanticscholar.org/f032/2f270366e1bd0120d5831d459915465fef98.pdf.

[9] A. Dunkels. The ContikiMac Radio Duty Cycling Protocol. Inf. tec. Uppsala, Sweden,2011. url: http://dunkels.com/adam/dunkels11contikimac.pdf.

[10] Eclipse Foundation. url: https://www.eclipse.org/.

[11] Edge/Fog Computing: del Cloud hacia la computacion en los dispositivos. url: https://www.gradiant.org/blog/edge-fog-computing-cloud/.

[12] Joakim Eriksson. Contiki-ng Port to EFR32. url: https://github.com/joakimeriksson/contiki-ng/tree/contrib/efr32.

[13] Gregory Ewing. Reverse-Engineering a CRC Algorithm. Inf. tec. 2010. url: http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html.

[14] J. Portilla G. Mujica J.-S. Lee y T. Riesgo. “The Extreme Edge at the Bottom of theInternet of Things: A Review”. En: IEEE Sensors Journal 19.9 (2019), pags. 3179-3190.doi: 10.1109/JSEN.2019.2891911. url: https://ieeexplore.ieee.org/stamp/

stamp.jsp?tp=&arnumber=8607067.

[15] Aruna U. Gawade y Narendra Shekokar. “Lightweight Secure RPL : A need in IoT”.En: 2017 International Conference on Information Technology (ICIT 2017). (Singapore,27-29 de dic. de 2017). doi: 10.1109/ICIT.2017.31. url: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8423910.

[16] gcc The Hard Way: How to Include Functions from the Math Library. url: https://medium.com/@larmalade/gcc-the-hard-way-how-to-include-functions-from-

the-math-library-1cfe60f24a7a.

[17] IEEE 802.15.4v-2017. url: https://standards.ieee.org/standard/802_15_4v-2017.html.

[18] Internet of Things (IoT) connected devices installed base worldwide from 2015 to 2025(in billions). url: https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/.

[19] IoT Connectivity – IoT Protocol Layers. url: http://www.infiniteinformationtechnology.com/iot-connectivity-iot-protocol-layers.

[20] ISO/IEC 20922:2016 - Message Queuing Telemetry Transport (MQTT). url: https:

//www.iso.org/standard/69466.html.


https://www.advanticsys.com/shop/mtmcm5000msp-p-14.html

https://www.advanticsys.com/shop/mtmcm5000msp-p-14.html

https://www.arduino.cc/

http://dunkels.com/adam/ko11beyond.pdf

https://en.wikipedia.org/wiki/Contiki

https://github.com/contiki-ng/contiki-ng/wiki

https://tarifaluzhora.es/

https://www.digikey.com/eewiki/display/microcontroller/CRC+Basics

https://www.digikey.com/eewiki/display/microcontroller/CRC+Basics

https://doi.org/10.1155/ASP.2005.844

https://pdfs.semanticscholar.org/f032/2f270366e1bd0120d5831d459915465fef98.pdf

https://pdfs.semanticscholar.org/f032/2f270366e1bd0120d5831d459915465fef98.pdf

http://dunkels.com/adam/dunkels11contikimac.pdf

https://www.eclipse.org/

https://www.gradiant.org/blog/edge-fog-computing-cloud/

https://www.gradiant.org/blog/edge-fog-computing-cloud/

https://github.com/joakimeriksson/contiki-ng/tree/contrib/efr32

https://github.com/joakimeriksson/contiki-ng/tree/contrib/efr32

http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

https://doi.org/10.1109/JSEN.2019.2891911

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8607067


https://doi.org/10.1109/ICIT.2017.31



https://medium.com/@larmalade/gcc-the-hard-way-how-to-include-functions-from-the-math-library-1cfe60f24a7a



https://standards.ieee.org/standard/802_15_4v-2017.html

https://standards.ieee.org/standard/802_15_4v-2017.html

https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

http://www.infiniteinformationtechnology.com/iot-connectivity-iot-protocol-layers

http://www.infiniteinformationtechnology.com/iot-connectivity-iot-protocol-layers

https://www.iso.org/standard/69466.html

https://www.iso.org/standard/69466.html

[21] Yung-Wei Kao y col. “Physical Access Control Based on QR Code”. En: 2011 InternationalConference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC2011). (Beijing, China, 10-12 de oct. de 2011). doi: 10.1109/CyberC.2011.55. url:https://ieeexplore.ieee.org/abstract/document/6079444.

[22] H.-S. Kim y col. “System architecture directions for post-soc/32-bit networked sensors”.En: Proceedings of the 16th ACM Conference on Embedded Networked Sensor Systems(Sensys ’18). (Shenzhen, China, 4-7 de nov. de 2018). doi: 10.1145/3274783.3274839.url: https://dlnext.acm.org/doi/abs/10.1145/3274783.3274839.

[23] Prof. Dr. W. Kowalk. CRC Cyclic Redundancy CheckAnalysing and Correcting Errors.Inf. tec. 2006. url: http://einstein.informatik.uni-oldenburg.de/papers/CRC-BitfilterEng.pdf.

[24] La expedicion Kon-Tiki. url: https://en.wikipedia.org/wiki/Kon-Tiki_expedition.

[25] Silicon Labs. AN0007.1: MCU and Wireless SoC Series 1 Energy Modes. 2017. url:https://www.silabs.com/documents/public/application-notes/an0007.1-efr32-

efm32-series-1-energymodes.pdf.

[26] Silicon Labs. efr32mg12-datasheet. 2018. url: https://www.silabs.com/documents/public/data-sheets/efr32mg12-datasheet.pdf. (accessed: 02.18.2019).

[27] Silicon Labs. si7021-datasheet. 2016. url: https : / / www . silabs . com / documents /

public/data-sheets/Si7021-A20.pdf. (accessed: 02.18.2019).

[28] Libelium - Waspmote website. url: http://www.libelium.com/products/waspmote/.

[29] Making sense of interoperability: Protocols and Standardization initiatives in IOT. url:https://pdfs.semanticscholar.org/cc70/63734f97701e853a4fb8830f64f16f11df92.

pdf?_ga=2.198780134.834020194.1561574870-1790811385.1561574870r.

[30] Modulacion de senales. url: https : / / w3 . ual . es / ~vruiz / Docencia / Apuntes /

Transmission/04-Modulacion/index.html.

[31] K. Nagata y F. Nemenzo. “Some Properties of Binary Gray Code”. En: 2015 Internatio-nal Conference on Computer Application Technologies (CCATS). (Matsue, Japan, 31 deago.-2 de sep. de 2015). doi: 10.1109/CCATS.2015.27. url: https://ieeexplore.ieee.org/document/7372317.

[32] Packet format for 6LoWPAN/AD6LoWPAN? url: https://ez.analog.com/wireless-sensor-networks-reference-library/ad6lowpan/f/q-a/4641/packet-format-for-

6lowpan-ad6lowpan.

[33] Prolansys Technologies - Server Virtualization. url: https://prolansystechnologies.wordpress.com/2014/11/11/server-virtualization/.

[34] ¿Que son los procesadores ARM? url: https://www.ibertronica.es/blog/tutoriales/que-son-los-procesadores-arm/.

[35] Raspberry Pi website. url: https://www.raspberrypi.org/.

[36] RFC 4944 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks. url: https://tools.ietf.org/html/rfc4944.

[37] RFC 6206 - The Trickle Algorithm. url: https://tools.ietf.org/html/rfc6206.

[38] RFC 6282 - Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Net-works. url: https://tools.ietf.org/html/rfc6282.

[39] RFC 6550 - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. url: https://tools.ietf.org/html/rfc6550.

[40] RFC 6719 - The Minimum Rank with Hysteresis Objective Function. url: https://

tools.ietf.org/html/rfc6719.


https://doi.org/10.1109/CyberC.2011.55

https://ieeexplore.ieee.org/abstract/document/6079444

https://doi.org/10.1145/3274783.3274839

https://dlnext.acm.org/doi/abs/10.1145/3274783.3274839

http://einstein.informatik.uni-oldenburg.de/papers/CRC-BitfilterEng.pdf

http://einstein.informatik.uni-oldenburg.de/papers/CRC-BitfilterEng.pdf

https://en.wikipedia.org/wiki/Kon-Tiki_expedition

https://www.silabs.com/documents/public/application-notes/an0007.1-efr32-efm32-series-1-energymodes.pdf

https://www.silabs.com/documents/public/application-notes/an0007.1-efr32-efm32-series-1-energymodes.pdf

https://www.silabs.com/documents/public/data-sheets/efr32mg12-datasheet.pdf

https://www.silabs.com/documents/public/data-sheets/efr32mg12-datasheet.pdf

https://www.silabs.com/documents/public/data-sheets/Si7021-A20.pdf

https://www.silabs.com/documents/public/data-sheets/Si7021-A20.pdf

http://www.libelium.com/products/waspmote/

https://pdfs.semanticscholar.org/cc70/63734f97701e853a4fb8830f64f16f11df92.pdf?_ga=2.198780134.834020194.1561574870-1790811385.1561574870r

https://pdfs.semanticscholar.org/cc70/63734f97701e853a4fb8830f64f16f11df92.pdf?_ga=2.198780134.834020194.1561574870-1790811385.1561574870r

https://w3.ual.es/~vruiz/Docencia/Apuntes/Transmission/04-Modulacion/index.html

https://w3.ual.es/~vruiz/Docencia/Apuntes/Transmission/04-Modulacion/index.html

https://doi.org/10.1109/CCATS.2015.27

https://ieeexplore.ieee.org/document/7372317


https://ez.analog.com/wireless-sensor-networks-reference-library/ad6lowpan/f/q-a/4641/packet-format-for-6lowpan-ad6lowpan



https://prolansystechnologies.wordpress.com/2014/11/11/server-virtualization/

https://prolansystechnologies.wordpress.com/2014/11/11/server-virtualization/

https://www.ibertronica.es/blog/tutoriales/que-son-los-procesadores-arm/

https://www.ibertronica.es/blog/tutoriales/que-son-los-procesadores-arm/

https://www.raspberrypi.org/

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








[41] RFC 6775 - Neighbor Discovery Optimization for IPv6 over Low-Power Wireless PersonalArea Networks (6LoWPANs). url: https://tools.ietf.org/html/rfc6775.

[42] RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format. url:https://tools.ietf.org/html/rfc8259.

[43] RIOT - The friendly OS for IoT. url: https://github.com/RIOT-OS/RIOT.

[44] Segger - J-Link Software and Documentation Pack. url: https://www.segger.com/downloads/jlink#J-LinkSoftwareAndDocumentationPack.

[45] P. Suresh y col. “A state of the art review on the Internet of Things (IoT) history,technology and fields of deployment”. En: 2014 International Conference on Science En-gineering and Management Research (ICSEMR). (Chennai, India, 27-29 de nov. de 2014).doi: 10.1109/ICSEMR.2014.7043637. url: https://ieeexplore.ieee.org/document/7043637.

[46] Tutorial I2C - Sparkfun. url: https://learn.sparkfun.com/tutorials/i2c/all.

[47] Understanding and implementing CRC (Cyclic Redundancy Check) calculation. url: http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html.

[48] Web del proyecto SCOTT. url: https://scottproject.eu/.

[49] What is the OSI Model? url: https://www.bmc.com/blogs/osi-model-7-layers/.

[50] Which fields are compressed in a header compression in 6LoWPAN? url: https://www.quora.com/Which-fields-are-compressed-in-a-header-compression-in-6LoWPAN.

[51] Harun Baraki Xuan Thang Nguyen Huu Tam Tran y Kurt Geihs. FRASAD: A Fra-mework for Model-driven IoT Application Development. Inf. tec. 2015. url: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7389085.




https://github.com/RIOT-OS/RIOT

https://www.segger.com/downloads/jlink#J-LinkSoftwareAndDocumentationPack

https://www.segger.com/downloads/jlink#J-LinkSoftwareAndDocumentationPack

https://doi.org/10.1109/ICSEMR.2014.7043637



https://learn.sparkfun.com/tutorials/i2c/all

http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html

http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html

https://scottproject.eu/

https://www.bmc.com/blogs/osi-model-7-layers/

https://www.quora.com/Which-fields-are-compressed-in-a-header-compression-in-6LoWPAN

https://www.quora.com/Which-fields-are-compressed-in-a-header-compression-in-6LoWPAN



Documents

Validaci on Hardware de plataforma para IoT en el Edge y porting de Contiki …oa.upm.es/65537/1/TFM_PABLO_MERINO_CALERO.pdf · 2020. 11. 24. · Tras la intro-ducci on se presenta