JP2017527895A - 複数のプロセッサを含む、機能安全を有するアプリケーション用の電子システムにおいてプログラムを実行する方法、対応システム、およびコンピュータプログラム製品 - Google Patents

Abstract

単一プロセッサまたはマルチプロセッサ処理システム、および別の独立制御モジュールを含む、機能安全が設けられるアプリケーション用の電子システムにおいて、プログラム（Ｐ）を実行する方法が開示される。この方法には、プログラム（Ｐ）を複数の並列サブプログラム（Ｐ１〜Ｐｎ）に分解する動作を実行するステップと、各並列サブプログラム（Ｐ１〜Ｐｎ）の実行をシステムの各処理モジュールに割り当てて、前記サブプログラム（Ｐ１〜Ｐｎ）のそれぞれに関連する自己テスト動作（Ａｓｔｌ、Ａｓｙｓ、Ａｃｈｋ）を周期的に実行するステップと、が含まれる。

Description

本開示は、機能安全が要求されるアプリケーション用の電子システムに関連してプログラムを実行する技術に関する。開示される電子システムは、単一プロセッサ（ＣＰＵ）または複数のプロセッサを備えるアーキテクチャに基づく。
開示される技術では、
前記アーキテクチャにより実行されるプログラムを複数の並列サブプログラムに分解する動作を行い、
システムの各処理モジュール、具体的には、前記プロセッサのうちの１つに関連する物理プロセッサまたは仮想マシンに各並列サブプログラムの実行を割り当て、
機能安全目標を満たすよう設計される自己テスト動作を前記アーキテクチャの通常動作中のプログラムのサイクル頻度に従って周期的に実行し得る。

本開示の種々の実施形態は、機能安全に適用可能である。具体的には、本開示の種々の実施形態は、産業用ロボットおよび産業用制御装置の分野の電子システム、および運転手をアシストする自動車用アプリケーション、部分的あるいは完全な自動運転を行う自動車用アプリケーション用の電子システムの技術分野に適用可能である。

ＩＥＣ６１５０８、ＩＳＯ１３８４９、およびＩＳＯ２６２６２などの機能安全規格には、一体型電子システムにおいて潜在的に危険な故障を検知することに関する要求事項も含まれている。例えば、ＩＳＯ２６２６２の規格では、要求事項の１つに、「ＨＷの偶発的な故障に対する確率メトリック（ＰＭＨＦ；ｐｒｏｂａｂｉｌｉｓｔｉｃ ｍｅｔｒｉｃ ｆｏｒ ＨＷ ｒａｎｄｏｍ ｆａｉｌｕｒｅｓ）」という規定があり、所与の故障モデルＦに関する第１の近似値が、ベース故障確率（λ）、故障モデル（ΛＦ）上でのこの確率の分布、安全側故障（１−ｓ）の一部の補数、および非安全側故障（１−ｋ）の自己診断率の補数の積として規定されている。

「安全側故障」とは、電子装置上で実行されるプログラムのミッションが影響を受けない、あるいは、影響を受けたとして大きな問題にはならない、すなわち、機能安全に対する危険がない既知の状態、いわゆる「安全状態」でミッションが完了する故障を意味する。

単一プロセッサまたはマルチプロセッサの処理システム内のプロセッサは、このような一体型電子システムの中でも最も重要な要素であり、これらのプロセッサは当技術分野が進歩すればするほど複雑になる。

これらのプロセッサに関して、上記の規定（例えば、ＩＳＯ２６２６２−５、Ａｎｎｅｘ Ｄ、Ｔａｂｌｅ Ｄ．４）では、非安全側故障のカバレッジのできるだけ高い診断値（ｋにより指定される）を得るために、様々な可能性のある技術が提示されている。

従来の技術では、上記の技術により様々な実装形態が見出されてきた。

例えば、米国特許第６，２３３，７０２号明細書（特許文献１）や米国特許第７，４７２，０５１号明細書（特許文献２）などに記載されるアーキテクチャは、機能安全を保証するために、必ずプロセッサのハードウェアの修正を必要とし、プロセッサの完全冗長性の形態または低冗長性の形態を実装する。

例えば、米国特許第５，５１３，３１９号明細書（特許文献３）に記載されるアーキテクチャでは、独立要素（監視装置）が、予め設定された時間間隔でプロセッサから周期的にクエリを受ける。しかし、このような方法を用いてプロセッサの故障のうちの少ないパーセンテージだけしか検知できなければ、保証可能な機能安全は限られてしまい、これにより、基本的には、プログラムフローに大幅な差が引き起こされる。

米国特許第６，２３３，７０２号明細書 米国特許第７，４７２，０５１号明細書 米国特許第５，５１３，３１９号明細書

本明細書で記載される実施形態の目的は、先程議論した通り、従来技術による方法の潜在能力を伸ばすことである。具体的には、最新マルチプロセッサなどの複雑なアーキテクチャ上で高い自己診断率を実現し、同様に、単一プロセッサに対するカバレッジ目標を制限し、ハードウェアを修正する必要性を制限する、あるいは、取り除くことを可能にする。

種々の実施形態では、添付されている請求項に記載される特徴を有する方法により上記の目的が達成される。種々の実施形態は、アーキテクチャ、さらには、コンピュータプログラム製品にも関し、このコンピュータプログラム製品は、少なくとも１つのコンピュータ（例えば、ネットワーク内の端末）のメモリにインストールすることができ、少なくとも１つのコンピュータ上でプログラムが実行されると、方法のステップを実行するよう設計されるソフトウェアコードの一部を含む。本明細書で使用される場合、上記のコンピュータプログラム製品は、本発明による方法を協働して実行するようコンピュータシステムを制御する命令を含むコンピュータ可読手段と同じものとして理解されよう。「少なくとも１つのコンピュータ」という言及は、モジュール方式および／または分配される形態で実施される本発明の可能性を強調することとして理解されよう。請求項が、本発明に関連して本明細書で提供される技術教示の必須部分を形成する。

種々の実施形態では、自己テスト動作を含む方法が開示され、この自己テスト動作には、
診断型自己テスト動作、すなわち、プロセッサ上でテストを実行し、その結果を設計段階で事前に計算された数値と比較する動作と、
アーキテクチャ上でシステム値（純粋な例として、電圧と温度）を測定し、その結果を予想される基準範囲と比較する自己テスト動作と、
前記サブプログラムの部分結果どうしを比較する動作と、が含まれ、
前記自己テスト動作が、
自己テスト動作に関する各自己テストデータを生成することと、
前記自己テストデータ上でチェック動作を実行することと、
メッセージプロトコルを用いて、別の独立制御モジュールと前記自己テストデータのやり取りを連続して行うことと、
前記別の独立制御モジュール内で前記チェック動作を少なくとも部分的に実行することと、
前記診断型自己テスト動作により決定されるカバレッジ値、アーキテクチャ上で測定されるシステム値の自己テストの動作の所与のカバレッジ値、および前述のサブプログラムの部分結果どうしを比較する動作により決定されるカバレッジ値の関数である故障確率目標に重点を置くために、プログラムを複数の並列サブプログラムに分解する前記動作を実行することと、を含む。

記載されるプログラムの分解の手順と、前述の３つの別々の動作（診断テストによる自己テスト、システム値の監視による自己テスト、中間結果間の比較による自己テスト）に自己テスト動作を分割することにより、既知の技術を改善することができる。具体的には、３分割することで効率的な目標の分配が可能となる。すなわち、実現するために著しい設計の手間、すなわち、ハードウェアの修正を必要とする動作（記載される方法が用いられる特定のタイプのシステムに関して）に関する目標を下げその代り、それに関連して実行が簡単な動作に関する目標を上げる。

次に、下記の添付図面を純粋な例として参照して、種々の実施形態を説明する。

図１は、本明細書に記載される方法を実施するよう構成される、電子システムに関するマルチプロセッサのアーキテクチャの実施形態のブロック図である。 図２は、本明細書に記載される方法で用いられる安全機能を示す図である。 図３は、本明細書に記載される方法を実施するよう構成されるマルチプロセッサのアーキテクチャのソフトウェアレベルを示す図である。 図４は、マルチプロセッサのアーキテクチャにより実施される通信プロトコルにより用いられるパケットを示す図である。 図５は、マルチプロセッサのアーキテクチャにより実施される通信プロトコルにより用いられるパケットを示す図である。 図６は、本明細書に記載される方法を実施するためのマルチプロセッサのアーキテクチャと協働する制御モジュールのブロック図である。 図７は、本明細書に記載されるマルチプロセッサのアーキテクチャにより実行されるテストプログラムの概略図である。 図８は、本明細書に記載される方法の分解動作の論理実装形態の一例を示す論理図である。 図９は、２コアの対称マルチプロセッサを用いる、ＳｏＣ（システム・オン・チップ）上のシステムの実装形態を示す原理図である。

次の説明では、例として提供される実施形態の最大限の理解を可能にするために、非常にたくさんの具体的詳細が盛り込まれている。これらの実施形態は、具体的詳細、あるいは、その他の方法、構成要素、材料などの有無に関わらず実施可能である。実施形態の種々の様態が不明瞭にならないよう、その他の環境では、周知の構造、材料、または動作を詳細に図示、説明していない。本明細書では、「ある実施形態」または「一実施形態」とは、その実装形態に関連して記載される特定の構造、特性、または特徴が少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書の様々な箇所で度々登場する「ある実施形態では」や「一実施形態では」などのフレーズは、必ずしも１つの実施形態および同じ実施形態を指しているわけではない。さらに、特定の構造、特性、または特徴を、都合よく１つ以上の実施形態に組み合わせることも可能である。

本明細書では様々な引用が提供されるが、これらは単に読み手の理解を容易にするためのもので、その実施形態の範囲や趣旨を規定するものではない。

図１には、機能安全が設けられるアプリケーションに関する一体型電子システムにおける、機能安全が設けられる処理アーキテクチャが示されている。前述の通り、この電子システムは、例えば、運転手をアシストし、部分的な、あるいは完全な自動運転を行う自動車用アプリケーション用の電子システムでよく、機能安全で動作する処理アーキテクチャが含まれる。

前述のアーキテクチャは、マルチプロセッサ処理システムを含む。すなわち、全体として参照符号１０で示されるマルチプロセッサ処理システム上に実装されるのは、複数の処理チャネルおよび制御チャネルの提供に基づく機能安全システムである。安全に関連して、具体的にはＩＥＣ６１５０８において、「チャネル」とは、機能安全機能すなわち「安全機能ＳＦ」を独立して実施する要素および要素群を意味する（ＩＥＣ６１５０８−４、３．３．６を参照）。これは、例えば、マイクロプロセッサ、仮想マシン、あるいはその他の要素でよい。

このマルチプロセッサ処理システム１０は、複数のプロセッサモジュール１１を含む。前述のプロセッサモジュール１１は、主として、いわゆる「コア」と呼ばれる独立ＣＰＵを含む。後でより詳細に説明するが、本明細書では、マルチコアシステム内（同様に、単一コアシステム内）のプロセッサモジュールが、前述のコアのうちの１つの上で動作する仮想化ソフトウェアにより生成される仮想マシンを指し得る。図１および図３を参照すると、本明細書では「プロセッサモジュール」１１は、マルチプロセッサ１０内の複数のコアＣ１〜Ｃｍのうちの１つを意味する、あるいは、前述のコアＣ１〜Ｃｍの１つ以上により実装される複数の仮想マシンＶ１〜Ｖｎのうちの１つを意味する。

