BACnet frente a Modbus frente a OPC UA: una guía para integradores de edificios

BACnet, Modbus y OPC UA se diferencian en semántica, seguridad y preparación analítica. Esta guía compara los tres, además de dónde encaja el protocolo más reciente, oBIX.

Publicado20 de julio de 2026Tiempo de lectura9 min de lectura
BACnet frente a Modbus frente a OPC UA: una guía para integradores de edificios

Elige el protocolo equivocado el primer día de una integración de BMS y seguirás pagándolo cinco años después, normalmente en forma de una caja de gateway que nadie recuerda haber configurado. Elige bien y esa misma integración apenas se menciona en las notas de traspaso. Las consecuencias son así de desiguales, y aun así la decisión rara vez se toma a propósito. La mayoría de los edificios simplemente heredan el protocolo que envió el último contratista de controles.

Eso no es necesariamente incorrecto. BACnet, Modbus y OPC UA todavía tienen una función que cumplir, y la mayoría de las carteras de edificios operan más de uno a la vez. Lo que importa para cualquiera que intente llevar datos de sensores y contadores a una capa analítica es saber qué protocolo hace qué, dónde se le acaban las posibilidades a cada uno, y qué significa eso para el gateway o el agente que se sienta encima. Esta guía cubre los tres, además de oBIX, el recién llegado que la mayoría de los integradores solo ha encontrado una o dos veces.

BACnet: el predeterminado, con dos variantes

BACnet (Building Automation and Control Network) es el protocolo que habla de forma nativa la mayoría de los BMS modernos, y con razón. Es un estándar ANSI/ASHRAE e ISO diseñado específicamente para esta tarea, y define lo que significa un dato, no solo cómo se mueven los bytes: un "valor" que llega por BACnet ya lleva consigo un tipo de objeto, una temperatura, una consigna, un estado de alarma. Esa capa semántica es precisamente lo que no te da un protocolo industrial genérico, y es la razón por la que BACnet se convirtió en la lengua franca de la automatización de edificios en lugar de un bus de campo de propósito general adaptado a la tarea.

Donde se complica es en la división entre BACnet/IP y BACnet MS/TP. IP es la versión moderna, nativa de Ethernet; MS/TP es la variante serie más antigua que aún corre en muchas redes de controladores de nivel de campo, sobre todo cualquier cosa instalada antes de la última gran renovación de un edificio. Los dos no se comunican directamente entre sí. Un segmento MS/TP necesita un router o gateway para llegar a una red IP, y en los edificios más antiguos encontrarás varios de estos puentes apilados en un armario, cada uno un punto de fallo que nadie ha auditado en años. La nomenclatura de objetos está técnicamente estandarizada, pero los fabricantes interpretan la especificación con suficiente variación local como para que un ingeniero de controles que se mueva entre una cartera Siemens Desigo y una Schneider EcoStruxure siga encontrando friccion al mapear puntos limpiamente.

Para cualquiera que construya sobre un sistema de gestión de edificios, la conclusión práctica es que la cobertura BACnet por sí sola no garantiza una lectura sencilla. Confirma si la red con la que estás integrando corre IP o MS/TP, y presupuesta el gateway si es lo segundo. Los detalles completos del protocolo, incluido cómo funciona el modelo de objetos, están en nuestra página del glosario de BACnet.

Modbus: antiguo, simple, y todavía en cada contador

Modbus precede a BACnet por más de una década. Modicon lo introdujo en 1979, y sobrevive hoy por la misma razón que sobrevive mucha tecnología antigua y aburrida: es simple, es libre de regalías, y todos los fabricantes de contadores de energía, subcontadores y controladores de planta heredados ya saben implementarlo. Hay dos variantes en uso activo. Modbus RTU es la forma serie original, que corre sobre RS-485 o RS-232 con tramas binarias compactas. Modbus TCP envuelve el mismo modelo de datos en Ethernet, y es la más fácil de integrar en una red moderna. Un contador serie RTU llega a una red IP a través de un gateway, el mismo patrón que BACnet MS/TP.

