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