JP2018156294A - ソフトウェア検証装置およびソフトウェア検証プログラム - Google Patents

Abstract

【課題】環境シミュレータにてモデルの変更が発生した場合にも共通のインタフェース関数を変更なしで使用できるようにする。【解決手段】ソフトウェア検証装置４０は、動作検証部１０と、モニタ部２０と、環境シミュレータ部３０とを備える。環境シミュレータ部３０は、制御ソフトウェアを搭載する実機ハードウェアを模擬する。動作検証部１０は、環境シミュレータ部３０で動作する制御ソフトウェアを検証する。モニタ部２０は、動作検証部１０の各機能部から環境シミュレータ部３０にアクセスするためのインタフェース関数を共通のインタフェース関数として１つにまとめ、環境シミュレータ部３０の各モデルと各モデルに含まれるリソースとのマッピング情報５０を管理する。【選択図】図１

Description

本発明は、ソフトウェア検証装置およびソフトウェア検証プログラムに関するものである。

従来、組み込み制御ソフトウェアの開発プロセスでは、実機ハードウェアが完成した後に、事前に実装した制御ソフトウェアを、完成した実機ハードウェアに搭載して、デバッグ作業、具体的にはハードウェアの不具合検出および動作確認、あるいは、制御ソフトウェアの修正等の作業を行う。これは、組み込み系のソフトウェアは、ハードウェアを制御することが目的であるために、制御対象となる実機ハードウェアがないと、動作確認等の機能検証ができないためである。

しかし、このような開発プロセスにおいては、実装する制御ソフトウェアに関して、都度デバッグ等の機能確認を行うことはできず、開発後段にてハードウェア実機に関わる障害が発見され、手戻り工数が大きくなってしまうという問題がある。

このような問題の解決策として、実機ハードウェアを模擬する環境シミュレータを構築し、動作検証処理部と環境シミュレータとを用いてソフトウェアの動作検証を行う手法が従来技術としてある。

特許文献１に記載の技術では、ソフトウェアの動作検証を行う際に、検証対象装置として実機ハードウェアを使用できる場合と、実機ハードウェアがない状況でソフトウェアの動作検証が可能となる環境シミュレータを使う場合とを想定して、動作検証処理部と検証対象装置との間に共通インタフェースライブラリ部を用意している。共通インタフェースライブラリ部は、実機ハードウェアと環境シミュレータとの差異を吸収するライブラリである。特許文献１に記載の技術では、共通インタフェースライブラリ部を利用することで、検証対象の違いに依存する変更を効率的に行っている。

特開２０１０−１５７１０３号公報

特許文献１に記載の技術では、環境シミュレータそのものの内部構成に変更があった場合に、共通インタフェースライブラリ部を変更しなければならない。

本発明は、環境シミュレータにてモデルの変更が発生した場合にも共通のインタフェース関数を変更なしで使用できるようにすることを目的とする。

本発明の一態様に係るソフトウェア検証装置は、
ソフトウェアを搭載するハードウェアに備えられる複数のハードウェア部品を個別のモデルとして模擬し、模擬に際して、前記ソフトウェアの動作によって各モデルに与えられる値を保持する１つ以上のリソースを、各モデルに割り当てる環境シミュレータ部と、
共通のインタフェース関数を呼び出すことで、前記インタフェース関数のパラメータとして名前を指定したリソースにアクセスし、前記ソフトウェアの動作を個別の方式によって検証する複数の機能部を有する動作検証部と、
各モデルと前記環境シミュレータ部により割り当てられたリソースとの対応を示すマッピング情報を取得してメモリに格納し、各リソースの名前を前記複数の機能部に通知し、前記インタフェース関数が呼び出される度に、前記メモリに格納したマッピング情報を参照して、前記インタフェース関数のパラメータとして名前が指定されたリソースに対応するモデルを特定し、当該リソースへのアクセスを、特定したモデルに要求し、要求に対する応答を受け取って前記インタフェース関数の呼び出し元の機能部に返すモニタ部とを備える。

本発明では、各機能部から各モデルのリソースへアクセスするための共通のインタフェース関数が呼び出される度に、リソースへのアクセスを仲介するモニタ部に、モデルとリソースとの対応を示すマッピング情報を参照させる。このため、環境シミュレータ部にてモデルの変更が発生した場合にも共通のインタフェース関数を変更なしで使用できる。

