JP7799862B2 - 処理負荷推定システム、及び処理負荷推定方法 - Google Patents

Description

本発明は、ソフトウェアコンポーネントの処理負荷推定システムに係り、特に、組込みソフトウェア開発において、システム全体の性能評価においても、精度良く処理負荷を推定することができる処理負荷推定システムに関する。

近年の車両の制御装置に実装される組込みソフトウェアは多様化・複雑化の一途を辿っており、組込みソフトウェアの設計および検証に要する工数は増大し続けている。これらに対応する一つの手法として、モデルを用いてシミュレーション設計・検証するモデルベースによる組込みソフトウェア開発技術が挙げられる。

モデルベース開発では、Ｓｉｍｕｌｉｎｋに代表されるようなモデリングツールを用いて開発を行う方法が代表的である。この方法では、基本演算ブロックや機能ブロックを組み合わせることで制御仕様を満たしたモデルを設計し、シミュレーションによる検証が可能であり、モデリングツールを使用しない場合と比較して高効率な設計開発が実現できる。

車両の制御装置では、ＣＰＵリソースやＲＯＭ／ＲＡＭ容量などの制約が厳しく、リソースの制約を考慮した設計が求められる。特に車両の電動制御の分野においては、高速な処理速度が求められことでＣＰＵリソース不足が顕在化しており、上流工程で機能的な検証を通ったモデルが、実装段階になってＣＰＵリソースの制約を満たせないことが判明し、モデルの作り直しや追加の処理負荷低減施策などにより開発工数が増大してしまう問題が発生する。そこで、例えば特許文献１の発明では、複数の機能モデルにより構成される評価対象システムにシナリオデータを入力して得られたトレース情報から、実行経路毎の処理負荷を単に予測するだけでなく、選択したＯＳのスケジューリングアルゴリズムに従って性能シミュレーションをすることで、複数の処理が同時に実行された場合の処理負荷を精度よく見積るシミュレーション装置が開示されている。

また、特許文献２では、複数の処理が同時に起動した場合の遅延を考慮しつつ、モデルの構成要素である演算ブロックの処理時間やＣＰＵの実行サイクル数からモデル全体のＣＰＵ処理負荷を設計上流段階で予測する、モデルベースの性能予測システムが開示されている。

特開２００９－２５８８３１号公報 特開２０１１－１５４５２１号公報

特許文献１の発明では、複数の機能モデルを有した評価システムに対してシナリオデータを入力し、そのシナリオで実行されたシーケンス毎に処理時間を評価している。しかしながら、このシーケンスはモデル内の演算経路を指しているのではなく、ＯＳによってスケジューリングされる機能モデルの実行順序を指しており、機能モデル単体の処理時間は固定値であるため、機能モデル単体の処理時間を精度よく見積ることはできない。

一方、特許文献２の発明では、モデルの構成要素である基本演算ブロック毎の処理時間を予め記憶しておき、モデルの処理時間を予測している。この手法を用いれば、分岐処理などによりモデル内に複数の演算経路がある場合でも、その経路毎に処理時間を予測可能であり、例えば、演算ブロックの処理時間の累積値が最大となる経路から最大処理時間を予測可能である。しかしながら、この方法では車両の制御装置に実装して動作させた際の、平均処理時間を精度よく予測することはできない。

また、各ＣＰＵコアに実装された制御システムが処理負荷破綻を起こしてしまうか否かを予測するためには、各ＣＰＵコアに配置する全モデルの最大処理時間を予測しなければならない。この全モデルの最大処理時間を予測するためには、例えばＯＳによってスケジューリングされた結果に従い個々のモデルの理論上の最大処理時間を累積する方法が考えられる。しかし、各ＣＰＵコアに実装された全モデルの処理時間が最大となる時、必ずしも個々のモデルの最大処理時間となる演算経路が実行されるわけではない。よって、個々のモデルの最大処理時間を累積したものを全体の最大処理時間としてしまうと、実際より過大な最大処理時間として予測されてしまう問題があった。

更に、近年では、組込みマルチコア型のリアルタイムシステムのタイミングやスケジューリングを検証するツールが導入され始めている。このようなツールでは、スケジューリング情報や周期タスク、割り込みタスクの情報などのＯＳの設計情報と、スケジューリング対象である各モデルの処理時間をインプットすることで、システム全体のタイミングやスケジューリングを検証することが可能である。よって、処理時間の推定において、特許文献１や特許文献２の特徴である、ＯＳスケジューリングの機能を兼ね備える必要性はあまりなく、モデル単体の処理負荷を精度よく求めることがより重要になってきている。

本発明は、上記課題を鑑みてなされるものであり、ソフトウェアコンポーネント単体から推定する処理時間の精度を高めつつ、システム全体の性能評価においても、実用的で高精度な処理負荷推定システムを提供するものである。

前述の課題を解決するために、本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、処理負荷推定システムであって、所定の処理を実行する演算装置と、前記演算装置がアクセス可能な記憶装置とを備え、予め定められた演算フローを実現する複数の演算要素を有し入力値に応じて演算経路が異なるソフトウェアコンポーネントが入力されるソフトウェアコンポーネント入力部と、前記ソフトウェアコンポーネントに与えるテストスイートが入力されるテストスイート入力部と、前記演算装置が、前記演算経路毎の処理負荷を推定する処理負荷推定部と、前記演算装置が、前記テストスイートに基づいて、前記ソフトウェアコンポーネントのシミュレーションを行い、複数のシミュレーション結果から得られる動的な特徴を出力するシミュレーション部と、前記演算装置が、前記シミュレーション部から出力された動的な特徴を処理する結果処理部と、を有し、前記結果処理部は、前記動的な特徴と、前記入力値に対応する複数の演算結果と、前記経路毎の処理負荷とに基づいて、前記ソフトウェアコンポーネントの実用処理負荷を推定することを特徴とする。

本発明の一態様によれば、高精度に処理負荷性能を推定できる。前述した以外の課題、構成及び効果は、以下の実施例の説明によって明らかにされる。

第１の実施形態に係る処理負荷推定システムのシステム構成図である。 第１の実施形態に係る制御モデルを示すモデル図である。 第１の実施形態に係る制御モデルの演算経路を示す図である。 第１の実施形態に係るコストデータベースの一例を示す図である。 第１の実施形態に係る演算経路毎の累積コストを示す図である。 第１の実施形態に係るテストスイートを示す図である。 第１の実施形態に係るシミュレーション結果情報を示す図である。 第１の実施形態に係る結果処理部が実行する処理のフローチャートである。 第１の実施形態に係る偏差の算出結果の例を示す図である。 第１の実施形態に係る実用的な処理時間を示す図である。 第２の実施形態に係るプログラムのフローチャートである。 第２の実施形態に係るプログラムの演算経路の例を示す図である。 第２の実施形態に係るコストデータベースの一例を示す図である。 第３の実施形態に係る結果処理部が実行する処理のフローチャートである。 第４の実施形態に係る結果処理部が実行する処理のフローチャートである。 第４の実施形態に係る通過率の一例を示す図である。 第５の実施形態に係る処理負荷推定システムのシステム構成図である。 第５の実施形態に係るコストデータベースの一例を示す図である。 第７の実施形態に係る処理負荷推定システムのシステム構成図である。 第７の実施形態に係る制御モデルのデータフロー図である。 第７の実施形態に係るコストデータベースの一例を示す図である。 第７の実施形態に係る経路コスト評価部が実行する処理のフローチャートである。

