Identification des paramètres qui dérivent vers la non-conformitéSalut la communauté,
J'ai une donnée de puissance qui augmente avec le nombre de run jusqu'à ce qu'elle s'écrase.
Quel devrait être un bon moyen statistique pour l'identifier quelques fois avant qu'il ne s'écrase afin d'éviter l'écrasement en le réparant à temps ?
ci-joint, exemple de données.
BR,
Yoav
Études de consommation et de marchéObjet : Dérive des paramètres d'identification vers la non-conformitéSalut DS,
Il semble que la moyenne mobile des 5 derniers points puisse me donner un assez bon avertissement. Je dois encore trouver le point de consigne exact pour l'alerte, mais il semble que ce soit un bon moyen. Malheureusement, je ne peux pas partager en ligne des données beaucoup plus détaillées.
une autre option qui, je pense, peut être faite consiste à trouver la "force de tendance" avec une moyenne mobile et à rechercher une forte rupture de tendance (fort changement, augmentation de la tendance)
Cordialement,
Yoav
Objet : Dérive des paramètres d'identification vers la non-conformitéSalut @YGerchman ,
Avez-vous également de nombreuses colonnes de différentes sources de données : par exemple, la vitesse de l'outil, ou la température de l'outil, ou quelque chose ? Les milliers de lignes sont bonnes, mais il peut également être utile d'avoir d'autres données à intégrer dans 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, plus comme quelque chose d'autre devient incontrôlable qui provoque finalement la montée en puissance de la puissance et le plantage 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 sur le point de tomber en panne. É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 davantage 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 apporter d'autres données et examiner les corrélations ou les pics/baisses similaires à un point de crash, cela pourrait aider à trouver un facteur latent.
Je suis intéressé d'entendre ce que vous trouvez.
Bonne chance!,
DS
Objet : Dérive des paramètres d'identification 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 son empreinte digitale de configuration et n'est pas affectée par le crash de phase1. il pourrait être aussi plus élevé que 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 expliqué précédemment - je recherche un test qui pourrait avertir les ingénieurs de certains processus avant que l'outil ne tombe en panne. Je suis sûr que cela peut être fait car il peut également être vu à l'œil nu sur le graphique.Objet : Dérive des paramètres d'identification 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 avez des données supplémentaires qui accompagnent la puissance, vous pouvez utiliser la plate-forme de cartes de contrôle multivariées pilotées par modèle (sous Analyser> Qualité et processus). Cette plate-forme réduit les données multidimensionnelles (en supposant que vous ayez d'autres paramètres de processus qui sont enregistrés avec la puissance) en utilisant PCA et rapporte la valeur T ^ 2 et en regardant les valeurs aberrantes, vous pouvez savoir quelle partie de votre processus sortait 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 plus grande consommation de courant, modifiant ainsi la puissance, donc selon la situation, il se peut qu'il s'agisse d'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 à mesure que 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 la panne, la puissance augmente avant le crash pour les deux phases, donc si vous avez des données provenant d'entrées de traitement supplémentaires, cela peut aider à détecter un facteur latent qui est la cause première de la panne. 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 impacté l'alimentation pendant la phase 2 ?
Apporter plus de données pourrait aider à déterminer la cause.
Bonne chance!,
DS
Objet : Dérive des paramètres d'identification vers la non-conformitéCher @YGerchman , comme on peut le voir dans le tableau 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 qui se trouvent dans 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 que l'écrasement ne se produise. Voir l'exemple dans la capture d'écran.
- J'ai d'abord supprimé les lignes de puissance 0 (car vous ne les connaissez pas avant que ça é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 > (mean(power) + 2 x stddev(power)), c'est juste avant le crash
Cela fonctionne pour les données actuelles, il faudra peut-être beaucoup plus de données pour montrer si cette règle est fiable.
Tout dépend également des coûts d'avoir une course écrasée et des coûts de résolution du problème avant.
BR
Objet : Dérive des paramètres d'identification vers la non-conformitéSalut Yoav !
Il existe probablement un très grand nombre fini de "bonnes méthodes statistiques" pour signaler les passages dans les données.
Une façon 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 coulé 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 démontré toutes les règles, mais vous pouvez utiliser les règles que vous jugez appropriées pour détecter spécifiquement ce que vous souhaitez. Vous trouverez ci-joint quelques articles de référence de Lloyd Nelson qui détaillent 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!
