JP2004502234A - Modeling Method of Discrete Event System Using Event Flowchart - Google Patents

Abstract

The present invention relates to a method for modeling a discrete event system using an event flowchart, which can easily describe a discrete event system completely by describing only an event flow without using a state of the discrete event system. A method for modeling a discrete event system comprises: a first step of receiving a request and specification of the discrete event system defined by a user; a second step of extracting and storing events and actions from the request and specification; A third step of generating a tree-type data structure including a start node, and searching the stored event to determine whether or not there is an allowable event in the event represented by the end node. A fourth step of terminating the generation of the data structure if no possible event exists, and a child of the terminal node representing an acceptable event if any of the stored events is present. A fifth step of generating a node; and a fourth step of performing a search for all terminal nodes of the data structure. And a sixth step of repeating the fifth step of generating a child node.

Description

【００８６】
表１に示すように、ＥＦＣにおいて二つのイベントの間に直接リンクが存在する場合、すなわち、二つのイベントがツリー構造で親−子の関係にある場合、ルートに近い親イベントは、子イベントに対する直先行イベント（ｉｍｍｅｄｉａｔｅｌｙ ｐｒｅｃｅｄｉｎｇ ｅｖｅｎｔ、ＩＰＥ）と呼ばれ、ルートから遠い子イベントは、親イベントに対する直後行イベント（ｉｍｍｅｄｉａｔｅｌｙ ｓｕｃｃｅｅｄｉｎｇ ｅｖｅｎｔ、ＩＳＥ）と呼ばれる。
【００８７】
直先行イベント（ＩＰＥ）及び直後行イベント（ＩＳＥ）は、それぞれ直上位状態及び直下位状態と類似している。先行イベント及び後行イベントは、それぞれ上位状態及び下位状態と同様に定義される。直前発生イベント（ｉｍｍｅｄｉａｔｅ ｈａｐｐｅｎｅｄ−ｂｅｆｏｒｅ ｅｖｅｎｔ、ＩＨＢＥ）は、最近起こったイベントであり、ＳＣのカレント状態と類似している。
【００８８】
ＩＨＢＥの転移が許容された許容可能イベントは、転移可能状態と類似している。状態転移に類似したイベントフローとは、イベントの発生と状態転移の遂行を意味する。自己イベントフローは、自己転移と類似しており、禁止されたイベントフローを示す非活性イベントリストは、転移が禁止された転移不能状態集合と類似している。
【００８９】
イベントフローとは、カレント状態で発生した許容可能なイベントの認知、及び該認知による状態転移を意味する。イベントフローの制御とは、イベントフローを定義することであり、これは本質的に状態転移メカニズムと同じである。
【００９０】
本発明に係るＥＦＣは、ＳＣと同等な変形した表現方式である。イベントだけでモデリングが可能な理由は、本質的にそのイベントが、状態転移を決めることができ、状態を置き換えることができる固有の要素であるからである。図２に示されたＳ_ｘ＝ｇ（ｉ_ｊ、Ｓ_ｌ）は回帰式であって、状態はイベントにより決められることを示す。本発明によれば、ＳＣをＥＦＣに変換する方法、及びＥＦＣをＳＣに変換する方法が提供される。
【００９１】
図１０Ａ〜図１０Ｄは、本発明に係る状態チャートからイベントフローチャートへの変換過程を示す。
変換規則Ｉ（ＳＣからＥＦＣへの変換）
ステップ１）ＳＣをツリー形態（状態ツリー）で示す。下位状態の親ノードのように下位状態にリンクした上位状態で、ツリー形態を構成する。
【００９２】
ステップ２）上位状態を基準状態として作成する。
【００９３】
ステップ３）転移を発生させるイベントを端に表示する。
【００９４】
ステップ４）自己転移不能な状態を表示する。
【００９５】
ステップ５）各状態が転移を許容されていない兄弟状態を表示する。
【００９６】
ステップ６）状態をイベントに置き換える。
変換規則ＩＩ（ＥＦＣからＳＣへの変換）
ステップａ）イベントを状態に置き換える。
【００９７】
ステップｂ）上位状態が下位状態を含む包含関係を有するＳＣ図形式によってツリー形態を示す。
【００９８】
ステップｃ）重複された基準状態を除去する。
【００９９】
ステップｄ）転移関係を表示する。
ステップ２）において、上位状態を基準状態に置き換えることは、上位状態の抽象的な特性をなくすためである。ＥＦＣでは、抽象的な上位状態を許容せず具体化された基準状態に置き換える。
【０１００】
ステップ４）とステップ５）とは、状態ツリーが有する表現の制約を克服するための過程である。状態ツリーは、単に「親／子」と言われる階層関係のみを示し、自己転移と兄弟状態間の転移が明確に表現されない。
【０１０１】
状態ツリーにおいて、特別な表示がない限り、基本的に全ての状態で自己転移が可能であり、任意の兄弟状態間の転移が可能である。
【０１０２】
したがって、図１０Ｄの「Ｐａｕｓｅｄ」状態９０３のように、自己転移が不可能であることを示すか、「Ｓｔｏｐｐｅｄ」状態１００１のように「Ｐａｕｓｅｄ」状態９０３に転移不可能に転移不能状態リストを生成する。
【０１０３】
ステップｃ）で重複される基準状態を除去するとは、上位状態に位置した基準状態を除去し、抽象化された上位状態に表現することをいう。
【０１０４】
図１０Ｄは、ＳＣから最終的に誘導されたＥＦＣであって、ここで用いられる用語は、前記表１に示すように、ＳＣの用語と一対一の対応関係を有する。
【０１０５】
図１１は、本発明によってシステム要求及び明細から直接イベントフローチャートを生成する過程を示すフロチャートである。
【０１０６】
本発明に係るＥＦＣの最も重要な長所は、システムの要求明細から抽象的な概念の状態を抽出せずＥＦＣが直接生成でき、従来のシステム記述と全く同一にシステムを記述できるという点である。
【０１０７】
ＥＦＣは、基本的に順次的な先行関係によって生成される。システムが作動し始めると、自動的に帰属される初期状態から、許容可能なイベントを順次的にリンクしてツリー構造のＥＦＣを生成する。この場合、任意にリンクされた二つのイベントは先行関係を形成し、初期状態に近いイベント、すなわちＥＦＣのツリー構造において、親イベントが先行イベント、先行イベントの子イベントは、後行イベントという。許容可能なイベントとその先行関係は、要求明細から容易に抽出されるので、ＥＦＣのツリー構造は容易に生成できる。
【０１０８】
本発明にかかるＥＦＣのシステムモデリング方法は、上述したＳＣのシステムモデリングと完璧に相互変換可能であるという点から従来のシステムモデリング方法と全く同一にシステム記述が可能であるということが分かる。
【０１０９】
図１１に示すように、設計しようとするシステムの要求及び明細はステップＳ１１０１において、本発明に係るＥＦＣＥに入力され、ステップＳ１１０３において、入力された要求及び明細からイベント及びアクションが抽出される。また、抽出された全てのイベント及びアクションは、各々一対一にマッチングされる。
【０１１０】
イベント及びアクションを抽出した後、ステップＳ１１０５において、ＥＦＣのツリー構造を生成するため開始ノードを生成する。したがって、ＥＦＣツリー構造の頂点では、いかなるイベントも定義されない。
【０１１１】
次いで、開始ノードを終端ノードと認識して、該終端ノードから許容可能なイベントが存在しているか否かを、ステップＳ１１０３で抽出されたイベントで判断する（ステップＳ１１０７）。該判断の結果、許容可能なイベントが存在しない場合には、該ＥＦＣツリー構造が全て生成されたものであるため、ＥＦＣ生成プロセスを終了する。
【０１１２】
ステップＳ１１０７での判断の結果、終端ノードから許容可能なイベントが存在する場合、ステップＳ１１０９に進んで、許容可能なイベントを該終端ノードの子ノードとしてツリー構造を生成する。
【０１１３】
次いで、前記生成された子ノードが後述するインタラプトイベント／リターンフロー制御イベント／無条件フロー制御イベントであるか否かを判断して、何れか一つに該当する場合、該子ノードがインタラプトイベント／リターンフロー制御イベント／無条件フロー制御イベントであるという情報を格納する（ステップＳ１１１１）。
【０１１４】
次いで、前記生成された子ノードを終端ノードとして前記ステップＳ１１０７〜Ｓ１１１１を繰り返し実行し、生成されるＥＦＣのツリー構造に存在する全ての終端ノードに対して行う。
【０１１５】
ステップＳ１１０３は、前記入力されたユーザ定義のシステム要求及び明細を、本発明にかかるＥＦＣ生成システムが認識できるコードに変換し、イベント及びアクションを抽出するインコーダー及びパーサにより実行される。抽出されたイベント及びこれに一対一に対応するアクションは、データ格納手段に格納される。
【０１１６】
また、開始ノードを含むＥＦＣツリー構造のノードを生成し、後述するイベント検索器により許容可能なイベントを終端ノードに生成するプロセス（ステップＳ１１０５及びステップＳ１１０９）は、イベントノード生成器により行われる。
【０１１７】
ステップＳ１１０７における各終端ノードイベント毎に許容可能なイベントが存在しているか否かの判断は、イベント検索器により行われる。
【０１１８】
最後にステップＳ１１１１における、各終端イベントがインタラプトイベント／リターンフロー制御イベント／無条件フロー制御イベントであるか否かを判断して、該当イベントにインタラプトフラグ／リターンフロー制御フラグ／無条件フロー制御フラグを生成するプロセスは、フラグ生成器により行われる。
【０１１９】
図１２Ａ〜図１２Ｄは、図７の要求及び明細から図１１のＥＦＣツリー構造を生成する方法によって、ＣＤプレイヤーシステムをイベントフローチャートにモデリングする過程を示す図面である。
【０１２０】
要求明細からＥＦＣを作成する漸進的な過程は、次の通りである。
【０１２１】
（１）ＩＨＢＥ以後に許容するイベントをＩＨＢＥの後行イベントに生成する。但し、初期にはＩＨＢＥが定義されないので、最初に許容するイベントを開始ノードにリンクする。また、後行イベントがイベントフローの可能な位置に既に記述されていると、これを省略する。
【０１２２】
（２）各後行イベントの自己フローが可能か否かを決定し、該後行イベントから転移が許容されない非活性イベントリストを作成する。
【０１２３】
（３）各後行イベントをＩＨＢＥとして前記ステップ（１）、（２）及び（３）を繰り返す。
【０１２４】
「一時停止」機能を追加したＣＤプレイヤーの要求明細からＥＦＣを作成する。
【０１２５】
新しい要求明細は、図７と同様である。
【０１２６】
（ａ）初期状態で許容するイベントをリンクする。電源スイッチを付けるか消すイベントである｛ｉ_１｝５０３、または電源を消す｛ｉ_４｝５０１のみが許容されるので、これを開始ノードにリンクする（図１２Ａ参照）。
【０１２７】
（ｂ） ｛ｉ_４｝５０１の後行イベントを記述する。再び電源を付けるか消すイベントである｛ｉ_１｝５０３と｛ｉ_４｝５０１が許容可能であるが、既に各々兄弟イベントと上位イベントに記述されているので、リンクを省略する（図１２Ｂ参照）。
【０１２８】
（ｃ） ｛ｉ_１｝５０３の後行イベントを記述する。｛ｉ_１｝５０３及び｛ｉ_４｝５０１は、（ｃ）と同じ理由で省略される。これに対し、音楽を再生する｛ｉ_２｝５０５、再生を停止する｛ｉ_３｝１００１、再生を一時停止する｛ｉ_５｝９０３は、初めて記述されるイベントであるので、後行イベントとしてリンクされる（図１２Ｂ参照）。
【０１２９】
（ｄ）一時停止中に｛ｉ_５｝９０３の再発生は、再生を起こさなければならないので、自己フローを不可能にする（図１２Ｃ参照）。
【０１３０】
（ｅ）停止中に｛ｉ_５｝９０３の発生は意味がないので、｛ｉ_３｝１００１の非活性イベントリストに｛ｉ_５｝を含める。以上、処理するイベントがないのでチャート作成を終了する（図１２Ｄ参照）。
【０１３１】
以上のように、要求明細からＥＦＣツリーを生成することは、状態概念を利用する従来の方法より具体化された作業であって、容易く作成できる。
【０１３２】
これは、抽象的な概念の状態を確認する過程が隠され、具体的な現象であるイベントのみを記述するためである。したがって、状態という概念を熟知しない非専門家も容易にモデリングでき、設計者によるモデリング結果の差が大きくないという長所が得られる。
【０１３３】
図１５は、許容可能なイベントを示す例示図である。ＥＦＣのイベントフローは、ＳＣの状態転移と同一なメカニズムを有する。ＳＣの場合、カレント状態において転移可能な状態集合は、自分の直下位状態、自分の兄弟状態、上位状態の兄弟状態である。図９Ｃの「Ｐａｕｓｅｄ」状態９０３において転移可能な状態を検討する。「Ｐａｕｓｅｄ」状態９０３は、直下位状態を有しないので、自分の兄弟状態である「Ｓｔｏｐｐｅｄ」状態５０３、「Ｐｌａｙｉｎｇ」状態５０５、及び上位状態の「Ｐｏｗｅｒ−ｏｎ」状態６０１の兄弟状態である「Ｐｏｗｅｒ Ｏｆｆ」状態５０１への転移が可能である。
【０１３４】
注目すべき点は、ＳＣで上位状態の兄弟状態への転移が表現されないが、そういう転移が可能であるという点である。カレント状態は基本的に上位状態に属するため、上位状態の兄弟状態への転移が可能でなければならない。これによって、「Ｐａｕｓｅｄ」状態９０３が「Ｐｏｗｅｒ−ｏｎ」状態６０１を示すこともあるため、「Ｐｏｗｅｒ−ｏｎ」状態６０１から「Ｐｏｗｅｒ Ｏｆｆ」状態５０１への転移が「Ｐａｕｓｅｄ」状態９０３でも適用される。したがって、「Ｐａｕｓｅｄ」状態９０３の転移可能状態の集合は、［「Ｓｔｏｐｐｅｄ」状態５０３、「Ｐｌａｙｉｎｇ」状態５０５、「Ｐｏｗｅｒ Ｏｆｆ」状態５０１］である。
【０１３５】
ＥＦＣにおいても、同じ方式によってイベントフローを定義する。許容可能なイベントには、直後行イベント、兄弟イベント、先行イベントの兄弟イベントである。イベントフローは、基本的に先行関係に従うが、ＳＣから導入した状態転移方式によって、階層的な形態のイベントフローが可能である。
【０１３６】
図１５は、許容可能なイベントを示す例示図であって、｛ｉ_６｝１５０１で許容可能なイベントフローを示している。フローが可能なイベントには、｛ｉ_６｝１５０１の直後行イベントである［ｉ_１６、ｉ_１７］１５０７、兄弟イベントの［ｉ_７］１５０３、上位イベントの兄弟イベントである［ｉ_３、ｉ_２、ｉ_５］１５０９及び［ｉ_４、ｉ_１］１５１１がある。｛ｉ_６｝１５０１は、自己フローが禁止されているため脱落され、｛ｉ_９｝１５０５は｛ｉ_６｝１５０１の兄弟イベントであるが、非活性イベントとされているため脱落されている。
【０１３７】
図１６は、インタラプトイベント／リターンフロー制御イベントによるイベントフロー制御を示す例示図であり、図１７は、無条件フローによるイベントフロー制御を示す例示図である。
【０１３８】
本発明に係るＥＦＣ生成方法では、拡張された特性を追加してＥＦＣのモデリング性能を高めることができる。第一番目は、インタラプトイベント及びリターンフローである。後述するＥＦＣＥは、全域的なスタックを有し、非同期イベントが発生した時、カレントのノード（ＩＨＢＥ）をプッシュする。
【０１３９】
逆に、リターンフロー制御イベントに会うと、スタックから最近プッシュされたノードをポップして得られた状態で分岐する。このため、リターンフロー制御イベントは、後行イベントを有することができない。
【０１４０】
インタラプトイベントは、本来の状態を復元するために必要な概念である。
【０１４１】
図１６は、インタラプトイベントとリターンフロー制御イベントによるシステム制御の例を示している。ＩＨＢＥが｛ｉ_６｝１４０１である場合、インタラプトイベントの｛ｉ_２０｝１６０１が発生すると、スタックには｛ｉ_６｝１４０１がプッシュされて格納される。
【０１４２】
ＩＨＢＥが｛ｉ_２０｝１６０１である状況において、リターンフロー制御イベントである｛ｉ_２１｝１６０３が発生すると、スタックに格納されていた｛ｉ_６｝１４０１がポップされてＩＨＢＥが｛ｉ_６｝１４０１に更新される。すなわち、リターンフロー制御イベントが発生すると、カレントスタックに格納されているイベントは発生せずＩＨＢＥをスタックに格納されているイベントノードに分岐するのである。リターンフローがリンクしたイベント（｛ｉ_２１｝１６０３）も後行イベントを有することができない。
【０１４３】
第２度目は、無条件フロー制御イベントである。これはイベントフローを強制する手段であって、無条件フローが定義されていると、ＩＨＢＥは無条件フローが定義されたイベントに分岐する。
【０１４４】
無条件フローの導入は、イベントフローが繰り返し記述される時に、重複性をなくすためのものであって、ＥＦＣツリー構造の作成を単純化する。
【０１４５】
図１７は、無条件フローイベントによるシステム制御の例を示している。
【０１４６】
ＩＨＢＥが｛ｉ_６｝１４０１である場合、無条件フロー制御イベントである｛ｉ_７｝１４０３が発生すると、ＩＨＢＥは｛ｉ_７｝１４０３ではなく｛ｉ_７｝１４０３の無条件フローがリンクされた｛ｉ_２｝１７０１に更新される。
【０１４７】
ここで、インタラプトイベント、リターンフロー制御イベント及び無条件フロー制御イベントは、他のイベントと同様にアクションが一対一にマッピングされているが、他のイベントとは異なってインタラプトイベント、リターンフロー制御イベント及び無条件フロー制御イベントが発生する場合に、それぞれマッピングされているアクションが実行されるようにする、或いは実行されないように定義することができる。
【０１４８】
図１３は、本発明に係るイベントフロー制御エンジンの機能ブロック図であり、図１４は、図１３のイベントフロー制御エンジンのイベントフロー制御フロチャートである。
【０１４９】
図１３に示すように、前記の拡張された特性を含むＥＦＣによりイベントフロー制御エンジンＥＦＣＥがモデリングされたシステムを制御し、ＥＦＣＥは、イベントが発生する時毎に駆動される。
【０１５０】
ＥＦＣＥは、制御部１３０１と、イベントマッチング部１３０３と、条件検査部１３０５と、アクション実行部１３０７及びＩＨＢＥアップデート部１３０９とから構成される。
【０１５１】
制御部１３０１は、イベントの入力を待ち受け、イベントが入力された場合、イベントマッチング部１３０３及び条件検査部１３０５を駆動させて、イベントマッチングするか否か（ステップＳ１４０５）及び条件満足するか否か（ステップＳ１４０７）を判断する。イベントがマッチングされ、条件を満足する場合には、アクション実行部１３０７及びＩＨＢＥアップデート部１３０９が駆動されて該入力されたイベントに一対一にマッピングされているアクションを実行Ｓ１４０９し、ＩＨＢＥをアップデートＳ１４１３する。
【０１５２】
イベントマッチング部１３０３は、許容可能なイベントが格納されているキューから入力イベントを検索してイベントマッチングするか否かを判断する。
【０１５３】
条件検査部１３０５は、該入力イベントが実行されるための条件を検査し、条件を満足する場合には、該入力イベントを新しいＩＨＢＥに設定し、アクション実行部１３０７を駆動する。
【０１５４】
アクション実行部１３０７は、条件を満足するイベントに一対一にマッピングされているアクションを行ってモデリングされたシステムを制御する。
【０１５５】
ＩＨＢＥアップデート部１３０９は、現在入力されたイベントがリターンフロー制御イベント、または無条件フロー制御イベントであるか否かを判断して、リターンフロー制御イベント、または無条件フロー制御イベントの場合、条件検査部１３０５で新しく設定したＩＨＢＥを入力されたリターンフロー制御イベント、または無条件フロー制御イベントが定義した新しいＩＨＢＥにアップデートする。すなわち、入力されたイベントがリターンフロー制御イベントである場合には、スタックに格納されているイベントノードを、入力されたイベントが無条件フロー制御イベントである場合には、該イベントが指定するイベントノードにＩＨＢＥをアップデートする。
【０１５６】
図１４に示すように、ステップＳ１４０１において、ＥＦＣＥは初期に待ち受け状態にあり、ステップＳ１４０３において、イベントの発生、すなわちＥＦＣＥへのイベント入力を認知して、イベントフローを制御する。ステップＳ１４０５において、イベントフロー制御は、まず発生したイベントが許容可能なイベントであるか否かを検査するイベントマッチングを開示する。すなわち、入力されたイベントがＥＦＣの現在ＩＨＢＥで許容可能なイベントの中から定義されたイベントであるか否かを検査する。この場合、自己フローが禁止されたＩＨＢＥと非活性イベントリストに含まれたイベントは、イベントマッチング検査から除外される。
【０１５７】
入力されたイベントがマッチングされると、すなわち、入力されたイベントがＥＦＣの現在ＩＨＢＥで許容可能なイベントの中から定義されたイベントである場合、入力されたイベントの条件に対して検査する（ステップＳ１４０７）。
【０１５８】
条件検査が満足されると、入力されたイベントノードを現在ＩＨＢＥに設定し、入力されたイベントと一対一にマッピングされているアクションを実行してモデリングされたシステムを制御する（ステップＳ１４０９）。アクション実行後には、ステップＳ１４０９で設定されたＩＨＢＥのアップデートが必要であるか否かを判断する（ステップＳ１４１１）。
【０１５９】
すなわち、入力されたイベントがリターンフロー制御イベント、または無条件フロー制御イベントであるか否かを判断する。判断結果、ＩＨＢＥアップデートが必要な場合にはＩＨＢＥアップデートを行う（ステップＳ１４１３）。すなわち、入力されたイベントがリターンフロー制御イベントである場合には、カレントスタックに格納されているイベントノードをポップして新しいＩＨＢＥに設定し、入力されたイベントが無条件フロー制御イベントである場合には、無条件フロー制御イベントで定義している目的イベントノードを新しいＩＨＢＥに設定する。
【０１６０】
図１８は、本発明の実施の形態に係るイベントフローチャートモデリング及びイベントフロー制御エンジンが実行されたシステムのインターフェースを示す図面であり、図１９Ａ〜図１９Ｉは、本発明の実施の形態に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【０１６１】
図１８に示すように、ＭＰ３プレイヤーをモデリングした例示図として、インターフェース左側領域１８０５には、オブジェクト単位で構成されるＭＰ３プレイヤーシステムの外形が示されており、右側領域１８０７には、本発明によってモデリングしたＭＰ３プレイヤーシステムのＥＦＣのツリー構造が示されている。右上側領域（１８０１及び１８０３）には、具体的なイベント及びそれに一対一にマッピングされるアクションが表示される。モデリングされた結果は、本発明に係るＥＦＣＥにより直接的な制御が可能である。
【０１６２】
上述したような本発明の方法は、プログラムで実行されコンピュータ読み取り可能な記録媒体（ＣＤ−ＲＯＭ、ＲＡＭ、ＲＯＭ、フロッピーディスク、ハードディスク、光磁気ディスクなど）に格納することができる。
【０１６３】
上述したように、本発明に係るＥＦＣは、抽象的な状態に対する考慮なしに直観的で、かつ明確なモデリングを可能にする。これは、ＳＣが有するモデリングの困難さ及び設計者によるモデリングの偏差をなくすと共に、モデルの実行及び修正を容易にするという利点がある。したがって、状態システムに対する知識が不足した者であっても、容易に状態システムをモデリングすることができ、設計者によるモデリングの差を最小化することができるという効果がある。
【０１６４】
また、本発明の実施の形態に係るＥＦＣのもう一つの長所は、チャート作図の容易さにある。ＳＣでは、状態間の階層関係はダイヤグラム形態に表現し、状態間の転移関係は、リンク線で表現される。それに対し、ＥＦＣは単純なツリー構造であって、階層関係及び転移関係が同時に表現される。したがって、チャートを非常に単純化することができるという効果が得られる。また、チャートを修正する場合にもＥＦＣが有利である。ＳＣでは、新しい下位状態を表現するために、上位状態のダイヤグラムのサイズを大きくし（連鎖的に上位状態のサイズが大きくならなければならない）、新しい下位状態を描かなければならない。しかしながら、ＥＦＣでは、ツリーに対し単に新しいノードを追加するという簡単な方法で修正をすることができる。
【０１６５】
尚、本発明は、上記の本実施の形態に限られるものではない。本発明の趣旨から逸脱しない範囲内で多様に変更して実施することが可能である。
【図面の簡単な説明】
【図１】離散イベントシステムの開発過程を示すフロチャートである。
【図２Ａ】非状態システム及び状態システムの特徴を示す図面である。
【図２Ｂ】非状態システム及び状態システムの特徴を示す図面である。
【図３】ＣＤプレイヤーの要求及び明細を示す図面である。
【図４】図３の要求及び明細から抽出されたイベント、アクション及び状態を示す図面である。
【図５】図３の要求及び明細によりモデリングされた状態転移図を示す図面である。
【図６】図３の要求及び明細によりモデリングされた状態チャートを示す図面である。
【図７】図３の要求及び明細に一時停止機能を追加した要求及び明細を示す図面である。
【図８】図７の要求及び明細から抽出されたイベント、アクション及び状態を示す図面である。
【図９Ａ】図７の要求及び明細によりモデリングされた相異なる状態チャートを示す図面である。
【図９Ｂ】図７の要求及び明細によりモデリングされた相異なる状態チャートを示す図面である。
【図９Ｃ】図７の要求及び明細によりモデリングされた相異なる状態チャートを示す図面である。
【図１０Ａ】状態チャートから本発明に係るイベントフローチャートを変換させる過程を示す図面である。
【図１０Ｂ】状態チャートから本発明に係るイベントフローチャートを変換させる過程を示す図面である。
【図１０Ｃ】状態チャートから本発明に係るイベントフローチャートを変換させる過程を示す図面である。
【図１０Ｄ】状態チャートから本発明に係るイベントフローチャートを変換させる過程を示す図面である。
【図１１】本発明によってシステム要求及び明細から直接イベントフローチャートを生成する過程を示すフロチャートである。
【図１２Ａ】図７の要求及び明細からＣＤプレイヤーシステムをイベントフローチャートにモデリングする過程を示す図面である。
【図１２Ｂ】図７の要求及び明細からＣＤプレイヤーシステムをイベントフローチャートにモデリングする過程を示す図面である。
【図１２Ｃ】図７の要求及び明細からＣＤプレイヤーシステムをイベントフローチャートにモデリングする過程を示す図面である。
【図１２Ｄ】図７の要求及び明細からＣＤプレイヤーシステムをイベントフローチャートにモデリングする過程を示す図面である。
【図１３】本発明の実施の形態に係るイベントフロー制御エンジンの機能ブ　ロック図である。
【図１４】図１３のイベントフロー制御エンジンのイベントフロー制御フロチートである。
【図１５】許容可能なイベントを示す例示図である。
【図１６】インタラプトイベント／リターンフローに応じたイベントフロー制御を示す例示図である。
【図１７】無条件フローに応じたイベントフロー制御を示す例示図である。
【図１８】本発明に係るイベントフローチャートモデリング及びイベントフロー制御エンジンが実行されたシステムのインターフェースを示す図面である。
【図１９Ａ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｂ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｃ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｄ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｅ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｆ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｇ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｈ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。
【図１９Ｉ】本発明に係るイベントフロー制御エンジンを実行した擬似プログラムコードを示す図面である。[0001]
(Technical field)
The present invention relates to the modeling and execution of a Discrete Event System (DES), and more particularly, to a method of modeling a DES according to an event flow chart (EFC), and an event for executing the DES modeled by the EFC. The present invention relates to a flow control engine (Event Flow Control Engine, EFCE).
(Background technology)
First, terms used in the present specification for describing the present invention are as follows.
[0002]
(1) State: This is for describing the operation of the system, and is defined by system attributes (attributes or attributes). The state of the system changes over time, and at any time the system must belong to a particular state.
[0003]
Taking a simple CD player as an example, a CD player whose power is on has a state such as "playing" or "stopped" and belongs to a specific state.
[0004]
(2) Immediate substate: The concept of a state is hierarchical, and an arbitrary state can be expressed by a plurality of subordinate states. Such a subordinate state is called an immediate substate. .
[0005]
For example, in the case of a CD player, “playing” and “stopped” can all be said to be immediately below “power-on”.
[0006]
(3) Immediate super state: This is the opposite concept of the immediate lower state.
[0007]
In the example of the CD player, the “power-on” state is a state immediately above “playing” and “stopped”. The immediate upper-level state is an abstract concept of the immediate lower-level state, and can be said to be a state representing the immediate lower-level state. Thus, in the example of the CD player, the “playing” state can be said to be a “power-on” state.
[0008]
(4) Substate: This is an extended concept of the immediate lower state. The immediately lower-order state of the immediately lower-order state, including the immediately lower-order state, is called the lower-order state.
[0009]
(5) Super state: This is an extended concept of the immediately higher state. Including the immediately higher-order state, the upper-order state of the immediately higher-order state obtained repeatedly is called the upper-order state.
[0010]
(6) sibling state: refers to a state having the same immediate superordinate state.
[0011]
In the example of the CD player, “playing” and “stopped” are sibling states having the same immediate higher state of “power-on”.
[0012]
(7) Hierarchical depth: means the number of higher-level states.
[0013]
(8) Active state: A state in which the system is currently stopped.
[0014]
In contrast, the remaining state is called an inactive state. The active state is also called a current state.
[0015]
(9) State transition: A change in the active state of the system from the current state to another state.
[0016]
(10) Event: A change that occurs inside or outside the system that affects DES. An event is an input to the system that occurs inside or outside the system, and is a specific phenomenon that causes a change in the state of the output of the system.
[0017]
(11) Condition (guard condition): A condition for determining whether or not a state transition is permitted.
[0018]
(12) action: An event generated by the system when a state transition occurs, and is an output of the system.
[0019]
(13) State Transition Diagram (STD): A method proposed by Moore and Mealy, which expresses a transition relationship between states.
[0020]
(14) State Chart: An extended form of STD proposed by David Harel. This is an extension of the existing STD to add a hierarchical structure and express parallel state (orthogonality).
[0021]
(15) Transition-allowed state: A state in which transition from the current state (current state) is possible.
[0022]
FIG. 1 is a flowchart showing a development process of the discrete event system (DES).
[0023]
Generally, as shown in FIG. 1, the DES development process includes a “requirement and specification” step S101 for describing the function of the DES, an “analysis and design” step S103 for modeling the DES in accordance with the requirements and specification, and a modeling result. Is executed, and an “verification” step S107 for verifying the DES is performed.
[0024]
This DES development process is usually repeated many times until the DES satisfies the requirements and specifications. This DES development process is repeated from the "request and specification" step S101 when an error is detected or when the DES requires a function change.
[0025]
The “analysis and design” step S103 includes, in detail, substeps of a “system description” step, an “element confirmation” step, an “element relation description” step, and a “dynamic behavior modeling” step.
[0026]
The present invention has a design method and an execution method of a discrete event system (DES), and more particularly, a description method of a dynamic operation of the DES and an execution method thereof, which are required in the “analysis and design” step S103. Provided by
[0027]
2A and 2B are diagrams illustrating characteristics of a non-state system and a state system.
[0028]
DES is a system in which the occurrence of an event causes a reaction of the system. DES is divided into a non-state system and a state system.
[0029]
A non-state system has an output that depends only on its inputs, as shown in FIG. 2A, and its operation is relatively simple. I is DES input i _j O is the output O of the DES _k S is the DES state S _l And f is an output function.
[0030]
The state system has an output that depends on both the input and the state of the DES, as shown in FIG. 2B, and its operation is relatively complex. State systems require a substep of "Modeling Dynamic Behavior". Function g is a state function.
[0031]
The difference between a non-state system and a state system is apparent from FIGS. 2A and 2B.
[0032]
As shown in FIGS. 2A and 2B, in the non-state system, “O _k = F (i) ", so what is needed when modeling a non-state system is to check the output function f (•). Therefore, modeling a non-state system is a relatively easy process that only requires a relationship between inputs and outputs.
[0033]
In contrast, most real systems are state systems. The output function f (·) of the state system is the state variable S which is the current state. _l That is, the state variable S _l Is the output o _k Needed to determine the Next state S _x Is the state function S _x = G (i _j , S _l ).
[0034]
The difficulty in modeling a state system is higher than in modeling a non-state system due to the description of state changes.
[0035]
FIG. 3 shows the request and specification of the CD player, FIG. 4 shows the events, actions and states extracted from the request and specification of FIG. 3, and FIG. 5 shows the request and specification of FIG. FIG. 6 is a modeled state transition diagram, and FIG. 6 is a modeled state chart according to the requirements and specifications of FIG.
[0036]
To express the state change, there is a state transition diagram (STD) proposed by Moore and Mealy, and a state chart (State Chart: SC) proposed by David Harel (FIG. 5 and FIG. 5). See FIG. 6).
[0037]
The STD expresses a transition between states and is monotonously described. Input event i causing state transition _j Is usually displayed on the STD.
[0038]
The STD state transition process is as follows.
(1) An event occurs,
(2) Check the guard condition,
(3) State transition is performed under conditions that satisfy the guard condition.
[0039]
The exit action of the current state, the state change, and the entry action of the target state are performed continuously in the execution of the state transition.
[0040]
As an example of a CD player, FIG. 4 shows the input (I, event) / output (O, action) / state (S) identified from the given request and specification in FIG.
[0041]
FIG. 5 shows an STD represented by input (I, event) / output (O, action) / state (S) in FIG. The default state 501 is an initial state or a sub-state in which the CD player automatically enters when the CD player enters an arbitrary state.
[0042]
STDs have been widely used due to their flat structure, which has been able to visually represent the transition relation between states and increase the efficiency of modeling, but has the drawback of not being able to represent the transition relation between complex states. Did not.
[0043]
Harel's SC overcomes the shortcomings of this STD. The SC can express a hierarchical state transition relationship.
[0044]
Any state of the SC can have a number of subordinate sub-states within it, and is a generalized form of a state diagram.
[0045]
FIG. 6 shows SCs represented by input (I, event) / output (O, action) / state (S) in FIG.
As in the example of the CD player shown in FIG. 6, the “Stopped” state 503 and the “Playing” state 505 are possible states only when the power is on, and the “Power-On” state 601 is , “Stopped” state 503 and “Playing” state 505. As a result, the “Stopped” state 503 and the “Playing” state 505 become lower-order states 601 of “Power-On”, and the “Power-On” state 601 is an upper state of the “Stopped” state 503 and the “Playing” state 505. (Super-state).
[0046]
Since the CD player automatically enters the “Stopped” state 503, the “Stopped” state 503 is the reference state of the “Power-On” state 601.
[0047]
Harel's SC is a commercial software for visual modeling of DES using the concept of SC, such as "STATEMETE" of "I-Logix", "BetterState" of "MatrixX", and "Stateflow" of "Matlab". It has been implemented.
[0048]
A similar concept is used in "Rapid" of commercial software "Emultek" used for designing a human-device interface. Yes (the referenced software and / or company name may be a registered trademark belonging to that company).
[0049]
Modeling DES with SC methodology is known to be advantageous for DES implementation, modification, and extension for accurate description of DES dynamic behavior.
[0050]
However, it is difficult to model DES by SC methodology. Modeling DES with the SC methodology basically requires accurate confirmation of the DES state. It is quite possible that there is a modeling flow that cannot be imagined, and because of the abstraction of the concept of "state", the results of modeling DES with the SC methodology can vary with the designer.
[0051]
Therefore, for non-experts, it is difficult to model DES with SC methodology, and different views of experts will result in different SC DES models.
[0052]
A CD player is a very simple system with only three states, but can be modeled with different views as shown in FIGS.
[0053]
Due to the abstract nature of the concept "state", the modification and extension of already completed DES models is also complicated.
[0054]
FIG. 7 illustrates a request and a description obtained by adding a suspension function to the request and the description of FIG. 3, and FIG. 8 illustrates events, actions and states extracted from the request and the description of FIG. 9A-9C show three different types of state charts modeled according to the requirements and specification of FIG.
[0055]
The request / specification and the event / action / state in FIGS. 3 and 7 indicate that the CD player in the “play” state after the “stop” state plays a track from the first track. On the other hand, CD players in the "play" state after the "pause" state are different from each other in that they play tracks from the original position.
[0056]
Various modeling depending on the designer are exemplified below.
[0057]
Modeling I defines “Paused” as a substate of “Stopped” state 503.
[0058]
Modeling II defines “Paused” as a substate of the “Playing” state 505.
[0059]
Modeling III defines “Paused” as a sibling of the “Stopped” state 503 and the “Playing” state 505.
[0060]
9A to 9C show SCs corresponding to the modeling I / II / III, respectively.
[0061]
It is difficult to determine which model is better in that the efficiency of the model is determined by the purpose and execution of the DES. However, the efficiency of development decreases when people work together to develop different models from the same DES. In addition, since the views of the same designer change depending on the case, there is a problem that the consistency of development is also reduced.
[0062]
In order to solve the problem of the abstraction in the conventional SC, the features of the event are emphasized as a message sequence chart (MSC: message sequence chart) of International Telecommunication Union (ITU) or a company of "Cycore" “Cult3D” has been proposed.
[0063]
The MSC message is an overall communication phenomenon including data transmission and function call, and can be treated as an event. The MSC can be said to be a structural method of describing a data flow by dealing with message transmission between elements constituting the DES.
[0064]
The same concept is used in a sequence diagram and a collaboration diagram of a UML (Unified Modeling Language) similar to the MSC, and these are considered to be slightly modified versions of the MSC.
[0065]
The disadvantage, however, is that such an MSC cannot describe a control flow that controls the entire DES, including the data transmission or the operation within the component itself, in that it only describes the data transmission.
[0066]
In “Cult3D”, unlike the MSC, the operation of the DES is described. However, in “Cult3D”, an operation can be described only for a non-state system, and therefore, a state depending on the operation cannot be described. That is, “Cult3D” ignores the state change and _k = F (i _j ) Describes only the relationship between input and output, and thus has a weak point that dynamic operation of DES cannot be described.
[0067]
The following references are helpful in understanding the present invention.
[0068]
1) David Harel, "Stattecharts, a visual approach to complex systems", Science of Computer Programming, 1987.
2) David Harel, "On Visual Formalism", Communication of the ACM, pp 514-530, May 1988.
3) David Harel, "STATEMATE: A Working Environment for Development of Complex Reactive System", IEEE Transactions, Software Agency, April 1979.
4) D. Coleman, F.C. Hayes and S.A. Bear, "Introducing objectcharts or how to use starts in inobject-oriented design", IEEE Transactions on software engineering. 18, no. 1, pp. 9-18, January 1992.
5) D. Budgen, "Software Design", Addison Wesley, pp 123-135, 1994.
6) Anti Auer, "State Testing of Embedded Software, University of Oulu, Department of Information Processing and Information Technology and Information Technology.
7) P.S. Ramadge and W.S. M. Wonham, “The Control of Discrete Event Systems”, Proceedings of the IEEE, Vol 77, No. 1, 1989.
8) Quatani, Terry. "Visual Modeling with Rational Rose and UML," Addison Wesley, 1998.
9) Gomaa, Hassan. , "Software Design Methods for Concurrent and Real-Time Systems", Addison Wesley, 1993.
10) ITU (International Telecommunication Union), "ITU-T Recommendation Z.120-Message Sequence Chart", ITU, November 1999.
(Disclosure of the Invention)
Therefore, the present invention is a method of modeling a discrete event system (DES) using an event flow chart (EFC), and easily and thoroughly describes a DES simply by describing an event flow without a concept of a state in the DES. It is an object of the present invention to provide a method capable of performing the method, and a computer-readable recording medium recording a program for executing the method.
[0069]
It is another object of the present invention to provide a system for controlling an EFC-modeled DES according to the method according to the present invention.
[0070]
Those skilled in the art to which the invention pertains will readily recognize other objects and advantages of the invention from the drawings, detailed description and claims.
[0071]
According to one aspect of the present invention, there is provided a method of modeling a discrete event system, comprising: a first step of receiving a request and specification of the discrete event system defined by a user; and an event and an action from the request and specification. A second step of extracting and storing the event, a third step of generating a tree-type data structure including a start node, and searching the stored event to determine whether an event allowable in the event represented by the end node is available. Judging whether or not there is an acceptable event, if there is no acceptable event, a fourth step of terminating the generation of the data structure, and if there is an acceptable event in the stored event, A fifth step of generating child nodes of the terminal node, which expresses a specific event, Te, modeling method of the discrete event system, characterized in that it comprises a sixth step of repeating the fifth step of generating the fourth step child nodes to search are provided.
[0072]
According to an aspect of the present invention, there is provided a program for executing a method of modeling DES in a modeling system including a processor, the method including receiving a request and specification of the discrete event system defined by a user. A first function for extracting and storing events and actions from the request and the specification, a third function for generating a tree-type data structure including a start node, and a method for retrieving the stored events. A fourth function of determining whether there is an allowable event in the event represented by the terminal node, and terminating the generation of the data structure when there is no allowable event; A fifth device that generates a child node of the terminal node, which represents the allowable event, when an allowable event exists. And a sixth function of repeating a fourth function of performing a search and a fifth function of generating a child node for all terminal nodes of the data structure. A possible recording medium is provided.
[0073]
According to an aspect of the present invention, in a modeling system for modeling a discrete event system, a request and specification of the discrete event system defined by a user are received and converted into a code readable by the modeling system. Encoding means; parsing means for extracting event and action data from the code converted by the encoding means; storage means for storing the extracted event and action data; and a tree type including a start node and an end node. Event node generating means for generating and storing a data structure; and searching for event data stored in the storing means, wherein, in the tree-type data structure, allowable event data for the event data represented by the terminal node is determined. Exists or not It is determined that if there is no acceptable event, the tree-type data structure generation is terminated, and if there is acceptable event data, the acceptable event data is set as a child node of the terminal node. An event search means for activating the event node generator for generating the event node generator is provided.
[0074]
According to an aspect of the present invention, there is provided an event flow control system for executing an event flowchart modeled by the modeling system, wherein the input event is an event allowable from a current node representing the event. And a condition for executing the input event is satisfied when it is determined that the input event is an event allowable from the current node from the event matching unit. A condition checking means for determining whether or not the input event is executed by the condition checking means when the condition for executing the input event is determined to be satisfied; Perform the actions that drive the modeled system An event flow chart execution system is provided, comprising: an action performing means for updating the current node when the input event is the return flow control event or the unconditional flow control event. You.
[0075]
According to the present invention, it is possible to minimize the modeling error by eliminating the abstraction of the SC and also to minimize the difference in modeling between designers.
[0076]
The present invention includes an EFC-based modeling method and an execution method to solve the problems of the past DES modeling method.
[0077]
In the EFC modeling process, an interrupt event, a return flow, and an unconditional flow are additionally defined to increase the efficiency of the modeling.
[0078]
The interrupt event is used to store the event that has just occurred, and upon encountering a return flow, forces the flow to the stored event. This is useful for the system to restore the previous event flow and resume the original work.
[0079]
The unconditional flow refers to leaving the rule of the event flow control and exceptionally forcing the event flow. This is useful for avoiding duplication and simplifying the chart when repeating the same form of event flow.
[0080]
The EFC generated by the present invention is executed by the event flow control engine, which is composed of four step modules.
[0081]
The four steps of the event flow control include an event matching unit, a condition inspection unit, an action execution unit, and an IHBE update unit. The event matching means performs a function of searching whether or not the actually generated event belongs to a set of allowable events, and the condition checking means determines whether or not the flow to the successfully matched event is possible. Perform inspection function. If the result of the condition check is possible, the action execution unit performs an action of the system, and the IHBE update unit performs IHBE update for the next event flow.
(Best Mode for Carrying Out the Invention)
The above and other objects and features of the present invention will become more apparent from the following detailed description of preferred embodiments in connection with the accompanying drawings. First, when attaching a reference numeral to a component in each drawing, attention has been paid so that the same component is given the same number as much as possible, even if it is shown in different drawings. Further, when it is determined that the gist of the present invention is not clear due to the specific description in the related known technology, the description is omitted. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.
[0082]
The EFC describes the occurrence of allowable events in the DES, and differs from the SC in that the SC describes an abstract state and the EFC describes a specific event. Is the same modeling in that it describes the dynamic behavior of
[0083]
The state transition process of SC also applies to EFC. In EFC, instead of the term "state transition", the term "event flow" is defined for the purpose of facilitating the creation of EFC by hiding the concept of state. For the same purpose, EFC defines a different term with a similar concept to that of SC.
[0084]
Table 1 below shows EFC terms and corresponding SC terms.
[0085]
[Table 1]