以下、図面を用いて、本発明の第１から第７の実施形態について説明する。なお、各図において、同一符号は同一部位を示す。

（第１の実施形態）
図１は、本発明の第１の実施形態に係るソフトウェアコンポーネントの処理負荷推定システム１のシステム構成図である。

ソフトウェアコンポーネントの処理負荷推定システム１は、ソフトウェアコンポーネント入力部１０２、テストスイート入力部１０４、シミュレーション部１０５、処理負荷推定部１０６、及び結果処理部１０７によって構成される。ソフトウェアコンポーネント入力部１０２は、ソフトウェアコンポーネント１００の入力を受ける。テストスイート入力部１０４は、テストスイート１０３の入力を受ける。シミュレーション部１０５は、ソフトウェアコンポーネント入力部１０２に入力されたソフトウェアコンポーネント１００とテストスイート入力部１０４に入力されたテストスイート１０３を用いてシミュレーションを行う。処理負荷推定部１０６は、ソフトウェアコンポーネントの処理負荷を推定する。結果処理部１０７は、シミュレーション部１０５によるシミュレーション結果と処理負荷推定部１０６による推定結果に基づいて、ソフトウェアコンポーネント１００の実用的で高精度な処理負荷を推定する。ソフトウェアコンポーネント１００は、例えば制御モデル１０１やプログラム２０１である。

第１の実施形態では、ソフトウェアコンポーネント１００が制御モデル１０１である場合について説明する。

本実施形態における処理負荷推定部１０６は、各演算経路の処理時間を推定する。処理負荷推定部１０６は、制御モデル１０１を構成する演算ブロック毎の処理負荷に係るコストを記憶するコスト記憶部１０８と、コスト記憶部１０８を参照しながら経路毎の演算ブロックのコストを累積して、制御モデル１０１の各演算経路の処理時間を推定する経路コスト評価部１０９を有する。

なお、本発明の実施形態では、処理負荷推定部１０６の具体例として、処理負荷推定部１０６がコスト記憶部１０８と経路コスト評価部１０９を有する場合を説明するが、他の方法を採用してもよい。例えば、経路毎の処理時間を予め記憶する方法でもよい。

第１の実施形態に係る処理負荷推定システム１は、プロセッサ（ＣＰＵ）、メモリ、補助記憶装置、及び通信インターフェースを有する計算機によって構成される。処理負荷推定システム１は、入力インターフェース及び出力インターフェースを有してもよい。

プロセッサは、メモリに格納されたプログラムを実行する演算装置である。プロセッサが、各種プログラムを実行することによって、処理負荷推定システム１の各機能部（例えば、ソフトウェアコンポーネント入力部１０２、テストスイート入力部１０４、シミュレーション部１０５、処理負荷推定部１０６、結果処理部１０７など）による機能が実現される。なお、プロセッサがプログラムを実行して行う処理の一部を、他の演算装置（例えば、ＡＳＩＣ、ＦＰＧＡ等のハードウェア）で実行してもよい。

メモリは、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）のような高速かつ揮発性の記憶素子であり、プロセッサが実行するプログラム及びプログラムの実行時に使用されるデータ（例えば、コスト記憶部１０８など）を一時的に格納する。

補助記憶装置は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置である。また、補助記憶装置は、プロセッサがプログラムの実行時に使用するデータ（例えば、コスト記憶部１０８としてＲＡＭに展開されるコストデータが記録されたファイルなど）、及びプロセッサが実行するプログラムを格納する。すなわち、プログラムは、補助記憶装置から読み出されて、メモリにロードされて、プロセッサによって実行されることによって、処理負荷推定システム１の各機能を実現する。

通信インターフェースは、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。

入力インターフェースは、キーボードやマウスなどの、ユーザからの入力を受けるインターフェースである。例えば、入力インターフェースは、コストデータが記録され、補助記憶装置に格納されるファイルの入力を受け付ける。また、入力インターフェースは、ＧＵＩを提供し、ユーザからコストデータの入力を受け付けてもよい。

出力インターフェースは、ディスプレイ装置やプリンタなどの、プログラムの実行結果をユーザが視認可能な形式で出力するインターフェースである。例えば、第１の実施形態に係る処理負荷推定システム１では、出力インターフェースは、結果処理部１０７が出力する演算量や処理コストを表示するためのデータを出力する。また、出力インターフェースは、プログラムの実行結果をユーザが視認可能な形式で出力するデータ出力ポートでもよい。例えば、出力インターフェースは、結果処理部１０７が出力する演算量や処理コストが表示されるレポートを所定のデータ形式（例えばｐｄｆ、ｈｔｍｌ）で出力する。

なお、処理負荷推定システム１にネットワークを介して接続された端末が入力インターフェース及び出力インターフェースを提供してもよい。

プロセッサが実行するプログラムは、リムーバブルメディア（ＣＤ－ＲＯＭ、フラッシュメモリなど）又はネットワークを介して処理負荷推定システム１に提供され、非一時的記憶媒体である不揮発性の補助記憶装置に格納される。このため、処理負荷推定システム１は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

処理負荷推定システム１は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。例えば、ソフトウェアコンポーネント入力部１０２、テストスイート入力部１０４、シミュレーション部１０５、処理負荷推定部１０６、及び結果処理部１０７は、各々別個の物理的又は論理的計算機上で動作するものでも、複数が組み合わされて一つの物理的又は論理的計算機上で動作するものでもよい。

図２は、本実施形態に係る制御モデル１０１を示すモデル図である。

制御モデル１０１は、入力ポート１０１０１、１０１０２、１０１０３、１０１０４、入力値を増幅するゲインブロック１０１０５、入力値を加算する加算ブロック１０１０６、入力値を乗算する乗算ブロック１０１０７、固定値を出力する定数ブロック１０１０８、１０１０９、１０１１０、パラメータ値を出力する定数ブロック１０１１１、１次元のテーブル検索を行い該当する結果を出力する一次元テーブル検索ブロック１０１１２、入力値を比較演算する比較演算ブロック（比較）１０１１３、入力値が等価か否かを判定する比較演算ブロック（等価）１０１１４、２番目の入力値がＴＲＵＥの場合は１番目の入力を、ＦＡＬＳＥの場合には３番目の入力を出力するスイッチブロック１０１１５、１０１１６、及び出力ポート１０１１７によって構成される。

図３は、本実施形態に係る制御モデル１０１の演算経路を示す図である。

制御モデル１０１は、三つのメイン演算経路ＭＲ１、ＭＲ２、及びＭＲ３と、二つのサブ演算経路ＳＲ１、及びＳＲ２を有している。制御モデル１０１は、制御モデルの入力ポート１０１０１、１０１０２、１０１０３、１０１０４の入力値や、定数ブロック１０１１１のパラメータ値によって実行される演算経路が異なる。メイン演算経路ＭＲ１は、サブ演算経路ＳＲ１の結果がＴＲＵＥであり、且つサブ演算経路ＳＲ２の結果がＴＲＵＥである場合に実行される経路である。メイン演算経路ＭＲ２は、サブ演算経路ＳＲ１がＦＡＬＳＥであり、且つサブ演算経路ＳＲ２がＴＲＵＥである場合に実行される経路である。メイン演算経路ＭＲ３は、サブ演算経路ＳＲ１の結果によらず、サブ演算経路ＳＲ２がＦＡＬＳＥである場合に実行される経路である。

