サブグループサイズが大きい場合の管理図 Xbar-RJMP は、大きなサブグループ サイズの Xbar-R 管理図を作成できます。 サブグループサイズが 475 の場合、範囲の管理上限を求める式は何ですか? サブグループ サイズが 475 のサブグループが 60 個あります。
Xbar-S の S の管理限界の計算方法はすでに理解していますが、Xbar-R の UCLR の式はわかりません。
マイク
Re: サブグループサイズが大きい場合の管理図 Xbar-R@Mark_Baileyこれは、SPC 第 2 版の理解の第 5 章 (p. 112-113)、サブグループ化原則番号 #1 のウィーラー博士の「サブグループ化原則 #1、#2、および #3」を思い出させます。意図的に異なるものを一緒にサブグループ化しないでください。サブグループ化の原則 #2:各サブグループ内の変動を最小限に抑える。サブグループ化の原則 #3:サブグループ間の変動の機会を最大化します。
Re: サブグループサイズが大きい場合の管理図 Xbar-Rここでの返信をそのように解釈してしまい申し訳ありません。 私の知る限り、誰もあなたに自分を守るように頼んでいません。 あなたに尋ねた質問は、明確にするためのものです。 重要な詳細が議論に欠けている場合、間違った答えや解決策を提供するのは簡単です。 あなたが間違っていたと言っている人は一人もいません。 彼らは、サブグループのサイズが自分たちの経験の中で異常であることをほのめかしており、そのため、サブグループの性質について疑問を抱いていました。
ここでさらに詳しく説明するかどうかは、あなたの判断です。 JMP について質問がある場合は、コミュニティが利用できる最良のリソースである可能性が高いため、今後もコミュニティをご利用いただければ幸いです。
Re: サブグループサイズが大きい場合の管理図 Xbar-Rこの状況では、Xbar-R と Xbar-S を選択する「正しい」方法はなく、どちらも間違っています。 サブグループ内の変動は、変動の 3 つの要素、つまり短期的なランダム性、「長期的な」傾向、および時折発生する特殊な原因による予測不可能なスパイクで構成されます。 この状況に適した管理図はありません。 高度なモデリングだけがあり、最終的にはそれが適切になる可能性があります。 ただし、この製品のこの状況では、レンジ チャートはスパイクのあるデータの検出に優れていることが実証されており、S チャートは感度が高すぎて過剰反応を引き起こします。
単に数学を知りたかっただけです。 JMP ヘルプでもっとスキルがあれば、ヘルプ フォーラムを避けられたかもしれません。 何かがどのように機能するかについて質問するためだけに自分を弁護しなければならないことに腹を立てます。 私の質問に対して得られた回答を見ると、半数以上の人が、答えについて何の洞察も示さずに、私が何か間違ったことをしていると言ってきました。 これは荒らし行為に近く、専門的なヘルプ フォーラムというよりも Reddit に似ています。 私の実際の質問に答えるために貢献した人は 2 人だけでした。
誰かに疑惑の利益を与えるようにしてください。私がいくつかのガイドラインに違反しているからといって、私は無能であり、ある種の異端者であるとすぐに決めつけないでください。 私は応用に関する質問をしているのではなく、数式について質問しているのです。
Xbar-S を行うべきだという多数の意見とは対照的に、なぜ n=475 なのかに興味を持った人が 1 人いました。 Xbar-S も間違っていますが、反対意見があると詳しく説明する気にもなれません。
Re: サブグループサイズが大きい場合の管理図 Xbar-R@MiBo n>50 の場合、d2 および d3 の値はより不安定になります。定数は閉じた形式では利用できないため、さまざまな参考文献からさまざまな答えが得られます (それぞれが異なる推定方法を使用しています)。したがって、開発者は n=50 で停止することにしました。サンプル サイズが 50 を超える XBar/S チャートに切り替えることをお勧めします。
Re: サブグループサイズが大きい場合の管理図 Xbar-Rおかげでダン・オーバーミラーそしてTonya_mauldin0手がかりのために。 簡単に言うと、
UCLR = Rbar + 3 * d3 * (Rbar/d2)
サブグループ サイズ 50 の場合、
Harter によるこの論文の表 2 によると、d2 = 4.4981472588、d3 の 2 乗は 0.4252899556 です。 https://projecteuclid.org/download/pdf_1/euclid.aoms/1177705684
d3 は 0.6526098038
管理図の定数のソースに詳しく調べなければならなかったのは今回が初めてですが、幸いなことに Harter 論文がオンラインにありました。
その論文は n=100 まで可能です。 Minitabはサブグループサイズを100まで実行します。なぜJMPが50で停止するのかわかりません。
私のプロジェクトでは、サブグループ内に偶然の原因が継続的に存在するわけではないことをよく知っています。 それでも、範囲グラフは特定の状況では役立ちます。
Re: サブグループサイズが大きい場合の管理図 Xbar-R「サブグループ」というと、平均「合理的なサブグループ」。 私はあなたの選択を批判しているわけではありません。 ただ確認しているだけです。
サブグループに観測値をもたらす特殊原因イベントの可能性が(理想的には)ゼロになるように、管理図のデータ収集を設計します。 このように設計された合理的なサブグループは、短期変動の不偏推定値を生成します。同時に、特殊な原因を検出する可能性が高くなるように、十分な頻度でサブグループの間隔をあけます。 自己相関は、管理図のパフォーマンスと解釈を損なう可能性がある問題でもあります。 もちろん、サブグループの構成、サイズ、頻度の選択は、実際的な考慮事項によって制約されることがよくあります。
管理図は、小さなサブグループから有用な情報 (つまりシグナル) を提供できる効率的かつ客観的なツールです。 サイズ 475 のサブグループの根拠は何ですか?
Re: サブグループサイズが大きい場合の管理図 Xbar-R@バイロン_JMPこのトピックについては多くの議論があり、さまざまな経験則が見つかります。一般に、サンプル サイズが小さい場合は R 図が推奨され、サンプル サイズが大きい場合は S 図が推奨されます。以下のウェブページhttps://www.qualitymag.com/articles/95813-control-charts-what-one-Should-i-useサンプルサイズが 1<10 の場合、R 図を使用する必要があることを示唆しています。サンプルサイズが 10 以上の場合は、S 図を使用する必要があります。
別のページはこちら( Xbar R チャートと Xbar S チャートをいつ使用するか? ) 1<11 の場合は R管理図を使用する必要があることを示唆しています。サンプルサイズが 12 以上の場合は、S 図を使用する必要があります。
Re: サブグループサイズが大きい場合の管理図 Xbar-R@tonya_mauldinサブグループ サイズが大きい場合、S バーを使用することにいくつかの利点があるのではないでしょうか? n=25 または 30 あたりでは、平均推定値はかなり良好で、おそらく X バーに使用される古典的なアプローチよりも優れているのではないでしょうか?
Re: サブグループサイズが大きい場合の管理図 Xbar-RJMP のバージョン 15 より前では、JMP の d2 および d3 の値は最大 25 までしかありませんでした。バージョン 15 からは、d2 および d3 の値は最大 50 になります。サンプル サイズが 475 であるかどうかに関係なく、JMP は d2 および d3 の値を使用します。 50 であるため、「50 を超えるサブグループ サイズが発生しました。提案される代替案は、サブグループを細分するか、範囲ではなく標準偏差グラフを使用することです。」
Re: サブグループサイズが大きい場合の管理図 Xbar-R@MiBoつまり、ダンが言ったように、これはサブグループのサイズが非常に大きいということです。 何も悪いことはありませんが、興味深いです。 どのような種類のデータがトレンドになっているのか知りたいです。
Re: サブグループサイズが大きい場合の管理図 Xbar-R求めている式は、JMP ドキュメントに記載されています。


サンプルサイズに対して 475 という高さの d2 値の表を見たことがありません。 サブグループ サンプルをシミュレートするために 475 個のランダムな正規数を作成し、範囲を計算することで推定しました。 これを 1,000,000 回実行したところ、平均値は 6.041 で、これは d2 の妥当な推定値となります (d2 がわかっているサンプル サイズについては、このアプローチを検証できます)。
それほど大きなサブグループに範囲を使用することは、おそらく良い考えではないことに注意してください。 Xbar-S チャートを使用する方が合理的だと思います。 ほとんどの著者は、n >= 8 の場合には Xbar-S を使用する必要があるとも述べています。 また、これほど大きなサブグループには、当然ながら非常に厳しい管理限界が設定されます。