JP2005518992A - システムにおける安全性を判定し，かつその安全性を得るための装置，方法および対応するコンピュータプログラム - Google Patents

Abstract

特に自動車内で，システムにおける安全分析を実施する方法であって，複数のシステムまたは少なくとも１つのシステムが複数のコンポーネントから構成され，前記複数のコンポーネント間に通信関係が存在し，前記複数のコンポーネントおよび前記通信関係によって前記複数のシステムまたは前記少なくとも１つのシステムの機能構造が形成され，前記機能構造に依存するエラーが求められ，前記機能構造に関する前記エラー依存性が評価される。

Description

本発明は，独立請求項の上位概念に記載された，製品開発の早期の段階において，特に自動車内の，システムの安全性を判定する装置，方法および対応するコンピュータプログラム，コンピュータプログラム製品に関する。独立請求項の上位概念に相当するカテゴリーの方法は，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析（ＣＳＡ）と称され，それに応じて装置によって，またはコンピュータプログラムを実施する際に，実施される。

製品開発サイクルを短縮しながら，同時に安全性と信頼性に対する増大する要請を満たすことは，自動車産業だけにおける挑戦ではない。このような状況では，製品開発の間の極めて早い時期にすでに，安全に対する分析を考慮することが必要となる。プランニングの開始から市場導入までの期間が短いということは，製品をライバルより前に市場に定着させるために，決定的な競争上の利点となる。製品開発の早い段階において安全分析を考慮することによって，製品開発の進んだ段階において製品をテストして改良するための時間のかかる反復が減少し，理想的な場合にはそのような反復を回避できる。早期の開発段階においては，システムの考察方法は抽象的である。すなわち，システムがどの機能を満たすべきか，そしてこれらの機能がどのように協働するかは認識されているが，これらの機能がどのように実現されるか（たとえばハードウェア，ソフトウェア，機構）はまだ決定されていない。この抽象的な見方は，自動車メーカーおよび納入者ニュートラルな構造化コンセプトＣＡＲＴＲＯＮＩＣ（登録商標）によって示すことができる。この構造化コンセプトは，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析のための基礎を形成する。

特に，自動車というシステムの複雑さが増すことは，一方では個々のサブシステムの複雑さと数が増すことにあるが，そのネットワーク化の増大によっても著しく影響を受ける。自動車というシステムの複雑さを支配することは，他のサブシステムとの相互作用を考慮して，ＣＡＲＴＲＯＮＩＣ（登録商標）に基づくサブシステムの構造化によって達成される。

ＣＡＲＴＲＯＮＩＣ（登録商標）構造化コンセプト（Ｂｅｒｔｒａｍ， Ｔ．； Ｂｉｔｚｅｒ， Ｒ．； Ｍａｙｅｒ， Ｒ．； Ｖｏｌｋｈａｒｔ， Ａ．； １９９８，ＣＡＲＴＲＯＮＩＣ−Ａｎ ｏｐｅｎ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｎｅｔｗｏｒｋｉｎｇ ｔｈｅ ｃｏｎｔｒｏｌ ｓｙｓｔｅｍｓ ｏｆ ａｎ ａｕｔｏｍｏｂｉｌｅ（自動車のコントロールシステムをネットワーク化するためのオープンアーキテクチャ），Ｄｅｔｒｏｉｔ／Ｍｉｃｈｉｇａｎ ＵＳＡ， ＳＡＥ ９８２００を参照）は，オブジェクト指向の考え方に基づいている。自動車というシステムは，論理的な機能ユニットに構造化されて，それらが標準化されたインターフェイスを介して互いに通信する。

ＣＡＲＴＲＯＮＩＣ（登録商標）は，車両のすべての開ループ制御および閉ループ制御システムのための構造化コンセプトである。このコンセプトは，取り決め可能な形式的な構造化およびモデル化規則に基づく「機能」と「安全性」のためのモジュール状の拡張可能なアーキテクチャを有している。

ここでアーキテクチャとは，構造化システム（規則）でもあり，それを具体的な構造に変換することでもある。機能アーキテクチャは，車両内で生じるすべての開ループ制御および閉ループ制御の課題を包含している。システム複合体の課題は，いわゆる機能的なコンポーネントに対応づけられ，コンポーネントのインターフェイス（機能的なインターフェイス）とその協働が決定される。安全アーキテクチャは，機能アーキテクチャを，システム複合体の確実な駆動を保証するエレメントだけ拡張する。

他の表示形式は，ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｌｉｎｇ Ｌａｎｇｕａｇｅ）へコピーすることによって得られる，それがさらに，コンピュータシステムの管理を容易にする。ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造をＵＭＬモデルへコピーすることは，（Ｔｏｒｒｅ Ｆｌｏｒｅｓ， Ｐ．； Ｌａｐｐ， Ａ．； Ｈｅｒｍｓｅｎ， Ｗ．； Ｓｃｈｉｒｍｅｒ， Ｊ．； Ｗａｌｔｈｅｒ， Ｍ．； Ｂｅｒｔｒａｍ， Ｔ．； Ｐｅｔｅｒｓｅｎ， Ｊ．； ２００１， Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ ａ ｓｔｒｕｃｔｕｒｉｎｇ ｃｏｎｃｅｐｔ ｆｏｒ ａ ｖｅｈｉｃｌｅ ｃｏｎｔｒｏｌ ｓｙｓｔｅｍ ｉｎｔｏ ｔｈｅ ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｐｒｏｃｅｓｓ ｕｓｉｎｇ ＵＭＬ ｍｏｄｅｌｉｎｇ ｍｅｔｈｏｄｓ（車両コントロールシステムのための構造化コンセプトをＵＭＬモデリング方法を使用してソフトウェア開発プロセス内へ統合すること）， Ｄｅｔｒｏｉｔ／Ｍｉｃｈｉｇａｎ ＵＳＡ， ＳＡＥ ２００１−０１−００６６）に記載されている。