実施の形態１に係るソフトウェア検証装置の構成を示すブロック図。 実施の形態１に係るリソース名とモデルとのマッピング例を示す図。 実施の形態１に係るソフトウェア検証装置の動作を示すフローチャート。 実施の形態１に係る共通のインタフェース関数の呼び出し例を示す図。 実施の形態２に係るソフトウェア検証装置の構成を示すブロック図。

以下、本発明の実施の形態について、図を用いて説明する。各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。なお、本発明は、以下に説明する実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。例えば、以下に説明する実施の形態のうち、２つ以上の実施の形態が組み合わせられて実施されても構わない。あるいは、以下に説明する実施の形態のうち、１つの実施の形態または２つ以上の実施の形態の組み合わせが部分的に実施されても構わない。

実施の形態１．
本実施の形態について、図１から図４を用いて説明する。

＊＊＊構成の説明＊＊＊
図１および図２を参照して、本実施の形態に係るソフトウェア検証装置４０の構成を説明する。

ソフトウェア検証装置４０は、コンピュータである。ソフトウェア検証装置４０は、プロセッサ４１を備えるとともに、メモリ４２、入力インタフェース４３および出力インタフェース４４といった他のハードウェアを備える。プロセッサ４１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

ソフトウェア検証装置４０は、機能要素として、動作検証部１０と、モニタ部２０と、環境シミュレータ部３０とを備える。動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能は、ソフトウェアにより実現される。

動作検証部１０は、手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３および性能解析機能部１４といった複数の機能部を有する。

環境シミュレータ部３０は、ＣＰＵモデル３１、デバイスＡモデル３２、デバイスＢモデル３３およびプラントモデル３４といった複数のモデルを有する。「ＣＰＵ」は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略語である。

手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３および性能解析機能部１４から、ＣＰＵモデル３１、デバイスＡモデル３２、デバイスＢモデル３３およびプラントモデル３４の保持する各リソースに対しての値の取得および設定は、モニタ部２０に用意された共通のインタフェース関数を呼び出すことで実現する。手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３および性能解析機能部１４の各機能部は、対象のリソース名をパラメータとして持たせて共通のインタフェース関数を呼び出す。本実施の形態では、共通のインタフェース関数として、値を取得するｇｅｔＶａｌｕｅ（）関数と、値を設定するｓｅｔＶａｌｕｅ（）関数とがある。

プロセッサ４１は、各種処理を行うＩＣである。「ＩＣ」は、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。プロセッサ４１は、例えば、ＣＰＵである。

メモリ４２には、マッピング情報５０が記憶される。マッピング情報５０は、後述するように、環境シミュレータ部３０の各モデルと環境シミュレータ部３０により割り当てられたリソースとの対応を示す情報である。メモリ４２は、例えば、フラッシュメモリまたはＲＡＭである。「ＲＡＭ」は、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略語である。

入力インタフェース４３は、図示していない入力装置が接続されるインタフェースである。入力装置は、例えば、マウス、キーボードまたはタッチパネルである。

出力インタフェース４４は、図示していない出力装置が接続されるインタフェースである。出力装置は、例えば、ディスプレイまたはプリンタである。

ソフトウェア検証装置４０は、ハードウェアとして、通信装置を備えていてもよい。

通信装置は、データを受信するレシーバおよびデータを送信するトランスミッタを含む。通信装置は、例えば、通信チップまたはＮＩＣである。「ＮＩＣ」は、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄの略語である。

メモリ４２には、動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能を実現するプログラムであるソフトウェア検証プログラムが記憶されている。ソフトウェア検証プログラムは、プロセッサ４１に読み込まれ、プロセッサ４１によって実行される。メモリ４２には、ＯＳも記憶されている。「ＯＳ」は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍの略語である。プロセッサ４１は、ＯＳを実行しながら、ソフトウェア検証プログラムを実行する。なお、ソフトウェア検証プログラムの一部または全部がＯＳに組み込まれていてもよい。

ソフトウェア検証プログラムおよびＯＳは、補助記憶装置に記憶されていてもよい。補助記憶装置は、例えば、フラッシュメモリまたはＨＤＤである。「ＨＤＤ」は、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略語である。補助記憶装置に記憶されているソフトウェア検証プログラムおよびＯＳは、メモリ４２にロードされ、プロセッサ４１によって実行される。

