Un gruppo di FFU si presenta come un problema di controllo molto prima di manifestarsi come un problema di flusso d’aria. Una volta che le unità sono collegate in rete a un gateway o a un sistema di gestione dell’edificio, il progetto deve rispondere a una domanda diversa da “ogni unità funziona?” — deve rispondere a “il sistema di controllo sa, in modo inequivocabile, quale unità è quale, a quale zona appartiene e cosa succede quando qualcosa va storto?” Un errore in questo senso di solito non si manifesta durante la messa in servizio di una singola unità; si manifesta in seguito, quando un allarme segnala una posizione che non corrisponde più alla planimetria as-built, oppure quando un comando di zona raggiunge il gruppo sbagliato di unità.

Assegnare a ogni indirizzo FFU una posizione fisica e una zona operativa

Ogni FFU presente in una rete necessita di un indirizzo, ma l’indirizzo di per sé non fornisce al sistema di controllo alcuna informazione sulla posizione di quell’unità, su quale sia la sua funzione o su quali altre unità da cui dipenda per una risposta coordinata. L’indirizzo è un identificatore di comunicazione; la corrispondenza tra tale identificatore e il contesto fisico e funzionale è un’informazione distinta che deve essere creata e gestita in modo mirato. Laddove tale corrispondenza non esista sotto forma di registro discreto e consultabile, la logica di controllo e la disposizione effettiva degli ambienti tendono a divergere nel tempo, in particolare quando le unità vengono sostituite, ricablate o riassegnate a una zona diversa durante il ciclo di vita del progetto.

La mappatura richiede almeno quattro elementi associati a ciascun indirizzo: la posizione fisica dell’unità, la zona operativa a cui appartiene, il controller a cui fa capo e il circuito di alimentazione che la alimenta. Ciascuno di questi elementi modifica l’interpretazione di un segnale proveniente da quell’unità. Un segnale di stato proveniente da un'unità assume un significato se il contesto della zona è noto e un altro se non lo è: un guasto segnalato senza il contesto della zona indica all'operatore che qualcosa non va, ma non cosa significhi quel “non va” per il processo che la zona protegge. Allo stesso modo, conoscere il circuito di alimentazione è importante perché un’unità che smette di funzionare a causa di un problema di cablaggio non dovrebbe essere diagnosticata o gestita allo stesso modo di un’unità che smette di funzionare a causa di un problema di comunicazione, anche se entrambe possono sembrare identiche dal punto di vista dello stato di base.

Il raggruppamento in zone merita un’attenzione a sé stante rispetto all’indirizzo. Due FFU possono condividere lo stesso locale fisico e appartenere comunque a zone operative diverse se supportano processi diversi, hanno limiti di qualificazione diversi o requisiti di risposta ai guasti diversi. Al contrario, le unità situate in locali adiacenti possono appartenere alla stessa zona operativa se si prevede che rispondano insieme a un’unica decisione di controllo. L’assegnazione delle zone dovrebbe seguire il processo da proteggere, non la disposizione fisica dei condotti o del cablaggio, poiché la disposizione fisica è una questione di praticità di installazione, mentre l’assegnazione delle zone è una decisione di controllo con conseguenze sul comportamento del sistema sia in condizioni di funzionamento normale che in caso di guasto.

Prima dell’inizio della programmazione, questo registro di indirizzamento — che riporta posizione, zona, controller e circuito di alimentazione per ogni unità fisica — deve esistere sotto forma di documento a cui i team di messa in servizio e di controllo possano fare riferimento, e non come informazioni ricostruite in modo informale sulla base di disegni o appunti presi sul campo. Verificare l’esistenza di tale registro e la sua completezza per ogni unità del gruppo è un prerequisito fondamentale per tutte le fasi successive della configurazione del sistema di controllo.

Definire i comandi, i segnali di stato, gli allarmi e i punti di andamento per ciascuna interfaccia

Una volta stabiliti l’identità di ciascuna unità e il contesto della zona, la decisione successiva riguarda ciò che effettivamente attraversa il interfaccia tra i comandi dell'FFU e i sistemi circostanti — il controller dell’unità, qualsiasi gateway e il sistema di gestione dell’edificio. Di norma, è necessario definire in modo esplicito quattro categorie di informazioni: i comandi inviati alle unità, i segnali di stato da esse restituiti, gli allarmi che richiedono una risposta e i valori di andamento o registrati conservati per una successiva analisi. Considerarli come un unico flusso di dati indifferenziato crea ambiguità sul significato di ciascun dato e su chi debba intervenire di conseguenza.

