En el sexto artículo de esta serie sobre KNX IoT, Bruno Johnson y Wouter van der Beek explican cómo utilizar Thread para KNX IoT.
La transformación digital ha sido uno de los principales temas estratégicos en las agendas de las reuniones de los consejos de administración de las empresas durante los últimos años. La oportunidad de desarrollar servicios digitales a partir de aplicaciones basadas en la nube requiere conexiones de red basadas en el protocolo de Internet (IPv6) con dispositivos periféricos que se convierten en la interfaz con el cliente. Empresas de todo tipo y tamaño del sector de la automatización de edificios comerciales han solicitado soluciones inalámbricas de IoT para hacer esto posible, y la Asociación KNX ha respondido lanzando la KNX IoT Point API (KNX IoT).
Introducción al hilo
Como ya se explicó en nuestro artículo «KNX IoT: Parte 2 - las ventajas de Thread», Thread es una red en malla basada en IPv6. En este artículo explicaremos Thread con más detalle técnico, incluyendo cómo se puede utilizar para dispositivos KNX IoT.
La red en malla Thread contiene diversas funciones de red Thread, tal y como se muestra en la figura 1.
Enrutador de borde de Thread
El enrutador de borde Thread (BR) es la entidad de red que conecta la red Thread a la red informática más amplia. Esta entidad es necesaria cuando la herramienta de software de configuración KNX, ETS, se ejecuta como una aplicación de PC en la red informática. También es necesario para otras comunicaciones de red, por ejemplo, utilizando el enrutador KNX IoT (véase Parte 5 de esta serie) para conectar KNX IoT a otros dispositivos KNX.
El enrutador perimetral Thread es una función de red estándar. Este producto puede tener múltiples aspectos y basarse en equipos de red; por ejemplo, Thread puede ser una extensión de un router Wi-Fi. Además, son posibles otras implementaciones, como integrarlo en el ámbito de las aplicaciones. Ten en cuenta que Thread permite utilizar varios routers de frontera en una red Thread, con fines de redundancia.
Esto permite que las redes Thread se se dividan ya sea de forma intencionada o no (en caso de que un router falle por cualquier motivo), sin interrumpir el funcionamiento.
Además del enrutador de borde, Thread especifica los tipos de dispositivos que pueden asumir las diferentes funciones de red. Para explicar los distintos tipos de dispositivos, primero hay que comprender las funciones de red de Thread.
Función de enrutador
El nodo enrutador es la entidad de red que enruta los mensajes IPv6 entre los nodos de Thread, ya sean otros nodos enrutadores o dispositivos finales. Se trata de una función de red de la red Thread.
Función de dispositivo final
La función de dispositivo final es un nodo hoja. Desde el punto de vista de la red, solo se comunica con su nodo padre (un enrutador). Estas funciones de dispositivo final son el REED (dispositivo final apto para enrutador) o el dispositivo final.
Rol de líder
El líder es un rol específico de un nodo enrutador. El primer nodo enrutador de la red se convertirá en líder. El líder es responsable de tomar decisiones relacionadas con la red; por ejemplo, puede promover dispositivos aptos para enrutador a enrutadores para mejorar la conectividad si es necesario. Solo hay un líder en una red Thread. Si el líder falla, otro enrutador pasará a ser el líder. Todos los enrutadores almacenan los datos de la red, pero solo el líder puede realizar cambios en ellos.
REED (dispositivo final apto para enrutador)
El dispositivo REED puede desempeñar el papel de enrutador Thread o de dispositivo final Thread, y se actualizará dinámicamente de dispositivo final a enrutador a medida que la red Thread se expanda y, a la inversa, se degradará de enrutador a dispositivo final a medida que la red se contraiga. El dispositivo REED resulta muy útil, ya que permite que la red Thread se autogestione.
ED (dispositivo final)
Este dispositivo solo admite la función de dispositivo final. El dispositivo ED solo puede conectarse a un dispositivo con función de enrutador o al enrutador fronterizo.
SED (dispositivo terminal en modo de suspensión)
Este dispositivo solo admite la función de «dispositivo final», pero tiene la capacidad de entrar en modo de suspensión. La principal diferencia es que, cuando el dispositivo entra en modo de suspensión, se desconecta de la red Thread (es decir, no hay comunicación por radio). El enrutador principal almacenará en caché el tráfico entrante destinado a dicho dispositivo, de modo que, cuando vuelva a estar activo, recibirá dicho tráfico.
El dispositivo SED solo puede conectarse a un dispositivo con el rol de enrutador o al enrutador de borde, y cambiará automáticamente de enrutador principal si pierde la conectividad.
Extensor de malla
Este dispositivo no se ha mencionado anteriormente, pero en realidad es un enrutador alimentado por la red eléctrica o un dispositivo REED. La finalidad de este dispositivo es ampliar el alcance de la red en malla; es decir, puede colocarse en lugares donde la conexión directa a la red sea débil. Este dispositivo puede ser un dispositivo Thread puro, lo que significa que no tiene implementada ninguna funcionalidad de aplicación.
Implicaciones
Entonces, ¿cómo se aplican estas funciones de Thread a los dispositivos KNX IoT?
Los dispositivos KNX IoT basados en Thread tendrán que implementarse como dispositivos REED, ED o SED; de lo contrario, no formarán parte de la red Thread. Esto parecería ser una decisión independiente de cuál debe ser la función del dispositivo KNX, pero ¿lo es realmente?
Todos los dispositivos KNX IoT implementarán un conjunto de bloques funcionales: es decir, la finalidad del dispositivo. La selección del hardware para cumplir dicha finalidad dependerá de si el dispositivo se alimenta de la red eléctrica (siempre encendido) o de fuentes de baja energía (como la recolección de energía o el funcionamiento con batería). La regla general es que, si el dispositivo se alimenta de la red eléctrica, se debe construir un dispositivo REED. Para todas las demás fuentes, se puede construir un dispositivo final (End Device) e incluso un dispositivo final en modo de reposo (Sleepy End Device) si la función del dispositivo KNX IoT puede realizarse con hardware que consuma poca energía o que pueda apagarse periódicamente (es decir, que no consuma energía en modo activo).
Ejemplos de dispositivos finales (ED) y dispositivos finales en reposo (SED) de KNX IoT
Por ejemplo, si un dispositivo solo envía datos periódicamente, como un sensor de temperatura, y si la adquisición de datos del sensor de temperatura consume poca energía, se puede crear un SED. Si la adquisición de datos del sensor es continua, también se puede crear un SED (para evitar el consumo energético adicional que supone el transmisor de RF), pero podría tratarse de un dispositivo ED.
En el caso de los dispositivos que reciben solicitudes y requieren una respuesta oportuna, el dispositivo puede ser un ED o un REED.
En el caso de los dispositivos que reciben solicitudes, pero cuya respuesta a dichas solicitudes es lenta —como un sensor de calidad del aire—, estos pueden implementarse como SED.
Los dispositivos que requieran alimentación de red debido a su hardware adicional deben diseñarse como REED. Un ejemplo de ello son las luminarias.
Resumen
Thread permite desarrollar dispositivos KNX IoT de forma que se adapten al presupuesto energético requerido. La elección entre REED, ED o SED debe realizarse en función de los requisitos de potencia de los periféricos que conforman la función del dispositivo.
Bruno Johnson y Wouter van der Beek son, respectivamente, director ejecutivo y director de operaciones de Cascoda Limited. Cascoda es una empresa de comunicaciones que fabrica radios y módulos semiconductores seguros para el IoT, y lidera el desarrollo de estándares de comunicaciones seguras para el IoT destinados a edificios inteligentes y ciudades inteligentes. Sus productos resuelven problemas de alcance, fiabilidad, seguridad, consumo y escalabilidad para el IoT industrial y comercial mediante innovaciones patentadas y los estándares más recientes y seguros, todo ello integrado en módulos de IoT económicos y de consumo ultrabajo.
