El mes pasado , repasé el análisis preliminar necesario para comenzar a construir un SEM para el simulador Tennessee Eastman (un simulador de procesos químicos). Este análisis arrojó factores y correlaciones factoriales entre las variables manifiestas y los factores latentes, que pueden usarse como modelo de referencia para la comparación SEM. Sin embargo, como he mencionado en algunos de mis publicaciones anteriores , se deben crear y considerar otros modelos con base en el análisis preliminar para determinar que hemos encontrado un buen modelo para el sistema. En este caso, un modelo "bueno" sería aquel que pueda detectar fallas en el sistema sin señalar ningún problema en el tiempo de ejecución normal. Una de las principales formas en que evaluaré estos modelos es a través de las métricas estadísticas proporcionadas a través de JMPPro Ventana de comparación de modelos.
Construyendo el SEM
Antes de entrar en la construcción del modelo, quiero ofrecerles una de mis tablas de comparación de modelos completas. Siempre que mencione uno de los SEM en esta sección, consultaré la siguiente tabla con el número de modelo correspondiente al modelo correcto. He hecho esto para resaltar cuántos modelos es necesario crear para siquiera comenzar a tener una idea de los datos, pero no planeo explicar cada uno de estos modelos, solo los más importantes.
Al crear los SEM, solo utilicé los datos bajo control. Una vez que se completó el modelo, lo apliqué a varios intervalos de tiempo para intentar observar qué cambios ocurrieron. Para simplificar las cosas, hice el primer modelo usando solo dos factores con una covarianza entre los factores, ya que sabemos que estos factores probablemente estén relacionados (este es el modelo 5).
Esto lo vemos a través de las líneas continuas, que denotan significación estadística, y la línea discontinua, que denota una correlación estadísticamente significativa. Dado que nosotros mismos seleccionamos las correlaciones, una línea discontinua probablemente indique que la correlación entre esas variables no es necesaria en el modelo para que éste se ajuste bien a los datos. Por nuestro conocimiento del dominio, sabemos que debe haber una relación covariable entre estos factores (temperatura y presión), por lo que esto debería hacer sonar las alarmas sobre este modelo.
Sin embargo, tal vez recuerdes en mi publicación anterior Mencioné que un par de variables manifiestas basadas en el compresor no están tan correlacionadas con la presión como las otras variables. Entonces, en este punto, decidí agregar un tercer factor latente, llamarlo compresor y asignar las variables manifiestas previamente asociadas con la presión a este nuevo factor compresor. Como probablemente ya se habrá dado cuenta en este punto, es probable que todos nuestros factores latentes estén altamente correlacionados entre sí, por lo que en este modelo se agregó una covarianza entre todos los factores. En la práctica, esto tiene sentido ya que el trabajo de los compresores es aumentar la presión, pero también produce calor en el proceso, lo que significa que es probable que afecte tanto a nuestros factores de temperatura como a nuestros factores de presión (este es el modelo 9 en la tabla).
Al comparar el modelo 5 con el modelo 9, vemos que el modelo 9 funciona mejor en todas las métricas probadas. No sólo esto, sino que también vemos que todas nuestras covarianzas entre factores latentes ahora son estadísticamente significativas. Este es un resultado prometedor. También podrás notar en la tabla comparativa que tenemos muchos valores negativos; esto no es un problema. Se aplican las mismas reglas: los valores más bajos son mejores. Aquí puede ver que de los 12 modelos que creé, el modelo 9 es el "mejor" modelo estadísticamente.
Detección de fallas
Entonces, ahora que tenemos un modelo que parece ajustarse razonablemente bien a los datos y nos brinda correlaciones estadísticamente significativas cuando tenemos el control, es hora de hacer la gran pregunta: ¿Cómo nos muestra el SEM que hay un fallo? Este es el quid de mi trabajo, por lo que destacaré un par de formas en las que descubrí que se puede detectar la falla y los pros y los contras de estos métodos de detección de fallas.
Para aquellos lectores atentos entre nosotros, habrán notado que aunque mencioné en mi última publicación que la falla fue un error en la relación de alimentación del A/C, ¡no hay variables manifiestas relacionadas con la relación de alimentación del A/C en el modelo! Cubriré este punto más el próximo mes a medida que aborde los problemas con este modelo, pero por ahora solo sé que probé varias variables relacionadas con la relación A/C y descubrí que la suma que dio las mejores estadísticas fue cuando la variable "A- Se agregó Feed S1” al modelo.
A continuación he incluido las estadísticas de comparación para dos modelos con la variable A-Flow incluida. Como es habitual, se dan los modelos independientes y sin restricciones, junto con el modelo 3, que es un SEM sin conexiones de covarianza entre los factores latentes. El modelo 4 es el mismo SEM pero con la covarianza entre los factores latentes incluida (es más probable que este sea el modelo correcto).
Hay algunas formas en que se observan los cambios dentro del sistema. En primer lugar, la importancia de la conexión entre variables puede ser un indicador de que se está produciendo una falla, ya que el modelo ahora considera que esa conexión que debería ser importante no es importante. Desafortunadamente, a veces, dependiendo de su modelo y de su sensibilidad, la significancia estadística de las correlaciones puede cambiar ante pequeños cambios en el sistema. Se trata claramente de una cuestión de sensibilidad, pero nos muestra que debemos tener cuidado al emplear este tipo de análisis.
En segundo lugar, la falla de convergencia se puede utilizar para detectar fallas en el sistema. Esto se combina con la cantidad de iteraciones que han tenido lugar en la plataforma. Si se realizan más de 1000 iteraciones, el análisis se cancela y el modelo no puede converger. Esta es una distinción muy clara entre los modelos de control y de falla y, de hecho, cuando descubrí esto por primera vez, pensé que proporcionaba una distinción muy clara entre los datos de control y fuera de control. Pero hace precisamente eso y sólo eso, lo cual es el inconveniente. Verificar si el modelo ha convergido nos dirá que hay un error en alguna parte, pero no dónde ni cuándo ocurrió. Lo cual, si el sistema no está produciendo producto o está sufriendo alguna falla catastrófica, sería bastante claro y no requeriría un SEM.
Por lo tanto, el método de detección de fallas que creo que es el mejor es observar el cambio en las estadísticas proporcionadas por el informe de comparación de modelos durante un período de tiempo determinado, especificado por el usuario. Para mí, la forma más sencilla de demostrar esto es utilizar el filtro de datos local en JMP junto con los controles de animación.
Como puede ver en la animación anterior, agregué un filtro de datos locales para dividir todos los datos configurados en 10 grupos de 192 puntos de tiempo. La falla ocurre en el punto de datos 1120, pero se puede observar manualmente alrededor de las 1130. En cualquier caso, esto significa que la falla ocurre al final del grupo 5 y los efectos se ven principalmente en los grupos 6 y 7 antes de que el sistema alcance un nuevo estado estable. Si observa las estadísticas de comparación de estos grupos, puede ver que después del grupo 5 las estadísticas cambian rápidamente, lo que indica una falla.
Sin embargo, algunas estadísticas son mejores que otras para detectar este fallo en particular. Por ejemplo, el AICc cambia drásticamente en estos grupos, lo que nos indica que ha ocurrido una falla. Pero el AICc dificulta identificar dónde se ha producido específicamente esta falla, ya que los principales cambios en este valor ocurren en el grupo 7, mucho después de que ocurriera la falla. En este caso, si no supiera dónde estaba la falla, probablemente informaría que la falla ocurrió en el grupo 7. Mientras que si observamos el CFI y el RMSE en los mismos grupos, vemos que estos valores comienzan a desviarse significativamente de sus valores de referencia tan pronto como ocurre la falla. El RMSE en particular parece ser la mejor métrica para detectar este cambio, ya que en el grupo 5 el RMSE aumenta ligeramente y luego en el grupo 6 el RMSE aumenta hasta niveles que indican un error en el modelo. Una vez que el sistema vuelve a un estado estable después de la falla, el RMSE vuelve a su valor anterior a la falla. En consecuencia, para este ejemplo en particular, RMSE es la mejor métrica estadística para basar nuestro análisis, pero esta conclusión necesita más pruebas para ver si este resultado se encuentra para otras fallas en otros conjuntos de datos.
Arriba he proporcionado el mismo análisis que antes, pero a medida que recorro los grupos se proporciona el SEM y sus respectivas correlaciones. En los grupos 3 y 4, vemos que diferentes correlaciones se vuelven estadísticamente insignificantes de la misma manera que las conexiones se vuelven insignificantes en los grupos 5 y 6, después de la falla. El problema aquí es que es imposible saber si la falla ocurre en el grupo 3 o en el grupo 5 solo por el significado de la correlación. Esta falta de distinción sugiere tres posibilidades: que este SEM no sea bueno para el sistema, que no haya suficientes puntos de tiempo por grupo o que este método de detección de fallas no sea bueno. El mes que viene exploraré más a fondo la idea de que el propio SEM es pobre. Pero considerando las estadísticas comparativas del SEM original, es poco probable que el modelo sea el problema. En cambio, es probable que el problema sea el método de detección de fallos, ya que saber si una correlación es significativa o no proporciona mucha menos información que varias estadísticas que nos dan valores cuantitativos para comparar.
Como puede ver, detectar la falla a través de las estadísticas calculadas en la sección de comparación de modelos brinda una imagen mucho más clara de dónde ocurre la falla en lugar de observar únicamente la importancia de las correlaciones.
Conclusión/Trabajo adicional
A partir de esta exploración, debería poder ver cómo es posible, aunque lleve mucho tiempo, crear SEM y utilizarlos para detectar fallas en un sistema industrial real. Sin embargo, obviamente existen inconvenientes con esta aplicación y la forma específica en que creé los modelos. El mes que viene, mi objetivo es explorar algunos de estos inconvenientes y el alcance en el que se puede utilizar SEM en procesos reales. En esta etapa, una conclusión justa es que SEM se puede utilizar en la detección de fallas, pero sólo como modelo básico para ciertas condiciones, no es exhaustivo.
Si alguien más ha tenido éxito en la detección de fallas usando SEM, ya sea a través de otro ejemplo o usando otro método para detectar cuándo y dónde ocurrió una falla, envíe un comentario a continuación, me encantaría saberlo.