I comandi e i segnali di stato non sono immagini speculari l’uno dell’altro, anche se spesso percorrono lo stesso percorso fisico. Un comando indica a un’unità o a una zona cosa fare; un segnale di stato riporta ciò che sta effettivamente accadendo. Laddove un sistema di controllo confonde i due elementi — ad esempio, deducendo che un comando sia stato eseguito con successo anziché confermarlo tramite un punto di stato indipendente — un progetto perde la capacità di distinguere tra “il sistema ha richiesto questo” e “il sistema ha verificato che ciò sia avvenuto”. Tale distinzione assume la massima importanza proprio quando si verifica un errore, momento in cui è più difficile ricostruirla a posteriori se non è stata integrata fin dall’inizio.

Gli allarmi richiedono una definizione propria, distinta dallo stato ordinario, poiché un allarme implica una risposta obbligatoria, mentre un segnale di stato può essere semplicemente informativo. Quali condizioni generano un allarme, in quale punto della logica di controllo tale allarme viene generato e dove viene instradato sono tutte decisioni specifiche del progetto che dipendono dal modo in cui il processo protetto risponde alla condizione di guasto sottostante. I punti di andamento, a loro volta, hanno uno scopo ancora diverso: vengono conservati per essere esaminati piuttosto che per essere utilizzati in tempo reale, quindi il loro valore dipende da ciò che viene registrato, con quale risoluzione e per quanto tempo, piuttosto che da una risposta immediata.

La questione della titolarità è un filo conduttore che attraversa tutte e quattro le categorie. Per ogni elemento — comando, stato, allarme o andamento — il progetto deve sapere quale sistema lo registra, quale sistema è autorevole al riguardo e a quale sistema un revisore debba fare riferimento qualora il valore registrato venisse mai messo in discussione. Definire questi aspetti a livello di interfaccia, prima che lo schema di controllo sia finalizzato, evita che lo stesso segnale sembri provenire da due sistemi senza che vi sia un accordo su quale dei due sia quello di riferimento.

Assegnare la proprietà a controller di unità, gateway e al sistema di gestione dell'edificio (BMS)

Un'architettura di controllo con un un controller di unità, un gateway e un sistema di gestione dell'edificio crea tre livelli, ciascuno dei quali può plausibilmente rivendicare la responsabilità di una determinata decisione o di un determinato dato. La titolarità deve essere assegnata in modo esplicito, poiché la semplice esistenza di un percorso di dati tra i livelli non stabilisce quale livello sia autorevole in caso di discrepanza tra i valori o quando sia necessario impartire un comando.

Il controller dell’unità è in genere il più vicino all’apparecchiatura fisica e offre la visione più immediata del suo stato operativo effettivo. Il gateway, laddove presente, traduce e aggrega le informazioni tra il controller dell’unità e il BMS e, così facendo, introduce un punto in cui i dati possono subire ritardi, essere trasformati o andare persi se il suo ruolo non è chiaramente definito. Il BMS si trova più lontano dall’unità fisica e in genere ha la visione più ampia su tutte le zone, ma tale visione è accurata solo nella misura in cui lo sono i dati che riceve attraverso i livelli sottostanti. Nessuna di queste tre posizioni è automaticamente quella “corretta” per assumere la responsabilità di una determinata decisione; chi deve assumerla dipende da ciò che la decisione richiede: una risposta fisica immediata favorisce la responsabilità a livello vicino all’unità, mentre il coordinamento tra le zone favorisce la responsabilità a livello del BMS.

Laddove la titolarità rimane implicita, un sistema di controllo può sviluppare comportamenti contrastanti: un comando emesso a livello di BMS potrebbe essere sovrascritto localmente dal controller dell’unità senza che vi sia alcuna traccia di tale sovrascrittura, oppure un gateway potrebbe memorizzare temporaneamente una modifica di stato per un tempo sufficientemente lungo da far sì che il BMS agisca sulla base di informazioni non aggiornate. Nessuna delle due modalità di guasto richiede il malfunzionamento di un singolo componente: entrambe possono verificarsi anche se ogni componente funziona esattamente come previsto, semplicemente perché l’assegnazione dell’autorità non è mai stata resa esplicita per quel punto dati o quel percorso di comando.

Assegnare la proprietà significa anche decidere cosa succede quando i livelli non sono d’accordo: se prevale la lettura locale del controller dell’unità, se al gateway è consentito sostituire un valore predefinito quando non riesce a raggiungere l’unità e se il BMS visualizza un valore che non può verificare autonomamente. Queste decisioni devono essere inserite nello schema di controllo insieme al registro di indirizzamento e alle definizioni dei punti, poiché determinano il comportamento del resto del sistema una volta che i dati stessi scorrono correttamente.

