Lo scorso mese , ho esaminato l'analisi preliminare necessaria per iniziare a costruire un SEM per il simulatore Tennessee Eastman (un simulatore di processi chimici). Questa analisi ha prodotto fattori e correlazioni fattoriali tra variabili manifeste e fattori latenti, che possono essere utilizzati come modello di base per il confronto SEM. Tuttavia, come ho già detto in alcuni i miei post precedenti , altri modelli devono essere creati e considerati sulla base dell'analisi preliminare per determinare se abbiamo trovato un buon modello per il sistema. In questo caso, un modello “buono” sarebbe quello in grado di rilevare guasti nel sistema senza segnalare alcun problema durante il normale tempo di esecuzione. Uno dei modi principali in cui valuterò questi modelli è attraverso le metriche statistiche fornite JMP Pro la finestra di confronto dei modelli di.
Costruire il SEM
Prima di addentrarmi nella costruzione del modello, voglio fornirti una delle mie tabelle complete di confronto dei modelli. Ogni volta che menziono uno dei SEM in questa sezione, farò riferimento alla tabella seguente con il numero di modello corrispondente al modello corretto. L'ho fatto per evidenziare quanti modelli è necessario creare anche solo per iniziare a farsi un'idea dei dati, ma non ho intenzione di spiegare ciascuno di questi modelli, solo i più importanti.
Durante la creazione dei SEM, ho utilizzato solo i dati di controllo. Una volta completato il modello, l'ho applicato a vari intervalli di tempo per cercare di osservare quali cambiamenti si sono verificati. Per semplificare le cose, ho creato il primo modello utilizzando solo due fattori con una covarianza tra i fattori poiché sappiamo che questi fattori sono probabilmente correlati (questo è il modello 5).
Lo vediamo attraverso le linee continue, che denotano la significatività statistica, e la linea tratteggiata, che denota una correlazione statisticamente significativa. Poiché selezioniamo noi stessi le correlazioni, è probabile che una linea tratteggiata indichi che la correlazione tra tali variabili non è necessaria nel modello affinché il modello si adatti bene ai dati. Dalla nostra conoscenza del dominio, sappiamo che deve esserci una relazione covariata tra questi fattori (temperatura e pressione), quindi questo dovrebbe far scattare un campanello d’allarme su questo modello.
Tuttavia, potresti ricordare in il mio post precedente Ho detto che un paio di variabili manifest basate sul compressore non sono correlate alla pressione come le altre variabili. Quindi, a questo punto, ho deciso di aggiungere un terzo fattore latente, chiamarlo compressore e assegnare le variabili manifeste precedentemente associate alla pressione a questo nuovo fattore compressore. Come probabilmente avrai capito a questo punto, è probabile che tutti i nostri fattori latenti siano altamente correlati tra loro, quindi in questo modello è stata aggiunta una covarianza tra tutti i fattori. In pratica questo ha senso poiché il compito del compressore è quello di aumentare la pressione, ma produce anche calore nel processo, il che significa che è probabile che influenzi sia i nostri fattori di temperatura che quelli di pressione (questo è il modello 9 nella tabella).
Confrontando il modello 5 con il modello 9, vediamo che il modello 9 ha prestazioni migliori in ogni parametro testato. Non solo, ma vediamo anche che tutte le nostre covarianze tra fattori latenti sono ora statisticamente significative. Questo è un risultato promettente. Potresti anche notare nella tabella comparativa che abbiamo molti valori negativi; questo non è un problema Si applicano le stesse regole: valori più bassi sono migliori. Qui puoi vedere che, dei 12 modelli che ho creato, il modello 9 è il modello “migliore” statisticamente.
Rilevamento guasti
Quindi, ora che abbiamo un modello che sembra adattarsi abbastanza bene ai dati e ci fornisce correlazioni statisticamente significative quando siamo sotto controllo, è tempo di porci la grande domanda: Come ci mostra il SEM che c'è un guasto? Questo è il nocciolo del mio lavoro, quindi evidenzierò un paio di modi in cui ho scoperto che l'errore potrebbe essere rilevato e i pro e i contro di questi metodi di rilevamento dell'errore.
I lettori più attenti tra noi potrebbero aver notato che, sebbene nel mio ultimo post abbia menzionato che il guasto era un errore nel rapporto di alimentazione A/C, non ci sono variabili manifeste relative al rapporto di alimentazione A/C nel modello! Tratterò più approfonditamente questo punto il mese prossimo mentre affronterò i problemi con questo modello, ma per ora so solo che ho testato varie variabili relative al rapporto A/C e ho scoperto che l'aggiunta che forniva le statistiche migliori era quando la variabile "A- Feed S1” è stato aggiunto al modello.
Di seguito ho incluso le statistiche di confronto per due modelli con inclusa la variabile A-Flow. Come al solito, vengono forniti i modelli illimitati e indipendenti, insieme al modello 3, che è un SEM senza connessioni di covarianza tra i fattori latenti. Il modello 4 è lo stesso SEM ma con inclusa la covarianza tra i fattori latenti (è più probabile che questo sia il modello corretto).
Ci sono alcuni modi in cui si osservano i cambiamenti all’interno del sistema. In primo luogo, la significatività della connessione tra le variabili può essere un indicatore del verificarsi di un errore poiché quella connessione che dovrebbe essere importante ora viene vista come non importante dal modello. Sfortunatamente, a volte a seconda del modello e della sua sensibilità, la significatività statistica delle correlazioni può cambiare in caso di piccoli cambiamenti nel sistema. Si tratta chiaramente di una questione di sensibilità, ma ci mostra che dobbiamo stare attenti quando utilizziamo questo tipo di analisi.
In secondo luogo, la mancata convergenza può essere utilizzata per rilevare guasti nel sistema. Questo è abbinato al numero di iterazioni che hanno avuto luogo nella piattaforma. Se vengono eseguite più di 1.000 iterazioni, l'analisi viene annullata e il modello non può convergere. Questa è una distinzione molto chiara tra i modelli in controllo e quelli a guasto, e in effetti quando l'ho scoperto per la prima volta, ho pensato che fornisse una distinzione molto chiara tra i dati in controllo e quelli fuori controllo. Ma fa proprio questo e soltanto quello, il che è lo svantaggio. Controllare se il modello è convergente ci dirà che c'è un errore da qualche parte, ma non dove o quando si è verificato. Il che, se il sistema non produce prodotti o sta subendo un guasto catastrofico, sarebbe abbastanza chiaro e non richiederebbe un SEM.
Pertanto, il metodo di rilevamento dei guasti che ritengo essere il migliore è osservare la modifica delle statistiche fornite dal rapporto di confronto dei modelli in un determinato periodo di tempo specificato dall'utente. Il modo più semplice per dimostrarlo è utilizzare il filtro dati locale in JMP insieme ai controlli di animazione.
Come puoi vedere dall'animazione sopra, ho aggiunto un filtro dati locale per dividere l'intero set di dati in 10 gruppi di 192 punti temporali. L'errore si verifica al punto dati 1120, ma è osservabile manualmente intorno alle 1130. In entrambi i casi, ciò significa che il guasto si verifica alla fine del gruppo 5 e gli effetti si osservano principalmente nei gruppi 6 e 7 prima che il sistema raggiunga un nuovo stato stazionario. Se osservate le statistiche di confronto su questi gruppi, potete vedere che dopo il gruppo 5 le statistiche cambiano rapidamente, il che indica un errore.
Tuttavia, alcune statistiche sono migliori di altre nel rilevare questo particolare guasto. Ad esempio, l'AICc cambia drasticamente su questi gruppi, il che ci dice che si è verificato un guasto. Ma l’AICc rende difficile identificare dove si è verificato specificamente questo errore poiché i principali cambiamenti in questo valore si verificano nel gruppo 7, molto tempo dopo che si è verificato l’errore. In questo caso, se non sapessi dov'è il guasto, probabilmente segnaleresti che il guasto si è verificato nel gruppo 7. Se invece osserviamo il CFI e l’RMSE sugli stessi gruppi, vediamo che questi valori iniziano a discostarsi in modo significativo dai valori di base non appena si verifica il guasto. L'RMSE in particolare sembra essere la metrica migliore per rilevare questo cambiamento, poiché nel gruppo 5 l'RMSE aumenta leggermente e poi nel gruppo 6 l'RMSE viene aumentato a livelli che indicano un errore nel modello. Una volta che il sistema ritorna allo stato stazionario dopo il guasto, l'RMSE ritorna al suo valore precedente al guasto. Di conseguenza, per questo particolare esempio, RMSE è la migliore metrica statistica su cui basare la nostra analisi, ma questa conclusione necessita di ulteriori test per vedere se questo risultato viene trovato per altri errori in altri set di dati.
Sopra ho fornito la stessa analisi di prima, ma mentre passo in rassegna i gruppi vengono forniti il SEM e le sue rispettive correlazioni. Nei gruppi 3 e 4 vediamo che le diverse correlazioni diventano statisticamente insignificanti proprio come le connessioni diventano insignificanti nei gruppi 5 e 6, dopo il guasto. Il problema qui è che è impossibile dire se l’errore si verifica nel gruppo 3 o nel gruppo 5 solo dal significato della correlazione. Questa mancanza di distinzione suggerisce tre possibilità: che questo SEM non sia adatto al sistema, che non ci siano abbastanza punti temporali per gruppo o che questo metodo per rilevare un guasto non sia adatto. Il mese prossimo esplorerò ulteriormente l’idea che il SEM stesso sia povero. Ma considerando le statistiche di confronto del SEM originale, è improbabile che il modello sia il problema. Invece, è probabile che il problema sia il metodo di rilevamento degli errori, poiché sapere se una correlazione è significativa o meno fornisce molte meno informazioni rispetto a diverse statistiche che forniscono valori quantitativi da confrontare.
Come si spera si possa vedere, il rilevamento del guasto attraverso le statistiche calcolate nella sezione di confronto dei modelli fornisce un quadro molto più chiaro di dove si verifica il guasto rispetto all'osservazione del solo significato delle correlazioni.
Conclusione/Ulteriore lavoro
Da questa esplorazione, dovresti essere in grado di vedere come sia possibile, anche se dispendioso in termini di tempo, creare SEM e utilizzarli per rilevare guasti in un sistema industriale reale. Tuttavia, ci sono ovviamente degli svantaggi con questa applicazione e con il modo specifico in cui ho creato i modelli. Il prossimo mese mi propongo di esplorare alcuni di questi inconvenienti e l’ambito in cui il SEM può essere utilizzato nei processi reali. In questa fase, una giusta conclusione è che il SEM può essere utilizzato nel rilevamento dei guasti ma solo come modello di base per determinate condizioni e non è completo.
Se qualcun altro ha avuto successo con il rilevamento dei guasti utilizzando SEM tramite un altro esempio o utilizzando un altro metodo per rilevare quando e dove si è verificato un guasto, lascia un commento qui sotto, sarei molto entusiasta di saperlo.