本実施形態で利用される定数ブロック１０１１１に設定されるパラメータは、調整可能なパラメータであり、例えばキャリブレーションパラメータやコンフィギュレーションパラメータなどが考えられる。どちらも、プログラムとして実装した後に値を変更できる。キャリブレーションパラメータは、制御モデル１０１の制御性能の向上を目的とする調整可能なパラメータであり、例えば、車載電子制御装置の場合、車両走行試験などを通して適切な値に校正される。一方、コンフィギュレーションパラメータは、例えば、仕向け地、車両諸元、車両装備品などによって、車両の工場出荷時に変更されるパラメータである。

図４は、本実施形態に係るコスト記憶部１０８に含まれるコストデータベースの一例を示す図であり、演算ブロック毎の演算負荷コストが記録されるコストデータベースの一例を示す。

コスト記憶部１０８は、ゲインブロック１０１０５のコストＣ１、加算ブロック１０１０６のコストＣ２、乗算ブロック１０１０７のコストＣ３、一次元テーブル検索ブロック１０１１２のコストＣ４、比較演算ブロック（比較）１０１１３のコストＣ５、比較演算ブロック（等価）１０１１４のコストＣ６、スイッチブロック１０１１５、１０１１６のコストＣ７を予め記憶している。コスト記憶部１０８は、経路コスト評価部１０９によって参照される。なお、本実施形態では、入力ポート１０１０１、１０１０２、１０１０３、１０１０４や、定数ブロック１０１０８、１０１０９、１０１１０、１０１１１、出力ポート１０１１７は四則演算や論理演算などの演算処理を伴わないため、コストが定義されていない。

処理負荷に係るコストとは、例えば、各演算ブロックをプログラムとして実装し、マイコンシミュレータや実機マイコンを用いて予め計測した処理時間などである。この方法は、一度全ての演算ブロックの処理時間を実測してデータベースを構築すれば、その後は容易に処理負荷を推定できる。しかしながら、処理時間は、プログラムが実装される制御装置やクロック周波数によって異なるため、制御装置が変わる毎に処理負荷を再計測しなければならない課題がある。

一般に、車載電子制御装置に多く使用されるＲＩＳＣ方式のマイコンは、基本的に全ての演算は１クロックサイクルで実行され、また、最小限必要な単純な命令のみでプログラムを実行するという特徴がある。また、ＲＩＳＣ方式のマイコンの命令セットは、加減算、論理演算、比較演算、乗算など、低レベル演算の種類においては、それほど変わらない。一方で、処理時間はマイコンのクロック周波数によって大きく変化する。そこで、可能な限り様々なマイコン環境で活用でき、且つマイコンのクロック周波数が変わっても再測定することなく容易に処理負荷を推定可能とするため、各演算ブロックのコストとしてクロックサイクルを採用してもよい。１クロックサイクルの実行時間はマイコンのクロック周波数で決定されるため、マイコンのクロック周波数が変わっても、クロックサイクルから処理時間を容易に推定できる。

続いて、本実施形態における処理負荷推定部１０６の詳細について説明する。経路コスト評価部１０９は、ソフトウェアコンポーネント入力部１０２を経由して入力された制御モデル１０１を解析し、図３の三つのメイン演算経路ＭＲ１、ＭＲ２、ＭＲ３と、どのメイン演算経路が実行されるか決定する二つのサブ演算経路ＳＲ１、ＳＲ２を抽出する。その後、図４のコスト記憶部１０８に予め記憶されたコストＣ１、Ｃ２、Ｃ３、Ｃ４、Ｃ５、Ｃ６、Ｃ７を参照しながら各演算径路のコストを累積し、三つのメイン演算経路ＭＲ１、ＭＲ２、ＭＲ３の処理時間を推定する。

図５は、各メイン演算経路ＭＲ１、ＭＲ２、ＭＲ３の推定処理時間に相当する累積コストを示す図である。

メイン演算経路ＭＲ１は、サブ演算経路ＳＲ１がＴＲＵＥであり、且つサブ演算経路ＳＲ２がＴＲＵＥの時に実行されるため、メイン演算経路ＭＲ１の累積コストＣ_MR1は、メイン演算経路ＭＲ１上に配置されている演算ブロックの累積コストと、サブ演算経路ＳＲ１、ＳＲ２上に配置されている演算ブロックの累積コストの合計値で決定される。具体的には、メイン演算経路ＭＲ１の演算ブロックであるゲインブロック１０１０５のコストＣ１と、スイッチブロック１０１１５、１０１１６のコストＣ７と、サブ演算経路ＳＲ１のコストＣ_SR1と、サブ演算経路ＳＲ２のコストＣ_SR2を全て累積し、累積コストＣ_MR1は、Ｃ１＋Ｃ７＋Ｃ７＋Ｃ_SR1＋Ｃ_SR2として求められる。なお、サブ演算経路ＳＲ１のコストＣ_SR1は、サブ演算経路ＳＲ１に配置されている演算ブロックである比較演算（比較）ブロック１０１１３のコストＣ５である。

サブ演算経路ＳＲ２のコストＣ _SR2 は、サブ演算経路ＳＲ２に配置されている演算ブロックである比較演算（等価）１０１１４のコストＣ６である。よって、メイン演算経路ＭＲ１の選択時に実行される全ての演算ブロックの累積コストＣ_MR1は、Ｃ１＋Ｃ７＋Ｃ７＋Ｃ５＋Ｃ６によって求められる。同様の考え方で、メイン演算経路ＭＲ２の経路が選択される際に実行される全ての演算ブロックの累積コストＣ_MR2は、Ｃ２＋Ｃ７＋Ｃ７＋Ｃ５＋Ｃ６によって求められる。

メイン演算経路ＭＲ３は、サブ演算経路ＳＲ１の実行結果によらず、サブ演算経路ＳＲ２がＦＡＬＳＥの場合に実行される。よって、本実施形態では、ＳＲ１のコストは累積せず、メイン演算経路ＭＲ３とサブ演算経路ＳＲ２の経路上に配置されている演算ブロックの累積コストの合計値でＭＲ３の累積コストＣ_MR3を求める。具体的には、メイン演算経路ＭＲ３の演算ブロックである乗算ブロック１０１０７のコストＣ３、一次元テーブル検索ブロック１０１１２のコストＣ４、スイッチブロック１０１１５のコストＣ７と、サブ演算経路ＳＲ２のコストＣ _SR2 、つまりＣ６を全て累積し、メイン演算経路ＭＲ３の累積コストＣ_MR3を求める。よって、メイン演算経路ＭＲ３の経路が実行される際に実行される演算ブロックの累積コストは、Ｃ３＋Ｃ４＋Ｃ７＋Ｃ６によって求められる。