このマルチプロセッサ１０は、構造上様々な方法で構築することができ、均一なアーキテクチャ（同じ種類の種々の処理コア１１を含むアーキテクチャ）と不均一アーキテクチャ（異なる種類の処理コア１１を含むアーキテクチャ）の両方、およびメッセージをやり取りすることにより通信を行う分配メモリアーキテクチャの共有メモリアーキテクチャを含む。物理実装形態の視点からすると、１つの同じ集積回路にコア１１が供給される高い集積度から異なる集積回路または異なる別々のモジュールにマルチプロセッサ１０のコア１１が供給される低い集積度までの範囲の複数のソリューションも可能である。

これに関連して、前述のマルチプロセッサ１０を１つだけ含み、このマルチプロセッサが、複数のプロセッサモジュール１１を含むアーキテクチャが図１の例として示されている。アプリケーション機能、すなわち、例えば、自動車の運転を制御またはアシストするプログラムＰ、ならびに、システムの保全性の自己テスト、およびマルチプロセッサ１０自体の論理メモリやソリッドステートメモリまたはそれらのサブ部品で発生する可能性のある潜在的故障または機能不良の検知を目指す安全機能ＳＦが、このマルチプロセッサ１０上で動作する。

マルチプロセッサ１０に加えて、図１に示される機能安全が設けられるアーキテクチャは、制御モジュール１５で示される独立処理ユニットを含み、この処理ユニットは、それらの機能安全の監視、および、それらのプログラムを起動させる論理回路で発生する可能性のある、あるいは、より一般的に、各プロセッサモジュール１１で実行可能なようにプログラムＰが分割されるサブプログラムＰ１〜Ｐｎの実行フローで発生する可能性のある全ての潜在的な機能不良の検知を可能にするために、マルチプロセッサ１０のプロセッサ１１により実行される、前述の自己テスト動作を実施するマルチプロセッサ１０内の様々な動作プログラムから送られる監視および制御メッセージＭＣの流れのコンテンツを分析、処理、比較するよう構成される。

マルチプロセッサ１０と制御モジュール１５は、通信手段１２を介して通信し、この通信手段１２により、マルチプロセッサ１０の種々のプロセッサモジュール１１は、前述の監視および制御メッセージＭＣを、処理および比較ユニットに送信したり、処理および比較ユニットから受信したりすることができ、逆に、制御モジュール１５は、例えばアラームなどのメッセージをマルチプロセッサ１０から受信したり、マルチプロセッサ１０に送信したりすることができる。

上記に記載した通り、説明を容易にするために図１では、マルチプロセッサ１０が１つだけ示されているが、実際にはアーキテクチャは、各通信手段１２を通して、制御モジュール１５と、監視および制御メッセージをやり取りする複数のプロセッサまたはマルチプロセッサを含むことができる。

本明細書に記載される方法は、安全機能（図２のＳＦで示される）を実装するマルチプロセッサ１０のこれら全ての潜在的な構成に適用可能である。「安全機能」とは、上述の規格で指定される個々の機能安全の要求事項を必要とするシステムのフレームワークにおいて動作する機能を意味する。実際には、図２には、ソフトウェアの処理で実行される安全機能ＳＦ、およびマルチプロセッサ１０上で実行されるプログラムＰが示されている。図２では、このプログラムＰは（周期的に実行される処理）全体として、サイクル時間Ｔ_ｃｙｃを伴う時間ｔでの周期的な実行を表す環形状で示されている。安全機能ＳＦは、前述のプログラムＰの時間セグメント（すなわち、環形状の扇形）を占有し、この安全機能ＳＦが、通常、プログラムＰの一部を成し、サイクル時間Ｔ_ｃｙｃよりも短い安全実行時間Ｔ_ｓで実行される。また図２には、安全機能ＳＦの実行中（すなわち、安全実行時間Ｔ_ｓ中）、監視および制御メッセージＭＣがどのようにやり取りされるかが示されている（具体的には、独立制御モジュール１５と）。

図１に示される通り、本明細書に記載される方法では、プログラムＰが並列サブプログラムＰ１〜Ｐｎに分解され、図１のアーキテクチャにおいて、これらの並列がそれぞれ、コア１１上で実施される。図１には１つのマルチプロセッサが示されているが、処理システムが、例えば、仮想化技術によりプロセッサを１つだけ提示する場合には、サブプログラムＰ１〜Ｐｎも分割することができる。マルチプロセッサのオペレーティングシステムの領域で利用可能な技術ソリューションは、仮想化技術であり、この技術により、単一コア、すなわち、次に図示される通り、マルチプロセッサ１０のコア１１上で（例えば、いわゆる「ハイパーバイザ」または「仮想マシンモニタ」を参照）、アプリケーションプログラムが実行されるハードウェアを正確に仮想化することが可能となる。仮想化技術を使用するパラダイムによれば、プログラムＰは、並列実行を行うために、仮想マシンＶ１〜Ｖｎ上でそれぞれ実行される複数の並列処理Ｐ１〜Ｐｎに分割される。このことは、安全機能ＳＦを含むプログラムＰを開始することと機能的に同じことである。

種々の仮想マシンまたはコアに割り当てられるサブプログラムＰ１〜Ｐｎへの分解は、特定のプログラムＰの関数に関する関数型を考慮することにより、既知のシステム内で誘導される。後でより詳細に説明する通り、本明細書に記載される方法では、代わりにサブ処理Ｐ１〜Ｐｎに分解する前述の動作を産業用アプリケーションおよび自動車用アプリケーションで用いられる機能安全規格により要求されるランダムなタイプの故障の存在に関するカバレッジの所与の制限の各関数として実行する。したがって、前述の制限は、通常、規格により要求されるカバレッジｋのレベルの関数ｆ（ｋ）として示される。

図１の機能安全アーキテクチャは、図３により詳細に記載される自己テスト動作を安全機能ＳＦのフレームワーク内で実行するようさらに構成され、通常この自己テスト動作には、
図３に示される通り、プロセッサ１１に関連する自己テストライブラリ（ＳＴＬ）５０を実行することにより、診断テストを実行する診断型自己テスト動作Ａ_ｓｔｌと、
好ましくは、自己テストライブラリ（ＳＴＬ）５０を実行することにより実行される、アーキテクチャ上で測定されるシステム値の自己テストの動作Ａ_ｓｙｓと、
図３に示される、アプリケーション比較ソフトウェアモジュール６０により実行されるサブプログラムＰ１〜Ｐｎ間の比較の動作Ａ_ｃｈｋと、が含まれる。

これに関連して、自己テストライブラリ（ＳＴＬ）５０およびアプリケーション比較ソフトウェアモジュール６０が図２に示されており、これらは各コア１１に関連し、３種類の自己テスト動作Ａ_ｓｔｌ、Ａ_ｃｈｋ、Ａ_ｓｙｓをそれぞれ実施する。上記に記載された通り、ＳＴＬ５０は、診断型自己テスト動作Ａ_ｓｔｌを実行するためのソフトウェアとアーキテクチャ上で測定されるシステム値の自己テストの動作Ａ_ｓｙｓを実行するためのソフトウェアの両方を含むことが好ましいが、種々の実施形態では、システム値の自己テストの動作Ａ_ｓｙｓは、分離された専用ソフトウェアモジュールにより実行することができる。

前述の３種類の自己テスト動作Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋには、マルチプロセッサ１０上で、自己テストデータ、すなわち、診断型自己テストデータＤ_ｓｔｌ、システム自己テストデータＤ_ｓｙｓ、アプリケーション自己テストデータＤ_ｃｈｋをそれぞれ生成することが含まれる。上記に記載され図３に詳細に図示される通り、さらに、診断型自己テストライブラリ５０とアプリケーション比較ソフトウェアモジュール６０により示されるソフトウェアモジュールにおいて前述の自己テストデータＤ_ｓｔｌ／Ｄ_ｓｙｓ／Ｄ_ｃｈｋを生成し、監視および制御メッセージＭＣ内で送信し、制御モジュール１５内に含まれる論理モジュール５１、６１として図２に示されるモジュールにより前述の自己テストデータＤ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ上でチェック動作が実行されるようにする。

もう１度、図１を参照すると、通信システム１２が示され、この通信システムが制御モジュール１５とマルチプロセッサ１０を構成するプロセッサモジュールとの間の監視および制御メッセージＭＣのやり取りに用いられる。前述の通信チャネルは、ポイント・トゥ・ポイントタイプのセグメントにより構成され得る、あるいは、通信バス（図示される）などの共有物理媒体へのマルチアクセスを用いて階層的に作成される。やり取りされる監視および制御メッセージＭＣのコンテンツは、後で詳細に説明するその他の動作と伴に自己テスト動作Ａ_ｓｔｌ、Ａ_Ｓｙｓ、Ａ_ｃｈｋを実行することにより決定され、マルチプロセッサ１０を構成するプロセッサモジュール１１が、プログラムＰを分解することにより得られる各アプリケーションプログラムＰ１〜Ｐｎを実行し始める一定の時間間隔で監視および制御メッセージＭＣ自体が送信され、通常それにそれらの時間のほとんどが費やされ、特定のコード、すなわち、自己テストライブラリ５０内のプログラムのコードの実行に割り当てられる。具体的には、監視および制御メッセージＭＣは、マルチプロセッサ１０内で実行されるソフトウェアの異なる階層レベルで生成されるが、これに関しては後でより詳細に説明する。システムのマルチプロセッサ１０と制御モジュール１５との間の監視および制御メッセージＭＣのやり取りは、通信プロトコルＰＬに従って行われるが、これに関しては後でより詳細に説明する。

本明細書に記載される方法の主要様態によると、故障確率目標（通常のケースではｇで示され、以後本明細書で示される２つのプロセッサの例ではｇ１２で示される）に重点を置くためにプログラムＰを複数の並列サブプログラムＰ１〜Ｐｎに分解する動作が開示され、この故障確率目標とは、前述の診断型自己テスト動作Ａ_ｓｔｌにより決定される各カバレッジ値ｋ_ｓｔｌ、マルチプロセッサのアーキテクチャ１０上で測定される数値の自己テストの動作Ａ_ｓｙｓの各所与のカバレッジ値ｋ_ｓｙｓ、およびサブプログラムＰ１〜Ｐｎ間の比較の動作Ａ_ｃｈｋにより決定されるカバレッジ値ｋ_ｃｈｋのサブプログラムＰ１〜Ｐｎごとの関数である。

図１に示される安全アーキテクチャの各構成要素の安全側故障の一部（これに関連して、安全規格ＩＥＣ６１５０８を参照）、および自己診断率（ＤＣ）に関するカバレッジ（具体的には、診断型自己テスト動作Ａ_ｓｔｌ（自己テストライブラリ５０）のソフトウェアプログラムの一部に関する）は、システムの次の特徴の関数として決定される。
安全度のレベル（ＳＩＬ）：システムにより重点を置かれるカバレッジｋの要求事項につながるシステム（具体的には、２チャネルシステム）に関して達成される。
動作のベースサイクル周波数ｆ_ｃｙｃおよび診断テスト間隔（ＤＴＩ）：これに関して、図２に示される通り、サイクル時間Ｔ_ｃｙｃ、およびこれに伴いベースサイクルの周波数ｆ_ｃｙｃでプログラムＰ全体が周期的に実行され、安全機能ＳＦがサイクル時間Ｔ_ｃｙｃよりも短い安全実行時間Ｔ_ｓの前述のプログラムＰの時間セグメントを占有する。
実行されるチェックの数とタイプ：具体的には、考慮されるアーキテクチャ内で、単位時間内の診断型自己テスト動作Ａ_ｓｔｌの結果に基づいて制御モジュール１５により実行され、安全実行時間Ｔ_ｓは、安全規格により要求されるカバレッジｆ（ｋ）の制限の関数である。

