JPWO2018083729A1 - ステートチャート実行装置 - Google Patents

Abstract

関連度計算部（１２）は、ステートチャートを構成するデータ間の関連度を計算する個別データバイナリ化部（１３）は、ステートチャートを構成するデータをバイナリ化する。最適配列計算部（１４）は、関連度計算部（１２）が計算した関連度に基づき、ステートチャートを構成するデータの配列を計算する。オフセット設定部（１５）は、個別データバイナリ化部（１３）がバイナリ化したデータを最適配列計算部（１４）が計算した配列で並べた場合の位置を示すオフセットを設定する。バイナリデータ統合部（１６）は、個別データバイナリ化部（１３）がバイナリ化しオフセット設定部（１５）がオフセットを設定したデータを、最適配列計算部（１４）が計算した配列で統合してバイナリデータ（１０４）にする。ステートチャート実行部（２０）は、バイナリデータ（１０４）に基づいてステートチャートの処理を実行する。

Description

この発明は、ステートチャートのデータを生成し実行するステートチャート実行装置に関するものである。

近年、タッチパネル、音声認識、または空間ジェスチャ認識などのユーザインタフェースデバイスが実用化されている。さらに、カーナビゲーションシステムに代表されるように、これらのユーザインタフェースデバイスを複数組み合わせたマルチモーダルアプリケーションが開発されている。従来、複数のユーザインタフェースデバイスを効率的に結合するマルチモーダルインタフェースの設計方式の１つとして、ステートチャート（または、ステートマシン）が広く活用されている。

例えば非特許文献１では、ステートチャートのＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）記述方式であるＳｔａｔｅ Ｃｈａｒｔ ＸＭＬ（ＳＣＸＭＬ）について記載されている。また、非特許文献２では、Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｇ Ｌａｎｇｕａｇｅ（ＵＭＬ）におけるステートチャートの作画ルールが記載されている。

また、従来、設計したステートチャートをプログラムとして効率的に実行する様々な方式が提案されている。例えば特許文献１には、テーブルで表現されたステートチャートを実行する方式について、および、ステートチャートを実行した結果に基づいて状態遷移の優先順位を決めることについて、記載されている。また、特許文献２では、連想配列を利用して動的にステートチャートを実行する方式が記載されている。

特開平１１−２４９０７号公報 米国特許出願公開第２０１３０１３８５９３号明細書

"Ｓｔａｔｅ Ｃｈａｒｔ ＸＭＬ（ＳＣＸＭＬ）：Ｓｔａｔｅ Ｍａｃｈｉｎｅ Ｎｏｔａｔｉｏｎ ｆｏｒ Ｃｏｎｔｒｏｌ Ａｂｓｔｒａｃｔｉｏｎ"，[Ｏｎｌｉｎｅ]，Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ，インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｃｘｍｌ／＞ "Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ（ＵＭＬ） Ｖｅｒｓｉｏｎ ２．５"，[Ｏｎｌｉｎｅ]，Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ，インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｍｇ．ｏｒｇ／ｓｐｅｃ／ＵＭＬ／２．５／＞

従来の方式において、階層構造を持ち、かつ膨大なステート数を持つステートチャートをコンピュータ上で実行するにあたり、ステートチャートのデータ構造が最適化されていないために実行速度が低下するという課題があった。

例えば、特許文献１では、テーブルで表現されたステートチャートを実行したときの状態毎の状態遷移履歴およびイベント毎のイベント成立履歴に基づき、ステートチャートの状態毎に、他の状態への遷移順序とイベントの成立順序とを決定する方式について記載されている。しかし、遷移順序および成立順序を利用して、データをコンピュータのメモリ上にどのように最適に配置するかについては記載されていない。また、テーブル型のステートチャートについて記載があるのみで、平行状態および階層状態を持つステートチャートにおいて遷移先の優先度を決めて最適に実行する方法について記載がない。

また、特許文献２では、ステート名の文字列からステートデータのメモリ上の位置を特定するために、ステートチャートのデータを動的なツリー（木）構造として保持することが記載されている。しかし、動的にツリーを構成した場合、ステート数が膨大になると、関連性のあるステートデータがメモリ上の離れた位置に配置されることでキャッシュヒット率が低下し、ステートチャートの実行処理が低速になる可能性がある。また、状態遷移の処理において２分木によるステートデータの探索処理が少なからず必要であるため、ステート数が増えると処理時間が長くなる。

この発明は、上記のような課題を解決するためになされたもので、ステートチャートを高速に実行することを目的とする。

この発明に係るステートチャート実行装置は、状態の遷移を表現したステートチャートに関するステートチャート情報をバイナリデータにするバイナリデータ生成部と、バイナリデータに基づいてステートチャートの処理を実行するステートチャート実行部とを備え、バイナリデータ生成部は、ステートチャート情報を読み込み、ステートチャートを構成するデータを生成するステートチャート情報読み込み部と、ステートチャートを構成するデータ間の関連度を計算する関連度計算部と、ステートチャートを構成するデータをバイナリ化する個別データバイナリ化部と、関連度計算部が計算した関連度に基づき、ステートチャートを構成するデータの配列を計算する最適配列計算部と、個別データバイナリ化部がバイナリ化したデータを最適配列計算部が計算した配列で並べた場合の位置を示すオフセットを設定するオフセット設定部と、個別データバイナリ化部がバイナリ化しオフセット設定部がオフセットを設定したデータを、最適配列計算部が計算した配列で統合してバイナリデータにするバイナリデータ統合部とを有するものである。

この発明によれば、ステートチャートを構成するデータ間の関連度に基づいてデータの配列を計算し、オフセットを設定したバイナリデータを生成することにより、このバイナリデータに基づいてステートチャートを高速に実行することができる。

この発明の実施の形態１に係るステートチャート実行装置の構成例を示すブロック図である。 この発明の実施の形態１に係るステートチャート実行装置の動作例を示すフローチャートである。 図３Ａは、この発明の実施の形態１におけるステートチャートの一例を示す図であり、図３Ｂは、図３Ａのステートチャートを記述したステートチャート情報を示す図である。 図３Ａに示すステートチャートから得られる関連度の表である。 この発明の実施の形態１におけるステートチャートの別の例を示す図である。 図５に示すステートチャートから得られる関連度の表である。 この発明の実施の形態１におけるステートチャートの別の例を示す図である。 図７に示すステートチャートから得られる関連度の表である。 この発明の実施の形態１におけるステートチャートの別の例を示す図である。 図９に示すステートチャートから得られる関連度の表である。 この発明の実施の形態１におけるステートチャートの修正頻度を示すグラフである。 この発明の実施の形態１に係るステートチャート実行装置の個別データバイナリ化部が行う動作を説明する図である。 図１３Ａ、図１３Ｂおよび図１３Ｃは、図３Ｂのステートチャート情報に含まれる個々の情報を示す図である。 この発明の実施の形態１に係るステートチャート実行装置の最適配列計算部が行う動作を説明する図である。 この発明の実施の形態１に係るステートチャート実行装置のオフセット設定部が行う動作の一例を説明する図である。 この発明の実施の形態１に係るステートチャート実行装置のオフセット設定部が行う動作の別の例を説明する図である。 この発明の実施の形態１におけるステートチャートの別の例を示す図である。 図１７のステートチャートに相当するバイナリデータを示す図である。 図１９Ａおよび図１９Ｂは、この発明の実施の形態１に係るステートチャート実行装置のハードウェア構成の例を示す図である。