また、各メイン演算経路ＭＲ１、ＭＲ２、ＭＲ３の累積コストを比較し、累積コストが最も高い経路が、制御モデル１０１の理論上の最大処理時間となる経路である。同様に、累積コストが最も低い経路が、制御モデル１０１の理論上の最小処理時間となる。

但し、処理負荷推定部１０６で推定された最大処理時間と最小処理時間は、実際のユースケース、例えば実際の車両走行において、必ずしも実行される経路であるとは限らない。推定対象のモデルの入力がそのモデルの前処理で決定されるため、該当の経路を実行する入力が必ずしも生成されるとは限らないため、これらの経路が実行されない可能性がある。又は、どのようなデータを入力しても該当する経路が到達不能である場合や、調整可能なパラメータによっては、該当する経路が実行されない可能性もある。このような理由から、前述の方法で求めた最大処理時間及び最小処理時間は、実用的な範囲における最大処理時間及び最小処理時間とはならず、実用的な処理時間の推定が課題となる。また、システム全体の最大処理時間を推定する際に、個々のモデルの理論上の最大処理時間を累積して推定すると、過大な最大処理時間が推定される課題もある。

よって、結果処理部１０７は、経路コスト評価部１０９の結果に基づいて、新たにシミュレーション部１０５より得られた複数の演算結果を用いて、これらの課題を解決する。

図６に示すテストスイート１０３は、複数のテストケースの集合体であり、制御モデル１０１に入力される入力データである。入力データは、一般的に信号とパラメータの２種類に分類される。具体的には、テストスイート１０３の入力信号１、入力信号２、入力信号３、及び入力信号４は、制御モデル１０１の入力ポート１０１０１、１０１０２、１０１０３、及び１０１０４にそれぞれ入力される。また、テストスイート１０３のパラメータ１は、制御モデル１０１の定数ブロック１０１１１が出力するパラメータ値である。

シミュレーション部１０５は、入力された制御モデル１０１にテストスイート１０３を入力し、シミュレーションを行う。図７に、シミュレーション部１０５が出力するシミュレーション結果を示す。シミュレーション結果は、出力ポート１０１１７から出力されるタイムステップ毎の出力データだけでなく、どの演算経路を実行したかの情報も含む。

結果処理部１０７は、シミュレーション部１０５が出力するシミュレーション結果（図７）を分析し、複数の演算結果を算出する。更に、結果処理部１０７は、処理負荷推定部１０６が推定した演算経路毎の推定処理時間と、シミュレーション部１０５が算出した複数の演算結果を組み合わせることで、最終的な推定処理時間を決定する。

本実施形態では、結果処理部１０７が分析して得られた複数の演算量に関する値である、動的な特徴を使用し、より実用的な処理負荷を推定する。結果処理部１０７が使用する演算量に関する値として、演算負荷の平均値や、標準偏差を使用するとよい。

図８は、本発明の実施形態１に係る結果処理部１０７が実用的な最大処理負荷を推定する場合に実行する処理のフローチャートである。

結果処理部１０７は、フローチャートに示す通り、ステップＳ１０７１０１から処理を開始する。

ステップＳ１０７１０２で、結果処理部１０７は、シミュレーション部１０５からシミュレーション結果（図７）を取得する。

ステップＳ１０７１０３で、結果処理部１０７は、処理負荷推定部１０６から演算経路毎の累積コスト（図５）を取得する。

ステップＳ１０７１０４で、結果処理部１０７は、シミュレーション結果（図７）から取得したタイムステップ毎の演算経路情報と、演算経路毎の累積コスト（図５）に基づいて、テストスイートの平均累積コストを算出する。

ステップＳ１０７１０５で、結果処理部１０７は、各タイムステップの累積コストと平均累積コストを用いて累積コストのばらつき（偏差）を算出後、標準偏差を算出する。

ステップＳ１０７１０６で、結果処理部１０７は、標準偏差に係数を乗算して平均値に加えることで、実ユースケースで取り得る可能性が高い最大累積コストを推定する。

ステップＳ１０７１０７で、結果処理部１０７は、演算経路毎の累積コスト（図５）の中から、最も大きい累積コストを抽出する。

ステップＳ１０７１０８で、結果処理部１０７は、実ユースケースで取る可能性が高い最大累積コストが演算経路上の最大累積コストを超えるかを判定し、算出された最大累積コストが演算経路上の最大累積コストより小さい場合（ＮＯ）、ステップＳ１０７１０９に進み、算出された最大累積コストが演算経路上の最大累積コストを超える場合（ＹＥＳ）、ステップＳ１０７１１０に進む。

ステップＳ１０７１０９で、結果処理部１０７は、標準偏差を用いて算出された最大累積コストを最大処理時間として推定して出力する。

ステップＳ１０７１１０で、結果処理部１０７は、経路上の最大累積コストを最大処理時間として推定して出力する。

ステップＳ１０７１１１で、結果処理部１０７は、処理を終了する。

ステップＳ１０７１０４におけるテストスイートの平均累積コストＣμの算出方法について説明する。平均累積コストＣμは、テストスイートに含まれる各タイムステップの累積コストを全て合計し、総数ｎで除算することで求められる。

次に、ステップＳ１０７１０５における標準偏差σの算出方法について説明する。標準偏差を求めるには、まず偏差ｄを求める。偏差ｄは、テストスイートの各累積コストＣｉから平均累積コストＣμを減算して求めることができる。偏差ｄの算出結果の例を図９に示す。標準偏差は、偏差ｄを２乗し、データの総数ｎで除算した値の平方根で求めることができる。

標準偏差は、ばらつき具合を表す統計学の指標の一つであり、標準偏差σによって、平均に対する数値のばらつきを知ることができる。ばらつきが大きいと標準偏差σが大きくなり、ばらつきが小さいと標準偏差σが小さくなる。一般的に、平均値±σの中に観測データが含まれる確率は６８．３％、平均値±２σの中に観測データが含まれる確率は９５％、平均値±３σの中に観測データが含まれる確率は９９．７％となる。

次に、ステップＳ１０７１０８、Ｓ１０７１０９、Ｓ１０７１１０における実用的な最大処理負荷決定方法の詳細について説明する。本実施形態では、実用的な最大処理負荷ＰＣ_maxを平均累積コストＣμ、標準偏差σ、調整可能な係数ｋを用いて、以下の計算式で求める。この時、ｋは調整可能なパラメータ係数であり、システムの特徴や、テストスイートの成熟度により、ユーザで任意の値に補正することができる。但し、ステップＳ１０７１０７で抽出した経路上の最大累積コストＣ_maxは、理論上の最大累積コストとなるため、標準偏差を用いて算出した結果がＣ_maxを超えてはならない。標準偏差を用いて算出した最大累積コストが理論上の最大累積コストＣ_maxを超える場合には、実用的な最大処理負荷ＰＣ_maxをＣ_maxとする。

実施形態１に係るばらつきを考慮した処理負荷推定システムによると、図１０に示すような領域における動的な特徴であるばらつきを考慮して実用的な最大処理時間を求めることができる。なお、本実施形態では実用的な最大処理時間を推定するシステムについて説明したが、同様の手法を用いることで、実用的な最小処理時間も算出できる。