構造化のための基本装備が，機能的なコンポーネントを形成する。機能的なコンポーネントは，自動車というシステム内の機能を表している。コンパクトに表示するために，以下においては，機能的なコンポーネントという概念の代わりに，単にコンポーネントという概念が使用される。コンポーネントは，開発の経過と共に細分（細目化）され，その場合に上位に配置されている機能は覆いとして残される。上位に配置されている機能は，細分（細目化）の内部で再び，上位に配置された機能の個々の部分を表すコンポーネントから構成される。構造化コンセプトにおいて，３つの異なるタイプのコンポーネントに区別される：
□主に調整し，かつ分配する課題を有するコンポーネント，
□主として作戦的かつ実施する課題を有するコンポーネント，
□もっぱら情報を形成し，かつ用意するコンポーネント

通信関係においては，命令（フィードバックを含む），照会（指示を含む）および要請の間で区別される。命令を特徴づけるのは，実施する義務である。つまり，命令を満たすことができない場合には，命令の受け手は命令の送り手へ命令を満たせない理由をフィードバックしなければならない。照会は，命令実施のための情報の形成に用いられる。あるコンポーネントが照会された情報を用意できない場合には，そのコンポーネントは照会したコンポーネントへ指摘を与える。要請は，機能が他のコンポーネントによって実施される，という「希望」を記述する。要請には，もちろん満たす義務はなく，そのことはたとえば要請が競り合っている場合に考慮される。表１は，構造エレメントを要約して示している。

・・・（表１）

構造化規則は，車両全体のアーキテクチャの内部で許される通信関係を規定する。同一の抽象的なレベルにおける通信関係およびより高いレベルとより低いレベルにおける通信関係を，与えられた周辺条件を考慮して定める構造化規則が区別される。さらに，構造化規則は通信関係を他の機能性の細部へ伝えることを明らかにする。

構造化およびモデリング規則に従って開発された構造は，次の特徴によって特徴づけられる：
□すべての抽象レベルにおける，取り決められた統一的な構造化およびモデリング規則，
□階層的な命令フロー
□個々のコンポーネントの高い自己責任
□操作エレメント，センサおよび評価装置は，等価の情報マスターであり，かつ
□各コンポーネントを残りのコンポーネントのために，必要な程度に見えるように，かつ可能な限り見えないように表す，カプセル化

従って，特に自動車内で，少なくとも１つのシステムの改良された安全分析および改良された安全構造の形成を可能にする，方法と装置および対応するコンピュータプログラムとコンピュータプログラム製品を提供するという，課題が設定される。

本発明は，特に自動車内で，システムにおける安全分析を実施するための装置，特にコンピュータシステム，コンピュータプログラム，コンピュータプログラム製品および方法に関するものである。その場合に複数のシステムまたは少なくとも１つのシステムが複数のコンポーネントからなり，それら複数のコンポーネントの間に通信関係が存在し，コンポーネントおよびその通信関係が複数のシステムまたは少なくとも１つのシステムの機能構造を形成する。その場合に，好ましくは，機能構造に依存するエラーが求められ，機能構造に関するエラー依存性が評価される。

実施形態においては，本発明は，特に自動車内で，システムにおける予め定めることのできる安全段階を得るための装置，特にコンピュータシステム，コンピュータプログラム，コンピュータプログラム製品および方法に関するものである。その場合に複数のシステムまたは少なくとも１つのシステムが複数のコンポーネントからなり，それらコンポーネントの間に通信関係が存在し，コンポーネントとその通信関係がシステムの機能構造を形成する。その場合に，機能構造に依存するエラーが求められ，機能構造に関するこのエラー依存性が評価されるものであって，次のステップを有している：

ａ）機能構造内のエラー依存性を追求してエラーパスを形成し，エラーのグローバルな作用を求め，
ｂ）グローバルな作用を，予め定めることのできる安全段階に従って評価し，
ｃ）コンポーネントまたは通信関係のエラー行動をもたらすエラーを求め，
ｃ）コンポーネントまたは通信関係のエラー行動を，グローバルな作用に対応づけ，
ｅ）エラーを認識する措置および／またはエラーをコントロール措置を求め，
ｆ）得ることのできる安全段階を求めて，求められた安全段階を，得るべき安全段階と比較し，かつ
ｇ）比較に従って，得るべき安全段階が得られるまで，ａ）から新たな処理を開始する。

従って好ましくは，問題領域を正しい時期に認識するために，製品開発の早期の段階における安全分析を実施することと，早い時期に安全措置を機能構造内へ統合することが行われる（“ｓａｆｅｔｙ ｔｈｒｏｕｇｈ ｄｅｓｉｇｎ”）。

従って本発明に基づく安全分析は，好ましい方法で，反復する分析および改良プロセスとしても示される。

システムの安全性を判定する方法は，好ましくは，ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造またはＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデルに基づいて示すことができるが，他のシステムモデルにも適用できる。

本方法は，好ましくは，ＣＳＡテーブルを用いて実施される。ＣＳＡテーブルによって，グローバルなエラー作用が識別されて，評価される。ＣＳＡテーブルには，コンポーネントと通信関係のエラー依存性が示される。その場合にエラー行動は，コンポーネントまたは通信内の機能構造エラー（以後，ＦＳエラーとも称する。）によってもたらされる。通信エラー（命令，要請）は，通信の目標コンポーネント（通信先のコンポーネント）において考慮される。照会の際のＦＳエラーは，通信元のコンポーネントにおいて考慮される。

コンポーネントのエラー行動が，グローバルな作用に対応づけられる。それによってグローバルな作用の判定だけでなく，機能構造のどのコンポーネントがそれに関して責任を有しているか，も得られる。

本方法は，特殊な実施形態においては，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの開発プロセスへ組み込まれる。それによって，形式的，系統的なやり方が促進される。

安全措置は，特にＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデルに適用される。このことが，決定された製品要請または製品仕様書に対する形式的な検証を可能にする。製品仕様書の妥当性検査は，このやり方においても可能である。

