Desmitificando IoT. Parte I

Recientemente tuve que preparar una presentación para dar una charla de IoT a estudiantes de Ciclos formativos de Grado Superior, y quise preparar un material exhaustivo, pero a la vez sencillo de explicar y de entender, en el que se identificaran los elementos clave que fundamentan las arquitecturas IoT. En este artículo describiré brevemente cuáles son éstos elementos clave, y cómo se interrelacionan entre sí para que todo funcione adecuadamente.

La primera diapositiva que mostré a los asistentes contenía únicamente el mensaje “¿Qué es IoT?”, e invitaba a los estudiantes a reflexionar sobre el significado del acrónimo (Internet Of Things) y las implicaciones que se esconden detrás de la idea de que “las cosas” se conecten a “Internet”.

A continuación, mostré, en otra diapositiva, la típica imagen que suele mostrarse en estos casos, de una colección heterogénea de dispositivos (sensores, electrodomésticos…) conectados entre sí a través de “la nube”:

En definitiva, y haciendo mención a la definición de IoT en la Wikipedia, concluía con los alumnos en que IoT se refiere a la interconexión digital de objetos cotidianos (o no tan cotidianos) con Internet, con propósitos diferentes según el caso de uso (envío de telemetría por parte de sensores de temperatura, presión, humedad, o el envío de comandos para encender o apagar aparatos remotos, como por ejemplo bombillas inteligentes).

Los asistentes asentían con la cabeza, y se mostraban cómodos con la imagen anterior; dispositivos apuntando a la nube con líneas y flechas en ambos sentidos. Todos sabían qué es Internet, y todos conocían o tenían algún dispositivo relacionado con IoT en sus casas capaz de conectarse por sí solo a la red WIFI de sus hogares (algunos tenían Alexa, otros Google Nest Mini, otros una bombilla inteligente…). A priori, no parecía (tengo la impresión) que yo tuviera nada para impresionarlos, nada nuevo que contarles…

Entonces comencé a lanzar preguntas como: “¿Qué hay dentro de esa nube? ¿Los dispositivos se hablan directamente entre ellos? ¿Cómo se gestiona la seguridad en las comunicaciones? ¿Todos los dispositivos se conectan directamente a internet? ¿Creéis que los sensores que existen en el mercado (temperatura, humedad…) vienen con ranuras SIM o tienen antena WIFI para conectarse a internet?” (la audiencia dudaba, los rostros ya no asentían, ceños fruncidos y murmullo generalizado). Detrás de estas preguntas están, en mi opinión, las claves de IoT, y son las que utilizaré en este artículo para desmitificar su funcionamiento.

¿Qué hay dentro de la nube?

Los alumnos que asistieron a la charla lo tenían bastante claro: “la nube es Internet y dentro está la red mundial de computadores” – dijo uno de los asistentes. Efectivamente, y para completar su respuesta dedicamos un rato a repasar los orígenes de Internet, el protocolo TCP/IP y algunas curiosidades que me confesaron que no conocían (como por ejemplo uno de los varios cables submarinos que tiene Google para sus servicios de Cloud, el cable Dunant, o los puntos neutros de Internet). Para todos aquellos interesados en este tipo de curiosidades sobre Internet, recomiendo esta Charla TED de Andrew Blum: “Discover the physical side of the internet”.

Así pues, en IoT “las cosas” se comunican utilizando la red de redes, y por extensión, utilizando sus protocolos (no se tratarán en este artículo otras aproximaciones específicas para arquitecturas LAN, ya que, como veremos más adelante, las arquitecturas IoT pueden implementarse localmente. En este caso, consideraré estas arquitecturas como “basadas en IoT”, pero no soluciones IoT).

¿Los dispositivos se hablan directamente entre ellos?

Esta pregunta esconde una de las claves más importantes para entender IoT. La respuesta es no (y aunque como en todo en esta vida, siempre puede haber matices, la respuesta general es no). Cuando le decimos a Google Assistant desde la playa, con nuestra conexión 4G, “Hey Google, apaga la luz del salón”, porque nos la dejamos encendida por olvido, no hay, en ningún caso, una comunicación directa entre nuestro dispositivo móvil (o la propia aplicación Google Assistant) y la bombilla inteligente de turno (vamos a suponer que es una bombilla con conectividad WIFI, de las muchas que podemos encontrar en Amazon) enroscada en la lámpara del salón (ninguno conoce la IP del otro). Sin embargo, nuestras palabras son traducidas por Google en un “comando” de apagado, y este comando, codificado en algún servidor de Google Cloud, termina llegando al router de nuestro hogar, y a través del él, a nuestra bombilla (sin que tengamos que “abrir puertos”, como hacíamos en mi época con el eMule). ¿Cómo es esto posible? Vayamos por partes, comenzando por la bombilla. Si “algo” se puede comunicar desde el exterior con nuestra bombilla, sin necesidad de que tengamos que configurar nada en nuestro router, significa que es la bombilla la que, activamente, se conecta al exterior, a ese “algo”, y para hacerlo, nuestra bombilla necesita conocer su IP y a qué puerto conectarse. Si antes comentaba que dos dispositivos en IoT nunca se conectan directamente ¿qué es entonces este elemento intermedio con el que se conecta nuestra bombilla inteligente? Veámoslo en el siguiente gráfico:

