JP6320328B2 - 被制御システムの制御ソフトウェアをテストする方法およびシステム - Google Patents

Description

本発明は、被制御システムの制御ソフトウェアをテストする方法およびシステムに関する。前記被制御システムは、１以上の電子制御ユニット、１以上のアクチュエータ、および１以上のセンサを備える。各センサは、前記１以上の電子制御ユニットのうち少なくとも１つに対して個々のセンサ信号を入力するように構成され、各アクチュエータは、前記少なくとも１つの電子制御ユニットから入力される個々の制御信号に応答して動作するように構成されている。各電子制御ユニットは、制御ソフトウェアコードデータに基づき個々の実行可能制御プログラムを実行し、入力センサ信号に基づき前記１以上のアクチュエータに対して１以上の制御信号を出力するように構成されている。

例えば車両制御システムや組込システムなどの被制御システム／プラントにおいて、制御ソフトウェアコードデータおよび現在センサ値によって与えられる制御ロジックに基づき各電子制御ユニット（ＥＣＵ）が計算した制御コマンドの出力にしたがって被制御システム／プラントのアクチュエータを制御する、１以上の電子制御ユニットが配置される。車両システムにおいて、この制御ソフトウェアコードデータと現在センサ値は、車両の動作および／または運転者のアクションを示している。例えばアクチュエータは、ＥＣＵソフトウェア制御に基づき、電子信号または油圧によって制御される。しかし電子制御ユニットの責任が増加し、被制御システムが複数の電子制御ユニットを備えあるいは複数の制御ユニットが共有アクチュエータ間で制御を共有して複雑性が増すことにより、機能性に対する要求は増え続けている。

制御ソフトウェアを検証しテストするためには、特に安全性要件の観点から、システムバグフリー開発の際に効率的かつ信頼性よく被制御システム／プラントの電子制御ユニットの制御ソフトウェアをテストすることが重要である。例えば日本国特開２００９−０１４４０６号公報は、いわゆるＨａｒｄｗａｒｅ−Ｉｎ−Ｔｈｅ−Ｌｏｏｐ（ＨＩＬ）手法に基づくソフトウェアテストプロセスについて記載している。ＨＩＬにおいては、プラントシミュレータが電子制御ユニットに取りつけられ、電子制御ユニットのソフトウェアをテストする。しかしこの手法は、電子制御ユニットの制御ソフトウェア動作にのみフォーカスし、プラント動作をテストすることにフォーカスしていないので、テストプロセスにおいてシステムバグが見逃される場合がある。またＨＩＬ手法において、２以上の電子制御ユニットを有するシステムをテストすることは困難であり、複数の電子制御ユニットが共同動作することに起因するシステムバグが見逃される場合がある。

上記に鑑みて、本発明の目的は、信頼性よくかつ効率的に被制御システムのシステムバグを発見することができる、被制御システムの制御ソフトウェアをテストする方法およびシステムを提供することである。このシステムバグは、複数の電子制御ユニットの共同動作およびプラント動作に起因する特定の状況において生じるものを含む。

上記目的を解決するため、本発明の実施形態に基づき、請求項１に係る被制御システムの制御ソフトウェアをテストする方法、請求項１４に係る被制御システムの制御ソフトウェアをテストするシステム、および請求項１５に係るコンピュータプログラムを提案する。従属請求項は望ましい実施形態に関するものである。

実施形態の１側面に基づき、被制御システムの制御ソフトウェアをテストする方法を提供することができる。前記被制御システムは、１以上の電子制御ユニット、１以上のアクチュエータ、および１以上のセンサを備える。各前記センサは、前記１以上の電子制御ユニットのうち少なくとも１つに対して個々のセンサ信号を入力するように構成され、各前記アクチュエータは、前記少なくとも１つの電子制御ユニットから入力される個々の制御信号に応答して動作するように構成されている。各前記電子制御ユニットは、制御ソフトウェアコードデータに基づき個々の実行可能制御プログラムを実行し、入力センサ信号に基づき前記１以上のアクチュエータに対して１以上の制御信号を出力するように構成されている。

前記方法は：前記１以上の電子制御ユニットそれぞれに対して制御ソフトウェアコードデータを提供するステップ；前記被制御システムに対してシミュレーションコードデータを提供するステップ；前記１以上の電子制御ユニットそれぞれに対して提供する制御ソフトウェアコードデータおよび前記提供するシミュレーションコードデータに基づきシステムモデルを生成するステップ；前記生成するシステムモデルに基づき実行可能プログラムを生成するステップ；および／または前記実行可能プログラムに基づきソフトウェア検証プロセスを実施するステップ；を有する。

本発明の実施形態に基づき、システムモデルに基づき構築された実行可能プログラム上でソフトウェア検証システムを実施することは、基本的な考え方である。前記システムモデルは、被制御システムの関連する電子制御ユニットそれぞれの制御ソフトウェアコードデータとともに、プラント動作を数値シミュレートするために生成されたシミュレーションコードデータを含む。これにより前記検証プロセスは、ある時点における１の電子制御ユニットの制御動作にフォーカスするのみならず、複数の電子制御ユニットの共同動作および前記制御システム／プラントの動作に起因して生じ得る影響を考慮する。その利点として、本発明の実施形態によれば、通常の制御ソフトウェア検証技術においては見逃される可能性のある、電子制御ユニットの共同動作とプラント動作に起因する特定状況下のみにおいて生じるシステムバグを含む関連システムバグを、効率的かつ信頼性よく発見することができる。

望ましい側面によれば、前記実行可能プログラムに基づく前記ソフトウェア検証プロセスを実施するステップは、前記システムモデルに基づき記号的実行を実施するステップを有する。前記生成したシステムモデルに基づき前記実行可能プログラムを生成するステップは、前記システムモデルの１以上のパラメータを記号的実行のシンボルへ転送するステップを有することが望ましい。これにより、シンボル変数の抽象パス条件に基づき、実入力値と比較して様々な状況を効率的かつ信頼性よくテストできる利点がある。

他の望ましい側面によれば、前記方法はさらに、システム入力情報データを提供するステップを有する。前記システム入力情報データは、記号的実行のシンボルへ転送される前記システムモデルの前記１以上のパラメータを示す。これにより、記号的実行のシンボルへ転送される前記システム入力値を選択し、またユーザ入力により変更し、複数の検証手法を効率的に使用できる利点がある。

前記システムモデルは、前記提供されるシステム入力情報データに基づき、パラメータをシンボルへ転送する機能を定義する、シンボルモジュールコードデータを備えることが望ましい。

他の望ましい側面によれば、前記方法はさらに、個々の制御エラー状況に対応する１以上の検証要件条件を示す検証要件情報データを提供するステップを有する。

ソフトウェア検証プロセスを実施するステップは：前記実行可能プログラムの１以上のパス条件にしたがって前記実行可能プログラムの実行ツリーを繰り返すステップ；および／または、各繰り返しにおいて前記１以上の検証要件条件のうち少なくとも１つが満たされているか否かをチェックするステップ、および、特に望ましくは前記１以上の検証要件条件のうち少なくとも１つが満たされていると判定する場合は前記制御エラー状況をユーザへ通知するステップを有することが望ましい。

他の望ましい側面によれば、前記方法はさらに、前記検出した制御エラー状況に対応付けられた特定のパス条件を出力するステップを有する。これにより、前記検出したエラーを招く前記システム入力変数の元になっているパス条件を、検出および分析できる利点がある。

他の望ましい側面によれば、前記方法はさらに、前記提供する制御ソフトウェアコードデータと前記提供するシミュレーションコードデータの関連する入力パラメータと出力パラメータを示すコラボレーション情報データを提供するステップを有する。これにより、前記提供する制御ソフトウェアコードデータと前記提供するシミュレーションコードデータの関連する入力パラメータと出力パラメータの既定関係を用いるシステムモデルを定義できる利点がある。

前記システムモデルは、前記提供するコラボレーション情報データに基づき、対応付けられた入力パラメータに対して出力パラメータをコピーする１以上の機能を示す、コラボレーションモジュールコードデータを有することが望ましい。

前記コラボレーションモジュールコードデータは：１以上の電子制御ユニットの制御ソフトウェアコードデータの出力パラメータを、１以上の電子制御ユニットの制御ソフトウェアコードデータの対応する入力パラメータに対してコピーする、第１機能；１以上の電子制御ユニットの制御ソフトウェアデータの出力パラメータを、前記シミュレーションコードデータの対応する入力パラメータに対してコピーする、第２機能；および／または、前記シミュレーションコードデータの出力パラメータを、１以上の電子制御ユニットの制御ソフトウェアコードデータの対応する入力パラメータに対してコピーする、第３機能；を提供することが望ましい。

他の望ましい側面によれば、前記システムモデルは、前記１以上の電子制御ユニットの前記制御ソフトウェアコードデータの１以上の機能の実行と、前記被制御システムの前記シミュレーションコードデータとの間の同期を示す、同期モジュールコードデータを有する。これにより、前記被制御プラントの時間的動作、および１または同時動作する複数の電子制御ユニットの制御動作とプラント動作との間の同期を考慮して、前記システムモデルを効率的かつ正確に提供できる利点がある。

前記同期モジュールコードデータは、前記１以上の電子制御ユニットおよび前記シミュレーションコードデータの前記制御ソフトウェアコードデータの実行可能機能の実行順序と実行タイミングを示す、実行可能機能を提供することが望ましい。特に、前記制御ソフトウェアコードデータの機能を、前記シミュレーションコードデータの機能とは異なる頻度で実行できるようにすることが望ましい。

他側面によれば、上記側面のうち１以上に基づき、検証システムが提供される。前記検証システムは：前記１以上の電子制御ユニットそれぞれの制御ソフトウェアコードデータを提供し、前記被制御システムのシミュレーションコードデータを提供するように構成された、データ提供ユニット；前記１以上の電子制御ユニットそれぞれに対して提供される制御ソフトウェアコードデータおよび前記提供するシミュレーションコードデータに基づきシステムモデルを生成するように構成されたシステムモデル構築器；前記生成したシステムモデルに基づき実行可能プログラムを生成するように構成されたコンパイラ；および／または、前記実行可能プログラムに基づきソフトウェア検証プロセスを実施するように構成された検証ユニット；を備える。

他側面によれば、コンピュータ読取可能媒体上に格納し、コンピュータデバイスが実行することができる、コンピュータプログラム手段を備えるコンピュータプログラム製品が提供される。前記プログラム手段は、前記側面のうち１以上に係る方法のステップを前記コンピュータデバイスに実施させる、実行可能命令を有する。

実施形態に基づく検証システムの概念図を示す。 図１の検証システムにおけるデータフロー構造を示す。 被制御システムの例を示す。 個々のモデル化した制御システムを示す。 図３Ａのブレーキ制御ユニットの制御ソフトウェアコードデータの一部を示す。 図３Ａの電子安定制御についての電子制御ユニットの制御ソフトウェアコードデータの一部を示す。 図３Ａの被制御システムのプラントシミュレーションコードデータの一部を示す。 図３Ａの被制御システムのコラボレーション情報データを示す。 図３Ａの被制御システムのテスト目的のためのシステム入力情報データを示す。 検証要件情報データを示す。 図７のコラボレーション情報データに基づくコラボレーションモジュールコードデータの一部を示す。 図８のシステム入力情報データに基づくシンボルモジュールコードデータの一部を示す。 図９の検証要件データに基づくアサートモジュールコードデータの一部を示す。 同期モジュールコードデータの一部を示す。 システムモデルデータの構成を示す。 システムモデル構造の概観を示す。 検証結果の表示例を示す。 実施形態に基づく制御ソフトウェアテストの検証プロセスのフローチャートを示す。