[0086]
As shown in Table 1, when a direct link exists between two events in the EFC, that is, when two events are in a parent-child relationship in a tree structure, a parent event close to the root is assigned to a child event. A child event far from the root is called an immediate preceding event (IME), which is called an immediate preceding event (IPE), and a child event far from the root is called an immediate success event (ISE).
[0087]
The immediate preceding event (IPE) and the immediately succeeding event (ISE) are similar to the immediate upper state and the immediate lower state, respectively. The preceding event and the following event are defined in the same manner as the upper state and the lower state, respectively. The immediate happened-before event (IHBE) is a recent event, and is similar to the current state of the SC.
[0088]
The tolerable event in which IHBE metastasis was allowed is similar to the metastasizable state. The event flow similar to the state transition means occurrence of an event and execution of the state transition. The self-event flow is similar to the self-transfer, and the inactive event list indicating the forbidden event flow is similar to the non-transferable state set in which the transfer is prohibited.
[0089]
The event flow refers to recognition of an allowable event that has occurred in the current state, and state transition based on the recognition. Controlling the event flow is defining the event flow, which is essentially the same as the state transition mechanism.
[0090]
The EFC according to the present invention is a modified expression method equivalent to SC. An event alone can be modeled because the event is essentially a unique element that can determine state transitions and replace states. S shown in FIG. _x = G (i _j , S _l ) Is a regression equation, and indicates that the state is determined by an event. According to the present invention, there is provided a method of converting SC to EFC, and a method of converting EFC to SC.
[0091]
10A to 10D show a process of converting a state chart into an event flowchart according to the present invention.
Conversion rule I (Conversion from SC to EFC)
Step 1) The SC is shown in a tree form (state tree). A tree form is composed of a higher-level state linked to a lower-level state like a parent node of a lower-level state.
[0092]
Step 2) Create the upper state as the reference state.
[0093]
Step 3) An event that causes a transition is displayed at the end.
[0094]
Step 4) Display a state in which self transfer is impossible.
[0095]
Step 5) Display sibling states where each state is not allowed to transfer.
[0096]
Step 6) Replace state with event.
Conversion Rule II (Conversion from EFC to SC)
Step a) Replace events with states.
[0097]
Step b) The tree form is shown in the SC diagram form in which the upper state has an inclusive relation including the lower state.
[0098]
Step c) Remove the duplicated reference state.
[0099]
Step d) Display the transfer relationship.
Replacing the upper state with the reference state in step 2) is for eliminating the abstract characteristics of the upper state. In the EFC, an abstract upper state is not allowed and is replaced with a embodied reference state.
[0100]
Steps 4) and 5) are a process for overcoming the restriction of the representation of the state tree. The state tree shows only the hierarchical relationship referred to as "parent / child", and the self transfer and the transfer between sibling states are not clearly expressed.
[0101]
In the state tree, self-transition is basically possible in all states, and transition between arbitrary sibling states is possible unless otherwise indicated.
[0102]
Therefore, as shown in the “Paused” state 903 of FIG. 10D, it indicates that self-transition is not possible, or a non-transferable state list is generated that cannot be transferred to the “Paused” state 903 as in the “Stopped” state 1001. I do.
[0103]
Removing the duplicated reference state in step c) means removing the reference state located in the upper state and expressing it in the abstracted upper state.
[0104]
FIG. 10D is an EFC finally derived from the SC, and the terms used here have a one-to-one correspondence with the terms of the SC as shown in Table 1 above.
[0105]
FIG. 11 is a flowchart illustrating a process of generating an event flowchart directly from system requirements and specifications according to the present invention.
[0106]
The most important advantage of the EFC according to the present invention is that the EFC can be directly generated without extracting the state of the abstract concept from the required specifications of the system, and the system can be described in exactly the same manner as the conventional system description.
[0107]
An EFC is basically generated by a sequential precedence relationship. When the system starts operating, the allowable events are sequentially linked from the automatically assigned initial state to generate a tree-structured EFC. In this case, two events arbitrarily linked form a predecessor relationship, and an event close to the initial state, that is, in the EFC tree structure, a parent event is a predecessor event, and a child event of the predecessor event is a subsequent event. Since the allowable events and their predecessors are easily extracted from the requirement specification, the EFC tree structure can be easily generated.
[0108]
It can be seen that the system modeling method of the EFC according to the present invention is completely interchangeable with the system modeling of the SC described above, and thus the system description can be exactly the same as the conventional system modeling method.
[0109]
As shown in FIG. 11, the requirements and specifications of the system to be designed are input to the EFCE according to the present invention in step S1101, and events and actions are extracted from the input requests and specifications in step S1103. Also, all the extracted events and actions are matched one-to-one.
[0110]
After extracting the event and the action, in step S1105, a start node is generated to generate an EFC tree structure. Therefore, no events are defined at the top of the EFC tree structure.
[0111]
Next, the start node is recognized as the terminal node, and it is determined whether or not there is an allowable event from the terminal node based on the event extracted in step S1103 (step S1107). If there is no acceptable event as a result of the determination, the EFC tree structure has been completely generated, and the EFC generation process ends.
[0112]
If it is determined in step S1107 that there is an allowable event from the terminal node, the process advances to step S1109 to generate a tree structure using the allowable event as a child node of the terminal node.
[0113]
Next, it is determined whether or not the generated child node is an interrupt event / return flow control event / unconditional flow control event, which will be described later. Information that the event is a return flow control event / unconditional flow control event is stored (step S1111).
[0114]
Next, the steps S1107 to S1111 are repeatedly executed by using the generated child node as a terminal node, and the process is performed for all terminal nodes existing in the tree structure of the generated EFC.
[0115]
Step S1103 is executed by an encoder and a parser that converts the input user-defined system request and specification into codes that can be recognized by the EFC generation system according to the present invention, and extracts events and actions. The extracted event and the action corresponding to the extracted event are stored in the data storage unit.
[0116]
In addition, the process of generating a node of the EFC tree structure including the start node and generating an allowable event at the end node by an event searcher described later (steps S1105 and S1109) is performed by the event node generator.
[0117]
The determination as to whether an allowable event exists for each terminal node event in step S1107 is performed by the event searcher.
[0118]
Finally, in step S1111, it is determined whether each terminal event is an interrupt event / return flow control event / unconditional flow control event, and an interrupt flag / return flow control flag / unconditional flow control flag is assigned to the event. The generation process is performed by a flag generator.
[0119]
12A to 12D are views illustrating a process of modeling a CD player system into an event flowchart according to the method of generating the EFC tree structure of FIG. 11 from the request and description of FIG.
[0120]
The progressive process of creating an EFC from a request specification is as follows.
[0121]
(1) An event allowed after the IHBE is generated as a subsequent event of the IHBE. However, since the IHBE is not initially defined, the event to be permitted is linked to the start node first. If the succeeding event is already described at a possible position in the event flow, this is omitted.
[0122]
(2) Determine whether the self-flow of each subsequent event is possible or not, and create an inactive event list in which transition from the subsequent event is not allowed.
[0123]
(3) The following steps (1), (2) and (3) are repeated with each subsequent event as IHBE.
[0124]
Create an EFC from the request details of the CD player to which the "pause" function has been added.
[0125]
The new requirement is similar to FIG.
[0126]
(A) Linking events allowed in the initial state. Event to turn on / off the power switch @i ₁ $ 503 or turn off the power $ i ₄ Since only $ 501 is allowed, it is linked to the start node (see FIG. 12A).
[0127]
(B) ｛i ₄ Describe the following event of $ 501. It is an event to turn the power on or off again. ₁ $ 503 and $ i ₄ Although $ 501 is acceptable, the link is omitted because it is already described in each of the sibling event and the upper event (see FIG. 12B).
[0128]
(C) ｛i ₁ Describe the subsequent event of $ 503. ｛I ₁ $ 503 and $ i ₄ $ 501 is omitted for the same reason as in (c). On the other hand, the music playback $ i ₂ $ 505, stop playback $ i ₃ $ 1001, pause playback $ i ₅ Since $ 903 is an event described for the first time, it is linked as a subsequent event (see FIG. 12B).
[0129]
(D) During pause, $ i ₅ The re-occurrence of $ 903 makes self-flow impossible, as it must cause regeneration (see Figure 12C).
[0130]
(E) While stopped, ₅ Since the occurrence of $ 903 is meaningless, $ i ₃ $ I in the inactive event list of $ 1001 ₅ Include｝. As described above, since there is no event to be processed, the chart creation ends (see FIG. 12D).
[0131]
As described above, generating an EFC tree from a request specification is a more specific operation than the conventional method using the state concept, and can be easily created.
[0132]
This is because the process of checking the state of the abstract concept is hidden, and only the event, which is a specific phenomenon, is described. Therefore, non-experts who are not familiar with the concept of the state can easily perform modeling, and the advantage that the difference in modeling results between designers is not large is obtained.
[0133]
FIG. 15 is an exemplary diagram showing an allowable event. The EFC event flow has the same mechanism as the SC state transition. In the case of the SC, the state sets that can be transited in the current state are the immediate lower-order state, the own sibling state, and the higher-order sibling state. Consider a state in which transition is possible in the “Paused” state 903 of FIG. 9C. Since the “Paused” state 903 has no immediate lower-level state, it is a sibling state of its own sibling state “Stopped” state 503, “Playing” state 505, and higher-order state “Power-on” state 601. A transition to the "Power Off" state 501 is possible.
[0134]
It should be noted that the SC does not represent the transition to the higher-order sibling state, but such transition is possible. Since the current state basically belongs to the upper state, it must be possible to transfer the upper state to the sibling state. As a result, the “Paused” state 903 may indicate the “Power-on” state 601, and the transition from the “Power-on” state 601 to the “Power Off” state 501 is also applied to the “Paused” state 903. . Therefore, the set of the transferable states of the “Paused” state 903 is [“Stopped” state 503, “Playing” state 505, and “Power Off” state 501].
[0135]
In the EFC, an event flow is defined by the same method. Acceptable events include immediately following events, sibling events, and sibling events of preceding events. Although the event flow basically follows the precedence relation, a hierarchical form of the event flow is possible by the state transition method introduced from the SC.
[0136]
FIG. 15 is a view showing an example of an allowable event. ₆ $ 1501 shows an allowable event flow. Events for which flow is possible include $ i ₆ The event immediately after $ 1501 is [i ₁₆ , I ₁₇ 1507, sibling event [i ₇ ] 1503, which is a sibling event of the upper event [i ₃ , I ₂ , I ₅ ] 1509 and [i ₄ , I ₁ ] 1511. ｛I ₆ $ 1501 is dropped because self-flow is prohibited, and $ i ₉ $ 1505 is $ i ₆ Although it is a sibling event of $ 1501, it has been dropped because it is an inactive event.
[0137]
FIG. 16 is an exemplary diagram showing an event flow control by an interrupt event / return flow control event, and FIG. 17 is an exemplary diagram showing an event flow control by an unconditional flow.
[0138]
In the EFC generation method according to the present invention, an extended characteristic can be added to enhance the modeling performance of the EFC. The first is an interrupt event and return flow. The EFCE described later has a global stack, and pushes the current node (IHBE) when an asynchronous event occurs.
[0139]
Conversely, when a return flow control event is encountered, the node that has recently been pushed from the stack is popped and branched. For this reason, the return flow control event cannot have a subsequent event.
[0140]
An interrupt event is a concept necessary to restore the original state.
[0141]
FIG. 16 shows an example of system control by an interrupt event and a return flow control event. IHBE is $ i ₆ If $ 1401, $ i of the interrupt event ₂₀ When $ 1601 occurs, the stack contains $ i ₆ $ 1401 is pushed and stored.
[0142]
IHBE is $ i ₂₀ In the situation of $ 1601, the return flow control event $ i ₂₁ When $ 1603 occurs, $ i stored in the stack ₆ $ 1401 is popped and IHBE is $ i ₆ It is updated to $ 1401. That is, when the return flow control event occurs, the event stored in the current stack does not occur, and the IHBE branches to the event node stored in the stack. Return flow linked event ($ i ₂₁ $ 1603) also cannot have a subsequent event.
[0143]
The second time is an unconditional flow control event. This is a means for forcing an event flow. If an unconditional flow is defined, IHBE branches to an event in which an unconditional flow is defined.
[0144]
The introduction of the unconditional flow is for eliminating duplication when the event flow is repeatedly described, and simplifies the creation of the EFC tree structure.
[0145]
FIG. 17 shows an example of system control by an unconditional flow event.
[0146]
IHBE is $ i ₆ If it is $ 1401, it is an unconditional flow control event $ i ₇ When $ 1403 occurs, IHBE returns $ i ₇ ｛I instead of｝ 1403 ₇ $ I linked to $ 1403 unconditional flow ₂ It is updated to $ 1701.
[0147]
Here, the actions of the interrupt event, the return flow control event, and the unconditional flow control event are mapped one-to-one like other events, but unlike the other events, the interrupt event, the return flow control event, and the When the unconditional flow control event occurs, it is possible to define whether the mapped action is executed or not executed.
[0148]
FIG. 13 is a functional block diagram of the event flow control engine according to the present invention, and FIG. 14 is an event flow control flowchart of the event flow control engine of FIG.
[0149]
As shown in FIG. 13, the event flow control engine EFCE controls the system in which the event flow control engine EFCE is modeled by the EFC including the extended characteristics, and the EFCE is driven every time an event occurs.
[0150]
The EFCE includes a control unit 1301, an event matching unit 1303, a condition check unit 1305, an action execution unit 1307, and an IHBE update unit 1309.
[0151]
The control unit 1301 waits for an input of an event. When an event is input, the control unit 1301 drives the event matching unit 1303 and the condition checking unit 1305 to determine whether or not to perform event matching (step S1405) and whether or not the condition is satisfied (step S1405). Step S1407) is determined. If the event is matched and the condition is satisfied, the action execution unit 1307 and the IHBE update unit 1309 are driven to execute an action mapped to the input event on a one-to-one basis S1409, and update the IHBE S1413. .
[0152]
The event matching unit 1303 searches for an input event from a queue in which allowable events are stored, and determines whether to perform event matching.
[0153]
The condition checking unit 1305 checks a condition for executing the input event, and when the condition is satisfied, sets the input event to a new IHBE and drives the action execution unit 1307.
[0154]
The action execution unit 1307 controls a system modeled by performing an action mapped one-to-one to an event that satisfies a condition.
[0155]
The IHBE update unit 1309 determines whether the currently input event is a return flow control event or an unconditional flow control event, and if the event is a return flow control event or an unconditional flow control event, the condition check unit At 1305, the newly set IHBE is updated to the input return flow control event or the new IHBE defined by the unconditional flow control event. That is, if the input event is a return flow control event, the event node stored in the stack is replaced with the event node specified by the event if the input event is an unconditional flow control event. To update IHBE.
[0156]
As shown in FIG. 14, in step S1401, the EFCE is initially in a standby state. In step S1403, the occurrence of an event, that is, an event input to the EFCE is recognized, and the event flow is controlled. In step S1405, the event flow control discloses event matching that first checks whether the occurred event is an acceptable event. That is, it is determined whether or not the input event is an event defined from the allowable events of the current IHBE of the EFC. In this case, the IHBE whose own flow is prohibited and the events included in the inactive event list are excluded from the event matching check.
[0157]
If the input event is matched, i.e., if the input event is an event defined among the events that are acceptable in the current IHBE of the EFC, the condition of the input event is checked (step). S1407).
[0158]
If the condition check is satisfied, the input event node is set to the current IHBE, and an action mapped one-to-one with the input event is executed to control the modeled system (step S1409). After executing the action, it is determined whether or not the IHBE set in step S1409 needs to be updated (step S1411).
[0159]
That is, it is determined whether the input event is a return flow control event or an unconditional flow control event. If the result of the determination is that IHBE update is necessary, IHBE update is performed (step S1413). That is, if the input event is a return flow control event, the event node stored in the current stack is popped and set to a new IHBE, and if the input event is an unconditional flow control event, Sets the target event node defined in the unconditional flow control event to the new IHBE.
[0160]
FIG. 18 is a diagram illustrating an interface of a system in which an event flow chart modeling and event flow control engine according to an embodiment of the present invention is executed. FIGS. 19A to 19I are diagrams illustrating an event flow according to an embodiment of the present invention. 6 is a diagram illustrating a pseudo program code that executes a control engine.
[0161]
As shown in FIG. 18, as an example of modeling an MP3 player, an outer shape of an MP3 player system composed of objects is shown in an interface left area 1805, and a model according to the present invention is shown in a right area 1807. The tree structure of the EFC of the MP3 player system is shown. In the upper right area (1801 and 1803), specific events and actions that are mapped on a one-to-one basis are displayed. The modeled result can be directly controlled by the EFCE according to the present invention.
[0162]
The method of the present invention as described above can be executed by a program and stored in a computer-readable recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.).
[0163]
As mentioned above, the EFC according to the present invention allows for intuitive and unambiguous modeling without considering abstract states. This has the advantage of eliminating the difficulty of modeling of the SC and the deviation of the modeling by the designer, as well as facilitating the execution and modification of the model. Therefore, even if a person who lacks knowledge of the state system can easily model the state system, there is an effect that a difference in modeling between designers can be minimized.
[0164]
Another advantage of the EFC according to the embodiment of the present invention resides in ease of chart drawing. In the SC, the hierarchical relation between the states is represented in a diagram form, and the transition relation between the states is represented by a link line. On the other hand, the EFC has a simple tree structure, in which a hierarchical relationship and a transfer relationship are simultaneously expressed. Therefore, an effect is obtained that the chart can be greatly simplified. EFC is also advantageous when modifying charts. In the SC, in order to represent a new lower state, the size of the upper state diagram must be increased (the size of the upper state must increase in a chain), and the new lower state must be drawn. However, with EFC, modifications can be made in a simple way by simply adding new nodes to the tree.
[0165]
Note that the present invention is not limited to the above embodiment. Various changes can be made without departing from the spirit of the present invention.
[Brief description of the drawings]
FIG. 1 is a flowchart showing a development process of a discrete event system.
FIG. 2A is a diagram illustrating features of a non-state system and a state system.
FIG. 2B is a diagram illustrating features of a non-state system and a state system.
FIG. 3 is a diagram showing requirements and specifications of a CD player.
FIG. 4 is a diagram illustrating events, actions, and states extracted from the request and specification of FIG. 3;
FIG. 5 is a diagram illustrating a state transition model modeled according to the requirements and specifications of FIG. 3;
FIG. 6 is a diagram showing a state chart modeled by the requirements and specifications of FIG. 3;
FIG. 7 is a diagram illustrating a request and a description obtained by adding a suspension function to the request and the description of FIG. 3;
FIG. 8 is a diagram illustrating events, actions, and states extracted from the request and specification of FIG. 7;
9A is a diagram illustrating different state charts modeled according to the requirements and specifications of FIG. 7;
9A and 9B illustrate different state charts modeled according to the requirements and specifications of FIG. 7;
FIG. 9C is a diagram illustrating different state charts modeled according to the requirements and specifications of FIG. 7;
FIG. 10A is a diagram illustrating a process of converting an event flowchart according to the present invention from a state chart.
FIG. 10B is a diagram illustrating a process of converting an event flowchart according to the present invention from a state chart.
FIG. 10C is a diagram showing a process of converting an event flowchart according to the present invention from a state chart.
FIG. 10D is a diagram showing a process of converting an event flowchart according to the present invention from a state chart.
FIG. 11 is a flowchart illustrating a process of generating an event flowchart directly from system requirements and specifications according to the present invention.
12A is a diagram illustrating a process of modeling a CD player system into an event flowchart based on the request and description of FIG. 7;
12B is a diagram illustrating a process of modeling a CD player system into an event flowchart based on the request and description of FIG. 7;
FIG. 12C is a diagram illustrating a process of modeling a CD player system into an event flowchart based on the request and specification of FIG. 7;
FIG. 12D is a diagram illustrating a process of modeling a CD player system into an event flowchart from the request and description of FIG. 7;
FIG. 13 is a functional block diagram of the event flow control engine according to the embodiment of the present invention.
FIG. 14 is an event flow control flow chart of the event flow control engine of FIG. 13;
FIG. 15 is an exemplary diagram showing an allowable event.
FIG. 16 is an exemplary diagram showing event flow control according to an interrupt event / return flow.
FIG. 17 is an exemplary diagram showing an event flow control according to an unconditional flow.
FIG. 18 is a diagram illustrating an interface of a system in which an event flowchart modeling and event flow control engine according to the present invention is executed.
FIG. 19A is a view showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19B is a diagram showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19C is a diagram showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19D is a view showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19E is a view showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19F is a diagram showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19G is a diagram showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19H is a view showing a pseudo program code for executing the event flow control engine according to the present invention.
FIG. 19I is a diagram showing a pseudo program code for executing the event flow control engine according to the present invention.

