IBMS · Arquitectura
Arquitectura de un IBMS — un modelo de referencia que sobrevive a la entrega
Una arquitectura de referencia para un IBMS: dispositivos de campo, una capa de red y pasarelas, un núcleo de supervisión con un único modelo de datos y aplicaciones basadas en roles.
Respuesta rápida
Una arquitectura de IBMS tiene cuatro capas: dispositivos de campo y controladores, la capa de red y pasarelas, un núcleo de supervisión con un único modelo de datos y aplicaciones basadas en roles. El control permanece local, la lógica de integración reside en el núcleo y las aplicaciones leen de él en lugar de consultar directamente los subsistemas.
Cuatro capas, una única fuente de verdad
Considere la arquitectura como cuatro capas. Los dispositivos de campo miden y accionan. Los controladores ejecutan secuencias locales. La capa de red y pasarelas transporta datos entre protocolos y redes. El núcleo de supervisión normaliza los puntos en un único modelo de objetos y es responsable de las alarmas, los horarios, el historial y los interbloqueos. Las aplicaciones se sitúan por encima y presentan vistas específicas por rol. Las capas se definen por responsabilidad, no por nombres de producto. Un solo equipo puede desempeñar dos capas en un edificio pequeño, pero las responsabilidades deben quedar igualmente por escrito, porque eso es lo que hace el sistema verificable y mantenible una vez que el equipo del proyecto se ha marchado. Cuando se omite una capa, la responsabilidad que falta suele reaparecer como una rutina manual. Escriba la responsabilidad junto a cada equipo en el plano.
La capa de red y pasarelas
La mayoría de los fallos de integración empiezan aquí. BACnet/IP, Modbus TCP, KNX y DALI tienen cada uno su propia temporización, direccionamiento y modelo de diagnóstico. Mantenga la red del edificio segmentada respecto a la red corporativa, documente cada pasarela y su mapa de puntos y evite apilar traductores. Una pasarela debe traducir un protocolo, no ser responsable de una secuencia de control. Cuando un subsistema expone una API estable, úsela directamente; cuando no lo hace, defina el responsable de la pasarela, la alimentación, la política de firmware y el comportamiento ante fallos. Los diagramas de red dibujados después de la puesta en marcha son una señal de alarma, no un entregable. Mantenga una lista de puertos y un plan de direcciones; la puesta en marcha es más rápida cuando el mapa es correcto. Una pasarela que necesita un portátil y una contraseña que nadie tiene no es una interfaz abierta.
El núcleo de supervisión
El núcleo es donde el IBMS pasa a ser más que un conjunto de conectores. Cada punto necesita una identidad, una unidad, un indicador de calidad, una política de historial y una clase de alarma. Cada subsistema necesita una convención de nomenclatura que un nuevo ingeniero pueda leer. Los horarios y los interbloqueos pertenecen aquí para que puedan verse, probarse y modificarse sin editar código del proveedor. El núcleo también es responsable de la sincronización horaria, los roles de usuario y el registro de auditoría. Si dos aplicaciones discrepan sobre un valor, el núcleo es el lugar donde resolverlo, no una tercera base de datos mantenida por el equipo de informes. Los nombres de punto deben describir el equipo, la ubicación y la función, en ese orden. Un nombre que solo entiende el programador original es una futura llamada de servicio.
Resiliencia y seguridad desde el diseño
El control local debe sobrevivir a una interrupción de la supervisión, a un fallo de red y al reinicio de un servidor. Eso significa que los controladores conservan sus secuencias y sus posiciones seguras, y que la red tiene un modo de fallo documentado. La seguridad forma parte del mismo diseño: VLAN segmentadas, cuentas con nombre, privilegio mínimo, aplicación de parches, registro de eventos y una vía de acceso remoto controlada. Las copias de seguridad deben poder restaurarlas el cliente, no solo el integrador original. Pruebe los casos de fallo durante la puesta en marcha, porque una arquitectura sobre la que nunca se ha provocado un fallo sigue siendo solo un dibujo. Documente los pasos de recuperación y pruébelos con el equipo del cliente, no solo con el portátil del instalador. Una copia de seguridad que nunca se ha restaurado es una esperanza, no un control.
Capas y responsabilidades de un IBMS
5 rows| Capa | Responsable de | Pregunta de diseño |
|---|---|---|
| Campo | Medición y accionamiento | ¿Están definidas las ubicaciones de los sensores y las posiciones de fallo? |
| Controlador | Secuencias locales y seguridad | ¿Qué funciona cuando la red está caída? |
| Red y pasarela | Traducción de protocolos y transporte | ¿Quién es responsable de cada pasarela y de su mapa de puntos? |
| Núcleo de supervisión | Modelo de datos, alarmas, historial, interbloqueos | ¿Existe una única identidad para cada punto? |
| Aplicación | Vistas e informes basados en roles | ¿Lee del núcleo o consulta los subsistemas? |
Imágenes del proyecto
3 images
Preguntas frecuentes
01¿Cuántas capas necesita una arquitectura de IBMS?
Tres o cuatro, según si la red se cuenta por separado. Lo importante es que cada capa tenga un responsable y un comportamiento ante fallos claro, no el número en sí.
02¿Dónde deben situarse las pasarelas en la arquitectura?
En el borde, cerca del subsistema que traducen, en un segmento de red documentado. No deben soportar lógica de control ni convertirse en un punto único de fallo no documentado.
03¿Puede ejecutarse el IBMS en la nube?
La capa de aplicación puede hacerlo, y a menudo lo hace. La supervisión y el control local deben permanecer en el emplazamiento para que el edificio siga funcionando cuando se pierda la conexión.
04¿Cómo debe gestionarse la ciberseguridad?
Segmente las redes, use cuentas con nombre y privilegio mínimo, aplique parches en un ciclo definido, registre las acciones administrativas y controle el acceso remoto. Son requisitos de diseño, no una ocurrencia de última hora del departamento de IT.
05¿Qué documento define la arquitectura?
Un esquema vertical de red, una lista de puntos, una matriz de protocolos y una matriz de responsabilidades. En conjunto muestran qué se conecta con qué, quién es responsable de cada interfaz y cómo se probará.
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.