安全性重視システムの設計方法
【課題】安全性重視システムの設計とベリファイのための改良された方法を提供すること。
【解決手段】一組の望ましくないイベントを識別し、該イベントに、それぞれの深刻度の指標を付け、システム・アーキテクチャのインプリメンテーションのための最初のアーキテクチャの機能仕様を開発し、前記機能仕様において、該イベントの深刻度に結びつけて考えられたフォールト・トレランスの要求条件を洗練し、洗練されたフォールト・トレランスの要求条件を発信し、前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出し、システム・アーキテクチャのハードウエア構造を限定し、前記機能仕様を前記ハードウエア構造の上に写像し、前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイすることを特徴とする、システム・アーキテクチャを生み出す方法。
【解決手段】一組の望ましくないイベントを識別し、該イベントに、それぞれの深刻度の指標を付け、システム・アーキテクチャのインプリメンテーションのための最初のアーキテクチャの機能仕様を開発し、前記機能仕様において、該イベントの深刻度に結びつけて考えられたフォールト・トレランスの要求条件を洗練し、洗練されたフォールト・トレランスの要求条件を発信し、前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出し、システム・アーキテクチャのハードウエア構造を限定し、前記機能仕様を前記ハードウエア構造の上に写像し、前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイすることを特徴とする、システム・アーキテクチャを生み出す方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は安全性重視システムの設計方法に関し、特に、安全性重視システム(safety crytical system)の設計とベリファイすること(verification)のための方法と技術的補助手段に関する。
【背景技術】
【０００２】
多くのフォールト・トレラント(fault tolerant)なシステムが、今までに、汎用のプロパティが検証されインストールされている、いわゆる、フォールト・トレラント・フレームワーク上に構築されている。そのようなフレームワークは、原子力プラント、車両あるいは航空機の制御の基礎となりうるであろう。
【０００３】
そのようなフレームワークは、規模拡大可能(scalable)でも柔軟(flexible)でもなく、非常に高価なものであり、その理由は、そのようなフレームワークは高レベルのハードウエア冗長度(redundancy)を頼りとし、ハードウエアの前提条件、たとえば、専用のバス・ドライバあるいは他の構成要素、（特に、既存ソフトウエアを搭載したベリファイ(verify)済みのマイクロコントローラ）が有ること、を満足しなければならないことにある。そのようなフレームワークは、コスト最適化が主要課題となる、長い工程を持つ生産には適用されない。
【０００４】
バーチャル・プロトタイプの作成(virtual prototyping)を実現させる試みがなされつつあり、その一例として、下記非特許文献６に、タイム・トリガード・アーキテクチャのためのシステム・エンジニアリングが引用されている。
【０００５】
タイム・トリガード・プロトコル(time-triggered protocol (ＴＴＰ))のフレームワーク（下記非特許文献４参照）は、内蔵型エレクトロニクスへの応用のために構築された安全性フレームワークの良い例である。それは、ある程度、柔軟性と規模拡大可能性(scalability)の要求に応えるものであるが、ただしそれは、ノード間の通信のレベルにおいてである。
【０００６】
上記の全ての例には、一つの共通点がある。それは、一般的な安全性重視フレームワークが設定され、その応用の設計は、そのフレームワーク内において、そのフレームワークに固有の規則に従って作成されなければならないということである。安全性の立証はフレームワーク全体に対して得られるのであって、特定のフレームワークに対して得られるのでなない。たとえば、上記ＴＴＰフレームワークにおいて、システムの「正常」な動作のために少なくとも４個のノードが要求され、相異なったＴＴＰノードにおけるプロセスの４つのインスタンスの写像(mapping)が、そのプロセスの利用者に、プロセスの結果が適宜利用可能であり正確であることを保証する。このアイディアは、物理的アーキテクチャのための一般的な立証手段が存在し、この立証手段が、安全性のデータフローにおける多くのインスタンスと、システムに内蔵されている機能とに応じて特定化しているということである。
【０００７】
他のアイディアを挙げるならば、その中において安全性重視フレームワーク、ＳＩＦＴ、が設計されているプロジェクトが下記非特許文献３に引用されている。
【０００８】
このＳＩＦＴプロジェクトにおいては、いくつかの独立な計算チャネルが有り、その計算チャネルは、近似的に同期して動作する、それぞれに専用のプロセッサを持ち；センサのような単一発信源からのデータは各チャネルに、ビザンチン（すなわち、非同期）故障(Byzantine (i.e. asynchronous) faults)に強い形で配信され、それによって、良好なチャネルは正確に同一の入力データを得；すべてのチャネルは同じアプリケーションのタスクを同じデータに基づいて近似的に同時に実行し、その結果は、アクチュエータに送られる前に、正確一致多数票決(exact-match majority voting)に送られる。
【０００９】
これは安全性重視フレームワークの良い説明例である。しかしながら、上記刊行物の後の方の節には、応用がまったく言及されていないこと注意されたい。このフレームワークは、原子力プラント、スペースシャトル、またはコーヒー・マシンにまで使うことができるように見える。そこで、たとえ、このＳＩＦＴフレームワークがフライト制御システムをサポートするために構築されたとしても、設計者は、その上で、彼らの、固定された複製、通信および票決規則に従う安全性重視アプリケーションを設計することができるような「良好な」安全性プロパティを備えた安全性重視フレームワークを設計することを望むであろう。
【００１０】
下記非特許文献５に記載された解析方法が議論されている。特定の故障の実際の影響が安全性の観点から回路の機能への影響に関連して考慮され、その深刻度(severity)の指標(indicator)が付される。一度指定された深刻度の指標は固定される。
【００１１】
従って、安全性重視システムを設計しベリファイする改良された方法の継続的な必要性があることが判り、そのような方法はそのシステムにおけるハードウエア・アーキテクチャの最適化を可能とする。
【非特許文献１】"Advanced Design and ValidationTechniques for ElectronicControl Units", Max Fuchs et al, SAE, 1998 SAE paper 980199 オンラインで入手可能：www4.informamatik.tu-muenchen.de/publ/papers/FEMPS98.pdf
【非特許文献２】"State charts: A Visual Formalism For Complex Systems", David Harel, Sciece of Computer Programming 8, Elsevier Science Publisher B. V (North Holland), 1987
【非特許文献３】"Formal Methods and Their Role in the Certification of Critical Systems", John Rushby, Technicalreport CSL-95-1, Computer Science Laboratory, SRI International, Menlo Park, CA, 1995
【非特許文献４】"The SystematicDesign of Embedded Real-Time Systems", H. Kopetz, Lecture notes, Hermann Kopetz, 1996; また "Real Time Systems: Design Principles for Distributed Embedded Applications", H. Kopetz, publishedby Kluwer Academic,1997
【非特許文献５】"IEC 61508: Functional safety of electrical/electronic/programmable electronicsafety-related systems", International Electrotechnical Commission (IEC), 1998
【非特許文献６】"System Engineering for Time TriggeredArchitectures",(SETTA).DeliverableD7.3 Final Document,version 1.0", XP-002264808, 18 April 2002.これは URL を経由して見られる: "http:www.setta.org"
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、安全性重視システム(safety crytical system)の設計とベリファイすること(verification)のための改良された方法と技術的補助手段とを提供することであり、特に、互いに接続された複数の電気デバイスのためのシステムのアーキテクチャを製作する改良された方法を提供することである。
【課題を解決するための手段】
【００１３】
本発明は、互いに接続された複数の電気装置からなるシステムのアーキテクチャを製作する方法を提供し、前記システムは、望ましくは、フォールト・トレラント(fault tolerant)なシステムからなり、
前記方法は、
a)一組の望ましくないイベントを識別(identify)し、前記望ましくないイベントのそれぞれに、それぞれの深刻度(severity)の指標(indicator)を付ける(ascribe)ことを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考える(associate with)ことを含み、
c)前記アーキテクチャのインプリメンテーション(implementation)のために提案された最初のアーキテクチャの機能仕様(functional specification)を開発する(develop)ことを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフロー(dataflow)と該構成要素間のデータフローとを含み、前記構成要素は、例として、センサまたはアクチュエータを含み、
前記方法は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられた(associated with)フォールト・トレランス(fault tolerance)の要求条件を洗練(refine)し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信すること(issuing)を含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記方法は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定する(define)ことを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像(mapping)することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイ(verify)することを含む。
【００１４】
フォールト・トレランス要求仕様を洗練する(refine)ことは、本発明によって提供される優位性に、特に、それがシステムのアーキテクチャの設計とベリファイのための規模拡大可能な(scalable)プロセスである場合に、貢献する。
【００１５】
この方法は、望ましくはステップ(c)において、一連のオペレーションのモード、たとえばノミナル(nominal)・モードとリンプ-ホーム(limp-home)・モード、を定義することを含んでいてよい。
【００１６】
この方法は、前記一連のオペレーションのモードを１つまたは複数のステート・チャート(state chart)の形で特定化することを含んでいてよい。
【００１７】
この方法は、ハードウエア構成要素を幾何学的写像すること、および／または、配線し、それから、前記幾何学的写像によって前記独立性の指標が保持されていることを自動的にベリファイすることを含んでいてよい。
【００１８】
この方法は、深刻度を単位時間当たりに故障が起こる確率として特定することを含んでいてよい。この方法は、前記システムのアーキテクチャ製作のための１組のデータを出力することを含んでいてよい。そのアーキテクチャは車両のためのアーキテクチャ、たとえばブレーキ・システムのための制御回路のような、安全性重視アーキテクチャからなっていてよい。
【００１９】
本発明は、また、コンピュータ読み取り可能なメモリであって、その上にシステムのアーキテクチャ設計とベリファイのためのプログラムをエンコードしてあり、そのプログラムは本発明の方法を実施するためのコードを含んでいるメモリを含む商品を提供する。
【００２０】
本発明は、また、その上にコンピュータ・プログラム・コード手段を持つコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品を提供し、前記プログラムがロードされるとコンピュータ・プログラム・コード手段はコンピュータにシステムのアーキテクチャ設計とベリファイの手順を実行させ、
前記手順は、
a)一組の望ましくないイベントを識別(identify)し、前記望ましくないイベントのそれぞれに、それぞれの深刻度(severity)の指標(indicator)を付ける(ascribe)ことを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考える(associate with)ことを含み、
c)前記アーキテクチャのインプリメンテーション(implementation)のために提案された最初のアーキテクチャの機能仕様(functional specification)を開発する(develop)ことを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフロー(dataflow)と該構成要素間のデータフローとを含み、前記構成要素は、例として、センサまたはアクチュエータを含み、
前記手順は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられた(associated with)フォールト・トレランス(fault tolerance)の要求条件を洗練(refine)し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信すること(issuing)を含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記手順は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定する(define)ことを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像(mapping)することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイ(verify)することを含む。
【００２１】
本発明は、また、システムのアーキテクチャ設計とベリファイに適合した設計ツールを提供し、前記設計ツールは本発明の方法のステップを実行することに適合しているか、または、本発明に従ったコンピュータ・プログラム製品を用いてプログラムされている。
【発明の効果】
【００２２】
本発明の実施により、互いに接続された複数の電気デバイスのためのシステムのアーキテクチャを製作する改良された方法を提供することが可能となる。
【発明を実施するための最良の形態】
【００２３】
本発明は、これから、例示の方法のみによって、いくつかの実施例を引用し、上述の図面を参照して記述されるであろう。
【００２４】
機械部品の安全性はその部品の物理的性質と化学的性質とをマスタすることによって得られる：これは、われわれが「マテリアル・レジスタンス」と呼ぶものであり、膨大な経験を伴った進んだ知識領域である。電子部品の安全性は、冗長度と票決を通じて得られる、結果の信頼性のレベルの実証(proof)は、機械部品の世界で可能であるのに比べると、得るのが不便であることが明らかになるかもしれない。
【００２５】
「複製(replicate)」とその派生語について引用しよう。複製とは、一般的術語として、プロセス・データフローとハードウエア・デバイスとの冗長度を持った空間または時間ドメインにおけるインプリメンテーションのことである。たとえば、センサの複製は同じ構造と同じ機能とを持つ物理的複製、たとえば、同じ生産ラインから作り出された別の部品であろう。データフローの複製は、もとのデータフローが運ぶ情報と同じ情報を、問題としているシステムの設計トレランスに十分に適合する正確さとサンプリングレートで運ぶ他のデータフローであろう。複製情報は、複製の目的が、単に、その情報が健全な(sound)ものであることを保証することを目的とした場合に、部分的につくられるものであろう。たとえば、繰り返し冗長度チェック（ＣＲＣ）は、チェックされるプログラムの空間における部分的複製であると考えられるであろう。
【００２６】
われわれは、本発明において、設計者が同じ値を算出するのに異なったメカニズムを提供するときの機能的複製と、単一の情報源から全体または部分情報をコピーすることによって得られる複製とを区別するであろう。われわれは、機能的複製は、機能的アーキテクチャにおいて、同じ源(source)からのいかなる複製が実行されるよりも前に、取り扱われることを考慮するであろう。われわれの発明は主に同じ源からの複製を取り扱うが、機能的複製から来る要請をも考慮する。
【００２７】
時間と空間における複製は計算の信頼性を改善するための好ましいツールであるので、複製された情報を一緒に集め、一組のプロセスの、誤りかもしれない結果の中から正しい値を決定することもまた必要である。情報の収集は、常に、空間あるいは時間におけるある種の票決にある。票決には異なったアルゴリズムが存在し、われわれは、特定のアルゴリズムが、それぞれの種類の票決（２、３または４個の複製間；そしてフェイル・サイレントまたはフォールト・トレラントの計算）に対して選定されていると仮定する。冗長度は異なった形：空間、時間そして両方の高いかあるいは低い巧妙度の組合わせで用いられるであろうことに注意されたい。われわれは、特定の電子部品の高レベルの安全性を仮定することができないときに冗長度を必要とする。われわれは、これから一組の複製の安全性について論議しよう。
【００２８】
故障(fault)は対称または非対称でありうる。非対称故障は「ビザンチン(Byzantine)」と呼ばれている。異なる電子制御ユニットが同じ情報（異なった情報源からか否かにかかわらない）の複製を受けたとき、われわれは、それらの電子制御ユニットが相互に連絡し合って、それらのユニットが実際に同一の情報を得たことを確認した事実を「アグリーメント(agreement)」と呼ぶ。一致は、また、この技術分野において「コンセンサス(consensus)」としても知られている。
【００２９】
「ビザンチンアグリーメント」は、プロセス間での連絡のコンテキストの中で明確化される。プロセスＡが初期値“１”でスタートし、プロセスＢが初期値“０”でスタートし、プロセスＣが初期値“０”でスタートする、と想像しよう。プロセス全体は同一の数値に収斂することを望み、各プロセスは、究極の多数票決を行い同一の数値に収斂するために、それぞれの初期値を他の２つのプロセスへ送信する。もしも、ＡとＢが正しければ、それらは、それぞれ、“１”と“０”を送信する。Ｃがビザンチンであるとは、Ｃが誤った非対称な情報をＡとＢに送ることを意味する。これが、非対称がビザンチンを表す理由である。たとえば、Ｃは、Ａには“０”を、Ｂには“１”を送るかもしれない。この場合には、正常に働いているＡはＢとＣから“０”を受取り、“０”を結論とするであろう。正常に働いているＢはＡとＣから“１”を受取り、“１”を結論とするであろう。そこで、結論として、３つの無故障プロセスは、１つのビザンチン故障の存在のために１ラウンドではコンセンサスに到達しない。しかしながら、数ラウンドの後には、もしもそのような補足ラウンドを時間制約が許すならば、コンセンサスが得られることが可能である。
【００３０】
典型的なビザンチンエラー源は、過渡的な短絡回路や誘導効果の存在下では、一般に受入れられている尺度(measure)である。サンプリングがいつ実行されるかに正確に依存して、同じ時間内における捉え方の違いで実際の信号は大きくも小さくもなる。
【００３１】
他の典型的なビザンチンエラー源は、同期アルゴリズムのコンテキストにおけるクロックである。クオーツ・ジッタや通信遅延によって、あるクロックが他のクロックに相反する情報を送るかもしれない。
【００３２】
ビザンチン故障（非対称故障とも呼ばれる）は、１ラウンドでコンセンサスに到達するために、高レベルの冗長度を要求する。しかしながら、ほとんどの時間において、非対称故障は設計において考慮されていない、それは、非対称故障が、多くのの場合に、過渡的であって、「巨視的」な物理的数値に基づいて作業しているときには無視することができるからである。
【００３３】
われわれが非対称故障を考慮すると決めるか否かにかかわらず、本発明の方法は平等に適用される。複製の個数と冗長度「戦略」とが対称故障の場合と異なるだけである。対称故障の例は、コミュニケーション・バスの「オフ」、マイクロ−コントローラのシャットダウンまたはクラッシュ、フューズの溶断、そして、多分もっと一般に、「死んだ」電気部品である。
【００３４】
電子的な安全性アーキテクチャが構成され、特定の物理的アーキテクチャおよびアプリケーション・ドメイン用にチューニングされている。すでに検討したように、原子力プラント、車両および航空機は高度の技能を持った技術者によって設計された高価なシステムの例であり、それらは規模拡大可能(scalable)でも柔軟(flexible)でもない。これらのシステムのために、階層制のアプローチ、すなわち、装置・レベルのアプローチが最初で、それからソフトウエア・レベルのアプローチ、が伝統的に用いられてきていている。この考えは、目的に合った物理的装置を同定し、それから、各ノードにおけるソフトウエアを記述するルールを提供することである。
【００３５】
決定論は安全性重視システムにとって安心できるプロパティであり、決定論は理想主義的であるので、われわれは、「レプリカ決定論」を考え、そのレプリカ決定論においては、１つの部品の異なった複製は、「実の(real)」時間の間だけ、常に「同じ状態」になるとする。ここで、「実の」時間は理論的な概念であり、それは、「同じ状態」が、われわれは数学ではなく物理学を扱っているので、「等しいと考えられることに十分に近いこと」を示している。レプリカ決定論を得るには、最も多く存在する安全性システムはタイム・トリガードである。グローバル・クロックのアイディアは故障：時間故障の完全なカテゴリをスキップすることを許す。完全に対称なアプローチは、時間故障が修繕(fix)され、そして、精度故障が修繕されるような世界における「分割と克服(divide and conquer)」アプローチを許す。実際に、決定論は、安全性重視フレームワークの強制的なプロパティである、何故かというと、そのようなフレームワークは、決定論が無ければ、設計と実証が非常に困難となり、ほとんど不可能であろうからである。
【００３６】
１９８５年に刊行された論文、“Impossibility of distributed consensus
with one faulty process"(１つの故障プロセスを伴う分散されたコンセンサスの不可能性）は、もし、相異なる分散されたプロセス（それは、異なったＣＰＵにおいて異なった周波数で進行するプロセスを意味する）の間の情報伝達の速さについての仮定がなされなければ、コンセンサスの問題は解けないであろうと、議論している。この論文の結論は、プロセス間での情報交換が同期していないシステムを設計する場合には、或る同期化の手段が必要であるということである：少なくともクロック・スピードについての仮定が期待される。望むらくは、これは、内蔵システムへの適用において常に実現することであり、したがって、少なくとも理論的には、非同期のフォールト・トレラントのシステムを設計することは不可能ではない。
【００３７】
コンファインメント(confinement)は、安全性重視フレームワークの、その他の非常に重要なプロパティである、一般的で高価な規則は、異なったフォールト・トレラントの要求を持ったシステムが、フォールト・トレラントではないシステムが不用意に開発されるであろうという仮定と、本質的でない機能の設計の誤りが安全性システムの故障の理由であるということは受け入れられないという仮定の下で、混じり合うことを避けることである。
【００３８】
故障は、しばしば、一時的であり、過渡的ですらある。故障を持っていた構成要素は、ある時間の後には故障を持っていないかもしれない。電子制御ユニット（ＥＣＵ）のホット・リセットは良い実例である。もしも、或る理由で、或るＥＣＵが正常に動作していないときに、このＥＣＵをリセットし、システムの動作中においてさえも、ふたたび、正常に動作させることが一般に可能である。これは、故障は一時的でありうることを意味する。そこで、故障の確率は単位時間当たりとして特定され、これは、決定的な故障と一時的な故障との両方に適用できる。
【００３９】
一時的故障の概念に関連して、診断は、構成要素またはシステムの信頼性を動的に補強する方法と見られることができ、それは、また、構成要素の種類を変えることを許す。たとえば、電子制御ユニットの構成要素が正常に動作していないこと、あるいは、他の電子制御ユニットが正常に動作していないこと検出して、ホット・リセットを始動させることができる。診断は、また、定常的なエラーを一時的なエラーにに変換することを許す。われわれの応用の目的には、われわれは、診断を、応用の一部分または機能的アーキテクチャへの要求仕様に適合する方法であると考える。
【００４０】
他の古典的な安全性重視設計システム技術は異なったソース(source)によるインプリメンテーションである。しかしながら、開発チームが、技術が設計誤りを避けるための強力な方法であるとする同じ考えを持っているので、同じ設計誤りを含んだソフトウエアのよく知られた例がある。このことは、ハードウエアにも当てはまる；われわれは、安全性重視システムの異なったノードに同一のマイクロプロセッサを使うことを避けるべきである。こうすれば、一方で、マイクロプロセッサのうちの１つが故障を起こす確率は広がるが、同時に２つのマイクロプロセッサが故障を起こす確率は大幅に低くなる。
【００４１】
われわれは、非特許文献３おいて定義された設計誤りに言及するつもりはない。設計誤りに基づく事例は、ブレーキ操作のための誤った制御規則であり、それは、或る状況の下では、全くブレーキをかけることに至らないというようなことであろう。むしろ、われわれは、健全な機能設計を正確にインプリメントする問題に注目したい。異なったソースによる複製をインプリメントすることは、設計誤りにうまく対処する優れた方法である。
【００４２】
いわゆるフェイル・セーフ・システムにおいて、システムが機能の一部または全部までも失っても、利用者が、装置を操作できたり、装置を安全と定義されている既定の状態に持っていけるようなオペレーションのモードが存在することは評価されることであろう。たとえば、トラックのブレーキは、加圧空気システムによってオフ位置に保たれるであろう。もしも、加圧空気システムに故障、たとえばパイプ破損、があれば、空気は洩れ出して、ブレーキはオン状態となり、システムが利用者をトラック操縦可能にはしないにしても、この状態は予め安全と定義されている状態である。
【００４３】
故障が起こっても動作を続けるシステム(フェイル・オペレーショナル(fail-operational)システム)には、システムが機能の一部または全部までも失っても、利用者が、装置を操作できたり、装置を安全と定義されている既定の状態に持っていけるようなオペレーションのモードは存在しない。このようなシステムにおいては、最低レベルの運行が要求される。
【００４４】
フェイル・サイレント(fail-silent)な構成要素とは、その構成要素が内蔵されたシステムに故障が起こると動作を行わなくなる（サイレントになる）ような構成要素のことである。これは定性的な定義である。この定義は、われわれが、システムに故障が起こったときに、その構成要素がサイレントになる確率を特定することによって定量的になることが判る。たとえば、われわれは、１時間稼働中に１０−９の確率で起こるような故障が起こった場合にサイレントになるフェイル・サイレントな構成要素を対象としてよいであろう。フェイル・サイレントな構成要素は２つの故障が起こったときにサイレントになってもよい。単にフェイル・サイレントと言った場合には、それは、１つの故障が起こったときにサイレントになることを意味する。
【００４５】
フォールト・トレラントな構成要素は、その構成要素が内蔵されているシステムに故障が起こっても、あるレベルでの運行を行うような構成要素である。この定義は、フェイル・サイレントな構成要素の場合と同様に、故障の個数と故障が起こる確率が特定されている場合に拡張される。
【００４６】
安全性重視システム設計において、たとえばフェイル・セーフまたはフェイル・オペレーショナルの場合に、われわれは、多くの場合に、フェイル・サイレントなアクチュエータを考える。これは、少なくとも１つまたは２つのフェイル・サイレントなアクチュエータを考慮に入れることができるようなシステムレベルでのフォールト・トレランスを意味する。もしも、或るアクチュエータがフェイル・サイレントであることが証明されることができなければ、われわれは、そのようなアクチュエータの故障に対してシステム補償を用意する。たとえば、車両のブレーキの１つにおける、車両の安定性の減少に直結する、異常なブレーキ応力を推定することは可能である。このようなことは受入れられない。しかしながら、反対側の車輪に等価のブレーキ応力を印加することは、或るレベルでのブレーキ動作につながるであろう、これは、要求されたブレーキ動作とは異なるけれども、車軸の両側の応力配分は本質的に均等となり、それ自体望ましいことではないが、安全性の観点からは、不均等な応力配分に比べれば、明らかに受入れやすいことである。そのような、通常行う、正常な機能の一時的変更は、しばしば、リンプ-ホーム(limp-home)・モードという名で引用される。多くの電子部品にとって幸いなことに、フェイル・サイレントな挙動を保証することが、ほとんど常に、可能である。それは、電流が切られたときに、アクチュエータが受動的になることを保証するだけで十分であるからである。これは、典型的に、ＡＢＳコントロールに許された解決方法である。
【００４７】
自動車への応用の分野において、大規模流れ生産のため、われわれは、部品信頼性の定量的尺度を持っていて、それは、実に優れていて、冗長度を用いる場合の、高水準の信頼性を証明するのに十分である。不幸なことに、これとは別の厳しい制限はコストであり、それは、不必要な冗長度を回避し、特に、ハードウエアのレベルにおいて、すぐに再発するコストとなってしまう。電線によるブレーキ操作(Brake-by-wire)または電線による操舵(Steer-bu-wire)のような、安全性重視システムの応用分野は、われわれの発明のプロセスに特に適している、というのは、われわれは、コストと安全性との間のトレードオフの柔軟な関係を提供し、また、本発明の方法の基礎を作ることができ、それによって、われわれは、現実的な部品信頼性に基づく設計手法を生み出し、その手法は、航空工学領域や列車運送領域で設計されるシステムにわたって決定的な優位点となるからである。
【００４８】
本発明の方法によれば、われわれは、一片のコードの正しさや、いかに忠実に数学的関数をエンコードしたかを考慮しない。安全性システムの制御規則を取り扱う際に、信号の遅延や信号処理の正確さが問題にならないように、物理的システムの動作周波数よりも十分に速いペースでソフトウエアと情報通信とを働かせることは一般に可能であるということが起こる。このようなことが起こらない場合には、最適化はずっと困難になるであろうけれども、われわれのプロセスは、安全性への要求は満たされることがもっと困難であるように見えるにもかかわらず、健全な状態を維持する。
【００４９】
われわれの設計プロセスにおいては、われわれは、時間故障と価値故障とを区別しない、なぜかというと、われわれは、どちらの故障も正確性故障であると考えるからだある。センサの場合は、冗長度と、票決と、時間故障と価値故障とを同様に扱ってよいこととを議論する上で、特に興味深い。説明の道筋において、われわれは、ここで、特に図１Ａと１Ｂとを引用して、或るフォールト・トレランスの要求を持っているセンサＳを考慮する。
【００５０】
或る機能の或る複製ｆにおいて、そのような複製はセンサＳの複製であるセンサＳ１、Ｓ２およびＳ３からのデータを使わなければならない。これらのセンサは、それぞれのデータフローＤ１、Ｄ２およびＤ３を通して情報を提供することを仮定しよう。簡単のため、また、範囲を限定する例とはしないということで、センサＳ１、Ｓ２およびＳ３はブレーキ・ペダルの位置を測るものであるとしよう。
【００５１】
さらに、第１近似として、信号は２値であるとしよう。信号が高ければ、それは運転者がブレーキをかけていることを意味し；信号が低ければ、それは運転者がブレーキをかけていないことを意味するとする。入力に対して或るフィルタリングが遂行され、５００マイクロ秒毎の５つのサンプルから数値が計算される。フィルタリングは、それがいくつかのサンプルから数値を作ることを意味するので、一種の冗長度であることに注意されたい。これは、ペダル・スイッチが低ければ、スイッチの検出結果が実際に誤りなく伝えられる前には、１．５ｍｓが必要であることを意味する。
【００５２】
ここで、われわれは、アーキテクチャにおけるＤ１、Ｄ２およびＤ３の伝播遅延を考慮しなけならない。センサＳ１、Ｓ２およびＳ３によるデータの補足は、３つの、異なるクロック；クロック１、クロック２およびクロック３を持つ、相異なるマイクロコントローラの上で行われるとする。そこで、データフローＤ１、Ｄ２およびＤ３は、実際に、電子制御ユニット（ＥＣＵ）と通信バスによって構成された複雑な電子的アーキテクチャを通って進む。Ｄ１の動作には５ｍｓ+/-３ｍｓ；Ｄ２の動作には８ｍｓ+/-４ｍｓ、そして、Ｄ３の動作には１０ｍｓ+/-２ｍｓが、種々のクロック・ドリフトと種々のジッタとを含めて、要求されると考えよう。さらに、以下のように考えよう：
Ｄ１は５ｍｓ＝毎にクロック１＊Ｎ１サイクルで送られ、Ｄ２は５ｍｓ＝毎にクロック２＊Ｎ２サイクルで送られ、Ｄ３は５ｍｓ＝毎にクロック３＊Ｎ３サイクルで送られる；
クロック１、クロック２およびクロック３は３％よりも少ない変動を持つ；そして
“ｆ" を計算するタスクは１ｍｓ以内に、５ｍｓ毎に遂行される。
【００５３】
われわれは、ｆによって受け取られたＤ１、Ｄ２およびＤ３の最後の３つのサンプルを比較すると仮定し、それらをＤ１ｆ、Ｄ２ｆおよびＤ３ｆと呼ぼう。そのとき、問題は：運転者による実際のペダル・ブレ−キの要請の後に、いつ、ブレ−キの要請の同定に収束するか？ということである。
Ｄ１ｆは古さ(age)が範囲Ｒ１[-15,545ms..-11,5ms]の範囲内にある信号を代表する
1,5ms + 5ms+ (0,003*5ms) + 1ms + 5ms + 3ms = 15,515ms
Ｄ２ｆは古さ(age)が範囲Ｒ２[-19,545ms..-14,5ms]の範囲内にある信号を代表する
1,5ms + 5ms+ (0,003*5ms) + 1ms + 8ms + 4ms = 19,515ms
Ｄ３ｆは古さ(age)が範囲Ｒ３[-19,545ms..-16,5ms]の範囲内にある信号を代表する
1,5ms + 5ms+ (0,003*5ms) + 1ms + 10ms + 2ms = 19,515ms
範囲Ｒ１とＲ２とが共通範囲を持たないことは、われわれが観測する現象の頻度がサンプリングの頻度の桁よりも大きな桁のオーダーである限りは、問題ではない。もしも、われわれが見つけようとしている信号が２０ｍｓよりも低いか、それと同じオーダーの頻度で進展するものであれば、われわれのサンプリングは無意味となる。人間の行動の場合には、頻度はむしろ数百ミリ秒の範囲内にあり、そして、ブレ−キ・ペダルの場合には、通常、軽いブレーキについては確かに１００ｍｓを超え、ペダルは少なくとも１秒間は踏まれている。
【００５４】
ここで、図１Ｂを参照して、いかに、サンプリングと情報通信とが「実」時間の間に行われるかを見ることができる。Ｄ１、Ｄ２およびＤ３の数値は、実際の数値が捕捉されてから長くても２０ｍｓの後には受け取られていることを考慮に入れれば、故障の個数が１を上回る場合を除いて、Ｄ１、Ｄ２およびＤ３の間のいかなる票決の計算も１つの結果に到達するであろうことがわかる。上記と同様のことが、ブレ−キ・ペダルが解除されるときにも当てはまる。
【００５５】
もし、われわれが、“ｆ”が５ｍｓ毎（最悪の実行時間に基づく最大１ｍｓの遅延を伴う）に予定されていることを考慮に入れるならば、“ｆ"は、正確なブレーキ・コマンド“Ｏ”を、ブレーキの要求が検知されてから最長２６ｍｓの後には、生成するであろうことが判る。ブレーキを解除する場合も同様である。
【００５６】
ここで、われわれは、ペダル・ブレ−キの要求を表すものとして、ブール代数的信号ではなく、整数を用いることを考えよう。このとき、次のようなアルゴリズムが使われるであろう：Ｄ１、Ｄ２、Ｄ３の一番新しい数値が“ｆ"によって受け取られ、２つの極端な数値が除外される（われわれはただ１つの故障を考える）。われわれは、比較する異なった数値は正確に同じ時に捕捉されたのではないことに気を付ける、たとえば、古さ(age)の違いは１０ｍｓになりうる。もしも、われわれが、各センサの精度を知っていて、１０ｍｓ以内のペダル・ブレ−キの動きが許される範囲内であると考えるならば、アルゴリズムは健全である。
【００５７】
もしも、強いブレーキをかけるコンテキストの中で許されるならば、数値を、先行する３つの数値との間で平均をとることによってフィルタし、コマンドに「慣性」を与えることも可能である。そのようなフィルタリングの詳細なインプリメンテーションは、しかしながら、ペダルのアーゴノミクスの問題であり、われわれの本発明の視野外にある。
【００５８】
実際の設計において、他のフィルタが導入されてもよく、それは、われわれの例において応答時間をさらに改善するであろう。ブレーキシステムの場合には、もしもわれわれが、出力“Ｏ"がエレクトロメカニカルな構成要素によって２４ｍｓ以内に実行されるブレーキの命令であると考えるならば、それは、ペダルブレーキ操作の要求尺度のパーセンテージとして特定化されるであろう正確度をもつ実際の要求が発せられてから最大でも５０ｍｓ後に、ブレーキ操作がスタートすることを意味する。
【００５９】
われわれの部分的ブレーキ・システムは、ともかく、「同期的」("synchronous")である：われわれの包括的な時間は運転者の行動ペースである。ここに、われわれが示したのは、分散システムは、デッドラインを保証するためにタイム・トリガードである必要はないことである。また、時間誤差は、数値的確度誤差と異なって考えられなくてもよく、伝播する情報のエージングが与えられた確度で制限されている限りにおいて、確度範囲と言い替えてもよい。そのとき、信号が遅れているということは誤差であると考えられてよい。たとえば、バスのノードが常に無制御状態で情報伝達をする、「夢想愚者」("bubbling idiot")として知られているデータ・バスの古典的デフォルトがある。これは、アクセスとトラフィックを無駄にし、通常は、バス上でのメッセージを遅らせる。
【００６０】
本発明に従ったわれわれのアプローチへの入力は、機能的モードと機能的安全性解析とを伴った機能的設計である。これは、下記のステップを実行することによって得られる：
ａ）一組の好ましくないイベントを識別すること(identifying)と、それらの好ましくないイベントの各々にそれぞれの深刻度(severity)を表す指標(indicator)を付けること(ascribing)；
ｂ）それらの好ましくないイベントの各々を、可能な範囲で、機能的設計によって提案されたシステムのアーキテクチャにおける１つまたは複数のアクチュエータに関連させること(associating)；
ｃ）そのシステムのアーキテクチャのインプリメンテーションのために提案された初期アーキテクチャの機能的仕様(specification)を開発すること(developing)、その初期アーキテクチャの機能的仕様は、それについての構成要素へのデータフローと構成要素間のデータフローとを含み、その構成要素は、たとえば、センサまたはアクチュエータを含む；そして
ｄ）前記機能的仕様における、前記好ましくないイベントの深刻度に関連したフォールト・トレランスの要求を洗練すること(refining)と、前記機能的仕様における、洗練されたフォールト・トレランスの要求を発信すること(issuing)。
【００６１】
設計手法のインプリメンテーションの過程においては、機能的仕様の複製が、それらの複製の独立性を表す指標と、洗練されたフォールト・トレランスの要求を反映する指標とを付けられて作られる。設計プロセスは、また、提案されたシステムアーキテクチャ、たとえば、一連の相互にネットワークで接続された電子制御ユニットのためのハードウエア構造を限定し、それから、機能的仕様をそのハードウエア構造の上に写像(map)する。
【００６２】
このプロセスは、これらの独立性を表す指標を、写像(mapping)中に、自動的にベリファイすることを含む。このようにして、設計プロセスは、出力過程において、提案されたシステムアーキテクチャが、或る、すでに定義された安全性への要求条件に合致するか否かをの確証(proof)を得る。もしも、この確証が、システムが特定された安全性への要求条件を満足することを示したときには、それはテストのための実証(validation)モデルへの入力として用いられる。
【００６３】
設計プロセスのさらなる出力は、各構成要素に適用される、究極的にシステムを構築する際には実証されなければならない一連の局所的要求条件であろう。これは、さらに下流に向かっての入力として使われるデータの形をしていて、最終的には、一連の、機械製造用の構成要素との共同作業、または、そのシステムアーキテクチャに使われる回路のレイアウトにおける用途に適した指示に移行する(translate)であろう。
【００６４】
本発明の利点の中に、安全性概念の抽象があり、その抽象は、分割と克服(divide and conquer)のアプローチを可能とする。これは複雑なシステム・デザインのための鍵である。さらに、われわれは特定の技術、バス・プロトコルまたはいかなるあらかじめ定義された安全性設計のフレームワークを頼りにしない。そうではなくて、われわれのアプローチにおいては、ＴＴＰのようなフレームワークは「パラメータ」として見ることができ、それは、われわれが、フォールト・トレラント・システムを、既存のフォールト・トレラント技術なしに、作り出すことさえもできることを意味する。換言すれば、われわれが発明し、開示した方法は、既存のフレームワークを考え、比較することを許すけれども、また、それらを結合させる方法を提供する。上記の点は、前に述べたように、異なる技術を結合することは設計誤りを避ける最善の方法であるので、特に興味深い。
【００６５】
われわれは、ここで、特別の、しかしこれに制限されない、図２における車両のスピードの検出と、図３Ａないし５において図示された方法論を用いた抽象における取り扱いとを参照する車両のブレーキ操作に関連する例を考える。この設計プロセスの概要は図６に示されている。
【００６６】
図２において、機能「車輪スピード計算」405はデータフロー“Ｖ”403を、車輪スピードセンサ401からの入力として持つ。提案されたインプリメンテーションにおいては、同じ車輪スピードセンサ420が１つのＥＣＵ436に接続され、機能「車輪スピード計算」405はＥＣＵ434において実行される。
【００６７】
機能的アーキテクチャからの車輪スピードセンサ401は、ハードウエア・アーキテクチャからの車輪スピードセンサ420に変換される(矢印410)。機能的アーキテクチャからの機能「車輪スピード算出」405は、ＥＣＵ434上の実行可能なプロセスに変換される(矢印412)。車輪センサ401と機能「車輪スピード計算」405との間のデータフローは複雑な道筋に移行し、その道筋は下記を含む：
・ＥＣＵ436、434、そして、それらそれぞれのコネクタ428、432；
・ネットワーク430；
・リンク422、426；そして
・コネクタ424。
【００６８】
図３Ａにおいて、機能“Ｆ”603は,少なくとも１つの入力データフロー“i”601と１つの出力データフロー“ｏ”605を持つ。他の入力と出力とは、簡単化のために、描かれていない。
【００６９】
"Ｆ”とその入力と出力とは、フォールト・トレランス特性のタグをつけることができる：611、613および615。タグ“ＦＴ(Ｆ)”(613)は、機能“Ｆ”に対しるフォールト・トレランスの要求条件が存在することを意味する。これは直感的に、"Ｆ”のインプリメンテーションは、異なるＥＣＵそれぞれの上に複製を要求し、一組の入力が与えられたときに、たとえ１つの故障が起こっても、"Ｆ”の処理(process）実行の大部分が行われるようにするであろうことを意味する。"ＦＴ(ｏ)”(615)は、データフロー“ｏ”に対してフォールト・トレランスの要求条件が存在することを意味する。"ＦＴ(i)”(611)は、データフロー“i”に対してフェイル・サイレントの要求条件が存在することを意味する。
【００７０】
本発明において述べられた処理に従えば、タグＦＴ(ｏ）は或る、データフロー"i”を消費する機能に対する安全性要求条件（の結果）に比較して劣性である。図３Ｂにおいて、システム設計者は、"ｏ”に対する安全性要求条件から、"Ｆ”はフォールト・トレラントであり、"i”はフェイル・サイレントであろうと推論する。
【００７１】
本発明のさらに先の処理のステップにおいて、われわれは、図３Ｃにおいて、データフロー“i”と"ｏ”は、タグ611、613および615によって特定された安全性要求条件に対処するために複製されることを見ることができる。図３Ｃにおいて、複製は１つの対称的故障に対して定義される。これは、１つのフォールト・トレラントな構成要素に対してただ３つの複製が要求され、１つのフェイル・サイレントな構成要素に対してただ２つの複製が要求されることを意味する。
【００７２】
図３Ｃにおいて、Ｆ１ 641、Ｆ２ 643、Ｆ３ 645は、機能“Ｆ”の複製であり、ＦＴ(ｏ)１ 651、ＦＴ(ｏ)２ 653、655はデータフロー“ｏ”の複製であり、ＦＳ(i)１ 621、625、629およびＦＳ(i)２ 623、627、631はデータフロー“i”の複製である。
【００７３】
図３Ｃにおいて、データフローＦＴ(ｏ)１は、Ｆ２とＦ３とにおいて、"ｏ２"(624）と“ｏ３"(626）とで処理(process）され、Ｆ１において、入力ＦＳ(i)１とＦＳ(i)２との“ｏ１”で処理される。この処理の遂行に当たって、票決手順(vote procedure）がＦＳ(i)１とＦＳ(i)２と間と、"ｏ１"、"ｏ２"(624）および“ｏ３"(626）の計算の間に適用されるであろう。さらに一般的な実施例においては、ＦＴ(ｏ)１は、単に、Ｆ１によって処理された“ｏ１”、"ｏ２"(624）、“ｏ３"(626）よりなるトリプレット(triplet）であろう。この場合に、票決はＦＴ(ｏ)１を消費する任意の機能によって遂行することができる。
【００７４】
“ｏ３"(626)と“ｏ３"(632)とは、同じ物理的道筋を通らないので、異なった形で誤るので、相異なることに注意されたい。そこで、われわれは、Ｆ３で処理され、Ｆ１で受け取られる“ｏ３"(626)と、Ｆ３で処理され、Ｆ２で受け取られる“ｏ３"(632)とを区別する。
【００７５】
Ｆ１の処理をするとき、"ｏ２"(624）と“ｏ３"(626）と十分に最近に計算される必要があり、上記の票決前の“ｏ１”、"ｏ２"(624）、“ｏ３"(626）の計算が、上記のブレーキ・ペダルの要求条件の例のように、時宜を得た形で、実行されたことの正当化が存在するべきである。それらのサンプリングとエージングとは、データフロー“ｏ”における正確さに関して（"w.r.t."）健全であるべきである。このような正当化は、タイム-トリガード・システムのコンテキストにおいて、より簡単であり、これが、タイム-トリガード・システムが、電子部品のコストが問題にならないほとんどの場合（短いインスタンスの場合）に用いられる理由である。
【００７６】
フェイル・サイレントなオブジェクトの２つの複製は、１つの対称的故障が同時に誤差を生じえない場合に、１つの対称的故障に対して自由であるといわれる。対照的な例としては、図３Ｄにおける“Ｇ”は、機能“Ｇ”の処理における誤差は潜在的に x1 と x2 とに誤差を生じるので、データフロー x1 673 と x2 675 は連結されている場合を示す。
【００７７】
フォールト・トレラントなオブジェクトの３つの複製は、１つの対称的故障が同時に１つ以上の複製において誤差を生じえない場合に、１つの対称的故障に対して「自由」であるといわれる。
【００７８】
１つの整数を“k”としたときに、フォールト・トレラントなオブジェクトの "2k+1" 個の複製は、“k”個の対称的故障が同時に１つ以上の複製において誤差を生じえない場合に、“k”個の対称的故障に対して「自由」であるといわれる。
【００７９】
これらの定義は、データフローに対するように、正確に適用され、処理の誤差は間違った実行であり、フローの誤差は間違った情報伝送であるかまたは情報不伝送である。或る誤差が検出できるか否かということは、設計者がデータフローにタグを付ける際に気がつくことである。
【００８０】
Ｆやその他のオブジェクトの複製を作ることに付随して、任意のオブジェクトの複製間の「自由性(freeness)」の要求条件が生成される。これは、好ましくは自動的に実行されるが、結局は複製と票決の戦略に依存するであろう
図３Ｃにおいて、データフローＦＴ(ｏ)１ 651、ＦＴ(ｏ)２ 653およびＦＴ(ｏ)３ 655は自由せあるべきであり、それは、或る１つの故障が、同時に、これらの１つよりも多いフローにおける誤差を生じえないことを意味する。
【００８１】
同様に、
- ＦＳ(i)１とＦＳ(i)２とは自由であり、
- Ｆ１、Ｆ２、Ｆ３は自由であり、それは、単一の故障は、複数の複製の
処理中に同時に故障を生じえないことを意味し、
- Ｆ２に送られたデータフロー "ｏ１"(622)と Ｆ３に送られたデータフ
ロー "ｏ１"(628)とは自由であり、
- Ｆ２で作られた "ｏ２" と、Ｆ３で作られた“ｏ３" とは自由である。
【００８２】
他の複製のスキームがインプリメントされることが可能であり、それらに付けられた自由性の要求条件は異なるであろう。例えば、非対称故障を容認するシステムに対しては、４つの複製がＦに対して必要であろうが、ただ１つの対称故障のみが許されるような例においては、図３Ａないし３Ｄにおけるように、３つの複製が必要なだけである。
【００８３】
自由性は、複製が同一源からのコピーであるかぎり、局部的なプロパティである。もしも、フォールト・トレラントな入力が、データフローの３つの機能的複製（例えば“d、e、f”であって、それらは設計者によって提案され、同じ結果を得る異なった計算方法）の間の票決に基づくものであれば、“d、e、f”は自由であり、１つの故障は他の２つにインパクトを与えないことを保証するであろうし、このときには、自由性のプロパティは局部的ではなくなる。設計者によって提供された３つの独立なデータフローが「自由」であるということは、それらのうちの２つについての計算のいかなる段階にも関与するオブジェクトは存在しないことを意味する。このようなプロパティは大変に証明することが困難であり、その理由は、そのような証明には機能的アーキテクチャ全体が関ってくることにある。タグを付ける前の機能的アーキテクチャと複製であって、本発明に係る方法において実施される、設計プロセスの最初の部分となるものについては、上記の証明を行うことができる。そしてまた、機能的複製の解析から得られた自由性の要求条件は機能的アーキテクチャに適合すべきでろうし、ハードウエア・アーキテクチャ上に写像されるであろう。
【００８４】
項目 621 ないし 655 からなる機能的アーキテクチャを物理的アーキテクチャに写像するときに、自由性の要求条件は、インプリメンテーション後に、満たされるべきである。これは、ハードウエア・アーキテクチャにおいて写像を受けた構成要素は同じ自由性の要求条件を満たすことを意味する。図４Ａないし４Ｄにおいて、われわれは、ハードウエア・アーキテクチャ上へのフェイル・サイレントな機能の写像を説明している。われわれは、図３Ａないし３Ｄにおけるのと同じ処理のステップを開始する。
【００８５】
第１のステップ（図４Ａ）において、項目 701 ないし 705、機能“Ｊ”705 が、入力データフロー“k”701 と出力データフロー“i”701 によって、特定化される。
【００８６】
第２のステップ（図４Ｂ）において、項目 711 ないし 715、アクチュエータからセンサまでからの逆行性解析の後、機能Ｊと、その入力と出力の流れに安全性の属性のタグ（Ｊには（713)、"k”には（711)、"i" には（715）)を付けられる。"ＦＳ(Ｊ)" 713 は、Ｊがフェイル・サイレントであるべきであり、故障が起こった場合に、ＦＳ(Ｊ)は、フォールト-フリーな処理の結果を送るか、または、何も送らないかのいずれかであることを示す。
【００８７】
第３ステップ（図４Ｃ）において、項目 721 ないし 725、複製と自由性の要求条件とが、要求された安全性のレベルを提供するために、特定化される。例えば、インスタンス i１ と i２ とは自由であり、機能Ｊ１とＪ２とは自由であるとする。
【００８８】
第４ステップ（図４Ｄ）において、冗長度のある機能的アーキテクチャが、ＥＣＵとネットワークとからなるハードウエア・アーキテクチャの上に写像される。機能Ｊ１はＥＣＵ 741 で処理され、機能Ｊ２はＥＣＵ 743 で処理される。われわれは、このインプリメンテーションにおいては、Ｊ１とＪ２は自由であることをチェックできる。しかしながら、データフロー "i１" と "i２" が、設計者によって、通信バス上に写像されたとすると、 "i１" と "i２" の自由性の条件もはや満足されない、というのは、１つの故障（バスはオフである）が、"i１" と "i２" の両方の誤りの下位にあるからである。そこで、"i１" をバス 745 で送り、"i２" をバス 747 で送るのが、自由性の条件に明らかに適合するために、より健全である。
【００８９】
冗長度のある機能的アーキテクチャをハードウエア・アーキテクチャの上に写像する過程において、われわれは、安全性と自由性の要求条件を洗練することに進むことに注意されたい。例えば、"i１" と "i２" とが自由であるという要求条件は、これらの流れのインプリメンテーションが自由であるという要求条件となり、これはさらに複雑な条件である。
【００９０】
もしも、これから、構成要素が故障する確率を考えるとしたら、フォールト・トレラントのシステムの設計はさらに正確である。自由性の条件は確率を使って特定化される。
【００９１】
ここで、"p”を、ある期間において、ある故障が、データフロー "i１" と "i２" の両方の故障を生じる最大の許容しうる確率であるとしよう。確率 "p”は、いくらか、 "i１" と "i２" の自由性の程度を表している。それは、また、システム（および、特に、機能Ｆ）が、故障が起こったときに、フェール・トレラントでない確率でもある。
【００９２】
そこで、もしも、フロー "i１" と "i２" が、故障確率が "p”よりも小さいバスに送られとしたとき、自由性の条件は満たされる。もしも、反対に、"p1”がバス 745 の故障確率であり、"p2”が バス 747 の故障確率であるすると、p1*p2 が "p”よりも大きければ、自由性の要求条件は満たされず、もっと信頼性の高い設計が要求される。
【００９３】
図５に、われわれは、タグをつけることと、安全性要求条件とが、機能を組み合わせたときに、どのように安定化するかを説明する。この様子は、非常にに重要であり、その理由は、これがわれわれの「分割と克服」アプローチのための鍵となるものであり、そこにおいて、システム上で実証さるべきすべての安全性要求条件が一組の処理または一組のデータフローが自由であることの証明に帰着するからである。
【００９４】
このことは、もしもわれわれが、ＦとＧとの合成（ＦｏＧ）に対する安全性要求条件を持つとしたとき、これは、一方ではＦとＧとの間のフローの安全性要求条件の結果であり、他方では他の機能についてのＦとＧとの安全性要求条件の結果であることを意味する。結局は、システムがフォールト・トレラントであることを証明することは、機能のレベルにおけるいくつかの簡単な証明であることが判明する。或る複雑なシステムが或る安全性要求条件を満たすことを証明することは、そのシステムにおける各機能が、システムレベルにおける安全性要求条件から洗練(refine)された「局部的な」安全性要求条件を満たすことを証明することと等価である。例えば、機能の１００セットの複製および/または５つのＥＣＵに写像されたデータフローが自由であることを証明することは、各セットの複製が自由であることを、それぞれに、証明することからなるであろう。この安全性要求条件の合成的性質は、「分割と克服」アプローチのための鍵であり、このことは、結果として、規模拡大可能(scalable)である。
【００９５】
図３Ａないし３Ｄと４Ａないし４Ｄにおける例は、図３Ａないし３Ｄと４Ａないし４Ｄにおいて、機能が結合されたときに、いかに、解析が結合されるかを示すために、図５に付加されている。これは、いくつかの機能を含む複雑なシステムに対して、いかにものごとが扱われるかを知るのに役立つ。
【００９６】
機能ＪとＦが結合されるときに、データフロー 601 と 705 とは、それらが同じデータフロー "i" を表しているので、等価とされる。もしも、いくつかの機能がデータフロー "i" を消費するならば、"i" に対する安全性要求条件は、"i" を消費する各機能から受け継がれた安全性要求条件の最大値である。そこで、複製の個数とその信頼性は、また、同じ方法で計算される。
【００９７】
逆に、もしも、１つのデータの３つの複製が利用可能であるならば、例えば、フォールト・トレランス要求条件が特定化されているので、このデータは或る、安全性要求条件を持たない機能によって消費される。これは、その機能を計算するために１つの複製を選びだすのに十分である。他方、３つの複製が存在している場合に、これは、少なくとも１つのフォールト・トレラントな機能の複製が３つのデータフローの複製のすべてを消費するであろうからである。
【００９８】
図５における輪郭 821 は、図３Ａないし３Ｄと図４Ａないし４Ｄに示された機能ＦとＪの合成を説明している。データフロー "i" に対して、一方でデータフロー 725、他方でデータフロー 621、625 および 629 が等価とされていることに注意されたい。同様に、一方でデータフロー 735、他方でデータフロー 623、627 および 631 が等価とされている。
【００９９】
もしも、われわれが、ＦとＪの合成であるＦｏＪを考えるならば、ＦｏＪへの自由性の要求条件に適合することは、一方で輪郭 821 内でのＦとＪとの間の自由性の要求条件と、他方で輪郭 821 外でのＦ、Ｊそれぞれの自由性の要求条件とに適合することを意味する。
【０１００】
そこで、機能的アーキテクチャは、アクチュエータからセンサまでの繰り返しで、回帰的に完全にタグ付けられる。そして、機能的複製は、自由性の要求条件とともに、生成されることができる。そのような生成は、もしも、複製の戦略がフォールト・トレランスの各レベルに対して標準的である場合には、自動的に実行されることができるに注意されたい。例えば、すべてのフェール・サイレントな機能が、多くても１つの故障が存在する場合に、図４におけるＪと同様な方法で複製される。
【０１０１】
冗長度のある機能的アーキテクチャが（複製生成の後に）ハードウエア・アーキテクチャの上に写像されれば、最適化は、いかなる機能に対しても、インプリメンテーションが高価でないデータフローの複製からなる。例えば、機能Ｆが、３つの複製、i1、i2およびi3を伴うデータフロー "i" を消費するとする。Ｆが、入力 "i" から、いかなるフォールト・トレランスのプロパティも要求しない場合を考えよう。そうならば、"i" の複製の１つは消費されなければならない。もしも、例えば、インスタンス i1 が、処理Ｆを行うＥＣＵ上で利用可能であり、i1 が他のＥＣＵ上で利用可能であれば、Ｆへの入力としては i1 を選ぶのがよい。
【０１０２】
図６において、フォールト・トレラントなアーキテクチャの設計プロセスの好ましい実施例が本発明に従って記載されている。このプロセスは以下のステップを含む。
１ 望ましくないイベントとその重要性(gravity)の識別(identification)。
２ 実または仮想のセンサとアクチュエータによって構成されたシステムの機能
仕様決定(functional specification)。
３ リンプ-ホーム・モード(limp-home modes)の記述。
４ 望ましくないイベントを実または仮想のアクチュエータと関連づけること
(association)。
５ 機能的アーキテクチャの上での望ましくないイベントの洗練(refinement)。
６ 安全性要求条件の洗練(refinement)とともに冗長度の導入。
７ ハードウエア・アーキテクチャの定義。
８ 電子制御ユニット上へ機能を写像すること。
９ 結果として生じる電子的アーキテクチャのフォールト・トレランスをベリフ
ァイすること。
１０ 物理的構成要素の幾何学的写像と配線。
１１ 結果として生じる電気-電子的アーキテクチャのフォールト・トレランス
をベリファイすること。
【０１０３】
このプロセスは線形(linear)であることは意図されていない。少数のループが表現(presentation)に隠されている。例えば、ステップ６は相異なる、多くのやり直しを誘起するであろう経路で実行されてもよい。また、相異なるハードウエア・アーキテクチャが、ステップ７において、与えられたフォールト・トレラントの要求条件の下において、より高価でないアーキテクチャを見つけることのゴールとして、調査されるであろう。ステップ８において、別の写像が、特に、ステップ９が、或る写像が満足すべきものではないことを立証し、さらなる作業を要求するときに、調査されるであろう。また、ステップ１０において、別の場所(location)のノードが調査されるであろう。図６に示された新しいプロセスのステップは、これから、詳細に、記述されるであろうが、古典的技術の様態は、ここでは、完全に詳細には記述されない。
【０１０４】
１．望ましくないイベントとその重要性(gravity)の識別(identification)
このステップはよく知られている、機能的故障解析(Functional Failure Analysis)（ＦＦＡ）のステップであり、ＦＦＡは安全性解析の古典的部分である。或るシステムに対するＦＡＡの結果は望ましくないイベントを、そのイベントが起こったときの結果の深刻度(severity)とともに識別することである。
【０１０５】
２．実または仮想のセンサとアクチュエータによって構成されたシステムの機能仕様決定(functional specification)
このステップは、例えば図２に関連して上記された技術を用いて遂行されるであろう。
【０１０６】
この段階において、われわれは設計欠陥(design fault)を洗練(refine)することができ、このことはすでに言及した。
【０１０７】
３．リンプ-ホーム・モード(limp-home modes)の記述
モードの記述は、機能的アーキテクチャを補足するものである。或るシステムは、制御-自動機械(control
automata)、例えば、ステート・チャート(state chart)によって構成されるとして記述されることができ、ステート・チャートはデータフローをトリガ(trigger)する（上記非特許文献１参照）。最高のレベルにおいて、自動機械はシステム・ノードをインプリメントしなければならず、システム・ノードとしては、初期化、ノミナル・モード、リンプ-ホーム・モード、および、或るモードから他のモードへのスイッチ機能がある。
【０１０８】
例えば、車両のブレーキ・システムの場合に、もしも前左のブレーキが機能せず、他のブレーキは正常に働いているとすると、ブレーキをかけることは、車両の安定性の損失を結果として生じ、このことは、多くの場合に、ブレーキをまったくかけないよりも悪いことになる。そこで、その場合に、信頼できるリンプ-ホーム・モードは、前右のブレーキと後左のブレーキの、両ブレーキへの適切なブレーキ圧力によるブレーキングであろう。その場合に、車両の速さは結果的に減少し、車両は安定な状態に留まるであろう。
【０１０９】
安全性重視システムにおいては、リンプ-ホーム・モードは、多くの場合に、或る故障のためにノーマル・モードが利用できない場合に、低級な働きを提供することにあるであろう。これは、われわれが図６において出発するステップである。
【０１１０】
４．望ましくないイベントを実または仮想のアクチュエータと関連づけること(association)と状態遷移（図６のステップａ））
われわれのプロセスにおいて、われわれは、ＦＦＡの結果の部分のみを考える。各望ましくないイベントに対して、われわれは、関連のあるアクチュエータ、すなわち、他のアクチュエータは正常に機能しているのに、そのアクチュエータの故障が望ましくないイベントを生じるアクチュエータを考える。例えば、車両のブレーキ・システムに対しては、われわれは、望ましくないイベントは、「ブレーキ操作における安定性の欠如」と考えることができる。これは、アクチュエータの１つがブレーキ操作をしていず、他のアクチュエータがブレーキ操作をしている場合に、可能であろう。もしも、われわれの目標が、システムが１つの故障に対してトレラントであることにあるならば、或る解析が、例えば、安全性の欠如はアクチュエータの１つの故障によるとの結論に導くかも知れない。その場合に、われわれは、「ブレーキ操作中の安定性の欠如」を各ブレーキ・アクチュエータのみと関連づける(associate)ことであろう。いま、われわれが、望ましくないイベントを「ブレーキ操作が要求されているのにブレーキをかけないこと」と考えるならば、アクチュエータのいずれもが、この望ましくないイベントが明らかにすべてのブレーキに関連づけられるような健全なコマンド受け取っていないことは明白である。
【０１１１】
しかしながら、われわれのブレーキ・システムは、制御自動機械によってトリガされ、ブレーキをかける要求は、その制御自動機械の移行(transition)であり、その制御自動機械は「ブレーキ」状態へ導くと仮定しよう。もしも、その移行が正常に遂行されないときには、ブレーキが正常に働いているとしても、望ましくないイベントが起こるであろう。そこで、或る望ましくないイベントは、或る状態の移行に、もしも、その状態の移行の故障が上記の望ましくないイベントを引き起こす場合には、、結びつけられる(attached)であろう。ステップの終わりにおいて、望ましくないイベントの各々は、１つまたは少数の、アクチュエータまたは状態の移行の結果の組合わせに結びつけられるであろう。
【０１１２】
深刻度のレベルについての可能性のある引用例は上記非特許文献５において提供されている。深刻度に応じて、１つまたは２つの故障が存在するときに、フェイル・サイレントまたはフォールト・トレランスのレベルが、故障を受け取ることの予測される確率とともに、予期される。
【０１１３】
電気的ブレーキ・システムの場合には、アクチュエータは「フェイル・サイレント」であることが要求され、ブレーキが、それが機能しない物理的状態に置かれうることが確証されなければならない。もしも確率が予期されるのであれば、われわれは、電気的ブレーキが、単位時間における確率 "p"("p"は非常に小さく、例えば、１時間当たり１０−８である）の場合を除いて、それが機能する物理的状態に置かれるということができるであろう。
【０１１４】
５．機能的アーキテクチャの上での望ましくないイベントの洗練(refinement)
スタート 901 において、機能的アーキテクチャはセンサ、アクチュエータおよびデータフローで構成され、いくつかのデータフローは電流をモデル化し、バッテリーはセンサとしてモデル化され、前のステップ（ａ）において、望ましくないイベントが識別され、アクチュエータと結びつけられる；設計技術者は、それから、彼がフェイル・サイレントを期待するのか、フォールト・トレラントを期待するのか、なにも要求しないのかを、各アクチュエータの異なった入力の流れから、その隔離されたアクチュエータに付随する望ましくないイベントに応じて示すことができる。
【０１１５】
ブレーキ・システムの場合に、例えば、ブレーキ単独では故障してはいけないという要求があるときには、各ブレーキのブレーキ力命令はフォールト・トレラントとして特定できる。しかしながら、設計者は簡単に、ブレーキ・システムが故障が検知された後に十分に速やかに反応するならば、フェイル・サイレントの要求で十分と考えるかも知れない。このタギング(タグをつけること)は、アーキテクチャとその性格に依存する。
【０１１６】
繰り返し、われわれは、機能とセンサとの安全性要求条件を、各機能とその機能に関連する望ましくないイベントに同様の解析を適用して、決定する。
【０１１７】
もしも、機能がデータフローを生成し、そのデータフローが機能的アーキテクチャを通して、一組のアクチュエータの制御に直接貢献するならば、われわれは、その機能について、アクチュエータの組のなかの一部に関連付けられている望ましくないイベントの全てを、前記機能とそれへの入力に対する安全性要求条件を確立するために、考えなければならない。さらに、われわれは、その機能に対して、その出力への制限が、その出力を消費する機能についての以前の安全性解析からもたらされることもまた考えなければならない。図５において、例えば、機能Ｆの出力への要求条件 615 は、機能Ｆの入力への要求条件 611 を含んでいる。これは、機能Ｊについても当てはまり、機能Ｆの以前の解析が、機能Ｊの出力と機能Ｊ自体の制限とへの要求条件 711 を含んでいる。
【０１１８】
ステップ（ｂ）において、われわれは、その出力または関連する望ましくないイベントが処理されてない一組の機能を計算する。
【０１１９】
ステップ（ｃ）において、（ｂ）において計算された機能に対して、われわれは解析する：
i)入力についてどのような新しい安全性要求条件が求められているか；そして、
ii)機能それ自体に対して、どのようなレベルの安全性が要求されているか（フォールト・トレランス(ＦＴ)、フォールト・サイレンス(ＦＳ)、なにも要求しない(Ｎ))。
【０１２０】
われわれは、それから、ステップ 907 と 911 をたどり、繰り返して、(b)と(c)とを、(b)の中が空でない限り、適用する。
【０１２１】
ステップ(e)において、各センサは、それが生成するデータフローに要求される最高レベルのフォールト・トレランスを取る。
【０１２２】
また、データフローへの安全性要求条件の洗練(refinement)は各モードで実行されるべきであり、それは、オペレーションの各モードは個別に考慮されなければならないからである。望ましくないイベントは、各望ましくないイベントに関連して、どの間違ったモード移行が巻き込まれるであろうかを考慮して、モード移行に適用されるべきである。モード移行は状態移行の特別の場合であることに注意されたい。ある移行に要求条件が設定された場合に、われわれは、アクチュエータの場合と同様に、正確に進む。
【０１２３】
モード移行は、それを活性化するような望ましくないイベントの下では失敗しないことが要求される。そこで、モード移行を引き起こす望ましくないイベントの各々に対しては、モード移行は、望ましくないイベントの深刻度に対応した安全性要求条件を受け継いでいて、その望ましくないイベントに結びつけられていなければならない。
【０１２４】
６．安全性要求条件の洗練(refinement)とともに冗長度の導入（図６における931）
それから、ステップ 931 において、それぞれの機能に対して、複製をインプリメントするように選ばれた機能のインプリメンテーションモードと、票決機構とが要求されれ、それは、それまでに生成された安全性要求条件に依存している。このステップにおいて、われわれはまた、図３Ａないし３Ｄ、４Ａないし４Ｄに示されているように、自由性条件を収集する。
【０１２５】
結果として生じる機能的アーキテクチャは、初めのものよりも大きい。フォールト・トレランスもフェイル・サイレントも、この段階では、仕様決定されず、機能的アーキテクチャは変化していないことに注意されたい。
【０１２６】
７．ハードウエア・アーキテクチャの定義
この段階において、われわれは電子制御ユニット（ＥＣＵ）と、システムをインプリメントするネットワークを特定する。安全性解析が定量的なコンテキストにおいては、各ハードウエア構成要素の予期される単位時間当たりの故障率が特定される。
【０１２７】
８．電子制御ユニット上へ機能を写像すること（933）
このステップにおいて、例えば図４において図解されているように、機能が電子制御ユニットに写像される。
【０１２８】
９．結果として生じる電子的アーキテクチャのフォールト・トレランスをベリファイすること（935）
このステップは、自由性条件のベリフィケーションからなる。このベリフィケーションは自動的に実行されることが可能である。例えば、自由性条件に結びつけられたデータフローは、設計ツールとしてプログラム化されたコンピュータに受入れらるようなデータベース中に記録されることができるであろう。データフローをインプリメントする構成要素も、また、類似のやり方でそのようなデータベース中に記録されることができるであろう。われわれは、それから、その設計ツールを用いて、いくつかの自由なデータフフローをインプリメントする構成要素が存在するか否かを、自動的に見いだす。
【０１２９】
本発明のプロセスをインプリメントするためのソフトウエアは役に立つように、コンピュータ読み取り可能なメモリのようなコンピュータ・プログラム製品中に、設計ツールとして動作するのに適合したコンピュータによる実行に適するコンピュータ・プログラムの形で記録されるであろう。そのコンピュータ・プログラム製品は、コンピュータ読み取り可能な媒体からなるであろう。そして、その媒体上には、コンピュータ・プログラム・コードが、そのプログラムがロードされたときに、それは、コンピュータに、システム・アーキテクチャを本発明の方法に従って設計し、ベリファイする手順を実行させるような形でエンコードされていてる。
【０１３０】
要求の出力はそのような構成要素のリストであることができ、その出力は、マニュアルまたは、物理的設計の提案されたアーキテクチャの強靱度の自動的チェックに適した形をしているであろう。確率が特定されている場合には、要求の出力は、予期された自由性条件の故障確率より低い信頼性を持った構成要素のリストであろう。
【０１３１】
１０．物理的構成要素の幾何学的写像と配線 (再び933)
このステップにおいては、配線の経路、コネクタおよび電子制御ユニット間のケーブル、バッテリー、センサ、アクチュエータおよびさらに一般な電気構成要素が特定される。
【０１３２】
１１．結果として生じる電気-電子的アーキテクチャのフォールト・トレランスをベリファイすること (再び935)
自由性のプロパティは、構成要素の写像を通じて洗練される：２つの配線Ｗ１とＷ２とが、それぞれ、データフローＤ１とＤ２を同一のコネクタＣに運んでいるとする。もしもＣが誤っているとすると、Ｗ１とＷ２の両方が、同じ誤りによって非接続となり、それは、自由性条件条件に関して、健全ではない。
【０１３３】
そこで、幾何学的写像の後で行われるべきベリフィケーションは、コネクタとケーブル（配線を集めている）に関係し、自由性条件は次のように洗練される：
−同じコネクタへ自由なデータフローを運んでいる配線を、確率が特定されている場合と、コネクタが誤っている確率が、要求されている自由性の誤りの確率よりも低い場合とを除いて、非接続とすること。
−集結し、１つのケーブル中で自由なデータフローを運んでいる配線を、ケーブル製造プロセスが、十分に低い確率にまで、短絡、断線の発生を抑えている場合を除いて、非接続とすること。
【０１３４】
配線中のデータフロー自由性条件は、新しい要求条件（不可能性要求条件）を生み出すであろう。これのベリフィケーションは自動的に実行される。例えば、自由性条件が結びつけられたデータフローは、設計ツールとしてプログラム化されたコンピュータがアクセスできるようなデータベース中に記録されることができる。構成要素をインプリメントするデータフローも、また、そのようなデータベース中に、類似の方法で、記録されることができる。われわれは、そのとき、その設計ツールを用いて、構成要素をインプリメントするいくつかのデータフローが存在しているか否かを自動的に見いだす。本発明のプロセスをインプリメントするためのソフトウエアは、有用な形で、コンピュータ読み取り可能なメモリに、その設計ツールとして動作するのに適合したコンピュータの実働のためのコンピュータ・プログラムの形で、記録されることができる。
【０１３５】
このようにして、本発明は、安全性重視システムの規模拡大可能な設計のための、方法ステップを持つ設計プロセスを提供することが明らかとなる。さらに、解析が、機能のレベルで遂行され、それから、異なるハードウエアのインプリメンテーションに用いられる。すなわち、例えば、提案されたハードウエアのインプリメンテーションが、他のものよりも、より高価でないか、および/または、より安全であるかを評価することに用いられる。
【図面の簡単な説明】
【０１３６】
【図１】図１Ａ、１Ｂは、１つのフォールト・トレランス装置を持つ複製の模式的図とグラフ的図である。
【図２】本発明の方法における１つの段階に従って、機能アーキテクチャをハードウエア・アーキテクチャの上に写像することを描いた図である。
【図３】図３Ａ〜３Ｄは、機能アーキテクチャのタグ付けの段階と本発明の方法に従った付加条件と複製へのタグの拡張を描いた図である。
【図４】図４Ａ〜４Ｄは、フォールト・トレランスの必要条件を、本発明の方法における１つの段階に従って、ハードウエア・アーキテクチャの上に写像することを描いた図である。
【図５】本発明の方法に従った機能構成によるフォールト・トレランスの必要条件の安定性を説明する図である。
【図６】本発明の方法に従った、フォールト・トレラントな電子的アーキテクチャの設計とベリファイの全体のプロセスを説明する図である。
【符号の説明】
【０１３７】
401、420：車輪スピードセンサ、422：リンク、424：コネクタ、426：リンク、428：コネクタ、430：ネットワーク、432：コネクタ、434、436：ＥＣＵ。
【技術分野】
【０００１】
本発明は安全性重視システムの設計方法に関し、特に、安全性重視システム(safety crytical system)の設計とベリファイすること(verification)のための方法と技術的補助手段に関する。
【背景技術】
【０００２】
多くのフォールト・トレラント(fault tolerant)なシステムが、今までに、汎用のプロパティが検証されインストールされている、いわゆる、フォールト・トレラント・フレームワーク上に構築されている。そのようなフレームワークは、原子力プラント、車両あるいは航空機の制御の基礎となりうるであろう。
【０００３】
そのようなフレームワークは、規模拡大可能(scalable)でも柔軟(flexible)でもなく、非常に高価なものであり、その理由は、そのようなフレームワークは高レベルのハードウエア冗長度(redundancy)を頼りとし、ハードウエアの前提条件、たとえば、専用のバス・ドライバあるいは他の構成要素、（特に、既存ソフトウエアを搭載したベリファイ(verify)済みのマイクロコントローラ）が有ること、を満足しなければならないことにある。そのようなフレームワークは、コスト最適化が主要課題となる、長い工程を持つ生産には適用されない。
【０００４】
バーチャル・プロトタイプの作成(virtual prototyping)を実現させる試みがなされつつあり、その一例として、下記非特許文献６に、タイム・トリガード・アーキテクチャのためのシステム・エンジニアリングが引用されている。
【０００５】
タイム・トリガード・プロトコル(time-triggered protocol (ＴＴＰ))のフレームワーク（下記非特許文献４参照）は、内蔵型エレクトロニクスへの応用のために構築された安全性フレームワークの良い例である。それは、ある程度、柔軟性と規模拡大可能性(scalability)の要求に応えるものであるが、ただしそれは、ノード間の通信のレベルにおいてである。
【０００６】
上記の全ての例には、一つの共通点がある。それは、一般的な安全性重視フレームワークが設定され、その応用の設計は、そのフレームワーク内において、そのフレームワークに固有の規則に従って作成されなければならないということである。安全性の立証はフレームワーク全体に対して得られるのであって、特定のフレームワークに対して得られるのでなない。たとえば、上記ＴＴＰフレームワークにおいて、システムの「正常」な動作のために少なくとも４個のノードが要求され、相異なったＴＴＰノードにおけるプロセスの４つのインスタンスの写像(mapping)が、そのプロセスの利用者に、プロセスの結果が適宜利用可能であり正確であることを保証する。このアイディアは、物理的アーキテクチャのための一般的な立証手段が存在し、この立証手段が、安全性のデータフローにおける多くのインスタンスと、システムに内蔵されている機能とに応じて特定化しているということである。
【０００７】
他のアイディアを挙げるならば、その中において安全性重視フレームワーク、ＳＩＦＴ、が設計されているプロジェクトが下記非特許文献３に引用されている。
【０００８】
このＳＩＦＴプロジェクトにおいては、いくつかの独立な計算チャネルが有り、その計算チャネルは、近似的に同期して動作する、それぞれに専用のプロセッサを持ち；センサのような単一発信源からのデータは各チャネルに、ビザンチン（すなわち、非同期）故障(Byzantine (i.e. asynchronous) faults)に強い形で配信され、それによって、良好なチャネルは正確に同一の入力データを得；すべてのチャネルは同じアプリケーションのタスクを同じデータに基づいて近似的に同時に実行し、その結果は、アクチュエータに送られる前に、正確一致多数票決(exact-match majority voting)に送られる。
【０００９】
これは安全性重視フレームワークの良い説明例である。しかしながら、上記刊行物の後の方の節には、応用がまったく言及されていないこと注意されたい。このフレームワークは、原子力プラント、スペースシャトル、またはコーヒー・マシンにまで使うことができるように見える。そこで、たとえ、このＳＩＦＴフレームワークがフライト制御システムをサポートするために構築されたとしても、設計者は、その上で、彼らの、固定された複製、通信および票決規則に従う安全性重視アプリケーションを設計することができるような「良好な」安全性プロパティを備えた安全性重視フレームワークを設計することを望むであろう。
【００１０】
下記非特許文献５に記載された解析方法が議論されている。特定の故障の実際の影響が安全性の観点から回路の機能への影響に関連して考慮され、その深刻度(severity)の指標(indicator)が付される。一度指定された深刻度の指標は固定される。
【００１１】
従って、安全性重視システムを設計しベリファイする改良された方法の継続的な必要性があることが判り、そのような方法はそのシステムにおけるハードウエア・アーキテクチャの最適化を可能とする。
【非特許文献１】"Advanced Design and ValidationTechniques for ElectronicControl Units", Max Fuchs et al, SAE, 1998 SAE paper 980199 オンラインで入手可能：www4.informamatik.tu-muenchen.de/publ/papers/FEMPS98.pdf
【非特許文献２】"State charts: A Visual Formalism For Complex Systems", David Harel, Sciece of Computer Programming 8, Elsevier Science Publisher B. V (North Holland), 1987
【非特許文献３】"Formal Methods and Their Role in the Certification of Critical Systems", John Rushby, Technicalreport CSL-95-1, Computer Science Laboratory, SRI International, Menlo Park, CA, 1995
【非特許文献４】"The SystematicDesign of Embedded Real-Time Systems", H. Kopetz, Lecture notes, Hermann Kopetz, 1996; また "Real Time Systems: Design Principles for Distributed Embedded Applications", H. Kopetz, publishedby Kluwer Academic,1997
【非特許文献５】"IEC 61508: Functional safety of electrical/electronic/programmable electronicsafety-related systems", International Electrotechnical Commission (IEC), 1998
【非特許文献６】"System Engineering for Time TriggeredArchitectures",(SETTA).DeliverableD7.3 Final Document,version 1.0", XP-002264808, 18 April 2002.これは URL を経由して見られる: "http:www.setta.org"
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、安全性重視システム(safety crytical system)の設計とベリファイすること(verification)のための改良された方法と技術的補助手段とを提供することであり、特に、互いに接続された複数の電気デバイスのためのシステムのアーキテクチャを製作する改良された方法を提供することである。
【課題を解決するための手段】
【００１３】
本発明は、互いに接続された複数の電気装置からなるシステムのアーキテクチャを製作する方法を提供し、前記システムは、望ましくは、フォールト・トレラント(fault tolerant)なシステムからなり、
前記方法は、
a)一組の望ましくないイベントを識別(identify)し、前記望ましくないイベントのそれぞれに、それぞれの深刻度(severity)の指標(indicator)を付ける(ascribe)ことを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考える(associate with)ことを含み、
c)前記アーキテクチャのインプリメンテーション(implementation)のために提案された最初のアーキテクチャの機能仕様(functional specification)を開発する(develop)ことを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフロー(dataflow)と該構成要素間のデータフローとを含み、前記構成要素は、例として、センサまたはアクチュエータを含み、
前記方法は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられた(associated with)フォールト・トレランス(fault tolerance)の要求条件を洗練(refine)し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信すること(issuing)を含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記方法は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定する(define)ことを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像(mapping)することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイ(verify)することを含む。
【００１４】
フォールト・トレランス要求仕様を洗練する(refine)ことは、本発明によって提供される優位性に、特に、それがシステムのアーキテクチャの設計とベリファイのための規模拡大可能な(scalable)プロセスである場合に、貢献する。
【００１５】
この方法は、望ましくはステップ(c)において、一連のオペレーションのモード、たとえばノミナル(nominal)・モードとリンプ-ホーム(limp-home)・モード、を定義することを含んでいてよい。
【００１６】
この方法は、前記一連のオペレーションのモードを１つまたは複数のステート・チャート(state chart)の形で特定化することを含んでいてよい。
【００１７】
この方法は、ハードウエア構成要素を幾何学的写像すること、および／または、配線し、それから、前記幾何学的写像によって前記独立性の指標が保持されていることを自動的にベリファイすることを含んでいてよい。
【００１８】
この方法は、深刻度を単位時間当たりに故障が起こる確率として特定することを含んでいてよい。この方法は、前記システムのアーキテクチャ製作のための１組のデータを出力することを含んでいてよい。そのアーキテクチャは車両のためのアーキテクチャ、たとえばブレーキ・システムのための制御回路のような、安全性重視アーキテクチャからなっていてよい。
【００１９】
本発明は、また、コンピュータ読み取り可能なメモリであって、その上にシステムのアーキテクチャ設計とベリファイのためのプログラムをエンコードしてあり、そのプログラムは本発明の方法を実施するためのコードを含んでいるメモリを含む商品を提供する。
【００２０】
本発明は、また、その上にコンピュータ・プログラム・コード手段を持つコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品を提供し、前記プログラムがロードされるとコンピュータ・プログラム・コード手段はコンピュータにシステムのアーキテクチャ設計とベリファイの手順を実行させ、
前記手順は、
a)一組の望ましくないイベントを識別(identify)し、前記望ましくないイベントのそれぞれに、それぞれの深刻度(severity)の指標(indicator)を付ける(ascribe)ことを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考える(associate with)ことを含み、
c)前記アーキテクチャのインプリメンテーション(implementation)のために提案された最初のアーキテクチャの機能仕様(functional specification)を開発する(develop)ことを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフロー(dataflow)と該構成要素間のデータフローとを含み、前記構成要素は、例として、センサまたはアクチュエータを含み、
前記手順は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられた(associated with)フォールト・トレランス(fault tolerance)の要求条件を洗練(refine)し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信すること(issuing)を含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記手順は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定する(define)ことを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像(mapping)することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイ(verify)することを含む。
【００２１】
本発明は、また、システムのアーキテクチャ設計とベリファイに適合した設計ツールを提供し、前記設計ツールは本発明の方法のステップを実行することに適合しているか、または、本発明に従ったコンピュータ・プログラム製品を用いてプログラムされている。
【発明の効果】
【００２２】
本発明の実施により、互いに接続された複数の電気デバイスのためのシステムのアーキテクチャを製作する改良された方法を提供することが可能となる。
【発明を実施するための最良の形態】
【００２３】
本発明は、これから、例示の方法のみによって、いくつかの実施例を引用し、上述の図面を参照して記述されるであろう。
【００２４】
機械部品の安全性はその部品の物理的性質と化学的性質とをマスタすることによって得られる：これは、われわれが「マテリアル・レジスタンス」と呼ぶものであり、膨大な経験を伴った進んだ知識領域である。電子部品の安全性は、冗長度と票決を通じて得られる、結果の信頼性のレベルの実証(proof)は、機械部品の世界で可能であるのに比べると、得るのが不便であることが明らかになるかもしれない。
【００２５】
「複製(replicate)」とその派生語について引用しよう。複製とは、一般的術語として、プロセス・データフローとハードウエア・デバイスとの冗長度を持った空間または時間ドメインにおけるインプリメンテーションのことである。たとえば、センサの複製は同じ構造と同じ機能とを持つ物理的複製、たとえば、同じ生産ラインから作り出された別の部品であろう。データフローの複製は、もとのデータフローが運ぶ情報と同じ情報を、問題としているシステムの設計トレランスに十分に適合する正確さとサンプリングレートで運ぶ他のデータフローであろう。複製情報は、複製の目的が、単に、その情報が健全な(sound)ものであることを保証することを目的とした場合に、部分的につくられるものであろう。たとえば、繰り返し冗長度チェック（ＣＲＣ）は、チェックされるプログラムの空間における部分的複製であると考えられるであろう。
【００２６】
われわれは、本発明において、設計者が同じ値を算出するのに異なったメカニズムを提供するときの機能的複製と、単一の情報源から全体または部分情報をコピーすることによって得られる複製とを区別するであろう。われわれは、機能的複製は、機能的アーキテクチャにおいて、同じ源(source)からのいかなる複製が実行されるよりも前に、取り扱われることを考慮するであろう。われわれの発明は主に同じ源からの複製を取り扱うが、機能的複製から来る要請をも考慮する。
【００２７】
時間と空間における複製は計算の信頼性を改善するための好ましいツールであるので、複製された情報を一緒に集め、一組のプロセスの、誤りかもしれない結果の中から正しい値を決定することもまた必要である。情報の収集は、常に、空間あるいは時間におけるある種の票決にある。票決には異なったアルゴリズムが存在し、われわれは、特定のアルゴリズムが、それぞれの種類の票決（２、３または４個の複製間；そしてフェイル・サイレントまたはフォールト・トレラントの計算）に対して選定されていると仮定する。冗長度は異なった形：空間、時間そして両方の高いかあるいは低い巧妙度の組合わせで用いられるであろうことに注意されたい。われわれは、特定の電子部品の高レベルの安全性を仮定することができないときに冗長度を必要とする。われわれは、これから一組の複製の安全性について論議しよう。
【００２８】
故障(fault)は対称または非対称でありうる。非対称故障は「ビザンチン(Byzantine)」と呼ばれている。異なる電子制御ユニットが同じ情報（異なった情報源からか否かにかかわらない）の複製を受けたとき、われわれは、それらの電子制御ユニットが相互に連絡し合って、それらのユニットが実際に同一の情報を得たことを確認した事実を「アグリーメント(agreement)」と呼ぶ。一致は、また、この技術分野において「コンセンサス(consensus)」としても知られている。
【００２９】
「ビザンチンアグリーメント」は、プロセス間での連絡のコンテキストの中で明確化される。プロセスＡが初期値“１”でスタートし、プロセスＢが初期値“０”でスタートし、プロセスＣが初期値“０”でスタートする、と想像しよう。プロセス全体は同一の数値に収斂することを望み、各プロセスは、究極の多数票決を行い同一の数値に収斂するために、それぞれの初期値を他の２つのプロセスへ送信する。もしも、ＡとＢが正しければ、それらは、それぞれ、“１”と“０”を送信する。Ｃがビザンチンであるとは、Ｃが誤った非対称な情報をＡとＢに送ることを意味する。これが、非対称がビザンチンを表す理由である。たとえば、Ｃは、Ａには“０”を、Ｂには“１”を送るかもしれない。この場合には、正常に働いているＡはＢとＣから“０”を受取り、“０”を結論とするであろう。正常に働いているＢはＡとＣから“１”を受取り、“１”を結論とするであろう。そこで、結論として、３つの無故障プロセスは、１つのビザンチン故障の存在のために１ラウンドではコンセンサスに到達しない。しかしながら、数ラウンドの後には、もしもそのような補足ラウンドを時間制約が許すならば、コンセンサスが得られることが可能である。
【００３０】
典型的なビザンチンエラー源は、過渡的な短絡回路や誘導効果の存在下では、一般に受入れられている尺度(measure)である。サンプリングがいつ実行されるかに正確に依存して、同じ時間内における捉え方の違いで実際の信号は大きくも小さくもなる。
【００３１】
他の典型的なビザンチンエラー源は、同期アルゴリズムのコンテキストにおけるクロックである。クオーツ・ジッタや通信遅延によって、あるクロックが他のクロックに相反する情報を送るかもしれない。
【００３２】
ビザンチン故障（非対称故障とも呼ばれる）は、１ラウンドでコンセンサスに到達するために、高レベルの冗長度を要求する。しかしながら、ほとんどの時間において、非対称故障は設計において考慮されていない、それは、非対称故障が、多くのの場合に、過渡的であって、「巨視的」な物理的数値に基づいて作業しているときには無視することができるからである。
【００３３】
われわれが非対称故障を考慮すると決めるか否かにかかわらず、本発明の方法は平等に適用される。複製の個数と冗長度「戦略」とが対称故障の場合と異なるだけである。対称故障の例は、コミュニケーション・バスの「オフ」、マイクロ−コントローラのシャットダウンまたはクラッシュ、フューズの溶断、そして、多分もっと一般に、「死んだ」電気部品である。
【００３４】
電子的な安全性アーキテクチャが構成され、特定の物理的アーキテクチャおよびアプリケーション・ドメイン用にチューニングされている。すでに検討したように、原子力プラント、車両および航空機は高度の技能を持った技術者によって設計された高価なシステムの例であり、それらは規模拡大可能(scalable)でも柔軟(flexible)でもない。これらのシステムのために、階層制のアプローチ、すなわち、装置・レベルのアプローチが最初で、それからソフトウエア・レベルのアプローチ、が伝統的に用いられてきていている。この考えは、目的に合った物理的装置を同定し、それから、各ノードにおけるソフトウエアを記述するルールを提供することである。
【００３５】
決定論は安全性重視システムにとって安心できるプロパティであり、決定論は理想主義的であるので、われわれは、「レプリカ決定論」を考え、そのレプリカ決定論においては、１つの部品の異なった複製は、「実の(real)」時間の間だけ、常に「同じ状態」になるとする。ここで、「実の」時間は理論的な概念であり、それは、「同じ状態」が、われわれは数学ではなく物理学を扱っているので、「等しいと考えられることに十分に近いこと」を示している。レプリカ決定論を得るには、最も多く存在する安全性システムはタイム・トリガードである。グローバル・クロックのアイディアは故障：時間故障の完全なカテゴリをスキップすることを許す。完全に対称なアプローチは、時間故障が修繕(fix)され、そして、精度故障が修繕されるような世界における「分割と克服(divide and conquer)」アプローチを許す。実際に、決定論は、安全性重視フレームワークの強制的なプロパティである、何故かというと、そのようなフレームワークは、決定論が無ければ、設計と実証が非常に困難となり、ほとんど不可能であろうからである。
【００３６】
１９８５年に刊行された論文、“Impossibility of distributed consensus
with one faulty process"(１つの故障プロセスを伴う分散されたコンセンサスの不可能性）は、もし、相異なる分散されたプロセス（それは、異なったＣＰＵにおいて異なった周波数で進行するプロセスを意味する）の間の情報伝達の速さについての仮定がなされなければ、コンセンサスの問題は解けないであろうと、議論している。この論文の結論は、プロセス間での情報交換が同期していないシステムを設計する場合には、或る同期化の手段が必要であるということである：少なくともクロック・スピードについての仮定が期待される。望むらくは、これは、内蔵システムへの適用において常に実現することであり、したがって、少なくとも理論的には、非同期のフォールト・トレラントのシステムを設計することは不可能ではない。
【００３７】
コンファインメント(confinement)は、安全性重視フレームワークの、その他の非常に重要なプロパティである、一般的で高価な規則は、異なったフォールト・トレラントの要求を持ったシステムが、フォールト・トレラントではないシステムが不用意に開発されるであろうという仮定と、本質的でない機能の設計の誤りが安全性システムの故障の理由であるということは受け入れられないという仮定の下で、混じり合うことを避けることである。
【００３８】
故障は、しばしば、一時的であり、過渡的ですらある。故障を持っていた構成要素は、ある時間の後には故障を持っていないかもしれない。電子制御ユニット（ＥＣＵ）のホット・リセットは良い実例である。もしも、或る理由で、或るＥＣＵが正常に動作していないときに、このＥＣＵをリセットし、システムの動作中においてさえも、ふたたび、正常に動作させることが一般に可能である。これは、故障は一時的でありうることを意味する。そこで、故障の確率は単位時間当たりとして特定され、これは、決定的な故障と一時的な故障との両方に適用できる。
【００３９】
一時的故障の概念に関連して、診断は、構成要素またはシステムの信頼性を動的に補強する方法と見られることができ、それは、また、構成要素の種類を変えることを許す。たとえば、電子制御ユニットの構成要素が正常に動作していないこと、あるいは、他の電子制御ユニットが正常に動作していないこと検出して、ホット・リセットを始動させることができる。診断は、また、定常的なエラーを一時的なエラーにに変換することを許す。われわれの応用の目的には、われわれは、診断を、応用の一部分または機能的アーキテクチャへの要求仕様に適合する方法であると考える。
【００４０】
他の古典的な安全性重視設計システム技術は異なったソース(source)によるインプリメンテーションである。しかしながら、開発チームが、技術が設計誤りを避けるための強力な方法であるとする同じ考えを持っているので、同じ設計誤りを含んだソフトウエアのよく知られた例がある。このことは、ハードウエアにも当てはまる；われわれは、安全性重視システムの異なったノードに同一のマイクロプロセッサを使うことを避けるべきである。こうすれば、一方で、マイクロプロセッサのうちの１つが故障を起こす確率は広がるが、同時に２つのマイクロプロセッサが故障を起こす確率は大幅に低くなる。
【００４１】
われわれは、非特許文献３おいて定義された設計誤りに言及するつもりはない。設計誤りに基づく事例は、ブレーキ操作のための誤った制御規則であり、それは、或る状況の下では、全くブレーキをかけることに至らないというようなことであろう。むしろ、われわれは、健全な機能設計を正確にインプリメントする問題に注目したい。異なったソースによる複製をインプリメントすることは、設計誤りにうまく対処する優れた方法である。
【００４２】
いわゆるフェイル・セーフ・システムにおいて、システムが機能の一部または全部までも失っても、利用者が、装置を操作できたり、装置を安全と定義されている既定の状態に持っていけるようなオペレーションのモードが存在することは評価されることであろう。たとえば、トラックのブレーキは、加圧空気システムによってオフ位置に保たれるであろう。もしも、加圧空気システムに故障、たとえばパイプ破損、があれば、空気は洩れ出して、ブレーキはオン状態となり、システムが利用者をトラック操縦可能にはしないにしても、この状態は予め安全と定義されている状態である。
【００４３】
故障が起こっても動作を続けるシステム(フェイル・オペレーショナル(fail-operational)システム)には、システムが機能の一部または全部までも失っても、利用者が、装置を操作できたり、装置を安全と定義されている既定の状態に持っていけるようなオペレーションのモードは存在しない。このようなシステムにおいては、最低レベルの運行が要求される。
【００４４】
フェイル・サイレント(fail-silent)な構成要素とは、その構成要素が内蔵されたシステムに故障が起こると動作を行わなくなる（サイレントになる）ような構成要素のことである。これは定性的な定義である。この定義は、われわれが、システムに故障が起こったときに、その構成要素がサイレントになる確率を特定することによって定量的になることが判る。たとえば、われわれは、１時間稼働中に１０−９の確率で起こるような故障が起こった場合にサイレントになるフェイル・サイレントな構成要素を対象としてよいであろう。フェイル・サイレントな構成要素は２つの故障が起こったときにサイレントになってもよい。単にフェイル・サイレントと言った場合には、それは、１つの故障が起こったときにサイレントになることを意味する。
【００４５】
フォールト・トレラントな構成要素は、その構成要素が内蔵されているシステムに故障が起こっても、あるレベルでの運行を行うような構成要素である。この定義は、フェイル・サイレントな構成要素の場合と同様に、故障の個数と故障が起こる確率が特定されている場合に拡張される。
【００４６】
安全性重視システム設計において、たとえばフェイル・セーフまたはフェイル・オペレーショナルの場合に、われわれは、多くの場合に、フェイル・サイレントなアクチュエータを考える。これは、少なくとも１つまたは２つのフェイル・サイレントなアクチュエータを考慮に入れることができるようなシステムレベルでのフォールト・トレランスを意味する。もしも、或るアクチュエータがフェイル・サイレントであることが証明されることができなければ、われわれは、そのようなアクチュエータの故障に対してシステム補償を用意する。たとえば、車両のブレーキの１つにおける、車両の安定性の減少に直結する、異常なブレーキ応力を推定することは可能である。このようなことは受入れられない。しかしながら、反対側の車輪に等価のブレーキ応力を印加することは、或るレベルでのブレーキ動作につながるであろう、これは、要求されたブレーキ動作とは異なるけれども、車軸の両側の応力配分は本質的に均等となり、それ自体望ましいことではないが、安全性の観点からは、不均等な応力配分に比べれば、明らかに受入れやすいことである。そのような、通常行う、正常な機能の一時的変更は、しばしば、リンプ-ホーム(limp-home)・モードという名で引用される。多くの電子部品にとって幸いなことに、フェイル・サイレントな挙動を保証することが、ほとんど常に、可能である。それは、電流が切られたときに、アクチュエータが受動的になることを保証するだけで十分であるからである。これは、典型的に、ＡＢＳコントロールに許された解決方法である。
【００４７】
自動車への応用の分野において、大規模流れ生産のため、われわれは、部品信頼性の定量的尺度を持っていて、それは、実に優れていて、冗長度を用いる場合の、高水準の信頼性を証明するのに十分である。不幸なことに、これとは別の厳しい制限はコストであり、それは、不必要な冗長度を回避し、特に、ハードウエアのレベルにおいて、すぐに再発するコストとなってしまう。電線によるブレーキ操作(Brake-by-wire)または電線による操舵(Steer-bu-wire)のような、安全性重視システムの応用分野は、われわれの発明のプロセスに特に適している、というのは、われわれは、コストと安全性との間のトレードオフの柔軟な関係を提供し、また、本発明の方法の基礎を作ることができ、それによって、われわれは、現実的な部品信頼性に基づく設計手法を生み出し、その手法は、航空工学領域や列車運送領域で設計されるシステムにわたって決定的な優位点となるからである。
【００４８】
本発明の方法によれば、われわれは、一片のコードの正しさや、いかに忠実に数学的関数をエンコードしたかを考慮しない。安全性システムの制御規則を取り扱う際に、信号の遅延や信号処理の正確さが問題にならないように、物理的システムの動作周波数よりも十分に速いペースでソフトウエアと情報通信とを働かせることは一般に可能であるということが起こる。このようなことが起こらない場合には、最適化はずっと困難になるであろうけれども、われわれのプロセスは、安全性への要求は満たされることがもっと困難であるように見えるにもかかわらず、健全な状態を維持する。
【００４９】
われわれの設計プロセスにおいては、われわれは、時間故障と価値故障とを区別しない、なぜかというと、われわれは、どちらの故障も正確性故障であると考えるからだある。センサの場合は、冗長度と、票決と、時間故障と価値故障とを同様に扱ってよいこととを議論する上で、特に興味深い。説明の道筋において、われわれは、ここで、特に図１Ａと１Ｂとを引用して、或るフォールト・トレランスの要求を持っているセンサＳを考慮する。
【００５０】
或る機能の或る複製ｆにおいて、そのような複製はセンサＳの複製であるセンサＳ１、Ｓ２およびＳ３からのデータを使わなければならない。これらのセンサは、それぞれのデータフローＤ１、Ｄ２およびＤ３を通して情報を提供することを仮定しよう。簡単のため、また、範囲を限定する例とはしないということで、センサＳ１、Ｓ２およびＳ３はブレーキ・ペダルの位置を測るものであるとしよう。
【００５１】
さらに、第１近似として、信号は２値であるとしよう。信号が高ければ、それは運転者がブレーキをかけていることを意味し；信号が低ければ、それは運転者がブレーキをかけていないことを意味するとする。入力に対して或るフィルタリングが遂行され、５００マイクロ秒毎の５つのサンプルから数値が計算される。フィルタリングは、それがいくつかのサンプルから数値を作ることを意味するので、一種の冗長度であることに注意されたい。これは、ペダル・スイッチが低ければ、スイッチの検出結果が実際に誤りなく伝えられる前には、１．５ｍｓが必要であることを意味する。
【００５２】
ここで、われわれは、アーキテクチャにおけるＤ１、Ｄ２およびＤ３の伝播遅延を考慮しなけならない。センサＳ１、Ｓ２およびＳ３によるデータの補足は、３つの、異なるクロック；クロック１、クロック２およびクロック３を持つ、相異なるマイクロコントローラの上で行われるとする。そこで、データフローＤ１、Ｄ２およびＤ３は、実際に、電子制御ユニット（ＥＣＵ）と通信バスによって構成された複雑な電子的アーキテクチャを通って進む。Ｄ１の動作には５ｍｓ+/-３ｍｓ；Ｄ２の動作には８ｍｓ+/-４ｍｓ、そして、Ｄ３の動作には１０ｍｓ+/-２ｍｓが、種々のクロック・ドリフトと種々のジッタとを含めて、要求されると考えよう。さらに、以下のように考えよう：
Ｄ１は５ｍｓ＝毎にクロック１＊Ｎ１サイクルで送られ、Ｄ２は５ｍｓ＝毎にクロック２＊Ｎ２サイクルで送られ、Ｄ３は５ｍｓ＝毎にクロック３＊Ｎ３サイクルで送られる；
クロック１、クロック２およびクロック３は３％よりも少ない変動を持つ；そして
“ｆ" を計算するタスクは１ｍｓ以内に、５ｍｓ毎に遂行される。
【００５３】
われわれは、ｆによって受け取られたＤ１、Ｄ２およびＤ３の最後の３つのサンプルを比較すると仮定し、それらをＤ１ｆ、Ｄ２ｆおよびＤ３ｆと呼ぼう。そのとき、問題は：運転者による実際のペダル・ブレ−キの要請の後に、いつ、ブレ−キの要請の同定に収束するか？ということである。
Ｄ１ｆは古さ(age)が範囲Ｒ１[-15,545ms..-11,5ms]の範囲内にある信号を代表する
1,5ms + 5ms+ (0,003*5ms) + 1ms + 5ms + 3ms = 15,515ms
Ｄ２ｆは古さ(age)が範囲Ｒ２[-19,545ms..-14,5ms]の範囲内にある信号を代表する
1,5ms + 5ms+ (0,003*5ms) + 1ms + 8ms + 4ms = 19,515ms
Ｄ３ｆは古さ(age)が範囲Ｒ３[-19,545ms..-16,5ms]の範囲内にある信号を代表する
1,5ms + 5ms+ (0,003*5ms) + 1ms + 10ms + 2ms = 19,515ms
範囲Ｒ１とＲ２とが共通範囲を持たないことは、われわれが観測する現象の頻度がサンプリングの頻度の桁よりも大きな桁のオーダーである限りは、問題ではない。もしも、われわれが見つけようとしている信号が２０ｍｓよりも低いか、それと同じオーダーの頻度で進展するものであれば、われわれのサンプリングは無意味となる。人間の行動の場合には、頻度はむしろ数百ミリ秒の範囲内にあり、そして、ブレ−キ・ペダルの場合には、通常、軽いブレーキについては確かに１００ｍｓを超え、ペダルは少なくとも１秒間は踏まれている。
【００５４】
ここで、図１Ｂを参照して、いかに、サンプリングと情報通信とが「実」時間の間に行われるかを見ることができる。Ｄ１、Ｄ２およびＤ３の数値は、実際の数値が捕捉されてから長くても２０ｍｓの後には受け取られていることを考慮に入れれば、故障の個数が１を上回る場合を除いて、Ｄ１、Ｄ２およびＤ３の間のいかなる票決の計算も１つの結果に到達するであろうことがわかる。上記と同様のことが、ブレ−キ・ペダルが解除されるときにも当てはまる。
【００５５】
もし、われわれが、“ｆ”が５ｍｓ毎（最悪の実行時間に基づく最大１ｍｓの遅延を伴う）に予定されていることを考慮に入れるならば、“ｆ"は、正確なブレーキ・コマンド“Ｏ”を、ブレーキの要求が検知されてから最長２６ｍｓの後には、生成するであろうことが判る。ブレーキを解除する場合も同様である。
【００５６】
ここで、われわれは、ペダル・ブレ−キの要求を表すものとして、ブール代数的信号ではなく、整数を用いることを考えよう。このとき、次のようなアルゴリズムが使われるであろう：Ｄ１、Ｄ２、Ｄ３の一番新しい数値が“ｆ"によって受け取られ、２つの極端な数値が除外される（われわれはただ１つの故障を考える）。われわれは、比較する異なった数値は正確に同じ時に捕捉されたのではないことに気を付ける、たとえば、古さ(age)の違いは１０ｍｓになりうる。もしも、われわれが、各センサの精度を知っていて、１０ｍｓ以内のペダル・ブレ−キの動きが許される範囲内であると考えるならば、アルゴリズムは健全である。
【００５７】
もしも、強いブレーキをかけるコンテキストの中で許されるならば、数値を、先行する３つの数値との間で平均をとることによってフィルタし、コマンドに「慣性」を与えることも可能である。そのようなフィルタリングの詳細なインプリメンテーションは、しかしながら、ペダルのアーゴノミクスの問題であり、われわれの本発明の視野外にある。
【００５８】
実際の設計において、他のフィルタが導入されてもよく、それは、われわれの例において応答時間をさらに改善するであろう。ブレーキシステムの場合には、もしもわれわれが、出力“Ｏ"がエレクトロメカニカルな構成要素によって２４ｍｓ以内に実行されるブレーキの命令であると考えるならば、それは、ペダルブレーキ操作の要求尺度のパーセンテージとして特定化されるであろう正確度をもつ実際の要求が発せられてから最大でも５０ｍｓ後に、ブレーキ操作がスタートすることを意味する。
【００５９】
われわれの部分的ブレーキ・システムは、ともかく、「同期的」("synchronous")である：われわれの包括的な時間は運転者の行動ペースである。ここに、われわれが示したのは、分散システムは、デッドラインを保証するためにタイム・トリガードである必要はないことである。また、時間誤差は、数値的確度誤差と異なって考えられなくてもよく、伝播する情報のエージングが与えられた確度で制限されている限りにおいて、確度範囲と言い替えてもよい。そのとき、信号が遅れているということは誤差であると考えられてよい。たとえば、バスのノードが常に無制御状態で情報伝達をする、「夢想愚者」("bubbling idiot")として知られているデータ・バスの古典的デフォルトがある。これは、アクセスとトラフィックを無駄にし、通常は、バス上でのメッセージを遅らせる。
【００６０】
本発明に従ったわれわれのアプローチへの入力は、機能的モードと機能的安全性解析とを伴った機能的設計である。これは、下記のステップを実行することによって得られる：
ａ）一組の好ましくないイベントを識別すること(identifying)と、それらの好ましくないイベントの各々にそれぞれの深刻度(severity)を表す指標(indicator)を付けること(ascribing)；
ｂ）それらの好ましくないイベントの各々を、可能な範囲で、機能的設計によって提案されたシステムのアーキテクチャにおける１つまたは複数のアクチュエータに関連させること(associating)；
ｃ）そのシステムのアーキテクチャのインプリメンテーションのために提案された初期アーキテクチャの機能的仕様(specification)を開発すること(developing)、その初期アーキテクチャの機能的仕様は、それについての構成要素へのデータフローと構成要素間のデータフローとを含み、その構成要素は、たとえば、センサまたはアクチュエータを含む；そして
ｄ）前記機能的仕様における、前記好ましくないイベントの深刻度に関連したフォールト・トレランスの要求を洗練すること(refining)と、前記機能的仕様における、洗練されたフォールト・トレランスの要求を発信すること(issuing)。
【００６１】
設計手法のインプリメンテーションの過程においては、機能的仕様の複製が、それらの複製の独立性を表す指標と、洗練されたフォールト・トレランスの要求を反映する指標とを付けられて作られる。設計プロセスは、また、提案されたシステムアーキテクチャ、たとえば、一連の相互にネットワークで接続された電子制御ユニットのためのハードウエア構造を限定し、それから、機能的仕様をそのハードウエア構造の上に写像(map)する。
【００６２】
このプロセスは、これらの独立性を表す指標を、写像(mapping)中に、自動的にベリファイすることを含む。このようにして、設計プロセスは、出力過程において、提案されたシステムアーキテクチャが、或る、すでに定義された安全性への要求条件に合致するか否かをの確証(proof)を得る。もしも、この確証が、システムが特定された安全性への要求条件を満足することを示したときには、それはテストのための実証(validation)モデルへの入力として用いられる。
【００６３】
設計プロセスのさらなる出力は、各構成要素に適用される、究極的にシステムを構築する際には実証されなければならない一連の局所的要求条件であろう。これは、さらに下流に向かっての入力として使われるデータの形をしていて、最終的には、一連の、機械製造用の構成要素との共同作業、または、そのシステムアーキテクチャに使われる回路のレイアウトにおける用途に適した指示に移行する(translate)であろう。
【００６４】
本発明の利点の中に、安全性概念の抽象があり、その抽象は、分割と克服(divide and conquer)のアプローチを可能とする。これは複雑なシステム・デザインのための鍵である。さらに、われわれは特定の技術、バス・プロトコルまたはいかなるあらかじめ定義された安全性設計のフレームワークを頼りにしない。そうではなくて、われわれのアプローチにおいては、ＴＴＰのようなフレームワークは「パラメータ」として見ることができ、それは、われわれが、フォールト・トレラント・システムを、既存のフォールト・トレラント技術なしに、作り出すことさえもできることを意味する。換言すれば、われわれが発明し、開示した方法は、既存のフレームワークを考え、比較することを許すけれども、また、それらを結合させる方法を提供する。上記の点は、前に述べたように、異なる技術を結合することは設計誤りを避ける最善の方法であるので、特に興味深い。
【００６５】
われわれは、ここで、特別の、しかしこれに制限されない、図２における車両のスピードの検出と、図３Ａないし５において図示された方法論を用いた抽象における取り扱いとを参照する車両のブレーキ操作に関連する例を考える。この設計プロセスの概要は図６に示されている。
【００６６】
図２において、機能「車輪スピード計算」405はデータフロー“Ｖ”403を、車輪スピードセンサ401からの入力として持つ。提案されたインプリメンテーションにおいては、同じ車輪スピードセンサ420が１つのＥＣＵ436に接続され、機能「車輪スピード計算」405はＥＣＵ434において実行される。
【００６７】
機能的アーキテクチャからの車輪スピードセンサ401は、ハードウエア・アーキテクチャからの車輪スピードセンサ420に変換される(矢印410)。機能的アーキテクチャからの機能「車輪スピード算出」405は、ＥＣＵ434上の実行可能なプロセスに変換される(矢印412)。車輪センサ401と機能「車輪スピード計算」405との間のデータフローは複雑な道筋に移行し、その道筋は下記を含む：
・ＥＣＵ436、434、そして、それらそれぞれのコネクタ428、432；
・ネットワーク430；
・リンク422、426；そして
・コネクタ424。
【００６８】
図３Ａにおいて、機能“Ｆ”603は,少なくとも１つの入力データフロー“i”601と１つの出力データフロー“ｏ”605を持つ。他の入力と出力とは、簡単化のために、描かれていない。
【００６９】
"Ｆ”とその入力と出力とは、フォールト・トレランス特性のタグをつけることができる：611、613および615。タグ“ＦＴ(Ｆ)”(613)は、機能“Ｆ”に対しるフォールト・トレランスの要求条件が存在することを意味する。これは直感的に、"Ｆ”のインプリメンテーションは、異なるＥＣＵそれぞれの上に複製を要求し、一組の入力が与えられたときに、たとえ１つの故障が起こっても、"Ｆ”の処理(process）実行の大部分が行われるようにするであろうことを意味する。"ＦＴ(ｏ)”(615)は、データフロー“ｏ”に対してフォールト・トレランスの要求条件が存在することを意味する。"ＦＴ(i)”(611)は、データフロー“i”に対してフェイル・サイレントの要求条件が存在することを意味する。
【００７０】
本発明において述べられた処理に従えば、タグＦＴ(ｏ）は或る、データフロー"i”を消費する機能に対する安全性要求条件（の結果）に比較して劣性である。図３Ｂにおいて、システム設計者は、"ｏ”に対する安全性要求条件から、"Ｆ”はフォールト・トレラントであり、"i”はフェイル・サイレントであろうと推論する。
【００７１】
本発明のさらに先の処理のステップにおいて、われわれは、図３Ｃにおいて、データフロー“i”と"ｏ”は、タグ611、613および615によって特定された安全性要求条件に対処するために複製されることを見ることができる。図３Ｃにおいて、複製は１つの対称的故障に対して定義される。これは、１つのフォールト・トレラントな構成要素に対してただ３つの複製が要求され、１つのフェイル・サイレントな構成要素に対してただ２つの複製が要求されることを意味する。
【００７２】
図３Ｃにおいて、Ｆ１ 641、Ｆ２ 643、Ｆ３ 645は、機能“Ｆ”の複製であり、ＦＴ(ｏ)１ 651、ＦＴ(ｏ)２ 653、655はデータフロー“ｏ”の複製であり、ＦＳ(i)１ 621、625、629およびＦＳ(i)２ 623、627、631はデータフロー“i”の複製である。
【００７３】
図３Ｃにおいて、データフローＦＴ(ｏ)１は、Ｆ２とＦ３とにおいて、"ｏ２"(624）と“ｏ３"(626）とで処理(process）され、Ｆ１において、入力ＦＳ(i)１とＦＳ(i)２との“ｏ１”で処理される。この処理の遂行に当たって、票決手順(vote procedure）がＦＳ(i)１とＦＳ(i)２と間と、"ｏ１"、"ｏ２"(624）および“ｏ３"(626）の計算の間に適用されるであろう。さらに一般的な実施例においては、ＦＴ(ｏ)１は、単に、Ｆ１によって処理された“ｏ１”、"ｏ２"(624）、“ｏ３"(626）よりなるトリプレット(triplet）であろう。この場合に、票決はＦＴ(ｏ)１を消費する任意の機能によって遂行することができる。
【００７４】
“ｏ３"(626)と“ｏ３"(632)とは、同じ物理的道筋を通らないので、異なった形で誤るので、相異なることに注意されたい。そこで、われわれは、Ｆ３で処理され、Ｆ１で受け取られる“ｏ３"(626)と、Ｆ３で処理され、Ｆ２で受け取られる“ｏ３"(632)とを区別する。
【００７５】
Ｆ１の処理をするとき、"ｏ２"(624）と“ｏ３"(626）と十分に最近に計算される必要があり、上記の票決前の“ｏ１”、"ｏ２"(624）、“ｏ３"(626）の計算が、上記のブレーキ・ペダルの要求条件の例のように、時宜を得た形で、実行されたことの正当化が存在するべきである。それらのサンプリングとエージングとは、データフロー“ｏ”における正確さに関して（"w.r.t."）健全であるべきである。このような正当化は、タイム-トリガード・システムのコンテキストにおいて、より簡単であり、これが、タイム-トリガード・システムが、電子部品のコストが問題にならないほとんどの場合（短いインスタンスの場合）に用いられる理由である。
【００７６】
フェイル・サイレントなオブジェクトの２つの複製は、１つの対称的故障が同時に誤差を生じえない場合に、１つの対称的故障に対して自由であるといわれる。対照的な例としては、図３Ｄにおける“Ｇ”は、機能“Ｇ”の処理における誤差は潜在的に x1 と x2 とに誤差を生じるので、データフロー x1 673 と x2 675 は連結されている場合を示す。
【００７７】
フォールト・トレラントなオブジェクトの３つの複製は、１つの対称的故障が同時に１つ以上の複製において誤差を生じえない場合に、１つの対称的故障に対して「自由」であるといわれる。
【００７８】
１つの整数を“k”としたときに、フォールト・トレラントなオブジェクトの "2k+1" 個の複製は、“k”個の対称的故障が同時に１つ以上の複製において誤差を生じえない場合に、“k”個の対称的故障に対して「自由」であるといわれる。
【００７９】
これらの定義は、データフローに対するように、正確に適用され、処理の誤差は間違った実行であり、フローの誤差は間違った情報伝送であるかまたは情報不伝送である。或る誤差が検出できるか否かということは、設計者がデータフローにタグを付ける際に気がつくことである。
【００８０】
Ｆやその他のオブジェクトの複製を作ることに付随して、任意のオブジェクトの複製間の「自由性(freeness)」の要求条件が生成される。これは、好ましくは自動的に実行されるが、結局は複製と票決の戦略に依存するであろう
図３Ｃにおいて、データフローＦＴ(ｏ)１ 651、ＦＴ(ｏ)２ 653およびＦＴ(ｏ)３ 655は自由せあるべきであり、それは、或る１つの故障が、同時に、これらの１つよりも多いフローにおける誤差を生じえないことを意味する。
【００８１】
同様に、
- ＦＳ(i)１とＦＳ(i)２とは自由であり、
- Ｆ１、Ｆ２、Ｆ３は自由であり、それは、単一の故障は、複数の複製の
処理中に同時に故障を生じえないことを意味し、
- Ｆ２に送られたデータフロー "ｏ１"(622)と Ｆ３に送られたデータフ
ロー "ｏ１"(628)とは自由であり、
- Ｆ２で作られた "ｏ２" と、Ｆ３で作られた“ｏ３" とは自由である。
【００８２】
他の複製のスキームがインプリメントされることが可能であり、それらに付けられた自由性の要求条件は異なるであろう。例えば、非対称故障を容認するシステムに対しては、４つの複製がＦに対して必要であろうが、ただ１つの対称故障のみが許されるような例においては、図３Ａないし３Ｄにおけるように、３つの複製が必要なだけである。
【００８３】
自由性は、複製が同一源からのコピーであるかぎり、局部的なプロパティである。もしも、フォールト・トレラントな入力が、データフローの３つの機能的複製（例えば“d、e、f”であって、それらは設計者によって提案され、同じ結果を得る異なった計算方法）の間の票決に基づくものであれば、“d、e、f”は自由であり、１つの故障は他の２つにインパクトを与えないことを保証するであろうし、このときには、自由性のプロパティは局部的ではなくなる。設計者によって提供された３つの独立なデータフローが「自由」であるということは、それらのうちの２つについての計算のいかなる段階にも関与するオブジェクトは存在しないことを意味する。このようなプロパティは大変に証明することが困難であり、その理由は、そのような証明には機能的アーキテクチャ全体が関ってくることにある。タグを付ける前の機能的アーキテクチャと複製であって、本発明に係る方法において実施される、設計プロセスの最初の部分となるものについては、上記の証明を行うことができる。そしてまた、機能的複製の解析から得られた自由性の要求条件は機能的アーキテクチャに適合すべきでろうし、ハードウエア・アーキテクチャ上に写像されるであろう。
【００８４】
項目 621 ないし 655 からなる機能的アーキテクチャを物理的アーキテクチャに写像するときに、自由性の要求条件は、インプリメンテーション後に、満たされるべきである。これは、ハードウエア・アーキテクチャにおいて写像を受けた構成要素は同じ自由性の要求条件を満たすことを意味する。図４Ａないし４Ｄにおいて、われわれは、ハードウエア・アーキテクチャ上へのフェイル・サイレントな機能の写像を説明している。われわれは、図３Ａないし３Ｄにおけるのと同じ処理のステップを開始する。
【００８５】
第１のステップ（図４Ａ）において、項目 701 ないし 705、機能“Ｊ”705 が、入力データフロー“k”701 と出力データフロー“i”701 によって、特定化される。
【００８６】
第２のステップ（図４Ｂ）において、項目 711 ないし 715、アクチュエータからセンサまでからの逆行性解析の後、機能Ｊと、その入力と出力の流れに安全性の属性のタグ（Ｊには（713)、"k”には（711)、"i" には（715）)を付けられる。"ＦＳ(Ｊ)" 713 は、Ｊがフェイル・サイレントであるべきであり、故障が起こった場合に、ＦＳ(Ｊ)は、フォールト-フリーな処理の結果を送るか、または、何も送らないかのいずれかであることを示す。
【００８７】
第３ステップ（図４Ｃ）において、項目 721 ないし 725、複製と自由性の要求条件とが、要求された安全性のレベルを提供するために、特定化される。例えば、インスタンス i１ と i２ とは自由であり、機能Ｊ１とＪ２とは自由であるとする。
【００８８】
第４ステップ（図４Ｄ）において、冗長度のある機能的アーキテクチャが、ＥＣＵとネットワークとからなるハードウエア・アーキテクチャの上に写像される。機能Ｊ１はＥＣＵ 741 で処理され、機能Ｊ２はＥＣＵ 743 で処理される。われわれは、このインプリメンテーションにおいては、Ｊ１とＪ２は自由であることをチェックできる。しかしながら、データフロー "i１" と "i２" が、設計者によって、通信バス上に写像されたとすると、 "i１" と "i２" の自由性の条件もはや満足されない、というのは、１つの故障（バスはオフである）が、"i１" と "i２" の両方の誤りの下位にあるからである。そこで、"i１" をバス 745 で送り、"i２" をバス 747 で送るのが、自由性の条件に明らかに適合するために、より健全である。
【００８９】
冗長度のある機能的アーキテクチャをハードウエア・アーキテクチャの上に写像する過程において、われわれは、安全性と自由性の要求条件を洗練することに進むことに注意されたい。例えば、"i１" と "i２" とが自由であるという要求条件は、これらの流れのインプリメンテーションが自由であるという要求条件となり、これはさらに複雑な条件である。
【００９０】
もしも、これから、構成要素が故障する確率を考えるとしたら、フォールト・トレラントのシステムの設計はさらに正確である。自由性の条件は確率を使って特定化される。
【００９１】
ここで、"p”を、ある期間において、ある故障が、データフロー "i１" と "i２" の両方の故障を生じる最大の許容しうる確率であるとしよう。確率 "p”は、いくらか、 "i１" と "i２" の自由性の程度を表している。それは、また、システム（および、特に、機能Ｆ）が、故障が起こったときに、フェール・トレラントでない確率でもある。
【００９２】
そこで、もしも、フロー "i１" と "i２" が、故障確率が "p”よりも小さいバスに送られとしたとき、自由性の条件は満たされる。もしも、反対に、"p1”がバス 745 の故障確率であり、"p2”が バス 747 の故障確率であるすると、p1*p2 が "p”よりも大きければ、自由性の要求条件は満たされず、もっと信頼性の高い設計が要求される。
【００９３】
図５に、われわれは、タグをつけることと、安全性要求条件とが、機能を組み合わせたときに、どのように安定化するかを説明する。この様子は、非常にに重要であり、その理由は、これがわれわれの「分割と克服」アプローチのための鍵となるものであり、そこにおいて、システム上で実証さるべきすべての安全性要求条件が一組の処理または一組のデータフローが自由であることの証明に帰着するからである。
【００９４】
このことは、もしもわれわれが、ＦとＧとの合成（ＦｏＧ）に対する安全性要求条件を持つとしたとき、これは、一方ではＦとＧとの間のフローの安全性要求条件の結果であり、他方では他の機能についてのＦとＧとの安全性要求条件の結果であることを意味する。結局は、システムがフォールト・トレラントであることを証明することは、機能のレベルにおけるいくつかの簡単な証明であることが判明する。或る複雑なシステムが或る安全性要求条件を満たすことを証明することは、そのシステムにおける各機能が、システムレベルにおける安全性要求条件から洗練(refine)された「局部的な」安全性要求条件を満たすことを証明することと等価である。例えば、機能の１００セットの複製および/または５つのＥＣＵに写像されたデータフローが自由であることを証明することは、各セットの複製が自由であることを、それぞれに、証明することからなるであろう。この安全性要求条件の合成的性質は、「分割と克服」アプローチのための鍵であり、このことは、結果として、規模拡大可能(scalable)である。
【００９５】
図３Ａないし３Ｄと４Ａないし４Ｄにおける例は、図３Ａないし３Ｄと４Ａないし４Ｄにおいて、機能が結合されたときに、いかに、解析が結合されるかを示すために、図５に付加されている。これは、いくつかの機能を含む複雑なシステムに対して、いかにものごとが扱われるかを知るのに役立つ。
【００９６】
機能ＪとＦが結合されるときに、データフロー 601 と 705 とは、それらが同じデータフロー "i" を表しているので、等価とされる。もしも、いくつかの機能がデータフロー "i" を消費するならば、"i" に対する安全性要求条件は、"i" を消費する各機能から受け継がれた安全性要求条件の最大値である。そこで、複製の個数とその信頼性は、また、同じ方法で計算される。
【００９７】
逆に、もしも、１つのデータの３つの複製が利用可能であるならば、例えば、フォールト・トレランス要求条件が特定化されているので、このデータは或る、安全性要求条件を持たない機能によって消費される。これは、その機能を計算するために１つの複製を選びだすのに十分である。他方、３つの複製が存在している場合に、これは、少なくとも１つのフォールト・トレラントな機能の複製が３つのデータフローの複製のすべてを消費するであろうからである。
【００９８】
図５における輪郭 821 は、図３Ａないし３Ｄと図４Ａないし４Ｄに示された機能ＦとＪの合成を説明している。データフロー "i" に対して、一方でデータフロー 725、他方でデータフロー 621、625 および 629 が等価とされていることに注意されたい。同様に、一方でデータフロー 735、他方でデータフロー 623、627 および 631 が等価とされている。
【００９９】
もしも、われわれが、ＦとＪの合成であるＦｏＪを考えるならば、ＦｏＪへの自由性の要求条件に適合することは、一方で輪郭 821 内でのＦとＪとの間の自由性の要求条件と、他方で輪郭 821 外でのＦ、Ｊそれぞれの自由性の要求条件とに適合することを意味する。
【０１００】
そこで、機能的アーキテクチャは、アクチュエータからセンサまでの繰り返しで、回帰的に完全にタグ付けられる。そして、機能的複製は、自由性の要求条件とともに、生成されることができる。そのような生成は、もしも、複製の戦略がフォールト・トレランスの各レベルに対して標準的である場合には、自動的に実行されることができるに注意されたい。例えば、すべてのフェール・サイレントな機能が、多くても１つの故障が存在する場合に、図４におけるＪと同様な方法で複製される。
【０１０１】
冗長度のある機能的アーキテクチャが（複製生成の後に）ハードウエア・アーキテクチャの上に写像されれば、最適化は、いかなる機能に対しても、インプリメンテーションが高価でないデータフローの複製からなる。例えば、機能Ｆが、３つの複製、i1、i2およびi3を伴うデータフロー "i" を消費するとする。Ｆが、入力 "i" から、いかなるフォールト・トレランスのプロパティも要求しない場合を考えよう。そうならば、"i" の複製の１つは消費されなければならない。もしも、例えば、インスタンス i1 が、処理Ｆを行うＥＣＵ上で利用可能であり、i1 が他のＥＣＵ上で利用可能であれば、Ｆへの入力としては i1 を選ぶのがよい。
【０１０２】
図６において、フォールト・トレラントなアーキテクチャの設計プロセスの好ましい実施例が本発明に従って記載されている。このプロセスは以下のステップを含む。
１ 望ましくないイベントとその重要性(gravity)の識別(identification)。
２ 実または仮想のセンサとアクチュエータによって構成されたシステムの機能
仕様決定(functional specification)。
３ リンプ-ホーム・モード(limp-home modes)の記述。
４ 望ましくないイベントを実または仮想のアクチュエータと関連づけること
(association)。
５ 機能的アーキテクチャの上での望ましくないイベントの洗練(refinement)。
６ 安全性要求条件の洗練(refinement)とともに冗長度の導入。
７ ハードウエア・アーキテクチャの定義。
８ 電子制御ユニット上へ機能を写像すること。
９ 結果として生じる電子的アーキテクチャのフォールト・トレランスをベリフ
ァイすること。
１０ 物理的構成要素の幾何学的写像と配線。
１１ 結果として生じる電気-電子的アーキテクチャのフォールト・トレランス
をベリファイすること。
【０１０３】
このプロセスは線形(linear)であることは意図されていない。少数のループが表現(presentation)に隠されている。例えば、ステップ６は相異なる、多くのやり直しを誘起するであろう経路で実行されてもよい。また、相異なるハードウエア・アーキテクチャが、ステップ７において、与えられたフォールト・トレラントの要求条件の下において、より高価でないアーキテクチャを見つけることのゴールとして、調査されるであろう。ステップ８において、別の写像が、特に、ステップ９が、或る写像が満足すべきものではないことを立証し、さらなる作業を要求するときに、調査されるであろう。また、ステップ１０において、別の場所(location)のノードが調査されるであろう。図６に示された新しいプロセスのステップは、これから、詳細に、記述されるであろうが、古典的技術の様態は、ここでは、完全に詳細には記述されない。
【０１０４】
１．望ましくないイベントとその重要性(gravity)の識別(identification)
このステップはよく知られている、機能的故障解析(Functional Failure Analysis)（ＦＦＡ）のステップであり、ＦＦＡは安全性解析の古典的部分である。或るシステムに対するＦＡＡの結果は望ましくないイベントを、そのイベントが起こったときの結果の深刻度(severity)とともに識別することである。
【０１０５】
２．実または仮想のセンサとアクチュエータによって構成されたシステムの機能仕様決定(functional specification)
このステップは、例えば図２に関連して上記された技術を用いて遂行されるであろう。
【０１０６】
この段階において、われわれは設計欠陥(design fault)を洗練(refine)することができ、このことはすでに言及した。
【０１０７】
３．リンプ-ホーム・モード(limp-home modes)の記述
モードの記述は、機能的アーキテクチャを補足するものである。或るシステムは、制御-自動機械(control
automata)、例えば、ステート・チャート(state chart)によって構成されるとして記述されることができ、ステート・チャートはデータフローをトリガ(trigger)する（上記非特許文献１参照）。最高のレベルにおいて、自動機械はシステム・ノードをインプリメントしなければならず、システム・ノードとしては、初期化、ノミナル・モード、リンプ-ホーム・モード、および、或るモードから他のモードへのスイッチ機能がある。
【０１０８】
例えば、車両のブレーキ・システムの場合に、もしも前左のブレーキが機能せず、他のブレーキは正常に働いているとすると、ブレーキをかけることは、車両の安定性の損失を結果として生じ、このことは、多くの場合に、ブレーキをまったくかけないよりも悪いことになる。そこで、その場合に、信頼できるリンプ-ホーム・モードは、前右のブレーキと後左のブレーキの、両ブレーキへの適切なブレーキ圧力によるブレーキングであろう。その場合に、車両の速さは結果的に減少し、車両は安定な状態に留まるであろう。
【０１０９】
安全性重視システムにおいては、リンプ-ホーム・モードは、多くの場合に、或る故障のためにノーマル・モードが利用できない場合に、低級な働きを提供することにあるであろう。これは、われわれが図６において出発するステップである。
【０１１０】
４．望ましくないイベントを実または仮想のアクチュエータと関連づけること(association)と状態遷移（図６のステップａ））
われわれのプロセスにおいて、われわれは、ＦＦＡの結果の部分のみを考える。各望ましくないイベントに対して、われわれは、関連のあるアクチュエータ、すなわち、他のアクチュエータは正常に機能しているのに、そのアクチュエータの故障が望ましくないイベントを生じるアクチュエータを考える。例えば、車両のブレーキ・システムに対しては、われわれは、望ましくないイベントは、「ブレーキ操作における安定性の欠如」と考えることができる。これは、アクチュエータの１つがブレーキ操作をしていず、他のアクチュエータがブレーキ操作をしている場合に、可能であろう。もしも、われわれの目標が、システムが１つの故障に対してトレラントであることにあるならば、或る解析が、例えば、安全性の欠如はアクチュエータの１つの故障によるとの結論に導くかも知れない。その場合に、われわれは、「ブレーキ操作中の安定性の欠如」を各ブレーキ・アクチュエータのみと関連づける(associate)ことであろう。いま、われわれが、望ましくないイベントを「ブレーキ操作が要求されているのにブレーキをかけないこと」と考えるならば、アクチュエータのいずれもが、この望ましくないイベントが明らかにすべてのブレーキに関連づけられるような健全なコマンド受け取っていないことは明白である。
【０１１１】
しかしながら、われわれのブレーキ・システムは、制御自動機械によってトリガされ、ブレーキをかける要求は、その制御自動機械の移行(transition)であり、その制御自動機械は「ブレーキ」状態へ導くと仮定しよう。もしも、その移行が正常に遂行されないときには、ブレーキが正常に働いているとしても、望ましくないイベントが起こるであろう。そこで、或る望ましくないイベントは、或る状態の移行に、もしも、その状態の移行の故障が上記の望ましくないイベントを引き起こす場合には、、結びつけられる(attached)であろう。ステップの終わりにおいて、望ましくないイベントの各々は、１つまたは少数の、アクチュエータまたは状態の移行の結果の組合わせに結びつけられるであろう。
【０１１２】
深刻度のレベルについての可能性のある引用例は上記非特許文献５において提供されている。深刻度に応じて、１つまたは２つの故障が存在するときに、フェイル・サイレントまたはフォールト・トレランスのレベルが、故障を受け取ることの予測される確率とともに、予期される。
【０１１３】
電気的ブレーキ・システムの場合には、アクチュエータは「フェイル・サイレント」であることが要求され、ブレーキが、それが機能しない物理的状態に置かれうることが確証されなければならない。もしも確率が予期されるのであれば、われわれは、電気的ブレーキが、単位時間における確率 "p"("p"は非常に小さく、例えば、１時間当たり１０−８である）の場合を除いて、それが機能する物理的状態に置かれるということができるであろう。
【０１１４】
５．機能的アーキテクチャの上での望ましくないイベントの洗練(refinement)
スタート 901 において、機能的アーキテクチャはセンサ、アクチュエータおよびデータフローで構成され、いくつかのデータフローは電流をモデル化し、バッテリーはセンサとしてモデル化され、前のステップ（ａ）において、望ましくないイベントが識別され、アクチュエータと結びつけられる；設計技術者は、それから、彼がフェイル・サイレントを期待するのか、フォールト・トレラントを期待するのか、なにも要求しないのかを、各アクチュエータの異なった入力の流れから、その隔離されたアクチュエータに付随する望ましくないイベントに応じて示すことができる。
【０１１５】
ブレーキ・システムの場合に、例えば、ブレーキ単独では故障してはいけないという要求があるときには、各ブレーキのブレーキ力命令はフォールト・トレラントとして特定できる。しかしながら、設計者は簡単に、ブレーキ・システムが故障が検知された後に十分に速やかに反応するならば、フェイル・サイレントの要求で十分と考えるかも知れない。このタギング(タグをつけること)は、アーキテクチャとその性格に依存する。
【０１１６】
繰り返し、われわれは、機能とセンサとの安全性要求条件を、各機能とその機能に関連する望ましくないイベントに同様の解析を適用して、決定する。
【０１１７】
もしも、機能がデータフローを生成し、そのデータフローが機能的アーキテクチャを通して、一組のアクチュエータの制御に直接貢献するならば、われわれは、その機能について、アクチュエータの組のなかの一部に関連付けられている望ましくないイベントの全てを、前記機能とそれへの入力に対する安全性要求条件を確立するために、考えなければならない。さらに、われわれは、その機能に対して、その出力への制限が、その出力を消費する機能についての以前の安全性解析からもたらされることもまた考えなければならない。図５において、例えば、機能Ｆの出力への要求条件 615 は、機能Ｆの入力への要求条件 611 を含んでいる。これは、機能Ｊについても当てはまり、機能Ｆの以前の解析が、機能Ｊの出力と機能Ｊ自体の制限とへの要求条件 711 を含んでいる。
【０１１８】
ステップ（ｂ）において、われわれは、その出力または関連する望ましくないイベントが処理されてない一組の機能を計算する。
【０１１９】
ステップ（ｃ）において、（ｂ）において計算された機能に対して、われわれは解析する：
i)入力についてどのような新しい安全性要求条件が求められているか；そして、
ii)機能それ自体に対して、どのようなレベルの安全性が要求されているか（フォールト・トレランス(ＦＴ)、フォールト・サイレンス(ＦＳ)、なにも要求しない(Ｎ))。
【０１２０】
われわれは、それから、ステップ 907 と 911 をたどり、繰り返して、(b)と(c)とを、(b)の中が空でない限り、適用する。
【０１２１】
ステップ(e)において、各センサは、それが生成するデータフローに要求される最高レベルのフォールト・トレランスを取る。
【０１２２】
また、データフローへの安全性要求条件の洗練(refinement)は各モードで実行されるべきであり、それは、オペレーションの各モードは個別に考慮されなければならないからである。望ましくないイベントは、各望ましくないイベントに関連して、どの間違ったモード移行が巻き込まれるであろうかを考慮して、モード移行に適用されるべきである。モード移行は状態移行の特別の場合であることに注意されたい。ある移行に要求条件が設定された場合に、われわれは、アクチュエータの場合と同様に、正確に進む。
【０１２３】
モード移行は、それを活性化するような望ましくないイベントの下では失敗しないことが要求される。そこで、モード移行を引き起こす望ましくないイベントの各々に対しては、モード移行は、望ましくないイベントの深刻度に対応した安全性要求条件を受け継いでいて、その望ましくないイベントに結びつけられていなければならない。
【０１２４】
６．安全性要求条件の洗練(refinement)とともに冗長度の導入（図６における931）
それから、ステップ 931 において、それぞれの機能に対して、複製をインプリメントするように選ばれた機能のインプリメンテーションモードと、票決機構とが要求されれ、それは、それまでに生成された安全性要求条件に依存している。このステップにおいて、われわれはまた、図３Ａないし３Ｄ、４Ａないし４Ｄに示されているように、自由性条件を収集する。
【０１２５】
結果として生じる機能的アーキテクチャは、初めのものよりも大きい。フォールト・トレランスもフェイル・サイレントも、この段階では、仕様決定されず、機能的アーキテクチャは変化していないことに注意されたい。
【０１２６】
７．ハードウエア・アーキテクチャの定義
この段階において、われわれは電子制御ユニット（ＥＣＵ）と、システムをインプリメントするネットワークを特定する。安全性解析が定量的なコンテキストにおいては、各ハードウエア構成要素の予期される単位時間当たりの故障率が特定される。
【０１２７】
８．電子制御ユニット上へ機能を写像すること（933）
このステップにおいて、例えば図４において図解されているように、機能が電子制御ユニットに写像される。
【０１２８】
９．結果として生じる電子的アーキテクチャのフォールト・トレランスをベリファイすること（935）
このステップは、自由性条件のベリフィケーションからなる。このベリフィケーションは自動的に実行されることが可能である。例えば、自由性条件に結びつけられたデータフローは、設計ツールとしてプログラム化されたコンピュータに受入れらるようなデータベース中に記録されることができるであろう。データフローをインプリメントする構成要素も、また、類似のやり方でそのようなデータベース中に記録されることができるであろう。われわれは、それから、その設計ツールを用いて、いくつかの自由なデータフフローをインプリメントする構成要素が存在するか否かを、自動的に見いだす。
【０１２９】
本発明のプロセスをインプリメントするためのソフトウエアは役に立つように、コンピュータ読み取り可能なメモリのようなコンピュータ・プログラム製品中に、設計ツールとして動作するのに適合したコンピュータによる実行に適するコンピュータ・プログラムの形で記録されるであろう。そのコンピュータ・プログラム製品は、コンピュータ読み取り可能な媒体からなるであろう。そして、その媒体上には、コンピュータ・プログラム・コードが、そのプログラムがロードされたときに、それは、コンピュータに、システム・アーキテクチャを本発明の方法に従って設計し、ベリファイする手順を実行させるような形でエンコードされていてる。
【０１３０】
要求の出力はそのような構成要素のリストであることができ、その出力は、マニュアルまたは、物理的設計の提案されたアーキテクチャの強靱度の自動的チェックに適した形をしているであろう。確率が特定されている場合には、要求の出力は、予期された自由性条件の故障確率より低い信頼性を持った構成要素のリストであろう。
【０１３１】
１０．物理的構成要素の幾何学的写像と配線 (再び933)
このステップにおいては、配線の経路、コネクタおよび電子制御ユニット間のケーブル、バッテリー、センサ、アクチュエータおよびさらに一般な電気構成要素が特定される。
【０１３２】
１１．結果として生じる電気-電子的アーキテクチャのフォールト・トレランスをベリファイすること (再び935)
自由性のプロパティは、構成要素の写像を通じて洗練される：２つの配線Ｗ１とＷ２とが、それぞれ、データフローＤ１とＤ２を同一のコネクタＣに運んでいるとする。もしもＣが誤っているとすると、Ｗ１とＷ２の両方が、同じ誤りによって非接続となり、それは、自由性条件条件に関して、健全ではない。
【０１３３】
そこで、幾何学的写像の後で行われるべきベリフィケーションは、コネクタとケーブル（配線を集めている）に関係し、自由性条件は次のように洗練される：
−同じコネクタへ自由なデータフローを運んでいる配線を、確率が特定されている場合と、コネクタが誤っている確率が、要求されている自由性の誤りの確率よりも低い場合とを除いて、非接続とすること。
−集結し、１つのケーブル中で自由なデータフローを運んでいる配線を、ケーブル製造プロセスが、十分に低い確率にまで、短絡、断線の発生を抑えている場合を除いて、非接続とすること。
【０１３４】
配線中のデータフロー自由性条件は、新しい要求条件（不可能性要求条件）を生み出すであろう。これのベリフィケーションは自動的に実行される。例えば、自由性条件が結びつけられたデータフローは、設計ツールとしてプログラム化されたコンピュータがアクセスできるようなデータベース中に記録されることができる。構成要素をインプリメントするデータフローも、また、そのようなデータベース中に、類似の方法で、記録されることができる。われわれは、そのとき、その設計ツールを用いて、構成要素をインプリメントするいくつかのデータフローが存在しているか否かを自動的に見いだす。本発明のプロセスをインプリメントするためのソフトウエアは、有用な形で、コンピュータ読み取り可能なメモリに、その設計ツールとして動作するのに適合したコンピュータの実働のためのコンピュータ・プログラムの形で、記録されることができる。
【０１３５】
このようにして、本発明は、安全性重視システムの規模拡大可能な設計のための、方法ステップを持つ設計プロセスを提供することが明らかとなる。さらに、解析が、機能のレベルで遂行され、それから、異なるハードウエアのインプリメンテーションに用いられる。すなわち、例えば、提案されたハードウエアのインプリメンテーションが、他のものよりも、より高価でないか、および/または、より安全であるかを評価することに用いられる。
【図面の簡単な説明】
【０１３６】
【図１】図１Ａ、１Ｂは、１つのフォールト・トレランス装置を持つ複製の模式的図とグラフ的図である。
【図２】本発明の方法における１つの段階に従って、機能アーキテクチャをハードウエア・アーキテクチャの上に写像することを描いた図である。
【図３】図３Ａ〜３Ｄは、機能アーキテクチャのタグ付けの段階と本発明の方法に従った付加条件と複製へのタグの拡張を描いた図である。
【図４】図４Ａ〜４Ｄは、フォールト・トレランスの必要条件を、本発明の方法における１つの段階に従って、ハードウエア・アーキテクチャの上に写像することを描いた図である。
【図５】本発明の方法に従った機能構成によるフォールト・トレランスの必要条件の安定性を説明する図である。
【図６】本発明の方法に従った、フォールト・トレラントな電子的アーキテクチャの設計とベリファイの全体のプロセスを説明する図である。
【符号の説明】
【０１３７】
401、420：車輪スピードセンサ、422：リンク、424：コネクタ、426：リンク、428：コネクタ、430：ネットワーク、432：コネクタ、434、436：ＥＣＵ。
【特許請求の範囲】
【請求項１】
システムのアーキテクチャを生み出す方法であって、前記アーキテクチャは相互に接続された複数の電気装置を含み、前記システムは、望ましい例としてフォールト・トレラントなシステムを含み、
前記方法は、
a)一組の望ましくないイベントを識別し、前記望ましくないイベントのそれぞれに、それぞれの深刻度の指標を付けることを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考えることを含み、
c)前記アーキテクチャのインプリメンテーションのために提案された最初のアーキテクチャの機能仕様を開発することを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフローと該構成要素間のデータフローとを含み、該構成要素は、例として、センサまたはアクチュエータを含み、
前記方法は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられたフォールト・トレランスの要求条件を洗練し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信することを含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記方法は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定することを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイすることを含むことを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項２】
請求項１に記載のシステムのアーキテクチャを生み出す方法において、望ましくは前記 c)の段階において、ノミナル・モードおよびリンプ-ホーム・モードを例とする一連のオペレーションのモードを定義することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項３】
請求項２に記載のシステムのアーキテクチャを生み出す方法において、前記一連のオペレーションのモードを１つまたは複数のステート・チャートの形で明確化することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項４】
請求項１、２または３に記載のシステムのアーキテクチャを生み出す方法において、ハードウエア構成要素および/または配線に、写像を幾何学的に行った後に、前記独立性の指標が該写像に際して保存されていることを自動的にベリファイすることを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項５】
請求項１、２、３または４に記載のシステムのアーキテクチャを生み出す方法において、深刻度を、単位時間当たりに故障が起こる確率の形で特定することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項６】
請求項１ないし５のいずれかに記載のシステムのアーキテクチャを生み出す方法において、前記アーキテクチャを製造するために一組のデータを出力することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項７】
請求項１ないし６のいずれかに記載のシステムのアーキテクチャを生み出す方法において、前記アーキテクチャは、ブレーキ・システムのための制御回路を例とする安全性重視アーキテクチャを例とする、車両のためのアーキテクチャであることを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項８】
コンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品において、前記媒体は、コンピュータ・プログラムのコード手段を有し、前記プログラムがロードされたときに、前記コード手段は、コンピュータに、システムのアーキテクチャを設計し、ベリファイする手順を実行させ、
前記手順は、
a)一組の望ましくないイベントを識別し、前記望ましくないイベントのそれぞれに、それぞれの深刻度の指標を付けることを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考えることを含み、
c)前記アーキテクチャのインプリメンテーションのために提案された最初のアーキテクチャの機能仕様を開発することを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフローと該構成要素間のデータフローとを含み、前記構成要素は、例として、センサまたはアクチュエータを含み、
前記手順は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられたフォールト・トレランスの要求条件を洗練し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信することを含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記手順は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定する(define)ことを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイすることを含むことを特徴とするコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品。
【請求項９】
システムのアーキテクチャの設計とベリフィケーションに適合した設計ツールであって、前記設計ツールは、請求項１ないし７のいずれかに記載のシステムのアーキテクチャを生み出す方法における各段階のインプリメンテーションに適合するか、または、請求項８に記載のコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品を用いてプログラムされることを特徴とする、システムのアーキテクチャの設計とベリフィケーションに適合した設計ツール。
【請求項１】
システムのアーキテクチャを生み出す方法であって、前記アーキテクチャは相互に接続された複数の電気装置を含み、前記システムは、望ましい例としてフォールト・トレラントなシステムを含み、
前記方法は、
a)一組の望ましくないイベントを識別し、前記望ましくないイベントのそれぞれに、それぞれの深刻度の指標を付けることを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考えることを含み、
c)前記アーキテクチャのインプリメンテーションのために提案された最初のアーキテクチャの機能仕様を開発することを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフローと該構成要素間のデータフローとを含み、該構成要素は、例として、センサまたはアクチュエータを含み、
前記方法は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられたフォールト・トレランスの要求条件を洗練し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信することを含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記方法は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定することを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイすることを含むことを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項２】
請求項１に記載のシステムのアーキテクチャを生み出す方法において、望ましくは前記 c)の段階において、ノミナル・モードおよびリンプ-ホーム・モードを例とする一連のオペレーションのモードを定義することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項３】
請求項２に記載のシステムのアーキテクチャを生み出す方法において、前記一連のオペレーションのモードを１つまたは複数のステート・チャートの形で明確化することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項４】
請求項１、２または３に記載のシステムのアーキテクチャを生み出す方法において、ハードウエア構成要素および/または配線に、写像を幾何学的に行った後に、前記独立性の指標が該写像に際して保存されていることを自動的にベリファイすることを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項５】
請求項１、２、３または４に記載のシステムのアーキテクチャを生み出す方法において、深刻度を、単位時間当たりに故障が起こる確率の形で特定することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項６】
請求項１ないし５のいずれかに記載のシステムのアーキテクチャを生み出す方法において、前記アーキテクチャを製造するために一組のデータを出力することを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項７】
請求項１ないし６のいずれかに記載のシステムのアーキテクチャを生み出す方法において、前記アーキテクチャは、ブレーキ・システムのための制御回路を例とする安全性重視アーキテクチャを例とする、車両のためのアーキテクチャであることを特徴とするシステムのアーキテクチャを生み出す方法。
【請求項８】
コンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品において、前記媒体は、コンピュータ・プログラムのコード手段を有し、前記プログラムがロードされたときに、前記コード手段は、コンピュータに、システムのアーキテクチャを設計し、ベリファイする手順を実行させ、
前記手順は、
a)一組の望ましくないイベントを識別し、前記望ましくないイベントのそれぞれに、それぞれの深刻度の指標を付けることを含み、
b)前記望ましくないイベントのそれぞれを、可能性がある場所において、前記アーキテクチャの１つまたは複数のアクチュエータに結びつけて考えることを含み、
c)前記アーキテクチャのインプリメンテーションのために提案された最初のアーキテクチャの機能仕様を開発することを含み、前記最初のアーキテクチャの前記機能仕様は、構成要素へのデータフローと該構成要素間のデータフローとを含み、前記構成要素は、例として、センサまたはアクチュエータを含み、
前記手順は、
d)前記機能仕様において、各前記望ましくないイベントの深刻度に結びつけて考えられたフォールト・トレランスの要求条件を洗練し、洗練された、前記機能仕様のフォールト・トレランスの要求条件を発信することを含み、
e)前記機能仕様において、複製と該複製に付けられた該複製の独立性の指標とを作り出すことを含み、前記独立性の指標は前記洗練されたフォールト・トレランスの要求条件を反映し、
前記手順は、
f)前記システムのアーキテクチャのための、相互にネットワークで接続された一連の電子制御ユニットを例とする、ハードウエア構造を限定する(define)ことを含み、
g)前記機能仕様を前記ハードウエア構造の上に写像することを含み、
h)前記独立性の指標が、写像の過程において、保存されることを自動的にベリファイすることを含むことを特徴とするコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品。
【請求項９】
システムのアーキテクチャの設計とベリフィケーションに適合した設計ツールであって、前記設計ツールは、請求項１ないし７のいずれかに記載のシステムのアーキテクチャを生み出す方法における各段階のインプリメンテーションに適合するか、または、請求項８に記載のコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品を用いてプログラムされることを特徴とする、システムのアーキテクチャの設計とベリフィケーションに適合した設計ツール。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００７−５２８５３２（Ｐ２００７−５２８５３２Ａ）
【公表日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願番号】特願２００６−５４８５７０（Ｐ２００６−５４８５７０）
【出願日】平成１７年１月１３日（２００５．１．１３）
【国際出願番号】ＰＣＴ／ＩＢ２００５／０５０７０１
【国際公開番号】ＷＯ２００５／０６９０８９
【国際公開日】平成１７年７月２８日（２００５．７．２８）
【出願人】（５０３０４１７９７）ルノー・エス・アー・エス (286)
【Ｆターム（参考）】
【公表日】平成１９年１０月１１日（２００７．１０．１１）
【国際特許分類】
【出願日】平成１７年１月１３日（２００５．１．１３）
【国際出願番号】ＰＣＴ／ＩＢ２００５／０５０７０１
【国際公開番号】ＷＯ２００５／０６９０８９
【国際公開日】平成１７年７月２８日（２００５．７．２８）
【出願人】（５０３０４１７９７）ルノー・エス・アー・エス (286)
【Ｆターム（参考）】
[ Back to top ]