ライフデータプラットフォームの競合するリスク混合物とサブサンプル間の分布パラメータの不一致こんにちは、みんな、
私が使う生命分布からのプラットフォーム信頼性と存続分布を信頼性の結果に適合させるため。
故障の原因を区別するために、2つのワイブル分布を使用しました。競合するリスクの混合の生命分布プラットフォーム（下のグラフと添付ファイルを参照）。
部分1 1番目のワイブル分布に関連する信頼性結果の競合リスク混合物レポート種の一部からの値（黄色でマーク）。
の生命分布プラットフォームワイブル分布は、信頼性結果の[1-（部分1）]％サブセットに適合しました。
私が理解している限り、2番目の分布のワイブルパラメータは競合するリスクの混合レポートとサブセット一致する必要がありますが、実際には一致しません（黄色でマークされています）。
ワイブルパラメータが2番目の分布の間にある理由競合するリスクの混合レポートとサブセット異なっています？
他のRe：ライフデータプラットフォームの競合するリスク混合物とサブサンプル間の分布パラメータの不一致Competing Risk Mixtureに適合した場合、データは障害の原因に関する情報がないことを意味しました。
変更されたデータを適合させ、2番目の原因によるサブセットとして扱う場合、障害の原因に関する具体的な情報を提供します。
異なるデータ、異なるモデル、したがって異なる結果。
また、データを変更する方法もわかります。 最初の25行を重み= 26の1行に統合しました。 その単一の行を使用して、最初の原因による障害を表すことをお勧めします。 原因について正しいと仮定すると、データを変更する方法は正しくありません。 例として2番目の行を取り上げます。最初の原因により、[0.25,0.5]の間で失敗します。 [0.5、MISSING]として変更する必要があります。これにより、2番目の原因による右打ち切り観測として扱われます。つまり、2番目の原因によって失敗した場合、0.5以降のいずれかの時点で発生することになります。
とにかく、私が説明したようにデータを変更しても、結果はとにかく同じにはなりません。 情報が異なり、モデルが異なり、結果が異なります。
Re：ライフデータプラットフォームの競合するリスク混合物とサブサンプル間の分布パラメータの不一致親愛なるpeng_liu、
迅速かつ明確な回答をありがとうございます。
信頼性データを2つの障害モードに分割するための提案された変更を行いました。部分1からの値競合するリスク混合レポート。
ワイブルαとβグループ2の分布パラメーター（下のグラフを参照）は、ワイブルと同じ値を取得しましたαとβ上記の私の投稿のサブセットからの分布パラメータ。
PS
する方法はありますか競合するリスクの混合のXによるフィットライフプラットホーム？
Re：ライフデータプラットフォームの競合するリスク混合物とサブサンプル間の分布パラメータの不一致あなたがしたことは私が提案したことではありません。 「LifeDistribution-CompareGroups」を使用して最後に行ったことは、このディスカッションスレッドの3番目の分析です。 あなたが行ったことは、2回目の分析で行ったことと技術的に同じです。 そのため、「同じ」結果が得られます。 目的がわからないので、具体的なデータのご案内はやめます。 以下では、JMPサンプルデータセットを使用してポイントを作成します。これは、このスレッドを読む読者に一般的に役立ちます。
初め、 "競合するリスクの混合" と "競合する原因"は2つの異なる分析です。 「競合するリスク」と「競合する原因」という用語は、文献では同じ意味で使用される場合があります。 それらは両方とも観測の列を取り、各観測はイベントまでの時間の観測です。 そして、それぞれの観察は原因に関連付けられています。 しかし、いくつかの実験では、あなたは原因を知っていました。他の実験では、あなたはしません。 失敗の原因がない場合は、競合するリスクの混合を使用します。 故障原因がある場合は、「競合原因」を使用します。 競合するリスク混合は、個々の故障原因の分布を推測するのに役立ちますが、個々の観察の原因を確実に知ることはできません。 競合する原因は、個々の故障原因の分布に適合し、故障原因は既知の情報です。 通常のユースケースでは、どの分析を使用するかについて混乱が生じたり、分析タイプを切り替えるためにデータを変更したりしないでください。 「Appliance.jmp」は、競合する原因を説明するための信頼性サンプルデータフォルダの下にあるサンプルデータです。 テーブルに原因コード列があります。 信頼性サンプルデータフォルダの下のサンプルデータである「MixtureDemo.jmp」の列「Y2」は、競合するリスク混合物を示すために作成されています。 表に原因情報はありません。
第二に、競合する原因を使用する場合、ユーザーがデータを変更する必要はありません。 ソフトウェアは、モデルに合うようにユーザーのデータを変更します。 これがソフトウェアが概念的に行うことです。 例として「Appliance.jmp」を使用します。
- すべての原因コードについて、データ全体のコピーを作成します。 現在の原因コードが9であるとします。 そして、私は36行のデータ全体のコピーを持っています。
- 左と右の2つの新しい列を作成します。
- すべての行について、原因コードが9の場合、タイムサイクルを左と右の両方に単純にコピーします。 行の例、2番目の行。
- 原因コードが9でない場合は、Time CyclesをLeftにコピーしますが、Rightに欠落している値を入力します。 これは正しい打ち切り観測を表していることに気付くかもしれません。 例として、失敗の原因が1である最初の行を取り上げます。 競合する原因であるため、原因1が最初に発生しました。 1が発生しなかったふりをして、原因9が原因でシステムが故障した場合、故障時間は11サイクル後のどこかになりますが、いつかはわかりません。 したがって、この行の場合、ソフトウェアは11を左にコピーし、右に欠落している値を入力します。
- これで、コード1を発生させるために分布を適合させたい場合、LeftとRightがY TimetoEventロールに移動する必要がある新しい列になります。
新しいデータは次のようになります。
次のようにLifeDistributionを使用して変更されたデータを分析する場合：
競合原因分析からのものと同じワイブル推定値を取得できます。
これは、Appliance.jmpに埋め込まれたスクリプトを実行することによる競合する原因の結果です。
そして、これは修正されたデータを使用した生命分布の結果です。
すべての原因コード値に対して繰り返します。 そして、すべての原因の配布の完全な結果を取得します。 ソフトウェアはユーザーのためにそれらすべてを実行し、最終的にすべての適合した分布をシステムの障害分布である1つに集約します。
結論として、強調したいのは「競合するリスクの混合" と "競合する原因"は2つの異なる分析です。 故障原因の情報があるかどうかでどちらを使用するかを決定します。
最後に、最後の質問ですが、Fit Life by Xは、競合するリスク混合タイプの分布をサポートしていません。