ソフトウェア検証装置４０は、プロセッサ４１を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、ソフトウェア検証プログラムの実行を分担する。それぞれのプロセッサは、プロセッサ４１と同じように、各種処理を行うＩＣである。

動作検証部１０、モニタ部２０および環境シミュレータ部３０の処理の結果を示す情報、データ、信号値および変数値は、メモリ４２、補助記憶装置、または、プロセッサ４１内のレジスタまたはキャッシュメモリに記憶される。

ソフトウェア検証プログラムは、磁気ディスクおよび光ディスクといった可搬記録媒体に記憶されてもよい。

図２を参照して、リソース名とモデルとのマッピングについて説明する。

リソース名は、リソース名ツリーで定義されている。本実施の形態において、ＣＰＵモデル３１の保持するリソースのうち、あるレジスタのリソース名は、“ＣＰＵ．Ｒｅｇｉｓｔｅｒ１”である。デバイスＡモデル３２の保持するリソースのうち、あるレジスタのリソース名は、“ＩＯ．ＤｅｖＡ．Ｒｅｇｉｓｔｅｒ２”である。デバイスＢモデル３３の保持するリソースのうち、あるレジスタのリソース名は、“ＩＯ．ＤｅｖＢ．Ｒｅｇｉｓｔｅｒ３”である。各モデルが保持するリソースのリソース名は、各モデルが持つリソース情報に示されている。

各モデルが保持するリソース情報は、環境シミュレータ部３０の模擬対象の構成の変更に応じて変わってくる。例えば、デバイスＡモデル３２とデバイスＢモデル３３とが１つのＩＯモデルとして構成されるように、環境シミュレータ部３０内において変更があったとする。この場合、ＩＯモデルの保持するリソース情報において、“ＩＯ．ＤｅｖＡ．Ｒｅｇｉｓｔｅｒ２”および”ＩＯ．ＤｅｖＢ．Ｒｅｇｉｓｔｅｒ３”という２つのレジスタのリソース名が示されることになる。「ＩＯ」は、Ｉｎｐｕｔ Ｏｕｔｐｕｔの略語である。

デバイスＡモデル３２に、新たにレジスタが追加された場合、新たにデバイスＡモデル３２の保持するリソース情報に“ＩＯ．ＤｅｖＡ．Ｒｅｇｉｓｔｅｒ４”が追加される。

ソフトウェア検証装置４０において、モニタ部２０は、初期化時に環境シミュレータ部３０から通知されるモデルとリソースとのマッピング情報５０を保持する仕組みとなっている。このため、環境シミュレータ部３０の構成変更およびリソースの追加等の変更に対して、モニタ部２０の変更は不要となる。

＊＊＊動作の説明＊＊＊
図１から図４を参照して、本実施の形態に係るソフトウェア検証装置４０の動作を説明する。ソフトウェア検証装置４０の動作は、本実施の形態に係るソフトウェア検証方法に相当する。

図３のステップＳ１において、環境シミュレータ部３０は、検証対象のソフトウェアを搭載するハードウェアに備えられる複数のハードウェア部品を個別のモデルとして模擬する処理を開始する。環境シミュレータ部３０は、模擬に際して、検証対象のソフトウェアの動作によって各モデルに与えられる値を保持する１つ以上のリソースを、各モデルに割り当てる。本実施の形態において、環境シミュレータ部３０は、ソフトウェア検証装置４０が初期化される度に、模擬を開始したモデルと当該モデルに割り当てたリソースとの対応を示す情報をマッピング情報５０として生成し、モニタ部２０に提供する。

具体的には、ソフトウェア検証装置４０の初期化時に、環境シミュレータ部３０内のＣＰＵモデル３１、デバイスＡモデル３２、デバイスＢモデル３３およびプラントモデル３４の各モデルが、モニタ部２０に対して、各モデル自身の持つリソース情報および各モデル自身のモデル名の組み合わせを通知する。ＣＰＵモデル３１は、検証対象のソフトウェアを搭載するハードウェアに備えられるＣＰＵを模擬するためのモデルである。デバイスＡモデル３２およびデバイスＢモデル３３は、それぞれ当該ハードウェアに備えられるコントローラ等のデバイスを模擬するためのモデルである。プラントモデル３４は、当該ハードウェアに備えられるモータ等の部品を模擬するためのモデルである。

