平均と上限/下限管理限界を示す管理図がある場合、管理点外の原因が割り当て可能かどうかをどのように判断できますか?


8

IEEE CSDA模擬試験-エンジニアリング統計-管理図

15ポイントが与えられます。管理限界は+/- 3です。ポイント1、4、5、6、7、8、9、10、11、13、15は管理限界内にあります。ポイント2、3、12、および14は管理限界の外側にあり、2は管理限界の下限を下回り、3、12、および14は管理限界の上限を上回っています。σ

ポイント2、3、12、および14が偶然の原因または割り当て可能な原因が原因で制御不能になっているかどうかをどのようにして知ることができますか?


1
誰かが私に望んでいるなら、私が与えられたものと同様のグラフを作り、ここにリンクすることができます。この質問は、IEEE認定ソフトウェア開発アソシエイトの模擬試験から出されたものです。正解は明らかに「割り当て可能な原因による制御不能」です。残念ながら、それが答えである理由はわかりません。一連の制御不能なポイントがないため、「偶然の原因によって制御不能」と言いました。
Thomas Owens

はい、グラフは役に立ちます。私の回答で述べたように、管理限界の外にある点だけでなく、チャートの外観も重要です。
Carlos Accioly、2010年

質問の写真を追加しました。グラフも含まれています。私も正解をマークしました。
Thomas Owens

回答:


6

はい、あなたは制限の外にあるすべてのポイントについて、割り当て可能な原因を見つけるべきです。しかし、物事はもう少し複雑です。

管理図はプロセスが制御不能になると無意味になるため、最初にプロセスが制御されているかどうかを判断する必要があります。観測値のほぼ1/4が限界を超えている場合、プロセスが制御不能になっている可能性があることを強く示しています。チャートを見ると、プロセスが管理されているかどうかを判断するのに役立ちます。

管理限界の外にあることに加えて、特定の観察に対して割り当て可能な原因を探す必要がある他の潜在的な理由があります。たとえば、平均の同じ側にある行に複数の観測がある場合、特にそれらが管理限界に近い場合、特別な原因を割り当てる必要がある場合があります。

チャート自体を投稿する場合は、もっと具体的に説明できるかもしれません。

管理図についてさらに詳しく知りたい場合は、SPC Pressに役立つ無料のリソースが多数用意されています。また、この本をご覧になることもできます。短く、簡潔で、非常に有益です。

(編集:)

試験問題ではなく、実際のデータについて話していると思いました。この場合、正解は最初の答えです。管理限界の外側のポイントは、(おそらく)割り当て可能な原因が原因です。

ただし、試験の用語は少しずさんです。実際には、管理限界の外側のポイントが偶然に起因するものではないことを100%確実に伝えることはできません。限界外の特定のポイントが偶然に引き起こされていない確率は99.7%であると言えます。


元の質問とグラフを含む画像を追加しました。
Thomas Owens

5

管理図についての私の理解は少し異なります...観測2での最初の信号の後、プロセスを停止し、問題をチェックしてから再起動しませんか?

いずれの場合でも、p値の引数を使用できます。プロセスが実際に制御されている場合、制御限界を超えて4つ以上の観測値(15のうちの)を観測する確率は非常に小さくなります。プロセスが実際に制御されているときに観測値が管理限界の外に出る確率が約0.01であるとします(この正確な確率はデータの制御内分布に依存します)。したがって、プロセスが制御されている場合、falseが予想されます。 100回程度の観測ごとにアラーム(すなわち、ランダムな偶然によって引き起こされた制御信号外)。プロセスが制御されているときに4つ以上の制御信号(15個のうち)を監視する確率は約0.000012であるため、信号がランダムな偶然によるものである可能性はほとんどありません。

実際の診断では、チャートを見て、場合によっては実際の物理プロセスを調査する必要がありますが、管理外のポイントは管理限界の上下にあるため、スケールシフト(つまり、分散の増加)があったに違いありません。 )


私はEngineering Statsのコースを1つだけ受講しましたが、制御不能な3(多分2)ポイントになるまでプロセスを停止しないことを覚えているようです。ただし、2番目の引数は理にかなっており、実際に制御されているプロセスでは、+ /-3 std devの外側に4/15の観測がありません。残念ながら、私は自分のEngStatsブックを自宅で確認できません。少なくともそれはもっともらしい。とりあえず+1、これをもう少し調査できるようになるまで。しかし、少なくともそれは出発点です。
Thomas Owens