添付する図面を参照して本発明の望ましい実施形態を以下に説明する。実施形態の特徴や側面を変更または組み合わせて、本発明の別実施形態を形成することができる。

コンピュータを物理システムへリンクするＣｙｂｅｒ−Ｐｈｙｓｉｃａｌ Ｓｙｓｔｅｍ（ＣＰＳ）は、安全要件が厳しいプロセスを監視および制御するために用いられる。すなわち、故障すると多大な被害や損害を生じさせ得るプロセスである。安全重視のシステムは、離散（コンピュータ）領域とアナログ（制御）領域の双方においてよく研究されている。開発された技術は主に、特定の離散領域またはアナログ領域において適用される。Ｃｙｂｅｒ−Ｐｈｙｓｉｃａｌ Ｓｙｓｔｅｍはこれら双方の領域にかかっているので、個々の領域にフォーカスするとシステムレベルにギャップが生じ、両領域間で複雑に相互やり取りすると、統合ＣＰＳの物理部分またはデジタル部分を考慮するのみでは分析できないエラーが生じ得る。

Ｃｙｂｅｒ−Ｐｈｙｓｉｃａｌ Ｓｙｓｔｅｍ（ＣＰＳ）は、輸送システム、電力システム、その他安全重視のシステムにおいて用いられることが増えている。ＣＰＳを用いて、物理アクチュエータを通じた物理現象を監視および制御（アナログ）する。物理アクチュエータは、安全重視コンピュータシステムによって操作される（デジタル）。システムの安全を確保してシステムに対するまたは動作環境に対する被害を防ぐため、このプロセスは、ターゲットシステム動作を正確に監視し、アクチュエータを正確に操作することが必要である。

その結果、安全重視ＣＰＳにおいては、離散特性と連続特性の双方を考慮して正確な動作を保証する堅牢な検証技術が研究されてきた。しかし、これら技術は個々の側面にフォーカスしているのが通常なので、離散処理と連続動作との間の複雑な相互作用により、複雑なシステムレベルバグを引き起こす可能性がある。

例えば車両ブレーキ制御システムは、所与のシーケンスとタイミングの組み合わせの下で特定の運転者操作と特定の車両挙動の組み合わせによってのみ生じる、発見することが困難な安全性関連のバグを有している。重要なＣＰＳにおける安全検証要件は、述べるのは容易であるものの、従来のエンジニアリング手法を用いて全てのあり得るコンピュータ動作と制御相互作用をカバーするのは現実的でない。これら複雑な制御／コンピュータ動作の相互作用により、タイミングバグやシーケンスバグが生じ、これは発見することが特に困難である。また設計エンジニアは離散制御ドメインまたはコンピュータ動作ドメインにおいてのみ詳細な知識を有していることがよくあるので、この問題を非常に複雑にしている。

実施形態によれば、安全重視ＣＰＳにおいて実用可能な形式検証プラットフォーム／システムを用いることを提案する。提案する検証システムは、システムモデルの安全関連プロパティをチェックすることにより、システムレベルバグを発見することができる。システムモデルは、記号的実行ベースの形式検証に基づき、制御ソフトウェアとプラントソースコードを組み合わせることにより、制御システムの動作をシミュレートする。

実施形態の主要な側面は、以下に関するものである：１）安全重視ＣＰＳにおける実用可能な形式検証プロセスを構築する、２）安全重視ＣＰＳにおけるシステムモデル構築方法を開発する、３）安全重視ＣＰＳのシステム入力についてのシンボル定義を明確にする、４）安全重視ＣＰＳにおいてアサート命令を用いてプロパティ定義を明確にする、５）実際の車両ブレーキ制御システムの安全検証に関するケーススタディを通じて、システムレベルバグ検出を確立する、および／または、６）安全重視ＣＰＳにおける実用可能な最適化プロセスを構築する。

実施形態において、記号的実行を利用することを提案する。記号的実行ベースの形式検証により、ユーザはターゲットソースコードのエラーを生じさせる入力値ケースを効率的に発見することができる。検証プロセスは、ユーザが条件分岐（パス条件）を見てシンボルとして定義した変数値の変更によって生じ得る全ての影響を検査するからである。その結果、ユーザが検証ターゲットの入力変数をシンボルとして定義し、アサートコードとしてエラーを検出する負プロパティのような条件とともに分岐命令を挿入すると、ターゲットがそのプロパティを満たさない場合、検証プロセスはエラーを生じさせる入力ケースを発見する。

記号的実行ベースの形式検証は、検証ターゲットのプログラムロジックを分析し、シンボルに影響する数式を抽出する。検証プロセスは、その数式にしたがって個々の分岐についての制約条件を生成する。制約条件が複数のシンボルに関連する場合、検証プロセスはこれら数式を統合することにより制約条件を生成する。最後に検証プロセスは、制約条件を解くソルバを用いて、制約条件を満たすシンボルの固定値を提供する。これにより、プログラムがエラーパスに到達すると検証プロセスはエラーテストケースを通知することができるので、検証ターゲットのあり得る動作を全て論理的にカバーし、効率的な検証技術を提供することができる。

実施形態において、提案するプロセスにより、制御システム全体を検証することができる。プロセスにおいて、制御ソフトウェア、プラントコード、安全要件、および／またはシステム情報を組み合わせることにより、制御システム動作をシミュレートするシステムモデルを構築する。次に、安全要件違反を検出するプロパティにしたがって、シンボルシステム入力を用いてシステムモデル動作をチェックする。プラントコードは、プラント動作ロジックを有するコードに対応する。これは例えば、ＨＩＬＳデバイスの依存性コードを除き、ＨＩＬＳのプラントコードから抽出することができる。さらに、提案する検証プロセスを実現する形式検証プラットフォーム（検証システムとして）を提案する。この検証システムは、所与の制御ソフトウェア、ＨＩＬＳのプラントコード、安全要件、およびシステム情報から、システムモデルを自動的に生成することができる。システム情報は、システム入力、タスク実行期間、および／または、プラント離散時間に関連する。記号的実行ベースの形式検証により、システムはシステムモデルの安全検証を実施することができる。

図１は、実施形態に基づく検証システムの概略図を示す。検証システム１は、コンピュータ２を備える。コンピュータ２は演算ユニット３（例えば１以上のＣＰＵ）とメモリ４を有し、メモリ４はデータと演算ユニット３が実行するプログラムを格納するように構成されている。これはオペレーティングシステムプログラムを含む。メモリは揮発性メモリおよび／または不揮発性メモリを含み、例えばＲＡＭ、ＲＯＭ、キャッシュメモリ、ハードディスクストレージ、および／またはフラッシュメモリなどの異なるメモリユニットを含むこともできる。

メモリ４は、システム検証ツール５と記号的実行ベース検証ツール６を格納する。記号的実行ベース検証ツール６は例えば、ＥＸＥ、ＫＬＥＥ、ＣＲＥＳＴに基づく記号的実行ベース検証ツールである（例えば、Ｃ．ＣａｄａｒとＫ．Ｓｅｎによる“Ｓｙｍｂｏｌｉｃ Ｅｘｅｃｕｔｉｏｎ ｆｏｒ Ｓｏｆｔｗａｒｅ Ｔｅｓｔｉｎｇ：Ｔｈｒｅｅ Ｄｅｃａｄｅｓ Ｌａｔｅｒ”）。

さらに検証システム１は、ユーザ入力を受け取る入力デバイス８（例えばキーボード、キーパッド、マウス、タッチパッド、および／またはタッチスクリーン）、およびユーザに対してスクリーン上で情報を提供するディスプレイ９を備える。入力デバイス８とディスプレイ９は、コンピュータ２の入出力ユニット７によって検証コンピュータ２に接続されている。

本明細書において、２つのタイプのデータを区別する：情報データとコードデータである。情報データは、パラメータ、入出力パラメータ、パラメータ値、パラメータ間の関係、などの情報を示すデータタイプである。情報データの形式は限定されない。一方でコードデータは、Ｃ、Ｃ＋＋、ＰＥＲＬ、Ｐｏｓｔｓｃｒｉｐｔ、Ｊａｖａ、Ｊａｖａｓｃｒｉｐｔなどのプログラム言語のコードとして記述されており、個々のプログラム言語のルールに準じる。制御データは、入力パラメータに依拠し出力パラメータを提供する機能を定義する。これは例えば既定の計算式に基づく。コンパイラを用いることにより、コードデータを演算ユニット３が実行できる実行可能機能へ変換することができる。

図２は、図１に基づく検証システムにおけるデータフロー構造を示す。図２に示すように、以下の入力データを例示する：制御ソフトウェアコードデータ５０２（例えば１以上のＥＣＵからのソフトウェアソースコード）；プラントシミュレーションコードデータ５０３（例えばＳｉｍｕｌｉｎｋなどのコードジェネレータが生成したプラントソースコード）；コラボレーション情報データ５０４（システム構造の情報を示す）；システム入力情報データ５０５（システム入力の情報を示す）；ユーザが提供する検証要件情報データ５０６（１以上の検証要件の情報を示す）。

上記入力データは、システム検証ツール５のシステムモデル構築器５０１に対して入力される。システム構築器５０１は、入力データに基づきシステムモデル５０７を生成するように構成されている。入力データとは具体的に、ソフトウェアコードデータ５０２、プラントシミュレーションコードデータ５０３、コラボレーション情報データ５０４、システム入力情報データ５０５、検証要件情報データ５０６である。

生成されたシステムモデル５０７は、記号的実行ベース検証ツール６に対して入力され、記号的実行ベースの検証（例えば、上述したＫＬＥＥ、ＥＸＥ、またはＣＲＥＳＴなどの既知の記号的実行ベース検証ツールに基づいて）を実施する。記号的実行ベース検証ツール６は、検証結果６０２を出力する。

上記検証について、以下に述べる被制御システムである車両ブレーキ制御システムとともに説明する。ただし、検証プロセスはブレーキ制御システムに限定されるものではなく、様々な被制御システム／プラントに対して適用することができる。例えば、１以上の電子制御ユニット、１以上のアクチュエータ、１以上のセンサを備え、各前記センサは個々のセンサ信号を少なくとも１つの前記電子制御ユニットに対して入力するように構成され、各前記アクチュエータは少なくとも１つの前記電子制御ユニットからの個々の制御信号に応じて動作するように構成され、各前記電子制御ユニットは個々の制御プログラムを実行して入力センサ信号に基づき前記１以上のアクチュエータに対して１以上の制御信号を出力するように構成された、被制御システムである。

図３Ａは被制御システムの例を示し、図３Ｂは個々の被制御システムのモデル例を示す。ブレーキ制御システムは、２つの電子制御ユニットを備える。すなわちブレーキ制御ユニット５０２（ＢＣＵ５０２）と電子安定制御ユニット５０２（ＥＳＣ５０２）である。これらは通信ネットワーク（例えばシステムバスまたはＣｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ））を介して通信可能に接続されている。ブレーキ制御ユニット５０２は、ブレーキペダルから入力を受け取り（ペダルイベント）、ブレーキペダルからの入力に基づきアクチュエータとしてブレーキキャリパ５０３を制御し、ブレーキキャリパ５０３に対して加えられる油圧を介してブレーキ力を生成する。

