Il momento più economico per correggere un progetto di edilizia intelligente è prima della scadenza della gara.
Quando un progetto di costruzione intelligente va storto sul posto, il danno è solitamente già stato fatto mesi prima. Gli errori più costosi vengono commessi prima che qualsiasi cosa venga installata: risultati mai definiti in termini operativi, interfacce che nessuno possiede, dati considerati pronti quando non lo sono e criteri di accettazione scritti dopo che l’appaltatore ha finito. Anche i problemi durante l'installazione sono importanti, ma sono per lo più sintomi di quelle lacune precedenti. Nessun prodotto, per quanto capace, può salvare un brief ambiguo.
Vale la pena cercare prima otto errori. Sono elencati di seguito più o meno nell'ordine in cui vengono realizzati da un progetto.
Si inizia con una dimostrazione impressionante. Viene selezionata una piattaforma e il progetto va quindi alla ricerca dei problemi che può risolvere. Da quel momento il team di consegna sta ottimizzando per la dimostrazione. Il funzionamento quotidiano diventa un ripensamento e il proprietario finisce per pagare per funzionalità che nessuno utilizza.
Il rimedio è scrivere, per ciascuna funzione prevista, chi la utilizza, quale decisione supporta, quale azione segue e come verrà controllato il successo, e solo allora selezionare i prodotti in base a tali affermazioni.
Il programma di integrazione prevede alcuni giorni per "collegare il BMS". Quindi la squadra scopre nomi di punti incoerenti, unità mancanti, rapporti con apparecchiature non documentate e sensori che sono hanno subito deriva. La mappatura e la correzione diventano variazioni non prezzate e finché non vengono eseguite l'analisi produce risultati fuorvianti.
Un'indagine su un campione rappresentativo di punti prima della gara evita la sorpresa. Consente di stimare lo sforzo di mappatura e correzione e di trasformarlo in un articolo con ambito prezzato con un proprietario nominato.
Due fornitori consegnano ciascuno apparecchiature conformi, ma il flusso di lavoro combinato fallisce e ciascuno afferma che la colpa è dell'altro. Difetti di integrazione di questo tipo passano oltre la consegna senza alcun proprietario contrattuale. Il US Department of Energy lo annovera tra i principali ostacoli a un buon controllo degli edifici: l'integrazione coinvolge tipicamente diversi fornitori con hardware, software e protocolli proprietari, e i dati finiscono in silos.
Un registro d'interfaccia lo impedisce nominando, per ogni connessione, i dati oi comandi scambiati, il protocollo e la versione, e il responsabile a ciascuna estremità. La certificazione di prodotto aiuta ma non la sostituisce. La certificazione BACnet Testing Laboratories (BTL) dimostra che un prodotto è stato testato in modo indipendente rispetto al pacchetto di test BACnet per verificarne la conformità e l'interoperabilità, riducendo il rischio di integrazione; la sequenza del tuo progetto deve ancora essere testata sul posto.
La messa in servizio mostra i valori che appaiono su uno schermo e i comandi che raggiungono i dispositivi, il tutto mentre ogni sistema è integro. Quindi la prima interruzione della rete, il riavvio del server o il guasto del sensore rivelano un comportamento che nessuno ha mai specificato.
L'accettazione deve includere i casi di guasto: perdita della rete, perdita di un server o di un servizio cloud, valore del sensore obsoleto o mancante e successivo ripristino. La specifica dovrebbe indicare cosa deve avvenire a livello locale e quali allarmi devono comparire.
Password predefinite sui controller, account dei fornitori condivisi, accesso remoto organizzato in modo informale, sistemi di costruzione sulla stessa rete piatta di tutto il resto: ognuno di essi è una debolezza evitabile. Sono importanti perché i sistemi di costruzione controllano le apparecchiature fisiche. La guida NIST alla sicurezza operativa della tecnologia (SP 800-82) comprende nel suo ambito i sistemi di automazione degli edifici; in tali sistemi un incidente di sicurezza può compromettere la sicurezza e la disponibilità, nonché i dati.
La segmentazione della rete, gli account individuali, l'accesso remoto gestito, le responsabilità di aggiornamento e un inventario dei dispositivi connessi dovrebbero essere tutti specificati come risultati finali e verificati all'accettazione come qualsiasi altra cosa.
Un'applicazione segnala i guasti ogni mattina, ma nessuno ha il tempo o l'autorità per risolverli. Il lavoro arretrato aumenta, il team smette di cercare e il proprietario paga un abbonamento che non cambia nulla nell'edificio.
Prima del go-live, nomina la persona che revisiona ogni output, il tempo che ha a disposizione e come verranno monitorate le azioni. Un minor numero di avvisi e un livello di sicurezza più elevato costituiscono un’apertura migliore, con l’ambito ampliato man mano che il team acquisisce l’abitudine.
Il budget di capitale è stato approvato, ma gli abbonamenti, il supporto, i rinnovi delle licenze e le spese di esportazione dei dati non sono mai stati confrontati. Il vero costo emerge dopo il dopo la consegna, quando il potere contrattuale del proprietario è più debole e le restrizioni sull'accesso ai dati possono rendere costoso il successivo cambio di fornitore.
I costi dell’intera vita dovrebbero essere confrontati nello stesso periodo e l’accesso ai dati, i diritti di esportazione e l’assistenza alla transizione dovrebbero essere stabiliti nel contratto prima dell’aggiudicazione.
L'installazione è completata, l'appaltatore se ne va e il team operativo riceve una serie di manuali e una password. Incapace di mantenere sequenze, indagare sui guasti o gestire gli utenti, il team osserva il calo delle prestazioni.
La disponibilità operativa deve far parte dell'accettazione. I ruoli nominati dovrebbero essere formati sui loro compiti reali e chiesto di dimostrare i flussi di lavoro chiave prima che l'edificio venga accettato, e dovrebbero ricevere disegni architettonici attuali, pianificazioni dell'interfaccia, backup di configurazione e dettagli sulla licenza.
La maggior parte di questi errori possono essere rilevati sulla carta. Se un brief non riesce a superare il test riportato di seguito, il rischio è ancora nel progetto.
| Controllo | Pronto se... |
|---|---|
| Casi d'uso | Ognuno ha un utente, una decisione, un'azione e una misura di successo |
| Dati | È stato esaminato un campione rappresentativo ed è stato stimato lo sforzo di correzione |
| Interfacce | Ogni connessione ha proprietari ad entrambe le estremità |
| Modalità di fallimento | Il comportamento previsto è scritto per interruzioni comuni |
| Sicurezza | I compiti di segmentazione, accesso e aggiornamento sono risultati finali |
| Operazioni | Le persone nominate agiranno sugli output |
| Aspetti commerciali | I costi ricorrenti e i diritti sui dati sono comparabili tra le offerte |
Qualsiasi riga lasciata senza risposta tornerà probabilmente dopo l'assegnazione, come variazione o come sistema che nessuno utilizza. Correggerlo sulla carta costa molto meno e una revisione indipendente dei documenti di gara, offerta da Pagin Consulting, mostra quali lacune colmare per prime.
Questo articolo si collega al nostro lavoro su Progettazione di edifici.
Possiamo discutere come questo tema entra nel brief del progetto.
Contatta Pagin Consulting