以下、この発明をより詳細に説明するために、この発明を実施するための形態について、添付の図面に従って説明する。
実施の形態１．
図１は、この発明の実施の形態１に係るステートチャート実行装置１０１の構成例を示すブロック図である。ステートチャート実行装置１０１は、バイナリデータ生成部１０と、ステートチャート実行部２０とを備えている。バイナリデータ生成部１０は、ステートチャート情報読み込み部１１と、関連度計算部１２と、個別データバイナリ化部１３と、最適配列計算部１４と、オフセット設定部１５と、バイナリデータ統合部１６とを有している。ステートチャート実行部２０は、バイナリデータ読み込み部２１と、通信部２２と、状態遷移処理部２３とを有している。

ステートチャート実行装置１０１は、外部機器１０２に接続されている。外部機器１０２は、例えば、カーナビゲーションシステム等の車載機器であって、タッチパネル、音声認識、または空間ジェスチャ認識などのユーザインタフェースデバイスを有する。この外部機器１０２は、ユーザインタフェースデバイスを用いてユーザの指示を受け付け、イベント情報としてステートチャート実行装置１０１へ送信する。また、外部機器１０２は、ステートチャート実行装置１０１から命令を受信し、命令に従って動作する。

図２は、この発明の実施の形態１に係るステートチャート実行装置１０１の動作例を示すフローチャートである。ステップＳＴ１〜ＳＴ６の処理は、ステートチャート設計時に行う事前処理である。ステップＳＴ７〜ＳＴ９の処理は、設計したステートチャートを実行する処理である。
ステップＳＴ１において、ステートチャート情報読み込み部１１は、ステートチャート情報１０３を読み込み、ステートチャートを構成するデータを生成する。

ここで、ステートチャート情報１０３は、ステートチャートを構成するステートおよび状態遷移などの情報を含む。また、ステートチャート情報１０３は、ステートチャートを構成する各データの利用頻度、設計者が意図的に設定した状態遷移の優先度および設計履歴等、設計時の付加的な情報を含んでもよい。このステートチャート情報１０３は、設計者によって作成された、外部機器１０２に実行させるステートチャートのデータファイルである。
なお、実施の形態１において、ステートは状態と同義である。ステートチャートは、状態遷移図、ステートマシン図、および状態機械図と同義である。

図３Ａは、この発明の実施の形態１におけるステートチャートの一例を示す図であり、図３Ｂは、図３Ａのステートチャートに対応するステートチャート情報１０３を示す図である。図３Ｂに例示するステートチャート情報１０３は、ＳＣＸＭＬの形式で記述されたテキストファイルである。
以下では、ＳＣＸＭＬ形式で記述されたステートチャート情報１０３を例に用いて実施の形態１を説明するが、記述形式はこれに限らない。

ステートチャートを構成するデータとは、ステートチャート情報１０３に記述された、ステートチャートを構成する初期ステート、ステート、状態遷移、平行状態およびヒストリ等、各要素の情報のことと定義する。

例えばＳＣＸＭＬにおいて遷移データとは、＜ｔｒａｎｓｉｔｉｏｎ＞タグに記述された属性（アトリビュート）および子要素の情報を指すものと定義する。図３Ｂに示したＳＣＸＭＬの例では、以下の２つの遷移データが存在する。各遷移データには、子要素であるイベント名（ｅｖｅｎｔ）と、遷移先のステート名（ｔａｒｇｅｔ）が含まれる。
遷移データ１
・ｅｖｅｎｔ＝“ｅｖ１”
・ｔａｒｇｅｔ＝“ｓｔ２”
遷移データ２
・ｅｖｅｎｔ＝“ｅｖ２”
・ｔａｒｇｅｔ＝“ｓｔ１”

また、例えばＳＣＸＭＬにおいてステートデータとは、＜ｓｔａｔｅ＞タグに記述された属性（アトリビュート）および子要素の情報を指すものと定義する。図３Ｂに示したＳＣＸＭＬの例では、以下の２つのステートデータが存在する。各ステートデータには、子要素である遷移データが含まれる。
ステートデータ１
・ｉｄ＝“ｓｔ１”
・遷移データ１
ステートデータ２
・ｉｄ=“ｓｔ２”
・遷移データ２

ステップＳＴ２において、関連度計算部１２は、ステートチャート情報読み込み部１１が読み込んだステートチャート情報１０３に基づき、ステートチャートを構成するデータ間の関連度を計算する。
ここで、関連度について定義する。ステートチャート実行時に２つのデータが近い順番でアクセスされる可能性が高い場合、該当のデータ間の関連度は高いものとする。反対に、離れた順番でアクセスされる可能性が高い場合、該当のデータ間の関連度は低いものと定義する。

実施の形態１では、関連度計算方法（１）〜（５）を例示する。

関連度計算方法（１）：ルールに基づく関連度計算
関連度計算部１２は、以下のルール（１）〜（６）に基づいてステートチャートを構成するデータ間の関連度を計算する。
ルール（１）：遷移データと遷移先のステートデータとの関連度を１とする
ルール（２）：親子関係にあるデータは関連度を３とする
ルール（３）：平行状態（パラレルステート）にあるステートデータ間の関連度を２とする
ルール（４）：自己遷移するステートデータと遷移データとの関連度を４とする
ルール（５）：ルール（１）〜（４）に該当しないデータ間の関連度を０とする
ルール（６）：初期ステートと、初期ステートの遷移先のデータとの関連度を１とする
上記ルールにおける関連度は、０〜４の整数値であるが、これに限らず、ユーザが適宜設定した実数値でよい。

上記ルールに基づく関連度計算により、図３Ａに示すステートチャートから、図４に示す関連度の表が得られる。ここで、図３Ａおよび図４を用いて、ルールに基づく関連度計算の具体例について述べる。
・ステートデータ１（ｓｔ１）は、子要素に遷移データ１（ｅｖ１）を持つため、ルール（２）が適用され、関連度が３となる。
・ステートデータ１（ｓｔ１）とステートデータ２（ｓｔ２）とは直接関連がないため、ルール（５）が適用され、関連度が０となる。
・初期ステートデータ（ｉｎｉｔｉａｌ）は、ステートデータ１（ｓｔ１）に遷移するため、ルール（６）が適用され、関連度が１となる。

ステートチャートの別の例を示す。図５は、この発明の実施の形態１におけるステートチャートの別の例を示す図である。図６は、図５に示すステートチャートから得られる関連度の表である。
上記ルールに基づく関連度計算により、図５に示すステートチャートから、図６に示す関連度の表が得られる。ここで、図５および図６を用いて、ルールに基づく関連度計算の具体例について述べる。
以下では、説明のために、ステート名ｓｔを持つステートデータを「ステートデータｓｔ」、イベント名ｅｖを持つ遷移データを「遷移データｅｖ」などと呼ぶ。