さらに、後で詳細に説明する通り、重点を置かれる前述の故障確率目標ｇのさらに別の関数に従って、データ量ｑおよび頻度ｆが選択されるメッセージのシーケンスでデータのやり取りの動作が実行される。

付加的なステップとして、前述の故障確率目標ｇの関数として決定されるカバレッジ目標値ｋが、例えば、本出願人の名前で出願されている欧州特許第１，９８０，９６４Ａ１号明細書によるシミュレーションステップで、故障注入により効率的に実現されたかどうかを確かめるステップを含み得る。

次に、重点を置かれる故障確率目標ｇの関数に従って、プログラムＰを複数の並列サブプログラムＰ１〜Ｐｎに分解する動作を詳しく説明する。

ハードウェアを修正することなく、かつプログラムＰへの影響（プログラムメモリのサイズと実行時間の両方として理解される）を最小限に抑え、最も低い故障確率ｇを得るために、実際に、記載される方法を用いて、このプログラムＰを２つ以上の独立プログラムＰ１、Ｐ２〜Ｐｎに分解することができる。

記載される機能安全を設けたアーキテクチャは、故障確率目標ｇの関数として、したがって、カバレッジｋの値の関数として実現される。次に参照する特定の例は、実質的には、２チャネルシステムを示す。すなわち、プログラムＰが２つの処理Ｐ１とＰ２に分解され、これらの処理Ｐ１とＰ２が、結果として２つのチャネルをもたらす２つのコアＣ１およびＣ２上、あるいは２つの仮想マシンＶ１およびＶ２上で実行されるシステムを示す。

したがって、２つのプログラムＰ１、Ｐ２に分解する動作を例にとり、説明を簡単にするために、１と等しい同じベース故障確率λ、および１と等しい同じ故障モデルΛの分布を有する２つの独立プログラムＰ１、Ｐ２が２つの同一のプロセッサモジュール１１上で実行されると想定すると、プロセッサ１および２で構成されるマルチプロセッサシステムの故障確率は次のように表される。：

なお、ｋ１、ｋ２は、２つのプログラムＰ１とＰ２を実行する２つのプロセッサ、例えば、Ｃ１とＣ２の故障カバレッジ値であり、ｓ１、ｓ２は、それぞれ２つのプログラムＰ１とＰ２を実行する２つのプロセッサＣ１、Ｃ２の安全側故障の一部であり、βは、２つのプロセッサＣ１、Ｃ２間の共通原因故障（ＣＣＦ）を引き起こし得る故障の一部であり、ｋ１２は、２つのプロセッサＣ１、Ｃ２間の共通原因故障を引き起こし得る故障カバレッジ値であり、ｓ１２は、２つのプロセッサＣ１、Ｃ２に共通の安全側故障の一部であり、ｔｅｘｐは、第１の故障の暴露時間である。暴露時間ｔｅｘｐは、システムの使用のタイプおよび故障モデルのタイプにより規定され、究極には、システムのサービス時間を同じでよい。所与のサブプログラムＰｉを考慮し、ベース故障確率λが１と等しく、故障モデルΛの分布が１と等しいと想定すると、一対の数値ｓｉ、ｋｉ（対応プロセッサの安全側故障の一部、および故障カバレッジ値で）により、それらの故障確率がそれぞれ実質的に特定される。

２つの独立サブプログラムＰ１とＰ２の故障確率目標ｇ１２に関して事前に規定された式（１）は、故障の木解析（ＦＴＡ）の演算により決定される（例えば、ＩＳＯ２６２６２−１０、Ａｎｎｅｘ Ｂを参照）。すなわち、各プログラムが、実行される各ハードウェアが非常に低い故障確率に接続するＡＮＤタイプの論理関数により接続される２つのサブプログラムＰ１とＰ２の故障確率の決定に対応する（図８を参照）。したがって、式（１）は、発生する平均故障確率、すなわち、各確率と暴露時間ｔの積としての、故障確率目標の目安を表す。

したがって、任意の数の独立プログラムに関する式（１）は、簡単に拡張することができる。例えば、３つのプログラムを用いる場合、３入力ＡＮＤゲートを２つの２入力ＡＮＤゲートに分解し、上記に記載される２つのプログラムＰ１およびＰ２に関する式を用いて、新しい式を作ることが可能である。

つまり、重点を置かれる故障確率目標ｇに関するサブプログラムＰ１〜Ｐｎの故障確率の数値は、サブプログラムＰ１〜Ｐｎをサブプログラムと同じ数の入力を有するＡＮＤゲートの入力と見なし、前述のＡＮＤゲートを２つの２入力ＡＮＤゲートに分解し、各２入力ＡＮＤゲートの出力での故障確率の積と実行時間との関数として確率目標を計算することにより計算される。

もう一度ＦＴＡ演算を適用し、故障ＣＣＦを考慮して、共通原因項β・（ｌ−ｓｌ２）・（ｌ−ｋｌ２）を合計することにより（すなわち、ＯＲタイプの論理関数）、故障確率ｇ１２が得られる。

したがって、前述の故障確率目標ｇの計算では、サブプログラムＰ１〜ＰｎをサブプログラムＰ１〜Ｐｎと同じ数の入力を有するＡＮＤ論理関数ＡＧの入力と見なし、前述のサブプログラムＰ１〜Ｐｎ間に含まれる対を入力として有する２入力ＡＮＤ論理関数にこのＡＮＤ論理関数（ＡＧ）を分解し、故障確率の積、すなわち、各２入力ＡＮＤゲートの出力での対ｋｉ、ｓｉを計算し、共通原因故障の一部βと暴露時間ｔｅｘｐの補数により、ＯＲ関数を共通原因故障に適用することにより得られる数値、すなわち、共通原因故障の一部βにより乗算されるサブプログラムＰ１〜Ｐｎの全ての対ｉｊ間の対ｋｉｊ、ｓｉｊに加える事前の動作の結果の関数として前述の確率目標ｇを計算する。

図８には、先程説明した論理関数を実施することによる、行われる確率目標ｇの計算の動作が論理回路を介して示されている。参照符号ＡＧで示されているのは、各サブプログラムＰｉ、カバレッジｋｉ、および安全側故障の一部ｓｉを入力（式１の例ではｋ１、ｓ１およびｋ２、ｓ２）として受け取る先程説明された、複数の２入力ゲートに分解可能なｎ入力ＡＮＤゲートである。この出力は、共通原因故障を引き起こし得る故障の一部の補数であるｌ−βで乗算される。ＡＮＤゲート（ＦＴＡ演算で想定される）により、暴露時間との積の計算が可能となる。参照符号ＯＧで示されているのは、共通原因故障カバレッジｋｉｊと共通原因安全側故障の一部ｓｉｊを入力（例ではｋｌ２、ｓｌ２）として受け取る２つのサブプログラムＰｉおよびＰｊに関するマルチ入力ＯＲゲートである。この出力は、共通原因故障を引き起こし得る故障の一部であるβで乗算される。次いで、ゲートＯＧＴは、ゲートＡＧの出力とゲートＯＧの出力の合計を計算して、式（１）の故障目標ｇ１２の一般形式ｇを算出する。

この方法を特徴づける特性の１つは、故障カバレッジ値ｋｌ、ｋ２、およびｋｌ２が、３つの寄与の組み合わせとして規定されることである。：
ｋ_ｓｔｌ、すなわち、診断型自己テスト動作Ａ_ｓｔｌを実行することにより（自己テストライブラリ５０により実行される、具体的には、モジュール１５上に存在するモジュール５１と協働して）保証されるカバレッジの一部。
ｋ_ｃｈｋ、すなわち、プログラムＰ１とＰ２の中間結果の比較を行うことにより、すなわち、自己テスト動作Ａ_ｃｈｋを実行することにより（比較要素６０で実行される、具体的には、制御モジュール１５上に存在するモジュール６１と協働して）、保証されるカバレッジの一部。
ｋ_ｓｙｓ、すなわち、自己テスト動作Ａ_ｓｙｓ（好ましくは、マルチプロセッサ１０のモジュールとモジュール１５のモジュールの間の協働により、プログラムＰ１とＰ２が実行される温度およびプロセッサＣ１、Ｃ２の電圧などのマルチプロセッサのアーキテクチャ１０のシステムパラメータ間、および基準値または限界値、すなわち範囲Ｒ_ａｔｔで実行される）により得られるシステム自己テストデータＤ_ｓｙｓを比較することにより保証されるカバレッジの一部。

具体的には、プログラムＰ１およびＰ２のカバレッジｋｌ、ｋ２、ならびに共通原因のカバレッジｋｌ２は下記の式で表される。：

集合論の規則により、ＵＮＩＯＮ演算子

が、それらの個々の故障カバレッジの関数としての２つのカバレッジを組み合わせる。

プロセッサＣ１上で実行されるプログラム内のライブラリ５０に関連する自己テストライブラリｋ_ｓｔｌ１のカバレッジ目標、プロセッサＣ２上で実行されるプログラム内のライブラリ５０に関連する自己テストライブラリｋ_ｓｔ１２のカバレッジ目標、および、共通原因故障（したがって、構造およびプログラミング）をカバーするためのプロセッサＣ１および／またはプロセッサＣ２上で実行されるプログラム内のライブラリ５０に関連する自己テストライブラリｋ_{ｓｔｌ１２}のカバレッジ目標は、パラメータβ、ｔおよびｓ１、ｓ２、ならびにｓ１２の関数としての故障確率目標ｇ１２を得るために決定される。

したがって、実際には、この方法は、安全アーキテクチャにおいて、カバレッジｋ_ｓｔｌ、ｋ_ｃｈｋ、ｋ_ｓｙｓが関連する３つの異なるタイプの自己テスト動作Ａ_ｓｔｌ、Ａ_ｃｈｋ、Ａ_ｓｙｓと、自己テスト動作Ａ_ｓｔｌまたはＡ_ｃｈｋまたはＡ_ｓｙｓのタイプごとの機能安全においてプログラムＰが分解される所与の数のサブプログラムＰ１〜Ｐｎと、を提供し、カバレッジｋ_ｓｔｌまたはｋ_ｃｈｋまたはｋ_ｓｙｓの新しい数値が、式（１）で表されるものによる他の２つのタイプの自己テスト動作から派生した数値と伴に、そのシステムに関して規定される故障確率目標ｇに重点を置くように、自己テスト動作Ａ_ｓｔｌまたはＡ_ｃｈｋまたはＡ_ｓｙｓのパラメータを規定することにより、前述の自己テスト動作Ａ_ｓｔｌまたはＡ_ｃｈｋまたはＡ_ｓｙｓを各サブプログラムＰ１〜Ｐｎおよび／またはプロセッサ１１に関連付ける。

本明細書に記載される方法のさらに別の様態に従うと、
２つのプロセッサＣ１およびＣ２に関する各自己テストカバレッジｋ_ｓｔｌ１、ｋ_ｓｔｌ２、およびｋ_{ｓｔｌ１２}を用いて規定される自己テストライブラリ５０に基づく前述の診断型自己テスト動作Ａ_ｓｔｌ、
比較カバレッジｋ_ｃｈｋを有するプログラムＰ１およびＰ２の中間結果間（アプリケーション自己テストデータＤ_ｃｈｋ）の比較の動作Ａ_ｃｈｋ、および
プログラムＰ１およびＰ２が実行されるプロセッサＣ１、Ｃ２のシステム自己テストデータＤ_ｓｙｓとシステムカバレッジｋ_ｓｙｓを規定する予想範囲Ｒ_ａｔｔとの間の比較の動作Ａ_ｓｙｓは、
マルチプロセッサ１０内では実行されないが、マルチプロセッサ１０とは独立したさらに別の要素である制御モジュール１５により順序通り実行される。これは、マルチプロセッサ１０と制御モジュール１５との間のデータのやり取り（メッセージＭＣ）により実行される。