被制御システムは、油圧システムにおける油圧を検出する圧力センサを有する。油圧システムのバルブはＥＳＣ５０２によって制御され、ＥＳＣ５０２は車両がサイドスリップ状態（サイドスリップイベント）にあるか否かを検出するセンサから入力を受け取り、車両のサイドスリップが検出された場合に限りその入力に基づき油圧を介してブレーキキャリパ５０３を制御する。

したがってＢＣＵ５０２とＥＳＣ５０２は、「共有する」油圧に基づきブレーキキャリパ５０３を制御する。ＢＣＵおよびＥＳＣ５０２の制御状態は、この２つの電子制御ユニット間で送受信される。始めに、運転者がブレーキペダルを押したことが検出され、これが「ペダルイベント」としてＢＣＵ５０２に対して入力され、ＢＣＵ５０２は検出された運転者のペダルストロークに基づき油圧を圧縮するよう指示し、油圧制御によりブレーキキャリパ５０３を駆動する。

「サイドスリップイベント」が検出されない限りＥＳＣ５０２は動作しないが、「サイドスリップイベント」が検出されＥＳＣ５０２に対して入力されると即座に、ＥＳＣはブレーキキャリパ５０３の制御を引き継ぐ。すなわち、ＥＳＣ５０２はその制御状態をＢＣＵ５０２に対して送信し、ＢＣＵ５０２はこれによりブレーキキャリパ５０３の制御を停止し（すなわち、ＢＣＵ５０２はこのような状況においては動作しない）、ＥＳＣ５０２はバルブを閉じる（油圧システムのＢＣＵ側に対する逆流を防止するため）とともに、バルブのＢＣＵ側の油圧システムからの油流（例えばオイル）を吸収することによりバルブの油圧ダウンストリーム（ブレーキキャリパ側）を増やすよう指示する。

車両が再び安定状態になったことが検出されたとき（サイドスリップがもう起こらない）、ＥＳＣ５０２はバルブを再開するよう指示し、新たな制御状態をＢＣＵ５０２に対して送信する。これによりＢＣＵ５０２は再び制御を引き継ぎ、ＥＳＣ５０２は少なくとも新たなサイドスリップイベントが検出されるまで制御を停止する。

しかし通常のシステムにおいて、ＢＣＵ５０２とＥＳＣ５０２は個々の独立した制御ソフトウェアコードに基づき動作し、個々の制御ソフトウェアについて信頼性を検証し機能を訂正する（すなわち、個々の制御ソフトウェアコード自身にバグがない）だけでは十分でない。複数の電子制御ユニットの共同動作によりシステム全体としての制御動作不良が生じ得ることを考慮する必要がある。

例えばシステムによっては、ＢＣＵ５０２は油流のリークを検出する制御を追加的に実装している場合がある。これにより、油リークに起因して油圧システムの圧力が通常以下に下がったことを検出した場合におけるブレーキ制御コマンドを増やしている。運転者はこれにより、リークが発生した場合であっても安全のためスピードを落とすことができる。

図３Ａのシステムにおいて、ＢＣＵ５０２とＥＳＣ５０２の制御ソフトウェアコードが個別に不具合／バグを有していない場合であっても、これはシステム全体バグを生じさせる場合がある。例えばサイドスリップイベントによりＥＳＣ５０２が制御を引き継ぎ、車両が安定してその制御を停止した場合、ＢＣＵ５０２はＥＳＣ５０２から受け取った状態情報に基づき再び制御を引き継ぐ。しかし、ＥＳＣによる制御の間に液体がバルブの上流側／ＢＣＵ側から吸収されているため、圧力低下を検出する場合がある。これにより、液体リークを検出したものと想定して（実際には起こっていない）、誤って高い圧力を加える可能性がある。このとき液体リーク制御は偶発的に油圧を上昇させるよう制御し、ブレーキ力を不意に生成させる可能性がある。

複数の電子制御ユニットが共同動作する場合における連携接続に起因して生じるこのような誤制御は、単一の電子制御ユニットの制御ソフトウェアを個別にテストする既知のソフトウェア検証技術においては、検出することができない。例えば１つの電子制御ユニットにおけるＨａｒｄｗａｒｅ−Ｉｎ−Ｔｈｅ−Ｌｏｏｐシステム検証（ＨＩＬ）がこれに当たる。

図４は、図３ＡのＢＣＵの制御ソフトウェアコードデータ５０２を示す。制御ソフトウェアコードデータ５０２は、関数ＢＣＵ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）を定義する。これは、図３ＡのＢＣＵの１ｍｓ周期の制御機能に対応する。すなわちＢＣＵは、１ｍｓサイクル毎に制御機能を実行する。

関数ＢＣＵ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）を実行するときの第１入力パラメータとして、制御ソフトウェアコードデータ５０２は入力パラメータＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓを受け取る。このパラメータは例えば１または０の値をとり、ＥＳＣ制御の状態を示す。例えば０はＥＳＣ制御が動作してないことを示し、１はＥＳＣ制御が動作していることを示す。入力パラメータＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓが０である場合、ＢＣＵ制御機能が実行され、そうでなければ（例えば入力パラメータＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓが１である場合）ＢＣＵはその１ｍｓサイクルの間は動作しない。

ＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓが０であることを検出した場合、ＢＣＵの制御ソフトウェアコードデータ５０２は、入力パラメータＢＣＵ＿ｉｎｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅ（ユーザによるブレーキペダルのペダルストロークを検出するセンサのセンサ値を示す）とＢＣＵ＿ｉｎｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅ（油圧システムのＢＣＵ側における圧力を検出する圧力センサのセンサ値を示す）の比を求めることにより、パラメータ「ｒａｔｉｏ」を計算する。具体的には、油圧システムの液体リークの場合において、ペダルストロークが大きい場合であっても、検出した圧力は小さい。

計算した「ｒａｔｉｏ」の値が例えば２未満であった場合（ｒａｔｉｏ＜２）、通常ブレーキ制御を実行する。この場合、出力パラメータＢＣＵ＿ｏｕｔｐｕｔ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄは、ブレーキペダルのペダル位置に基づき計算される（この場合：ｓｏｆｔｗａｒｅ＿ｉｎｐｕｔ＿ｐｅｄａｌ＿ｓｅｎｓｏｒ＿ｖａｌｕｅは、上述のパラメータＢＣＵ＿ｉｎｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅ＿ｖａｌｕｅに等しい）。計算されたＢＣＵ＿ｏｕｔｐｕｔ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄを用いて、油圧システムの圧力を制御するアクチュエータを駆動し、これによりブレーキキャリパを駆動する。

一方で計算したｒａｔｉｏが２未満でない場合、液体リークが生じていると想定され、フェールセーフモードが実行される。フェールセーフモードにおいては、ＢＣＵ＿ｏｕｔｐｕｔ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄは安全のため高い値で出力される。ここでは説明を簡単にするため固定値１０を用いる。実際のフェールセーフモードは、状況に応じて（例えば別のセンサ入力に基づき）可変の高出力コマンドを出力すべきであることを理解されたい。

ＢＣＵ制御を要約すると、ＢＣＵは、液体リークが生じておらずＥＳＣが動作していない場合、運転者のペダルストロークの位置を示すペダルセンサ値にしたがって、ブレーキ制御コマンドを計算することができる。一方でＥＳＣが制御を引き継いだ場合（すなわちＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓの場合）、ＢＣＵは動作せず、ブレーキ制御コマンドを出力しない。またＢＣＵ制御は、ペダルストロークと油圧の比較に基づき油圧システムにおける液体リークを検出するように構成された、液体リーク検出機能を提供する。

図５は、図３ＡのＥＳＣの制御ソフトウェアコードデータ５０２の一部を示す。ＥＳＣの制御ソフトウェアコードデータ５０２は、関数ＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）を定義する。この関数は、図３ＡのＥＳＣの１ｍｓ周期の制御機能に対応する。すなわちＥＳＣは、１ｍｓサイクル毎に制御機能を実行する。ＥＳＣのサイクル時間は本例において上記ＢＣＵのサイクル時間と同じであるが、本発明はサイクル時間が同じ電子制御ユニットを有するシステムに対して適用することに限定されるものではなく、以下に説明するようにシステム同期に応じて異なるサイクル時間を有するシステムに対して適用できることを付言しておく。

関数ＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）は、入力パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔを受け取る。この入力パラメータは、車両のサイドスリップが生じたか（パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが１）、または車両が安定であるか（サイドスリップなし、パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが０）を示す。パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔは、車両動作を示す１以上のセンサから入力される。このセンサは、加速度センサ、ジャイロセンサ、および／または、トラクション制御センサを含む。

パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが０である場合、ＥＳＣは動作せず、出力パラメータＥＳＣ＿ｏｕｔｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓを値０で出力する。この出力パラメータは、ＢＣＵに対して入力される（すなわち上述のＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓとして）。車両サイドスリップイベントが検出され、パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが０でない場合、ＥＳＣは出力パラメータＥＳＣ＿ｏｕｔｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓを値１で出力する。この出力パラメータはＢＣＵに対して入力され（すなわち上述のＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓとして）、ＥＳＣが制御を引き継いだことをＢＣＵに対して通知する。

パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが０でない場合、ＥＳＣは出力パラメータＥＳＣ＿ｏｕｔｐｕｔ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄを出力する。説明を簡単にするため、本例においてＥＳＣはブレーキ制御コマンドとして固定値を出力するが、これは本発明を限定することを意図したものではない。具体的には、制御コマンド値は、サイドスリップの間は他センサ入力に基づき車両状態に応じて可変であることが望ましい。

油圧システムのバルブはバックフローを自動的に防ぐように動作するバルブであることを想定し、記載の簡易のため図５には示していないが、パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが０でなく、バルブが制御可能バルブとして実装されている場合（例えばソレノイド制御バルブ）、ＥＳＣはバルブを閉じるアクチュエータに対して別の制御コマンドを出力することができる。

ＥＳＣ制御を要約すると、ＥＳＣユニットは、車両のサイドスリップが生じたことを示すセンサ入力にしたがって、ブレーキ制御コマンドを出力する（さらに場合によっては能動的に油圧システムのＢＣＵ側のバルブを閉じる）ことができる。またＥＳＣがＢＣＵからブレーキ制御を引き継いだとき、出力パラメータＥＳＣ＿ｏｕｔｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓ（ＢＣＵ＿ｉｎｐｉｕｔ＿ＥＳＣ＿ｓｔａｔｕｓとしてＢＣＵに対して入力される）により、ＢＣＵに対してＥＳＣ状態が出力される。サイドスリップが生じない限り、ＥＳＣは動作しない。

図６は、図３Ａの被制御システムのプラントシミュレーションコードデータ５０３を示す。プラントシミュレーションコードデータは、ＢＣＵとＥＳＣに関する上述の制御ソフトウェアコードデータとは別のものであることを付言しておく。制御ソフトウェアコードデータは、実施形態に係る検証システムがテストする電子制御ユニットＢＣＵとＥＳＣの実際の制御ソフトウェアコードに対応し、または少なくとも部分的にこれに基づくからである。プラントシミュレーションコードデータは、被制御システム／プラントの動作を記述しており、電子制御ユニットの出力パラメータを受け取って対応する出力パラメータを生成する。この出力パラメータは、次サイクルにおいて電子制御ユニットに対して（実行するソフトウェアコードの関数に対して）入力されるセンサ入力に対応する。

図３Ａのシステムに示すような車両の被制御システムにおいて、対応するプラントシミュレーションコードデータを実行して、電子制御ユニットが出力するコマンドに基づき被制御システム／プラントのシミュレートすることができる。さらに、１以上の運転シナリオにしたがって、運転者の行動をシミュレートすることができる。プラントシミュレーションコードデータは、被制御システムに対して入力される制御コマンドに基づき、被制御システム／プラントの現在ステータスを更新するように構成されている。このプロセスは、システムセンサの対応するセンサ値を計算するステップ、被制御システム／プラントの状態を表す内部値を更新／計算するステップ、を含む。