・遷移データｅｖ２と遷移データｅｖ３の遷移先にはステートデータｓｔ２１が設定されている。このため、ルール（１）が適用され、遷移データｅｖ２とステートデータｓｔ２１との関連度は１、遷移データｅｖ３とステートデータｓｔ２１との関連度も１となる。
・ステートデータｓｔ１は、子要素に遷移データｅｖ１を持つため、ルール（２）が適用され、関連度が３となる。
・平行状態データｐａ１は、子要素にステートデータｓｔ３とステートデータｓｔ４を持つ。このため、ルール（２）が適用され、平行状態データｐａ１とステートデータｓｔ３との関連度は３、平行状態データｐａ１とステートデータｓｔ４との関連度も３となる。
・平行状態データｐａ１において、ステートデータｓｔ３とステートデータｓｔ４は平行に実行される。このため、ルール（３）が適用され、ステートデータｓｔ３とステートデータｓｔ４との関連度は２となる。
・ステートデータｓｔ２は、子要素にステートデータｓｔ２１とステートデータｓｔ２２を持つ。このため、ルール（２）が適用され、ステートデータｓｔ２とステートデータｓｔ２１との関連度は３、ステートデータｓｔ２とステートデータｓｔ２２との関連度も３となる。
・遷移データｅｖ５は、ステートデータｓｔ１に自己遷移しているため、ルール（４）が適用され、関連度は４となる。

関連度計算方法（２）：利用頻度に基づく関連度計算
関連度計算部１２は、各遷移状態に関わる利用頻度の情報を利用して、データ間の関連度を計算してもよい。
図７は、この発明の実施の形態１におけるステートチャートの別の例を示す図である。図８は、図７に示すステートチャートから得られる関連度の表である。図７および図８を用いて、利用頻度に基づく関連度計算の具体例について述べる。

例えば、カーナビゲーションシステムなどの車載機器の音声対話をステートチャートで設計し、ユーザの問い合わせを以下の３種類に分類設計したとする。
分類（１）：簡単で短いユーザの命令、またはカーナビゲーションシステムが「はい（Ｙｅｓ）」か「いいえ（Ｎｏ）」で回答できる質問
質問例：「カーナビ起動して」、「ナビ終了」、「ここ右折かな？」、「近くに道の駅がある？」
分類（２）：カーナビゲーションシステムが複雑で長い回答を返すと想定される質問
質問例：「おすすめのレストランは？いまラーメンかカレーが食べたいな」
分類（３）：エラー処理
例：音声認識デバイスが起動しない等、稀に発生するエラー時の処理

上記分類（１）〜（３）を元に、例えば、図７のステートチャートにおける音声対話の処理フローを以下のように表現する。
・ステートデータｓｔ１は、カーナビゲーションシステムがユーザの問い合わせを受け付け、質問を分類する状態
・遷移データｅｖ１は、分類（１）が発生した場合の遷移
・遷移データｅｖ２は、分類（２）が発生した場合の遷移
・遷移データｅｖ３は、分類（３）が発生した場合の遷移
・ステートデータｓｔ２は、カーナビゲーションシステムが分類（１）の回答処理をする状態
・ステートデータｓｔ３は、カーナビゲーションシステムが分類（２）の回答処理をする状態
・ステートデータｓｔ４は、カーナビゲーションシステムが分類（３）の回答処理をする状態

ここで、分類（１）は頻繁に利用され、分類（２）は中程度に利用され、分類（３）は滅多に発生しない、という情報が事前に得られているものとする。この利用頻度に関する情報は、ユーザが手動で設定してもよいし、関連度計算部１２が大量の対話データの傾向から求めてもよい。

関連度計算部１２は、利用頻度に関する情報に基づいて、以下のようにデータ間の関連度を決定する。
・ステートデータｓｔ１から遷移データｅｖ１を経由する確率が最も高いため、ステートデータｓｔ１と遷移データｅｖ１との関連度を１５とする。
・ステートデータｓｔ１から遷移データｅｖ２を経由する確率が２番目に高いため、ステートデータｓｔ１と遷移データｅｖ２との関連度を１０とする。
・ステートデータｓｔ１から遷移データｅｖ３を経由する確率が最も低いため、ステートデータｓｔ１と遷移データｅｖ３との関連度を１とする。

関連度計算部１２は、上記以外のデータの関連度に関しては、前記ルールに基づいて計算し、図８に示す関連度の表を得る。なお、利用頻度に基づく関連度１５、１０、１の値は、これに限らず、例えばユーザが手動で設定してもよいし、関連度計算部１２が大量の対話データを用いたシミュレーションなどにより状態遷移確率を求めて、その状態遷移確率に比例するように関連度の値を決定してもよい。

関連度計算方法（３）：誘導度合いに基づく関連度計算
カーナビゲーションシステムなどの車載機器が、ユーザに対して機器の使い方または道順などを教示する際に、ユーザの動作を誘導したい場合がある。その場合、誘導したい度合（以下、「誘導度合い」と称す）の高い状態遷移に関わるデータ間の関連度を相対的に高めてもよい。

例えば、カーナビゲーションシステムがユーザとの音声対話にて近くのレストランを検索し、燃費コストに基づき以下の３種類の検索結果が得られ、３種類の検索結果を選択肢としてユーザに提示する場合を考える。
選択肢（１）レストランＡ：現在地からの移動に伴う燃費コスト１
選択肢（２）レストランＢ：現在地からの移動に伴う燃費コスト５
選択肢（３）レストランＣ：現在地からの移動に伴う燃費コスト１０

上記選択肢（１）〜（３）を元に、例えば、前記関連度計算方法（２）で用いた図７のステートチャートに適用した場合における音声対話の処理フローを、以下のように設計する。
・ステートデータｓｔ１は、選択肢（１）〜（３）をユーザに提示した状態。ただし、カーナビゲーションシステムは、燃費コストが１番低い選択肢（１）をユーザに優先的に勧める。すなわち、選択肢（１）が最も誘導度合いが高い。カーナビゲーションシステムは、例えば、選択肢（１）の表示文字を他の選択肢の表示文字より大きくしたり、選択肢（１）をリストの１番上位に表示したり、音声ガイダンスで選択肢（１）を勧めたりする
・遷移データｅｖ１は、ユーザにより選択肢（１）が選択された場合の遷移
・遷移データｅｖ２は、ユーザにより選択肢（２）が選択された場合の遷移
・遷移データｅｖ３は、ユーザにより選択肢（３）が選択された場合の遷移
・ステートデータｓｔ２は、選択肢（１）が選択された後のカーナビゲーションシステムの処理
・ステートデータｓｔ３は、選択肢（２）が選択された後のカーナビゲーションシステムの処理
・ステートデータｓｔ４は、選択肢（３）が選択された後のカーナビゲーションシステムの処理

関連度計算部１２は、誘導度合いに基づいて、以下のようにデータ間の関連度を決定する。
・選択肢（１）の誘導度合いが高いため、ステートデータｓｔ１から遷移データｅｖ１を経由する確率が最も高いと判断する。このため、ステートデータｓｔ１と遷移データｅｖ１との関連度を１５とする。
・ステートデータｓｔ１から遷移データｅｖ２を経由する確率と、ステートデータｓｔ１から遷移データｅｖ３を経由する確率とは同程度に低い。このため、ステートデータｓｔ１と遷移データｅｖ２との関連度は１、ステートデータｓｔ１と遷移データｅｖ３との関連度も１とする。

