(57)【要約】【課題】　システムモデルをシステムサブモデルへと自動的に分解する。【解決手段】　ダイナミックシステムのシステムモデル１を分解する為の方法４００であって、システムモデル１が複数の機能ブロックを有し、システムモデル１の修飾を設計者が行えるようにし、複数の別個の部分を有する修飾システムモデル１００を生じるステップ４１０と、前記各システムのサブモデルにある全ての重要なシステムレベル情報である、修飾システムモデル１００との一貫性を維持しながら、修飾システムモデル１００の前記複数の別個の部分のそれぞれについて修飾システムモデル１００から自動的にシステムサブモデルを生成するステップ４４０とを含んでなる方法を提供する。【選択図】　　　　図１
2004139599.tif 000002
【特許請求の範囲】
【請求項１】
　ダイナミックシステムのシステムモデルを分解する方法であって、
　該システムモデルが複数の機能ブロックを有し、該システムモデルの修飾を設計者が行えるようにし、複数の別個の部分を有する修飾システムモデルとなるようにするステップと、
　各システムのサブモデルの全ての重要なシステムレベル情報の、前記修飾システムモデルとの一貫性を維持しながら、前記修飾システムモデルの前記複数の別個の部分のそれぞれについて前記修飾システムモデルから自動的にシステムサブモデルを生成するステップと
を含んでなる方法。
【請求項２】
　設計者が、前記修飾システムモデルの前記複数の別個の部分の各々に関連付けられるターゲットプラットフォームを識別することができるようにするステップを更に含む請求項１に記載の方法。
【請求項３】
　設計者が識別する前記ターゲットプラットフォームの少なくとも１つが、前記ダイナミックシステムの実際の部品である請求項２に記載の方法。
【請求項４】
　少なくとも１つのシステムサブモデルからソフトウエアサブモデルを生成し、前記システムサブモデルに関連する前記ターゲットプラットフォーム上での実行に供するステップを更に含む請求項２に記載の方法。
【請求項５】
　前記ソフトウエアサブモデルが、コンポーネント・オブジェクト・モデル技術を用いて相互に通信を行うものである請求項４に記載の方法。
【請求項６】
　前記自動的に生成するステップを記述するシステム情報ファイルを生成するステップを更に含む請求項４に記載の方法。
【請求項７】
　前記修飾システムモデルから、前記ダイナミックシステムの前記システムサブモデルにより表される実際の部品へのマッピングを、前記システム情報ファイルが提供するものである請求項６に記載の方法。
【請求項８】
　前記ソフトウエアサブモデルの各々を、後の実行に供する為にそれが関連するターゲットプラットフォームに伝送するステップを更に含み、前記伝送するステップが前記システム情報ファイルを利用するものである請求項６に記載の方法。
【請求項９】
　前記システム情報ファイルがＸＭＬフォーマットである請求項６に記載の方法。
【請求項１０】
　前記ターゲットプラットフォームを識別することができるようにするステップが、システム情報ブロックと、少なくとも１つのターゲット情報ブロックと、少なくとも１つの入出力ブロックとによって実現されるものである請求項２に記載の方法。
【請求項１１】
　前記自動的に生成するステップが、前記修飾システムモデルを確認するサブステップと、
　前記修飾システムモデルの実行順序を生成するサブステップと、
　前記修飾システムモデルをシステムサブモデルへと系統化する為に前記修飾システムモデルの各機能ブロックを解析するサブステップと、
　前記修飾システムモデルの各ターゲット情報ブロックについて、システムサブモデルを生成するサブステップと
を含む請求項１０に記載の方法。
【請求項１２】
　前記システムサブモデルを生成するステップが、
　新たなシステムサブモデルを作成するステップと、
　前記修飾システムモデルから重要なシステムレベル情報を前記新たなシステムサブモデルへと複写するステップと、
　前記修飾システムモデルから前記新たなシステムサブモデルへと、入出力ブロックを含む機能ブロックと前記新たなシステムサブモデルに関連する前記機能ブロックとの間の関連する相互接続を複写するステップと、
　前記新たなシステムサブモデルの前記入出力ブロックを更新することにより前記入出力ブロックに関連する通信リンクの特質を反映させるステップと、
　前記修飾システムモデルの実行順序に対応する実行順序を前記新たなシステムサブモデルの前記機能ブロックに割り当てるステップと
を更に含む請求項１１に記載の方法。
【請求項１３】
　前記更新するステップが、
　前記新たなシステムサブモデルが他のシステムサブモデルと通信を行うものであるのか、または、前記ダイナミックシステムの実際の部品と通信を行うものであるのかに応じて、前記新たなシステムサブモデルの各入出力ブロックを入出力部品に代替するステップと、
　前記新たなシステムサブモデルの各入出力ブロックがデータソースであるのか、またはデータシンクであるのかを判定するステップと
を更に含む請求項１２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、自動的にダイナミックシステムモデルをサブモデルへと分解する為の方法に関する。
【背景技術】
【０００２】
　人の手により産み出されたダイナミックシステムは、その環境における状況変化に対して何らかの有益な方法で応答するものであるが、このようなシステムが効果的に対応することができなければならない状況が多様で無数に存在することから、設計者には大きな難題が突きつけられている。例えば、ある種のダイナミックシステムとして代表される電気および電子回路は、常に変化する入力信号に反応し、システムが作動する環境において何らかの好適な動作を生じさせる為にその入力信号に基づく出力信号を供給できなければならない。電気回路および電子回路は、電子レンジやパソコン等の日常民生品からハイテク軍事兵器まで、非常に多くのアプリケーションにおいて有益に利用されている。更にダイナミックシステムは、特定の有用な機能を実現するように書き込まれた何らかのソフトウエアをも含む。また、ダイナミックシステムは、電気的、ソフトウエア的、機械的、気力学的、もしくは化学的な原理、またはこれらの組み合わせ（これらを含むがこれらに限られない）に基づくものをも含みうる。
【０００３】
　ダイナミックシステムを設計するというタスクは、システムシミュレーション技術の絶え間ない発展により、大きく進歩してきた。このようなシミュレーションによれば、構築も維持も困難な高価なプロトタイプを用意する必要なくダイナミックシステム設計モデルの試験を最初に実施することが可能である。シミュレーションを通じ、想定し得るテスト条件群を使用して初期のシステムデザインを徹底的に作動させてみることができる。こうすることによりシステム設計者がこれらのテスト結果を利用してシステムのパフォーマンスを解析することができる。通常は、そのテスト結果に基づいた変更が加えられ、テストを再起動してその結果をもう一度解析し、その変更の良い効果または悪い効果が判断される。従って、シミュレーションを通じた被験装置の構築前の反復プロセスによりダイナミックシステムのデザインを改善することができ、その結果、より早く、より生産的なシステム開発ができるようになっている。
【０００４】
　このようなモデリング環境の具体例として、Ｍａｔｈｗｏｒｋｓ，Ｉｎｃ．によるＳｉｍｕｌｉｎｋ（登録商標）システム定義およびツールがある。図２に示したように、モデリング環境２１０により、システム設計者はダイナミックシステムが電気的なものであるのか、機械的なものであるのか、または、システム設計者が決定したシステムモデル１の処理特性であるのかを特定することができるものである。システムモデル１の一例を図１に示した。システムモデル１は、各々が何らかの識別可能なタスクをシステムモデル１内において実施する幾つかの機能ブロック２から構成されている。設計者は、各機能ブロック２を利用することにより、例えばディジタル信号プロセッサ（以下、「ＤＳＰ」とよぶ）上で実行されるソフトウエア、Ｗｉｎ３２演算システム上で起動するソフトウエア、またはＤ／Ａ変換器（ＤＡＣ）などの特殊用途向けハードウエア部品等の特定のターゲットとして実現されたシステムモデル１の識別可能部分を指定することができる。通常、システムモデル１により示したダイナミックシステムは、１つ以上の入力信号３および出力信号４（または集合的に外部変数）を使用することにより周囲環境と通信し、これに影響を及ぼす。システムモデル１の内部信号５により、機能ブロック２は通信可能となり、これによって機能ブロック２間の協調が実現し、ダイナミックシステムの全体的な機能が実行されるのである。例えばＳｉｍｕｌｉｎｋなどの多くのモデリング環境２１０も、階層的設計を許容するものであるが、これはシステムモデル１の各機能ブロック２が更にサブブロック（図示せず）から構成される場合があり、これらのサブブロックがその上位レベルブロック２に付随する様々な機能を提供することもある為である。
【０００５】
　更に、システムモデル１におけるいずれの機能ブロックも、モデリング環境２１０において通常は使用可能な事前定義の機能ブロック（例えば分化または統合機能ブロック）であっても、システム設計者がその挙動を指定することができる事後定義機能ブロックであっても良い。そのような事後定義ブロックは、「Ｓファンクション」という方式（ブロックの挙動をユーザまたは第三者が提供するソフトウエアにより定義することができるものであり、これはＣ言語とＡｄａとＦｏｒｔｒａｎとを含む複数の異なる言語で書くことができる）によりＳｉｍｕｌｉｎｋにおいて指定することができる。
【０００６】
　システムモデル１の各機能ブロック２（およびサブブロック）は、通常、特にその挙動がシステムモデル１における他の機能ブロック２に関連する場合においては、各機能ブロック２の作動挙動の定義を助ける関連する様々なタイミングパラメータおよびブロック優先順位を持っている。タイミングパラメータは、システムモデル１のシミュレーションにおいて、１つの入力の変化に呼応して、機能ブロック２（またはサブブロック）の出力が変化するまでにどれくらいの時間が必要かを示すものである。ブロック優先順位は、２つの機能ブロック２が同時に出力状態を変化させる可能性がある場合において、どちらの機能ブロック２（またはサブブロック）が先に出力状態変化を示すのかの判定を助けるものである。各機能ブロック２のタイミングパラメータおよびブロック優先順位は、共にシステムモデル１全体としての各機能ブロック２の実行順序を決定するものである。
【０００７】
　図２に示したように、Ｓｉｍｕｌｉｎｋ環境において指定されたシステムモデル１は、次にその同じ環境においてシステム設計者の提供する入力信号３を用いてシミュレーションすることができる。モデルの解析と、後の設計変更と、更なるシミュレーションとは、通常、全てＳｉｍｕｌｉｎｋツールの範囲において生じるものである。このプロセスを向上させる為に、Ｓｉｍｕｌｉｎｋは、提示されたシステムの挙動定義を助けるシステムモデル１の内部信号５へのアクセスを可能とするものである。より具体的には、内部信号５により設計者はシステムモデル１の動作をより詳しく洞察することができる。従って、これらの内部信号５へのアクセスにより、シミュレーションおよび解析プロセス全体をより効率化することができるのである。
【０００８】
　Ｍａｔｈｗｏｒｋｓ社の提供するＲｅａｌ−Ｔｉｍｅ　Ｗｏｒｋｓｈｏｐ（登録商標）（以下、「ＲＴＷ」とよぶ）などの関連コード生成ツール２２０は、元々、モデリング環境２１０において開発されたシステムモデル１を入力として受け、そのシステムモデルを表すソフトウエアモデル２３０であるコードを生成する。ソフトウエアモデル２３０は、Ｃ言語、Ａｄａ、その他を含む幾つかの異なるプログラミング言語のいずれか１つを使って生成することができる。そして、ソフトウエアモデル２３０が他のプラットフォームへと送られて実行されるが、このソフトウエアモデル２３０の実行は、プラットフォームの特性によってはリアルタイムで進行する場合もある。ソフトウエアシステムの場合には、プラットフォームがシステムを実現する為に最終的に用いられるターゲットプラットフォームであり得るため、システムモデル生成から製造レベルコードへのほぼシームレスな進行が提供される。
【０００９】
　多くのモデリング環境は、本質的に画一的で自由度のないモノリシックなシステムモデル１の生成しか許容していない。換言すると、設計者が指定した各システムモデル１は、モデリング環境においてはひとまとめにシミュレーションされた単一の存在として取り扱われるのである。更に、これらのシステムモデル１からコード生成ツール２２０という手段により生成されたソフトウエアモデル２３０は、同じ特性を呈するものでもある。しかしながら、今日開発されている多くのダイナミックシステムは、モノリシックでなない。即ち、このようなシステムは、各々が何らかの異なる機能を実行するハードウエアおよびソフトウエアといった異なる種類の混合により実現されている場合も多いのである。これらの様々な断片の集合的な作動により、最終的にモデルシステム１は所要される結果を実現することができるのである
　例えば、システムモデル１（図１に示したもの）の機能ブロック２の各々は、異なるハードウエア／ソフトウエアプラットフォーム上に実現されるべきシステム部分を表す場合がある。一例をあげると、機能ブロック１はＷｉｎ３２コンピュータシステム上で起動するソフトウエアとして、機能ブロック２は埋め込み型マイクロプロセッサシステム上で実行されるべきファームウエアとして、機能ブロック３はＤＳＰ上で実行されるソフトウエアとして実現されている。これらの機能ブロック２の各々を完全にシミュレーションする為に、システムの各区分に付随するサブモデルを異なるプラットフォームにより実現することが有利であるが、これは、シミュレーションが最終的なシステムに非常に近似した、複写でもあり得るプラットフォーム上で実行される可能性があるためである。更に、各々が異なるプラットフォームで起動する幾つかの「サブモデル」にシミュレーションを分割した場合にも、必要とされる処理が同時に起動する複数のプラットフォームにまたがって分散される為、より複雑なシミュレーションを加速することができる。かわりに、システム全体のテストをより正確に実施する為に、１つ以上のサブモデルを、その特定のサブモデルが表す電気モーター等の実際の部品に置き換えることもできる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
　現在、シミュレーションをこのような方法で強化する為には、システムモデル１の各機能ブロックク２等の異なるシステムサブモデルへとシステムモデル１を設計者が手動で分割しなければならない。そして、システムサブモデルの各々を使用してＲＴＷ等のコード生成ツールによるソフトウエアサブモデルを生成するものであり、それにより、その各々を異なるターゲットプラットフォーム上でシミュレーションすることができる。
【００１１】
　しかしながら、サブモデルを手動で生成する場合に幾つかの問題が発生する。
　第一に、システムモデルからの手動によるシステムサブモデルの生成処理により、元のシステムモデル１とサブモデルとの間に自動化された繋がりが全く存在しないことから、サブモデル中にエラーが導入されてしまう可能性があるという点である。
　第二に、異なるターゲットプラットフォーム上で起動する様々なサブモデル間に通信手段を提供する為に、各ソフトウエアサブモデルにカスタムソフトウエアを加えなければならないという点である。
【００１２】
　第三に、サブモデルの処理挙動の少なくとも一部は、システムの他の部分との相互作用により決定される為、サブモデル挙動に影響を及ぼすこれらのシステムレベル特性を各サブモデルの一部として捕捉することにより、これらのサブモデルがシステム全体の一部として適正に作動するようにしなければならない。例えば、設計者は、シミュレーションの１つの時間段階中にブロックが処理される実行順序を決めるタイミングパラメータとブロック優先順位の一貫性をソフトウエアサブモデルの各々が維持していることを保証しなければならない。そのようにしなければ、様々なソフトウエアサブモデルをまたぐシミュレーションは行き詰まり、これによりシミュレーションは成功・完了せずに停止してしまうことになる。更に、各サブモデルに提供されるデータタイプが他のシステム部分により決定される場合がある。従って、各サブモデルが適正なデータタイプを許容するように構成されていない限りにおいては、その入力データが誤訳される可能性がある為、適切なサブモデルの実行は望めないのである。これらの問題は、異なるシステムサブモデルがシステムモデル１全体としての環境において生成され、確認されたものではなく、手動で生成されたことに起因するものである。更に、システムモデル１において加えられた変更が先に生成されたシステムサブモデルにも、その逆方向にも反映されず、システムモデル１およびシステムサブモデルの両方の維持においては別の苦労の種となっている。
【００１３】
　よって、上述したように、システムモデルの別個のシステムサブモデルへと、システム設計者の意図する自動分解を提供する方法があれば有利である。そして、設計者の選択したターゲットプラットフォーム上での実行が可能なソフトウエアサブモデルを生成する為に各システムサブモデルを使用することができ、これにより、統合化したシステムのシミュレーションの精度および速度の両方を向上させることができる。
【課題を解決するための手段】
【００１４】
　以下に説明する本発明の実施例は、自動的にシステムモデルをシステムサブモデルへと分解することにより、そのモデルを複数の多岐にわたるターゲットプラットフォーム上で同時に発生させる為の方法を提供するものである。以下に説明するその方法の事前準備として、システム設計者は、各々がターゲットプラットフォーム上で実行されるべき特定のシステムサブモデルとなる別個の部分にシステムモデルを系統化し、これにより、本発明の実施例を通じて、どのシステムモデルの部分をサブモデルとするのかを設計者が指定することができる。任意選択的に、各サブモデルの実行に関連するターゲットプラットフォームを更にユーザが指定できるようにしても良い。そして、本発明の実施例により提供されるコードにより、設計者が指定した各部分のシステムサブモデルが生成され、タイミングパラメータやブロック優先順位などの重要なシステムレベル情報の全てがシステムモデル全体を通じて一貫して保持される。そして、これらのシステムサブモデルの各々を利用してソフトウエアサブモデルが生成され、これのソフトウエアサブモデルが適正なターゲットプラットフォームへと伝送されて実行される。かわりに、これらのシステムサブモデルが現している実際のシステム部品に１つ以上のシステムサブモデルを置き換えても良い。
【００１５】
　本発明の様々な実施例には幾つかの利点がある。システムサブモデルの生成が自動的に実施される為、システムサブモデルへと導入される危険性のある誤りが基本的に排除される。更に、各種サブモデル間での通信用にソフトウエアサブモデルに付加されなければならない全てのソフトウエアが自動的に生成される。また、システムモデルはシステムモデルを生成する為に直接的に利用される為、各サブモデル内の機能ブロック間とサブモデル間におけるタイミングパラメータおよびブロック優先順位の一貫性が維持され、これにより、デッドロックが回避される。更に、システムサブモデルはシステムモデルから自動的に生成される為、システムへの全ての変更をシステムモデルレベルのみに実施すれば良く、サブモデルへの変更は、システムサブモデルが構築される度に自動的に処置される。
【００１６】
　本発明の他の態様および利点は、以下の詳細な説明を、本発明の原理を例示した添付図と共に参照することにより明らかとなる。
【００１７】
　以下に説明する本発明の実施例は、開始点として上述したＭａｔｈｗｏｒｋｓ　Ｓｉｍｕｌｉｎｋ（登録商標）モデリング環境を利用したものである。しかしながら、本発明の他の実施例における基盤として他のシミュレーションモデル環境を同様の形式で採用することも可能である。
【００１８】
　更に、本発明の他の実施例におけるソフトウエアは、関連するモデリング環境との様々な統合化レベルにおいて実現することができる。例えば、他の実施例においては、モデリング環境とは別にインストールされた別個の後継ソフトウエアが含まれていても良い。本願において特定して説明するように、他の実施例は独自に開発されたものではあるが、しかしモデリング環境に統合化されたソフトウエアを含むものであっても良い。更に他の実施例は、モデリング環境の残りの部分から成る外部の観測要素から見た場合に区別し得ない程度の、高度に統合化されたコードを提供するものであっても良い。
【発明を実施するための最良の形態】
【００１９】
　図４は本発明の実施例の提供するステップ４００を統合化して示したものであるが、システム設計者または他のユーザにより実施されるステップを介在させて表したものである。本発明の実施例に直接的に関わるステップは、点線で囲んだブロックに示す。
【００２０】
　まず始めに、本発明の実施例は、設計者が定義した（図４のステップ４１０）モデルにおいて使用される分解機能ブロック６、７、８（図３）の集合を提供する。分解機能ブロック６、７、８は、通常、モデリング環境中のライブラリに常駐する事前定義、または第三者定義のブロックである。他の機能ブロックと同様に、分解機能ブロック６、７、８は、システム設計者による利用および変更が可能である。
【００２１】
　図４において、システム設計者はシステムモデル１（図１）に複数の分解機能ブロック６、７、８に加えることにより、またはこれらで「修飾」（decorate）することにより、システムモデル１を変更し、この結果、図３にその詳細を示す修飾システムモデル(decorated system model)１００が得られる。可能な分解ブロック６、７、８の各々は、通常、修飾システムモデル１００中にこのようなブロックを作成する段階において設計者へと提示される、関連するマスキングされたダイアログボックスを有している。このようなダイアログボックスは、各々に関連付けられた機能ブロックのカスタマイズを可能とするものである。
【００２２】
　分解機能ブロック６、７、８は、幾つかの異なるタイプのブロックから構成されているが、その各々は特定の目的を果たしている。例えば、実施例においては１つのシステム情報ブロック６が各修飾システムモデル１００に使用される。システム情報ブロック６は、後に生成される全てのシステムサブモデルに使用可能な、修飾システムモデル１００全体の名称または識別子のようなグローバルシステム情報を作る為に用いられる。設計者は、修飾システムモデル１００中におけるブロック生成時に設計者に提示される、これに関係するマスキングされたダイアログボックスという形式により情報を特定することができる。システム情報ブロック６は、通常、図３に示したように、修飾システムモデル１００の最上レベル表現中に位置する。システム情報ブロック６は修飾システムモデル１００の残りの部分とは「機能的」方式で作用し合わないことから、システム情報ブロック６はこれらのブロックへの、またはからの内部信号という手段により他のいずれの機能ブロックとも接続するものではない。
【００２３】
　提供される他のタイプの分解機能ブロックは、ターゲット情報ブロック７であり、そのうちの１つが各システムサブモデルの最上レベルに位置する。図３に示した修飾システムモデル１００の具体例においては、ターゲット情報ブロック７がそのモデルの最上レベル記述において使用されている。修飾システムモデル１００中には、ＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ１（Ｗｉｎ３２ターゲットプラットフォーム）、ＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ２（埋め込み型マイクロプロセッサターゲットプラットフォーム）およびＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ３（ディジタル信号プロセッサターゲットプラットフォーム）の各々に対応する３つの異なるシステムサブモデルが定義されていることから、全体において３つのターゲット情報ブロック７が使用されている。ＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ２およびＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ３は各々にターゲット情報ブロックを、各サブモデルの次に最も低い抽象化レベル（図示せず）において含んでいる。この特定の実施例においては、図３のターゲット情報ブロック７に示したように、図３に示した最上レベルの図が、この場合はＷｉｎ３２サブモデルの実際の最上レベルとして作用している為、ＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ１はその中に別個のターゲット情報ブロック７を含んでいない。従って、Ｗｉｎ３２サブモデルはＦＵＮＣＴＩＯＮＡＬ　ＢＬＯＣＫ１だけではなく、入力信号３、出力信号４およびその特定のサブモデルにおいてシミュレーションされる何らかのハードウエア機能をも組み込んでいるのである。各ターゲット情報ブロック７は、関連するダイアログボックスを持っているが、これは、提示された特定のシステムサブモデル、そのシステムサブモデルが関連する全体的なシステムモデルの識別、および得られたソフトウエアサブモデルが実行されることになる特定のターゲットプラットフォーム（Ｗｉｎ３２システム、ＤＳＰ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等々）の表示を設計者が指定できるようにするものである。ダイアログボックス中に「ＮＵＬＬ」ターゲットの表示があった場合には、実際のシステムの関連部品が分解シミュレーションモデル中のサブモデルの地位を取るものであることを意味する。各ターゲット情報ブロックについて得られた情報は、後に実施されるシステムサブモデルの生成中に使用する為に「テンプレートモデル」中に記憶される。
【００２４】
　設計者は、図３に示すように入出力（Ｉ／Ｏ）ブロック８を修飾システムモデル１００にも配置するが、これは様々なシステムサブモデルが相互に通信する為に使用することになる通信リンクの位置および性質を示している。各Ｉ／Ｏブロック８は、通常、Ｉ／Ｏシミュレーションコード（図示せず）およびＩ／Ｏ情報ブロック（図示せず）と共に入出力ポートを持つ単純なＩ／Ｏサブシステムを含んでいる。Ｉ／Ｏシミュレーションコードは、関連するサブモデルが完全なシステムレベルシミュレーションにおいて使用される場合に用いられる。Ｉ／Ｏ情報ブロックは、実際にそのＩ／Ｏを実現する為にはどのコード集合をそのサブモデルへとリンクさせるべきかを表示する。Ｉ／Ｏ情報ブロックにより選択されるコードは、他のサブモデルとのＩ／Ｏ通信を提供するコード、または他のサブモデルがそれを表す為に指定されている実際の部品との通信を提供するコードのいずれかでありうる。Ｉ／Ｏ情報ブロックに付随するのは、設計者が、どのＩ／Ｏ通信コード集合を用いるべきかを表示することを可能とするダイアログボックスである。Ｉ／Ｏ情報ブロックは、サブモデル相互通信用の入出力ポートの各々に関わるターゲットプラットフォームの情報も含みうる。かわりに、この情報はシステムサブモデルの実際の生成時に得られるようになっていても良く、これは、修飾システムモデル１００の各部分がその時点でターゲットプラットフォームに関連付けられる為である。図３に示した修飾システムモデル１００の具体例の場合には、サブモデル間の各通信リンクは、それに付随するＩ／Ｏブロック８を有している。
【００２５】
　システムサブモデルから得られたソフトウエアサブモデル間での通信に用いられるＩ／Ｏ技術は、コンピュータシステム内またはコンピュータシステム間に採用することが可能ないずれの通信リンクでありうる。例えば、Ｍｉｃｒｏｓｏｆｔ　Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）によるコンポーネント・オブジェクト・モデル（以下、「ＣＯＭ」とよぶ）技術を採用することができる。ＣＯＭは、異なるソフトウエア開発者が様々な言語で書いたソフトウエア「コンポーネンツ」、即ちソフトウエア部分の相互通信を可能とする、ソフトウエア・アーキテクチャ定義として広く使用されている。基本的にＣＯＭアーキテクチャは、異種ソフトウエアの統合化を容易にするものであり、これらのソフトウエアがどのように相互に通信を行うべきかを管理する枠組みを定義することにより、何らかの統合化機能を実施させるものである。Ｉ／Ｏ技術の他の選択肢としては、Ｍｉｃｒｏｓｏｆｔの「ＮＥＴ」を挙げることができるが、これはＣＯＭよりも包括的なインターフェース技術であり、ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ（以下、「ＸＭＬ」とよぶ）ウェブサービス群を採用してソフトウエア部分間の相互接続性を許容するものである。現在、メモリ共有Ｉ／Ｏ等、他にも多くのＩ／Ｏ技術が利用可能である。関連するサブモデルがシミュレーションされたシステムの実際の部品と通信する場合においては、使用されるＩ／Ｏとして、その部品へのインターフェースとして具体的に意図された特定ハードウエア向けデバイスドライバをあげることができる。
【００２６】
　Ｓｉｍｕｌｉｎｋに関連して開示した実施例においては、分解機能ブロック６、７、８は上述した「Ｓファンクション（S-function）」として実現されている。換言すると、分解機能ブロック６、７、８は、関連する分解機能ブロック６、７、８の機能性を記述し表現するソフトウエア部分という形で定義される。
【００２７】
　設計者が、修飾システムモデル１００を完成させた後に、そのプロセスを起動することにより様々なシステムサブモデルが自動的に生成される。実施例によれば、このプロセスは、モデリング環境２１０において提供された複数のソフトウエアスクリプトにより実施される。
【００２８】
　（図４におけるステップ４４０であり、図５により詳細に示される）分解プロセスは、修飾システムモデル１００がシステムサブモデルへと適正に分解可能であることの確認から開始される（ステップ５１０）。修飾システムモデルがこの確認で不合格となった場合には、分解プロセスは停止する。
【００２９】
　次に、修飾システムモデル１００の実行順序が生成される（ステップ５２０）。実行順序は、基本的に、修飾システムモデル１００の機能ブロックがシミュレーションの各時間ステップで実行されるという、逐次の順序である。実行順序は、上述したように、その修飾システムモデル１００に関連するタイミングパラメータおよびブロック優先順位のような重要なシステムレベル情報から生成される。実行順序の生成は、各システムサブモデルの様々な機能ブロックが適正な順序で確実に実行されるようにするには必要なものであり、これにより各種サブモデルが協調して実行される場合におけるデッドロックまたは他のタイミング問題が回避される。
【００３０】
　次に適正なシステムサブモデルへと系統化することができるように修飾システムモデル１００の機能ブロックの各々が解析される（ステップ５３０）。このステップにおいて使用される各Ｉ／Ｏブロック８は、それが関連する各サブモデルに割り当てられる。使用される各ターゲット情報ブロック７は、各サブモデルの最上ブロック、即ち「ルート」ブロックを表示する。
【００３１】
　そして、各ターゲット情報ブロック７を利用して、そのターゲット情報ブロック７用のシステムサブモデルが生成される。まず始めに、ターゲット情報ブロック７からのテンプレートモデル情報を用いてシステムサブモデルが作成される（ステップ５４０）。システム情報ブロック６中に記憶された情報も、新たなサブモデルにコピーすることにより修飾システムモデル１００へと遡って関連付けられる（ステップ５５０）。ルートブロックにある、そのサブモデル用の全てのブロックが、それらの関連相互接続と共に新たなサブモデルへとコピーされる（ステップ５６０）。そして、新たなサブモデルへとコピーされたいずれのＩ／Ｏブロック８も、関連する通信リンクの特性に関する適正な情報により更新される（ステップ５７０）。このステップには、各Ｉ／Ｏブロック８がデータシンクであるのか、またはデータソースであるのかが含まれる。Ｓｉｍｕｌｉｎｋのようなモデリング環境の殆どはシステムモデル中のあらゆる内部信号５のデータフロー方向を示すものである為、この情報は通常は修飾システムモデル１００から得ることが可能である。この更新ステップに更に含まれるのは、Ｉ／Ｏブロック８を通じて実際の部品との通信が行われているのか、または他のシステムサブモデルとの通信が行われているのかに関するＩ／Ｏブロック８中の情報に応じて実施されるＩ／Ｏ部品の代替処理である。最後に、サブモデル中の各ブロックに修飾システムモデル１００から生成された実行順序が割り当てられる（ステップ５８０）。
【００３２】
　各システムサブモデルが生成された後、システムモデルの様々なシステムサブモデルへの分解に関する情報を保持するシステム情報ファイルが生成される（図４のステップ４４０）。実施例においては、このシステム情報ファイルは、ＸＭＬフォーマットであるが、いずれの好適なデータフォーマットでも使用することができる。このファイル中の情報は、後に得られたソフトウエアサブモデルを、それらを要求するターゲットプラットフォームへとダウンロードする為に使用される。更に、時にシステムの「マニフェスト（manifest）」とも呼ばれるシステム情報ファイルは、モデリングの対象となった実際のシステムの構築を助ける情報を含む場合もある。例えば、この情報を電子部品の発注やソースコードのコンパイル等を補助する為に利用することができる。
【００３３】
　そして、システムサブモデルの各々は、各々に意図された特定のターゲットプラットフォームへと送られるべき関連のソフトウエアサブモデルの生成に用いられる（図４のステップ４５０）。このプロセスは、通常、本実施例においてはＭａｔｈｗｏｒｋｓ社のＲＴＷツールであるコード生成ツールにより実施されるものである。各システムサブモデルに関するテンプレートモデルからの情報がこのプロセスを助ける。コード生成の間、各ソフトウエアサブモデルに関する情報は、ＸＭＬシステム情報ファイルへと加えられる。
【００３４】
　設計者は任意の時点で各ソフトウエアサブモデルを適正なターゲットプラットフォームへと伝送することができ、この時点で各ソフトウエアサブモデルを実行することが可能となる。通常、モデリング環境２１０におけるサービスは、先にＸＭＬシステム情報ファイル中に記憶された情報の助けを借りてこのタスクを自動的に実施する。
【００３５】
　各種ソフトウエアサブモデルが適正なターゲットへと伝送されると、得られた分散システムモデル６００を図６に示したようにシミュレーション目的で実行することができる。図３の特定の修飾システムモデル１００を使用するが、３つのソフトウエアサブモデル６１０、６２０、６３０の各々が同時に実行され、各サブモデル６１０、６２０、６３０間の通信が、通信リンク６４０を通じて生じる。設計者によるターゲットプラットフォームの選択が適正である場合には、各サブモデル６１０、６２０、６３０の実行は、各サブモデルと選択されたターゲットプラットフォームと間の関係により、潜在的により効率化される。例えば、Ｗｉｎ３２サブモデル６１０は、実際のＷｉｎ３２コンピュータシステム上で最も良好にシミュレーションすることができる。一方、ＤＳＰソフトウエアサブモデル６３０は、実際のＤＳＰシステムまたはＤＳＰエミュレータ上で最も効率的に起動する可能性が高い。製造システムの一部分を実際に実現するか、または非常に近似させたターゲットプラットフォーム上で各々が起動する別個のサブモデルへとシステムモデルを分解することにより、結果的に得られるシステムレベルのシミュレーションは、通常の作動条件下で生じる事柄をよりうまく表すことができる可能性が高い。
【００３６】
　上述したように、潜在的なターゲットプラットフォームとして上げられる他の例はＦＰＧＡである。ＦＰＧＡは、マイクロプロセッサの何倍もの速度で多数の演算を実行することができるものである。この結果、ＦＰＧＡは特に実際の通信システムおよびシミュレーションした通信システムのようなＤＳＰアプリケーションに好適であると言え、結果的に他の選択肢よりも大幅に高いパフォーマンスを提供することができる。
【００３７】
　更に、得られたシステムシミュレーションは複数のプラットフォーム上で実行される為、ターゲットプラットフォーム間で同時に発生するシミュレーション処理量により全体的なシミュレーション時間を大幅に短縮することができ、これにより潜在的な全体のシミュレーション時間を縮め、実際のダイナミックシステムが市場に出るまでの時間を改善することができる。
【００３８】
　先にも述べたように、１つ以上のシステムサブモデルを、シミュレーションされているダイナミックシステムにおいて最終的に使用されることになる実際の部品に置き換えることが可能である。このようなサブモデルの実際の部品への置き換えは、システム全体のシミュレーションにおける総合的な精度および効率を更に強化するものである。
【００３９】
　上述から、先に説明した本発明の実施例が、全体的なダイナミックシステムモデルを個々のシステムサブモデルへと自動的に分解する方法を提供するものであることが示された。更に、本発明を実現する他の特定のシステムおよび方法も可能である。よって本発明は本願に記載および図示した特定の形式に限られたものではなく、請求項によってのみ限定されるものである。
【図面の簡単な説明】
【００４０】
【図１】Ｓｉｍｕｌｉｎｋモデリング環境およびその他のモデリング環境において表すことができるシステムモデルのブロック図である。
【図２】ダイナミックシステムのシステムモデルおよびソフトウエアモデルを開発する従来の方法を説明するフローチャートである。
【図３】本発明の一実施例に基づいて設計者が修飾した図１のシステムモデルのブロック図である。
【図４】システムモデルを生成し、このシステムモデルを関連するシステムサブモデルおよびソフトウエアサブモデルへと分解する統合化処理の全体を説明するフローチャートである。
【図５】図４に示したように、修飾システムモデルから個々のシステムサブモデルを自動的に生成する本発明の一実施例に基づく方法のフローチャートである。
【図６】図３の修飾システムモデルから生成されたソフトウエアサブモデル群が様々なターゲットプラットフォーム上で実行される場合の相互関係を示す概略ブロック図である。
【符号の説明】
【００４１】
　１　システムモデル
　１００　修飾システムモデル
【図１】
2004139599.tif 000003
【図２】
2004139599.tif 000004
【図３】
2004139599.tif 000005
【図４】
2004139599.tif 000006
【図５】
2004139599.tif 000007
【図６】
2004139599.tif 000008