本実施形態によれば、実際のユースケースでは実行されない経路を排除できるだけでなく、入力されたテストスイートの実ユースケースのカバー率が低い場合でも、標準偏差を用いることで実運用の範囲で最大処理時間を統計学の観点から予測できる。これにより、従来の課題であった、各モデルの理論上の最大処理時間を累積してシステム全体の最大処理時間を予測する場合に、予測結果が過剰となる問題を抑制できる。

本実施形態では、標準偏差を用いて推定した処理時間を出力する場合について特に焦点を当てて説明したが、図８のフローチャートのステップＳ１０７１０４で算出した平均累積コストを平均処理時間として推定してもよい。

また、テストスイートの実ユースケースのカバー率が高い場合には、標準偏差を用いずに、図１０のテストスイート内の最大処理時間や最小処理時間を、実用的な最大処理時間、最小処理時間として推定してもよい。

（第２の実施形態）
第２の実施形態では、ソフトウェアコンポーネント１００が、プログラム２０１である場合について、制御モデル１０１だけではなく、プログラム２０１においても同様に実用的な処理負荷を推定できることを説明する。第２の実施形態では、主に第１の実施形態との差分について説明し、第１の実施形態と同じ構成及び処理の説明は省略する。

図１１Ａは、本実施形態に係るプログラム２０１のフローチャートであり、図１１Ｂは、本実施形態に係るプログラム２０１の演算経路の例を示す図である。

プログラム２０１は、フローチャートに示す通り、ステップＳ２０１０１から処理を開始する。

ステップＳ２０１０２で、プログラム２０１は、条件１を満たすかを判定し、条件１を満たす場合（ＹＥＳ）、ステップＳ２０１０３に進み、条件１を満たさない場合（ＮＯ）、ステップＳ２０１０４に進む。

ステップＳ２０１０３で、プログラム２０１は、命令１を実行後、ステップＳ２０１０４に進む。

ステップＳ２０１０４で、プログラム２０１は、条件２を満たすかを判定し、条件２を満たす場合（ＹＥＳ）、ステップＳ２０１０５に進み、条件２を満たさない場合（ＮＯ）、ステップＳ２０１０６に進む。

ステップＳ２０１０５で、プログラム２０１は、命令２を実行する。

ステップＳ２０１０６で、プログラム２０１は、命令３を実行する。

ステップＳ２０１０７で、プログラム２０１は、処理を終了する。

図１１Ｂに示す通り、プログラム２０１の演算経路は、分岐１と分岐３が実行される演算経路Ｒ１、分岐１と分岐４が実行される演算経路Ｒ２、分岐２と分岐３が実行される演算経路Ｒ３、分岐２と分岐４が実行される演算経路Ｒ４の四つの経路がある。よって、プログラム２０１は、複数の演算経路を有しており、入力によって条件判定の結果が変化し、実行される経路が異なる点で、制御モデル１０１と同様に扱える。

図１２は、本実施形態に係るコスト記憶部１０８に含まれるコストデータベースの一例を示す図であり、ＣＰＵ演算要素毎の演算負荷コストが記録されるコストデータベースの一例を示す。

第１の実施形態に係るコスト記憶部１０８は、演算ブロック毎のコスト記憶するのに対し、本実施形態に係るコスト記憶部１０８は、プログラム２０１を構成するＣＰＵの演算要素毎の処理負荷をコストとして記憶する。例えば、加算（ＡＤＤ）はＣ２３、乗算（ＭＵＬ）はＣ２５のように、ユーザが任意にコストを定義できる。

本実施形態に係るプログラム２０１用のコスト記憶部１０８では、ＣＰＵの演算要素に対応してコストを記憶するが、例えば四則演算などの演算子毎にコストを記憶してもよい。

続いて、プログラム２０１が入力された場合の経路コスト評価部１０９の動作の詳細を説明する。実施形態１では、経路毎のブロックのコストを累積したが、本実施形態では演算経路毎のＣＰＵの演算要素のコストを累積する。

経路コスト評価部１０９は、例えば、プログラム２０１の構文を解析して、各演算経路のＣＰＵの演算要素を抽出してもよい。又は、プログラムをコンパイルしてアセンブラレベルに変換し、ＣＰＵの演算要素を抽出してもよい。

以上のように、制御モデル１０１から処理負荷を推定するより、プログラム２０１から処理負荷を推定する方が、実際の動作に近い演算要素を用いて処理負荷を推定でき、より高精度な処理負荷を推定できる。一方で、プログラム２０１を設計してからでないと処理負荷を推定できないため、制御モデル１０１を用いた手法と比べて大きな手戻りが発生する懸念がある。

本実施形態によれば、制御モデル１０１だけではなく、プログラム２０１においても同様に実用的な処理負荷を推定できることを説明した。

（第３の実施形態）
第３の実施形態では、結果処理部１０７で分析して得られた複数の演算結果の一つとして、動的な特徴である各演算経路の通過情報を活用し、より実用的な処理負荷を推定する。具体的には、結果処理部１０７が、通過情報に基づいて、実行されない演算経路を特定し、実行されない演算経路を推定対象から除外することで、より実用的な処理時間を推定する。なお、第３の実施形態では、主に前述した実施形態との差分について説明し、前述した実施形態と同じ構成及び処理の説明は省略する。また、ソフトウェアコンポーネント１００は、制御モデル１０１でもプログラム２０１でもどちらでもよいが、第３の実施形態では制御モデル１０１を例として説明する。

図１３は、本実施形態に係る結果処理部１０７が実行する処理のフローチャートである。

結果処理部１０７は、フローチャートに示す通り、ステップＳ１０７２０１から処理を開始する。

ステップＳ１０７２０２で、結果処理部１０７は、シミュレーション部１０５からシミュレーション結果（図７）を取得する。

ステップＳ１０７２０３で、結果処理部１０７は、処理負荷推定部１０６から演算経路毎の累積コスト（図５）を取得する。

ステップＳ１０７２０４で、結果処理部１０７は、シミュレーション部１０５によるシミュレーションの結果を解析し、実行されていない演算経路を特定する。

ステップＳ１０７２０５で、結果処理部１０７は、実行されない演算経路が存在するか否かを判定し、実行されない演算経路が存在する場合（ＹＥＳ）、ステップＳ１０７２０６に進み、実行されない演算経路が存在しない場合（ＮＯ）、ステップＳ１０７２０７に進む。

ステップＳ１０７２０６で、結果処理部１０７は、シミュレーション部１０５より得られた各演算経路の累積コストのうち、実行されない演算経路の累積コスト以外の累積コストを用いて処理時間を推定する。

ステップＳ１０７２０７で、結果処理部１０７は、シミュレーション部１０５より得られた各演算経路の累積コストをそのまま利用して処理時間を推定する。

ステップＳ１０７２０８で、結果処理部１０７は、処理を終了する。

例えば、実行されない演算経路を除いた累積コストの中で最も大きな累積コストを最大処理時間として推定してもよい。また、実行されない演算経路を除いた累積コストの中で最も小さい累積コストを最小処理時間として推定してもよい。また、実行されない演算経路を除いた累積コストの平均値を算出し、平均処理負荷として推定してもよい。

本実施形態によれば、実際のユースケースでは実行されない経路を除外して、より実用的で高精度に処理時間を推定できる。

