Saltar al contenido principal

Control de consignas HVAC en un gateway perimetral: hardware, despliegue y resultados medidos

Aviso de uso

Este es un recomendador de consignas de supervisión, no un sistema de control certificado para seguridad: los enclavamientos y controles de seguridad propios de la planta tienen prioridad, y no se proporciona ninguna cifra de ahorro energético.

Qué hace esta solución​

Una planta central de HVAC en una oficina, un centro comercial o una fábrica suele funcionar con un horario fijo: la misma consigna tanto si la planta está llena como si está vacía. Esta solución coloca un gateway junto a la planta que lee el controlador de HVAC y un analizador de energía en un modelo de punto único, aprende una recomendación de consigna a partir de los datos históricos propios de ese edificio y la escribe de vuelta en el controlador; una escritura se considera aplicada solo después de que el valor se haya leído de nuevo desde campo y coincida con lo que se envió.

Se utiliza en planta central: enfriadoras, unidades de tratamiento de aire y los controladores que tienen delante. No es para aires acondicionados tipo split, y no está en el lazo de seguridad.

  • Selección y despliegue: página de diseño de referencia
  • Repositorio de código fuente: no publicado. github.com/Seeed-Solution/Solution_HVAC_SmartControl no es accesible públicamente.
  • Los controladores y analizadores existentes se conectan tal como están

    Los controladores que hablan OPC UA, Modbus TCP, Modbus RTU sobre RS-485 o BACnet/IP no se sustituyen, y el analizador SDM630 tiene una plantilla integrada. Hasta 2.000 puntos, de los cuales hasta 50 pueden ser escribibles.

  • Cada escritura se lee de nuevo y se verifica

    El último valor, calidad, marca de tiempo y prioridad conocidos como correctos se congelan antes de la escritura; el punto se vuelve a leer tras un retardo de asentamiento y se compara dentro de una tolerancia. Una lectura de retorno cuya calidad no sea buena no pasa.

  • Reversión automática y alarmas ante fallos

    La discrepancia en la lectura de retorno, la fuente fuera de línea, la predicción deshabilitada, la cancelación por parte del operador y un lote aplicado parcialmente desencadenan todos una reversión. Las alarmas se indexan por causa, de modo que un fallo recurrente reutiliza la alarma abierta.

  • Capacidad medida: 2.000 puntos a 349,99 eventos/s

    Frente a un objetivo de 350,0, medido en una ejecución de loopback de 180 s en una reComputer R2000 Serie. Las condiciones están en el apéndice.

Lo que muestra la consola​

La consola en ejecución representa la tabla de puntos con la calidad por punto, la página de acceso con cada fuente y su recuento de puntos registrados, y un libro mayor de recepción de comandos. El libro mayor es donde la ruta de escritura es visible: cada fila lleva el valor solicitado, el valor efectivo, el actor, el acuse de recibo del protocolo y — tras el retardo de asentamiento— el resultado de la lectura de retorno. Una escritura cuyo registro se haya cambiado por fuera se lee como mismatched, compensated con el valor que se encontró, y el comando de compensación emitido por plugin:prediction:rollback aparece como la fila siguiente.

La página de acceso enumera cada fuente con su recuento de puntos registrados; este es el primer lugar donde el cableado se muestra como operativo:

Página de acceso: protocolo, dirección, estado en línea y recuento de puntos registrados para cada fuente

La tabla de puntos lleva la calidad por punto, de modo que un punto que no esté leyendo good es visible aquí:

Tabla de puntos: nombre, valor actual, unidad, calidad y última actualización

La página de tiempo de ejecución de la predicción muestra las consignas recomendadas de esta ronda, la ventana de historial que las respalda y el modo de control actual:

Página de tiempo de ejecución de la predicción: consignas recomendadas de esta ronda, ventana de historial y modo de control

La ruta de escritura es visible en el libro mayor de recepción de comandos: el valor solicitado, el valor efectivo, el actor, el acuse de recibo del protocolo y la lectura de retorno tienen cada uno su columna:

Paso dos del envío de comandos: confirmar el valor a escribir, el punto de destino y los límites de seguridad

