Des idées pour le suivi du DOE pour les données STMicro?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Vous recherchez des idées pour un DOE de suivi plausible pour l'ensemble de données STMicroelectronic. Ce serait dans le thème de "l'exploration de données permettant une DOE plus productive / holistique DOE."
L'ensemble de données est joint. En gros si vous y allez Grâce à l’approche holistique DOE de Explore / Screen / Experiment, vous découvrez qu’il existe une poignée de tests paramétriques importants en corrélation avec la réponse: échec de logBin10. La forêt de démarrage avec des informations manquantes vous permet de parcourir rapidement les paramètres 606 PT et de trouver ceux qui caractérisent le mieux la présence du mode de défaillance dominante.
Il existe également une variable scindée dans le jeu de données, qui est un équipement utilisé pour la fabrication de ces puces. Et ce que vous voyez, c'est que la scission est également liée à l'échec.
Ainsi, à partir de ces données, nous obtenons un ensemble de paramètres PT liés au BIN de défaillance principale, ce qui est utile aux ingénieurs car les PT sont utilisés tôt dans le processus de fabrication et peuvent alerter de manière anticipée les puces, qui échouent au tri électrique des tranches. (Et en raison de l’exploration de données que nous venons de mener, il suffit de surveiller les valeurs de 4 à 5 de ces paramètres pour avoir une bonne idée des défaillances probables).
Mais il semble qu'il y ait plus d'opportunités d'apprentissage ici, et cet exercice d'exploration de données devrait bien mener à une expérience plus contrôlée, permettant à l'organisation de mieux comprendre ce qui se passe. Si la scission pose des problèmes dans le processus de fabrication, quoi d'autre pourrait être à l'œuvre ici?
Il semble que l'exploration de données porte peut-être sur les symptômes et non sur la cause fondamentale du processus de fabrication. Mais vous ne voudriez pas créer un DOE de suivi en utilisant les paramètres PT comme facteurs nécessairement, ou le feriez-vous? Cela serait-il judicieux de fabriquer à dessein des puces dont la lecture est faible ou élevée sur les PT afin de déclencher l'échec du SAP? Si vous modifiez systématiquement ces PT, vous serez en mesure de vérifier les causes et les effets plutôt que de simplement extraire les données de production.
Sur la base de la forêt bootstrap, voici les deux relations dominantes PT-EWS, avec 164 et 451:
En combinaison avec la scission que nous aimerions également tester, nous pouvons configurer une conception personnalisée. Ce sont les cycles de conception pour les deux PT et la scission:
Je suppose que de nombreux autres facteurs susceptibles d’avoir une incidence sur la défaillance de BIN10 méritent d’être explorés: recette de dépôt, fournisseur de matière première, vitesse de gravure, etc. L'objectif ici serait de créer une conception de suivi plausible qui aurait du sens dans un contexte de DOE basé sur des données. J'apprécie les pensées et l'aide.
Re: Des idées pour le suivi du DOE pour les données STMicro?Merci Robert! J'attends votre cas avec impatience. Ce sera un bon complément à l’affaire ST que nous avons déjà. Scott et moi avons organisé notre premier événement holistique DOE à Denver la semaine dernière (le 2 octobre).) et j’ai présenté ce cas ST avec le DOE de suivi décrit ci-dessus. Cela semblait aller bien (en fait, avant l’installation du DOE dans le public, quelqu'un a dit: "Je parie que c’est le pas de la gravure!").
Le semblait être OK avec le fait que Spilled est 4 machines différentes. Je me suis concentré uniquement sur le Split 3, qui a eu la réponse la plus intéressante et la plus variée (les Splits 1 et 2 ont eu de faibles échecs Bin10, Spilled 4 a eu tous des échecs élevés, ce qui, j’ai expliqué, pourrait être un appareil défectueux sur lequel il faudrait enquêter).
Ce n'est pas parfait, mais cela semblait plausible au public. Je veux encore affiner le cas un peu plus car je reçois plus de commentaires. Nous verrons comment cela se passe pour le reste des événements de ce mois-ci.
Re: Des idées pour le suivi du DOE pour les données STMicro?
J'ai regardé ma démo à nouveau et il y a quelques problèmes que j'essaye actuellement de résoudre. Le principal problème est que vous pouvez obtenir la même réponse en utilisant les fonctionnalités JMP standard plutôt que Pro. L'utilisation de JMP standard n'est pas aussi simple que d'utiliser Pro. Même avec Pro, j'avais besoin d'un script pour parcourir différentes colonnes de validation afin d'obtenir un résultat fiable. L’essentiel de ma demi-démo est l’importance de l’utilisation de la validation si vous souhaitez supprimer les faux positifs. Si je parviens à surmonter les problèmes avec la démo semi, je le rendrai disponible.
Dans le livre blanc ST, je ne suis pas sûr de ce qui sépare S1, S2, S3 et S4. Je ne pense pas que ce sont des machines différentes. Ils ressemblent davantage à une "expérience" dans laquelle ils ont délibérément (ou accidentellement) modifié un paramètre ou un processus.
Je remarque également dans le livre blanc de ST qu'ils ont choisi le paramètre 171 comme étant le paramètre le plus significatif à utiliser plutôt que le paramètre 451. Je suppose que la raison en est qu’ils ont une meilleure compréhension du paramètre 171 et de la manière dont il serait lié à un paramètre de processus ou à une caractéristique de performance du dispositif, par exemple 171 pourrait être une mesure de largeur de ligne électrique qu’ils peuvent directement associer à une dimension physique. ils mesurent en ligne à une étape particulière. Considérant que 451 pourrait être un courant de fuite qui a une relation moins évidente à cette dimension physique.
En termes d'expérience de suivi, un processus de gravure sèche étant le problème, il résonnerait bien auprès de la plupart des utilisateurs de semi-conducteurs. Les procédés de gravure sèche posent souvent des problèmes, mais se prêtent également bien aux investigations de DoE. Ils ont de nombreux facteurs qui peuvent être variés et souvent, l'ingénieur de procédé n'aura pas une bonne compréhension quantitative de la façon dont ces facteurs interagissent les uns avec les autres et affectent le processus.
Un bon ensemble de facteurs pourrait être: puissance RF, puissance polarisée, pression de la chambre, température du mandrin. Helium BSC (refroidissement par l'arrière). Je connais deux problèmes de rendement différents dus à la température de Chuck et au problème de BSC He dus à des différences d'étalonnage entre les chambres de gravure. Je suggérerais également de mener l'expérience à la fois sur une "bonne" et une "mauvaise" chambre.
Les problèmes de rendement dans les semi-conducteurs présentent souvent un motif spatial sur les tranches, comme indiqué dans l'exemple ci-dessous, à l'instar de la signature de «sourire» mentionnée dans le livre blanc de ST. Ces schémas peuvent constituer des indices importants pour les ingénieurs afin de déterminer ce qui ne va pas.
Re: Des idées pour le suivi du DOE pour les données STMicro?C'est une grande amélioration et je suis sûr que quelqu'un ayant une expérience plus approfondie dans l'industrie du semi peut vous guider dans les facteurs et les gammes à utiliser dans le DSD proposé pour le processus de gravure.
Si une partie du public cible de cette démonstration est constituée des utilisateurs JMP existants, je vous encourage à réfléchir à la manière dont vous démontrez que le flux de travail proposé dans Pro est plus simple et donne une solution potentiellement meilleure que JMP. Par exemple, si vous utilisez Ajuster Y par X pour obtenir une analyse à deux variables de log (bin10) vs chaque X, puis exportez les estimations de paramètres dans une table de données combinée, supprimez les termes d'interception de la table combinée, puis triez par valeur p ascendante. obtenir les six paramètres principaux étant 26, 451, 183, 2, 47, 164. Il semble donc qu'il ne serait pas trop difficile de parvenir à la même conclusion avec JMP avec un flux de travail potentiellement plus simple, car nous n'avons pas à nous soucier du nombre d'arbres dans la forêt. Peut-être devrions-nous modifier les données ST afin d’induire des effets d’interaction importants qui seraient omis par l’approche Fit Y by X mais qui seraient facilement capturés par Bootstrap Forest? Si une partie du public cible est constituée d’utilisateurs JMP existants, je pense que nous devons être prêts à montrer qu’ils ne peuvent pas recréer facilement la solution dans JMP.
Vous pouvez également utiliser la demi-démo créée par Robert lors de la première sortie de Pro, qui montre comment Pro a détecté la cause d’un problème dû à un effet d’intection à trois voies qui avait été omis par l’approche Fit Y par X ci-dessus. Vous pouvez ensuite baser l'expérience de suivi sur les trois étapes de processus adjacentes qui interagissaient pour provoquer le problème. Je demanderai à Robert de vous faire parvenir sa démo.
Malcolm
Re: Des idées pour le suivi du DOE pour les données STMicro?Bonjour Malcolm - Merci pour la réponse. Re: le tableau de données, je vais donner crédit à Ian pour cela. Il a fait un excellent travail en assemblant les scripts et une courte vidéo pour une campagne de marketing. Je ne fais que construire sur cela dans le contexte holistique du DOE.
Pour vos points spécifiques:
1) Graine aléatoire - Par 1 000 arbres, les choses se sont stabilisées et les résultats sont reproductibles - 26, 451, 164 et 171 se classent parmi les 4 meilleurs. Ces 4 premiers restent maintenant même lorsque vous exécutez la forêt Bootstrap encore et encore. C'est donc un bon changement à faire.
2) 164 est délicat car il va dans la mauvaise direction et semble avoir un comportement différent par rapport à 26, 451 et 171. Un autre ajout intéressant que je vais ajouter est la classification variable, qui montre que 71% de la variation dans les données est expliquée par le paramètre 451 param moy.
Je pense donc que ces deux problèmes sont triés. Les conclusions de l’exploration de données sont donc les suivantes:
1) Nous avons utilisé une forêt d'amorçage et une ACP pour trouver une association de clé entre le résultat du test paramétrique le plus représentatif (451) et la défaillance Bin10.
2) Nous avons également constaté que la variable fractionnée indique que la défaillance peut être due à un équipement (Séparation 3 et Séparation 4), ce qui provoque un test paramétrique trop élevé dans la plage entraînant la défaillance de bin10.
3) Forts de ces faits, nous pouvons revenir aux ingénieurs avec la moyenne de test paramétrique comme réponse (451_Param_average) et concevoir un DOE pour étudier l’étape de gravure sur l’équipement divisé 3.
En ce qui concerne la simulation des données, je sais approximativement dans quelle plage ce paramètre devrait être et nous pouvons en quelque sorte déterminer le taux d'échec de Bin10 pour le niveau 451.
J'ai donc juste besoin d'un ensemble plausible d'entrées et de niveaux pour la conception suivante.
Peut-être un DSD à 5 facteurs:
Avec des données simulées pour ressembler à ceci quand bon vous semble:
Ainsi, l’histoire peut concerner la machine - des pièces / capteurs usés ou défectueux entraînant une vitesse d’immersion intermittente ou des vitesses d’alimentation moyennes (absentes des autres fractionnements fonctionnant dans les spécifications), ce qui pourrait entraîner haute param moyenne causant la prospérité pour un échec bin10 élevé.
Pas marié à cette histoire, mais ça pourrait marcher si des gens plus intelligents que moi dans ce domaine pensaient que c'était plausible. Encore une fois, appréciez les pensées et les commentaires.
Re: Des idées pour le suivi du DOE pour les données STMicro?Bonjour Dan
Le tableau de données pour l'analyse des données historiques est bien documenté avec des scripts expliquant les processus et les types de mesure, et donne une grande histoire, une histoire que nous, SE, pouvons reproduire et fournir facilement dans les industries des semi-conducteurs et autres. Le problème habituel est que la graine aléatoire utilisée pour la forêt bootstrap donne différentes solutions. Par exemple, lors du deuxième essai, 164_PARAM_AVERAGE est le principal prédicteur de log (Bin10), ce qui n'est pas inclus dans le reste du flux de démonstration. Nous devons résoudre ce problème pour obtenir des résultats cohérents. Nous pourrions définir une graine aléatoire dans le script pour la forêt d'amorçage, mais j'aime éviter cela autant que possible, car nous ne pouvons plus afficher le dialogue pour la forêt d'amorçage. Est-il possible d'essayer un plus grand nombre d'arbres en forêt pour voir si cela résout le problème ou même un arbre boosté?
Comme vous le suggérez, les tests paramétriques sont des symptômes plutôt que des causes du problème et je me demande si un prochain DOE plus réaliste consisterait à se concentrer sur les étapes de processus responsables de chacun des quatre échecs de tests paramétriques. Robert pourrait vous guider dans ce sens, mais je suppose qu'un DOE plus crédible pourrait figurer sur l'une des étapes de gravure avec le scénario: c'est l'étape de gravure qui est responsable de la fonctionnalité qui est à l'origine de la valeur de test paramétrique élevé et du test paramétrique élevé la valeur est à l'origine de l'échec bin10.
Malcolm
