図1Aは、状態機械モデルのための状態‐状態遷移表102を記述するデータ構造を図示する。表102は、状態機械モデル(例えばS1やS2)の遷移元状態(例えば、状態の名称、状態と関連付けられるラベル、状態と関連付けられる注釈など)を格納する縦のフィールド列104(例えば表102の左に沿った)を含む。ここで、「S1」は状態の名称または状態と関連付けられるラベルである。同様に、「S2」も別の状態の名称または状態と関連付けられるラベルである。
表102は、状態機械モデルの遷移先状態(例えばS1やS2)を格納する横のフィールド行106(例えば表102の上に沿った)も含む。前述のように、「S1」は状態の名称であり、「S2」は別の状態の名称である。遷移元状態のうちの1つによって特定される行と遷移先状態のうちの1つによって特定される列との交点には、状態機械モデルが対応する遷移元状態から対応する遷移先状態に遷移する条件(またはイベント)(例えば条件C11〜条件C22)を格納する条件フィールドがある。表102によれば、例えば、状態機械が現在、遷移元状態S1にある場合に、条件C12が満たされるときは、状態機械は状態S2に遷移し得る。条件C11〜条件C22は、例えば、ブール条件を含んでもよい。
条件と共に、表102は、対応する条件が満たされた場合に、および/または状態機械モデルが対応する遷移元状態から対応する遷移先状態に遷移する場合に、状態機械が取る(または実行する)アクション(例えばA11〜A22)を格納するアクションフィールドを含む。表102によれば、例えば、状態機械が現在、遷移元状態S1にあり、条件C12が満たされた場合には、状態機械は、それが状態S2に遷移するときにアクションA12を取る。アクションA11〜アクションA22は、変数に値を割り当てる、イベントを生成する、などをし得る。一実施形態では、表102は、例えば、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。さらに、一実施形態では、表102内の1または複数のセルが、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外してもよい。例えば、表102は、条件が満たされるが、状態機械モデルが異なる状態に遷移しない場合に取られるアクションを規定し得る。
前述のように、行(例えば、遷移元状態の名称で特定される)と列(例えば、遷移先状態の名称で特定される)との交点には、条件フィールドおよび、おそらくは、アクションフィールドがある。便宜上、条件フィールドおよびそれに対応するアクションフィールドを、遷移元状態および遷移先状態に対応する「セル」とみなされ得る。前述のように、セルは、アクションフィールド、条件フィールド、または遷移先フィールドさえも含んでもよく、または含まなくてもよい。
以下の説明では、列を縦として、行を横として記述する。これらの用語(「列」、「行」、「縦」、「横」)は、フィールドセットの相対的関係(直交など)を示すために意図され、必ずしも特定の縦方向および/または横方向ではない。したがって、横の行の第1のフィールドセットおよび縦の列の第2のフィールドセットを記述し、および/または表示する実施形態は、同時に、縦の列の第1のフィールドセットおよび横の行の第2のフィールドセットを記述し、および/または表示する実施形態を開示するとも理解される。同様に、本明細書では、縦としてのライン、または横としてのラインと記述する。これらの用語(「ライン」、「縦」、「横」)は、ラインの相対的関係(直交など)を示すために意図され、必ずしも特定の縦方向および/または横方向ではない。したがって、第1の横のラインおよび第2の縦のラインを記述し、および/または表示する実施形態は、同時に、縦としての第1のラインおよび横としての第2のラインを記述し、および/または表示する実施形態を開示するとも理解される。
図1Bは、状態機械モデルのための状態‐条件(または状態‐イベント)表112を記述するデータ構造を図示する。表102と同様に、表112は、状態機械モデルの遷移元状態(例えば、状態の名称、状態と関連付けられるラベル、状態と関連付けられる注釈)を格納する縦のフィールド列114(例えば表112の左に沿った)を含む。表102とは異なり、表112は、条件またはイベントを格納する横のフィールド行116(例えば表112の上に沿った)を含む。遷移元状態のうちの1つによって特定される行と条件のうちの1つによって特定される列との交点には、対応する条件が満たされる場合に(または対応するイベントが発生する場合に、または対応するイベントが発生し、条件が満たされる場合に)状態機械が遷移し得る遷移先状態を格納する遷移先フィールドがある。表112によれば、例えば、状態機械が現在、遷移元状態S1にあり、条件C2が満たされる場合には、状態機械は状態S2に遷移し得る。表102と同様に、条件C1および条件C2は、例えば、ブール条件を含んでもよい。
条件と共に、表112は、対応する条件が満たされる場合に対応する遷移元状態にあるとき、対応するイベントが発生する場合、または対応するイベントが発生し、条件が満たされる場合に(例えば、状態機械モデルが対応する遷移先状態に遷移する場合に)、状態機械が取る(または実行する)アクション(例えばA11〜A22)を格納するアクションフィールドを含む。表112によれば、例えば、状態機械が現在、遷移元状態S1にあり、条件C2が満たされる場合には、状態機械はアクションA12を取る(例えば、それが状態S2に遷移する時点で)。アクションA11〜アクションA22は、変数を再定義する、などをし得る。一実施形態では、表112は、例えば、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。さらに、一実施形態では、表112内の1または複数のセルが、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外してもよい。
前述のように、行(すなわち、遷移元状態によって特定される)と列(すなわち、条件によって特定される)との交点には、遷移先フィールドおよび、おそらくは、アクションフィールドがある。便宜上、遷移先フィールドおよびそれに対応するアクションフィールドは、遷移元状態および条件に対応する「セル」とみなされ得る。セルは、アクションフィールド、条件フィールド、または遷移先フィールドさえも含んでもよく、または含まなくてもよい。
状態機械によってモデリングされるシステムに応じて、ユーザは状態機械を、状態‐状態遷移表によって、または状態‐条件遷移表によって記述するよう選択し得る。すなわち、ある場合には、状態‐状態遷移表を選択した方がより好都合となり、別の場合には、状態‐条件遷移表を選択した方がより好都合となる。
状態機械モデルが前述のように格納されることに加えて、状態機械モデルは、また図1Aおよび図1Bに示されるように提示され(例えば表示され)得る。すなわち、ユーザは状態機械モデルを、ディスプレイ上の状態‐状態遷移表102として、またはディスプレイ上の状態‐条件遷移表112として見得る。
<例示的モデリング環境>
図2Aは、例えば、状態図を生成するための方法およびシステムを実装するための例示的環境200の図である。図2Aに示すように、環境200は、コンピュータデバイス210、ネットワーク230、ターゲット環境240、およびプロセッシングクラスタ250を含み得る。
コンピュータデバイス210は、例えば、パーソナルコンピュータ、ワークステーション、サーバデバイス、ブレードサーバ、メインフレーム、携帯情報端末(PDA:personal digital assistant)、デスクトップコンピュータ、ラップトップ、タブレット、または、1もしくは複数のアクティビティを実行し、および/または1もしくは複数の結果を生成する命令を実行するデバイスといった別のタイプの計算デバイスもしくは通信デバイスなどの、1または複数のコンピュータデバイスを含み得る。コンピュータデバイス210は、処理動作、表示動作、通信動作などを実行するデバイスを含み得る。例えば、コンピュータデバイス210は、ユーザに代わってアクティビティの処理を実行し、および/または支援するために使用され得る、1または複数の処理デバイスやストレージデバイスといった論理回路(logic)を含み得る。
コンピュータデバイス210は、さらに、別のデバイス(図2Bには示されていない)にデータを送信し、または別のデバイスからデータを受信することによる通信動作を実行し得る。データは、1または複数のネットワークにおいて、および/または1または複数のデバイスと共に使用するために適合され得る、実質的にあらゆるフォーマットの任意のタイプの機械可読情報であってよい。データは、ディジタル情報を含んでもよく、アナログ情報を含んでもよい。データはさらに、パケット化されてもよく、および/またはパケット化されなくてもよい。アナログデータはディジタル化されてもよい。
コンピュータデバイス210は、モデリングシステム220を含んでもよい。モデリングシステム220は、動的システムを表すグラフィカルモデルの作成、変更、設計、および/またはシミュレーションを可能にする開発ツール(ソフトウェアアプリケーションなど)を含んでもよい。さらに、モデリングシステム220は、グラフィカルモデルに基づく実行可能なコードの自動生成を可能であり得る。モデリングシステム220は、動的モデルとコストと制約条件モデルとによって定義される軌道最適化問題を解くためのフレームワーク100を提供するための機能を含んでもよい。
ネットワーク230は、コンピュータデバイス210が、ターゲット環境240および/またはプロセッシングクラスタ250といった、環境200の他の構成要素と通信できるようにし得る。ネットワーク220は、1または複数の有線ネットワークおよび/または無線ネットワークを含み得る。例えば、ネットワーク220は、セルラネットワーク、公衆陸上移動網(PLMN:Public Land Mobile Network)、第2世代(2G)ネットワーク、第3世代(3G)ネットワーク、第4世代(4G)ネットワーク(LTE(long term evolution)ネットワークなど)、第5世代(5G)ネットワーク、符号分割多元接続(CDMA:code division multiple access)ネットワーク、GSM(global system for mobile communications)ネットワーク、GPRS(general packet radio services)ネットワーク、Wi‐Fiネットワーク、イーサネットネットワーク、上記ネットワークの組み合わせ、および/または別のタイプの無線ネットワークを含んでもよい。加えて、または代替として、ネットワーク230はまた、ローカル・エリア・ネットワーク(LAN:local area network)、広域ネットワーク(WAN:wide area network)、メトロポリタン・エリア・ネットワーク(MAN:metropolitan area network)、アドホックネットワーク、イントラネット、インターネット、光ファイバベースのネットワーク(光ファイバ・サービス・ネットワークなど)、衛星ネットワーク、テレビネットワーク、および/またはこれらもしくは他のタイプのネットワークの組み合わせを含んでもよい。
ターゲット環境240は、モデリングシステム220内のグラフィカルモデルによって表される動的システムと関連付けられ得る1または複数のデバイスを含んでもよい。例えば、ターゲット環境240は、動的システムに対応する1組のセンサおよび/または1組のコントローラを含み得る。モデリングシステム220は、ターゲット環境240からデータを受信し、受信されるデータをグラフィカルモデルへの入力として使用し得る。さらに、ターゲット環境240は、モデリングシステム220から実行可能なコードを受信し得る。受信される実行可能なコードは、ターゲット環境240が、ターゲット環境240と関連付けられる動的システム上で1または複数の動作を実行できるようにし得る。ターゲット環境240は、例えば、組み込み処理デバイスを含んでもよい。
プロセッシングクラスタ250は、グラフィカルモデルと関連してモデリングシステム220によって使用され得る処理リソースを含み得る。例えば、プロセッシングクラスタ250は、プロセッシングユニット255‐A〜プロセッシングユニット255‐N(本明細書ではまとめて「各プロセッシングユニット255」、個別に「プロセッシングユニット255」と称する)を含んでもよい。各プロセッシングユニット255は、コンピュータデバイス210に代わって動作を実行し得る。例えば、プロセッシングユニット255は、モデリングシステム220内のグラフィカルモデルにおいて並列処理を実行し得る。モデリングシステム220は、プロセッシングクラスタ250に実行されるべき動作を提供してもよく、プロセッシングクラスタ250は、各プロセッシングユニット255間で動作と関連付けられるタスクを分割してもよく、プロセッシングクラスタ250は、各プロセッシングユニット255から実行されたタスクの結果を受信し、動作の結果を生成し、動作の結果をモデリングシステム220に提供してもよい。
一実装形態では、プロセッシングユニット255は、グラフィックプロセッシングユニット(GPU:graphic processing unit)を含んでもよい。GPUは、グラフィックス処理(例えば、ブロック画像転送動作、同時の画素単位動作など)に関連した動作を実行するための、および/または多数の動作を並列に実行するための専用回路を含む1または複数の装置を含んでもよい。別の例では、プロセッシングユニット255は、マルチコアプロセッサの1つのコアに対応してもよい。別の例では、プロセッシングユニット255は、例えば、コンピューティングクラウドの一部として動作する計算デバイスなど、コンピュータデバイスのクラスタの一部であるコンピュータデバイスを含んでもよい。
図2Aには環境200の例示的な構成要素が示されているが、他の実装形態では、環境200は、図2Aに示されるものと比べて、より少ない構成要素、異なった構成要素、異なった配置の構成要素、および/または追加的な構成要素を含んでもよい。代替として、または加えて、環境200の1または複数の構成要素が、環境200の1または複数の他の構成要素によって実行されるとして記述される1または複数のタスクを実行してもよい。
図2Bは、一実施形態を実施するための代替の例示的な環境200’を図示する。環境200’は、モデル用のコントローラを設計、実装し、および/または、例えば、コントローラ用のコードを生成するなど、モデルからコードを生成するための、1または複数のエンティティを含むモデル(状態機械モデルなど)を構築するために使用され得る。環境200’は、コンピュータデバイス210、取得論理(acquisition logic)214、オペレーティングシステム212、モデリングシステム220、モデル222、入力デバイス240、表示デバイス216、モデル表現(model representation)218、およびプラント242を含んでもよい。図2Bのシステムは例示であり、環境200’の他の実施形態は、より少ないデバイス、より多いデバイス、および/または図2Bの構成とは異なる構成のデバイスを含み得る。
コンピュータ210(図2Bの)は、おおむね、図2Aを参照して前述したものと同様であり得る。取得論理214は、コンピュータデバイス210の外部のデバイスからデータを取得し得て、そのデータをコンピュータデバイス210に利用可能にし得る。例えば、取得論理214は、コンピュータデバイス210にデータを利用可能にするために使用される、アナログ・ディジタルコンバータ、ディジタル・アナログコンバータ、フィルタ、マルチプレクサなどを含んでもよい。コンピュータデバイス210は、モデリング操作、コントローラ設計アクティビティなどを実行するために、取得されるデータを使用し得る。
オペレーティングシステム212は、コンピュータデバイス210と関連付けられるハードウェアリソースおよび/またはソフトウェアリソースを管理し得る。例えば、オペレーティングシステム212は、ユーザ入力の受理、コンピューティング環境デバイス210の操作、メモリの割当て、システム要求の優先順位付けなどと関連付けられるタスクを管理し得る。一実施形態では、オペレーティングシステム212は、仮想オペレーティングシステムであってもよい。オペレーティングシステム212の実施形態は、Linux、Mac OS、Microsoft Windows、Solaris、UNIXなどを含んでもよい。オペレーティングシステム212はさらに、コンピュータデバイス210によって提供され得る仮想マシン上で実行してもよい。
モデリングシステム220は、ユーザが、それだけに限らないが、数学、科学、工学、医学、商取引などといった分野に関連したシミュレーションタスクまたはモデリングタスクを実行することを可能にするコンピューティング環境を提供し得る。モデリングシステム220は、ユーザが実行可能なセマンティクスを有するモデルを構築することを可能にする命令を実行する1または複数のアプリケーションをサポートし得る。例えば、一実施形態では、モデリングシステム220は、ユーザが、実行可能なセマンティクスを有するフリーフォームモデル(例えば、1次、2次、3次、4次、5次などのオーダモデル)を作成することを可能にし得る。モデリングシステム220はさらに、時間ベース、イベントベースなどのモデリングアクティビティをサポートし得る。
モデル222は、実行可能なテキストモデルまたはグラフィカルモデルについての情報を含んでもよい。例えば、モデル222は、時間ベースのモデル、イベントベースのモデル、状態遷移モデル、データ・フロー・モデル、構成要素図、エンティティ・フロー・ダイアグラム、方程式ベースの言語図などであり得る、テキストモデルまたはグラフィカルモデムについての情報を含んでもよい。モデル222のグラフィカルな実施形態は、動作を実行するための実行可能なコードを表すエンティティ(例えば、ブロック、アイコンなど)を含んでもよい。モデルを用いてシミュレーションを実行するために、エンティティについてのコードが実行され得る。エンティティは、モデル内のあるエンティティと別のエンティティとの間でデータを共有するための経路を表すラインを用いて相互に接続され得る。
入力デバイス240はユーザ入力を受理し得る。例えば、入力デバイス240は、ユーザの動きまたは行為を、コンピュータデバイス210によって解釈され得る信号またはメッセージに変換し得る。入力デバイス240は、それだけに限らないが、キーボード、ポインティングデバイス、バイオメトリックデバイス、加速度計、マイクロフォン、カメラ、触覚デバイスなどを含み得る。
表示デバイス216は、ユーザに情報を表示し得る。表示デバイス216は、陰極線管(CRT:cathode ray tube)、プラズマ表示デバイス、発光ダイオード(LED:light emitting diode)表示デバイス、液晶ディスプレイ(LCD:liquid crystal display)デバイスなどを含んでもよい。表示デバイス216の実施形態は、必要に応じてユーザ入力を受理する(例えばタッチスクリーンを介して)ように構成され得る。一実施形態では、表示デバイス216はユーザに1または複数のグラフィカル・ユーザ・インターフェース(GUI:graphical user interface)を表示し得る。GUIは、モデル240および/または他のタイプの情報を含んでもよい。
モデル表現218は、モデル222の視覚表現および/またはモデル222によって提供される視覚表現、例えばプロットウィンドウなどを含んでもよい。例えば、モデル表現218は、ユーザに表示されてもよく、ラインで接続されるいくつかのエンティティを含んでもよい。
プラント242は、コンピュータデバイス210にデータを提供する1または複数のデバイスを含んでもよい。例えば、プラント242は、加速度計、サーモカップル、光電トランシーバ、ひずみ計などといったセンサを用いてモニタされるエンジンシステムを含んでもよい。一実施形態では、取得論理214は、アナログ形式またはディジタル形式でプラント242から信号を受理し得て、それらの信号を、コンピュータデバイス210での使用に適した形式に変換し得る。
<例示的なコンピュータデバイス>
図2Cは、一実施形態によるコンピュータデバイス210の例示的な構成要素を示す図である。図2Cに示されるように、コンピュータデバイス210は、バス260、プロセッサ265、メモリ270、入力デバイス275、出力デバイス280、および通信インターフェース285含み得る。
バス260は、コンピュータデバイス210の構成要素間の通信を可能にする経路を含んでもよい。プロセッサ265は、1もしくは複数のシングルコアプロセッサおよび/もしくはマルチコアプロセッサ、マイクロプロセッサ、ならびに/または命令を解釈し、実行することのできる処理論理(processing logic)(例えば、ASIC(application specific integrated circuit)、FPGA(field programmable gate array)、ARMプロセッサなど)を含んでもよい。メモリ270は、情報およびプロセッサ265による実行のための命令を格納し得るRAM(random access memory)デバイスもしくは別のタイプの動的ストレージデバイス、プロセッサ265による使用のための静的情報および命令を格納し得るROM(read only memory)デバイスもしくは別のタイプの静的ストレージデバイス、磁気記録メモリデバイスおよび/もしくは光記録メモリデバイスおよびこれに対応するドライブ、ならびに/またはフラッシュメモリといったリムーバブル形式のメモリを含んでもよい。
入力デバイス275は、例えば、キーパッド、キーボード、ボタン、またはキーパッドもしくはキーボードといった入力デバイスのための入力ジャック、カメラ、アナログ・ディジタルコンバータ(ADC)、パルス幅変調(PWM:pulse−width modulation)入力など、オペレータがコンピュータデバイス210に情報を入力することを可能にするメカニズムを含み得る。出力デバイス280は、1または複数のライトインジケータ、スピーカ、ディジタル・アナログコンバータ(DAC)、PWM出力などを含む、オペレータに情報を出力するメカニズムを含み得る。
出力デバイス280は、ユーザに情報を表示する表示デバイスを含んでもよい。表示デバイスは、陰極線管(CRT)、プラズマ表示デバイス、発光ダイオード(LED)表示デバイス、液晶ディスプレイ(LCD)デバイスなどを含んでもよい。表示デバイスは、必要に応じてユーザ入力を受理する(例えばタッチスクリーンを介して)ように構成され得る。一実施形態では、表示デバイスはユーザに1または複数のグラフィカル・ユーザ・インターフェース(GUI)を表示し得る。表示デバイスは、状態機械モデルを含むモデルの表現(例えば、状態‐状態遷移表、状態‐条件遷移表、状態‐イベント遷移表、および/または統合状態遷移表)を表示し得る。またモデル表現は、ラインで接続されるいくつかのエンティティも含んでもよい。
通信インターフェース285は、コンピュータデバイス210が他のデバイスおよび/またはシステムと通信できるようにする送受信機を含み得る。例えば、通信インターフェース285は、モデム、ネットワーク・インターフェース・カード、および/または無線インターフェースカードを含んでもよい。
以下で詳細に記述するように、コンピュータデバイス210は、軌道最適化問題の解を生成するためのフレームワークに関連したある動作を実行し得る。コンピュータデバイス210は、これらの動作を、プロセッサ265が、メモリ270といったコンピュータ可読媒体に格納されるソフトウェア命令を実行したことに応答して実行し得る。コンピュータ可読媒体は、非一時的メモリデバイスとして定義され得る。メモリは、単一の物理的メモリデバイス内のメモリ空間を含んでもよく、複数の物理的メモリデバイスにまたがって分散されてもよい。
ソフトウェア命令は、別のコンピュータ可読媒体から、または通信インターフェース285を介して別のデバイスからメモリ270に読み込まれ得る。メモリ270に含まれるソフトウェア命令は、プロセッサ265に、以下に記述するプロセスを実行させ得る。あるいは、本明細書に記述するプロセスを実装するために、配線回路をソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて使用されてもよい。よって、本明細書で記述する実装形態は、ハードウェア回路とソフトウェアとのいかなる特定の組み合わせにも限定されない。
図2Cにはコンピュータデバイス210の例示的な構成要素が示されているが、他の実装形態では、コンピュータデバイス210は、図2Cに示されるものと比べて、より少ない構成要素、異なった構成要素、追加的な構成要素、または異なった配置の構成要素を含んでもよい。加えて、または代替として、コンピュータデバイス210の1または複数の構成要素が、コンピュータデバイス210の1または複数の他の構成要素によって実行されるとして記述される1または複数のタスクを実行してもよい。
<例示的なモデリングシステム>
図3は、コンピュータデバイス210に含まれ得るモデリングシステム220の例示的な構成要素の図である。モデリングシステム220は、既存のソフトウェアコンポーネントをモデルの作成において使用されるようにし、モデルに基づく実行可能なコードの生成を可能にし得る開発ツールを含み得る。例えば、開発ツールは、数値コンピューティング環境のためのユーザインターフェースを提供するグラフィカル・モデリング・ツールまたはアプリケーションを含んでもよい。加えて、または代替として、開発ツールは、動的システムをモデリングし(例えば、微分方程式、差分方程式、代数方程式、離散事象、離散状態、確率関係などに基づいて)、シミュレートする(例えば、モデルを実行することによって)ためのユーザインターフェースを提供するグラフィカル・モデリング・ツールおよび/またはアプリケーションを含んでもよい。
動的システム(自然なものにせよ人工的なものにせよ)は、応答がいつでも、その入力刺激、その現在の状態、および現在時刻の関数であり得るシステムであり得る。そうしたシステムの範囲は、単純なシステムから高度に複雑なシステムにまでに及び得る。自然な動的システムには、例えば、落下物体、地球の自転、生体力学系(筋肉、関節など)、生化学系(遺伝子発現、タンパク質経路)、天気、および気候パターンシステム、ならびに/または任意の他の自然の動的システムが含まれ得る。人工的な、または工学技術で作られた動的システムには、例えば、弾むボール、一端に分銅が結び付けられたばね、自動車、航空機、主要な電気製品の制御システム、通信ネットワーク、オーディオ信号処理システム、および金融もしくは株式市場、ならびに/または任意の他の人工的な、もしくは工学技術で作られた動的システムが含まれ得る。
モデルによって表されるシステムは、モデルにおいて、ブロックと呼ばれることの多いモデリングエンティティの集合体として表され得る様々な実行セマンティクスを有し得る。ブロックは、一般には、モデルにおいて使用され得る機能の一部分をいう。ブロックは、グラフィカルに表され、テキストで表され、および/または何らかの形式の内部表現に格納され得る。また、例えばグラフィカルなブロック図においてブロックを表すために使用される特定の視覚的描写は設計上の選択であり得る。
ブロックは、ブロック自体がそのブロックを構成する1または複数のブロックを含み得るという点で、階層的であってよい。1または複数のブロック(サブブロック)を含むブロックは、サブシステムブロックと称され得る。サブシステムブロックは、モデルによって表される全体システムのサブシステムを表すように構成され得る。サブシステムブロックは、サブシステムブロックが含む要素によってのみ読取り可能、書き込み可能な変数を含む論理的な作業領域を有するように構成されるマスク・サブシステム・ブロックであってもよい。
グラフィカルモデル(機能モデルなど)は、エンティティ間の関係を伴うエンティティを含んでもよく、関係および/またはエンティティは、それらと関連付けられる属性を有していてもよい。エンティティは、ブロックおよび/またはポートといったモデル要素を含んでもよい。関係は、ライン(コネクタラインなど)および参照といったモデル要素を含んでもよい。属性は、属性と関連付けられるモデル要素の値情報およびメタ情報といったモデル要素を含んでもよい。グラフィカルモデルは、構成情報と関連付けられてもよい。構成情報は、モデル実行情報(例えば、数値積分スキーム、基本実行周期など)、モデル診断情報(例えば、代数ループをエラーとみなすべきか、それとも警告を生じさせるべきか)、モデル最適化情報(例えば、モデル要素が実行中にメモリを共有すべきかどうか)、モデル処理情報(例えば、共通機能をモデルのために生成されるコードにおいて共有すべきかどうか)などといったグラフィカルモデルについての情報を含んでもよい。
加えて、または代替として、グラフィカルモデルは、実行可能なセマンティクスを有してもよく、および/または実行可能であってもよい。実行可能なグラフィカルモデルは時間ベースのブロック図であってもよい。時間ベースのブロック図は、例えば、ライン(コネクタラインなど)で接続されたブロックで構成され得る。ブロックは、微分方程式系(例えば、連続時間の振る舞いを規定するための)、差分方程式系(例えば、離散時間の振る舞いを規定するための)、代数方程式(例えば、制約条件を規定するための)、状態遷移系(例えば、有限状態機械の振る舞いを規定するための)、イベントベースのシステム(例えば、離散事象の振る舞いを規定するための)などといった要素的な動的システムで構成され得る。ラインは、信号(例えば、ブロック間の入力/出力関係を規定するため、または関数呼び出しといったブロック間の実行依存関係を規定するための)、変数(例えば、ブロック間で共用される情報を規定するための)、物理的接続(例えば、電線、体積流量を有するパイプ、リジッドな機械的接続などを規定するための)などを表し得る。属性は、モデル要素と関連付けられた、サンプル時間、次元、複雑さ(値に対する虚数成分があるかどうか)、データ型などといったメタ情報で構成され得る。
時間ベースのブロック図では、ポートをブロックと関連付けられ得る。2つのポート間の関係は、2つのポート間のライン(コネクタラインなど)を接続することによって作成され得る。ラインは同様に、または代替として、例えば分岐点を作成することによって、他のラインに接続され得る。例えば、3つ以上のポートは、ラインを各ポートに接続し、各ポートをすべてのラインの共通分岐点に接続することによって接続され得る。物理的な接続を表すラインの共通分岐点は動的システム(例えば、あるタイプのすべての変数を合計して0にすること、またはあるタイプのすべての変数を同等にすることによって)であり得る。ポートは、入力ポート、出力ポート、イネーブルポート、トリガポート、関数呼び出しポート、パブリッシュポート、サブスクライブポート、例外ポート、エラーポート、物理ポート、エンティティ・フロー・ポート、データ・フロー・ポート、制御フローポートなどであり得る。
ブロック間の関係は、因果的であってもよく、および/または非因果的であってもよい。例えば、モデル(機能モデルなど)は、ライン(コネクタラインなど)を使用して連続時間積分ブロック(continuous−time integration block)の出力ポートをデータ・ログ・ブロック(data logging block)の入力ポートに接続することによってデータ・ログ・ブロックに因果的に関連させ得る連続時間積分ブロックを表すブロックを含み得る。さらに、モデルの実行中に、連続時間インテグレータによって格納される値は、実行の現在時刻が進むに従って変化し得る。連続時間インテグレータの状態の値は出力ポート上で利用可能であり得て、データ・ログ・ブロックの入力ポートとの接続は、この値をデータ・ログ・ブロックに利用可能にし得る。
一例では、ブロックは、非因果的モデリング関数または動作を含み、またはこれに対応してもよい。非因果的モデリング関数の一例は、1もしくは複数の入力、状況、および/もしくは条件に応じて異なって実行され得る関数、動作、または方程式を含み得る。言い換えると、非因果的モデリング関数または動作は、予め決定される因果関係を持たない関数、動作、または方程式を含み得る。例えば、非因果的モデリング関数は、他方の変数(例えば「Y」)に対応する割り当てられた値を受理すると、方程式中の一方の変数(例えば「X」)の値を識別するために使用され得る方程式(例えば、X=2Y)を含み得る。同様に、他方の変数(例えば「Y」)の値が提供された場合にも、方程式は、一方の変数(例えば「X」)を判定するために使用され得る。
方程式への因果関係の割り当ては、方程式中のどの変数がその方程式を用いて算出されるか判定することで構成され得る。因果関係の割り当ては、ガウス消去法といったソーティングアルゴリズムによって実行され得る。因果関係の割り当ての結果は、代数的サイクルまたはループを表す強く接続された成分を有するソートされた方程式を表す下三角ブロック行列であり得る。因果関係の割り当ては、モデルコンパイル(model compilation)の一部であり得る。
方程式はシンボリック形式で提供され得る。1組のシンボリック方程式は、例えば、より単純な形式の手続にシンボリック的に処理され得る。例を挙げると、2つの方程式X=2Y+UおよびY=3X−2Uの系が、1つの方程式5Y=−Uにシンボリック的に処理され得る。方程式のシンボリック的な処理はモデルコンパイルの一部であり得る。
したがって、非因果的モデリング関数は、例えば、有効な出力を生成し、またはそれ以外に意図されるように動作するために、ある入力または入力のタイプ(例えば、特定の変数の値)を要件としなくてもよい。実際、非因果的モデリング関数の動作は、例えば、その非因果的モデリング関数に対応する状況、条件、または入力に基づいて変動し得る。したがって、上記の記述はブロック間の方向的に一貫した信号フローを記述するが、他の実装形態では、ブロック間の相互作用は、必ずしも方向的に特有の、または一貫したものに限らなくてもよい。
一実施形態では、モデル内のコネクタラインは、2つの接続されたブロック間で共有される関連した変数を表し得る。それらの変数は、その組み合わせが電力を表すように関連され得る。例えば、コネクタラインは、電圧、電流、電力などを表し得る。加えて、または代替として、ブロック間の信号フローは、自動的に導出され得る。
ある実装形態では、1または複数のブロックは同様に、または代替として、それらのブロックが含まれるモデルに対応する1または複数の規則またはポリシーに従って動作し得る。例えば、モデルが、電子回路といった実際の物理的なシステムまたはデバイスとして振る舞うために意図されていた場合、ブロックは、例えば、物理学の法則(本明細書では「物理学に基づく規則」ともいう)内で動作することが要件とされ得る。これらの物理学の法則は、微分方程式および/または代数方程式(例えば制約条件など)として定式化され得る。微分方程式は、時間、距離、および/または他の量に関する導関数を含んでもよく、常微分方程式(ODE:ordinary differential equation)、偏微分方程式(PDE:partial differential equation)、および/または微分代数方程式(DAE:differential and algebraic equation)であってもよい。モデルおよび/またはモデル成分がそうした規則またはポリシーに従って動作することを要件とすることは、例えば、そうしたモデルに基づくシミュレーションが意図されるように動作することを保証することに役立つ。
サンプル時間は、グラフィカルモデルの要素と関連付けられ得る。例えば、グラフィカルモデルは、入力値を実行時間の進捗に従って積分し得る連続時間積分ブロックといった連続サンプル時間を有するブロックを含み得る。この積分は、微分方程式によって規定され得る。実行中、連続時間の振る舞いは、数値ソルバーの一部である数値積分スキームによって近似され得る。数値ソルバーは実行時間を進めるために離散的ステップを取り得て、これらの離散的ステップは、実行中一定であってもよく(例えば固定ステップ積分)、または実行中に変動してもよい(例えば可変ステップ積分)。
イベントは、連続時間の振る舞いが特定の特性を示す場合に生成され得る。例えば、連続時間の振る舞いを近似する数値ソルバーの2つの離散的ステップの間で不等式がその真理値を変化させる場合に、イベントが生成され得る。イベントの時間には、2つの離散的ステップのどちらかの時間が割り当てられてもよく、真理値が変化する時間に最も近い、2つの離散的ステップの間の値であってもよい。2つの離散的時間ステップの間のこの時間は、規定された数値的正確さに見合う求根数値アルゴリズムに基づいて計算され得る。またイベントは関数呼び出しに関連され得る。すなわち、関数呼び出しは、例えば、条件の評価のためにモデルを「起動し」得るイベントであってもよい。
代替として、または加えて、グラフィカルモデルは、特定の遅延の後で対応する入力の値を出力し得る単位遅延ブロック(unit delay block)といった、離散サンプル時間を伴うブロックを含んでもよい。この遅延は時間間隔であってよく、この間隔は、ブロックのサンプル時間を判定し得る。実行中に、実行時間が、単位遅延ブロックの出力が変化し得る時点に到達する度に、単位遅延ブロックが評価され得る。これらの時点は、実行を開始する前に、グラフィカルモデルのスケジューリング解析に基づいて静的に判定され得る。
代替として、または加えて、グラフィカルモデルは、接続されたブロックが非周期的に評価されるようにスケジュールすることができる関数呼び出しジェネレータブロック(function−call generator block)といった、非対称サンプル時間を伴うブロックを含んでもよい。実行中に、関数呼び出しジェネレータブロックは入力を評価し得て、実行時間がある時点に到達して入力が特定の値を獲得する場合、関数呼び出しジェネレータブロックは、接続されたブロックを、この時点であって実行時間を進める前に評価されるようにスケジュールし得る。
さらに、グラフィカルモデルの属性の値は、グラフィカルモデルの他の要素またはグラフィカルモデルの属性から推測され得る。推測はモデルコンパイルの一部であり得る。例えば、グラフィカルモデルは、ブロックのサンプル時間を規定する属性を有し得る、単位遅延ブロックといったブロックを含んでもよい。グラフィカルモデルが、基本実行周期を規定する実行属性を有する場合、単位遅延ブロックのサンプル時間は、この基本実行周期から推測され得る。
別の例として、グラフィカルモデルは、2つの単位遅延ブロックのうちの第1のブロックの出力が2つの単位遅延ブロックのうちの第2のブロックの入力に接続される2つの単位遅延ブロックを含んでもよい。第1の単位遅延ブロックのサンプル時間は、第2の単位遅延ブロックのサンプル時間から推測され得る。この推測は、第2の単位遅延ブロックのサンプル時間属性を評価した後で、第1の単位遅延ブロックのサンプル時間属性を評価することによってグラフ探索が継続するように、モデル要素属性の伝搬によって実行され得る。なぜならば、第1の単位遅延ブロックは第2の単位遅延ブロックに直接的に接続されているからである。
グラフィカルモデルの属性の値は、1または複数の継承された設定、1または複数のデフォルト設定などといった特性設定に設定され得る。例えば、ブロックと関連付けられた変数のデータ型は、doubleといったデフォルトに設定され得る。デフォルト設定により、グラフィカルモデルが含む要素の属性(例えば、接続されたブロックと関連付けられた変数のデータ型)および/またはグラフィカルモデルの属性に基づいて代替のデータ型(例えば、single、integer、fixed pointなど)が推測され得る。別の例として、ブロックのサンプル時間が継承されるように設定され得る。継承されるサンプル時間の場合には、グラフィカルモデルが含む要素の属性および/またはグラフィカルモデルの属性(例えば基本実行周期)に基づいて特定のサンプル時間が推測され得る。
別の例として、実行可能なグラフィカルモデルは、状態機械モデル(例えばグラフィカル状態機械モデル)を含んでもよい。状態機械モデルは、実行可能な時間ベースのモデルを含んでもよい。状態機械モデルは、ある時点におけるその遷移を評価する離散的状態遷移系を含んでもよい。これらの時点は周期的な(また離散的な)サンプル時間に基づいてもよく、式(例えば不等式)の真理値の変化に基づいてもよい。遷移系の評価はイベントの発生と関連付けられてもよく、評価は、ある状態からの遷移が可能であるかどうかを評価することからなっていてもよい。遷移は、関連付けられたイベント(1または複数の)が発生したとき、および関連付けられた条件(1または複数の)が満たされた場合に可能となり得る。状態遷移系は、グラフィカルモデル内の他のエンティティから獲得され、グラフィカルモデル内の他のエンティティに提供され得る入力変数および出力変数を有してもよい。上記のように、グラフィカルエンティティは、微分方程式系および差分方程式系といった時間ベースの動的システムを表し得る。別の実施形態では、グラフィカルモデルおよびグラフィカルエンティティは、多領域の動的システムを表し得る。各領域は、例えば、連続時間、離散時間、離散事象、状態遷移系、および/もしくは計算処理のモデルといった実行領域または振る舞いを含んでもよい。計算処理のモデルは、微分方程式、差分方程式、代数方程式、離散事象、離散状態、確率関係、データフロー、同期データフロー、制御フロー、プロセスネットワーク、および/または状態機械に基づいてもよい。
モデリングシステム220は、テクニカルコンピューティング環境(TCE:technical computing environment)を実装し得る。TCEは、ユーザが、それだけに限らないが、数学、科学、工学、医学、商取引などといった分野に関連したタスクを、C++、Fortran、Javaなどといった従来のプログラミング言語でユーザがコードを開発することを必要とする環境といった別のタイプの環境でそれらのタスクが実行された場合よりも、効率よく実行することを可能にするコンピューティング環境を提供する、ハードウェアおよび/またはソフトウェアベースの論理を含み得る。
一実装形態では、TCEは、当業者がよく知る数学的表記で問題および/または解を表現するために使用され得る動的型付け言語を含んでもよい。例えば、TCEは、基本要素として配列を使用してもよく、その場合、配列は次元化を要件としなくてもよい。加えて、TCEは、データ解析、データ視覚化、アプリケーション開発、シミュレーション、モデリング、アルゴリズム開発などに使用され得る行列および/またはベクトルの定式化を実行するように適合され得る。これらの行列および/またはベクトルの定式化は、統計、画像処理、信号処理、制御設計、生命科学モデリング、離散事象の解析および/または設計、状態ベースの解析および/または設計などといった、多くの分野で使用され得る。
TCEはさらに、数学的関数および/またはグラフィカルツール(例えば、プロット、面、画像、立体表現などを作成するための)を提供し得る。一実装形態では、TCEは、これらの関数および/またはツールを、ツールボックス(例えば、信号処理、画像処理、データプロット、並列処理などのためのツールボックス)を用いて提供し得る。別の実装形態では、TCEはこれらの関数をブロックセットとして提供し得る。別の実装形態では、TCEはこれらの関数を、ライブラリによってなど、別のやり方で提供し得る。TCEは、テキストベースの環境、グラフベースの環境、または、テキストおよびグラフの両方に基づくハイブリッド環境といった別のタイプの環境として実装され得る。
TCEは、それだけに限らないが、The MathWorks, Inc.によるMATLAB(登録商標);Octave;Python;Comsol Script;National InstrumentsのMATRIXx;Wolfram Research, Inc.のMathematica;Mathsoft Engineering & Education Inc.のMathcad;MaplesoftのMaple;Imagine That Inc.のExtend;仏国のコンピュータサイエンスおよび制御の研究機関(INRIA)のScilab;CadenceのVirtuoso;Dassault SystemesのModelicaまたはDymolaといった製品を用いて実装され得る。
代替の実施形態は、それだけに限らないが、The MathWorks, Inc.によるSimulink(登録商標)、Stateflow(登録商標)、SimEvents(登録商標)など;Visual SolutionsによるVisSim;National InstrumentsによるLabView(登録商標);Dassault SystemesによるDymola;Measurement ComputingによるSoftWIRE;DALSA CorecoによるWiT;AgilentによるVEE ProまたはSystemVue;PPT VisionのVision Program Manager;Khoral ResearchのKhoros;Gedae, Inc.によるGedae;(INRIA)のScicos;CadenceのVirtuoso;IBMのRational Rose;TelelogicのRhopsodyまたはTau;カリフォルニア大学バークレー校のPtolemy;統一モデリング言語(UML:unified modeling language)またはSysML環境の諸態様といった製品を用いてTCEをグラフベースのTCEとして実装し得る。
別の実施形態は、上記のテキストベースのTCEまたはグラフベースのTCEの1またはは複数といったTCEを含む製品と互換性のある言語で実装され得る。例えば、MATLAB(登録商標)(テキストベースのTCE)は、第1のコマンドを使用してデータ配列を表し、第2のコマンドを使用して配列を転置することができる。別の製品は、TCEを含んでも含まなくてもよいが、MATLAB(登録商標)互換であり、配列コマンド、配列転置コマンド、または他のMATLAB(登録商標)コマンドを使用することができる。例えば、別の製品は、モデル検査を実行するために、MATLAB(登録商標)コマンドを使用し得る。
さらに、別の代替の実施形態は、テキストベースのTCEおよびグラフベースのTCEの特徴が組み合わさったハイブリッドTCEで実装され得る。一実装形態では、一方のTCEが他方のTCEの上で動作することができる。例えば、テキストベースのTCE(MATLAB(登録商標)など)が基礎として動作し、グラフベースのTCE(Simulinkなど)がMATLAB(登録商標)の上で動作し得て、ユーザにグラフィカル・ユーザ・インターフェースおよびグラフィカル出力(例えば、データについてのグラフィカル表示、ダッシュボードなど)を提供するために、テキストベースの機能(コマンドなど)を利用し得る。
図3に示されるように、モデリングシステム220は、シミュレーションツール310、エンティティライブラリ320、インターフェース論理330、コンパイラ340、コントローラ論理350、オプティマイザ360、シミュレーションエンジン370、レポートエンジン380、およびコードジェネレータ390を含み得る。図3に示されるモデリングシステム220の実施形態は例示であり、モデリングシステム220の他の実施形態は、本発明の趣旨を逸脱することなく、より多数のエンティティまたはより少数のエンティティを含み得る。
シミュレーションツール310は、モデルを構築するためのアプリケーションを含んでもよい。シミュレーションツール310は、動的システムモデル110ならびに/またはコストおよび制約モデル120といった、実行可能なセマンティクスを有するテキストモデルまたはグラフィカルモデルを構築するために使用され得る。グラフィカルモデルの場合、シミュレーションツール310は、ユーザに、モデルエンティティおよび/または接続の作成、表示、変更、診断、注釈付け、削除、印刷などを行わせ得る。シミュレーションツール310は、ユーザ入力を受理し、モデルを実行し(例えばシミュレーションを獲得するために)、結果を表示させ、コードを生成するなどのために、図2または図3に示される他のエンティティとインタラクションし得る。シミュレーションツール310は、ユーザに、テキストモデルを構築し、もしくはテキストモデルとインタラクションするためのエディタ、および/またはグラフィカルモデルを作成し、もしくはグラフィカルモデルとインタラクションするためのGUIを提供し得る。エディタは、ユーザに、例えば、モデルの指定、編集、注釈付け、保存、印刷、および/またはパブリッシュを行わせるように構成され得る。エディタとのインタラクションを可能にするテキストインターフェースが提供され得る。ユーザは、テキストインターフェースを用いてモデルに対する自動編集操作を実行するスクリプトを書き得る。例えば、テキストインターフェースは、モデルのキャンバスとして機能し得る1組のウィンドウを提供し得て、ユーザにモデルとインタラクションさせ得る。モデルは1または複数のウィンドウを含んでもよい。複数の階層レベルに分割されたモデルが別々のウィンドウとして異なる階層レベルを示し得る。
エンティティライブラリ320は、動的システムモデル110ならびに/またはコストおよび制約モデル120に追加される特定のブロックといった、グラフィカルモデル(例えばモデル表現218)を含む表示ウィンドウに、ユーザがドラッグ・アンド・ドロップすることができるコードモジュールまたはエンティティ(ブロック/アイコンなど)を含んでもよい。グラフィカルモデルの場合、ユーザはさらに、ターゲット環境140および/またはプラント242といった、システムのグラフィカルモデルを生成するために、接続を用いてエンティティを連結し得る。
インターフェース論理330は、モデリングシステム220に、デバイス(例えば、プラント242、ターゲット環境240、プロセッシングクラスタ250など)またはソフトウェアモジュール(例えば、関数、アプリケーション・プログラム・インターフェースなど)へ/からデータおよび/または情報を送信させ、または受信させ得る。一実施形態では、インターフェース論理330は、取得論理310とモデリングシステム220との間のインターフェースを提供し得る。
コンパイラ340は、動的システムモデル110、コストおよび制約モデル120、ならびに/またはインターフェースモデル130といったモデルをコンパイルして実行可能形式にし得る。コードジェネレータ390は、コンパイラ340によって生成されたコンパイル済みモデルからコードを生成し得る。生成されたコードは、モデル化の結果を生成するために、コンピュータデバイス210上で実行され得る。一実施形態では、コンパイラ340は、モデルと関連付けられたエラーを診断するためのデバッグ機能も提供し得る。コードジェネレータ390は、グラフィカルモデルの一部の実行可能なコードを生成し得る。次いで、実行可能なコードは、モデルの実行中に自動的に実行され得て、モデルの第1の部分は解釈済み実行として実行し、モデルの第2の部分はコンパイル済み実行として実行する。
コントローラ論理350は、グラフィカルモデルにおいてコントローラを作成し、実装するために使用され得る。例えば、コントローラ論理350は、グラフィカルモデルにおいてコントローラのタイプを表すエンティティについての機能を提供し得る。グラフィカルモデルが実行されると、コントローラ論理350は、グラフィカルモデル内のエンティティとインタラクションすることによってモデル上の制御動作を実行し得る。一実施形態では、コントローラ論理350は、例えば、フレームワーク100と関連付けられた決定済みのNOCゲインを含むフィードバック制御、「比例・積分・微分(PID:proportional−integral−derivative)」制御、ゲインスケジューリング制御、H無限大制御、モデル予測制御(MPC:model predictive control)、動的反転制御、バング/バング制御、スライディングモード制御、デッドビート制御、および/または他のタイプの制御といった、グラフィカルモデルにおけるコントローラを実装する制御アルゴリズムを含んでもよい。コントローラ論理350の実施形態は、スタンドアロンの、または分散型の実装形態として動作するように構成され得る。
オプティマイザ360は、モデルについてのコード、パラメータ、性能(例えば、実行速度および/またはメモリ使用)などを最適化し得る。例えば、オプティマイザ360は、コードが最適化されずにコードが実行される場合よりも、例えば、コードが占有するメモリを少なくし、コードを効率よく実行させ、コードを高速で実行させるようにコードを最適化し得る。またオプティマイザ360は、例えば、コントローラのパラメータを最適化するために、コントローラ論理350の最適化を実行してもよい。一実施形態では、オプティマイザ360は、コンパイラ340、コントローラ論理350、コードジェネレータ390などと一緒に動作し得て、またはこれらに統合され得る。オプティマイザ360の実施形態は、例えば、オプティマイザ360が作用するデータを受理するための他のオブジェクト指向ソフトウェアとインタラクションするソフトウェアオブジェクトによって実装され得る。
シミュレーションエンジン370は、システムをシミュレートするモデルを実行するための動作を実行し得る。システムをシミュレートするモデルを実行することは、モデルをシミュレートすると称され得る。シミュレーションエンジン370は、ユーザ設定またはシステム設定に基づいて、スタンドアロンのシミュレーションまたはリモートシミュレーションを実行するように構成され得る。
レポートエンジン380は、モデリングシステム220内の情報に基づいてレポートを生成し得る。例えば、報告エンジン380は、コントローラが設計仕様を満たすかどうかを示すレポート、コントローラが安定して動作するかどうかを示すレポート、モデルが正しくコンパイルされているかどうかを示すレポートなどを生成し得る。レポートエンジン380の実施形態は、ディスプレイ(表示デバイス216など)上での表示のための電子形式で、ハードコピー形式で、および/または記憶デバイスにおける格納に適合された形式でレポートを生成することができる。
コードジェネレータ390は、コンパイラ340によって生成されたコンパイル済みモデルからコードを生成することができる。一実施形態では、コードジェネレータ390は、生成されたコードをコンパイルし、リンクさせてモデルの「メモリ内実行可能」バージョンを生成するように構成され得る。モデルのメモリ内実行可能バージョンは、例えば、モデルをシミュレートし、検証し、削減し、および/または線形化するために使用され得る。別の実施形態では、コードジェネレータ390は、モデルからコードを生成することができる。一実施形態では、コードジェネレータ390は、第1の形式のコードを受理し得て、そのコードを第1の形式から第2の形式へ変換し得る。一実施形態では、コードジェネレータ390は、モデルの少なくとも一部分から、ソースコード、アセンブリ言語コード、バイナリコード、インターフェース情報、コンフィグレーション情報、パフォーマンス情報、タスク情報などを生成することができる。例えば、コードジェネレータ390は、モデルから、C、C++、SystemC、Java、構造化テキスト、ハードウェア記述言語(HDL:hardware description language)などのコードを生成することができる。
コードジェネレータ390の実施形態はさらに、統一モデリング言語(UML)ベースの表現および/またはグラフィカルモデルの一部または全部からの拡張(例えば、SysML(System Modeling Language)、XML(Extensible Markup Language)、MARTE(Modeling and Analysis of Real Time and Embedded System)、AADL(Architecture Analysis and Design Language)、HDL、AUTOSAR(Automotive Open System Architecture)などを生成することができる。一実施形態では、オプティマイザ360は、パラメータ(例えば、メモリ使用、実行速度、多重処理など)に従って最適化されたコードを生成するために、コードジェネレータ390とインタラクションすることができる。本発明の原理と一致するモデリング環境の実施形態は、さらに、検証構成要素、妥当性検査構成要素などといった構成要素を含むことができる。
本発明の実施形態は、多変数フィードバック制御問題をインタラクティブに定式化し、ほとんどすべてのオーダおよび/または遅延の非線形モデルにおける使用のためのコントローラを設計するために使用され得る。各実施形態は、正確な線形化手法を使用して、非線形モデルの少なくとも一部分を表すことができる線形時不変モデルを生成するように構成され得る。図3にはモデリングシステム220の例示的な構成要素が示されているが、他の実装形態では、モデリングシステム220は、図3に示されるものと比べて、より少ない構成要素、異なった構成要素、異なった配置の構成要素、または追加的な構成要素を含んでもよい。加えて、または代替として、モデリングシステム220の1または複数の構成要素が、モデリングシステム220の1または複数の他の構成要素によって実行されると記載される1または複数のタスクを実行してもよい。
<例示的なデータ構造>
図4Aは、一実施形態における状態機械モデルを記述する例示的なデータ構造402(または統合状態遷移表402)を図示する。表402は、状態機械モデルの遷移元状態を格納する縦のフィールド列404(例えば表402の左側に沿った)を含む。遷移元状態フィールドのうちの1または複数について、表402は、1または複数のセル406(個別には「セル406」または「セル406‐x」)も含んでいてよい。セル406は、満たされる場合、状態機械モデルが対応する遷移元状態から遷移先状態に遷移し得る条件を特定する条件フィールドを含んでもよい。一実施形態では、条件フィールドは、それが発生する場合条件(例えば同じフィールド内の)を評価させるイベントを規定し得る。またイベントは関数呼び出しに関連させられ得る。すなわち、関数呼び出しは、例えば、条件の評価のためにモデルを「起動し」得るイベントであってもよい。
またセル406は、対応する条件(例えば同じセル内の)が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールドも含んでもよい。またセル406は、対応する条件(例えば同じセル内の)が満たされ、状態機械モデルが対応する遷移先状態(例えば同じセル内の)に遷移する場合に、状態機械モデルによって取られるアクションを特定するアクションフィールドも含んでもよい。一実施形態では、統合状態遷移表402は、例えば、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。さらに、一実施形態では、表402内の1または複数のセル406が、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外してもよい。条件フィールドがイベントを規定する実施形態では、アクションフィールドは、対応するイベントが発生し、対応する条件が満たされた場合に、状態機械モデルによって取られるべきアクションを特定する。便宜上、また理解しやすくするために、図4Aの例示的な実施形態では、遷移表402内の条件フィールドがイベントを含まないとみなされている。遷移先フィールドが省かれる場合には、デフォルトの遷移(例えば、隣接するセルの遷移先状態、テンプレート行内のセルの遷移先状態など)が発生し得る。
前述の状態‐状態遷移表102および状態‐条件遷移表112内のセルとは異なり、表402内のセルは、条件フィールドおよび遷移先フィールドの両方を含む。例示的な表402には、3つの遷移元状態S1、S2、およびS3が示されている。遷移元状態S1は条件フィールド(セル406‐1の)に格納された条件CAと関連付けられる。よって、表402、セル406‐1に記載されているように、状態機械モデルが遷移元状態S1にあり、条件CAが満たされる場合、状態機械モデルは状態S3に遷移する。表402に示されるように、遷移元状態S2は、別のセルの条件フィールド(例えばセル406‐2)に格納された同じ条件CAと関連付けられる。したがって、表402、セル406‐2に記載されているように、状態機械モデルが遷移元状態S2にあり、条件CAが満たされる場合、状態機械モデルは状態S1に遷移する。よって、表402に示されるように、遷移元状態S1(セル406‐2の)に対応する条件フィールドは、遷移元状態S2に対応する条件フィールドと同一の条件(例えばCA)を有する。言い換えると、表402は、例えば、状態‐条件遷移表112と比べて冗長な条件情報を格納し得る。一実施形態では、セル406‐2に冗長な条件情報を格納するのではなく、セル406‐2の条件フィールドは、セル406‐1の条件フィールドを参照し得る(例えば指し示す)。例えば、セル406‐2の条件フィールドは、$1$2(例えば、状態を規定する列がカウントされると仮定すると、行1の列2)を参照し得る。
さらに、表402、セル406‐3に記載されているように、遷移元状態S2は、遷移先フィールドに格納された遷移先状態S2および条件フィールドに格納された条件CCと関連付けられる。よって、状態機械モデルが遷移元状態S2にあり、条件CCが満たされる場合、状態機械モデルは状態S2に遷移する。セル406‐4で特定されるように、遷移元状態S3も、遷移先フィールドに格納された遷移先状態S2と関連付けられる。よって、状態機械モデルが遷移元状態S3にあり、条件CBが満たされる場合、状態機械モデルは状態S2に遷移する。よって、表402に示されるように、遷移元状態S2(セル406‐3の)に対応する遷移先状態フィールドは、遷移元状態S3に対応する遷移先状態(セル406‐4の)と同一の遷移先状態(例えばS2)を有する。言い換えると、表402は、例えば、状態‐状態遷移表402と比べて冗長な遷移先状態情報を格納し得る。実際、セル406‐5も、遷移先状態S2(例えば、冗長な遷移先状態)のための条件CBを特定する。セル406‐5で特定されるように、状態機械モデルが遷移元状態S1にあり、条件CBが満たされる場合、状態機械モデルは遷移先状態S2に遷移し得る。一実施形態では、冗長な遷移先状態情報を格納する(例えばセル406‐4に)のではなく、遷移先フィールド(例えばセル406‐4の)は、別のセル(例えばセル406‐3)の遷移先フィールドを参照(例えば指し示す)し得る。例えば、セル406‐4の遷移先フィールドは、$2$3(例えば行2列3)を参照し得る。
遷移表402に示されるように、状態S2は、遷移先状態として複数回参照されており、「多参照状態」とみなされ得て、遷移先状態S2の特定は、表402において重複して格納され得る。さらに、表402に示されるように、条件CAは条件として複数回規定されており、「多参照条件」とみなされ得て、条件CAの特定は、表402において重複して格納され得る。
図4Bは、別の実施形態における状態機械モデルを記述する例示的なデータ構造452(または統合状態遷移表452)を図示する。表452は、表402と同様に、状態機械モデルの遷移元状態を格納する縦のフィールド列454を含む。遷移元状態フィールドのうちの1または複数について、表452は、1または複数のセル456も含んでもよい。セル456は、満たされる場合、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。
表402のセルと同様に、表452のセル456は、条件フィールドおよび遷移先フィールドの両方を含む。例示的な表452には、4つの遷移元状態S1、S2、S3、およびS4が示されている。もっと多くの遷移元状態が可能であるが、便宜上4つが示されている。さらに、3より多くのセル456を各遷移元状態と関連付けられ得るが、便宜上、遷移元状態ごとに3つのセル456が示されている。遷移元状態S1は、同じ遷移先状態(例えば遷移先状態S2)を特定する複数のセル456(例えばセル456‐1およびセル456‐2)と関連付けられる。この場合、状態機械モデルが遷移元状態S1にあり、かつ条件CB(セル456‐2で特定されている)が満たされ、または条件CC(セル456‐1で特定されている)が満たされる場合、状態機械モデルは状態S2に遷移する。前述のように、一実施形態では、あるセル(例えばセル456‐2)で規定される遷移先状態は、別のセル(例えばセル456‐1)を参照(例えば、セル456‐2の遷移先フィールドで$1$3を規定)し得る。さらに、遷移元状態S2は、同じ条件(例えば条件CC)を特定する複数のセル(例えばセル456‐3およびセル456‐4)と関連付けられる。一実施形態では、そうした状況をエラーとみなされ得る。別の実施形態では、そうした状況は、第2の条件(例えばセル456‐3の条件)が考慮されることなく、第1の条件(例えば、左から右へ、またはセル456‐4の条件)が考慮される結果となり得る。すなわち、状態機械モデルが遷移元状態S2にあり、条件CCが満たされた場合には、状態機械モデルは、セル456‐4で特定される遷移先状態S2に遷移する。前述のように、一実施形態では、あるセル(例えばセル456‐4)で規定されている条件は、別のセル(例えばセル456‐3)を参照(例えば、セル456‐2の遷移先フィールドで$2$3を規定)し得る。
遷移表452に示されるように、状態S2は、遷移先状態として複数回参照されており、「多参照状態」とみなされ得て、遷移先状態S2の特定は、表452に重複して格納され得る。さらに、表452に示されるように、条件CCは条件として複数回規定されており、「多参照条件」とみなされ得て、条件CCの特定は、表452に重複して格納され得る。
図4Aおよび図4Bは、表402の情報の例示的な表示も図示し得る。すなわち、表402または表452は、表示デバイス216の画面上に、ほぼ図4Aに示される通りに表示され得る。後述するように、表402は別のやり方で、例えば、状態‐状態形式、状態‐条件形式、状態‐イベント形式、またはそのような形式の組み合わせで表示され得る。
図4Cは、一実施形態における状態機械モデルを含むグラフィカルモデルを生成し、評価するためのプロセスのフローチャートである。プロセス480は、コンピュータデバイス210によって実行され得る。プロセス480は、時間ベースの動的システムを表す実行可能なグラフィカルモデルを生成から始め得る(ブロック482)。前述のように、グラフィカルモデルは、グラフィカルエンティティ間の関係を伴うグラフィカルエンティティを含んでもよい。グラフィカルモデルは、遷移表402および/または遷移表452といった状態遷移表によって記述される状態機械モデル(例えば、複数の離散状態を有する時間ベースの実行可能な状態機械)を含んでもよい。
グラフィカルモデルは、評価され、および/またはシミュレートされ得る(ブロック484)。実行可能なグラフィカルモデルを評価することは、状態機械モデルを評価すること(ブロック486)を含んでもよい。前述のように、状態機械を評価することは、各時点において状態間で遷移すべきかどうかを評価することを含んでもよい。各時点は、例えば、周期的に、式の値が変化する場合に、イベントが発生する場合に、または条件が満たされる場合に発生し得る。一実施形態では、状態間で遷移すべきかどうかを評価することは、多参照状態を含む状態遷移表(例えば、遷移元状態のうちの複数から同一の遷移先状態に遷移することを記述する表)を評価することを含んでもよい。別の実施形態では、状態間で遷移すべきかどうかを評価することは、多参照条件を含む状態遷移表(例えば、遷移元状態のうちの複数から遷移すべき同一の条件を記述する表)を評価することを含んでもよい。
一実施形態では、状態機械モデルを評価することは、グラフィカルエンティティのうちの1つから変数(例えば入力変数)を入力すること(ブロック488)および入力変数に基づいて状態機械モデルを評価すること(ブロック490)を含んでもよい。別の実施形態では、グラフィカルモデルを評価することは、グラフィカルエンティティのうちの1つに変数(例えば出力変数)を出力すること(ブロック492)および出力変数に基づいてグラフィカルモデルを評価すること(ブロック494)を含んでもよい。
例えば、図5Aは、状態‐状態遷移表形式の統合状態遷移表402の表示を図示する。状態‐状態遷移表102と同様に、表502は、状態機械モデルの遷移元状態を表示する縦のフィールド列504と、状態機械モデルの遷移先状態を表示する横のフィールド行406とを含む。遷移元状態のうちの1つによって特定される行と遷移先状態のうちの1つによって特定される列との交点には、状態機械モデルが対応する遷移元状態から対応する遷移先状態に遷移する条件を表示する条件フィールドがある。条件と共に、表502は、対応する条件が満たされた場合に、および/または状態機械モデルが対応する遷移元状態から対応する遷移先状態に遷移する場合に、状態機械が取る(または実行する)べきアクションを表示するアクションフィールドを含む。
統合状態遷移表402に格納された情報は、表502に示されるように編成し、表示され得る。図5Dは、統合状態遷移表内の情報を編成し、表示するためのプロセス550のフローチャートである。一実施形態では、同一の遷移先状態と関連付けられた表402の条件フィールドをグルーピングし得る(ブロック552)。例えば、図4Aに示されるように、セル406‐4、セル406‐3、およびセル406‐5はすべて、同一の遷移先状態S2に遷移するための条件(それぞれ、CB、CC、およびCB)を含む。これらの3つの条件(CB、CC、およびCB)は、表502の1つの列508にグルーピングされ得て、その場合、列508は列の最上部に遷移先状態S2を含む。同様に、図4Aに示されるように、セル406‐1およびセル406‐6は、どちらも遷移先状態S3に遷移するための条件(それぞれ、CAおよびCD)を含み得る。これら2つの条件(CAおよびCD)は、表502の1つの列510にグルーピングされ得て、その場合、列510は列の最上部に遷移先状態S3を含む。
よって、同一の遷移先状態と関連付けられた条件フィールドのグルーピング後、状態‐状態遷移表502は、状態機械モデルを表すように表示され得て(ブロック554)、遷移元状態は表502の列504に表示され、遷移先状態は表502の行506に表示され、各条件は、条件フィールドのグルーピングに基づき、遷移先状態が遷移先状態を表示する行506において反復されないように表示される。たとえデータが統合状態遷移表(例えば表402)として格納されたとしても、ユーザから見ると、状態機械モデルは状態‐状態遷移表(例えば表502)として表示される。別の実施形態では、各条件は、遷移先状態が遷移先状態を表す行506において反復され得るように表示される。
一実施形態では、ユーザは、表502に表示された情報を編集し得る。すなわち、表502は、統合状態遷移表402に格納された状態機械モデルへの変更、修正、および更新を受理するユーザインターフェースとして使用され得る。インターフェース論理330は、行506に表示された遷移先状態のうちの1つを編集するためのユーザからの入力を受理し得て(ブロック556)、編集された遷移先状態は2つの条件フィールドと関連付けられ、各条件フィールドは異なる遷移元状態に対応する。
例えば、図5Bにカーソル514で示されるように、ユーザは、表502の列510に格納された遷移先状態を「S1」に(「S3」から)なるように編集し得る。ユーザが編集を完了する場合、編集された遷移先状態は、表402の適切な遷移先フィールドに(例えば、遷移元状態に対応する条件と関連付けられた1もしくは複数のフィールドに)格納され得る(ブロック558)。よって、図5Cの編集された統合状態遷移表402’は、セル406‐1およびセル406‐6に遷移先状態S1(「S3」ではなく)を示している。後述するように、状態遷移表は、編集された情報と共に再表示され得て(ブロック560)、および/または新しい状態図は、編集された情報から、再生成され、表示され得る(ブロック562)。
図6Aは、状態‐条件遷移表形式602の統合状態遷移表402の表示を図示する。状態‐条件遷移表112と同様に、表602は、状態機械モデルの遷移元状態を表示する縦のフィールド列614と、条件を表示する横のフィールド行616とを含む。遷移元状態のうちの1つによって特定される行と条件のうちの1つによって特定される列との交点には、対応する条件が満たされた場合に状態機械が遷移し得る遷移先状態を表示する遷移先フィールドがある。条件と共に、表602は、対応する条件が満たされた場合に対応する遷移元状態にあったときに(例えば、状態機械モデルが対応する遷移先状態に遷移するときに)、状態機械が取る(または実行する)べきアクションを表示するアクションフィールドを含む。
よって、統合状態遷移表402に格納された情報は、表602に示すように編成され、表示され得る。図6Dは、統合状態遷移表内の情報を編成し、表示するためのプロセス650のフローチャートである。一実施形態では、同一の条件と関連付けられた遷移先フィールドは、グルーピングされ得る(ブロック652)。例えば、図4Aに示されるように、セル406‐1およびセル406‐2は同一の条件CAと関連付けられた遷移先状態(それぞれS3およびS1)を含む。これら2つの遷移先状態(S3およびS1)は表602の1つの列608にグルーピングされ得て、その場合、列608は列の最上部に条件CAを含む。同様に、図4Aに示されるように、セル406‐5およびセル406‐4も、同一の条件CBと関連付けられた遷移先状態(S2)を含む。これらの遷移先状態(S2)は表602の1つの列610にグルーピングされ得て、その場合、列610は列の最上部に条件CBを含む。
したがって、同一の条件と関連付けられた遷移先状態フィールドのグルーピング後、状態‐条件遷移表602は、状態機械モデルを表すように表示され得て(ブロック654)、遷移元状態は表602の列614に表示され、条件は表602の行616に表示され、遷移先状態は、遷移先状態のグルーピングに基づき、条件が条件を表示する行において反復されないように表示される。たとえデータが統合状態遷移表(例えば表402)として格納されたとしても、ユーザから見ると、状態機械モデルは状態‐条件遷移表(例えば表602)として表示される。別の実施形態では、各遷移先状態は、条件が条件を表す行において反復され得るように表示される。
一実施形態では、ユーザは、表602に表示された情報を編集し得る。すなわち、表602は、統合状態遷移表に格納された状態機械モデルへの変更、修正、および更新を受理するユーザインターフェースとして使用され得る。インターフェース論理330は、行616に表示された条件のうちの1つを編集するためのユーザからの入力を受理し得て(ブロック656)、編集された条件は2つの遷移先状態フィールドと関連付けられ、各遷移先状態フィールドは異なる遷移元状態に対応する。例えば、図6Bにカーソル618で示されるように、ユーザは、表602の列608に格納された条件を「CD」になる(「CA」から)ように編集し得る。ユーザが編集を完了する場合、編集された条件は、遷移元状態に対応する遷移先と関連付けられた適切な遷移先フィールドに格納される(ブロック658)。よって、図6Cの編集された統合状態遷移表402’’は、セル406‐1およびセル406‐2に条件CDを示す(「CA」ではなく)。
図4Aに示されるように、統合状態遷移表402は、セル406にアクションを格納するためのアクションフィールドを含む。特に、セル406‐5のアクションフィールドは、セル406‐2のアクションフィールドと同じアクション(例えばA12)を格納する。さらに、セル406‐1のアクションフィールドは、セル406‐6のアクションフィールドと同じアクションを格納する。また、セル406‐3のアクションフィールドは、セル406‐4のアクションフィールドと同じアクションを格納する。後述するように、状態遷移表は、編集された情報と共に再表示され得て(ブロック660)、および/または新しい状態図が、編集された情報から、再生成され、表示され得る(ブロック662)。
図7Aは、状態‐アクション遷移表形式702の統合状態遷移表402の表示を図示する。状態‐条件遷移表602と同様に、状態‐アクション遷移表は、状態機械モデルの遷移元状態を表示する縦のフィールド列714と、アクションを表示する横のフィールド行716とを含む。遷移元状態のうちの1つによって特定される行と条件のうちの1つによって特定される列との交点には、対応する条件が満たされた場合に状態機械が遷移し得る遷移先状態を表示する遷移先フィールドおよび条件フィールドがある。表702の上に沿って表示されたアクションフィールドは、状態機械モデルがある遷移元状態にあり、適切な条件が満たされた場合に(例えば、状態機械モデルが対応する遷移先状態に遷移する場合に)、状態機械が取る(または実行する)べきアクションを示す。
統合状態遷移表402に格納された情報は、表702に示されるように編成され、表示され得る。一実施形態では、同一のアクションと関連付けられた条件フィールドおよび/または遷移先フィールドがグルーピングされ得る。例えば、図4Aに示されるように、セル406‐5およびセル406‐2は同一のアクションA12と関連付けられた条件および遷移先状態を含む。これら2つの遷移先状態および条件は表702の1つの列710にグルーピングされ得て、その場合、列710は列の最上部にアクションA12を含む。同様に、図4Aに示されるように、セル406‐1およびセル406‐6は、同一のアクションA11と関連付けられた遷移先状態および条件を含む。これらの遷移先状態および条件は表702の1つの列708にグルーピングされ得て、その場合、列708は列の最上部にアクションA11を含む。最後に、図4Aに示されるように、セル406‐3およびセル406‐4は、同一のアクションA22と関連付けられた遷移先状態および条件を含む。これらの遷移先状態および条件は表702の1つの列712にグルーピングされ得て、その場合、列712は列の最上部にアクションA22を含む。
同一の条件と関連付けられた遷移先状態フィールドのグルーピング後、状態‐アクション遷移表702は、状態機械モデルを表すように表示され得て、遷移元状態は表702の列714に表示され、アクションは表702の行716に表示され、遷移先状態および条件は、アクションのグルーピングに基づき、アクションがアクションを表示する行において反復されないように表示される。たとえデータが統合状態遷移表(例えば表402)として格納されたとしても、ユーザから見ると、状態機械モデルは状態‐アクション遷移表(例えば表702)として表示される。別の実施形態では、遷移先状態および条件は、アクションがアクションを表す行において反復され得るように表示される。
一実施形態では、ユーザは、表702に表示された情報を編集し得る。すなわち、表702は、統合状態遷移表に格納された状態機械モデルへの変更、修正、および更新を受理するユーザインターフェースとして使用され得る。インターフェース論理330は、行716に表示されたアクションのうちの1つを編集するためのユーザからの入力を受理し得て、編集された条件は2つの遷移先状態フィールドおよび/または2つの条件フィールドと関連付けられ、各遷移先フィールドおよび/または条件フィールドは異なる遷移元状態に対応する。例えば、図7Bにカーソル718で示されるように、ユーザは、表702の列710格納されたアクション(例えば「A12」)を「AA」になるように編集し得る。この例では、表示される状態‐アクション遷移表は、図7Bに示されるもの(すなわち表702’)であってもよい。ユーザが編集を完了する場合、編集されたアクションは、遷移元状態に対応する遷移先および/または条件と関連付けられた適切なアクションフィールドに格納される。よって、図7Cの編集された統合状態遷移表402’’は、セル406‐5およびセル406‐2にアクション「AA」を示す(「A12」ではなく)。
図8Aは、別の実施形態における統合状態遷移表802を図示する。表402と同様に、表802は、状態機械モデルの遷移元状態の名称を格納する縦のフィールド列804を含む。1または複数の遷移元状態フィールドについて、表802は、1または複数のセル806も含んでもよい。セル806は、満たされる場合、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。
図8Bは、統合状態遷移表802に格納された情報をハイブリッド遷移表822に表示する別のやり方を図示する。表822は、表822の上に沿ったセル行824を含む。セル行824の各セルは、これらのセルの下の列にあるセルに格納されたフィールドのためのテンプレートとして振舞い得る。表822の場合、セル806内の上のフィールドは条件を規定し、中間のフィールドはアクションを規定し、下のフィールドは遷移先状態を規定する。行824の各セルのフィールドは、その列の下方の各フィールドの共通点を規定する。例えば、セル806‐1およびセル806‐2はどちらも、状態S2がセル824‐1で規定されているため、遷移先状態S2を規定している。別の例としてセル806‐3およびセル806‐4は、条件C3がセル824‐2で規定されているため、条件C3を規定している。別の例としてセル806‐5およびセル806‐6は、セル824‐3が条件C1およびアクションA1を規定しているため、条件C1およびアクションA1を規定している。セル806‐6の場合には、結果として得られるセルの条件は(C1およびC2)であり、結果として得られるアクションは(A1およびA23)である。言い換えると、表822内の各行のセルはどのように配置されてもよく、任意の列の共通要素は表822の上に沿って行824で表示され得る。行824の各セルはセル806と同じフィールドを有する。
図8Cは、別の実施形態における統合状態遷移表852を図示する。表402と同様に、表852は、状態機械モデルの遷移元状態の名称を格納する縦のフィールド列854を含む。1または複数の遷移元状態フィールドについて、表852は、1または複数のセル856も含んでもよい。セル856は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。
図8Dは、状態遷移表852に格納された情報をハイブリッド遷移表872に表示する別のやり方を図示する。表872は、表872の上に沿った条件フィールド行874を含む。行874のセルは条件フィールドを表示している。行874の条件フィールドは、同じ列の下方のフィールドの共通条件を規定する。例えば、セル856‐1は、条件C1が行874のその上の条件フィールドで規定されているため、条件C1を規定している。しかし、行874は、表852内のすべての条件を規定するものではない。それどころか、行874は、条件のうちの一部を規定するに過ぎない。行874に表示された条件は、自動的に選択されてもよく、ユーザによって選択されてもよい。セルが自動的に選択される(例えばインターフェース論理330によって)状況では、選択は、共通条件を規定する表852内のセル806(図8C参照)の数に基づいてもよい。すなわち、当該条件を規定する表852内のセル806(図8C参照)が多いほど、その条件が行874に表示される可能性がより高い。行874で規定されていない条件について、それらの条件はセル886で規定され得る。例えば、一実施形態では、他のどんなセルとも共通の特性を有しない表852内のセル806(図8C参照)は、セル886でリストされ得る。
図8Dは、共通の特性として条件が表示している。他の実施形態では、共通の特性は、例えば、遷移先状態やアクション(または、条件、アクション、および遷移先状態の任意の組み合わせ)であってもよい。
図9Aは、状態機械モデルを格納するための、アクションのラベルを含むデータ構造を図示する。表902は、前述の統合状態遷移表402と同様に構築されている。表902は、状態機械モデルの遷移元状態(オンおよびオフ)を格納する縦のフィールド列904(例えば、表902の左側に沿った)を含む。遷移元状態フィールドごとに、表902は、1または複数のセル906も含んでもよい。セル906は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件(例えば同じセル内の)が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件(例えば同じセル内の)が満たされ、状態機械モデルが対応する遷移先状態(例えば同じセル内の)に遷移する場合に、状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。
セル906‐1は、特定されたアクションのラベルも含む。例えば、表902に記述されているように、セル906‐1は(遷移元状態オフでは)条件「スイッチ入力>0」、オンという遷移先状態、および「入力値=1」というアクションを特定している。よって、状態機械モデルが遷移元状態オフにあり、条件「スイッチ入力>0」が満たされる場合には、状態機械モデルはオン状態に遷移し得て、アクション「入力値=1」を取られ得る。またセル906‐1は、アクション「入力値=1」にラベル「スイッチチェック」を関連付けている。
図9Aで使用されるシンタックスは、例示としては「ラベル:アクション」であるが、他のシンタックスも使用され得る。セル906‐1におけるラベルの定義は、ラベルがセル906‐2(例えば、アクション式の略記特定として)のアクションフィールドで特定されたアクションに使用されることを可能にする。すなわち、セル906‐2のアクションフィールドで特定されたアクションは「スイッチチェック」であり、これは、セル906‐1のアクションフィールドで特定されたラベルを参照することによって特定される。よって、セル906‐2のアクションフィールドで特定されたアクションは、セル906‐1のアクションフィールドで特定されたアクションと同一である。前述のように、一実施形態では、あるセル(例えばセル906‐2)で規定されるアクションは、別のセル(例えばセル906‐1)を参照(例えば、セル456‐2の遷移先フィールドで$1$2を規定)し得る。
図9Bは、ラベルを含む、統合状態遷移表902に格納された情報を表示する別の方法を図示する。図9Bに示されるように、表902に格納されたフィールドはディスプレイ上に表示される。ラベル「スイッチチェック」および関連付けられたアクション「入力値=1」は、セル906‐1のアクションフィールドに表示される。さらに、カーソル(例えば矢印)がセル906‐2内のラベル「スイッチチェック」を表示するアクションフィールド上でホバリングする。一実施形態では、ラベル「スイッチチェック」は、アクションを表示することなく、セル906‐2のアクションフィールドに表示される。この実施形態では、ユーザは、アクションが別の場所で(例えばセル906‐2で)定義されていると理解する。他の実施形態では、関連付けられたアクション式は、セル906‐2のラベルの横に示され得る。セル906‐2はラベルを参照させるに過ぎないため、一実施形態では、アクションラベルに近接して(例えばその上で)カーソルをホバリングさせることによって、ラベルと関連付けられたアクションを表示するポップアップボックス922が生成される。ポップアップボックス922の表示は、例えば、ラベルとアクションを関連付けるアクションフィールドが同時にディスプレイ上に表示されない場合に特に有用である。
一実施形態では、インターフェース論理330は、ユーザに、図9Bに示されるセル906‐2に表示されたアクションラベルを選択させ(例えば「クリックさせ」)得る。例えば、マウスを動かすことによってセル906‐2のアクションラベル上でカーソル矢印をホバリングさせた後で、ユーザは、「クリック」してマウス上のボタンを押下し得る。この場合には、ディスプレイの焦点を、アクション式がラベルと関連付けられるセル906‐1内のアクションフィールドに移動し得る。図9Bにおけるフォーカスは、表示されたセル906‐1のアクションフィールドの周りの太線のボックスとして示されている。この例では、ユーザは、例えばアクション式、すなわちラベルの名称を編集し得る。図9Bに示されるように、インターフェース論理330は、アクションラベルおよびアクション式を表示しているフィールドに別のカーソル924を表示し(例えばセル906‐1を呼び出し)、アクション式を編集するために、ユーザはタイプする(例えばキーボードで)ことができるようにし得る。
インターフェース論理330は、編集されたアクション式を受理し、編集されたアクション式を表902内の適切なフィールドに格納し得る。よって、この実施形態では、ユーザは、アクション式を一度編集し得て、編集された式は、他のセルの他のアクションフィールド(例えばセル906‐2のアクションフィールド)に格納されたアクションラベルの各出現と関連付けられる。シミュレーションツール310は、編集された式を表902のセル906‐1のアクションフィールドに格納し得る。一実施形態では、インターフェース論理330は、ユーザに、アクションラベルを表示している任意のアクションフィールド内のアクション式を編集することを可能にする。別の実施形態では、インターフェース論理330は、ユーザに、表示されたアクションフィールドとは別個の場所(例えば、アクションラベルをアクション式と関連付ける表)にあるアクション式を編集することを可能にする。
ラベルは、アクションフィールド以外のフィールドに使用され得る。例えば、ラベルは条件と関連付けられ得る。図9Cは、状態機械モデルを格納するための、条件のラベルを含むデータ構造を図示する。図9Cには、表902と同様の統合状態遷移表942が示されている。表942のセル946‐1は、条件フィールド内の条件のラベル「スイッチオン」を含む。ラベル「スイッチオン」は条件式「スイッチ入力>0」と関連付けられている。条件のラベルは、セル946‐2の条件フィールドでも、すなわち「(スイッチオン)以外」として使用される。図9Dには、ディスプレイ上に表示される表942が示されている。図示のように、カーソル(例えば矢印)が、セル946‐2の条件フィールドのラベル「スイッチオン」上でホバリングする。この場合、インターフェース論理330は、ユーザからカーソルをラベル「スイッチオン」上で動かす(例えばマウスを用いて)ためのコマンドを受理していてもよい。これに応答して、インターフェース論理330は、ラベルと関連付けられた条件式(例えば「スイッチ入力>0」)を表示し得る。一実施形態では、ユーザは、条件式を条件ラベル(例えばセル946‐1の)と関連付ける条件フィールドへフォーカスを変更させるために、マウス上のボタンを押下(例えば、条件ラベルを「クリック」)し得る。
アクションラベルに関して前述したように、インターフェース論理330は、ユーザに、条件式および/または条件ラベルを編集するための別のカーソルを提示し得る。インターフェース論理330は、編集された条件式を受理し、編集された条件式を表942内の適切なフィールドに格納し得る。よって、この実施形態では、ユーザは、条件式を一度編集し得て、編集された式は、次いで、他のセルの他のアクションフィールド(例えばセル946‐2のアクションフィールド)に格納されたアクションラベルの各出現と関連付けられる。インターフェース論理330は、編集された式を表942のセル946‐1のアクションフィールドに格納し得る。一実施形態では、インターフェース論理330は、ユーザが、アクションラベルを表示している任意のアクションフィールド内のアクション式を編集することを可能にする。別の実施形態では、インターフェース論理330は、ユーザが、表示された条件フィールドとは別個の場所(例えば、条件ラベルを条件式と関連付ける表)にある条件式を編集することを可能にする。
一実施形態では、インターフェース論理330は、ユーザに、遷移元状態のラベルを変更することを可能にし得る。例えば、図9Dに示されるように、ラベル「オフ」は「オフ1」であるように編集されている。すなわち、インターフェース論理330は、状態ラベルを編集するためのユーザからの入力を受理していた。この場合、インターフェース論理330はまた、その状態の参照を更新し得る(例えば自動的に)。よって、セル946‐2で規定された遷移先状態は、「オフ」から変更されて「オフ1」になる。複数のセル946が「オフ」とラベル付けされた遷移先状態の参照を含む場合、一実施形態では、セル946内のすべての参照が「オフ」から「オフ1」に変更され得る。別の実施形態では、セル内のすべての参照を「オフ」から「オフ1」に変更する前に、ユーザは警告され、または指示され得る。別の実施形態では、複数のセル946が「オフ」とラベル付けされた遷移先状態の参照を含む場合、ユーザは、ラベル「オフ」のどの出現を「オフ」から「オフ1」に変更すべきか選択し得る。
図10は、一実施形態における状態機械モデルを記述する例示的なデータ構造1002(例えば、統合状態遷移表1002)を図示する。表1002は、状態機械モデルの遷移元状態を格納する縦のフィールド列1004を含む。遷移元状態フィールドごとに、表1002は、1または複数のセル1006も含んでもよい。セル1006は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされ、状態機械モデルが対応する遷移先状態に遷移する場合に、状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。一実施形態では、統合状態遷移表1002は、例えば、セル1006内のアクションフィールドを除外し得る。また図10には、表1002内のデータをどのように表示するかも表されている。すなわち、表1002内のデータは、図10に示されるように表示され得る。
一実施形態では、セル1006は、対応する遷移元状態を特定する行の相対位置を規定することによって遷移先状態を規定し得る。例えば、図10に示されるように、セル1006‐1内の遷移先フィールドは「次」と規定されている。この場合には(セル1006‐1で特定されているように)、状態機械モデルが遷移元状態S1にあり、条件CAが満たされる場合、状態機械モデルは次の状態に、すなわち、データ構造で次に出現する(例えば、下方の、または下方向の)隣接する行(例えば、セル1006‐2を含む行)によって特定されている状態に遷移する。図10はデータをどのように表示し得るかも表しているため、「次」を規定している遷移先フィールドはまた、ディスプレイ上で(例えば、下方向における下方で)次に出現する隣接する行によって特定されている状態を規定し得る。一実施形態では、セル1006の遷移先フィールドは、「次(X)」(例えばXは整数である)を規定し得る。この場合、状態機械モデルが対応する遷移元状態にあり、対応する条件が満たされる場合、状態機械モデルは、対応する現在の遷移元状態のX行下方の状態に遷移する。例えば、「次(3)」はデータ構造における3行下を規定し得る。
別の例として、セル1006‐3の遷移先フィールドは、「前」を規定する。この場合には(セル1006‐3で特定されているように)、状態機械モデルが遷移元状態S3にあり、条件CCが満たされる場合、状態機械モデルは前の状態に、すなわち、データ構造で前に出現する(例えば、上方の、または上方向の)隣接する行(例えば、セル1006‐2を含む行)によって特定されている状態に遷移する。図10はデータをどのように表示し得るかも表しているため、「前」を規定している遷移先フィールドはまた、ディスプレイ上で(例えば、上方または上方向で)前に出現する隣接する行によって特定されている状態を規定し得る。一実施形態では、セル1006の遷移先フィールドは、「前(Y)」(例えばYは整数である)を規定し得る。この場合、状態機械モデルが対応する遷移元状態にあり、対応する条件が満たされる場合、状態機械モデルは、対応する現在の遷移元状態のY行上方の状態に遷移する。例えば、「前(3)」はデータ構造における3行上方を規定し得る。
遷移先状態を「前」または「次」として規定し得ることは、離散状態がおおむねその近隣の状態にのみ移動し、遠く離れた状態の遷移は規則ではなく例外である「列車のような」構造を有する有限状態機械のモデルには特に有用である。
別の例として、セル1006‐4の遷移先フィールドは「最後」を規定する。この場合には(セル1006‐4で特定されているように)、状態機械モデルが状態S1にあり、条件CBが満たされる場合、状態機械モデルは最後の状態または終了状態に、すなわち、データ構造で最後に出現する(例えば、下方向に最も離れた)最後の行(例えば、セル1006‐3を含む行)によって特定されている状態に遷移する。図10はデータがどのように表示され得るかも表しているため、「最後」を規定している遷移先フィールドはまた、表示される最後の行(例えば、ユーザが表示される表の最下部までスクロールする場合の最後の行)である状態を規定し得る。
別の例として、セル1006‐5の遷移先フィールドは「最初」を規定する。この場合には(セル1006‐5で特定されているように)、状態機械モデルが状態S3にあり、条件CBが満たされる場合、状態機械モデルは最初の状態または開始状態に、すなわち、データ構造で最初に出現する(例えば、上方向に最も離れた)最初の行(例えば、セル1006‐1を含む行)によって特定されている状態に遷移する。図10はデータがどのように表示され得るかも表しているため、「最初」を規定している遷移先フィールドはまた、表示される最初の行(例えば、ユーザが表示される表の最上部までスクロールする場合の最初の行)によって特定される状態を規定し得る。
遷移先状態を「次」、「前」、「最後」および「最初」として規定することができることにより、状態遷移表(例えば表1002)を、状態名変更または状態の再配置によって導入されるエラーの影響をより受けにくくさせ得る。すなわち、ユーザは、位置標識(例えば、「次」、「前」、「最後」または「最初」)がない場合に必要となるはずの余分なデータ入力を行うことを免れ得る。
一実施形態では、表1002といった状態遷移表は、遷移先状態を、対応する遷移元状態の振る舞い位置に対する、状態機械モデルの実行中の、振る舞いとして(例えば、時間的に実行され、またはシミュレートされる状態機械モデルの振る舞い)規定する遷移先フィールドを含んでもよい。例えば、セル1006‐6は遷移先状態を「先」として特定している。この場合には、状態機械モデルの実行中に、状態機械モデルが状態S2にあり、条件CCが満たされるときに、状態機械モデルは、状態アクティビティ振る舞いにおける先の状態に遷移し得る。この実施形態では、状態機械モデルは、状態機械モデルが実行中に前の状態に戻り得るように、状態アクティビティ振る舞いにおける前の状態、または状態アクティビティ振る舞いにおける前の状態数を格納し得る。
図11Aは、一実施形態における統合状態遷移表1102の表示(例えば、データ構造1102の表示)を図示する。表1102は、状態機械モデルの遷移元状態の名称を格納する縦のフィールド列1104を含む。遷移元状態フィールドごとに、表1102は、1または複数のセル1106も含んでもよい。前述の表402の場合と同様に、セル1106は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。一実施形態では、統合状態遷移表1102は、例えば、セル1106内のアクションフィールドを除外し得る。
表1102の表示は行インデックス(例えばR1〜R3)の列1120を含む。表1102の各行は異なる行インデックスと関連付けられ、行インデックスは1から開始し、毎行1ずつ増加し得る。例えば、3行ではなく10行あった場合には、行インデックスはR1から開始しR10まで続き得る。xが行数であるS1〜Sxといった他の行インデックスが使用され得る。
表1102の表示は、列インデックス(A〜B)の行1122を含む。表1102の各列は異なる列インデックスと関連付けられ、列インデックスはAから開始するが、毎列1ずつ英字インデックスを増加し得る。例えば、2列ではなく10列あった場合には、列インデックスはAから開始してJ(10番目の文字)まで続き得る。yが列数であるC1〜Cyといった他の列インデックスが使用され得る。
図11A、セル1106‐1に示すように、遷移先は、遷移先状態の名称(例えば「状態3」)ではなく、またはこれに加えて行インデックス(例えば「R3」)の参照によって規定され得る。この実施形態では、行インデックスは、表1102のデータ構造におけるアドレスを規定する。一実施形態では、遷移先状態は、表1102内のセルの絶対位置によって(例えば絶対行インデックスを規定することによって)特定され得る。例えば、セル1106‐2は、遷移先状態を「$R3」として規定している。この実施形態でも、絶対行インデックスは、表1102のデータ構造におけるアドレスを規定している。
絶対行インデックスと非絶対行インデックスとの違いは、絶対行インデックスは、行が、挿入され、または表1102から削除される場合に自動的に更新され得ないことである。他方、非絶対行インデックスは、行が、挿入され、または表1102から削除される場合に、自動的に更新され得る。例えば、図11Bは、表1102’
(編集された情報を伴う表1102である)を図示する。インターフェース論理330は、「状態2」(図11Aの行インデックスR2と関連付けられた)と名付けられた遷移先状態と、「状態3」(図11Aの行インデックスR3と関連付けられた)と名付けられた遷移先状態との間の状態を入力するためのユーザからの入力を受理し得る。この場合には、新しい遷移元状態が「状態2_1」という名称と共に追加される。新しい状態の行インデックスは、状態2_1が表1102’の第3行であるため、R3である。「状態3」(図11Bの)という名称の遷移元状態は、表1102’の第4行になるため、R4の行インデックスと関連付けられる。状態3と名付けられた状態と関連付けられた行インデックスの変更により、セル1106‐1で特定された遷移先状態は、「R3」ではなく「R4」になるように更新される。しかし、セル1106‐2で特定された遷移先状態は、更新されず、$R3のままであり、「$」は、行インデックスが更新されるべきでないことを示している。表1102の絶対アドレスを示すために「$」以外のインジケータが使用されてもよい。
一実施形態では、行インデックス(および列インデックス)は、データ構造1102(表1102)自体に格納されなくてもよい。例えば、$R3への参照は、表1102が表1102にラベル「R3」を格納することなく第3行を記述し得る。同様に、列「A」への参照は、表1102がラベル「A」を格納することなく、第1列(列1120以外の)を記述し得る。
図12Aは、一実施形態における別の統合状態遷移表1202の表示を図示する。以下でより詳細に記述するように、表1202は、例えば、記述された状態機械モデルの実行中に実行されないモデルの部分をユーザに伝えるようなやり方で表示され得る。表402と同様に、表1202は、状態機械モデルの遷移元状態を格納する縦のフィールド列1204を含む。遷移元状態フィールドごとに、表1202は、1または複数のセル1206も含んでもよい。セル1206は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。
シミュレーションエンジン370は、表1202によって記述された状態機械モデルを実行し得る。一実施形態では、前述のように、表1202内の情報は実行可能なコードに変換され得る。コードの実行中に、シミュレーションエンジン370は、例えば、表1202によって記述される状態機械モデルのあらゆる可能な状態または結果をシミュレートするように、異なる入力変数をシミュレートし得る。さらに、コードの実行中に、シミュレーションエンジン370は、コードのどの部分(例えばどんな条件)が実行されず、または一度も満たされることがないのかを判定し得る。これらの結果は多種多様なやり方でユーザに表示され得る。例えば、セル1206‐1によって特定される条件が一度も満たされることがなく、および/またはアクションが一度も実行されない場合には、これは図12Aに示されるように強調表示され得る。言い換えると、表1202の表示は、モデルの実行の「範囲」を示し得る。当該範囲の表示は、ユーザが表1202によって記述される状態機械モデルをデバッグすることに役立つ。図12Aには統合状態遷移表が示されているが、当該範囲は、状態‐状態遷移表(例えば図1Aに示されるような)または状態‐条件遷移表(例えば図1Bに示されるような)を伴うなどのように、他の表形式で表示され得る。よって、一度も実行されないアクションまたは一度も満たされることがない条件を特定する条件フィールドは、図12Aに示されるように表示され得る。
さらに、図12Bに示されるように、当該範囲は、コードジェネレータ390によって生成されたコンピュータコードにおいて表示され得る。図12Bは、一度も実行されないコード(例えば、条件を特定する)または一度も満たされることがない条件を特定している(例えば強調表示する)。さらに、図12Cに示されるように、当該範囲は、表1202に格納された情報から生成された状態図において表示され得る。図12Cは、状態機械モデルにおいて一度も実行されないコードまたは一度も満たされることがなかった条件を強調表示している。当該範囲は、任意のコード(例えば、コードジェネレータ390によって生成されたものではなくユーザによって直接的に入力されたコード)について表示され得る。
図12A、図12B、および図12Cでは、一度も実行されないコードまたは一度も満たされなかった条件が、強調表示といった技法を用いて特定され得る。強調表示は、予め決定される図形または色(赤など)で条件を強調表示することを含んでもよい。代替として、または加えて、一度も実行されない、または一度も満たされることがない条件を強調表示するのではなく、実際に実行されるコードおよび実行中に満たされる条件が強調表示されてもよい。この場合もやはり、実行されるコード(例えば、満たされる条件)は、予め決定される図形または色(緑など)で強調表示され得る。一度も実行されないコードまたは一度も満たされることがない条件に関する情報も、例えば、テキスト形式のレポートとして記録され得る。
別の実施形態では、一度も実行されないアクションを特定するアクションフィールドも強調表示され得る。別の実施形態では、状態機械モデルは、セルの行および列を伴う表として図12Aに示されるように状態機械モデルの実行中に表示され得る。この実施形態では、現在実行されているセルが強調表示され得る。別の実施形態では、現在の状態が時間の関数として表示され得る。例えば、図12Dは、表1202によって記述される状態機械モデルの実行中の時間の関数(例えば折れ線グラフにおける)として現在の状態を図示する。一実施形態では、状態機械モデルの実行は、ユーザによって特定される任意の時点において停止され得る。停止される場合、状態機械の実行がユーザによって特定された時点に停止されるときは、現在の状態および変数の値がユーザに示されてもよい。この実施形態では、ユーザは、対象となるコードのラインに沿った表のセルに直接的に中断点を入れることによって、遷移表をデバッグし得る。ユーザは、特定の状態の入場点で、特定の状態からの退場点で、アクションが取られる場合、および/または遷移条件が満たされる場合に、中断点を規定し得る。
一実施形態では、複数の状態機械モデル(例えば並列状態の)は一度に実行し得る。この場合、異なる並列状態(例えば状態_Aおよび状態_B)は相互にメッセージを送り得る。図12Eは、状態機械モデル(状態_Aとして特定された)および状態機械モデル(状態_Bとして特定された)の実行中の時間の関数(例えば折れ線グラフにおける)として現在の状態を図示する。この場合、状態_Aは、状態0、状態1、および状態2という子状態を含む。状態_Bは、状態A、状態B、および状態Cという子状態を含む。状態_Aのグラフは子状態を時間の関数として示している。状態_Bのグラフは子状態を時間の関数として示している。さらに、状態_Aと状態_B(親状態)との間で送られるメッセージは、EおよびFとして図示され、および/または記録される。
図12Dに示されるグラフのように、折れ線グラフで現在の状態を表示するのではなく、現在の状態は、状態名の横に色を示すことによってアニメーション表示され得る。例えば、図12Fは、状態機械モデルの実行中のアニメーションを図示する。図12Fは、状態を記載した列1204を含む。状態機械モデルの実行中に、現在の状態の横のセルは強調表示され得る。例えば、図12Fに示されている現在の状態は状態2(図12Fにおいて濃いグレーで強調表示された)である。前の状態(例えば状態3)は、異なる色または異なる濃淡(図12Fにおいて中間のグレーで強調表示された)で示され得る。前の前の状態(例えば状態1)は、異なる色または異なる濃淡(図12Fにおいて薄いグレーで強調表示された)で示され得る。
前述のように、シミュレーションエンジン370は、一度も実行されない条件または一度も満たされない条件を特定する条件フィールドを判定し、記録し、および強調表示するためにモデルを実行し得る。一実施形態では、コードジェネレータ390は、一度も実行されないアクション、一度も満たされなかった条件、および/または一度も到達しなかった状態を特定するためのコードを生成しない。この実施形態では、例えば、コードを生成することなく、状態機械モデルが解釈され得る(例えば、解釈済み実行および/またはシミュレーション)。別の実施形態では、到達不能な状態(一度も実行されない条件または一度も満たされなかった条件を含んでもよい)は、状態機械モデルを実行するのではなく状態機械モデルを記述する情報のパース(例えばパースエンジン)に基づいて判定され得る。例えば、パース論理は、ある状態に到達するための条件が一度も真にならない、または特定された状態が一度も到達されないと判定し得る。この場合、これらの状態は、図12A〜図12Fで記述したように強調表示され得る。
一実施形態では、状態機械モデルのパースに基づいて、満たされ得ない条件を含む条件フィールドが、記録され、または表示され得る。別の実施形態では、状態機械モデルのパースに基づいて、どの遷移元状態も特定の遷移先状態を遷移先状態として規定していないと判定することによって、当該特定の遷移先状態が到達不能であることが判定され得る。さらに、パースエンジンは、特定の遷移先状態を規定する各遷移元状態が、その特定の状態に遷移するための、満たされ得ない条件を含むと判定することによって、特定の遷移先状態が到達不能であると判定し得る。別の実施形態では、パースエンジンは、遷移元状態が、2つの異なる状態に遷移するための、同時に真となりうる2つの条件を含むと判定し得る。そうした状況は、表示され、または記録され得る。
一実施形態では、表1202(および、例えば、表402といった他の表)に示される条件フィールドは変数を含んでもよい。各変数の型およびサイズは推測され得る(例えば、整数、行列、行列サイズなど)。前述のように、状態機械モデルの実行のために、状態機械モデルに基づいてコンピュータコードが生成され得る。さらに、生成されたコードは、ユーザによって特定される、人間が読取り可能な方式で自動的にフォーマットされ得る。コンピュータコードは、C、C++、C#、PLC(programmable logic controller)言語、HDL、Ada、Java、および/またはMATLAB(登録商標)といったコンピュータ言語のものを含んでもよい。
図13Aは、一実施形態における状態機械モデルを記述する例示的な統合状態遷移表1302の表示を図示する。表1302は、状態機械モデルの遷移元状態を格納する縦のフィールド列1304を含む。遷移元状態フィールドごとに、表1302は、1または複数のセル1306も含んでもよい。セル1306は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を記述する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを記述するアクションフィールドを含んでもよい。一実施形態では、統合状態遷移表1302は、例えば、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。さらに、一実施形態では、表1302内の1または複数のセル1306が、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。例えば、表1302は、条件が満たされるが、状態機械モデルが異なる状態に遷移しない(例えば、遷移先フィールドで遷移先を規定していない)場合に取られるアクションを規定し得る。一実施形態では、対応する条件が満たされ、遷移が行われる場合に、状態機械モデルによってアクションが取られ得る。
図13Aに示されるように、表1302は、ある状態を「連結点1」として特定している。連結点は、例えば、連結点名を特定するフィールドを取り囲む角丸を表示することによって、他の状態と区別される。連結点は、状態機械モデルがとどまらず、即座に別の状態に遷移する特定のタイプの状態とみなされ得る。言い換えると、連結点は、別の状態に退場するための1または複数の条件を特定する。例えば、表1302の連結点1は2つの条件、すなわち、u>0およびu≦0を特定している。連結点1の2つの条件のうちの1つは常に満たされ、状態機械モデルは、表1302に記載されるように、状態1または状態2に遷移する。言い換えると、連結点状態は、状態機械モデルが遷移先状態のうちの1つに遷移し、その連結点状態に止まらないことを保証する1または複数の条件と関連付けられる。
一実施形態では、状態遷移表は、状態機械モデルがそこで開始すべき状態であるデフォルト状態を含んでもよい。この実施形態では、デフォルト状態は連結点状態であってよい。図13Bは、状態機械モデルが実行される場合に最初に実行されるデフォルト状態(「デフォルト遷移行」)を含む統合状態遷移表1342を図示する。この例では、遷移元状態1304をリストする遷移表の列にリストされる最初の状態(例えば最上段の状態)は連結点状態であってもよい。パースエンジンは、状態機械モデルが連結点状態にとどまらないように条件のうちの1つが常に満たされることを保証し得る。この例では、シミュレーションエンジン370は状態機械モデルを実行し得て、連結点は実行される最初の状態である。図13Cは、「デフォルト」と名付けられた連結点を伴う遷移表1342に対応する状態図を図示する。図13Cには、楕円形の状態が示されており、遷移は状態間の矢印で示されている。条件は、遷移を表す関連付けられた矢印の横に示されている。条件は、対応するアクションおよびトランザクションの横の括弧内に示されている。この場合、状態機械モデルは、デフォルト状態(例えば、遷移表1342に記載された最初の状態)に入ることによって実行を開始し得る。状態機械モデルは、次いで、状態「状態1」または状態「状態2」のどちらかに即座に遷移し得る。よって、この実施形態では、ユーザは、状態機械モデルが実行を開始し次第、どちらの状態に入るべきか(例えば状態1かそれとも状態2か)を条件によって選択し得る。この実施形態では、条件は、遷移表1342で規定されるように左から右に実行され得る。
前述のように、シミュレーションエンジン370は、統合状態遷移表といった状態遷移表によって記述される状態機械モデルを実行し得る。シミュレーションエンジン370は、2つの異なる状態間の接続性を測定し得る。例えば、状態機械モデルの実行中に、状態S1にある場合に、状態S3に遷移する可能性が非常に高いときには、状態S1と状態S3との間には高い接続性が存在するはずである。他方、例えば、状態機械モデルが実際に状態S2から状態S1に一度も遷移しなかった場合には、状態S2と状態S1との間の接続性は非常に低くなるはずである。これらの例では、接続性は方向を有していてもよい。すなわち、状態S3と状態S2との間の接続性は、状態S2と状態S3との間の接続性(例えば反対方向の)と同じでなくてよい。状態間の接続性は記録され得る。
一実施形態では、ユーザは、状態図ビュー1322と状態遷移表1342ビューとを切り換え得る。一実施形態では、インターフェース論理330は、表1302が編集され生成される際に、統合状態遷移表1302から状態図1322を自動的に生成し得る(例えばバックグラウンドプロセスとして)。さらに、ユーザはまた、状態遷移表1342に格納された情報を、例えば、状態‐状態遷移表(例えば前に図5Aで示され、記述されたような)として、状態‐条件遷移表(例えば前に図6Aで示され、記述されたような)として、状態‐アクション遷移表(例えば前に図7Aで示され、記述されたような)として格納し得る。
ユーザは、任意のビュー(例えば状態図1322)として情報を編集し得て、編集された情報を、統合状態遷移表(例えば統合状態遷移表1302などの)に記録し得る。例えば、ユーザは、状態図1322の状態の名称を編集し得て、編集は、表1342において反映され得る。例えば、ユーザが状態図1322の楕円内の状態「状態1」の名称を「状態A」に変更した場合には、この名称は、表1342の列1304、セル1306‐1、セル1306‐2、およびセル1306‐3でも変更されるはずである。ユーザは、状態図1322に示される条件および状態図1322に示されるアクションも編集し得て、そうした編集は表1342で反映されることになる。ユーザはまた、ある楕円から別の楕円へ矢印を移動させることによって遷移先状態を変更し得る。この場合もやはり、そうした編集は表1342において反映され得るはずである。
図13Aは、連結点を、状態機械モデルで実行される最初の状態として特定している。他の実施形態では、連結点は、最初の状態以外の状態機械モデルの他の部分で出現してもよい。
図14に示されるように、状態間の接続性は、接続性表1402で表示され得る。一実施形態では、異なる色または濃淡を使用して異なる接続性を示し得る。接続性はまた、例えば、0から10までの数字で表現され得る。表1402は、遷移元状態をリストする縦の列1404、および遷移先状態をリストする横の列1406を含む。任意の遷移元状態と任意の遷移先状態との接続性は、遷移元状態と遷移先状態との交点に(例えば対応するセルに)示され得る。接続性は、例えば、表示され、または記録され得る。
一実施形態では、接続性は、対応する遷移元状態と対応する遷移先状態との間の、状態機械モデルの実行中の異なる経路の数に基づき得る。別の実施形態では、接続性は、対応する遷移元状態と対応する遷移先状態との間の、状態機械モデルの実行中の各経路に沿った状態の数に基づいてもよい。
図15Aは、2つの退場連結点を伴う状態機械モデルを記述する統合状態遷移表1502を図示する。特に、表1502は、「状態B」と呼ばれる状態機械モデルを記述している。表1502は、状態機械モデルの遷移元状態を格納する縦のフィールド列1504を含む。遷移元状態フィールドごとに、表1502は、1または複数のセル1506を含んでもよい。セル1506は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件の場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;満たされた場合、および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。表1502は、図15Bに示される状態図1522として表示され得る。
一実施形態では、統合状態遷移表1502は、例えば、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。さらに、一実施形態では、表1502内の1または複数のセル1506が、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。一実施形態では、条件フィールドはイベント(その発生時に条件が評価される)を規定し得る。この実施形態では、アクションフィールドは、対応するイベントが発生し、対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定し得る。便宜上、また理解しやすくするために、図15Aの例示的な実施形態では、遷移表1502内の条件フィールドがイベントを含まないものとみなされている。遷移先フィールドが省かれる場合には、デフォルトの遷移(例えば、隣接するセルの遷移先状態、テンプレート行内のセルの遷移先状態など)が発生し得る。
図15Aに示されるように、表1502は、ある状態を「デフォルト」として特定している。このデフォルト連結点は、図13A〜図13Cに関連して前に述べたように動作し得る。表1502のデフォルト連結点はまた、点を囲む円といった図記号1505によって指定され得る。表1502はさらに、退場点として2つの状態を特定している。一方の退場点は「ノーマル退場点」とラベル付けされ、例えば、エラーなしでの状態Bからの退場点を指定する。他方の退場点は「フォールト退場点」とラベル付けされ、フォールト状態Bからの退場点を指定する。表1502の退場点はまた、「X」を囲む円といった図記号1507によって指定され得る。
以下でさらに記述するように、退場連結点は、「状態B」と呼ばれる状態機械モデルのインスタンス(表1502によって記述される)が別の状態機械モデルに埋め込まれることを可能にし得る。退場連結点は、例えば、連結点名を特定するフィールドを取り囲む角丸を表示することによって、他の状態と区別され得る。退場連結点は、状態機械モデルがとどまらず、即座に、この場合には、表1502によって記述される状態機械モデルから遷移して退場する特定のタイプの状態とみなされ得る。表1502によって記述される状態機械モデルを退場する場合に、退場点の名称(例えばラベル名)(ノーマル退場点やフォールト退場点など)は、例えば条件としての評価のためにその親状態に渡される。
図15Cは、別の状態機械モデルのインスタンスを呼び出す状態機械モデルを記述する統合状態遷移表1542を図示する。特に、表1502は、「状態B」と呼ばれる状態機械モデルを記述し、呼び出している。表1542は、状態機械モデルの遷移元状態の名称を格納する縦のフィールド列1544を含む。遷移元状態フィールドごとに、表1542は、1または複数のセル1546も含んでもよい。セル1546は、満たされる場合に、状態機械モデルが対応する遷移元状態から遷移先状態に遷移する条件を特定する条件フィールド;対応する条件が満たされた場合に状態機械モデルが遷移すべき遷移先状態を特定する遷移先フィールド;および対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定するアクションフィールドを含んでもよい。
一実施形態では、統合状態遷移表1542は、例えば、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。さらに、一実施形態では、表1542内の1または複数のセル1546が、アクションフィールド、条件フィールド、および/または遷移先フィールドを除外し得る。一実施形態では、条件フィールドは、発生時に条件が評価されるイベントを規定し得る。この実施形態では、アクションフィールドは、対応するイベントが発生し、対応する条件が満たされた場合に状態機械モデルによって取られるべきアクションを特定し得る。便宜上、また理解しやすくするために、図15Aの例示的な実施形態では、遷移表1542内の条件フィールドがイベントを含まないものとみなされている。遷移先フィールドが省かれる場合には、デフォルトの遷移(例えば、隣接するセルの遷移先状態、テンプレート行内のセルの遷移先状態など)が発生し得る。
表1542は、表1502によって記述される状態Bのインスタンスである遷移元状態「状態B’」を記述している。表1542は、やはり表1502によって特定される状態Bのインスタンスである遷移元状態「状態B’’」も特定している。状態「状態B’」および状態「状態B’’」は、それぞれ「親」状態とみなされ得て、それぞれ独自の「子遷移表」を伴う。その結果、状態図1562は、図15Dに示されるように、状態「状態B’」および状態「状態B’’」を有する。
しかし、状態「状態B」の各インスタンスは、デフォルトの遷移状態に影響を及ぼす異なる変数で開始され得る。さらに、状態「状態B」の各インスタンスは、その「親」において、終了し、異なる状態に遷移し得る。例えば、「状態B’」と呼ばれる状態「状態B」のインスタンスは、子状態からの退場連結点がノーマル退場点である(セル1546‐1)場合に、状態「状態1」に遷移する。さらに、「状態B’」と呼ばれる状態Bのインスタンスは、子状態からの退場連結点がフォールト退場点である(セル1546‐2)場合に、状態フォールトハンドラに遷移する。「状態B’’」と呼ばれる状態「状態B」のインスタンスは、子状態からの退場連結点がノーマル退場点である(セル1546‐3)場合に、状態「状態1」に遷移する。さらに、「状態B’’」と呼ばれる状態Bのインスタンスは、子状態からの退場連結点がフォールト退場点である(セル1546‐4)場合に、状態フォールトハンドラに遷移する。「子」から退場する場合に異なる遷移を特定することは、セル1546‐1およびセル1546‐2に起因する。例えば、セル1546‐1は遷移先状態「状態0」を特定し、セル1546‐2は遷移先状態「状態A」を特定する。図15Eは、表1542に埋め込まれた表1502を伴う表1542の表示の1つのやり方を図示する。表1542の下部分は、都合上、図示されていない。
実行中に、状態機械モデルが状態「状態0」にあるときに、状態「状態B’」への(例えば、状態「状態1」または状態「状態2」のいずれかへの)遷移は、状態機械モデルが親状態から子状態(例えば、内部状態「状態1」に、または内部状態「状態2」に)遷移するため、「内部遷移」とみなされ得る。この例では、状態「状態1」および状態「状態2」は「内部状態」または「下位状態」とみなされ得て、状態「状態B’」および状態「状態B’’」は「上位状態」とみなされ得る。状態遷移表の階層は図15Dおよび図15Eに示されており、各図において状態「状態B’」および状態「状態B’’」は、状態「状態0」および状態「状態A」を含む状態機械モデルより下位の階層にある状態機械モデルである。
一実施形態では、退場連結点の代わりに、例えば、遷移表によって記述される「子」状態機械モデルの最後の状態は、その遷移先状態として「次」を規定し得る。この場合、次の状態は、「親」状態機械モデルでの次の状態、すなわち、子状態機械モデルの「おじ」であり得る。状態は「遷移元状態」または「遷移先状態」として記述されることもある。図13Cにおいて言及したように、例えば、「遷移先状態」はまた「遷移元状態」であってもよい。
一実施形態では、多参照状態または冗長な情報が状態図としてグラフで現れ得る。この実施形態では、多参照状態は、複数回、または重複して表示され得る。
本出願は、整理番号第0081‐0009号、「Generating a State Diagram」という見出しの、2013年2月15日に出願された、米国特許出願代13/XXX,XXX号明細書を参照により加える。
<結論>
本発明の例示的実施形態の以上の記述は例示および説明を提供するものであるが、網羅的であることも、本発明を開示通りの形態に限定することも意図するものではない。上記の教示に照らして変更および変形が可能であり、または本発明の実施により変更および変形を取得され得る。例えば、一連の動作が記述されているが、各動作の順番は、本発明の原理と整合性を有する他の実装形態において変更されてもよい。さらに、非依存の動作は並列に実行されてもよい。
加えて、本発明の原理と整合性を有する実装形態は、本発明の趣旨を逸脱することなく、各図に例示され、本明細書で記述されているもの以外の装置および構成を用いて実装され得る。具体的な展開および/または適用に応じて、装置および/または構成要素が、図2A、図2B、図2C、または図3の各実装形態に追加され、または各実装形態から削除され得る。さらに、開示の実装形態はいかなる特定のハードウェアの組み合わせにも限定されない。
さらに、本発明のいくつかの部分は、1または複数の機能を果たす「論理」として実装され得る。この論理は、配線論理、特定用途向け集積回路、フィールド・プログラマブル・ゲート・アレイ、マイクロプロセッサ、またはハードウェアとソフトウェアとの組み合わせといったハードウェアを含んでもよい。本発明の記述で使用されるいかなる要素、動作、または命令も、特に明示しない限り、本発明にとって必要不可欠であると解釈すべきではない。また、本明細書で使用する場合、冠詞の「a」は1または複数の項目を含むことが意図されている。さらに、「〜に基づく(based on)」という句は、本明細書で使用する場合、特に明示しない限り、「〜に少なくとも一部は基づく(based, at least in part, on」を意味する。
本明細書で使用する見出しおよび小見出しは、本明細書を小区分に分割することによって読みやすくするためのものである。これらの見出しおよび小見出しは、本発明の範囲を限定するものとしても、本発明の特徴を定義するものとしても解釈すべきではない。