En la tercera entrega de esta serie de artículos sobre KNX IoT, Bruno Johnson y Wouter van der Beek explican los fundamentos de los dispositivos 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 los dispositivos periféricos que actúan como 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 realidad, y la Asociación KNX ha respondido con el lanzamiento de la KNX IoT Point API (KNX IoT).
Conceptos básicos
Para garantizar la compatibilidad con versiones anteriores de otros medios KNX (instalaciones KNX Classic), la especificación KNX IoT del grupo de especificaciones del sistema KNX (3_10_5 KNX IoT Point API) describe:
• Una nueva capa de transporte basada en IPv6, por ejemplo, redes Wi-Fi, Ethernet y basadas en Thread.
• Un nuevo protocolo de comunicación/mensajería que permite los siguientes modos de comunicación:
- Punto a multipunto, sin conexión (multidifusión).
- Punto a punto, sin conexión.
- Punto a punto, orientado a conexión.
Además, el nuevo transporte debe utilizar los mismos puntos de datos que las capas de transporte KNX existentes, tal y como se definen en las especificaciones de Descripciones de Aplicaciones (Volumen 7).
El diseño del nuevo medio de transporte con estas restricciones no modificará la forma en que se aplica actualmente KNX. Se mantiene el mismo enfoque del ETS a la hora de configurar los dispositivos, y estos siguen comunicándose entre sí mediante modo S
La pila tecnológica
Los dispositivos deben poder comunicarse mediante IPv6, independientemente de la capa física utilizada, lo que significa que son compatibles con Ethernet (incluido PoE), Wi-Fi y Thread. De hecho, Thread se basa intrínsecamente en IPv6.
Detección
Para comunicarse a través de IP, es necesario conocer la dirección IP y el puerto del dispositivo KNX. Para obtener estos datos, se utilizan dos mecanismos de detección diferentes.
1) El descubrimiento mDNS es un protocolo que utiliza el DNS de multidifusión (mDNS) para encontrar dispositivos y servicios en la red local sin conocer su dirección IP. También se conoce como «configuración cero», Bonjour, o Avahi. Se utiliza ampliamente en dispositivos domésticos inteligentes, dispositivos inalámbricos Arduino, impresoras, altavoces, dispositivos de almacenamiento en red, etc. Funciona enviando paquetes a todos los nodos de la red para resolver nombres de host y consultar servicios. Se puede utilizar junto con el servicio de descubrimiento de servicios DNS (DNS-SD) para buscar y resolver servicios basándose bien en el nombre de host, bien en el servicio. Solo funciona para el dominio de nivel superior (TLD) .local.
El descubrimiento mDNS permite la detección mediante:
- Número de serie.
- Dirección individual.
- Modo de programación.
2) El descubrimiento mediante CoAP (Protocolo de Aplicaciones Restringidas) es una solicitud especial de CoAP destinada a detectar los recursos de un host conocido. Para detectar el host, se puede utilizar una solicitud de multidifusión, pero el servidor debe admitirla.
El descubrimiento CoAP permite el descubrimiento mediante:
- Número de serie.
- Dirección individual.
- Modo de programación.
- Detección de un dispositivo que contenga un punto de datos específico.
- Detección de un dispositivo que contiene un bloque funcional específico.
Transportes de telegramas
El siguiente nivel es la comunicación a través de IPv6 utilizando CoAP. Se trata de la capa que transporta los telegramas KNX desde el remitente hasta el destino. Esto se consigue mediante el uso de URL. La forma más sencilla de entender CoAP es considerar que es equivalente a HTTP, ya que implementa el envío de mensajes mediante el paradigma de solicitud y respuesta, entre un cliente (iniciador) y un servidor (respondedor). La principal diferencia entre HTTP y CoAP es que los encabezados de CoAP están en formato binario y que CoAP funciona sobre UDP.
Los verbos para enviar los mensajes son los mismos:
- GET: para la recuperación de datos.
- POST: para la actualización parcial de datos.
- PUT: para la actualización completa de datos.
- DELETE: para eliminar un recurso.
Además, OBSERVE es una nueva función similar al «long poll» de HTTP. Observe se puede utilizar para obtener múltiples respuestas. Por ejemplo, cuando los datos cambian, se envía una nueva respuesta a la solicitud Observe. Para ofrecer la misma fiabilidad que HTTP sobre TCP, el protocolo CoAP implementado confirma las transferencias. Por lo tanto, el reenvío de los paquetes, cuando no se acusa recibo, forma parte de CoAP y, por lo tanto, las solicitudes confirmadas por CoAP son tan fiables como el HTTP sobre TCP. La carga útil de un mensaje viene determinada por el tipo de contenido, es decir, se pueden admitir diferentes formatos, al igual que en HTTP.
Tipos de carga útil
La especificación KNX IoT utiliza dos formatos de contenido, cada uno para una función diferente. El primero sirve para enumerar las URL (puntos de datos/bloques funcionales) con las que interactuar, y el segundo para la interacción con dichas URL.
El formato Application-Link
Este formato de contenido permite describir los recursos alojados, sus atributos y otras relaciones entre enlaces. Basándose en el campo «HTTP Link Header» definido en RFC 5988, el formato de enlace de entornos RESTful restringidos (CoRE) se transmite como carga útil y se le asigna un tipo de medio de Internet. Se define una URL conocida como punto de entrada predeterminado para solicitar los enlaces alojados en un servidor.
Respuesta típica
Un ejemplo de respuesta típica es el siguiente:
<auth/at>;rt=“urn:knx:fb.at“;ct=40,
<dev>;rt=“urn:knx:fb.0“;ct=40,
<swu>;rt=“urn:knx:fb.swu“;ct=40,
<f/rts>;rt=“urn:knx:fb.321“;ct=40
Cada línea contiene:
- La URL alojada (entre <>).
- El tipo de recurso (rt), que indica de qué se trata.
- El tipo de contenido, p. ej., 60 para CBOR y 40 para el formato Application-Link.
Esto permite al cliente interactuar con el dispositivo a través de una URL.
Interacción con un dispositivo
La URL puede considerarse un punto de datos con el que se puede interactuar mediante pares clave-valor. Los pares clave-valor se describen mediante la Representación Concisa de Objetos Binarios (CBOR). CBOR es un formato de serialización de datos binarios basado libremente en JSON. Al igual que JSON, permite la transmisión de objetos de datos que contienen pares nombre–valor, pero de forma más concisa. Esto aumenta las velocidades de procesamiento y transferencia a costa de la legibilidad para el ser humano. Sin embargo, facilita la documentación: se definen las cargas útiles en JSON para aumentar la legibilidad de la especificación y se utiliza el formato binario en la red.
Los datos de un mensaje en modo S pueden definirse en JSON de la siguiente manera:
{ "s": { "st": "el valor st", "ga": "el valor ga", "value": "el valor" } }
Las claves JSON se pueden sustituir por valores enteros para reducir aún más el tamaño del mensaje, tal y como se muestra a continuación:
{ 5: { 6: «el valor de st», 7: «el valor de ga», 1: «el valor» } }
Seguridad
El OSCORE RFC 8613 (Object Security for Constrained RESTful Environments), que proporciona seguridad de extremo a extremo para los mensajes CoAP en la capa de aplicación, cifra los mensajes de solicitud/respuesta de la capa de aplicación entre los puntos finales. No solo se cifra la carga útil que contiene el valor asociado a un recurso, sino también el método de solicitud, el identificador del recurso y el formato de contenido de la carga útil. Esto significa que los datos relevantes para la aplicación y la semántica de la solicitud y la respuesta pueden protegerse de forma independiente del transporte de los mensajes, al tiempo que se mantiene una sobrecarga mínima.
Además de CoAP, OSCORE también utiliza la Concise Binary Object Representation (CBOR) para la codificación compacta y el Firma y cifrado de objetos CBOR (COSE) para el cifrado y las estructuras de derivación de claves —ambas diseñadas para el funcionamiento de dispositivos con recursos limitados— y se comprime aún más con OSCORE al omitir la información redundante. OSCORE cuenta con identificadores integrados que permiten operaciones de extremo a extremo a través de múltiples rutas diferentes, con o sin IP.
La sobrecarga del mensaje es mínima, ya que OSCORE protege únicamente la información relevante de la capa de aplicación, y la cantidad de datos añadidos al tamaño del mensaje CoAP original puede ser de tan solo 11-13 bytes con los identificadores integrados. OSCORE ha sido fundamental a la hora de definir el nivel de sobrecarga para una seguridad de las comunicaciones ligera y supera a la seguridad de la capa de transporte de última generación.
Poniéndolo todo en contexto
Ya se han explicado todos los mecanismos de comunicación. El dispositivo KNX IoT dispone de un conjunto de URL que enumeran qué bloques funcionales y puntos de datos están implementados, así como de URL para configurar el dispositivo.
Por ejemplo, existen recursos (puntos de datos) para configurar el dispositivo. Conceptos ya existentes como la máquina de estados de carga (LSM), el modo de programación (PM), la dirección individual (IA) y la tabla de objetos de grupo se modelan mediante los mecanismos descritos anteriormente.
Como resultado, en la especificación de la API de KNX IoT Point se hace referencia a las siguientes especificaciones de la IETF (Internet Engineering Task Force):
Resumen
La ventaja de KNX IoT es que esta nueva tecnología está basada en IP y, por lo tanto, puede utilizarse en redes informáticas. Se ha desarrollado garantizando la interoperabilidad con la tecnología KNX existente y utiliza en su especificación las últimas tecnologías subyacentes basadas en Internet, lo que hace que KNX IoT sea seguro por diseño.
La especificación se ha diseñado pensando en los dispositivos embebidos, y se ha demostrado que la pila de código abierto que implementa KNX IoT es bastante pequeña, ya que funciona con tan solo 512 kB de memoria de almacenamiento y 96 kB de memoria.
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 energético 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.