プラントシミュレーションコードデータは、要件にしたがってユーザが手動生成することもできるし、あるいはユーザはＭＡＴＬＡＢ／Ｓｉｍｕｌｉｎｋ（例えばサンプリング理論に基づき選択された離散時間間隔でＳｉｍｕｌｉｎｋ Ｃｏｄｅｒが生成する）などの自動コード生成器を用いてプラントモデルに基づきプラントシミュレーションコードデータを生成できることを付言しておく。

図６のプラントシミュレーションコードデータ５０３は、関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）を定義する。この関数は、ＢＣＵとＥＳＣから入力される制御コマンドパラメータを含む複数の入力パラメータに基づきプラントを更新する機能を定義する。図６のプラントシミュレーションコードデータ５０３は最初に、入力パラメータｐｌａｎｔ＿ｉｎｐｕｔ＿ｖａｌｖｅ＿ｓｔａｔｕｓの値を検出する。この入力パラメータは、油圧システムのバルブが開いているか（ｐｌａｎｔ＿ｉｎｐｕｔ＿ｖａｌｖｅ＿ｓｔａｔｕｓが０）、それとも閉じているか（ｐｌａｎｔ＿ｉｎｐｕｔ＿ｖａｌｖｅ＿ｓｔａｔｕｓが１）を示す。パラメータｐｌａｎｔ＿ｉｎｐｕｔ＿ｖａｌｖｅ＿ｓｔａｔｕｓは、ＥＳＣの状態またはＢＣＵ側圧力とＥＳＣ側圧力との比較に基づき決定することができる。

ｐｌａｎｔ＿ｉｎｐｕｔ＿ｖａｌｖｅ＿ｓｔａｔｕｓが０でありバルブが開いていることが検出された場合、プラントシミュレーションコードデータ５０３は、パラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔを用いて、出力パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅを決定する。この出力パラメータは、ブレーキペダルの位置を検出するセンサのセンサ値を示す。パラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔは、運転者がブレーキペダルを押したか否かを示す。運転者がブレーキペダルを押した場合、そのことはパラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔが１であることによって示され、運転者がブレーキペダルを押してない場合、そのことはパラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔが０であることによって示される。

ユーザがブレーキペダルを押していないことをシミュレートする場合、パラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔは０であり、パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅは０にセットされる。ユーザがブレーキペダルを押したことをシミュレートする場合、パラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔは１であり、パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅは例えば本例において説明の簡易のため固定値１０にセットされる。ただしパラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅは、運転者の行動動作のシミュレーションにしたがって可変させ得ることを理解されたい。

図６において、例えば「ｔｆ＿ｐｅｄａｌ＿ｓｔｒｏｋｅ」などのようにプレフィックス「ｔｆ」を付与した関数を用いており、これらプレフィックスはプラント動作の更新における対応する関数／パラメータの伝搬遅延を示している。例えば関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）は、最後に関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）を呼び出したときの従前のパラメータを用い、プレフィックス「ｔｆ」を付与したパラメータセットは、例えば関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）を次に呼び出すときまで更新されない。

プラントシミュレーションコードデータ５０３は、パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅを決定するように構成されている。このパラメータは、被制御システム／プラントのシミュレーションの出力パラメータとして、図３Ａの被制御システムの油圧システムにおける圧力値を示す。パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅは、入力パラメータｐｌａｎｔ＿ｉｎｐｕｔ＿ＢＣＵ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄの関数ｔｆ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅに基づき決定される。この入力パラメータは、ブレーキ制御ユニットＢＣＵが出力するブレーキ制御コマンドに対応する。ｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅはまた、被制御システムの圧力センサが出力する値に対応し、ブレーキ制御ユニットＢＣＵに対して入力される。

その他パラメータとして、プラントシミュレーションコードデータ５０３は、パラメータｂｒａｋｅ＿ｆｏｒｃｅを決定するように構成されている。このパラメータは、ブレーキキャリパ５０３によって加えられるブレーキ力を示す。パラメータｂｒａｋｅ＿ｆｏｒｃｅは、油圧システムの油圧にしたがって関数ｔｆ＿ｂｒａｋｅ＿ｆｏｒｃｅに基づき決定される。すなわち、上述のｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅに等しいｐｌａｎｔ＿ｏｕｔｐｕｔ＿ＢＣＵ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅに基づき決定される。

一方で、ｐｌａｎｔ＿ｉｎｐｕｔ＿ｖａｌｖｅ＿ｓｔａｔｕｓが１でありバルブが閉じていることが検出された場合、プラントシミュレーションコードデータ５０３は、パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅを決定するように構成されている。このパラメータは、被制御システム／プラントのシミュレーションの出力パラメータとして、図３Ａの被制御システムの油圧システムにおける圧力値を示す。ただしこのシミュレーションにおいて、プラントシミュレーションコードデータ５０３は、最初に別の圧力パラメータｐｌａｎｔ＿ｉｎｓｉｄｅ＿ＥＳＣ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅ（バルブのアップストリーム側とダウンストリーム側との間の圧力差がある場合があるためその時点で閉じているバルブのＥＳＣ側ダウンストリームにおける油圧システムの圧力を示す）を決定するように構成されている。

パラメータｐｌａｎｔ＿ｉｎｓｉｄｅ＿ＥＳＣ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅは、関数ｔｆ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅに基づき決定される。これは、入力パラメータｐｌａｎｔ＿ｉｎｐｕｔ＿ＥＳＣ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄの関数である。この入力パラメータは、安定制御のための電子制御ユニット（ＥＳＣ）が出力するブレーキ制御コマンドに対応する。その他パラメータとして、プラントシミュレーションコードデータ５０３は、パラメータｂｒａｋｅ＿ｆｏｒｃｅを決定するように構成されている。このパラメータは、バルブが閉じているシナリオにおいてブレーキキャリパ５０３が加えるブレーキ力を示す。パラメータｂｒａｋｅ＿ｆｏｒｃｅは、油圧システムの油圧にしたがって関数ｔｆ＿ｂｒａｋｅ＿ｆｏｒｃｅに基づき決定されるが、ここではＥＳＣ側の圧力に基づき（すなわちｐｌａｎｔ＿ｉｎｓｉｄｅ＿ＥＳＣ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅに基づき）決定される。

プラントシミュレーションコードデータ５０３は、出力パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅをパラメータｐｌａｎｔ＿ｉｎｓｉｄｅ＿ＥＳＣ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅの規定値へセットするように構成されている。このシミュレーションにおいて、ｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅは、バルブが閉じられているとき生じる上述の圧力差に起因して、ｐｌａｎｔ＿ｏｕｔｐｕｔ＿ＢＣＵ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅに等しくない。油流は油圧システムのＢＣＵ側から吸収される。

しかしこのとき上述のように、図４のＢＣＵ制御コードデータ５０２を実行し、車両が安定になってＥＳＣが動作しないとき、次サイクルの被制御システムの状態において、油圧システムの液体リークが実際には生じていないにも関わらず、パラメータ「ｒａｔｉｏ」が２以上と判定されることになる。このような状況は、いずれの電子制御ユニットの制御ソフトウェアコードのバグにも起因しない制御不具合を表し、それぞれ個別の制御ソフトウェアコードデータを有する複数の電子制御ユニットの共同動作においてのみ現れる検出困難なシステム全体バグを表している。本発明の実施形態の検証プロセスにおいては、そのような検出困難なシステムバグであっても、検証プロセスに追いて発見することができる。

上述のように本実施形態において、被制御システムの各電子制御ユニットの制御ソフトウェアコードデータの各部分を提供する。個々の制御ソフトウェアコードデータは、個々の電子制御ユニットによる制御のため用いる１以上の入力パラメータを受け取り、受け取った１以上の入力パラメータに基づき１以上の出力パラメータ（特に制御コマンド）を決定する、電子制御ユニットの制御動作に関連する。

本実施形態において、被制御システム／プラントの動作をシミュレートし、プラントの現在状態を更新する、少なくとも１つのプラントシミュレーションコードデータを提供する。別実施形態において、複数のプラントシミュレーションコードデータを提供し、被制御システム／プラントの複数部分をシミュレートすることもできる。

プラントシミュレーションコードデータが定義する機能を実行することによる被制御システム／プラントのシミュレーションは、入力値／入力パラメータとして、電子制御ユニットから出力値／出力パラメータを受け取り、これに基づき１以上の出力値／出力パラメータを決定する。これらは入力値／入力パラメータとして電子制御ユニットに対して入力される（例えばセンサ値を表す）。プラントシミュレーションコードデータが定義する機能を実行することにより、内部パラメータを決定することができる。例えば被制御システム／プラントの状態を表す上述のブレーキ力である。

上述のように被制御システムにおいて、電子制御ユニットの各出力パラメータは、１以上の他の電子制御ユニットの入力パラメータ（例えばＥＳＣ＿ｏｕｔｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓをＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓとして用いる）として用い、および／または、プラントシミュレーションコードデータにおける被制御システム／プラントの入力パラメータ（例えばＢＣＵ＿ｏｕｔｐｕｔ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄをｐｌａｎｔ＿ｉｎｐｕｔ＿ＢＣＵ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄとして用いる）として用いることができる。一方で、被制御システム／プラントのシミュレーションの各出力パラメータは、１以上のその他電子制御ユニットの入力パラメータとして用いることができる（例えばｐｌａｎｔ＿ｏｕｔｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅ＿ｖａｌｕｅをＢＣＵ＿ｉｎｐｕｔ＿ｐｅｄａｌ＿ｓｔｒｏｋｅ＿ｖａｌｕｅとして用いる）。

図７は、図３Ａの被制御システムのコラボレーション情報データ５０４を示す。コラボレーション情報データ５０４のフォーマットは限定されない。コラボレーション情報データ５０４において示されている情報は、後にコラボレーションモジュールコードデータ５０８を生成する際に用いる。

コラボレーション情報データ５０４は、入力パラメータと出力パラメータの関係を示す。また、制御ユニットから制御ユニットへ、制御ユニットから被制御システム／プラントへ、および／または、被制御システム／プラントから制御ユニットへ送信される出力パラメータとこれに対応する入力パラメータのマッピングを示す。すなわちコラボレーション情報データ５０４の情報は、パラメータ間の関係とデータフロー方向（すなわちある出力パラメータからこれに対応する入力パラメータへの方向）を示す。

例えば図７のコラボレーション情報データ５０４は、図３Ａのシステムの入出力パラメータの関係を記載している。例えば、図４のＢＣＵ制御ソフトウェアコードデータにおいて用いる出力パラメータＢＣＵ＿ｏｕｔｐｕｔ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄは、図６のプラントシミュレーションコードデータ５０３において用いる入力パラメータｐｌａｎｔ＿ｉｎｐｕｔ＿ＢＣＵ＿ｂｒａｋｅ＿ｃｏｎｔｒｏｌ＿ｃｏｍｍａｎｄとマッピング／対応付けされる（電子制御ユニットＢＣＵから被制御システム／プラントへ：「ｓｏｆｔｗａｒｅ ｔｏ ｐｌａｎｔ」）。