（第４の実施形態）
第４の実施形態では、結果処理部１０７で分析して得られた複数の演算結果の一つとして、動的な特徴である各演算経路の通過頻度を表す通過率を活用し、より実用的な処理負荷を推定する。具体的には、結果処理部１０７は、所定の閾値より通過率が小さい場合は推定対象から除外することでより実用的な処理時間を推定するシステムについて説明する。なお、第４の実施形態では、主に前述した実施形態との差分について説明し、前述した実施形態と同じ構成及び処理の説明は省略する。また、ソフトウェアコンポーネント１００は、制御モデル１０１でもプログラム２０１でもどちらでもよいが、第４の実施形態では制御モデル１０１を例として説明する。

図１４は、本実施形態に係る結果処理部１０７が実行する処理のフローチャートである。

結果処理部１０７は、フローチャートに示す通り、ステップＳ１０７３０１から処理を開始する。

ステップＳ１０７３０２で、結果処理部１０７は、シミュレーション部１０５からシミュレーション結果（図７）を取得する。

ステップＳ１０７３０３で、結果処理部１０７は、処理負荷推定部１０６から演算経路毎の累積コスト（図５）を取得する。

ステップＳ１０７３０４で、結果処理部１０７は、シミュレーション部１０５によるシミュレーションの結果を解析し、各演算経路の通過率を算出する。

ステップＳ１０７３０５で、結果処理部１０７は、各演算経路の通過率とユーザが予め設定した閾値とを比較し、通過率が小さい演算経路が存在するかを判定し、通過率が小さい演算経路が存在する場合（ＹＥＳ）、ステップＳ１０７３０６に進み、通過率が小さい演算経路が存在しない場合（ＮＯ）、ステップＳ１０７３０７に進む。

ステップＳ１０７３０６で、結果処理部１０７は、通過率が小さい演算経路を除いた演算経路の累積コストを用いて処理時間を推定する。

ステップＳ１０７３０７で、結果処理部１０７は、全演算経路の累積コストを用いて処理時間を推定する。

ステップＳ１０７３０８で、結果処理部１０７は、処理を終了する。

図１５は、制御モデル１０１の場合の通過率の一例を示す図である。

制御モデル１０１の演算経路ＭＲ１、ＭＲ２、ＭＲ３の通過率がそれぞれ、３９．９９９９％、６０．０％、０．０００１％である場合、ステップＳ１０７３０５で通過率の閾値が０．００１％である場合、演算経路ＭＲ３の通過率は閾値を下回っているため、演算経路ＭＲ３の累積コストは除外され、ＭＲ１とＭＲ２の累積コストを用いて処理負荷を推定する。

例えば、通過率が閾値より小さい演算経路を除いた累積コストの中で最も大きな累積コストを最大処理時間として推定してもよい。又は、通過率が閾値より小さい演算経路を除いた累積コストの中で最も小さい累積コストを最小処理時間として推定してもよい。また、通過率が閾値より小さい演算経路を除いた累積コストの平均値を算出し、平均処理負荷として推定してもよい。

システム全体の最大処理時間、最小処理時間となるタイミングにおいて、各ソフトウェアコンポーネントの中で実行頻度が低い演算経路が実行される可能性は極めて小さい。本実施形態によれば、実際のユースケースでは実行される可能性があるが、実行頻度が低い演算経路を除外することで、前述の問題を解決し、システム全体の最大処理負荷や最小処理負荷の推定精度を向上できる。

（第５の実施形態）
第５の実施形態では、処理負荷推定部１０６がメモリアクセスの通信遅延時間であるレイテンシを考慮して処理負荷を推定するシステムについて説明する。なお、第５の実施形態では、主に前述した実施形態との差分について説明し、前述した実施形態と同じ構成及び処理の説明は省略する。また、ソフトウェアコンポーネント１００は、制御モデル１０１でもプログラム２０１でもどちらでもよいが、第５の実施形態では制御モデル１０１を例として説明する。

図１６は、本発明の第５の実施形態に係るソフトウェアコンポーネントの処理負荷推定システム１のシステム構成図である。第１の実施形態のシステム構成図（図１）と異なる点は、処理負荷推定部１０６にメモリ解析部５０１が追加されている点である。

メモリ解析部５０１は、メモリ属性としてソフトウェアコンポーネント１００のメモリアクセスに関係する演算要素を抽出し、経路コスト評価部１０９に送る。経路コスト評価部１０９は、メモリ解析部５０１の抽出結果を取得し、予め記憶されたメモリアクセスのレイテンシのコストをコスト記憶部１０８から読み出し、各演算経路の累積コストと共に、レイテンシのコストを累積する。

図２に示す制御モデル１０１の入力ポート１０１０１、１０１０２、１０１０３、１０１０４が制御モデル１０１の入力インターフェースであり、出力ポート１０１１７が制御モデル１０１の出力インターフェースである。例えば、入出力インターフェースをグローバル変数アクセスとしてプログラムを設計する場合、入力ポート１０１０１、１０１０２，１０１０３、１０１０４に対しグローバル変数の読み出し処理のレイテンシに相当するコストを割り当て、出力ポート１０１１７に対しグローバル変数の書き込み処理のレイテンシに相当するコストを割り当てる。

図２に示す制御モデル１０１のパラメータ値を出力する定数ブロック１０１１１は、パラメータを読み込む。本実施形態では、例えばキャリブレーションパラメータをメモリ領域から読み出すレイテンシに相当するコストを定数ブロック１０１１１に割り当てる。

図１７は、本実施形態に係るコスト記憶部１０８に含まれるコストデータベースの一例を示す図であり、メモリ演算ブロック毎の演算負荷コストが記録されるコストデータベースの一例を示す。

経路コスト評価部１０９は、ユーザが予め定めた適用条件に該当するブロックをメモリ演算ブロックとして検出し、メモリ演算ブロックのコストもあわせて演算ブロックのコストを累積して、演算経路毎の累積コストを算出する。例えば、メイン演算経路ＭＲ１は、入力ポート１０１０１のグローバル変数を読み込み、定数ブロック１０１１１のパラメータ読み込み、出力ポート１０１１７のグローバル変数を書き込むレイテンシに相当するコストが加算される。よって、メイン演算経路ＭＲ１が選択される際に実行される全ての演算ブロックとメモリ演算ブロックの累積コストＣ_MR1は、Ｃ５１＋Ｃ１＋Ｃ７＋Ｃ７＋Ｃ５＋Ｃ５３＋Ｃ６＋Ｃ５２によって求められる。同様に、メイン演算経路ＭＲ２が選択される際に実行される全ての演算ブロックとメモリ演算ブロックの累積コストＣ_MR2は、Ｃ５１＋Ｃ５１＋Ｃ２＋Ｃ７＋Ｃ７＋Ｃ５＋Ｃ５３＋Ｃ６＋Ｃ５２によって求められる。また、メイン演算経路ＭＲ３が選択される際に実行される全ての演算ブロックとメモリ演算ブロックの累積コストＣ_MR3は、Ｃ５１＋Ｃ３＋Ｃ４＋Ｃ７＋Ｃ５３＋Ｃ６＋Ｃ５２によって求められる。