比較カバレッジｋ_ｃｈｋは、各比較でやり取りされるデータ量ｑの全体の量に対する関数として、目標時間Ｔに対するデータ交換期間ｔ（その反対がデータ交換頻度ｆ）として決定され、通常、上記の機能安全規格の処理安全時間（ＰＳＴ）または耐故障時間間隔（ＦＴＴＩ）に応じて計算される。

データ交換期間ｔは、安全実行時間Ｔに対応する。

式（１）および式（２）から、カバレッジｋｌ、ｋ２、ｋｌ２は、比較カバレッジｋ_ｃｈｋの値に依存し、故障確率目標は、ｋｌ、ｋ２、ｋｌ２の関数であることが分かる。したがって、故障確率目標ｇを考慮して、やり取りされるデータ量ｑの値およびデータ交換の頻度ｆの値の大きさが決められ、これにより、式（１）および式（２）にその数値が入力されると、故障確率目標ｇに重点が置かれるよう、比較カバレッジｋ_ｃｈｋにより数値が想定されることが分かる。

上記の通り決定される目標値に対するカバレッジｋ_ｓｔｌ１、ｋ_ｓｔｌ２、ｋ_{ｓｔｌ１２}、ｋ_ｃｈｋ、およびｋ_ｓｙｓの対応関係をシミュレーション中に故障注入を行うことによりテストする。

したがって、本明細書に記載される方法では、機能安全が設けられる電子システムに関連して所与のプログラムＰを実行し、プログラムＰをサブプログラムに分解する動作、および故障目標をサブプログラムのカバレッジにリンクさせる関係（式（１））に従って、自己テスト動作を３つの別々の動作、すなわち、診断テストを行う自己テストＡ_ｓｔｌ、システム値を監視する自己テストＡ_ｓｙｓ、中間結果を比較する自己テストＡ_ｃｈｋ、に分割する動作を実行し、これらが、今度は、３つの自己テスト動作Ａ_ｓｔｌ、Ａ_ｃｈｋ、Ａ_ｓｙｓのカバレッジｋ_ｓｔｌ、ｋ_ｃｈｋ、ｋ_ｓｙｓの関数として規定され、３つの自己テスト動作にそれぞれ割り当てられるカバレッジ目標の正確な特定を可能にし、同様に、効率的に目標を分配することを可能にする。

図１に示されるアーキテクチャは、さらに、監視および制御メッセージＭＣをやり取りするための通信プロトコルＰＬを介して外部モジュールおよび制御モジュール１５と協働して前述の自己テスト動作を実行する。前述のモジュールは、プロセッサが設けられる集積回路に含まれ得るが、本明細書では、「外部モジュール」とは、プロセッサ１１の外部のモジュールを意味する。つまり、記載される方法では、１つの同じ単一プロセッサまたはマルチプロセッサの処理システム内で自己テストデータを生成しチェックする既知のシステムで実行される自己テスト動作とは異なり、この自己テスト動作では、単一プロセッサまたはマルチプロセッサ処理システム内に自己テストデータを生成するが、別の独立要素、すなわち制御モジュール１５を介してチェックを実行することにより自己テスト動作を完了する。

上記およびその他の様態をより詳細に説明するために、図３には、本明細書に記載されるＩＳＯ／ＯＳＩタイプのソリューションの実施形態の抽象概念のモデルが、物理層とソフトウェア層の階層を通して、概略的に示されており、これらの層が通信プロトコルＰＬも表している。

前述の通信プロトコルＰＬは階層レベルで実施され、アプリケーション層（図３のＬ４）のメッセージがプログラムＰにより実施されるプロトコルＰＬ内に密封され、下部レベルで（図３の層Ｌ２）、ＳＴＬ５０に関するメッセージが加えられる。図３に示される通り、制御モジュール１５は、前述の階層レベルに対して正反射するように通信プロトコルＰＬを実施する。図６により詳細に示される通り、前述のプロトコルＰＬは、異なるプロセッサモジュール１１の異なる識別子ＩＤに関する異なるパケットを密封可能な階層フレーム内に監視および制御メッセージＭＣを並べ、分析と比較を行うために制御モジュール１５内で事前に並べられた処理ユニットに向けて送信する。次に、参照符号ＶＣで示されているのは、特定のシステム層に対応する論理チャネルであり、参照符号ＩＤで示されているのは、処理要素を参照する物理チャネルに対応する識別子であり、参照符号Ｃ１〜Ｃｍで示されているのは物理コアであり、参照符号Ｖ１〜Ｖｍで示されているのは、仮想マシンである。具体的には、プロトコルＰＬでは、パケットタイプのメッセージＭＣは数値に関して、
それらの属する論理チャネルＶＣの機能としてのメッセージＭＣの階層化専用のフィールドと、
メッセージＭＣのパケットの基本および時間シーケンスのためのフィールドと、
制御モジュール１５のコマンドのフィールドと、
そのデータに対して制御モジュール１５が自己テスト動作を完了しなければならないデータを含むペイロードフィールドと、を含む。

この制御モジュール１５は、エラーの検知および／または修正を可能にするアルゴリズムにより、メッセージＭＣのコンテンツの保全性のチェックを実行するようさらに構成される。アルゴリズムＣＲＣ３２をエラー検知アルゴリズムとして用いることが好ましい（図７ではモジュール１１２ａに実装される）。

図３の物理階層レベルおよびソフトウェア階層レベルの図をさらに詳細に説明すると、参照符号Ｌ１で示されるのは、マルチプロセッサ１０に対応する、ハードウェア用の物理層であり、複数のコアＣ１〜Ｃｍおよび入力／出力モジュールＩＯを含む。これは、通常、１つ以上の集積回路により実装される。

参照符号Ｌ２で示されているのは、仮想マシン１７の管理用のモジュール（通常「ハイパーバイザ」と呼ばれるソフトウェアコンポーネント）により代表されるスーパーバイザ層Ｌ２、であり、このスーパーバイザ層は、独立ユニット（いわゆる「ゲスト仮想マシン」）として使用可能になるよう、仮想化レベルＬ３で対応するオペレーティングシステムでｎ個の仮想マシン管理Ｖ１〜Ｖｎを利用可能にする物理層Ｌ１の既存のハードウェアを仮想化する機能を有する。仮想マシン１７を管理するためのモジュールが、種々の仮想マシンＶ１〜Ｖｎ、および対応するサブプログラムＰ１〜Ｐｎを保証する。これらのサブプログラムが、プログラムＰから、例えば、手動で、分解され、プログラムＰのための必要な所与の特性を有する。あるいは、前述の分解動作は保護されてなくてもよく、アプリケーション自体を修正する、あるいはそのオペレーティングシステムを修正することにより保護されてもよい。機能安全のアプリケーションのフィールドでは、前述の特性には、通常、リアルタイムの実行および異なる処理の実行間の不干渉の保証も含まれる。その代り、前に述べた通り、本明細書に記載される方法では、前述の特性は、故障確率目標ｇだけを考慮する、あるいは故障確率目標ｇも考慮する。一般に、仮想マシンの数ｎは、プログラムＰから分解されるサブ処理Ｐ１〜Ｐｎの数と同じであり、好ましい例では、ｎ＝２である。１つの同じコア上で複数の仮想マシンを得ることができるため、コアの数ｍは、ｎ以下であることが好ましい。

前に述べた通り、本明細書に記載される仮想マシン１７を管理するためのモジュールは、ＳＴＬ５０に対応するソフトウェアコンポーネントを含み、各コアＣ１〜Ｃｍ、およびその下部に位置するハードウェアすなわち物理層Ｌ１を構成する周辺装置の機能の保全性に対するテストを導入して、前述の下部ハードウェア内で発生しカバレッジｋの所定のパーセンテージでランダムなタイプの潜在的な故障を検知することを保証する。同類のマルチプロセッサの場合、ライブラリ５０が１つだけしか存在しない場合もあり得る。ソフトウェアコンポーネント、本明細書ではＳＴＬ５０の構成要素（または非同類のマルチプロセッサの場合、ＳＴＬ５０の複数の構成要素）が、仮想マシン管理１７を管理するためのモジュール内に統合される方式は当業者には既知である。既知の仮想化システムが設けられる、そのようなタイプのモジュール（例えば、ハイパーバイザ）が、通常、付加的な構成要素の統合を可能にするユーザインターフェースに存在する限り、仮想マシン管理１７を管理するためのモジュール内でＳＴＬ５０の構成要素を簡単に統合することができる。したがって、図３に示される通り、ＳＴＬ５０の構成要素を付加的な構成要素として統合することは可能である。

アプリケーション層Ｌ４は、プログラムＰから分解された、仮想マシンＶ１〜Ｖｎ上で実施されるサブプログラムＰ１〜Ｐｎのレベルに対応する。このアプリケーション層Ｌ４に関連するのは、通常、チャネル中間結果間の比較を通してアプリケーション自己テストデータＤ_ｃｈｋを生成する自己テスト動作を実行する、具体的には、アプリケーション比較６０（具体的には「アプリケーション安全層」（ＡＳＬ）と呼ぶ）に関する処理Ｐ１〜Ｐｎごとに１つのソフトウェアモジュールすなわちコンポーネントである。より具体的には、上記に記載した通り、本明細書に記載される方法では、アプリケーション比較ソフトウェアモジュールすなわちコンポーネント６０（具体的には、処理Ｐ１〜Ｐｎごとに１つ）が、アプリケーション自己テストデータＤ_ｃｈｋを取得し、このデータを制御モジュール１５内でチェックし比較する。

図３では、図６で詳細に示されるハードウェアコンポーネントとして制御モジュール１５が示されている。しかし、この制御モジュールは同様にソフトウェアとして実装することもでき、その結果発生するコンポーネントにより、コスト／性能が異なる。純粋な例として、制御モジュール１５をさらに別のプロセッサにより実行されるプログラムとして実装することも可能である。

この制御モジュール１５により、自己テスト動作Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋを完了させるためにやり取りされる監視および制御メッセージＭＣは、次の２つの明確なタイプに分割される。
例えば、マルチプロセッサ１０のコアＣ１〜Ｃｍの電圧および／または温度の測定を含む、アーキテクチャ上で測定されるシステム値を自己テストする動作Ａ_ｓｙｓにより生成されるシステム自己テストデータＤ_ｓｙｓ、および、自己テストライブラリ５０の特定の診断型自己テストの手順の１つに従って行われる計算の中間結果に関する診断型自己テストデータＤ_ｓｔｌなどの、マイクロプロセッサ１０上で実行されるプログラムＰの特性とは関係ないデータを含むメッセージ。
アプリケーション比較ソフトウェアモジュール６０を介するサブプログラムＰ１〜Ｐｎ間の比較動作Ａ_ｃｈｋにより生成されるアプリケーション自己テストデータＤ_ｃｈｋなどの、プログラムＰの処理の中間結果に関するデータを含み、これに伴いプログラムＰまたはアプリケーション自体に依存するメッセージ。

