En la cuarta parte de esta serie sobre KNX IoT, Bruno Johnson y Wouter van der Beek nos explican con detalle la arquitectura de los dispositivos KNX IoT y muestran cómo KNX IoT es compatible con los sistemas KNX Classic.
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).
El flujo de alto nivel
Para garantizar la retrocompatibilidad con los sistemas KNX Classic [por ejemplo, KNX Twisted Pair [(KNX TP)], la especificación KNX IoT tiene implementados dos mecanismos fundamentales que son semánticamente equivalentes a KNX TP: estos mecanismos son la configuración de dispositivos y el comportamiento en tiempo de ejecución. Además, el flujo de configuración en un cliente de gestión (MAC, por ejemplo, ETS) sigue los mismos pasos que ya utilizan los instaladores. El resultado es que para los instaladores no hay diferencia entre utilizar dispositivos KNX TP y KNX IoT. El flujo de cómo utilizar los nuevos dispositivos IoT KNX se representa en la Figura 1.
En la configuración de los dispositivos KNX IoT se utiliza la misma información que para los dispositivos KNX TP seguros:
• Asignación del número de serie a una dirección individual.
• Descarga de la configuración de las direcciones de los grupos.
• Uso de una contraseña, similar a la clave de configuración de fábrica por defecto (FDSK, por sus siglas en inglés) para configurar la seguridad.
Junto a esto, se implementa una nueva característica: una identificación de la instalación (iid). Esto permite que varias instalaciones funcionen en la misma red informática. Cuando el dispositivo se encuentra en tiempo ejecución (es decir, el estado es «cargado»), intercambia mensajes en modo s utilizando la información configurada. Se describe en la Figura 2.
Ten en cuenta que la comunicación en tiempo de ejecución puede establecerse entre N dispositivos emisores y M dispositivos receptores, como con KNX TP.
Arquitectura de dispositivos
Las direcciones web, por ejemplo, las URL, se implementan en el dispositivo. Todas las direcciones URL que muestra el dispositivo proporcionan información similar a la de un servidor HTTP, cada URL tiene una finalidad distinta. Las direcciones URL se definen en la especificación y la especificación define lo que la URL hace en el sistema. La Figura 3 muestra las URL más comunes en un dispositivo.
Las direcciones URL tienen funciones diferentes dentro del sistema. Sin embargo, se almacena la misma información mediante URL que la que se almacena en los dispositivos KNX TP.
La Figura 3 muestra las URL a nivel de dispositivo, y éstas transmiten datos como:
• El número de serie del dispositivo.
• El modo de programación (activado o desactivado).
• El identificador de la instalación.
– Estado de la máquina de estado de carga («descargado», «cargando», «cargado»), y acción para cambiar el estado («descargado», «comenzar carga», «carga completada»).
• La huella digital del estado cargado, para saber si algo ha cambiado.
La URL para aplicar la configuración
Las tablas se utilizan para configurar la comunicación en tiempo de ejecución, por ejemplo, la transmisión del mapeo entre la dirección de grupo, los indicadores de comunicación, el punto de datos (URL), las claves de seguridad y la dirección multidifusión IPv6 para la comunicación de grupo.
Se utilizan las siguientes tablas:
• Tabla de objetos de grupo: contiene el mapeo entre la URL del punto de datos y la dirección del grupo, incluidos los indicadores de comunicación.
• Tabla de destinatarios: contiene la asignación de dirección de grupo al ID de grupo; el identificador de grupo se utiliza como parte de la dirección multidifusión de la comunicación en modo s o para enumerar la dirección individual como destino.
(Comunicación saliente)
• Tabla de editores: contiene la correspondencia entre la dirección del grupo y el identificador del grupo. El identificador de grupo se utiliza como parte de la dirección multidifusión de la comunicación en modo s.
(Comunicación entrante)
• Tabla de seguridad: contiene las claves de seguridad OSCORE que guardan la información OSCORE («osc») y el mapeo a KNX para la comunicación de grupo, por ejemplo, la lista de direcciones de grupos o los ámbitos de acceso de unidifusión identificados por la lista de interfaces.
Gestión de tablas
Las nuevas entradas se crean con un protocolo de aplicación de Internet para dispositivos restringidos conocido como Protocolo de Aplicación Restringida (CoAP). Un ejemplo sería un CoAP POST en la URL de la tabla utilizando CoAP POST ‘/fp/g’ para la tabla de objetos de grupo. Los valores tienen que definir una entrada correcta. El «ID» utilizado formará parte de la URL de la nueva entrada. Por ejemplo, si se utiliza id = ‘item_1’, aparecerá una nueva entrada con una URL secundaria como, por ejemplo ‘/fp/g/item_1’. Por tanto, el MAC tiene el control de la definición de las URL de entrada.
La URL creada aparece con un CoAP GET en ‘/fp/g’ como entrada de formato de enlace en la respuesta. La entrada se puede consultar lanzando un CoAP GET en ‘/fp/g/item_1’. La respuesta da los valores según la especificación. Las entradas se pueden eliminar lanzando un CoAP Delete en ‘/fp/g/item_1’. Esto hace que la entrada se elimine del dispositivo, por lo que si hacemos un CoAP GET sobre ‘/fp/g’ más tarde ya no aparecerá en la lista. Ten en cuenta que la gestión de las tablas para la comunicación de grupo sólo es posible en el estado «cargando».
Dirección URL para la comunicación en tiempo de ejecución
La URL ‘/.knx’ se utiliza para la comunicación de mensajes en modo s. Los mensajes del modo s contienen la siguiente información:
• Dirección del grupo (‘ga’).
• Dirección individual del remitente («sia»).
• Tipo de servicio (‘st’).
El ejemplo de flujo de modo s que se muestra en la Figura 5 más abajo consta de un mínimo de 2 dispositivos, a saber, uno que crea un mensaje de modo s y otro que recibe el mensaje. El dispositivo emisor tiene una Entrada de objeto de grupo con la dirección de grupo 5 y una URL que representa/contiene el valor
Comunicación multidifusión en modo s
La tabla de destinatarios y editores también tiene entradas. Estas entradas regulan qué dirección multidifusión se está utilizando. Por ejemplo, una entrada con ga = 5 y grpid = 1 hará que el valor grpid = 1 forme parte de la dirección multidifusión emisora o receptora. Por tanto, las entradas de la tabla de destinatarios y editores para la misma dirección de grupo deben coincidir, ya que, de lo contrario, el emisor podría utilizar una dirección multidifusión distinta a la del receptor.
Comunicación unidifusión en modo s: nuevo para KNX IoT
La comunicación unidifusión se diferencia por tener una entrada diferente en el lado emisor. El remitente tiene una dirección individual de destino («ia»). La dirección individual debe resolverse en una dirección IPv6 real. Esto puede hacerse mediante protocolos informáticos comunes, como el descubrimiento CoAP o el DNS multidifusión (mDNS). Entonces se puede utilizar la dirección IPv6 real para la comunicación en tiempo de ejecución.
Información semántica: bloques funcionales y puntos de datos (Nuevo para KNX IoT)
KNX TP y ETS trabajan con longitudes de datos. Por tanto, no se transfiere la información semántica de lo que contienen los mensajes del modo s. Sin embargo, con KNX IoT, esto se ha añadido a nivel de dispositivo como, por ejemplo, los puntos de datos utilizados para recuperar o establecer el valor tienen una dirección URL (punto de datos). La URL (punto de datos) puede utilizarse para obtener el valor ‘dpt’ emitiendo un CoAP GET con el parámetro de consulta ‘?m=*’. Junto a esto, el recurso /f ofrece una lista de todos los bloques funcionales, por ejemplo, CoAP GET en /f da una lista de todos los bloques funcionales implementados en formato enlace. La URL de cada entrada de bloque funcional dará los puntos de datos implementados en el bloque funcional.
Como puede verse en la Figura 6, esta información proporciona la información semántica de la misma forma que con KNX TP.
Resumen
La ventaja de KNX IoT es que es perfectamente interoperable con la infraestructura KNX existente, a la vez que está basada en IP. De este modo, varias instalaciones pueden funcionar simultáneamente en la misma red (informática) utilizando infraestructuras cableadas (Ethernet/PoE) e inalámbricas (Thread/WiFi/móvil). 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.
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.
