KNX (1)

Uno de los protocolos más extendidos en domótica es el KNX. Aunque como tal su estándar se publicó en 2001, hay que hacer notar que ya tenía una década de recorrido bajo el nombre de EIB (European Installation Bus) o Instabus. Su origen hay que buscarlo por tanto hace 25 años, cuando quince compañías europeas, entre ellas Siemens, acordaron unas especificaciones comunes para las instalaciones domóticas. EIB utilizó desde sus inicios un par trenzado (TP1, de Twisted Pair) como medio de transporte. La configuración de los dispositivos se hacía mediante una herramienta independiente, ETS (EIB Tool Software). Con los años se decidió la convergencia con otros dos buses empleados en domótica, a saber: EHS (European Home Systems), que aprovecha las instalaciones eléctricas preexistentes (PLC, power line communication), y BatiBUS. De dicha unificación surgió KNX, si bien el estándar se ha ido ampliando con comunicaciones inalámbricas (KNX RF) y Ethernet (KNX IP). Durante estos años también se normalizó como EN 50090 e ISO/IEC 14543. Su administración está gestionada por la Asociación KNX.

KNX cubre los aspectos que se pueden esperar en un sistema domótico: iluminación, HVAC, persianas, control de accesos, audio y vídeo, etc. Por ello tiene que manejar datos con muy distinto significado o función. Al mismo tiempo, se trata de un sistema no propietario, y desde el principio se quiso desligar de cualquier plataforma o arquitectura de procesador, de modo que cada fabricante lo implementa de acuerdo a criterios propios. Y ello debe hacerse de modo que los equipos de distintas marcas puedan interactuar adecuadamente, sin requerir una configuración compleja. Otra característica de KNX es su arquitectura completamente descentralizada. Cada dispositivo habla con sus compañeros, situados incluso en otra subred, sin un maestro que gestione las comunicaciones. Lo que da lugar, como iremos viendo, a colisiones que es necesario salvar. Todas estas cuestiones obligan a una cierta vigilancia de la implementación del estándar, no sólo de las comunicaciones, sino también en cuanto al uso de tipos de datos estandarizados. El etiquetado KNX supone pues una conformidad con estos requerimientos.
Vamos a comenzar describiendo el modelo de KNX en relación con las capas OSI. En la figura inferior pueden observarse las distintas implementaciones de la capa física, que puede utilizar bien un bus de par trenzado (TP1), la red de alimentación eléctrica (PL110), comunicaciones inalámbricas (RF) o una red Ethernet (IP). Independientemente del medio, el enlace se establece mediante el direccionamiento propio de KNX, basado en la topología original de bus que se describirá más adelante. En lo que toca a la capa de aplicación, hay que distinguir el funcionamiento usual, de un sistema ya implantado, de la comunicación con las herramientas de configuración. En el segundo caso, existen varias formas de parametrizar los equipos, que se pueden agrupar en modo sistema y modo fácil. También en este nivel encontraríamos equipos de integración como supervisores, pasarelas, etc.

Para desgranar los detalles del estándar, voy a centrarme de momento en las especificaciones para par trenzado y relegaremos las variantes (PL100, FR, IP). La razón principal es que de ella, como he comentado, hereda la topología lógica de KNX, y por tanto el direccionamiento de los dispositivos se concibe con esta perspectiva. Una instalación de KNX está formada en general por un bus troncal que enlaza varios buses principales, que a su vez unen mediante acopladores buses secundarios. Un bus secundario podría típicamente cubrir una planta de un edificio, mientras que el primario recorrería la vertical; el bus troncal uniría varios edificios cercanos. Pero insisto, es sólo una posibilidad, y en último término debe entenderse que ésta es la topología lógica y no tiene por qué corresponderse con la física (imaginar por ejemplo una comunicación por radiofrecuencia).
El direccionamiento de cada elemento en esta red se realiza mediante dos bytes, que hacen referencia a un bus y al dispositivo dentro de dicho bus. El primer byte se puede dividir por otra parte en dos mitades: la primera indica el área dentro del dominio (es decir, el bus principal), y la segunda, el bus secundario. Por tanto, una instalación puede tener 16 áreas, cada una de ellas con 16 buses secundarios, y dentro de cada uno de ellos 256 dispositivos, con lo que se pueden direccionar 65536 dispositivos. En realidad habría que aclarar que para el bus troncal se reserva el número 0 (y el término área no sería por tanto adecuado), y lo mismo sucede con los buses principales; es una cuestión de terminología, y no afecta a lo expuesto. Cuando se habla de KNX sobre TP1, hay que hacer notar que por cuestiones de alimentación no se admiten segmentos de bus con más de 64 elementos; el inconveniente se soslaya introduciendo fuentes adicionales.

Esta entrada continúa en KNX (2).