756834_ja-JP

liliconcom

でも、どうすればいいの？JMPで信頼性モデルを使ってイベント予測を行う（2021-US-30MP-823）

ブラッドフォード・フォークス、Optimal Analytics エンジニアリング ディレクター

数週間、あるいは数ヶ月かけてデータを収集し、信頼性モデルを構築した後、「次は何をすればいいのか？」という疑問が湧いてくるかもしれません。あるいは、「何台が故障するのか？」という疑問が湧いてくるかもしれません。JMP Proには、少し手を加えるだけでこうした疑問に答えられるプラットフォームがあります。修復可能システムシミュレーション（RSS）プラットフォームでは、信頼性モデル（あるいはモデル群）を入力して、事象の発生頻度とその影響度を予測できます。このプレゼンテーションでは、信頼性モデルから事象予測へと進む方法を、RSSプラットフォームの生成を自動化する手法を用いて解説します。出力結果を基に、事象予測、年間ダウンタイム値、システム内の個々のモデルに関する疑問に答えるレポートの作成方法を紹介します。このプレゼンテーションでは、実践的な例に加え、JSLを使用してプラットフォームとレポート生成を容易にする方法についても説明します。

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

スピーカー	トランスクリプト
ブラッド・フォークス	「しかし、次に何をすればよいのでしょうか? JMP で信頼性モデルを使用してイベント予測を行う」という私の講演にご参加いただき、ありがとうございました。
	よく聞かれる質問は…信頼性モデルを構築したら、実際に何をすればいいのですか？ そして、信頼性モデルを使えば、実際にいつイベントが発生するかを予測できることを忘れている人が多いのです。
	そして、最初のイベントだけではなく、時間の経過とともにその製品に発生する可能性のある 2 番目、3 番目、または 4 番目のイベントも含まれます。
	少し自己紹介をさせていただきます。ブラッド・フォークスと申します。Optimal Analyticsのエンジニアリングディレクターを務めており、企業の皆様と協力し、データの理解、課題の特定、そしてより効率的なビジネス展開の実現を支援しています。
	その役職に就く前は、信頼性エンジニアリングの分野で約 9 年間勤務し、部品の信頼性を理解し、時間の経過とともに部品が実際にいつ故障するかを把握する方法に取り組んでいました。
	私は JMP を 8 年ほど使っています。JMP 10 あたりだと思います。よく覚えていませんが、かなり前のことなので、どのバージョンを使っていたかは忘れてしまいました...当時は使っていました。
	私のお気に入りのJMPツールでは、信頼性モデリングが使われているため、寿命分布をよく使います。適合モデルとJSLもよく使います。
	スクリプトを使うことで、様々な新しいツールや新しい遊び方ができるようになります。では、なぜ今日これをご紹介したいのでしょうか？
	なぜなら、この質問は、モデル構築の最後に出てくることが多く、その時点まではあまり考えられていないからです。
	モデルを完成させて、たくさんの確率を導き出した後、次に何をすればいいのか分からなくなることがあります。そこで、モデルを構築し、さらに先に進む際に実行できる選択肢の一つをご紹介します。
	さて、今日お話しするのはイベント予測についてです。モデルを構築すると、このようなグラフをよく目にするでしょう。個々の時間、
	これらはハードウェアや製品のライフサイクルかもしれません。例えば、ブレンダーや、寿命が短いかもしれないキッチン家電や小型家電などです。
	非常に長い期間です。そのため、これらのうちいくつかは非常に早く失敗し、いくつかは非常に遅く失敗するでしょう。
	しかし、結局のところ、これらのことがいつ起こるか、つまり故障の確率が出てきます。つまり、ここに来て、「なるほど、故障の約90%は4年以内に発生するだろう」と言うかもしれません。
	それは素晴らしいですね。初期の故障をある程度理解し、現場で部品が故障する確率を推測するのに役立ちますが、実際にこれらの製品を購入したり使用したりする必要がある人にとっては、あまり役に立ちません。
	実際にこれらを使用している顧客にとって、どれくらい長持ちするかは気にしません。一定期間に何個購入する必要があるかなど、知りたくないかもしれません。
	ライフサイクル全体の中で、おそらく。彼らは10年先を見たいだけなので、10年間でどれだけの製品を購入すれば生き残れるのか、といったことを考えているのです。
	そこで、イベント予測が登場します。イベント予測の本質は、分布を取得してそれを反転させることです。つまり、時間の分布は保持されます。
	ここで示されているイベントの発生時間と、イベントの確率はどれくらいでしょうか。それでは
	これらのイベントがどのくらいの頻度で発生するかを見てみましょう。最初のイベントは8歳半頃、2番目のイベントは9歳半頃発生するかもしれません。
	3つ目のイベントは…これはすべて1つの顧客に関するものです。つまり、これはすべて1つの顧客、1つのユースケースであり、彼らにとっては、つまり、故障までの期間です。
	ここにあるすべての部分、すべての間隔、そしてこれらの置換を調べます。つまり、ここにある
	お客様が実際にこれを見るのは20年以上先のことです。ですから、お客様は…おそらく…その20年間耐え抜くためには、少なくとも3つの部品が必要だということを知りたいと思うでしょう。
	したがって、このランダム選択とシミュレーションの一部を使用することで、これらの部品をどのくらいの頻度で交換する必要があるか、顧客がどのくらいの頻度で製品を購入する必要があるかを理解することができます。
	それで、これはどのように実用的なのでしょうか？そうですね、結局のところは代替品が必要になります。
	交換部品については、どのくらいの頻度で新しい部品、あるいは新品同様の部品を取り付けているのでしょうか？
	修理可能なシステムと修理不可能なシステムです。修理可能なシステムとは、
	再び走れる状態になるまで、そして新品同様ではないかもしれない状態まで回復するまで。例えば、タイヤに穴が開いたとしましょう。漏れている部分を塞げば、そのまま走り続けることができます。
	修理完了です。でも、もしタイヤを新品同様になるまで修理して、二度と故障しないようにできたらどうでしょう？
	タイヤの場合、それはあまり現実的ではないかもしれませんが、他のものの場合は、部品を交換したり、部品の一部を切り取って、故障した部品だけを交換したりする必要があるかもしれません。
	部品を新品同様に修理すると、修理不能なシステムになってしまう可能性があります。そのため、修理を行ったとしても、新品同様にするためには
	少し状況が変わります。これは大きな注意点です。新品同様とはどういう意味か、多くの考慮が必要ですが、多くの場合、部品…あるいは人々は、
	彼らは修理して新品同様に修理し、「これは修理可能なシステムだ」と考えますが、信頼性の世界ではそうではありません。さて、少しこの議論は終わりにしましょう。
	代替品の話に戻りますが、単一のシステムを検討する際に、
	ここで何かを見て、ああ、そうだね、と言うかもしれません
	一つのシステムのために、
	部品はどのくらいの頻度で故障しますか？ 1人の顧客だけを例に挙げると、どのくらいの頻度で部品を購入しますか？ 最初の部品は4年間持ちました。
	その後、2台目を買わざるを得なくなりました。1台目はたった1.3年しか持たず、3台目も買わざるを得なくなり、今度は大活躍して8年も持ちました。
	つまり、結局のところ、12年間で3つの部品を買わなければならなかったわけですが、その差は大きいのです。これはあらゆる製品、携帯電話、
	その他の家庭用品。早く故障するものもあれば、遅く故障するものもあります。
	友達と話している時に、「ねえ、このひどい携帯を買ったんだけど、こんなに早く壊れるなんて信じられない」と言うかもしれません。すると彼らは、10年間も使い続けている同じ携帯について話すでしょう。もちろん10年とは言わないかもしれませんが、
	しばらくかかるかもしれません。つまり、このシステム、この顧客1社につき、部品を3回交換しなければならなかったということになります。
	複数のシステムを見てみると、時間の経過とともにこれらのことがどのくらい頻繁に発生するかが分かります。
	ある顧客が最初のシステムを導入し、その後 2 番目の顧客は、ほぼ同じ期間に 5 回または 6 回の交換を行った可能性があります。
	したがって、最初のシステムを見ると、少なくとも 4 年目までは障害は発生しないと考えられるでしょう。
	しかし、2つ目のシステムを見てみると、1年目に故障が発生しています。つまり、1年目と2年目に予想される平均的な故障数やイベント発生件数を計算すると、
	最初のシステムからはあまり多くのことが分かりません。つまり、データがなく、モデルに分布があって、ワイブル分布のベータとイータなどが分かっている場合、
	シミュレーションを使用すると、実際に持っているデータよりもはるかに先の 1 年目、2 年目、3 年目に顧客がイベントをどのくらいの頻度で予想しているかを予測することができます。
	そうすることで、複数のシステムを見て、そのシミュレーションを見ることで、どれくらいの頻度で
	これらの部品は毎年交換されます。このデータは7年間のイベント期間に基づいて作成されたものですが、
	暦年や顧客時間については、一時的に急増し、その後は交換品の水準がほぼ一定になるでしょう。
	シミュレーションでは、多少の跳ね返りが見られます。それがここにも見られます。もしこれを閉じた形で解くことができれば、きれいな直線が得られるはずですが、
	シミュレーションでは、ある程度のばらつきがあります。それがここに表示されているものです。線を引いて、平均的に見ると、
	1年に3分の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日かもしれません。ただし、これを年単位で計算すると、数字は非常に小さくなります。それがここに表示されているのです。
	ここでは全てのオプションについて詳しく説明するつもりはありません。ご覧の通り、スタンバイやK-of-Nなどを使ってできることは他にもたくさんあり、その多くはより複雑な分析に使用されます。
	さて、分析を実行します。ここに記載された 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年目までスクロールすると
	パート2では、シミュレーション1にイベントが1つあることが表示されます。つまり、発生する可能性のあるあらゆる年の組み合わせについて、これらのイベントを並べているだけです。
	そうですね、そのレベルの情報があれば、すべてのシミュレーションにわたってそれが得られ、ご覧のとおり 4,000 件のレコードがあり、それが年、シミュレーション、およびパーツの可能なすべての順列になります。
	しかし、実際にはこれらを平均化したいのです。平均化して、シミュレーションの数、つまり行数、年値、そして部品の数を確認したいと思います。40行まで減らせば、はるかに扱いやすく、理解しやすくなります。
	パート2では、最初に少し急上昇し、その後は落ち着いている様子が見られます。
	これはシミュレーションであり、実行したイベントは 100 件だけなので、結果は変動しますが... または、100 回のシミュレーションですが、一定の置換状態が見られる可能性があります。
	しかし、これを累積的な視点から見てみると、顧客が10年後にどれくらいの数の交換を期待するかが分かります。それではパート2では、
	顧客が最初の部品をいつ交換する必要があるのか​​知りたいとします。最初の部品とは何ですか？最初の部品とは何ですか？
	4年生と5年生の間、つまり4年生が終わった直後に起こります。そして2つ目はちょうど…7年生くらいに起こります。
	3 番目は、約 10 年目に発生します。つまり、最初は故障があまりない、少し上昇する期間があるのですが、その後は安定した状態になり、約 3 年ごとに部品の交換が必要になります。
	これは、顧客にとっても、ビジネスの計画にとっても、あるいはサプライ チェーンの取り組みにおいても、このようなことを実行したい場合に非常に役立ちます。
	修理可能なシステムのシミュレーションから得られるこのイベント予測は、故障の確率や発生時期だけでなく、部品の数についても簡単に把握できる方法です。
	今日お話ししたいもう一つのことは、修復可能なシステムのシミュレーションを少し簡単にする方法です。
	きっと気が遠くなるようなこともあるでしょう。新しいツールなので、自分が何を扱っているのかすべてを把握しているわけではないかもしれませんが、
	テンプレートから始めて、テーブルから始めると、修復可能なシステムのシミュレーションの構築がはるかに簡単になります。
	最終的にモデルを構築するには、約13個のデータが必要になります。これらのほとんどは、あなたが思いもよらないバックグラウンドで処理されていますが、これらをテーブルやテンプレートにまとめると、
	ここには様々な列がありますが…13列と言いましたが、実際にはもっと少ない列数で済みます。ここでいくつか変更を加えて、便利な機能をいくつか実装しました。
	しかし、実際には分布、モデルの種類、パラメータ、時間単位など、JMPではデフォルトで設定されているものがあり、変更することも、
	これらは追加するものです。つまり、それぞれに、ブロックが失敗した場合に新しいものに置き換えるものがあり、これらを調整して、イベント名とプロセスを異なる方法で接続することができます。
	私の世界では、行動の変化が頻繁に見られます。最初の数年間はこれが代替率で、次の数年間はこれが代替率だと理解しておく必要があるかもしれません。
	あるいは、競合する障害モードがあり、それらを利用したい場合もあるでしょう。ここでご紹介するソリューションは、そうした障害モードの多くに対応できます。
	すみません、これは決して完璧ではありません。これは
	あなた自身のユースケースに合わせて調整する必要がありますが、結局のところ、テンプレートから始めることは開発をスピードアップするための素晴らしい方法です。
	調整ができるように…つまり、細かい調整をその場で行えるように。ここに便利なスクリプトがあって、それをクリックすると、修復可能なシステムのシミュレーションが自動的に生成されるんです。
	こちらを見ると、ベータ版が 1.86 または 826、アルファ版が 153 の最初のパーツがあります。
	この表を修復可能なシステムのシミュレーションに応用するだけです。
	もっと複雑なものなので、この部分はこれで終わりにしたいと思います。
	ここに14個のパーツがあります。これらの分布は必要に応じて変更できます。
	しかし、ここでは他の種類のイベントも確認したいので、分布を分割して
	一定期間が経過すると、形状が変化したり変化したりします。製品導入、つまり全社的に実施される製品アップグレードをモデル化しようとしているのかもしれません。あるいは、競合する故障モードがあり、それを考慮に入れたいのかもしれません。
	スクリプトでこのテンプレートを使うと、これらすべてを非常に簡単に処理できます。どれだけ速かったかお分かりいただけたでしょうか。1秒かそこらで
	このモデルを生成するにはどうすればいいでしょうか？もし私がこれをもう一つ作りたいなら、おそらくこれは
	対数正規分布。
	ここでそれをやれば、
	私の脚本を見に来てください
	そして
	それをもう一度実行すると、別のモデルが得られます（そういえば、何だったっけ？パート5）。
	パート5は対数正規分布になりました。様々な反復やモデルを試すのはとても簡単で、毎回新しいモデルが生成されます。
	この図に表のラベルを付けます。このテンプレートと、ここに埋め込まれたスクリプトを使って分析を行い、イベント予測を時系列で把握するのは非常に便利です。

自動化とスクリプト基本的なデータ分析とモデリングコンテンツの編成実験計画法マスカスタマイゼーション予測モデリングと機械学習品質およびプロセスエンジニアリング信頼性分析