Las capturas anteriores están conectadas a los propios simuladores de protocolo del paquete, no a un analizador o controlador físico; el lado del gateway ejecuta el software suministrado.

Qué hardware necesitas​

Tres cosas: un controlador que ya tengas, un analizador y un host Docker.

① El controlador de HVAC: cualquiera que ya esté delante de la planta, siempre que hable OPC UA, Modbus TCP/RTU o BACnet/IP. Para una prueba en vacío sin planta conectada, el paquete incluye un simulador OPC UA en el puerto 4841.

② El analizador de energía: un Eastron SDM630 con el mapa de registros Modbus V2, sobre Modbus TCP, un gateway Modbus TCP o RS-485. Diez puntos de solo lectura: tensión y corriente trifásicas, potencia activa total (kW), factor de potencia total, frecuencia, energía activa importada (kWh).

③ El host gateway: el único dispositivo que necesitas elegir. El servicio es una carga de trabajo Docker en x86-64 o arm64, por lo que una máquina Linux que ya esté en la red de la planta es un destino compatible.

GatewayAlmacenamientoCuándo elegirlo
reComputer R1124-10reComputer R1124-10
4 GB RAM, RS-485 / RS-232 / DI / DO integrados
16 GB eMMCEl historial vive en un servidor; el gateway mantiene una ventana local corta
reComputer R1125-10reComputer R1125-10
misma placa, eMMC más grande
32 GB eMMCMeses de historial de operación permanecen en el gateway; el conjunto de entrenamiento puede volver a importarse localmente

La serie R1100 incorpora RS-485 a bordo, por lo que un analizador en RS-485 no necesita adaptador USB. El servicio en sí necesita alrededor de 1 GB de disco; el almacenamiento determina cuánta historia puedes consultar localmente sin un servidor.

Otros requisitos previos: Docker Engine 20.10 o más reciente, los puertos 8280 y 4841 libres en el host, y al menos una semana de operación histórica en CSV o Excel con columnas de marca de tiempo, consigna, temperatura medida y consumo de energía.

Cómo desplegar en sitio​

1. Instalar el hardware: cableado​

Comprueba primero el orden de bytes y palabras del analizador

La plantilla integrada del SDM630 usa por defecto bytes y palabras big-endian, tomada del valor por defecto publicado por el proveedor. Lee un registro con un valor físico conocido y compáralo con la propia pantalla del analizador. Una tensión y frecuencia que sean cercanas pero incorrectas, o una energía importada que salta hacia atrás, suelen significar un error en el ajuste del orden de palabras; comprueba el orden de palabras antes de cablear.

Pon el gateway en la misma red que el controlador y el analizador (o su gateway Modbus TCP). Para Modbus RTU, haz coincidir la velocidad en baudios, la paridad y el id de unidad con aquello para lo que esté configurado el analizador; un desajuste muestra solo como un tiempo de espera, sin mensaje de error. Usa el perfil de despliegue serial-device: el perfil estándar de Docker no adjunta ningún dispositivo serie del host, por lo que no hay /dev/ttyUSB0 dentro del contenedor.

2. Software: tres pasos​

Los campos del formulario por paso y los paquetes de aplicación están en la página del diseño de referencia; elige una configuración para tu sitio y descárgala.


Resumen:

  1. Despliega el servicio — despliegue con Docker, ya sea en la máquina que ejecuta la herramienta de despliegue o por SSH a un dispositivo en la red de la planta. El formulario incluye el transporte del medidor, el endpoint OPC UA, los límites de seguridad, el modo de control y los umbrales de alarma.
  2. Abre la consola — crea el primer administrador y confirma que ambas fuentes están en línea con sus conteos de puntos esperados. El asistente de acceso pide dirección e intervalo de sondeo por protocolo:
Primer paso del asistente de acceso: elige el protocolo, rellena la dirección y el intervalo de sondeo
  1. Puesta en servicio — registra el medidor, ejecuta predicciones en modo de observación, inyecta fallos a propósito y solo entonces habilita las escrituras. Antes de que salga un lote, confirma en la página de selección exactamente qué puntos cubre:
Selección de envío por lotes: los puntos cubiertos por este lote y sus valores actuales

Deja Control Mode en observe y deja Safety Baseline Approved By en blanco. Mientras el aprobador esté en blanco, la línea base aparece como no aprobada; introducir un nombre significa que ese ingeniero aprueba los límites de seguridad.

La estimación hasta una consola en ejecución con lectura de puntos es de unos 60 minutos. La puesta en servicio lleva más tiempo, porque incluye un ciclo completo de ocupación de predicciones en modo de observación revisadas por quien opera la planta.

Qué cubre la imagen publicada

La imagen publicada missionpack-knn:v1.6.5 no incluye la plantilla SDM630, el coordinador de rollback ni el sobre de alarma. En la v1.6.5 los subpasos de modo de observación siguen aplicando; los subpasos de medidor, rollback y alarma no se pueden completar.

Interfaces disponibles​

Todo lo que expone el despliegue se encuentra detrás de un puerto HTTP en el host gateway. Nada sale de la red de la planta a menos que la publicación hacia el norte esté activada.

  • Operadores — la consola en el navegador en 8280: tabla de puntos con calidad por punto, registro de medidores, ejecuciones de predicción, acuses de recibo de comandos, banner de alarmas.
  • Supervisión — GET /system/runtime-metrics. Con la publicación hacia el norte activada incluye northbound.spool.queued y northbound.spool.dropped; queued de vuelta a 0 con dropped sin cambios es la comprobación que pide el paso de puesta en servicio.
  • Tu propio sistema — la misma superficie de API de la consola detrás de 8280, más el endpoint de salud que el despliegue espera al arrancar.

Lista completa de endpoints​

Puerto / endpointQué sirveNecesita internet
8280 /Consola en el navegadorNo
8280 /system/runtime-metricsContadores de tiempo de ejecución, contadores del spool hacia el norteNo
8280 /api/v1/healthComprobación de salud; el arranque permite 30 sNo
4841Simulador OPC UA integrado, para una prueba en secoNo

En un acuse de recibo de comando, lee la columna de readback: protocol_acknowledged solo significa que el controlador aceptó la trama. La columna de readback (matched, o mismatched, compensated con el valor encontrado) es lo que realmente hay en campo. Una compensación emitida por el coordinador de rollback aparece como su propio acuse inmediatamente después de la escritura que deshizo, de modo que el rastro de auditoría se lee en orden sin unir dos tablas.

Los logs del contenedor rotan a 10 MB con cuatro copias de seguridad (docker logs missionpack_knn). Exporta el rastro de auditoría de comandos, el diario de rollback y el historial de alarmas antes de que caduquen.

Alcance del protocolo hacia el sur​

Todos los puntos se encuentran en un único registro, limitado a 2.000 puntos, de los cuales como máximo 50 pueden ser escribibles. Los 10 puntos del medidor SDM630 son de solo lectura; cuentan para los 2.000 y no para los 50.

TransporteFunciónRestricciones
OPC UALectura y escritura en el controlador HVACEndpoint establecido por despliegue; simulador integrado en 4841
Modbus TCPMedidor y controladoresID de unidad y puerto por fuente; directo o a través de un gateway TCP
Modbus RTU (RS-485)MedidorNecesita el perfil de despliegue serial-device; el perfil estándar no adjunta dispositivos serie del host
BACnet/IPLectura y escritura en manejadoras de aireLas escrituras usan una prioridad y liberación con Null. La suscripción COV, el registro BBMD y MS-TP no están implementados

Rendimiento y datos medidos​

Todo lo aquí descrito se midió contra el simulador de protocolo sobre loopback; no hay datos de un edificio real, y cada cifra proviene de una sola ejecución salvo que se indique lo contrario.

Capacidad​

MétricaValorCondiciones
Rendimiento de muestreo349,99 eventos/s (99,99% del objetivo de 350,0)2.000 puntos, 4 fuentes de protocolo
Tasa de predicción0,939 ciclos/sMisma ejecución
Pico de RSS del grupo de procesos217,3 MiBMisma ejecución