この制御モジュール１５は、制御モジュール１５内に含まれる対応する自己テスト論理構成要素５１およびアプリケーション比較論理構成要素６１を用いて、協働および対応する自己テストデータＤ_ｓｔｌおよびＤ_ｃｈｋを含むメッセージＭＣのやり取りを行って、マルチプロセッサ１０内で開始される自己テスト動作Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋを完了する。図６に示される通り、前述の分割は論理タイプの分割であるが、構成要素５１および６１は、１つのおよび同じセットのハードウェアモジュールにより実施することができる。例えば、これは、次のように行われる。：
制御モジュール１５は、前述の制御モジュール１５内に格納される事前に計算された予想値Ｄ_ｓｔｌａのセットを用いて、自己テストライブラリ５０の特定の診断型自己テストの手順のうちの１つに従って、マルチプロセッサ１０のコアＣ１〜Ｃｍ上で行われる計算の中間結果に関する診断型自己テストデータＤ_ｓｔｌの比較を論理モジュール５１内で行うことにより、診断型自己テスト動作Ａ_ｓｔｌを完了し、潜在的な共通原因故障（ＣＣＦ）を検知し、前述の診断型自己テストデータＤ_ｓｔｌと事前に計算された予想値Ｄ_ｓｔｌａのセットとの間の潜在的な差は、マルチプロセッサ１０のコアＣ１〜Ｃｍの論理回路内またはその状態の故障の影響（恒久的な、あるいは一時的な）を示し、
それと同時に、制御モジュール１５は、事実上、仮想マシンまたはコアのどちらかのプロセッサモジュール１１の対により独立して生成されるアプリケーション自己テストデータＤ_ｃｈｋの論理モジュール６１内で連続して比較を行うことにより、２つの対応する安全チャネル間のクロスチェックの機能を実行し、
同様に、制御モジュール１５内に格納されるシステム自己テストデータＤ_ｓｙｓが予想範囲Ｒ_ａｔｔ内に入るかどうかをチェックすることにより、制御モジュール１５は、アーキテクチャ上で測定されるシステム値の自己テスト動作Ａ_ｓｙｓをチェックと伴に完了する。

この制御モジュール１５は、例えば、比較に関する次の基準に従って、監視および制御メッセージＭＣ上で前述のチェックを行う。：
メッセージＭＣの着信の順番、および、比較に関して考慮されるサイクルに属しているかどうかだけを考慮し、したがって、別の実施形態では考慮されているかもしれないが、個々のメッセージＭＣの着信の絶対時間を考慮しないことが好ましい。
制御モジュール１５は、前に示された通り、２つのプロセッサモジュール１１のそれぞれのシーケンス内の順番を十分に尊重して、異なる供給源、すなわち、異なるプロセッサ要素１１（この場合２つの）からのメッセージＭＣに仲介ができるよう構成される。
制御モジュール１５は、サイクル時間Ｔ_ｃｙｃにより規定される各サイクルのチェックを完了することにより、サイクルベースで独自のチェックを適用する。

次に、自己テストライブラリ５０および補足的論理モジュール５１をより詳細に説明する。

ＳＴＬ５０は、次の２つの機能を有する。：
マルチプロセッサ処理システム１０の診断型自己テスト動作Ａ_ｓｔｌにより示される自己テスト動作を実施する。計算の結果、すなわちマルチプロセッサ１０により、テスト自体が行われるときに処理される診断型自己テストデータＤ_ｓｔｌと、事前に計算され、格納される正確な結果、すなわち予想結果Ｄ_ｓｔｌａとを比較して、この診断型自己テスト動作Ａ_ｓｔｌは実施され、この診断型自己テスト動作Ａ_ｓｔｌに割り当てられたプログラムシーケンスをマルチプロセッサ１０が計算し正確に実行しているどうかをチェックする。マイクロプロセッサ１１の様々な回路要素に最も完全、広範、網羅的に関与するために、この計算結果Ｄ_ｓｔｌは、通常、演算および論理タイプの動作ならびに対応動作のシーケンスから取得される。前に記載された通り、本明細書に記載される方法およびアーキテクチャでは、予想値Ｄ_ｓｔｌａと比較する動作は、外部の処理モジュール、制御モジュール１５との協働により実施される（すなわち、図３の階層表現内のモジュール５０および５１の協働動作を用いて）。
システム自己テストデータＤ_ｓｙｓ、すなわち、各マイクロプロセッサの動作および／または動作の状態に関する全パラメータ、好ましくは、マイクロプロセッサの動作電圧、およびシステムの温度、またはマイクロプロセッサ内部の温度の数値を測定し、この機能は、マイクロプロセッサの潜在的な故障の状況、具体的には、マイクロプロセッサの共通原因故障を判定可能な状況を特定する上で特に重要であり、別のライブラリ内に供給され、論理モジュール５１内の予想範囲Ｒ_ａｔｔに対してチェックされ得ても、前に記載した通り、前述のシステム自己テストデータＤ_ｓｙｓは、ライブラリ５０内に含まれる対応プログラムを介して取得されることが好ましい。

具体的には、診断型自己テストデータＤ_ｓｔｌを供給する診断型自己テスト動作Ａ_ｓｔｌに関して、自己テストコードは、通常、参照符号２０２で示されるテストセグメントのセットで構成されるが、これに関して、図７を参照してさらに詳細に説明する。

この場合、集積回路レベルで、かつ具体的には、個々のコアＣ１〜Ｃｍ、または個々のプロセッサ上で実施される「故障モード影響診断解析」（ＦＭＥＤＡ）タイプの分析目標に従って、マルチプロセッサ処理システム１０のマイクロプロセッサの１つ以上の機能ユニットをテストすることに、前述のテストセグメントが特化していることが好ましい。前述のＦＭＥＤＡは、例えば、本出願人の名前で提出されている欧州特許第１，９８０，９６４Ａｌ号明細書の特許出願に記載される次の手順で実行することができる。各コアＣ１〜ＣｍのＳＴＬ５０を構成するテストセグメントの全体目標は、カバレッジ、特に、自己テストカバレッジｋ_ｓｔｌまたはシステムカバレッジｋ_ｓｙｓのレベルを達成して、具体的には、コアＣ１〜Ｃｍを構成する全体の論理回路上で事前に決定されるカバレッジ制限ｆ（ｋ）を満たすことである。このことは、通常、進んだアーキテクチャ（スーパースカラー、複数の問題タイプの深いパイプラインを有する）を有するマイクロプロセッサにとって非常に難しい課題であり、自己診断を行っているマイクロプロセッサの複雑さが増せば増すほど難しくなる。適用分野に関連する機能安全の規格により、システムおよびシステムの種々の構成要素の保全性に関する最低限の要求事項が規定されている。

したがって、ライブラリ５０を構成する種々のセグメントは、全体として、マイクロプロセッサ全体すなわちコア上で、関連の安全規格で規定されるレベル以上の保全性のレベルを可能にするカバレッジｋ_ｓｔｌの目標値を実現するよう（式１を適用することにより本明細書に記載される計算と同様の計算手順により）設計されなければならない。

診断型自己テストライブラリ５０のプログラムは、通常、テストされるマイクロプロセッサの種々の機能ユニット対する拡張性、およびマイクロプロセッサの各機能ユニット上のより簡単なユニット（テストセグメント２０２）の専門化を実現するために、モジュール式の形態で構築されている。

図７には、これに関連して、参照符号２００で示される自己テストライブラリ５０の自己診断プログラムの概略図が示されている。プログラム２００に含まれるテストセグメント２０２は、周期的かつ定期的にライブラリ５０の自己診断プログラムを起動するソフトウェアのためのインターフェースを供給する「テストインターフェース２０１」と呼ばれるソフトウェア層により、実行されるテストセグメントの識別子ＩＤ＃を示すことにより起動する。テストセグメント２０２は、パス／失敗スタンプを送信することにより回答する。

テストセグメント２０２の構造も、連続するステージによるモジュールタイプで構築され、通常はハイレベル言語（ＡＮＳＩ−Ｃ）で書き込まれる（すなわち、自己テストを受けているマイクロプロセッサのアーキテクチャとは関係ない）プリアンブル２０３およびポストアンブル２０４を含む。これらのプリアンブル２０２とポストアンブル２０４は、全変化を管理するより高い層へのインターフェース機能、およびこれらのソフトウェアモジュールにより処理されるとテスト結果を悪化させる全てのエラーの検知を可能にする技術と伴に管理されるテストの結果に特化する。

テストセグメント２０２の中心部は、一連のモジュール２０６により示される低いレベルコード（通常、アセンブラ）で書き込まれ、「ＡＳＭコアコード」として表されるマイクロプロセッサのアーキテクチャに特化する。これらのモジュール２０６は、マイクロプロセッサ自体の潜在的な故障を発動させて観察するために狙った方法で種々の論理および演算ならびにマイクロプロセッサの一連のユニットに刺激を与える限り、自己テストを効果的に実行する要素である。低いレベルコードの種々のモジュール２０６は、高いレベルの言語で書き込まれるルーチン２０５により管理され得る。このテストセグメント２０２は、モジュール２０５および２０６により、チェックの最後に失敗／パススタンプを生成するスタンプカルキュレータ２０７を含む。テストセグメント２０２は、安全解析により規定される故障モードの所与のセットを考慮して、故障に対するカバレッジ目標を得るための低いレベルのコードの複数のモジュール２０６を含む。

次に、自己テスト解析の分配について、具体的には、プロセッサ１１上のＳＴＬ５０と制御モジュール１５上の論理構成要素５１の間の診断型自己テスト動作Ａ_ｓｔｌについて説明する。

ＳＴＬ５０の動作は、ＳＴＬ５０を構成し中間結果を生成する種々の論理回路の潜在的な寄与ができるだけ多く必要なコードシーケンスなどのコードシーケンスを実行することにより自己をテストする、マイクロプロセッサの能力に基づき、この中間結果が適切に蓄積されて、中間結果内の潜在的なエラーが相殺できないため、故障がないと想定して事前に計算された同じ数値と比較するときに、スタンプを生成し、これにより、テストを受ける論理回路を悪化させているかもしれない潜在的な故障の検知の最も高い信頼を産み出す。故障を発動し検知する能力は、故障を発動させるＳＴＬ５０の能力と、中間結果を蓄積するために用いられる数値法であって、そのためこの蓄積処理中は、中間結果内の全ての潜在的な差が相殺されない数値法と、の両方に依存する。明瞭にするために、様々なタイプの結果、すなわち、中間結果、蓄積、およびスタンプがマイクロプロセッサ内のＳＴＬ５０により作りだされるが、本実施形態によれば、最後の２つは高い頻度で同じである。蓄積は、通常、中間結果の数を減らすために必要であり、そうでない場合には、扱いづらくなる。次に、簡単にするために、この定義では、上記に示した３つの全てのタイプの結果を含む中間結果を参照する。

単一マイクロプロセッサ内の故障の発動の検知は、下記の２つの別々の機構により行われる。
ａ）自己テストソフトウェア自体による検知、この検知により、診断型自己テストデータＤ_ｓｔｌと、事前に計算されたもの、すなわち、予測結果Ｄ_ｓｔｌａとを比較することで差を検知することにより、エラーが判定され、プログラム的に対応手段が適用されて、検知されたエラーが示される。これは故障によりプログラムフローの制御に悪影響を及ぼさないが、データの演算／論理計算の一部だけに悪影響が及ぶ通常の場合である。
ｂ）ＳＴＬ５０のテストを実行することにより得られる、故障の発生に伴う刺激、この刺激により、エラーを通知する外部の監視装置により監視される実行時間ｔ上のテスト極値を破る、プログラムＰの実行シーケンス内のエラーが判定される。これは故障によりプログラムフローの制御の論理責任に悪影響が及ぼされる通常の場合である。なお、この監視装置はシステムの専用要素、あるいは、別のコアでよく、このコアがクロスチェックを実行することにより、考慮されるマイクロプロセッサ上のテスト５０の実行の誤作動または一時的な挙動を検知する。