一方で、例えば図６のプラントシミュレーションコードデータ５０３において用いる出力パラメータｐｌａｎｔ＿ｏｕｔｐｕｔ＿ＢＣＵ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅは、図４のＢＣＵ制御ソフトウェアコードデータにおいて用いる入力パラメータＢＣＵ＿ｉｎｐｕｔ＿ｈｙｄｒａｕｌｉｃ＿ｐｒｅｓｓｕｒｅにマッピング／対応付けされる（被制御システム／プラントから電子制御ユニットＢＣＵへ：「ｐｌａｎｔ ｔｏ ｓｏｆｔｗａｒｅ」）。異なる電子制御ユニットの出力パラメータと入力パラメータの関係について、図７のコラボレーション情報データ５０４は、図５のＥＳＣ制御ソフトウェアコードデータにおいて用いる出力パラメータＥＳＣ＿ｏｕｔｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓが図４のＢＣＵ制御ソフトウェアコードデータにおいて用いる入力パラメータＢＣＵ＿ｉｎｐｕｔ＿ＥＳＣ＿ｓｔａｔｕｓにマッピング／対応付けされている関係を示している（ある電子制御ユニットから他の電子制御ユニットへ：「ＥＣＵ ｔｏ ＥＣＵ」）。

図８は、図３Ａの被制御システムをテストするためのシステム入力情報データ５０５を示す。システム入力情報データ５０５のフォーマットは限定されない。システム入力情報データ５０５において示されている情報は、後にシンボルモジュールコードデータ５１１を生成するために用いる。

システム入力情報データは、ソフトウェア検証の間に変数（システム入力）として変化するパラメータを示す。また、入力値が変化する可能性のある時間を示唆する時間間隔を示す。図８のシステム入力情報データ５０５は、図６のプラントシミュレーションコードデータ５０３において用いるパラメータ「ｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔ」と図５のＥＳＣ制御ソフトウェアコードデータにおいて用いる「ｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔ」を、ソフトウェア検証の間に変化するシステム入力変数として示す。これらシステム入力変数パラメータはともに、変化時間が２０００にセットされている（単位はｍｓであり、したがってそれぞれ１ｍｓサイクル時間に対応する関数ＢＣＵ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）とＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）は２０００回呼び出される）。

図９は、検証要件情報データ５０６を示す。検証要件情報データ５０６のフォーマットは限定されない。検証要件情報データ５０６において示されている情報は、後にアサートモジュールコードデータ５１０を生成するために用いる。

図９の検証要件データ５０６は、ソフトウェアテストの検証時間を示す。検証時間は５０００ｍｓにセットされている（すなわち、それぞれサイクル時間１ｍｓに対応する制御ソフトウェアコードデータの関数ＢＣＵ＿ｓｏｆｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）とＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）は、検証の間に５０００回呼び出される）。

図９の検証要件情報データ５０６は、検証要件（検証条件）を示す。これは、制御エラーを表す条件に対応する。検証要件は例えば、意図しないブレーキ作動が発生する条件として定義できる。具体的には、運転者がブレーキペダルを少なくとも５００ｍｓ（パラメータｐｅｄａｌ＿ｏｆｆ＿ｔｉｍｅが５００以上）押しておらず（パラメータｐｅｄａｌ＿ｅｖｅｎｔが０）、車両が少なくとも５００ｍｓ（パラメータｓｉｄｅｓｌｉｐ＿ｏｆｆ＿ｔｉｍｅが５００以上）安定であり（サイドスリップなし、パラメータｓｉｄｅ＿ｓｌｉｐ＿ｅｖｅｎｔが０）、それでもなお関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）を最後に呼び出したときからパラメータｂｒａｋｅ＿ｆｏｒｃｅが増える（パラメータｂｒａｋｅ＿ｆｏｒｃｅ＿ｉｎｃｒｅａｓｅが０より大きい）ような、条件である。

上記パラメータｐｅｄａｌ＿ｏｆｆ＿ｔｉｍｅ、ｓｉｄｅｓｌｉｐ＿ｏｆｆ＿ｔｉｍｅ、およびｂｒａｋｅ＿ｆｏｒｃｅ＿ｉｎｃｒｅａｓｅは、制御ソフトウェアコードデータの関数ＢＣＵ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）やＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）またはプラントシミュレーションコードデータの関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）において用いられていないが、制御ソフトウェアコードデータの関数ＢＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）やＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）またはプラントシミュレーションコードデータの関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）の検証プロセス中の複数回の呼び出し間における情報または情報変化を示すパラメータであることを、付言しておく。

例えばパラメータｐｅｄａｌ＿ｏｆｆ＿ｔｉｍｅは、パラメータｐｅｄａｌ＿ｅｖｅｎｔ＿ｓｗｉｔｃｈｉｎｇが１から０へ変わったことにより示されるブレーキペダル解放後からのカウントを表すカウンタによって表すことができる。パラメータｓｉｄｅｓｌｉｐ＿ｏｆｆ＿ｔｉｍｅは、パラメータｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔが１から０へ変わったことにより示される車両安定化後のカウントを表すカウンタによって表すことができる。パラメータｂｒａｋｅ＿ｆｏｒｃｅ＿ｉｎｃｒｅａｓｅは、プラントシミュレーションコードデータの関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）を現在の繰り返しループにおいて実行することにより定められるパラメータｂｒａｋｅ＿ｆｏｒｃｅの計算値を関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）の最後の呼び出しにおけるものと比較することにより得られる、変化量を示す。正値は計算したブレーキ力が増加したことを示し、負値は減少したことを示す。

時間解像度は、被制御システム／プラントの離散時間に依拠する。プラントシミュレーションの時間解像度は通常、電子制御ユニットのサイクル時間よりも短い（すなわち、プラントシミュレーションを呼び出す頻度は、電子制御ユニットの制御ソフトウェアコードデータ機能を呼び出す頻度よりも大きい）。

図１０は、図７のコラボレーション情報データ５０４に基づくコラボレーションモジュールコードデータ５０８の一部を示す。例えばコラボレーションモジュールコードデータ５０８は、手動生成することができる。あるいはコラボレーションモジュールコードデータ５０８は、図７のコラボレーション情報データ５０４に基づきコード生成器によって自動生成することが望ましい。

コラボレーションモジュールコードデータ５０８は、１以上の出力パラメータを１以上の入力パラメータへコピーする１以上の機能を備える。具体的には、コラボレーションモジュールコードデータ５０８は、１以上の電子制御ユニットの１以上の出力パラメータを被制御システム／プラントのシミュレーションの１以上の入力パラメータへコピーする１以上の機能、１以上の電子制御ユニットの１以上の出力パラメータを１以上の電子制御ユニットの１以上の入力パラメータへコピーする１以上の機能、および／または、被制御システム／プラントのシミュレーションの１以上の出力パラメータを１以上の電子制御ユニットへコピーする１以上の機能、を備える。

図１０のコラボレーションモジュールコードデータ５０８は、３つの関数ｃｏｐｙ＿ｓｏｆｔｗａｒｅ＿ｔｏ＿ｐｌａｎｔ（）、ｃｏｐｙ＿ｐｌａｎｔ＿ｔｏ＿ｓｏｆｔｗａｒｅ（）、ｃｏｐｙ＿ＥＣＵ＿ｔｏ＿ＥＣＵ（）の定義を備える。関数ｃｏｐｙ＿ｓｏｆｔｗａｒｅ＿ｔｏ＿ｐｌａｎｔ（）は、コラボレーション情報データ５０４の「ｓｏｆｔｗａｒｅ ｔｏ ｐｌａｎｔ」が示す対応関係にしたがって、ＢＣＵおよびＥＳＣの制御ソフトウェアコードの関数の出力パラメータを、被制御システム／プラントのシミュレーションの対応する入力パラメータへコピーする。

関数ｃｏｐｙ＿ｐｌａｎｔ＿ｔｏ＿ｓｏｆｔｗａｒｅ（）は、コラボレーション情報データ５０４の「ｐｌａｎｔ ｔｏ ｓｏｆｔｗａｒｅ」が示す対応関係にしたがって、被制御システム／プラントのシミュレーションの出力パラメータを、ＢＣＵとＥＳＣの制御ソフトウェアコードデータの関数の対応する入力パラメータへコピーする。関数ｃｏｐｙ＿ＥＣＵ＿ｔｏ＿ＥＣＵ（）は、コラボレーション情報データ５０４の「ＥＣＵ ｔｏ ＥＣＵ」が示す対応関係にしたがって、ＥＳＣの制御ソフトウェアコードデータの関数の出力パラメータを、ＢＣＵの制御ソフトウェアコードデータの関数の対応する入力パラメータへコピーする。

要約すると、コラボレーションモジュールコードデータ５０８は、電子制御ユニットの制御ソフトウェアと被制御システム／プラントとの間のデータ同期動作を実施する。コラボレーションモジュールデータ５０８は、被制御システム／プラントの動作を示すセンサデータとセンサ値を、プラント側から制御ソフトウェア側へコピーする実行可能関数、および、被制御システム／プラントのアクチュエータに対するコマンド出力を示す制御コマンドを制御ソフトウェア側からプラント側へコピーする実行可能関数を定義する。

１以上の電子制御ユニットを有するシステムにおいて、コラボレーションモジュールコードデータ５０８はさらに、制御出力パラメータをある電子制御ユニットからシステムの他の電子制御ユニットの対応する入力パラメータへコピーする、実行可能関数を定義することができる。

図１１は、図８のシステム入力情報データに基づくシンボルモジュールコードデータ５１１の一部を示す。図１１のシンボルモジュールコードデータ５１１は、ＫＬＥＥ記号的実行ベース検証ツールのフォーマットで形成される。シンボルモジュールコードデータ５１１は、コマンドｋｌｅｅ＿ｍａｋｅ＿ｓｙｍｂｏｌｉｃを利用して、ＫＬＥＥ記号的実行ベース検証ツールのシンタックスに基づき、関数ｓｙｍｂｏｌｉｃ＿ｍｏｄｕｌｅ（）を定義する。

具体的には、関数ｓｙｍｂｏｌｉｃ＿ｍｏｄｕｌｅ（）は、図８のシステム入力情報データに基づき生成され、図８のシステム入力情報データにおけるパラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔとｃａｒ＿ｓｉｄｅｓｌｉｐ＿ｅｖｅｎｔについてシンボル変数ＸおよびＹを用いるよう記号的ベース検証ツール６へ指示する。また、パラメータｄｒｉｖｅｒ＿ｐｅｄａｌ＿ｅｖｅｎｔをＸへ変換し、パラメータｃａｒ＿ｓｉｄｅｌｉｐ＿ｅｖｅｎｔをＹへ変換する。

ただし、システム入力情報データが示す時間２０００に基づき、関数ｋｌｅｅ＿ｍａｋｅ＿ｓｙｍｂｏｌｉｃは、時間カウントパラメータｖ＿ｔｉｍｅを２０００で割った余りが０である場合のみ呼び出される。すなわち、ｖ＿ｔｉｍｅが２０００の整数倍となった場合である。したがってシンボル変換は、システム入力情報データが定義しているように、２０００ｍｓ毎に実施される。

一般にシンボルモジュールコードデータは、制御ソフトウェアの記号的実行ベース検証の準備において、システム入力をＸやＹなどの抽象シンボルへ変換する。これは、ソフトウェア検証が様々な数値セットとともに様々な論理パスを網羅する必要がなく、パス条件に基づき複数の状況を抽象的にカバーする抽象変数を用いて、発生し得るパスをテストおよび検証できる、という利点がある。

