Un sistema misto di distribuzione dell’aria raramente si guasta perché qualcuno ha scelto il regolatore sbagliato. Si guasta perché nessuno ha definito, prima della fase di progettazione, quale unità di filtraggio dei ventilatori chi doveva agire di concerto, chi doveva raggiungerli e, innanzitutto, cosa si intendesse con il termine “controllo” nel contesto del progetto. La scelta tra controllo locale e controllo centralizzato consiste in realtà in una serie di decisioni più specifiche relative a zone, segnali e accesso; e la corretta sequenza di tali decisioni determina ciò che un fornitore può effettivamente configurare.

Inizia dalle zone operative, non dall'etichetta del regolatore

“I termini ”locale“ e ”centrale” descrivono l’origine di un comando, non ciò che il sistema deve fare. Prima che un acquirente possa confrontare i percorsi di controllo, il progetto deve definire le proprie zone operative: i gruppi di FFU che devono rispondere all’unisono, i gruppi che devono rimanere indipendenti e le condizioni al contorno che separano una zona dall’altra. Una zona non è necessariamente una stanza. Può trattarsi di un’area di processo all’interno di una stanza, di un insieme di unità al servizio di una postazione di lavoro o di una singola unità indipendente che non ha alcuna relazione operativa con le unità vicine.

Questo è importante perché l’architettura di controllo segue la logica delle zone, non il numero di apparecchiature. Laddove un progetto preveda molte FFU ma solo pochi gruppi operativi indipendenti, un sistema in rete potrebbe svolgere un carico di lavoro di gran lunga superiore a quanto richiesto dalla suddivisione in zone. Laddove un progetto preveda un numero minore di unità, ma ciascuna richieda una programmazione, un accesso o una regolazione basata sulle condizioni distinti, anche un’implementazione di piccole dimensioni può giustificare una soluzione più strutturata rispetto alla semplice regolazione locale. Il numero di zone è un dato di input del progetto che l’acquirente definisce in base alla disposizione degli ambienti e dei processi, non un presupposto mutuato da un’installazione dall’aspetto simile.

La definizione delle zone deve inoltre distinguere tra l'erogazione dell'aria e la responsabilità del controllo. Un'unità ventilatore-filtro e un'unità a flusso laminare possono entrambe convogliare aria filtrata in una zona di lavoro, ma non condividono necessariamente lo stesso sistema di controllo, e un alloggiamento del filtro terminale un sistema privo di ventilatore proprio non presenta alcuna questione di controllo in senso stretto — il suo ruolo è quello di fornire aria in modo passivo, non di funzionare su comando. Raggruppare questi sistemi sotto un unico schema di controllo, semplicemente perché si trovano nella stessa stanza, rende difficile distinguere quali apparecchiature necessitino effettivamente di un percorso di comando e quali richiedano solo la verifica del flusso d’aria.

I requisiti di accesso rientrano in questo stesso esercizio di suddivisione in zone. Chi deve modificare un’impostazione e in quali circostanze — modifica della programmazione, modifica del processo, attività di manutenzione — determina se una zona può essere gestita a livello di singola unità o se è necessario un punto di accesso condiviso. La documentazione del produttore illustra questa gamma a livello di prodotto: La famiglia CamFFU HP-EC di Camfil elenca le opzioni di controllo tramite dispositivo portatile o BUS per una singola linea di FFU, mentre il catalogo PURAFLO di Price Industries descrive il controllo locale o BACnet per le proprie apparecchiature per l’aria pulita. Entrambi dimostrano che la posizione di controllo è un attributo configurabile del prodotto, non una caratteristica fissa di ’un’FFU“ in generale — ed è proprio per questo che deve avere la precedenza la definizione della zona da parte dell’acquirente, non la categoria dell’apparecchiatura.

Confronto tra percorsi di controllo locali, raggruppati e in rete

