JP2010015240A - 検証システム及び検証装置 - Google Patents

Abstract

【課題】装置において実行されるプログラムの動作を検証する検証システム及び検証装置において、汎用性を広げるとともに検証をより簡単かつ正確に行うことができるようにする。
【解決手段】試験者は、ＵＭＬモデリングツール５０（以下、ツール５０）を介して、検証方法を表すテスト仕様を例えばシーケンス図の形式で視覚的に認識可能に作成することができる。ツール５０を介して試験者により作成されたシーケンス図Ｔ２０を表す情報は、ツール５０におけるスクリプトの生成機能により、ＣＡＮバスモニタ５２が認識及び実行可能なテストスクリプトＴ２２に変換される。ＣＡＮバスモニタ５２は、検証対象であるＥＣＵ５４の動作を監視し、そのＥＣＵ５４の実際の動作が、テストスクリプトＴ２２が表すテスト仕様に合致するか否かを判断し、判断結果を表すテストレポートＴ２４を外部に出力する。
【選択図】図３

Description

本発明は、装置において実行されるプログラムの動作を検証する検証システム及び検証装置に関する。

従来、装置において実行されるプログラムの動作を検証するシステムとして、例えば特許文献１に記載されたような検証システムが知られている。
特許文献１の検証システムは、検証対象のプログラム中に測定点を表す記述を埋め込み、ある測定点から他の測定点に至るまでの経過時間が設計値に合致しているか否か（許容範囲内か否か）を判別することで、そのプログラムの動作が正常か否かを検証するものである。
特開２００２−１０８６５６号公報

しかしながら、特許文献１の検証システムでは、検証対象のプログラム中に測定点を表す記述を埋め込むようになっているため、例えばその記述の読み出し等に要する処理時間（オーバーヘッド）が生じる場合がある。このため、場合によっては、検証結果（ある測定点から他の測定点に至るまでの経過時間）においてそのオーバーヘッドを考慮する必要があり、検証が複雑なものとなっていた。また、検証結果が不正確なものとなるおそれがあった。

また、プログラムの種類によっては、測定点を表す記述をそのまま使えない場合があり、汎用性の点で問題があった。
さらに言えば、装置のうち、特にネットワークに接続される通信装置においては、その通信装置においてやりとりされる信号（メッセージ）の内容が設計値（仕様）に合致しているか否かが問題となる。

この点、上記特許文献１の検証システムでは、通信装置に搭載されるプログラム上のある測定点から他の測定点に至るまでの経過時間（言い換えると、通信装置におけるある処理に要する時間）が設計値に合致しているか否か（許容範囲内か否か）を検証することはできるものの、通信装置においてやりとりされる信号（メッセージ）の内容が設計値（仕様）に合致しているか否かを検証する点については考慮されていない。このため、特許文献１の検証システムは、ネットワーク上の通信装置に実装されるプログラムの検証には不向きであり、汎用性の改善が望まれていた。

本発明は、こうした問題に鑑みなされたもので、装置において実行されるプログラムの動作を検証する検証システム及び検証装置において、汎用性を広げるとともに検証をより簡単かつ正確に行うことができるようにすることを目的とする。

上記目的を達成するためになされた請求項１に記載の発明は、検証対象のプログラム、を実装した装置（以下、検証対象装置と言う）の挙動を監視する監視装置を備え、その監視装置の監視結果に基づきプログラムの動作を検証する検証システムであって、モデル生成手段と、スクリプト変換手段と、スクリプト解釈手段と、合否判定手段と、判定結果出力手段と、を備えている。

モデル生成手段は、検証対象装置が振る舞うべき挙動を表すモデル（以下、挙動モデルと言う）を使用者の入力に基づき生成する。言い換えれば、使用者は、検証対象装置が振る舞うべき挙動を、モデル形式で簡単に生成することができる。挙動モデルは、検証対象装置の検証（つまり、検証対象装置において実行されるプログラムの動作の検証）に用いられるものであり、挙動モデル通りに検証対象装置が動作すれば合格と判断され、挙動モデル通りに検証対象装置が動作しなければ不合格と判断されるように構成することができる。また、挙動モデルの形式としては、動作の流れを表すフロー図の形式、オブジェクト間のメッセージの流れを時系列的に表現したシーケンス図の形式など、種々の形式を適用することができる。使用者は、検証方法に応じて、挙動モデルの形式を適宜選択すれば良い。

そして、検証対象装置が振る舞うべき挙動がモデルで表されることで、使用者や第三者にとって理解が容易となる。例えば、使用者や第三者にとって、プログラム列を解析して理解するような場合と比較すれば、モデルを理解するほうが簡単である。このため、検証の際の工数を削減できるようになる。

次に、スクリプト変換手段は、モデル生成手段により生成された挙動モデルをスクリプトに変換する。スクリプトとは、機械語への変換作業を自動化或いは省略してコンピュータ上において簡単に実行できるようにした簡易プログラムである。

そして、スクリプト変換手段により変換されて生成されたスクリプトは、スクリプト解釈手段が解釈する。
つまり、使用者にとって認識が容易な挙動モデルが、本検証システムにとって認識可能（本検証システムにおけるコンピュータにとって認識可能）なスクリプトに変換されて解釈されるようになっており、使用者がわざわざスクリプトを生成する必要がない。このため、使用者の手間を省くことができる。また、使用者自らがスクリプトを記述する場合と比較すれば、スクリプトの記述に誤りが生じる可能性を低減することができる。

そして、合否判定手段が、監視装置の監視結果に基づく検証対象装置の実際の挙動がスクリプト解釈手段の解釈結果が表す挙動に合致するか否かに基づき、プログラムの動作の適否を判定し、判定結果出力手段が、合否判定手段の判定結果を表す情報を出力するようになっている。

