お時間を割いていただきありがとうございます。このビデオをご覧ください。
あなたがここにいるのは、あなたが使ったことがある、または使おうとしたからだと思います。
JMP 内の修復可能なシステムシミュレーション プラットフォーム。
もう少し詳しく知りたいかもしれません。
イライラすることもあるでしょう
自分ができないと思っていたことをやろうとしているのです。
今日は何をお話ししようと思いますか
ドキュメントでは詳しく説明されていないもの、
試行錯誤を通して学んだこと
ドキュメントに記載されていないもの
開発者と話して学んだことなど
プラットフォームに関するもの、見つけられないもの
他の方法はありません。
あなたはこのプラットフォームに多少なりとも触れたことがあるものと仮定します。
信頼性分析について少しはご存知だと仮定します。
並列設定とは何かという点について詳しく説明する必要はありません。
N 個のうち K 個となるものは何ですか、など。
いくつか例を挙げて説明したいと思います。
たくさんの材料があります。始めましょう。
さて、実際に見ていく前に
修復可能システム シミュレーション プラットフォームについて、概要を説明します。
おそらく、あなたは以前にも使ったことがあるでしょうし、使い慣れているでしょう。
3つの異なる要素についてお話しします
ドキュメントに記載されていないコンポーネントに関する側面
またはドキュメントで十分に説明されていません。
まず最初にブロックについてお話します。
ブロックは、修復可能なシステムシミュレーションを構築するために使用します
パラレル、K アウト オブ N、スタンバイなど。
したがって、各ブロックに対して、そのブロックにイベントを関連付けることができます。
ここに小さなオレンジ色のブロックがあります。それぞれのブロックは
1 つ以上の結果またはアクションを関連付けることができます。
私たちが見ている青い点は、
そしてそれは私のシミュレーションの構築に役立つでしょう。
例えば、ブロックが失敗したときに知りたいと思うかもしれません
そしてそのブロックが故障したら、そのブロックを修復したいと思うかもしれません。
修理には、たとえば 40 時間かかる場合があります。
これが、これらの RSS 図を作成する背後にある考え方です。
まずは、
ブロックの一般的な特性の一部。
結び目には6つの異なるブロックがあり、
これにより、図内で物事を結び付けることができます。
これら 6 つのブロックのうち 5 つは複合ブロックです。
それらは 2 つ以上のサブユニットで構成されるように構築されました。
JMP では、これらを 1 つのサブユニットで使用できます。
しかし、実際の使用例では、それらは 2 つ以上のサブユニットで構成されています。
イベントとアクションはブロック全体に適用されます。
これが重要なポイントです。
ブロック内のコンポーネントは個別に扱うことはできません。
スタンバイブロックを除く。
単一の配布が割り当てられます。
これら2つの項目を合わせると、修理などの
またはサブユニットのメンテナンスが不可能
これらの複合ブロック内にあります。
ブロック全体が壊れるまで待たなければなりません
そのブロックで実際に何かする前に
ブロックを修復する前に。
ブロック内で異なる分布が必要な場合は、
スタンバイを除いて、それもできません。
これについては、後ほど例を挙げて説明します。
すべての複合ブロックのサブユニット、
シリーズブロックを除いて、並列です。
これらの異なる複合ブロックを区別するもの
実行中のコンポーネントの数です。
ブロックがいつ失敗するか、ブロックがどのように古くなるか。
そこで私は複合ブロックのすべてを網羅した小さな表を作成しました
そしてそれらの特性によってどのように異なるのかを説明します。
スタンバイを除くすべての複合ブロックでは、
すべてのコンポーネントが同時に実行されます。
複合ブロックを使用すると、NユニットのうちKユニットを選択して実行できます。
残りのユニットはバックアップになります。
では、これらのブロックはいつ失敗するのでしょうか?
信頼性の経験があれば、シリーズブロックが故障することは明らかです
1 つのユニットが故障した場合。
並列ブロックはすべてのユニットが故障すると故障します。
K ユニット未満の場合は N 個中 K 個、など。
信頼性分析で当然予想されることは、
スタンバイと共有には別の障害方法があります。
スタンバイユニットには切り替え機構があります。
ブロック全体に1つのスイッチがある可能性がある
または、バックアップごとに 1 つのスイッチ。
スイッチが1つしかない場合、スタンバイが失敗する可能性があります
そのスイッチが故障した場合、または使用しようとした場合
私のバックアップユニットのそれぞれ
そして、それらのバックアップ ユニットのスイッチも故障します。
したがって、スイッチの障害がブロック障害の別の原因である可能性があります。
ストレス共有でも同じことが言えます。
しかし、Stress Sharing ではスイッチは 1 つしかありません。
最後の異なる特徴
これらの複合ブロック間の経年変化によって、ブロックの寿命が決まります。
最初の 3 つのブロックは、同じように古くなります。
ブロック内のすべてのサブユニットは均等に老化します。
スタンバイとストレス共有の場合、サブユニットは老化する可能性があります...
スタンバイの場合、それぞれ異なる経過時間になることがあります。
ストレス共有に関しては、明らかに老化の進み方が異なります。
スタンバイの場合、
事業部門ごとに単一の配布を選択できます。
私のバックアップユニットについては、
老化しないように選択できる――それがコールドスタンバイだ――
あるいは別の配分を与えることもできる
スタンバイモードのときにどのように老化するか
またはバックアップとして機能しているとき。
それは同じである可能性もありますが、私のオペレーティング ユニットが異なるものである可能性もあります。
つまり、2 つの異なるディストリビューションを選択できます。
問題は、また、
これらの複合ブロックと同様に、1つの分布が得られます
すべての運用ユニットに対して、すべてのバックアップに対して 1 つの配布を実行します。
組み合わせることはできません。
最後に、ストレスシェアリングでは、ストレスシェアリングは機能します
少し違います。
応力共有により、応力はブロック間で均等に分散されます。
しかし、サブユニットの1つが故障すると、
残りの運用ユニットには追加のストレスが伴います。
つまり、ストレスは失敗ごとに変化します。
その例を後ほど見てみましょう。
さて、皆さんが見つけたものの一つは、
あるいは、時々
もう少し柔軟性が欲しい
柔軟性を高める方法は、基本ブロックを配置することです
または、Parallel や K out of N のように基本ブロックを作成します。
私の複合ブロックの 1 つとして。
基本ブロックは、直列、並列、K out of Nのように簡単に配置できます。
スタンバイとストレス共有ブロックでは難しくなります
ユニットが 2 つ以上ある場合。
少し例を挙げます
これは、2 つの基本ブロックを含むスタンバイ セットアップを示しています。
それを実行する方法は比較的簡単です。
しかし、これを3つのブロックに拡張しようとすると、
はるかに難しくなります。
不可能ではないが、非常に難しい
何が動作していて、何が動作していないかを把握する必要があるからです
障害が発生した場合に何が起こるかなど。
ストレス共有についても同様です。
最初の例を見てみましょう。
最初の例として、基本的な K out of N 配置を見てみましょう。
サブユニットは 5 つあります。
そのうち 3 つは稼働している必要があります。
それらはすべて、アルファが 2,000、ベータが 1 のワイブル分布になります。
ブロックが失敗した場合、
交換には40時間かかります。
私たちはその取り決めを
K アウトオブ N 複合ブロックと直列に接続します。
また、K-of-N複合ブロックは40時間かかると仮定します。
5つのサブユニットがあるにもかかわらず、
そのブロック内で失敗したもの。
どのような違いがあるのか見てみましょう
これらを個別の項目として扱うかどうか
または複合アイテムとして使用しますか?
これは RSS での私の設定は次のようになります。
とてもシンプルにしました。
ここに、N のうちの K に関連するサブユニットを示します。
N ではなく K になる理由は結び目にあります。
入荷した商品の数を指定できます
動作している必要があります。
ここで3つの操作が必要だと言いました。つまり、NのうちKになるということです。
この配置では、N のうち K です。
そして私はそれを非常にシンプルにしておくつもりです。
私が注目する唯一のイベントは、ブロックが失敗するかどうかです。
私が取る唯一の行動は、新品同様に修理することです。
さあ、これを実行してみましょう。
比較的早いです。
出力について少しお話ししたいと思います
出力と状態に送られるものは
将来図を作成し始めるときに役立ちます。
操作の順序を見てみましょう
この最初の失敗に対して。
つまり、ユニット Sub1 が故障してから 766 時間経過していることがわかります。
ブロックが削除されます。
これは私が起こす可能性のある出来事の 1 つなので、この点に注意することが重要です。
ブロックが削除され、プロセスが開始され、ブロックが置き換えられます。
そしてブロックが交換された後、私が指定した40時間後に
私の設定では、システムは自動的にオンになります。
それがもう一つの重要なポイントです。
私たちはその状況に遭遇するだろう
一部のイベントではシステムが
自動的にオンになるものがいくつかあります。それがどれなのかについてお話しします。
そのような場合に私たちがしなければならないこと
実際にシステムをオンにするか、場合によってはブロックが
自動的にオンにならない場合は、ブロックを手動でオンにしてください。
ここではSub3が失敗し、同様の一連のイベントが発生しています。
Sub2が失敗するなど、何が起こるか見てみましょう
システムがダウンしたとき。
そして、N 個中 K 個が失敗した場合、それが確実に発生することがわかっています。
さて、これがシステムが失敗する最初のケースです。
繰り返しになりますが、ほとんどの操作に関しては非常に似ています。
しかし、システムの電源が落ちていることに気づくでしょう。
システムが停止したことに注目してください。したがって、システムを停止する必要があります。
システム内のすべてのブロックをオフにします。
もう一度、心に留めておくべき重要なことは、
なぜなら、知っておく必要があるケースがあるからです
ブロックがオンかオフか。
ブロックを手動でオンにする必要があるかどうか。
それでは交換に移りましょう。
交換が完了したら、
すべてのブロックが自動的にオンになります。
そしてまた、これを新しいものに置き換えて、
電源のオンとオフはすべて自動的に行われます。
だから心配する必要はありません。
ついに、K out N の交換が完了し、次の障害が発生するまで作業は完了です。
比較的簡単です。
システムのパフォーマンスを確認したい場合
結果エクスプローラーを起動します。
デフォルトでは、コンポーネント レベルの情報は表示されません。
コンポーネントレベルの情報が必要な場合は、ホットスポットに戻る必要があります
オーバーオールが欲しい場合は、
コンポーネントごとにダウンタイムを選択します。
さて、この組織について覚えておくべきことは、
これはただ私に伝えているだけです
私のコンポーネントに関連するシステムのダウンタイム。
つまり、これは N のうち K が何回システムをダウンさせたかを示します。
これらのそれぞれについて、
これらは、そのサブユニットがシステムをダウンさせたときと一致していました。
考えてみれば、これらは時代に対応している
サブユニットが私の5つのユニットのうち最後にダウンしたとき、
システムがダウンするのはその時だけだからです
これら 5 つのサブユニットがすべてダウンした場合です。
さて、コンポーネントレベルの分布を確認したいとします。
これは、システムがダウンしたときにのみ通知されます。
しかし、Sub1がどのくらい頻繁にダウンしたかに興味があるとします。
Sub2 がダウンした頻度など。
ホットスポット、この点推定を見ることができます
コンポーネントの可用性について。
そして、例えばSub1までスクロールすると、
これにより分布情報が得られます
コンポーネント自体に対して。
Zにはサブユニット1がシステムを停止させたときだけでなく、
しかし、サブユニット 1 自体がダウンしたとき。
すべてのサブコンポーネントの個別のディストリビューションを詳しく調べる最も簡単な方法。
これらの行動やイベントのいくつかを見てみましょう
そしてそれらに関連する特定のプロパティの一部について説明します。
まずはイベントから始めましょう。
ドキュメントに記載されていない
ただし、Inservice は基本ブロックでのみ使用できます。
念のため言っておきますが、インサービスはブロックの年齢に基づいています
シミュレーションの時間の年齢ではありません。
例えば、何かを修理したい場合
100 時間使用した後、Inservice を使用します。
それ以外の場合は、スケジュールされたイベントのみを使用することもできます。
予定されたイベントは週に1回実施されます。
しかし、Inservice は Basic ブロックでのみ利用可能です。
Inserviceを使いたいかどうか教えてください
これらの基本的なブロックを構築する必要があります。
初期化、ブロック障害、システムダウン
各ブロックごとに 1 回のみ使用できます。
実際に使ってみると、
イベントパレットから消えるので、もう表示されなくなります。
したがって、これらは 1 回しか使用できません。
行動について話しましょう。
使用できるアクションは 13 個あります。
Install Used、Change Distribution、および If は、Basic ブロックでのみ使用できます。
最小限の修復は、ベーシックとシリーズでのみ使用できます。
つまり、どのブロックにも使用できるアクションは 9 つ残ります。
つまり、ブロックのオン/オフ、システムのオン/オフ、
新品と交換、新品を設置、ブロックの取り外し、故障の検査、
そしてスケジュール。これらが9つです
基本ブロックまたは複合ブロックのいずれかのブロックで使用できます。
特定のブロックに対してアクションを何回使用できるかに制限はありません。
つまり、「Turn Off Block」を複数回使用した例です。
その理由は
曲がった後やブロックで曲がったときに何をしたいかは異なるかもしれない
ブロックがいつオンになるかによって異なります。
また、その例については後ほど説明します。
アクションは他のアクションにのみ接続できます。
実際のところ、イベントはアクションにのみ関連付けることができます。
そのため、イベントまたはアクションをブロックまたは別のイベントに接続することはできません。
ただし、連鎖できるアクションの数には制限がありません。
いくつかの特定のプロパティ。
初期化は一度だけ行われ、それは最初の部分です
シミュレーション実行の。
それが違いを生む例を挙げてみましょう。
初期化時にブロックをオフにする場所
しかし、システムがオンラインに戻ると、そのブロックは再びオンになります。
したがって、手動でオフにする必要があります。
したがって、初期化は最初だけ行われます。
システムダウンはブロックごとに発生します。
どのブロックがシステムをダウンさせたかに関係なく。
それで、それをリスナーとして使用して確認することができます...
例えば、システムがダウンした場合、
ブロックが壊れていても、メンテナンスをしたい場合があります。
走っていたのかもしれない、ただそれを戻すためだけだった
ほぼ新品の状態に戻すか、新品同様に復元します。
したがって、どのブロックがダウンを引き起こしたかに関係なく、システム ダウンが発生します。
では、行動についてですが、
システムをオンにすると、利用可能なすべてのブロックがオンになります。
ここで言うすべてのブロックとは、すでにダウンしていないすべてのものを意味します
障害のため、または停止が予定されているため。
何かをダウンさせる予定を立てることができる
スケジュールされたイベントを使用するか、スケジュールされたアクションを使用します。
システムをオンにすると、すべてのブロックがオンになります。
ブロックは手動でオンにする必要がある
新規インストール、中古インストール、または配布の変更後。
これらはシステムが起動しないケースの2つです。
ブロックは自動的にオンになりません。
これが私が使いたい理由です、
たとえば、「新しいものに置き換える」ではなく「新しいものをインストール」です。
「新規インストール」を使用すると、システムを再びオンにする前に作業を行うことができます。
他の操作を実行する機会が与えられます
システムの電源を入れる前に、またはその他の操作を実行します。
ブロックが手動でオフにされている場合、ブロックをオンにしてもシステムはオンになりません。
出力を見ると、
出力からお気づきかと思いますが、システムがオンになっているかどうかに関係なく、
システムの起動イベントが表示される場合があります。
システムがすでにオンになっている場合は、システムをオンにしても問題ありません。
私が言いたいのは、疑わしい場合はターンオンシステムを追加することです
システムがオンになっていることを確認するために、一連のイベントを実行します。
ちなみに、ブロックが最初にオンになっているかどうかは関係ありません
または、最初にシステムがオンになります。
どちらも同じように動作します。
さて、2番目の例に移りましょう。
これからやることは、基本的なブロックを構築することです
スタンバイ配置で。
メインユニットを 1 つ、スタンバイユニットを 1 つ用意します。
コールドスタートアップをします。
つまり、スタンバイ ユニット、バックアップ ユニットは古くなりません。
ただし、ユニットの起動には 30 分かかります。
複合スタンバイではできないこと。
制御後にバックアップの8時間のメンテナンスが実行される
メインユニットに返されます。
2 つの異なるスイッチ状況を見てみましょう。
実際に絶対確実なスイッチを見てみます
90% の信頼性を備えたスイッチを確認します。
すべてのブロックに対して、Exponential(500) を仮定します。
修理またはメンテナンスには 8 時間かかると想定します。
故障したブロックは新しいブロックに置き換えられます。
前の例と同様に、基本的なブロックを見ていきます
この配置では、同じ設定のスタンバイブロックと直列に接続され、
もちろん、30分の起動時間を除けば、
それは私にはできない。
見てみましょう。
これが私たちの基本的な取り決めです。
バックアップユニット、メインユニット、スタンバイユニットがあり、それぞれに
失敗イベントと「新規に置換」を関連付けました。
私が最初に取り組むかもしれないものの骨組みのようなもの。
以前、出力を見たときに指摘したかどうかは分かりませんが、
イベントを追加したり、アクションを追加して一意の名前を付けるときに役立ちます
なぜなら、それらは私の出力に表示される名前だからです。
では、バックアップユニットから始めましょう。
システムが時間ゼロでオンラインになると、すべてがオンになります。
時刻 0 でバックアップ ユニットがオフになっていることを確認したいと思います。
それを実行するには、初期化を使用します。
初期化を使用すると、
それは消えた。
次にやりたいのは、ブロックをオフにすることです。
これまでにRSSを使用したことがある方は、
アクションを追加しようとすると、
これらのアクションを積み重ねることになります。
時々、そこは彼らにとって最適な場所ではないことがあります。
いつでもできる一つの行動から始められる。
アクションを選択するには、このプラス記号をクリックして押し続けます
そしてプラスをドラッグするだけです。
これでアクションを追加できます。
この場合は、ブロックをオフにしたいと思います。
ここで、これに関連付けられている Turn off Block は不要なので、New に置き換えます。
それを回避するには、矢印を削除するだけです。
希望するイベントに接続できるようになりました。
これを実行する利点は、ブロックを好きな場所に移動できることです。
ブロックの動作方法に関して、より柔軟性が高まります。
もう一つやることは、これらにラベルを付けることです
結果表を見ると、何が起こるかが分かります。
これはブロックをオフにするものです...
これを開始時にバックアップをオフにするということとします。
各イベント、各アクションに固有の名前を付けます
だから、いつそれが起こったかが分かるのです。
これにより、開始時にバックアップがオフになります。
次にやりたいことは、メインユニットが故障したときです。
バックアップユニットをオンにしたいと思います。
ここでも、バックアップユニットを選択して「ブロックをオンにする」と言うのではなく、
ブロックをオンにするをインタラクティブに選択します。
これを移動できるように、ここで接続を削除します。
少し場所を変えてみます。
これをここへ移動します。
もう一度、この図に戻ってきたら、この図に名前を付けます。
数日後には、このアクションが何に関連しているかがわかります。
これをメインからのバックアップのオンと呼びます。
ドキュメントに記載されているもう一つのことは、
どれくらい強いのかは分かりませんが、繋がることはできます。
この場合、あるブロックのイベントをアクションに接続します
別のブロックにあります。
絶対できますよ。
さて、先ほども述べたように、これでブロックがオンになります
そのブロックは手動でオフにされたため、
システムもオンにする必要があります。
システムの電源をオンにします。
もう一度言いますが、私はおそらくそれをラベル付けしたいのです。
バックアップからシステムをオンにするなどと言います。
さて、図に付け加える必要があるのは
メインがオンラインに戻ったら、バックアップをオフにしたいのですが、
バックアップのメンテナンスを実行します。
今ならおそらく...
さて、まずはバックアップをオフにして、ブロックをオフにしましょう。
それを削除してください。
これを呼び出します。
オンを選択したはずですが、オフブロックになりました。
もう一度試してみましょう。
ブロックをオフにしてラベルを付け、メインからのバックアップをオフにします。
そこが私のメインがオンラインになる場所です。
そこでバックアップをオフにしました。
メンテナンスをしたいです。
それを実行するには、新しいものに置き換えるだけです。
わかりました。これを予防保守と呼ぶことにします。
予防保守は
8時間かかります。
もう一度思い出さなければならない
「Replace with New」は自動的にブロックを開始します。
今やらなければならないのは、ブロックをオフにすることです。
さて、もう少し詳しく考えてみると、
おそらく、オンラインに戻ってきた新しいサイトから直接アクセスできたはずです
メンテナンスを行うこと。
バックアップのメンテナンスを開始すると、バックアップの動作が停止します。
メンテナンスが終わったら、
ブロックをオフにします。
このブロックは害はありませんが、冗長です。
だから、それを捨ててしまいましょう。
それが私の設定です。
私はいつも、物事がうまく機能しているかどうかを再確認するために走ります
適切な順序で入力すると、出力が生成されます。
この場合は、シミュレーションを 1 つだけ実行するように設定しています。
２、３個取らないといけないかもしれない
ユニットに関連付けられた信頼性に応じてシミュレーションが異なります。
これが主な失敗です。システムがダウンし、
スタンバイブロックがオフになり、新しいメインが挿入され、
メインのバックアップをオンにします。
捕食者の列を見ると、メインのバックアップのターンが私の番になっています。
バックアップからシステムをオンにし、システムによるブロックをオンにします。
繰り返しますが、私はこれらを一度構築したら、確認するためにステップごとに確認するのが好きです。
物事は正しい順序で起こります。
ターンシステムがオンになります。
新しいメインが取り付けられました。
システムの電源を入れると、
繰り返しますが、すでにオンになっていますが、問題ありませんし、害もありません。
新しいメインを New に置き換えます。
それがブロックであり、バックアップがオンになっている
PMを取得するなど。
バックアップはオフになっているはずです。
もう一度言いますが、私は二重チェックのためにこれらを使うのが好きです
物事が適切に機能するようにするため。
これがスイッチなしのセットアップです。
スイッチを追加するのは比較的簡単です。
それをどこに置くかというと、
メインの故障とバックアップの開始の間
そして、それが if ブロックが作られる目的です。
その接続を解除してみましょう。
それがどのブロックから来たかは関係ない
そこに置きたくなかったんです。
では、始めましょう...。
万が一そのようなことが起こった場合に備えて、バックアップを取っておきます。
さぁ行こう。
バックアップがオンになっています。
そこが私の主な欠点です。
私たちはそれを取り除くつもりです。
おそらく、if ブロックを追加して、どこにでも移動できるようにしたいでしょう。
これらのいずれか 1 つを取得して、if を追加します。
接続を削除します。
それをつなげてみましょう。
さて、私がifを設定する方法は、
if の動作は、if 条件ボックスの内容を評価することです。
それが真であれば、つまり 1 と評価された場合は、続行します。
ゼロと評価された場合は停止します。
私が言えるのは、もし…そこに「もし」は必要ないということです。
ランダムユニフォームは 0.9 未満だと言うつもりです。
それが真実であればチェーンは継続され、そうでない場合はそこで停止します。
それでおしまい。
if ステートメントを挿入するのはそれほど簡単です。
これもおそらくラベルを付けたいと思うでしょう。
つまり、切り替えが成功した場合などです。
この時点での唯一の欠点は、スイッチが故障した場合に何が起こるかということです。
そうですね、スイッチが故障したので、メインがオンラインに戻るまで待つ必要があります。
メインがオンラインに戻ると、バックアップをオフにしようとします。
すでにオフになっているものをオフにしてみても問題ありません。
でも、私がやりたくないかもしれないことは
バックアップが使用されなかった場合は、メンテナンスを実行したくないかもしれません。
後ほどの例では、これをどう回避するかを見ていきます。
システムを調べて、バックアップが実行中かどうかを確認するにはどうすればよいでしょうか?
動作していない場合は、メンテナンスを行ってください。
稼働していればメンテナンスは必要ありません。
次の例に移りましょう。
この場合、予防保守と並行して2つのポンプが稼働しています
2週間ごとに8時間かけて行われます。
両方のポンプがダウンしないように、首相は1週間ずらして任命される。
同時に。
ポンプが故障した場合、4 時間かけて最小限の修理が行われます。
この場合、シミュレーションは 1 年間実行されます。
まずは基本から始めましょう。
ここに私のポンプの故障と交換品を示します。
PM を開始する 1 週間前に待機するにはどうすればよいでしょうか?
最後の例と同様に、初期化から始めます。
私が言いたいのは、1週間待つことです。
1週間待つと言えばいいでしょうか?
さて、私はスケジュールアクションを使用します。
これまでやってきたことをこれからもやっていきます。
スケジュールを設定し、接続を削除します。
スケジュールにはさまざまなオプションがあります。
これが一度だけ起こってほしい。最初から起こってほしい。
つまり、初期化イベントに接続されます。
これを1週間待つことにします。
私はこれが一度だけ起こることを望んでいます。
168時間かかるようにしたいです。
それは、シミュレーションを数時間でセットアップしたからです。
それは、開始時に1週間待つことです
そして、ここで接続したアクションを実行します。
接続するアクションは何ですか?
さて、またスケジュールを使うことにします。
これはポンプ 2 の PM になります。
最大発生回数は空白のままにしておきます。
つまり、シミュレーションの最後までそれが実行されます。
完了時間は 168 x 2 なので 336 になります。
最初の1週間が過ぎると、336時間ごとに
もう一度手術を受けることができます。
その操作にはいくつかの異なる方法があります。
PM [聞き取れず 00:37:03] だと仮定します。
そこで、「新しいものに置き換えます」と言います。
ここでは、ポンプ B を交換すると言えます。
さて、皆さんが考えていることの一つは
予防メンテナンスを行うとどうなるか
すべてがずれているが、何らかの理由でポンプAがダウンしており、
失敗した可能性があります。
必ずしもポンプBを降ろす必要はない
予防保守のため。
そうしてシステムを停止します。私たちが使うのは
シミュレーション コンテキストと呼ばれる隠し変数を使用します。
シミュレーション コンテキストは、システムを調査する方法です。
シミュレーションのコンテキストを設定します
予定されている予防メンテナンスと実際の予防メンテナンスの間にこれを配置します。
これをやってみましょう。
これを取り除いて、if を使用して実装してみましょう。
接続して、ポンプAが動作している場合は、
ここで問題になるのは、ポンプ A が動作しているかどうかをどうやって確認するかということです。
さて、私のif条件では、隠し変数を指定する必要があります
それはポンプ A に関連付けられています...アクティブかどうかに関係なく。
私がそれをする方法は、シミュレーションコンテキストです
大文字と小文字は区別されません。
シミュレーションのコンテキストと変数、
システム変数は配列の関連付けとして保存されます。
これをポンプAの状態と呼びます。
私が今発見したのは、
ダイアログ ボックスのこの特定の部分はそれほど柔軟ではありません。
もっと複雑なものを作りたいときは
それからスクリプトウィンドウでそれを実行し、コピーして貼り付けます
このウィンドウに。
しかし、これは比較的小さいので、そのまま入力していきます。
これをアクティブとします。
私ならそれを使います。
さて、それが使用しなければならないものであることをどうやって知ったのでしょうか?
結局のところ、このif条件と少し
後でストレスの共有について話すとき、
これはスクリプトのように機能します。
私ができること、そしてよくやってきたこと
print ステートメントに入力した場合、何が使用可能かを知るにはどうすればよいですか?
そこにprint文を入れてみましょう
そして、シミュレーションコンテキストを印刷します。
私たちが確信する必要がある唯一のこと
それは if 文であり、その if 条件の最後の文が true を評価します。
何が起こるかをお見せするために
これを実行したら、先に進んで実行してみましょう。
イメージをつかんでいただくために、これを実行してみましょう
ログに何が印刷されるか。
先にログを取ってみましょう。それは他のログの 1 つにあります...
さあ、これが私のログです
さあ始めましょう。
これがログに出力されたものです。
これにより、利用可能なすべての変数に関する情報が得られます
この特定の図のシミュレーション コンテキストでは、
そこにもっと多くのブロック、もっと多くのアクション、もっと多くのイベントを入れていたなら
するとそれらが表示され、それらに関する情報も表示されます。
しかし、これは良い伝え方です
私のシステムには何があるのか、また私がアクセスできる変数は何なのか。
ここで覚えておくべき重要なことは
これを読み取ることはできますが、この特定の変数に書き戻すことはできません。
シミュレーションで変更するオプションはありません。
しかし、その情報は使えます。
最後の例に戻ると、私ができたことは
そこにif文を入れることもできたでしょう
バックアップがアクティブであれば、
じゃあ、電源を落としてメンテナンスをしましょう。
わかった。
さて、時間の関係で先へ進みます
最後に皆さんにお伝えしたい情報があります。
ちなみに、ジャーナルも用意しておきます。
記事が用意されているはずです。
時間がなくて説明できなかった例をもっと挙げます。
さらにいくつかのアクションを見てみましょう
どのように実装されるかを見る機会がなかった
そして他のものも
それはそれほど簡単ではないかもしれません。
カスタムストレスシェアリングは、デフォルトでは、
ストレスはサブユニット間で均等に共有されます。
これは、このブロックの古さを変えることによって実装されます
分布を明示的に変更しないこと。
応力共有がない場合、n個のサブユニットを並列に持つとします。
最初のものは 1 回目に失敗し、2 番目は 2 回目に失敗し、というように続きます。
ストレスの共有、ブロックを老化させる方法
最初の故障はtの1倍のnで発生するということである。
作業単位の数を掛けます。
2番目はブロックの年齢をさらにn-1だけ上げる
最初の失敗と 2 回目の失敗の差の 10 倍です。
3番目はnから2倍した差である
3 回目、2 回目の失敗など。
ブロックはこのように古くなります。
これは、カスタム関数に渡される情報です。
これをストレスの共有に取り入れようとすると、
さて、これがどのように設定されているかについての最後の例を共有したいと思います。
私の例を見つけてみましょう。
さて、ここには 3 つの異なるストレス共有があります。
基本的なストレス共有があるので、それを基本として設定しました。
これが私のカスタムです。
これが私が話している終わりです。
このログ関数にそれが組み込まれていることがわかります。
ブロックの経年変化を合わせるためにこのようにするのです
カスタムの応力共有ブロックに使用できる分布です。
私がやっているのは、自分の説明に基づいて物事を考えることです
最初のユニットは時間の何倍もの速度で老化し、
2番目のものは、ある乗数倍の差で
1回目と2回目の失敗など。それが私の考え方です
これらすべてについて。例えば、設定したいとします。
さて、そこに行く前に、簡単に言っておきますが、
if ブロックと同様に、ここに print ステートメントを配置できます。
ここにprint文を入れると、
これはシステムが起動する前に実行されることに気づくでしょう。
5を印刷し、5を印刷します
この場合、ブロックには 5 つのユニットがあるからです。
最初の1つが失敗したら5つ印刷します
print four関数に戻ります。
などなど。
これをカスタム失敗として設定したいとします。ブロックが
5倍ではなく10倍の速度で老化が進む
2番目は5歳、3番目は3歳です。
2番目は1歳で
そして最後のものは過剰なストレスを受け、2倍の速さで老化します。
私ができることは、
もう一度、これをここに置きましょう。
少しスペースを追加しましょう
そして箱を少し大きくします。
例えば、
もう一度、そのログを入れたいのですが、そのログはそこになければなりません
ログに記録して、choose のようなことを言います。
chooseはnに基づいて何を行うか、それは返します、
見てみましょう、ユニットが1つある場合は、半分、つまりユニットが2つある場合を返したいのですが、
3ユニットで2.5としましょう
4ユニットで5、そして最終的に10です。
これが私がカスタムのストレス共有を作成する方法です。
この選択機能に限定されません。
この特定の例では、
関数を使用しています。
さて、ここで重要なのは
これらすべてがこのログ関数に埋め込まれ、老化が
ブロックと分布が一致できるようになります。
はい、残念ながら、今日はここまでです。
もっと時間があればいいのに。確かに、やりたいことはたくさんある
他にも話せることはたくさんあります。
それは私が皆さんに提供した資料の中にあります。
あなたのフィードバックを聞きたいです
ご質問やご意見がありましたらお知らせください。
改めて、お時間をいただきありがとうございます。こちらをご覧下さい。
これが本当に役に立つことを願っています。ありがとうございます。
