Un grupo de FFUs se manifiesta como un problema de control mucho antes de que se manifieste como un problema de flujo de aire. Una vez que las unidades están conectadas en red a una pasarela o a un sistema de gestión de edificios, el proyecto tiene que responder a una pregunta diferente a “¿funciona cada unidad?”: tiene que responder a “¿sabe el sistema de control, sin lugar a dudas, qué unidad es cada una, a qué zona pertenece y qué ocurre cuando algo falla?”. Si esto no se hace correctamente, normalmente no se detecta durante la puesta en marcha de una sola unidad; se detecta más tarde, cuando una alarma indica una ubicación que ya no coincide con el plano de obra, o cuando un comando de zona llega al grupo equivocado de unidades.

Asignar cada dirección de la FFU a una ubicación física y a una zona operativa

Cada FFU de una red necesita una dirección, pero la dirección por sí sola no proporciona al sistema de control ninguna información sobre dónde se encuentra esa unidad, qué se supone que debe hacer o de qué otras unidades depende para dar una respuesta coordinada. La dirección es un identificador de comunicación; la correspondencia entre ese identificador y el contexto físico y funcional es un dato independiente que debe crearse y mantenerse de forma deliberada. Cuando esta correspondencia no existe como un registro discreto y consultable, la lógica de control y la distribución real de la sala tienden a desfasarse con el tiempo, sobre todo a medida que las unidades se sustituyen, se recablean o se reasignan a una zona diferente durante el ciclo de vida del proyecto.

La asignación requiere al menos cuatro elementos vinculados a cada dirección: la ubicación física de la unidad, la zona operativa a la que pertenece, el controlador al que responde y el circuito de alimentación que la alimenta. Cada uno de estos elementos modifica la interpretación de una señal procedente de dicha unidad. Una señal de estado procedente de una unidad significa una cosa si se conoce el contexto de la zona y otra si no: una avería notificada sin el contexto de la zona indica al operador que algo va mal, pero no qué implica ese “problema” para el proceso que protege la zona. Del mismo modo, conocer el circuito de alimentación es importante porque una unidad que deja de responder por un problema de cableado no debe diagnosticarse ni tratarse de la misma manera que una unidad que deja de responder por un problema de comunicación, aunque ambas puedan parecer idénticas desde el punto de vista del estado puro.

La propia agrupación en zonas merece una atención distinta a la de la dirección. Dos FFU pueden compartir una misma sala física y, aun así, pertenecer a zonas de funcionamiento diferentes si dan soporte a procesos distintos, tienen límites de calificación diferentes o cumplen requisitos distintos de respuesta ante fallos. Por el contrario, las unidades situadas en salas adyacentes pueden pertenecer a la misma zona de funcionamiento si se espera que respondan conjuntamente a una única decisión de control. La asignación de zonas debe ajustarse al proceso que se desea proteger, y no a la disposición física de los conductos o el cableado, ya que la disposición física es una cuestión de comodidad en la instalación, mientras que la asignación de zonas es una decisión de control con consecuencias para el comportamiento del sistema tanto en funcionamiento normal como en caso de fallo.

Antes de comenzar la programación, este registro de direccionamiento —que incluye la ubicación, la zona, el controlador y el circuito de alimentación de cada unidad física— debe existir como un documento que los equipos de puesta en marcha y control puedan consultar, y no como información reconstruida de manera informal a partir de planos o notas de campo. Confirmar que este registro existe y que está completo para todas las unidades del grupo es una condición previa para todo lo que viene a continuación en la configuración del control.

Definir comandos, señales de estado, alarmas y puntos de tendencia para cada interfaz

Una vez que se han determinado la identidad de cada unidad y el contexto de la zona, la siguiente decisión es qué es lo que realmente fluye a través de la interfaz entre los controles de la FFU y los sistemas que la rodean — el controlador de la unidad, cualquier pasarela y el sistema de gestión del edificio. Normalmente, hay cuatro categorías de información que requieren una definición explícita: los comandos enviados a las unidades, las señales de estado que estas devuelven, las alarmas que requieren una respuesta y los valores de tendencia o registrados que se conservan para su revisión posterior. Tratar estos datos como un único flujo indiferenciado genera ambigüedad sobre el significado de cada dato y sobre quién debe actuar en consecuencia.