これによれば、使用者は、判定結果出力手段により出力される判定結果を参照することで、検証対象装置が振る舞うべき挙動通りにその検証対象装置が動作しているか否かについて、つまり、検証対象装置において実行されるプログラムの動作の適否について、容易に把握できるようになる。例えば、使用者自らが検証対象装置の動作ログを解析することでその検証対象装置の挙動の適否（プログラムの動作の適否）を検証する方法もあるが、そのような手間を省くことができる。

このように、請求項１の検証システムによれば、装置において実行されるプログラムの動作を簡単に検証することができる。また、検証対象のプログラムを変更する（例えば検証対象のプログラムに検証処理のためのプログラムを埋め込む）必要がないため、検証を正確に行うことができるようになる。さらに、検証対象のプログラムの種類を気にしなくても良くなる。つまり、検証対象のプログラムの種類を問わず、検証が実行されるようになる。

次に、請求項２の検証システムは、請求項１の検証システムにおいて、検証対象装置は、ネットワークに接続されてそのネットワーク上の通信機器との間で信号の送受信を行う装置であり、挙動モデルは、少なくとも検証対象装置において通信機器との間で送受信されるべき信号（以下、送受信信号と言う）の情報を含み、送受信信号の内容を表す論理名をその送受信信号のそれぞれについて記憶するデータベースを備え、モデル生成手段は、データベースを参照し、送受信信号の論理名を用いて挙動モデルを生成することを特徴としている。

このような請求項２に記載の検証システムによれば、挙動モデルにおいて、検証対象装置において送受信されるべき送受信信号が、その送受信信号の内容を表す論理名で表されるようになる。このため、使用者や第三者にとって送受信信号の内容を把握し易くなり、ひいては挙動モデルの内容が分かりやすいものとなる。つまり、挙動モデルの可読性が向上する。したがって、使用者や第三者が挙動モデルの内容を確認したり検証したりするための工数（時間）を削減し得るようになり、ひいては検証のための工数を削減し得る。

次に、請求項３の検証システムは、請求項２の検証システムにおいて、スクリプト変換手段は、データベースを参照し、送受信信号の論理名を用いてスクリプトを生成することを特徴としている。

このような請求項３の検証システムによれば、スクリプトにおいて、検証対象装置において送受信されるべき送受信信号を表す記述（プログラム）が、その送受信信号の内容を表す論理名で表されるようになる。このため、使用者や第三者にとってスクリプトの内容が分かりやすいものとなる。つまり、スクリプトの可読性が向上する。したがって、使用者や第三者がスクリプトの内容を確認したり検証したりするための工数（時間）を削減し得るようになる。

次に、請求項４の検証システムは、請求項１〜３の検証システムにおいて、モデル生成手段は、検証対象装置の動作環境についての条件（以下、環境条件と言う）を表すモデル（以下、条件モデルと言う）を使用者の入力に基づき生成する条件モデル生成手段を備え、スクリプト変換手段は、条件モデル生成手段により生成された条件モデルをスクリプトに変換する条件スクリプト変換手段を備えている。そして、監視装置は、条件スクリプト変換手段により変換されて生成されたスクリプトに基づき環境条件を再現する条件再現手段を備え、その条件再現手段によりその環境条件が再現された際の検証対象装置の挙動を監視することを特徴としている。

具体的に、動作環境としては、装置のＣＰＵの負荷や、ネットワークのトラフィック量（通信量）等を挙げることができる。本請求項４の検証システムでは、そのような動作環境について所望の条件を設定し、その設定した条件下で装置が振る舞うべき挙動を検証できるようになる。このため、種々の動作環境下において、装置が振る舞うべき挙動を検証することができる。言い換えれば、種々の条件下においてプログラムの動作を検証できるようになる。このため、プログラムの動作をより精密に検証し得るようになる。

次に、請求項５の発明は、検証対象のプログラム、を実装した装置（以下、検証対象装置と言う）と接続され、その検証対象装置におけるプログラムの動作を検証する検証装置であって、検証対象装置の挙動を監視する監視手段と、検証対象装置が振る舞うべき挙動を表すモデル（以下、挙動モデルと言う）を使用者の入力に基づき生成するモデル生成手段と、モデル生成手段により生成された挙動モデルをスクリプトに変換するスクリプト変換手段と、スクリプト変換手段により変換されて生成されたスクリプトを解釈するスクリプト解釈手段と、監視手段の監視結果に基づく検証対象装置の実際の挙動が、スクリプト解釈手段の解釈結果が表す挙動に合致するか否かに基づき、プログラムの動作の適否を判定する合否判定手段と、合否判定手段の判定結果を表す情報を出力する判定結果出力手段と、を備えていることを特徴としている。

このような検証装置によれば、請求項１について述べた効果と同じ効果を得ることができる。

以下に、本発明の実施形態を図面に基づき説明する。
［第１実施形態］
まず、第１実施形態について説明する。

図１は、第１実施形態の検証システム１の概略構成図である。
第１実施形態の検証システム１は、テスト対象通信装置１４に実装されるプログラム（ソフトウエア）の動作を検証するためのものである。テスト対象通信装置１４は、図示しないネットワークに接続され、そのネットワーク上の機器と通信可能に構成されている。

検証システム１は、具体的に、テスト対象通信装置１４と通信可能に接続されてそのテスト対象通信装置１４の動作（及びネットワークの状態）を監視するパーソナルコンピュータ（以下、ＰＣと記載する）１２と、そのＰＣ１２と通信可能に接続されるＰＣ１０とを備えている。