関連度計算方法（４）：ステートチャートの修正日時に基づく関連度計算
関連度計算部１２は、設計時におけるステートチャートの修正日時に基づき、データ間の関連度を計算してもよい。例えば、設計の採取段階において、最も新しく修正されたデータは、重要な処理フローと考えられるため、その他のデータと比較して関連度を高くする。
図９は、この発明の実施の形態１におけるステートチャートの別の例を示す図である。図１０は、図９に示すステートチャートから得られる関連度の表である。図９および図１０を用いて、修正日時に基づく関連度計算の具体例について述べる。
図９に示すステートチャートは、図３Ａに示したステートチャートに対して遷移データｅｖ３が追加されたものである。関連度計算部１２は、追加された遷移データｅｖ３を重要な処理とみなして、ステートデータｓｔ１と遷移データｅｖ３との関連度を、他のデータ間の関連度よりも相対的に高い値である１０に設定し、図１０の関連度表を得る。なお、図１０において初期ステートデータ（ｉｎｉｔｉａｌ）の関連度の図示は省略する。

関連度計算方法（５）：ステートチャートの修正頻度に基づく関連度計算
関連度計算部１２は、設計時におけるステートチャートの修正頻度に基づき、データ間の関連度を計算してもよい。
図１１は、この発明の実施の形態１におけるステートチャートの修正頻度を示すグラフである。関連度計算部１２は、ステートチャートの設計時、当該ステートチャートを構成するデータＡ〜Ｆそれぞれの修正頻度を求め、低頻度に修正されたデータ群と、高頻度に修正されたデータ群と、残りのデータ群とに分類する。高頻度に修正されたデータ群は設計上重要な処理フローである可能性が高いため、関連度計算部１２は、高頻度に修正されたデータ群の関連度を残りのデータ群の関連度より高くする。また、低頻度に修正されたデータ群は修正が不要な基本的な処理フローである可能性が高いため、関連度計算部１２は、低頻度に修正されたデータ群の関連度を残りのデータ群の関連度より高くする。
図１１の例であれば、低頻度に修正されたデータＡとデータＢとの関連度に「１」が加算される。同様に、高頻度に修正されたデータＥとデータＦとの関連度に「１」が加算される。データＡとデータＣとの関連度、およびデータＡとデータＥとの関連度等、その他のデータ間の関連度はそのままである。この例では関連度に加算する値を「１」としたが、値はこれに限られない。また、低頻度に修正されたデータ群の関連度に加算する値と、高頻度に修正されたデータ群の関連度に加算する値とは、同じ値であってもよいし、異なる値であってもよい。

関連度計算部１２は、関連度計算方法（１）〜（５）のうちのいずれか１つを用いて関連度を計算してもよいし、２つ以上の方法を組み合わせて関連度を計算してもよい。

ステップＳＴ３において、個別データバイナリ化部１３は、ステートチャート情報読み込み部１１が生成した個々のデータをバイナリ化する。また、個別データバイナリ化部１３は、バイナリ化した各データのサイズを求める。
ここでは、ステートチャート情報１０３が、図３Ｂに示すＳＣＸＭＬ形式で記述されている場合を考える。

図１２は、この発明の実施の形態１に係るステートチャート実行装置１０１の個別データバイナリ化部１３が行う動作を説明する図である。図１３Ａ、図１３Ｂおよび図１３Ｃは、図３Ｂのステートチャート情報１０３に含まれる個々の情報を示す図である。

ステートチャート情報１０３のうちの図１３Ａに示す部分に、初期ステートデータｓｔ１の情報が記述されている。個別データバイナリ化部１３は、この初期ステートデータｓｔ１の情報を元に、下記（１）のようなバイナリ化したヘッダデータを作成する。
（１）ｉｄ=“ｓｔ１”を持つステートデータへのオフセット
オフセットとは、後のステップＳＴ６にて作成するバイナリデータ１０４における該当データの開始位置である。ここでは、オフセットは整数値であり、そのデータサイズを４バイトと仮定した。このため、バイナリ化したヘッダデータのデータサイズは、４バイトである。
上記（１）のオフセットには後のステップＳＴ５で値を代入することになるため、ステップＳＴ３では個別データバイナリ化部１３は疑似的に整数値の０を代入する。

ステートチャート情報１０３のうちの図１３Ｂに示す部分に、遷移データ１の情報が記述されている。個別データバイナリ化部１３は、この遷移データ１の情報をバイナリ化して、下記（１）および（２）のデータを生成する。
（１）ｅｖｅｎｔの“ｅｖ１”を表す文字列
（２）ｔａｒｇｅｔの文字列の代替として、ｉｄ＝“ｓｔ２”を持つステートデータへのオフセット
ここで、１文字のデータサイズを２バイトと仮定したため、上記（１）の“ｅｖ１”を表す文字列のデータサイズは６バイトである。上記（２）のオフセットは４バイトの整数値である。このため、バイナリ化した遷移データ１のデータサイズの合計は、１０バイトである。
また、上記（２）のオフセットには後のステップＳＴ５で値を代入することになるため、ステップＳＴ３では個別データバイナリ化部１３は疑似的に整数値の０を代入する。

ステートチャート情報１０３のうちの図１３Ｃに示す部分に、ステートデータ１の情報が記述されている。個別データバイナリ化部１３は、このステートデータ１の情報をバイナリ化して、下記（１）および（２）のデータを生成する。
（１）ｉｄの“ｓｔ１”を表す文字列
（２）遷移データ１へのオフセット
ステートデータ１も遷移データ１と同様、１文字のデータサイズを２バイトと仮定したため、上記（１）の“ｓｔ１”を表す文字列のデータサイズは６バイトである。上記（２）のオフセットは４バイトの整数値である。このため、バイナリ化したステートデータ１のデータサイズの合計は、１０バイトである。
また、上記（２）のオフセットには後のステップＳＴ５で値を代入することになるため、ステップＳＴ３では個別データバイナリ化部１３は疑似的に整数値の０を代入する

個別データバイナリ化部１３は、ステートチャート情報１０３に含まれている遷移データ２およびステートデータ２の情報も、上記同様にバイナリ化する。

ここでは、ステート情報（＜ｓｔａｔｅ＞）の子要素に遷移情報（＜ｔｒａｎｓｉｔｉｏｎ＞）が含まれている場合について述べたが、これに限らず、ステート情報としてその他の情報が含まれていてもよい。例えば、ＳＣＸＭＬの場合、＜ｓｔａｔｅ＞タグの子要素である＜ｏｎｅｎｔｒｙ＞および＜ｏｎｅｘｉｔ＞が定義されており、個別データバイナリ化部１３はそれらを適宜バイナリ化してもよい。同様にＳＣＸＭＬにて＜ｔｒａｎｓｉｔｉｏｎ＞タグの子要素である＜ｓｃｒｉｐｔ＞タグなどを適宜バイナリ化してもよい。

ステップＳＴ４において、最適配列計算部１４は、関連度計算部１２が計算したデータ間の関連度に基づき、関連度が高いデータ同士が可能な限り近くに配置されるような各データの一次元配列、つまり最適な順列を計算する。

実施の形態１では、最適配列計算方法（１）〜（３）を例示する。

最適配列計算方法（１）：隣接するデータの関連度の利用
最適配列計算部１４は、ステートチャートを構成する各データを一次元配列に並べた際の、隣接するデータ間の関連度を総計した総合関連度を計算し、総合関連度が最大となるデータの順列を求める。
図１４は、この発明の実施の形態１に係るステートチャート実行装置１０１の最適配列計算部１４が行う動作を説明する図である。最適配列計算部１４は、図４の関連度表を利用して、図１４に示す順列Ａ，Ｂの総合関連度を計算する。

