(シューハート) 管理図テスト番号をメイン データ テーブルの列に追加JMP コミュニティの皆さん、こんにちは。
管理図を生成します（分析する>品質とプロセス>管理図ビルダー) すべてのテストを実行します (チャートを右クリック >警告>テスト>すべてのテスト) 以下のチャートを取得します。
いくつかのポイントの隣に表示されるテスト番号を、グラフの生成元と同じデータ テーブルの新しい列に追加して、各数値がそれが属するデータ ポイントと同じ行に表示されるようにしたいと考えています (データチャートに番号のないポイントは、この新しい列に単に空のエントリまたは N/A を含めることができます)。 最終的には、この列を 3D プロットの「色分け」として使用したいと考えています。
よろしくお願いします。
アーメド
マスカスタマイゼーション品質およびプロセスエンジニアリングRe: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加する@Mark_Baileyそして@スタットマン、私の指導のためのアイデアを寛大に説明するために時間を割いていただき、誠にありがとうございます。 気をつけます。 とても有難い。
Re: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加するチャートの別の解釈 (実際にはシューハートのオリジナルの解釈)。 シューハートが作成したチャートは 2 つあります。 レンジ チャートと X バー チャート。 これらは併用されます。 の範囲チャートは一貫性/安定性を評価しますサブグループ内の変動 (サブグループ内のサンプリング周波数で変化する変数 (x) の関数です)。 これは、サブグループ内の変動が比較の基礎となるためです。 サブグループ内の変動に一貫性がない場合、比較は役に立ちません (比較はサブグループ内の変数がその時点で何をしていたかに依存します)。 のXバーチャートは比較チャートです。 一貫性を評価するのではなく、サブグループ内の変動 (これらは管理限界です) をサブグループ間の変動、つまりプロットされた平均 (サブグループ間のサンプリング頻度で変化する変数の関数) と比較します。 制御不能な点がない場合は、サブグループ内の変動が支配的になります。 この一連の x がレバレッジの場所です。 制御不能な点 (またはその他の非ランダム パターン) がある場合は、サブグループ間の変動が支配的になります。 このように、管理図は、調査員が最も大きな影響力を持つ x のサブセットを指し示すのに役立ちます。 変数のサブセットをさらに分離して特定の原因因子を特定するには、さらなるサンプリングまたは実験が必要です。
Re: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加する管理図は、プロセスが不安定であるという信号を生成するツールです。 安定していないことはすでにご存知でしょう。 管理図のポイントは監視ではなく、信号を確認したときに調査を開始し、修正を実行することです。 これらのチャートは他の種類の分析の基礎にもなりますが、それがあなたが知りたいことに最適であるかどうかはわかりません。
関連性を見つけて評価するためのより優れたツールがあります。 これらは量的変数と質的変数の両方に存在します。 それらの多くは、「予測」と「分類」の範疇に当てはまります。 教師なし学習モデルは、事前に決定された応答 (合格、不合格など) がない場合に役立ちます。 階層クラスタリングは、目的に役立つツールの好例です。
をご覧ください。ヘルプ> JMP ドキュメント ライブラリ>予測モデリング完全な説明と実際の例についてはガイドを参照してください。
Re: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加するこんにちは、スタットマンです。
私はこの特定のテーマについてまだ深く理解していませんし、あなたも理解しているようですので、私の答えはあなたの好奇心を払拭できないかもしれません。 私は物理的な 3D オブジェクトから収集された高密度のデータ ポイントを扱っていますが、その動機は単に空間的な傾向 (つまり、オブジェクト上のデータ ポイントの位置とフラグが立てられたルールとの間の相関関係) があるかどうかを確認することでした。
質問の答えになっていない場合は申し訳ありませんが、質問に完全に答えるにはまだ十分な知識がありません。 しかし、あなたの考えを共有してくれてありがとう - そこには私が学ぶべき何かがあると確信しています。Re: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加するやりたいことを実現するための技術的な方法は別として...その理由を理解するのを手伝ってもらえますか? 敵対するつもりはなく、知識を高めるだけです。 トレンドに割り当てられる原因がポイント OOC とは異なる可能性があることは理解していますが、チャートはそれらを特定するのに役立つだけであり、いずれの場合でも原因が何であるかを判断するにはプロセスの知識が必要です。
私の知る限り、シューハート氏は異なるテストを区別することを提案したわけではありません。 これらは 1956 年に Western Electric Company のグループによって設立されました。 これらは、ガイダンスを提供し、時系列として提示されたデータ内の異常なパターン (管理限界の解釈を超えたもの) を識別する能力を高めることを目的としていました。 異常なパターンを特定可能な原因の変動の証拠として特定するためにどのような「ルール」が使用されたのかをなぜ区別するのか不思議です。 また、1点にはルールが適用されないことも多い。 たとえば、MR管理図では、OOC条件は2つのデータポイントの関数です。 トレンドは 7 つのデータ ポイントの関数です...など。
Re: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加するジェリーさん、早速のご返信ありがとうございます！
Re: メイン データ テーブルの列に (シューハート) 管理図テスト番号を追加するこんにちは、アーメッドさん
必要なものを入手するには数回クリックする必要がありますが、それほど苦痛ではありません。 管理図ビルダー レポートの赤い三角ボタンのメニューから [概要の保存] を選択すると、テスト失敗列を元のデータ テーブルに結合するために必要なすべての情報が含まれる新しいテーブルが生成されます。 これが個別のグラフの場合、データは両方のテーブルで同じ順序で表示される必要があるため、コピー/ペーストで新しい列を結合できます。 どのような場合でも、「テーブル」->「結合」を使用して、目的の列を結合できます。 いつものように、これを頻繁に行う必要がある場合は、スクリプトを作成できます。 お役に立てれば。
-ジェリー
