(57)【特許請求の範囲】
【請求項１】
ソフトウェア機能および制御ユニットをシミュレートするためのシミュレーションモデルを利用し、前記制御ユニットの前記ソフトウェア機能を検証する方法であって、
エクスペリメンタル制御ユニット及び標準制御ユニットのために、同一のシミュレーションモデルから、前記ソフトウェア機能を実現するためのソフトウェアコードが自動的に生成され、
２つの前記制御ユニットのソフトウェア機能を検証するために、同一の入力値が入力され、２つの前記制御ユニットから、前記入力値に応じて出力される出力値が各々同期で検出され、
２つの前記制御ユニットの前記出力値の比較によって、前記ソフトウェア機能が検証され、さらに、前記エクスペリメンタル制御ユニットにおける前記ソフトウェアコードのコード・カバレッジを定めるために、前記ソフトウェアコード又は前記ソフトウェア機能の中において動作するパスが検出され、
前記エクスペリメンタル制御ユニットは、前記ソフトウェア機能の動作へのアクセスが可能なことを特徴とする、制御ユニットのソフトウェア機能を検証する方法。
【請求項２】
前記出力値又は最終的に出力される前に得られた経過値の検出と比較が、前記エクスペリメンタル制御ユニットによって自動的に実行されることを特徴とする、請求項１に記載の方法。
【請求項３】
前記ソフトウェア機能を実現するための前記ソフトウェアコードは、前記エクスペリメンタル制御ユニットまたは標準制御ユニットのために、異なる生成手段を用いて生成されることを特徴とする、請求項１に記載の方法。
【請求項４】
前記ソフトウェア機能が、車両における駆動シーケンスを制御するために使用されることを特徴とする、請求項１に記載の方法。
【請求項５】
前記ソフトウェア機能の全ての検証は、実際の車両を使用することなく、車両をシミュレートするシミュレーション手段を用いて実行されることを特徴とする、請求項４に記載の方法。
【請求項６】
前記ソフトウェアコードが、ハードウェアに依存するソフトウェアコードと、ハードウェアに依存しないソフトウェアコードとに分けて、前記ハードウェアに依存しないソフトウェアのみが、車両における駆動シーケンスを制御するためのソフトウェア機能に使用されることを特徴とする、請求項１又は請求項４に記載の方法。
【請求項７】
検証の際にさらに、前記標準制御ユニットにおけるソフトウェアコードのコード・カバレッジを定めるために、前記ソフトウェアコード又は前記ソフトウェア機能の中において動作されるパスが検出されることを特徴とする、請求項１に記載の方法。
【請求項８】
ソフトウェア機能および制御ユニットをシミュレートするためのシミュレーションモデルを利用し、前記制御ユニットの前記ソフトウェア機能を検証するシステムであって、互いに通信接続されているエクスペリメンタル制御ユニットおよび標準制御ユニットを有するシステムにおいて、
エクスペリメンタル制御ユニット及び標準制御ユニットのために、同一のシミュレーションモデルから、前記ソフトウェア機能を実現するためのソフトウェアコードを自動的に生成する第１手段と、
２つの前記制御ユニットのソフトウェア機能を検証するために、各制御ユニットにお互いに同一の入力値が入力され、２つの前記制御ユニットから、前記入力値に応じて出力される出力値を各々同期で検出する第２手段と、
前記エクスペリメンタル制御ユニットに含まれ、２つの前記制御ユニットの前記出力値の比較によって、前記ソフトウェア機能を検証する第３手段と、
前記エクスペリメンタル制御ユニットにおける前記ソフトウェアコードのコード・カバレッジを定めるために、前記ソフトウェアコード又は前記ソフトウェア機能の中において動作するパスを検出する第４手段とを有し、
前記エクスペリメンタル制御ユニットは、前記ソフトウェア機能の動作へのアクセスが可能なことを特徴とする、制御ユニットのソフトウェア機能を検証するシステム。
【請求項９】
プログラムコードから構成されるコンピュータプログラムであって、前記コンピュータプログラムによって、コンピュータまたはコンピュータシステム上で、特に制御ユニットまたは請求項８に基づくシステム上で前記プログラムコードを実行する際に、請求項１〜請求項７のいずれかに記載の方法が自動的に実施される、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，独立請求項に記載の制御ユニットのためのソフトウェア機能を検証する方法及びシステムに関する。本発明は，さらに，請求項１０に記載のソフトウェア検証方法を実施するためのプログラムコードエレメントからなるコンピュータプログラムに関する。
【背景技術】
【０００２】
制御装置機能あるいは個々の車両制御装置又は制御ユニット（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔｓ  ＥＣＵ）の複雑さの増大，そして，車両複合体内の制御ユニットと制御装置機能のネットワーク化と相互作用の増加並びに品質及び安全要請の増大が，ソフトウェア機能の検証を困難かつ複雑にしている。これは，例えば工作機械製作，自動化などのような他の技術的分野における制御ユニットとモジュールのネットワーク化についても該当する。今日においては，個別システムのためのソフトウェア承認は，複合エレクトロニクス内の系統的なテストによって実行される。まさに車両領域内では，これは通常車両内でのみ可能であるため，コストがかかる。その場合に，ソフトウェアテストの際にできるだけ高いカバレッジを得るために，定められた環境条件の元で決定された走行状況カタログが運用される。コストの理由からシリーズ制御装置においては極めて制限されたメモリと実施時間のリソースしか提供されないので，確立されたテストテクノロジーを，例えばソフトウェア承認の際のコードカバレッジ（Ｃｏｄｅ  Ｃｏｖｅｒａｇｅ）−分析のために使用することは，通常，不可能であり，あるいはコストの増大と結びついている。
【０００３】
このようなことは，コードカバレッジを検出するために付加的なコードカバレッジメモリが必要であるという限りにおいて，ＤＥ１９９５９２４７Ａ１に開示されている。即ち，上記公報における発明は，車両内のプロセスを制御するための開ループ制御あるいは閉ループ制御制御装置において使用するためのマイクロコンピュータを示している。車両走行中もマイクロコンピュータの開ループ制御あるいは閉ループ制御プログラムのコードカバレッジを定めることを可能とするために，マイクロコンピュータはプログラムメモリとデータメモリに対して付加的かつ並列にコードカバレッジメモリを有しており，それがアドレスバスとデータバスを介してマイクロコンピュータに接続されていることが，提案される。その場合に，コードカバレッジメモリ内には，車両走行の間に書込みあるいは読取りアクセスの範囲内でマイクロコンピュータによって，プログラムメモリから制御プログラムを実施する間にプログラムメモリあるいはデータメモリのどのアドレスがアドレスされるかについてのデータを格納することができる。その場合に，従来技術に基づくプログラムのための可能な検査及びテスト方法として，コードカバレッジを定めるための，いわゆるコードカバレッジ方法が，いわゆるシステム実行アナライザによって実行される。その場合に，外部のアドレスバス内に存在するマイクロプロセッサの全てのアドレスは，メモリ一覧における識別をもたらす。従って，テストの最後に特徴付けられていないアドレス領域は，プログラムの実施の範囲内ではアドレスされておらず，従ってそれに応じたプログラム部分は通過されていない。かかるテストギャップの分析によって，例えばテストされない機能と機能要請のエラーのある変換が認識されて，除去される。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら，標準制御ユニットの場合には，通常定められているように，付加的なコードカバレッジメモリとそれに応じた計算時間が提供されない場合には，ＤＥ１９９５９２４７Ａ１に示す方法は実施できない。その場合には，制御装置内部の変量測定の他に，制御装置ソフトウェアあるいは対応するソフトウェア機能へのアクセスは不可能であって，その場合に，ソフトウェア機能はブラックボックスとしてしかテストすることができない。この状況は，同時にシステムの高い実時間性と信頼性が必要とされる場合には，目標相克をもたらす。
【０００５】
近い将来において，例えばＸ−バイ−ワイヤ−システムにおけるように，制御装置ソフトウェアは安全上重要な走行機能も制御しかつ監視するので，埋込みコントロールシステムにおけるソフトウェア開発と検証のための品質要請が増大する。
【０００６】
本発明の目的は，正確に定められた，一貫した機能開発プロセスを用いて，ソフトウェア機能あるいはソフトウェアコードを検証する方法を提供することであって，このことにより，従来技術から得られる状況を最適化するために，ソフトウェアの品質をさらに向上させることができる。そのために，方法の他に，検証するシステムとそれに対応するコンピュータプログラムも，本発明の対象となる。
【課題を解決するための手段】
【０００７】
そのために，本発明は，ソフトウェア機能および制御ユニットをシミュレートするためのシミュレーションモデルを利用し、前記制御ユニットの前記ソフトウェア機能を検証する方法であって、エクスペリメンタル制御ユニット及び標準制御ユニットのために同一のシミュレーションモデルが利用され、前記シミュレーションモデルから、前記ソフトウェア機能を実現するためのソフトウェアコードが自動的に生成され、２つの前記制御ユニットのソフトウェア機能のために、同一の入力値が入力され、２つの前記制御ユニットにおいて、前記入力値によって出力される出力値が各々同期で検出され、２つの前記制御ユニットの前記出力値の比較によって、前記ソフトウェア機能が検証され、さらに、前記エクスペリメンタル制御ユニットにおける前記ソフトウェアコードのコード・カバレッジを定めるために、前記ソフトウェアコード又は前記ソフトウェア機能の中において動作するパスが検出され、前記エクスペリメンタル制御ユニットは、前記ソフトウェア機能の動作（Verhalten）へのアクセスを可能にすることによってソフトウェア機能が検証される。
【０００８】
従って，エクスペリメンタル制御ユニット（即ち，エクスペリメンタルターゲット）のため，及び標準制御ユニット（即ち，ＥＣＵターゲット）のために，統一的なシミュレーションモデルが基礎とされる。これに基づいて，その後，上記のように，シミュレーションモデル，例えばＡＳＣＥＴ−ＳＤ内でモデリングされた機能の，エクスペリメンタルターゲット上でのいわゆるターゲット−アイデンティカル−プロトタイピング並びに制御装置入力値による機能の刺激が行われる。他方で，同様に自動的にシミュレーションモデルから，ターゲット−コード生成を用いて，標準制御ユニット，即ちＥＣＵターゲットのために同一のモデルからソフトウェア機能のための変換が行われる。その場合に，検証は，エクスペリメンタルターゲットとＥＣＵターゲット上で並列の機能テストによって行われる。
【０００９】
その場合に，好ましくは，標準制御ユニット，即ちＥＣＵターゲットの出力値及び／又は出力値をもたらす経過値と，エクスペリメンタルターゲット又はエクスペリメンタル制御ユニットのそれらの検出と比較は，エクスペリメンタル制御ユニットによって自動的に実施される。
【００１０】
その場合に，好ましくは，各々エクスペリメンタル制御ユニットと標準制御ユニットについて，ソフトウェア機能のためのソフトウェアコードは，異なる生成手段によって生成され，従って，特に同一のプロセッサのためあるいは異なるプロセッサのために，異なるコンパイラによって変換される。
【００１１】
好ましい実施形態においては，ソフトウェア機能を検証する際に付加的に，エクスペリメンタル制御ユニット，エクスペリメンタルターゲット上あるいは標準制御ユニット上でソフトウェアコードカバレッジを定めるために，コードカバレッジ，即ちソフトウェアコード内及び／又はソフトウェア機能内で通過するパスが検出され，それはＥＣＵターゲットにおいては，ハードウェアに依存するソフトウェア又はプラットフォームソフトウェアが含まれている，という利点を有している。
【００１２】
その場合に，好ましい実施形態においては，ソフトウェア機能は，車両における駆動シーケンスを制御するために用いられ，かつそれに応じて方法，システム及び対応するコンピュータプログラムによって検証される。
【００１３】
効果的かつ安価な実施形態においては，ソフトウェア機能の全検証は，実際の車両の使用なしで，車両及び／又は車両コンポーネント及び／又は車両機能をシミュレートするシミュレーション手段，例えばＬａｂＣａｒによって実施される。
【００１４】
好ましくは，ソフトウェア機能のソフトウェアコードは，ハードウェアに依存するソフトウェアコードとハードウェアに依存しないソフトウェアコードに分割される。その場合にハードウェアに依存する部分は，例えば駆動システム及び，種々の選択可能なハードウェアに依存しないソフトウェアコード部分について，これらハードウェアに依存するソフトウェアコード部分へ結合するための，一般的な標準化されたインタフェースを定義する，いわゆるハードウェアアブストラクションレイヤを含んでおり，その場合にハードウェアに依存しないソフトウェアコード部分は，車両における駆動シーケンスを制御するためのソフトウェア機能を有している。
【００１５】
即ち，さらに，ソフトウェア検証の他に，多段の機能開発プロセスが生じ，その機能開発プロセスによって各段階においてソフトウェア品質を向上させ，かつ開発リスクを最小限に抑えることができ，それがコストを節約するための高い潜在可能性をもたらす。
【発明の効果】
【００１６】
好ましい実施形態においては，ソフトウェア機能を検証する際に付加的に，エクスペリメンタル制御ユニット，エクスペリメンタルターゲット上あるいは標準制御ユニット上でソフトウェアコードカバレッジを定めるために，コードカバレッジ，即ちソフトウェアコード内及び／又はソフトウェア機能内で通過するパスが検出され，それはＥＣＵターゲットにおいては，ハードウェアに依存するソフトウェア又はプラットフォームソフトウェアが含まれている，という利点を有している。
【００１７】
他の利点と好ましい形態は，明細書と請求項の特徴から明らかにされる。
【発明を実施するための最良の形態】
【００１８】
以下，図面に示す図を用いて，本発明を詳細に説明する。
【００１９】
そのために図１は，標準制御ユニット１００，いわゆるＥＣＵターゲットとエクスペリメンタル制御ユニット１０１，いわゆるエクスペリメンタルターゲットを示している。両制御ユニット１００と１０１は，通信接続１０３を介して接続されている。各々使用場合に応じて，この通信接続は１方向，双方向，シリアル又はパラレルなどとすることができる。さらに，エクスペリメンタルターゲット１０１には，視覚化及び／又は評価手段１０２が接続されており，それは以下ではＧＵＩ又はＧｒａｆｆｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅとも称される。同様に，パラレル又はシリアルかつ１方向又は双方向である接続自体は，ここでは符号１０４で示されている。この視覚化手段１０２は，すでに説明したように，評価能力，即ち計算ユニット及び／又はメモリユニットを有することができ，その場合にこのＧＵＩは，同様にエクスペリメンタルターゲット１０１内に統合することができる。
【００２０】
ブロック１０５と１０６によって，ＥＣＵ−ソフトウェアアーキテクチャとエクスペリメンタルターゲットのソフトウェアアーキテクチャが象徴的に示されている。標準制御ユニットのソフトウェアあるいはソフトウェア機能のアーキテクチャ，従ってＥＣＵアーソフトウェアは，例えばコンポーネント形成とバリアント形成，再使用とポート可能性並びに開発ツールのための標準制御ユニットのインタフェースの支援のために，中心的な重要性を有している。従って，開発プロセスとソフトウェアアーキテクチャは，共通に考えられなければならない。その場合に，層アーキテクチャが効果的であって，その層アーキテクチャにおいては本来の制御装置機能性，即ちアプリケーションソフトウェアのようなハードウェアに依存しないソフトウェア機能は，プラットフォームソフトウェアのハードウェアに依存するソフトウェア層から分離されている。このことにより，第１に，プラットフォームソフトウェアをプロジェクト全体を覆うように再利用することができ，第２には好ましい方法で制御ユニットへのアクセスのためのインタフェースが簡略化される。従って，標準化された方法あるいはこの標準インタフェースに合わせられた工具を，開発，検証の間，そして製造とサービスにおいても，例えばラピッドプロトタイピング，デバッギング，測定及び校正のために使用することが可能である。さらに，特に車両における駆動シーケンスを制御するために，アプリケーションソフトウェアの機能あるいはソフトウェア機能をハードウェアに関係なく特殊化することができるので，様々な制御装置プラットフォームへポートすることができる。
【００２１】
その場合に，ブロック１０５内には，データブロック１０７が含まれており，そのデータブロックはデータの全体，即ち入力値と出力値，測定データ，内部の経過値などを有している。これらの機能のデータは，ソフトウェア機能の範囲内でブロック１０７とブロック１０９内でほぼ等しい。しかしながら，ソフトウェアブロック１０５内では，他のソフトウェアコードあるいは他のソフトウェア機能はもはや直接にはアクセスできないので，ブロック１０８はブラックボックス行動を示し，かつＥＣＵターゲット上では大体において，データブロック１０７に関して，測定と校正のみが可能である。
【００２２】
その他，後の検証のために，エクスペリメンタルターゲット１０１が使用され，そのエクスペリメンタルターゲットにおいては，ハードウェアに依存しないソフトウェアの範囲内で，データブロック１０９に加えてデータブロック１１０内の機能あるいはソフトウェア機能の行動へのアクセスも可能である。従って，エクスペリメンタルターゲットにおいては，ブロック１１１内でだけ，従ってプラットフォームソフトウェアに関して，ブラックボックス行動が示されている。その中には，駆動システム，例えばＯＳＥＫ−ＯＳ又はＥＲＣＯＳ及びオートモーティブサービスとアクセスされるアブストラクションレイヤ，ハードウェアアブストラクションレイヤＨＡＬが埋め込まれている。これらアブストラクション層によって，その上に存在するソフトウェア機能の行動とデータを記述しあるいは有しているソフトウェア層，特にアプリケーションソフトウェアの独立性が可能とされる。
【００２３】
以下の図２と３においても説明されるように，ソフトウェア機能あるいはソフトウェアコードの検証を可能にするために，ソフトウェア構造は，標準制御ユニット（即ちＥＣＵターゲット）とエクスペリメンタルターゲット（即ちクスペリメンタル制御ユニット）との間でほぼ同一である。さらに後に説明するために，検証の範囲内で時間同期性を示すことも重要であって，その場合に，基礎となる１つの駆動システムあるいは各々基礎となる複数の駆動システムは同一の時間行動を有しており，その場合に好ましくは同じ又は同様な駆動システム，特にＯＳＥＫのような標準駆動システムとＡＳＡＭのような他の基準が考慮され，かつ使用される。
【００２４】
ソフトウェア機能のデータと行動へのアクセスが可能であることによって，ブロック１０９と１１０においては標準制御ユニットとは異なり，これに関してラピッドプロトタイピングが可能であり，あるいは同じシミュレーションモデルＡＳＣＥＴ−ＳＤを使用することによって，エクスペリメンタルターゲット上での，ＡＳＣＥＴ−ＳＤ内でモデリングされた機能のターゲット−アイデンティカル−プロトタイピングと，標準制御ユニットの入力値による機能のシミュレーションが可能である。
【００２５】
そのために，シミュレーションモデルあるいは付属の開発ツール，例えばＡＳＣＥＴ−ＳＤは，ハードウェアに依存しないソフトウェア，特にアプリケーションソフトウェアの機能のグラフィックの，物理的な，コンポーネントベースのモデリング，エクスペリメンタルターゲットによるシミュレーションとラピッドプロトタイピング，従って標準制御ユニット，目標システム上に実装するためのターゲット−アイデンティカル−プロトタイピングと自動化されたターゲットコード生成を支援する。付加的に，シミュレーションモデルあるいは対応する開発ツールによって，制御ユニットの全ての測定及び調節変量のための，標準化フォーマット，例えばＡＳＡＭ−ＭＣＤ２の，完全な記述データファイルが生成され，それによって標準化された測定及び校正ツールインタフェースが可能である。
【００２６】
図２には，ブロック２００におけるシミュレーションモデルの形成から始まって，方法シーケンスが示されている。その場合に，特にハードウェアに依存しないソフトウェア機能のためのシミュレーションモデル，特にＡＳＣＥＴ−ＳＤは，標準制御ユニット，即ちＥＣＵターゲットとエクスペリメンタル制御ユニットにとって同様に「信号ソース」，即ちベースである。ブロック２０１において，ブロック２００で形成された，標準制御ユニットのためのシミュレーションモデルから，ソフトウェア機能のためのＥＣＵターゲットに関するターゲットコード生成が行われる。
【００２７】
ブロック２０２においては，同様に，エクスペリメンタルターゲット上で，シミュレーションモデルにおいてモデリングされた機能のターゲット−アイデンティカル−プロトタイピングが自動的に行われる。その場合に，ターゲット−アイデンティカル−プロトタイピングは，全算術的及び時間的行動が特殊化され，かつシミュレートされること（エクスペリメンタルターゲット上で）を意味し，かつ標準制御ユニットのシステム行動とバーチャルに正確に一致する。
【００２８】
その後，ブロック２０３において，ＥＣＵターゲットのために，特にＣでコンパイルすることによって，ソフトウェアコードの生成が行われる。その場合に，ソフトウェアコードは，例えばＣ又はＣ＋＋あるいはジャバなどのような任意のプログラム言語で存在するが，本発明の対象に関して制限的に理解すべきではない。同様に，ブロック２０４において，エクスペリメンタル制御ユニットのために，いわゆるソフトウェアコードへの変換が行われる。
【００２９】
そして，ブロック２０８と２０９において，本来のソフトウェア検証が行われる。そのために，ブロック２０８においては，標準制御ユニット２０５とエクスペリメンタル制御ユニット２０６上で時間的に並列の機能テストが行われ，その場合に接続２０７を介して示されるように，データ交換を行うことができる。その場合に，標準制御ユニットとエクスペリメンタル制御ユニットについて，テストケースは同一である。即ち，特に，例えばエクスペリメンタルターゲットの浮動小数点演算（例えば固定小数点演算も可能）と，例えば標準制御ユニット上の固定小数点演算において，浮動小数点演算と固定小数点演算との間で比較が可能である。従って，実装に関して不十分であることの表示を可能にして，必要に応じて，特に自動的に補正するために，数量化とオーバーフロー効果が標準制御ユニット，従ってＥＣＵターゲットに及ぼす影響を調査することが，早期に可能である。
【００３０】
その後，ブロック２０９において，好ましくはエクスペリメンタル制御ユニット上で，ソフトウェア機能に関する出力値の測定と比較が行われる。その場合に，標準制御ユニットとエクスペリメンタル制御ユニット上の測定あるいは値の検出とその比較は，同時かつ時間同期で行われる。即ち，要約すると，ターゲット−アイデンティカル−プロトタイピングとターゲット−コード−生成によるソフトウェア検証が可能である。ターゲット−アイデンティカル−プロトタイピングとターゲット−コード生成のために同一のコードジェネレータオプションを提供することができ，このことにより，その後２つのターゲットあるいは制御ユニット上で固定小数点演算が使用される。既に示したように，好ましくはエクスペリメンタルターゲット上では，標準制御ユニットにおけるのと同じ駆動システム，特に，例えばＥＲＣＯＳのような，ＯＳＥＫ駆動システム及び同一のサービスルーチンが使用される。
【００３１】
選択的かつ付加的に，ブロック２１０によって，コードカバレッジ分析，いわゆるコードカバレッジ分析が，接続２１２を介してエクスペリメンタルターゲット上で，あるいは選択的に接続２１３を介して標準制御ユニット上で可能である。そのために，特にシミュレーションモデルによって自動的に生成されるソフトウェアコード，特にＣ−コードが計測される。そのために，高いカバレッジ（パス及び／又はブランチカバレッジ）を得るという目的を達成するために，コード計測あるいはカバレッジ分析のための商用のカバレッジ工具をシミュレーションモデル内に埋め込むことができる。
【００３２】
即ち，例えば，ハードウェアに依存しないソフトウェア機能のための１００％のターゲット−アイデンティカル−プロトタイピングを前提にして，１００％のブランチカバレッジから，ＥＣＵターゲット上の１００％のブランチカバレッジを推定することができる。
【００３３】
代替的に，コードカバレッジ分析は，接続２１３を介して示すように，ＥＣＵターゲット上で実施することもでき，この場合においては，コードカバレッジ分析が直接標準制御ユニットのソフトウェアコード上で実施され，従ってハードウェアに依存するソフトウェア成分，プラットフォームソフトウェアもカバレッジされると，効果的であろう。
【００３３】
同一のシミュレーションモデル，例えばＡＳＣＥＤ−ＳＤから，後の検証のために，２つのパスについて，ターゲットコード生成を有するＥＣＵターゲットのためと，ターゲット−アイデンティカル−プロトタイピングを有するエクスペリメンタルターゲットのために，ソフトウェアコードとして，特にＣコードが生成される。エクスペリメンタル制御ユニット上の浮動小数点演算と標準制御ユニット上の固定小数点演算との間で比較するために，同一のテスト刺激，従って特に同一の入力値及び同時かつ同期化された測定値検出，即ち２つの制御ユニット上で出力値の検出が実施される。
【００３４】
その場合に，好ましくは，測定及びシミュレーション環境はエクスペリメンタル制御ユニット内へ統合されており，ラボ内，試験台，かつ車両内で同様に使用することができる。好ましくは測定量比較，従って出力値の比較は，エクスペリメンタル制御ユニット上で計算される。さらに，コンパイラとコードジェネレータセットを含む，使用されるプラットフォームの多様性によって，特に標準制御ユニットのためのコードジェネレータ最適化の調査と検査，コードジェネレータ，コンパイラ及びプロセッサの問題あるいはエラーの識別並びに標準制御ユニットのタイミング問題の認識が可能である。これについて，図３のデータ及びコントロールの流れを用いて再度詳細に説明する。
【００３５】
図３において，ここでもブロック１０１によってエクスペリメンタル制御ユニットが示され，ブロック１００によって標準制御ユニットが示されている。標準制御ユニット１００は，接続３０３を介して固有の入力値を得て，接続３０２を介してソフトウェア機能に応じて出力値又は測定量を出力する。制御区間である，ブロック３００は，一方では，既に説明したように，車両とすることができる。他方では，例えばＬａｂＣａｒとしてのラボ内での種々の車両機能又は車両全体の表示のような，シミュレーション環境とすることができ，このことにより検査シーケンス全体をこの種のＬａｂＣａｒと共にラボ内へ移動させて，自動化することができる。その場合に，実際の標準制御ユニットの入力値は，例えば双方向の接続１０３を介して，あるいは代替的に接続３０４によって，エクスペリメンタル制御ユニットへ伝達することができる。同様に，標準制御ユニットの測定量又は出力値は，比較がエクスペリメンタル制御ユニット上で実施される限りにおいて，比較のために接続１０３を介してこのエクスペリメンタル制御ユニットへ伝達することができる。導線３０１あるいは象徴的な信号の流れは，例えばＥＣＵターゲットからエクスペリメンタルターゲットへのトリガーを示している。同様に標準制御ユニットの出力値は，パス３０６を介して視覚化及び（場合によっては）評価システム１０２ＧＵＩへ伝達され，同システムは接続１０４を介して，特に双方向で，エクスペリメンタル制御ユニットと接続されている。ここでも，原理的にＧＵＩをエクスペリメンタル制御ユニット内へ統合することが可能である。
【００３６】
同様に，選択的に，エクスペリメンタルターゲットの出力値又は比較結果も，パス３０５を介して他の評価手段又は表示手段へ伝達することができる。特にエクスペリメンタル制御ユニット内で，あるいは選択的に視覚化又は評価ユニット，例えば１０２内で，あるいはパス３０５との組合わせにおいて，エクスペリメンタル制御ユニットと標準制御ユニットの出力値の比較が行われる。出力値が等しい場合には，独立したソフトウェア機能に関するターゲット−アイデンティカル−プロトタイピングが達成されている。出力値が異なる場合には，コードジェネレータ，コンパイラ，プロセッサ，サービスルーチン又は標準制御ユニットのタイミング，ＥＣＵタイミングによる問題が存在しており，エラーとして表示し，かつそれに応じたエラーリアクションを付随させることができる。このエラー解明は，別々のパスが使用される限りにおいて，保証されている。即ち，２台のプロセッサ−エクスペリメンタルターゲット内の１台とＥＣＵユニット内の１台−が使用されることによってだけでなく，２つのパス内のエラーの繰返しを阻止して，エラーあるいは問題を発見するために，これらが選択的に同タイプでなく，異なるコンパイラである場合にも可能である。
【００３７】
以上説明してきた方法は，図示されている検証システム上でプログラムコードエレメントを有するコンピュータプログラムの範囲内で自動化されて実行される。その場合に，個々のプログラムコードエレメントは，請求項に記載の本発明に基づく処理ステップを得るために，処理される。従って，コンピュータ，計算機あるいは検証システム上で行われる場合に実行され，あるいは実施されるプログラムコードエレメントは，本発明に基づくシステムに記載の処理ステップを有する。その場合に，プログラムコードエレメントは，実施前あるいは実施するために，任意のデータ担体（システム内部又は外部），従ってＲＡＭ，ＲＯＭ，ＥＰＲＯＭ，ＣＤ−ＲＯＭ，ディスケットなどの上に格納されている。
【図面の簡単な説明】
【００３８】
【図１】標準制御ユニット，従ってＥＣＵターゲットとエクスペリメンタルターゲットを各々のソフトウェアアーキテクチャと共に示している。
【図２】ソフトウェア検証方法の実行を説明するフローチャートである。
【図３】本発明に基づくソフトウェア検証方法に関するデータとコントロールの流れを再度示している。
【図１】
0004236104.tif 000002
【図２】
0004236104.tif 000003
【図３】
0004236104.tif 000004