Los comandos y las señales de estado no son imágenes especulares entre sí, aunque a menudo recorran la misma ruta física. Un comando indica a una unidad o a una zona qué debe hacer; una señal de estado informa de lo que está ocurriendo realmente. Cuando un sistema de control confunde ambos conceptos —por ejemplo, al deducir que un comando se ha ejecutado correctamente en lugar de confirmarlo mediante un punto de estado independiente—, el proyecto pierde la capacidad de distinguir entre “el sistema lo solicitó” y “el sistema verificó que esto ocurrió”. Esa distinción cobra mayor importancia precisamente cuando se produce un fallo, que es cuando resulta más difícil reconstruirla a posteriori si no se ha incorporado desde el principio.

Las alarmas deben definirse por separado del estado ordinario, ya que una alarma implica una respuesta obligatoria, mientras que una señal de estado puede ser meramente informativa. Las condiciones que generan una alarma, el momento en el que se activa dicha alarma dentro de la lógica de control y el lugar al que se envía son decisiones específicas de cada proyecto que dependen de cómo responde el proceso protegido a la condición de fallo subyacente. Los puntos de tendencia, por su parte, tienen un propósito diferente: se conservan para su revisión, en lugar de activarse en tiempo real, por lo que su valor depende de lo que se registre, con qué resolución y durante cuánto tiempo, más que de una respuesta inmediata.

La cuestión de la propiedad está presente en las cuatro categorías. Para cada punto —comando, estado, alarma o tendencia—, el proyecto debe saber qué sistema lo registra, qué sistema es el de referencia y a qué sistema debe acudir un revisor si alguna vez se cuestiona el valor registrado. Definir esto a nivel de interfaz, antes de que se ultime el esquema de control, evita que se dé una situación en la que una misma señal parezca proceder de dos sistemas sin que exista un registro consensuado sobre cuál de ellos prevalece.

Asignar la responsabilidad entre los controladores de las unidades, las pasarelas y el sistema de gestión de edificios (BMS)

Una arquitectura de control con un un controlador de unidad, una pasarela y un sistema de gestión de edificios crea tres capas, cada una de las cuales puede atribuirse de forma plausible la responsabilidad de una decisión determinada o de un dato concreto. La titularidad debe asignarse de forma explícita, ya que la mera existencia de una ruta de datos entre capas no determina qué capa tiene la última palabra cuando los valores no coinciden o cuando es necesario emitir un comando.

El controlador de la unidad suele ser el que se encuentra más cerca del equipo físico y el que tiene una visión más inmediata de su estado operativo real. La pasarela, cuando existe, traduce y agrega la información entre el controlador de la unidad y el BMS, y al hacerlo introduce un punto en el que los datos pueden sufrir retrasos, transformarse o perderse si su función no está claramente delimitada. El BMS se encuentra más alejado de la unidad física y suele tener la visión más amplia de todas las zonas, pero esa visión general solo es tan precisa como los datos que recibe a través de las capas inferiores. Ninguna de estas tres posiciones es automáticamente la “correcta” para asumir una decisión concreta; quién debe asumirla depende de lo que requiera la decisión: una respuesta física inmediata favorece que la responsabilidad recaiga cerca de la unidad, mientras que la coordinación entre zonas favorece que recaiga a nivel del BMS.

Cuando la titularidad se da por implícita, un sistema de control puede desarrollar un comportamiento contradictorio: un comando emitido a nivel del BMS podría ser anulado localmente en el controlador de la unidad sin que quede constancia alguna de dicha anulación, o una pasarela podría almacenar en memoria un cambio de estado durante el tiempo suficiente como para que el BMS actúe basándose en información obsoleta. Ninguno de estos modos de fallo requiere que un único componente funcione mal; ambos pueden producirse aunque todos los componentes funcionen exactamente según lo previsto, simplemente porque la asignación de autoridad nunca se hizo explícita para ese punto de datos o esa ruta de comando.

Asignar la propiedad también implica decidir qué ocurre cuando las capas no coinciden: si prevalece la lectura local del controlador de la unidad, si se permite que la pasarela sustituya un valor por defecto cuando no pueda comunicarse con la unidad y si el BMS muestra un valor que no puede verificar por sí mismo. Estas decisiones deben incluirse en el esquema de control, junto con el registro de direccionamiento y las definiciones de puntos, ya que determinan cómo se comporta el resto del sistema una vez que los datos fluyen correctamente.

