Desarrollo de IIoT para Edificios Inteligentes
Un edificio inteligente rara vez es un solo sistema; es una planta enfriadora en BACnet/IP, medidores en Modbus, un panel de iluminación que habla un RS-485 propietario y un controlador de accesos que posee los datos de ocupación pero no comparte ninguno. Construimos el gateway IIoT y la capa de integración que normaliza esos protocolos en un modelo de etiquetas único e impulsa lógica supervisora entre ellos, para que el edificio funcione como un sistema y no como cinco islas de proveedores desconectadas.
Challenges specific to Smart Buildings
Los datos BACnet/IP de la planta enfriadora nunca llegan a la analítica
El controlador de planta expone objetos BACnet/IP pero sin enlace a historiador, así que la temperatura de impulsión de agua helada, el kW y el caudal se registran localmente 24 horas y luego se sobrescriben, y nadie puede demostrar el kW/ton de la planta a lo largo de una temporada.
Los medidores de servicios e inquilinos viven en un troncal Modbus huérfano
Los medidores de potencia y BTU están en un bucle Modbus RTU sin gateway, los registros se leen con una hoja de cálculo una vez al mes y las disputas de submedición de inquilinos no tienen datos de intervalo auditables para resolverse.
La ocupación queda atrapada dentro del sistema de control de accesos
Los recuentos de fichaje que deberían impulsar la ventilación por demanda y el retroceso en zonas desocupadas permanecen bloqueados en una base de datos de accesos propietaria sin exportación, así que el HVAC acondiciona pisos vacíos a plena carga.
La iluminación y la seguridad funcionan en islas de protocolo
Un panel de iluminación DALI/0-10V y el DVR de seguridad hablan cada uno su propio bus, no comparten horario con el HVAC, y un festivo o un evento fuera de horario hay que programarlo cinco veces en cinco herramientas.
La lógica supervisora entre sistemas no tiene dónde ejecutarse
No existe una capa que pueda leer juntos la carga de planta, la demanda de los medidores y la ocupación, así que el límite de demanda pico y el arranque/parada óptimo son imposibles y el edificio paga cada pico de cargo por demanda.
How GizanTech solves them
- Gateway multiprotocolo y normalización de etiquetas. 1) Un gateway de borde ejecuta clientes concurrentes BACnet/IP, BACnet MS/TP y Modbus RTU/TCP, mapea cada objeto y registro a un modelo de etiquetas normalizado con unidades de ingeniería y banderas de calidad, y lo expone aguas arriba como MQTT/Sparkplug B o BACnet/IP.
- Enlace al historiador de planta y ruta de datos M&V. 2) Enlazamos el kW, el caudal y las temperaturas de impulsión/retorno de la planta enfriadora a un historiador de series temporales con resolución de un minuto, calculamos kW/ton y la eficiencia de planta en el borde, y retenemos datos de intervalo de calidad IPMVP para medición y verificación.
- Tubería de submedición de calidad de facturación. 3) Los medidores Modbus de potencia y BTU se sondean a intervalo fijo, se marcan con marca de tiempo y bandera de huecos en el gateway, y se entregan como lecturas de intervalo de 15 minutos auditables para que la asignación de costes a inquilinos y el reporte ENERGY STAR sean defendibles.
- Liberación de datos de ocupación y accesos. 4) Extraemos los eventos de fichaje y ocupación del sistema de control de accesos vía su API o un puente OSDP/Wiegand, los normalizamos a etiquetas de ocupación por zona y los publicamos al HVAC y a la iluminación para DCV y retroceso en zonas desocupadas.
- Capa de control supervisor entre sistemas. 5) Un motor supervisor lee juntas las etiquetas de planta, medidores y ocupación para ejecutar el límite de demanda pico, el arranque/parada óptimo y la programación fuera de horario una vez, y luego escribe consignas de vuelta por BACnet a cada subsistema.
| Sistema del edificio | Protocolo de bus de campo | Enfoque de integración | Resultado operativo / energético |
|---|---|---|---|
| HVAC / planta enfriadora | BACnet/IP (objetos del controlador) + Modbus TCP en los variadores | El gateway sondea objetos de planta, enlaza kW/caudal/temperaturas al historiador, calcula kW/ton en el borde | Tendencia continua de eficiencia de planta; el arranque/parada óptimo recorta 8-15% de la energía de funcionamiento |
| Energía / medición de inquilinos | Medidores Modbus RTU de potencia y BTU | Sondeo a intervalo fijo, el gateway marca tiempo y huecos en lecturas de intervalo de 15 minutos | Submedición auditable de calidad de facturación; la asignación de costes a inquilinos y los datos ENERGY STAR resisten |
| Ocupación / IAQ | CO2/IAQ BACnet MS/TP + ocupación del sistema de accesos vía API/OSDP | Normalizar el CO2 y los recuentos de fichaje en etiquetas de ocupación por zona para DCV y retroceso | La ventilación por demanda reduce las horas de ventilador y recalentamiento en pisos vacíos |
| Accesos / seguridad | OSDP / Wiegand + API de accesos propietaria | Puentear eventos de puerta e intrusión al modelo de etiquetas y al horario unificado | Los eventos fuera de horario impulsan HVAC e iluminación una vez en vez de cinco herramientas separadas |
| Control de iluminación | Panel DALI / 0-10V por RS-485 a BACnet | Mapear grupos de iluminación a objetos BACnet que comparten el horario supervisor de ocupación | El aprovechamiento de luz natural y vacancia reduce la carga de iluminación y se alinea con el retroceso del HVAC |
Go deeper
Industrial IoT Development for other industries
Frequently asked questions
¿Reemplazan nuestro BMS existente o se integran con él?
Nos integramos. El gateway IIoT se sitúa junto a sus controladores BACnet y Modbus existentes, lee sus objetos y registros, y añade encima una capa de datos normalizada y supervisora, así que conserva sus controladores de planta y gana control entre sistemas y datos de historiador sin tener que arrancar y reemplazar.
¿Cómo extraen los datos de ocupación de un sistema de accesos cerrado?
Nos integramos por lo que el sistema exponga: una API REST o de base de datos documentada donde exista, o un puente OSDP/Wiegand a nivel de lector donde no la haya. Los eventos de fichaje y puerta se normalizan en etiquetas de ocupación por zona que impulsan la ventilación por demanda y el retroceso en zonas desocupadas.
¿Los datos de submedición son suficientes para facturar a inquilinos?
Sí. Sondeamos los medidores Modbus de potencia y BTU a intervalo fijo, marcamos con marca de tiempo cada lectura en el gateway, señalamos cualquier hueco y almacenamos datos de intervalo de 15 minutos auditables, así que la asignación de costes a inquilinos, el análisis de cargos por demanda y los envíos ENERGY STAR son defendibles y no conjeturas de hoja de cálculo.
¿La capa de integración realmente ahorra energía o solo monitorea?
Controla. El motor supervisor lee juntas la carga de planta, la demanda medida y la ocupación para ejecutar el límite de demanda pico, el arranque/parada óptimo y la programación fuera de horario, y luego escribe consignas de vuelta por BACnet, lo que normalmente recorta 8-15% de la energía de funcionamiento de la planta y recorta los picos de cargo por demanda.
¿Cómo se ven los datos para nuestra plataforma de nube o analítica?
Aguas arriba publicamos el modelo de etiquetas normalizado como MQTT con Sparkplug B, o lo exponemos como BACnet/IP para un head-end existente, así que su plataforma de analítica, detección de fallos o nube ve unidades de ingeniería y banderas de calidad consistentes en lugar de registros crudos de proveedor.