En la cuarta parte de esta serie sobre KNX IoT, Bruno Johnson y Wouter van der Beek explican la arquitectura de los dispositivos KNX IoT y muestran cómo KNX IoT es compatible con los sistemas KNX Classic.
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 realidad, y la Asociación KNX ha respondido con el lanzamiento de la KNX IoT Point API (KNX IoT).
El flujo general
Para garantizar la compatibilidad con versiones anteriores de los sistemas KNX Classic (por ejemplo, KNX Twisted Pair (KNX TP)), la especificación KNX IoT cuenta con dos mecanismos fundamentales implementados que son semánticamente equivalentes a KNX TP: estos mecanismos son la configuración de los dispositivos y el comportamiento en tiempo de ejecución. Además, el flujo de configuración en un cliente de gestión (MAC, p. ej., ETS) sigue los mismos pasos que ya utilizan los instaladores. El resultado es que, para los instaladores, no hay ninguna diferencia entre utilizar dispositivos KNX TP y dispositivos KNX IoT. El flujo de uso de los nuevos dispositivos KNX IoT se muestra en la figura 1.
La configuración de los dispositivos KNX IoT utiliza la misma información que para los dispositivos KNX TP seguros, a saber:
• Asignación del número de serie a una dirección individual.
• Descarga de la configuración de la dirección de grupo.
• Uso de una contraseña, similar a la clave de configuración predeterminada de fábrica (FDSK), para configurar la seguridad.
Además, se ha implementado una nueva función, concretamente una identificación de instalación (iid). Esto permite que se ejecuten varias instalaciones en la misma red informática. Cuando el dispositivo está en tiempo de ejecución (es decir, su estado es «cargado»), intercambia mensajes en modo S utilizando la información configurada. Esto se muestra en la figura 2.
Cabe señalar que la comunicación en tiempo de ejecución puede establecerse entre N dispositivos emisores y M dispositivos receptores, al igual que con KNX TP.
Arquitectura del dispositivo
Las direcciones web, por ejemplo, las URL, se implementan en el dispositivo. Cada URL que expone el dispositivo proporciona información similar a la de un servidor HTTP, y cada URL tiene una finalidad diferente. Las URL se definen en la especificación, y esta especifica qué función desempeña cada URL en el sistema. La figura 3 muestra las URL más comunes en un dispositivo.
Las URL tienen diferentes finalidades en el sistema. Sin embargo, la misma información que en un dispositivo KNX TP se almacena a través de las URL.
La figura 3 muestra las URL a nivel de dispositivo, y estas transmiten datos tales como:
• Número de serie del dispositivo.
• Modo de programación (activado o desactivado).
• Identificador de instalación.
• Estado de la máquina de estados de carga («unloaded», «loading», «loaded») y acción para cambiar el estado («unload», «starLoading», «loadcompleted»).
• Huella digital del estado cargado, para detectar si algo ha cambiado.
La URL de configuración
Las tablas se utilizan para configurar la comunicación en tiempo de ejecución; por ejemplo, para establecer la correspondencia entre la dirección de grupo, los indicadores de comunicación, el punto de datos (URL), las claves de seguridad y la dirección de multidifusión IPv6 para la comunicación de grupo.
Se utilizan las siguientes tablas:
• Tabla de objetos de grupo: contiene la correspondencia entre la URL del punto de datos y la dirección de grupo, incluidas las banderas de comunicación.
• Tabla de destinatarios: contiene la correspondencia entre la dirección del grupo y el identificador del grupo; el identificador del grupo se utiliza como parte de la dirección de multidifusión de la comunicación en modo S o para indicar la dirección individual como destino.
(Comunicación saliente)
• Tabla de emisores: contiene la correspondencia entre la dirección de grupo y el identificador de grupo. El identificador de grupo se utiliza como parte de la dirección de multidifusión de la comunicación en modo S.
(Comunicación entrante)
• Tabla de seguridad: contiene las claves de seguridad OSCORE con información OSCORE («osc») y la correspondencia con KNX para la comunicación por grupos; por ejemplo, la lista de direcciones de grupo o los ámbitos de acceso unicast identificados por la lista de interfaces.
Gestión de tablas
Las nuevas entradas se crean mediante un protocolo de aplicación de Internet para dispositivos con recursos limitados conocido como Constrained Application Protocol (CoAP). Un ejemplo sería un POST CoAP en la URL de la tabla utilizando el POST CoAP «/fp/g» para la tabla de objetos de grupo. Los valores deben definir una entrada correcta. El «id» utilizado formará parte de la URL de la nueva entrada. Por ejemplo, si se utiliza id = «item_1», se creará una nueva entrada con una sub-URL como «/fp/g/item_1». Por lo tanto, el MAC se encarga de definir las URL de las entradas.
La URL creada aparece en la respuesta de una solicitud CoAP GET en «/fp/g» como una entrada en formato de enlace. La entrada se puede consultar enviando una solicitud GET de CoAP a «/fp/g/item_1». La respuesta proporciona los valores según la especificación. Una entrada se puede eliminar enviando una solicitud DELETE de CoAP a «/fp/g/item_1». Esto tiene como efecto que la entrada se elimine del dispositivo, por lo que en una solicitud CoAP GET posterior a «/fp/g» ya no aparecerá en la lista. Ten en cuenta que la gestión de las tablas para la comunicación en grupo solo es posible en el estado «loading».
La 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 en modo s contienen la siguiente información:
• Dirección de grupo («ga»).
• Dirección individual del remitente («sia»).
• Tipo de servicio («st»).
El ejemplo de flujo en modo S que se muestra en la figura 5 a continuación consta de un mínimo de dos dispositivos: uno que crea un mensaje en modo S y otro que lo recibe. El dispositivo emisor tiene una entrada de objeto de grupo con la dirección de grupo 5 y una URL que representa o contiene el valor <value>, y cuenta con el indicador de transmisión («t»). Cuando algo activa la configuración del mensaje en modo «s», este se construye y se envía por la red de forma cifrada. El dispositivo receptor tiene una entrada de objeto de grupo también con dirección de grupo = 5 y el indicador de comunicación de escritura («w»), lo que significa que la URL correspondiente se actualizará con el <valor> recibido.
Comunicación multicast en modo s
Las tablas de destinatarios y emisores también contienen entradas. Estas entradas determinan qué dirección de multidifusión se utiliza. Por ejemplo, una entrada con ga = 5 y grpid = 1 hará que el valor grpid=1 forme parte de la dirección de multidifusión de envío o recepción. Por lo tanto, las entradas de las tablas de destinatarios y emisores correspondientes a una misma dirección de grupo deben coincidir; de lo contrario, el emisor podría utilizar una dirección de multidifusión diferente a la del receptor.
Comunicación en modo s de unidifusión: novedad para KNX IoT
La comunicación unicast se diferencia por tener una entrada distinta en el lado del emisor. El emisor dispone de una dirección individual de destino («ia»). La dirección individual debe resolverse a una dirección IPv6 real. Esto puede realizarse mediante protocolos informáticos habituales, como el descubrimiento CoAP o el DNS de multidifusión (mDNS). A continuación, la dirección IPv6 real puede utilizarse para la comunicación en tiempo de ejecución.
Información semántica: bloques funcionales y puntos de datos (novedad en KNX IoT)
KNX TP y ETS funcionan con longitudes de datos. Por lo tanto, no se transfiere la información semántica sobre el contenido de los mensajes en modo s. Sin embargo, con KNX IoT, esto se ha añadido a nivel de dispositivo; por ejemplo, los puntos de datos utilizados para recuperar o establecer el valor tienen una URL (de punto de datos). La URL (del punto de datos) puede utilizarse para obtener el valor «dpt» enviando una solicitud CoAP GET con el parámetro de consulta «?m=*». Además, el recurso /f enumera todos los bloques funcionales; por ejemplo, una solicitud GET de CoAP en /f proporciona una lista de todos los bloques funcionales implementados en formato de enlace. La URL de cada entrada de bloque funcional mostrará los puntos de datos implementados en dicho bloque funcional.
Como se puede observar en la Figura 6 anterior, esta información proporciona los datos semánticos en el mismo formato que con KNX TP.
Resumen
La ventaja de KNX IoT es que es perfectamente interoperable con la infraestructura KNX existente, al tiempo que se basa en IP. De este modo, pueden funcionar simultáneamente múltiples instalaciones en la misma red (informática) utilizando infraestructura cableada (Ethernet/PoE) e inalámbrica (Thread/WiFi/celular). 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.
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 los problemas de alcance, fiabilidad, seguridad, consumo energético y escalabilidad del 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.
