ソフトウェアベースの電子システムの安全性と信頼性を検査する方法
本発明は，システムの要求される機能を検査するための信頼性機能を用いて，そのために必要とされる，システムのハードウェアコンポーネントに基づいて，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法に関する。その場合に，システムの要求される機能の少なくとも１つのものの信頼性を計算するための信頼性機能と，システムの安全性機能の少なくとも１つのものの信頼性を計算するための他の信頼性機能を定めることが提案され，その場合にこれら信頼性を定めるために，システムのソフトウェアコンポーネントが，これらソフトウェアコンポーネントがそれに分配されている，ハードウェアコンポーネントを用いて一緒に考慮される。それによって，ソフトウェアとハードウェアによって実現される，この種のシステムとこのシステムの機能の様々な監視コンセプトを早期に評価することが可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，システムの要求される機能を検査するための信頼性機能を用いて，そのために必要なシステムのハードウェアコンポーネントに基づいて，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法に関する。さらに，本発明は，この方法の使用および方法を実装するためのコンピュータプログラムとコンピュータプログラム製品に関する。
【背景技術】
【０００２】
車両機能に対する信頼性要請と安全性要請は，技術的，法律的および経済的な周辺条件を考慮して，顧客要望から得られる。車両機能に対する信頼性要請は，たとえば短い修理時間または長いサービスインターバルの形式で与えられる。それに対して安全性要請は，車両の部品の故障または障害の場合における車両の安全な行動を定める。車両機能に課せられる信頼性要請と安全性要請は，最初から，実現と立証義務に対する要請も定める。安全性と信頼性を向上させるための強力な手段の１つは，冗長性である。車両機能または車両機能の一部がソフトウェアによって実現されることが増えているので，信頼性分析と安全性分析を行う体系的な方法が，電子制御装置のためのソフトウェア開発に，たとえば監視概念，診断概念および安全性概念の実現に，ますます大きくなる影響を有している。
【０００３】
複雑な電子システムのためには，信頼性と安全性を確保するための行動が早期に計画されて，プロジェクトプラン全体に統合されなけれならない。
【０００４】
「システム」という概念は，本出願の枠内において，それぞれ文脈に従って以下のものと考えられる：所定の機能を得るために必要な最小のシステム部分，システム全体へ至るまでの，協働するシステム部分あるいは，さらに広く捉えて，操作者またはシステム全体に作用する他の要素を含めたシステム全体を指す。本発明を説明するために，本出願の枠内では，大体において，車両制御の構成部分であるシステムを参照する。この参照は，純粋に説明的な特性を有しており，本発明は決してこの種のシステムに限定されない。本発明は，むしろ，ソフトウェアベースの電子システムに関して，普遍的に妥当性を有している。
【０００５】
この種のシステムの安全性と信頼性を検査するために，信頼性機能の使用が知られており，その信頼性機能を用いてシステムの要求される機能についての信頼性の程度を示すことができる。この種の信頼性機能を定めるために，要求されるシステム機能に必要な，システムのハードウェアコンポーネントの信頼性から始めることができる。信頼性分析は，たとえば，故障率分析および作用分析（ＦＭＩＡ）あるいはエラーツリー分析（ＦＴＡ）のような，故障率分析および故障種類分析を有する。以下においては，信頼性分析を，故障率分析を用いて，考察されるシステムのための信頼性ブロック図を用いて信頼性機能を計算しながら，詳細に説明する。
【０００６】
考察ユニットの故障率の系統的調査は，計算による考察ユニットのための信頼性の予測を可能にする。弱い箇所を早期に認識して，代替策を評価し，信頼性，安全性および可用性の間の関係を量的に検出できるようにするために，この予測は重要である。さらに，たとえばシステムコンポーネントに対して信頼性要請を課すことができるようにするために，この種の調査は必要である。
【０００７】
無視と簡略化により，および使用される入力データの不確実性により，計算され，予測された信頼性は，真の信頼性のためのおおよその数値でしかなく，真の信頼性は信頼性検査とフィールド観察によってしか求められない。しかし，分析段階における比較調査の枠内では，絶対的な精度は役割を果たさないので，特に実現選択肢を評価する際に，予測される信頼性の計算は，有用である。
【０００８】
以下の部分において，考察単位は，常に車両の技術システムまたはシステムコンポーネントである。一般的な場合においては考察単位は，もっと広く捉えることができ，たとえば車両の運転者も含めることができる。
【０００９】
故障率分析（これについては，アレッサンドロ・ビロリーニの「機器とシステムの信頼性（Alessandro Birolini:Zuverlaessigkeit von Geraete und Systemen，
Springere Verlag, 1997）を参照）は，以下のステップを区別する：
・技術的システムの限界とコンポーネント，要求される機能および要求プログラムを定義
・信頼性ブロック図（英語ではReliability Block Diagram）を作成
・各コンポーネントについて負荷条件を決定
・各コンポーネントについて信頼性機能または故障率を決定
・システムのための信頼性機能を算出
・弱い箇所を克服
【００１０】
故障率分析は，多段階の方法であって，システムレベルから種々のサブシステムレベルを介して技術的システムアーキテクチャのコンポーネントレベルへ至るまで「トップダウン」で実施することができる。故障率分析は，技術的システムアーキテクチャが変化した後に，繰り返されなければならない。
【００１１】
以下，故障率分析の第１のステップを，詳細に説明する。
【００１２】
信頼性の予測のために必要な，論理的考察のためには，システムとその機能および信頼性と安全性を改良するための具体的可能性の詳細な知識が前提とされる。システム理解には，システムのアーキテクチャとその作用方法の知識，すべてのシステムコンポーネントのための作業条件と負荷条件および，たとえば信号の流れおよびすべてのコンポーネントの入力および出力サイトの形式の，コンポーネント間の相互の相互作用が重視される。改良のための具体的可能性に属するのは，駆動中のコンポーネントの負荷，たとえば静的または動的な負荷，インターフェイスの負荷の制限と減少，もっと適したコンポーネントの使用，システムまたはコンポーネント設計の簡略化，重要なコンポーネントの前処理および冗長性の使用である。
【００１３】
要求される機能が，システムの課題を指定する。システム限界および要求される機能を決定することは，それによって故障も定義されるので，各信頼性分析の出発点を形成する。
【００１４】
付加的に，システムのすべてのコンポーネントについて環境条件が定義されなければならない。というのは，それによってコンポーネントの信頼性が影響を受けるからである。すなわち，たとえば，温度領域は，ハードウェアコンポーネントの故障率に大きい影響を有している。車両内では，たとえば，要求される温度領域，湿度，埃または腐食性の環境下での使用あるいは振動，ショックまたは，たとえば供給電圧の変動による負荷が，環境条件に属する。さらに，要求される機能と環境条件が時間に依存する場合には，要求プロフィールが決定されなければならない。車両内の法律的に定められた要求プロフィールの例は，排ガス規則の維持を立証するための走行サイクルである。この場合において，代表的な要求プロフィールにも言及される。
【００１５】
次に，故障率分析の第２のステップを詳細に説明する。
【００１６】
信頼性ブロック図は，システムのどのハードウェアコンポーネントが必要な機能を満たすために原則的に機能しなければならないか，およびどのハードウェアコンポーネントが，故障した場合に，冗長に存在しているために原則的に機能を損なわないか，という問いに解答を与える。信頼性ブロック図の形成は，技術的システムアーキテクチャのコンポーネントを考察することによって行われる。これらのコンポーネントは，信頼性ブロック図内で，機能を満たすために必要なコンポーネントは直列に接続され，冗長なコンポーネントは並列回路内で接続されるようにして，接続される。
【００１７】
図１は，いわゆるブレーキ−バイ−ワイヤ−システム１を概略的に示しており，その場合にブレーキペダル２，制御装置３および４つのブレーキユニット，すなわち左前のブレーキユニット４，左後ろのブレーキユニット５，右前のブレーキユニット６および右後ろのブレーキユニット７，が示されている。ブレーキ−バイ−ワイヤ−システム１の機能のために必要なハードウェアコンポーネントは，Ｋで示されている。
【００１８】
図１に示すような，仮想のブレーキ−バイ−ワイヤ−システム１のために，まずシステム限界が定められる。システムは，ブレーキペダルユニット（Ｋ１），制御装置（Ｋ２），車輪ブレーキユニット（Ｋ５，Ｋ７，Ｋ９，Ｋ１１）および電気的な接続（Ｋ３，Ｋ４，Ｋ６，Ｋ８，Ｋ１０）のコンポーネントからなる。
【００１９】
ブレーキ−バイ−ワイヤ−システムにおいては，ブレーキペダルと車輪ブレーキの間に油圧的な接続はなく，電気的な接続がある。運転者の指示によってブレーキがかかった場合に，ブレーキペダルユニットＫ１によって設定されて，制御装置Ｋ２内で処理される，運転者の指示によるブレーキに必要なエネルギは，「ワイヤによって」車輪ブレーキユニットＫ５，Ｋ７，Ｋ９およびＫ１１へ伝達される。その場合に，従来のブレーキシステムにおいては機械−油圧的に実施される，電気的および電子的コンポーネントＫ２，Ｋ３，Ｋ４，Ｋ６，Ｋ８およびＫ１０による，ペダルユニットと車輪ブレーキユニットとの間の「情報伝達およびエネルギ伝達」機能の引渡しが，付加的な安全リスクをもたらさず，安全利得をもたらすことが，保証されなければならない。従ってブレーキ指令の予測可能な伝達は，必然的な予測である。同様に，コンポーネントの障害と故障においても，安全が保証されなければならない。
【００２０】
「ブレーキ」の機能を考察する。そのためにシステムの信頼性全体が定められる。コンポーネントＫ１からＫ１１の故障率λ１からλ１１がわかっているものと仮定する。
【００２１】
この例は，さらに，極めて著しく簡略化される。信頼性分析の際の原理的な方法のみが，明らかにされる。従って，情報伝送のみを考察し，エネルギ供給とエネルギ伝達の視点および，前車軸と後車軸上の要求されるブレーキ力分配のような，走行動的な周辺条件は無視される。もちろん，これらは信頼性分析の場合にも考慮されなければならない。
【００２２】
「ブレーキ」機能を満たすために，この簡略化された視点においては，ブレーキペダルユニットＫ１，制御装置Ｋ２のコンポーネントおよびブレーキペダルユニットと制御装置Ｋ３間の接続が機能することが，必要不可欠である。
【００２３】
ホイールブレーキユニットは，制御装置とホイールブレーキユニットの間の接続において，冗長性を有する。車両のための十分な補助ブレーキ力が１つのホイールブレーキユニットのみによって得られる，という著しく簡略化された仮定の下で，たとえばコンポーネントＫ４とＫ５は必要不可欠であって，コンポーネントＫ６とＫ７，Ｋ８とＫ９並びにＫ１０とＫ１１は冗長に存在している。この種の配置を，４−１の冗長性と称する。
【００２４】
「ブレーキ」機能のための信頼性ブロック図は，図２のように示される。
【００２５】
すべてのコンポーネントＫｉについて負荷条件を決定し，かつ信頼性機能Ｒｉ（ｔ）を定めた後に，次の表３に示す，信頼性ブロック図のための基本的な規則を考慮して，システムの信頼性機能Ｒｓ（ｔ）を計算することができる。
【００２６】
従って図２の例について，システムの信頼性機能Ｒｓを計算することができる。Ｒ４＝Ｒ６＝Ｒ８＝Ｒ１０およびＲ５＝Ｒ７＝Ｒ９＝Ｒ１１と仮定して，Ｒｓについて次の式が成り立つ：
Ｒｓ＝Ｒ１Ｒ２Ｒ３［１−（１−Ｒ４Ｒ５）４］
【００２７】
この簡略化した例が示すように，機能のためのシステムの信頼性は，信頼性ブロック図内の冗長なコンポーネントにより，コンポーネントの信頼性に比較して増大する。それに対して，連続的に図示されているコンポーネントにおいては，システム信頼性はコンポーネント信頼性に比較して減少する。従って信頼性ブロック図内の連続的なコンポーネントのために，既にコンポーネントの高い信頼性を要求しなければならず，あるいはここでも冗長な構造を設ける，技術的システムアーキテクチャを計画しなければならない。
【００２８】
上記では，システムの信頼性機能の計算が，所定の要求されるシステム機能について実例として，著しく簡略化して示されているが，同様な方法で，システムの安全性に関する説明を行うことができるようにすることが望ましい。システムの安全性のためには，しばしば，考察の単位が要求される機能を満たしているか否かは，それによって支持し得ない高いリスクが生じない限り，重要ではない。本出願において考察されるような，ソフトウェアベースの電子システムは，主としてハードウェアコンポーネントとソフトウェアコンポーネントからなり，その場合にソフトウェアコンポーネントは大体において，システムのハードウェアコンポーネントの幾つかに分配することができる。この種のソフトウェアベースの電子システムの安全性も信頼性も，信頼のおけるように検査できるようにする，強い要請がある。
【発明の開示】
【００２９】
本発明によれば，システムが要求する機能の少なくとも１つのものの信頼性を計算するための信頼性機能と，システムの安全性機能の少なくとも１つのものの信頼性を計算するための信頼性機能とが定められ，その場合にこの信頼性機能を定める際に，システムのソフトウェアコンポーネントも一緒に考慮される。その場合にソフトウェアコンポーネントは，ハードウェアコンポーネント（このハードウェアコンポーネントにソフトウェアコンポーネントが分配されている）を用いて，一緒に考慮される。その場合にこの考慮は，１つまたは複数のハードウェアコンポーネント自体と，それぞれのソフトウェアにより（たとえば出力信号の出力によって）影響を受けるハードウェアの接続にも拡げることができる。それによって初めて，ソフトウェアベースの電子システムの安全性と信頼性に関する説明を行うことが可能となり，その場合にこの説明は，それぞれの接続を含めたハードウェアコンポーネントとソフトウェアコンポーネントからなるシステムに関するものであって，ハードウェアコンポーネントのみに限定されない。
【００３０】
ハードウェアコンポーネントとソフトウェアコンポーネントを有するシステムの安全性と信頼性は，信頼性機能を使用して検査され，その信頼性機能は，例えば冒頭で説明した，システムのための信頼性ブロック図を用いて定めることができる。後で説明するように，本発明によれば，信頼性機能を定める場合にシステムのソフトウェアコンポーネントが一緒に考慮される。これは，新しいシステム定義に匹敵する。というのは，これまで信頼性分析のためには，ハードウェアコンポーネントからなるシステムのみが考慮されており，ソフトウェアコンポーネントはもし考慮されるとしても，独自の別の分析を受けていたからである。
【００３１】
本発明によれば，一般に，ソフトウェアとハードウェアから実現される電子システムの特殊性と機能において，達成可能なシステム安全性およびシステム信頼性に関して，電子制御装置の様々な監視概念を早期に評価することが可能となる。結果は，特にネットワーク化された制御装置のマイクロコントローラへのソフトウェア機能の分配と，それに伴って分配された，ネットワーク化された制御装置のためのソフトウェアの開発に影響を与える。
【００３２】
全体としてシステムに関する説明を行うことができるようにするために，システムのすべての機能，従ってすべての要求されるシステム機能とシステムのすべての安全性機能を，該当する信頼性機能の規定によって検査することが適切である。
【００３３】
信頼性機能は，通常，たとえば０から１の，所定の範囲の値を有しており，その場合に以下においては普遍妥当性を制限することなしに，高い値（１）が高い信頼性を表し，低い値（０）は低い信頼性を表すと仮定する。本発明に基づく信頼性機能は，一方では，要求されるシステム機能の信頼性に関し，他方ではシステムの安全性機能の信頼性に関する。該当する信頼性機能を定めた後に，システム機能の信頼性ないし安全性機能に関する具体的な説明を得るために，選択したシステムアーキテクチャ（またはシステム構成）についてこれらの信頼性機能の具体的な値を計算することが，効果的である。
【００３４】
通常，選択されたシステムアーキテクチャの他に，同一の要求されるシステム機能をもたらす，他の構成も実現可能である。同じことが，要求される安全性機能についても当てはまる。従って適切なシステムアーキテクチャを選択するためには，種々のシステムアーキテクチャについて本発明により定められる信頼性機能が定められると，効果的である。その場合にシステムアーキテクチャは，以下のように変化させることができる：要求されるシステム機能および安全機能を実現するために必要なハードウェアコンポーネントの決定（ハードウェアコンポーネントの種類，これらのコンポーネントの配置と冗長性）；要求されるシステム機能と安全機能を実現するために必要なソフトウェアコンポーネントの決定および所定のハードウェアコンポーネントへのソフトウェアコンポーネントの対応付け。これらの決定あるいは対応づけの１つまたは複数のバリエーションによって，システムアーキテクチャが変化する。
【００３５】
その場合に，生じるシステムアーキテクチャについて信頼性（信頼性機能の値）を計算し，高い信頼性を有するコンフィグレーションに優先順位を与えることが有効である。その場合に計算された信頼性は，要求されるシステム機能に関するか，あるいはシステムの安全機能に関する。２つの信頼性を混合して，それによって信頼性に関しても安全性に関しても高い値を得るシステムアーキテクチャを見出すと，効果的である。
【００３６】
安全性を高めるためには，要求されるシステム機能を監視機能によってコントロールすることが有効である。それによって，システムの所定のシステム機能がもはや供給できない場合に，遅すぎない時期に措置を講じることができる。この措置は，万一のリスクを最小限に抑えるために，該当する情報の出力からシステム全体の遮断に及ぶ。
【００３７】
安全性は，システム機能を監視するための監視機能自体がシステム監視機能によって監視されることにより，さらに向上する。
【００３８】
さらに，システム監視機能が，システム機能を監視するための監視機能を有するシステム部分を，少なくとも部分的に監視すると，効果的である。それによって監視機能だけでなく，システム部分（たとえばマイクロコントローラ）全体も管理され，このシステム部分の故障が検出される。
【００３９】
さらに，システム監視機能が２つのシステム部分へ分配され，そのうちの一方のシステム部分が上述の監視機能と，この分配された監視機能によって監視される，要求されるシステム機能を有していると，効果的である。すなわち，この種の構成は，２つのシステム部分の相互監視，特にこれらシステム部分の相互の監視を可能にする。
【００４０】
本発明に基づく方法は，以下で詳細に説明するように，分配され，ネットワーク化されたシステム（制御装置）内でソフトウェアコンポーネントを（マイクロコントローラのような）ハードウェアコンポーネントに最適に対応づけるために，効果的に使用される。さらに，本発明に基づく方法は，ソフトウェアベースの電子システム，特に，エンジン制御装置のような，制御装置のシステムアーキテクチャを効果的に定めるのに，適している。
【００４１】
本発明に基づく方法は，実際において，数多く存在する複雑な電子システムのために，好ましくはコンピュータプログラムを用いて実装される。このコンピュータプログラムは，与えられたシステムアーキテクチャにおいて付属の信頼性機能を定め，それに基づいてシステムの信頼性と安全性についての該当する値を計算する。コンピュータプログラムを介して実装する場合に，特にシステムアーキテクチャが効率的に最適化され，その場合に（モンテカルロ方法のような）既知の最適化方法を使用することができる。信頼性機能を定めるために信頼性ブロック図を使用する場合に，コンピュータプログラムは冒頭で示された基本的規則（上の表３を参照）を使用して迅速に該当する信頼性機能を求める。
【００４２】
コンピュータプログラムは，ＥＥＰＲＯＭ，フラッシュメモリ，そしてまたＤＶＤ，ＣＤ−ＲＯＭ，ディスケットまたはハードディスクドライブのような，適切なデータ媒体上に記憶させることができる。内部の，あるいは公的に利用可能なネットワーク（イントラネットまたはインターネット）を介してコンピュータプログラムをダウンロードすることも可能である。
【発明を実施するための最良の形態】
【００４３】
図１と２は，明細書導入部ですでに詳細に扱われている。
【００４４】
まず，図３を用いて信頼性分析および安全性分析のステップを説明する。それは，複数のステップを有する，反復性を有してつながり合ったプロセスである。それは，電子システムのためのハードウェア，ソフトウェアとおよびソフトウェア開発プロセスへの要求に影響を与える。ここでは，システムの安全性分析のためにも，ＦＭＥＡまたはＦＴＡのような，故障率分析の方法が使用される。故障率分析は，システムのすべての機能についてのリスクの評価をもたらす。許容しうる限界リスクは，通常，法律，規格または規則のような，安全技術的定義によって暗示的に予め定められる。システムの機能について求められたリスクおよび許容しうる限界から，たとえばＩＥＣ６１５０８のような規格を用いて，システムに対する安全技術的要求が導き出され，それはしばしばエレクトロニクス開発においてシステム設計，ハードウェア設計およびソフトウェア設計に大きい影響を有している。
【００４５】
故障率分析によって定められ，定義された，システムのいわゆる安全上重要な機能のために，しばしば特別な保護措置がとられなければならず，それはたとえばハードウェアまたはソフトウェア内で実現することができる。
【００４６】
詳細には，図３は，２つのメインブロック９と１０を示しており，その場合に第１のメインブロック９は信頼性分析および安全性分析に関するものであって，第２のメインブロック１０は，信頼できる，安全なシステムの詳細な説明に関する。信頼性分析および安全性分析（メインブロック９）へ，論理的システムアーキテクチャ１１も，技術的システムアーキテクチャ１２も加わる。技術的システムアーキテクチャ１２自体は，システムの詳細な説明の結果であって，その場合に変更されたシステムの詳細な説明（システムアーキテクチャ）が更新された信頼性分析および安全性分析をもたらす。
【００４７】
信頼性分析および安全性分析の最初には，一方では危険分析１３が，他方では重要なコンポーネントおよびサブシステムの識別（符号１４を有するブロック）がある。危険分析１３からは，具体的な，危険な状態１５が生じ，それに，明細書の導入部（背景技術）で詳細に説明したように，リスク（故障種類）および故障率分析１７が接続されている。この故障率分析１７の結果が，システムへの信頼性要求および安全性要求１８である。他方の側で，重要なコンポーネントおよびサブシステムの識別１４の結果として，システムの信頼と安全上重要なコンポーネントおよびサブシステム１６が得られる。
【００４８】
２つの信頼性分析および安全性分析の結果から，すなわち信頼上および安全上重要なコンポーネントおよびサブシステム１６とシステムへの信頼性要求および安全性要求１８から，必要かつ可能なシステム仕様書（メインブロック１０）が導き出される。重要なコンポーネントおよびサブシステムは，検証および妥当性検査プロセスの定義１９と技術的コンポーネントおよびサブシステムへの要求の定義２０に影響を与える。システムへの信頼性要求および安全性要求１８は，ソフトウェア開発プロセスの定義（ブロック２１）に影響を与える。
【００４９】
具体的な結果は，ここでは，検証と妥当性検査プロセス２２，ハードウェアへの信頼性要求および安全性要求２３，ソフトウェアへの信頼性要求および安全性要求２４並びに本来のソフトウェア開発プロセス２５である。
【００５０】
この４つの具体的な結果が，技術的システムアーキテクチャ１２の全体結果をもたらす。この技術的アーキテクチャは，場合によっては補正することができ，補正したシステムアーキテクチャがより信頼性と安全性が高いシステムをもたらすかを検査するために，上述したステップを繰り返すことができる。
【００５１】
この監視概念の安全性と信頼性の立証は，道路交通に対して車両を許可するための前提である。以下において，Ｅ−ガス−システムのための監視概念の例で，信頼性ブロック図を使用して監視概念の信頼性と安全性を判定する方法を説明する。
【００５２】
Ｅ−ガス−システムにおいて起こりうる危険として，意図しない加速とそれに基づく事故が想定される。エンジン制御装置にとって，これは，エンジントルクの不用意な増大をもたらす可能性のある，すべての開ループ制御および閉ループ制御機能ｆｎが安全上重要であることを意味している。従って，これらの機能について，監視概念が必要である。
【００５３】
この例において，何年も前からエンジン制御装置において使用されているような，安全性と信頼性に関する，幾分簡略化された監視コンセプトを，本発明に基づく方法を用いて調べる。自動車産業組合（ＶＤＡ）のワークグループ「Ｅ−ガス」の枠内では，ローベルトボッシュ社によって開発された，この基本概念が，現在，オットーエンジンとディーゼルエンジンのエンジン制御のための標準化された監視概念として，さらに開発されている。
【００５４】
図４には，安全上重要な開ループ制御および閉ループ制御機能ｆｎのための監視コンセプトが示されている。
【００５５】
図４では，ソフトウェアベースの電子システムとして，制御装置３０が示されている。第１のマイクロコントローラ３１が，機能計算機として用いられ，第２のマイクロコントローラ３２は監視計算機として使用される。信号が，制御装置３０の入力段３３へ達して，そこからマイクロコントローラ３１内のＡ／Ｄ変換器３４へ供給される。デジタル化された信号が，本来の開ループ制御および閉ループ制御機能ｆｎ（ブロック４１）を作動させる。並行して信号がブロック４２へ供給され，そのブロックは開ループ制御および閉ループ制御機能を監視するための機能ｆＵｎ（Ｕはウムラウト付き。以下同様）を有している。開ループ制御および閉ループ制御機能を監視するために，ブロック４１はブロック４２と接続されている。上述した監視機能ｆＵｎは，それ自体マイクロコントローラを監視する機能，すなわちいわゆるシステム監視機能によって検査される。そのために，ブロック４２がブロック４３と接続されている。ブロック４１，４２および４３は，マイクロコントローラ３１のソフトウェア４５の構成部分である。ブロック４２と４３は，純粋な監視機能を有している。
【００５６】
さらに図４には，監視計算機として用いられるマイクロコントローラ３２が示されており，マイクロコントローラを監視する機能（ブロック４４）がマイクロコントローラ３２に属している。図４から明らかなように，マイクロコントローラを監視するためのこの機能（システム監視機能）は，２つのマイクロコントローラ３１と３２に分配されている。それについては，後に詳しく説明する。ブロック４２，４３および４４は，監視機能２９を表している。
【００５７】
制御装置によって実施される開ループ制御および閉ループ制御機能ｆｎ（ブロック４１）は，出力信号の形式でＤ／Ａ変換器３５へ印加され，その出力に出力段４０が接続されている。監視を行うブロック４２，４３および４４の出力３６，３７および３８は，加算素子３９へ供給されるので，３つのブロックの中の１つの，ブロック４２，４３または４４によるエラーの認識が，加算素子３９のエラーの認識に応じた出力信号をもたらす。加算素子は，出力段４０と接続されており，エラーの認識によってそれぞれのエラーの種類に応じて，定義された影響を出力段へ与えることができる。
【００５８】
以下で，図４に示す監視概念の機能を詳細に説明する。
【００５９】
安全上重要な開ループ制御および閉ループ制御機能ｆｎは，監視機能ｆＵｎによって常に監視される。監視機能ｆＵｎは，開ループ制御および閉ループ制御機能ｆｎと同じ入力量を使用するが，異なるデータおよび異なるアルゴリズムで作動する。
【００６０】
マイクロコントローラを監視する機能（＝システム監視機能）は，ＲＡＭ機能，ＲＯＭ機能およびマイクロプロセッサ機能の他に，たとえば，開ループ制御および閉ループ制御機能ｆｎと監視機能ｆＵｎがそもそも実施されるかについても検査する。これが，この例において，制御装置３０内の第２のマイクロコントローラの，いわゆる監視計算機の使用を必要とする。マイクロコントローラ３１，３２を監視する機能は，機能計算機と監視計算機に分配されている。両者は，好ましくは質問−応答プレイにおいて，相互に監視する。
【００６１】
安全な状態として，この実施例においては，電気機械的な絞り弁のための電流遮断が定められている。絞り弁は，電流遮断後に自動的にアイドリング位置を占めるような構造に設計されている。従って，安全な状態への移行は，絞り弁を駆動する制御装置の出力段４０の切断が行われることによって，導かれる。従ってエンジンは，非常走行でさらに駆動することができる。
【００６２】
従って，機能計算機と監視計算機上の監視機能ｆＵｎもマイクロコントローラを監視する機能も，制御装置３０の絞り弁出力段を遮断することができる。エラーが認識された場合には，この安全反応の他に，エラーメモリへの記入も行われる。さらに，多くは，たとえば計器板内の表示を介して，運転者にも情報が出力される。
【００６３】
この監視コンセプトの信頼性を判定しようとする場合には，まず，３つの種類の機能が区別される：
・開ループ制御および閉ループ制御機能ｆｎ
・監視機能ｆＵｎ
・マイクロコントローラを監視する機能（＝システム監視機能）
その場合に，これら異なる機能のための図５に示した信頼性ブロック図の４５，４６，４７が，極めて簡単に定められる。
【００６４】
システム信頼性を定めるために，３つの種類の機能すべてが必要となる。その場合にシステム信頼性は，これらのブロック図の直列接続によって得られる。付加的に，個々の機能のブロック図内には設けられない，コンポーネントＫ７とＫ８（図４のブロック４３と４４の接続）も，直列に接続されなければならない。
【００６５】
システム信頼性ＲＳ Zuverlaessigkeitは，３つの機能Ｒｘ；ｘ＝Ａ，Ｂ，Ｃの信頼性をコンポーネントの信頼性Ｋ７ＲＤとＫ８ＲＥで乗算することによって得られ，Ｒｘ＜１であるので，どんな場合にも機能Ｒｘのそれぞれの信頼性よりも小さい。システム信頼性を計算する場合に，信頼性ブロック図内で何回も生じるエレメントを有する計算のための規則に注意しなければならない（上記Allessandro Birolini:Zuverlaessigkeit von Geraete und Systemenを参照）。
ＲＳ
Zuverlaessigkeit＝ＲＡＲＢＲＣＲＤＲＥ
【００６６】
それに対して安全性については，信頼できる故障の確認と信頼できる安全な状態への移行のみが必要とされる。この安全反応の信頼性ＲＳ Sicherheitは，監視機能ｆＵｎまたはマイクロコントローラを監視する機能の信頼性によって予め定められ，従って機能Ｒｘの信頼性よりも高い。さらに，コンポーネントの信頼性Ｋ７ＲＤとＫ８ＲＥは，ＲＳ Sicherheitの計算には含まれない。
【００６７】
安全機能（安全反応）の信頼性のための信頼性機能は，以下のようになる：
ＲＳ
Sicherheit＝１−（１−ＲＢ）（１−ＲＣ）
【００６８】
この例が示すように，安全性を向上させるための手段は，システムの信頼性を減少させる可能性がある。さらに，信頼性を向上させる手段が，システムの安全性の低減をもたらす可能性があることが，明らかである。
【００６９】
本発明に基づく方法においては，原則として，ハードウェアコンポーネントとハードウェア接続のみが考察されるが，信頼性分析および安全性分析は，ソフトウェア開発に大きな影響を有している。監視概念の評価の例で示したように，それは，たとえば分配され，ネットワーク化されたシステム内のマイクロコントローラへのソフトウェア機能の対応づけあるいはソフトウェア開発において必要な品質保証手段に影響を与える。これは，従来技術に比較して，著しい前進であって，システム開発における大きな利点をもたらす。
【００７０】
本発明に基づく方法は，ソフトウェアベースの電子システムの安全性と信頼性を検査するための以下の方法を可能にする（図４と５を参照）：
【００７１】
ステップ１：電子システムのハードウェアネットワークの決定，すなわち特にマイクロコントローラ３１，３２の特殊化とそのネットワーク化；
ステップ２：電子システムの機能を実現するために必要な，ソフトウェアコンポーネント４１−４４の決定とソフトウェアコンポーネント４１〜４４間の通信の特殊化；
ステップ３：ハードウェアネットワークのマイクロコントローラ３１，３２へのソフトウェアコンポーネント４１−４４の対応づけ；
ステップ４：ハードウェアコンポーネントとハードウェア接続Ｋｉ，ｉ＝１，…，１３に基づいて電子システム３０の要求される機能のための信頼性ブロック図４５〜４７を作成；
ステップ５：電子システム（３０）の安全性機能のための信頼性と要求される全機能のための信頼性の計算により安全性と信頼性を立証；
ステップ６：場合によってはステップ１から５を繰り返して，システムアーキテクチャ，すなわちソフトウェアネットワークおよびハードウェアネットワークと，ハードウェアコンポーネントへのソフトウェアコンポーネントの対応づけを補正。
【図面の簡単な説明】
【００７２】
【図１】電子システムの例としてブレーキ−バイ−ワイヤ−システムを概略的に示す説明図である。
【図２】図１に示すシステムに属する信頼性ブロック図を機能「ブレーキ」について示す説明図である。
【図３】信頼性および安全性分析におけるステップのシーケンスと信頼できかつ安全なシステムの仕様書の例を示す説明図である。
【図４】本発明に基づいて安全性と信頼性に関して監視される，分配され，ネットワーク化されたシステムの例として，制御装置のコンポーネントを概略的に示す説明図である。
【図５】図４に示すシステムの機能についての種々の信頼性ブロック図を示す説明図である。
【技術分野】
【０００１】
本発明は，システムの要求される機能を検査するための信頼性機能を用いて，そのために必要なシステムのハードウェアコンポーネントに基づいて，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法に関する。さらに，本発明は，この方法の使用および方法を実装するためのコンピュータプログラムとコンピュータプログラム製品に関する。
【背景技術】
【０００２】
車両機能に対する信頼性要請と安全性要請は，技術的，法律的および経済的な周辺条件を考慮して，顧客要望から得られる。車両機能に対する信頼性要請は，たとえば短い修理時間または長いサービスインターバルの形式で与えられる。それに対して安全性要請は，車両の部品の故障または障害の場合における車両の安全な行動を定める。車両機能に課せられる信頼性要請と安全性要請は，最初から，実現と立証義務に対する要請も定める。安全性と信頼性を向上させるための強力な手段の１つは，冗長性である。車両機能または車両機能の一部がソフトウェアによって実現されることが増えているので，信頼性分析と安全性分析を行う体系的な方法が，電子制御装置のためのソフトウェア開発に，たとえば監視概念，診断概念および安全性概念の実現に，ますます大きくなる影響を有している。
【０００３】
複雑な電子システムのためには，信頼性と安全性を確保するための行動が早期に計画されて，プロジェクトプラン全体に統合されなけれならない。
【０００４】
「システム」という概念は，本出願の枠内において，それぞれ文脈に従って以下のものと考えられる：所定の機能を得るために必要な最小のシステム部分，システム全体へ至るまでの，協働するシステム部分あるいは，さらに広く捉えて，操作者またはシステム全体に作用する他の要素を含めたシステム全体を指す。本発明を説明するために，本出願の枠内では，大体において，車両制御の構成部分であるシステムを参照する。この参照は，純粋に説明的な特性を有しており，本発明は決してこの種のシステムに限定されない。本発明は，むしろ，ソフトウェアベースの電子システムに関して，普遍的に妥当性を有している。
【０００５】
この種のシステムの安全性と信頼性を検査するために，信頼性機能の使用が知られており，その信頼性機能を用いてシステムの要求される機能についての信頼性の程度を示すことができる。この種の信頼性機能を定めるために，要求されるシステム機能に必要な，システムのハードウェアコンポーネントの信頼性から始めることができる。信頼性分析は，たとえば，故障率分析および作用分析（ＦＭＩＡ）あるいはエラーツリー分析（ＦＴＡ）のような，故障率分析および故障種類分析を有する。以下においては，信頼性分析を，故障率分析を用いて，考察されるシステムのための信頼性ブロック図を用いて信頼性機能を計算しながら，詳細に説明する。
【０００６】
考察ユニットの故障率の系統的調査は，計算による考察ユニットのための信頼性の予測を可能にする。弱い箇所を早期に認識して，代替策を評価し，信頼性，安全性および可用性の間の関係を量的に検出できるようにするために，この予測は重要である。さらに，たとえばシステムコンポーネントに対して信頼性要請を課すことができるようにするために，この種の調査は必要である。
【０００７】
無視と簡略化により，および使用される入力データの不確実性により，計算され，予測された信頼性は，真の信頼性のためのおおよその数値でしかなく，真の信頼性は信頼性検査とフィールド観察によってしか求められない。しかし，分析段階における比較調査の枠内では，絶対的な精度は役割を果たさないので，特に実現選択肢を評価する際に，予測される信頼性の計算は，有用である。
【０００８】
以下の部分において，考察単位は，常に車両の技術システムまたはシステムコンポーネントである。一般的な場合においては考察単位は，もっと広く捉えることができ，たとえば車両の運転者も含めることができる。
【０００９】
故障率分析（これについては，アレッサンドロ・ビロリーニの「機器とシステムの信頼性（Alessandro Birolini:Zuverlaessigkeit von Geraete und Systemen，
Springere Verlag, 1997）を参照）は，以下のステップを区別する：
・技術的システムの限界とコンポーネント，要求される機能および要求プログラムを定義
・信頼性ブロック図（英語ではReliability Block Diagram）を作成
・各コンポーネントについて負荷条件を決定
・各コンポーネントについて信頼性機能または故障率を決定
・システムのための信頼性機能を算出
・弱い箇所を克服
【００１０】
故障率分析は，多段階の方法であって，システムレベルから種々のサブシステムレベルを介して技術的システムアーキテクチャのコンポーネントレベルへ至るまで「トップダウン」で実施することができる。故障率分析は，技術的システムアーキテクチャが変化した後に，繰り返されなければならない。
【００１１】
以下，故障率分析の第１のステップを，詳細に説明する。
【００１２】
信頼性の予測のために必要な，論理的考察のためには，システムとその機能および信頼性と安全性を改良するための具体的可能性の詳細な知識が前提とされる。システム理解には，システムのアーキテクチャとその作用方法の知識，すべてのシステムコンポーネントのための作業条件と負荷条件および，たとえば信号の流れおよびすべてのコンポーネントの入力および出力サイトの形式の，コンポーネント間の相互の相互作用が重視される。改良のための具体的可能性に属するのは，駆動中のコンポーネントの負荷，たとえば静的または動的な負荷，インターフェイスの負荷の制限と減少，もっと適したコンポーネントの使用，システムまたはコンポーネント設計の簡略化，重要なコンポーネントの前処理および冗長性の使用である。
【００１３】
要求される機能が，システムの課題を指定する。システム限界および要求される機能を決定することは，それによって故障も定義されるので，各信頼性分析の出発点を形成する。
【００１４】
付加的に，システムのすべてのコンポーネントについて環境条件が定義されなければならない。というのは，それによってコンポーネントの信頼性が影響を受けるからである。すなわち，たとえば，温度領域は，ハードウェアコンポーネントの故障率に大きい影響を有している。車両内では，たとえば，要求される温度領域，湿度，埃または腐食性の環境下での使用あるいは振動，ショックまたは，たとえば供給電圧の変動による負荷が，環境条件に属する。さらに，要求される機能と環境条件が時間に依存する場合には，要求プロフィールが決定されなければならない。車両内の法律的に定められた要求プロフィールの例は，排ガス規則の維持を立証するための走行サイクルである。この場合において，代表的な要求プロフィールにも言及される。
【００１５】
次に，故障率分析の第２のステップを詳細に説明する。
【００１６】
信頼性ブロック図は，システムのどのハードウェアコンポーネントが必要な機能を満たすために原則的に機能しなければならないか，およびどのハードウェアコンポーネントが，故障した場合に，冗長に存在しているために原則的に機能を損なわないか，という問いに解答を与える。信頼性ブロック図の形成は，技術的システムアーキテクチャのコンポーネントを考察することによって行われる。これらのコンポーネントは，信頼性ブロック図内で，機能を満たすために必要なコンポーネントは直列に接続され，冗長なコンポーネントは並列回路内で接続されるようにして，接続される。
【００１７】
図１は，いわゆるブレーキ−バイ−ワイヤ−システム１を概略的に示しており，その場合にブレーキペダル２，制御装置３および４つのブレーキユニット，すなわち左前のブレーキユニット４，左後ろのブレーキユニット５，右前のブレーキユニット６および右後ろのブレーキユニット７，が示されている。ブレーキ−バイ−ワイヤ−システム１の機能のために必要なハードウェアコンポーネントは，Ｋで示されている。
【００１８】
図１に示すような，仮想のブレーキ−バイ−ワイヤ−システム１のために，まずシステム限界が定められる。システムは，ブレーキペダルユニット（Ｋ１），制御装置（Ｋ２），車輪ブレーキユニット（Ｋ５，Ｋ７，Ｋ９，Ｋ１１）および電気的な接続（Ｋ３，Ｋ４，Ｋ６，Ｋ８，Ｋ１０）のコンポーネントからなる。
【００１９】
ブレーキ−バイ−ワイヤ−システムにおいては，ブレーキペダルと車輪ブレーキの間に油圧的な接続はなく，電気的な接続がある。運転者の指示によってブレーキがかかった場合に，ブレーキペダルユニットＫ１によって設定されて，制御装置Ｋ２内で処理される，運転者の指示によるブレーキに必要なエネルギは，「ワイヤによって」車輪ブレーキユニットＫ５，Ｋ７，Ｋ９およびＫ１１へ伝達される。その場合に，従来のブレーキシステムにおいては機械−油圧的に実施される，電気的および電子的コンポーネントＫ２，Ｋ３，Ｋ４，Ｋ６，Ｋ８およびＫ１０による，ペダルユニットと車輪ブレーキユニットとの間の「情報伝達およびエネルギ伝達」機能の引渡しが，付加的な安全リスクをもたらさず，安全利得をもたらすことが，保証されなければならない。従ってブレーキ指令の予測可能な伝達は，必然的な予測である。同様に，コンポーネントの障害と故障においても，安全が保証されなければならない。
【００２０】
「ブレーキ」の機能を考察する。そのためにシステムの信頼性全体が定められる。コンポーネントＫ１からＫ１１の故障率λ１からλ１１がわかっているものと仮定する。
【００２１】
この例は，さらに，極めて著しく簡略化される。信頼性分析の際の原理的な方法のみが，明らかにされる。従って，情報伝送のみを考察し，エネルギ供給とエネルギ伝達の視点および，前車軸と後車軸上の要求されるブレーキ力分配のような，走行動的な周辺条件は無視される。もちろん，これらは信頼性分析の場合にも考慮されなければならない。
【００２２】
「ブレーキ」機能を満たすために，この簡略化された視点においては，ブレーキペダルユニットＫ１，制御装置Ｋ２のコンポーネントおよびブレーキペダルユニットと制御装置Ｋ３間の接続が機能することが，必要不可欠である。
【００２３】
ホイールブレーキユニットは，制御装置とホイールブレーキユニットの間の接続において，冗長性を有する。車両のための十分な補助ブレーキ力が１つのホイールブレーキユニットのみによって得られる，という著しく簡略化された仮定の下で，たとえばコンポーネントＫ４とＫ５は必要不可欠であって，コンポーネントＫ６とＫ７，Ｋ８とＫ９並びにＫ１０とＫ１１は冗長に存在している。この種の配置を，４−１の冗長性と称する。
【００２４】
「ブレーキ」機能のための信頼性ブロック図は，図２のように示される。
【００２５】
すべてのコンポーネントＫｉについて負荷条件を決定し，かつ信頼性機能Ｒｉ（ｔ）を定めた後に，次の表３に示す，信頼性ブロック図のための基本的な規則を考慮して，システムの信頼性機能Ｒｓ（ｔ）を計算することができる。
【００２６】
従って図２の例について，システムの信頼性機能Ｒｓを計算することができる。Ｒ４＝Ｒ６＝Ｒ８＝Ｒ１０およびＲ５＝Ｒ７＝Ｒ９＝Ｒ１１と仮定して，Ｒｓについて次の式が成り立つ：
Ｒｓ＝Ｒ１Ｒ２Ｒ３［１−（１−Ｒ４Ｒ５）４］
【００２７】
この簡略化した例が示すように，機能のためのシステムの信頼性は，信頼性ブロック図内の冗長なコンポーネントにより，コンポーネントの信頼性に比較して増大する。それに対して，連続的に図示されているコンポーネントにおいては，システム信頼性はコンポーネント信頼性に比較して減少する。従って信頼性ブロック図内の連続的なコンポーネントのために，既にコンポーネントの高い信頼性を要求しなければならず，あるいはここでも冗長な構造を設ける，技術的システムアーキテクチャを計画しなければならない。
【００２８】
上記では，システムの信頼性機能の計算が，所定の要求されるシステム機能について実例として，著しく簡略化して示されているが，同様な方法で，システムの安全性に関する説明を行うことができるようにすることが望ましい。システムの安全性のためには，しばしば，考察の単位が要求される機能を満たしているか否かは，それによって支持し得ない高いリスクが生じない限り，重要ではない。本出願において考察されるような，ソフトウェアベースの電子システムは，主としてハードウェアコンポーネントとソフトウェアコンポーネントからなり，その場合にソフトウェアコンポーネントは大体において，システムのハードウェアコンポーネントの幾つかに分配することができる。この種のソフトウェアベースの電子システムの安全性も信頼性も，信頼のおけるように検査できるようにする，強い要請がある。
【発明の開示】
【００２９】
本発明によれば，システムが要求する機能の少なくとも１つのものの信頼性を計算するための信頼性機能と，システムの安全性機能の少なくとも１つのものの信頼性を計算するための信頼性機能とが定められ，その場合にこの信頼性機能を定める際に，システムのソフトウェアコンポーネントも一緒に考慮される。その場合にソフトウェアコンポーネントは，ハードウェアコンポーネント（このハードウェアコンポーネントにソフトウェアコンポーネントが分配されている）を用いて，一緒に考慮される。その場合にこの考慮は，１つまたは複数のハードウェアコンポーネント自体と，それぞれのソフトウェアにより（たとえば出力信号の出力によって）影響を受けるハードウェアの接続にも拡げることができる。それによって初めて，ソフトウェアベースの電子システムの安全性と信頼性に関する説明を行うことが可能となり，その場合にこの説明は，それぞれの接続を含めたハードウェアコンポーネントとソフトウェアコンポーネントからなるシステムに関するものであって，ハードウェアコンポーネントのみに限定されない。
【００３０】
ハードウェアコンポーネントとソフトウェアコンポーネントを有するシステムの安全性と信頼性は，信頼性機能を使用して検査され，その信頼性機能は，例えば冒頭で説明した，システムのための信頼性ブロック図を用いて定めることができる。後で説明するように，本発明によれば，信頼性機能を定める場合にシステムのソフトウェアコンポーネントが一緒に考慮される。これは，新しいシステム定義に匹敵する。というのは，これまで信頼性分析のためには，ハードウェアコンポーネントからなるシステムのみが考慮されており，ソフトウェアコンポーネントはもし考慮されるとしても，独自の別の分析を受けていたからである。
【００３１】
本発明によれば，一般に，ソフトウェアとハードウェアから実現される電子システムの特殊性と機能において，達成可能なシステム安全性およびシステム信頼性に関して，電子制御装置の様々な監視概念を早期に評価することが可能となる。結果は，特にネットワーク化された制御装置のマイクロコントローラへのソフトウェア機能の分配と，それに伴って分配された，ネットワーク化された制御装置のためのソフトウェアの開発に影響を与える。
【００３２】
全体としてシステムに関する説明を行うことができるようにするために，システムのすべての機能，従ってすべての要求されるシステム機能とシステムのすべての安全性機能を，該当する信頼性機能の規定によって検査することが適切である。
【００３３】
信頼性機能は，通常，たとえば０から１の，所定の範囲の値を有しており，その場合に以下においては普遍妥当性を制限することなしに，高い値（１）が高い信頼性を表し，低い値（０）は低い信頼性を表すと仮定する。本発明に基づく信頼性機能は，一方では，要求されるシステム機能の信頼性に関し，他方ではシステムの安全性機能の信頼性に関する。該当する信頼性機能を定めた後に，システム機能の信頼性ないし安全性機能に関する具体的な説明を得るために，選択したシステムアーキテクチャ（またはシステム構成）についてこれらの信頼性機能の具体的な値を計算することが，効果的である。
【００３４】
通常，選択されたシステムアーキテクチャの他に，同一の要求されるシステム機能をもたらす，他の構成も実現可能である。同じことが，要求される安全性機能についても当てはまる。従って適切なシステムアーキテクチャを選択するためには，種々のシステムアーキテクチャについて本発明により定められる信頼性機能が定められると，効果的である。その場合にシステムアーキテクチャは，以下のように変化させることができる：要求されるシステム機能および安全機能を実現するために必要なハードウェアコンポーネントの決定（ハードウェアコンポーネントの種類，これらのコンポーネントの配置と冗長性）；要求されるシステム機能と安全機能を実現するために必要なソフトウェアコンポーネントの決定および所定のハードウェアコンポーネントへのソフトウェアコンポーネントの対応付け。これらの決定あるいは対応づけの１つまたは複数のバリエーションによって，システムアーキテクチャが変化する。
【００３５】
その場合に，生じるシステムアーキテクチャについて信頼性（信頼性機能の値）を計算し，高い信頼性を有するコンフィグレーションに優先順位を与えることが有効である。その場合に計算された信頼性は，要求されるシステム機能に関するか，あるいはシステムの安全機能に関する。２つの信頼性を混合して，それによって信頼性に関しても安全性に関しても高い値を得るシステムアーキテクチャを見出すと，効果的である。
【００３６】
安全性を高めるためには，要求されるシステム機能を監視機能によってコントロールすることが有効である。それによって，システムの所定のシステム機能がもはや供給できない場合に，遅すぎない時期に措置を講じることができる。この措置は，万一のリスクを最小限に抑えるために，該当する情報の出力からシステム全体の遮断に及ぶ。
【００３７】
安全性は，システム機能を監視するための監視機能自体がシステム監視機能によって監視されることにより，さらに向上する。
【００３８】
さらに，システム監視機能が，システム機能を監視するための監視機能を有するシステム部分を，少なくとも部分的に監視すると，効果的である。それによって監視機能だけでなく，システム部分（たとえばマイクロコントローラ）全体も管理され，このシステム部分の故障が検出される。
【００３９】
さらに，システム監視機能が２つのシステム部分へ分配され，そのうちの一方のシステム部分が上述の監視機能と，この分配された監視機能によって監視される，要求されるシステム機能を有していると，効果的である。すなわち，この種の構成は，２つのシステム部分の相互監視，特にこれらシステム部分の相互の監視を可能にする。
【００４０】
本発明に基づく方法は，以下で詳細に説明するように，分配され，ネットワーク化されたシステム（制御装置）内でソフトウェアコンポーネントを（マイクロコントローラのような）ハードウェアコンポーネントに最適に対応づけるために，効果的に使用される。さらに，本発明に基づく方法は，ソフトウェアベースの電子システム，特に，エンジン制御装置のような，制御装置のシステムアーキテクチャを効果的に定めるのに，適している。
【００４１】
本発明に基づく方法は，実際において，数多く存在する複雑な電子システムのために，好ましくはコンピュータプログラムを用いて実装される。このコンピュータプログラムは，与えられたシステムアーキテクチャにおいて付属の信頼性機能を定め，それに基づいてシステムの信頼性と安全性についての該当する値を計算する。コンピュータプログラムを介して実装する場合に，特にシステムアーキテクチャが効率的に最適化され，その場合に（モンテカルロ方法のような）既知の最適化方法を使用することができる。信頼性機能を定めるために信頼性ブロック図を使用する場合に，コンピュータプログラムは冒頭で示された基本的規則（上の表３を参照）を使用して迅速に該当する信頼性機能を求める。
【００４２】
コンピュータプログラムは，ＥＥＰＲＯＭ，フラッシュメモリ，そしてまたＤＶＤ，ＣＤ−ＲＯＭ，ディスケットまたはハードディスクドライブのような，適切なデータ媒体上に記憶させることができる。内部の，あるいは公的に利用可能なネットワーク（イントラネットまたはインターネット）を介してコンピュータプログラムをダウンロードすることも可能である。
【発明を実施するための最良の形態】
【００４３】
図１と２は，明細書導入部ですでに詳細に扱われている。
【００４４】
まず，図３を用いて信頼性分析および安全性分析のステップを説明する。それは，複数のステップを有する，反復性を有してつながり合ったプロセスである。それは，電子システムのためのハードウェア，ソフトウェアとおよびソフトウェア開発プロセスへの要求に影響を与える。ここでは，システムの安全性分析のためにも，ＦＭＥＡまたはＦＴＡのような，故障率分析の方法が使用される。故障率分析は，システムのすべての機能についてのリスクの評価をもたらす。許容しうる限界リスクは，通常，法律，規格または規則のような，安全技術的定義によって暗示的に予め定められる。システムの機能について求められたリスクおよび許容しうる限界から，たとえばＩＥＣ６１５０８のような規格を用いて，システムに対する安全技術的要求が導き出され，それはしばしばエレクトロニクス開発においてシステム設計，ハードウェア設計およびソフトウェア設計に大きい影響を有している。
【００４５】
故障率分析によって定められ，定義された，システムのいわゆる安全上重要な機能のために，しばしば特別な保護措置がとられなければならず，それはたとえばハードウェアまたはソフトウェア内で実現することができる。
【００４６】
詳細には，図３は，２つのメインブロック９と１０を示しており，その場合に第１のメインブロック９は信頼性分析および安全性分析に関するものであって，第２のメインブロック１０は，信頼できる，安全なシステムの詳細な説明に関する。信頼性分析および安全性分析（メインブロック９）へ，論理的システムアーキテクチャ１１も，技術的システムアーキテクチャ１２も加わる。技術的システムアーキテクチャ１２自体は，システムの詳細な説明の結果であって，その場合に変更されたシステムの詳細な説明（システムアーキテクチャ）が更新された信頼性分析および安全性分析をもたらす。
【００４７】
信頼性分析および安全性分析の最初には，一方では危険分析１３が，他方では重要なコンポーネントおよびサブシステムの識別（符号１４を有するブロック）がある。危険分析１３からは，具体的な，危険な状態１５が生じ，それに，明細書の導入部（背景技術）で詳細に説明したように，リスク（故障種類）および故障率分析１７が接続されている。この故障率分析１７の結果が，システムへの信頼性要求および安全性要求１８である。他方の側で，重要なコンポーネントおよびサブシステムの識別１４の結果として，システムの信頼と安全上重要なコンポーネントおよびサブシステム１６が得られる。
【００４８】
２つの信頼性分析および安全性分析の結果から，すなわち信頼上および安全上重要なコンポーネントおよびサブシステム１６とシステムへの信頼性要求および安全性要求１８から，必要かつ可能なシステム仕様書（メインブロック１０）が導き出される。重要なコンポーネントおよびサブシステムは，検証および妥当性検査プロセスの定義１９と技術的コンポーネントおよびサブシステムへの要求の定義２０に影響を与える。システムへの信頼性要求および安全性要求１８は，ソフトウェア開発プロセスの定義（ブロック２１）に影響を与える。
【００４９】
具体的な結果は，ここでは，検証と妥当性検査プロセス２２，ハードウェアへの信頼性要求および安全性要求２３，ソフトウェアへの信頼性要求および安全性要求２４並びに本来のソフトウェア開発プロセス２５である。
【００５０】
この４つの具体的な結果が，技術的システムアーキテクチャ１２の全体結果をもたらす。この技術的アーキテクチャは，場合によっては補正することができ，補正したシステムアーキテクチャがより信頼性と安全性が高いシステムをもたらすかを検査するために，上述したステップを繰り返すことができる。
【００５１】
この監視概念の安全性と信頼性の立証は，道路交通に対して車両を許可するための前提である。以下において，Ｅ−ガス−システムのための監視概念の例で，信頼性ブロック図を使用して監視概念の信頼性と安全性を判定する方法を説明する。
【００５２】
Ｅ−ガス−システムにおいて起こりうる危険として，意図しない加速とそれに基づく事故が想定される。エンジン制御装置にとって，これは，エンジントルクの不用意な増大をもたらす可能性のある，すべての開ループ制御および閉ループ制御機能ｆｎが安全上重要であることを意味している。従って，これらの機能について，監視概念が必要である。
【００５３】
この例において，何年も前からエンジン制御装置において使用されているような，安全性と信頼性に関する，幾分簡略化された監視コンセプトを，本発明に基づく方法を用いて調べる。自動車産業組合（ＶＤＡ）のワークグループ「Ｅ−ガス」の枠内では，ローベルトボッシュ社によって開発された，この基本概念が，現在，オットーエンジンとディーゼルエンジンのエンジン制御のための標準化された監視概念として，さらに開発されている。
【００５４】
図４には，安全上重要な開ループ制御および閉ループ制御機能ｆｎのための監視コンセプトが示されている。
【００５５】
図４では，ソフトウェアベースの電子システムとして，制御装置３０が示されている。第１のマイクロコントローラ３１が，機能計算機として用いられ，第２のマイクロコントローラ３２は監視計算機として使用される。信号が，制御装置３０の入力段３３へ達して，そこからマイクロコントローラ３１内のＡ／Ｄ変換器３４へ供給される。デジタル化された信号が，本来の開ループ制御および閉ループ制御機能ｆｎ（ブロック４１）を作動させる。並行して信号がブロック４２へ供給され，そのブロックは開ループ制御および閉ループ制御機能を監視するための機能ｆＵｎ（Ｕはウムラウト付き。以下同様）を有している。開ループ制御および閉ループ制御機能を監視するために，ブロック４１はブロック４２と接続されている。上述した監視機能ｆＵｎは，それ自体マイクロコントローラを監視する機能，すなわちいわゆるシステム監視機能によって検査される。そのために，ブロック４２がブロック４３と接続されている。ブロック４１，４２および４３は，マイクロコントローラ３１のソフトウェア４５の構成部分である。ブロック４２と４３は，純粋な監視機能を有している。
【００５６】
さらに図４には，監視計算機として用いられるマイクロコントローラ３２が示されており，マイクロコントローラを監視する機能（ブロック４４）がマイクロコントローラ３２に属している。図４から明らかなように，マイクロコントローラを監視するためのこの機能（システム監視機能）は，２つのマイクロコントローラ３１と３２に分配されている。それについては，後に詳しく説明する。ブロック４２，４３および４４は，監視機能２９を表している。
【００５７】
制御装置によって実施される開ループ制御および閉ループ制御機能ｆｎ（ブロック４１）は，出力信号の形式でＤ／Ａ変換器３５へ印加され，その出力に出力段４０が接続されている。監視を行うブロック４２，４３および４４の出力３６，３７および３８は，加算素子３９へ供給されるので，３つのブロックの中の１つの，ブロック４２，４３または４４によるエラーの認識が，加算素子３９のエラーの認識に応じた出力信号をもたらす。加算素子は，出力段４０と接続されており，エラーの認識によってそれぞれのエラーの種類に応じて，定義された影響を出力段へ与えることができる。
【００５８】
以下で，図４に示す監視概念の機能を詳細に説明する。
【００５９】
安全上重要な開ループ制御および閉ループ制御機能ｆｎは，監視機能ｆＵｎによって常に監視される。監視機能ｆＵｎは，開ループ制御および閉ループ制御機能ｆｎと同じ入力量を使用するが，異なるデータおよび異なるアルゴリズムで作動する。
【００６０】
マイクロコントローラを監視する機能（＝システム監視機能）は，ＲＡＭ機能，ＲＯＭ機能およびマイクロプロセッサ機能の他に，たとえば，開ループ制御および閉ループ制御機能ｆｎと監視機能ｆＵｎがそもそも実施されるかについても検査する。これが，この例において，制御装置３０内の第２のマイクロコントローラの，いわゆる監視計算機の使用を必要とする。マイクロコントローラ３１，３２を監視する機能は，機能計算機と監視計算機に分配されている。両者は，好ましくは質問−応答プレイにおいて，相互に監視する。
【００６１】
安全な状態として，この実施例においては，電気機械的な絞り弁のための電流遮断が定められている。絞り弁は，電流遮断後に自動的にアイドリング位置を占めるような構造に設計されている。従って，安全な状態への移行は，絞り弁を駆動する制御装置の出力段４０の切断が行われることによって，導かれる。従ってエンジンは，非常走行でさらに駆動することができる。
【００６２】
従って，機能計算機と監視計算機上の監視機能ｆＵｎもマイクロコントローラを監視する機能も，制御装置３０の絞り弁出力段を遮断することができる。エラーが認識された場合には，この安全反応の他に，エラーメモリへの記入も行われる。さらに，多くは，たとえば計器板内の表示を介して，運転者にも情報が出力される。
【００６３】
この監視コンセプトの信頼性を判定しようとする場合には，まず，３つの種類の機能が区別される：
・開ループ制御および閉ループ制御機能ｆｎ
・監視機能ｆＵｎ
・マイクロコントローラを監視する機能（＝システム監視機能）
その場合に，これら異なる機能のための図５に示した信頼性ブロック図の４５，４６，４７が，極めて簡単に定められる。
【００６４】
システム信頼性を定めるために，３つの種類の機能すべてが必要となる。その場合にシステム信頼性は，これらのブロック図の直列接続によって得られる。付加的に，個々の機能のブロック図内には設けられない，コンポーネントＫ７とＫ８（図４のブロック４３と４４の接続）も，直列に接続されなければならない。
【００６５】
システム信頼性ＲＳ Zuverlaessigkeitは，３つの機能Ｒｘ；ｘ＝Ａ，Ｂ，Ｃの信頼性をコンポーネントの信頼性Ｋ７ＲＤとＫ８ＲＥで乗算することによって得られ，Ｒｘ＜１であるので，どんな場合にも機能Ｒｘのそれぞれの信頼性よりも小さい。システム信頼性を計算する場合に，信頼性ブロック図内で何回も生じるエレメントを有する計算のための規則に注意しなければならない（上記Allessandro Birolini:Zuverlaessigkeit von Geraete und Systemenを参照）。
ＲＳ
Zuverlaessigkeit＝ＲＡＲＢＲＣＲＤＲＥ
【００６６】
それに対して安全性については，信頼できる故障の確認と信頼できる安全な状態への移行のみが必要とされる。この安全反応の信頼性ＲＳ Sicherheitは，監視機能ｆＵｎまたはマイクロコントローラを監視する機能の信頼性によって予め定められ，従って機能Ｒｘの信頼性よりも高い。さらに，コンポーネントの信頼性Ｋ７ＲＤとＫ８ＲＥは，ＲＳ Sicherheitの計算には含まれない。
【００６７】
安全機能（安全反応）の信頼性のための信頼性機能は，以下のようになる：
ＲＳ
Sicherheit＝１−（１−ＲＢ）（１−ＲＣ）
【００６８】
この例が示すように，安全性を向上させるための手段は，システムの信頼性を減少させる可能性がある。さらに，信頼性を向上させる手段が，システムの安全性の低減をもたらす可能性があることが，明らかである。
【００６９】
本発明に基づく方法においては，原則として，ハードウェアコンポーネントとハードウェア接続のみが考察されるが，信頼性分析および安全性分析は，ソフトウェア開発に大きな影響を有している。監視概念の評価の例で示したように，それは，たとえば分配され，ネットワーク化されたシステム内のマイクロコントローラへのソフトウェア機能の対応づけあるいはソフトウェア開発において必要な品質保証手段に影響を与える。これは，従来技術に比較して，著しい前進であって，システム開発における大きな利点をもたらす。
【００７０】
本発明に基づく方法は，ソフトウェアベースの電子システムの安全性と信頼性を検査するための以下の方法を可能にする（図４と５を参照）：
【００７１】
ステップ１：電子システムのハードウェアネットワークの決定，すなわち特にマイクロコントローラ３１，３２の特殊化とそのネットワーク化；
ステップ２：電子システムの機能を実現するために必要な，ソフトウェアコンポーネント４１−４４の決定とソフトウェアコンポーネント４１〜４４間の通信の特殊化；
ステップ３：ハードウェアネットワークのマイクロコントローラ３１，３２へのソフトウェアコンポーネント４１−４４の対応づけ；
ステップ４：ハードウェアコンポーネントとハードウェア接続Ｋｉ，ｉ＝１，…，１３に基づいて電子システム３０の要求される機能のための信頼性ブロック図４５〜４７を作成；
ステップ５：電子システム（３０）の安全性機能のための信頼性と要求される全機能のための信頼性の計算により安全性と信頼性を立証；
ステップ６：場合によってはステップ１から５を繰り返して，システムアーキテクチャ，すなわちソフトウェアネットワークおよびハードウェアネットワークと，ハードウェアコンポーネントへのソフトウェアコンポーネントの対応づけを補正。
【図面の簡単な説明】
【００７２】
【図１】電子システムの例としてブレーキ−バイ−ワイヤ−システムを概略的に示す説明図である。
【図２】図１に示すシステムに属する信頼性ブロック図を機能「ブレーキ」について示す説明図である。
【図３】信頼性および安全性分析におけるステップのシーケンスと信頼できかつ安全なシステムの仕様書の例を示す説明図である。
【図４】本発明に基づいて安全性と信頼性に関して監視される，分配され，ネットワーク化されたシステムの例として，制御装置のコンポーネントを概略的に示す説明図である。
【図５】図４に示すシステムの機能についての種々の信頼性ブロック図を示す説明図である。
【特許請求の範囲】
【請求項１】
システム（３０）の要求される機能を検査するための信頼性機能を使用して，そのために必要なハードウェアコンポーネントに基づいて，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法において，
システム（３０）の要求される機能の少なくとも１つのものの信頼性を計算するための信頼性機能と，システム（３０）の安全性機能の少なくとも１つのものの信頼性を計算するための信頼性機能が定められ，その場合に前記信頼性機能を定めるために，システムのソフトウェアコンポーネント（４１，４２，４３，４４）が，前記ソフトウェアコンポーネント（４１，４２，４３，４４）が分配されているハードウェアコンポーネントを用いて一緒に考慮されることを特徴とする，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項２】
システム（３０）のすべての要求される機能について，前記信頼性機能が定められることを特徴とする請求項１に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項３】
システムのすべての前記安全性機能について，前記信頼性機能が定められることを特徴とする請求項１または２に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項４】
所定のシステムアーキテクチャについて２つの前記信頼性機能の値が計算されることを特徴とする請求項１〜３のいずれか１項に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項５】
システムアーキテクチャが，
要求されるシステム機能および安全性機能の実現のために必要なハードウェアコンポーネントの決定と；
要求されるシステム機能および安全性機能の実現のために必要なソフトウェアコンポーネントの決定と；
ハードウェアコンポーネントへのソフトウェアコンポーネントの対応づけと；
の構成部分の中の１つまたは複数によって変化されることを特徴とする請求項４に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項６】
システムアーキテクチャが，様々なシステムアーキテクチャにおいて要求されるシステム機能について最大化された，計算された信頼性を用いて，最適化されることを特徴とする請求項４または５に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項７】
システムアーキテクチャが，種々のシステムアーキテクチャにおいてシステムの安全性機能について計算された信頼性の混合を用いて，最適化されることを特徴とする請求項４〜６のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項８】
前記信頼性機能が，信頼性ブロック図を用いて定められることを特徴とする請求項１〜７のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項９】
要求されるシステム機能が，前記システム機能を監視するための監視機能によって監視され，その場合に前記監視機能自体がシステム監視機能によって監視されることを特徴とする請求項１〜８のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１０】
前記システム監視機能が，システム機能を監視するための前記監視機能を含むシステム部分（３１）を，少なくとも部分的に監視することを特徴とする請求項９に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１１】
前記システム監視機能が，２つのシステム部分（３１，３２）に分配され，そのうちの一方のシステム部分（３１）が要求されるシステム機能および前記監視機能を有していることを特徴とする請求項１０に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１２】
２つのシステム部分（３１，３２）が，前記システム監視機能を介して相互に監視することを特徴とする請求項１１に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１３】
システム（３０）の安全性と信頼性を検査するために，
システム（３０）のハードウェアコンポーネントとそのネットワーク化を決定し，特にマイクロコントローラ（３１，３２）とそのネットワーク化を特殊化するステップと；
システム（３０）のシステム機能と安全機能を実現するために必要な，システム（３０）のソフトウェアコンポーネント（４１，４２，４３，４４）を決定し，かつ前記ソフトウェアコンポーネント（４１，４２，４３，４４）間の通信を特殊化するステップと；
前記ソフトウェアコンポーネント（４１，４２，４３，４４）を，ハードウェアコンポーネント，特にシステム（３０）のマイクロコントローラ（３１，３２）へ対応づけるステップと；
前記ハードウェアコンポーネントおよびハードウェア接続に基づいて安全性機能を含めてシステム（３０）の要求される機能について信頼性ブロック図（４５，４６，４７）を作成するステップと；
システム（３０）の安全性と信頼性を立証するために，システム（３０）の安全性についての信頼性と，要求される全機能についての信頼性を計算するステップと；
を含むことを特徴とする請求項１〜１２のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１４】
他のステップとして，システムアーキテクチャ，従ってソフトウェアネットワークおよびハードウェアネットワークと，ハードウェアコンポーネントに対するソフトウェアコンポーネントの対応づけが補正され，請求項１３に示すステップが繰り返されることを特徴とする請求項１３に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１５】
分配され，ネットワーク化されたシステム（３０）内で，マイクロコントローラ（３１，３２）のようなハードウェアコンポーネントにソフトウェアコンポーネント（４１，４２，４３，４４）を対応づけるために，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１６】
エンジン制御装置のような，制御装置（３０）のシステムアーキテクチャを決定するために，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１７】
コンピュータプログラムがコンピュータまたは該当する計算ユニット上で実施された場合に，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法のすべてのステップを実施するために，プログラムコード手段を有するコンピュータプログラム。
【請求項１８】
コンピュータプログラム製品がコンピュータ上または該当する計算ユニット上で実施された場合に，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法のすべてのステップを実施するために，コンピュータ読み取り可能なデータ担体上に記憶されている，プログラムコード手段を有するコンピュータプログラム製品。
【請求項１】
システム（３０）の要求される機能を検査するための信頼性機能を使用して，そのために必要なハードウェアコンポーネントに基づいて，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法において，
システム（３０）の要求される機能の少なくとも１つのものの信頼性を計算するための信頼性機能と，システム（３０）の安全性機能の少なくとも１つのものの信頼性を計算するための信頼性機能が定められ，その場合に前記信頼性機能を定めるために，システムのソフトウェアコンポーネント（４１，４２，４３，４４）が，前記ソフトウェアコンポーネント（４１，４２，４３，４４）が分配されているハードウェアコンポーネントを用いて一緒に考慮されることを特徴とする，ソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項２】
システム（３０）のすべての要求される機能について，前記信頼性機能が定められることを特徴とする請求項１に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項３】
システムのすべての前記安全性機能について，前記信頼性機能が定められることを特徴とする請求項１または２に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項４】
所定のシステムアーキテクチャについて２つの前記信頼性機能の値が計算されることを特徴とする請求項１〜３のいずれか１項に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項５】
システムアーキテクチャが，
要求されるシステム機能および安全性機能の実現のために必要なハードウェアコンポーネントの決定と；
要求されるシステム機能および安全性機能の実現のために必要なソフトウェアコンポーネントの決定と；
ハードウェアコンポーネントへのソフトウェアコンポーネントの対応づけと；
の構成部分の中の１つまたは複数によって変化されることを特徴とする請求項４に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項６】
システムアーキテクチャが，様々なシステムアーキテクチャにおいて要求されるシステム機能について最大化された，計算された信頼性を用いて，最適化されることを特徴とする請求項４または５に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項７】
システムアーキテクチャが，種々のシステムアーキテクチャにおいてシステムの安全性機能について計算された信頼性の混合を用いて，最適化されることを特徴とする請求項４〜６のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項８】
前記信頼性機能が，信頼性ブロック図を用いて定められることを特徴とする請求項１〜７のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項９】
要求されるシステム機能が，前記システム機能を監視するための監視機能によって監視され，その場合に前記監視機能自体がシステム監視機能によって監視されることを特徴とする請求項１〜８のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１０】
前記システム監視機能が，システム機能を監視するための前記監視機能を含むシステム部分（３１）を，少なくとも部分的に監視することを特徴とする請求項９に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１１】
前記システム監視機能が，２つのシステム部分（３１，３２）に分配され，そのうちの一方のシステム部分（３１）が要求されるシステム機能および前記監視機能を有していることを特徴とする請求項１０に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１２】
２つのシステム部分（３１，３２）が，前記システム監視機能を介して相互に監視することを特徴とする請求項１１に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１３】
システム（３０）の安全性と信頼性を検査するために，
システム（３０）のハードウェアコンポーネントとそのネットワーク化を決定し，特にマイクロコントローラ（３１，３２）とそのネットワーク化を特殊化するステップと；
システム（３０）のシステム機能と安全機能を実現するために必要な，システム（３０）のソフトウェアコンポーネント（４１，４２，４３，４４）を決定し，かつ前記ソフトウェアコンポーネント（４１，４２，４３，４４）間の通信を特殊化するステップと；
前記ソフトウェアコンポーネント（４１，４２，４３，４４）を，ハードウェアコンポーネント，特にシステム（３０）のマイクロコントローラ（３１，３２）へ対応づけるステップと；
前記ハードウェアコンポーネントおよびハードウェア接続に基づいて安全性機能を含めてシステム（３０）の要求される機能について信頼性ブロック図（４５，４６，４７）を作成するステップと；
システム（３０）の安全性と信頼性を立証するために，システム（３０）の安全性についての信頼性と，要求される全機能についての信頼性を計算するステップと；
を含むことを特徴とする請求項１〜１２のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１４】
他のステップとして，システムアーキテクチャ，従ってソフトウェアネットワークおよびハードウェアネットワークと，ハードウェアコンポーネントに対するソフトウェアコンポーネントの対応づけが補正され，請求項１３に示すステップが繰り返されることを特徴とする請求項１３に記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１５】
分配され，ネットワーク化されたシステム（３０）内で，マイクロコントローラ（３１，３２）のようなハードウェアコンポーネントにソフトウェアコンポーネント（４１，４２，４３，４４）を対応づけるために，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１６】
エンジン制御装置のような，制御装置（３０）のシステムアーキテクチャを決定するために，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法。
【請求項１７】
コンピュータプログラムがコンピュータまたは該当する計算ユニット上で実施された場合に，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法のすべてのステップを実施するために，プログラムコード手段を有するコンピュータプログラム。
【請求項１８】
コンピュータプログラム製品がコンピュータ上または該当する計算ユニット上で実施された場合に，請求項１〜１４のいずれかに記載のソフトウェアベースの電子システムの安全性と信頼性を検査する方法のすべてのステップを実施するために，コンピュータ読み取り可能なデータ担体上に記憶されている，プログラムコード手段を有するコンピュータプログラム製品。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２００７−５０６５９１（Ｐ２００７−５０６５９１Ａ）
【公表日】平成１９年３月２２日（２００７．３．２２）
【国際特許分類】
【出願番号】特願２００６−５１５２７７（Ｐ２００６−５１５２７７）
【出願日】平成１６年６月２３日（２００４．６．２３）
【国際出願番号】ＰＣＴ／ＤＥ２００４／００１３１７
【国際公開番号】ＷＯ２００５／００３９７２
【国際公開日】平成１７年１月１３日（２００５．１．１３）
【出願人】（５０１１２５２３１）ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング (329)
【Ｆターム（参考）】
【公表日】平成１９年３月２２日（２００７．３．２２）
【国際特許分類】
【出願日】平成１６年６月２３日（２００４．６．２３）
【国際出願番号】ＰＣＴ／ＤＥ２００４／００１３１７
【国際公開番号】ＷＯ２００５／００３９７２
【国際公開日】平成１７年１月１３日（２００５．１．１３）
【出願人】（５０１１２５２３１）ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング (329)
【Ｆターム（参考）】
[ Back to top ]