BACnet, KNX o Modbus: elegir un protocolo del que no te arrepientas en diez años

Esta pregunta aparece en casi todos los proyectos, normalmente planteada como una elección entre tres opciones. El planteamiento es erróneo. Casi cualquier edificio no trivial acaba funcionando con al menos dos de ellos, y la decisión de proyecto que de verdad importa es dónde están las fronteras entre ellos y quién es dueño de la traducción.

Aun así, no se puede tomar esa decisión sin saber en qué es genuinamente bueno cada protocolo.

Los tres, en breve y con honestidad

BACnet

Protocolo abierto de automatización de edificios, normalizado como ASHRAE 135 e internacionalmente como ISO 16484-5. Su rasgo distintivo es que es orientado a objetos y semántico: un punto no es solo un número en una dirección, es un objeto con tipo, unidades, valor presente, matriz de prioridades y propiedades de alarma y tendencia. Dos dispositivos de fabricantes distintos pueden así mantener una conversación con sentido sobre lo que un valor significa.

Funciona sobre IP (BACnet/IP) y sobre RS-485 (BACnet MS/TP). Encaja de forma natural en el nivel de planta y supervisión: climatizadoras, enfriadoras, calderas y el puesto central que las vigila. Es comparativamente pesado para encender una luz.

KNX

Bus descentralizado de nivel de campo, normalizado como EN 50090 e ISO/IEC 14543-3, con una penetración muy fuerte en automatización de sala en Europa. Su rasgo distintivo es la interoperabilidad certificada: los dispositivos se ensayan contra un modelo común, se configuran con una única herramienta, y no hay un controlador central que deba sobrevivir para que la sala siga funcionando.

Esa descentralización es su verdadero argumento. La iluminación, la protección solar y el control terminal siguen operando cuando la capa de supervisión está caída o se está sustituyendo. Es excelente en la sala, y no es lo que quieres para ejecutar la secuencia de una enfriadora.

Modbus

En realidad no es un par de los otros dos, y es más claro dejar de tratarlo como tal. Modbus es un protocolo simple, antiguo y basado en registros —RTU sobre serie, TCP sobre Ethernet— sin ninguna capa semántica. Lees un número de una dirección. Lo que ese número significa vive en un PDF del fabricante, y posiblemente en un factor de escala escondido en una nota al pie.

Suena a crítica. No lo es del todo. Modbus es la forma en que los contadores, variadores, inversores, enfriadoras y equipos compactos del mundo te van a hablar, lo hayas elegido o no. Es el disolvente universal de la integración, y su simplicidad es la razón de que siga en todas partes.

La arquitectura que suele resultar

En un edificio terciario mediano o grande, la forma que más a menudo sobrevive al contacto con la realidad es:

• KNX a nivel de sala — iluminación, protección solar, presencia, unidades terminales, ajuste local de consigna.
• BACnet a nivel de planta y supervisión — climatizadoras, generación, distribución, puesto central, tendencias y alarmas.
• Modbus a nivel de dispositivo — contadores, variadores, equipos compactos, todo lo que vino con un documento de integración en lugar de un perfil.
• Pasarelas definidas en cada frontera, con una lista explícita y documentada de qué la cruza.

Ese último punto es donde los proyectos se ganan o se pierden.

El problema de las pasarelas

Cada pasarela es tres riesgos a la vez: una traducción que puede estar mal, un equipo que puede fallar y una dependencia comercial que puede licenciarse, descatalogarse o convertirse en rehén en la renovación. Un edificio que ha acumulado pasarelas de integración en integración, sin una arquitectura que lo gobierne, acaba con un sistema de control que nadie puede describir por completo — lo que significa que nadie puede cambiarlo con seguridad.

Dos reglas lo mantienen manejable:

1. Especifica qué cruza la frontera, no solo que la frontera existe. Una lista de puntos que indique exactamente qué valores pasan entre KNX y BACnet, en qué sentido, con qué frecuencia de actualización y con qué comportamiento ante fallo. Lo que no está en la lista, no cruza.
2. Mantén el recuento deliberado. Cada pasarela adicional necesita una razón que aguante decirse en voz alta. «El equipo del subcontratista solo habla su propio protocolo» no es una razón; es una decisión de compra tomada por omisión.

Los criterios que de verdad deciden

Las tablas comparativas de protocolos se centran en capacidad técnica, que rara vez es la restricción determinante. En la práctica, las decisiones que importan a lo largo de la vida del edificio son comerciales y organizativas:

• ¿Puedes volver a licitar el mantenimiento? Si exactamente un integrador puede acceder a la configuración, has comprado una suscripción, no un sistema. Es el error más caro de este campo.
• ¿Quién custodia los archivos de configuración, y están en la entrega? Nómbralos en el pliego. Recíbelos. Comprueba que abren.
• ¿Cómo es el mercado local de integradores? Un protocolo con tres empresas capaces a una hora en coche gana a otro técnicamente superior sin ninguna.
• ¿Qué pasa cuando la capa de supervisión está apagada? Decide deliberadamente qué funciones deben sobrevivir y bájalas a una capa que siga funcionando.
• ¿Puedes leer los puntos con algo escrito por ti? Si alguna vez quieres analítica, detección de fallos o tu propio panel, el acceso abierto de lectura es lo que lo hace posible.

Entonces, ¿qué especificamos?

Protocolos abiertos en cada capa, fronteras trazadas a propósito, una lista de puntos documentada en cada frontera y los archivos de configuración nombrados como entregable contractual. Y después dejamos que oferte más de un integrador.

El objetivo no es la pureza de protocolo. Es que dentro de diez años, cuando se sustituya el puesto central y el integrador original haya sido absorbido, alguien pueda todavía abrir el sistema, entender qué hace y modificarlo — sin un proyecto de rescate.