従って安全措置を含む，ＣＳＡテーブル，ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造またはＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデルを基礎とする，さらに進歩した量的な安全考察の実施を得ることができる。

他の利点と好ましい形態は，明細書，請求項の特徴から明らかにされる。

以下，図によって示される図面と表を用いて本発明を詳細に説明する。

以上説明したように本発明によれば，開発段階で潜在的な危険箇所を識別することにおいてシステム開発者を支援することができる。

以下で説明する安全分析は，考察されるシステムのＣＡＲＴＲＯＮＩＣ（登録商標）機能構造またはＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬ−モデルに基づいている。ＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬ−モデルは，ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造をＵＭＬ（ｕｎｉｆｉｅｄ ｍｏｄｅｌｉｎｇ ｌａｎｇｕａｇｅ）へ適用するものである。ＵＭＬへ適用することによって，発明の自動化された実現を容易にするような，形式化され，かつより正確に明細化された表示が得られる。ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造をＵＭＬモデルへコピーすることは，（Ｔｏｒｒｅ Ｆｌｏｒｅｓ， Ｐ．； Ｌａｐｐ， Ａ．； Ｈｅｒｍｓｅｎ， Ｗ．； Ｓｃｈｉｒｍｅｒ， Ｊ．； Ｗａｌｔｈｅｒ， Ｍ．； Ｂｅｒｔｒａｍ， Ｔ．； Ｐｅｔｅｒｓｅｎ， Ｊ．； ２００１， Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ ａ ｓｔｒｕｃｔｕｒｉｎｇ ｃｏｎｃｅｐｔ ｆｏｒ ａ ｖｅｈｉｃｌｅ ｃｏｎｔｒｏｌ ｓｙｓｔｅｍ ｉｎｔｏ ｔｈｅ ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｐｒｏｃｅｓｓ ｕｓｉｎｇ ＵＭＬ ｍｏｄｅｌｉｎｇ ｍｅｔｈｏｄｓ（車両コントロールシステムのための構造化コンセプトをＵＭＬモデリング方法を使用してソフトウェア開発プロセス内へ統合すること）， Ｄｅｔｒｏｉｔ／Ｍｉｃｈｉｇａｎ ＵＳＡ， ＳＡＥ ２００１−０１−００６６）に記載されている。

ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析は，抽象的なシステムレベルで系統的な安全分析を行う方法であって，従って開発信条「デザインを通しての安全（ｓａｆｅｔｙ ｔｈｒｏｕｇｈ ｄｅｓｉｇｎ）」を支援するものである。より以前の刊行物に記載されている，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析を行う方法（Ｂｅｒｔｒａｍ， Ｔ．； Ｄｏｍｉｎｋｅ， Ｐ．； Ｍｕｅｌｌｅｒ， Ｂ．； １９９９， Ｔｈｅ Ｓａｆｅｔｙ−Ｒｅｌａｔｅｄ Ａｓｐｅｃｔ ｏｆ ＣＡＲＴＲＯＮＩＣ（ＣＡＲＴＲＯＮＩＣの安全関連のアスペクト）， Ｄｅｔｒｏｉｔ／Ｍｉｃｈｉｇａｎ ＵＳＡ， ＳＡＥ‘９９， Ｓｅｓｓｉｏｎ Ｃｏｄｅ ＰＣ ２６）が，根本的に検討されて，構造的なエラー依存性の分析だけ拡張されている。早期の開発段階において本方法を使用することによって，エラーとその原因を抽象的に，たとえば「エラーが存在する」あるいは「エラーは存在しない」と記述することができる。従って本方法は，ＦＭＥＡ（Ｆａｉｌｕｒｅ Ｍｏｄｅ ａｎｄ Ｅｆｆｅｃｔｓ Ａｎａｌｙｓｉｓ またはＦｅｈｌｅｒ−Ｍｏｅｇｌｉｃｈｋｅｉｔｓ−ｕｎｄ Ｅｉｎｆｌｕｓｓ−Ａｎａｌｙｓｉｓ（エラー可能性および影響分析））の抽象を表しており，その方法が構造化されたエラー依存性の分析だけ拡張されている。その場合にＦＭＥＡは，システム，構成部品および製造プロセスを分析，評価および文書化する，方法上の処理であって，特にエラー回避に用いられる。ＣＳＡの意図は，ＦＭＥＡに代わることではなく，ただ早期の開発段階において潜在的な危険箇所を識別することにおいてシステム開発者を支援することである。

まず重要な概念を定義してから，例を用いて発明を説明する。

定義１（グローバルな作用）
グローバルな作用は，アクチュエータによって自動車というシステム全体に作用する，物理的な効果である。それらはセンサ技術により（あるいは車両運転者によっても）機能損失（たとえばブレーキシステムの不具合）または快適性損失（たとえばアダプティブクルーズコントロールのようなアシストシステムのオフによる）によって認識される。

定義２（機能構造エラー）
機能構造エラー（ＦＳエラー）は，コンポーネントまたは通信のエラー行動をもたらすエラーである。

定義３（機能構造エラー原因）
機能構造エラー原因（ＦＳエラー原因）は，コンポーネントのエラー行動の理由である。コンポーネントのエラー行動の理由は，ＦＳエラーの存在にある。ＦＳエラーは，さらに細目化されたエラー種類に分割される。その場合に細目化されたエラー種類がまた，ＦＳエラーの原因になることもある。細目化されたエラー種類は次のごとくである：
コンポーネントエラー：
コンポーネントが機能していない
コンポーネントが誤った値を計算
コンポーネントは，コントロールされない状態でアクティブである
コンポーネントは，誤った時期に結果を生成
通信エラー：
通信中断
通信が誤った情報を提供
通信は，コントロールされない状態でアクティブである
通信は，誤った時期に情報を提供
通信は，誤ってガイドされている