Specificare il comportamento della zona in caso di anomalie relative alla comunicazione, all'alimentazione e all'unità

L'assegnazione degli indirizzi, le definizioni dei punti e le attribuzioni di proprietà descrivono come il sistema dovrebbe comportarsi in condizioni normali. Il comportamento in caso di guasto costituisce una specifica a sé stante e non può essere dedotto automaticamente dalla logica di funzionamento normale: un sistema che funziona correttamente quando tutte le unità comunicano tra loro non presenta, per questo motivo, un comportamento definito per i casi in cui un'unità smetta di comunicare, subisca un'interruzione di alimentazione o diventi comunque non disponibile.

Tre condizioni di guasto si ripetono nei gruppi di FFU: perdita di comunicazione con un’unità, interruzione dell’alimentazione di un’unità e un’unità semplicemente non disponibile per qualche altro motivo. Ciascuna di queste ha una causa sottostante diversa, e trattarle come intercambiabili produce una risposta di controllo che potrebbe risultare inappropriata per almeno una di esse. Una perdita di comunicazione non implica necessariamente che il ventilatore abbia smesso di far circolare l’aria; un’interruzione di alimentazione quasi certamente sì; e un’unità segnalata come non disponibile tramite qualche altro meccanismo può corrispondere o meno a un’effettiva variazione del flusso d’aria. Poiché le conseguenze fisiche differiscono tra questi tre casi, la risposta programmata della zona non dovrebbe assumere automaticamente un comportamento identico per tutti e tre semplicemente perché si tratta, dal punto di vista del sistema di controllo, di “guasti”.

Il comportamento corretto della zona per ciascun guasto dipende dal processo che la zona protegge e dalla valutazione dei rischi specifica del sito, non da un’impostazione predefinita generale adatta a ogni progetto. Laddove una zona protegga un processo che non può tollerare alcuna interruzione del flusso d’aria coordinato, la perdita di comunicazione di una singola unità potrebbe dover attivare un allarme immediato a livello di zona e un comando di ripiego definito per le unità rimanenti, anche prima che la causa sottostante sia confermata. Laddove la zona protegga un processo meno sensibile, la stessa perdita di comunicazione potrebbe essere gestita con un allarme ritardato che conceda il tempo necessario per distinguere un problema transitorio di rete da un vero e proprio guasto dell’unità, evitando una risposta non necessaria a livello di zona a una condizione che si risolve da sola. Nessuno dei due approcci è universalmente corretto; ciascuno rappresenta una valutazione che dipende dal processo protetto e dalle conseguenze di una risposta errata rispetto a una risposta ritardata.

È proprio in questa fase che la decisione di suddivisione in zone del progetto, presa in precedenza durante l’assegnazione degli indirizzi alle zone operative, determina l’ambito della risposta al guasto. Un guasto in un'unità assegnata a una zona strettamente delimitata non dovrebbe propagare automaticamente una risposta alle unità in una zona adiacente, a meno che il processo stesso non richieda un comportamento coordinato oltre tale confine. Specificare esplicitamente tale ambito, per ciascuno dei tre tipi di guasto, è ciò che consente allo schema di controllo di definire una risposta precisa, anziché lasciare che il comportamento effettivo venga scoperto solo quando si verifica un guasto durante il funzionamento.

Verificare l'indirizzamento, l'instradamento degli allarmi e i dati registrati al momento del collaudo in loco

Ogni decisione presa in precedenza — il registro degli indirizzi, le definizioni dei punti, le assegnazioni di proprietà e il comportamento in caso di guasto — rimane sulla carta sotto forma di schema di controllo approvato fino a quando non viene verificata rispetto al sistema installato. Accettazione del sito è il momento in cui si verifica che il progetto corrisponda effettivamente a quanto specificato in termini di realizzazione e programmazione, e tale verifica deve essere effettuata punto per punto, anziché basarsi sul semplice fatto che il sistema sembri funzionare.

La verifica dell’indirizzamento consiste nel confermare che l’indirizzo di ciascuna FFU fisica, così come riportato dal sistema di controllo, corrisponda effettivamente alla posizione, alla zona, al controller e al circuito di alimentazione registrati nel registro. Questa verifica è necessaria perché le attività di installazione e messa in servizio — ricablaggio, sostituzione di unità o rietichettatura — possono compromettere silenziosamente la corrispondenza tra un’unità fisica e la sua identità registrata senza produrre alcun sintomo visibile fino a quando un allarme o un comando non viene indirizzato erroneamente.

