収益低下要因の優先順位付け

[#1]

さらに、質問は spec(value) --- 単一のパラメータについてです。
仕様限界を持つパラメータが複数ある場合、複数の仕様違反（不合格 A、不合格 A+B、不合格 A + K ... 不合格 K、合格）のセットが存在する可能性があります... JMP で歩留まり低下要因の優先順位を定義することはできますか?

デバイス 1 は仕様 A が原因で失敗しました。後続の仕様はテストする必要がありません。
-> 合計で x% のデバイスが (優先順位付けされた) 仕様 A が原因で故障します。

...

デバイス 2 は仕様 K が原因で失敗しました。後続の仕様はテストする必要がありません。
-> 優先順位の低い仕様 K が原因で、合計 x% のデバイスが故障しますが、優先順位の高い仕様はありません。

...

デバイス 3 はすべての仕様を満たしています -> 合格。

[#2]

@ホギ ,

つまり、デバイス (データ テーブルの行) がすべての仕様を満たしているかどうかを確認し、満たしていない場合はフラグを立てて、どのプロセスで失敗したかを示すことが要求されているということですか?

もしそうなら、私はまだマーケットプレイスに提出していないアドインを作成し、他の人による追加のテストを受けることができます (私に代わってテストしていただける場合は)。

応援して、

[#3]

hogiは、特定の順序/優先順位に基づいて最初の失敗を特定しようとしていると思います。以下は、このような場合にすぐに思い浮かぶいくつかの理由です。

• 失敗するまでのみテストするかもしれません（残りの結果は欠落している可能性があります）
• すべてをテストするかもしれませんが、特定の分析では最初の失敗のみを気にします

もちろん、失敗したプロセスをすべて確認したい場合もあります。

[#4]

こんにちは@Chris_Kirchberg 、素晴らしいですね : )
テストをお手伝いさせていただきます...

に関して:
どのプロセスで失敗したかを明記してください。 @jthiは正しいです。目標は、プロセスの重要性を使用して、すべての部分に固有の失敗フラグを取得することです。
例えば

キャンディーを砕く場合、色は関係ありません。

形や色はOKですが、味はどうでしょうか？

等々 ...

[#5 · Accepted solution]

私のアドインはそれに近いものですが、事前に決定された優先順位はありません。失敗順のリストのみ (列は複数の応答)。また、ユーザーは kx Sigma (標準偏差) を指定して、その行/単位がすべてのプロセスでその範囲外にあるかどうかを確認することもできます。

添付されているのは、私が取り組んでいるものです。おそらく、このフレームワークはその始まりになるのではないでしょうか。優先順位リストと障害モードのフラグの種類をインポートするためのスキームを考え出す必要があります。残りは比較的簡単です (障害モード フラグ付きの新しい列)。

私のアドインの目的は、仕様制限を使用して数百のプロセスを調べ、akx sigma limit を使用して、設定された仕様制限よりも優れているか劣っているかを確認し、そのユニット (または行) が準拠しているかどうかを確認することでした。

したがって、すべての仕様限界または kx シグマ限界 (それぞれ独自の列を持つ) に合格 (1) のフラグが設定され、次にプロセスの列 (列順、つまりチェック順) もそれぞれに対して作成されます。限界を超えたプロセス数の列も作成されます。出力のスクリーンショットを下に示します。

まだ進行中の作業なので、あなたのコメントは貴重です。

[#6]

優先順位付けには、プロセス重要度(仕様制限の一部) を使用します。

[#7]

3つの注文オプションを検討します（単純な注文ベースのものだけを維持する場合）

• hogiのような列プロパティは
• 列の順序
• ユーザーが読み込むことができる別のリストも可能 (たとえば、Ppk を使用してテーブルを作成し、それに基づいてテーブルを順序付けし、その順序付けを使用できます)

非常に簡単なテストに基づいて、私の頭に浮かんだいくつかのアイデア。これらのいくつかは、このアドインの範囲外である可能性があります。これらは特定の順序ではありません。

• ランチャーにダイアログを開いたままにするオプションがあるのが気に入っています
• 既存のテーブルに新しい列を追加するのではなく、別のレポートを作成できるようにします。
  • ユーザーが選択した ID 列を持つリンクされたサブセット (リンクが壊れると煩わしいのでリンクされていない) でしょうか?
• 特定の列のみを選択することも可能なので、計算に使用された列が明確にわかるようにします (Notes 列プロパティを使用するとよいでしょう)。
  • オプションで、同じランチャーを使用して既存の列を新しい選択で更新できるようにします (以前の選択をアドイン ランチャー ウィンドウに読み込むボタンを用意することもできます)。
• 「仕様制限のあるすべての列を追加する」などのボタンを追加します
• OKとキャンセルを下ではなく右に移動して、JMPプラットフォームに似たものにします。
• 規格外の値を色分けするオプションを追加
  • すべての障害に対して単一の色を選択するか、2 つの色を選択するオプション (プロセス スクリーニングのように) があります。

[#8]

アイデアを提供してくれた@jthiと@hogiに感謝します。

[#9]

アドインをありがとうございます。必要なものにかなり近いです。

Sort(nc)を追加するだけです

クールなトリック
1)

clb << Get Items("Column Reference");

... 文字列ではなく列参照を返します

2)

Insert Into( list of lists[i], item )

... リストの詳細な操作、すごい!

3) 複数回答のヒストグラム - 私は大ファンです!
マウスを 2 回クリックするだけで、表や要約、集計では不可能な詳細な統計情報を取得できます。

ただし、同じグラフ ビルダー オブジェクト内で、複数の応答プロパティを持つ別の列を使用することは避けてください。
Re: グラフ ビルダーのバグ? 複数の応答 + 複数のヒストグラム

視覚化を試してみます。複数の回答の失敗情報と「最優先」の失敗情報を1つの画像に組み合わせます。タイミングは完璧です。v19EA4では、色に複数の回答列を使用することはもうできません。

多分：
シグマを MAD に基づく堅牢なバージョンに置き換えます。そうすれば、極端な外れ値によって他の外れ値が「伸びた」カーペットの下に隠れる機会がなくなります : )

[#10]

故障したデバイスのプロットについては、棒グラフの代わりに次の操作を行います。

ヒストグラム チャートを使用すると、複数の障害の相関関係についてさらに詳しく知ることができます。