順列Ａに従って各データを一次元配列に並べた場合は、総合関連度が１となる。
総合関連度
＝（ヘッダデータと遷移データ１との関連度）
＋（遷移データ１と遷移データ２との関連度）
＋（遷移データ２とステートデータ１との関連度）
＋（ステートデータ１とステートデータ２との関連度）
＝０＋０＋１＋０
＝１

順列Ｂに従って各データを一次元配列に並べた場合は、総合関連度が８となる。
総合関連度
＝（ヘッダデータとステートデータ１との関連度）
＋（ステートデータ１と遷移データ１との関連度）
＋（遷移データ１とステートデータ２との関連度）
＋（ステートデータ２と遷移データ２との関連度）
＝１＋３＋１＋３
＝８

最適配列計算部１４は、総合関連度が大きい順列Ｂを選択する。説明を省略するが、最適配列計算部１４は、同様に考えうる可能な順列をすべて列挙、または確率的サンプリングで順列候補を列挙し、それらの総合関連度を計算し、総合関連度が最大となる順列を選択する。
総合関連度の計算式は、最適なデータの順列を求めるための評価関数である。

なお、図１４の例では、対象とするデータに隣接する１個のデータの関連度を加算して総合関連度を求めたが、対象とするデータに隣接するＮ個（Ｎ≧１）のデータの関連度を加算して総合関連度を求めてもよい。例えば、隣接する２個のデータの関連度を考慮する場合、最適配列計算部１４は、図１４の順列Ｂにおいて、対象とするヘッダデータに対しては、ステートデータ１と遷移データ１の関連度を加算する。結果として、Ｎ＝２の場合の順列Ｂの総合関連度は８となる。
Ｎ＝２の場合の順列Ｂの総合関連度
＝（ヘッダデータとステートデータ１との関連度）
＋（ヘッドデータと遷移データ１との関連度）
＋（ステートデータ１と遷移データ１との関連度）
＋（ステートデータ１とステートデータ２との関連度）
＋（遷移データ１とステートデータ２との関連度）
＋（遷移データ１と遷移データ２との関連度）
＋（ステートデータ２と遷移データ２との関連度）
＝１＋０＋３＋０＋１＋０＋３
＝８

これにより、一次元に並べた各データをメモリ上に展開した際に、関連するデータが近くに並ぶため、ステートチャート実行時のキャッシュヒット率が向上し、状態遷移処理を高速化できる。また、隣接するＮ個の関連度しか考慮しないため、総合関連度の計算において計算量を抑えることができる。

最適配列計算方法（２）：データ間の距離と関連度の利用
最適配列計算部１４は、データ間の距離が遠くなるほど関連度が減少するような評価関数を設定し、その評価関数が最大となるようなデータの順列を求めてもよい。

評価関数の例を以下に示す。
変数の定義
Ｍ：データ数
Ｅ：ステートチャートを構成するデータの順列の集合。要素数はＭ！
ｓ（ｉ）：ステートチャートを構成するｉ番目のデータ
ｓ（ｊ）：ステートチャートを構成するｊ番目のデータ
ｒ（ｉ，ｊ）：ｓ（ｊ）とｓ（ｉ）との関連度
ｄ（ｅ，ｉ，ｊ）：順列ｅ∈Ｅに従ってデータを一次元に配列した場合の、ｓ（ｊ）とｓ（ｉ）との距離。すなわち、ｓ（ｊ）とｓ（ｉ）とのオフセット（データ開始位置）の差分の絶対値。

これにより、一次元に並べた各データをメモリ上に展開した際に、関連するデータが可能な限り近くに並ぶため、ステートチャート実行時のキャッシュヒット率が向上し、状態遷移処理を高速化できる。また、すべてのデータ間の関連度を考慮するため、最適配列計算方法（１）と比較して、より最適なデータの順列を求めることができると期待される。

最適配列計算方法（３）：データ間の距離、関連度および閾値の利用
最適配列計算部１４は、あらかじめ定められた距離以上離れてしまうデータ間の関連度を総計してコスト関数とし、コスト関数が最小となるようなデータの順列を求めてもよい。ここで、上記のあらかじめ定められた距離を、閾値Ｂ１と定義する。閾値Ｂ１には、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が持つキャッシュメモリのブロックサイズまたはラインサイズが設定される。これにより、キャッシュヒットミスが低減されるようなデータの順列を求めることができる。

コスト関数の例を以下に示す。
変数の定義
Ｅ：ステートチャートを構成するデータの順列の集合
Ｂ１：上述した閾値
ｓ（ｉ）：ステートチャートを構成するｉ番目のデータ
ｓ（ｊ）：ステートチャートを構成するｊ番目のデータ
ｒ（ｉ，ｊ）：ｓ（ｊ）とｓ（ｉ）との関連度
ｄ（ｅ，ｉ，ｊ）：順列ｅ∈Ｅに従ってデータを一次元に配列した場合の、ｓ（ｊ）とｓ（ｉ）との距離
Ｘ１（ｅ）：ｄ（ｅ，ｉ，ｊ）＞Ｂ１を満たすｉ，ｊの組

このとき、最適配列計算部１４は、下式（３）のようにコスト関数を定義する。

または、大小異なるブロックサイズのキャッシュメモリを持つＣＰＵを利用する場合、最適配列計算部１４は、閾値Ｂ２として大きめのブロックサイズまたはラインサイズを設定し、下式（４）のようにコスト関数を定義してもよい。

Ｂ２：Ｂ１＜Ｂ２を満たす閾値（キャッシュメモリのブロックサイズ等）
Ｘ２（ｅ）：ｄ（ｅ，ｉ，ｊ）＞Ｂ２を満たすｉ，ｊの組
α，β：適切な重み係数

これにより、一次元に並べた各データをメモリ上に展開した際に、キャッシュメモリのブロックサイズまたはラインサイズに収まらないデータのペアを可能な限り少なくすることができる。これによって、ステートチャート実行時のキャッシュヒットミスが低減し、状態遷移処理を高速化できる。

なお、評価関数を最大化する、またはコスト関数を最小化する場合に、データ数が増えると計算量が増大し、順列の最適解を現実的な時間内に求めることは困難となる。そこで、評価関数を最大化する、またはコスト関数を最小化する準最適解を求めてもよい。
最適配列計算部１４は、準最適解を求める方法として、遺伝アルゴリズムなどの確率的最適化手法を利用できる。最適配列計算部１４は、例えば、ステートチャートを構成するデータの順列を、下記文献の３４ページに記載された順序表現（Ｏｒｄｉｎａｌ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）で表現し、最適配列計算方法（１）もしくは（２）で示した評価関数を最大化するような順列、または最適配列計算方法（３）で示したコスト関数を最小化するような順列を、遺伝アルゴリズムにより求める。
伊庭 斉志、「遺伝的アルゴリズムの基礎―ＧＡの謎を解く―」、第１版、オーム社、１９９４、ｐ．３４

ステップＳＴ５において、オフセット設定部１５は、最適配列計算部１４が計算した順列に従ってバイナリ化した各データを一次元に配列した場合の、各データのオフセットを求め、オフセットを各データに設定する。オフセットは、バイナリデータ１０４におけるデータの開始位置である。