図１は，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析の処置方法を示している。本方法は，以下のように区分することができる：
ステップ１：ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造ないしＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデルに基づいて，グローバル作用を識別
ステップ２：安全段階（ｓａｆｅｔｙ ｌｅｖｅｌ，以後，ＳＬとも称する。）によってグローバル作用を評価
ステップ３：ＦＳエラー原因の分析（定義３を参照），たとえばコンポーネントまたは通信関係のエラーを分析
ステップ４：コンポーネントのエラー行動をグローバル作用に対応づける
ステップ５：エラー認識措置および／またはエラーコントロール措置を求める
ステップ６：ＣＡＲＴＲＯＮＩＣ（登録商標）安全構造の形成ないし補完
ステップ７：もたらされた機能および安全構造を，安全性の観点から検証

次に，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析を例を用いて説明する。例として，簡略化されたブレーキシステムを選択する。簡略化されたブレーキシステムのＣＡＲＴＲＯＮＩＣ（登録商標）機能構造とＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデルが，図２と３に示されている。例示されたシステムは，コンポーネントであるトルク分配器，推進装置，ブレーキシステム，ブレーキシステムコーディネータ，ブレーキアクチュエータおよびブレーキライトを備える。ＣＡＲＴＲＯＮＩＣ（登録商標）の論理的，階層的な機能構造において，コンポーネントであるブレーキシステムコーディネータとブレーキアクチュエータは，ブレーキシステムの細目化内にある。コンポーネントであるトルク分配器，推進装置およびブレーキシステムは，推進装置とブレーキの細目化である。機能構造において，推進装置とブレーキは，車両運動の細目化である。コンポーネントであるブレーキライトは，ライトと光信号の細目化内にあって，その光信号は外部照明の細目化である。この外部照明もまた，コンポーネントである，ボディと室内の視認性と信号化の細目化である。車両運動およびボディと室内の細目化は，車両レベル内に位置づけされている。車両レベルは，ＣＡＲＴＲＯＮＩＣ（登録商標）機能構造の一番上のレベルである。

ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析の認識は，表，ＣＳＡテーブルにわかりやすくまとめて記憶される。

ＣＳＡテーブルによって，機能構造の内部でエラー依存性に対する個々のコンポーネントのエラー行動の対応づけが得られる。ＣＳＡテーブルで示されたＦＳエラーは，上述したエラー種類に細分することができる。細分化されたエラー種類は，抽象的なシステムレベルで，ＦＳエラーの原因として解釈可能である。さらに，「内部の作用」（コンポーネントのエラー行動）が，グローバルな作用に対応づけられる。それによって構造内部のエラー依存性とグローバルな作用との間の複雑な依存性が認識可能となる。

以下で説明する方法は，原因分析に関して「ボトムアップ」の考え方を採用している。というのは，潜在的なエラー行動に基づいて，そのエラー行動を引き起こす可能性のある原因が識別されるからである。この措置を，上述した例とすでに示されているステップ１〜７を用いて説明する。

ステップ１：グローバルな作用を識別
グローバルな作用は，周囲へのシステムインターフェイスを考察する場合に生じる。考察されるシステムによって駆動されるアクチュエータは，周囲へのインターフェイスを表す。ここで考察される文脈において，周囲とは全体としての自動車を意味する。図２と３に例示するシステムのためのアクチュエータは，ブレーキシステム（細目化においてはブレーキアクチュエータ），推進装置およびブレーキライトである。単に，調査すべきサブシステムが責任を負うべきグローバルな作用が考察され，たとえばコンピュータシステム内で検出される。すなわち，たとえば，ブレーキ作用の全体的な損失に対する責任をブレーキシステムに負わせるように駆動するアダプティブクルーズコントロール（ＡＣＣ）サブシステムは，重要ではない。この関係は，対応表またはエキスパートシステムによって検出可能であって，処理の推移においてコンピュータシステムによってアクセス可能に提供される。その場合に措置が反復する場合には，それぞれ反復プロセスに従って異なる関係を上述した形式で使用することができる。これはまた，以下で説明するような，他の措置についても当てはまる。

図２に示す例について，たとえば以下のグローバルな作用を識別することができる：
□加速作用→推進装置
・管理されない加速
○加速強すぎ
○加速弱すぎ
・加速なし
□ブレーキ作用→ブレーキアクチュエータ
・ブレーキ作用なし
・小さすぎるブレーキ作用
□信号化→ブレーキライト
・表示なし
・連続的な表示（制動されないのに，ブレーキライトが点灯，というシナリオが得られる）

図４には，ＣＳＡテーブルにおいてグローバルな作用が設定されているヘッダ部分が示されている。

ステップ２：安全段階によってグローバルな作用を評価
グローバルな作用の評価は，ＤＩＮ Ｖ１９２５０に定められている要請クラスに準拠して行われる。規格内の要請クラスは，一般にＭＳＲ保護装置（ＭＳＲ−Ｍｅｓｓｅｎ， Ｓｔｅｕｅｒｎ， Ｒｅｇｅｌｎ／測定，開ループ制御，閉ループ制御）のために定められている。そこで決定されている前提は，直接自動車には移し替えられない。この規格内では，次の点が評価に取り入れられる。

□危険領域内の滞在時間
□一人または複数の人間が，潜在的なエラーの作用を受ける
それに対して自動車の場合には，上記２点の場合を考慮することは，重要ではない。上記２点は，所定の機械を駆動する場合に，機械を操作する人間はその機械を検査台から操作し，たとえば保守作業の場合に，制限された期間の間所定の前提の元でのみ潜在的な危険にさらされる，という前提の元で考慮される。それに対して自動車においては，人は常に潜在的な危険にさらされている。さらに，常に複数の人がエラーの作用を受ける可能性がある。この違いを考慮して，自動車のための適合された「要請クラス」が設けられ，それはＣＳＡの枠内で安全段階（英語ではｓａｆｅｔｙ ｌｅｖｅｌ−ＳＬ）と称される。エラー作用に対する安全段階の対応づけが，図５のリスクグラフに示されている。

