Lo scorso mese , ho esaminato l'analisi preliminare necessaria per iniziare a costruire un SEM per il simulatore Tennessee Eastman (un simulatore di processo chimico). 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 accennato in alcuni di i miei post precedenti , altri modelli devono essere creati e considerati sulla base dell'analisi preliminare per determinare che 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 runtime. Uno dei modi principali in cui valuterò questi modelli è attraverso le metriche statistiche fornite JMP Pro la finestra di confronto dei modelli.
Costruire il SEM
Prima di entrare nella costruzione del modello, voglio fornirti una delle mie tabelle complete di confronto dei modelli. Ogni volta che menzionerò 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 per iniziare anche a ottenere un'idea dei dati, ma non ho intenzione di spiegare ciascuno di questi modelli, solo il più importante.
Durante la creazione dei SEM, ho utilizzato solo i dati di controllo. Una volta completato il modello, ho applicato il modello a vari intervalli di tempo per cercare di osservare quali modifiche si sono verificate. 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 di covariata tra questi fattori (temperatura e pressione), quindi questo dovrebbe far scattare campanelli d'allarme su questo modello.
Tuttavia, potresti ricordare il mio post precedente Ho detto che un paio di variabili manifest basate sul compressore non sono correlate con la pressione come le altre variabili. Quindi, a questo punto, ho deciso di aggiungere un terzo fattore latente, chiamarlo compressore e assegnare le variabili manifest precedentemente associate alla pressione a questo nuovo fattore di compressione. Poiché probabilmente a questo punto stai capendo, è probabile che tutti i nostri fattori latenti siano altamente correlati tra loro, quindi in questo modello è stata aggiunta una covarianza tra tutti i fattori. Praticamente questo ha senso poiché il lavoro di un compressore è aumentare la pressione, ma produce anche calore nel processo, il che significa che è probabile che influenzi sia i nostri fattori di temperatura che 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 metrica testata. Non solo questo, ma vediamo anche che tutte le nostre covarianze tra fattori latenti sono ora statisticamente significative. Questo è un risultato promettente. Potresti anche notare nella tabella di confronto che abbiamo molti valori negativi; questo non è un problema. Si applicano le stesse regole: valori più bassi sono migliori. Qui puoi vedere, dei 12 modelli che ho creato, il modello 9 è statisticamente il modello "migliore".
Rilevamento guasti
Quindi ora che abbiamo un modello che sembra adattarsi ragionevolmente bene ai dati e ci fornisce correlazioni statisticamente significative quando abbiamo il controllo, è il momento di porre la grande domanda: In che modo il SEM ci mostra che c'è un errore? Questo è il punto cruciale del mio lavoro, quindi evidenzierò un paio di modi in cui ho scoperto che l'errore potrebbe essere rilevato e i pro ei contro di questi metodi di rilevamento degli errori.
Per quei lettori attenti tra noi, potresti aver notato che sebbene nel mio ultimo post ho menzionato che l'errore era un errore nel rapporto di alimentazione A/C, nel modello non ci sono variabili manifeste relative al rapporto di alimentazione A/C! Tratterò questo punto in modo più approfondito 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 ha fornito le statistiche migliori è stata quando la variabile "A- Feed S1” è stato aggiunto al modello.
Di seguito ho incluso le statistiche di confronto per due modelli con la variabile A-Flow inclusa. 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 la covarianza tra i fattori latenti inclusi (è 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, il significato della connessione tra variabili può essere un indicatore di un guasto che si verifica poiché quella connessione che dovrebbe essere importante è ora vista come non importante dal modello. Sfortunatamente, a volte a seconda del tuo modello e della sua sensibilità, la significatività statistica delle correlazioni può cambiare in base a piccole modifiche nel sistema. Questo è chiaramente un problema di sensibilità, ma ci mostra che dobbiamo stare attenti quando utilizziamo questo tipo di analisi.
In secondo luogo, l'errore di convergenza può essere utilizzato per rilevare i guasti nel sistema. Questo è abbinato al numero di iterazioni che hanno avuto luogo nella piattaforma. Se vengono eseguite oltre 1.000 iterazioni, l'analisi viene annullata e il modello non può convergere. Questa è una distinzione molto chiara tra i modelli in-control e fault, e infatti quando l'ho scoperto per la prima volta, ho pensato che fornisse una distinzione molto chiara tra i dati in-control e out of control. Ma fa proprio questo e solo quello, che è lo svantaggio. Il controllo 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 sta producendo prodotto o sta subendo un guasto catastrofico, sarebbe abbastanza chiaro e non richiederebbe un SEM.
Pertanto, il metodo di rilevamento dei guasti che ritengo il migliore è osservare il cambiamento nelle statistiche fornite dal rapporto di confronto del modello in un determinato periodo di tempo specificato dall'utente. Il modo più semplice per dimostrarlo è utilizzare il filtro dati locali in JMP insieme ai controlli di animazione.
Come puoi vedere attraverso l'animazione sopra, ho aggiunto un filtro dati locali 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 a circa 1130. In entrambi i casi, ciò significa che il guasto si verifica alla fine del gruppo 5 con gli effetti osservati principalmente nei gruppi 6 e 7 prima che il sistema raggiunga un nuovo stato stazionario. Se osservi le statistiche di confronto su questi gruppi, puoi 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 difetto. Ad esempio, l'AICc cambia radicalmente su questi gruppi, il che ci dice che si è verificato un guasto. Ma l'AICc rende difficile identificare dove si è verificato questo errore in particolare poiché le principali modifiche di questo valore si verificano nel gruppo 7, molto tempo dopo che si è verificato l'errore. In questo caso, se non sapessi dove si trova l'errore, è probabile che riferisca che l'errore si è verificato nel gruppo 7. Considerando che se osserviamo CFI e RMSE sugli stessi gruppi, vediamo che questi valori iniziano a deviare in modo significativo dai loro valori di base non appena si verifica l'errore. L'RMSE in particolare sembra essere la metrica migliore per rilevare questo cambiamento, poiché nel gruppo 5 l'RMSE aumenta leggermente e quindi nel gruppo 6 l'RMSE viene aumentato a livelli che indicano un errore nel modello. Una volta che il sistema torna a uno stato stabile dopo il guasto, l'RMSE torna al 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 scorro i gruppi vengono forniti il SEM e le sue rispettive correlazioni. Nei gruppi 3 e 4, vediamo che diverse correlazioni diventano statisticamente insignificanti proprio nello stesso modo in cui 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 è buono per il sistema, non ci sono punti temporali sufficienti per gruppo o che questo metodo di rilevamento di un guasto non è buono. 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 metodo di rilevamento dei guasti sia il problema poiché il fatto di sapere se una correlazione è significativa o meno fornisce molte meno informazioni rispetto a diverse statistiche che forniscono valori quantitativi da confrontare.
Come si spera, rilevare il guasto attraverso le statistiche calcolate nella sezione di confronto del modello fornisce un quadro molto più chiaro di dove si verifica il guasto invece di osservare il significato delle sole correlazioni.
Conclusione/ulteriori lavori
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 vero sistema industriale. Tuttavia, ci sono ovviamente degli svantaggi con questa applicazione e 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. A questo punto, una conclusione equa è che il SEM può essere utilizzato nel rilevamento dei guasti ma solo come modello di base per determinate condizioni, non è completo.
Se qualcun altro ha avuto successo con il rilevamento degli errori utilizzando SEM tramite un altro esempio o utilizzando un altro metodo per rilevare quando e dove si è verificato un errore, lasciare un commento di seguito, sarei molto entusiasta di sentirlo.