ＰＣ１０は、ＣＰＵや主記憶装置等（何れも図示省略）が筐体に内蔵されたパーソナルコンピュータ本体１０ａと、キーボード、マウス等から構成される入力装置１０ｂと、ディスプレイ１０ｃと、を中心に構成される。尚、パーソナルコンピュータ本体１０ａ内部の構成については周知であるため、ここでは詳細な説明を省略する。また、他のＰＣについても詳細な説明は省略することとする。

ＰＣ１２は、具体的に、テスト対象通信装置１４において送受信される信号を監視したり、テスト対象通信装置１４において実行される各種処理の状態について監視したりする。

次に、ＰＣ１０は、テスト対象通信装置１４が振る舞うべき挙動を表す図面（例えばシーケンス図）を、使用者が入力装置１０ｂを介して描画するための設計図面描画ツール４０と、その設計図面描画ツール４０を介して入力された図面から、ＰＣ１２が認識可能なスクリプトを生成するテストスクリプト生成ツール４２とを備えている。この設計図面描画ツール４０及びテストスクリプト生成ツール４２は、具体的には、ＰＣ１０上で動作するアプリケーションである。ＰＣ１０において、テストスクリプト生成ツール４２により生成されたスクリプト（以下、テストスクリプトとも記載する）Ｔ２は、ＰＣ１２に出力される。

ＰＣ１２は、ＰＣ１０においてテストスクリプト生成ツール４２により生成されたテストスクリプトＴ２を解釈（認識）するテストスクリプト解釈ツール４４を備えている。このテストスクリプト解釈ツール４４は、具体的にはＰＣ１２上で動作するアプリケーションである。

本検証システム１の概略について、図２を用いてさらに説明する。
図２は、本検証システム１における検証の流れ（検証方法）を表す概念図である。尚、図１と同じ構成を表すブロックについては、図１と同じ符号を付している。

まず、検証を進める主体である試験者は、設計図面描画ツール４０を用い、テスト対象通信装置１４が振る舞うべき挙動（以下、テスト仕様とも記載する）を入力する。
本実施形態では、テスト仕様として、例えば、テスト対象通信装置１４において実行されるべき通信手順（より具体的に、テスト対象通信装置１４において送受信されるべき信号の内容、及び送受信のタイミング）が入力される。例えば、信号の内容及び信号のやりとりを視覚的に記述したシーケンス図の形式でテスト仕様が記述される。尚、この点については図４において後述する。

設計図面描画ツール４０を用いて使用者により入力されたテスト仕様を表す図面（図２における設計図面Ｔ１０）は、設計図面描画ツール４０により外部に出力される。具体的には、設計図面Ｔ１０はディスプレイ１０ｃに表示される。

設計図面描画ツール４０によりディスプレイ１０ｃに表示された設計図面Ｔ１０は、第三者（確認者）によりその内容（妥当性等）がチェックされる。
設計図面Ｔ１０は、確認者によりチェックされた後、テストスクリプト生成ツール４２に入力される。具体的に、試験者或いは確認者が、ＰＣ１０の入力装置１０ｂを介して所定の指令を入力することにより、設計図面Ｔ１０がテストスクリプト生成ツール４２に入力される。つまり、設計図面Ｔ１０を表すデータが、設計図面描画ツール４０からテストスクリプト生成ツール４２に渡される。

テストスクリプト生成ツール４２は、入力された設計図面Ｔ１０を表すスクリプト（以下、テストスクリプトと記載する）Ｔ２を生成し、外部に出力する。具体的に、テストスクリプトＴ２をディスプレイ１０ｃに表示させる。設計図面Ｔ１０をコンピュータ（ＰＣ１０）が認識可能な形態に置き換えたものがテストスクリプトＴ２である。テストスクリプトＴ２は、より具体的に、機械語への変換作業を自動化或いは省略してコンピュータ上において簡単に実行できるようにした簡易プログラムである。

テストスクリプト生成ツール４２により生成されたテストスクリプトＴ２は、テストスクリプト解釈ツール４４に入力される。
テストスクリプト解釈ツール４４は、通信監視装置４６（図１におけるＰＣ１２に相当）と連携するプログラム（アプリケーション）である。言い換えると、通信監視装置４６上で動作するアプリケーションである。

通信監視装置４６は、テスト対象通信装置１４及びそのテスト対象通信装置１４が接続されるネットワークの状態を監視する。より具体的に、テスト対象通信装置１４において送受信される信号（メッセージ）や、ネットワーク上のトラフィック（通信量）を監視する。そして、通信監視装置４６は、テスト対象通信装置１４における通信ログＴ１６を外部に出力する。具体的に、通信ログＴ１６は、その通信監視装置４６が備えるディスプレイに表示される。

一方、テストスクリプト解釈ツール４４は、通信監視装置４６の監視結果及びテストスクリプトＴ２に基づき、テスト対象通信装置１４の実際の動作、言い換えると、テスト対象通信装置１４に実装されるプログラムの動作が、テストスクリプトＴ２が表すテスト仕様に合致しているか否かを判断する。例えば、テスト対象通信装置１４において送受信される信号（メッセージ）の内容や送受信の時間（タイミングや期間）が、テスト仕様に合致しているか否かを判断する。

そして、テストスクリプト解釈ツール４４は、テスト対象通信装置１４の実際の動作がテストスクリプトＴ２が表すテスト仕様に合致しているか否かを表すテストレポートＴ１４を、外部に出力する。具体的に、テストレポートＴ１４は、テストスクリプト解釈ツール４４が実装される装置（ここでは、通信監視装置４６）が備えるディスプレイに表示される。

ここで、本検証システム１を適用したより具体的な実施形態について、図３を用いて説明する。図３は、本検証システム１を車両のネットワークに適用した例を表す図面である。

