La “cadena IoT” es una abstracción valida para proyectos de IoT con la cual se pueden describir diferentes componentes sin importar su arquitectura o constructor. Es valida para todos los proyectos de IoT en los que he tenido el gusto de participar.

En este artículo quiero comprobar la aplicabilidad de la cadena para 2 proyectos IoT muy diferentes: El Proyecto de Energía IoT realizado con el ITCR  y Yo Alcalde.

IoT TEC

Sensores y/o Actores

Todos los proyectos de IoT tienen sensores y/o acotres. Estos son los encargados de recolectar data o de actuar basandose en comandos emitidos. En el caso del proyecto en el ITCR se utilizaron sensores de temperatura DS18B20.

El en caso del proyecto Yo Alcalde los “sensores” son los ciudadanos de Curridabat.

Controller

Los sensores y actores no suelen tener por lo general la capacidad de comunicación con la nube y necesitan de cierta inteligencia para hacerlo. En el caso del proyecto del curso, se utilizaron Arduinos como controladores de los sensores de temperatura. Estos se encargaban de monitorear la temperatura en ciclos rápidos, y solo emitir un dato hacia el gateway cuando se cumplia el criterio de suficiente cambio (0,25 K). Si por ejemplo los sensores se evaluan por el controlador cada segundo, pero la temperatura cambia 0,25K en 1 hora, entonces el controlador solo emite 1 valor hacia el gateway por hora. De esa manera garantizamos una compresion inteligente de la data y a la vez no perdemos resolucion cuando hay cambios significativos.

En el caso de Yo Alcalde, el “controlador” es una mezcla entre la conciencia del usuario que reconoce y decide sobre los reportes a hacer, y la interfaz gráfica de un app para telefonos celulares disponible para iOS y Android que le permite seleccionar la categoría adecuada, escribir un comentario y tomar fotos.

Gateway

Es común separar las funciones de controlador y gateway en 2 sistemas diferentes. El primero tiene como meta evaluar los sensores lo más rapido posible y es por lo general un chip de baja capacidad de procesamiento. El segundo, al ser un poco mas potente y poder ejecutar procesos en paralelo, puede sincronizar con la nube sin comprometer la capacidad de recibir datos.

En el proyecto del ITCR se utilizo un Raspberry Pi como gateway. Este se encarga de

  1. recibir la data de los sensores enviada por el controlador,
  2. guardarla en una base de datos local y
  3. enviarla a la nube en un proceso paralelo.

Adicionalmente, el proyecto reailzado con los estudiantes tiene otras metas para el gatway, como las de controlar el controlador (!) y poderlo actualizar de manera remota.

En el caso de Yo Alcalde, el gateway es una parte de la aplicación móvil que se encarga de la transferencia de datos hacia la nube.

Cloud

Tanto Yo Alcalde como el proyecto de energía utilizan un backend llamado Parse. Este tiene las ventajas de ser de código abierto y muy versatil. Se programa en JavaScript, un lenguaje moderno muy apetecido por la comunidad de programadores en el mundo, lo cual hace de Parse un backend muy popular.

Normalmente es en la nube donde se corren algoritmos de analisis de datos  y automatizaciones. Ya que el avanze del proyecto con los estudiantes no está tan avanzado en este ámbito, se crearon algoritmos para matlab que evaluan la data offline.

En el caso de Yo Alcalde, se creó un dashboard donde los funcionarios de la municipalidad pueden interactuar con la data y tomar accion sobre ella. Toda la inteligencia automatizada se encuentra en la nube.

¿Otras aplicaciones para la cadena?

¿Conoce usted otras aplicaciones para esta cadena que se deberían mencionar en este artículo? O ¿tal vez conoce usted estructuras de proyectos donde esta abstracción no aplica? No dude en comunicarmelo para poder generar conocimiento y compartir con la comunidad. Esta discusión enriquecerá mucho las clases de futuros estudiantes en Costa Rica.