El problema con Modbus es que transporta valores, no significado. Un cliente sondea un dispositivo por el contenido de un registro numerado, y eso es todo: sin autodescripción, sin unidades incorporadas, sin indicación de si el registro 40012 es una lectura de kWh o la posición de una válvula. Necesitas el mapa de registros del dispositivo para saber qué estás leyendo, y ese mapa vive en un PDF del fabricante del contador, no en el protocolo mismo. Si te equivocas con el mapa, ingerirás alegremente basura que parece datos. Tampoco hay autenticación ni cifrado incorporados, algo que rara vez es un problema en una red de contadores aislada pero que conviene saber antes de exponer una a algo más amplio.

En la práctica, Modbus y BACnet coexisten constantemente: BACnet gestiona el BMS, Modbus alimenta los contadores que el BMS no lee de forma nativa. Esa mezcla es exactamente la materia prima que necesita el software de gestión energética para convertir lecturas en decisiones, siempre que cada registro se mapee primero a algo físico. Más sobre el propio protocolo en nuestra página del glosario de Modbus.

OPC UA: moderno, seguro y semántico

OPC UA (Unified Architecture) es el más reciente de los tres protocolos principales y el construido con la ingeniería más deliberada. Sustituyó al antiguo estándar OPC Classic y se diseñó desde el principio para ser independiente de la plataforma, orientado a servicios y seguro: la autenticación, el cifrado y el control de acceso forman parte de la especificación, no se añaden después como tendrían que hacerse con Modbus. También define un modelo de objetos genuinamente rico, más cercano al enfoque de BACnet que al de Modbus, lo que hace que la integración sea considerablemente menos frágil una vez configurada.

El terreno natural de OPC UA es la fabricación y las industrias de proceso, donde se ha convertido casi en el estándar para el intercambio de datos máquina a máquina. En los edificios aparece donde el BMS se ha modernizado recientemente o donde convergen los datos de edificio e industriales, por ejemplo un centro de datos, una fábrica con un bloque de oficinas anexo, o cualquier sitio donde se pide a los equipos de OT y de TI que compartan una capa de datos. Esa convergencia es gran parte de por qué OPC UA importa para la integración de edificios aunque no empezara ahí. Las suscripciones a eventos de cambio de valor funcionan de forma nativa, así que obtienes actualizaciones push en lugar de sondeo constante, y el perfil de seguridad en uso en un sitio determinado decide exactamente cómo se gestiona la autenticación en el momento de la conexión. El panorama completo está en nuestra página del glosario de OPC UA.

oBIX: el más reciente, sobre todo en Niagara

oBIX (Open Building Information Exchange) merece su propia sección, no porque esté sustituyendo a nada sino porque sigue apareciendo en rincones específicos de la pila de edificios que los otros tres protocolos no cubren con la misma limpieza. Es un estándar de OASIS, publicado por primera vez en 2006, y adopta un enfoque técnico diferente: servicios web XML sobre HTTP en lugar de un protocolo de edificios diseñado a propósito o un bus de campo industrial. En la práctica, el lugar donde te encuentras con oBIX es una estación Tridium Niagara. Niagara expone sus puntos a través de oBIX (y a menudo también BACnet), y cualquier despliegue de Honeywell WEBs o JACE de terceros que corra sobre el framework Niagara suele ofrecer la misma opción.

Añadimos soporte para oBIX al FrostLogic Edge Agent porque nos encontrábamos constantemente con exactamente esta situación: una cartera mixta en la que la mayoría de los edificios hablan BACnet con limpieza pero uno o dos operan un supervisor Niagara que es más fácil de leer por oBIX. El Edge Agent ahora habla cuatro protocolos, BACnet, Modbus, OPC UA y oBIX, y su primera conexión oBIX en producción se ejecutó contra un BMS Tridium Niagara. Eso no es un caso de estudio, es simplemente cómo se ve la matriz de integración en una semana normal de incorporación de edificios. Si operas una cartera Niagara específicamente, nuestra página de integraciones con Honeywell Niagara cubre los detalles de conexión, y la mecánica de oBIX en sí está en nuestra página del glosario de oBIX.

La comparación de un vistazo