Claims (24)

A method of modeling a discrete event system, comprising:
Receiving a request and specification of the discrete event system defined by a user;
A second step of extracting and storing events and actions from the request and specification;
A third step of generating a tree-type data structure including a start node;
The stored event is searched to determine whether there is an allowable event in the event represented by the terminal node. If there is no allowable event, the generation of the data structure ends. The fourth step,
A fifth step of generating a child node of the terminal node, representing an allowable event, if the stored event includes an allowable event;
And a sixth step of repeating the fourth step of performing a search for all terminal nodes of the data structure and the fifth step of generating a child node. The method of claim 1, further comprising: generating and storing a flag according to whether an event represented by the terminal node is allowed to flow. The method of claim 1, further comprising: generating a flag according to whether an event represented by the terminal node is an interrupt event. The interrupt event is
4. The method of claim 3, wherein when the interrupt event occurs, a current node representing the event is pushed and stored on a stack. The method of claim 1, further comprising: generating a flag according to whether the event represented by the terminal node is a return flow control event. The return flow control event,
6. The method according to claim 5, wherein when the return flow control event occurs, a node stored in a current stack is popped and branched to the node. The method of claim 1, further comprising: generating a flag according to whether the event represented by the terminal node is an unconditional flow control event. The unconditional flow control event is
8. The method according to claim 7, wherein when the unconditional flow control event occurs, a branch is made to a node representing a predetermined event. A program for performing a method of modeling DES in a modeling system having a processor, the system comprising:
A first function of receiving a request and specification of the discrete event system defined by a user;
A second function of extracting and storing an event and an action from the request and the specification,
A third function for generating a tree-type data structure including a start node;
The stored event is searched to determine whether there is an allowable event in the event represented by the terminal node. If there is no allowable event, the generation of the data structure ends. Features and
A fifth function of generating a child node of the terminal node, which represents an allowable event when an allowable event exists in the stored event;
A computer-readable recording program for causing a computer to execute a fourth function of performing a search and a sixth function of repeating a fifth function of generating a child node for all terminal nodes of the data structure. recoding media. 10. The computer-readable recording program according to claim 9, wherein the event represented by the terminal node further implements a seventh function of generating and storing a flag depending on whether a self-flow is permitted. Possible recording medium. The computer-readable recording medium according to claim 9, further comprising an eighth function of generating a flag depending on whether the event represented by the terminal node is an interrupt event. The interrupt event is
The computer-readable recording medium according to claim 11, wherein when the interrupt event occurs, a current node representing the event is pushed and stored on a stack. 10. The computer readable recording according to claim 9, wherein a ninth function of generating a flag is further realized depending on whether the event represented by the terminal node is a return flow control event. Medium. The return flow control event,
14. The computer-readable recording medium according to claim 13, wherein when the return flow control event occurs, a node stored in a current stack is popped and branched to the node. 10. The computer-readable recording medium according to claim 9, further comprising a tenth function of generating a flag depending on whether the event represented by the terminal node is an unconditional flow control event. recoding media. The unconditional flow control event is
16. The computer-readable recording medium according to claim 15, wherein when the unconditional flow control event occurs, a branch is made to a node representing a predetermined event. In a modeling system for modeling a discrete event system,
Encoding means for receiving a request and specification of the discrete event system defined by a user, and converting the request into a code readable by the modeling system;
Parsing means for extracting event and action data from the code converted by the encoding means, and storage means for storing the extracted event and action data;
Event node generating means for generating and storing a tree-type data structure including a start node and an end node,
The event data stored in the storage unit is searched to determine whether acceptable event data exists in the event data represented by the terminal node in the tree-type data structure. If the event node does not exist, the tree type data structure generation is terminated, and if there is allowable event data, the allowable event data is generated in a child node of the terminal node. And an event search means for activating the vessel. A flag generation unit that generates a flag depending on whether the event represented by the terminal node is an event in which a self-flow is permitted, an interrupt event, a return flow control event, or an unconditional flow control event. The modeling system according to claim 17, wherein: The interrupt event is
19. The modeling system according to claim 18, wherein, when the interrupt event occurs, a current node representing the event is pushed and stored on a stack. The return flow control event,
19. The modeling system according to claim 18, wherein when the return flow control event occurs, the node stored in the current stack is popped and branched to the node. The unconditional flow control event is
19. The modeling system according to claim 18, wherein when the unconditional flow control event occurs, a branch is made to a node representing a predetermined event. An event flow control system that executes an event flowchart modeled by the modeling system according to any one of claims 18 to 21,
Event matching means for determining whether the input event is an event allowable from the current node expressing the event,
If the event matching unit determines that the input event is an event acceptable from the current node, a condition check is performed to determine whether a condition for executing the input event is satisfied. Means,
If it is determined from the condition checking unit that the condition for executing the input event is satisfied, the action mapped to the input event on a one-to-one basis is performed, and the modeled Action performing means for driving the system;
If the input event is the return flow control event or the unconditional flow control event, a node updating means for updating a current node is provided. The node updating means,
23. The event flowchart execution system according to claim 22, wherein when the input event is the return flow control event, the node stored in the stack is updated to a current node. The node updating means,
23. The event flowchart execution system according to claim 22, wherein when the input event is the unconditional flow control event, a node defined by the unconditional flow control event is updated to a current node.

Images