Come trasformare la diagnostica PLC e SCADA in una manutenzione affidabile senza compromettere il controllo.
Il segnale esiste già all'interno del livello di controllo
Un PLC spesso continua a funzionare mentre la sua salute peggiora. Innanzitutto, controlla la cronologia diagnostica, non il sinottico. Le interruzioni delle comunicazioni aumentano lentamente. Un modulo I/O remoto segnala guasti intermittenti. Al livello SCADA, le disconnessioni si ripetono prima di qualsiasi arresto della produzione. Sono segnali di allarme precoci, non rumore. I controller moderni espongono già questi dati. Non serve sempre una nuova rete di sensori. La parte difficile è assegnare a ogni segnale una destinazione utile. Questa destinazione è un record di manutenzione associato a un asset reale.
Passaggio 1 - Raccogliere gli stati reali di salute del controller
La logica predittiva deve utilizzare segnali effettivamente supportati dal dispositivo. Non dare per scontato che ogni PLC esponga gli stessi dati sullo stato di salute. Su un Allen-Bradley ControlLogix (come un Processore Allen-Bradley ControlLogix) o su un sistema CompactLogix, monitora i contatori degli errori della porta EtherNet/IP sulle schede di comunicazione, come il Modulo di comunicazione ControlLogix 1756. Tieni traccia dei conteggi dei guasti recuperabili per ogni stazione remota. Su un controller Woodward raggiungibile tramite Modbus TCP (nei sistemi di monitoraggio con moduli I/O Woodward), interroga i registri relativi alla richiesta di manutenzione e ai limiti di vita utile. Alcuni dispositivi segnalano direttamente guasti interni o un'alimentazione anomala.
-
Passaggio 1 - Elenca ogni dato diagnostico realmente fornito dal dispositivo target.
-
Passaggio 2 - Analizza i contatori settimanalmente, poiché la frequenza rivela il deterioramento meglio di un singolo evento.
-
Passaggio 3 - Genera un allarme solo in presenza di una tendenza crescente o di una durata, non per un singolo picco.
-
Passaggio 4 - Collega ogni contatore a un asset identificato, mai a un rack generico.
Passaggio 2 - Smettere di trasformare ogni allarme in un ticket
Lo SCADA cattura l'attenzione dell'operatore. La manutenzione decide chi deve intervenire fisicamente. Confondere i due ambiti nasconde il deterioramento reale sotto una montagna di ticket inutili. Un allarme di alta temperatura può essere semplicemente un comportamento normale della produzione. Una breve disconnessione può risolversi da sola. Pertanto, valuta la condizione prima di creare un ordine di lavoro. La ripetizione è più significativa di un singolo evento. La durata spesso conta più della gravità di picco. Anche una deriva lenta al di sotto del limite di allarme può meritare un intervento. Inoltre, mantieni separati la presa in carico e il completamento. Un operatore conferma di aver visto un guasto. Ciò non dimostra che l'apparecchiatura sia stata riparata.
-
Passaggio 1 - Aggiungi una regola che richieda tre ripetizioni in sette giorni per attivare un intervento.
-
Passaggio 2 - Aggiungi il contesto: l'asset, la tendenza e gli interventi precedenti.
-
Passaggio 3 - Chiudi il ticket solo dopo che l'intervento è stato eseguito e registrato.
La cronologia delle riparazioni perfeziona il modello
I dati dello storico mostrano cosa è accaduto prima di un guasto. La cronologia della manutenzione mostra cosa è accaduto dopo l'ispezione. Supponiamo che un errore di comunicazione generi continuamente ticket. Ogni volta i tecnici non rilevano alcun difetto hardware. È probabile che il trigger sia troppo sensibile. Tuttavia, se lo stesso evento termina sempre con la sostituzione di un connettore, considera attendibile questo schema. Merita attenzione anticipata. Gli interventi completati separano il sintomo dalla causa. Un guasto I/O fantasma può essere riconducibile a un dispositivo di campo che ha perso alimentazione. Sostituire il modulo significherebbe riparare l'asset sbagliato. La nota di chiusura conserva la causa reale per il turno successivo.
Integrare senza introdurre rischi
Un CMMS non deve diventare un client privilegiato del sistema di controllo. Instrada la diagnostica verso l'esterno attraverso un livello dati. Acquisisci la tendenza dallo SCADA o da uno storico. Utilizza OPC UA in sola lettura per le informazioni standardizzate sullo stato di salute e sulla diagnostica. Un servizio di integrazione trasferisce quindi gli eventi qualificati alla piattaforma di manutenzione tramite API. In questo modo il traffico della manutenzione resta lontano dalla logica sensibile ai tempi. I calcoli predittivi non devono essere eseguiti all'interno del controller. Inoltre, proteggi la rete. Un'applicazione di manutenzione raramente deve scrivere nella memoria del PLC. Limitala all'accesso in sola lettura. Segui il processo di gestione delle modifiche dello stabilimento prima che qualsiasi collegamento automatizzato raggiunga la produzione. Infine, sincronizza gli orologi. Un evento SCADA registrato a distanza di minuti dal record CMMS compromette la ricostruzione del guasto.
Conclusione e consigli operativi
La manutenzione predittiva premia la pazienza e un flusso di dati pulito, non i cruscotti sofisticati. Innanzitutto, raccogli solo gli stati di salute realmente forniti dai tuoi dispositivi. In secondo luogo, valuta una condizione in base alla ripetizione e alla durata prima di creare un ticket. Inoltre, lascia che la cronologia verificata delle riparazioni perfezioni i tuoi trigger nel tempo. Tuttavia, non consentire mai al CMMS di scrivere nella logica di controllo né di ignorare la gestione delle modifiche. Pertanto, crea un percorso in sola lettura attraverso lo storico e OPC UA, con orari sincronizzati. Infine, considera l'infrastruttura di controllo stessa come apparecchiatura soggetta a manutenzione. Inizia questa settimana da un collegamento EtherNet/IP critico. Verifica il ciclo end-to-end prima di estenderlo a tutto lo stabilimento.
Autore: Sun Yifei è un ingegnere dell'automazione industriale con oltre 10 anni di esperienza in PLC, DCS e sistemi di controllo.