図示のように，作用が特殊な場合において生じるか，あるいは通常の場合において生じるか，が区別される。特殊な場合においてとういのは，圧倒的多数の場合において，該当する作用を考慮する必要がないことを意味している。安全段階に，事象頻度を対応づけることができる。このような事象頻度は，後に実現されるコンポーネントによって少なくとも満たされるべき設定値である。事象頻度のアプリオリな検証は，通常不可能である。というのは，信頼できるデータは，しばしば一連の使用の後に提供されるからである。しかし，安全段階に対応付けられた事象頻度の目標値を，後から，検出された実際値と比較することは可能である。その場合に偏差が生じた場合には，すなわち実際に求められた事象頻度が，安全段階の許容される事象頻度よりも大きい場合には，事象頻度を減少させる措置を講じなければならない。

図６には，安全段階によるブレーキシステムのグローバルな作用の評価が示されている。ブレーキシステムは，すべての状況の下で保証されなければならない自動車の最も重要な機能である。グローバルな作用「ブレーキ作用なし」は，通常の場合においては，車両運転者によってはコントロールできない身体と生命の脅威を意味している。従ってここでは，安全段階ＳＬ４が与えられなければならない。作用「加速なし」については，安全段階ＳＬ１が与えられる。とういのは，ここでは通常の場合において，たとえばわずかな速度差を有する追突事故による，最大でも軽微な損傷であるということが推定できるからである。特殊な場合においては，身体と生命の危険が生じる可能性があるが，それは，たとえば警告点滅設備をオンにすることによって，コントロールできる。

以下においては，見やすい表示を得るために，テーブル欄「管理されない加速」の細分化は省かれている。

ステップ３：機能構造−エラー−原因分析
原因分析においては，何がコンポーネント（トルク分配器，推進装置，ブレーキシステム，ブレーキシステムコーディネータ，ブレーキアクチュエータ，ブレーキライト）のエラー行動をもたらしたか，が問われる。

原因分析は，何によってＣＡＲＴＲＯＮＩＣ（登録商標）コンポーネント（トルク分配器，推進装置，ブレーキシステム，ブレーキシステムコーディネータ，ブレーキアクチュエータ，ブレーキライト）のエラー行動がもたらされた可能性があるか，を調査する。コンポーネントとその細目化（わかっている限りにおいて）のエラー行動が調査される。原因分析するために，考察されるシステムのＣＡＲＴＲＯＮＩＣ（登録商標）機能構造が，ＣＳＡテーブルの先頭行「機能構造」へ引き継がれる。さらにＣＡＲＴＲＯＮＩＣ（登録商標）機能構造が，欄「エラー行動コンポーネント」へ引き継がれる（図７を参照）。

１つのコンポーネントにおけるＦＳエラーが同じコンポーネント内のエラー行動をもたらした場合には，機能構造に基づくコンポーネントが同じコンポーネントのエラー行動へ対応づけられる（「ｘ」で識別，図７を参照）。さらに，コンポーネントにとって重要な，通信関係のＦＳエラーも考慮される。通信関係のＦＳエラーが，エラー行動をもたらした場合には，同様に，考察される通信の種類と名称を表す，機能構造の対応づけが行われる。通信関係の種類は，通信の英語表現の大文字の頭文字によって示される。従って命令（英語ではＯｒｄｅｒ）については「Ｏ」，要請（英語ではＲｅｑｕｅｓｔ）については「Ｒ」，照会（英語ではＩｎｑｕｉｒｙ）については［Ｉ」が使用される。通信の種類にアンダーバー「＿」が続き，それに通信の名称が続く（たとえばＩ＿Ｉ１）。

コンポーネントのエラー行動についての原因分析において，
□コンポーネント自体，および
□到着した命令
□到着した要請
□出力される照会
が考察される。

以降の推移において，エラー依存性が調査される。従って，他のどのコンポーネントと通信が，考察されるコンポーネントのエラー行動に責任を有する可能性があるか，が求められる。そのために，コンポーネントの欄Ｍにある１つまたは複数の通信が遡及されて，新しく見いだされた１つまたは複数のコンポーネントが同じ行内でコンポーネントエラー特性に対応づけられる。新しく見いだされたこの１つは，新しい出発点として用いられる。このコンポーネントに対応づけられた１つまたは複数の通信が求められて，該当するコンポーネントの欄Ｍへ記録される。このコンポーネントに対応づけられた通信も，遡及される。従って新しい出発コンポーネントが見いだされる。このプロセスは，他の通信が存在しなくなるまで，またはすべての到達可能なコンポーネントが通過されるまで，反復して続行される（以下の例と図８を参照）。

例：
コンポーネントトルク分配器（ｆｃ１）のエラー行動は，コンポーネントトルク分配器（ｆｃ１）自体内のコンポーネントエラー，照会Ｉ１または要請Ｒ１あるいは要請Ｒ２内の通信エラー，コンポーネント推進装置（ｆｃ３）内のコンポーネントエラーまたは命令Ｏ２における通信エラー，コンポーネントブレーキシステムコーディネータ（ｆｃ２１）内のコンポーネントエラーあるいは命令Ｏ１内の通信エラーが発生したことに，原因を有している。
コンポーネントブレーキシステム（ｆｃ２）のエラー行動は，ブレーキシステム（ｆｃ２）自体内にコンポーネントエラーが存在するか，命令Ｏ１内の通信エラーあるいはここで考慮すべき通信エラー要請Ｒ１，要請Ｒ２および照会Ｉ１を伴うトルク分配器（ｆｃ１）内のコンポーネントエラー，またはコンポーネント推進装置（ｆｃ３）内のエラー，命令Ｏ２内の通信エラーが発生していることに，原因を有している。

図２に示す例についてのＣＳＡテーブルへの記入が，図８の，特に図８ａから明らかにされる。