図３のステップＳ２において、モニタ部２０は、マッピング情報５０を取得してメモリ４２に格納する。本実施の形態において、モニタ部２０は、ソフトウェア検証装置４０が初期化される度に、環境シミュレータ部３０からマッピング情報５０を取得してメモリ４２に格納する。

具体的には、モニタ部２０は、ステップＳ１で各モデルから通知されたリソース情報とモデル名との組み合わせをマッピング情報５０として保持する。

なお、モニタ部２０は、ソフトウェア検証装置４０が初期化される度に、外部ファイルからマッピング情報５０を取得してメモリ４２に格納してもよい。

図３のステップＳ３において、モニタ部２０は、メモリ４２に格納したマッピング情報５０から各リソースの名前を抽出して動作検証部１０の複数の機能部に通知する。

具体的には、モニタ部２０は、ステップＳ２で保持したマッピング情報５０から、値の設定あるいは値の取得が可能なリソースのリソース情報を取り出し、動作検証部１０内の手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３および性能解析機能部１４に対して通知する。

図３のステップＳ４において、動作検証部１０の複数の機能部は、共通のインタフェース関数を呼び出す。このとき、各機能部は、インタフェース関数のパラメータとしてリソースの名前を指定する。

具体的には、手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３および性能解析機能部１４が、モニタ部２０から通知されたリソース情報をパラメータとして持たせて、図４に示すように、モニタ部２０に対して、値を取得するｇｅｔＶａｌｕｅ（）関数を呼び出す。あるいは、手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３および性能解析機能部１４が、モニタ部２０から通知されたリソース情報をパラメータとして持たせて、モニタ部２０に対して、値を設定するｓｅｔＶａｌｕｅ（）関数を呼び出す。

図３のステップＳ５において、モニタ部２０は、インタフェース関数が呼び出される度に、メモリ４２に格納したマッピング情報５０を参照して、インタフェース関数のパラメータとして名前が指定されたリソースに対応するモデルを特定する。

具体的には、モニタ部２０は、モニタ部２０自身の保持するマッピング情報５０から、パラメータとして通知されたリソース情報に対応するリソースを管理するモデルを特定する。

図３のステップＳ６において、モニタ部２０は、インタフェース関数のパラメータとして名前が指定されたリソースへのアクセスを、特定したモデルに要求し、要求に対する応答を受け取る。

具体的には、モニタ部２０は、図４に示すように、ステップＳ５で特定したモデルに対して、手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３または性能解析機能部１４から通知されたリソース情報をパラメータとして持たせて、値を取得するｇｅｔＶａｌｕｅ（）関数を呼び出す。あるいは、モニタ部２０は、ステップＳ５で特定したモデルに対して、手動試験機能部１１、自動試験機能部１２、デバッグ機能部１３または性能解析機能部１４から通知されたリソース情報をパラメータとして持たせて、値を設定するｓｅｔＶａｌｕｅ（）関数を呼び出す。呼び出し先のモデルは、パラメータとして通知されたリソース情報に対応するリソースに対して、値の取得あるいは値の設定を実行し、その結果をモニタ部２０に対して通知する。

図３のステップＳ７において、モニタ部２０は、受け取った応答をインタフェース関数の呼び出し元の機能部に返す。これにより、その機能部は、インタフェース関数のパラメータとしてリソースの名前を指定したリソースにアクセスしたことになり、検証対象のソフトウェアの動作を検証することができる。

具体的には、モニタ部２０は、環境シミュレータ部３０内のＣＰＵモデル３１、デバイスＡモデル３２、デバイスＢモデル３３またはプラントモデル３４から通知された結果を、動作検証部１０における、該当する機能部に対して通知する。

本実施の形態において、動作検証部１０の複数の機能部は、検証対象のソフトウェアの動作を個別の方式によって検証する。

具体的には、手動試験機能部１１は、ユーザの操作に応じて検証対象のソフトウェアを試験する。自動試験機能部１２は、自動で検証対象のソフトウェアを試験する。デバッグ機能部１３は、検証対象のソフトウェアをデバッグする。性能解析機能部１４は、検証対象のソフトウェアの性能を解析する。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態では、各機能部から各モデルのリソースへアクセスするための共通のインタフェース関数が呼び出される度に、リソースへのアクセスを仲介するモニタ部２０に、モデルとリソースとの対応を示すマッピング情報５０を参照させる。このため、環境シミュレータ部３０にてモデルの変更が発生した場合にも共通のインタフェース関数を変更なしで使用できる。

