El mes pasado , repasé el análisis preliminar requerido para comenzar a construir un SEM para el simulador Tennessee Eastman (un simulador de procesos químicos). Este análisis arrojó factores y correlaciones de factores 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 basados en el análisis preliminar para determinar que hemos encontrado un buen modelo para el sistema. En este caso, un modelo "bueno" sería uno 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 Pro JMP ventana de comparación de modelos.
Construyendo el SEM
Antes de entrar en la construcción del modelo, quiero brindarle una de mis tablas completas de comparación de modelos. Cada vez que mencione uno de los SEM en esta sección, me referiré a la siguiente tabla con el número de modelo correspondiente al modelo correcto. Hice esto para resaltar cuántos modelos es necesario crear para siquiera comenzar a obtener una idea de los datos, pero no planeo explicar cada uno de estos modelos, solo los más importantes.
Al crear los SEM, solo usé los datos de control. Una vez que se completó el modelo, apliqué el modelo a varios intervalos de tiempo para tratar de observar qué cambios ocurrieron. Para simplificar las cosas, hice el primer modelo utilizando solo dos factores con una covarianza entre los factores, ya que sabemos que estos factores probablemente estén relacionados (este es el modelo 5).
Vemos esto 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, es probable que una línea discontinua indique que la correlación entre esas variables no es necesaria en el modelo para que el modelo 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, usted puede recordar en mi publicación anterior Mencioné que un par de variables de manifiesto 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 se esté dando 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 un compresor es aumentar la presión, pero también produce calor en el proceso, lo que significa que es probable que afecte tanto a la temperatura como a los factores de presión (este es el modelo 9 de la tabla).
Comparando el modelo 5 con el modelo 9, vemos que el modelo 9 se desempeña mejor en cada métrica probada. No solo 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 puede notar en la tabla de comparación 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 una falla? Este es el quid de mi trabajo, por lo que destacaré un par de formas en las que descubrí que se podía detectar la falla y los pros y los contras de estos métodos de detección de fallas.
Para aquellos lectores agudos entre nosotros, es posible que hayan notado que aunque mencioné en mi última publicación que la falla fue un error en la relación de alimentación de A/C, ¡no hay variables manifiestas relacionadas con la relación de alimentación de A/C en el modelo! Cubriré más este punto el próximo mes a medida que aborde los problemas con este modelo, pero por ahora solo sepa que probé varias variables relacionadas con la relación A/C y descubrí que la adición que brindó las mejores estadísticas fue cuando la variable "A- Feed S1” fue agregado al modelo.
A continuación, he incluido las estadísticas de comparación de dos modelos con la variable A-Flow incluida. Como de costumbre, se dan los modelos no restringidos e independientes, 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 incluidos (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 las variables puede ser un indicador de que se está produciendo un error, ya que el modelo considera que esa conexión que debería ser importante ahora no lo es. Desafortunadamente, a veces, según su modelo y cuán sensible sea, la importancia estadística de las correlaciones puede cambiar con pequeños cambios en el sistema. Este es claramente un problema 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 bajo control y falla, y de hecho, cuando descubrí esto por primera vez, pensé que proporcionaba una distinción muy clara entre los datos bajo control y fuera de control. Pero hace justamente eso y sólo eso, que es el inconveniente. Verificar si el modelo ha convergido nos dirá que hay un error en alguna parte, pero no dónde o cuándo ocurrió. Lo cual, si el sistema no está produciendo un producto o está experimentando una 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 cierto período de tiempo especificado por el usuario. Para mí, la forma más fácil de demostrar esto es usar el Filtro de datos locales 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 toda la configuración de datos en 10 grupos de 192 puntos de tiempo. La falla ocurre en el punto de datos 1120, pero se puede observar manualmente alrededor de 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 sobre 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 esta falla en particular. Por ejemplo, el AICc cambia drásticamente sobre estos grupos, lo que nos dice que ha ocurrido una falla. Pero el AICc hace que sea difícil identificar dónde ocurrió específicamente esta falla ya que los principales cambios en este valor ocurren en el grupo 7, mucho después de que ocurrió la falla. En este caso, si no sabía 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 sobre 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 se incrementa a 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 previo 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, proporcioné el mismo análisis que antes, pero a medida que recorría los grupos, se dan 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 la importancia 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 próximo mes, exploraré más a fondo la idea de que el SEM en sí es pobre. Pero considerando las estadísticas de comparación del SEM original, es poco probable que el problema sea el modelo. En cambio, es probable que el método de detección de fallas sea el problema, ya que saber si una correlación es significativa o no proporciona mucha menos información que varias estadísticas que brindan valores cuantitativos para comparar.
Como puede ver, la detección de 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 solo la importancia de las correlaciones.
Conclusión/Trabajo Adicional
A partir de esta exploración, debería poder ver cómo es posible, aunque lleva mucho tiempo, crear SEM y usarlos para detectar fallas en un sistema industrial real. Sin embargo, obviamente hay inconvenientes con esta aplicación y la forma específica en que creé los modelos. El próximo mes, 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 usar en la detección de fallas, pero solo como un modelo básico para ciertas condiciones, no es completo.
Si alguien más ha tenido éxito con la detección de fallas utilizando SEM, ya sea a través de otro ejemplo o mediante el uso de otro método para detectar cuándo y dónde ocurrió una falla, deje un comentario a continuación, estaría muy emocionado de saberlo.
