Un IBMS se describe a menudo como «una plataforma que lo conecta todo». Esa descripción es cierta e inútil. La pregunta útil es dónde se produce la conexión, quién es propietario de los datos y qué ocurre cuando un subsistema funciona mal.
Utilizamos un modelo de tres capas en cada proyecto: dispositivo, supervisión y aplicación. Procede del modelo de integración distribuida empleado en la especificación del proyecto en la que se basa esta práctica, y ha resistido el contacto con edificios reales porque mantiene las responsabilidades explícitas.
Por qué lo plano supera a lo profundo
Cada pasarela adicional, traductor de protocolos o salto de middleware añade latencia, un punto de fallo y un lugar donde el modelo de datos puede desviarse. Una arquitectura plana reduce el número de traducciones entre un sensor y la persona que debe actuar a partir de él.
Plano no significa «sin jerarquía». Significa que la jerarquía es funcional, no accidental: controladores en el borde, un núcleo de supervisión y aplicaciones que leen de ese núcleo en lugar de construir sus propias bases de datos en la sombra.

Capa 1: dispositivo
La capa de dispositivo es donde se produce el control físico. Los controladores y módulos de E/S de Loxone ejecutan secuencias locales, leen sensores y gobiernan actuadores. Los sistemas de terceros se conectan mediante pasarelas o interfaces nativas: BACnet/IP para instalaciones, Modbus para medidores e inversores, KNX para iluminación y protección solar, DALI para luminarias y contactos secos para incendios y equipos heredados.
La decisión de diseño importante no es qué protocolo gana. Es qué controlador asume cada secuencia y qué ocurre cuando la capa de supervisión está desconectada. El control local debe ser lo bastante completo para que el edificio siga siendo seguro y utilizable.
Capa 2: supervisión
La capa de supervisión es el núcleo de integración. Normaliza cada subsistema en un modelo de objetos común: un punto tiene una identidad, una unidad, un indicador de calidad, un estado de alarma y un historial. Una puerta es una puerta tanto si proviene de un controlador de acceso como de un PLC. Una temperatura es una temperatura tanto si llega por BACnet como por Modbus.
Aquí es donde residen los interbloqueos entre sistemas. El control de acceso abre una sala; la iluminación, la climatización (HVAC) y el CCTV responden. El interbloqueo se configura en la capa de supervisión, no se cablea entre controladores de distintos fabricantes. Eso lo hace visible, comprobable y modificable.
Qué debe asumir la capa de supervisión
- Un único modelo de alarmas con prioridad, reconocimiento y escalado.
- Un modelo de horarios que pueda anularse sin editar el código del controlador.
- Un registro de auditoría de comandos, consignas y reconocimientos.
- Un modelo de historial que almacene datos de intervalo con una resolución conocida.
- Una convención de nombres que sobreviva a la entrega.
Capa 3: aplicación
La capa de aplicación es lo que ve la gente. Debe construirse para roles, no para la demostración del integrador: una vista de operador que muestre lo que requiere atención, una vista de ingeniero que exponga puntos y tendencias y una vista de dirección que informe de los resultados.
Las aplicaciones leen del núcleo de supervisión. No consultan los subsistemas directamente ni mantienen su propia copia de la verdad. Esa regla evita el modo de fallo clásico en el que el panel de control y el BMS no coinciden.
Un ejemplo práctico
Un inquilino entra en una planta a las 07:40. El controlador de acceso informa del evento. La capa de supervisión comprueba el horario del inquilino y el estado de ocupación de la planta. Activa la escena de iluminación, inicia la secuencia de climatización y solicita al CCTV que marque el evento de entrada. El operador ve un evento, no cuatro.
Si un comportamiento entre sistemas no puede describirse en una frase, probablemente pertenece a una secuencia documentada y no a un script oculto.
Qué especificar
| Requisito | Por qué importa |
|---|---|
| Independencia del control local | El edificio debe seguir siendo seguro y utilizable durante una caída de la red o de la nube. |
| Lista de protocolos abiertos | Evita que un único fabricante se convierta en la única vía de acceso a los datos del edificio. |
| Modelo único de alarmas | Evita alarmas duplicadas y hace auditable el escalado. |
| Convención de nombres de puntos | Hace posible la entrega, el mantenimiento y la integración futura. |
| Retención y exportación del historial | Las afirmaciones sobre energía y rendimiento necesitan una trazabilidad de datos defendible. |
Un modelo de tres capas no es un diagrama de producto. Es un diagrama de responsabilidades. Si no puede decir qué capa asume un comportamiento, probablemente el comportamiento está en el lugar equivocado.
Conclusión
La arquitectura IBMS no consiste en conectar el mayor número de sistemas. Consiste en hacer legibles las conexiones: un modelo de datos, un modelo de alarmas, un registro de auditoría y un control local que sobreviva a la red. Si eso está bien resuelto, el panel de control es fácil. Si está mal, ningún panel de control salvará el proyecto.