Una volta definite le zone, i tre grandi percorsi di controllo diventano comparabili secondo i propri termini piuttosto che come opzioni generiche in competizione tra loro. Il controllo locale colloca il comando e l’indicazione sull’apparecchiatura stessa. Elimina qualsiasi dipendenza da una rete di comunicazione, il che semplifica sia l’installazione che la risoluzione dei problemi laddove una zona è realmente autonoma. Il suo svantaggio è l’accesso distribuito: chiunque debba verificare lo stato o effettuare una regolazione deve trovarsi fisicamente presso l’unità, e il coordinamento di più unità sotto controllo locale richiede un’azione separata su ciascuna di esse.

Il controllo raggruppato si colloca a metà strada tra le due opzioni. Allinea diverse FFU che servono una stanza o una zona di processo sotto un unico punto di comando, senza necessariamente estendere tale comando a una rete a livello di impianto. Ciò si adatta a situazioni in cui una zona dispone di più di un’unità, ma il progetto non richiede che lo stato di quella zona venga reso visibile al di fuori dei propri confini. Il compromesso è che il controllo raggruppato comporta l’introduzione di un quadro elettrico, del cablaggio e di un elenco definito di unità incluse — decisioni che dovranno essere riviste qualora i confini della zona dovessero cambiare in seguito.

Il controllo in rete o centralizzato estende i comandi, lo stato e spesso i dati tracciabili a un sistema di controllo del progetto più ampio. Le opzioni documentate da Camfil per la sua famiglia HP-EC includono il controllo LON, Modbus o 0-10 V, mentre il catalogo di Price distingue il funzionamento locale da quello basato su BACnet con punti monitorati quali lo stato del filtro e la caduta di pressione. Questi esempi dimostrano che la disponibilità dei protocolli è specifica per ciascun prodotto e varia a seconda del produttore e della configurazione — un fatto che l’acquirente deve considerare come una questione relativa alle apparecchiature di YOUTH piuttosto che come un presupposto tratto dal catalogo di un altro fornitore.

Il criterio decisionale non è che il controllo in rete sia più efficiente in senso assoluto. È piuttosto che il controllo in rete soddisfi un’esigenza del progetto in termini di visibilità remota, allarmi coordinati o analisi centralizzata dei trend, e che tale esigenza debba sussistere prima che valga la pena introdurre nel progetto la complessità aggiuntiva — configurazione del gateway, indirizzamento, perimetro di sicurezza informatica, responsabilità dell’integrazione. Laddove una zona non abbia l’esigenza di inviare dati all’esterno, il controllo locale o raggruppato evita tale sovraccarico. Laddove il team di controllo del progetto gestisca già una rete dell’edificio o della struttura e preveda che le unità funzionali (FFU) trasmettano i dati a tale rete, il controllo in rete diventa il quadro che soddisfa effettivamente le esigenze del progetto, a condizione che il protocollo e la disponibilità dei punti siano confermati per la configurazione selezionata.

Definire i limiti relativi a segnali, alimentazione, accesso e guasti

La scelta di un percorso di controllo definisce solo la struttura generale. L’acquirente deve comunque definire le interfacce all’interno di tale struttura: come l’alimentazione raggiunge ciascuna unità, quali segnali viaggiano dove, chi può accedere fisicamente a un’unità e cosa succede quando un collegamento o un’unità non sono disponibili.

La distribuzione dell’alimentazione è un elemento di progetto prima ancora di essere una questione di controllo. Il modello di alimentazione disponibile — ovvero il modo in cui l’energia raggiunge le unità e i pannelli e dove avviene l’isolamento — determina quali funzioni di controllo siano effettivamente possibili in quel punto. Un’unità cablata per una semplice alimentazione on/off non può trasmettere comandi di velocità o di modalità senza un diverso approccio alla distribuzione e al cablaggio, indipendentemente dal percorso di controllo scelto a livello concettuale.

