識別參數漂移到不符合項嗨，社區，
我擁有的功率數據會隨著運行次數的增加而增加，直到崩潰為止。
為了避免在按時修復之前發生擠壓，應該有什麼好的統計方法來識別它在擠壓之前的運行情況？
附件，數據樣本。
BR
約夫
分析工具數據表圖形學其他回复：確定參數漂移到不符合項嗨，約阿夫！
可能有非常有限的“良好統計方式”來表示數據中的運行。
一種方法是在“分析”下拉菜單中使用Nelson規則，即>“質量和過程”>“舊版控製圖”>“ Levey Jennings”。將變量轉換為它們的角色並單擊“確定”後，將製作一個控製圖。在紅色小三角形（LIRT）下，選擇“測試”>“所有測試”。您會得到如下所示的內容：
我演示了所有規則，但是您可以使用您認為合適的任何規則來專門檢測您想要的東西。 隨函附上勞埃德·納爾遜（Lloyd Nelson）的幾篇參考文章，詳細介紹了規則及其依據。
當然，如果您願意，甚至可以製定自己的規則，並使用JSL實施它們。而且，正如我之前提到的，還有許多其他測試可用於數據運行。選擇一種可以可靠地檢測到您想要的東西。
祝你好運！
回复：確定參數漂移到不符合項親愛的@YGerchman ，正如我們在SPC圖表中看到的@凱文·安德森力量總是在壓碎之前增加。 您可以找到規則，以在暗戀發生之前對其進行檢測。 我無法使用平台中的SPC規則獲得任何合理的結果，但是您還可以計算在擠壓發生之前可以達到的上限，並使用該上限來修復擠壓發生之前的功率。 請參閱屏幕截圖中的示例。
- 我首先刪除了0個電源行（因為在崩潰之前您不知道它們）
- 然後我創建了一個列公式來計算該階段功率的均值和標準差
- 然後我將其與當前值進行比較
- 噹噹前值>（平均值（power）+ 2 x stddev（power））時，就在崩潰之前
這適用於當前數據，可能需要更多數據，以顯示此規則是否可靠。
同樣，所有這些都取決於運行失敗的成本以及之前解決問題的成本。
BR
回复：確定參數漂移到不符合項你好@YGerchman ，
除了兩者@凱文·安德森和@喬治已提供，我將添加以下內容：
另一個選擇是，如果您擁有與功能一起提供的其他數據，則可以使用模型驅動的多元控製圖平台（在“分析”>“質量和過程”下）。 該平台使用PCA減少了多維數據（假設您具有與功率一起記錄的其他過程參數），並報告了T ^ 2值，並通過查看異常值可以發現過程的哪一部分出局了控制。 這在許多過程參數（例如速度，溫度，混合速率，功率等）都是過程的一部分的情況下通常很有用。 有時，溫度可能會改變，從而導致更大的電流消耗，從而改變功率，因此，根據情況，可能是多種因素的混合，而MDMVCC平台對此非常有幫助。
考慮到隨著批號的增加，故障往往會發生，這表明在此過程中隨著時間的推移發生了一些事情。 您可以看到，在發生故障之前，兩個階段的崩潰之前都會加電，因此，如果您有來自其他處理輸入的數據，這可能有助於捕獲潛在的因素，這是故障的根本原因。 同樣，在第一階段和第二階段之間，功率輸出也發生了很大的變化。 設置是否發生變化，或者階段1的故障是否影響階段2的電源？
引入更多數據可能有助於確定原因。
祝你好運！，
DS
回复：確定參數漂移到不符合項感謝您的詳細回答。關於最後一個問題-第二階段為其設置了指紋，並且不受階段1崩潰的影響。它也可能高於第一階段。
數據只是我實際管理的簡化示例。實際上-我們有成千上萬的數據行，並且正如我之前解釋的那樣-我正在尋找某種測試，該測試可以在工具出現故障之前警告工程師一些過程。我確信它可以做到，因為它也可以用肉眼從運行圖上看到。回复：確定參數漂移到不符合項你好@YGerchman ，
您是否還有許多不同數據源的列：例如工具速度，工具溫度或其他內容？ 成千上萬行是好的，但是將其他數據帶入分析也可能會有所幫助。 在我看來，確實有一個潛在的因素是故障的根本原因，而不一定是電源本身，更像是其他一些失控的因素，最終導致電源尖峰和工具崩潰。
您可以做的一件事是，考慮最近三到五個測量值的移動平均值，並估計碰撞前最後一次讀數的位置，並找到功率的相對變化-假設如果功率開始增加超過20％，設定點，表明工具即將失效。 由於第2階段的平均設置低於第1階段的平均設置，但仍然失敗，因此似乎是功率相對於設定點的相對變化，而不是絕對變化。
但是同樣，如果您可以引入其他數據並查看崩潰點處的任何相關性或相似的尖峰/跌落，則可能有助於查找潛在因素。
我很想听聽您的發現。
祝你好運！，
DS