Condiciones para las tres filas: 2.000 puntos en 4 fuentes de protocolo, OPC UA y Modbus muestreados cada 5 s, BACnet cada 10 s, solo loopback, ejecución de 180 s, en una reComputer R2000 serie (arm64).

Reproducir: upstream b5fe4cc, captura capacity-smoke r14

Latencia​

MétricaValorCondiciones
Latencia del ciclo de predicción46,27 ms máx.n = 4 ciclos, sin carga
Latencia de admisión de control1,41 ms máx.n = 2 ciclos, sin carga

Ambas reflejan solo el coste de la propia ruta de código.

Reproducir: upstream f831bae, línea base de tiempo de ejecución de northbound-smoke

Tiempo de ejecución y parámetros clave​

El modelo de predicción es KNN, entrenado con el propio historial operativo del edificio (CSV o Excel con columnas de marca de tiempo, punto de consigna, temperatura medida y potencia); el servicio es una carga de trabajo Docker en x86-64 o arm64. Cada predicción puede revisarse en la consola antes de que llegue al controlador.

  • Modo de control y límites de seguridad: el modo de control se entrega como observe, por lo que no se escribe ningún punto hasta que un operador lo cambie. El mínimo / máximo del punto de consigna de 18 / 30 °C, el cambio máximo de 1,0 °C por 300 s y la lista blanca de modos off / fan / cool / heat / auto son todos marcadores de posición; rellénalos para la planta.
  • La verificación de readback está desactivada por defecto: la configuración de ejecución de predicción (creada en la consola) debe indicar "rollback": { "enabled": true, "settle_seconds": 2.5 } explícitamente; una configuración sin sección rollback se trata como enabled: false.
  • settle_seconds (0–30, por defecto 1,0) debe ser mayor que el intervalo de muestreo de la fuente, o el readback verá el valor previo a la escritura e informará de una discrepancia que no existe.

Degradación conocida​

  • La tasa de predicción tiene un techo estructural (no corregido): el bucle de predicción duerme un intervalo fijo después de cada ciclo, por lo que su tasa es 1/(1.0 + t_cycle). A 2.000 puntos t_cycle es de unos 0,119 s, lo que sitúa el techo cerca de 0,894 ciclos/s, por debajo del umbral de 0,90 que exige la prueba de resistencia.
  • Solo las escrituras Modbus se verifican por readback: una salida BACnet no tiene prioridad de escritura disponible y se omite.
  • Orden de bytes: hasta que se compruebe frente a la propia pantalla del medidor, los puntos del medidor se decodifican con el orden de palabras por defecto del proveedor (big-endian) y pueden ser incorrectos.

Próximos pasos​

  • Lectura/escritura con readback independiente contra dispositivos reales OPC UA, Modbus TCP, Modbus RTU (USB-a-RS-485) y BACnet/IP en un reComputer R10 serie o reTerminal DM.
  • Una ejecución desatendida de 72 horas en los mismos hosts de destino, con simulacros de recuperación de red, broker, procesos y dispositivos durante la ejecución.

Fuentes de datos y activos​

  • Mapa de registros SDM630 — documento publicado por Eastron sobre el protocolo Modbus (mapa de registros Modbus V2, registros de entrada float32 IEEE-754). Las direcciones siguen ese documento; el orden de bytes y palabras big-endian es el valor por defecto del proveedor.
  • Datos históricos de operación — suministrados por el sitio que realiza el despliegue. No se distribuye nada con el paquete, y no se usa ni se requiere ningún conjunto de datos público.
  • Capturas de la consola — capturas de pantalla originales del software empaquetado ejecutándose contra los propios simuladores de protocolo del paquete. La configuración del simulador, el host de captura y los checksums se registran en gallery/ATTRIBUTION.md del paquete. No se incluye ningún recurso, marca de terceros ni imagen de stock.
  • Diagrama de arquitectura — dibujado a partir de un IR de arquitectura estructurada; trabajo original, sin arte de terceros.
Loading Comments...