図３では、具体的に、車内ＬＡＮとしてのＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続される電子制御装置（以下、ＥＣＵと記載する）５４を検証対象としている（言い換えると、ＥＣＵ５４に実装されるプログラムを検証対象としている）。

次に、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）モデリングツール５０は、図１或いは図２の設計図面描画ツール４０に相当するものであり、試験者は、ＵＭＬモデリングツール５０を介して、テスト仕様を表す図面を入力する。より具体的に、図示しないコンピュータにＵＭＬモデリングツール５０がインストールされ、試験者は、そのコンピュータにおける入力装置を用いてテスト仕様を表す図面を入力できる。

ＵＭＬは、オブジェクト指向モデリング概念とその表記を標準化したものであり、システムのモデリングを行うためのツールである。ＵＭＬを用いたモデリングにおいて生成される図の種類としては様々なものがあり、例えば、システムに対してどのようなアクター（システムの外部にあってシステムに作用するもの）が存在するのかを記述したりそれぞれのアクターがどのような作用をしそれに対してシステムがどう応答をするのかを記述したユースケース図、システムの静的な構造を記述したクラス図、システムにおけるオブジェクト間での信号（メッセージ）のやりとりを記述したシーケンス図、などがある。

本例では、シーケンス図の形式により、ＥＣＵ５４において送受信されるべき信号（メッセージ）の内容や送受信の時間（タイミングや期間）がテスト仕様として表されるようになっている。ＵＭＬモデリングツール５０を介して生成されたシーケンス図Ｔ２０は、外部に視認可能に出力される。具体的に、ＵＭＬモデリングツール５０が実装される図示しないコンピュータにおけるディスプレイに表示される。そして、シーケンス図Ｔ２０の内容（妥当性等）が、確認者によりチェックされる。

ここで、ＵＭＬモデリングツール５０を介して試験者により入力されたテスト仕様（シーケンス図）に基づきそのテスト仕様（シーケンス図）をスクリプトに変換する機能は、ＵＭＬモデリングツール５０に追加される拡張機能（アドオン）として提供される。つまり、ＵＭＬモデリングツール５０により生成されたテスト仕様（シーケンス図）は、そのＵＭＬモデリングツール５０が実装される図示しないコンピュータ上において、スクリプトに変換される。

ＵＭＬモデリングツール５０の拡張機能により生成されたスクリプト（以下、テストスクリプトとも記載する）Ｔ２２は、外部に視認可能に出力される。具体的に、ＵＭＬモデリングツール５０が実装される図示しないコンピュータにおけるディスプレイに表示される。

次に、ＣＡＮバスモニタ５２は、ＥＣＵ５４及びＣＡＮの状態を監視するものであり、図２における通信監視装置４６、或いは図１におけるＰＣ１２に相当する。テストスクリプトＴ２２は、そのＵＭＬモデリングツール５０からＣＡＮバスモニタ５２に入力される。

ＣＡＮバスモニタ５２には、スクリプトインタプリタが内蔵（インストール）されている。スクリプトインタプリタは、所定のプログラム言語で記述されたソースコードを、コンピュータが実行できる形式（オブジェクトコード）に変換しながら実行するソフトウエアである。つまり、スクリプトを解釈して実行するツールである。

そして、ＣＡＮバスモニタ５２は、ＥＣＵ５４やＣＡＮの状態の監視結果、及びテストスクリプトＴ２２の内容に基づき、ＥＣＵ５４の実際の動作（ＥＣＵ５４に実装されるプログラムの動作）が、テストスクリプトＴ２２が表すテスト仕様に合致するか否かを判断する。そして、ＣＡＮバスモニタ５２は、判断結果を表すテストレポートＴ２４を、外部に視認可能に出力する。例えば、所定のディスプレイ上に表示させる。尚、ＣＡＮバスモニタ５２は、ＥＣＵ５４における通信ログＴ２６を外部に出力するようになっている。

次に、本実施形態の作用について、図４，５を用いて説明する。
本検証システム１において、ＥＣＵ５４の動作（ＥＣＵ５４に実装されるプログラムの動作）を検証する場合、まず、その検証方法を表すテスト仕様が定められる。本例では、図４（ａ）に示すように、「ＣＡＮバスモニタ５２がＥＣＵ５４にメッセージＡを送信してから１０ｍｓ以内に、そのＣＡＮバスモニタ５２がＥＣＵ５４からメッセージＢを受信した場合、テスト合格」、となるようなテスト仕様が定められたものとする。

試験者は、図４（ａ）に示すテスト仕様を表す図面（例えばシーケンス図）を、ＵＭＬモデリングツール５０を介して作成（入力）する。
図４（ｂ）に、同図（ａ）のテスト仕様を表現したシーケンス図Ｔ２０の具体例を示す。図４（ｂ）のシーケンス図Ｔ２０では、ＣＡＮバスモニタ５２からＥＣＵ５４に送信されるメッセージＡが、ＣＡＮバスモニタ５２からＥＣＵ５４に向かう矢印及び記号「Ａ」で表され、また、ＥＣＵ５４からＣＡＮバスモニタ５２に送信されるメッセージＢが、ＥＣＵ５４からＣＡＮバスモニタ５２に向かう矢印及び記号「Ｂ」で表されている。また、ＣＡＮバスモニタ５２において、メッセージＡが送信されてからメッセージＢが受信されるまでの間隔を１０ｍｓｅｃ未満とする旨の条件が記述されている。

次に、図４（ｂ）のシーケンス図Ｔ２０は、ＵＭＬモデリングツール５０のアドオン（テストスクリプトを生成する拡張機能）により、テストスクリプトＴ２２に変換される。図４（ｃ）に、テストスクリプトＴ２２の具体例を示す。

