Conectar el control de enjuague a los sistemas de gestión de edificios (BMS)
Conectar el control de enjuague a nivel de punto de uso con el sistema del edificio convierte un régimen que funciona en silencio en uno que puede supervisarse y ajustarse de forma centralizada. La conexión puede ser tan sencilla como un contacto seco hacia un controlador local, o un bus de campo que llega a los protocolos del edificio a través de una pasarela. La restricción que condiciona la mayoría de los diseños es la energía, porque en una batería, cada hora que una interfaz de comunicación pasa a la escucha es energía que el dispositivo no tiene.
En esta sección
Por qué conectar
Una razón es la evidencia. Un edificio con varios cientos de puntos de uso controlados genera varios cientos de pequeños registros, y la recopilación centralizada es la diferencia entre un operador que responde en segundos a una pregunta sobre un punto de uso en una fecha determinada, y alguien que recorre el edificio con una linterna.
Además, la conexión convierte un hallazgo en una notificación. Una batería que se acerca al final de su vida útil, o un ciclo que no se ejecutó, merece conocerse en el momento en que ocurre y no en la siguiente inspección. Lo que puede convertirse en alarma depende por completo de lo que reporte el dispositivo: un contacto seco solo demuestra que se emitió una señal, y una conexión serie transporta únicamente los parámetros y eventos que implemente su registro o su mapa de puntos.
Además, saca la escalera de mano de los cambios rutinarios. Ajustar un intervalo en toda un ala del edificio, escalonar los ciclos para que una montante completa no se enjuague a la vez, o cambiar de régimen cuando varía la ocupación: todo ello se hace entonces desde el mismo lugar donde se gestiona el resto de la instalación.
Lo que no es una razón es que la conexión haga que el régimen sea más correcto. Un sistema en red con una duración mal elegida intercambiará muy poca agua, o la desperdiciará, en cada punto de uso que controle. Primero hay que fijar bien los parámetros hidráulicos.
Lo que realmente se intercambia
El conjunto de datos es reducido.
Eventos de ciclo y de activación con marca de tiempo, los parámetros actuales, el estado del dispositivo y, donde el hardware lo permita, la temperatura en el punto de uso o una señal que confirme que la válvula se movió.
Cambios de parámetros, una orden para ejecutar un ciclo de inmediato, una referencia de reloj y, cuando proceda, una instrucción para suspender los ciclos durante el mantenimiento.
Eso equivale a un puñado de registros u objetos por punto de uso. El esfuerzo de ingeniería no está en la carga útil. Está en el direccionamiento y la puesta en marcha, y en el presupuesto energético allí donde los dispositivos funcionan con batería.
El panorama de los protocolos
Los edificios no se construyen desde cero, y el protocolo situado en lo más alto de la jerarquía, el del sistema de gestión de edificios (BMS), suele decidirse antes de que nadie especifique un grifo.
BACnet es un protocolo de automatización de edificios muy utilizado en el nivel de supervisión, especialmente en instalaciones comerciales e institucionales, y es un objetivo habitual para todo lo que deba aparecer junto a los sistemas de climatización y energía.
Modbus es una opción habitual a nivel de dispositivo y de controlador. Las implementaciones están ampliamente disponibles en ambos extremos del enlace, tanto en los dispositivos de los puntos de uso como en los controladores y pasarelas que recogen sus datos, lo que lo convierte en una forma práctica de llevar los datos del punto de uso hasta algo que hable el protocolo del edificio.
KNX se emplea sobre todo en la automatización de estancias y de edificios, incluidas la iluminación, las persianas y el control de ambiente, y aparece tanto en edificios comerciales y hoteles como en viviendas. En aplicaciones de agua, la documentación de KNX se concentra en la detección de fugas, la medición de consumo, el control de caudal y el corte de suministro, más que en el enjuague higiénico programado. Trátelo como un objetivo de integración secundario en los proyectos que ya utilicen KNX para la automatización de estancias, alcanzado a través de una pasarela o un controlador local, y no como un protocolo a nivel de punto de uso.
Los protocolos de medición y los protocolos inalámbricos de bajo consumo aparecen en el extremo de la red, sobre todo donde los dispositivos funcionan con batería y el cableado resulta poco práctico.
De ahí se derivan dos puntos prácticos. Un controlador de punto de uso rara vez necesita hablar él mismo el protocolo de supervisión; necesita llegar hasta algo que lo hable. Y la elección del protocolo suele venir impuesta por el edificio, de modo que un producto con una interfaz sencilla a nivel de dispositivo y una vía a través de pasarela encaja en más proyectos que uno que se comprometa con un único protocolo de supervisión.
Cómo se conectan los dispositivos
Son habituales cuatro configuraciones.
Contacto seco o entrada digital. El controlador activa una salida cuando se ejecuta un ciclo, y un controlador local, un PLC o un módulo de entradas lo cuenta y le pone marca de tiempo. El enlace es una salida hacia una entrada, así que hay poco que configurar y poco que pueda fallar en la propia conexión. Tampoco transporta parámetros, ni el estado del dispositivo, ni diagnóstico, de modo que solo responde a si se están ordenando ciclos, y nada más.
Bus de campo serie. El dispositivo comparte un bus con otros y responde a una dirección, lo que da acceso a los parámetros y eventos que implemente su mapa de puntos. Aplicable donde ya existe cableado o donde puede tenderse por una montante.
Controlador local con enlace ascendente. Los dispositivos de los puntos de uso reportan a un controlador pequeño que atiende una zona, el cual agrega los datos y habla el protocolo del edificio hacia arriba. Esto mantiene simples los dispositivos de los puntos de uso y concentra la complejidad en un único lugar por zona.
Inalámbrico hacia una pasarela. Donde el cableado es el obstáculo, que suele ser la misma situación en la que el dispositivo funciona con batería, un enlace de radio de bajo consumo hacia una pasarela es la respuesta práctica, con el estudio del sitio y el trabajo de cobertura que eso implica. La radio suele gestionarla un módulo en lugar de integrarse en el controlador del punto de uso, lo que mantiene abierta la elección de tecnología inalámbrica: el mismo controlador puede situarse detrás de distintos módulos de radio según lo exija un proyecto o un mercado, en vez de comprometer el producto con una sola tecnología durante toda su vida útil.
La energía condiciona la arquitectura
Esta es la restricción que separa una especificación que funciona de una que decepciona.
Un dispositivo de punto de uso alimentado por red puede mantener una interfaz activa, responder con rapidez y comportarse como cualquier otro dispositivo de campo. Con batería, la disponibilidad y la latencia se pagan con energía, y el diseño tiene que decidir cuánto quiere de cada una. Las redes de bajo consumo gestionan ese compromiso de formas distintas: ventanas de recepción programadas en horarios acordados, sondeo periódico iniciado por el dispositivo, o una conexión permanente de bajo ciclo de trabajo donde la radio y el protocolo lo permitan.
Las consecuencias para una especificación son prácticas, no excepcionales. Puede no haber respuesta inmediata a una consulta no programada. Las órdenes pueden quedar en cola de forma centralizada y ser recogidas por el dispositivo en su siguiente ventana. La gestión del reloj tiene que contar con que el dispositivo no está sincronizado de forma continua. Y el propio intervalo de reporte pasa a ser una decisión energética, no una preferencia: reportar cada evento de inmediato cuesta más que agruparlos.
Nada de esto descarta los dispositivos de batería conectados. Sí significa que un diseño que suponga un sondeo continuo no ofrecerá la vida útil que pedía la especificación. Donde el reporte no es realmente necesario, mantener los dispositivos de batería en modo autónomo sigue siendo una respuesta legítima.
La puesta en marcha es el trabajo real
Integrar un único punto de uso es una tarea acotada con un método conocido, y la documentación de la interfaz indica la mayor parte de lo que hace falta. A lo largo de varios cientos, ese mismo trabajo se convierte en un proyecto, porque el esfuerzo se traslada de la interfaz a la identidad y la configuración de cada dispositivo.
Cada dispositivo necesita una dirección y una identidad de ubicación que tenga sentido para el operador, de modo que una alarma se lea como una habitación y un aparato, y no como un número de nodo. Los parámetros difieren según el punto de uso porque el volumen de agua retenido en el ramal difiere de un punto a otro, incluso donde el sitio trabaja con un número reducido de perfiles de régimen estándar. La temporización de los ciclos debe coordinarse en todo el edificio: escalonada para repartir la demanda, o agrupada donde el régimen aplicable o el diseño hidráulico exijan una velocidad de flujo objetivo en tramos de tubería compartidos, lo cual solo es viable donde se haya verificado la capacidad combinada. Y la correspondencia entre los puntos del dispositivo y los objetos del sistema del edificio debe construirse y probarse una vez por cada tipo de punto, y después replicarse.
Dos cosas reducen esto de forma considerable. Los dispositivos que se entregan con los parámetros ya configurados antes del envío se comportan correctamente desde el principio donde los valores ya se conocen, aunque el volumen del ramal instalado y el caudal real siguen debiendo verificarse en el sitio. Y un mapa de puntos coherente en todos los dispositivos significa que la integración se construye una sola vez, y no por cada tipo de aparato.
Seguridad, brevemente
Los controladores de punto de uso conviven en la red con sistemas más sensibles, y precisamente esa cercanía es lo que importa.
Mantenga la capa de campo segmentada de la red informática general, no exponga las pasarelas directamente a internet, cambie las credenciales predeterminadas y trate el acceso remoto a los parámetros como una función privilegiada y no como una comodidad. Cuando un sistema ofrezca acceso en la nube, deje claro qué sale del edificio y quién puede acceder a ello. Trate un dispositivo no segmentado como una posible vía de acceso hacia otra cosa, y diseñe en consecuencia.
Cómo es una buena integración
Juzgada en funcionamiento y no en la puesta en marcha, una buena integración pasa desapercibida. Los ciclos aparecen como eventos asociados a puntos de uso identificados por su nombre. Las condiciones que el dispositivo realmente puede detectar generan alarmas con suficiente contexto para enviar a alguien. Los parámetros pueden leerse de vuelta, de modo que el registro muestra lo que se configuró en el dispositivo y no lo que indica un plano. Y se degrada con sensatez: cuando la red no está disponible, los dispositivos de los puntos de uso siguen ejecutando sus regímenes, porque el régimen pertenece al dispositivo y no a la red.
La conexión debe añadir supervisión a un sistema que ya funciona sin ella.
¿Va a integrarlo en un producto?
Indíquenos la aplicación, el entorno y el presupuesto energético. Le responderemos con una configuración.
Solicitar muestras configuradas¿Necesita la electrónica de control que hay detrás?
Conmutación programable, sensórica y firmware, desarrollados y fabricados con medios propios.
Hablar de su desarrollo de producto