GRR を考慮して仕様制限を広げますか?こんにちは。製造/統計に関する質問です。製造中に複数のポイント (ノード) でテストされている部品があるとします。GRR を考慮して最初のノードの後に制限を広げるかどうか、またどの程度広げるか興味があります。USL に 1 GRR を追加したり、LSL から 1 GRR を減算したりするだけですか? それとも、統計コミュニティでこれをどのように処理すべきかについて他のコンセンサスがあるのでしょうか?
これまで、私は最初のノードの後に +/- 1 GRR だけ制限を広げてきました。これは、テスター/テスト/オペレーターの変動によって生じるシフトを考慮するためです。最初のノードで値が制限に近かった合格パーツは、この変動により範囲外にシフトしている可能性があるため、これを考慮して下流の制限を広げます。これは、パーツが +/- 1GRR だけシフトできると想定されているため、最初のテスト ノードの後にのみ行われます。
1. 他の人も同じようにやっているのでしょうか?
2. 目標 Cpk = 2 を達成するために制限を設定する場合、平均に +/- 3 シグマを追加します。この論理では、+/- 1GRR ではなく +/- 3GRR を制限に追加する必要がありますか?
統計的に正しい処理方法は次の通りだと思いますが、コミュニティからの確認を得たいと思います。測定値を、その部分の静的な「真の」値 X と、平均 = 0、分散 = GRR^2 の正規ランダム変数 Eps の合計として扱うとします。
ノード 1: Xmeas1 = Xtrue + Eps1 平均 (Xmeas1) = Xtrue 変動 (Xmeas1) = GRR1^2
ノード N: XmeasN = Xtrue + EpsN 平均 (XmeasN) = Xtrue 変動 (XmeasN) = GRRN^2
XmeasN は、初期測定値とノード間のシフトを表す新しいランダム変数 (EpsDiff) に基づいて書き直すことができます。
XmeasN = Xmeas1 - Eps1 + EpsN = Xmeas1 + EpsDiff
どこ：
平均(EpsDiff) = 0 (平均(Eps) == 0なので)
Var(EpsDiff) = GRR1^2 + GRRN^2 = 2GRR^2 (すべてのノードでGRRが同じであると仮定)
この論理によれば、下流ノードでの制限を +/-sqrt(2)*GRR だけ広げるべきでしょうか?
これについて人々がどう思うか知りたいです。 ありがとう!
品質およびプロセスエンジニアリングRe: GRR を考慮して仕様制限を拡大しますか?以下は私の考え/質問の一部ですが、同意できない場合もあります。
1.GRRとは？ 仕様を設定するときに測定システムの誤差を考慮したいと思いますよね？ しかし、あなたが使用しようとしているGRR番号がわかりません（再現性、再現性、両方の標準開発）？分散成分は常に追加されます (標準偏差ではありません)。
2. 私の理解では、従来の仕様はアプリケーション要件の機能です (できれば顧客主導)。 これらはネゴシエートされる可能性がありますが、コンポーネント、アセンブリなどのパフォーマンスがどの時点で低下するか (または実行に失敗するか) を反映する必要があります。 残念ながら、これらは通常、真のプロセス能力とは無関係に設定されます。 あなたが提案しているのは、測定システムの不確実性を説明するために処理制限（おそらく内部仕様）を設定することだと思います...これはあなたが言いたいことですか?
3. 測定システムによる変動の推定値に関していくつか質問があります (Cpk の推定に使用されるサンプル統計についても同様です)。 測定システムは安定していますか？ 統計を推定するために使用されるサンプルのコレクションの推論空間は? 将来の状況をどの程度代表していますか?
4. 仕様の「考え方」の有用なアプリケーションをあまり見たことがないので、私自身のちょっとした暴言です (仕様を満たすことは、継続的な改善に反するものです)。 私が時間を費やすのは、製造プロセスのどの要因が、出力製品の重要な性能測定値の平均と変動に影響を与えるかを理解することです. Y=f(X) (サンプリングと DOE を使用)。 測定プロセスも同様です。 次に、どの時点でパフォーマンスが低下するかを定量化します (タグチ損失関数)。
Re: GRR を考慮して仕様制限を拡大しますか?何の上に構築するために@スタットマン言及されており、これをさらに複雑にするために、通常は仕様制限ではありません引き締まった測定システムの誤差を説明するには？ Jerry Fish と Jason Wiggins は、今年の Discovery でこのトピックについて発表し、MSA/GRR エラーに基づいて仕様制限の変更を計算するためのアドインもアップロードしました。 リンクはこちら. アドインを使用して、仕様の制限をどれだけ広げる必要があるかを計算できます。
Re: GRR を考慮して仕様制限を拡大しますか?この考えは、によって提示されたものと同じです@スタットマンと@Jed_Campbellしかし、別の視点から。 処理（合格、不合格）の仕様は、要件に対する性能によって設定されます。 測定/テスト誤差は、これらの制限に追加されるのではなく、差し引かれます。 この概念に基づく確立されたスキームは複数あります。 逆に行く人を見たことがない。 仕様を壁と考えてください。外側は顧客が見るものです。 インテリアから奪うことはできますが、それらから奪うことはできません。
Re: GRR を考慮して仕様制限を拡大しますか?こんにちはマークと他の人。
まず、いくつかのことを明確にさせてください。 仕様制限は、ユーザー主導またはプロセス主導の場合があります。 ユーザー主導の制限により、パーツが事前に定義された主要な基準を満たしているかどうかがチェックされます。 プロセス主導の制限は、プロセスを確実に管理するために使用されます。 これらの制限は、(通常) 目標の cpk = 2 を達成するために選択され、ユーザーの基準ではなく、過去のデータに基づいています。
また、明確にするために、「GRR」を使用して、複数のテスター/オペレーター/繰り返しによって導入された測定の差異を指しています。 つまり、総分散 (TV) から部分分散 (PV) を差し引いたものです。
そうは言っても、ユーザー変数とプロセス変数の両方の測定値は、下流に移動するにつれて GRR によるシフトの影響を受けます (測定値は、変数の名前を気にしません)。 したがって、制限を決して広げてはならないという意見には同意しません。 おそらく、問題を別の方法で表現すると役立つでしょう。 部品が下流に行くにつれて限界を広げるという観点で話していました。 代わりに、通過する部品が最終的な下流の仕様を満たすように、上流の制限を厳しくしたいと考えています。 私の質問は、単純に、GRR を説明するためにアップストリームの制限をどれだけ厳しくするかということです。
Re: GRR を考慮して仕様制限を拡大しますか?アップストリームの制限を厳しくすることは、これを組み立てる興味深い方法です-明確化していただきありがとうございます。 のアドインこのリンクGRR を考慮して仕様制限を移動するための適切な量を計算するために使用できます。 手動で行う場合は、OC 曲線プラットフォーム (分析、品質とプロセス、OC 曲線) を使用することもできます。
Re: GRR を考慮して仕様制限を拡大しますか?用語とその後の混乱についてのフィードバックです。 私見、「プロセス主導」の制限は仕様の制限ではありません。 管理限界について話しているのですか？ これらはプロセスの関数であり、サンプリング方法です。 データの取得方法によって異なりますが、選択することはできません。 残念ながら、仕様制限は独立して導出されるため、統計的管理とは何の関係もありません。
任意の制限を設定できます。 プロセスは、課された制限を気にせず、影響も受けません。 しかし、続けて...
Re: GRR を考慮して仕様制限を拡大しますか?このような複雑なトピックを議論する際には、確立された用語を使用することが役立つことに同意します。