図４（ｃ）のテストスクリプトＴ２２のプログラム列のうち、１，２行目は、サンプルテストである旨が記述（宣言）されたものである。
３〜８行目は、「Ａを出力してから１０ｍｓｅｃ以内にメッセージＢを受信した場合に合格と判定する」旨、及び「Ａを出力してから１０ｍｓｅｃ以内にメッセージＢを受信できなかった場合に不合格と判定する」旨、が記述されたものである。

以上、図４に示すように、ＥＣＵ５４の動作（ＥＣＵ５４に実装されるプログラムの動作）の検証に際しては、例えばそのＥＣＵ５４において実現されるべき通信（通信手順）が予め定められるようになっている。そして、ＥＣＵ５４における実際の動作（通信手順）が、その実現されるべき通信手順に合致するか否かが検証される。

ここで、図５に示すが、本実施形態では、例えばＥＣＵ５４が接続されるＣＡＮ上に所望の通信負荷を与え、その通信負荷の下でのＥＣＵ５４の動作を検証することができるようになっている。

ここでは、例えばＣＡＮ上の通信負荷を３０％に設定する場合を想定する。
試験者は、テスト仕様を入力する場合と同様に、ＵＭＬモデリングツール５０を介して、「通信負荷３０％」という条件を表すシーケンス図Ｔ４０を生成する。本例では、シーケンス図Ｔ４０において、矢印にて信号がやりとりされる旨が表されるとともに、「通信負荷３０％」である旨のコメントが付記される。

そして、ＵＭＬモデリングツール５０のアドオン（テストスクリプトを生成する拡張機能）により、シーケンス図Ｔ４０を表すテストスクリプトＴ４２が生成される。より具体的に、テストスクリプトＴ４２は、図４のテストスクリプトＴ２２において、通信負荷を３０％にする旨の記述（論理）が反映（追加）されたものである。尚、テストスクリプトＴ４２の具体的な記載については省略する。

ここで、図５に示すフローチャートは、テストスクリプトＴ４２に基づき、ＣＡＮバスモニタ５２において実行される処理を表すフローチャートである。ＣＡＮバスモニタ５２は、テストスクリプトＴ４２を解釈し、例えば「通信負荷３０％」という条件を表す部分の記述に基づき、図５のフローチャートに示す処理を実行する。この処理は、ＣＡＮバスモニタ５２において、テストスクリプトＴ４２の内容が解釈された時点で開始される。

この処理では、まずＳ１１０において、テストスクリプトＴ４２に含まれるテスト仕様（テストスクリプトＴ４２のうち、テストスクリプトＴ２２に相当する部分）の内容を解析し、そのテスト仕様において用いられていない信号の種類を算出する。そして、使用されていない信号の中から何れかを選択する。例えば、信号の種類として信号Ａ〜Ｅがあり、そのうち、信号Ａ，Ｂがテスト仕様において用いられており、残りの信号Ｃ〜Ｅが用いられていないとする。この場合、信号Ｃ〜Ｅの中から何れかを選択する。

次に、Ｓ１２０に進み、選択した信号をネットワーク（ＣＡＮ）に送出する。例えば、信号Ｃ〜Ｅのうち信号ＣをＳ１１０において選択したとすると、Ｓ１２０では、その信号ＣをＣＡＮに送出する。

Ｓ１２０の後はＳ１３０に進み、予め定められた期間の間待機する。
次に、Ｓ１４０に進み、ＣＡＮ上の通信負荷が３０％未満か否かを判定し、３０％未満であると判定すると（Ｓ１４０：ＹＥＳ）、Ｓ１５０に移行する。

Ｓ１５０では、待機期間（Ｓ１３０における待機期間）を所定間隔だけ短くする。そして、再びＳ１２０に戻る。つまり、Ｓ１２０に戻って信号Ｃを送出した後、Ｓ１３０に進み、前述のＳ１５０で所定間隔だけ短く設定された期間の間待機する。

そして、Ｓ１４０でＣＡＮ上の通信負荷が３０％未満でない、つまり３０％以上であると判定すると（Ｓ１４０：ＹＥＳ）、そのままＳ１２０に戻る。
このようにして、通信負荷が３０％以上になるまで信号Ｃの送出間隔が徐々に狭められ、通信負荷が３０％に達すると、その際の送出間隔での信号Ｃの送出が続けられることとなる。尚、Ｓ１３０の待機期間は、初期設定では、通信負荷が３０％未満となるように十分に大きな値となっている。

ＣＡＮバスモニタ５２は、図５のフローチャートに示すような処理を実行して通信負荷が３０％となるような環境を実現した後、図３，４にて前述したようにＥＣＵ５４の動作を検証する。

つまり、ＣＡＮバスモニタ５２は、ＥＣＵ５４やＣＡＮの状態の監視結果、及びテストスクリプトＴ４２の内容に基づき、ＥＣＵ５４の実際の動作（ＥＣＵ５４に実装されるプログラムの動作）が、テストスクリプトＴ４２が表すテスト仕様に合致するか否かを判断するとともに、判断結果を表すテストレポートＴ２４を、外部に視認可能に出力する。

以上説明したように、本第１実施形態によれば、試験者は、検証対象（例えばＥＣＵ５４）の動作を検証するための検証方法を表すテスト仕様を、例えばシーケンス図の形式で作成することができる。このため、試験者は、テスト仕様を簡単に作成することができる。また、テスト仕様の内容が、試験者或いは第三者にとって視覚的に分かりやすいものとなるため、テスト仕様の内容（妥当性等）の確認作業等の時間を削減し得るようになる。