図１５は、この発明の実施の形態１に係るステートチャート実行装置１０１のオフセット設定部１５が行う動作の一例を説明する図である。ここでは、最適配列計算部１４が、図１４の順列Ｂを選択して、オフセット設定部１５に出力したものとする。
オフセット設定部１５は、順列Ｂの順番に従って、ステートデータを構成するデータを並べる。結果、図１５の通り、ヘッダデータ、ステートデータ１、遷移データ１、ステートデータ２、遷移データ２の順番でデータが配置される。

ヘッダデータのデータサイズは４バイト、ステートデータ１のデータサイズは１０バイト、遷移データ１のデータサイズは１０バイト、ステートデータ２のデータサイズは１０バイト、および遷移データ２のデータサイズは１０バイトである。このことから、オフセット設定部１５は、ヘッダデータのオフセットを０バイト目、ステートデータ１のオフセットを５バイト目、遷移データ１のオフセットを１５バイト目、ステートデータ２のオフセットを２５バイト目、および遷移データ２のオフセットを３５バイト目と計算する。

続いてオフセット設定部１５は、ステップＳＴ３で０に仮設定されていた各オフセットを、計算した正しい値に設定しなおす。オフセット設定部１５は、例えば、初期ステートデータのオフセットには、ステートデータ１のオフセットである５を設定する。また、オフセット設定部１５は、ステートデータ１が持つ「遷移データ１のオフセット」には１５を設定する。また、オフセット設定部１５は、遷移データ１が持つ「ステートデータ２のオフセット」には２５を設定する。オフセット設定部１５は同様に、ステートデータ２および遷移データ２が持つ各オフセットにも値を設定する。

図１５では、オフセット設定部１５がオフセットを利用してステートチャート情報１０３をバイナリ化する方法について述べたが、例えば、ステートデータが変更されてそのデータサイズが増えた場合、すべてのデータに設定されたオフセットの再計算が必要になるという問題がある。
そこで、以下では、オフセット設定部１５がオフセットアレイデータとオフセットアレイデータのインデックスとを用いて、効率的にデータをバイナリ化する方法について述べる。

図１６は、この発明の実施の形態１に係るステートチャート実行装置１０１のオフセット設定部１５が行う動作の別の例を説明する図である。ここでは、最適配列計算部１４が、図１４の順列Ｂを選択して、オフセット設定部１５に出力したものとする。
オフセット設定部１５は、オフセットアレイデータを追加で用意し、ヘッダデータ、オフセットアレイデータ、ステートデータ１、遷移データ１、ステートデータ２、遷移データ２の順番に配置する。

オフセットアレイデータには、ステートデータ１のオフセットに相当するインデックス０、遷移データ１のオフセットに相当するインデックス１、ステートデータ２のオフセットに相当するインデックス２、遷移データ２のオフセットに相当するインデックス３を定義する。１つのオフセットは４バイトの整数値であるため、オフセットアレイデータのデータサイズは４バイト×４＝１６バイトである。そして、オフセット設定部１５は、以下のようにインデックス０〜３にオフセット値を設定する。
インデックス０：２１（ステートデータ１のオフセット）
インデックス１：３１（遷移データ１のオフセット）
インデックス２：４１（ステートデータ２のオフセット）
インデックス３：５１（遷移データ２のオフセット）

続いてオフセット設定部１５は、ステートデータ１、遷移データ１、ステートデータ２、および遷移データ２において、オフセット値の代替として、オフセットアレイデータのインデックスを指定する。
例えば、図１５において、ステートデータ１には「遷移データ１のオフセット」（オフセット値１５）が設定されていたが、その代替として、図１６ではオフセットアレイデータのインデックス１を設定する。オフセットアレイデータにおいて、インデックス１は、遷移データ１のオフセットである３１が設定されているためである。

以上のように、オフセットアレイデータを利用すれば、データサイズが変更になった場合でも、オフセットアレイデータを変更するのみで済む。例えば、ステートデータ１の文字列が“ｓｔ１”から“ｓｔ１＿ｎｅｗ”に変更されて文字数が増えた場合、１文字が２バイトとすると、ステートデータ１のデータサイズは８バイト増える。そのため、オフセット設定部１５は、オフセットアレイデータにおいて、遷移データ１、ステートデータ１および遷移データ２のオフセットをそれぞれ８バイト増やし、オフセットアレイデータを以下のように変更する。
インデックス０：２１（ステートデータ１のオフセット）
インデックス１：３９（遷移データ１のオフセット）
インデックス２：４９（ステートデータ２のオフセット）
インデックス３：５９（遷移データ２のオフセット）

これにより、オフセットが正しいデータの位置を指し示すことになる。この際に、データの順列は変更していないため、各データに設定されたインデックスは変更する必要がない。従って、各データの中身を書き換える必要が無い。

ステップＳＴ６において、バイナリデータ統合部１６は、個別データバイナリ化部１３がバイナリ化し、オフセット設定部１５がオフセットまたはオフセットアレイデータを設定したデータを、最適配列計算部１４が計算した配列で統合してバイナリデータ１０４にし、バイナリデータ１０４を保存する。バイナリデータ統合部１６は、バイナリデータ１０４を、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメモリに保存してもよいし、ファイル等の形式でディスクに保存してもよい。

次に、ステートチャート実行部２０の動作について述べる。

ステップＳＴ７において、バイナリデータ読み込み部２１は、保存されたバイナリデータ１０４を読み込む。例えば、バイナリデータ１０４がバイナリファイルとして保存されている場合、バイナリデータ読み込み部２１は、まずバイナリデータサイズ分のメモリを確保し、確保したメモリ上にステートチャートを構成するすべてのデータを格納する。

ステップＳＴ８において、通信部２２は、外部機器１０２と通信し、外部機器１０２からイベント情報を受信する。イベント情報とは、イベントの名前を示す文字列と、イベントに付随する任意のデータのことを指す。
図１７は、この発明の実施の形態１におけるステートチャートの別の例を示す図である。このステートチャートでは、通信部２２は、“ｅｖ１”のイベント文字列、または“ｅｖ２”のイベント文字列と付随データｖａｌｕｅ１＝＝１０とを受信する。

ステップＳＴ９において、状態遷移処理部２３は、通信部２２が受信したイベント文字列と付随データ、およびステップＳＴ７でバイナリデータ読み込み部２１が読み込んだバイナリデータ１０４に従って、状態遷移処理を実行する。

ここで、図１７および図１８を用いて、ステップＳＴ７〜ＳＴ９の処理の例について述べる。図１７は、イベントｅｖ２の遷移データ２において、ガード条件“ｖａｌｕｅ１＝＝１０”と、アクションＡｃｔｉｏｎ１（）とを含むステートチャートを示す。図１８は、図１７のステートチャートに相当するバイナリデータ１０４を示す図である。遷移データ２は、イベント名とステートデータ１へのオフセットとに加え、ガード条件文字列“ｖａｌｕｅ１＝＝１０”とアクション文字列“Ａｃｔｉｏｎ１（）”とを持つ。

