398676_ja-JP

liliconcom

しかし、今、私は何をすべきでしょうか？ 信頼性モデルを使用した JMP でのイベント予測 (2021-US-30MP-823)

レベル: 中級

 

Bradford Foulkes 氏、最適分析担当エンジニアリング ディレクター

 

数週間または数か月かけてデータを収集し、信頼性モデルを構築すると、多くの場合、「さあ、どうする?」という気持ちになります。あるいは、「何人が失敗するでしょうか?」という質問もあるかもしれません。 JMP Pro には、いくつかの調整を加えて、これらの質問に答えることができるプラットフォームがあります。修復可能システム シミュレーション (RSS) プラットフォームを使用すると、信頼性モデルまたはモデルのシステムを入力して、イベントがどのくらいの頻度で発生するか、およびその影響がどのようなものかを確認できます。このプレゼンテーションでは、RSS プラットフォームの生成を自動化する方法を介して、信頼性モデルからイベント予測に至る方法を説明します。出力を取得したら、イベント予測、年間ダウンタイム値、システム内の個々のモデルに関する質問に答えるレポートを作成する方法を示します。このプレゼンテーションでは、実践的な例と、JSL を使用してプラットフォームとレポートの生成を容易にする方法について説明します。

 

 

自動生成されたトランスクリプト...

 