本実施形態によれば、演算に伴う処理時間の他、メモリアクセスのレイテンシを考慮することで、より高精度に処理時間を推定できる。

（第６の実施形態）
第６の実施形態では、処理負荷推定部１０６が、予め記憶された特定のブロックの組み合わせを検出した場合、本来のコストとは異なるコスト（特定のブロックの組み合わせに対応付けられたコスト）に補正して処理負荷を推定するシステムについて説明する。なお、第６の実施形態では、主に前述した実施形態との差分について説明し、前述した実施形態と同じ構成及び処理の説明は省略する。また、ソフトウェアコンポーネント１００は、制御モデル１０１でもプログラム２０１でもどちらでもよいが、第６の実施形態では制御モデル１０１を例として説明する。

図３に示すサブ演算経路ＳＲ２では、比較演算ブロック（等価）１０１１４が、パラメータが１であるかを判定し、判定結果である論理値をスイッチブロック１０１１６に入力する。その後、スイッチブロックでは、入力された論理値を判定し、論理値に応じて経路を選択する。この時、比較演算ブロック（等価）１０１１４とスイッチブロック１０１１６のそれぞれで処理が発生するため、それぞれのコストが累積される。

しかし、実際のプログラムでは、比較演算ブロック（等価）１０１１４による比較演算処理は省略され、スイッチブロック１０１１６の処理の中で、具体的にはｉｆ文の条件式でパラメータがＴＲＵＥかＦＡＬＳＥか直接判定するようにプログラムが設計されるのが一般的である。よって、このようなモデルからプログラムに変換される過程で生じる最適化を考慮するために、例えば、比較演算ブロックからスイッチブロックの流れでモデリングされている場合、経路コスト評価部１０９が比較演算ブロック１０１１４のコストと、スイッチブロック１０１１６のコストを単に参照して累積せず、新たなコストを参照する。また、コスト記憶部１０８は、予め、比較演算ブロック１０１１４とスイッチブロック１０１１６とを組み合わせたコストを記憶する。

本実施形態によれば、最適化の影響を考慮した累積コストを算出でき、実際の動作に近づくことで、より高精度に処理負荷を推定できる。

（第７の実施形態）
第７の実施形態では、処理負荷推定部１０６がデータフローを考慮して処理負荷を推定するシステムについて説明する。なお、第７の実施形態では、主に前述した実施形態との差分について説明し、前述した実施形態と同じ構成及び処理の説明は省略する。また、ソフトウェアコンポーネント１００は、制御モデル１０１でもプログラム２０１でもどちらでもよいが、第７の実施形態では制御モデル１０１を例として説明する。

図１８は、本発明の実施形態に係るデータフローを考慮したソフトウェアコンポーネントの処理負荷推定システム１を示すシステム構成図である。第１の実施形態に係る処理負荷推定システム（図１）と、処理負荷推定部１０６にデータフロー解析部７０１が新たに追加される点で異なる。

データフロー解析部７０１は、図１９に示すような制御モデル１０１のデータフローを解析し、ブロックとブロックを接続する信号線のデータ型を特定する。更に、ゲインブロック１０１０５や、定数ブロック１０１０８、１０１０９、１０１１０、１０１１１、一次元テーブル検索ブロック１０１１２などの定数やパラメータが設定されているブロックを解析し、設定されている定数やパラメータのデータ型を特定する。

図２０は、本実施形態に係るコスト記憶部１０８に含まれるコストデータベースの一例を示す図であり、演算ブロック毎の演算負荷コストが記録されるコストデータベースの一例を示す。

図２０に示すように、各演算の処理時間はデータ型によって異なるため、予め各データ型のコストをコスト記憶部１０８に記憶する。更に、型変換のサイクル数もデータ型によって異なるため、型変換のサイクル数を予めコスト記憶部１０８に記憶する。

図２１は、本実施形態に係る経路コスト評価部１０９が実行する処理のフローチャートである。

経路コスト評価部１０９は、フローチャートに示す通り、ステップＳ１０９７０１から処理を開始する。

ステップＳ１０９７０２で、経路コスト評価部１０９は、信号線のデータ型やブロックに設定されている定数やパラメータのデータ型の情報を含むモデル情報を、データフロー解析部７０１から取得する。

ステップＳ１０９７０３で、経路コスト評価部１０９は、データ型の情報を含むモデル情報から制御モデル１０１に含まれる全演算ブロックとその入力データ型を特定する。

ステップＳ１０９７０４で、経路コスト評価部１０９は、コスト記憶部１０８を参照し、演算ブロックとデータ型の組み合わせに応じたコストをそれぞれ取得する。

ステップＳ１０９７０５で、経路コスト評価部１０９は、データの型変換が発生している箇所を特定する。

ステップＳ１０９７０６で、経路コスト評価部１０９は、コスト記憶部１０８を参照し、データの型変換の種類に応じたコストをそれぞれ取得する。

ステップＳ１０９７０７で、経路コスト評価部１０９は、ステップＳ１０９７０４で取得した演算ブロックとデータ型の組み合わせに応じたコストと、ステップＳ１０９７０６で取得したデータの型変換のコストを演算経路毎に全て累積し、演算経路毎の累積コストを算出する。

ステップＳ１０９７０８で、経路コスト評価部１０９は、処理を終了する。

例えば、図１９に示すゲインブロック１０１０５の入力データ型はｄｏｕｂｌｅ型であり、且つゲインブロック１０１０５に設定されている定数値１０もｄｏｕｂｌｅ型である。このとき、ステップＳ１０９７０３では、ゲインブロック１０１０５とｄｏｕｂｌｅ型の組み合わせを特定し、ステップＳ１０９７０４において、図２０に示すコスト記憶部１０８のデータベースからゲインブロックｄｏｕｂｌｅ型のコストであるＣ１２を選択する。

また、例えば、図１９のゲインブロック１０１０５の入力データ型はｄｏｕｂｌｅ型、ゲインブロック１０１０５に設定されている定数値１０もｄｏｕｂｌｅ型、出力信号のデータ型はｓｉｎｇｌｅ型である。よって、ｄｏｕｂｌｅ型からｓｉｎｇｌｅ型へデータの型変換が１回発生しており、このようなデータの型変換はステップＳ１０９７０５で特定される。その後、ステップＳ１０９７０６において、図２０に示すコスト記憶部１０８のデータベースから、ｄｏｕｂｌｅ型からｓｉｎｇｌｅ型に変換する際のコストＣ９１を選択する。

以上のような考え方を適用して、メイン演算経路ＭＲ１の経路が選択される際に実行される全ての演算ブロックの累積コストＣ_MR1は、Ｃ１２＋Ｃ９１＋Ｃ７１＋Ｃ７１＋Ｃ５１＋Ｃ６１となる。

本実施形態によれば、ブロック情報だけでは推定できなかった処理負荷を、データ型を考慮して推定でき、演算ブロック情報だけの場合に比べて、高精度に処理負荷を推定できる。

なお、第７の実施形態は、必ずしもシミュレーション部１０５や、結果処理部１０７を必要とせず、処理負荷推定部１０６のみで独立して実施できる。

以上、本発明の複数の実施形態を説明したが、２以上の実施形態を任意に組み合わせることができる。