前述の内容では、図３に示されるＳＴＬ５０は、自己テスト処理あるいは中間結果（または、部分結果、中間結果の蓄積、中間結果と予想値との間の比較の結果）に関するデータを含む診断型自己テストデータＤ_ｓｔｌを生成し、このデータが、外部モジュール、制御モジュール１５に送信され、これらのモジュールが、診断型自己テストデータＤ_ｓｔｌ（機構ａ）とプログラムフローの制御との間のクロス比較を実行する（このように、上記に記載される通りＳＴＬテストの刺激の機構ｂとの関連で外部監視装置の機能を実行する）。

このＳＴＬ５０は、システム構成、すなわち、システム自己テストデータＤ_ｓｙｓを含む測定値をさらに生成する。

ＳＴＬ５０は、マルチプロセッサ１０の物理コアＣ１〜Ｃｍ上で実行され、前述の診断型自己テストデータＤ_ｓｔｌおよびシステム自己テストデータＤ_ｓｙｓを含む、制御モジュール１５への対応メッセージＭＣを生成し、この制御モジュール１５が、論理構成要素５１を用いて前述のメッセージを処理する。

この論理構成要素５１により行われる処理は、次の動作を実行するよう構成される。：
マイクロプロセッサＣ１〜Ｃｍにより行われる比較の結果の実行フローのチェック（チャネル内）を実施すること、および
各マイクロプロセッサＣ１〜Ｃｍ上のライブラリ５０のテストを処理することにより得られる部分結果上でクロスチェック（チャネル間）を実施することの両方により、
診断型自己テストデータＤ_ｓｔｌ上でクロスチェックを実行する動作。
比較の結果すなわち部分結果が、所定の時間窓内に（最大待ち時間と最小待ち時間により特徴づけられる）かつ所定の順番で送受信されているかチェックすることによる、適切な一時実行のチェックを実行する動作。これにより、フローの実行中の潜在的なエラーの検知が可能になるが、前にも示した通り、ＳＴＬ５０のテストの実行フロー中にエラーを検知する機構では、外部構成要素の支援が必要となる。
測定値Ｄ_ｓｙｓが、測定値（一般には、動作電圧と温度）の変動の規定の範囲内に収まっているかどうかのチェックを実行する動作。さらに、テスト５０のライブラリにより取得され、実行中のシステムの状態を示す、システム構成の整合性のチェックも実行することができる。

図６に示される通り、たった今記載したチェックのうちの１つ違反により、制御モジュール１５によるアラームＡＬの生成、および安全のアプリケーションに必要な対応手段の実施が示唆される。前述のアラーム生成機能は、アラームをモジュール１６（システム１０内のシステムリソースを制御するモジュール）に送信し、例えば、リセットを実施することができる、あるいは、システムの安全状態に影響が及ぶ場合は、いつでも供給電圧を取り除くことができる。

自己テストライブラリ５０に関連する動作フローの一例は次の通りである。
ずっと繰り返す｛
スーパーバイザ層上の、または直接各物理コア上のマルチプロセッサ１０上で実行される、自己診断ライブラリの全てのプログラムからデータを受け取る
コア、仮想チャネル、およびタイプに従ってデータを分割し、構成する
ライブラリ５０の各プログラムに対応する中間結果を並べ、対応する中間結果と最大待ち時間の間の最大スキューをチェックする
ライブラリ５０の中間結果間のクロスチェックを実行し、エラーを検知する
異なるコアから測定値を集め、対応する中間結果と最大待ち時間との間の最大スキューをチェックする
その範囲でチェックを実行し、違反を特定する
｝

図６に示される通り、モジュール１１６を参照すると、制御モジュール１５は、数値、順番、時間（待ち時間、スキュー、およびタイムスタンプを用いる絶対着信時間）、および範囲（コンパレータを有するモジュール１１４内の）のマルチチェックを実行する。具体的には、自己テストデータＤ_ｓｔｌ、Ｄ_ｃｈｋ、Ｄ_ｓｙｓに関して次のチェックを行う。
・中間結果が同じものか、あるいは、修正されたものかを確認する、数値のチェック。
・メッセージ内のカウンタよってメッセージの順番が正確かどうかを確認する、順番のチェック。
・進行中の実行サイクル内の予想最小時間および予想最大時間と、かつ／または、他のコアからの対応メッセージと、メッセージの着信の時間とのを比較する、着信時間のチェック。
・測定値が所定の範囲Ｒ_ａｔｔ内に入っているかどうかを確認する、範囲のチェック

各チェックの違反は、制御モジュール１５により管理され、この制御モジュール１５がエラーを通知し、モジュール１６にアラームを送信する。

次に、制御モジュール１５内に存在するアプリケーション比較ソフトウェアコンポーネント６０、および補足的論理モジュール６１についてより詳細に説明する。

したがって、図３に示す通り、仮想マシンＶ１〜Ｖｎ上で実行されるサブプログラムＰ１〜Ｐｎ内に存在するのは、ＡＳＬすなわちサブプログラムＰ１〜Ｐｎの処理の部分結果の検知の手順を実施するアプリケーション比較ソフトウェアコンポーネント６０である。これらのアプリケーション比較ソフトウェアコンポーネント６０はまた、前述の部分結果を蓄積し、安全機能ＳＦを有するプログラムにより蓄積された結果（例えば、ＣＲＣ巡回冗長検査の蓄積）上の差を検知する。前述のアプリケーション比較ソフトウェアコンポーネント６０はまた、同じく本明細書に記載される方法の主題を形成するプロトコルＰＬに従って、蓄積された結果、およびアプリケーションデータＤ_ｃｈｋのフレーム内の差も構成する。

既に述べた通り、アプリケーション比較ソフトウェアコンポーネント６０はまた、対応するアプリケーション比較論理構成要素６１を制御モジュール１５内に有する。アプリケーション自己テストデータＤ_ｃｈｋ上で、制御モジュール１５は、具体的には、アプリケーション比較ソフトウェアコンポーネント６０により生成されるアプリケーション自己テストデータＤ_ｃｈｋのパケット内に出現する、アプリケーション自己テストデータＤ_ｃｈｋの数値、それらの順番、およびクロックタイムに基づいて、情報の整合性をチェックすることにより、クロス比較を実行する。

通信プロトコルＰＬについてさらに詳細に説明する。自己テスト動作Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋの構成では、メッセージを生成したソフトウェア層Ｌ２〜Ｌ４およびメッセージ自体の目的に従って、プロトコルＰＬ内の異なるタイプのメッセージのセットを構成する。

次の論理チャネル仮想チャネルＶＣを規定する。各論理チャネルＶＣにより、ＩＤ０およびＩＤ１により示される多くても２つの異なる物理チャネルから着信するメッセージが運ばれる。
ＶＣ０：安全ＶＣ−アプリケーション層Ｌ４において、安全機能ＳＦを有するプログラムから発生する安全論理チャネル（識別子ＩＤ０およびＩＤ１を有する物理チャネル）。
ＶＣ１：スーパーバイザＶＣ−本実装形態に従った、スーパーバイザ層Ｌ２またはアプリケーション層Ｌ４から発生する論理チャネル（識別子ＩＤ０を有する物理チャネル）。
ＶＣ２：Ｑ＆Ｓ−本実装形態に従った、スーパーバイザ層Ｌ２、または仮想マシンおよびオペレーティングシステム層Ｌ３から発生する、システム上でメンテナンス動作（品質およびサービス）を実行する、品質−および−サービス論理チャネル（識別子ＩＤ０およびＩＤ１を有する物理チャネル）。

２つの物理チャネルを有する好ましい実施形態では、
論理チャネルＶＣ０およびＶＣ２は、２つの物理チャネルＩＤ０およびＩＤ１をサポートするため安全チャネルであり、
論理チャネルＶＣ１は一方の物理チャネルＩＤ０だけをサポートする。

論理チャネルＶＣの前述の規定は制御モジュール１５の特定の特性に反映するため、メッセージの集合の分類ごとにプログラム式チェックおよびアラームを構成することが可能である。

制御モジュール１５の好ましい実施形態では、種々の論理チャネルＶＣの伝達の順番は、例えば、ＶＣ０、ＶＣ１、およびＶＣ２といった具合に、事前に決められ固定されている。図４には、制御モジュール１５の比較論理回路により反映される通信プロトコルＰＬの潜在的な実施形態の例が示されている。具体的に示されているのは、診断テストの間隔ＤＴＩ内で、論理チャネルＶＣ０、ＶＣ１、ＶＣ２、ＤＴＩが通信プロトコルＰＬに従って送信される、通信チャネルである。
物理チャネルＩＤ０、ＩＤ１に関する論理チャネルＶＣ０−このチャネルより安全機能ＳＦのデータ、すなわち、アプリケーション自己テストデータＤ_ｃｈｋが運ばれ、制御モジュール１５の構成要素６１とのこのデータの整合性がテストされ、チャネルＩＤ０およびＩＤ１に属する類似メッセージが互いに比較され、この比較により、正しい結果、すなわち、同じであるが、違いに関して、例えば、符号化が異なるデータが必ず生み出され、実際、データを、共通原因エラーの確率を下げるために、異なる方法で符号化することができる（例えば、チャネル内で補完される）。
物理チャネルＩＤ０に関する論理チャネルＶＣ１−このチャネルにより、スーパーバイザ層Ｌ２から着信する診断型自己テストライブラリ５０の診断型自己テストデータＤ_ｓｔｌが運ばれる。
物理チャネルＩＤ０、ＩＤ１に関する論理チャネルＶＣ２−このチャネルにより、温度、電圧の数値などの計測値、すなわち、システム自己テストデータＤ_ｓｙｓが運ばれる。

もう一度、図４を参照するが、最悪の場合、この伝達が連続して、プログラムＰのサイクル時間と同じサイクル時間Ｔ_ｃｙｃで行われなければならない限り、メッセージ通信チャネルＭＣ上の伝達のトータル時間は、システムの診断テスト間隔ＤＴＩを超えてはならないことに留意されたい。

メッセージのシーケンスＳｑ上で行われる、制御モジュール１５によるチェックを図５の図で説明する。第１の横列内に現われるのは、階層レベルＬ、およびそれに関与する要素、すなわち、プロセッサモジュールＣ１またはＣ２あるいはスーパーバイザモジュール１７のどれかである。識別子ＩＤ０およびＩＤ１でマークされるメッセージＭＣは、メッセージＳｑ（Ｓｑ１およびＳｑ２）の種々のセットに密封され、様々な論理チャネルＶＣ内に含まれる。制御モジュール１５により、これらのメッセージに対して、次の２つのタイプのチェックが行われる。：
チャネル内チェックＩＴＣ（図５には図示されず）、１つで同じ論理チャネルＶＣに属するメッセージ、および１つで同じ識別子ＩＤに属するメッセージに適用されるチェック。
チャネル間チェックＩＮＴＣ、異なる論理チャネルＶＣに属するメッセージＭＣに適応される（例えば、ＩＤ１の第１のメッセージＳｑ１の０，１と比較されるＩＤ０の第１のメッセージＳｑ１の０，０、およびＩＤ１の第２のメッセージＳｑ２，１と比較されるＩＤ０の第２のメッセージＳｑ１の２，０など）チェック。：これらのチャネル間チェックＩＮＴは、各チャネルから着信するメッセージの整合性に関するチャネル内チェックＩＴＣに加えて行われ、チャネル内チェックＩＴＣよりも高いレベルを有する。