また、検証対象（例えばＥＣＵ５４）において送受信される信号の種類の適否や送受信タイミングも検証することができ便利である。
また、テスト仕様に基づき試験者により作成されたシーケンス図が、コンピュータにおいて認識可能なスクリプトに変換され、そのスクリプトがコンピュータ上で実行されることで、検証が進められるようになっているため、試験者がわざわざスクリプトを新たに生成する必要がない。したがって、検証に要する工数を大幅に削減し得るようになる。

また、検証対象（ＥＣＵ５４）が接続されるネットワーク（ＣＡＮ）上の例えば通信負荷といったような条件もテスト仕様に含めることができ、所望の条件下で検証が実行されるようにできるため、検証対象の検証をより精密に行うことができる。

また、検証対象（ＥＣＵ５４）に実装されるプログラムを書き換えたり、そのプログラムに検証のための処理を埋め込んだりする必要がないため、精密な検証を行うことができる。例えば、検証対象（ＥＣＵ５４）に実装されるプログラムの検証に際し、そのプログラムに検証のための処理を埋め込むと、その検証のための処理自体の処理時間が必要となったり新たな負荷が生じたりするため、検証対象のプログラムの動作に影響が出るおそれもあるが、本第１実施形態の検証システム１によれば、そのような問題を回避することができる。

尚、本第１実施形態において、設計図面描画ツール４０、ＵＭＬモデリングツール５０がモデル生成手段及び条件モデル生成手段に相当し、シーケンス図Ｔ２０が挙動モデルに相当し、テストスクリプト生成ツール４２及びＵＭＬモデリングツール５０のアドオン（テストスクリプトを生成する拡張機能）がスクリプト変換手段及び条件スクリプト変換手段に相当し、テストスクリプト解釈ツール４４及びＣＡＮバスモニタ５２がスクリプト解釈手段、合否判定手段、判定結果出力手段、条件再現手段、監視手段に相当し、特に、図５のフローチャートに示す処理が条件再現手段に相当している。
［第２実施形態］
次に、第２実施形態の検証システム１について、第１実施形態の検証システム１と異なる点を中心に説明する。

図６は、第２実施形態の検証システム１の概念図である。
第２実施形態の検証システム１は、第１実施形態の検証システム１と比較して、ＸＭＬ（Ｅｘｔｅｎｓｉｂｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルを扱う点が異なっている。尚、ＸＭＬは、文書の意味や構造、データの意味や構造を記述するためのマークアップ言語の１つである。ＸＭＬを用いて書かれた文書はテキストファイルとなる。つまり、ＸＭＬファイルはテキストファイルである。

第１実施形態と異なる点をより具体的に説明する。
第１に、ＸＭＬファイルを扱うＣＡＮバスモニタ６４が用いられる点が異なっている。ＣＡＮバスモニタ６４は、ＸＭＬパーサ（ＸＭＬ文書をアプリケーションが利用しやすい形式に変換するソフトウエア）を備えている。

第２に、設計図面描画ツール４０として、試験者により入力（生成）された図面（テスト仕様を表す例えばシーケンス図）をＸＭＬに変換する機能を有するＵＭＬモデリングツール６０が用いられる点が異なっている。

第３に、テストスクリプト生成ツール４２として、ＵＭＬモデリングツール６０により生成されたＸＭＬファイルをＣＡＮバスモニタ６４の仕様に合致したＸＭＬファイルに変換するＸＭＬ変換プログラム６２が用いられる点が異なっている。

尚、ＵＭＬモデリングツール６０及びＸＭＬ変換プログラム６２は図１におけるＰＣ１０に実装され、ＣＡＮバスモニタ６４は図１におけるＰＣ１２に相当し、ＥＣＵ５４は図１におけるテスト対象通信装置１４に相当する。

図６において、試験者は、ＵＭＬモデリングツール６０を介して、テスト仕様を入力する。より具体的に、テスト仕様を表すシーケンス図を作成する。
ＵＭＬモデリングツール６０を介して試験者により生成されたシーケンス図Ｔ３０は、外部に視認可能に出力される。

また、ＵＭＬモデリングツール６０は、試験者により入力されたテスト仕様（シーケンス図Ｔ３０）をＸＭＬファイルＴ３２に変換して出力する。具体的に、ＸＭＬファイルＴ３２がＸＭＬ変換プログラム６２に入力される（渡される）。

ＸＭＬ変換プログラム６２は、ＵＭＬモデリングツール６０から受け取ったＸＭＬファイルＴ３２を、さらに、ＣＡＮバスモニタ６４の仕様に合致したＸＭＬファイルＴ３４に変換する。

ＸＭＬ変換プログラム６２により生成されたＸＭＬファイルＴ３４は、ＣＡＮバスモニタ６４に入力される。
ＣＡＮバスモニタ６４は、ＥＣＵ５４やＣＡＮの状態の監視結果、及びＸＭＬファイルＴ３４の内容に基づき、ＥＣＵ５４の実際の動作（ＥＣＵ５４に実装されるプログラムの動作）が、ＸＭＬファイルＴ３４が表すテスト仕様に合致するか否かを判断する。そして、ＣＡＮバスモニタ６４は、判断結果を表すテストレポートＴ３６を、外部に視認可能に出力する。また、ＣＡＮバスモニタ６４は、ＥＣＵ５４における通信ログＴ３８を外部に出力するようになっている。

このような第２実施形態によっても、第１実施形態と同様の効果を得ることができる。特に、ＸＭＬファイルを扱うようになっているため、試験者は、テキストエディタを用いてそのＸＭＬファイルの中身を読むことができ、また、テキストエディタを用いてＸＭＬファイルを編集することもできる。このため、場合によっては、試験者にとって検証作業が進めやすくなる。
［第３実施形態］
次に、第３実施形態の検証システム１について、第１実施形態の検証システム１と異なる点を中心に説明する。