BACnetModbusOPC UAoBIX
Caso de usoRedes de automatización de edificiosContadores, subcontadores, planta heredadaDatos industriales + de edificios modernizadosDatos de estación Niagara/Tridium
SemánticaModelo de objetos rico, autodescriptivoNinguna; solo valores de registro en brutoModelo de objetos rico, autodescriptivoRecursos web autodescriptivos
SeguridadVaría según la implementación del fabricanteNinguna incorporadaIntegrada en la especificaciónCapa HTTP (TLS cuando está configurado)
Equipo típicoBMS moderno, UTA, controladoresContadores de energía/agua, VFD, planta antiguaSistemas de fabricación, BMS modernizadoEstaciones Tridium Niagara, Honeywell WEBs, JACE
Preparación analíticaAlta, una vez resuelto IP frente a MS/TPBaja hasta que se mapean los registrosAlta desde el primer momentoAlta para datos nativos de Niagara

Qué significa esto para llevar datos a una capa analítica

Nada de esto cambia lo que realmente necesita una capa analítica: acceso de lectura a lo que ya está corriendo, sin tocar el sistema de control. Un sistema de gestión de edificios que corre BACnet para sus UTA, Modbus para sus contadores y posiblemente OPC UA u oBIX en alguna parte de la mezcla no es un problema de integración que resolver una vez. Es la forma normal de una cartera real, y la capa de ingesta tiene que gestionarlo todo a la vez, sin obligar a un sitio a estandarizarse en un protocolo antes de poder leerlo.

El FrostLogic Edge Agent está construido en torno a esa realidad. Se instala en el PC o servidor del BMS, lee BACnet, Modbus, OPC UA y oBIX en modo de solo lectura, y envía los datos a FrostLogic Explore, que los convierte en una cola de decisiones clasificada en lugar de otro panel de control. La configuración específica de cada fabricante, ya sea una red BACnet de Siemens Desigo o una cartera Schneider EcoStruxure con sus propias particularidades, está documentada en nuestras páginas de integraciones en lugar de enterrada en una especificación de protocolo genérica. Lo que hable tu BMS, lo leemos. Consulta las integraciones compatibles.

Preguntas frecuentes

¿Qué protocolo debo usar para una nueva integración de BMS? Usa lo que el equipo ya hable. BACnet es la opción segura por defecto para un BMS moderno y la que hay que especificar si se redacta un nuevo contrato de controles. No fuerces un cambio de protocolo solo por el afán de estandarizar; un contador Modbus que funciona o un flujo OPC UA de un sistema de proceso no necesitan sustituirse.

¿Pueden coexistir BACnet y Modbus en el mismo edificio? Sí, y es la configuración más común en la práctica. BACnet suele gestionar el BMS y sus controladores, mientras que Modbus alimenta contadores de energía, subcontadores y planta antigua que nunca migró a BACnet. Ningún protocolo tiene que desaparecer para que el otro funcione.

¿Necesita FrostLogic Explore un gateway para OPC UA? No. Explore lee OPC UA de forma nativa, incluidas las suscripciones a eventos de cambio de valor, con la autenticación y el cifrado gestionados según el perfil de seguridad que ya usa el sitio. Los gateways entran en juego para BACnet MS/TP y Modbus RTU, las dos variantes serie, no para OPC UA.

¿Qué es oBIX y lo necesito? oBIX es un estándar de servicios web para leer datos de edificios por HTTP, que se encuentra sobre todo en una estación Tridium Niagara. Lo necesitas específicamente si parte de tu cartera opera Niagara o un producto basado en Niagara como Honeywell WEBs. Si tus edificios corren un BMS BACnet estándar con contadores Modbus, oBIX simplemente no entrará en juego.

FrostLogic Explore lleva la inteligencia de sensores, la simulación de escenarios y la IA de inferencia fundamentada a los edificios comerciales e industriales. Más información sobre Sensor Intelligence o háblelo con nosotros.

¿Le interesa ver cómo quedaría en su edificio?

¿Qué no le está contando su edificio?

Cuéntenos qué intenta averiguar: un consumo que se desvía, un BMS del que no se fía, una normativa que intenta alcanzar. Primero escuchamos, y después le decimos con franqueza si Explore le sirve. 30 o 60 minutos, usted elige. Sin compromiso en cualquier caso.