(+1)良い答え。または、標準偏差が非常に長い一連のデータから以前に推定されていたとすると、分布の正規性について疑問に思うかもしれません。さらに、これらの15点はランダムな選択ではない可能性が高く、異常な数のOOC測定値が出現する短いシーケンスとして選択されたに違いありません。前者は、単一のOOCの可能性が0.01よりかなり大きい可能性があることを示唆していますが、後者は、二項計算が誤解を招くものであることを示しています。結局のところ、そのようなシーケンスが最終的に偶然に発生することは事実上確実です!
whuber

元の質問とグラフを含む画像を追加しました。
Thomas Owens

3
@トーマスそれはまだ私にとって悪い質問のように見えます。2つの概念(管理図の読み方と、「割り当て可能」と「チャンス」の原因の区別)を測定しようとしますが、これは1つの間違いであり、解釈するにはさらに多くの情報が必要であることを知っている思慮深い受験者を罰しますOOCはここで指定されているよりもポイントが大きく、これはさらに重大な間違いです。
whuber

4

(新しい回答を投稿して申し訳ありません。コメントに直接返信することはまだできません)

私はステートメントに本当に同意しません:

「どうやら、UCLまたはLCLのどちらかを通過する場合、割り当て可能な原因が必要です」

事を簡単にするために、制御分布がN(0,1)の場合、UCL 3とLCL -3を使用して、平均で370観測ごとに1回、誤ったアラームを取得します。チャートが信号を送ったとき、プロセスを調査する必要があります。その後、信号の理由を割り当てることができます(つまり、プロセス変更またはランダムエラー)。UCLとLCLを設定するには、ユーザーが目的の誤警報/検出漏れ率(タイプI /タイプIIエラーのトレードオフに類似)のバランスをとる必要があります。仮説検定。)

実際に停止してプロセスを調査するためにいくつかの信号まで待つこともできますが、その場合、最初の信号で実際に発生したシフトを検出するのが遅すぎる可能性があります。繰り返しになりますが、何もかもを無駄にすることはできません。ユーザーは、管理図の設定方法とプロセスの監視方法をユーザーが判断して決定する必要があります。


2

この試験に向けたIEEEの調査文書で興味深いものが発見されました。

  • UCLおよびLCLの範囲内にあるデータポイントは制御されていると見なされ、偶然の原因によって引き起こされます。
  • UCLを超える、またはLCLを下回る外れ値は、制御不能と見なされ、割り当て可能な原因によって引き起こされます。
  • いくつかのポイントが体系的に平均を上回ったり下回ったりします(ただし、UCLおよびLCL内にある)場合、これはランダムではない制御不能状態を示している可能性があります。
  • 管理図の目的は、制御不能状態をすばやく検出することです。
  • グラフだけでは、イベントの根本的な原因を示すことはできませんが、調査に役立つ可能性があります。

どうやら、UCLまたはLCLのいずれかを通過する場合、割り当て可能な原因が存在する必要があります。

これは、Wikipediaの割り当て可能な(特別な)原因の特性の定義を考えると、理にかなっています

  • システム内の新しい、予期しない、緊急の、または以前に無視された現象。
  • 変動は本質的に予測不可能であり、確率的にもです。
  • 歴史的体験ベース以外のバリエーション。そして
  • システムの固有の変更の証拠、またはシステムに関する知識。

わかりました。ありがとうございます。元の質問を解決します。「割り当て可能」は「偶然に起因しない」ことを意味しているようで、これは問題の二分法と一致しています。私が苦労しているのは、OOCイベントは偶然によるものではあり得ないという仮定です。@HairyBeastが指摘したように、これは明らかに間違っています。調査文書のもう1つの印象的な側面は、「ポイントの数」(いくつですか)や「体系的」(何を意味するか)のように、非公式で非定量で、その場限りのように見えることです。CUSUMを参照するか、適切なガイドラインを提供せずにチャートを実行するようです。
whuber

2
@whuber完全に同意します。これがIEEEによって公開され維持されていることを考えると、私はずっと良くなると思っていました。それはソフトウェアエンジニアリングの認定であり、他のことにはあまり深く入りたくないので、彼らがたくさんのものを手で振っているのではないかと思っています。しかし、それはこの混乱の一部の言い訳にはなりません。
Thomas Owens、
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.