I comandi e i feedback devono essere specificati, non dati per scontati. Un progetto potrebbe prevedere come comandi l'accensione/spegnimento, la regolazione della velocità, la selezione della modalità o il funzionamento basato su una programmazione, e come feedback lo stato, gli allarmi o i valori monitorati. Documentazione PURAFLO di Price dimostra che determinate apparecchiature possono fornire informazioni quali lo stato dei filtri e la caduta di pressione, oltre all’accesso al controllo locale o tramite BACnet; tuttavia, tale elenco si riferisce ai prodotti Price citati, non alle unità FFU in generale. L’elenco dei parametri fornito dall’acquirente deve essere verificato rispetto a ciò che la configurazione selezionata rende effettivamente disponibile, poiché un parametro desiderato che non è presente sull’unità scelta non potrà essere recuperato in un secondo momento senza una modifica hardware.

La topologia di rete, in cui viene scelto un percorso in rete o raggruppato, richiede una propria conferma: quale protocollo si aspetta la piattaforma di progetto, se è necessario un gateway, come viene gestito l’indirizzamento e chi è responsabile di tale configurazione una volta installata. È qui che il confine tra fornitore delle apparecchiature e integratore dei controlli di progetto deve essere esplicito, poiché un punto di controllo presente sull’unità non è la stessa cosa di un punto che è stato mappato, indirizzato e verificato nel sistema di progetto.

L’accesso e il fallback completano il quadro. I vincoli di accesso relativi agli operatori e alla manutenzione determinano se sia necessaria una deroga locale anche all’interno di uno schema raggruppato o in rete: un’unità che può essere comandata solo da remoto potrebbe comunque necessitare di un percorso di accesso locale documentato per le operazioni di manutenzione. Il manuale delle apparecchiature Terra illustra che l’alimentazione e l’accesso fisico alle FFU sono interfacce di installazione a livello di unità, che rappresentano un aspetto distinto dall’interfaccia di comunicazione sovrapposta. La risposta a un’interruzione della comunicazione o a un’unità isolata — ovvero cosa fa il sistema e cosa ci si aspetta che faccia un tecnico — non è qualcosa che l’acquirente dovrebbe presumere o specificare unilateralmente. Deve essere documentata congiuntamente dal fornitore e dal team di controllo del progetto, poiché un’ipotesi di sicurezza in caso di guasto non verificata e riportata nella fase di messa in servizio diventa una lacuna individuata durante i test anziché risolta in fase di progettazione.

Trasformare la scelta in un passaggio di progetto verificabile

Una decisione relativa all'architettura di controllo ha valore solo se viene messa per iscritto in una forma che i team di progettazione, realizzazione e messa in servizio possano utilizzare come base per agire e verificare. ISO 14644-4 descrive come i requisiti si riflettano nelle fasi di progettazione, costruzione, avviamento, verifica e manutenzione continua dei progetti relativi alle camere bianche — stabilisce che questa catena di custodia delle informazioni sia fondamentale, senza prescrivere quale debba essere l’architettura di controllo né chi detenga la responsabilità contrattuale per ciascuna interfaccia. Tale attribuzione spetta al progetto stesso.

Il documento di passaggio delle consegne dovrebbe indicare l’architettura scelta — locale, raggruppata o in rete — e l’appartenenza alle zone ad essa associata, in modo che chiunque esamini il progetto in seguito possa risalire a quali unità appartengano a quale perimetro operativo. Dovrebbe elencare i comandi e i punti di feedback concordati per quell’architettura, distinguendo i punti disponibili sulle apparecchiature selezionate da quelli che il sistema di progetto deve ancora ricevere tramite mappatura o configurazione. Dovrebbe indicare il soggetto responsabile della configurazione di tali punti, poiché un elenco di punti privo di un responsabile tende a emergere come lacuna durante l’integrazione piuttosto che durante la revisione del progetto.