図５には、その発生元によってメッセージが示されており、そのメッセージの伝達に用いる一時シーケンスによって示されているわけではないことを強調しなければならない。

図６を参照して説明した通り、記載される通信プロトコルＰＬの構造、およびメッセージのセット上で実行されるチェックにより、制御モジュール１５の機能アーキテクチャをその実装可能なマイクロアーキテクチャに落とす、直接対応を見出すことができる。

前に述べた通り、実装形態は制御モジュール１５に関するソフトウェアタイプと、例えば、ＦＰＧＡディバイスあるいはＡＳＩＣ内の専用論理回路を有するハードウェアタイプと、の両方で実現可能である。

図６には、制御モジュール１５内に統合される主な機能が示されている。

図６に示されるレベルは、専用ハードウェアユニットを反映しているが、ＦＰＧＡディバイスあるいはＡＳＩＣ内の専用ハードウェアとしてではなく、例えば、マルチプロセッサ１０から分離したプロセッサモジュール内の組み込みソフトウェアとしてその実施形態を提供するための機能ユニットも同様に反映することができる。純粋な例として、図９には、システム・オン・チップ（ＳｏＣ）１０００上で提案されるアーキテクチャの潜在的な実装形態が示されている。この実施形態には、具体的には、２コア対称マルチプロセッサを有し、２つのプロセッサ１１が「ハードマクロ」１０１０に含まれ、一方、制御モジュール１５は、ＳｏＣ１０００のプログラム可能部分１０２０（ＦＰＧＡ）に実装される冗長プロセッサ上で実行されるソフトウェアモジュールである。

図６に戻ると、参照符号１１２により示されているのは、通信バス１２に向けられるバスインターフェースであり、構成および状態インターフェースモジュール１１２ｃ、および種々のチャネルＩＤ０およびＩＤ１のメッセージのためのバッファー１１２ｂを含む。このバスインターフェースは、着信するパケット上のＣＲＣタイプのチェックを行うためのモジュール１１２ａをさらに含む。

参照符号１１３で示されているのは、タイミングをチェックする、具体的には、実行時間がチェックに関する極値設定内に残っていることをチェックする、タイミングモジュールである。

参照符号１１４で示されているのは、チャネル間チェック（ＩＮＴＣ動作）を行うためのモジュールであり、このモジュールは、チャネルのデータのチャネル間比較を行うためのコンパレータ１１４ａ、およびハードウェア故障インジェクタ１１４ｂを含む。

参照符号１１６で示されているのは、チャネル内チェック（ＩＴＣ動作）を行うためのモジュールであり、このモジュールは、着信するデータの着信時間、順番、および数値をチェックするモジュール１１６ａ、１１６ｂ、１１６ｃを含む。

メッセージ発信モジュール１１５により、前述のモジュール１１４および１１６にデータが供給されるが、このメッセージ発信モジュールは、直接メモリアクセス（ＤＭＡ）モジュール１１６ａおよびメッセージ制御モジュール１１６ｂを含むことが好ましい。

参照符号１１１で示されているのは、プログラムマブルイベントルータを介してアラームをモジュール１６に送信するエラー制御装置である。モジュール１１４および１１６内の物理チャネルＩＤ０とＩＤ１の間の比較、または数値の予想範囲に対する比較、あるいは事前に計算された結果に対する比較から検知される、異常な条件から派生したデータおよびアラームに関する情報および信号は、基準の安全規格により要求される通り、（論理的、電気的、および物理的視点から）別々に維持される（例えば、ＩＥＣ６１５０８「安全設計勧告」を参照）。再度、図６を参照すると、アラームが点線で示されている。示されるアラーム供給源は、次の比較による異常の検知に関する。：
チャネル間チェックＩＮＴＣ（モジュール１１４）−このタイプの比較には、数値の比較、例えば、マルチプロセッサの異なるコアにより計算されたものと同じと予測される数値の比較、および事前に計算された予想値の比較が含まれ、これらの比較によりチャネル間アラームＡｌｉｎｔｃが生成される。
チャネル内チェックＩＴＣ（モジュール１１６）−このタイプの比較には、事前に計算された予想値との比較、すなわち、所定の基準範囲（例えば、動作温度または動作電圧の範囲）に対するチェックが含まれ、これらの比較によりチャネル内アラームＡｌｉｔｃが生成される。
タイミング上のチェック（モジュール１１３）、例えば、実行時間がチェックに関する極値設定内に残っているかどうかに対するチェック。これらのチェックにより、タイミングアラームＡｌｔが生成される。
考慮されている例における公式な視点からの構造およびメッセージの構成の異常、インターフェース１１２への入力でメッセージのテキスト上でＣＲＣモジュール１１２ａにより行われるＣＲＣタイプのチェックの故障。このチェックにより、アラームＡＬｃが生成される。

最後に、制御モジュール１５は故障注入モジュール１１７を含む。

図６の説明で理解できる通り、論理モジュール５１および６１は別々には実施されないが、各論理モジュールに関して必要な機能は、モジュール１１４、１１６および１１３により基本的に実施される。

したがって、上記の説明から本発明の利点が明らかとなる。

記載される方法およびアーキテクチャは、好都合にも、単一の集積回路上のマルチプロセッサ内で高度に統合されたものであっても、マルチチャネルシステムまたは単一チャネルシステムに関する機能安全の所与の要求事項を満たすことが可能である。

上記のプログラムの分解の手順と、自己テスト動作を３つの別々の動作、すなわち、診断テストによる自己テスト、システム値の監視による自己テスト、および中間結果の比較による自己テストへの分割と、対応する式（１）と、により、３つの自己テスト動作にそれぞれ割り当てられるカバレッジ目標を正確に特定することが可能になり、同様に、効率的な目標の分配、すなわち、実現するために著しい設計の手間を必要とする動作に関する目標を下げ（記載される方法が適用される特定のタイプのシステムに関して）、その代り、それに関連して実行が簡単な動作に関する目標を上げることも可能となる。

さらに記載されるソリューションは、基本的に制御モジュール、すなわち、記載される３つの異なる自己テスト動作を所与の周期すなわち頻度で実行するようプロセッサにより事前に設定された時間間隔で周期的にクエリされる独立電子タイマーモジュールにより示される要素を導入することにより、共通原因故障（ＣＣＦ）の問題を緩和することができる。

具体的には、上記のことは、次の自己テスト動作を実行することにより実現する：
所定の時間窓内の事象の発生のチェックを課し、既定のシーケンスに重点を置き、前述の診断型自己テスト動作に対応する、プロセッサにより決定される、すなわち、いずれにしても計算される数値に対するチェックを行うことによる、一時タイプと数値およびシーケンスタイプの両方のチェック機能。
プロセッサにより計算された数値、あるいは、プロセッサ内、または、通常は、マルチプロセッサ内の使用可能なセンサにより測定された数値をシステム値の自己テストの前述の動作に対応する事前に計算された正確な値と比較することによる、プロセッサ内のＣＣＦの発生の検知。
プログラムの中間結果の自己テストの前述の動作に対応する、クロスチェックに基づくプロセッサの保全性を判定するための、プロトコルの実装形態。

これに関連して、マルチプロセッサの高度に統合された均一な実施形態が、いかに、システムの最も高い性能と最も低いコストを保証するものであるかということと、しかし同時に、アーキテクチャが、より均一で高度に統合されればされるほど、防ぐこと、および／または、検知することがより重要で、難しくなるＣＣＦの問題に対して脆弱であることが強調される。得られるはずの経済的恩恵がなくなってしまうにもかかわらず、ＣＣＦが存在するために、構造的かつ実装可能なソリューションのこのタイプが、自動車分野および産業分野の安全規格に従属するアプリケーションの世界で広く用いられていない。

記載されるソリューションにより、仮想マシン管理（例えば、ハイパーバイザ）の制御ソフトウェアと、前述の自己テスト動作を実施する専用ソフトウェアプログラムとを組み合わせることができ、それらの共同使用により、産業用アプリケーションおよび自動車用アプリケーションにおいて要求される機能安全の保全性のレベルを実現するために必要な要求事項を満たすこともできる。

さらに、記載されている方法およびアーキテクチャにより、具体的には、コア間のクロスチェックに関するサポートを有するマルチコアシステムに関して、理論および一時的な監視が可能になる。
１ｏｏ１ボーティングを有するアーキテクチャと、ｌｏｏ２ボーティングを有するアーキテクチャの両方に関する診断を実施、
マルチコアのハードウェアに関する情報（状態、温度、供給状態など）の監視、
自己監視、
ＳＩＬ−２システムとＳＩＬ−３システム内に統合され得るＩＥＣ６１５０８−２の規格に準拠するシステム、
ソフトウェアと伴に用いられる標準インターフェース、
構成可能な反応、
選択される実装形態の技術（ＦＰＧＡまたはＡＳＩＣ）の最適化の可能性。

もちろん、本発明の趣旨に何ら影響を与えることなく、純粋な例として本明細書に記載される実施形態に対して、これらの実施形態の詳細は変化する可能性があり、それにより付随する請求項により規定され保護される領域から逸脱することはない。

例として見なす安全アーキテクチャでは、制御モジュール１５は、ボータモジュールに関連することができ、このボータモジュールが、一般に、マルチチャネルアーキテクチャにおいて、プログラムまたはアクチュエータにより用いられる前のチャネルの出力を連続的に比較し、ボーティング技術に従って、プログラムに供給される安全出力を評価するために用いられる。ＯＲゲートは、制御モジュール１５の出力、およびボータの出力を受け取り、これらの出力間の潜在的な差を検知することができる。差を検知することにより、故障の検知の状態を判定し、この状態により、実行されているプログラムに関して規定された安全状態に達するよう、あるいは、維持するようシステムを強制する。

「ライブラリ」という用語は、本明細書では自己診断テストプログラムのソフトウェアモジュールを規定するために使用されているが、システムデータ（前に記載した通り、診断型自己テストライブラリ内に含まれ得る）の自己テストを行うためのモジュール、およびサブプログラムの中間結果間を比較するための自己テストモジュールにも適用可能である。

自己テストプログラムを含む前述のライブラリすなわちソフトウェアモジュールは、例えば、処理システムを含む、カード上で使用可能な、あるいは統合型のフラッシュメモリに格納され得、処理モジュールのＲＡＭにロードされる。

本明細書に記載される方法では、処理システム、具体的には、マルチプロセッサシステム、および制御モジュールに言及しているが、それら自体のサブプログラムに分解する動作も、独立制御モジュールなしに、処理システムに適用される。すなわち、本開示の主題は、単一のプロセッサまたはマルチプロセッサタイプの処理システムを含む機能安全が設けられるアプリケーション用の電子システム内のプログラムを実行する方法でもあり、この方法には、安全機能を含み、前述のシステムにより実行されるプログラムを複数の並列サブプログラムに分解する動作を実行するステップと、各並列サブプログラムの実行をシステムの各処理モジュール、具体的には、前述のマルチプロセッサのアーキテクチャのプロセッサ、または前述のプロセッサのうちの１つに関連する仮想マシンに割り当てるステップと、システム内で、システムの通常動作中のプログラムのサイクル頻度に従って周期的に、前述の安全機能のフレームワーク内で各前述のサブプログラムおよびそれらが実行される、対応処理モジュールに関連する自己テスト動作を実行するステップと、が含まれ、上記の自己テスト動作には、診断型自己テストを実行する診断型自己テスト動作と、測定されるシステム値の自己テストの動作と、サブプログラムの中間結果間の比較の自己テスト動作と、が含まれ、これらの自己テスト動作が、その自己テスト動作に対応する各自己テストデータを生成することと、これらの自己テストデータのチェックの動作を実行することと、プログラムを複数の並列サブプログラムに分解する前述の動作を実行し、所与の故障確率目標に重点を置くよう、各サブプログラムまたは処理モジュールに関連する前述の自己テスト動作ごとにカバレッジ目標を得ることと、を含む。

