BMS vs IBMS — ¿supervisión o integración?

Profundidad de integración: pasarelas frente a un modelo común

Muchos proyectos de BMS integran mediante pasarelas: cada subsistema conserva su propio modelo y el BMS asigna puntos seleccionados a los gráficos. Eso funciona para la supervisión, pero la lógica entre sistemas se vuelve frágil porque cada regla depende de la nomenclatura de un proveedor. Se espera que un IBMS normalice los puntos en un único modelo de objetos, con identidad, unidades, calidad e historial, y que aplique un único modelo de alarmas y un único motor de interbloqueos. La diferencia se manifiesta durante el cambio: renombrar un punto en un sistema no debería romper una regla en otro. También se manifiesta en los informes, donde una misma métrica debe significar lo mismo en todos los subsistemas. Un modelo común también abarata añadir un nuevo subsistema, porque las reglas de nomenclatura y de alarmas ya existen.

Cuándo se justifica un IBMS

Un IBMS justifica su coste cuando las decisiones cruzan los límites entre sistemas: un evento de incendio que debe liberar un acceso, la entrada de un inquilino que debe activar la climatización (HVAC) y la iluminación, un recinto que necesita una única vista energética, una sala de control que supervisa varios edificios. También ayuda cuando la responsabilidad está distribuida, porque un registro de auditoría común permite rastrear cada acción. Un edificio único con una instalación pequeña, un solo operador y pocos sistemas de terceros normalmente no necesita esa maquinaria; un BMS bien delimitado con exportaciones abiertas es más fácil de operar. La prueba no es el tamaño del edificio, sino el número de decisiones acopladas. Si un edificio tiene una sala de máquinas y un equipo, un IBMS puede añadir coste sin añadir ninguna decisión que alguien necesite tomar.

El riesgo de la entrega es el alcance, no la tecnología

La mayoría de los problemas de un IBMS son problemas de alcance. Integrarlo todo produce integraciones superficiales, responsabilidades poco claras y una lista de alarmas en la que nadie confía. Empiece con una matriz de subsistemas: filas para cada sistema, columnas para supervisión, control, alarmas, interbloqueos e informes. Marque qué queda fuera del alcance y por qué. Asigne la interfaz a una sola parte, indique el protocolo y defina una prueba de aceptación para cada fila. Ese documento es más valioso que una demostración de la plataforma, porque sobrevive hasta la puesta en marcha y la entrega. También permite al cliente comparar propuestas sin comparar presentaciones. Redáctelo antes de la licitación, no después de la reunión de inicio, y manténgalo vivo durante los cambios de diseño.

• Filas: todos los subsistemas, incluidos los excluidos explícitamente
• Profundidad: supervisar, controlar, alarmar, interbloquear o informar
• Interfaz: protocolo, responsable de la pasarela y mapa de puntos
• Aceptación: la prueba que demuestra cada fila