Especificar el comportamiento de la zona en caso de fallos de comunicación, de alimentación y de la unidad

Las direcciones, las definiciones de puntos y las asignaciones de propiedad describen cómo se supone que debe comportarse el sistema en condiciones normales. El comportamiento en caso de fallo es una especificación independiente y no puede deducirse automáticamente de la lógica de funcionamiento normal: un sistema que funciona correctamente cuando todos los componentes se comunican entre sí no tiene, por ello, un comportamiento definido para el caso de que una unidad deje de comunicarse, se quede sin alimentación o, por cualquier otro motivo, deje de estar disponible.

Hay tres situaciones de fallo que se repiten en los grupos de FFU: la pérdida de comunicación con una unidad, la pérdida de alimentación de una unidad y una unidad que simplemente no está disponible por alguna otra razón. Cada una de ellas tiene una causa subyacente diferente, y tratarlas como si fueran intercambiables da lugar a una respuesta de control que puede resultar inadecuada para al menos una de ellas. Una pérdida de comunicación no significa necesariamente que el ventilador haya dejado de mover el aire; una pérdida de alimentación, casi con toda seguridad, sí lo significa; y una unidad que se indica como no disponible a través de algún otro mecanismo puede corresponder o no a un cambio real en el flujo de aire. Dado que las consecuencias físicas difieren entre estos tres casos, la respuesta programada de la zona no debería adoptar por defecto un comportamiento idéntico para los tres simplemente porque, desde el punto de vista del sistema de control, todos ellos sean “fallos”.

El comportamiento adecuado de una zona ante cada fallo depende del proceso que proteja y de la evaluación de riesgos específica de cada instalación, y no de un valor predeterminado general válido para todos los proyectos. Cuando una zona protege un proceso que no puede tolerar ninguna interrupción en el flujo de aire coordinado, es posible que la pérdida de comunicación de una sola unidad deba activar una alarma inmediata a nivel de zona y un comando de respaldo definido para las unidades restantes, incluso antes de que se confirme la causa subyacente. Cuando la zona protege un proceso menos sensible, esa misma pérdida de comunicación podría gestionarse con una alarma retardada que dé tiempo a distinguir un problema transitorio de red de un fallo real de la unidad, evitando así una respuesta innecesaria en toda la zona ante una situación que se resuelve por sí sola. Ninguno de los dos enfoques es universalmente correcto; cada uno es una decisión que depende del proceso protegido y de las consecuencias de una respuesta errónea frente a una respuesta retardada.

Es aquí también donde la decisión de zonificación del proyecto, tomada anteriormente al asignar direcciones a las zonas operativas, determina el alcance de la respuesta ante un fallo. Una avería en una unidad asignada a una zona estrictamente delimitada no debería propagar automáticamente una respuesta a las unidades de una zona adyacente, a menos que el propio proceso requiera un comportamiento coordinado más allá de ese límite. Especificar este alcance de forma explícita, para cada uno de los tres tipos de avería, es lo que permite que el programa de control establezca una respuesta definida, en lugar de dejar que el comportamiento real se descubra únicamente cuando se produzca una avería en servicio.

Comprobar el direccionamiento, el enrutamiento de las alarmas y los datos registrados durante la recepción de la instalación

Todas las decisiones tomadas anteriormente —el registro de direcciones, las definiciones de puntos, las asignaciones de propiedad y el comportamiento en caso de fallo— figuran por escrito en el esquema de control aprobado hasta que se comprueban con el sistema instalado. Aceptación del emplazamiento Es en este punto donde el proyecto confirma que lo que se especificó es lo que realmente se ha construido y programado, y esta verificación debe comprobarse punto por punto, en lugar de darse por sentado simplemente porque el sistema parece funcionar.

La verificación del direccionamiento consiste en confirmar que la dirección de cada FFU física, tal y como la indica el sistema de control, se corresponde efectivamente con la ubicación, la zona, el controlador y el circuito de alimentación registrados en el registro. Esta comprobación es necesaria porque las actividades de instalación y puesta en marcha —como el recableado, la sustitución de unidades o el reetiquetado— pueden alterar de forma imperceptible la correspondencia entre una unidad física y su identidad registrada, sin que se produzca ningún síntoma visible hasta que una alarma o un comando se dirijan de forma errónea.

