In che modo gli allarmi dell'edificio possono generare automaticamente ordini di lavoro di manutenzione?

Il modo più rapido per seppellire una squadra di manutenzione è collegare ogni allarme dell'edificio direttamente al sistema di manutenzione. Se eseguiti correttamente, tuttavia, gli ordini di lavoro automatici sono una delle integrazioni più utili che un edificio possa avere. Un'interfaccia tra il sistema di gestione dell'edificio (BMS) e il sistema computerizzato di gestione della manutenzione (CMMS) rileva un allarme qualificante, identifica l'asset a cui appartiene, controlla se esiste già un ordine di lavoro per quel problema e ne crea uno con la giusta priorità o aggiorna quello aperto.

La connessione stessa è solitamente la parte facile. Ciò che decide se aiutare o inondare il team è un insieme di regole: quali allarmi si qualificano, come vengono gestiti i duplicati e le cascate e come viene chiuso un ordine di lavoro. È meglio scrivere tali regole come policy dall'allarme all'ordine di lavoro prima che qualcuno configuri l'integrazione.

Centinaia di allarmi, una manciata di guasti

Gli edifici possono generare molti più allarmi di quelli su cui si agisce. Alcuni sono veri e propri difetti. Una buona percentuale può essere costituita da allarmi fastidiosi derivanti da limiti impostati in modo errato, sensori fuori calibrazione, apparecchiature in modalità di manutenzione o dagli effetti a catena di un singolo guasto a monte. Passateli tutti al CMMS e quel rumore si trasformerà in centinaia di ordini di lavoro. Gli ingegneri imparano a ignorarli e i veri difetti scompaiono nel volume.

Le sale di controllo dell’industria di processo si trovavano ad affrontare lo stesso problema. Lo standard ISA-18.2 sulla gestione dei sistemi di allarme, e i suoi rapporti tecnici, sono incentrati su una filosofia di allarme documentata e sulla razionalizzazione, ovvero la conferma che ogni allarme è necessario, ha una risposta definita e ha la corretta priorità. ISA-18.2 è scritto per le industrie di processo, non per gli edifici, ma la sua idea centrale si trasferisce bene: un allarme che non richiede un'azione definita da parte di una persona definita non dovrebbe essere un allarme, e certamente non dovrebbe essere un ordine di lavoro.

Decidere quali allarmi si qualificano

La policy inizia ordinando gli allarmi in tre gruppi:

Ogni allarme relativo all'ordine di lavoro necessita quindi di una risorsa definita, una priorità, un'impresa o un appaltatore responsabile e una risposta prevista.

Ogni allarme ha bisogno di un indirizzo

Un ordine di lavoro è utile solo se incontra la risorsa corretta nel CMMS, completa di posizione, cronologia e documenti. Ciò richiede una mappatura tra il punto BMS che genera l'allarme e l'identificatore della risorsa CMMS. Sui nuovi progetti la mappatura dovrebbe essere specificata nei requisiti informativi e identificatori coerenti tra BIM, COBie, BMS e CMMS lo rendono molto più semplice. Sugli edifici esistenti, aspettati di costruirli e controllarli manualmente per gli allarmi previsti.

Norme per le situazioni che provocano ondate di allarmi

Le inondazioni di allarme derivano da una manciata di situazioni prevedibili e ciascuna necessita di una regola esplicita:

• Un ritardo di persistenza richiede che un allarme duri per un tempo concordato prima di generare un ordine di lavoro, quindi le escursioni momentanee non creano attività.
• Un allarme rumoroso, che si attiva e si cancella ripetutamente, dovrebbe aggiornare un singolo ordine di lavoro e registrare lì ogni ripetizione. Il chiacchiericcio persistente è di per sé un difetto, da indagare come tutti gli altri.
• Se un ordine di lavoro è già aperto per la stessa risorsa e condizione, a tale ordine viene aggiunta una nuova occorrenza; non diventa mai un duplicato.
• Quando un guasto attiva molti allarmi a valle, i sintomi dovrebbero essere collegati a un singolo ordine di lavoro sulla causa probabile. Ciò richiede relazioni tra le apparecchiature, ad esempio quale pompa serve quali zone. Un modello semantico come Brick, che descrive le risorse dell’edificio e le relazioni tra di loro, rende queste regole a cascata molto più facili da scrivere e mantenere.
• Quando un tecnico lavora su un'apparecchiatura, i relativi allarmi devono essere soppressi o contrassegnati per un periodo definito, con la soppressione registrata e limitata nel tempo.

La priorità e il routing vengono dopo. La priorità dell'allarme dovrebbe corrispondere alla priorità dell'ordine di lavoro e al tempo di risposta utilizzando le categorie già presenti nel contratto di manutenzione, e il lavoro dovrebbe essere instradato per settore, luogo e ora del giorno, con un'escalation se nessuno lo riconosce entro il tempo concordato. Le regole fuori orario meritano particolare attenzione, perché una chiamata di emergenza generata automaticamente è costosa quando l'allarme non la giustifica.

Quando viene effettivamente risolto un guasto?

Un ordine di lavoro non dovrebbe chiudersi solo perché l'allarme è stato cancellato. Gli allarmi vengono cancellati per molte ragioni, incluso qualcuno che li ripristina. Una solida regola di chiusura richiede sia che l'allarme sia tornato alla normalità e sia rimasto lì per un periodo concordato, sia che l'ingegnere abbia registrato ciò che è stato riscontrato e fatto. Se lo stesso allarme ritorna all'interno di una finestra definita, l'ordine di lavoro si riapre o ne viene creato uno collegato e viene segnalata la ricorrenza.

Tali risultati dovrebbero avere un riscontro nella politica. Gli allarmi che continuano a creare ordini di lavoro chiusi come "nessun errore riscontrato" necessitano di una revisione dei limiti o della logica e tale revisione è il modo in cui la politica migliora nel tempo.

Scegliere dove risiede la logica

Già nel 2010, la Guida alle migliori pratiche per le operazioni e la manutenzione del Dipartimento dell'Energia degli Stati Uniti rilevava che molti prodotti CMMS potevano interfacciarsi con i sistemi di gestione e controllo dell'energia, quindi la capacità raramente rappresenta un ostacolo. I modelli comuni sono un'interfaccia diretta dal software di supervisione BMS al CMMS, un middleware o una piattaforma di integrazione che applica le regole, o un livello dati indipendente che riceve eventi da diversi sistemi e inoltra quelli qualificanti. Per qualsiasi cosa che vada oltre un piccolo edificio, generalmente preferiamo mantenere le regole in un luogo visibile e documentato. Sparsi tra la logica BMS e la configurazione CMMS, diventano difficili da controllare.

Qualunque sia il modello scelto, la specifica dovrebbe coprire il contenuto del messaggio, l'identificatore della risorsa utilizzato, il comportamento dei tentativi se il CMMS non è disponibile, il modo in cui vengono prevenuti i duplicati e cosa registra l'integrazione. I test dovrebbero utilizzare scenari realistici: un singolo guasto, un allarme intermittente, una cascata, un allarme durante la modalità di manutenzione e il CMMS che va offline.