DEVS(離散イベントシステム仕様の略)は、状態遷移表で記述できる離散イベントシステム、微分方程式で記述できる連続状態システム、および連続状態と離散イベントのハイブリッドシステムなど、一般的なシステムをモデル化および分析するためのモジュール型かつ階層的な形式体系です。DEVSは時間付きイベントシステムです。
DEVSは、離散事象システム(DES)のモデリングと分析のための形式体系です。DEVS形式体系は、アリゾナ大学名誉教授のバーナード・P・ジーグラーによって考案されました。DEVSは、ジーグラーがミシガン大学の准教授であった1976年に出版された最初の著書『モデリングとシミュレーションの理論』[ 1 ]で一般に紹介されました。DEVSは、出力が現在の状態のみによって決定され(入力に直接依存しない)、有限状態オートマトンであるムーアマシン形式体系[ 2 ]の拡張と見なすことができます。この拡張は、
各状態の寿命は実数(より正確には非負の実数)または無限大であるため、時間がティック時間と非負の整数の積で決まる離散時間システム、逐次マシン、ムーアマシンとは区別されます。さらに、寿命は確率変数となる可能性があり、例えば、特定の状態の寿命は指数分布または一様分布に従うことがあります。DEVSの状態遷移関数と出力関数も確率的になり得ます。
Zeiglerは1984年にDEVSモデルシミュレーションのための階層アルゴリズムを提案し[ 4 ]、これは1987年にSimulation誌に掲載されました。それ以来、DEVSから多くの拡張形式がそれぞれの目的で導入されてきました。例えば、連続イベントシステムと離散イベントシステムを組み合わせたDESS/DEVS、並列DES用のP-DEVS、DESの区分的連続状態軌跡モデリング用のG-DEVS、リアルタイムDES用のRT-DEVS、セルラーDES用のcell-DEVS、ファジーDES用のfuzzy-DEVS、動的に結合構造が変化するDES用のdynamic structuring DEVSなどです。これらの拡張に加えて、システム特性の決定可能性を実現するために、 SP-DEVSやFD-DEVSなどのサブクラスが研究されています。
モジュール式かつ階層的なモデリングビュー、およびシミュレーションベースの解析機能により、DEVS形式とその派生形式は、工学(ハードウェア設計、ハードウェア/ソフトウェア協調設計、通信システム、製造システムなど)や科学(生物学、社会学など)の多くの分野で活用されてきました。
DEVS は、システム構造だけでなくシステム動作も定義します。DEVS の形式におけるシステム動作は、入力イベントと出力イベント、および状態を使用して記述されます。たとえば、図 1 の卓球選手の場合、入力イベントは?receive、出力イベントは!sendです。各選手A、Bは、 SendとWaitという状態を持ちます。Send状態では、出力イベント!sendであるボールを 0.1 秒で送り返しますが、Wait状態は、入力イベント?receive であるボールを選手が受け取るまで続きます。
ピンポンゲームの構造は、2人のプレイヤーを接続することです。プレイヤーAの出力イベント!sendはプレイヤーBの入力イベント? receiveに送信され、その逆も同様です。
古典的なDEVS形式論では、アトミックDEVSはシステムの挙動を捉え、結合DEVSはシステムの構造を記述する。
以下の正式な定義は、従来の DEVS 用です。[ 5 ]この記事では、時間ベースを使用します。それは非負の実数の集合です。拡張された時間ベース、それは、非負の実数と無限大の集合である。
コンピューティングにおけるシステム変数のセグメントは、一定期間にわたるシステムダイナミクスの均質な状態を示します。ここで、変数の均質な状態とは、数式の係数の集合によって記述できる状態のことです。例えば、均質な状態の例として、定数(スイッチの「オン」)や線形( 速度で時速60マイルまたは96km)の状態が挙げられます。数学的には、セグメントは、実数区間によって定義できる時間の集合から、ある集合へのマッピング関数です。[Zeigler76]、[ZPK00]、[Hwang13]。システム変数の軌跡は、連結されたセグメントのシーケンスです。連結されたセグメントが定数(または線形)である場合、その軌跡を定数(または線形)と呼びます。
イベントセグメントは、定数セグメントが時間付きイベントまたはヌルセグメントのいずれかであるという制約を持つ、定数セグメントの特殊なクラスです。イベントセグメントは、 DEVS、時間付きオートマトン、時間付きペトリネットなどの時間付きイベントシステムを定義するために使用されます。
当該システムの 時間基準は、、そして定義した
非負の実数の集合として。
イベントとは、変化を抽象化したラベルです。イベントセットが与えられた場合、ヌルイベントは、何も変わらないという意味だ。
時間指定イベントはペアですどこそしてイベント時刻に発生する。
時間間隔におけるヌルセグメントは、それは何の意味もありません発生する。
単位イベントセグメントは、ヌルイベントセグメントまたは時間指定イベントのいずれかです。
イベントセットが与えられた場合2つのユニットイベントセグメントの連結以上そして以上は、その時間間隔は、そしてそれは。
イベントの軌跡イベントセット全体にわたってそして時間間隔ユニットイベントセグメントの連結そしてどこ。
数学的に言えば、イベント軌跡は写像である期間イベントセットへなので、関数形式で記述できます 。
普遍的な時間言語イベントセット全体にわたってそして時間間隔は、 上のすべてのイベント軌跡の集合です。そして。
時間制限のある言語イベントセット全体にわたってそして時間間隔は、イベント軌跡の集合である。そしてもし。
原子DEVSモデルは7タプルとして定義される
どこ
- は入力イベントの集合です。
- 出力イベントの集合です。
- は、連続する状態の集合(または部分状態の集合とも呼ばれる)です。
- 初期状態です。
- これは、状態の寿命を決定するために使用される時間進行関数です。
- は、入力イベントがシステムのステートをどのように変化させるかを定義する外部遷移関数であり、は全状態の集合であり、は最後のイベントからの経過時間です。[ 6 ]
- これは、システムの状態が内部的にどのように変化するかを定義する内部遷移関数です(経過時間がその状態の寿命に達したとき)。
- は出力関数であり、そしてこれはサイレントイベントまたは観測されないイベントです。この関数は、システムの状態が出力イベントを生成する方法(経過時間が状態の有効期間に達したとき)を定義します。
図1のプレイヤーAの原子DEVSモデルは、player=で与えられる。そのため
プレイヤーAとプレイヤーBはどちらもアトミックDEVSモデルです。
簡単に言うと、アトミックDEVSモデルには2つのケースがあります。状態を変えることができる(1)外部入力がシステムに入る(2)経過時間寿命に達するこれは次のように定義されます(2)と同時に、出力を生成するこれは次のように定義されます。
与えられたアトミックDEVSモデルの正式な動作記述については、「アトミックDEVSの動作」のセクションを参照してください。与えられたアトミックDEVSモデルの動作を実装するためのコンピュータアルゴリズムは、「アトミックDEVSのシミュレーションアルゴリズム」のセクションで入手できます。
結合DEVSは、どのサブコンポーネントがそれに属し、それらが互いにどのように接続されているかを定義します。結合DEVSモデルは8タプルとして定義されます。
どこ
- は入力イベントの集合です。
- 出力イベントの集合です。
- はサブコンポーネントの集合名です。
- は、各サブコンポーネントの集合であり、原子DEVSモデルまたは結合DEVSモデルのいずれでも構いません。
- は外部入力結合の集合です。
- は内部結合の集合です。
- は外部出力結合関数です。
- は、同時発生するイベントのセットからイベントを選択する方法を定義する、同点の場合の判定関数です。
図1の卓球ゲームは、結合DEVSモデルとしてモデル化できる。どこ;;;上記のとおり説明されている。;; そして。
簡単に言うと、原子DEVSクラスの動作と同様に、結合DEVSモデル外部イベントが発生したときに、構成要素の状態が変化する(1)入る(2)構成要素の一つがどこ内部状態遷移を実行し、出力を生成する。(1)と(2)のどちらの場合も、トリガーとなるイベントは、結合セットによって定義されるすべての影響に伝達される。そして。
結合DEVSの動作に関する正式な定義については、 「結合DEVSの動作」のセクションを参照してください。特定の結合DEVSモードの動作を実装するためのコンピュータアルゴリズムは、 「結合DEVSのシミュレーションアルゴリズム」のセクションで入手できます。
DEVSモデルのシミュレーションアルゴリズムは、時間同期とメッセージ伝播という2つの問題を考慮します。DEVSの時間同期とは、すべてのモデルが同一の現在時刻を持つように制御することです。ただし、効率的な実行のために、アルゴリズムは、イベントがスケジュールされ、内部状態遷移と出力生成が実行されると、現在時刻を最も緊急性の高い時刻にジャンプさせます。メッセージ伝播とは、結合DEVSモデルで定義された関連する結合に沿って、入力イベントまたは出力イベントのいずれかであるトリガーメッセージを送信することです。詳細については、原子DEVSのシミュレーションアルゴリズムと結合DEVSのシミュレーションアルゴリズムを参照してください。
連続セグメントを区分的定数セグメントとして抽象化する量子化手法を導入することで、DEVS は微分代数方程式のネットワークで記述される連続状態システムの挙動をシミュレートできます。この研究は 1990 年代に Zeigler によって開始されました。[ 7 ]多くの特性は 2000 年代に Kofman 教授と Nutaro 博士によって明らかにされました。2006 年に、 Continuous System Modelingの著者である Cellier 教授[ 8 ]と Kofman 教授は、教科書Continuous System Simulation を執筆しました。[ 9 ]この本の第 11 章と第 12 章では、 DEVS が連続状態システムをシミュレートする方法を扱っています。Nutaro 博士の著書[ 10 ]では、連続状態システムの離散イベントシミュレーションも扱っています。[ 11 ]
サンプリングベースのシミュレーション手法に対する代替分析手法として、検証と呼ばれる網羅的な生成動作アプローチが、 DEVS モデルの分析に適用されています。 与えられた DEVS モデル (特に結合 DEVS モデル) の無限の状態は、スケジュール保存 DEVS ( SP-DEVS )、有限かつ決定論的 DEVS ( FD-DEVS ) [ 12 ]、および有限かつリアルタイム DEVS ( FRT-DEVS ) [ 13 ]などの DEVS のサブクラスである場合、到達可能性グラフと呼ばれる動作的に同型な有限構造によって抽象化できることが証明されています。その結果、到達可能性グラフに基づいて、(1) デッドロックおよびライブロックフリーという定性的特性は、SP-DEVS [ 14 ] 、 FD-DEVS [ 15 ] 、および FRT-DEVS で決定可能です。[ 13 ]および (2) 最小/最大処理時間境界は、定量的特性として、2012 年までに SP-DEVS で決定可能です。
一般システムは、(1)時間ベース、(2)許容入力セグメント、(3)システム状態、(4)許容入力セグメントを持つ状態軌跡、(5)与えられた状態に対する出力を定義する観点から、Zeigler [ 16 ] [ 17 ] によって記述されています。現在のセグメントとイベントセグメントに関連付けられた状態軌跡を定義する時間イベントシステムは、非決定論的な動作を可能にするために、一般システムのクラスから生まれました。[ 18 ] DEVSの動作は時間イベントシステムで記述できるため、 DEVSとRTDEVSは時間イベントシステムのサブクラスまたは同等のクラスです。
時間指定イベントシステムは構造です
どこ
時間付きイベントシステムが与えられた場合、その振る舞いの集合は、観測時間の長さに応じてその言語と呼ばれる。観測時間の長さとする。、-長さの観察言語は、、そして次のように定義される
イベントセグメントを1-長さの挙動、 もし観測時間の長さを送信することで無限に、無限長の観測言語を定義しますは、、そして次のように定義される
イベントセグメントを無限長の挙動、 もし。
過去数十年の間に、古典的なDEVS形式を拡張した数多くの形式が開発されてきた。その中には、シミュレーション時間の経過とともにモデル構造が変化することを可能にする形式も含まれる。
G-DEVS、[ 19 ] [ 20 ]並列DEVS、動的構造化DEVS、セルDEVS、[ 21 ] dynDEVS、ファジーDEVS、GK-DEVS、ml-DEVS、シンボリックDEVS、リアルタイムDEVS、rho-DEVS
検証解析をサポートするために指定された、スケジュール保存型 DEVS ( SP-DEVS ) および有限かつ決定論的な DEVS ( FD-DEVS )と呼ばれるサブクラスがあります。表現力がE ( SP-DEVS )であるSP-DEVSおよびFD-DEVSがあります。E ( FD-DEVS )E (DEVS) ここで、E (形式主義) は形式主義の表現力を表します。
特定のDEVSモデルの動作は、ヌルイベントを含む一連の時間指定イベント(イベントセグメントと呼ばれる)によって定義され、これらのイベントによってモデルは一連の合法状態内で状態を遷移します。このように定義するには、違法状態と合法状態という概念を導入する必要があります。
さらに、特定の DEVS モデルの動作は、時間の経過時とイベント発生時の両方で状態遷移がどのように変化するかを定義する必要があるため、一般システムと呼ばれるより一般的な形式によって記述されてきました。[ 22 ]本稿では、代わりに時間イベントシステムと呼ばれる一般システム形式の一種を使用します。
DEVSモデルの全状態と外部状態遷移関数がどのように定義されているかによって、時間イベントシステムを使用してDEVSモデルの動作を定義する方法は2つあります。結合DEVSモデルの動作はアトミックDEVSモデルとして定義されているため、結合DEVSクラスの動作も時間イベントシステムによって定義されます。
DEVSモデルを仮定すると、もっている
次に、DEVSモデル、時間指定イベントシステムどこ
- イベントセット。
- 州はどこ。
- 初期状態の集合。
- 受理状態の集合
- 状態軌跡の集合これは、2つの異なるケースについて定義されています。そして受け入れない州の場合偶数セグメントには変化はありませんそれで
完全な状態その時そしてイベントセグメント次のように。
ユニットイベントセグメント の場合ヌルイベントセグメント、つまり
ユニットイベントセグメントの場合時間制限のあるイベントですイベントが入力イベントである場合、
ユニットイベントセグメントの場合時間制限のあるイベントですここで、イベントは出力イベントまたは観測不可能なイベントである。、
この動作観をシミュレートするためのコンピュータアルゴリズムは、「原子DEVS向けシミュレーションアルゴリズム」セクションで入手できます。
DEVSモデルを仮定すると、もっている
そして開発者時間指定イベントシステムどこ
- イベントセット。
- 州はどこ。
- 初期状態の集合。
- 受理状態の集合。
- 状態軌跡の集合これは2つのケースに依存します。そして受け入れない州の場合セグメントごとに変更はありませんそれで
完全な状態その時そしてイベントセグメント次のように。
ユニットイベントセグメント の場合ヌルイベントセグメント、つまり
ユニットイベントセグメントの場合時間制限のあるイベントですイベントが入力イベントである場合、
ユニットイベントセグメントの場合時間制限のあるイベントですここで、イベントは出力イベントまたは観測不可能なイベントである。、
この動作観をシミュレートするためのコンピュータアルゴリズムは、「原子DEVS向けシミュレーションアルゴリズム」セクションで入手できます。
ビュー1はZeigler [ 23 ]によって導入されたもので、全状態が与えられた場合そして
どこは残り時間です。[ 23 ] [ 22 ]言い換えれば、部分状態の集合は確かにどここれは状態セットです。DEVSモデルが入力イベントを受け取るとview1は経過時間をリセットしますDEVS モデルが無視する必要がある場合は、ゼロで寿命制御の観点から、モデラーは残りの時間を更新する必要がある
外部状態遷移関数においてそれはモデラーの責任です。
可能な値の数はこれは、DEVSモデルに入力される可能性のあるイベントの数と同じであり、つまり無制限です。結果として、状態の数はまた、無制限であるため、view2が提案されたのです。
DEVSモデルの有限頂点到達可能性グラフを気にしない場合、view1は経過時間を扱う上でシンプルであるという利点がある。DEVS モデルに入力イベントが到着するたびに。ただし、欠点としては、DEVS のモデラーは管理方法を知っておく必要があるかもしれません。上記のように、それ自体だが、。
View2はHwangとZeiglerによって導入され[ 24 ] [ 25 ]、全状態が与えられた残りの時間、は次のように計算されます
DEVSモデルが入力イベントを受け取るとview2は経過時間をリセットしますゼロのみDEVSモデルが無視する必要がある場合寿命制御の観点から、モデラーは。
view1とは異なり、残りの時間はコンポーネントではありません自然界では、状態の数、つまりが有限であれば、有限頂点(およびエッジ)状態遷移図を描くことができます。[ 24 ] [ 25 ]その結果、例えばSP-DEVSやFD-DEVSのような DEVS クラス ネットワークの振る舞いを、到達可能性グラフと呼ばれる有限頂点グラフとして抽象化することができます。[ 24 ] [ 25 ]
DEVSは結合に関して閉じている。[ 3 ] [ 26 ]言い換えれば、結合されたDEVSモデルが与えられた場合その動作は原子DEVSモデルとして記述される。特定の結合DEVSの場合同等の原子DEVSが手に入ったら、これは、時間イベントシステムに基づくアトミックDEVSの動作を参照することができます。
アトミック DEVS の動作と同様に、結合 DEVS クラスの動作は、全状態セットの定義とその処理に応じて、次のように記述されます。
結合されたDEVSモデルが与えられた場合その動作は原子DEVSモデルとして記述される。
どこ
どこ
部分状態が与えられた場合、 させて差し迫ったコンポーネントの集合を表す。発火コンポーネント内部状態遷移をトリガーし、出力イベントは以下によって決定される。
どこ
結合されたDEVSモデルが与えられた場合その動作は原子DEVSモデルとして記述される。
どこ
どこ
そして
部分状態が与えられた場合、 させて差し迫ったコンポーネントの集合を表す。発火コンポーネント内部状態遷移をトリガーし、出力イベントは以下によって決定される。
どこ
非空サブコンポーネントを持つ結合DEVSモデルでは、経過時間を記録する時計の数は複数あるため、モデルの時間の経過がはっきりとわかる。
総状態が与えられた場合どこ
ユニットイベントセグメント の場合ヌルイベントセグメント、つまり時間イベントシステムの観点から見た状態軌跡は
総状態が与えられた場合どこ
ユニットイベントセグメント の場合ヌルイベントセグメント、つまり時間イベントシステムの観点から見た状態軌跡は
原子DEVSモデル が与えられた場合、シミュレーションアルゴリズムは、モデルの合法的な振る舞い、すなわち違法な状態に到達しない軌跡を生成する方法です(DEVSの振る舞いを参照)。Zeiglerは当初、寿命に関連する時間変数を扱うアルゴリズムを導入しました。経過時間他の2つの時間変数、最後のイベント時間、、そして次のイベントの時間以下の関係で:[ 3 ]
そして
どこは現在の時刻を表します。そして残り時間は、
は、以下のように計算されます。
、 どうやら。
特定の原子DEVSモデルの挙動は、全状態と外部遷移関数に応じて2つの異なる視点で定義できるため(DEVSの挙動のセクションを参照)、シミュレーションアルゴリズムも以下のように2つの異なる視点で紹介します。
全体の状態に関する2つの異なる見解に関わらず、初期化および内部遷移ケースのアルゴリズムは一般的に以下のように定義されます。
DEVSシミュレーター 変数: 保護者 // 保護者コーディネーター // 最後のイベント発生時刻 // 次のイベントの時間 // 関連するAtomic DEVSモデル 初期化メッセージを受信したとき(時間)) スターメッセージを受信したとき(時間)) もしそれから エラー: 同期が不正です。 yメッセージを送信します(親へ;
アトミック DEVS の動作のセクションで説明したように、DEVS が入力イベントを受け取ると、右呼び出し最後のイベント時間、現在時刻によって設定されます。したがって経過時間はゼロになるのは。
x-messageを受信したとき(、 時間) もしそして== false の場合 エラー: 同期が不正です。
アトミック DEVS の動作のセクションで説明したように、値に応じて返します、最後のイベント時間、、そして次のイベントの時間、したがって、経過時間、寿命更新されます()または保存されている場合()
x-messageを受信したとき(、 時間) もしそして== false の場合 エラー: 同期が不正です。 もしそれから
結合DEVSモデルが与えられた場合、シミュレーションアルゴリズムは、モデルの合法的な振る舞いを生成する方法であり、これは違法な状態に到達しない軌跡の集合である。(結合DEVSモデルの振る舞いを参照。)Zeiglerは当初、寿命に関連する時間変数を扱うアルゴリズムを導入した。経過時間他の2つの時間変数、最後のイベント時間、、そして次のイベントの時間以下の関係で:[ 3 ]
そして
どこは現在の時刻を表します。そして残り時間は、
は、以下のように計算されます。
どうやらこれらの関係に基づいて、特定の結合DEVSの挙動をシミュレートするアルゴリズムは、次のように記述されます。
アルゴリズムDEVSコーディネーター 変数: 保護者 // 保護者コーディネーター : // 最後のイベントの時刻 : // 次のイベントの時間 // 関連する結合DEVSモデル各 初期化メッセージ(時間t ) を受信したとき子に init-message( t )を送信する; ; スターメッセージを受信したとき(時間t) それから エラー: 同期が不正です。 star-message( t )を送信します; ; x-messageを受信したとき(、時間t ) もしそして== false の場合 エラー: 同期が不正です。 各 x-messageを送信する(、t)子供へ; ; yメッセージを受信したとき(、時間t) それぞれについて x-messageを送信する(、t)子供へもし次に yメッセージを送信します(、t)親へ。 ; ;
FD-DEVS(有限決定論的離散事象システム仕様)は、離散事象動的システムをシミュレーションと検証の両方の方法でモデル化および分析するための形式体系です。FD-DEVSは、従来のDEVSから継承されたモジュール型および階層型のモデリング機能も提供します。
FD-DEVSは元々スケジュール制御可能なDEVS [ 27 ]と呼ばれ、30年間DEVS形式論の未解決問題であったネットワークの検証解析をサポートするように設計されました。さらに、 SP-DEVSのいわゆる「OPNA」問題を解決することも目的としていました。古典的なDEVSの観点から見ると、FD-DEVSには3つの制約があります。
3つ目の制約は、入力イベントによってスケジュールが常に維持されるSP-DEVSからの緩和と見なすこともできます。この緩和によりOPNA問題はなくなりますが、SP-DEVSネットワークの経過時間を抽象化するために使用できるタイムライン抽象化がFD-DEVSネットワークにはもはや役に立たないという制約もあります。[ 27 ]しかし、D. Dill教授によって考案された別の時間抽象化方法[ 28 ]は、FD-DEVSネットワークの有限頂点到達可能性グラフを取得するために適用できます。
2人のプレイヤーが参加する卓球の試合を考えてみましょう。各プレイヤーはFD-DEVSでモデル化でき、プレイヤーモデルには入力イベント「?receive」と出力イベント「!send」があり、 「Send 」と「Wait」の2つの状態があります。プレイヤーが「Send」状態になると、「!send」を生成し、送信時間(0.1時間単位)後に「Wait」状態に戻ります。「Wait」状態のまま「?receive」を受け取ると、再び「Send」状態になります。つまり、プレイヤーモデルは「?receive」を受け取るまで「Wait」状態にとどまります。
完全なピンポン試合を行うには、一方のプレイヤーが初期状態「送信」の攻撃者として、もう一方のプレイヤーが初期状態「待機」の防御者として開始します。したがって、図1では、プレイヤーAが初期攻撃者、プレイヤーBが初期防御者です。さらに、ゲームを継続させるには、図1に示すように、各プレイヤーの「送信」イベントが相手プレイヤーの「受信」イベントと連動する必要があります。
図2(a)に示すように、それぞれスタートノブが付いた2つのスロットがあるトースターを考えてみましょう。各スロットは、焼き時間以外は同じ機能を持っています。最初はノブは押されていませんが、ノブを押すと、対応するスロットがそれぞれの焼き時間(左側のスロットは20秒、右側のスロットは40秒)の間、焼き始めます。焼き時間が経過すると、各スロットとそのノブが飛び出します。対応するスロットが焼き上げられているときにノブを押しても、何も起こらないことに注意してください。
図2(b)に示すように、FD-DEVSでモデル化できます。2つのスロットは、入力イベントが「?push」、出力イベントが「!pop」であるアトミックFD-DEVSとしてモデル化され、状態は「Idle」(I)と「Toast」(T)で、初期状態は「idle」です。スロットが「Idle」のときに「?push」(ノブを押すため)を受け取ると、状態が「Toast」に変わります。つまり、「?push」イベントを受け取らない限り、スロットは永久に「Idle」のままです。20秒(または40秒)後に、左(または右)スロットは「Idle」に戻ります。
どこ
図1に示す卓球の例におけるプレーヤーの形式的な表現は、次のように表すことができます。どこ={?receive};={!send};={送信、待機};=プレイヤーAを呼び出し、プレイヤーBを待つ。(送信)=0.1、(待つ)=;(待機、?受信)=(送信、1)(送信、?受信)=(送信、0);(送信)=(!送信、待機)(待つ)=(、 待って)。
図2(a)および(b)に示す2スロットトースターのスロットの正式な表現は、次のように表すことができます。どこ={?push};={!pop};={I, T};=I;(T)=左スロットの場合は20、右スロットの場合は40、(I)=;(I, ?push)=(T,1),(T,?push)=(T,0);(T)=(!pop, I)(I)=(、 私)。
前述のとおり、FD-DEVSはSP-DEVSの緩和クラスです。つまり、FD-DEVSはSP-DEVSの上位クラスです。このWikipediaでは、 SP-DEVSで使用される横断歩道信号制御器のFD-DEVSモデルを示します。どこ={?p};={!g:0, !g:1, !w:0, !w:1};={BG、BW、G、GR、R、W、D};=BG、(BG)=0.5、(BW)=0.5、(G)=30、(GR)=30、(R)=2、(W)=26、(D)=2;(G,?p)=(GR,0),(s,?p)=(s,0) sの場合G;(BG)=(!g:1, BW)(BW)=(!w:0, G)(G)=(、G)(GR)=(!g:0, R)(R)=(!w:1, W)(W)=(!w:0, D)(D)=(!g:1, G);
FD-DEVSモデル、開発者どこ
DEVSの動作の詳細については、 「アトミックDEVSの動作」のセクションを参照してください。
図3は、図1で紹介した卓球ゲームをプレイするプレイヤーAのイベントセグメント(上)とそれに関連する状態軌跡(下)を示しています。図3では、プレイヤーAの状態は(状態、寿命、経過時間)=()と図 3 の下部の線分は経過時間の値を表します。プレイヤー A の初期状態は「送信」で、その寿命は 0.1 秒なので、(送信、0.1、)は0.1であり、これは(Wait, inf, 0) に変更した後0でリセットされますが、プレイヤーAはいつリセットされるかを知りませんは再び 0 になります。しかし、プレイヤー B が 0.1 秒後にプレイヤー A にボールを送り返すため、プレイヤー A は 0.2 秒で (Send, 0.1 0) に戻ります。その時点から 0.1 秒後、プレイヤー A の状態が (Send, 0.1, 0.1) になったとき、プレイヤー A はプレイヤー B にボールを送り返し、(Wait, inf, 0) になります。このように、「Send」と「Wait」の間を行ったり来たりするこの循環的な状態遷移は永遠に続きます。
図4は、図2で紹介した2スロットトースターの左スロットのイベントセグメント(上)とそれに関連する状態軌跡(下)を示しています。図3と同様に、左スロットの状態は(状態、寿命、経過時間)=(図4の(Wait, inf, )の高さは、) は、?push が発生するタイミングによって決定できます。図 4 は、?push が時刻 40 で発生し、トースターが (T, 20, 0) に変化するケースを示しています。その時点から 20 秒後にステータスが (T, 20, 20) になると、トースターは (Wait, inf, 0) に戻りますが、再び「Toast」に戻るタイミングはわかりません。図 4 は、?push が時刻 90 で発生し、トースターが (T, 20, 0) になるケースを示しています。時刻 97 で誰かが再び押すにもかかわらず、ステータス (T, 20, 7) は全く変化しないことに注意してください。(T,?push)=(T,1)。
入力イベントによって保存または変更可能な非負の有理値寿命と有限個の状態およびイベントの特性により、D. Dill 教授によって導入された時間抽象化手法を使用して経過時間の無限個の値を抽象化することにより、FD-DEVS ネットワークの動作を等価な有限頂点到達可能性グラフとして抽象化できることが保証されます。[ 28 ]有限頂点到達可能性グラフ (RG) を生成するアルゴリズムは Zeigler によって導入されています。[ 25 ] [ 31 ]
図5は、図2に示した2スロットトースターの到達可能性グラフを示しています。到達可能性グラフでは、各頂点には、それぞれ離散的な状態とタイムゾーンがあり、これらは範囲です。そして例えば、図 5 のノード (6) の場合、離散状態情報は ((E,)、(T,40))、タイムゾーンは各有向弧は、関連するイベントとリセット モデルのセットとともに、その始点頂点が終点頂点に変化する様子を示します。たとえば、遷移弧 (6) から (5) はpush1イベントによってトリガーされます。その時点で、弧のセット {1} は経過時間 1 (つまり、遷移(6)から(5)が発生すると、0にリセットされる。[ 25 ]
定性的な特性として、FD-DEVSネットワークの安全性は、(1)与えられたネットワークのRGを生成し、(2)いくつかの悪い状態に到達可能かどうかをチェックすることによって決定できます。[ 24 ]
定性的な特性として、FD-DEVS ネットワークの活性は、(1) 与えられたネットワークの RG を生成し、(2) RG から、頂点が強連結成分であるカーネル有向非巡回グラフ(KDAG) を生成し、(3) KDAG の頂点が活性状態の集合を含む状態遷移サイクルを含むかどうかをチェックすることによって決定できます。[ 24 ]
すべての特性関数の特徴、FD-DEVSの決定論的な性質は、非決定論的な振る舞いを持つシステムをモデル化する上で、ある種の制約と見なすことができます。例えば、図1に示す卓球ゲームのプレイヤーが「送信」状態で確率的な寿命を持つ場合、FD-DEVSは非決定論性を効果的に捉えることができません。
安全性と活性を見つけるための到達可能性グラフベースの検証アルゴリズムをサポートするオープンソースライブラリが2つあります。C #で書かれたDEVS# [ 32 ]とPythonで書かれたXSY [ 33 ]です。
DEVSの標準化、特にFDDEVSの使用に関して、Saurabh Mittal博士は同僚とともにFDDEVSのXMLフォーマットの定義に取り組んできました。[ 34 ]この標準XMLフォーマットはUML実行に使用されました。[ 35 ]
SP-DEVS(スケジュール保存型離散イベントシステム仕様)は、シミュレーションと検証の両方の方法で離散イベントシステムをモデル化および分析するための形式体系です。SP-DEVSは、従来のDEVSから継承されたモジュール型および階層型のモデリング機能も提供します。
SP-DEVSは、約30年間DEVS形式論における未解決問題であった、元のネットワークの有限頂点到達可能性グラフの取得を保証することで、ネットワークの検証分析をサポートするように設計されています。ネットワークの到達可能性グラフを取得するために、SP-DEVSには次の3つの制約が課されています。
したがって、SP-DEVSはDEVSとFD-DEVSの両方のサブクラスです。これらの3つの制約により、状態数が有限であっても、SP-DEVSクラスは結合に関して閉じたクラスとなります。この特性により、SP-DEVS結合モデルであっても、いくつかの定性的特性と定量的特性について、有限頂点グラフに基づく検証が可能になります。


横断歩道システムを考えてみましょう。赤信号(または歩行禁止信号)は青信号(または歩行可信号)とは逆の動作をするため、簡略化のために、図1に示すように、青信号(G)と歩行可信号(W)の2つの信号と1つの押しボタンのみを考えます。GとWの2つの信号を、一連のタイミング制約で制御したいと考えています。
2つのライトを初期化するには、Gを点灯させるのに0.5秒かかり、その0.5秒後にWが消灯します。その後、30秒ごとに、誰かが押しボタンを押した場合、Gが消灯しWが点灯する可能性があります。安全上の理由から、Gが消灯してから2秒後にWが点灯します。26秒後にWが消灯し、さらに2秒後にGが再び点灯します。これらの動作が繰り返されます。
上記の要件を満たすコントローラを構築するには、入力イベント「プッシュボタン」(略称:?p)と出力イベント「緑点灯」(!g:1)、「緑消灯」(!g:0)、「歩行開始」(!w:1)、「歩行終了」(!w:0)の4つを考慮することができます。これらは、緑信号と歩行者用信号のコマンド信号として使用されます。コントローラの状態のセットとして、「起動緑」(BG)、「起動歩行」(BW)、「緑点灯」(G)、「緑から赤へ」(GR)、「赤点灯」(R)、「歩行開始」(W)、「遅延」(D)を考慮します。図2に示すように状態遷移を設計しましょう。最初は、コントローラはBG状態から開始し、その寿命は0.5秒です。寿命が経過すると、BW状態に移行し、この時点で「緑点灯」イベントも生成されます。 BW に 0.5 秒間留まった後、寿命が 30 秒の G 状態に移行します。コントローラは、出力イベントを生成せずに G から G にループすることで G に留まり続けることも、外部入力イベント ?p を受け取ったときに GR 状態に移行することもできます。ただし、 GR での実際の滞在時間は、G でのループの残り時間です。GR から、出力イベント !g:0 を生成して R 状態に移行し、R 状態は 2 秒間続き、その後出力イベント !w:1 で W 状態に移行します。26 秒後、!w:0 を生成して D 状態に移行し、D に 2 秒間留まった後、出力イベント !g:1 で G に戻ります。
上記の横断歩道信号制御器は、アトミックSP-DEVSモデルでモデル化できます。正式には、アトミックSP-DEVSは7タプルです。
どこ
図2に示す上記のコントローラは次のように記述できます。どこ={?p};={!g:0, !g:1, !w:0, !w:1};={BG、BW、G、GR、R、W、D};=BG、(BG)=0.5、(BW)=0.5、(G)=30、(GR)=30、(R)=2、(W)=26、(D)=2;(G,?p)=GR、(s,?p)=s sの場合G;(BG)=(!g:1, BW)(BW)=(!w:0, G)(G)=(、G)(GR)=(!g:0, R)(R)=(!w:1, W)(W)=(!w:0, D)(D)=(!g:1, G);
原子SP-DEVSの動態を捉えるには、時間に関連する2つの変数を導入する必要があります。1つは寿命、もう1つは前回のリセットからの経過時間です。を、連続的に増加するのではなく、離散的なイベントが発生する時点によって決まる寿命とする。は経過時間を表し、リセットがない場合、時間とともに継続的に増加します。
図3は、図2に示すSP-DEVSモデルのイベントセグメントに関連付けられた状態軌跡を示しています。図3の上部は、横軸が時間軸であるイベント軌跡を示しており、特定の時間にイベントが発生することを示しています。例えば、!g:1は0.5時間単位、!w:0は1.0時間単位で発生します。図3の下部は、上記のイベントセグメントに関連付けられた状態軌跡を示しており、状態は寿命と経過時間に関連して、例えば、(G, 30, 11) は、状態が G であり、その寿命が 30 であり、経過時間が 11 時間単位であることを示します。図 3 の下部の線分は、SP-DEVS における唯一の連続変数である経過時間の時間の流れを示しています。
SF-DEVS の興味深い特徴の 1 つは、図 3 の時刻 47 で描かれている SP-DEVS のスケジュール制約 (3) が外部イベント ?p が発生したときに維持されることです。この瞬間、状態は G から GR に変化する可能性がありますが、経過時間は変化しないため、時刻 47 で線分は途切れません。まで成長することができますこの例では、30 です。入力イベントからのスケジュールの保持と、時間進行の制限が非負の有理数であること (上記の制限 (2) を参照) により、SP-DEVS モデルでは、各鋸の高さは非負の有理数または無限大 (図 3 の下部に示されているように) になります。
SP-DEVSモデル、開発者どこ
入力イベントによって変化しない非負の有理値寿命と、有限個の状態およびイベントという特性により、経過時間の無限個の値を抽象化することで、SP-DEVSネットワークの動作を等価な有限頂点到達可能性グラフとして抽象化できることが保証されます。
SP-DEVSネットワークの各コンポーネントの経過時間の無限に多くのケースを抽象化するために、スケジュールの順序と相対的な差が保持されるタイムライン抽象化と呼ばれる時間抽象化手法が導入されました。[ 37 ] [ 38 ]タイムライン抽象化技術を使用することで、任意のSP-DEVSネットワークの動作を、頂点とエッジの数が有限である到達可能性グラフとして抽象化できます。
定性的な特性として、SP-DEVSネットワークの安全性は、(1)与えられたネットワークの有限頂点到達可能性グラフを生成し、(2)いくつかの悪い状態が到達可能かどうかをチェックすることによって決定できます。[ 37 ]
定性的な特性として、SP-DEVS ネットワークの活性は、(1) 与えられたネットワークの有限頂点到達可能性グラフ (RG) を生成し、(2) RG から、頂点が強連結成分であるカーネル有向非巡回グラフ(KDAG)を生成し、(3) KDAG の頂点が活性状態の集合を含む状態遷移サイクルを含むかどうかをチェックすることによって決定できます。[ 37 ]
定量的な特性として、SP-DEVSネットワークにおける2つのイベントからの最小および最大処理時間境界は、(1)有限頂点到達可能性グラフを生成し、(2.a)最小処理時間境界の最短パスを見つけ、(2.b)最大処理時間境界の最長パス(利用可能な場合)を見つけることによって計算できます。[ 38 ]
総状態SP-DEVSモデルが受動的である場合そうでなければ、アクティブになります。
SP-DEVSの既知の制限の1つに、「SP-DEVSモデルが一度パッシブになると、アクティブに戻ることはない(OPNA)」という現象があります。この現象は、Hwang氏[ 39 ]によって最初に発見されましたが、元々はODNR(「一度死ぬと、二度と戻らない」)と呼ばれていました。この現象が発生する理由は、上記の制約(3)により、入力イベントによってスケジュールが変更されないため、パッシブ状態からアクティブ状態への復帰ができないためです。
例えば、図3(b)に描かれたトースターモデルは、SP-DEVSではありません。なぜなら、「アイドル」(I)に関連付けられた全体の状態は受動的ですが、トースト時間が20秒または40秒の能動状態「トースト」(T)に移行するからです。実際には、図3(b)に示されているモデルはFD-DEVSです。
DEVS# [ 32 ]と呼ばれるオープンソースライブラリがあり、安全性や活性、最小/最大処理時間境界を見つけるためのアルゴリズムをサポートしています。
{{cite journal}}: CS1メンテナンス: DOIは2025年7月現在非アクティブです(リンク){{cite journal}}: CS1メンテナンス: DOIは2025年7月現在非アクティブです(リンク){{cite conference}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク){{cite conference}}: CS1 maint: 非推奨のアーカイブサービス (リンク) (注:2つの機能に分けられる。そして)