¿Ideas para el seguimiento DOE para datos de STMicro?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Buscando algunas ideas para un DOE plausible de seguimiento para el conjunto de datos STMicroelectronic. Esto estaría en el tema de "Minería de datos que permite un DOE más productivo / DOE holístico".
El conjunto de datos se adjunta. Básicamente si vas A través del enfoque holístico del DOE de Explorar / Pantalla / Experimento, encontrará que hay un puñado de pruebas paramétricas importantes que se correlacionan con la respuesta: error logBin10. El Bootstrap Forest con información faltante le permite examinar rápidamente los 606 parámetros de PT y encontrar los que mejor caracterizan la presencia del modo de falla dominante.
También hay una variable dividida en el conjunto de datos, que es un equipo utilizado para fabricar estos chips. Y lo que ves es que la división también está relacionada con el fracaso.
Por lo tanto, a partir de estos datos, tenemos un conjunto de parámetros de PT que se relacionan con el BIN de falla principal, que es útil para los ingenieros, ya que los PT se realizan al principio del proceso fabuloso y pueden dar una advertencia temprana a los chips, lo que fallará en el tipo de oblea eléctrica. (Y debido a la minería de datos que acabamos de realizar, solo necesitan monitorear los valores de 4-5 de estos parámetros para tener una buena idea de las posibles fallas).
Pero parece que hay más oportunidades de aprender aquí, y este ejercicio de minería de datos debería conducir a un experimento más controlado donde la organización pueda entender mejor lo que está sucediendo. Si la división está causando problemas en el proceso de fabricación, ¿qué otra cosa podría funcionar aquí?
Parece que la extracción de datos se basa en los síntomas y tal vez no en la causa raíz del proceso de fabricación. ¿Pero no querría configurar un DOE de seguimiento utilizando los parámetros de PT como factores necesariamente, o lo haría? ¿Tendría eso sentido fabricar a propósito chips que estarían leyendo bajo o alto en los PT para provocar el fallo en el EWS? Si modifica estos PT de forma sistemática, podrá verificar la causa y el efecto en lugar de simplemente extraer los datos de producción.
Basados en el bosque de Bootstrap, aquí están los dos dominan las relaciones PT-EWS, con 164 y 451:
Combinado con la división, que también nos gustaría probar, podemos configurar un diseño personalizado. Este sería el diseño que se ejecuta para los dos PT y la división:
Supongo que hay muchos otros factores que pueden estar afectando la falla de BIN10 que vale la pena explorar, la receta de deposición, el proveedor de materia prima, la velocidad de grabado, etc. El objetivo aquí sería crear un diseño plausible de seguimiento que tenga sentido en un contexto DOE basado en datos. Aprecio los pensamientos y ayuda.
Re: Ideas para el seguimiento ¿DOE para datos de STMicro?Gracias, Robert! Espero su caso también. Eso será un buen complemento para el caso ST que ya tenemos. Scott y yo tuvimos nuestro primer evento Holistic DOE en Denver la semana pasada (2 de octubre.) y presenté este caso ST con el DOE de seguimiento que se describe anteriormente. Pareció ir bien (de hecho, alguien en la audiencia antes de configurar el DOE dijo: "¡Apuesto a que es el paso de grabado!").
Parecía estar bien con el hecho de que Spilled es 4 máquinas diferentes. Me centré solo en el Split 3, que tuvo la respuesta más interesante y variada (los Splits 1 y 2 tuvieron fallas bajas de Bin10, Spilled 4 tuvo todas las fallas altas, lo que expliqué podría ser un dispositivo defectuoso que debería investigarse).
No es perfecto, pero parecía plausible para la audiencia. Todavía quiero refinar el caso un poco más a medida que recibo más comentarios. Veremos cómo pasa el resto de los eventos que tenemos este mes.
Re: Ideas para el seguimiento ¿DOE para datos de STMicro?
He estado viendo mi semi demo de nuevo y hay algunos problemas con los que actualmente estoy tratando de solucionar. El problema principal es que puede obtener la misma respuesta utilizando la funcionalidad JMP estándar en lugar de Pro. El uso de JMP estándar no es tan sencillo como usar Pro, pero incluso con Pro, necesitaba una secuencia de comandos para recorrer las diferentes columnas de validación para lograr un resultado confiable. La clave que ilustra mi demostración parcial es la importancia de utilizar la validación si desea suprimir los falsos positivos. Si logro superar los problemas con la demostración parcial, la pondré a disposición.
En el informe técnico de ST no estoy seguro de qué son las divisiones S1, S2, S3 y S4. No creo que sean máquinas diferentes. Suenan más como un "experimento" en el que han variado deliberadamente (o accidentalmente) una configuración o parámetro de proceso.
También noté en el informe técnico de ST que eligen el parámetro 171 como el parámetro más significativo para usar en lugar de 451. Sospecho que la razón de esto es que tienen una mejor comprensión de qué es el parámetro 171 y cómo se vincularía a una configuración de proceso o característica de rendimiento del dispositivo, por ejemplo, 171 podría ser una medida de ancho de línea eléctrica que puedan relacionarse directamente con una dimensión física que se miden en línea en un paso particular. Mientras que, 451 podría ser una corriente de fuga que tenga una relación menos obvia con esa dimensión física.
En términos de un experimento de seguimiento, un proceso de grabado en seco que sea el problema resuena bien en la mayoría de las audiencias de semiconductores. Los procesos de grabado en seco a menudo son problemáticos, pero también se prestan bien a la investigación del DoE. Tienen muchos factores que pueden ser variados y, a menudo, el ingeniero de procesos no tendrá una buena comprensión cuantitativa de cómo estos factores interactúan entre sí y afectan el proceso.
Un buen conjunto de factores podría ser: potencia de RF, potencia de polarización, presión de la cámara, temperatura del mandril. Helio BSC (enfriamiento trasero). Sé de dos problemas de rendimiento diferentes que fueron causados por la temperatura de Chuck y los problemas de He BSC debido a las diferencias de calibración entre las cámaras de grabado. También sugeriría realizar el experimento tanto en una cámara "buena" como en una "mala".
Los problemas de rendimiento en los semiconductores a menudo exhiben un patrón espacial en las obleas, como se muestra en el siguiente ejemplo y como la firma de "sonrisa" que se menciona en el informe técnico de ST. Esos patrones pueden ser pistas importantes para los ingenieros a la hora de descubrir qué ha fallado.
Re: Ideas para el seguimiento ¿DOE para datos de STMicro?Esta es una gran mejora y estoy seguro de que alguien con una formación más profunda en la industria semi puede guiarlo en los factores y rangos a utilizar en el DSD propuesto para el proceso de grabado.
Si parte de la audiencia objetivo para esta demostración son usuarios de JMP existentes, le animo a que piense cómo demostrar que el flujo de trabajo propuesto en Pro es más simple y da como resultado una solución potencialmente mejor que JMP. Por ejemplo, si usa Fit Y por X para obtener un análisis bivariado del registro (bin10) frente a cada X y luego genera las estimaciones de los parámetros en una tabla de datos combinados, elimine los términos de intercepción de la tabla combinada y luego clasifíquelos por el valor de p ascendente. obtener los seis parámetros principales siendo 26, 451, 183, 2, 47, 164. Por lo tanto, parece que no sería demasiado difícil llegar a la misma conclusión con JMP con un flujo de trabajo potencialmente más sencillo porque no debemos preocuparnos por la cantidad de árboles en el bosque. ¿Tal vez necesitamos modificar los datos de ST para inducir algunos efectos de interacción fuertes que se perderían con el enfoque Fit Y por X pero que serían capturados fácilmente por Bootstrap Forest? Si parte del público objetivo son usuarios de JMP existentes, creo que debemos estar preparados para demostrar que no pueden recrear la solución fácilmente en JMP.
Alternativamente, podría usar la demostración parcial que Robert creó cuando se lanzó Pro por primera vez, que mostraba cómo Pro detectó la causa de un problema que se debió a un efecto de intección de tres vías que se perdió por la aproximación Ajustar Y por X. Luego, podría basar el experimento de seguimiento en torno a los tres pasos de proceso adyacentes que interactuaron para causar el problema. Le pediré a Robert que te envíe su demo.
Malcolm
Re: Ideas para el seguimiento ¿DOE para datos de STMicro?Hola Malcolm - Gracias por la respuesta. Re: la tabla de datos, le daré crédito a Ian por eso. Hizo un gran trabajo al armar los guiones y también un video corto para una campaña de marketing. Simplemente estoy construyendo sobre eso en el contexto holístico del DOE.
A sus puntos específicos:
1) Semilla aleatoria: por 1.000 árboles, las cosas se han establecido y los resultados son repetibles: 26, 451, 164 y 171 son los 4 primeros. Estos 4 mejores permanecen ahora incluso cuando se ejecuta Bootstrap Forest una y otra vez. Así que ese es un buen cambio que se debe hacer.
2) 164 es complicado porque va en la dirección equivocada y parece tener un comportamiento diferente en comparación con 26, 451 y 171. Otra buena adición que agregaré es la agrupación de variables, que muestra que el valor promediado de 451 explica el 71% de la variación en los datos.
Así que creo que esas dos cuestiones están ordenadas. Así que las conclusiones del ejercicio de minería de datos son así:
1) Utilizamos un Bootstrap Forest y PCA para encontrar una asociación clave entre el resultado de la prueba paramétrica más representativa (451) y la falla de Bin10.
2) También encontramos que la variable split indica que la falla puede deberse a un equipo (Split 3 y Split 4), lo que está causando que la prueba paramétrica sea alta en el rango que causa la falla bin10.
3) Armados con estos datos, podemos volver a los ingenieros con el promedio de la prueba paramétrica como respuesta (451_Param_average) y diseñar un DOE para investigar el paso de grabado en el equipo de la división 3.
En cuanto a la simulación de los datos, sé aproximadamente en qué rango debería estar este parámetro y podemos averiguar cuál sería la tasa de falla de Bin10 para el nivel 451.
Así que solo necesito un conjunto plausible de entradas y niveles para el diseño de seguimiento.
Tal vez un DSD de 5 factores:
Con datos simulados para ver algo como esto cuando encajan:
Por lo tanto, la historia aquí puede ser cualquier cosa sobre la máquina, tal vez piezas o sensores defectuosos o desgastados que causan una velocidad de inmersión intermitente o velocidades de alimentación promedio (no presentes en las otras divisiones, que funcionan según las especificaciones). alto promedio de param que causa la prosperidad por un alto fracaso bin10.
No estoy casado con esta historia, pero podría funcionar si las personas más inteligentes que yo en esta área creen que podría ser plausible. Una vez más, apreciar pensamientos y comentarios.
Re: Ideas para el seguimiento ¿DOE para datos de STMicro?Hola dan
La tabla de datos para el análisis de datos históricos está bien documentada con las secuencias de comandos que explican el proceso y los tipos de medición y ofrece una gran línea de historia, una que los SE podrían replicar y entregar fácilmente dentro de las industrias de semiconductores y otras. Obtenemos el problema habitual con la semilla aleatoria utilizada para el bosque de arranque con diferentes soluciones, por ejemplo, en el segundo intento obtuve 164_PARAM_AVERAGE como el principal predictor de registro (Bin10) y esto no está incluido en el resto del flujo de demostración. Necesitamos arreglar esto para dar resultados consistentes. Podríamos establecer la semilla aleatoria en el script para el bosque de arranque, pero me gustaría evitar eso si es posible porque ya no podemos mostrar el diálogo para el bosque de arranque. ¿Es posible probar un mayor número de árboles en el bosque para ver si eso soluciona el problema o incluso un árbol reforzado?
Como sugiere, las pruebas paramétricas son síntomas en lugar de causas del problema y me pregunto si un próximo DOE más realista sería centrarse en los pasos del proceso responsables de cada una de las cuatro fallas de pruebas paramétricas. Robert podría guiarlo en esto, pero espero que un DOE más creíble esté en uno de los pasos de etch con la trama de que es el paso de etch el responsable de la característica que está causando el alto valor de la prueba paramétrica y la alta prueba paramétrica valor está causando la falla bin10.
Malcolm
