L'identification des paramètres dérive vers la non-conformitéSalut la communauté,
J'ai une donnée de puissance qui augmente avec le nombre de tir jusqu'à ce qu'elle s'écrase.
Quel devrait être un bon moyen statistique de l'identifier quelques coups avant qu'il ne s'écrase afin d'éviter l'écrasement en le fixant à temps?
ci-joint, échantillon de données.
BR,
Yoav
AnalytiqueTableau de donnéesGraphiqueAutreRe: Identifier les paramètres dérivant vers la non-conformitéSalut, Yoav!
Il existe probablement un très grand nombre fini de «bonnes méthodes statistiques» pour signaler les courses dans les données.
Une méthode consiste à utiliser les règles de Nelson dans le menu déroulant Analyser,> Qualité et processus> Cartes de contrôle héritées> Levey Jennings.Après avoir converti les variables dans leurs rôles et cliqué sur OK, une carte de contrôle est créée.Sous le petit triangle rouge inversé (LIRT), choisissez Tests> Tous les tests.Vous obtenez quelque chose qui ressemble à ceci:
J'ai montré toutes les règles, mais vous pouvez utiliser les règles que vous jugez appropriées pour détecter précisément ce que vous souhaitez. Vous trouverez ci-joint quelques articles de référence de Lloyd Nelson qui détaille les règles et leurs justifications.
Bien sûr, vous pouvez même créer vos propres règles, si vous le souhaitez, et les implémenter avec JSL.Et, comme je l'ai mentionné plus tôt, il existe de nombreux autres tests pour les exécutions dans les données.Choisissez-en un qui détecte de manière fiable ce que vous souhaitez.
Bonne chance!
Re: Identifier les paramètres dérivant vers la non-conformitéchère @YGerchman , comme on peut le voir dans le graphique SPC de @Kevin_Anderson la puissance augmente toujours avant l'écrasement. Vous pouvez trouver une règle pour détecter l'écrasement avant qu'il ne se produise. Je n'ai pas pu obtenir de résultat raisonnable avec les règles SPC présentes sur la plate-forme, mais vous pouvez également calculer une limite supérieure à atteindre avant que l'écrasement ne se produise, et l'utiliser pour fixer la puissance avant l'écrasement. Voir l'exemple sur la capture d'écran.
- J'ai d'abord supprimé les 0 power lines (car vous ne les connaissez pas avant qu'il ne s'écrase)
- puis j'ai fait une formule de colonne pour calculer la moyenne et le stddev de la puissance dans cette phase
- puis je le compare à la valeur actuelle
- Lorsque la valeur actuelle> (moyenne (puissance) + 2 x stddev (puissance)), c'est juste avant le crash
Cela fonctionne pour les données actuelles, il peut avoir besoin de beaucoup plus de données, pour montrer si cette règle est fiable.
Tout dépend également des coûts liés à une course écrasée et des coûts de résolution du problème avant.
BR
Re: Identifier les paramètres dérivant vers la non-conformitésalut @YGerchman ,
En plus de ce que les deux @Kevin_Anderson et @Georg ont fourni, j'ajouterais ce qui suit:
Une autre option est que si vous disposez de données supplémentaires associées à la puissance, vous pouvez utiliser la plate-forme de cartes de contrôle multivariées pilotées par modèle (sous Analyse> Qualité et processus). Cette plate-forme réduit les données multidimensionnelles (en supposant que vous avez d'autres paramètres de processus qui sont enregistrés avec la puissance) à l'aide de l'ACP et rend compte de la valeur T ^ 2 et en regardant les valeurs aberrantes, vous pouvez savoir quelle partie de votre processus était en cours de contrôle. Ceci est souvent utile dans des circonstances où de nombreux paramètres de processus tels que la vitesse, la température, le taux de mélange, la puissance, etc. font tous partie du processus. Parfois, il se peut que la température change, entraînant une consommation de courant plus importante, modifiant ainsi la puissance, donc en fonction de la situation, il se peut que ce soit un mélange de facteurs, et la plate-forme MDMVCC est très utile pour cela.
Considérant que l'échec a tendance à se produire lorsque le numéro de lot augmente, cela suggérerait que quelque chose se passe pendant le processus qui change avec le temps. Vous pouvez voir que juste avant l'échec, la puissance monte avant le crash pour les deux phases, donc si vous avez des données d'entrées de traitement supplémentaires, cela peut aider à détecter un facteur latent qui est la cause première de l'échec. De plus, il y a un grand changement dans les sorties de puissance entre les phases 1 et 2. Les paramètres ont-ils changé ou la panne de la phase 1 a-t-elle eu un impact sur l'alimentation pendant la phase 2?
Apporter plus de données peut aider à déterminer la cause.
Bonne chance!,
DS
Re: Identifier les paramètres dérivant vers la non-conformitémerci pour votre réponse détaillée. en ce qui concerne la dernière question - la deuxième phase a obtenu l'empreinte digitale de la configuration et n'est pas affectée par le crash de phase1. il pourrait également être supérieur à la première phase.
les données sont un exemple simplifié de ce avec quoi j'ai vraiment réussi. en fait - nous avons des milliers de lignes de données et comme je l'ai déjà expliqué - je recherche un test qui pourrait avertir les ingénieurs de certains processus avant l'échec de l'outil. Je suis sûr que cela peut être fait car il peut voir à partir du graphique de course également à l'œil nu.Re: Identifier les paramètres dérivant vers la non-conformitésalut @YGerchman ,
Avez-vous également de nombreuses colonnes de sources de données différentes: par exemple, la vitesse de l'outil, ou la température de l'outil, ou quelque chose? Les milliers de lignes, c'est bien, mais il peut également être utile d'avoir d'autres données à intégrer à l'analyse. Pour moi, il semble vraiment qu'il y ait un facteur latent qui est la cause première de l'échec et pas nécessairement la puissance elle-même, plutôt que quelque chose d'autre devient incontrôlable qui provoque finalement une augmentation de la puissance et un crash de l'outil.
Une chose que vous pourriez faire est de considérer une moyenne mobile des trois ou cinq dernières mesures et d'estimer où se trouve la dernière lecture avant un crash et de trouver le changement relatif de puissance - disons que si la puissance commence à augmenter de plus de 20% de le point de consigne, cela indique que l'outil est en voie de défaillance. Étant donné que le réglage moyen de la phase 2 est inférieur à celui de la phase 1 et qu'il échoue toujours, il semble qu'il s'agisse plus d'un changement relatif de puissance par rapport au point de consigne plutôt que d'un changement absolu.
Mais encore une fois, si vous pouvez importer d'autres données et examiner des corrélations ou des pics / baisses similaires à un point de crash, cela peut aider à trouver un facteur latent.
Je suis intéressé de savoir ce que vous trouvez.
Bonne chance!,
DS