環境シミュレータ部３０において、周辺ＩＯ部分を１つのモデルとして実装していたとする。環境シミュレータ部３０内で実装する周辺ＩＯモデルの持つデバイス数が肥大化してきたために、周辺ＩＯモデルをデバイスの個数分のモデルに分割する必要が生じる場合がある。そのような場合でも、本実施の形態では、動作検証部１０が、共通のインタフェース関数を用いて、環境シミュレータ部３０内の各モデルが管理する各種リソースにアクセスすることができる。すなわち、上記のような環境シミュレータ部３０内の変更があった際に、その都度、動作検証部１０のインタフェースを修正する必要がない。

本実施の形態では、インタフェース関数をモデルごとに用意するのではなく、共通化しているため、動作検証部１０は、一意に決定されるモデルとそのモデルが保持するリソース情報とのマッピングをもとに、必要なリソースに対して、共通化したインタフェース関数を用いることでアクセスすることが可能となる。具体的には、動作検証部１０の各機能部が、ｇｅｔＶａｌｕｅ（）関数またはｓｅｔＶａｌｕｅ（）関数を呼び出す際に、パラメータでアクセス対象のリソース名を指定してリソースにアクセスすることができる。

本実施の形態では、マッピングの変更にも対応することができる。具体例として、環境シミュレータ部３０において、ＩＯモデルというモデルが、デバイスＡモデル３２およびデバイスＢモデル３３という２つのモデルに変更になった場合、各モデルとそのモデルが管理するリソースとのマッピングも変更することができる。

本実施の形態において、環境シミュレータ部３０は、制御ソフトウェアを搭載する実機ハードウェアを模擬する。動作検証部１０は、環境シミュレータ部３０で動作する制御ソフトウェアを検証する。モニタ部２０は、動作検証部１０の各機能部から環境シミュレータ部３０にアクセスするためのインタフェース関数を共通のインタフェース関数として１つにまとめ、環境シミュレータ部３０の各モデルと各モデルに含まれるリソースとのマッピング情報５０を管理する。環境シミュレータ部３０の各モデルが管理するリソース情報、あるいは、各モデルそのものに変更があった場合でも、モニタ部２０のインタフェース関数の追加または削除を行う必要はなく、モニタ部２０のインタフェース関数のパラメータに指定する対象リソース名のみを変更することで、動作検証部１０から環境シミュレータ部３０の各モデルの保持するリソースへのアクセスが可能である。マッピング情報５０は、初期化時に動的に登録される。

上記のように、本実施の形態では、動作検証部１０が環境シミュレータ部３０内の各モデルの保持するリソースへアクセスするための共通インタフェースを持つモニタ部に対して、初期化時に、各モデルと各モデルが保持するリソースとのマッピング情報５０を登録する。これにより、環境シミュレータ部３０内のモデルまたはリソースの構成が変更された場合でも、共通インタフェースを変更することが不要なだけでなく、動作検証部１０が環境シミュレータ部３０の構成変更を意識する必要がなくなる。よって、環境シミュレータ部３０の構成変更に対する設計柔軟性が増すという効果を得ることができる。

＊＊＊他の構成＊＊＊
本実施の形態では、動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能がソフトウェアにより実現されるが、変形例として、動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能の一部が専用の電子回路により実現され、残りがソフトウェアにより実現されてもよい。

専用の電子回路は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＦＰＧＡまたはＡＳＩＣである。「ＧＡ」は、Ｇａｔｅ Ａｒｒａｙの略語である。「ＦＰＧＡ」は、Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略語である。「ＡＳＩＣ」は、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。

プロセッサ４１、メモリ４２および専用の電子回路を、総称して「プロセッシングサーキットリ」という。つまり、動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、動作検証部１０、モニタ部２０および環境シミュレータ部３０の機能は、プロセッシングサーキットリにより実現される。

実施の形態２．
本実施の形態について、主に実施の形態１との差異を、図５を用いて説明する。

図５に示すように、本実施の形態では、環境シミュレータ部３０の各モデルが、ダイナミックリンクライブラリとして実装され、プラグイン５２としてモニタ部２０にリンクされる。

