En el sexto de esta serie de artículos sobre KNX IoT, Bruno Johnson y Wouter van der Beek explican cómo utilizar Thread para KNX IoT.
A lo largo de los últimos años, la transformación digital viene siendo uno de los principales temas estratégicos en las agendas de las reuniones de los consejos de administración de las empresas. 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) a dispositivos periféricos que son la interfaz del cliente. Empresas de todo tipo y tamaño involucradas en la automatización de edificios comerciales han estado pidiendo soluciones IoT inalámbricas para hacer que eso fuera una realidad, y KNX Association ha respondido lanzando la API KNX IoT Point (KNX IoT).
Introducción a Thread
Como ya explicamos en nuestro artículo ‘KNX IoT: Parte 2 – Las ventajas de Thread‘, Thread es una red de malla basada en IPv6. En este artículo explicaremos Thread desde un punto de vista más técnico y cómo puede usarse para los dispositivos KNX IoT.
La red de malla de Thread está compuesta por diferentes roles de red, tal y como se muestra en la Figura 1.
Router de borde de Thread
El router de borde de Thread (BR) es la entidad de red que conecta la red de Thread a una red de TI 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 de TI. También es necesario para otras comunicaciones de red, por ejemplo cuando se utiliza el router KNX IoT (ver Parte 5 de esta serie) para conectar KNX IoT a otros dispositivos KNX.
El router de borde de Thread es una función de red estándar. Este producto puede tener múltiples aspectos y puede basarse en equipos de red, por ejemplo, Thread puede ser una extensión de un router Wi-Fi. También son posibles otras ejecuciones como, por ejemplo, integrándolo con el dominio de la aplicación. Ten en cuenta que Thread permite utilizar varios routers fronterizos en una red Thread, por redundancia.
Esto permite que las redes de Thread se dividan intencionadamente o no (si un router falla por alguna razón), sin interrumpir el funcionamiento.
Junto al router de borde, Thread especifica los tipos de dispositivos que pueden asumir las distintas funciones de red. Para explicar los distintos tipos de dispositivos, primero hay que entender las funciones de la red Thread.
Función Router
El nodo Router es la entidad de red que enruta los mensajes IPv6 entre los nodos de Thread, ya sean otros nodos Router o Dispositivos finales. Esta es una función de red de la red Thread.
Función Dispositivo final
La función Dispositivo final es un nodo hoja. Desde el punto de vista de la red, sólo habla con su primario (un Router). Estas funciones de Dispositivo final son el REED (Dispositivo final apto para router) o el Dispositivo final.
Función Líder
La función Líder es una función específica de un nodo Router. El primer nodo Router de la red se convertirá en Líder. El Líder es el responsable de la toma de decisiones de red como, por ejemplo, el Líder puede convertir dispositivos Aptos para Router a Router para mejorar la conectividad, si es necesario. Solo hay un Líder en una red Thread. Si el Líder fracasa, otro Router se convertirá en Líder. Todos los routers almacenan los datos de la red, pero sólo el Líder puede modificarlos.
REED (Dispositivo final apto para router)
El dispositivo REED puede tener la función de router Thread o el de Dispositivo final de Thread, y se convertirá dinámicamente en un Router a partir de un Dispositivo final a medida que la red Thread se amplíe, y a la inversa, pasará de Router a Dispositivo final a medida que la red se contraiga. El dispositivo REED es muy útil porque permite que la red Thread se autogestione.
ED (Dispositivo final)
Este dispositivo admite únicamente la función de Dispositivo final. El ED solo se puede conectar a un dispositivo con la función Router o Router de borde.
SED (Dispositivo final durmiente)
Este dispositivo admite únicamente la función de Dispositivo final, pero tiene la capacidad de entrar en reposo. La principal diferencia es que cuando el dispositivo entra en reposo, se desvincula de la red Thread (es decir, no hay comunicación por radiofrecuencia). El Router primario almacenará en la memoria caché el tráfico entrante para dicho dispositivo, de modo que cuando vuelva a estar activo, recibirá el tráfico entrante.
El dispositivo SED sólo puede conectarse a un dispositivo con rol de Router o al Router de borde, y cambiará automáticamente de primario si pierde la conectividad.
Ampliador de malla
Este dispositivo no se ha mencionado antes, pero en realidad es un router alimentado por línea o dispositivo REED. La finalidad de este dispositivo es ampliar el alcance de la red de malla, es decir, puede colocarse donde un enlace de red directo sea débil. Este dispositivo puede ser un dispositivo Thread puro, lo que significa que no se implementa ninguna funcionalidad de aplicación en el dispositivo.
Implicaciones
Así que, ¿cómo se aplican estas funciones 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 una decisión independiente de cuál debe ser la función del dispositivo KNX, pero ¿lo es?
Todos los dispositivos KNX IoT implementarán un conjunto de bloques funcionales: es decir, la finalidad del dispositivo. La selección del hardware que compondrá la finalidad del dispositivo dependerá de si éste se va a alimentar por línea (siempre encendido) o mediante fuentes de baja energía (como la recolección de energía o la alimentación por batería). La regla general es que si el aparato se alimenta por línea, hay que desarrollar un aparato REED. Para todas las demás fuentes, se puede construir un Dispositivo final e incluso un Dispositivo final durmiente si la función del dispositivo KNX IoT se puede realizar con hardware que consuma poca energía o que se pueda apagar periódicamente (es decir, que no consuma energía activa).
Ejemplos de dispositivos ED y SED KNX IoT
Por ejemplo, si un dispositivo sólo envía datos de manera periódica, como un sensor de temperatura, y si la adquisición de datos del sensor de temperatura es de bajo consumo, se puede crear un SED. Si la adquisición de datos del sensor es continua, entonces todavía se puede hacer un SED (para evitar el consumo adicional de energía utilizado por el transmisor de radiofrecuencia), pero podría ser un dispositivo ED.
Los tipos de dispositivos que tienen solicitudes entrantes y requieren una respuesta oportuna pueden ser ED o REED.
Los tipos de dispositivos que tienen solicitudes entrantes, pero que son lentos al actuar sobre esa solicitud, como un sensor de calidad del aire, se pueden ejecutar como un SED.
Los dispositivos que requieren alimentación debido a su hardware adicional, deben ser REED. Ejemplos de ello son las luminarias.
Resumen
Thread permite que los dispositivos KNX IoT se desarrollen de forma que se adapten al presupuesto de energía necesario. La elección de REED, ED o SED debe hacerse en función de las necesidades de potencia de los periféricos que componen la función del dispositivo.
Bruno Johnson y Wouter van der Beek son el Director general y el Director de operaciones, respectivamente, de Cascoda Limited. Cascoda es una empresa de comunicaciones que fabrica radios y módulos semiconductores IoT seguros, y lidera el desarrollo de estándares de comunicaciones IoT seguras para edificios y ciudades inteligentes. Sus productos resuelven los problemas de alcance, fiabilidad, seguridad, potencia y escalabilidad del IoT industrial y comercial mediante innovaciones patentadas y la aplicación de los últimos estándares más seguros, todo ello integrado en módulos IoT económicos de consumo ultrabajo.