図１２は、図９の検証要件データに基づくアサートモジュールコードデータ５１０の一部を示す。アサートモジュールコードデータ５１０は、実行可能関数ａｓｓｅｒｔｉｏｎ＿ｍｏｄｕｌｅ（）を提供する。この関数は、検証要件が満たされているか否かをチェックするｉｆ文を備える。満たしている場合、関数ｋｌｅｅ＿ａｓｓｅｒｔ（０）が実行され、ユーザに対してエラー／バグの発生を通知する。これによりユーザに対し、意図しない検証要件を充足する状態にシステムが達するパス条件が見つかったことを知らせる。ユーザに対する出力としては、パス条件を出力することが望ましい（すなわち、初期状態から検証条件を満たすに至るシステム入力変数の条件）。

関数ｋｌｅｅ＿ａｓｓｅｒｔ（）は、記号的実行ベース検証ツールＫＬＥＥ固有の関数であるが、本発明はこの記号的実行ベース検証ツールを用いることに限定されない。その他の記号的実行ベース検証ツールを用いることもできる。一般にアサートモジュールコードデータ５１０は、１以上の検証要件をチェックする１以上の実行可能関数を備える。ある検証要件が充足されると判定した場合、ユーザに対してエラー制御条件を検出したことを通知する。例えば、検証要件が充足され安全システム仕様違反があった場合である。

図１２のアサートモジュールコードデータ５１０の関数ａｓｓｅｒｔｉｏｎ＿ｍｏｄｕｌｅ（）内のｉｆ文条件は、図９の検証要件情報データ５０６の検証要件情報に基づき生成される。これは例えば手動で生成し、または例えばコード生成器により提供された検証要件情報データ５０６に基づき自動で生成することができる。

図１３は、同期モジュールコードデータ５０９の一部を示す。同期モジュールコードデータは、関数ｍａｉｎ（）を定義する。この関数は、例えばソフトウェアソースコード、制御ソフトウェアコードデータ、プラントシミュレーションコードデータ、または入力情報にしたがって、適当なタイミングにおいて個々の制御ソフトウェアとシミュレーションソフトウェアを呼び出す。

関数ｍａｉｎ（）は、変数ｖ＿ｔｉｍｅについてｆｏｒループ繰り返しプロセスを実施する。変数ｖ＿ｔｉｍｅは、検証プロセスの時刻を示し、初期値ｖ＿ｔｉｍｅ＝０から開始して最大値ＭＡＸまで繰り返される（増加する）。例えばパラメータｖ＿ｔｉｍｅの繰り返しは、上述のＢＣＵとＥＳＣのサイクル時間にしたがって、１ｍｓの繰り返しステップに対応する。パラメータｖ＿ｔｉｍｅは、１ｍｓ以下または以上の時間間隔に対応する単位で繰り返すこともできる。

繰り返しプロセスの各繰り返しにおいて、すなわち時間パラメータｖ＿ｔｉｍｅを増加させる繰り返しのなかの各検証時刻ステップにおいて、電子制御ユニットの制御ソフトウェアのコードデータの他モジュールの複数の関数が呼び出され、被制御システム／プラントのシミュレーションが呼び出される。

最初に、シンボルモジュールコードデータ５１１の実行可能関数ｓｙｍｂｏｌｉｃ＿ｍｏｄｕｌｅ（）が実行される。少なくともシンボルモジュールコードデータ５１１の時刻条件ｖ＿ｔｉｍｅ％２０００＝＝０を満たす場合、すなわちパラメータｖ＿ｔｉｍｅが２０００の整数倍となった場合、記号的実行の対応する抽象シンボルに対してシステム入力パラメータを転送することにより、記号的実行を初期化する。

同期モジュールコードデータ５０９は、実行可能関数ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ（）を提供することにより、電子制御ユニットの制御機能を簡易的に実施する。この関数は、パラメータｖ＿ｔｉｍｅ％１＝＝０である場合のみ、すなわちパラメータｖ＿ｔｉｍｅが１の整数倍となった場合のみ、関数ＢＣＵ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）とＥＳＣ＿ｓｏｆｔｗａｒｅ＿ｅｘｅｃｕｔｉｏｎ＿１ｍｓ（）を呼び出す（ｉｆ文のなかで）。これにより、電子制御ユニットの制御機能を呼び出す際の同期を提供することができる。異なるタイミングおよび／または異なる頻度で、さらには被制御システム／プラントのシミュレーションとは異なるタイミングおよび／または頻度で、複数の電子制御機能の関数を呼び出すこともできる。

アサートモジュールコードデータ５１０のｍａｉｎ関数において、シンボルモジュール（ｓｙｍｂｏｌｉｃ＿ｍｏｄｕｌｅ）を呼び出して記号的実行を実施した後、プラントシミュレーションコードデータの関数ｐｌａｎｔ＿ｕｐｄａｔｅ（）を呼び出して被制御システム／プラントの現在状態を更新するステップを実施し、コラボレーションモジュールコードデータの関数ｃｏｐｙ＿ｐｌａｎｔ＿ｔｏ＿ｏｓｆｔｗａｒｅ（）を呼び出して更新後状態にしたがって被制御システムのミュレーションの出力値を制御ソフトウェアコードデータにおける電子制御ユニットの制御ソフトウェアの対応する入力パラメータに対して転送し、上述の関数ｓｏｆｔｗａｒｅ＿ｅｘｅｕｔｉｏｎ（）をこの繰り返しにおけるパラメータｖ＿ｔｉｍｅの関数として呼び出して電子制御ユニットの制御サイクルを実施し、関数ｃｏｐｙ＿ＥＣＵ＿ｔｏ＿ＥＣＵ（）を呼び出して電子制御ユニットの制御サイクルのシミュレーションの出力値を制御ソフトウェアコードデータにおける他の電子制御ユニットの制御ソフトウェアの対応する入力パラメータに対して転送するとともにコラボレーションモジュールコードデータの関数ｃｏｐｙ＿ｓｏｆｔｗａｒｅ＿ｔｏ＿ｐｌａｎｔ（）を呼び出して被制御システム／プラントのシミュレーションの対応する入力パラメータに対して転送することにより、１制御サイクルがシミュレートされる。

次にｅｌａｐｓｅｄ＿ｔｉｍｅ＋＋によってカウンタがインクリメントされ、時刻パラメータが１単位増加したことを示す。この例において、これはカウンタｐｅｄａｌ＿ｏｆｆ＿ｔｉｍｅとｓｉｄｅｓｌｉｐ＿ｏｆｆ＿ｔｉｍｅを増やす。

次に関数ａｓｓｅｒｔｉｏｎ＿ｍｏｄｕｌｅ（）が呼び出され、次の繰り返しに進む前に現在の繰り返し時刻ｖ＿ｔｉｍｅにおける検証要件が満たされているか否かをチェックする。

図１４は、システムモデルコードデータ５０７の構成を示す。システムモデルコードデータ５０７は、電子制御ユニット（ここではＢＣＵとＥＳＣ）の制御ソフトウェアコードデータ５０２、プランシミュレーションコードデータ５０３、コラボレーションモジュールコードデータ５０８、シンボルモジュールコードデータ５０９、アサートモジュールコードデータ５１０、同期モジュールコードデータ５１１を備える。

図１５は、システムモデル構造の概略を示す。システムモデルは、データ同期のための通信モジュール、システムモジュールのモジュール間同期のための同期モジュールを備える。

データ同期は、制御ソフトウェアとプラントとの間のシステム内部的やり取りを実施する。すなわち通信モジュールは、制御ソフトウェアがアクチュエータ制御のため計算する現在の制御コマンドを、コントローラモデル（例えばＳｉｍｕｌｉｎｋ）からの出力を受け取るプラント入力へコピーする。本モジュールは、測定したプラント動作を示す現在のセンサ値を、プラントモデル（例えばＳｉｍｕｌｉｎｋ）からの出力を受け取る制御ソフトウェア入力へコピーする。ＥＣＵ間のやり取りも、本モジュールによってサポートされる。

同期モジュールは、適切なタイミングにおける順次呼び出しおよび繰り返し呼び出しにより、制御ソフトウェアおよびプラントの現在状態を保持する。また本モジュールは、システム内部時間における検証時間を制限して有限状態遷移を生成する。基本的に制御システムは、制御ソフトウェアを周期的に更新することにより制御ループを維持し、電力供給イベントを除いて終了はない。その結果、提案する検証プラットフォームのユーザは、有限時間を決定して実施形態における検証結果を取得する必要がある。有限時間は、ターゲットシステムの特性に依拠する。例えば可変システム入力のタイミングとシーケンスの組み合わせによって生じるシステム影響をユーザが見たい場合、有限時間はこれらを考慮して定義することが望ましい。また記号的実行ベース形式検証について、システムモデルにおいてシンボル定義モジュールとアサートモジュールを提供することができる。シンボル定義モジュールは、ユーザ操作やプラント動作に影響する検証ターゲット環境からのイベントなどのシステム入力を、シンボルとして定義する。検証の間にシステム入力の値を変更するため、モジュールはこれらを再定義することができる。ただし再定義は新たなシンボルを生成するので、検証時間が増える。特にシンボル個数に依拠するソルバの実行時間が増える。再定義を何度も実施することを避けるため、特定のタイミング（例えば１秒毎）やイベントトリガなどにしたがって分岐命令を用いる再定義を提供することができる。ただし、発生し得るパスの個数が指数的に増加するので、検証時間が多大になる。したがって、システム検証に最適な再定義頻度を決定することが重要である。また、システムモデルは離散時刻毎にそのプラント動作を更新するので、最適な離散時間を決定することも重要である。離散時間は、サンプリング理論に基づき決定することが望ましい。アサートモジュールは、例えばアサートコードであり、システムモデルの注目変数を監視することにより制御システムのプロパティをチェックすることができる。

図１６は、ディスプレイ９上における検証結果の表示例を示す。制御ソフトウェアコードデータの検証終了時、すなわち検証要件情報が定義する検証時間の終了時、検証結果を示す。検証結果は、示しているパス条件において検証要件を満たすエラー検出が発生したことを示す。パス条件は、システム入力パラメータが検出エラーのエラー状況に達する条件を定義する。また、適正パスのパス条件を図１６のディスプレイに示す。

図１７は、実施形態に基づく制御ソフトウェアテストの検証プロセスのフローチャートを示す。

ステップＳ０１において、１以上の関連する電子制御ユニットの制御ソフトウェアコードデータ５０２、プラントシミュレーションコードデータ５０３、コラボレーション情報データ５０４、システム入力情報５０５、検証要件情報データ５０６を提供する。すなわち、ユーザは電子制御ユニットのソースコード、プラントシミュレーションのソースコード、システム構造と入出力関係に関する情報、検証プロセスの変数を示すシステム入力に関する情報、テストする検証条件に関する情報をセットする。

ステップＳ０２においてユーザは、検証プロセスを実行する検証システムにおいて検証プロセスを初期化／開始する。提供するデータに基づき、検証システム１はシステム検証ツール５を利用する。システムモデル構築器５０１は、提供するデータに基づきシステムモデル５０７（例えば図１４）を生成するように構成されている。

ステップＳ０３において、システムモデル構築器５０１は、コラボレーション情報データ５０４に基づきコラボレーションモジュールコードデータ５０８を生成する。ステップＳ０４において、システムモデル構築器５０１は、システム入力情報データ５０５に基づきシンボルモジュールコードデータ５５１１を生成する。ステップＳ０５において、システムモデル構築器５０１は、検証要件情報データ５０６に基づきアサートモジュールコードデータ５１０を生成する。ステップＳ０６において、システムモデル構築器５０１は、電子制御ユニットの制御ソフトウェアコードデータ、プラントシミュレーションコードデータ、コラボレーションモジュールコードデータにしたがって、同期モジュールコードデータ５０９を生成する。