具体的には、動作検証部１０およびモニタ部２０の機能を実現するプログラムが１つの実行ファイル５１として構成され、ＣＰＵモデル３１、デバイスＡモデル３２、デバイスＢモデル３３部およびプラントモデル３４が、それぞれ個別の．ｄｌｌファイルとして構成される。

ＣＰＵモデル３１、デバイスＡモデル３２、デバイスＢモデル３３およびプラントモデル３４の各．ｄｌｌファイルを特定のフォルダに格納しておき、実行ファイル５１を、そのフォルダ内の．ｄｌｌファイルを動的にリンクするようにしておけば、環境シミュレータ部３０の構成変更またはリソースの追加等の変更が入った際にも、実行ファイル５１側の再ビルドは不要となる。

１０ 動作検証部、１１ 手動試験機能部、１２ 自動試験機能部、１３ デバッグ機能部、１４ 性能解析機能部、２０ モニタ部、３０ 環境シミュレータ部、３１ ＣＰＵモデル、３２ デバイスＡモデル、３３ デバイスＢモデル、３４ プラントモデル、４０ ソフトウェア検証装置、４１ プロセッサ、４２ メモリ、４３ 入力インタフェース、４４ 出力インタフェース、５０ マッピング情報、５１ 実行ファイル、５２ プラグイン。

Claims (6)

1. ソフトウェアを搭載するハードウェアに備えられる複数のハードウェア部品を個別のモデルとして模擬し、模擬に際して、前記ソフトウェアの動作によって各モデルに与えられる値を保持する１つ以上のリソースを、各モデルに割り当てる環境シミュレータ部と、
   共通のインタフェース関数を呼び出すことで、前記インタフェース関数のパラメータとして名前を指定したリソースにアクセスし、前記ソフトウェアの動作を個別の方式によって検証する複数の機能部を有する動作検証部と、
   各モデルと前記環境シミュレータ部により割り当てられたリソースとの対応を示すマッピング情報を取得してメモリに格納し、各リソースの名前を前記複数の機能部に通知し、前記インタフェース関数が呼び出される度に、前記メモリに格納したマッピング情報を参照して、前記インタフェース関数のパラメータとして名前が指定されたリソースに対応するモデルを特定し、当該リソースへのアクセスを、特定したモデルに要求し、要求に対する応答を受け取って前記インタフェース関数の呼び出し元の機能部に返すモニタ部と
   を備えるソフトウェア検証装置。
2. 各モデルは、ダイナミックリンクライブラリとして実装され、プラグインとして前記モニタ部にリンクされる請求項１に記載のソフトウェア検証装置。
3. 前記モニタ部は、前記ソフトウェア検証装置が初期化される度に、前記環境シミュレータ部から前記マッピング情報を取得する請求項１または２に記載のソフトウェア検証装置。
4. 前記環境シミュレータ部は、前記ソフトウェア検証装置が初期化される度に、模擬を開始したモデルと当該モデルに割り当てたリソースとの対応を示す情報を前記マッピング情報として生成し、前記モニタ部に提供する請求項３に記載のソフトウェア検証装置。
5. 前記モニタ部は、前記ソフトウェア検証装置が初期化される度に、外部ファイルから前記マッピング情報を取得する請求項１または２に記載のソフトウェア検証装置。
6. コンピュータに、
   ソフトウェアを搭載するハードウェアに備えられる複数のハードウェア部品を個別のモデルとして模擬し、模擬に際して、前記ソフトウェアの動作によって各モデルに与えられる値を保持する１つ以上のリソースを、各モデルに割り当てる環境シミュレータと、
   共通のインタフェース関数を呼び出すことで、前記インタフェース関数のパラメータとして名前を指定したリソースにアクセスし、前記ソフトウェアの動作を個別の方式によって検証する複数の機能部を有する処理と、
   各モデルと前記環境シミュレータにより割り当てられたリソースとの対応を示すマッピング情報を取得してメモリに格納し、各リソースの名前を前記複数の機能部に通知し、前記インタフェース関数が呼び出される度に、前記メモリに格納したマッピング情報を参照して、前記インタフェース関数のパラメータとして名前が指定されたリソースに対応するモデルを特定し、当該リソースへのアクセスを、特定したモデルに要求し、要求に対する応答を受け取って前記インタフェース関数の呼び出し元の機能部に返す処理と
   を実行させるソフトウェア検証プログラム。

Images