En el tercero de esta serie de artículos sobre KNX IoT, Bruno Johnson y Wouter van der Beek explican los fundamentos de estos dispositivos.
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).
Fundamentos
Para asegurar la compatibilidad con versiones anteriores de otros sistemas multimedia KNX (instalaciones KNX Classic), las especificaciones de KNX IoT dentro 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, Wi-Fi, Ethernet y redes basadas en hilos.
• Un nuevo protocolo de comunicación/mensaje que permite los siguientes modos de comunicación:
- Punto a multipunto, no orientado a la conexión (multidifusión).
- Punto a punto, no orientado a la conexión.
- Punto a punto, orientado a la conexión.
Más allá de eso, el nuevo transporte debe utilizar los mismos puntos de datos que las capas de transporte KNX existentes, tal y como se define en las especificaciones de las Descripciones de aplicación (Volumen 7).
El diseño del nuevo medio de transporte con estas limitaciones no cambiará la forma en que KNX se aplica en la actualidad. La configuración de los dispositivos sigue teniendo el mismo planteamiento desde ETS, y éstos siguen comunicándose entre sí mediante mensajes en S-mode.
Pila de tecnología
Los dispositivos deben poder comunicarse utilizando IPv6, independientemente de la capa física utilizada, lo que significa que sean compatibles Ethernet (incluida PoE), Wi-Fi y Thread. De hecho, Thread está inherentemente basado en IPv6.
Descubrimiento
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 descubrimiento diferentes.
1) El descubrimiento mDNS es un protocolo que utiliza el DNS multidifusión (mDNS), que consiste en 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. Está ampliamente implementado en dispositivos de domótica inteligentes, dispositivos Arduino inalámbricos, impresoras, altavoces, dispositivos de almacenamiento en red, etc. Funciona enviando paquetes a todos los nodos de la red para resolver nombres del host y consultar servicios. Puede utilizarse con el descubrimiento de servicios DNS (DNS-SD) para explorar y encontrar servicios basándose en el nombre del host o del servicio. Sólo funciona para el dominio de nivel superior (TLD) .local.
El descubrimiento mDNS permite el descubrimiento por:
– Número de serie.
– Dirección individual.
– Modo de programación.
2) El descubrimiento CoAP (Constrained Application Protocol) es una petición CoAP especial que descubre los recursos de un host conocido. Para descubrir el host, se puede utilizar una solicitud de multidifusión, pero debe ser compatible con el servidor.
El descubrimiento CoAP permite el descubrimiento por:
– Número de serie.
– Dirección individual.
– Modo de programación.
– Descubrimiento de un dispositivo que contiene un punto de datos específico.
– Descubrimiento 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 mediante CoAP. Es la capa que transporta los telegramas KNX desde el emisor hasta el destino. Esto se consigue utilizando direcciones URL. La forma más sencilla de ver CoAP es que es equivalente a HTTP,implementa el envío de mensajes utilizando el paradigma de solicitud y respuesta, entre un Cliente (iniciador) y un Servidor (respondedor). La principal diferencia entre HTTP y CoAP radida en que las cabeceras CoAP están en formato binario y que CoAP funciona sobre UDP.
Los verbos para emitir los mensajes son los mismos:
- GET: para la obtención de datos.
- POST: para la actualización 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 sondeo largo HTTP. La observación puede utilizarse para obtener varias respuestas. Por ejemplo, cuando los datos cambian, se envía una nueva respuesta a la solicitud de observación. Para tener la misma fiabilidad que HTTP sobre TCP, el protocolo CoAP implementa transferencias confirmadas. De ahí que el reenvío de los paquetes, cuando no son reconocidos, forme parte de CoAP y, por tanto, las solicitudes confirmadas por CoAP son tan fiables como HTTP sobre TCP. La carga útil de un mensaje viene determinada por el tipo de contenido, es decir, pueden admitirse distintos formatos, de forma muy similar a HTTP.
Tipos de carga útil
El sistema KNX IoT utiliza dos formatos de contenido, cada uno para una función diferente. La primera es para listar las URL (puntos de datos/bloques funcionales) con los que interactuar, y la segunda para interactuar con las URL.
El formato «Aplicación-Enlace»
Este formato de contenido permite describir los recursos alojados, sus atributos y otras relaciones entre enlaces. Basado en el campo Encabezado de enlace HTTP definido en RFC 5988, el formato de enlace de entornos RESTful restringidos (CoRE) se transporta como carga útil y se le asigna un tipo de medio de Internet. Una URL conocida se define como un punto de entrada por defecto para solicitar los enlaces alojados en un servidor.
Respuesta típica
Respuesta típica. Un ejemplo de respuesta típica es el siguiente:
Cada línea contiene:
– La dirección URL alojada (entre ).
– El tipo de recurso (rt), que designa lo que es.
– El tipo de contenido, por ejemplo 60 para CBOR y 40 para el formato «Aplicación-Enlace».
Esto permite al cliente interactuar con el dispositivo en función de una URL.
Interacción con un dispositivo
La URL puede verse como un punto de datos con el que se puede interactuar a través de pares clave-valor. Los pares clave-valor se describen con la Representación Concisa de Objetos Binarios (CBOR). CBOR es un formato de serialización de datos binarios vagamente basado 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 la velocidad de procesamiento y transferencia a costa de la legibilidad humana. Sin embargo, abre la documentación: definir las cargas útiles en JSON para aumentar la legibilidad humana de la especificación y tener el formato binario en el cable.
Los datos de un mensaje en modo S pueden definirse en JSON como sigue:
{ «s»: { «st»: «the st value» , «ga»: «the ga value», «value»: «the value» } }
Las claves JSON pueden sustituirse por valores enteros para reducir aún más el tamaño del mensaje, como se indica a continuación:
{ 5: { 6: «the st value» , 7: «the ga value», 1: «the value» } }
Seguridad
El protocolo estándar OSCORE RFC 8613 (Seguridad de objetos para entornos RESTful restringidos) 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 sólo 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 del contenido de la carga útil. Esto significa que los datos relevantes para la aplicación y la semántica de la solicitud/respuesta pueden protegerse de forma desvinculada del transporte de los mensajes, al tiempo que son ligeros en términos de sobrecarga.
Además de CoAP, OSCORE también utiliza la representación concisa de objetos binarios (CBOR, por sus siglas en inglés) para la codificación compacta y la firma y cifrado de objetos CBOR (COSE, por sus siglas en inglés) para las estructuras de cifrado y derivación de claves (ambas diseñadas para operaciones con dispositivos limitados) y comprimidas aún más con OSCORE al omitir la información redundante. OSCORE cuenta con identificadores incorporados 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 sólo protege 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 sólo 11-13 bytes e integrar identificadores. OSCORE ha desempeñado un papel decisivo en la definición del nivel de sobrecarga para la seguridad de las comunicaciones ligeras y supera a la seguridad de la capa de transporte más avanzada.
Encajando todas las piezas
Ahora explicamos todos los mecanismos de comunicación. Los dispositivos KNX IoT cuentan con un conjunto de URL con las que enumeran los bloques funcionales y puntos de datos que han sido implementados y tienen URL para configurar el dispositivo.
Por ejemplo, hay recursos (datapoints) para configurar el dispositivo. Los conceptos existentes como máquina de estado de carga (LSM), modo de programación (PM), dirección individual (IA) y tabla de objetos de grupo se modelan con los mecanismos descritos anteriormente.
Como resultado, las siguientes especificaciones IETF (Internet Engineering task Force) son referenciadas en la especificación API KNX IoT Point:
Resumen
La gran ventaja de KNX IoT es que la nueva tecnología está basada en IP y, por tanto, puede utilizarse a través de redes informáticas Se ha desarrollado garantizando su interoperabilidad con la tecnología KNX existente, y utiliza las últimas tecnologías subyacentes basadas en Internet, logrando que KNX IoT sea seguro por diseño.
La especificación ha sido diseñada teniendo en cuenta los dispositivos integrados, mientras que la pila de código abierto que implementa KNX IoT ha demostrado ser bastante pequeña, funcionando con tan solo 512kB de memoria de almacenamiento y 96kB de memoria.
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 de IoT seguros y lidera el desarrollo de los 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 económicos módulos IoT de consumo ultrabajo.