La verificación de los comandos de zona consiste en comprobar que un comando enviado a una zona determinada llegue efectivamente a las unidades asignadas a dicha zona —y que estas lo ejecuten— y que solo esas unidades lo ejecuten. De este modo se confirma que la decisión de zonificación tomada durante la fase de asignación de direcciones se ha aplicado correctamente en la lógica programada, y no se ha limitado a quedar documentada.

Verificar el enrutamiento de las alarmas significa comprobar que las rutas de alarma definidas anteriormente —qué condiciones generan una alarma y por dónde se enruta dicha alarma entre los controles de la FFU y el BMS— se comportan según lo especificado en condiciones de prueba, y no solo en condiciones de funcionamiento normal. Una ruta de alarma que nunca se haya puesto a prueba no ofrece ninguna garantía de que se enrute correctamente cuando se produzca un fallo real, ya que el modo de fallo de una ruta de alarma suele ser silencioso, en lugar de evidente.

Verificar los valores registrados significa comprobar que la tendencia y los datos registrados disponibles en la interfaz entre los controles de la FFU y el BMS coinciden con lo especificado en el programa de control: los puntos correctos, procedentes de la fuente correcta, conservados de forma que un revisor pueda consultarlos posteriormente. Esto cierra el círculo y nos lleva de vuelta a la asignación de responsabilidad, ya que un valor registrado solo es útil si se ha establecido de antemano su fuente fidedigna. La comprobación de estas cuatro áreas con respecto al programa de control aprobado, en esta fase, es lo que permite al proyecto considerar el comportamiento del sistema de control como un hecho establecido, en lugar de una suposición, de cara al futuro.

Preguntas frecuentes

Q: ¿Qué hay que solucionar antes de que comience la asignación definitiva de direcciones a las FFU?
A: Establece el identificador de ubicación física, la zona de funcionamiento, el controlador y la relación con el circuito de alimentación de cada unidad en el registro de direccionamiento. Si alguna de esas asignaciones aún está sujeta a cambios, mantén las direcciones afectadas como provisionales hasta que se haya definido la disposición; de lo contrario, una reasignación posterior podría desconectar las rutas de alarma y los registros de aceptación de la unidad instalada.

Q: ¿Es necesario enviar todos los puntos de control de las FFU al BMS?
A: No. Selecciona los comandos, las señales de estado, las alarmas y los valores de tendencia necesarios para el plan de funcionamiento y supervisión de la instalación y, a continuación, anota el origen, el destino y el responsable de cada punto seleccionado. Una interfaz cuya responsabilidad no esté clara puede llevar tanto al equipo de control de las FFU como al equipo del BMS a dar por sentado que será la otra parte la que la configure o la verifique.

Q: ¿Cómo debe el proyecto determinar el comportamiento de la zona ante un fallo de comunicación, de alimentación o de la unidad?
A: Establezca la respuesta para cada tipo de fallo a partir de la evaluación de riesgos del proceso protegido y de la instalación, y registre por separado el comportamiento previsto de la zona en el plan de control aprobado. Utilice una única respuesta de reserva común únicamente cuando el proyecto haya determinado que los distintos fallos tienen las mismas consecuencias; de lo contrario, la respuesta prevista puede mantenerse oculta hasta las pruebas de aceptación.

Q: ¿Qué aspectos deben acordarse entre el proveedor de sistemas de control y el integrador de BMS antes de la presentación del presupuesto?
A: Facilite el registro de direccionamiento y la lista de puntos de interfaz; a continuación, asigne la propiedad de cada comando, señal de estado, alarma y valor de tendencia entre el controlador de la unidad, la pasarela y el sistema de gestión de edificios (BMS). Resuelva los puntos sin asignar y el comportamiento requerido en caso de fallo antes de que se ultimen el alcance y el presupuesto, de modo que los trabajos de puesta en servicio no queden a cargo de distintos contratistas.

Q: ¿Cómo puede un comprador evitar una aprobación aparente que oculte un error de integración de controles?
A: Utilice el esquema de control aprobado como base de aceptación y compruebe de principio a fin la asignación de direcciones físicas, los comandos de zona, las rutas de alarma y los valores registrados. Anote los resultados esperados y observados en cada comprobación; una respuesta en tiempo real por sí sola no es suficiente cuando la dirección, el destino o el valor almacenado no coinciden con el esquema aprobado.