Normalmente, cada fabricante/proveedor decide qué tipo de servidor y a través de qué protocolo se conectarán “sus dispositivos” a “su nube”. Sin embargo, en el mundo actual, con tanta diversidad de dispositivos y fabricantes, y ante un público que exige, cada vez más, que unos dispositivos sean compatibles con otros, lo más probable es que nuestra bombilla se conecte a los servidores del proveedor a través de un “IoT broker” mediante el protocolo MQTT. MQTT es un protocolo estándar, que implementa el patrón de mensajería “publish-subscribe”, que funciona normalmente sobre TCP/IP (aunque puede funcionar sobre otros protocolos) y que, por su naturaleza y propósito iniciales, es el candidato perfecto para convertirse en la opción preferente para IoT.

En MQTT, y en el modelo publish-subscribe en general, un suscriptor se suscribe a un “topic” (un topic, o tema, se identifica normalmente en el MQTT broker con un alfanumérico, y debe ser único en el broker), con el propósito de recibir los mensajes que otros, los publicadores, envíen a dicho “topic”. Así pues, nuestra bombilla podría suscribirse al topic “12567SH0208Z” (imaginemos que “12567SH0208Z” es el número de serie de la bombilla), que no tiene por qué existir previamente (es habitual que los brokers de mensajería “creen” topics bajo demanda, en el momento de la primera publicación o suscripción), a la espera de recibir comandos o mensajes de encendido, apagado, regulación de intensidad, cambio de color… que algún publicador (nosotros, el usuario) decida enviar a dicho topic.

Este diagrama (simplificado al máximo para que nos centremos en los conceptos) muestra los pilares fundamentales de las arquitecturas IoT, y si lo llevamos a la implementación, funcionaría. Sin embargo, una arquitectura real de un proveedor de soluciones IoT debería parecerse más a esta arquitectura de despliegue:

En la segunda parte de este artículo veremos la importancia y las ventajas de esta segunda arquitectura de despliegue (ventajas relativas a eficiencia, seguridad, y lo más importante, interoperabilidad). Pero volvamos dos párrafos atrás ¿Cómo sabe el publicador (nuestro dispositivo móvil en este caso) el topic en el que debe publicar los mensajes/comandos para interactuar con nuestra bombilla? Imaginemos el proceso de Unboxing de la bombilla, cuando llega a nuestra casa:

1. Extraemos la bombilla de la caja.
2. La enroscamos en una lámpara con la corriente encendida, comprobando que se enciende.
3. Instalamos la APP del fabricante/proveedor (la que nos indique en el manual de usuario).
4. De una u otra manera, desde la APP, configuramos la bombilla (este tipo de aplicaciones utiliza mecanismos de autodescubrimiento de dispositivos de manera inalámbrica, utilizando Bluetooth, WIFI Direct…), y es en este momento, tras el autodescubrimiento y la configuración, cuando nuestra APP intercambia información con la bombilla (indicándole, por ejemplo, a qué red WIFI y con qué credenciales conectarse). Es en este paso donde la APP podría obtener el número de serie de la bombilla.

El proceso aquí descrito plantea una de las posibles soluciones. Para averiguar el proceso exacto de configuración y suscripción de nuestra bombilla, sería necesario utilizar alguna herramienta como Wireshark para analizar el tráfico en nuestra red local (recomiendo el siguiente artículo para más detalles).

Así pues, en IoT, la comunicación se reduce al envío indirecto de mensajes entre un “publicador” (nosotros, a través de un dispositivo móvil, enviando comandos de encendido y apagado; un sensor de temperatura que envía cada segundo la telemetría recogida del entorno…) y un “suscriptor” (un Dashboard de control que recibe la telemetría del sensor de temperatura y la muestra en pantalla para su análisis; una bombilla a la espera de recibir comandos de encendido, apagado…), utilizando como elemento intermedio de comunicaciones un broker de mensajería (normalmente un broker MQTT).

En la segunda parte de este artículo continuaremos profundizando en los conceptos de IoT, daremos respuesta a las preguntas que nos han quedado pendientes (¿Cómo se gestiona la seguridad en las comunicaciones? ¿Todos los dispositivos se conectan directamente a internet?), y analizaremos en profundidad todos los entresijos que se esconden detrás del “Hey Google, apaga la luz del salón”.