システムモデル５０７（システムモデルコードデータ）を構築するステップＳ０３〜Ｓ０６は、任意の実行順序または並列に実施できることを付言しておく。本発明は図１６の実行順序に限定されない。

ステップＳ０７において、システムモデル５０７を利用して、検証システム１の演算ユニット３が実行できる実行可能プログラムを生成する。具体的には、システムモデル５０７がシステムモデルコードデータとして提供されている場合、ステップＳ０７はコンパイラを用いて、例えば記号的実行などの検証目・BR>Iのため、システムモデルコードデータをコンパイルする。

ステップＳ０８において、演算ユニット３はシステムモデル５０７の実行可能プログラム（例えばコンパイルされたシステムモデルコードデータ）を実行し、記号的実行ベース検証ツール６を起動して、システムモデルプログラムを実行するとき検証要件に合致する１以上の条件に到達する実行パスが存在するか否かを記号的検証により検証する。そのようなエラー状況が発見された場合、対応するエラーがユーザに対して通知され、そのパス条件が示される。

ステップＳ０９において、記号的実行ベース検証ツール６は、例えばディスプレイ９を介してユーザに対して検証結果を通知する。ステップＳ１０において、ユーザは検証結果と検証要件に合致した状況に到達した実行ツリーのパス条件をチェックする。

まとめると、本実施形態により、ＥＣＵテストまたはシステムテストにおいて、１以上の電子制御ユニット（ＥＣＵ）を有する被制御システム／プラントにおける電子制御ユニットの制御ソフトウェアのテストを、信頼性よくかつ効率的に実施することができる。これによりユーザは、車両システム、建築機械システム、その他組込システムおよび制御システムなどの電子機械制御システムにおけるシステムバグを、開発フェーズにおいて効率的かつ信頼性よく発見することができる。

本発明は、１つの電子制御ユニットを備え、互いに通信しおよび／または被制御システムの１以上のアクチュエータを共有制御する２つの電子制御ユニットを備え、あるいはそれ以上の個数の電子制御ユニットを備える制御システムの開発に対して、効率的かつ信頼性よく適用することができる。本発明により、システム状態およびユーザ操作またはシステム状態とユーザ操作の特定の組み合わせに応じて複数電子制御ユニットの共同動作によって特定状況においてのみ発生するため既知の検証技術において発見できなかったシステムバグであっても、効果的に発見することができる。

上記実施形態の構造の特徴、コンポーネント、詳細部分は、交換または組み合わせて個別のアプリケーションに最適化された別実施形態を形成することができる。これら変更が当業者にとって明らかである限り、それら変更事項は、本明細書の記載を簡潔にするため必ずしも全ての可能な組み合わせを格別明示していないとしても、以上の説明によって示唆されているというべきである。

当業者が理解するように、以上説明した本発明および添付する図面は、方法（例えばコンピュータ実装したプロセス、ビジネスプロセス、その他任意のプロセス）、装置（デバイス、機械、システム、コンピュータプログラム製品、および／またはその他装置を含む）、またはこれらの組み合わせとして実施することができる。

したがって本発明の実施形態は、完全なハードウェア実施形態、完全なソフトウェア実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または「システム」と呼んでいるソフトウェアとハードウェアを組み合わせた実施形態をとることができる。さらに本発明の実施形態は、コンピュータ実行可能プログラムコードを格納するコンピュータ読取可能媒体上のコンピュータプログラム製品の形態をとることができる。

図面において用いている矢印は、２以上の要素が関連する通信、転送、その他動作を表すことを付言しておく。双方向矢印は一般に、動作が双方向に生じ得ることを示す（例えばコマンド／リクエストがある方向において生じ、対応する返答が他方向において生じ、あるいは各要素がピアトゥピア通信をする）。ただし状況によっては、必ずしも動作が双方向で生じない場合もある。

単方向矢印は一般に、もっぱらまたはその大部分は１方向の動作を示す。ただし状況によっては、その動作が実際には同方向の動作を含む場合があることを付言しておく（例えば送信者から受信者に対するメッセージと、受信者から送信者に対する確認応答、または送信前の接続確立と送信後の接続終了）。したがって、図面において特定の動作を表すため用いている矢印のタイプは、例示であって限定的に解釈すべきではない。

本発明の実施形態を、方法と装置のフローチャートおよび／またはブロック図、および同方法および／または装置が生成するグラフィカルユーザインターフェースの表示例とともに説明した。フローチャートおよび／またはブロック図の各ブロック、および／またはフローチャートおよび／またはブロック図のブロックの組み合わせ、およびグラフィカルユーザインターフェースは、コンピュータ実行可能プログラムコードによって実装できることが理解されるであろう。

コンピュータ実行可能プログラムコードを、汎用コンピュータ、特定用途コンピュータ、その他プログラム可能データ処理装置のプロセッサに提供して特定のマシンを生成し、コンピュータプロセッサまたはその他プログラム可能データ処理装置がそのプログラムコードを実行して、フローチャート、ブロック図、図面、および／または記載した説明の機能／動作／出力を実装する手段を生成することができる。

これらコンピュータ実行可能プログラムコードは、コンピュータ読取可能メモリに格納することができる。コンピュータ実行可能プログラムは、コンピュータその他プログラム可能データ処理装置を特定の態様で機能させ、コンピュータ読取可能メモリが格納しているプログラムコードが製品を形成するようにことができる。この製品は、フローチャート、ブロック図、図面、および／または記載した説明の機能／動作／出力を実装した指示手段を含む。

コンピュータ読取可能プログラムコードは、コンピュータ上その他プログラム可能データ処理装置上へ読み出し、コンピュータその他プログラム可能装置上で実施される動作ステップを生じさせて、コンピュータ実装プロセスを生成することができる。このプログラムコードは、コンピュータ上その他プログラム可能装置上で実行され、フローチャート、ブロック図、図面、および／または記載した説明の機能を実装するステップを提供する。これに代えて、ステップまたは動作を実装したコンピュータプログラムは、オペレータまたは人間により実装したステップまたは動作と組み合わせて、本発明の実施形態を実施することができる。

「サーバ」「プロセッサ」という用語は、本発明の実施形態において用いるデバイスを記載するために用いており、文脈上要求されていない限りは本発明を特定のデバイスタイプに限定するように解釈すべきではないことを付言しておく。したがってデバイスは、ブリッジ、ルータ、ブリッジ−ルータ（ブルータ）、スイッチ、ノード、サーバ、コンピュータ、アプライアンス、その他タイプのデバイスを含み、これに限られない。これらデバイスは通常、通信ネットワークを介して通信するための１以上のネットワークインターフェース、デバイス機能を実施するように構成されたプロセッサ（例えばメモリその他周辺機器および／またはアプリケーション専用ハードウェアを備えるマイクロプロセッサ）、を備える。

通信ネットワークは一般に、パブリックおよび／またはプライベートネットワークを含み、ローカルエリア、ワイドエリア、メトロポリタンエリア、ストレージ、および／またはその他タイプのネットワークを含む。また、アナログ技術、デジタル技術、光技術、ワイアレス技術（例えばＢｌｕｅｔｏｏｔｈ）、ネットワーク技術、インターネットワーク技術を含む通信技術を採用することができるが、これに限られない。

デバイスは、通信プロトコルとメッセージ（例えば、デバイスが生成し、送信し、受信し、格納し、および／または処理するメッセージ）を用いることができ、このメッセージは通信ネットワークまたは媒体によって伝送できることを付言しておく。

文脈上必要でない限り、本発明は特定の通信メッセージタイプ、通信メッセージフォーマット、または通信プロトコルに限定されるように解釈すべきではない。したがって通信メッセージは一般に、フレーム、パケット、データグラム、ユーザデータグラム、セル、その他タイプの通信メッセージを含み、これに限定されない。

文脈上必要でない限り、特定の通信プロトコルに言及しているのは例示である。その他実施形態として、様々な通信プロトコル（例えば日々開発されるプロトコルの変形または拡張）その他既知もしくは将来開発されるプロトコルを採用できることを理解すべきである。

ロジックフローは本発明の様々な側面を示すために記載したものであり、特定のロジックフローまたはロジック実装に本発明を限定するように解釈すべきではないことを付言しておく。全体結果を変更せずまたは本発明の範囲から逸脱することなく、説明したロジックを、複数のロジックブロック（例えばプログラム、モジュール、関数、サブルーチン）に分離することができる。

全体結果を変更せずまたは本発明の範囲から逸脱することなく、ロジック要素を追加し、変更し、省略し、異なる順序で実行し、あるいは異なるロジック構成（ロジックゲート、条件ロジック、基本的な論理ループ、その他ロジック構成）を用いて実装することができる。

本発明は、多くの異なる形態で実施することができる。これには、プロセッサ（例えばマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、汎用コンピュータ）とともに用いるコンピュータプログラムロジック、プログラマブル論理デバイス（例えばＦｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（ＦＰＧＡ）その他ＰＬＤ）とともに用いるプログラム可能ロジック、個別部品、集積回路（例えば特定用途集積回路（ＡＳＩＣ））、これらの組み合わせを含むその他手段が含まれるが、これらに限られない。説明した機能の全部または一部を実装したコンピュータプログラムロジックは例えば、コンピュータ実行可能形式に変換されるコンピュータプログラム命令セットとして実装される。これは例えば、コンピュータ読取可能記憶媒体内に格納され、オペレーティングシステムの制御下でマイクロプロセッサによって実行される。説明した機能の全部または一部を実装したハードウェアベースロジックは、１以上の適切に構成されたＦＰＧＡを用いて実装することができる。

説明した機能の全部または一部を実装したコンピュータプログラムロジックは、様々な形態で実装することができる。これにはソースコード形式、コンピュータ実行可能形式、様々な中間形式（例えばアセンブラ、コンパイラ、リンカ、ロケータが生成する形式）が含まれるが、これらに限られない。

ソースコードは、様々なプログラム言語（例えばオブジェクトコード、アセンブリ言語、Ｆｏｒｔｒａｎ、Ｃ、Ｃ＋＋、Ｊａｖａ、ＨＴＭＬなどの高レベル言語）で実装され様々なオペレーティングシステムまたは動作環境とともに用いられるコンピュータプログラム命令系列を含む。ソースコードは、様々なデータ構造と通信メッセージを定義し用いることができる。ソースコードは、コンピュータ実行可能形式（例えばインタプリタを介する形式）で構成することができる。あるいはソースコードは、コンピュータ実行可能形式に変換する（例えばトランスレータ、アセンブラ、コンパイラを介して）ことができる。

本発明の実施形態の動作を実施するコンピュータ実行可能プログラムコードは、オブジェクト指向、スクリプト、またはＪａｖａ、Ｐｅｒｌ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などの非スクリプトプログラム言語で記述することができる。ただし本発明の実施形態の動作を実施するコンピュータプログラムコードは、例えばＣ言語や同様のプログラム言語などの従来の手続的プログラム言語で記述することもできる。

説明した機能の全部または一部を実装したコンピュータプログラムロジックは、単一プロセッサが異なる時刻において（例えば同時に）実行し、あるいは複数プロセッサが同時にもしくは異なる時刻に実行して単一のオペレーティングシステムプロセス／スレッド下もしくは複数のオペレーティングシステムプロセス／スレッド下で動作することができる。