細目内のコンポーネントのエラー行動が考察される場合には，覆いは原因分析のためには関心を持たれない。というのは，通信関係のみがより高いレベルから細目へ伝えられるからである。「機能構造」の欄のブレーキシステム（ブレーキシステム（ｆｃ２）はブレーキシステムコーディネータとブレーキアクチュエータのための覆い）は，コンポーネントブレーキシステムコーディネータ（欄「エラー行動コンポーネント」内の行ブレーキシステムコーディネータ（ｆｃ２１））のエラー行動の原因分析のために考慮する必要はない。コンポーネントブレーキライトのエラー行動の原因分析においては，コンポーネントブレーキシステムの細目のための分析が行われている場合には，コンポーネントブレーキシステムのための分析を実施することは不要である。可能性のある原因は，細目（ブレーキシステムコーディネータとブレーキアクチュエータ）を考察する際にすでに考慮されているからである。

従ってＣＳＡテーブルは，論理的なエラー依存性の追求を許すものである。多数の記入を有する機能構造の欄，たとえばトルク分配器（ｆｃ１）の欄と推進装置（ｆｃ３）の欄は，そこでは１つのエラーがシステムの大きな部分へ作用するので，重要なコンポーネントであるといえる。

ステップ４：グローバルな作用に対するコンポーネントのエラー行動の対応づけ
従ってまず，ステップ１において識別されたグローバルな作用が，そのエラー行動がグローバルな作用をもたらしたコンポーネントに対応づけられる。これらのコンポーネントは，システムインターフェイスである（ステップ１を参照）。

ステップ１で，この対応づけはすでに示されている。

□加速作用→エラー行動 推進装置
□ブレーキ作用→エラー行動 ブレーキアクチュエータ
□信号化→エラー行動 ブレーキライト

ＣＳＡテーブル内のこの対応づけは，図８ｂから明らかである。

ステップ３で求められたエラー依存性によって，グローバルな作用への残りのコンポーネントの対応づけが得られる。これは，システムインターフェイスの行のための機能構造の欄を考察することによって達成される（コンポーネントブレーキアクチュエータ（ｆｃ２２），推進装置（ｆｃ３）およびブレーキライト（ｆｃ４）のエラー行動）。システムインターフェイスのエラー行動に対応づけられている（たとえば「ｘ」で示されている），機能構造の各欄は，同じグローバルな作用をもたらす可能性がある。細目のエンベロープには，細分化のコンポーネントに対応づけられている，すべてのグローバルな作用が割り当てられる。このステップの結果が，図８ｃに示されている。

例：
以下，機能構造におけるコンポーネントトルク分配器（ｆｃ１）を考察する。機能構造内のコンポーネントトルク分配器（ｆｃ１）は，エラー行動 ブレーキアクチュエータ（ｆｃ２２）の行に対応づけられており，すなわちコンポーネントトルク分配器内のエラーがブレーキアクチュエータのエラー行動をもたらす可能性がある。そのことから，コンポーネントトルク分配器のエラー行動がブレーキアクチュエータのグローバルな作用もたらす可能性もあることが推定される。従ってブレーキアクチュエータのエラー行動のグローバルな作用（「ブレーキ作用なし」と「過少なブレーキ作用」）は，トルク分配器のエラー行動にも対応づけられる。さらに，コンポーネントトルク分配器（ｆｃ１）内のＦＳエラーが，推進装置（ｆｃ３）のエラー行動をもたらす可能性がある。従ってコンポーネントトルク分配器のエラー行動が，グローバルな作用「管理されない加速」と「加速なし」をもたらす可能性もある。コンポーネントトルク分配器（ｆｃ１）内のＦＳエラーは，ブレーキライト（ｆｃ４）のエラー行動をもたらす可能性がある。従ってコンポーネントトルク分配器のエラー行動が，グローバルな作用「表示なし」と「管理されない表示」をもたらす可能性がある。
コンポーネントブレーキシステムコーディネータ（ｆｃ２１）とブレーキアクチュエータ（ｆｃ２２）のエンベロープとしてのブレーキシステム（ｆｃ２）のエラー行動は，細目におけるそのすべてのコンポーネントのグローバルな作用をもたらす可能性がある。

ステップ４．１：安全段階をコンポーネントのエラー行動に対応づける
１つの行内でエラー行動に対応づけられている，グローバルな作用の安全段階の最大値が，欄ＳＬの対応するエレメント内に記入される。この措置が，図８ｄに示されている。

ステップ５：エラー認識措置および／またはエラーコントロール措置
以下の２つの表は，コンポーネント（表２）と通信関係（表３）のためのエラーを認識およびコントロールする手段を有している。

・・・（表２）

・・・（表３）

高い抽象レベルでのエラー認識および／またはエラーコントロール措置を示すことは，具体的に実現されたシステムがまだ存在していない場合には，困難である。ＣＳＡテーブル内の多くの抽象的なエラーについて，それらが実現に関係する，すなわち具体的なシステムトポロジーのために，示される場合にのみ，エラーを認識してコントロールするための有効かつ経済的に有意義な措置が示される。そうでない場合に実現に無関係に考察した場合には，抽象的なレベルで解決のために示すことのできる，余りにも多くの可能性が存在する（表２と表３を参照）。措置は，抽象的な原因を認識してコントロールするための可能性を示す。こられの抽象的な原因は，一般的なＦＳエラーのエラーモード（エラー種類）として理解することができる（定義３を参照）。

高い抽象レベルでは，すでに早期の開発段階において明らかにされている措置が示される。

それに数えられるのは，エラー伝播を阻止し，あるいは蓋然性に基づく措置である。すなわち，信号は，所定の限界値内にのみ存在することを許されていることは，明白であると言える。エラー伝播は，冗長性によって制限することができる。冗長な構造は，後の開発段階において，すなわち実現されたトポロジーの詳細な知識において，安価な措置に変換することができる。その例は，エラーを認識して補正するためのコードである。表の明文の記載は，プログラムやコンピュータシステム内ではコード化によって短縮可能かつ対応づけ可能である。