１．初期遷移（ステップＳＴ７）
バイナリデータ読み込み部２１は、初めに、バイナリデータ１０４のヘッダデータを読み込み、ヘッダデータに記述された初期ステートデータにアクセスする。図１８の例では、初期ステートデータのオフセットに５が設定されている。このため、バイナリデータ読み込み部２１は、バイナリデータ１０４の５バイト目にアクセスし、ステートデータ１を読み込む。これにより、ステートチャートの初期状態はｓｔ１となる。

２．イベント“ｅｖ１”を受信（ステップＳＴ８）
次に、通信部２２は、外部機器１０２からイベント情報を受信する。ここでは例えば、イベント文字列“ｅｖ１”を受信したものとする。

３．状態遷移（ステップＳＴ９）
次に、状態遷移処理部２３は、ステートデータ１が持つ遷移データ１のオフセットを参照し、１５バイト目の遷移データ１を読み込む。この遷移データ１には、イベント名“ｅｖ１”があり、先に受信したイベント文字列“ｅｖ１”と同一であることから、状態遷移処理部２３は、遷移先のステートデータ２に遷移する。具体的には、遷移先のステートデータ２のオフセットとして設定されている２５バイト目のデータにアクセスする。これにより、ステートデータ２に記述されたステート“ｓｔ２”に遷移する。
遷移先のデータのオフセットが２５バイトと設定されていることにより、状態遷移処理部２３が状態遷移する際に、探索処理を必要とせず、次の遷移情報にアクセスすることができる。
一方、遷移データ１のイベント名と受信したイベント文字列とが一致しない場合、状態遷移処理部２３はステート“ｓｔ１”に留まる。

４．イベント“ｅｖ２”と付随するデータを受信（ステップＳＴ８）
次に、通信部２２は、外部機器１０２からイベント文字列“ｅｖ２”と、それに付随するデータｖａｌｕｅ１＝＝１０とを受信する。

５．状態遷移（ステップＳＴ９）
次に、状態遷移処理部２３は、遷移データ２にアクセスし、遷移データ２が持つイベント名“ｅｖ２”と受信したイベント文字列“ｅｖ２”とが一致するか判定する。ここでは、遷移データ２が持つイベント名と受信したイベント文字列とが一致することから、状態遷移処理部２３は、次のガード条件判定に進む。一致しない場合、状態遷移処理部２３はステート“ｓｔ２”に留まる。

６．ガード条件判定とアクション実行（ステップＳＴ９）
次に、状態遷移処理部２３は、遷移データ２に記載されたガード条件文字列と外部機器１０２から受信した付随データのガード条件文字列とを比較し、ガード条件文字列の真偽を判定する。状態遷移処理部２３は、ガード条件文字列が真である場合、アクションデータに記載されたアクションを実行し、次の状態に遷移する。ここでは、受信した付随データがｖａｌｕｅ１＝＝１０であることから、図１８に記載されたガード条件文字列は真である。そこで、状態遷移処理部２３は、アクション文字列“Ａｃｔｉｏｎ１（）”を取得し、Ａｃｔｉｏｎ１（）を実行する。Ａｃｔｉｏｎ１（）は、外部機器１０２に登録された関数などであり、例えばステートチャート実行部２０が通信部２２を介して特定の外部機器１０２へイベント情報を送信するなどの命令が記述されている。最後に、状態遷移処理部２３は、ステートデータ１のオフセットに設定された５バイト目のデータにアクセスし、次のステート“ｓｔ１”に遷移する。
一方、ガード条件文字列が偽である場合、状態遷移処理部２３はステート“ｓｔ２”に留まる。

このように、ステートチャート実行部２０は、ステップＳＴ８のイベント文字列受信と、ステップＳＴ９の状態遷移処理とを繰り返す。

次に、ステートチャート実行装置１０１のハードウェア構成例を説明する。
図１９Ａおよび図１９Ｂは、この発明の実施の形態１に係るステートチャート実行装置１０１のハードウェア構成の一例を示す図である。
ステートチャート実行装置１０１におけるバイナリデータ生成部１０およびステートチャート実行部２０の各機能は、処理回路により実現される。すなわち、ステートチャート実行装置１０１は、状態の遷移を表現したステートチャートに関するステートチャート情報１０３をバイナリデータ１０４にし、このバイナリデータ１０４に基づいてステートチャートの処理を実行するための処理回路を備える。処理回路は、図１９Ａに示すように専用のハードウェアであってもよいし、図１９Ｂに示すようにメモリ１００６に格納されているプログラムを実行するＣＰＵ１００５であってもよい。

図１９Ａに示すように、処理回路が専用のハードウェアである場合、処理回路１００１は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、またはこれらを組み合わせたものが該当する。
バイナリデータ生成部１０およびステートチャート実行部２０の機能をまとめて１つの処理回路１００１で実現してもよいし、複数の処理回路１００１で実現してもよい。

図１９Ｂに示すように、処理回路がＣＰＵ１００５である場合、バイナリデータ生成部１０およびステートチャート実行部２０の機能は、ソフトウェア、ファームウェア、またはソフトウェアとファームウェアとの組み合わせにより実現される。ソフトウェアまたはファームウェアはプログラムとして記述され、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１００２またはメモリ１００６に格納される。ＣＰＵ１００５は、ＨＤＤ１００２またはメモリ１００６に格納されたプログラムを読み出して実行することにより、各部の機能を実行する。すなわち、ステートチャート実行装置１０１は、ＣＰＵ１００５により実行されるときに、図２に示したステップが結果的に実行されることになるプログラムを格納するためのＨＤＤ１００２またはメモリ１００６を備える。また、このプログラムは、バイナリデータ生成部１０およびステートチャート実行部２０の手順または方法をコンピュータに実行させるものであるともいえる。

ここで、ＣＰＵ１００５は、例えば、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、またはシステムＬＳＩ（Ｌａｒｇｅ−Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等であってもよい。
また、ＣＰＵ１００５は、１次キャッシュメモリおよび２次キャッシュメモリ等の複数のキャッシュメモリを備えてもよい。ＣＰＵ１００５は、バイナリデータ読み込み部２１の機能を実現する際、バイナリデータ１０４を読み込んでキャッシュメモリ上に展開する。

メモリ１００６とは、例えば、ＲＡＭ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ ＥＰＲＯＭ）等の不揮発性もしくは揮発性の半導体メモリ、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、またはＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）等が該当する。

なお、バイナリデータ生成部１０およびステートチャート実行部２０の各機能について、一部を専用のハードウェアで実現し、一部をソフトウェアまたはファームウェアで実現するようにしてもよい。例えば、ステートチャート実行部２０については専用のハードウェアとしての処理回路１００１でその機能を実現し、バイナリデータ生成部１０についてはＣＰＵ１００５がメモリ１００６に格納されたプログラムを読み出して実行することによってその機能を実現することが可能である。

バイナリデータ生成部１０に入力されるステートチャート情報１０３およびバイナリデータ生成部１０が生成したバイナリデータ１０４は、例えばＨＤＤ１００２に保存される。なお、これは一例にすぎず、ステートチャート情報１０３およびバイナリデータ１０４は、ＤＶＤ等のメモリ１００６に保存されてもよい。

ステートチャート実行装置１０１における通信部２２は、入力インタフェース装置１００３および出力インタフェース装置１００４である。入力インタフェース装置１００３は、外部機器１０２から情報を受信する。出力インタフェース装置１００４は、外部機器１０２へ情報を送信する。