したがって「コンピュータプロセス」という用語は一般に、同一または異なるプロセッサ上で異なるコンピュータプロセスが実行されるか否かによらず、また異なるコンピュータプロセスが同一のオペレーティングシステムプロセス／スレッド下もしくは異なるオペレーティングシステムプロセス／スレッド下で実行されるか否かによらず、コンピュータプログラム命令セットを実行することを指す。

コンピュータプログラムは、記憶媒体内に任意の形式（例えばソースコード形式、コンピュータ実行可能形式、中間形式）で永続化または一時格納することができる。記憶媒体は例えば、半導体メモリデバイス（例えばＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュプログラマブルＲＡＭ）、磁気メモリデバイス（例えばディスケットまたは固定ディスク）、光メモリデバイス（例えばＣＤ−ＲＯＭ）、ＰＣカード（例えばＰＣＭＣＩＡカード）、その他メモリデバイスである。

コンピュータプログラムは、様々な通信技術を用いてコンピュータへ送信する信号として永続化することができる。これにはアナログ技術、デジタル技術、光技術、ワイアレス技術（例えばＢｌｕｅｔｏｏｔｈ）、ネットワーク技術、インターネットワーク技術が含まれるが、これに限らない。

コンピュータプログラムは、添付する印刷文書または電子文書（例えば市販ソフトウェア）とともに、リムーバブル記憶媒体として任意形式で配信し、コンピュータシステムにプリロードし（例えばシステムＲＯＭ上または固定ディスク上）、通信システム（例えばインターネットやＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を介してサーバや電子掲示板から配信することができる。

説明した機能の全部または一部を実装したハードウェアロジック（プログラム可能ロジックデバイスとともに用いるプログラム可能ロジックを含む）は、従来のマニュアル手法を用いて設計することができる。あるいは、例えばコンピュータ支援設計（ＣＡＤ）、ハードウェア記述言語（例えばＶＨＤＬやＡＨＤＬ）、ＰＬＤプログラム言語（例えばＰＡＬＡＳＭ、ＡＢＥＬ、ＣＵＰＬ）などの様々なツールを用いて設計し、キャプチャし、シミュレートし、電子文書化することができる。

適切なコンピュータ読取可能媒体を利用することができる。コンピュータ読取可能媒体は、例えば電子媒体、磁気媒体、光学媒体、電磁気媒体、赤外線媒体、半導体システム、装置、デバイス、または媒体であるが、これらに限らない。

コンピュータ読取可能媒体のより具体的な例としては、１以上の配線その他記憶媒体を有する電子接続が含まれるが、これに限らない。この記憶媒体は、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、消去可能プログラマブル読取専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、コンパクトディスク読取専用メモリ（ＣＤ−ＲＯＭ）、その他光学または磁気記憶デバイスを含む。

プログラム可能ロジックは、例えば半導体メモリデバイス（例えばＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュプログラマブルＲＡＭ）、磁気メモリデバイス（例えばディスケットやフラッシュディスク）、光メモリデバイス（例えばＣＤ−ＲＯＭ）、その他メモリデバイスなどの記憶媒体内に永続化または一時格納することができる。

プログラム可能ロジックは、様々な通信技術を用いてコンピュータへ送信する信号として永続化することができる。これにはアナログ技術、デジタル技術、光技術、ワイアレス技術（例えばＢｌｕｅｔｏｏｔｈ）、ネットワーク技術、インターネットワーク技術が含まれるが、これに限らない。

プログラム可能ロジックは、添付する印刷文書または電子文書（例えば市販ソフトウェア）とともに、リムーバブル記憶媒体として任意形式で配信し、コンピュータシステムにプリロードし（例えばシステムＲＯＭ上または固定ディスク上）、通信システム（例えばインターネットやＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を介してサーバや電子掲示板から配信することができる。本発明の実施形態は、ソフトウェア（例えばコンピュータプログラム製品）とハードウェアの組み合わせとして実装することもできる。本発明の実施形態は、全てハードウェアで実装することもできるし、全てソフトウェアで実装することもできる。

添付する図面において実施形態を説明したが、これら実施形態は説明目的のものであり本発明を制限するものではないことを理解されたい。また本発明の実施形態は、説明した特定の構造や配置に限定されるものではないことを理解されたい。以上説明したものに加えて、様々な変更、組み合わせ、省略、変形、代替が可能である。

当業者は、本発明の範囲および要旨から逸脱することなく、様々な修正、変更、および／または説明した実施形態の組み合わせを構成できることを理解するであろう。したがって、特許請求範囲の範囲内において、本発明は説明したものとは別の形態で実施できることを理解されたい。例えば明示しない限り、説明したプロセスのステップは、説明したものとは異なる順序で実施でき、１以上のステップを組み合わせ、分割し、同時実施することができる。

当業者は、本明細書の観点から、本発明の複数の実施形態を組み合わせてその他の実施形態を形成できることを理解するであろう。

Claims (15)

1. 被制御システムの制御ソフトウェアをテストする方法であって、
   前記被制御システムは、１以上の電子制御ユニット、１以上のアクチュエータ、および１以上のセンサを備え、各前記センサは、前記１以上の電子制御ユニットのうち少なくとも１つに対して個々のセンサ信号を入力するように構成され、各前記アクチュエータは、前記電子制御ユニットのうち少なくとも１つから入力される個々の制御信号に応答して動作するように構成され、各前記電子制御ユニットは、制御ソフトウェアコードデータに基づき個々の実行可能制御プログラムを実行し、入力センサ信号に基づき前記１以上のアクチュエータに対して１以上の制御信号を出力するように構成され、
   前記方法は、
   前記１以上の電子制御ユニットそれぞれに対して制御ソフトウェアコードデータを提供するステップ、
   前記被制御システムに対してシミュレーションコードデータを提供するステップ、
   前記提供するシミュレーションコードデータおよび前記１以上の電子制御ユニットそれぞれに対して提供する制御ソフトウェアコードデータに基づきシステムモデルを生成するステップ、
   前記生成するシステムモデルに基づき実行可能プログラムを生成するステップ、
   前記実行可能プログラムに基づきソフトウェア検証プロセスを実施するステップ、
   を有することを特徴とする方法。
2. 前記実行可能プログラムに基づき前記ソフトウェア検証プロセスを実施するステップは、前記システムモデルに基づき記号的実行を実施するステップを有する
   ことを特徴とする請求項１記載の方法。
3. 前記生成したシステムモデルに基づき前記実行可能プログラムを生成するステップは、前記システムモデルの１以上のパラメータを記号的実行のシンボルへ転送するステップを有する
   ことを特徴とする請求項２記載の方法。
4. 前記方法はさらに、システム入力情報データを提供するステップを有し、
   前記システム入力情報データは、記号的実行のシンボルへ転送される前記システムモデルの前記１以上のパラメータを示す
   ことを特徴とする請求項３記載の方法。
5. 前記システムモデルは、前記提供されるシステム入力情報データに基づき、パラメータをシンボルへ転送する機能を定義する、シンボルモジュールコードデータを備える
   ことを特徴とする請求項４記載の方法。
6. 前記方法はさらに、個々の制御エラー状況に対応する１以上の検証要件条件を示す検証要件情報データを提供するステップを有する
   ことを特徴とする請求項１から５のいずれか１項記載の方法。
7. 前記ソフトウェア検証プロセスを実施するステップは、
   前記実行可能プログラムの１以上のパス条件にしたがって前記実行可能プログラムの実行ツリーを繰り返すステップ、
   各繰り返しにおいて前記１以上の検証要件条件のうち少なくとも１つが満たされているか否かをチェックするステップ、
   前記１以上の検証要件条件のうち少なくとも１つが満たされていると判定する場合は前記制御エラー状況を検出したことをユーザへ通知するステップ、
   を有することを特徴とする請求項６記載の方法。
8. 前記方法はさらに、前記検出した制御エラー状況に対応付けられた特定のパス条件を出力するステップを有する
   ことを特徴とする請求項７記載の方法。
9. 前記方法はさらに、前記提供する制御ソフトウェアコードデータと前記提供するシミュレーションコードデータの関連する入力パラメータと出力パラメータの関係を示すコラボレーション情報データを提供するステップを有する
   ことを特徴とする請求項１から８のいずれか１項記載の方法。
10. 前記システムモデルは、前記提供するコラボレーション情報データに基づき、対応付けられた入力パラメータに対して出力パラメータをコピーする１以上の機能を示す、コラボレーションモジュールコードデータを有する
    ことを特徴とする請求項９記載の方法。
11. 前記コラボレーションモジュールコードデータは、
    前記１以上の電子制御ユニットの前記制御ソフトウェアコードデータの出力パラメータを、前記１以上の電子制御ユニットの前記制御ソフトウェアコードデータの対応する入力パラメータに対してコピーする、第１機能、
    前記１以上の電子制御ユニットの前記制御ソフトウェアコードデータの出力パラメータを、前記シミュレーションコードデータの対応する入力パラメータに対してコピーする、第２機能、
    および／または、
    前記シミュレーションコードデータの出力パラメータを、前記１以上の電子制御ユニットの前記制御ソフトウェアコードデータの対応する入力パラメータに対してコピーする、第３機能、
    を提供することを特徴とする請求項１０記載の方法。
12. 前記システムモデルは、前記１以上の電子制御ユニットの前記制御ソフトウェアコードデータの１以上の機能の実行と、前記被制御システムの前記シミュレーションコードデータとの間の同期を示す、同期モジュールコードデータを有する
    ことを特徴とする請求項１から１１のいずれか１項記載の方法。
13. 前記同期モジュールコードデータは、前記１以上の電子制御ユニットおよび前記シミュレーションコードデータの前記制御ソフトウェアコードデータの実行可能機能の実行順序と実行タイミングを示す、実行可能機能を記述しており、特に前記制御ソフトウェアコードデータの機能を、前記シミュレーションコードデータの機能とは異なる頻度で実行できるようにする
    ことを特徴とする請求項１２記載の方法。
14. 被制御システムの制御ソフトウェアをテストする検証システムであって、
    前記被制御システムは、１以上の電子制御ユニット、１以上のアクチュエータ、および１以上のセンサを備え、各前記センサは、前記１以上の電子制御ユニットのうち少なくとも１つに対して個々のセンサ信号を入力するように構成され、各前記アクチュエータは、前記電子制御ユニットのうち少なくとも１つから入力される個々の制御信号に応答して動作するように構成され、各前記電子制御ユニットは、制御ソフトウェアコードデータに基づき個々の実行可能制御プログラムを実行し、入力センサ信号に基づき前記１以上のアクチュエータに対して１以上の制御信号を出力するように構成され、
    前記検証システムは、
    前記１以上の電子制御ユニットそれぞれの制御ソフトウェアコードデータを提供し、前記被制御システムのシミュレーションコードデータを提供するように構成された、データ提供ユニット、
    前記提供するシミュレーションコードデータおよび前記１以上の電子制御ユニットそれぞれに対して提供される制御ソフトウェアコードデータに基づきシステムモデルを生成するように構成されたシステムモデル構築器、
    前記生成したシステムモデルに基づき実行可能プログラムを生成するように構成されたコンパイラ、
    前記実行可能プログラムに基づきソフトウェア検証プロセスを実施するように構成された検証ユニット、
    を備えることを特徴とするシステム。
15. コンピュータ読取可能媒体上に格納し、コンピュータデバイスが実行することができる、コンピュータプログラム手段を備え、
    前記コンピュータプログラム手段は、請求項１から１３のいずれか１項記載の方法のステップを前記コンピュータデバイスに実施させる、実行可能命令を有する
    ことを特徴とするコンピュータプログラム。

Images