技術的および経済的な種類の最適な解決は，既知のトポロジーの内部でエラーを考察する場合に初めて見いだすことができる。ある照会について，原因「誤った情報を供給する」がクリティカルであると識別された場合に，とるべき措置は，照会がどのように実現されているか，に著しく関係する。プロセッサシステムの内部の値が照会される場合には（たとえば内部のメモリ），場合によっては措置はとられない（固有に安全）。またはユニット全体としてのプロセッサシステムを考察して，唯一の措置，たとえばウォッチドッグタイマによって，多数のオペレーションを監視することができる。通信が外部の接続（ケーブル，バスシステム）を介して進行する場合には，接続／メッセージ伝達を場合によっては冗長に設計しなければならない。電磁的な互換性の問題においては，場合によっては，シールドされたケーブルを介しての接続を他の付加的な電子的コストなしで保証できれば，十分である。

ステップ６：ＣＡＲＴＲＯＮＩＣ（登録商標）−安全構造
システムのＣＡＲＴＲＯＮＩＣ（登録商標）表示（図２の例について示される）は，ＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデル（図３）に適用することができる。これは，ＣＡＲＴＲＯＮＩＣ（登録商標）よりも形式的なシステム仕様書を可能にするものである。さらに，ＵＭＬは，国際的に規格化された言語である。しかし，システムトポロジーを記述するためには，すでにあるＣＡＲＴＲＯＮＩＣ（登録商標）−ＵＭＬモデルを拡張することが必要である。拡張は，エラーを認識しコントロールするための措置，制御装置への機能のパーティショニングおよび時間的かつ論理的シーケンスの表示を含まなければならない。拡張された構造は，使用される安全措置の文書化に使用することができる。構造，機能およびトポロジーを含む表示は，特に自動化された実施のための，未来の量的なシステム分析にも適している。

ステップ７：検証
検証する場合に，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析の結果が，製品仕様書が満たされることをもたらすか，が調べられる。与えられた安全段階が仕様書の要請に相当するか，つまり，得るべき安全段階が予め設定可能で，得るべき安全段階と一致するか，が調べられる。これがそうならない場合には，ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの安全分析のさらなる反復を実施することができる。この反復される改良プロセスは，仕様書ないし予め定められた安全段階のすべての要請が満たされるまでの間，続行される。

図９には，開発プロセスにおいて整理されたＣＳＡが示されている。使用された開発プロセスは，Ｖ−モデルにおいて方向を定められている。Ｖ−モデルは，ＩＴシステムのための連盟の開発標準である。Ｖ−モデルを，与えられている周辺条件にプロジェクト固有に適合させることができる。このプロセスは，テイラリング（Ｔａｉｌｏｒｉｎｇ）と称される。Ｖ−モデル内で，活動（アクティビティ）とその製品が決定される。ＣＡＲＴＲＯＮＩＣ（登録商標）ベースの開発プロセスに適合されたインクリメンタルな，反復的なＶ−モデル（ＩＩＶ−モデル）は，３つのレベル，システムレベル，サブシステムレベルおよび部分実現レベルで利用される。ＩＩＶ−モデル内のナビゲーションは，記入されている矢印に沿って行われる。Ｖ−モデルの左から右側へ達し（テストケース），かつ戻る（反復）ことができる。レベル間で，複数のインクリメントも可能である。部分実現レベルでは，たとえば，実現のために付加的な機能が必要とされることを，認識することができる。その場合には，サブシステム上で機能とその反復が導入されて，その後それらが部分実現レベルで実現されることにより，付加的なインクリメントを修了することができる。システムレベルでは，全体としての自動車が考察される。サブシステムは，自動車という全体システムを，部分システムへ細分する。これらの部分システムは，たとえばエンジン制御，ブレーキシステム，トランスミッションまたはアダプティブクルーズコントロールとすることができる。サブシステムレベルは，自動車の部分システムをさらに実現に関係なく表しており，すなわち機能性のみは考察されるが，技術的実現は考察されない。部分実現レベルでは，各システムがさらに細分される。

トポロジーに関する決定がなされ，かつ機能がソフトウェアとして，コンピュータハードウェアとして，油圧，電子，電気，機械などとして実現されるか，が決定される。次に，対応するサブシステムが形成されて，場合によってはソフトウェアが実装される。ＩＩＶ−モデルの各レベルでは，Ｖ−モデルの左側で要請分析が実施されて，草案が形成される。ＩＩＶ−モデルの右側は，該当するレベルで形成された草案の統合と検証に用いられる。システムレベルでは，上述したプロセスに加えて，妥当性検査を実施することができる。妥当性検査は，システム仕様書がそれに課せられた要請を満たすか，を調べる。それに対して検証は，製品が仕様書に適合しているかを検査する。

処理ステップ１からステップ５は，サブシステムレベルの分析段階で実施される。ステップ６は，サブシステムレベルの草案段階で実行される。ステップ５における考察，つまりエラーを認識してコントロールするための措置の具体化が，しばしばシステムトポロジーが認識された場合に初めて有意義になる。そのことに基づいて，ステップ５において安全措置の細分化を実施し，そしてステップ６を部分実現レベルで実施することが，推奨される。この段階において，システムトポロジー，すなわち制御装置への機能のパーティショニングが行われて，機能実現が決定される。従って，ここで説明したようなＣＳＡは，主としてサブシステムレベルで利用される。しかし，ＣＳＡを，部分実現レベルで続行することも，効果的である。ここでは，トポロジーと部分システムの実現に従ってどのように安全措置が構成されるか，という要請分析が実施されて，それに応じた草案が形成される。この草案とその統合は，ＩＩＶ−モデルの右側で検証することができる。

