(57)【特許請求の範囲】
【請求項１】
プロセッサ、アクラセレータ、またはコントローラを含む、バス・マスタがメモリにアクセスし得るシステムにおいて、シミュレーション・モデルが表しているプログラムの動作時に、前記バス・マスタによるメモリ・アクセス競合を評価する方法であって、
前記シミュレーション・モデルについて、シミュレーション・ステップ毎の実行時間及びメモリ・アクセス回数を、前記異なるバス・マスタ毎に測定し、あるいは測定値を事前に用意するステップと、
前記実行時間及びメモリ・アクセス回数の値を用いて、メモリ帯域の利用率を、前記異なるバス・マスタ毎に計算するステップと、
前記異なるバス・マスタ毎のメモリ帯域の利用率の積を含む式により、前記異なるバス・マスタの間のメモリ・アクセス競合の確率を計算するステップを有する、
メモリ・アクセス競合の確率を評価する方法。
【請求項２】
前記計算されたメモリ・アクセス競合の確率に基づき、メモリ・アクセス競合の結果の実行時間を評価するステップをさらに有する、請求項１に記載の方法。
【請求項３】
シミュレーション・ステップ毎の前記メモリ帯域の利用率Uは、
Tをステップ時間、
Nrを読取りアクセスの回数、
Nwを書込みアクセスの回数、
Wrを単位時間毎に利用可能な読取りアクセスの最大数、
Wwを単位時間毎に利用可能な書込みアクセスの最大数とすると、
U = (Nr/Wr)T + (Nw/Ww)/Tで計算される、請求項１に記載の方法。
【請求項４】
プロセッサ、アクラセレータ、またはコントローラを含む、バス・マスタがメモリにアクセスし得るコンピュータ・システムにおいて、シミュレーション・モデルが表しているプログラムの動作時に、前記バス・マスタによるメモリ・アクセス競合を評価するプログラムであって、
前記コンピュータ・システムに、
前記シミュレーション・モデルについて、シミュレーション・ステップ毎の実行時間及びメモリ・アクセス回数を、前記異なるバス・マスタ毎に測定し、あるいは測定値を事前に用意するステップと、
前記実行時間及びメモリ・アクセス回数の値を用いて、メモリ帯域の利用率を、前記異なるバス・マスタ毎に計算するステップと、
前記異なるバス・マスタ毎のメモリ帯域の利用率の積を含む式により、前記異なるバス・マスタの間のメモリ・アクセス競合の確率を計算するステップを実行させる、
メモリ・アクセス競合の確率を評価するプログラム。
【請求項５】
前記計算されたメモリ・アクセス競合の確率に基づき、メモリ・アクセス競合の結果の実行時間を評価するステップをさらに有する、請求項４に記載のプログラム。
【請求項６】
シミュレーション・ステップ毎の前記メモリ帯域の利用率Uは、
Tをステップ時間、
Nrを読取りアクセスの回数、
Nwを書込みアクセスの回数、
Wrを単位時間毎に利用可能な読取りアクセスの最大数、
Wwを単位時間毎に利用可能な書込みアクセスの最大数とすると、
U = (Nr/Wr)T + (Nw/Ww)/Tで計算される、請求項４に記載のプログラム。
【請求項７】
アプリケーションと、プロセッサ及びメモリをもち該アプリケーションを実行するためのプラットフォームと、メモリ・アクセス検出モジュールと、ステップ開始／終了検出モジュールを有する組込みシステムの性能をシミュレーションするための計算を行うプログラムであって、
前記メモリ・アクセス検出モジュールと前記ステップ開始／終了検出モジュールから出力されたデータに基づき、請求項４に記載のプログラムを用いて計算するステップを有する、シミュレーション・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、シミュレーション・モデルなどによって表されたプログラムの動作推測技法に関し、特に、メモリ・アクセス競合を推測する方法及びプログラムに関するものである。
【背景技術】
【０００２】
近年、組込みシステムのプログラム開発の設計工程において、MATLAB(R)/Simulink(R)、ＵＭＬ(Unified Modeling Language)、ＳｙｓＭＬ(Systems Modeling Language)などを用いたモデリングやシミュレーションが頻繁に行われている。
【０００３】
一方、開発されたプログラムは、所定のコンピュータのハードウェアで実行され、性能がテストされることになる。最近では、マルチコアのＣＰＵが一般的になりつつあるので、並列実行による速度向上なども考慮して、マルチコアのＣＰＵをもつコンピュータを、シミュレーションするニーズが高まっている。
【０００４】
ところが、マルチコアのＣＰＵをもつコンピュータでは、各々のコアがバスを介してメモリにアクセスするので、メモリ・アクセス競合の問題が生じ、それはまた、プログラムの実行時間に影響を及ぼす。
【０００５】
組込みシステムの設計の初期開発段階において、設計の自由度は膨大である。例えば、３個のソフトウェア・コンポーネントを、２つのコアと、３つのメモリ領域に割り当てるのにも、２１６通りのパターンがあり、詳細な設計段階に入る前に、粗い性能測定で、妥当でない組み合わせは排除しておくことが重要である。
【０００６】
しかし、既存の性能評価方法は、システム・アーキテクチャの設計フェーズでメモリ・アクセス競合を測定するには相応しくない。
【０００７】
例えば、キューイング・ネットワーク・モデルのような抽象的な数学的な技法は、状態遷移などのアプリケーションの振る舞いを記述するのが困難であり、実行毎の実行時間を生成することができず、主として統計的な目的に用いられる。
【０００８】
その他の技法としては、SystemC、または命令セット・シミュレータ（ＩＳＳ）などの細粒ステップ・シミュレーション技法だと、メモリ・アクセスの正確なタイミングを必要とし、そのようなデータを設計の初期段階で集めるのはコストが大きく、また、シミュレーションに時間がかかりすぎるという問題がある。
【０００９】
さらに別の技法として、命令・レベル・トレースを用いた技法がある。しかし、この技法では、測定すること自体がシステム性能に干渉し、やはりシミュレーションに膨大な時間を要してしまう。
【００１０】
特開平８−３３９３８８号公報は、マルチプロセッサシステムにおける論理シミュレーション方法、特に各プロセッサから同一のメモリ領域にアクセスする試験を行う方法に関し、論理シミュレーションとソフトシミュレーションとを同時に動作させ、任意のタイミングで、該論理シミュレーションの結果とソフトシミュレーションの結果とを比較する方法であって、各プロセッサの専用の読込み, 書込み領域と、全プロセッサの共有書込み領域を設け、読込み命令は各プロセッサの専用の読込み, 書込み領域から読込み、書込み命令は各プロセッサ専用の読込み, 書込み領域, 又は全プロセッサの共有の書込み領域に書込むようにして、全プロセッサに共有な書込み領域での各プロセッサからの書込みにより、プロセッサ間の競合の試験を行うように構成することを開示する。
【００１１】
特開２００３−１５９６５号公報は、メモリを共有するSymmetric Multiプロセッサにおいて、複数プロセッサから同一タイミングでメモリへのアクセスを発生する命令列を自動生成する試験方式を提供することを目的とするものであり、試験プログラムにおいて、試験環境設定処理、期待値を生成する命令シミュレータ、試験命令列実行トレース情報生成処理、結果比較処理、試験命令のカバレージ情報蓄積処理、試験命令列の生成処理を有し、試験命令列を各プロセッサ毎に並行に生成し、発行されるメモリアクセスの種類・アドレス、及び推測実行命令サイクル数をカバレージ情報に蓄積し、他プロセッサ側の命令生成で、前記カバレージ情報を参照し、既生成分のプロセッサ側の実行命令サイクル数相当の試験命令を選択し、複数プロセッサから同一タイミングで同一アドレスのメモリに対してのアクセスの競合する試験命令列を生成することを開示する。
【００１２】
特開２００７−１０２５０９号公報は、バスマスタのレイテンシを低減することが可能な調停装置に関し、インタフェース部が第１バスマスタから別のバスマスタのメモリへのアクセスの予約要求を受信した際に、制御部により、別のバスマスタにより現在使用されているデータバスのバス帯域からそのアクセスの予約要求が最新に許可されたバスマスタより現在使用されているデータバスのバス帯域を減算した第１の減算結果が、データバスの最大のバス帯域からその最新に許可されたバスマスタによるデータバスの予約分のバス帯域を減算した第２の減算結果よりも大きいと判定される場合には、既にアクセス要求が許可されているバスマスタ以外からのバスマスタのアクセスの予約要求は許可されないようにすることを開示する。
【００１３】
Mudge, T. N.; Hayes, J. P.; Buzzard, G. D. & Winsor, D. C."Analysis of Multiple-Bus Interconnection Networks", Journal of Parallel and Distributed Computing, 1986, 3, 328-343は、 メモリーアクセスがランダムかつ一様でプロセッサー間で独立であるという近似をし、新規のメモリーアクセスとバスの調停による待ち時間(再送)の両方込みの帯域利用率U*を計算する代数方程式を簡易的な反復法で解くことを開示する。しかし、この文献の開示技術は、対称マルチプロセッサ・システム上での全体のメモリ帯域の解析には使うことはできるが、異種マルチプロセッサ・システム上では利用できないし、アプリケーション・レベルでのメモリ帯域の解析にも使えない。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開平８−３３９３８８号公報
【特許文献２】特開２００３−１５９６５号公報
【特許文献３】特開２００７−１０２５０９号公報
【非特許文献】
【００１５】
【非特許文献１】Mudge, T. N.; Hayes, J. P.; Buzzard, G. D. & Winsor, D. C."Analysis of Multiple-Bus Interconnection Networks", Journal of Parallel and Distributed Computing, 1986, 3, 328-343
【発明の概要】
【発明が解決しようとする課題】
【００１６】
上記従来の技法は、テストするメモリ・アクセス・パターンの網羅性、測定のベースとなるデータを事前準備するためのコストの大きさ、シミュレーション結果に基づき実行速度を推定するための計算量の膨大さなどの点で十分でなかった。
【００１７】
従って、本発明の目的は、詳細なメモリ・アクセス・パターンを必要とせず、アプリケーションのモデリングに十分な粒度で且つ妥当な計算量で、メモリ・アクセス競合の確率を計算することを可能ならしめる技法を提供することにある。
【００１８】
この発明の他の目的は、そのように計算されたメモリ・アクセス競合の確率に基づき、メモリ・アクセス競合の結果の、プログラムの実行時間を推測する技法を提供することにある。
【課題を解決するための手段】
【００１９】
本発明は、上記課題を解決するもので、アプリケーション・レベルの振る舞いを、イベント・ドリブンのシミュレーションで表現するとともに、より粒度の小さいメモリ・アクセス・タイミングを統計的に近似して、ステップ実行時間予測を得る予測技法を提供する。
【００２０】
本発明は、様々なデータを入力して計算し、値を出力する、コンピュータ・システム上で動作するソフトウェアとして実現される。
【００２１】
本発明は、上記のイベント・ドリブンのシミュレーションを含む、粒度の粗いシステム・アーキテクチャ・モデルに適用可能であって、当該モデルのシミュレーション・ステップにおける、実行時間Tと、メモリ・アクセスの回数Nを入力とする。
【００２２】
そこで、メモリの同期的アクセスと調停を考慮に入れ、各メモリ・アクセスの正確なタイミングの情報なしでメモリ・アクセス競合の効果を評価あるいは推測し、多くの代替アーキテクチャと比較するのに十分なシミュレーション速度で、メモリ・アクセス競合時の各種の推定値を得る。
【００２３】
このシミュレーションの結果得られるのは、メモリ・アクセス競合の下でのシミュレーション・ステップの推定実行時間T'と、メモリ・アクセス競合の下での各シミュレーション・ステップのメモリ帯域の利用率{U'i}である。
【００２４】
以上のことを、数式を用いてもう少し厳密に説明すると次のとおりである。まず、メモリ帯域の利用率は、次のように表される。
U = (N/T) / W
ここで、Wは、共有メモリに対する、単位時間毎に利用可能なメモリ・アクセスの最大数である。尚、メモリ・アクセスのreadとwriteの速度が異なる場合は、
U = Nr/T/Wr + Nw/T/Wwの式を用いると、より正確に計算される。ここで、Nrはメモリ読取り回数、Nwはメモリ書込み回数、Wrは単位時間毎に利用可能な読取りアクセスの最大数、 Wwは単位時間毎に利用可能な書込みアクセスの最大数である。
【００２５】
Pc = Pc(U1,...,UM)
ここで、cは衝突パターンのインデックスであり、M個のプロセッサが存在すると、2M個の衝突パターンが存在する。
また、Uiは、i番目のプロセッサの上で走るステップのメモリ帯域利用率である。
【００２６】
そこで、N >> 1と想定すると、Pcから、メモリ・アクセス競合の効果による１ステップの実行時間T'iを、次の式で評価する。
【数１】
0005153904.tif 000002
ここで、Ac,iは、i番目のプロセッサにつき、衝突がない場合のメモリ・アクセスの待ち時間に対する、衝突パターンcの場合のメモリ・アクセスの待ち時間の比である。
【００２７】
メモリ・アクセス競合の下でのメモリ帯域利用率U'iは次の式で評価される。
(U'i/Ui) = (Ti/T'i)
【発明の効果】
【００２８】
この発明によれば、主としてモデルのシミュレーション・ステップにおける、実行時間Tと、メモリ・アクセスの回数Nを入力として、実行時間とメモリ・アクセス競合を妥当な計算量で求めることができるので、設計モデルの粗い段階でも、さまざまなアーキテクチャに対して、実行時間とメモリ帯域利用率を見積もって、どれが妥当なアーキテクチャを迅速に判定することが可能となる。
【図面の簡単な説明】
【００２９】
【図１】異なるハードウェア・アーキテクチャの例を示す図である。
【図２】２つのプロセッサでのラウンド・ロビン調停の場合の待ち時間のU依存性を示す図である。
【図３】開発されるプログラムの性能を予測するシステムの全体を表す概要ブロック図である。
【図４】本発明に従う性能計算処理のフローチャートを示す図である。
【図５】製品開発のＶ字プロセスを示す図である。
【図６】２つのプロセッサのアクセスによって競合が生じることを示す図である。
【図７】メモリ・アクセスの典型的なシナリオを示す図である。
【図８】詳細粒度のシミュレーションに必要なパラメータとＵＭＬレベルのステップの関係を表す図である。
【図９】ＵＭＬモデルにおける、リソース・アクセスと利用率Uの関係をあらわす図である。
【図１０】ＵＭＬエディタの機能を示す概要図である。
【図１１】製品開発サイクルの流れを示す図である。
【図１２】ＵＭＬの入力モデルを示す図である。
【図１３】リソース利用率の計算の例を示す図である。
【図１４】リソース・マネジャの状態マシンを示す図である。
【発明を実施するための形態】
【００３０】
本発明の実施例を説明する前に、何故、組み込みシステムの設計空間探索に、命令セット・シミュレータ（ＩＳＳ）を使用するだけではうまくいかないのかを説明する。
【００３１】
組み込みシステムにおいては、ハードウェアとソフトウェアの両方を設計する必要があり、ハードウェアとソフトウェアのコンポーネントが増大するにつれて、考慮すべき代替アーキテクチャの数も指数関数的に増加する。組み込みシステムにおいては、ＡＳＩＣ(Application Specific Integrated Circuit)やＳｏＣ(System-on-Chip)が、製品能力の源である。
【００３２】
一方で、製造コスト、電力消費などの多くの制約がある。
【００３３】
例えば、３個のソフトウェア・コンポーネントを、２つのコアと、３つのメモリ領域に割り当てるとして、２１６の代替アーキテクチャがあるとする。
１つの製品の１つのテストに１分かかるとする。
テスト・パターンは１００あるとする。
ＩＳＳは、元のシステムより１００倍低速であるとする。
ホスト・プロセッサは、ターゲット・プロセッサより１０倍速いとする。
すると、シミュレーション時間は、216×1×100×100/(10×60×24) = 150日かかる。ただし、並列化して、このシミュレーション時間を減らすことは可能である。
【００３４】
さらに、ソフトウェア・コードと、ハードウェア・モデルは、代替アーキテクチャに合わせて２１６回書き直さなくてはならない。なぜなら、ソフトウェアは特にハードウェアにアクセスするように設計されるからである。
【００３５】
従って、処理が軽い技法で、設計空間を刈り込むことは重要である。ＩＳＳは、刈り込みの後、推測値をより正確にするために使用することができる。
【００３６】
このような前提の下で、本発明は、典型的にはＵＭＬなどの設計モデルを作成するツールによって生成された実行可能プログラムを、異なるアーキテクチャのハードウェアで動作させた場合の性能の差を迅速に推測することを可能とする技術である。
【００３７】
ここでいう異なるアーキテクチャとは、マルチコアのＣＰＵにおけるコア数やメモリ配置のトポロジなどである。図１(a)〜(c)に、異なるアーキテクチャの例を示す。以下の実施例では、プラットフォームとも称する。
【００３８】
そこでまず最初の仮定は、異なるアーキテクチャで走らせるプログラムは、同一の命令セットとコンパイラ・オプションで生成されたものであるべし、ということである。なぜなら、取得したステップの実行時間が、命令セットが全く異なるアーキテクチャでは大きく異なってしまうからである。
【００３９】
次の仮定は、基準とするアーキテクチャと、別のアーキテクチャで、キャッシュ・ミス・レートが同一に保たれるべし、ということである。これは、粗い粒度のモデルが使用され、キャッシュ・アーキテクチャが変更されないなら妥当であろう。なぜなら、キャッシュは、アクセスの局所性を利用し、一方、アクセスの局所性は、プログラムの局所的な構造（例えば、ループ）から顕われてくるからである。もちろん、キャッシュ・サイズやキャッシュ方法などのキャッシュ構造を変更すると、このことは最早当てはまらなくなる。すると、追加の実験やシミュレーションによって、キャッシュ・ミス・レートを調整する必要が出てくる。
【００４０】
次の仮定は、大抵のメモリ・アクセスに、メモリ・ストール(memory stall)が存在する、ということである。アウト・オブ・オーダー実行やプリフェッチングは、メモリ・ストールを減少させるが、この仮定はそれでも妥当であろう。なぜなら、最近のコンピュータ・システムにおいては、プロセッサ速度とメモリ・レイテンシの間のギャップは大きい（100サイクル以上)。これの仮定が正しくないなら、本発明の技法は、時間を過分に見積もっていることになる。
【００４１】
次の仮定は、メモリ・アクセスのスループットは一定であるべし、ということである。このことは、アクセスするアドレスがランダムなら、近似的に正しい。しかし、順次的アクセスのような場合、ＤＲＡＭはより高いスループットを達成する傾向があるので、最早正しくない。この場合、連続的なアクセスとランダムアクセスで、異なるスループットの値を使用することにより対応できる。
【００４２】
次に、本発明を実施するために必要となる、性能パラメータ(TおよびN)の取得について説明する。
(1) 既存のシステムの測定
アプリケーション・プロファイル収集ツールは、外部ハードウェアを用いたロギングに対応したアプリケーション・プロファイル収集ツールや、インサーキット・キャッシュ評価システムを使用するなら、システム性能にわずかな擾乱しか与えないで、実行時間やメモリ・アクセス回数を測定することができる。大抵の新規システムは、既存のシステムの変更なので、これがコスト的にも最も効率的で、正確な方法である。
(2) 既存のシステムの設計仕様文書の解析
ＡＳＩＣ及びＳｏＣコンポーネントからのメモリ・アクセスの回数は通常測定できない。なぜなら、ＡＳＩＣ及びＳｏＣコンポーネントは、アプリケーション・プロファイル収集ツールなどが接続されていないハードウェアだからである。ＡＳＩＣ及びＳｏＣコンポーネントはキャッシュ・メモリをもたないので、ＡＳＩＣ及びＳｏＣコンポーネントのメモリ・アクセスを評価するために、設計文書に記載されているアルゴリズムやデータサイズについての仕様からメモリ・アクセス回数を見積もることもできる。
(3) 全く新しいコンポーネントが新しいシステムに追加されるなら、それは測定できない。もしプラットフォームが存在し、ソフトウェア部分のみが新規であるなら、ソフトウェア・コンポーネントをプロトタイプし、アプリケーション・プロファイル収集ツールで測定することは、妥当である。
(4) 仮想プラットフォーム上での部分プロトタイピング
新しいコンポーネントのプラットフォームもソフトウェアもともに入手可能でないなら、パラメータは、プロトタイプのＩＳＳ、SystemCまたはＨＤＬなどの粒度の小さいシミュレーションから推測することになる。このことは、上述の方法に比較して、相対的にコストがかかるが、設計空間の探索を、本発明の軽量の方法で行うので、全体としては依然としてコスト的に合理的であるといえる。ともかく、多くの場合、新しいコンポーネントの比率はあまり大きくない。
【００４３】
次に、本発明に従う計算の理論的根拠について説明する。先ず、M個のプロセッサの場合の、衝突確率Pは、次の式で計算される。
【数２】
0005153904.tif 000003
ここで、衝突パターン・インデックスcは、c = 0,1,2,...,2M - 1の非負の整数であらわされる。b(q,c)という関数は、cをM桁の２進数としたとき、cのq番目のビットが1であるなら1を返し、そうでないなら0を返す。n(q,c)は、1 - b(q,c)である。
【００４４】
上記式２は、他のアクセスが完了するのを待っている、それまでのアクセスと、新しいアクセスの間の衝突をカウントしない。この効果により、実際の衝突確率は、式(2)で示すのよりも大きいものとなる。
【００４５】
そこで、この効果を考慮に入れるために、次のような値を導入する。
【数３】
0005153904.tif 000004
この式の分子は、メモリ・サブシステムによって処理されるメモリ処理の時間(TU)と、処理の待ち時間T' - Tとの和である。
【００４６】
そこで、次のように、式(1)のUqを、q=iを除いてU*qで置き換えることにする。
【数４】
0005153904.tif 000005
【００４７】
もし式(4)を用いるなら、U*qはT'iに依存するため、前記式(1)は、T'iの代数方程式となる。
【００４８】
これは、順次代入していくことで解ける。すなわち、式(4)の右辺にU*q = Uqを初期値として代入し、式(3)と下記の式(5)とでU*qを更新する。この手続は、値が収束するまで繰り返される。式(1)は、再掲である。
【数５】
0005153904.tif 000006
【数６】
0005153904.tif 000007
【００４９】
図２は、２つのプロセッサでの待ち時間のU依存性を示す図である。２つのプロセッサからのアクセスのラウンドロビン調停において、図２(a)に示すように、アクセスが即時に完了する場合(A = 1、上向きの矢印）と、アクセスが遅延する場合(A = 2、下向きの矢印）とがある。もし衝突の次のサイクルが、メモリ・アクセスでないなら、プロセッサはどちらの場合も直ちに再開する。どちらの場合も、等確率で起きるので、待ち時間の比は、A = 1×(1/2) + 2×(1/2) = 3/2で推測される。
【００５０】
一方、調停装置は、２つのプロセッサ１及び２の場合、1,2,1,2,...のような予め決まった順序で、同時的なメモリ・アクセスを処理する。もし衝突の次のサイクルが、メモリ・アクセスであるなら、アクセスは、他のプロセッサからのアクセスが完了するまでは、処理されるチャンスがないことになる。
【００５１】
こうして、この場合、図２(b)に示すように、待ち時間の比は、長くなる(A = 2)傾向がある。
【００５２】
以上から、待ち時間Aの期待値は、次のように書かれる。
【数７】
0005153904.tif 000008
【００５３】
この式は、調停が平等として、M個のプロセッサに一般化することができる。この効果は、m(c)番目の連続サイクルまで及ぶ。プロセッサが衝突パターンcにおいて衝突に関係する場合、すなわちb(i,c) = 1の場合、
【数８】
0005153904.tif 000009
またはそれ以外の場合、すなわちb(i,c) = 0の場合はAc,i(Ui) = 1である。式(7)に登場するUiとしては、初期値のUiを用いる。ここで、
【数９】
0005153904.tif 000010
である。
【００５４】
図３は、本発明の処理を実施するための機能を示すブロック図である。図３のシステムは、参照組込みシステム３１０と、モデリング／シミュレーション・システム３２０と、計測システム３３０からなる。参照組込みシステム３１０において、アーキテクチャ３０２とは例えば、組み込みシステムを実装するためのハードウェア・アーキテクチャであり、その例は、図１に示すようなものである。
【００５５】
参照組込みシステム３１０において、アプリケーション３１２は、動作をテストされる実行可能プログラムである。プラットフォーム３１４は、アプリケーション３１２を動作するためのハードウェアであり、その例は、図１に示すようなものである。メモリ・アクセス検出モジュール３１６は、アプリケーション３１２の、プラットフォーム３１４のメモリへのアクセスを検出する。ステップの開始／終了検出モジュール３１８は、図８に関して後述するような、ステップTstepの開始と終了を検出する。
【００５６】
モデリング／シミュレーション・システム３２０は、好適にはＵＭＬに基づくシミュレーション・システムであり、モデル（ＵＭＬ）エディタ３２２と、計算モジュール３２４を有する。計算モジュール３２４は、上述したアルゴリズムに従い、実行時間やメモリ帯域利用率などの値を推測するものである。
【００５７】
計測モジュール３３０は、メモリ・アクセス検出モジュール３１６によって検出され、ステップの開始／終了検出モジュール３１８によって開始と終了を区切られたデータを、実行トレースの形にして、モデリング／シミュレーション・システム３２０に転送するように働く。
【００５８】
計算モジュール３２４は、計測モジュール３３０から渡されたデータを用いて、上述したアルゴリズムに従い、実行時間やメモリ帯域利用率などの値を推測するものである。
【００５９】
次に、図４のフローチャートを参照して、計算モジュール３２４の処理を説明するが、その前に、定義と前提を与える。
定義：
衝突とは、複数のプロセッサからの同時アクセスである。
cは、衝突パターンのインデックスである。もし、M個のプロセッサがあるなら、2M個のパターンがある。
Pcとは、パターンcの衝突の確率である。
Uiとは、i番目のプロセッサ上で走るステップのメモリ帯域利用率である。
Ac,iとは、パターンcの衝突の下でi番目のプロセッサからのメモリ・アクセスの待ち時間の、衝突がない場合のi番目のプロセッサからのメモリ・アクセスの待ち時間に対する比である。
前提条件：
Mステップは、並列に走っている。
{Ui}は、Ui = (Nri/Ti)/Wr + (Nwi/Ti)/Wwで計算される。ここで、Wはスループットである。ここで、Nriはメモリ読取り回数、Nwiはメモリ書込み回数、Wrは単位時間毎に利用可能な読取りアクセスの最大数、Wwは単位時間毎に利用可能な書込みアクセスの最大数である。
{Ac,i}は、式(7)、(8)及び(9)で計算される。
【００６０】
ステップ４０２では、計算モジュール３２４は、
U*i = Ui, U*i[0] = Ui, n := 0により初期化する。
【００６１】
ステップ４０４では、計算モジュール３２４は、n := n + 1により、nを増分する。
【００６２】
ステップ４０６では、計算モジュール３２４は、式(4)によりPc({U*i = Ui})を計算する。
【００６３】
ステップ４０８では、計算モジュール３２４は、式(1)によりT'i/Tiを計算する。
【００６４】
ステップ４１０では、計算モジュール３２４は、式(5)によりU'i[n]を計算する。
【００６５】
ステップ４１２では、計算モジュール３２４は、|U'i[n] - U'i[n-1]| < εかどうか判断する。ここでεは、予め定めた小さい値の正の定数であり、収束の判定に使われる。|U'i[n] - U'i[n-1]| < εとなると、計算モジュール３２４は、計算が収束したと判断し、ステップ４１４で、Pcを出力して計算処理を終る。
【００６６】
まだ|U'i[n] - U'i[n-1]| < εを満たさないなら、計算モジュール３２４は、ステップ４１６で、式(3)によりU*iを計算して、ステップ４０４に戻る。
【００６７】
こうして、ステップ４０４、４０６、４０８、４１０、４１２及び４１６のループを巡ってステップ４１２で計算が収束したと見なされると、計算が終了した段階で、
個々のT'iが得られる。全体のアプリケーションの実行時間を計算するには、ＵＭＬのセマンティクスに従ってステップを実行し、その度毎にT'iを加算するという処理が必要である。
【００６８】
プロセッサの数をMとして、この計算の計算量は、Ｏ(M2・2M)程度である。
同時アクセスの最大数は、Mであり、上記計算ループの収束回数は、実験結果によると、Ｏ(M)である。また、１つのケースにつき、衝突パターンの数は、2Mである。
【００６９】
示唆される事実として、次のことがある。
まず、シミュレーション速度は、メモリ・アクセスの回数に依存しない。
Nが大きい場合のシミュレーションは、粒度の細かい方法よりも高速である。というのは、粒度の細かい方法は、計算量がNに比例するからである。
本手法は、共有メモリに接続するプロセッサ数Mが増加すると不利であるが、そのようなシステムではメモリ・アクセスの競合で性能低下が大きいため、一般に多数のプロセッサをもつシステムでは、単一の共有メモリよりも寧ろ、分散メモリ・アーキテクチャの方が、競合を低減するのに相応しい。
【実施例１】
【００７０】
以下、ＵＭＬを用いた設計に、本発明を適用する具体的な実施例について説明する。先ず、図５に、組込みシステムのＶ字プロセスを示す。
【００７１】
マルチプロセッサ・システムの製品性能にとって、初期の段階の設計は重要である。それは、図５のＶ字プロセスでは特に、システム・アーキテクチャ設計に対応する。
【００７２】
自動コンパイラ最適化は、命令セット・アーキテクチャ・レベルの並列性を扱うことができる。また、アプリケーション・ドメインの知識と、システム・アーキテクチャがスレッド・レベル及びより高位の並列性として考慮されるようなソフトウェア設計に、ＵＭＬが使用される。
【００７３】
その並列性により、設計フェーズで、性能を評価することは困難である。
【００７４】
ソフト・リアルタイム組込みシステムでは、実行時間（または、応答時間）が最も重要な性能の指標であることが多い。
【００７５】
実行トレースは、システムの性能、例えば実行時間を解析するのに有用なツールである。実行トレースは、設計に関連するステップ（例えば、ファンクション・コール）からなる。既存の製品に対する実行トレースは、よい精度で測定される。計測モジュールと実行トレースを得る仕組みについては、後述する。
【００７６】
新しい製品の場合、次のようなことを考慮に入れたシミュレーションが必要である。
・各リソースの速度（それによって、ハードウェアが変更されるかもしれない）
・リソースに対する同期トランザクション（それによって、並列性によるメリットが低下してしまう）
・リソースに対する競合（それによって、並列性によるメリットが低下してしまう）
【００７７】
次に、実行トレースの例について説明する。実行トレースのステップは、ファンクション・コール、または状態に入ること(entry)／出ること(exit)／遷移(transition)である。
【００７８】
実行トレースは、実行されるステップの履歴である。実行トレースに含まれる情報として、下記のものがある。
・ステップ間の依存性
・各ステップの入った時間と出た時間
・追加の属性（メモリ・アクセスの回数、引数の値、スレッドＩＤなど）
下記に実行トレースの例を示す。ここでは、各ステップの入った時間と出た時間だけが示され、メモリ・アクセスの回数などの情報は省略されている。
Step_a: entry=0120ms
Step_b: entry=0125ms
Step_b: exit=0132ms
Step_c: entry=0132ms
Step_c: exit=0138ms
Step_b: entry=0143ms
Step_b: exit=0150ms
Step_c: entry=0150ms
Step_c: exit=0156ms
Step_a: exit=0156ms
【００７９】
図６は、メモリ・アクセス競合を模式的に示す図である。アーキテクチャの設計で、あるプロセッサ（旧ＭＰＵ１）を、速度ファクタＦのより高速の新ＭＰＵ１に置き換えるという状況がありえる。ところが、高速の新ＭＰＵ１だと、図示されているように、バス・アクセスの競合率が高まるということがありえる。
【００８０】
図７に、２つのプロセッサによるメモリ・アクセスの典型的なシナリオを示す。J1が一方のプロセッサのジョブであり、J2が他方のプロセッサのジョブである。ここでは、どのケースも、U1 = U2 = 0.5であるとする。
【００８１】
図７(a)は、周期的アクセスで、最良のケースである。この場合は、メモリ競合は全く起こらない。図７(b)は、穏当なケースで、ランダム且つ均一なアクセスの場合である。この場合は、ときどきメモリ競合が起きる。図７(c)は、クラスタ・アクセスで、最悪のケースである。不均一且つ相関したアクセスで、至るところでメモリ競合が生じる。本手法では、図７(b)のケースを近似計算で求めているため、その他の場合にはシミュレーション予測と実際のプログラムの挙動の間に誤差が生じ、図７(a)および(c)のケースが誤差の最大値を与える。すなわち、本手法の近似による誤差は有限の範囲にとどまる。
【００８２】
従来、実行トレースを扱うことのできて、かつメモリ・アクセスの競合を扱うことができる適切なシミュレーション方法はなかった。
例えば、キューイング・ネットワーク（ＱＮ）は、抽象度が高すぎて、実行トレースを得ることができない。ＱＮ、ＳＡＮ(Stochastic Automaton Network)、ＳＰＡ(Stochastic Process Algebra)などの多くの性能モデリング方法が生成するのは、統計である。
一方、トランザクション・レベルのモデリングは、細かすぎて、シミュレーション速度が遅く、モデリングのワークロードが大きい。また、トランザクション時間幅をTtrans、シミュレーション・ステップをTstepとすると、図８に示すように、Tstep >> Ttransなので、時間スケールの分離のために、多くのパラメータが必要になる。
【００８３】
次に、設計モデルの性能を評価する従来の方法と、本発明の方法を比較してみると、下記のような表に纏められる。
【表１】
0005153904.tif 000011
ここで、実行トレースとは、改めて定義すると、例えばページの印刷処理のようなジョブ毎の処理の時間とフローであり、トランザクション・レベル・モデリングとは、メモリ・アクセスのような、デバイス間のトランザクションのログと同じ抽象度のモデルである。この表から見て取れるように、本発明の方法は、既存のいくつかの方法の中庸を得て、ＵＭＬレベルの設計モデルに好適に適用できる点が特徴である。
【００８４】
そこで次に、ＵＭＬによる設計について説明する。設計者の意図は、次のようにしてＵＭＬステップ・レベルで記述される。
・ＵＭＬの挙動モデリングにおいて、アクティビティ、状態、あるいはオペレーションが、ＵＭＬステップの単位である。
・１ステップ内のトランザクション・パターンは、均一且つランダムであるとする。というのは、ループにおけるメモリ・アクセスの周期は、分岐によって変動し得るからである。
・ステップに亘るトランザクション・パターンは異なり得る。というのは、ステップ毎の設計の意図も異なり得るからである。
・時間のかかるステップは、多くのトランザクションを含む。すなわち、前述のように、Tstep >> Ttransである。なお、メモリ・アクセスの時間が問題となっている状況では、これは、N >> 1と等価となる。
【００８５】
このように、Tstep >> Ttransという時間スケールの分離があるので、時間スケールTtransでの挙動は、１ステップ内で統計的に評価される。一方、時間スケールTstepでの挙動は、シミュレーション時間をサポートして(timed)実行可能なＵＭＬによってシミュレーションされる。
【００８６】
前記した各リソースの速度、リソースに対する同期トランザクション、及びリソースに対する競合という３つの要件は以下のように評価される。まず、リソースの速度について説明する。ＵＭＬステップは、Tstepを更新するためのリソース利用要求によって特徴づけられる。このとき、計測時のシステムと新規システムのリソースの速度の違いを、下記の式で示すアムダールの法則によってTstepに反映する。
Tstep(new) = Tstep(ref.) * (1 - U + U/f)
ここでfは、参照リソースに対する新しいリソースの速度比(スピード係数)である。
Uは、そのリソースを使用する時間のTstep(ref.)に占める割合である。
プロセッサ・リソースの場合には、U = (1 - N*L/Tstep(ref.))
Lは、メモリ・アクセスのレイテンシである。
なお、レイテンシが読み込みと書き出しで異なる場合にはそれぞれをLr,Lwとし、それぞれのアクセス回数をNr,Nwとすると、
U = (1-(Nr*Lr+Nw*Lw)/Tstep(ref.))となる。
メモリ・リソースの場合、Uはメモリ・リソースの利用率である。
【００８７】
−  メモリ・リソースの場合、リソース競合は、トランザクションの分布がランダム且つ均一であるという仮定の下で、衝突確率から計算される。
【００８８】
−  プロセッサ・リソースの場合、リソース競合は、リソースがタイムスライスまたはキューによって共有されているという仮定の下で計算される。
【００８９】
また、同期的トランザクションの効果は、競合伝播アルゴリズムによって評価される。その詳細は、図１３を参照して後で説明する。
【００９０】
このようなＵＭＬステップ・ベースのリソース・アクセスと詳細な粒度のリソース・アクセスの関係の例を図９に示す。ジョブとしてそこに示されているように、リソース競合は、Tstepという粗いレベルで評価される。ここでリソースは、メモリ、あるいは、メモリにアクセスする、プロセッサ、アクラセレータ、またはコントローラを含む、バス・マスタと呼ばれるデバイスも含む。上記では、プロセッサに関して記述されているが、プロセッサ以外のバスマスタについても、シミュレーション方法は、プロセッサに準じて適用可能であることを理解されたい。
【００９１】
ここで、ＵＭＬベースのモデルに本発明を適用することの目的は、次のとおりである。
・新しい製品のソフトウェア及びハードウェア・アーキテクチャを、性能の観点から検証すること。ここでの性能の定義は、アプリケーション・プロセスの実行時間で測定されるものである。
【００９２】
そして期待される出力は、次のものである。
・リソース利用率（バス及びプロセッサ）
・ステップの実行トレース（各ステップの開始と終了時間）
【００９３】
ここで要求されるのは、つぎのものである。
・ＵＭＬ実行の実行セマンティックス（状態マシン、アクティビティ図など）をサポートすべきであること。これは、シミュレーション時間をサポートして(timed)実行されるＵＭＬをベースとして使用することにより、満たされる。
・正確なシミュレーション・パラメータを使用すること。これは、測定技術と、既存のソースコードからモデルを作成する技術てあるリバース・モデリングを使用することにより、満たされる。
【００９４】
また、既に説明したように、次のような効果を評価することが必要とされる。
・各リソースの速度
・リソースに対する同期トランザクション
・リソース競合
【００９５】
本発明の技法は、ＵＭＬレベル実行トレースのために設計されたものであるので、本発明のシミュレーション技法は、ＵＭＬエディタに統合することができる。このとき、次のように３種類のモデルを定義する。
・アプリケーション・モデルは、ステレオタイプによる性能パラメータ・アノテーションをもつソフトウェア設計のためのユーザーのモデルである。
・リソース割当てモデルは、MARTEアロケーション・パッケージを用いて、ソフトウェア・コンポーネントと、プラットフォーム・リソースの間の関係を記述する。ここで、MARTE（Modeling and Analysis of Real-Time & Embedded Systems）とは、リアルタイム組み込みシステム向けのドメイン特化モデリング言語で、ＵＭＬの拡張プロファイルとして定義されたものである。
・プラットフォーム・モデルは、プロセッサやメモリなどの振舞いをシミュレートするコンポーネントからなるシミュレーション・フレームワークである。
【００９６】
図１０は、このようなＵＭＬエディタの機能を模式的に示す図である。すなわち、ユーザーがアプリケーション・モデルを作成し、リソース割当てモデルを指定する。アプリケーション・モデルには、性能パラメータが注釈され、リソース割当てモデルには、プラットフォーム仕様が設定される。このとき、例えば、ＵＭＬエディタのプラグインが使用される。
【００９７】
アプリケーション・モデルとリソース割当てモデルは、ライブラリ・モジュールを含むプラット・フォーム・モデルと結合されて、性能シミュレーション・コードが生成される。この時、コード生成機能は、例えばＵＭＬエディタの既存のコード生成機能を拡張することで実現される。性能シミュレーション・コードは、組込みシステムとは別のコンピュータ・システム上で実行される。
【００９８】
このシミュレーションによって得られる典型的な情報は、実行トレースと、時間の関数としての各リソースの使用率のレポートである。
【００９９】
実行トレースは、下記の目的で使用することができる。
・視覚化を通じて、システムの振る舞いを理解する。
・テスト・ケースの実行時間を評価する。
・スループットなどの統計を計算する。
【０１００】
時間の関数としての各リソースの使用率は、下記の目的で使用することができる。
・ボトルネック・リソースを指摘する。
【０１０１】
図１１は、既存の製品から新しい製品を設計する場合の、処理の流れを示す図である。すなわち、ステップ１１０２で、既存の製品の動作が測定され、これによって実行トレースが得られる。
【０１０２】
ステップ１１０４では、実行トレースが解析され、その解析結果に基づき、ステップ１１０６でモデリングが行われる。モデリングに際しては、設計文書とパラメータも参照される。モデリングによって得られたモデルに基づき、ステップ１１２４ではシミュレーションが行われ、それによって実行トレースが得られる。
【０１０３】
その実行トレースは、ステップ１１１０で解析され、それによってレポートが生成されるので、そのレポートに基づき、必要に応じて、ステップ１１０６でモデリングがやり直される。
【０１０４】
こうして、十分なモデルが得られると、そのモデルとレポートの情報を以って、ステップ１１１２で設計が行われる。設計の後は、プロトタイプが作られ、ステップ１１０２で測定が行われる。
【０１０５】
それにより、満足のいく結果が得られないと、ステップ１１０６のモデリングに戻る。この一連のステップの結果、ステップ１１１２で満足のいく設計が得られると、それに基づき、新しい製品が作られる。
【０１０６】
次に、シミュレーション・モデルとして、注釈された(annotated)実行可能ＵＭＬの例について説明する。すなわち、ステップ・パラメータ記述（アプリケーション・モデル）と、ソフトウェア・コンポーネントに対するメモリ及びプロセッサ・リソースの割当て（リソース割当てモデル）が、プロファイル（すなわち、ＵＭＬエクステンション、例えば、ＯＭＧ  ＭＡＲＴＥプロファイル）を適用することによって、ＵＭＬに対して注釈される。
【０１０７】
ＵＭＬモデルはまた、ソフトウェアに対する仕様として使用される。すなわち、ソフトウェアを実装するとき、開発者はＵＭＬモデルに当たることができるし、あるいは、開発者は、モデルから自動的にソフトウェア・ソースコードを生成することができる。
【０１０８】
図１２は、そのようなアプリケーション・モデルと、リソース割当てモデルの例を示す。図において、<<...>>は、プロファイルで定義されたステレオタイプである。また、リソース割当てモデル中のＳＷ１、ＳＷ２は、ソフトウェア・コンポーネントを示す。
【０１０９】
なお、シミュレーションのために、ＵＭＬ以外の形式のイベント・ドリブンまたは離散時間シミュレーション・モデルも使用可能であることに留意されたい。
【０１１０】
アプリケーション・プロファイル収集ツールは、システムに対してほとんど擾乱を与えることなく、実行時間Tと、メモリ・アクセスの回数Nを測定することを可能ならしめる。
・ステップの実行時間Tは、ステップの開始／終了検出モジュールに対してステップの出入りを通知する小さいコードを挿入することによって、行うことができる（例えば、Ohba, N., Takano, K.: Hardware debugging method based on signal transitions and transactions. In: Proceedings of the 11th Asia South Pacific Design Automation Conference (ASPDAC 2006)を参照されたい）。
【０１１１】
メモリアクセスの回数Nは、キャッシュ・エミュレータ・ハードウェアを使用し、キャッシュ・ミスの回数をカウントすることによって測定される。
【０１１２】
これらの情報は、実行トレースとして報告され、モデル・パラメータは実行トレースから抽出することができる。
【０１１３】
さらにこの実施例の説明を続ける前に、用語の定義を与える。
先ず、ステップとは、ＵＭＬモデルにおけるアクション、状態、または操作に対応する。また、ステップは、実行されるとジョブを生成する。
【０１１４】
ジョブは、リソースによる処理の単位であり、ステップに対応する。
このとき、ジョブJ = {Tstep,U1,U2,...,Um}であり、ここで、mはリソースの数、Uiは、このジョブによってi番目のリソースに対して要求される利用率である。
ジョブの処理時間は、Tstepと、これらの利用率によって計算される。
【０１１５】
リソースとは、プロセッサ、メモリ帯域などのハードウェアの抽象である。
・このとき、リソースは、その利用率に従ってジョブを処理する。
・リソースは容量をもち、それは１に正規化される。各リソースにおいて、ジョブの利用率の合計は、同時にこの容量を超えることはない。
・リソースは、利用率の合計を１以下に保つようにジョブの利用率を変えることができる（競合状態）。
・リソースは、速度ファクタに従い、ジョブの利用率を変えることができる。
【０１１６】
ステップ・パラメータ：これは、参照システムから得られ、新しいシステム用に調整される。
T:ステップ時間
Nr:読取りアクセスの回数
Nw:書込みアクセスの回数
Wr:単位時間毎に利用可能な読取りアクセスの最大数
Ww:単位時間毎に利用可能な書込みアクセスの最大数
ジョブ・パラメータ
T:処理時間
Up:プロセッサ利用率要求
Ub:メモリ帯域利用率要求
【０１１７】
ステップ・パラメータと、ジョブ・パラメータの間の関係は、次のとおりである。
Job.T = Step.T
Ub = (Nr/Wr)T + (Nw/Ww)/T
Up = 1
【０１１８】
図１３は、利用率の計算の例を示す図である。この図において、リソースR1であるプロセッサと、リソースR2であるバスと、リソースR3であるプロセッサがあるとする。最初にジョブJ1が(R1,R2.R3) = (100%,60%,0%)、ジョブJ2が(R1,R2.R3) = (100%,60%,0%)、ジョブJ3が(R1,R2.R3) = (0%,60%,100%)であるとする。すると、明らかにリソース競合が起きるが、利用率が計算され、競合が伝播することによって、競合が緩和されている様子が示されている。
【０１１９】
次に、図１４を参照して、この実施例のシミュレーション方法全体について説明する。
Data lefti(t)は、ジョブがある時刻tに持つリソースアクセスの残量として定義される。
Data lefti(0) = T * Ui(0)は、ジョブ生成時の初期値となる。
1. 全てのリソースについて、ジョブの利用率Uを計算する（利用率計算アルゴリズムについては、後述する）
2. 全てのジョブについて、ジョブ完了時間を次の式で更新する。
ΔTi = Data lefti(t) / Ui （この値は、リソースに依存しない）
3. 全てのジョブにおいて、ジョブ完了時間の最小時間を見出す。
すなわち、ジョブにおけるΔTiの最小値をaとおく。
4. タイムアウトを待つ
Tm(a)、この間に、ジョブ開始イベントが、t' < t + aで起き得る。ここで、Tm(a)とは、a秒間のタイムアウトを待つことを示す。タイムアウト発生時には、現在のシミュレーション時刻tがt + aに更新される。
5. 全てのジョブについて、Data lefti(0)から、U * (t' - t)を引く。
6. Data lefti(t+a) == 0ならジョブを取り除き、ジョブ完了イベントを送る。
【０１２０】
図１４に、上記の処理に対応するリソース・マネジャの状態マシンを示す。図１４において、状態１４０２は、待機し、全てのジョブについての利用率の更新と、全てのジョブについてのΔTの更新と、最小のΔTであるaを見つけることを行う。
【０１２１】
一方、状態１４０４は、Data leftを更新し、完了したジョブを取り除く。
【０１２２】
次に、利用率計算アルゴリズムについて説明する。
先ず、メモリ帯域リソースの場合、図４に関連して説明したメモリ・アクセス競合計算技法を使用する。
【０１２３】
プロセッサ・リソースの場合、非プリエンプティブ・マルチタスク・システムであるなら、例えば、キューイング・モデルを使用する。一方、プリエンプティブ・マルチタスク・システムであるなら、例えば、次のような単純な比例的利用率割当てを用いる。
【数１０】
0005153904.tif 000012
【０１２４】
次に、他のリソースに対するリソース競合伝播の効果について説明する。図１３に示したように、あるジョブについて、競合のためにリソースに対する利用率が低下するなら、そのジョブの他のリソースに対する利用率は、同期的性質により低下する。
同様の伝播は、次のように記述される。
すなわち、もしUi' = f Uiであるなら、iに等しくないhについて、Uh' = f Uh
（なぜなら、T'Ui' = TUiで時間が延びるだけなので、T'Uh' = TUh）
【０１２５】
リソース間のリソース競合計算の順序は、競合伝播のため、ジョブの利用率の分布に影響する。そこで、計算順序であるが、明示的なデバイス・ベースの順序は、高い特権のリソースから計算することである。
・例えば、プロセッサ・リソースの利用率を最初に計算する。
・その結果を他のリソースに伝播する。
・次に、メモリ・リソースの利用率を計算する。
・その結果を他のリソースに伝播する。
【０１２６】
以上、リソース利用率の計算処理を、ＵＭＬエディタに追加する機能として説明したが、これには限定されず、任意の実行可能プログラムの性能評価に適用可能である。
【０１２７】
また、本発明は、使用するプラットフォームや、プログラミング言語処理系にも限定されないことを、この分野の当業者なら理解するであろう。
【符号の説明】
【０１２８】
３１０  参照組込みシステム
３１２  アプリケーション
３１４  プラットフォーム
３１６  メモリ・アクセス検出モジュール
３１８  ステップの開始／終了検出モジュール
３２０  モデリング／シミュレーション・システム
３２２  モデル（ＵＭＬ）エディタ
３２４  計算モジュール
３３０  計測モジュール
【図１】
0005153904.tif 000013
【図２】
0005153904.tif 000014
【図３】
0005153904.tif 000015
【図４】
0005153904.tif 000016
【図５】
0005153904.tif 000017
【図６】
0005153904.tif 000018
【図７】
0005153904.tif 000019
【図８】
0005153904.tif 000020
【図９】
0005153904.tif 000021
【図１０】
0005153904.tif 000022
【図１１】
0005153904.tif 000023
【図１２】
0005153904.tif 000024
【図１３】
0005153904.tif 000025
【図１４】
0005153904.tif 000026