Claims (12)

1. 単一プロセッサまたはマルチプロセッサ処理システム（１０）、および別の独立制御モジュール（１５）を含む、機能安全が設けられるアプリケーション用の電子システム内のプログラム（Ｐ）を実行する方法であって、
   安全機能（ＳＦ）を含み、前記システム（１０）により実行されるプログラム（Ｐ）を複数の並列サブプログラム（Ｐ１〜Ｐｎ）に分解する動作を実行するステップと、
   各並列サブプログラム（Ｐ１〜Ｐｎ）の実行を前記システムの各処理モジュール（１１）、具体的には、前記マルチプロセッサのアーキテクチャ（１０）のプロセッサ（Ｃ１〜Ｃｍ）、または前記プロセッサ（Ｃ１〜Ｃｍ）のうちの１つに関連する仮想マシン（Ｖ１〜Ｖｎ）に割り当てるステップと、
   前記システム（１０）において、前記システム（１０）の通常動作中の前記プログラム（Ｐ）のサイクル頻度（ｆ_ｃｙｃ）に従って周期的に前記安全機能（ＳＦ）のフレームワーク内で、前記各サブプログラム（Ｐ１〜Ｐｎ）、およびそれらが実行される前記対応処理モジュール（１１）に関連する自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）を実行するステップと、を含み、
   前記方法が、前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）には、
   診断型自己テストを実行する診断型自己テスト動作（Ａ_ｓｔｌ）と、
   測定されるシステム値の自己テストの動作（Ａ_ｓｙｓ）と、
   前記サブプログラム（Ｐ１〜Ｐｎ）の中間結果間の比較の自己テスト動作（Ａ_ｃｈｋ）と、が含まれることを特徴とし、
   前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）が、
   前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）に対応する各自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ）を生成し、前記自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ）上でチェック動作（５１、６１）を実行することと、
   前記別の独立制御モジュール（１５）とメッセージ（ＭＣ）のプロトコル（ＰＬ）を介して前記自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ）を連続してやり取りすることと、
   前記さらに別の制御モジュール（１５）内で前記チェック動作（５１、６１）の少なくとも一部を実行することと、
   前記プログラム（Ｐ）を複数の並列サブプログラム（Ｐ１〜Ｐｎ）に分解する動作を実行して、所与の故障確率目標（ｇ１２；ｇ）に重点を置くよう、各サブプログラム（Ｐ１〜Ｐｎ）すなわち処理モジュール（１１）に関連する前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）ごとのカバレッジ目標（ｋ_ｓｔｌ、ｋ_ｓｙｓ、ｋ_ｃｈｋ）を得ることと、を含む、方法。
2. 前記所与の故障確率目標（ｇ１２；ｇ）が、前記診断型自己テスト動作（Ａ_ｓｔｌ）により決定されるカバレッジ値（ｋ_ｓｔｌ）、前記処理システム（１０）上で測定されるシステム値の自己テストの前記動作（Ａ_ｓｙｓ）により決定されるカバレッジ値（ｋ_ｓｙｓ）、および前記サブプログラム（Ｐ１〜Ｐｎ）の中間結果間の比較の前記動作（Ａ_ｃｈｋ）により決定されるカバレッジ値（ｋ_ｃｈｋ）の関数であることを特徴とする、請求項１に記載の方法。
3. 前記故障確率目標（ｇ１２；ｇ）の計算には、
   前記サブプログラム（Ｐ１〜Ｐｎ）と同じ数の入力を有するＡＮＤ論理関数（ＡＧ）の入力として前記サブプログラム（Ｐ１〜Ｐｎ）を見なすことと、
   前記ＡＮＤ論理関数（ＡＧ）を前記サブプログラム（Ｐ１〜Ｐｎ）間に構成される対を入力として有する２入力ＡＮＤ論理関数に分解し、前記共通原因故障の一部（β）の補数による各２入力ＡＮＤゲートからの出力での前記故障確率と前記暴露時間（ｔｅｘｐ）の積を計算することと、
   共通原因故障の一部（β）で乗算される、サブプログラム（Ｐ１〜Ｐｎ）の対の間の共通原因故障にＯＲ関数を適用することにより得られる値に加えられる前記先行動作の結果の関数として前記確率目標（ｇ）を計算することと、が含まれることを特徴とする、請求項１に記載の方法。
4. 前記サブプログラム（Ｐ１〜Ｐｎ）の前記故障確率が、サブプログラム（Ｐ１〜Ｐｎ）ごとの前記診断型自己テスト動作（Ａ_ｓｔｌ）により決定される前記カバレッジ値（ｋ_ｓｔｌ）、前記アーキテクチャ（１０）上で測定されるシステム値の自己テストの前記動作（Ａ_ｓｙｓ）により決定される前記カバレッジ値（ｋ_ｓｙｓ）、および前記サブプログラム（Ｐ１〜Ｐｎ）の前記中間結果間の比較の前記自己テスト動作（Ａ_ｃｈｋ）により決定される前記カバレッジ値（ｋ_ｃｈｋ）のユニオンの関数として評価されることを特徴とする、請求項１〜３のいずれかに記載の方法。
5. 前記システム（１０）が、前記サブプログラム（Ｐ１〜Ｐｎ）を実行可能な仮想マシン（Ｖ１〜Ｖｎ）を生成する仮想マシン管理モジュール（１７）を実装することを特徴とする、先行する請求項のいずれかに記載の方法。
6. 前記さらに別の制御モジュール（１５）において前記チェック動作（５１、６１）の少なくとも一部を実行する前記動作には、
   事前に計算され格納される予想値（Ｄ_ｓｔｌａ）のセットを用いて行われる前記診断型自己テスト動作（Ｄ_ｓｔｌ）に従って、単一プロセッサまたはマルチプロセッサタイプの前記処理システム（１０）の前記プロセッサ（Ｃ１〜Ｃｍ）上で行われる計算の中間結果に対応する診断型自己テストデータ（Ｄ_ｓｔｌ）の前記比較を実行することと、
   前記サブプログラム（Ｐ１〜Ｐｎ）の前記中間結果間の比較の動作（Ａ_ｃｈｋ）により生成されるアプリケーション自己テストデータ（Ｄ_ｃｈｋ）の前記比較を実行することと、
   格納されている予想範囲（Ｒ_ａｔｔ）に対するシステム自己テストデータ（Ｄ_ｓｙｓ）の前記比較を実行することと、が含まれることを特徴とする、先行する請求項のいずれかに記載の方法。
7. 前記さらに別の制御モジュール（１５）が、前記自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｃｈｋ、Ｄ_ｓｙｓ）上で、
   前記中間結果、具体的には、前記アプリケーション自己テストデータ（Ｄ_ｃｈｋ）および／または診断型自己テストデータ（Ｄ_ｓｔｌ）が同じか、修正されたかを確認するための前記数値のチェックと、
   前記システム上で測定される自己テストデータ（Ｄ_ｓｙｓ）の値が所定の値（Ｒ_ａｔｔ）の範囲に属しているかどうかを確認するための前記数値の範囲のチェックと、
   前記メッセージの順番が正確かどうか確認するための前記順番のチェックと、
   前記メッセージの着信の時間のチェックと、を実行するよう構成されることを特徴とする、先行する請求項に記載の方法。
8. メッセージ（ＭＣ）のプロトコル（ＰＬ）を介して、前記別の独立制御モジュール（１５）と前記自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ）を連続してやり取りをする前記動作には、前記メッセージ（ＭＣ）を生成する階層レベル（Ｌ）および前記メッセージ（ＭＣ）を生成する物理チャネル（ＩＤ０、ＩＤ１）に従って、論理チャネル（ＶＣ）内で前記メッセージ（ＭＣ）を構成することが含まれることを特徴とする、先行する請求項のいずれかに記載の方法。
9. 前記さらに別の制御モジュール（１５）において、前記チェック動作（５１、６１）の少なくとも一部を実行する前記動作には、
   １つで同じ論理チャネル（ＶＣ）および１つで同じ物理チャネル（ＩＤ）に属するメッセージに適用されるチャネル内チェック（ＩＴＣ）の動作、および
   異なる論理チャネル（ＶＣ）に属するメッセージ（ＭＣ）に適用されるチャネル間チェック（ＩＮＴＣ）の動作を実行することが含まれることを特徴とする、請求項８に記載の方法。
10. 単一プロセッサまたはマルチプロセッサタイプの処理システム（１０）を含む、機能安全が設けられるアプリケーション用の電子システムにおいてプログラム（Ｐ）を実行する方法であって、
    安全機能（ＳＦ）を含み、前記システム（１０）により実行されるプログラム（Ｐ）を複数の並列サブプログラム（Ｐ１〜Ｐｎ）に分解する動作を実行するステップと、
    各並列サブプログラム（Ｐ１〜Ｐｎ）の実行を前記システムの各処理モジュール（１１）、具体的には、前記マルチプロセッサのアーキテクチャ（１０）のプロセッサ（Ｃ１〜Ｃｍ）または前記プロセッサ（Ｃ１〜Ｃｍ）のうちの１つに関連する仮想マシン（Ｖ１〜Ｖｎ）に割り当てるステップと、
    前記システム（１０）内において、前記システム（１０）の通常動作中の前記プログラム（Ｐ）のサイクル頻度（ｆ_ｃｙｃ）に従って周期的に前記安全機能（ＳＦ）のフレームワーク内で、前記各サブプログラム（Ｐ１〜Ｐｎ）、およびそれらが実行される前記対応処理モジュール（１１）に関連する自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）を実行するステップと、を含み、
    前記方法が、前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）には、
    診断型自己テストを実行する診断型自己テスト動作（Ａ_ｓｔｌ）と、
    測定されるシステム値の自己テストの動作（Ａ_ｓｙｓ）と、
    前記サブプログラム（Ｐ１〜Ｐｎ）の中間結果間の比較（６０）の自己テスト動作（Ａ_ｃｈｋ）と、が含まれることを特徴とし、
    前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）が、
    前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）に対応する各自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ）を生成し、前記自己テストデータ（Ｄ_ｓｔｌ、Ｄ_ｓｙｓ、Ｄ_ｃｈｋ）上でチェック動作（５１、６１）を実行することと、
    前記プログラム（Ｐ）を複数の並列サブプログラム（Ｐ１〜Ｐｎ）に分解する動作を実行して、所与の故障確率目標（ｇ１２；ｇ）に重点を置くよう、各サブプログラム（Ｐ１〜Ｐｎ）すなわち処理モジュール（１１）に関連する前記自己テスト動作（Ａ_ｓｔｌ、Ａ_ｓｙｓ、Ａ_ｃｈｋ）ごとのカバレッジ目標（ｋ_ｓｔｌ、ｋ_ｓｙｓ、ｋ_ｃｈｋ）を得ることと、を含む、方法。
11. 請求項１〜９のいずれかに記載の方法のステップを実施するよう構成される、単一プロセッサまたはマルチプロセッサタイプの処理システム（１０）、および別の独立制御モジュール（１５）を含む、機能安全が設けられる電子システム。
12. 少なくとも１つのコンピュータのメモリにロードできるコンピュータプログラム製品であって、少なくとも１つのコンピュータ上で前記プログラムが実行されると、請求項１〜１０のいずれかに記載の方法のステップを実施するよう設計されるソフトウェアコードの一部を含む、コンピュータプログラム製品。

Images