La verifica dei comandi di zona consiste nel verificare che un comando inviato a una determinata zona raggiunga effettivamente le unità associate a tale zona e che queste ultime, e solo quelle, lo eseguano. Ciò conferma che la scelta relativa alla suddivisione in zone, effettuata durante la fase di mappatura degli indirizzi, sia stata correttamente implementata nella logica programmata, anziché essere stata semplicemente documentata.

Verificare l'instradamento degli allarmi significa verificare che i percorsi di allarme definiti in precedenza — ovvero quali condizioni generano un allarme e dove tale allarme viene instradato tra i controlli FFU e il BMS — si comportino come specificato in condizioni di test, non solo durante il normale funzionamento. Un percorso di allarme che non è mai stato testato non offre alcuna garanzia che funzionerà correttamente quando si verifica un guasto reale, poiché la modalità di guasto di un percorso di allarme è spesso silenziosa piuttosto che evidente.

La verifica dei valori registrati consiste nel controllare che l’andamento e i dati registrati disponibili all’interfaccia tra i controlli dell’FFU e il BMS corrispondano a quanto specificato nel programma di controllo: i punti corretti, provenienti dalla fonte corretta, conservati in una forma che un revisore possa consultare in seguito. Ciò chiude il cerchio riportando all’attribuzione della responsabilità, poiché un valore registrato è utile solo se la sua fonte autorevole è stata stabilita in anticipo. La verifica di queste quattro aree rispetto al programma di controllo approvato, in questa fase, è ciò che consente al progetto di considerare il comportamento del sistema di controllo come consolidato anziché come ipotetico per il futuro.

Domande frequenti

Q: Cosa occorre sistemare prima di iniziare l'assegnazione definitiva degli indirizzi alle FFU?
A: Impostare nel registro di indirizzamento l'identificatore della posizione fisica, la zona operativa, il controller e la relazione con il circuito di alimentazione per ciascuna unità. Se una qualsiasi di queste assegnazioni è ancora in fase di definizione, mantenere gli indirizzi interessati come provvisori fino a quando la disposizione non sarà definitiva; in caso contrario, una successiva rimappatura potrebbe disconnettere i percorsi di allarme e i registri di collaudo dall'unità installata.

Q: È necessario inviare tutti i dati dei punti di controllo FFU al BMS?
A: No. Selezionare i comandi, i segnali di stato, gli allarmi e i valori di andamento necessari per il piano operativo e di monitoraggio del sito, quindi registrare l’origine, la destinazione e il responsabile di ciascun punto selezionato. Un’interfaccia la cui attribuzione non sia chiara può indurre sia il team addetto ai controlli delle FFU sia il team BMS a presumere che sia l’altra parte a configurarla o verificarla.

Q: In che modo il progetto dovrebbe determinare il comportamento della zona in caso di guasto alle comunicazioni, all’alimentazione o a un’unità?
A: Definire la risposta per ciascun tipo di guasto sulla base della valutazione dei rischi del processo protetto e del sito, e registrare separatamente il comportamento previsto della zona nel programma di controllo approvato. Ricorrere a un’unica soluzione di ripiego comune solo quando il progetto ha stabilito che i diversi guasti comportano le stesse conseguenze; in caso contrario, la risposta prevista può essere tenuta nascosta fino alle prove di accettazione.

Q: Quali aspetti devono essere concordati tra il fornitore dei sistemi di controllo e l'integratore BMS prima della presentazione dell'offerta?
A: Fornire il registro degli indirizzi e l'elenco dei punti di interfaccia, quindi assegnare la proprietà di ciascun comando, segnale di stato, allarme e valore di andamento tra il controller dell'unità, il gateway e il BMS. Risolvere la questione dei punti non assegnati e definire il comportamento richiesto in caso di guasto prima che l'ambito e il prezzo siano definiti in via definitiva, in modo che le attività di messa in servizio non rimangano a carico di più appaltatori.

Q: Come può un acquirente evitare un’operazione apparentemente regolare che nasconde un errore di integrazione del controllo?
A: Utilizzare lo schema di controllo approvato come base di accettazione e verificare, da un capo all'altro, la mappatura degli indirizzi fisici, i comandi di zona, i percorsi di allarme e i valori registrati. Registrare i risultati attesi e quelli osservati per ogni verifica; una semplice risposta in tempo reale non è sufficiente quando l'indirizzo, la destinazione o il valore memorizzato non corrispondono allo schema approvato.