JP2005504377A - 制御ユニットのためのソフトウェア検証方法及び検証システム - Google Patents

Abstract

ソフトウェア機能をシミュレートするためのシミュレーションモデルと制御ユニットの使用を有する，制御ユニットのためのソフトウェア機能を検証する方法とシステムであって，その場合に同一のシミュレーションモデルから，第１に，第１のエクスペリメンタル制御ユニットのために，そして第２に，第２のシリーズ制御ユニットのために，ソフトウェア機能のためのソフトウェアコードが自動的に生成され，その場合に２つの制御装置上でソフトウェアの機能のために同一の入力量が使用され，それから得られる，２つの制御ユニットの出力量が時間同期で，従って同時に検出され，その場合に２つの制御ユニットの出力量の比較によって，ソフトウェア機能が検証される。

Description

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

Claims (10)

1. ソフトウェア機能をシミュレートするためのシミュレーションモデルと制御ユニットの使用を有する制御ユニットのためのソフトウェア機能を検証する方法において，
   同一のシミュレーションモデルから，第１に，第１のエクスペリメンタル制御ユニットのために，そして第２に，第２のシリーズ制御ユニットのために，ソフトウェア機能のためのソフトウェアコードが自動的に生成され，
   その場合に，前記２つの制御装置上でソフトウェア機能のために同一の入力量が使用され，それから得られる，２つの制御ユニットの出力量が時間同期で検出され，
   その場合に，前記２つの制御ユニットの出力量の比較によってソフトウェア機能が検証される，
   ことを特徴とする制御ユニットのためのソフトウェア機能を検証する方法。
2. 前記出力量及び／又は前記出力量をもたらす中間量の検出と比較は，前記第１のエクスペリメンタル制御ユニットによって自動的に実行される，ことを特徴とする請求項１に記載の方法。
3. 前記各々のエクスペリメンタル制御ユニット又はシリーズ制御ユニットのためのソフトウェア機能のためのソフトウェアコードは，異なる生成手段によって生成される，ことを特徴とする請求項１に記載の方法。
4. 前記検証の際に，付加的に，ソフトウェアコードカバレッジを定めるために，前記ソフトウェアコード内及び／又は前記ソフトウェア機能内で通過するパスが，前記エクスペリメンタル制御ユニット上で検出される，ことを特徴とする請求項１に記載の方法。
5. 前記ソフトウェア機能は，車両における駆動シーケンスを制御するために使用される，ことを特徴とする請求項１に記載の方法。
6. 前記ソフトウェア機能の全ての検証は，実際の車両を使用することなく，車両をシミュレートするシミュレーションモデルによって実行される，ことを特徴とする請求項５に記載の方法。
7. 前記ソフトウェアコードは，ハードウェアに依存するソフトウェアコードとハードウェアに依存しないソフトウェアコードに分割されており，その場合に前記ハードウェアに依存しないソフトウェアコードのみが車両における駆動シーケンスを制御するためのソフトウェア機能に使用される，ことを特徴とする請求項１及び５に記載の方法。
8. 前記検証の際に，付加的に，ソフトウェアコードカバレッジを定めるために，前記ソフトウェアコード内及び／又は前記ソフトウェア機能内で通過するパスが，前記シリーズ制御ユニット上で検出される，ことを特徴とする請求項１に記載の方法。
9. ソフトウェア機能をシミュレートするためのシミュレーションモデル及び制御ユニットの使用と，互いに通信接続されている第１のエクスペリメンタル制御ユニット及び第２のシリーズ制御ユニットとを有する制御ユニットのためのソフトウェア機能を検証するシステムにおいて，
   同一のシミュレーションモデルから，第１に，第１のエクスペリメンタル制御ユニットのために，そして第２に，第２のシリーズ制御ユニットのために，ソフトウェア機能のためのソフトウェアコードを自動的に生成する第１の手段が設けられており，
   その場合に，前記双方の制御装置上でソフトウェア機能のために同一の制御量が使用され，かつそれから得られた，２つの制御ユニットの出力量を時間同期で検出する，第２の手段が設けられており，その場合に，２つの制御ユニットの出力量の比較によってソフトウェア機能を検証する，第３の手段が，特にエクスペリメンタル制御ユニット上に，設けられていることを特徴とする，制御ユニットのためのソフトウェア機能を検証するシステム。
10. プログラムコードエレメントからなるコンピュータプログラムであって，前記コンピュータプログラムによって，プログラムコードエレメントがコンピュータ上，あるいはコンピュータシステム上，特に制御ユニット上又は請求項９に記載のシステム上で実行される場合に，請求項１から８のいずれか１項に記載の方法が自動的に実施される，コンピュータプログラム。