図７は、第３実施形態の検証システム１の概念図である。尚、第３実施形態では、テストスクリプト生成機能７２はＵＭＬモデリングツール７０が有する機能（ＵＭＬモデリングツール７０の拡張機能）であるが、便宜上、別ブロックで記載している。また、テスト機能７４は監視ソフトウエア７６が有する機能であるが、便宜上別ブロックで記載している。

ＵＭＬモデリングツール７０及びテストスクリプト生成機能７２は図１におけるＰＣ１０に実装され、テスト機能７４及び監視ソフトウエア７６は図１におけるＰＣ１２に実装され、ＥＣＵ５４は図１におけるテスト対象通信装置１４に相当する。

第３実施形態の検証システム１は、第１実施形態の検証システム１と比較して、ＣＡＮデータベース（以下、ＤＢとも記載する）８０を備えている点が異なっている。ＣＡＮＤＢ８０は、ＣＡＮ上でやりとりされる信号のそれぞれについて、その信号の物理値を、論理名に対応付けたデータベースである。尚、論理名は、信号の内容・性質等を端的に表すように付されている。

そして、ＵＭＬモデリングツール７０は、試験者の入力に基づくシーケンス図Ｔ５０の描画において、例えば信号を表す物理値が試験者により入力されると、ＣＡＮＤＢ８０を参照し、その物理値で入力された信号を論理名で表すようになっている。つまり、シーケンス図Ｔ５０上においては、信号は、その信号の内容・性質等を表す論理名で表されるようになっている。

ＵＭＬモデリングツール７０により生成されたシーケンス図Ｔ５０を表す情報はテストスクリプト生成機能７２に渡され、テストスクリプト生成機能７２は、そのシーケンス図Ｔ５０を表す情報を、監視ソフトウエア７６が有するテスト機能７４にて認識可能なテストスクリプトＴ５２に変換する。テストスクリプト生成機能７２は、そのテストスクリプトＴ５２の生成において、ＣＡＮＤＢ８０を参照し、信号を論理名で記述するようになっている。

テストスクリプトＴ５２は、監視ソフトウエア７６のテスト機能７４に渡される。テスト機能７４は、監視ソフトウエア７６によるＥＣＵ５４、ＣＡＮ上の監視結果、及びテストスクリプトＴ５２の内容に基づき、ＥＣＵ５４の実際の動作（ＥＣＵ５４に実装されるプログラムの動作）が、テストスクリプトＴ５２が表すテスト仕様に合致するか否かを判断し、判断結果を表すテストレポートＴ５４を出力する。また、監視ソフトウエア７６は、ＥＣＵ５４における通信ログＴ５６を出力する。

このように、本第３実施形態においては、テスト仕様を表すシーケンス図Ｔ５０、及びシーケンス図Ｔ５０を変換したテストスクリプトＴ５２において、信号が論理名で記述されるようになっている。このため、試験者或いは第三者（確認者）にとって可読性が向上する。したがって、試験者或いは第三者（確認者）は、シーケンス図Ｔ５０及びテストスクリプトＴ５２の内容を把握し易くなり、ひいては、その内容の確認、チェック等に要する時間を削減し得る。

ところで、上記第１〜第３実施形態の検証システム１では、以下の変形例１，２のように構成しても良い。
〈変形例１〉
まず、変形例１について図８を用いて説明する。

図８の変形例１では、ＰＣ２０が、例えば第１実施形態に示すような検証システム１の機能を備えている。言い換えると、ＰＣ２０は、第１実施形態のＰＣ１０，１２の両方の機能を備えている。

具体的に、ＰＣ２０は、テスト対象通信装置１４と接続され、そのテスト対象通信装置１４の動作を監視する。また、ＰＣ２０は、設計図面描画ツール４０、テストスクリプト生成ツール４２、テストスクリプト解釈ツール４４を備えている。

このような構成の検証システム１では、試験者により、ＰＣ２０上でテスト仕様が作成され（言い換えると、テスト仕様を表すシーケンス図が作成され）、その作成されたテスト仕様（シーケンス図）は、ＰＣ２０上で、そのＰＣ２０が認識可能なテストスクリプトに変換される。ＰＣ２０は、テスト対象通信装置１４の実際の動作が、そのテストスクリプトが表すテスト仕様に合致するか否かを判断する。

このように、第１実施形態で説明した検証システム１の構成を、１台のコンピュータで実現することもできる。これによれば、コンピュータを複数台用いる場合と比較して、コストや設置スペースを節約することができる。
〈変形例２〉
次に、変形例２について図９を用いて説明する。

図９の変形例２の検証システム１は、設計図面描画ツール４０を備えたＰＣ３０と、テストスクリプト生成ツール４２を備えたＰＣ３２と、テストスクリプト解釈ツール４４を備えたＰＣ３４と、テスト対象通信装置１４の動作を監視する通信監視装置３６とを備えている。つまり、各機能毎に、専用のコンピュータが設けられている。

このような本変形例２では、試験者は、ＰＣ３０を用いて、テスト仕様を表す図面（例えばシーケンス図）を描画する。ＰＣ３０において描画されたシーケンス図Ｔ６を表す情報は、ＰＣ３０からＰＣ３２に出力される。

ＰＣ３２は、ＰＣ３０から入力されたシーケンス図Ｔ６を表す情報をコンピュータが認識可能なテストスクリプトＴ４に変換する。ＰＣ３２にて変換されたテストスクリプトＴ４は、ＰＣ３２からＰＣ３４に出力される。

ＰＣ３４は、ＰＣ３２から入力されたテストスクリプトＴ４を解釈する。
通信監視装置３６は、テスト対象通信装置１４及びテスト対象通信装置１４が接続されるネットワークの状態を監視し、その監視結果を、ＰＣ３４に出力する。

