IBMS
IBMS — sistema integrado de gestión de edificios
El IBMS explicado: cómo un sistema integrado de gestión de edificios unifica la climatización (HVAC), la iluminación, el control de acceso, el CCTV, la energía y el estado de incendios en una única imagen operativa.
Qué significa IBMS
IBMS significa sistema integrado de gestión de edificios. Es una capa de integración, no una marca única de controlador. Recopila datos del BMS y de otros sistemas del edificio, normaliza esos datos en un modelo común y ofrece a los operadores un único lugar para ver el estado, confirmar alarmas y emitir órdenes. El BMS sigue controlando las instalaciones; el IBMS coordina entre sistemas e informa sobre el edificio en su conjunto. Esa distinción mantiene la arquitectura honesta y evita que un proyecto de integración se convierta en una sustitución de control no planificada. Esa frontera también importa comercialmente: un IBMS no debe convertirse en una forma de sustituir un BMS en funcionamiento sin una decisión independiente. El IBMS debe presupuestarse y delimitarse como un servicio de integración, no como una licencia con ingeniería no especificada. Un alcance claro nombra los sistemas, los datos, las reglas y los roles de operador que la plataforma debe admitir.
- Capa de integración por encima del BMS
- Modelo común de datos y alarmas
- Una única vista del operador para todos los sistemas
- El BMS conserva el control de las instalaciones
Subsistemas en un solo modelo
Un alcance típico de IBMS incluye climatización (HVAC) e instalaciones, iluminación, protección solar, control de acceso, CCTV, alarma de intrusión, aparcamiento, megafonía, ascensores, medidores de energía, control de habitaciones de hotel y estado de incendios. Cada subsistema conserva su propio controlador y sus propias responsabilidades de seguridad. El IBMS lee estados, escribe órdenes permitidas y enlaza eventos entre sistemas. La matriz de integración debe indicar, para cada subsistema, qué datos son de solo lectura, cuáles son escribibles y qué proveedor sigue siendo responsable del equipo. Esa matriz es la definición práctica del proyecto. Cada subsistema debe tener un propietario designado, un documento de interfaz y un modo de fallo probado. Los puntos de solo lectura no son una limitación; son una frontera que protege la seguridad y la garantía del subsistema. La matriz también debe registrar la dirección de los datos, la frecuencia de actualización y el comportamiento cuando se pierde el enlace, porque esos tres detalles deciden si el operador puede confiar en la pantalla.
- Climatización (HVAC), iluminación y protección solar
- Control de acceso, CCTV e intrusión
- Aparcamiento, ascensores y megafonía
- Energía, habitaciones de hotel y estado de incendios
Alarmas que los operadores pueden utilizar
Un IBMS recopila alarmas de sistemas que nunca se diseñaron para compartirlas. Sin racionalización, el resultado es un muro de ruido. Un modelo de alarmas viable normaliza las descripciones, elimina duplicados, clasifica los eventos por consecuencia, los dirige al rol adecuado y registra la confirmación y la escalada. Un fallo de agua enfriada, una puerta forzada y un fallo de comunicación de un medidor no deben llegar con la misma prioridad. La filosofía de alarmas se acuerda durante el diseño, se prueba durante la puesta en marcha y se revisa después de la primera temporada de operación. El operador debe poder ver por qué se generó una alarma, no solo que existe; el contexto forma parte de la alarma. Deben revisarse los recuentos de alarmas y los eventos repetidos, porque un sistema ruidoso enseña a los operadores a ignorarlo. Una métrica útil es cuántas alarmas requieren acción; si la mayoría son eventos molestos, el modelo de alarmas necesita trabajo, no más pantallas.
- Descripciones de alarma normalizadas
- Clasificación por consecuencia
- Enrutamiento, confirmación y escalada
- Revisión de alarmas tras la temporada
Interbloqueos y lógica entre sistemas
El valor de un IBMS aparece cuando los sistemas actúan juntos. El acceso que abre una sala puede llevar la iluminación, la climatización (HVAC) y el CCTV al estado adecuado. La entrada de un vehículo al aparcamiento puede encender la iluminación de la zona de aproximación. Una alarma de incendios puede liberar puertas y detener unidades manejadoras de aire, mientras el panel de incendios conserva la autoridad sobre las funciones de seguridad de personas. Los interbloqueos deben configurarse como reglas visibles, no como cableado oculto entre controladores de proveedores. Cada regla necesita un disparador, una condición, una acción, un tiempo de espera y un comportamiento ante fallo. Las pruebas demuestran que la regla funciona, y el registro de auditoría muestra quién la modificó. Una regla que no se puede probar no debe desplegarse, porque el edificio acabará dependiendo de ella. Las reglas entre sistemas deben fallar en una dirección definida, normalmente dejando el subsistema afectado en su estado seguro local. Las reglas también necesitan un propietario y una fecha de revisión; de lo contrario, se acumulan y se contradicen entre sí.
- Vinculación de acceso, iluminación y climatización (HVAC)
- Iluminación de aparcamiento y fachada
- Modo incendio con autoridad del panel
- Reglas visibles con registros de auditoría
Experiencia del operador
Un IBMS se juzga a las 02:00, cuando hay una sola persona de turno y algo va mal. La interfaz debe mostrar qué ha cambiado, dónde está, qué afecta y qué hacer a continuación. Las vistas según el rol mantienen al operador, al ingeniero y a la dirección sobre los mismos datos con distintos niveles de detalle. Los planos de planta, las tendencias y el historial de alarmas deben ser accesibles sin rebuscar en los menús. El acceso móvil ayuda a un equipo pequeño a cubrir un emplazamiento grande. La formación y la documentación forman parte del producto, no son un añadido. Una prueba útil es que una persona no familiarizada con el proyecto complete una tarea rutinaria sin pedir ayuda. Las vistas deben diseñarse en torno a roles y tareas, no en torno a la estructura de menús del proveedor. La interfaz también debe distinguir un valor medido de un valor obsoleto, porque una pantalla que parece en vivo pero muestra datos antiguos es peor que ninguna pantalla.
- Jerarquía clara y navegación en detalle
- Vistas y permisos según el rol
- Tendencias, planos de planta e historial de alarmas
- Formación y documentación para el operador
Protocolos abiertos y control con prioridad local
El IBMS depende de las interfaces. BACnet/IP y Modbus son habituales para instalaciones y medidores, KNX para iluminación y control de salas, DALI para luminarias, API y ODBC para sistemas de negocio, y contactos secos para equipos que no ofrecen otra cosa. La plataforma debe ejecutarse en la red local, conservar el historial en el emplazamiento y tratar el acceso remoto como una opción con autenticación y registro. La segmentación de red entre OT e IT forma parte del diseño. El propietario debe poder cambiar de integrador sin perder el modelo de puntos, los gráficos ni los datos. La documentación debe incluir el diagrama de red, el modelo de puntos y la situación de las licencias, para que el propietario no quede atado a un único proveedor. El acceso remoto debe poder revocarse sin interrumpir la operación local. La prioridad local no significa aislamiento: significa que el edificio sigue funcionando cuando el enlace de área amplia no lo hace, y que el operador puede seguir accediendo a los datos en el emplazamiento.
- BACnet, Modbus, KNX y DALI
- API y ODBC para sistemas de negocio
- Servidores locales e historial
- Segmentación y acceso remoto auditado
Arquitectura, redes y ciberseguridad
Un IBMS es un proyecto de red tanto como un proyecto de control. El servidor de integración, las pasarelas y los clientes de operador residen en una red segmentada; los servicios del edificio no deben compartir una red plana con la IT de oficina. Un diseño habitual utiliza una VLAN de OT dedicada, un cortafuegos entre OT e IT y acceso remoto controlado mediante una VPN o un broker con autenticación multifactor. La sincronización horaria importa porque las alarmas y tendencias de distintos sistemas deben coincidir; sin una fuente de tiempo coherente, la correlación de eventos se convierte en conjeturas. Deben especificarse el almacenamiento del historial, la copia de seguridad y la restauración, incluido durante cuánto tiempo se conservan los datos y quién puede exportarlos. Las cuentas de usuario deben proceder de un directorio cuando sea posible, con permisos según el rol y un registro de auditoría de órdenes y cambios de consigna. El acceso remoto debe poder revocarse sin interrumpir la operación local. La ciberseguridad no es una característica del producto añadida al final; forma parte de la arquitectura de integración.
- Segmentación de OT e IT
- Sincronización horaria coherente
- Cuentas según el rol y registros de auditoría
- Política de copias de seguridad, retención y acceso remoto
Etapas de entrega y modos de fallo habituales
La entrega sigue una secuencia. Una auditoría confirma los sistemas, las versiones y las interfaces disponibles. Una matriz de integración define los derechos de lectura y escritura, los propietarios y las fronteras. Un modelo de puntos asigna a cada elemento un nombre, una unidad, un permiso y una prioridad de alarma. Las pasarelas e interfaces se configuran y prueban en fábrica cuando es posible, y después en obra. La puesta en marcha pasa de las comprobaciones punto a punto a las reglas entre sistemas y las pruebas de fallo, y termina con un periodo de transición suave en el que los operadores utilizan el sistema en condiciones reales. La documentación incluye el diagrama de red, el modelo de puntos, la matriz de integración, los registros de pruebas, la situación de las licencias y el procedimiento de recuperación. Los modos de fallo habituales son previsibles: una API que se supuso pero nunca se probó, avalanchas de alarmas que ocultan el evento real, datos obsoletos de una pasarela, nombres de puntos duplicados, deriva horaria entre sistemas y un modelo de licencias que impide al propietario añadir puntos sin el proveedor original.
- Auditoría y matriz de integración
- Modelo de puntos y pruebas de pasarelas
- Pruebas entre sistemas y de fallo
- Transición suave y registros conforme a obra
Matriz de integración del IBMS
18 rows| Subsistema | Interfaz típica | Rol del IBMS | Frontera |
|---|---|---|---|
| Climatización (HVAC) y BMS | BACnet/IP, Modbus, 0–10 V | Horarios, valores de consigna, alarmas, tendencias | El BMS conserva el control de las instalaciones |
| Iluminación | DALI, KNX, relés | Escenas, ocupación, estado de fallo | El controlador de iluminación conserva el control local |
| Protección solar | KNX, Modbus, contactos secos | Reglas solar y de viento, escenas | El controlador de motores o de fachada conserva los límites |
| Control de acceso | API, OSDP mediante controlador, contactos secos | Estado de puertas, apertura, vinculación de eventos | El sistema de acceso conserva la lógica de permisos |
| CCTV | ONVIF o API del proveedor | Mapa de cámaras, vinculación de eventos, estado de salud | El VMS conserva la grabación y la retención |
| Alarma de intrusión | Contactos secos, API | Estado de zonas, eventos de armado/desarmado | El panel de alarma conserva la lógica de detección |
| Alarma de incendio | Contactos secos, entradas supervisadas | Solo estado, prealarma y enlaces | El panel de incendios conserva la autoridad de seguridad de las personas |
| Control de humos | Contactos secos, API | Estado y posición de la compuerta | El sistema de control de humos conserva su secuencia |
| Aparcamiento | API, TCP/IP | Estado de entradas, conteo de espacios, excepciones | El sistema de aparcamiento conserva el control de la barrera |
| Megafonía | API, contactos secos | Estado de zonas, mensajes programados | El sistema de megafonía conserva la prioridad de emergencia |
| Ascensores | Contactos secos, API | Señales de estado, avería y alarma | El controlador del ascensor conserva la seguridad de movimiento |
| Contadores de energía | Modbus, M-Bus mediante pasarela, pulsos | Medición secundaria, líneas de base, reparto | El sistema de medición conserva los datos de tarifa |
| Contadores de agua y gas | Modbus, M-Bus mediante pasarela, pulsos | Tendencias de consumo y alarmas de fuga | La medición de servicios conserva los datos de facturación |
| Carga de vehículos eléctricos | OCPP, API del fabricante | Estado de sesión, control de carga, excepciones | El operador del cargador conserva la facturación y la seguridad |
| UPS y generadores | SNMP, Modbus, contactos secos | Horas de funcionamiento, estado del combustible, eventos de transferencia | El sistema de alimentación conserva la lógica de transferencia |
| Habitaciones de hotel y PMS | API, ODBC, interfaz RCU | Eventos de entrada y salida, estado de la habitación, límites de energía | El PMS conserva las reservas y la facturación |
| Gestión de visitantes | API, contactos secos | Estado de preregistro, eventos de puerta | El sistema de visitantes conserva las verificaciones de identidad |
| Analítica de edificios y FDD | API del historiador, exportación de base de datos | Detección de fallos, líneas de base, informes de rendimiento | La capa de analítica conserva sus modelos |
Imágenes del proyecto
3 images
Preguntas frecuentes
01¿Qué es un IBMS?
Un sistema integrado de gestión de edificios conecta los subsistemas del edificio en un único modelo de datos, una única lista de alarmas y una única vista para el operador. Añade reglas e informes entre sistemas, mientras cada subsistema conserva su propio controlador y sus responsabilidades de seguridad.
02¿Cuál es la diferencia entre IBMS y BMS?
Un BMS controla y supervisa los servicios del edificio, especialmente la climatización (HVAC) y las instalaciones. Un IBMS se sitúa por encima e integra el BMS con acceso, CCTV, aparcamiento, energía, habitaciones de hotel y estado de incendios. El BMS sigue siendo la capa de control.
03¿Hay que sustituir el BMS existente?
No. El enfoque habitual es integrar el BMS existente mediante BACnet, Modbus u otra interfaz disponible. La sustitución es una decisión comercial independiente, no una condición previa para un IBMS.
04¿Puede un IBMS funcionar sin internet?
Sí. La plataforma de integración y la lógica de control deben ejecutarse en la red local, con el historial almacenado en el sitio. El acceso a internet es opcional para soporte remoto e informes.
05¿Qué protocolos admite un IBMS?
Las interfaces habituales incluyen BACnet/IP, Modbus RTU y TCP, KNX, DALI, API, ODBC y contactos secos. El conjunto real depende de los equipos instalados y de las pasarelas seleccionadas para el proyecto.
06¿Cómo se gestionan las alarmas de incendio?
El incendio sigue siendo un sistema independiente de seguridad de las personas. El IBMS lee el estado y las señales de prealarma mediante contactos secos o entradas supervisadas y puede activar enlaces definidos, pero el panel de incendios conserva la autoridad en todo momento.
07¿Cómo se priorizan las alarmas?
Las alarmas se normalizan, se eliminan los duplicados y se ordenan por consecuencia, no por sistema de origen. La filosofía de alarmas define la prioridad, el enrutamiento, el acuse de recibo y el escalado, y se prueba durante la puesta en marcha.
08¿Puede un IBMS abarcar varios edificios?
Sí. Los controladores locales pueden gobernar cada edificio mientras una capa central consolida alarmas, energía e informes. El diseño debe definir qué permanece local y qué depende de la red entre sitios.
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.