示されている発明は，コンピュータシステム上で自動的に遂行することができる。そのために，個々のステップまたはこれらのステップの部分は，表と同様に，データと指令とを有するコンピュータプログラムとして示すことができる。従って，ステップ１から７をプログラムコードで実現でき，装置，特にコンピュータシステム内にそのプログラムコードが記憶されて実行されることによって上記装置において本発明に基づく方法を実施できる。その場合にメモリないしデータ担体として，ＣＤ−ＲＯＭ，ＤＶＤ，フロッピー（登録商標）ディスク，ＥＰＲＯＭ，フラッシュＥＰＲＯＭ，ＲＯＭ，ＲＡＭなどのような，考えられる各形式が有効であって，それによってコンピュータプログラムと組み合わせたコンピュータプログラム製品が提供される。特にプログラムをインターネットのようなネットワークを介して１つのメモリから他のメモリないしネットワーク加入者へ伝達することも，同様にその中に入る。

安全分析における方法または処置方法を示している。 例として考察されるブレーキシステムのＣＡＲＴＲＯＮＩＣ（登録商標）機能構造を示している。 図２に示すＣＡＲＴＲＯＮＩＣ（登録商標）機能構造のＵＭＬモデリングのための例を示している。 グローバルな作用を有するＣＳＡテーブルの表ヘッダを示している。 安全段階に対するエラー作用の対応づけを説明するフローチャートである。 グローバルな作用の評価の例を示している。 機能構造におけるエラー伝播系統またはグローバルな作用に対するＦＳエラーの対応づけを示している。 図２に示す例に従って，ＣＳＡテーブルを対応する識別子と共に示している。 図２に示す例に従って，ＣＳＡテーブルを対応する識別子と共に示している。 図２に示す例に従って，ＣＳＡテーブルを対応する識別子と共に示している。 図２に示す例に従って，ＣＳＡテーブルを対応する識別子と共に示している。 開発プロセスにおけるＣＳＡの分類を，特にＶモデルに従って示している。

Claims (15)

1. 特に自動車内で，システムにおける安全分析を実施する方法であって：
   複数のシステムまたは少なくとも１つのシステムが複数のコンポーネントから構成され，前記複数のコンポーネント間に通信関係が存在し，前記複数のコンポーネントおよび前記通信関係によって前記複数のシステムまたは前記少なくとも１つのシステムの機能構造が形成され，
   前記機能構造に依存するエラーが求められ，前記機能構造に関する前記エラー依存性が評価されることを特徴とする，システムにおける安全分析を実施する方法。
2. 前記機能構造内のエラー依存性が追求され，前記エラー依存性が追求されることによってエラーパスが形成され，エラーのグローバルな作用が前記エラーパスの終端として求められることを特徴とする請求項１に記載の方法。
3. 前記機能構造内のエラー依存性が追求され，前記エラー依存性が追求されることによってエラーパスが形成され，エラーのグローバルな作用が前記エラーパスの終端として求められて評価されることを特徴とする請求項１に記載の方法。
4. 前記グローバルな作用が，少なくとも１つの安全段階を求めることにより評価されることを特徴とする請求項３に記載の方法。
5. 前記機能構造に関するエラー依存性の他に，前記コンポーネントまたは前記通信関係のエラー行動をもたらすエラーが求められることを特徴とする請求項１に記載の方法。
6. 前記コンポーネントまたは前記通信関係のエラー行動が，グローバルな作用に対応づけられることを特徴とする請求項２および５，または請求項３および５に記載の方法。
7. 前記エラーを認識する措置および／または前記エラーをコントロールする措置が求められることを特徴とする請求項１から６のいずれか１項に記載の方法。
8. 前記機能構造が，前記グローバルな作用および／またはコンポーネントもしくは通信関係のエラー行動が考慮されるように，拡張されることを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 前記機能構造が，前記エラーを認識する措置および／または前記エラーをコントロールする措置が取り入れられるように，拡張されることを特徴とする請求項１から８のいずれか１項に記載の方法。
10. 特に自動車内で，予め定めることのできる安全段階を得る方法であって：
    複数のシステムまたは少なくとも１つのシステムが複数のコンポーネントから構成され，前記複数のコンポーネント間に通信関係が存在し，前記コンポーネントおよび前記通信関係によって前記システムの機能構造が形成され，前記機能構造に依存するエラーが求められ，前記機能構造に関する前記エラー依存性が評価され；
    ａ）前記機能構造内の前記エラー依存性を追求してエラーパスを形成し，前記エラーのグローバルな作用を求める
    ｂ）前記グローバルな作用を，予め定めることのできる安全段階に従って評価する
    ｃ）前記コンポーネントまたは前記通信関係のエラー行動をもたらす前記エラーを求める
    ｃ）前記コンポーネントまたは前記通信関係の前記エラー行動を，前記グローバルな作用に対応づける
    ｅ）前記エラーを認識する措置および／またはエラーをコントロールする措置を求める
    ｆ）得ることのできる安全段階を求めて，前記求められた安全段階を，前記得るべき安全段階と比較する
    ｇ）前記比較結果に従って，前記得るべき安全段階が得られるまで，ａ）から新たな処理を開始する
    前記ａ）からｇ）のステップを含むことを特徴とする，予め定めることのできる安全段階を得る方法。
11. ステップｅ）とステップｆ）の間に，前記機能構造の文書化が行われることを特徴とする請求項１０に記載の方法。
12. 前記機能構造が，ＵＭＬを使用したＣＡＲＴＲＯＮＩＣ（登録商標）機能構造として示されることを特徴とする請求項１から１１のいずれか１項に記載の方法。
13. 請求項１から１２の少なくとも１項に記載の方法を実施するための装置，特にコンピュータシステム。
14. 請求項１３に記載の装置内で実行された場合に，請求項１から１２の少なくとも１項に記載の方法を実施するコンピュータプログラム。
15. 請求項１３に記載の装置内へ導入した場合に，請求項１から１２の少なくとも１項に記載の方法を実施する，コンピュータプログラム製品，特に請求項１４に記載のコンピュータプログラムを有するデータ担体。
    

Images