以上に説明したように、本発明の実施形態によると、設計工程の上流において早い段階でより高精度で平均処理時間、最小処理時間、最大処理時間等の性能を推定でき、手戻り防止による開発工数を削減できる。また、実際のユースケースを考慮した実用的な処理時間を提供することで、ソフトウェアコンポーネント単体だけでなく、システム全体の性能評価にも活用できる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１００：ソフトウェアコンポーネント、１０１：制御モデル、１０２：ソフトウェアコンポーネント入力部、１０３：テストスイート、１０４：テストスイート入力部、１０５：シミュレーション部、１０６：処理負荷推定部、１０７： 結果処理部、１０８：コスト記憶部、１０９：経路コスト評価部、２０１：プログラム、５０１：メモリ解析部、７０１：データフロー解析部

Claims (15)

1. 処理負荷推定システムであって、
   所定の処理を実行する演算装置と、前記演算装置がアクセス可能な記憶装置とを備え、
   予め定められた演算フローを実現する複数の演算要素を有し入力値に応じて演算経路が異なるソフトウェアコンポーネントが入力されるソフトウェアコンポーネント入力部と、
   前記ソフトウェアコンポーネントに与えるテストスイートが入力されるテストスイート入力部と、
   前記演算装置が、前記演算経路毎の処理負荷を推定する処理負荷推定部と、
   前記演算装置が、前記テストスイートに基づいて、前記ソフトウェアコンポーネントのシミュレーションを行い、複数のシミュレーション結果から得られる動的な特徴を出力するシミュレーション部と、
   前記演算装置が、前記シミュレーション部から出力された動的な特徴を処理する結果処理部と、を有し、
   前記結果処理部は、前記動的な特徴と、前記入力値に対応する複数の演算結果と、前記経路毎の処理負荷とに基づいて、前記ソフトウェアコンポーネントの実用処理負荷を推定することを特徴とする処理負荷推定システム。
2. 請求項１に記載の処理負荷推定システムであって、
   前記演算要素は、前記ソフトウェアコンポーネントを構成するモデルにおける演算ブロックであることを特徴とする処理負荷推定システム。
3. 請求項１に記載の処理負荷推定システムであって、
   前記演算要素は、前記ソフトウェアコンポーネントを構成するソフトウェアにおける演算子であることを特徴とする処理負荷推定システム。
4. 請求項１に記載の処理負荷推定システムであって、
   前記結果処理部は、前記シミュレーション結果から動的な特徴として得られる演算量に関する値に基づいて、前記実用処理負荷を推定することを特徴とする処理負荷推定システム。
5. 請求項１に記載の処理負荷推定システムであって、
   前記結果処理部は、前記シミュレーションによって得られた演算負荷のばらつきから算出された標準偏差に基づいて、前記実用処理負荷を推定することを特徴とする処理負荷推定システム。
6. 請求項１に記載の処理負荷推定システムであって、
   前記結果処理部は、前記ソフトウェアコンポーネントに基づく理論上の演算経路のうち前記シミュレーションで通過しなかった演算経路を除外して、前記実用処理負荷を推定することを特徴とする処理負荷推定システム。
7. 請求項１に記載の処理負荷推定システムであって、
   前記結果処理部は、前記シミュレーションにおける各演算経路の通過頻度に基づいて、前記実用処理負荷を推定することを特徴とする処理負荷推定システム。
8. 請求項７に記載の処理負荷推定システムであって、
   前記結果処理部は、前記シミュレーションにおける通過頻度が所定の閾値以下である演算経路を除外して前記実用処理負荷を推定することを特徴とする処理負荷推定システム。
9. 請求項１から８のいずれか一つに記載の処理負荷推定システムであって、
   前記処理負荷推定部は、前記演算要素の処理負荷を記憶するコスト記憶部と、前記演算経路毎のコストを累積した累積コストを計算する経路コスト評価部と、を有し、
   前記経路コスト評価部は、前記累積コストに基づいて前記演算経路毎の処理負荷を推定することを特徴とする処理負荷推定システム。
10. 請求項９に記載の処理負荷推定システムであって、
    前記処理負荷推定部は、前記ソフトウェアコンポーネントのメモリ属性に関する演算要素を解析するメモリ解析部を有し、
    前記コスト記憶部は、前記メモリ解析部より得られた前記ソフトウェアコンポーネントの前記メモリ属性毎の書き込み及び読み込みの遅延時間に相当するコストを記憶し、
    前記処理負荷推定部は、前記遅延時間を考慮して処理負荷を推定することを特徴とする処理負荷推定システム。
11. 請求項９に記載の処理負荷推定システムであって、
    前記コスト記憶部は、特定の演算要素の組合せのコストを記憶し、
    前記経路コスト評価部は、
    特定の演算要素の組合せを検出し、
    前記検出された前記特定の演算要素の組合せに対応付けられたコストを用いて、前記演算経路毎の処理負荷を推定することを特徴とする処理負荷推定システム。
12. 請求項９に記載の処理負荷推定システムであって、
    前記処理負荷推定部は、データフローを解析するデータフロー解析部を有し、
    前記経路コスト評価部は、前記データフロー解析部よる解析結果に基づいて、前記演算経路毎の処理負荷を推定することを特徴とする処理負荷推定システム。
13. 請求項１２に記載の処理負荷推定システムであって、
    前記コスト記憶部は、データ型の違いに応じて異なるコストを記憶し、
    前記経路コスト評価部は、前記データ型の違いに応じたコストを用いて、前記演算経路毎の処理負荷を推定することを特徴とする処理負荷推定システム。
14. 請求項１２に記載の処理負荷推定システムであって、
    前記コスト記憶部は、データ型の変換のコストを記憶し、
    前記データフロー解析部は、データ型の変換を検出し、
    前記経路コスト評価部は、前記データ型の変換の違いに応じてコストを用いて、前記演算経路毎の処理負荷を推定することを特徴とする処理負荷推定システム。
15. 処理負荷推定システムが実行する処理負荷推定方法であって、
    前記処理負荷推定システムは、所定の処理を実行する演算装置と、前記演算装置がアクセス可能な記憶装置とを有し、
    前記処理負荷推定方法は、
    前記処理負荷推定システムが、予め定められた演算フローを実現する複数の演算要素を有し入力値に応じて演算経路が異なるソフトウェアコンポーネントが入力されるソフトウェアコンポーネント入力手順と、
    前記ソフトウェアコンポーネントに与えるテストスイートが入力されるテストスイート入力手順と、
    前記演算装置が、前記演算経路毎の処理負荷を推定する処理負荷推定手順と、
    前記演算装置が、前記テストスイートに基づいて、前記ソフトウェアコンポーネントのシミュレーションを行い、複数のシミュレーション結果から得られる動的な特徴を出力するシミュレーション手順と、
    前記演算装置が、前記シミュレーション手順で出力された動的な特徴を処理する結果処理手順と、を有し、
    前記結果処理手順では、前記演算装置が、前記動的な特徴と、前記入力値に対応する複数の演算結果と、前記経路毎の処理負荷とに基づいて、前記ソフトウェアコンポーネントの実用処理負荷を推定することを特徴とする処理負荷推定方法。