外部機器１０２は、ステートチャート実行装置１０１と同様に、専用のハードウェアであってもよいし、メモリに格納されているプログラムを実行するＣＰＵであってもよい。
また、ステートチャート実行装置１０１を構成する処理回路１００１またはＣＰＵ１００５が、ステートチャート実行装置１０１の機能だけでなく、外部機器１０２の機能を実現してもよい。例えば、カーナビゲーションシステムのＣＰＵが、ステートチャート実行装置１０１および外部機器１０２の各機能を実現する構成であってもよい。あるいは、例えばコンピュータのＣＰＵが、バイナリデータ生成部１０の機能を実現し、カーナビゲーションシステムのＣＰＵがステートチャート実行部２０および外部機器１０２の各機能を実現する構成であってもよい。

以上のように、実施の形態１に係るステートチャート実行装置１０１は、状態の遷移を表現したステートチャートに関するステートチャート情報１０３をバイナリデータ１０４にするバイナリデータ生成部１０と、バイナリデータ１０４に基づいてステートチャートの処理を実行するステートチャート実行部２０とを備える構成である。バイナリデータ生成部１０は、ステートチャート情報１０３を読み込み、ステートチャートを構成するデータを生成するステートチャート情報読み込み部１１と、ステートチャートを構成するデータ間の関連度を計算する関連度計算部１２と、ステートチャートを構成するデータをバイナリ化する個別データバイナリ化部１３と、関連度計算部１２が計算した関連度に基づき、ステートチャートを構成するデータの配列を計算する最適配列計算部１４と、個別データバイナリ化部１３がバイナリ化したデータを最適配列計算部１４が計算した配列で並べた場合の位置を示すオフセットを設定するオフセット設定部１５と、個別データバイナリ化部１３がバイナリ化しオフセット設定部１５がオフセットを設定したデータを、最適配列計算部１４が計算した配列で統合してバイナリデータ１０４にするバイナリデータ統合部１６とを有する構成である。これにより、ステートチャートのデータ構造を最適化したバイナリデータ１０４を得ることができる。そして、ステートチャート実行部２０は、バイナリデータ１０４に基づいてステートチャートを高速に実行することができる。

具体的には、最適配列計算部１４は、関連度計算部１２が計算した関連度に基づき、関連度が高いデータ同士が近くに配置されるような配列を計算する構成である。
最適配列計算部１４が評価関数またはコスト関数を最適化するようなデータの順列を求めることで、メモリ上で、関連性の高いデータを近くに配置することができる。これにより、ステートチャート実行部２０がステートチャートを実行するときに、ＣＰＵのキャッシュヒット率の向上およびキャッシュヒットミスの低減が見込まれ、よってステートチャートの処理高速化が見込める。

また、バイナリデータ生成部１０がステートチャート情報１０３をバイナリ化し、バイナリデータ１０４を連続したメモリ領域に配置することで、メモリフラグメンテーションが発生しない。これにより、バイナリデータ読み込み部２１によるメモリ割り当て処理の高速化と、状態遷移処理部２３によるステートチャート実行時のキャッシュヒット率向上とが見込まれる。

また、オフセット設定部１５は、ステートチャートを構成するデータのオフセットを設定する構成である。ステートチャート実行部２０は、バイナリデータ１０４を読み込むバイナリデータ読み込み部２１と、外部機器１０２からイベント情報を受信する通信部２２と、通信部２２が受信したイベント情報に従ってステートチャートの状態遷移処理を実行する際に、バイナリデータ１０４に設定されたオフセットが示す位置のデータにアクセスする状態遷移処理部２３とを有する構成である。
オフセットを利用したデータアクセスにより、状態遷移処理部２３が状態遷移処理を実行する際に直接遷移先のステートデータにアクセスできる。このため、ステート名の文字列からステートデータを探索するような処理が発生せず、よって状態遷移処理の高速化が可能である。

また、バイナリデータ生成部１０は、テーブル表現のステートチャートだけではなく、階層状態または平行状態を持つステートチャートも、それらのステートチャートを構成するデータ間の関連度を計算して一次元の配列に変換し、バイナリデータ１０４にすることができる。

なお、本発明はその発明の範囲内において、実施の形態の任意の構成要素の変形、または実施の形態の任意の構成要素の省略が可能である。

この発明に係るステートチャート実行装置は、ステートチャートを高速に実行するようにしたので、タッチパネル、音声認識、または空間ジェスチャ認識などのユーザインタフェースデバイスを備えた外部機器に用いるステートチャート実行装置に適している。

１０ バイナリデータ生成部、１１ ステートチャート情報読み込み部、１２ 関連度計算部、１３ 個別データバイナリ化部、１４ 最適配列計算部、１５ オフセット設定部、１６ バイナリデータ統合部、２０ ステートチャート実行部、２１ バイナリデータ読み込み部、２２ 通信部、２３ 状態遷移処理部、１０１ ステートチャート実行装置、１０２ 外部機器、１０３ ステートチャート情報、１０４ バイナリデータ、１００１ 処理回路、１００２ ＨＤＤ、１００３ 入力インタフェース装置、１００４ 出力インタフェース装置、１００５ ＣＰＵ、１００６ メモリ。

Claims (4)

1. 状態の遷移を表現したステートチャートに関するステートチャート情報をバイナリデータにするバイナリデータ生成部と、
   前記バイナリデータに基づいて前記ステートチャートの処理を実行するステートチャート実行部とを備え、
   前記バイナリデータ生成部は、
   前記ステートチャート情報を読み込み、前記ステートチャートを構成するデータを生成するステートチャート情報読み込み部と、
   前記ステートチャートを構成するデータ間の関連度を計算する関連度計算部と、
   前記ステートチャートを構成するデータをバイナリ化する個別データバイナリ化部と、
   前記関連度計算部が計算した関連度に基づき、前記ステートチャートを構成するデータの配列を計算する最適配列計算部と、
   前記個別データバイナリ化部がバイナリ化した前記データを前記最適配列計算部が計算した配列で並べた場合の位置を示すオフセットを設定するオフセット設定部と、
   前記個別データバイナリ化部がバイナリ化し前記オフセット設定部がオフセットを設定した前記データを、前記最適配列計算部が計算した配列で統合して前記バイナリデータにするバイナリデータ統合部とを有することを特徴とするステートチャート実行装置。
2. 前記ステートチャート実行部は、
   前記バイナリデータを読み込むバイナリデータ読み込み部と、
   外部機器からイベント情報を受信する通信部と、
   前記通信部が受信したイベント情報に従って前記ステートチャートの状態遷移処理を実行する際に、前記バイナリデータに設定されたオフセットが示す位置のデータにアクセスする状態遷移処理部とを有することを特徴とする請求項１記載のステートチャート実行装置。
3. 前記関連度計算部は、関連度を計算するための予め定められたルール、前記ステートチャートを構成するデータの利用頻度、前記ステートチャートにおける状態遷移の誘導度合い、前記ステートチャートを構成するデータの修正日時もしくは修正頻度のうちのいずれか１つ、または組み合わせに基づいて、関連度を計算することを特徴とする請求項１記載のステートチャート実行装置。
4. 前記最適配列計算部は、前記関連度計算部が計算した関連度に基づき、前記関連度が高いデータ同士が近くに配置されるような配列を計算することを特徴とする請求項１記載のステートチャート実行装置。

Images