I disegni e le schede tecniche devono essere inseriti in questo documento per lo stesso motivo: uno schema di controllo che illustra quadri, zone, dispositivi e percorsi di comunicazione fornisce al team addetto alla messa in servizio un riferimento per verificare le apparecchiature, ma riflette la selezione finale solo una volta che tale selezione è stata effettivamente effettuata — non può sostituire le decisioni relative alle apparecchiature e alle interfacce ancora in sospeso nelle fasi iniziali del progetto.

Le prove di messa in servizio devono essere specifiche per ogni progetto. La scelta di un protocollo o la documentazione che attesti che un’unità supporti BACnet o un altro schema di comunicazione non costituiscono prova del fatto che il sistema installato funzioni come previsto o che l’ambiente soddisfi le condizioni richieste. I criteri di accettazione e i soggetti responsabili della loro verifica sono decisioni che spettano al progetto, non conclusioni che derivano automaticamente dalla scelta delle apparecchiature.

Il documento dovrebbe inoltre indicare chiaramente ciò che non rientra nell’ambito di competenza del fornitore della FFU: l’infrastruttura di rete al di là dell’interfaccia dell’unità, l’integrazione a livello di edificio o le attività di messa in servizio a livello di locale che dipendono da altre figure professionali. Quando un acquirente prepara queste informazioni per la revisione, strutturarle in questo modo fornisce alla revisione della configurazione e del preventivo da parte di YOUTH un punto di partenza ben definito: un elenco delle zone, un elenco dei punti e un percorso di controllo specificato, anziché una richiesta di dedurre tali decisioni solo dai nomi delle apparecchiature. Da lì, collegando la configurazione FFU scelta e qualsiasi elemento correlato unità a flusso d'aria laminare oppure l’alloggiamento dei terminali nello stesso sistema misto, la sequenza di consegna e integrazione del progetto diventa una questione di verifica delle interfacce rispetto a tale documentazione, piuttosto che di rinegoziazione dell’architettura in fase di installazione. I lettori che stanno preparando questo passaggio di consegne nell’ambito di una più ampia revisione dei fornitori potrebbero trovare utile attenersi alla stessa disciplina documentale descritta in Guida di Youthfilter all’approvvigionamento di attrezzature per camere bianche e alla valutazione dei fornitori.

Domande frequenti

Q: È necessario un sistema di controllo centralizzato delle FFU se ho una sola sala gestita in modo indipendente?
A: Non necessariamente. La regolazione locale può essere adatta a un piccolo ambito operativo autonomo, purché l'accesso, la segnalazione e le impostazioni richieste possano essere gestiti direttamente sulle unità. Comandi remoti, allarmi o punti di tendenza potrebbero giustificare un'architettura diversa; è opportuno definire tali esigenze prima di scegliere un marchio di controllore.

Q: Le FFU che servono processi diversi possono condividere un unico gruppo di controllo?
A: Dovrebbero essere raggruppate solo se i requisiti operativi del progetto richiedono comandi coordinati. Definire quali unità devono operare insieme e quali condizioni o tempistiche differiscono. Registrare l’appartenenza alle zone e le esigenze di esclusione locale, in modo che il fornitore possa confermare il raggruppamento proposto.

Q: Specificare lo stesso protocollo utilizzato dal nostro sistema di gestione dell'edificio garantirà la compatibilità?
A: No. I punti proposti, il gateway, l’indirizzamento, la mappatura e l’ambito di configurazione devono ancora essere confermati. Chiedete al fornitore e al team di controllo del progetto di concordare lo schema di controllo e l’elenco dei punti, specificando chi fornirà i sensori, chi riceverà gli allarmi e chi completerà l’integrazione.

Q: Cosa dovrebbe indicare il preventivo riguardo alla perdita di comunicazione?
A: Dovrebbe documentare la risposta proposta per la configurazione selezionata e identificare gli elementi che devono ancora essere confermati nell’ambito del progetto. Definisci le tue aspettative in termini di funzionamento e accesso ai servizi, quindi verifica come si comportano le unità e i controlli quando un collegamento o un’unità non è disponibile. Non dedurre il comportamento di fallback dalla scelta del protocollo.