そして、ＰＣ３４は、テストスクリプトＴ４の解釈結果、及び通信監視装置３６から入力された監視結果に基づき、テスト対象通信装置１４の実際の動作が、テストスクリプトＴ４が表すテスト仕様に合致するか否かを判断する。

このような本変形例２では、各機能毎に、専用のコンピュータが設けられているため、処理負荷が各コンピュータに分散される。よって、処理に要する時間を短縮することができる。

以上、本発明の一実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、本発明の技術範囲内において種々の形態をとることができる。
例えば、上記実施形態において、設計図面描画ツール４０を介して出力される設計図面や、テストスクリプト生成ツール４２を介して出力されるテストスクリプトは、印刷出力されるようにしても良い。また、テストレポートや通信ログも印刷出力されるようにしても良い。

また、上記実施形態では、テスト仕様がシーケンス図の形式で表されるようになっているが、テスト仕様を表す際のモデルの形式はどのようなものでも良い。

第１実施形態の検証システム１のハードウエア構成を表す概略図である。 検証システム１における検証の流れ（検証方法）を表す概念図である。 検証システム１を車両のネットワークに適用した例を表す図面である。 検証システム１の作用を表す図面である。 検証システム１の作用を表し、特に、通信負荷の設定について説明した図面である。 第２実施形態の検証システム１を表す概念図である。 第３実施形態の検証システム１を表す概念図である。 変形例１のハードウエア構成を表す図面である。 変形例２のハードウエア構成を表す図面である。

符号の説明

１…検証システム、１０ａ…パーソナルコンピュータ本体、１０ｂ…入力装置、１０ｃ…ディスプレイ、１４…テスト対象通信装置、３６…通信監視装置、４０…設計図面描画ツール、４２…テストスクリプト生成ツール、４４…テストスクリプト解釈ツール、４６…通信監視装置、５０…ＵＭＬモデリングツール、５０…モデリングツール、５２…ＣＡＮバスモニタ、６０…ＵＭＬモデリングツール、６２…ＸＭＬ変換プログラム、６４…ＣＡＮバスモニタ、７０…ＵＭＬモデリングツール、７２…テストスクリプト生成機能、７４…テスト機能、７６…監視ソフトウエア。

Claims (5)

1. 検証対象のプログラム、を実装した装置（以下、検証対象装置と言う）の挙動を監視する監視装置を備え、その監視装置の監視結果に基づき前記プログラムの動作を検証する検証システムであって、
   前記検証対象装置が振る舞うべき挙動を表すモデル（以下、挙動モデルと言う）を使用者の入力に基づき生成するモデル生成手段と、
   前記モデル生成手段により生成された前記挙動モデルをスクリプトに変換するスクリプト変換手段と、
   前記スクリプト変換手段により変換されて生成されたスクリプトを解釈するスクリプト解釈手段と、
   前記監視装置の監視結果に基づく前記検証対象装置の実際の挙動が、前記スクリプト解釈手段の解釈結果が表す挙動に合致するか否かに基づき、前記プログラムの動作の適否を判定する合否判定手段と、
   前記合否判定手段の判定結果を表す情報を出力する判定結果出力手段と、
   を備えていることを特徴とする検証システム。
2. 請求項１に記載の検証システムにおいて、
   前記検証対象装置は、ネットワークに接続されてそのネットワーク上の通信機器との間で信号の送受信を行う装置であり、
   前記挙動モデルは、少なくとも前記検証対象装置において前記通信機器との間で送受信されるべき信号（以下、送受信信号と言う）の情報を含み、
   前記送受信信号の内容を表す論理名をその送受信信号のそれぞれについて記憶するデータベースを備え、
   前記モデル生成手段は、前記データベースを参照し、前記送受信信号の論理名を用いて前記挙動モデルを生成することを特徴とする検証システム。
3. 請求項２に記載の検証システムにおいて、
   前記スクリプト変換手段は、前記データベースを参照し、前記送受信信号の論理名を用いてスクリプトを生成することを特徴とする検証システム。
4. 請求項１ないし請求項３の何れか１項に記載の検証システムにおいて、
   前記モデル生成手段は、前記検証対象装置の動作環境についての条件（以下、環境条件と言う）を表すモデル（以下、条件モデルと言う）を使用者の入力に基づき生成する条件モデル生成手段を備え、
   前記スクリプト変換手段は、前記条件モデル生成手段により生成された前記条件モデルをスクリプトに変換する条件スクリプト変換手段を備え、
   前記監視装置は、前記条件スクリプト変換手段により変換されて生成されたスクリプトに基づき前記環境条件を再現する条件再現手段を備え、その条件再現手段によりその環境条件が再現された際の前記検証対象装置の挙動を監視することを特徴とする検証システム。
5. 検証対象のプログラム、を実装した装置（以下、検証対象装置と言う）と接続され、その検証対象装置における前記プログラムの動作を検証する検証装置であって、
   前記検証対象装置の挙動を監視する監視手段と、
   前記検証対象装置が振る舞うべき挙動を表すモデル（以下、挙動モデルと言う）を使用者の入力に基づき生成するモデル生成手段と、
   前記モデル生成手段により生成された前記挙動モデルをスクリプトに変換するスクリプト変換手段と、
   前記スクリプト変換手段により変換されて生成されたスクリプトを解釈するスクリプト解釈手段と、
   前記監視手段の監視結果に基づく前記検証対象装置の実際の挙動が、前記スクリプト解釈手段の解釈結果が表す挙動に合致するか否かに基づき、プログラムの動作の適否を判定する合否判定手段と、
   前記合否判定手段の判定結果を表す情報を出力する判定結果出力手段と、
   を備えていることを特徴とする検証装置。

Images