KNX (1)

publicado en: Domótica, 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.

Logo KNX
Logo 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.

Modelo KNX
Modelo KNX

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.

Topología KNX
Topología KNX

Esta entrada continúa en KNX (2).

Novedades 20151003

Microsiervos publicó recientemente una entrada dedicada a el PLC industrial basado en Arduino de nombre Industruino. El equipo se suma a una interesante serie de controladores similares que engrosa día a día, como el Controllino o los autómatas de Industrial Shields.
Según un estudio de Transparency Market Research, se espera un crecimiento en el mercado de la domótica de nada menos que un 26% anual (CAGR) hasta 2020. Este fuerte avance es debido a la necesidad de eficiencia en aplicaciones de iluminación, seguridad, entretenimiento y HVAC; y aunque el liderzago va de la mano de Estados Unidos y Canadá, regiones como Europa y Asia oriental están asimismo experimentando un fuerte crecimiento.
A estas alturas no hace falta incidir en las ventajas de Ethernet (no solo Industrial Ethernet) en las aplicaciones industriales: integración, estandarización en las capas bajas, etc. Ken Kao, de Advantech, destaca los aspectos que van a verse potenciados gracias a los avances recientes, desde la convergencia con el IoT o las mejoras en fiabilidad y diagnóstico hasta la reducción de precio de los switches gestionados.
Cuando en 2011 orienté mi TFM hacia el uso del lenguaje natural en sistemas de control, tenía claro que la penetración de estas tecnologías en el ámbito industrial iba a resultar costosa, por razones de seguridad, entre otras. La domótica no tiene unas exigencias tan estrictas. El pasado viernes, ABB presentó una versión mejorada de free@home, un sistema para controlar edificios inteligentes mediante comandos de voz. Por los pocos detalles que he visto, debe de utilizar una gramática libre de contexto; en sí, no es novedoso, pero supone un paso adelante en la dirección hacia la que debe evolucionar el sector.
Estos días descubrí Shodan en el siguiente artículo del Instituto Nacional de Ciberseguridad, que habla sobre amenazas en los sistemas de control industrial. Tras describir las consecuencias de un accidente de este tipo y presentar algunos ejemplos (la fuga en Union Carbide en 1985, que propiamente fue un error de programación, los vertidos de Maroochy en el 2000, Stuxnet, Dragonfly…), recoge unas breves buenas prácticas.
El Instituto Nacional de Ciberseguridad también ha publicado una presentación sobre Diagnóstico de Ciberseguridad en Entornos Industriales. En las primeras diapositivas describe en qué consiste una auditoría a este nivel, para después analizar las arquitecturas de red en industria, la detección de amenazas y los mecanismos de seguridad.
Para terminar, un vídeo breve para aclarar la relación entre Internet of Things (IoT), Industrial Internet of Things (IIoT) y la industria 4.0.