Protocolos e integración
KNX, BACnet y Modbus: guía de protocolos
En qué se diferencian KNX, BACnet y Modbus en modelo de datos, topología y esfuerzo de integración, y cómo combinarlos en un mismo sistema de automatización de edificios sin perder el control de la lista de puntos.
Respuesta rápida
KNX es un bus de campo descentralizado para iluminación, protección solar y control de salas; BACnet es un protocolo de automatización de edificios orientado a objetos para instalaciones y sistemas de supervisión; Modbus es un protocolo sencillo basado en registros para contadores, variadores y equipos. La mayoría de los edificios utiliza más de uno, conectados mediante pasarelas y un mapa de puntos documentado.
Por qué importa la elección del protocolo
Los protocolos no son una preferencia abstracta. Determinan qué dispositivos pueden incorporarse al sistema, qué herramienta de ingeniería se necesita, cómo se nombran los datos, cuántas pasarelas hay en medio y quién podrá mantener la instalación en el futuro. Un protocolo con un modelo de objetos rico hace que la integración sea predecible; un protocolo basado en registros aporta flexibilidad, pero deja el significado en manos del integrador. Un bus descentralizado reduce la dependencia de un controlador central; un protocolo de supervisión basado en IP facilita la integración de instalaciones y el diagnóstico remoto. La mayoría de los edificios acaba con más de un protocolo, porque la iluminación, las instalaciones, la medición y el control de salas tienen historias distintas y ecosistemas de dispositivos diferentes. La tarea de diseño consiste en situar cada protocolo donde encaja y hacer explícitos los límites, en lugar de declarar un ganador. Un protocolo fácil de instalar pero difícil de documentar costará más a lo largo de la vida del edificio. En el límite es donde se concentra la mayor parte del riesgo de integración: una pasarela que nadie asume es un fallo esperando una entrega. La elección del protocolo es, por tanto, una decisión de ciclo de vida, no una preferencia de compra. La cuestión no es qué protocolo es abierto, sino qué partes de la instalación siguen siendo mantenibles cuando el integrador original ya no está disponible. Una decisión tomada solo por el contratista eléctrico suele ignorar al equipo de mantenimiento.
- Ecosistema de dispositivos y herramientas de ingeniería
- Modelo de datos y nomenclatura
- Número de pasarelas y puntos de fallo
- Mantenibilidad y soporte durante el ciclo de vida
KNX: control de salas descentralizado
KNX es un bus de campo para el control de edificios, muy utilizado en iluminación, protección solar, terminales de climatización (HVAC) y funciones de sala. Los dispositivos se direccionan individualmente y se comunican mediante direcciones de grupo, de modo que un interruptor puede controlar una luz sin un programa central. La ingeniería se realiza en ETS, donde se definen la estructura de direcciones de grupo y los parámetros de los dispositivos. El modelo descentralizado es resistente: si falla un dispositivo, el resto del bus sigue funcionando. KNX puede ampliarse sobre IP con routers e interfaces, lo que lo hace práctico entre plantas y edificios. Su punto fuerte es el control de salas estandarizado con un amplio mercado de dispositivos. Su limitación es que las secuencias complejas de instalaciones y la lógica entre sistemas suelen residir en un controlador de supervisión o una pasarela, no en el propio bus. Un plan de direcciones de grupo limpio marca la diferencia entre una instalación KNX mantenible y un proyecto que nadie quiere tocar. Las direcciones de grupo deben planificarse por función y ubicación, no por el orden en que se instalaron los dispositivos. Una línea admite normalmente 64 dispositivos; los acopladores y los segmentos amplían la instalación, y cada límite debe documentarse. Las direcciones de grupo también deben dejar espacio para una nueva planta o un cambio de inquilino. Un bus fácil de ampliar también es fácil de sobreextender.
- Bus de par trenzado con lógica descentralizada
- Direccionamiento individual y de grupo
- ETS como herramienta de ingeniería
- Enrutamiento IP para instalaciones mayores
BACnet: objetos e integración de supervisión
BACnet es un protocolo orientado a objetos diseñado para la automatización y el control de edificios. Un dispositivo expone objetos como entrada analógica, salida analógica, valor analógico, entrada binaria, salida binaria, valor binario y objetos multiestado. Cada objeto tiene propiedades: valor actual, unidades, indicadores de estado, descripción y límites de alarma. Los servicios permiten lectura, escritura, descubrimiento y suscripción a cambios de valor. BACnet funciona sobre IP y sobre MS/TP, lo que le permite llegar a controladores de instalaciones y dispositivos de campo en el mismo emplazamiento. Su modelo de objetos hace que la integración sea más predecible que un mapa de registros en bruto, siempre que los nombres de objetos y las unidades sean coherentes. Las pruebas de BACnet y los listados de dispositivos ayudan, pero no sustituyen una comprobación punto por punto durante la puesta en marcha. Una nomenclatura coherente entre dispositivos vale más que una larga lista de objetos. El defecto de integración más habitual no es un fallo del protocolo; es un punto asignado al objeto equivocado o escalado de forma incorrecta. Un navegador de objetos muestra lo que existe, no lo que significa. El acceso a nivel de propiedad importa: un dispositivo que expone un valor pero prohíbe escribir su consigna no puede admitir una secuencia de reposición. La lista de objetos debe registrar qué propiedades son escribibles, no solo cuáles son legibles.
- Dispositivos, objetos, propiedades y servicios
- Tipos de objeto estándar para puntos
- Segmentos BACnet/IP y MS/TP
- Descubrimiento, COV y pruebas de puntos
Modbus: registros y límites prácticos
Modbus es un protocolo sencillo de petición-respuesta construido en torno a bobinas y registros. Modbus RTU funciona sobre enlaces serie; Modbus TCP envuelve el mismo modelo en Ethernet. Un maestro sondea a los esclavos por dirección de unidad y código de función, leyendo o escribiendo un número definido de registros. El protocolo define el transporte, no el significado: un registro puede ser una temperatura, una palabra de estado, un contador de energía o una versión de firmware. Esa flexibilidad es la razón por la que lo utilizan contadores, variadores de frecuencia, inversores y sensores, y por la que toda integración necesita un mapa de registros del fabricante. Conviene prestar atención al escalado, los valores con signo, el orden de palabras de 32 bits, los intervalos de sondeo y el comportamiento de los tiempos de espera. Un dispositivo Modbus que deja de responder debe generar un fallo claro, no un valor obsoleto que parece válido. Un registro que lee cero puede significar apagado, averiado o no configurado; el mapa debe indicar cuál. Documentar el mapa de registros es más valioso que cualquier configuración de pasarela, porque es lo que necesitará el siguiente ingeniero. Un segmento serie admite normalmente 32 unidades sin repetidor, y sondear demasiados dispositivos expone pronto el límite. El mapa de registros debe versionarse junto con el firmware del dispositivo, porque las direcciones cambian. El diagnóstico serie es limitado; un analizador de protocolo es una herramienta de puesta en marcha, no una solución permanente.
- RTU sobre serie, TCP sobre Ethernet
- Sondeo maestro-esclavo y direcciones de unidad
- Bobinas y registros con significado propio del fabricante
- Escalado, orden de bytes y comportamiento de los tiempos de espera
DALI y otros buses de campo
DALI merece un tratamiento aparte porque la iluminación suele ser la mayor población de dispositivos de un edificio. Una línea DALI direcciona drivers y dispositivos de control individuales, normalmente 64 por línea, y transporta comandos lentos pero fiables. No es una red de todo el edificio; las pasarelas la conectan a KNX, BACnet o a un controlador. DALI-2 añade declaraciones de interoperabilidad para sensores y dispositivos de control, lo cual importa cuando productos de varios fabricantes comparten una línea. La iluminación de emergencia puede supervisarse a través de DALI cuando las luminarias lo admiten, pero el régimen de pruebas y la obligación de informar siguen siendo locales. Los errores habituales son la dispersión de direcciones, la falta de mapas y una pasarela tratada como un cable transparente. Una integración de iluminación debe registrar la línea, la dirección, el grupo y la pertenencia a escenas de cada luminaria, porque ese registro es lo que realmente utiliza el mantenimiento. Otros buses, como 0-10V y la regulación por corte de fase, siguen existiendo y deben integrarse donde estén, en lugar de sustituirse por uniformidad. El diseño debe indicar qué bus controla cada luminaria, porque dos rutas de control hacia un mismo driver son un fallo esperando a ocurrir. Una pasarela DALI que pierde su mapa puede dejar a oscuras una planta sin que falle un solo driver. Los resultados de las pruebas de emergencia deben exportarse en un formato que la persona responsable pueda firmar.
- Direccionamiento individual de drivers y grupos
- Declaraciones de interoperabilidad DALI-2
- Pasarelas hacia KNX, BACnet o controladores
- Registros de línea, dirección y escenas en la entrega
Combinar protocolos sin una pila frágil
Un diseño práctico sitúa cada protocolo donde su ecosistema de dispositivos es más fuerte: KNX para el control de salas, DALI para luminarias, BACnet para instalaciones y equipos de supervisión, Modbus para contadores y variadores. Las pasarelas traducen entre ellos, pero toda pasarela es un dispositivo con alimentación, firmware, configuración y un modo de fallo. El número de pasarelas debe ser deliberado, cada una debe documentarse y debe decidirse qué ocurre cuando se queda sin conexión. Las secuencias de control deben ubicarse donde puedan ejecutarse localmente, no solo en la pasarela. Conviene segmentar las redes para que un fallo en un segmento no derribe todo el edificio. La sincronización horaria importa para el análisis de tendencias y la correlación de alarmas. La arquitectura de integración debe poder explicarse en una página; si necesita un diagrama que nadie puede seguir, probablemente sea demasiado profunda. El diseño también debe indicar qué sistema mantiene el reloj maestro y cómo se distribuye la hora. Una pila plana y documentada es más fácil de probar y más barata de mantener que una cadena de traductores. Cada capa de traducción adicional añade latencia, un archivo de configuración y una persona que debe entender ambos lados. Una pasarela que traduce en ambas direcciones necesita una regla para comandos en conflicto, no solo para datos perdidos. La sincronización horaria debe proceder de una única fuente, no de cada pasarela por separado.
- Un protocolo por ecosistema de dispositivos
- Pasarelas deliberadas y documentadas
- Secuencias locales independientes de las pasarelas
- Segmentación de red y sincronización horaria
Criterios de decisión y selección de pasarelas
La selección de pasarelas suele decidirse con tres preguntas: qué expone el dispositivo, qué puede consumir el sistema de supervisión y quién dará soporte al enlace. Una interfaz nativa es preferible a una pasarela cuando existe, porque elimina un dispositivo y un archivo de configuración de la ruta crítica. Una pasarela se justifica cuando el protocolo no es nativo, cuando se requiere aislamiento eléctrico o cuando el número de dispositivos supera lo que el controlador puede sondear de forma fiable. La capacidad no es solo un recuento de puntos; la carga de sondeo, el tiempo de respuesta y el número de conexiones simultáneas importan. Conviene comprobar si la pasarela admite los tipos de objeto y los servicios que necesita la secuencia, no solo si puede leer un valor. Debe confirmarse la compatibilidad de firmware y la política de actualización del fabricante. Debe registrarse quién configura la pasarela, quién es responsable de su copia de seguridad y a quién se llama cuando falla. La pasarela más barata rara vez es la integración más barata cuando se contabiliza el soporte. Una pasarela de la que no se puede hacer copia de seguridad no se puede sustituir en una tarde. Dos pasarelas en serie deben considerarse un indicio de mal diseño, incluso cuando cada una funciona por separado. Una pasarela sin capacidad de reserva se convierte en la razón por la que se retrasa la siguiente fase. Como regla de planificación, la carga de sondeo y el número de dispositivos deben mantenerse muy por debajo del máximo documentado, y la mitad de la capacidad declarada debe tratarse como un nivel de aviso, no como un objetivo.
- Interfaz nativa antes que pasarela cuando sea posible
- Comprobar servicios y tipos de objeto, no solo valores
- La carga de sondeo y el tiempo de respuesta importan
- Responsable, copia de seguridad y ruta de sustitución registrados
La lista de verificación de integración y los modos de fallo
Una integración está terminada cuando se ha demostrado cada punto, no cuando la pasarela aparece en línea. Se empieza por una lista de puntos que indique origen, destino, tipo de dato, unidad, rango, escalado, dirección de lectura o escritura, clase de alarma y estado de fallo. El mapa de objetos o de registros debe confirmarse con la documentación del fabricante. Deben probarse los valores normales, los valores fuera de rango, la desconexión, el reinicio y la sincronización horaria. Debe comprobarse que las alarmas llegan con la prioridad correcta y que se restablecen correctamente. Debe verificarse que un fallo de la pasarela produce un fallo visible y no un valor congelado. Deben registrarse los resultados y entregarse los mapas, las credenciales y los planos de red. La lista de verificación es también un documento comercial: define de qué responde el integrador y qué queda en manos del proveedor del equipo. Una lista firmada convierte una visita informal de puesta en marcha en evidencia de que la integración funciona. Sin ella, cada cambio futuro empieza con una investigación en lugar de con un plano. La lista debe revisarse en cada fase, no solo al final, porque un punto que falta en la lista normalmente falta en el precio. La lista debe estar firmada por la parte que mantendrá el sistema, no solo por el instalador. La lista de puntos es también la defensa más clara contra la ampliación descontrolada del alcance, porque muestra lo que se acordó.
- Lista de puntos con unidades, escalado y dirección
- Mapa de objetos o de registros verificado
- Pruebas de fallo, reinicio y sincronización horaria
- Mapas, credenciales y planos entregados
Comparación de KNX, BACnet y Modbus
17 rows| Aspecto | KNX | BACnet | Modbus |
|---|---|---|---|
| Origen y alcance | Bus de edificio para dispositivos de sala y de campo | Redes de automatización y control de edificios | Protocolo industrial de registros |
| Topología | Bus, árbol o estrella sobre par trenzado | IP, Ethernet y MS/TP | RTU serie o TCP |
| Direccionamiento | Direcciones individuales y de grupo | Instancia de dispositivo e identificadores de objeto | ID de esclavo o de unidad más dirección de registro |
| Modelo de datos | Objetos de grupo y puntos de datos | Objetos, propiedades y servicios | Bobinas y registros sin semántica |
| Descubrimiento | Programación del bus con ETS | Descubrimiento por broadcast y lista de objetos | Mapa de registros manual |
| Dispositivos habituales | Interruptores, reguladores, actuadores y controladores de sala | UMAs (AHU), enfriadoras, cajas VAV y BMS | Contadores, variadores, inversores y sensores |
| Herramienta de ingeniería | Proyecto ETS | Herramienta del fabricante y configuración del BMS | Manual del fabricante y configuración del sondeo |
| Modelo de lectura y escritura | Escritura y lectura de grupo | Servicios y matrices de prioridad | Códigos de función y sondeo |
| Pruebas | Exploración del bus y prueba de grupos | Navegador de objetos y prueba COV | Prueba de lectura, escritura y escalado de registros |
| Licencias | Licencia ETS por proyecto | Herramientas del fabricante y pruebas de dispositivos | Normalmente sin licencia de protocolo |
| Encaje típico | Iluminación, protección solar y control de salas | Integración de instalaciones y supervisión | Medición y datos de equipos |
| Error habitual | Dispersión de direcciones de grupo | Asignación de objetos sin unidades | Orden de bytes y escalado incorrectos |
| Límite típico de segmento | 64 dispositivos por línea antes de los acopladores | Segmento MS/TP normalmente muy por debajo de 127 nodos | 32 unidades por segmento serie sin repetidor |
| Comportamiento de respuesta | Rápido para comandos de sala, lento para lecturas de grupo extensas | Las suscripciones COV reducen la carga de sondeo | El ciclo de sondeo crece con el número de dispositivos |
| Ciberseguridad | Bus local; los routers IP necesitan refuerzo de seguridad | Las redes IP necesitan segmentación y control de acceso | Enlaces serie aislados; TCP necesita reglas de red |
| Documentación | Plan de direcciones de grupo y lista de dispositivos | Lista de objetos con unidades y ajustes COV | Mapa de registros con escalado y orden de palabras |
| Cuándo no usarlo | Secuencias extensas de instalaciones y lógica entre emplazamientos | Lecturas sencillas de contadores en un enlace serie pequeño | Objetos complejos, alarmas y programación horaria |
Imágenes del proyecto
3 images
Preguntas frecuentes
01¿Cuál es mejor, KNX o BACnet?
Resuelven tareas distintas. KNX destaca en el control de salas y de campo; BACnet destaca en la integración de instalaciones y en la supervisión. Muchos proyectos usan ambos, con una pasarela o un controlador que habla los dos. La elección debe seguir al ecosistema de dispositivos, no a una preferencia. Un proyecto que obliga a todos los dispositivos a un único protocolo suele pagarlo en pasarelas o en funcionalidad perdida.
02¿Puede un controlador hablar los tres protocolos?
A veces, mediante interfaces nativas o pasarelas. Conviene comprobar qué protocolos son nativos, cuántos puntos admite cada interfaz y si el controlador puede ejecutar las secuencias necesarias mientras sondea dispositivos externos. El soporte nativo en una ficha técnica no garantiza la capacidad de puntos ni los servicios que requiere la secuencia.
03¿Es Modbus TCP lo mismo que Modbus RTU?
Comparten el mismo modelo de registros, pero utilizan un transporte diferente. RTU funciona sobre enlaces serie con restricciones de temporización; TCP funciona sobre Ethernet. Las pasarelas entre ambos son habituales y debe comprobarse el comportamiento del sondeo. Una pasarela TCP delante de un dispositivo serie lento no hace que ese dispositivo sea más rápido, y el tiempo de espera debe reflejar la respuesta real.
04¿Qué es un objeto BACnet?
Un objeto es la representación de un punto o una función dentro de un dispositivo, con propiedades como valor actual, unidades, estado y límites de alarma. La integración asigna esos objetos a los nombres de punto del sistema de supervisión. La asignación debe conservar unidades, escalado y significado, porque un objeto correctamente conectado con unidades incorrectas sigue siendo una lectura incorrecta.
05¿Se necesitan siempre pasarelas?
No. Muchos dispositivos exponen BACnet, Modbus o KNX directamente. Se necesita una pasarela cuando la interfaz, la topología o las licencias del fabricante exigen traducción. Toda pasarela debe tener un responsable y un comportamiento de fallo documentado. Cada pasarela añade además una dependencia de firmware, por lo que su historial de actualizaciones forma parte del plan de mantenimiento.
06¿Cuántos dispositivos caben en un bus?
Depende del protocolo, del segmento, del presupuesto de alimentación y de la topología. El diseño debe seguir la norma y las reglas del fabricante, y después verificar la carga y los tiempos de respuesta. No existe un número universal responsable. Un bus que funciona en banco con diez dispositivos puede comportarse de forma distinta con cuarenta, especialmente cuando el sondeo y la alimentación están cerca del límite.
07¿Cómo debe probarse una integración?
Punto por punto: valores normales, valores fuera de rango, desconexión, reinicio, prioridad de alarmas y sincronización horaria. Deben registrarse los resultados y entregarse los mapas de objetos o de registros. Una pasarela en línea no es lo mismo que una integración que funciona. La prueba también debe incluir la pérdida de la propia pasarela, porque ese es el fallo que el edificio acabará experimentando.
Siguiente paso
Tráiganos el edificio.
Cuéntenos el tipo de edificio, los sistemas incluidos y el resultado que necesita. Le mostraremos la ruta más corta hacia un sistema en funcionamiento.