スピーカー	成績証明書
ブラッド・フォークス	「But What Do I Do Now?」に関する講演にご参加いただきありがとうございます。 JMP で信頼性モデルを使用してイベント予測を行う。
	非常に頻繁に質問されます...信頼性モデルを構築したら、それを実際にどうすればよいのですか? と尋ねられます。 そして、多くの場合、信頼性モデルを使用してイベントが実際にいつ発生するかを予測できることを忘れてしまいます。
	そして、最初のイベントだけでなく、おそらくその製品で時間の経過とともに 2 回目、3 回目、または 4 回目のイベントが発生する可能性があります。
	それで、私自身について少し。 私の名前はブラッド・フォークスです。 私は Optimal Analytics のエンジニアリング ディレクターを務めています。企業と協力して、企業が自社のデータを理解し、障害を特定し、より効率的に進めるよう支援しています。
	その職に就く前は、信頼性エンジニアリングの分野で約 9 年間働き、部品の信頼性をどのように理解し、部品が時間の経過とともに実際にいつ壊れるかを把握する方法に取り組んでいました。
	私は JMP を約 8 年間使用しており、JMP 10 あたりだったと思います。 よくわかりませんが、かなり前のことなので、どのバージョンを使用していたか忘れました...その時は使用していました。
	私のお気に入りの JMP ツールでは、信頼性モデリングが存在するため、寿命分布をよく使用します。 フィットモデルは、私が非常に頻繁に使用するJSLです。
	スクリプトを使用すると、さまざまな種類の新しいツールやおもちゃを利用できるようになります。 では、なぜ今日これを紹介したいのでしょうか?
	なぜなら、多くの場合、この質問はモデルの構築の最後に浮上し、それまでは深く考えられなかったからです。
	モデルが完成し、大量の確率が得られたとしても、次に何をすべきかまったく分からないかもしれません。 ここでは、モデルを構築した後、先に進むことができるオプションの 1 つを示します。
	さて、今日私たちがイベント予測に関して話していることは、モデルを構築するときに、ここでこの種のプロットを頻繁に見ることに慣れています。 それぞれの時間を過ごしていただけますので、
	そしておそらく、これらはハードウェアまたは製品のライフサイクルです。 それがミキサー、あるいは長持ちしないかもしれないあらゆる種類のキッチン家電や小型キッチン家電だとしましょう。
	恐ろしく長い時間。 したがって、これらの中には非常に早い段階で失敗するものもあります。非常に遅い段階で失敗する人もいます。
	しかし、結局のところ、これらのことが起こると、失敗する可能性が高くなります。 ここに来て、「そうですね、失敗の約 90% は 4 年までに発生するでしょう」と言うかもしれません。
	そうですね、それは素晴らしいですね。 これは、最初の失敗をある程度理解し、現場で部品が故障する確率を推定するのに役立ちますが、実際にこれらのものを購入したり使用しなければならない人にとって、これはあまり役に立ちません。
	実際にこれらを使用している顧客にとっては、それがどれくらい持続するかなどは気にしません。 彼らは知りたくないかもしれません、一定期間に何個購入する必要があるか、
	おそらくライフサイクル全体の中で。 彼らは 10 年だけを見たいのですが、それが生き残るためには 10 年間で何台購入する必要があるでしょうか。
	そこで登場するのがイベント予測です。 そして、イベント予測とは実際には、分布を取得し、それをひっくり返して、時間の分布を維持することです。
	ここにあるイベントが発生するまでの時間と、イベントの確率はどれくらいですか。 そして今も
	これらのイベントの一部がどのくらいの頻度で発生するかを確認できます。 つまり、おそらく最初の出来事は約8年半で起こり、2番目の出来事は9年半で起こります。
	3 回目のイベント...ただし、これはすべて 1 人の顧客です。 したがって、これはすべて 1 人の顧客、1 つのユースケースであり、彼らにとっては、失敗するまでの期間です。
	ここでこれらすべての部品を調べ、これらすべての間隔とこれらの交換を調べます。 それで、ここで、
	顧客が実際にこれを見ているのは 20 年以上の時間です。 彼らは...だから彼らは知りたいと思うでしょう...私はその20年を生き抜くために、少なくとも3つのパートが必要です。
	したがって、このランダムな選択とシミュレーションを使用することで、これらの部品を交換する必要がある頻度と、顧客が製品を購入する必要がある頻度をまとめることができます。
	それで、これはどのように実用的なのでしょうか？ さて、いよいよ交換作業に入ります。
	交換品については、どれくらいの頻度で新しい部品、または新品と同等の部品を入れていますか? それで
	修復可能なシステムと修復不可能なシステム。 そして、修復可能なシステムとは、問題を解決できるシステムのことです。
	もう一度実行できるという点ですが、おそらく新品ほど良くはありません。 タイヤに穴があったとします。 漏れを塞げば、そのまま進み続けることができます。
	それは修理されました。 しかし、タイヤを新品同様に修復でき、二度と故障しないとしたらどうなるでしょうか?
	タイヤの場合は、それほど現実的ではないかもしれませんが、他のものでは、部品を交換するか、部品の一部を切り取って、故障したその部分だけを交換する必要があるかもしれません。
	部品を新品同様にすると、システムが修理不能になる可能性があります。 したがって、修理を行ったとしても、新品同様にするには、
	それは状況を少し変えます。 これは大きな警告です。新品同様とは何かについては、多くの考慮が必要ですが、非常に頻繁に、一部の部分に対処していると思います...あるいは、人々は、
	彼らは修理し、新品同様に修理し、これは修理可能なシステムだと考えていますが、信頼性の世界ではそうではありません。 さて、それではちょっと石鹸箱から離れます。
	交換品に戻ります。 ある種の単一システムを見ていると、
	あなたはここで何かを見て、「わかった」と言うかもしれません。
	1 つの単一システムの場合、
	部品が故障する頻度はどれくらいですか? では、たった 1 人の顧客に注目した場合、彼らはどれくらいの頻度で商品を購入しているのでしょうか? そして、最初の部分はここで4年間続きました。
	その後、2 台目を購入する必要がありました。 そのモデルは 1.3 年しか持たず、その後 3 台目を購入する必要があり、このモデルは大失敗して 8 年間続きました。
	結局のところ、12 年間で 3 つの部品を購入する必要があることになりますが、ばらつきは大きくあります。 このことは、あらゆる種類の製品、一部の携帯電話、
	その他の家庭用製品。 いくつかのことは早期に失敗します。いくつかのことは遅れて失敗します。
	あなたは友達と話しているときに、「おい、私はこんなひどい携帯電話を持っているんだ」と言うかもしれません。 こんなに早く失敗したなんて信じられない。 そして、彼らは10年間持っていた同じ携帯電話についてあなたに話すでしょう。 確かに10年はかからないかもしれないが、
	しばらくかかるかもしれない。 結局のところ、この 1 つのシステム、この 1 人の顧客では、部品を 3 回交換する必要がありました。
	さて、複数のシステムを観察すると、これらのことがどれくらいの頻度で発生するかについて、時間の経過とともに把握することができます。 それで
	ある顧客が最初のシステムを使用し、次に 2 番目の顧客が、おそらく同じ期間で 5 台または 6 台の交換を行った可能性があります。
	したがって、最初のシステムを見てみると、少なくとも 4 年目までは障害は発生しないだろう、と言えるかもしれません。
	しかし、2 番目のシステムを見ると、1 年目に障害が発生しました。 したがって、1 年目または 2 年目に予想される平均失敗数または平均イベント数を把握しようとしている場合、
	最初のシステムでは多くのことがわかりません。 ここで、データがなく、モデル内にワイブルなどのベータとイータの分布が存在する場合、
	シミュレーションを使用して、一部の顧客が 1 年目、2 年目、3 年目、さらには実際に保有しているデータよりもはるかに先の期間にどのくらいの頻度でイベントが発生するかを予測することができます。
	そうすることで、それらの複数のシステムとそのシミュレーションを確認することで、どのくらいの頻度での頻度がどのくらいであるかをある程度理解し、傾向が見え始めることができます。
	これらの部品は毎年交換されます。 したがって、このデータは 7 年間にわたるイベント時間からのみ構築されたものかもしれませんが、
	なぜなら、カレンダーの時間や顧客の時間では、ある種の急増があり、その後、ある種の横ばいのレベルの代替品に横ばいになるからです。 今
	シミュレーションでは、多少のバウンスが見られます。それがここで見られるものです。 これに対して閉じた形式の解決策があれば、きれいな直線が得られるでしょうが、
	シミュレーションでは、ある程度の変動が得られます。 それがここにあります。 つまり、線を引くと、平均して次のことがわかります。
	人は、これらの 3 分の 1 を 1 年に交換すると予想するかもしれません。 したがって、3 年後には、一度動作し始めれば、代替品が登場することが期待できます。 最初は少しずつですが、その後は横ばいになります。
	それでは、これが何を意味するのか例を見てみましょう。
	ここにデータのテーブルがあり、ここにモデルがあります。 したがって、このモデルは単なるランダムなワイブルです。 JMP で使用できるさまざまな関数に慣れていない場合は、
	ランダムなワイブル、ワイブル分位数、ワイブル分布、ワイブル密度を使用できます。 これらはすべて、さまざまなディストリビューションに適用できる関数です。
	この場合、特定の分布からランダムな点のセットを選択しています。 私のディストリビューションのベータ版は 1.2、イータ版は 3 です。
	したがって、ここでこれらのランダム...ランダムなイベントを選択することで、
	これらはすべて個別のイベントであり、これが最終的にモデルに組み込まれることになります。 部品の故障に基づいてモデルを構築すると、最終的にはどうなるか、通常、最終的にそこに入力される日付が次のとおりです。 ただし、迷うのは、これが実際に顧客にどのような影響を与えるかということです。 それで時間が経つにつれて
	顧客は、20 年、30 年、40 年で何台交換できるか知りたいと考えているかもしれません。
	そこで、システム イベントの合計時間を確認する必要があります。 これは個々の時間の累積にすぎないため、8.3 が最初、1.2 が 2 番目というようになります。
	2 番目のシステムに進むと、1.8、3.9、5.9 が得られるため、これは個々の時間の単なる累積値になります。
	ここで覚えておくべきことは、これらすべての平均を計算しようとするとき、
	システム番号を見ていると思いますが、実際にこれが発生した年は、運用 2 年目に 1.8 年が発生したことになります。
	そして、それは、適切な年の失敗を確実に特定したいので、ここで覚えておくべき重要な違いです。
	つまり、0.6 ですが、それが最初の場合は 1 年目になりますが、実際には年が増えているだけです...システム時間...ここではシステムが 1 年ずつ増えています。
	これで、「よし、これですべてが揃ったので、イベントの数を数え、このシステムと年を調べて、ちょっとした分析を実行できる」と思われるかもしれません。 つまり、JMP には、これらすべてを実行してくれる優れたツールが実際に用意されています。
	それで
	JMP には修復可能システム シミュレーションと呼ばれるツールがあります。
	そしてこのツール、
	それは知っています...JMP 13、おそらく JMP 14 あたりで登場したと思います。 数年前からあります。
	これが必要なほど宣伝されていることはわかりません。なぜなら、これは非常に強力なツールですが、ここでは多くの人がその価値を理解していないと思うからです。
	それで、それは何ですか、ここで見ているのはシステムですか。 それで、おそらく、あるいは今、ここには 2 つの部分がありますが、おそらく私のシステムは実際には
	7、8 個の部品、あるいはギアボックス全体、ポンプなどです。 これらすべての部品が連携して機能するので、そのうちの 1 つが故障した場合でも、
	システム全体に障害が発生するため、何がイベントなのか、そのイベント時間が何時なのかを把握したいと考えます。 したがって、これらのそれぞれで、ワイブルが何であるか、またはモデルが何であるかを説明します。ここではベータ版 1.2 とアルファ版 15 を示します。
	これは年単位の時間です。必要に応じて、確かに別の分布を選択できます。
	そして、イベントが発生した場合に何が起こるかを言うことができます。 では、ブロックの場合...ここではブロック障害が発生していますが、実際に障害が発生した場合はどうなるのでしょうか?
	で、結果的には新品に交換することになるので、部品だけ交換したいと思います。 ここにはさまざまなオプションがたくさんあります。おそらく最小限の修理を行うこともできますが、その代わりに、これを真新しい部品と交換したいと言いました。したがって、これは新品同様の...新品同様のモデルになります。
	そして、ダウンタイムの量を含めることができます。 それで、これを修理するのにどれくらいかかりますか？ 修理にかかった平均時間はどれくらいでしたか？ 定数値でも構いません
	あるいは、それは...すぐに言うこともできますし、かかる時間も気にしないこともできますし、リストを与えてそこから選択することもできます。 ここでもいくつかの配布を行うことができます。
	これらのツールも同様です...そして今、私はここで非常に単純なシステムを構築しました。 既知のディストリビューションを含む 1 つのパート、または既知のディストリビューションを含む 2 つのパートがあります。
	これらのいずれかが故障した場合、交換の時間が与えられるため、2 番目のオプションを選択できます。
	そして、ご覧のとおり、ここに入れています。 ここで、選択肢はシミュレーションと同じ時間単位である必要があります。
	そこで、シミュレーションとして年を選択しました。 これは数年単位の話なので、何かを準備するのにかかる時間はわずか 1 時間、2 時間、あるいは 1 日かかる場合もあります。 ただし、これを何年にもわたって計算すると、その数は非常に小さくなります。したがって、それがここに表示されるものです。
	ここではすべてのオプションについて説明するつもりはありません。 ご覧のとおり、スタンバイで実行できることは他にもたくさんあります。N のうちの K であり、その多くはより複雑な分析に使用されます。
	さて、分析を実行します。ここにリストされている 20 年間、シミュレーション数を 100 として実行します。 多くの場合、それ以上の値が必要になりますが、デモンストレーションの目的で、100 に設定し、シードを 1234 に設定します。
	それで、ここで素晴らしい大きな大きな出力が得られます。最初の出力は常にnumberという名前で、非常に役に立ちます。
	でも、これを見れば大丈夫だと思うかもしれませんが、これをどうすればいいでしょうか？ ここに来て、この分析を開始して、
	コンポーネントごとの合計ダウンタイムを確認したい場合があります。 つまり、コンポーネントが発生する可能性のあるダウンタイムの分布はどのようにして...またはどのようなものになるのでしょうか?
	しかし、この部品は何回交換する必要があるのか、という 20 年以上にわたる疑問に実際に答えることはできません。
	そこで私はスクリプトを書きました。このジャーナルをダウンロードすると、そこに含まれるすべてのスクリプトが含まれることになります。
	私はこれをボタンとして設定しましたが、実際のスクリプトはこの下にありますので、使用したい場合は参照してください。
	それで、ボタンをクリックするだけで、たくさんのことが起こります。 そこで私は、これらのイベントが年間でどれくらいの頻度で発生すると予想されるかを計算してみました。 システムの観点から見ると、
	失敗イベントをサブセット化し、年の値を設定しました。 覚えているかもしれませんが、年の値は切り上げられるため、3.8 年は 4 になります。
	ここで、これはカレンダー時刻を調べ、これは使用している可能性のあるシステム時刻を調べます。 個々の時間を調べていないので、列 1 から列 2 までの各時間の間の時間は 1.8 年程度です。
	しかし、私たちはシステムを見ているので、実際には 5.69 を数えています。
	今度はそれを変換したいと思います...これらすべての値を何か役立つものに変換したいと思います。
	ただし、覚えておくべき重要なことは、毎年のイベントの平均数を調べる場合は、イベントが発生しなかった年に注目する必要があるということです。 したがって、この最初のシミュレーションでは、最初のイベントが 4 年目に発生します。
	しかし、1、2、3 にはゼロが必要であり、それが私のスクリプトの動作です。 私のスクリプトはセットに入るようなものです
	私が見たいもののパターン。 そこで、パート 1 を見ていきたいと思います。年の値とシミュレーション ID を調べてから、イベントが実際にいつ発生したかを見ていきたいと思います。 ここでは、最初のパート 1 のイベントが 10 年目に発生することがわかります。
	そして、それがここに追加されると、それが分析に更新されます。 パート 2 まで下にスクロールすると…
	シミュレーション 1 のパート 2 まで下にスクロールすると、
	そこには...イベントはありません。
	シミュレーション 1 の最初のイベントはまだ先です...
	4年目まで。 4 年目までスクロールすると
	パート 2 では、シミュレーション 1 にイベントが 1 つあることがわかります。 したがって、実際には、これが発生する可能性のある年のあらゆる組み合わせについて、これらのイベントを並べているだけです。
	そうですね、そのレベルの情報があれば、すべての...すべてのシミュレーションにわたって情報が得られました。4,000 件のレコードがあることがわかりました。これは、年、シミュレーション、部品の考えられるすべての並べ替えに過ぎません。
	しかし、実際にはそれらを平均化したいのです。 そこで、平均をとり、シミュレーションの数、すなわち行数、年の値、そして部分を調べたいと思います。 行数は 40 行まで減り、はるかに管理しやすくなり、理解しやすくなります。
	パート 2 では、最初に小さな急増があり、その後横ばいになっていることがわかります。 そして
	これはシミュレーションであり、100 回のイベントしか実行しなかったので、跳ね返りますが、...または 100 回のシミュレーションでも、表示される可能性のある置換の一種の定常状態が得られます。
	ただし、これを累積的な観点から見てみると、これにより、顧客は 10 年間で何台交換すると予想されるかを知ることができます。 パート 2 では、
	顧客が、最初の 1 台をいつ交換する必要があるのか知りたいと考えているとします。 一番最初のものは何ですか？ 一番最初のもの
	それは4年目から5年目の間、つまり4年目の直後に起こるでしょう。 そして、2回目はちょうど...または7年目くらいに起こります。
	3回目は10年目くらいに起こります。 ご覧のとおり、最初は故障がそれほど多くない、このようなちょっとした登りがありますが、その後は安定した状態が続き、最終的には 3 年ごとに部品を交換する必要があります。
	これは、顧客にとって、ビジネスの計画にとって、さらにはサプライ チェーンの取り組みにとっても、このようなことを実行したい場合に非常に役立ちます。
	したがって、修復可能なシステムのシミュレーションからのこのイベント予測を使用することは、故障の確率やいつ発生するかだけでなく、部品の数についてアイデアを与えたり、理解を与えたりするための便利で迅速な方法です。 それで
	1 つ...今日お話したいもう 1 つのことは、修復可能なシステムのシミュレーションを少し簡単にする方法です。
	ですから、気が遠くなるかもしれません。 新しいツールなので、何を使っているのかすべてを知っているわけではないかもしれませんが、
	もし...テンプレートから始めてテーブルから始めれば、修復可能なシステムのシミュレーションを構築するのがはるかに簡単になります。
	したがって、最終的にモデルを構築するには、およそ 13 個のデータが必要になります。 これらのほとんどは、思いもよらないバックグラウンドで進行しますが、これらを表とテンプレートにレイアウトすると、
	ここにさまざまなコラムがあります... 13 と言っていますが、実際にはもっと少なくて済みます。 ここで実行できるいくつかの細かい作業を処理するために、ここにいくつかの変更を加えました。
	しかし実際には、分布、モデル タイプ、パラメータ、時間単位が必要になります。 これらはすべて、JMP のデフォルトで変更できるものであるか、または
	それはあなたが追加するものであるということ。 つまり、これらのそれぞれには、ブロックが失敗した場合に、新しいものと置き換えるものがあります。 これらは調整でき、イベント名とプロセスを異なる方法で接続することができます。
	私の世界では、多くの場合、行動の変化が見られます。 そしておそらく、最初の数年間は代替率であり、その後の数年間は代替率であるということを理解したいのかもしれません。
	あるいは、競合する障害モードがあり、それを利用したい場合もあります。 したがって、ここで紹介するものはその多くに対処できます。
	すみません、これは決して完璧ではありません。 これ
	間違いなくあなた自身のユースケースに合わせて調整する必要がありますが、結局のところ、テンプレートから始めることは開発をスピードアップし、
	調整できるようにするために...その場で微調整を加えます。 これがあれば、ここに素晴らしい小さなスクリプトがあり、スクリプトをクリックすると、修復可能なシステムのシミュレーションが生成されます。
	ここを見てみると、最初の...最初のパートがあり、ベータ版は 1.86 または 826、アルファ版は 153 でした。
	そして実際には、このテーブルを取得して、修復可能なシステムのシミュレーションに変換するだけです。 できるよ
	さらに複雑なもの。 それでは、これを閉じさせていただきます。
	これで 14 個のパーツができました。 必要に応じて、これらのディストリビューションを変更できます。
	しかし、ここで見ていきたい他の種類のイベントもあります。 ディストリビューションを分割したいのですが、
	一定の時間が経過すると、変化したり形が変わります。 おそらく私は、製品の導入、つまりフリート全体に広がる製品のアップグレードをモデル化しようとしているのかもしれません。 あるいは、競合する障害モードが存在するので、それを考慮に入れたいのかもしれません。
	したがって、スクリプトでこのテンプレートを使用すると、これらすべてを非常に簡単な方法で処理できるようになります。 これで、それがいかに速いかがわかりました。 あれは何ですか、1秒ほどで
	このモデルを生成するには? これをもう 1 つ作成したい場合は、おそらく、これを
	ログは正常です。
	ここでそれを行うことができます。
	私の台本に来てください
	そして
	それをもう一度実行してください。 そして、別のモデルを入手しました（さあ、それは何でしたか？ パート 5。)
	パート 5 は対数正規になりました。 さまざまな反復を試したり、さまざまなモデルを試したりするのは非常に簡単で、毎回新しいモデルが生成されます。
	ここで図にテーブルのラベルを付けます。 したがって、このテンプレートを使用して分析を実行し、イベント予測を理解するのに便利な方法です。ここに埋め込まれているスクリプトを使用して分析を実行し、時間の経過とともにイベント予測を理解します。

起こる品質と信頼性統計とモデリング