JP2022535988A - 技術ユニットの安全性検査方法 - Google Patents

Abstract

少なくとも一つの第一の妥当なモデル変化形態と、場合によっては、一定数の代替モデル変化形態とが特定される、技術ユニット１の安全性を検査する方法であって、この方法が、検査コンピュータシステム２上で実施され、この方法が、既知の弱点をモデル変化形態のコンポーネントに割り当てる工程と、攻撃目標を定義する工程と、各モデル変化形態に対して、攻撃目標に関する少なくとも一つの攻撃モデルを作成する工程と、少なくとも一つの評価変数に関して、攻撃モデルのノードを重み付けする工程と、この評価変数に関する攻撃モデルの少なくとも一つのテストベクトルの評価を特定する工程と、全ての評価の中の最も不利な値として安全性値を特定する工程と、この安全性値が安全性判断基準に合致する場合に、安全性証明を出す工程とを有する。

Description

本発明は、検査コンピュータシステム上で実施される、技術ユニットの安全性を検査する方法、技術ユニットの少なくとも一つの妥当なコンフィグレーションを特定する方法、コンピュータプログラム製品及び検査コンピュータシステムに関する。

それぞれ専用のプロセッサ又はマイクロコントローラを備えた最新の技術機器、特に、車両、組み込まれて互いにネットワーク化された多数のコンポーネントは、或る程度以上の複雑さを有する。しかし、本開示は、車両に限定されるのではなく、多数の互いにネットワーク化されたコンポーネントを有し、本開示との関連において一般的に「技術ユニット」と呼ばれるそれ以外のユニット及び技術機器と関連して使用することもできる。技術ユニットの例としては、特に、異なる機器の組合せが挙げられる。例として、例えば、別のユニット、例えば、（自律的な）車両と通信するタブレット又はスマートフォンなどの自律的なコンピュータユニットの所定の課題、例えば、速度計としての課題を実施することができる。他方において、共通の課題を実施するために、例えば、仮想的な牽引棒との意味で互いに連結するために、複数の車両が、互いに、例えば、無線を介して通信することもできるか、或いは一つのユニット、例えば、建築分野、農業、タスクフォースなどでの特殊車両を一つ又は複数の車載機器と接続することができる。そのような組み合わされたユニットは、本開示の意味において、技術ユニットと見做すことができる。

一般的に、そのような技術ユニットのコンポーネントは、専用のメモリと通信インタフェースを有し、従って、それぞれ専用のコンピュータシステムとして観察することができる。そのようなコンポーネントは、「組込みシステム：ＥＳ」又は「サイバーフィジカルシステム：ＣＰＳ」とも呼ばれる。そのような技術ユニットの複雑さは、速く見通すことができないほど大きい。例えば、車両は、一般的に数千万行のプログラムコードを有するソフトウェアを共に実行する１ダースほどの制御機器を有する。通信インタフェースの例としては、部分的に同時に用いられる様々な無線接続プロトコルを単に引用することができる。複雑さと多様な通信インタフェースのために、そのような車両に対して、サイバー攻撃の大きなアタック面（Ａｔｔａｃｋ Ｓｕｒｆａｃｅ）が生じる。その場合、攻撃は、本来の通信インタフェースを介してだけでなく、例として、例えば、ライダーシステム又はレーダーシステムなどのセンサーを介しても行われる可能性がある。それらは、例えば、偽装信号により、或いはＤｏＳ／フラッディングを用いて攻撃される可能性がある。本開示との関連において、許されない手法で技術ユニットに影響を及ぼすことと、許されない手法で技術ユニットのデータを第三者に転送することとの一つ以上を目的とする外部又は内部から技術ユニットに作用する事象が「サイバー攻撃」と呼ばれる。

車両の物理的な能力（重量と速度、そのため大きな運動エネルギー、想定し得る多くの人との直接的な相互作用）、大量の車両（車両群）及び自律的な車両に向けた開発のために、そのような攻撃が膨大な危険の虞を発生させる可能性がある。それは、例えば、自動車、トラック又は軌道車両などの多数の陸上車両だけでなく、水上車両又は空中車両にも関係する。

本開示は、前記の車両及びそれ以外の技術ユニットをサイバー攻撃に対して防護するとともに、そのロバスト性に寄与するとの目的に関係する。本開示との関連において、（例えば、サイバー攻撃などの）作用する事象に関係無く、意図した結果を持続的に提供する、技術ユニットの能力が「ロバスト性」と呼ばれる。

サイバー攻撃に対して技術ユニットを防護するとともに、ロバストにするためには、開発時に弱点を出来る限り防ぐ、或いは出来れば危険に晒される個別コンポーネントを出来る限り隔離して、冗長的な安全措置を講じることが有効である。構想段階では、（例えば、非特許文献１に記載されている通りの）アーキテクチャ措置によって、それを実行する一方、例えば、ベストプラクティス、ソースコードレビューなどの相応の開発プロセスによって、その構想が実現される。

技術ユニットの組立完了及びそれへのコンポーネントの統合後には、如何なる場合でも、出来る限り全ての関係する弱点を（部分システムの組合せによって初めて生じる弱点も）発見できるようにするためには、テスト又は安全性検査の必要性が生じる。そのような安全性検査は、サイバーセキュリティテストとも呼ばれる。

弱点を発見できるようにするためには、その存在に関する知識を持つことが有用である（しかし、例えば、ファジングなどの予備知識を必要としない弱点を発見する技術も存在する）。安全性検査がベースとする弱点は、例えば、公開され自由にアクセスできるデータベース、有料のデータベース又は内部データベースから得ることができる。内部データベースは、独自の弱点分析の途中で発見された弱点を含むことができ、それまで発見されなかった多くの弱点も、ダークネットに有償で提供されている。

安全性検査は、製造業者（例えば、相手先商標製造会社：ＯＥＭ）、国の機関（例えば、自動車登録局）及びそれ以外の利害関係者（例えば、消費者連合、商用車両群運営者など）が技術ユニット又は車両の具体的なサイバーセキュリティリスクを評価できることを可能にすべきである。それは、車両の更なる開発又は改善時に、除去のために、或いは認証及び同様の課題に対しても適用することができる。

例えば、安全性検査は、ＯＥＭによる新しい車両の開発中、市場投入／類別／裁可時においても、その後の車両の全寿命中にも持続的に必要とされる。システムテストレベルでの安全性検査を繰り返す必要性は、そのためサイバーセキュリティの絶え間のない検査は、変更可能なコンフィグレーション、ソフトウェア（の一部）の絶え間のないアップデート、変化する周囲環境条件（例えば、車両対インフラストラクチャー：Ｖ２Ｉ、車両対車両：Ｖ２Ｖ、相互作用相手の変化）、（独自の安全性研究からも）新しく分かったテストベクトルなどのために生じる。その場合、安全性検査は、製造業者によって実施することができ、出来れば（車両群）運営者、自動車登録局及び第三者の専門会社によっても実施することができる。

自動車サプライチェーンにおける分散した開発、製造、コンフィグレーション及び保守のために、安全性検査では、技術ユニットの具体的な内部実装形態に関する知識にアクセスできないか、或いは非常に制限された形でしかアクセスできない。特に、製造業者自身以外の行為者による、例えば、ユーザー又は官庁などによる安全性検査に関しては、テストする技術ユニットのシステムアーキテクチャ、コンフィグレーションデータ、ソースコードなどは殆ど分からない。従って、安全性検査は、極めて「ブラックボックステスト」又は「グレイボックステスト」に、即ち、テストするユニットの内部の機能形態又は実装形態に関する知識無しに、或いは僅かな知識又は部分的な知識だけで開発されたテストに等しい。

それにより、安全性検査に適合したテストケース及びテストベクトル又は攻撃ベクトルを選定するとの問題が生じている。多様性の組合せに起因して、複雑さが増すことによって、実際に利用できる時間内に高価なコンピュータシステムによっても完全には処理できない極めて多数のテストケースが発生する。

Ｐａｐａｄｉｍｉｔｒａｔｏｓ社の出版物「Ｓｅｃｕｒｅ Ｖｅｈｉｃｕｌａｒ ＣｏｍｍｕｎｉｃａｔｉｏｎＳｙｓｔｅｍｓ： Ｄｅｓｉｇｎ ａｎｄ Ａｒｃｈｉｔｅｃｔｕｒｅ」， Ｐ．， Ｂｕｔｔｙａｎ， Ｌ．， Ｈｏｌｃｚｅｒ， Ｔ．， Ｓｃｈｏｃｈ， Ｅ．， Ｆｒｅｕｄｉｇｅｒ， Ｊ．， Ｒａｙａ， Ｍ．， Ｍａ， Ｚ．， Ｋａｒｇｌ， Ｆ．， Ｋｕｎｇ， Ａ．， ＆ Ｈｕｂａｕｘ， Ｊ．－Ｐ．， ２００８， ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ， ４６（１１）， １００～１０９ 「Ａｔｔａｃｋ ｔｒｅｅｓ」， Ｓｃｈｎｅｉｅｒ， Ｂ．（１９９９）， Ｄｒ． Ｄｏｂｂ’ｓ ｊｏｕｒｎａｌ，２４（１２），２１～２９ 「Ａｔｔａｃｋ Ｎｅｔ Ｐｅｎｔｒａｔｉｏｎ Ｔｅｓｔｉｎｇ」， ＭｃＤｅｒｍｏｔｔ， Ｊ．Ｐ．（２０００）， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０００ ｗｏｒｋｓｈｏｐ ｏｎ Ｎｅｗ ｓｅｃｕｒｉｔｙ ｐａｒａｄｉｇｍｓ， １５～２１ 「Ｓｏｆｔｗａｒｅ ｆａｕｌｔ ｔｒｅｅ ａｎｄ ｃｏｌｏｕｒｅｄ Ｐｅｔｒｉｎｅｔ－ｂａｓｅｄ ｓｐｅｃｉｆｉｃａｔｉｏｎ， ｄｅｓｉｇｎ ａｎｄ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ ａｇｅｎｔ－ｂａｓｅｄ ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍｓ」， Ｈｅｌｍｅｒ ｅｔ ａｌ．（２００７）， Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｐｕｔｅｒ Ｓｅｃｕｒｉｔｙ， １（１）， １０９～１４２ 「Ａｎ ｅｍｐｉｒｉｃａｌ ｅｖａｌｕａｔｉｏｎ ｏｆ ｔｈｅ ｅｆｆｅｃｔｉｖｅｎｅｓｓ ｏｆ ａｔｔａｃｋ ｇｒａｐｈｓ ａｎｄ ｆａｕｌｔ ｔｒｅｅｓ ｉｎ ｃｙｂｅｒ－ａｔｔａｃｋ ｐｅｒｃｅｐｔｉｏｎ」， Ｌａｌｌｉｅ， Ｈ． Ｓ．， Ｄｅｂａｔｔｉｓｔａ， Ｋ．， ＆ Ｂａｌ， Ｊ．（２０１７）， ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｏｒｅｎｓｉｃｓ ａｎｄ Ｓｅｃｕｒｉｔｙ， １３（５）， １１１０～１１２２

以上のことから、本発明の課題は、検査するテストケースの数を技術的に達成可能な程度に低減できる方法及び装置を提供することである。更に、安全性検査は、極めて自動的に実施できるようにすべきである。

これらの課題及び別の課題は、検査コンピュータシステムを用いて技術ユニットのコンフィグレーションの少なくとも一つの第一の妥当なモデル変化形態を特定する方法であって、この技術ユニットが、少なくとも一つのデータ伝送機器と、このデータ伝送機器を介してデータ通信できる多数のコンポーネントとを備え、この方法が、
ａ）検査コンピュータシステムの検査インタフェースと技術ユニットのデータ伝送機器との間の接続を構築する工程と、
ｂ）技術ユニットのコンフィグレーションのモデルの初期インスタンスを特定する工程と、
ｃ）この初期インスタンスを出発点として、少なくとも
ｃ１）場合によっては、誘発行動を実行する工程、
ｃ２）技術ユニットに特徴的な挙動を特定する工程、
ｃ３）この特徴的な挙動を分析して、技術ユニットの実際のコンフィグレーションの少なくとも一つの特性を推定する工程、及び
ｃ４）この少なくとも一つの特定された特性によりモデルの仕様を決定する工程、
をそれぞれ有する一連の詳細化プロセスによって、このモデルの詳細なインスタンスを生成する工程であって、少なくとも一つの詳細化プロセスが検査コンピュータシステムによって自動的に実施される工程と、
ｄ）少なくとも一つの判定条件が満たされた場合に、このモデルの詳細なインスタンスを第一の妥当なモデル変化形態として識別する工程と、
有する方法によって解決される。

この方法を用いて、安全性検査に関してテストしなければならないテストケースの多様な組合せを、技術ユニットに関する安全性証明の存在を検査するために、検査コンピュータシステムを用いて利用可能な時間期間内に完全に処理できる数に低減することが可能である。

本開示との関連において、少なくとも一つの電子回路（特に、集積回路、場合によっては、プロセッサ、マイクロコントローラ、ＦＰＧＡ、人工ニューラルネットワーク又はその同等物）を備え、データ通信能力を有し、技術ユニットの少なくとも一つのデータ伝送機器と直接的又は間接的に繋がったユニットが、技術ユニットの「コンポーネント」と呼ばれる。これらのコンポーネントは、本開示では、より狭い意味で「電子コンポーネント」又は「データ処理コンポーネント」とも呼ばれる。

本開示との関連において、単一のコンポーネントに繋がるか、或いは（データ通信の形式に関係無く）単一のコンポーネントに割り当てられたコンポーネントが、技術ユニットの「下位コンポーネント」と呼ばれる。

本開示との関連において、一般的に送信機（例えば、コンポーネント、下位コンポーネント又は外部のデータソース）から受信機（例えば、コンポーネント、下位コンポーネント又は外部のデータシンク）にデータを伝送することを可能にする手段が「データ伝送機器」と呼ばれる。データ伝送機器は、有線式又は無線式であるとすることができ、各データ伝送機器を介したデータ通信が、定義された接続プロトコルに基づき実施される。無線式接続プロトコルの例としては、例えば、３Ｇ／４Ｇ／５Ｇ移動体網、ブルートゥース、ＷＬＡＮ、Ｖ２Ｘ、ＲＦＩＤなどが挙げられ、それらに限定されない。有線式接続プロトコルの例には、例えば、ＣＡＮ、ＦｌｅｘＲａｙ、ＭＯＳＴ、（自動車）Ｅｈｅｒｎｅｔなどが挙げられる。

本開示との関連において、ここで開示する方法の相応の工程を実施するための任意のコンピュータシステムが「検査コンピュータシステム」と呼ばれる。

本開示との関連において、検査コンピュータシステムと技術ユニットのデータ伝送機器との間のデータ接続部が「検査インタフェース」と呼ばれる。この検査インタフェースは、そのような通信を可能にする任意の接続プロトコルを利用することができる。例えば、検査インタフェースは、無線式又は有線接続式のインタフェースであるとすることができる。この検査インタフェースは、場合によっては、例えば、技術ユニットのデータ伝送機器が利用する接続プロトコルが初め分からない場合に、複数の異なる接続プロトコルをサポートすることもできる。例えば、技術ユニットのＵＳＢインタフェース、ブルートゥースインタフェース又は診断インタフェースをインタフェースとして使用することができる。検査インタフェースとデータ伝送機器との間の接続の構築は、例えば、従来のプラグ接続式又は無線式に行うことができる。この関連において、検査コンピュータシステムに対してデータ伝送機器とのデータ通信を可能にするプロセスが「接続の構築」と呼ばれる。場合によっては、検査コンピュータシステムは、複数の互いに独立した検査インタフェースを備えることができる。

本開示との関連において、技術ユニットの特性の定義されたグループが「コンフィグレーション」と呼ばれ、このグループは、特に、
ａ）存在するコンポーネント及び／又は下位コンポーネントの数と形式、
ｂ）存在するコンポーネント及び／又は下位コンポーネントのモデル情報、
ｃ）存在するデータ伝送機器の数と形式、
ｄ）存在するデータ伝送機器の接続プロトコル、
ｅ）技術ユニットでのコンポーネント及び／又は下位コンポーネントの物理的な配置構成、
ｆ）一つ又は複数のデータ伝送機器を介したコンポーネントの通信能力、
ｇ）コンポーネントの下位コンポーネントの数と形式、
ｈ）コンポーネント又は下位コンポーネントに存在するファームウェアの識別子とバージョン情報、
ｉ）コンポーネント又は下位コンポーネントに存在するソフトウェアの識別子とバージョン情報、
ｊ）コンポーネント及び／又は下位コンポーネントの相互の通信接続形態、
ｋ）コンポーネント及び／又は下位コンポーネントの間の機能的な相互依存性（例えば、コンポーネントＡが、コンポーネントＢ無しでは機能しない）、
ｌ）全体システムの機能（例えば、車両の制動システムでの複数の制御チップの協力動作又はその制御）に関するコンポーネント及び／又は下位コンポーネントの（場合によっては、分散した）責任分担、
ｍ）コンポーネント（ハードウェア、ソフトウェア、ファームウェア）のバージョン、
ｎ）チップのバージョンと改訂番号、
ｏ）在り得るメタ情報（例えば、製造業者）、
ｐ）例えば、クロック周波数、伝送速度、実行時間（計算時間）、巡回課題の周期などのタイミング情報、
ｑ）ソフトウェア構成（例えば、タスク優先度、割り当てられたメモリ領域など）、
を含むことができる。

本開示との関連において、場合によっては、技術ユニットに割り当てられたユニットを考慮して、技術ユニットのコンフィグレーションをシステム的に反映したものが「モデル」又は「コンフィグレーションモデル」と呼ばれる。詳細度に応じて、このモデルは、コンフィグレーションに関して定義された特性の中の幾つか又は全てを包含することができる。一方において、モデルは、現実の技術ユニットと合致することが証明された、技術ユニットの特性を含むことができ、他方において、モデルは、技術ユニットと合致することが証明されていない特性を含むこともできる。このモデルは、特性に関する「未知情報」又は「ダミー情報」を含むこともでき、それからは、これらが技術ユニットに存在しなければならないことは分かるが、そのより精確な識別情報は分からない。この関連において、値を割り当てられていない変数が「未知情報」と呼ばれる。詳しい情報無しに特性に割り当てられた原始的なモデルノードが「ダミー情報」と呼ばれる。そのようなダミー情報は、例えば、技術ユニットに存在しなければならないことは分かるが、如何なる構造配列のコンポーネントであるのか、コンポーネントが正確に何処に在るのかが分からないコンポーネントに対して使用することができる。ダミー情報は、技術ユニットのそれ以外の特性、例えば、ソフトウェア、ファームウェア、データ伝送機器などに対しても使用することができる。

このモデルの詳細又は構造は、任意に選定することができ、（例えば、コンポーネントなどの）組になったユニットの特性の場合、モデルノードに対してストラクチャー構造が組み立てられ、コンポーネントの間の関係（例えば、階層的な従属性、データフロー、制御フローなど）が、モデルノードの間の接続部として表すことができる（ここでは、一般的に「接続ペイン」と呼ばれる）。このモデル化は、任意の好適なシステム体系に基づくことができるが、簡単な構造、例えば、ツリー構造によるモデルノードの階層的な配置構成又は網構造による配置構成は、本発明の教えには十分であり、このモデルの複雑さを一目で分かる程度にまで低減する。しかし、本開示は、それ以外の構造もモデル化に使用できるので、そのような構造に限定されない。

所定のテストに関して、確かにそれ自体が技術ユニットのベースにならないが、技術ユニットとの相互関係を有するコンポーネントをモデルに取り入れることも必要である。この場合、「技術ユニット」との用語は、広く解釈すべきであり、そのような「外部の」コンポーネントも包含することができる。

例えば、分析して、モデル化すべき技術ユニットが車両であるとすることができるが、所定の機能のためには、通信相手が必要である。この通信相手は、例えば、（Ｖ２Ｘ：Ｖｅｈｉｃｌｅ－ｔｏ－Ｅｖｅｒｙｔｈｉｎｇでは）第二の車両であるか、或いはネットワーク化された車両では、（Ｖ２Ｃ：Ｖｅｈｉｃｌｅ－ｔｏ－Ｃｌｏｕｄでは）クラウドで動作するアプリケーションであるとすることができる。場合によっては、技術ユニットのモデル化時に、そのような通信相手又はそのコンポーネントを一緒に取り入れることができ、この「外部の」通信相手のコンポーネント及び特性は、ここで開示する方法と関連して、本来の技術ユニットのコンポーネント及び特性と同様に使用することができる。

本開示との関連において、判定条件に合致するコンフィグレーションモデルが「第一の妥当なモデル変化形態」と呼ばれる。この妥当なモデル変化形態が実際のコンフィグレーションに合致することは、確かに確実に証明することはできないが、当該技術ユニットの実際のコンフィグレーションに合致すると推定することもできない。妥当なモデル変化形態は、コンポーネントの「ダミー情報」を含むこともできる。

本開示との関連において、一般的に不完全なモデルが「モデルの初期インスタンス」と呼ばれるが、それからは、このモデルの出来る限り多くの既知の特性が実際の技術ユニットに合致すると推測される。このモデルは、更に、それまでに識別されていない特性に関する未知情報又はダミー情報を含むことができる。例えば、技術ユニットの原始的なモデルが初期インスタンスであるとすることができる。場合によっては、例として、例えば、技術ユニットの形式表示などの事前情報に基づき、より詳細なモデルを初期モデルとして選定することもできる。初期インスタンスの特定は、検査コンピュータシステムと技術ユニットの間の接続の構築の前又は後に行うことができる。例えば、検査コンピュータシステムへのユーザー入力（例えば、技術ユニットの形式表示）に基づき、データベースからモデルの初期インスタンスを選定することができる。場合によっては、技術ユニットの接続の構築後に受信したデータに基づき、検査コンピュータシステムによって自律的に初期インスタンスを選定することもできる。場合によっては、同様の技術ユニットによる実績に基づき初期インスタンスを特定するために、予め定義されたテストケースを技術ユニットで実施して、初期インスタンスを特定することもできる。

本開示との関連において、実際の技術ユニットと合致する度合いが初期インスタンスよりも（並びに場合によっては、存在する詳細なインスタンスよりも）高い、モデルの変更されたバージョンが「モデルの詳細なインスタンス」と呼ばれる。

本開示との関連において、初期インスタンス又は存在する詳細なインスタンスからモデルの詳細なインスタンスを生成することが「詳細化プロセス」と呼ばれる。「モデルの詳細なインスタンスの展開」との用語は、反復実施される一連の詳細化プロセスと関係する。

本開示との関連において、「自動的に実行する」との用語は、検査コンピュータシステムがユーザー介入の必要性無しに相応のプロセスを実行することを意味する。一般的には、所要のユーザー介入の回数を必要最小限に低減することを意図する。

本開示との関連において、技術ユニットの特徴的な挙動、例えば、技術ユニットのデータ伝送機器を介した特徴的なデータ通信を期待通りに引き起こす行動が「誘発行動」と呼ばれる。誘発行動は、例えば、検査コンピュータシステムから検査インタフェースを介してデータ伝送機器に送られるデータの流れであるとすることができる。場合によっては、検査コンピュータシステムは、別のインタフェースを介して誘発行動を引き起こすこともでき、例えば、技術ユニットの一部に作用するアクチュエータを使用することができる。場合によっては、検査コンピュータシステムは、所定の誘発行動、例えば、技術ユニットの操作部品の操作又はコンポーネントの所定通りの操作を実行するように、ユーザーに指示することもできる。誘発行動は、例えば、特別な構成のデータ通信又はテスト的に実施されるサイバー攻撃であるとすることもできる。場合によっては、誘発行動の代わりに、技術ユニットの純粋に受動的な観察を行うこともできる。

本開示との関連において、技術ユニットのコンフィグレーションの少なくとも一つの特性を推定することに関連付けることができる挙動が「技術ユニットに特徴的な挙動」と呼ばれる。この場合、特徴的な挙動は、例えば、データ伝送機器を介した所定のデータ通信の発生、或いは技術ユニット又は技術ユニットのコンポーネントに関して特徴的な所定の測定値であるとすることができる。例えば、データ伝送機器として使用される回線のインピーダンスを測定することによって、その回線に繋がったコンポーネントの数を推定することができる。この特徴的な挙動は、それ以外の任意の測定によっても特定することができる。

技術ユニットの特徴的な挙動の分析及び実際のコンフィグレーションの少なくとも一つの特性の推定は、例えば、既知の技術ユニット又はコンポーネントの特徴的な挙動が保存されたデータベースに照会することによって行うことができる。このデータベースは、外部のシステム又は検査コンピュータシステムに統合することができ、場合によっては、検査コンピュータシステムによって自動的に更新することができる。

本開示との関連において、モデルのインスタンスが、所与の時間内に安全性検査を実現可能とするために十分に決定されたことを確認する条件が「判定条件」と呼ばれる。この場合、例えば、インスタンスに基づき、実際に有り得るコンフィグレーションの如何なる数の変化形態（又はモデル変化形態）が存在するのかを評価することができる。例えば、判定条件は、インスタンスの有り得る変化形態の数が所定の閾値を下回ることを要求することができる。しかし、より複雑な判定条件も実現可能である。例えば、判定条件によって、最後に実行された詳細化プロセスが、詳細なインスタンスの展開の中止が早過ぎないようにするために、どの程度成功したのかを考慮することもできる。この判定条件は、場合によっては、安全性検査の実行途中におけるモデル変化形態の数を更に制限できることも考慮することができる。

ここで開示する方法の有利な実施構成では、技術ユニットに特徴的な挙動を特定する工程は、検査コンピュータシステムがデータ伝送機器を介して伝送するデータを傍受することを含むことができる。この傍受によって、場合によっては、誘発行動後に、技術ユニットの実際のコンフィグレーションの多数の特性を特定することができる。

有利には、技術ユニットの実際のコンフィグレーションの特性は、一つのコンポーネントの少なくとも一つの特性及び／又はコンポーネントの間の少なくとも一つの関係から選定することができる。この関係は、例えば、機能的な関係又は通信関係であるとすることができる。コンポーネントの特性は、例えば、コンポーネントの形式表示、コンポーネントのモデルバージョン、ファームウェアバージョン、コンポーネント上で動作するソフトウェア及びそのバージョンの中の一つ以上であるとすることができる。コンポーネントの間の機能的な関係は、例えば、所定のデータ伝送機器において互いに通信するコンポーネントの配置構成、如何なるコンポーネントが所定のソフトウェアを実行するのかとの事実又は上位の機能への複数のコンポーネントの関与であるとすることができる。この「上位の機能」は、例えば、目標とする共通の効果であるとすることができる。しかし、この場合、それらは、必ずしも上下に通信する必要はない。それらのデータは、（可能であれば、それどころか詳しいモデル内で未だ発見されていない）別のユニットによって処理することができる。

ここで開示する方法の別の有利な実施構成では、第一の妥当なモデル変化形態に基づき、少なくとも一つの代替モデル変化形態が、有利には、多数の代替モデル変化形態が作成される。それによって、その後の安全性検査時に、詳細なインスタンスを展開する途中に発見できなかったコンポーネントと特性を考慮することが可能である。この場合、未知の特性に関して、複数の推測による仮定が設定されて、仮定毎に、それぞれ一つのモデル変化形態が作成される。検査コンピュータシステムの計算能力と技術ユニットの複雑さに応じて、代替モデル変化形態の全体数が、知的に把握可能な数の範囲を大きく上回って、「手動による」処理を最早達成できなく程多くなる可能性がある。それにも関わらず、代替モデル変化形態の量は、十分に少なく、例えば、安全性検査の途中に合理的な時間内でコンピュータに支援された分析を施すことができるほどである。

本開示との関連において、コンフィグレーションの少なくとも一つの未知の特性又は「ダミー情報」を、性質は既知であるが、技術ユニットの実際のコンフィグレーションにおいて存在するのかが分からない少なくとも一つの具体的な特性によって置き換えた、第一の妥当なモデル変化形態の修正版が「代替モデル変化形態」と呼ばれる。代替モデル変化形態は、例えば、単一のコンポーネントの代わりに、その一つのコンポーネントを共に実現する複数のコンポーネントを有することもできる。代替モデル変化形態は、例えば、完全に定義することができる、即ち、全てのダミー情報と未知情報を推測によるが具体的な仮定によって置き換えることができる。本開示との関連において、技術ユニットでの実際の実装形態をそれまで証明できていなかった、コンフィグレーションの具体的な特性が「推測による仮定」と呼ばれる。

別の観点において、本開示は、少なくとも一つの第一の妥当なモデル変化形態と、場合によっては、一定数の代替モデル変化形態とが特定される、検査コンピュータシステム上で実施される技術ユニットの安全性を検査する方法に関し、この方法が、
ａ）既知の弱点をモデル変化形態のコンポーネントに割り当てる工程と、
ｂ）攻撃目標を定義する工程と、
ｃ）攻撃目標と関連する、モデル変化形態に関する少なくとも一つの攻撃モデルを特定する工程と、
ｄ）少なくとも一つの評価変数に関して攻撃モデルのノードを重み付けする工程と、
ｅ）この評価変数に関して攻撃モデルの少なくとも一つのテストベクトルの評価を特定する工程と、
ｆ）全ての評価の中の最も不利な値として安全性値を特定する工程と、
ｇ）この安全性値が安全性判断基準に合致する場合に、安全性証明を出す工程と、
を有する。

そのため、本方法は、それどころか技術ユニットのコンフィグレーションの全てのコンポーネント及び特性が既知でない場合にも、技術ユニットの安全性に関する証明を与えることを可能にする。本方法は、極めて自動的に実施することができ、その結果、ユーザーの訓練負担を最小化することができる。

本開示との関連において、サイバー攻撃が可能である、技術ユニット内に存在するが、検知されていないかもしれないパスが「弱点」又は「脆弱性」と呼ばれる。これは、攻撃モデルのテストベクトルの評価が最早安全性判断基準に合致しないことを引き起こす可能性がある。

本開示との関連において、検査された技術ユニットが所定の安全性要件に合致することを証明（又は否定）するプロセスが「安全性検査」と呼ばれる。この安全性要件は、例えば、一つ又は複数の攻撃目標に対して、一つの安全性証明が存在することを決定することができる。

本開示との関連において、攻撃者が目標として設定した可能性の有る事象が「攻撃目標」と呼ばれる。攻撃目標は、例えば、コンポーネントのソフトウェア機能に関する制御を取得するか、或いは所定のコンポーネントに損害を与えることであるとすることができる。車両環境における攻撃目標の実際の例としては、例えば、エンジン制御の操作、噴射制御の変更又はそれと同等のことが挙げられる。攻撃目標は、一般的に攻撃モデル（例えば、攻撃ツリー又は攻撃ネット）の初期ノードを形成する。

本開示との関連において、初期ノード（攻撃目標）を出発点として、その攻撃目標に如何にして到達できるのかとの点を割り当てた、攻撃のモデルによる記述が「攻撃モデル」と呼ばれる。これらの点は、初期ノードに割り当てられたノードを形成して、それらのノードは、段階的に別のノードに割り当てることができる。特に、このモデルは、ツリー形又はネット形の構造を有する。この攻撃モデルの考えは、専門分野において周知であり、例えば、非特許文献２における「攻撃ツリー」の形又は非特許文献３又は４における「攻撃ネット」の形で記述され、非特許文献５が、攻撃モデルに関する（包括的ではない）概要を提供する。それ以降、攻撃モデルの考えは、関連文献に定義されるか、或いは掘り下げられている。本開示との関連において、当業者が攻撃モデルの考えの確固たる知識を有することを出発点とする。

本開示との関連において、攻撃モデルの段階的な階層に割り当てられたノードを出発点として初期ノードまでの攻撃パスが「テストベクトル」（又は「攻撃ベクトル」）と呼ばれ、攻撃目標に到達するために必要な一連の段階を定義する。

攻撃モデルの各ノードは、攻撃者がそのノードを作り上げるために負わなければならない負担を表す評価変数で重み付けされる。この評価変数は、コスト又はプライスと解釈することができ、評価変数の単位は、例えば、時間、通貨、工数、それ以外のリソース又はそれらの組合せとして定義することができる。

攻撃モデルのノードは、一般的にテストユニットの定義された下位ユニット、例えば、そのノードを征服するために操作しなければならない所定のコンポーネント又は所定のソフトウェアに割り当てられる。

本開示との関連において、一つのテストベクトルの全ての評価変数の総計が、その「テストベクトルの評価」と呼ばれる。そのため、この評価は、テストベクトルに沿った攻撃の実施に必要な負担であると解釈することができる。各攻撃モデルが多数のテストベクトルを有するので、安全性の判断に関して、テストされる全ての攻撃モデルの全てのテストベクトルの評価の中の最悪又は最も不利な値が重要である。この最も不利な値が、最も小さい負担で実施できるテストベクトルを定義する。本開示との関連において、攻撃の成功のために最も小さい負担を定義する値が「最も不利な」値と呼ばれる。

本開示との関連において、この一つの攻撃モデルのテストベクトルの全ての評価の中の最も不利な値が、安全性値と呼ばれる。この安全性値は、攻撃目標に到達するための最小の負担を定義する。この安全性値が定義された安全性判断基準を満たす場合に、攻撃モデルの安全性を証明することができる。

そのため、本開示との関連において、安全性を証明できるようにするためには、安全性値を満たさなければならない条件が「安全性判断基準」と呼ばれる。例えば、安全性値が下回ることが許されない閾値が、例えば、（例えば、通貨、時間、工数などで定義される）負担が、その条件としての役割を果たす。

本開示との関連において、テストされた技術ユニットが攻撃目標及び定義された安全性値に関して安全である（即ち、定義された安全性判断基準に合致する）と見做すことができることを表す言明が「安全性証明」と呼ばれる。

有利には、本方法は、更に、
ａ）特定された弱点に基づき選定された少なくとも一つのサイバー攻撃を技術ユニットに対して実行する工程と、
ｂ）このサイバー攻撃により達成された効果を評価する工程と、
ｄ）この達成された効果が決定的でないモデル変化形態を削除する工程と、
を有することができる。

これによって、検査中にモデル変化形態の数を更に低減することができ、実際のコンフィグレーションに関する知識を深くすることができる。

サイバー攻撃では、例えば、テストベクトルに基づき、エクスプロイトが選定されて、実行される。本開示との関連において、攻撃モデルのパスに沿って（テストベクトルに沿って）攻撃目標を追跡する一連の命令又は行動が「エクスプロイト」と呼ばれる。この場合、エクスプロイトは、既知の弱点を利用する。エクスプロイト以外に、サイバー攻撃は、ファジングも含むことができる。本開示との関連において、ランダムな行動の自動的な（大量の）実行（例えば、データ伝送機器を介したランダムなデータの大量の投入）が「ファジング」と呼ばれ、それによって、それまで分からなかった弱点に当たって、それを利用することを目的としている。

サイバー攻撃の効果は、例えば、攻撃が成功すること、攻撃が失敗すること、或いはそれ以外に、コンフィグレーションに関する推定を可能にする情報が得られることであるとすることができる。攻撃が成功した場合、一連の関与するハードウェア部品及びソフトウェア部品全体をほぼ推定することができ、技術ユニットの実際のコンフィグレーションに関する知識を極めて深くすることができる。

この関連において、モデル変化形態の「削除」とは、それが技術ユニットの実際のコンフィグレーションに合致しないことが分かったので、更なる安全性検査に関する相応のモデル変化形態を最早考慮しないことを意味する。これは、例えば、詳細なコンポーネントが実際に別のコンフィグレーションを有することによって直接的に知るか、或いは、モデル変化形態が、別のコンポーネントの判明したコンフィグレーションにより妥当でなくなったコンポーネント又はコンフィグレーションを有することによって間接的に知ることができる。

有利には、本方法は、更に、
ａ）技術ユニットのコンポーネントにインストールされた少なくとも一つのソフトウェア及び／又はファームウェアを特定する工程と、
ｂ）このソフトウェア及び／又はファームウェアを検査コンピュータシステムにより更新する工程と、
を有する。

これは、例えば、新しいバージョンへの相応のソフトウェア及び／又はファームウェアのアップデート（又は更新）により除去できる安全性欠陥を自動的に除去する役割を果たすことができる。そして、この安全性検査は、詳細なモデル変化形態（即ち、アップデートを考慮したモデル変化形態）に対応して更新することにより続行することができる。

本開示との関連において、コンピュータの非物理的な全ての技術的機能構成要素が「ソフトウェア」と呼ばれる。より狭い意味では、プログラム、文書及び場合によっては、付属データを含むデータ構造がソフトウェアと呼ばれる。

本開示との関連において、技術ユニットの物理的な構成要素（即ち、電子的及び機械的な構成要素）が「ハードウェア」と呼ばれる。

本開示との関連において、所定のハードウェア（特に、技術ユニットの所定のコンポーネント）に固定的に割り当てられ、そのハードウェアの機能をほぼ決定するソフトウェアが「ファームウェア」と呼ばれ、そのハードウェアは、ファームウェア無しでは使用できない。ファームウェアは、一般的に特殊な手段又は機能とのみ置き換えることが可能である。

別の有利な実施構成では、本方法は、更に、
ａ）技術ユニットのコンポーネントにインストールされたソフトウェア及び／又はファームウェアを特定する工程と、
ｂ）このソフトウェア及び／又はファームウェアの詳細なバージョンを含むシミュレーションされたモデル変化形態を作成する工程と、
ｃ）このシミュレーションされたモデル変化形態に基づき安全性値を特定する工程と、
を有する。

本開示との関連において、技術ユニットの実際のコンフィグレーションと周知の通り異なるモデル変化形態が「シミュレーションされたモデル変化形態」と呼ばれる。特に、このシミュレーションされたモデル変化形態は、ソフトウェア及び／又はファームウェアのバージョンに関して実際に存在するモデル変化形態と異なることができる。

同様に、シミュレーションされたモデル変化形態においてハードウェア（即ち、例えば、技術ユニットのコンポーネント）を別のハードウェアに「置き換える」こと、並びにシミュレーションにおける安全性への作用を検査することも可能である。

このシミュレーションされたモデル変化形態を用いて、場合によっては、即座に実行できる診断と安全性勧告を作成することができる。

有利には、技術ユニットが、車両、特に、ＳＡＥ標準Ｊ３０１６のＳＡＥレベル０～５の中の一つに基づく自動的又は自律的な車両であるとすることができる。この用語は、本出願の優先権日の時点で有効な版によるＳＡＥ標準Ｊ３０１６と関連する。

別の観点において、本開示は、コンピュータシステム製品に関し、この製品は、この製品がコンピュータ上で動作する場合に、デジタルコンピュータの内部メモリに直にロードすることができ、ここに開示する方法の工程を実施するためのソフトウェアコード部分を有する。

更に、本開示は、検査コンピュータシステムに関し、その上で、そのようなコンピュータプログラム製品が動作する。

以下において、本発明の有利な実施形態の例を模式的に、本発明を限定しない形で図示した図１～７を参照して、本発明を詳しく説明する。

技術ユニットと検査コンピュータシステムの模式図 技術ユニットのコンフィグレーションのモデルの初期インスタンスの例のブロック図 データフローが更に図示された前記のモデルの初期インスタンスのブロック図 技術ユニットのコンフィグレーションの特性に関する追加情報が追加された、前記のモデルの詳細なインスタンスのブロック図 技術ユニットの第一の妥当なモデル変化形態のブロック図 第一の妥当なモデル変化形態に基づき作成された多数の代替モデル変化形態のブロック図 モデル変化形態に既知の弱点に対する参照を付けた図６のブロック図

図１は、検査インタフェース６を介して互いに接続することができる技術ユニット１及び検査コンピュータシステム２を模式的に図示している。

この検査コンピュータシステム２は、従来のコンピュータシステムであるとすることができ、その上では、コンピュータプログラム製品が検査コンピュータシステム２上で動作する場合に、ここに記載した、検査コンピュータシステム２によって実行すべき工程を実行するためのソフトウェアコード部分を有するコンピュータプログラム製品が実行される。この検査コンピュータシステム２は、例として、例えば、コンピュータディスプレイなどの少なくとも一つ表示器と、例えば、マウス、キーボード、タッチパッド及び／又はアプリケーション用の特殊な入出力機器などの入力機器と、相応の周辺機器とを備えることができる。この検査コンピュータシステム２は、技術ユニット１のデータ伝送機器３とのデータ通信を可能とする検査インタフェース６を有する。

この検査インタフェース６は、データ伝送機器３との物理的な接続部を構築するために技術ユニット１に配備されたソケットに差し込むことができるプラグを備えたケーブルを有することができる。このソケットは、例えば、車両の診断インタフェース、或いは、例えば、ＵＳＢ端子などのそれ以外のインタフェースであるとすることができる。場合によっては、この検査インタフェース６は、相応の接続プロトコルを用いて無線データ伝送機器３との接続を構築する無線インタフェースであるとすることもできる。

この技術ユニット１のデータ伝送機器は、差し当たりコンフィグレーションが全く分からない可能性のある多数のコンポーネント４と接続することができる。このコンフィグレーションは、特に、コンポーネント４、データ伝送機器３及びそれらの配置構成の相関関係と関連する特性によって定義することができる。図１には、見易くするために、（例として、例えば、ＣＡＮバスなどのバスシステムの形式の）単一のデータ伝送機器３だけが図示されているが、技術ユニット１が、異なるコンポーネントを繋ぐことが可能な複数の異なる、場合によっては、互いにネットワーク化されたデータ伝送機器３を備え得ることが既知であるとの前提を設けることができる。場合によっては、この検査コンピュータシステム２は、技術ユニットの異なるデータ伝送機器３にそれぞれ割り当てられた複数の検査インタフェース６を備えることができる。これらのコンポーネント４は、場合によっては、データ伝送機器３に直に繋がれるのではなく、コンポーネント４に直に繋がれた下位コンポーネント４’を有することができる。

以下において、図２～５の図面と関連して、例えば、検査コンピュータシステム２を用いて、最終的に得られるモデル６（これは、「第一の妥当なモデル変化形態」と呼ばれる）を安全性検査に使用できるように、技術ユニット１の（初めはしばしば全く分からない）コンフィグレーションをモデル化することができる方法の使用形態を説明する。この場合、安全性検査は、経済的に合理的な手法で実行可能であるべきである。この場合、車両の安全性検査の環境において、安全性検査が数動作秒以内に実現可能であるべきである。深いスキャンは、場合によっては、より長い時間、例えば、数日間続く可能性があるが、人の干渉は、時々にしか、或いは全く必要でない。この場合、経済的な合理性の尺度は、その時々の用途に従い、新しい技術ユニット及び開発段階での技術ユニットの安全性検査では、比較的大きな負担を想定することができる。例えば、既に許可された路上走行車両の通常の安全性検査は、基本的に可能な限り速く終了できるべきである。有利な状況では、安全性検査は、一時間又は数時間以内に、それどころか出来れば数分以内に終了することができる。

そのようなモデル化の以下で説明する例は、モーター駆動式車両（例えば、電気車両、燃焼エンジンを備えた車両、ハイブリッド駆動部を備えた車両、燃料電池を備えた車両など）をベースとする。初めに、この車両の検査者（又は検査コンピュータシステムのユーザー）には、基本的なデータ、例えば、車両が電気モーター又は燃焼エンジンを有すること、それが如何なる車両モデルであるのかなどしか分からない。これらの情報は、ユーザーによって、検査コンピュータシステム２に入力することができ、場合によっては、検査インタフェース６を介した接続が構築された時に、検査コンピュータシステム２が、そのような情報を自動的に特定することもできる。基本的なデータは、（例えば、「運転者支援システムを有する」との）直接入力される情報と、（例えば、車両識別番号（ＶＩＮ）の表示から、そのような多数の属性のデータベースから自動的に照会することができる）間接的に特定される情報との混合体を含むこともできる。図２及び３に模式的に図示されている通り、このような基本的な情報に基づき、検査コンピュータシステム２がモデル５の初期インスタンス１００を選定することができる。モデル５の初期インスタンス１００は、例えば、相応の技術ユニット１に関する考え得るテンプレートのライブラリから、例えば、ネットワーク化された車両に関する考え得るテンプレートのライブラリから選定することができる。

このモデル５は、技術ユニットの構造又はコンフィグレーションを階層的に反映し、図示されたケースは、ツリー構造をベースとしている。このツリー構造では、個々の特性が、例えば、個々のコンポーネント又はサブコンポーネントを含むことができるモデルノード（１０００，１００１など）に集約されている。

このモデル５は、複数の階層的なレベルで構築されており、個々のモデルノードの間の階層的な関係及び／又はそれ以外の関係が、例えば、（例えば、システムとサブシステムの間の）機能の依存性の構造を表す接続ペイン１０によって表示されている。しかし、このモデルの構造とその関係は、例えば、木の根としての、検査インタフェース６と直に接続された入力ノードとの物理的な接続に基づき、それ以外の任意の構造にすることもできる。階層的に最も上のレベルは、最も上のモデルノード１０００において、モデル化された技術ユニット１を（例えば、車両形式及び車台番号として）識別する識別レベル２０１を形成する。その下では、モデルノード１００１において、モデル変化形態が識別される。破線で表示されたモデルノード１００１’により表される通り、各モデル５は複数の変化形態を有することができる。以下において、特に、図６及び７と関連して、モデル変化形態の構造と性質を説明する。

次の階層レベルは、コンポーネントレベル２０２と呼ぶことができる。そこでは、技術ユニット１の個々のコンポーネント４が表され、例えば、モデルノード１００２ａが、第一のコンポーネント４を表し、別のモデルノード１００２ｂ，１００２ｃなどが技術ユニットの別のコンポーネント４を表す。そのようなコンポーネントの例としては、例えば、エンジン制御部、走行動特性制御部、運転者支援システム、インストルメントパネル制御部などが挙げられる。

その下には、下位コンポーネント２０３が配備され、それらは、モデルノード１００３ａ，１００３ｂなどが、コンポーネントレベル２０２の個々のモデルノードにそれぞれ割り当てられた下位コンポーネントに関係する。

最も下の階層レベルは、相互作用レベル２０４と呼ぶことができる。そこに引用されているモデルノード１００４ａ，１００４ｂなどは、それぞれアクチュエータ、センサー、ユーザーインタフェースなどに関係することができる。相互作用レベル２０４のモデルノード１００４は、それぞれ階層に関して上位のモデルノードに割り当てられ、下位コンポーネントレベル２０３のモデルノード又はコンポーネントレベル２０２のモデルノードに割り当てることができる（第二の選択肢は図２に図示されていない）。

個々の階層レベルの符号は、単に具体的に説明する役割を果たし、決して本発明を限定すると解釈してはならない。特に、全てのモデルノードを技術ユニット１の「コンポーネント」と見做すことができ、モデルは、より多くの、或いはより少ないレベルを有することもできる。

これらの接続ペイン１０は、例えば、階層的な配置構成又は階層的な依存関係、それ以外の関係及び／又はデータ通信パスを表すことができる。一般的に、図１に図示されたモデル５のモデルノード及び接続ペイン１０を用いて、多数の特性を定義することができ、それらには、例えば、
ａ）部分システム及びシステム限界、
ｂ）インタフェース、センサー、アクチュエータ、
ｄ）（例えば、実装された機能、プロトコル、標準などの）機能性、
例えば、
ｄ１）各バージョンに関するより精確な情報、作成ツール（コンパイラー、リンカーなど）に関するデータ、デバッガー情報に関するデータなどを有する、ソフトウェア、含まれるライブラリ、実行時間環境などに関する情報、
ｄ２）ハードウェア（チップ製造業者、改訂版など）、デバッガーインタフェース（ＪＴＡＧ）に関するデータなど、
ｄ３）コンポーネントの間のデータパス、
などの技術的な実現形態の記述、
といった情報が挙げられる。

モデル５の初期インスタンス１００は、未知情報又はダミー情報と呼ばれる、所定の特性とモデルノードに関する不完全な情報を有する可能性がある。

モデル５の初期インスタンス１００は、例えば、個々のモデルノードの間に発生する可能性があるデータフロー及び通信関係を表現するために、階層構造と関係の無い別の表現レベルを有することができる。そのようなデータフロー１１は、例えば、図３に一点鎖線で表示されている。

実際の用途に転ずると、データフロー１１は、例えば、エンジン制御機器（ＥＣＵ）から変速機制御機器（ＴＣＵ）へのその時々のエンジン回転数の送信に関係することができる。エンジン制御機器は、例えば、モデルノード１００２ａにより表すことができる。これは、（例えば、センサー制御部及びインタフェース制御部を表す）下位システムのモデルノード１００３ａを介して、ノード１００４ａにより表される回転数センサーによって得られた測定値を受信する。エンジン制御機器（モデルノード１００２ａ）は、この測定値（又はこの測定値から導き出されたデータ）をノード１００３ｂに送信し、このノードは、そのデータをモデルノード１００３ａに更に転送する。この例では、ノード１００３ｂは、例えば、（例えば、アナログ・デジタル変換を含む）測定ノードであるとするか、或いは測定値の前処理（例えば、スケーリング）を実行することができる。ノード１００４ａにより表される（物理的な）センサーと、ノード１００３ａにより表されるユニット（例えば、測定前処理部）とは、共通の筐体内で組み立てることが可能であるが、それにも関わらず、論理的には、別個に観察することができ、従って、そのようにモデル化することもできる。その後、データは、例えば、ＣＡＮインタフェースを表すモデルノード１００４ｃに送られる。そして、このモデルノード１００４ｃは、ＣＡＮバスを介して、モデルノード１００２ｃにより表される変速機制御部にデータを転送する。同様に、このモデル５では、多数の別の考え得るデータフロー及び通信接続を表現することができる。

図２及び３の説明と関連して開示した性質は、理に適ったこととして、モデル５の初期インスタンス１００から展開した、以下において説明するモデル変化形態にも適用される。この場合、反復する詳細化プロセスにおいて、未知情報及びダミー情報が、以下において、図４及び５を参照して説明する具体的な特性に置き換えられる。

図４は、モデル５の詳細なインスタンス１０１のブロック図を図示しており、この詳細なインスタンス１０１は、モデルノード１００３ａの下位コンポーネントに関する（図４で情報ブロック１００３ａとして模式的に表示された）追加情報を追加されている。この情報ブロックは、例えば、使用される接続プロトコル、形式符号、開発段階、使用されるソフトウェア及びソフトウェアバージョン、ＣＰＵコントローラ又はマイクロコントローラに関する形式符号及び別の情報などを含むことができる。

初めに追加情報を取得する手法は、例えば、ユーザー照会であるとすることができる。ユーザーは、例えば、目視点検で検知可能であれば、目視検査によって、所定のコンポーネントが技術ユニット１内に組み込まれているのかを特定することができる。別の情報は、検査コンピュータシステム２から、詳細化プロセスによって、検査インタフェース６を介して半自動又は全自動で通過させることができる。ユーザーの介入を必要とする詳細化プロセスが「半自動で」と呼ばれ、それに対して、全自動の詳細化プロセスは、ユーザーの介入を必要としない。

半自動及び全自動の詳細化プロセスを実行するために、検査コンピュータシステム２は、例えば、スキャンを実行することができ、リバースエンジニアリングにより周知の方法が使用される。そのようなスキャンの例として、
ａ）プロトコルスニファーによる、実装された接続プロトコルとそのバージョンを特定すること、
ｂ）例えば、待ち時間などの追加の属性を測定すること、及び接続プロトコル（ソフトウェア、ハードウェア）の実装形態の詳細を特定すること、
ｃ）特別な構成のデータ通信（誘発行動）によって、コンポーネント及び／又はプロトコルを検知すること、
ｄ）メモリ（ＲＡＭ，フラッシュなど）を隈なく探して、パターンマッチングを用いて、既知のソフトウェアコンポーネントの署名を推定することによって、ソフトウェアを検知すること、
ｅ）既にコンパイルされたソフトウェアにおけるソフトウェアフロー構造を調査すること（制御フローインテグリティチェック）（その際、例として、例えば、Ｖａｌｇｒｉｎｄなどの既知のエラー分析ツールを使用することができる）、
が挙げられる。

場合によっては、上記のスキャンのために、ユーザーの専門知識によって、追加情報を取得することができる。これは、特に、未だ早い開発段階に在るか、或いは少ない実績値しか存在しない技術ユニットにとって有利である。

常に、スキャンプロセスの結果に基づき、技術ユニット１の実際のコンフィグレーションの少なくとも一つの特性を推定することを可能にする特徴的な挙動が検知された場合、このモデル５は、この情報により詳細化される。そのため、自動化可能なスキャンプロセスの適用によって、コンフィグレーショに関する情報レベルが、段階的に拡張されて、このモデル５の段階的に展開される詳細なインスタンス１０１に反映される。

スキャンプロセスは、誘発行動によって引き起こされる反応を分析して、評価することができるか、或いは、技術ユニット１自身によって引き起こされ、誘発行動に対する反応として生じない、技術ユニット１の挙動を評価することができる。例えば、データバス（例えば、車両のＣＡＮバス）上のデータの流れを検査コンピュータシステム２によって純粋に受動的に「傍受」することができる。そして、バス上に発生するデータ通信事象を分析、評価して、技術ユニットの特性を推測することができる。そのようなデータ通信事象の「傍受」は、誘発行動無しに可能であるが、それにより、達成可能な検知性能は制限されない。従って、更なる情報を取得できるようにするために、誘発行動を用いてデータ通信を目的通り引き起こすことが試みられる。この誘発行動は、例えば、検査コンピュータシステム２がデータ伝送機器３上に独自のデータの流れを発生させて、それに対する反応を分析、評価することであるとすることができる。しかし、例えば、検査コンピュータシステム２から与えられるユーザー操作を実行することによって、より複雑な誘発行動を行うこともできる。

この詳細化プロセスは、完全なコンフィグレーションが発見されるまで、検査コンピュータシステム２によって実行することができる。しかし、一般的に、これは、所与の時間内に実現可能でなく、その結果、詳細化プロセスは、判定条件が満たされると終了される。この結果は、確かに依然として欠落を有する可能性はあるが、モデルの初期インスタンス１００よりも明らかに高い詳細度を有する、洗練され、具体化されたモデルである。この判定条件は、例えば、識別されない特性の割合が或る割合を下回ることであるとすることができる。場合によっては、個々の特性をそれらの関係性に関して重み付けすることができ、識別されない特性の合計された重みが所定の値を下回った場合に、判定条件を満たすことができる。それに代わって、或いはそれに追加して、判定条件が、それ以外の判断基準、例えば、所定のテスト時間を含むことができるか、或いは、例えば、最後に実行された詳細化工程の結果を評価することもできる。この場合、詳細化工程が新しい情報を発生することに成功する限り、詳細化プロセスが更に実行される。場合によっては、別の判定条件と組み合わせて、詳細化プロセスに関する負担に対して、最早僅かな前進しか期待できなくなった場合に、詳細化プロセスを終了することができる。

本開示との関連において、詳細化プロセスを用いて展開されたモデル（即ち、モデル５の詳細なインスタンス１０１の最も完全なバージョン）が「第一の妥当なモデル変化形態１０２」と呼ばれる。

図５は、そのような技術ユニット１の第一の妥当なモデル変化形態１０２の模式的なブロック図を図示している。モデルノード１００２ａ，１００２ｂ，１００３ａ及び１００４ｃに関して、情報ブロック１１０２ａ，１１０２ｂ，１１０３ａ及び１１０４ｃで表示されている通り、所定の情報が特定できている。

考え得るコンフィグレーションに関するデータベースが拡大されて、本方法の益々自動的なフローが実現可能となるので、検査コンピュータシステム２によって全自動で実行できる詳細化プロセスの割合は、同様の、或いは同じ技術ユニット１で実行される検査の回数に応じて上昇する。それは学習システムである。最初の学習フェーズを乗り越えて、十分な情報がデータベースに保存されると、より複雑な課題であろうと、より短い時間で自動的に実行することができる。

第一の妥当なモデル変化形態１０２が識別されると、更なる詳細化が推測により行われる。これは、図６に例示して図示されている。図６は、第一の妥当なモデル変化形態１０２に基づき作成された、積層形態のレベルとして表示された複数の代替モデル変化形態１０３，１０３’及び１０３’’を図示している。これらの代替モデル変化形態１０３を作成する場合、先ずは、安全性検査と関連する全ての欠落している特性が特定される。その後、これらの特性毎に、それぞれ考え得る実装形態を表す複数の推測による仮定が設けられる。そして、これらの仮定の下で考え得る特性の組合せ毎に、代替モデル変化形態が作成される。

例えば、第一の妥当なモデル変化形態１０２では、所定の制御機器（例えば、モデルブロック１００３ｃで表される制御機器）において、如何なる具体的な実装形態がＴＣＰ／ＩＰスタックとして使用されるのかが分からない可能性がある。この理由から、今は、考え得る実装形態を有するＮ個の仮定が設けられる。これが第一の妥当なモデル変化形態１０２の単一の未知情報である場合、これは、正確にＮ個の代替モデル変化形態を生み出す。しかし、複数の未知の特性の考え得る実装形態を作成するには、一般的な手法が必要であり、これらの特性毎に、一定数の考え得る実装形態（Ｍ，Ｏ，．．．）が作成される。そのため、代替モデル変化形態の全体数が、各代替モデル変化形態の数の積（Ｎ×Ｍ×Ｏ．．．）として得られる。そのため、一般的に、代替モデル変化形態１０３の全体数は、高性能な検査コンピュータシステム２でしか調べて、検査することができない規模に達する。しかし、モデルの初期インスタンス１００の出発点と異なり、第一の妥当なモデル変化形態１０２がきっと判断基準を満たしているので、この課題は、所与の時間内に解決可能である。

代替モデル変化形態が作成された後、技術ユニット１の独自の安全性検査を行うことができる。

そのために、既に分かっている弱点が個々の代替モデル変化形態１０３に割り当てられる。この場合、識別された特性と設定された仮定が既知の弱点コレクションにより補正される。そのようなコレクションは、インターネットで自由に、或いは有料で入手可能である（例えば、ｈｔｔｐ：／／ｃｖｅ．ｍｉｔｒｅ．ｏｒｇ／又はｈｔｔｐｓ：／／ｗｗｗ．ａｕｔｏｍｏｔｉｖｅｉｓａｃ．ｃｏｍ／）か、製造業者、連盟などの内部のコレクションを使用することもできるか、或いはその両方である。この割当て後に、それぞれ既知の弱点に割り当てられた多数の代替モデル変化形態１０３が得られる。図７は、複数の参照１０４が既知の弱点に対して引用されて、所定のモデルノードに割り当てられた、図６に図示された代替モデル変化形態のブロック図を図示している。ここでは、場合によっては、複数の弱点を一つのモデルノードに割り当てることも、一つの弱点を複数のモデルノードに割り当てることもできる。

更に、攻撃目標が定義され、例えば、処理すべき攻撃目標のリストから攻撃目標を選定することができる。以下において、その一つの攻撃目標と関連して、安全性検査の実行を説明する。しかし、場合によっては、安全性検査は、複数の攻撃目標を包含することもでき、その場合、攻撃目標毎に同様に処理される。

ここで、攻撃目標に関して、代替モデル変化形態毎に、個々のモデルノードに対して既知の弱点を考慮した攻撃モデルが作成される。一般的に、各モデル変化形態における一つのノードが、この攻撃モデルにおける各ノードに対応する。弱点（と、場合によっては、実装された対抗措置と）が、一つのノードを潰す負担、そのため、攻撃目標までのパス上の障害物として克服すべき負担を決める（以下を参照）。攻撃モデルの階層構造は、既知のモデルノードに関して、これらのモデルノードに対して既に展開された攻撃モデルに頼るとともに、それらを各攻撃モデルにおいて利用することを可能にする。

場合によっては、例えば、未だ既知の弱点は存在しないが、（例えば、専門家によって）そのような弱点が是認できる時間内に発見できると予想されるノードに対して、「推測される弱点」を考慮することもできる。このノードに対して、推測される弱点を割り当てることができる。推測される弱点は、弱点データベースが未だ不完全であり、少量しか確保されていない場合のテストも実現可能にする役割を果たす。推測される弱点は、例として、例えば、ファジングなどの、予備知識が存在しない弱点を発見するための特別の技術によって、テストすることができる。

攻撃モデルのノードは、例えば、通貨、工数、時間、それ以外のリソースなどを単位として、それぞれノードに対してそれを克服するための負担に対応する負担に関する評価変数によって重み付けすることができる。ここで、定義された攻撃目標に関して、攻撃モデルのパス毎（即ち、テストベクトル毎）に、各ノードにおいて既知の弱点と各評価変数を利用して、評価を実行することができる。

しかし、この安全性検査に関しては、全てのテストベクトルの中の最も不利な値だけが重要であるので、各代替モデル変化形態の個々のテストベクトル毎の評価を求める必要はない。従って、一つのテストベクトルの評価は、そのテストベクトルの評価がそれまでに特定された最も不利な値よりも高いことが明らかな場合には、中止又は省略することができる。例えば、テストベクトル全体の中のそれまでに特定された最も不利な値よりも良い評価のノードを有するテストベクトルの評価を全く省くことができる。しかし、そのような代替テストベクトルは、詳細なモデルが変わり、従って、攻撃モデル又はそのパスの新たな評価を意味する場合に関係することができる。

安全性証明に関して定義された安全性判断基準を下回る、テストベクトルの評価が見出された場合、安全性検査を中止するか、或いは、技術ユニット１の安全性を向上させる措置、例えば、一つ又は複数のコンポーネントのソフトウェア又はファームウェアのアップデートを勧告するか、検査コンピュータシステム２によって実施することができる。その後、モデル変化形態を新たに特定して、安全性検査を繰り返すことができ、その時は、既に特定された特性を初めから使用することができる。

それ以外に、全ての代替モデル変化形態の全ての攻撃モデルの全てのテストベクトルの中の最も不利な値が特定されるまで、テストベクトルの評価が実行される。この（安全性値とも呼ぶことができる）最も不利な値が予め定義された安全性判断基準を上回った場合に、技術ユニットに対して安全性証明（セキュリティ証明）を出すことができる。更に、例えば、ソフトウェアのアップデートなどの、例えば、防護措置の識別によって、如何にして安全性を更に向上できるのかとの勧告を与えることができる。達成可能な安全性値に対するそのようなソフトウェアのアップデートの作用効果は、場合によっては、安全性検査のシミュレーションで事前にテストすることができる。場合によっては、一つ又は複数の防護措置の実行後に、新たな安全性検査を実行することができ、その際、それまでに特定された情報に頼ることができる。

安全性検査の工程は、反復して実施することができ、評価が安全性判断基準を下回るテストベクトルが発見されると、安全措置が実行され、その後、新しい知識に基づき本方法が続行される。

本方法を実施する場合、特性が、推測される仮定に基づき選定されているので、代替モデル変化形態に基づく攻撃モデルの多くのテストベクトルが、証明されていないコンポーネント又は特性に基づくノードを含むことを慎重に捉えるべきである。多数の代替モデル変化形態において、推測される仮定を有するノードを通過し、このノードが弱点を示すテストベクトルが発見されると、検査コンピュータシステム２により相応のサイバー攻撃を実行することによって、この弱点を現実の技術ユニット１において有効活用することを試みることができる。証明されたノードとテストベクトルも、この手法で（例として、例えば、侵入テスターなどの相応のツールによって）検査することができる。そして、この「実際の」攻撃は、調査結果を立証する役割を果たすことができる。場合によっては、それどころかひょっとしたら、攻撃が考えているよりも一層容易であり、そのため、実際は「コスト」（即ち、評価）がより小さいことが分かる可能性がある（例えば、容易に推測できるデフォルトのパスワードが付与されている可能性があり、その場合、ブルートフォース総当たり攻撃を適用する必要がない）。

例えば、（テストベクトルのノードに関する）所定のコンポーネントがＤＤｏＳ攻撃に弱いことが分かる可能性がある。そして、検査コンピュータシステム２が、テストベクトルに基づくエクスプロイトにより、そのようなＤＤｏＳ攻撃を実行することができる。そのようにしてサイバー攻撃が成功した場合、相応のテストベクトルがこの弱点を有さない全てのモデル変化形態を削除することができる。ここで、単一のモデル変化形態しか残っていない場合、そのことから、技術ユニット１の別の実際の特性を推定することができる。それによって、代替モデル変化形態の多様性を大幅に制限することができ、それどころか、場合によっては、このようにして、技術ユニットのコンフィグレーションをモデルに完全に反映させることが可能になる場合がある（即ち、その場合、技術ユニット１との完全な一致が証明された一つの代替モデル変化形態しか最早存在しない）。エクスプロイトの使用は、弱点の実際の内包を検査するために追加的に関係するとすることができ、そのように、ソフトウェアが基本的にこのような弱点によって打撃を受けるけれども、ソフトウェアのコンフィグレーションにおける簡単な変更又は追加の防護措置によっては、弱点を有効活用することはできない。

実行されたサイバー攻撃が成功することによって、一般的に、テストベクトルのノードが関連する一連のコンポーネント全体を完全に識別することができる。

評価が安全性判断基準を下回るテストベクトルが最早発見できなくなると、このシステムは「十分に安全である」と見做すことができ、安全性証明が出される。

各安全性検査において、得られた知識が評価されて、将来の安全性検査のために相応のデータベースに記憶される。例えば、サイバー攻撃を実現可能にするテストベクトル（即ち、弱点）が発見された場合、それから、将来の安全性検査において同様の技術ユニットを使用できる相応のテストケース、テストベクトルを、場合によっては、エクスプロイトを自動的に生成することができる。

本開示との関連において、前述した安全性検査時に同様の技術ユニットで検知されたパターンに基づく、テスト工程の自動的なフローが「テストケース」と呼ばれる。そのようなテストケースは、ここに開示した方法を大幅に短縮することができる。例えば、より早い安全性検査に基づき、技術ユニットの所定の形式又は所定のモデルがしばしば所定のテストベクトルに関する虚弱性を有することを検知することができる。ここで、このテストケースを用いて、モデル化の途中で、早くも相応のエクスプロイトを実行することができ、その成功又は不成功が、技術ユニットの実際のコンフィグレーションを推定することを可能にする。この場合、本開示との関連において、一つのテストケースのエクスプロイトが「誘発行動」と呼ぶことができ、その結果が、技術ユニットの特徴的な挙動を表す。

上述した手順は、極めて自動化されたテストの実行及びテストの評価を実装することを可能にして、技術ユニット１における機能的及び非機能的なエラー又は一般的に違反を検知することができる。

場合によっては、安全性検査の途中に（或いはその結果として）、安全措置及び／又は改善措置を提案して、場合によっては、試すこともできる。これらの提案は、攻撃モデル又はその少なくとも一つのテストベクトルを変える、コンフィグレーションの仮定又はシミュレーションされた仮想的な変更、例えば、ノードによって表されるコンポーネントのソフトウェアのアップデートから得られる。この場合、提案される改善措置の実証は、例えば、
ａ）（モデルでの純粋に計算による）攻撃モデルのシミュレーション、
ｂ）シミュレーション環境でのシミュレーション（即ち、技術ユニットが、少なくとも部分的に、その上で動作するソフトウェアバージョンによりシミュレーションされる仮想的なシミュレーションシステムに反映される）、
ｃ）実際の技術ユニット（例えば、検査台における物理的な車両）でのテスト（場合によっては、技術ユニットの個々のコンポーネントを（コ）シミュレーションの形で仮想的な同等物で置き換えることができる）、
の三つの形態で行うことができる。

そして、この実証は、ここに開示された安全性を検査する方法に応じて行われ、現実の技術ユニットの代わりに、部分的又は完全にシミュレーションされた技術ユニットが投入される。

ここに記載した方法は、安全性検査に関して、テストケースを自動的に発見し、優先順位を付け、付属するテストベクトルを識別し、エクスプロイトを生成し、安全性検査の自動的な実行を定義し、テスト事象の評価を自動的に支援することを可能にする。それによって、限られた（即ち、所与の）テストリリース（例えば、最大テスト時間）で、出来る限り大きなテスト成果を達成することができる。これは、全体システム（即ち、技術ユニット）における関連する（優先順位の高い）弱点の中の出来る限り多くを出来る限り高い確率で識別できることを意味する。

本方法は、更に、所与の環境下において（例えば、「ブラックボックステスト」の途中で）、技術ユニットに関する当初存在しない、或いは不完全に存在する情報（例えば、システム構造に関して欠落する細部、コンポーネントと下位コンポーネントの関係性、コンポーネントの特性、既知の弱点など）、関連するテストベクトルを識別して、所要のテストケースを選定又は生成することを可能にする。

１ 技術ユニット
２ 検査コンピュータシステム
３ データ伝送機器
４ コンポーネント
５ モデル
６ 検査インタフェース
１０ 接続ペイン
１００ 初期インスタンス
１０１ 詳細なインスタンス
１０２ 第一の妥当なモデル変化形態
１０３ 代替モデル変化形態
１０４ 参照
２０１ 識別レベル
２０２ コンポーネントレベル
２０３ 下位コンポーネントレベル
２０４ 相互干渉レベル
１００ｘ モデルノード
１１０ｘ 情報ブロック

Claims (12)

1. 少なくとも一つの第一の妥当なモデル変化形態と、場合によっては、一定数の代替モデル変化形態とが特定される、技術ユニット（１）の安全性を検査する方法であって、
   この方法が、検査コンピュータシステム（２）上で実施され、
   この方法が、
   ａ）既知の弱点をモデル変化形態のコンポーネントに割り当てる工程と、
   ｂ）攻撃目標を定義する工程と、
   ｃ）モデル変化形態に対して、攻撃目標に関する少なくとも一つの攻撃モデルを作成する工程と、
   ｄ）少なくとも一つの評価変数に関して、攻撃モデルのノードを重み付けする工程と、
   ｅ）この評価変数に関する攻撃モデルの少なくとも一つのテストベクトルの評価を特定する工程と、
   ｆ）全ての評価の中の最も不利な値として安全性値を特定する工程と、
   ｇ）この安全性値が安全性判断基準に合致する場合に、安全性証明を出す工程と、
   を有する方法。
2. 前記の少なくとも一つの第一の妥当なモデル変化形態と、場合によっては、一定数の代替モデル変化形態とが、検査コンピュータシステム（２）を用いて、技術ユニット（１）のコンフィグレーションの少なくとも一つの第一の妥当なモデル変化形態を特定する方法に基づき特定され、この技術ユニット（１）が、少なくとも一つのデータ伝送機器（３）と、このデータ伝送機器（３）を介してデータ通信できる多数のコンポーネント（４）とを有し、前記の特定する方法が、
   ａ）検査コンピュータシステム（２）の検査インタフェース（６）と技術ユニット（１）のデータ伝送機器（３）との間の接続を構築する工程と、
   ｂ）技術ユニット（１）のコンフィグレーションのモデル（５）の初期インスタンスを特定する工程と、
   ｃ）この初期インスタンスを出発点として、一連の詳細化プロセスによって、モデル（５）の詳細なインスタンスを展開する工程であって、少なくとも一つの詳細化プロセスが、検査コンピュータシステム（２）によって自動的に実行され、この詳細化プロセスが、
   ｃ１）場合によっては、誘発行動を実行する工程と、
   ｃ２）技術ユニットに特徴的な挙動を特定する工程と、
   ｃ３）この特徴的な挙動を分析して、技術ユニット（１）の実際のコンフィグレーションの少なくとも一つの特性を推定する工程と、
   ｃ４）この特定された少なくとも一つの特性によりモデル（５）を詳細化する工程と、
   を有する工程と、
   ｄ）少なくとも一つの判定条件が満たされた場合に、モデル（５）の詳細なインスタンスを第一の妥当なモデル変化形態として識別する工程と、
   を有する請求項１に記載の方法。
3. 検査コンピュータシステム（２）を用いて技術ユニット（１）のコンフィグレーションの少なくとも一つの第一の妥当なモデル変化形態を特定する方法であって、
   この技術ユニット（１）が、少なくとも一つのデータ伝送機器（３）と、このデータ伝送機器（３）を介してデータ通信できる多数のコンポーネント（４）とを有し、
   この方法が、
   ａ）検査コンピュータシステム（２）の検査インタフェース（６）と技術ユニット（１）のデータ伝送機器（３）との間の接続を構築する工程と、
   ｂ）技術ユニット（１）のコンフィグレーションのモデル（５）の初期インスタンスを特定する工程と、
   ｃ）この初期インスタンスを出発点として、一連の詳細化プロセスによって、モデル（５）の詳細なインスタンスを展開する工程であって、少なくとも一つの詳細化プロセスが、検査コンピュータシステム（２）によって自動的に実行され、この詳細化プロセスが、
   ｃ１）場合によっては、誘発行動を実行する工程と、
   ｃ２）技術ユニットに特徴的な挙動を特定する工程と、
   ｃ３）この特徴的な挙動を分析して、技術ユニット（１）の実際のコンフィグレーションの少なくとも一つの特性を推定する工程と、
   ｃ４）この特定された少なくとも一つの特性によりモデル（５）を詳細化する工程と、
   を有する工程と、
   ｄ）少なくとも一つの判定条件が満たされた場合に、モデル（５）の詳細なインスタンスを第一の妥当なモデル変化形態として識別する工程と、
   を有する方法。
4. 前記の技術ユニットに特徴的な挙動を特定する工程が、検査コンピュータシステム（２）によって、データ伝送機器（３）を介して伝送されるデータを傍受することを含むことを特徴とする請求項２又は３に記載の方法。
5. 前記の技術ユニットの実際のコンフィグレーションの特性が、コンポーネント（４）の少なくとも一つの特性及び／又はコンポーネント（４）の間の少なくとも一つの関係から選定されることを特徴とする請求項２～４のいずれか１項に記載の方法。
6. 前記の第一の妥当なモデル変化形態に基づき、少なくとも一つの代替モデル変化形態が作成されることを特徴とする請求項２～５のいずれか１項に記載の方法。
7. この方法が、更に、
   ａ）特定された弱点に基づき選定された少なくとも一つのサイバー攻撃を技術ユニット（１）に対して実行する工程と、
   ｂ）このサイバー攻撃により達成された効果を評価する工程と、
   ｃ）この達成された効果が決定的でないモデル変化形態を削除する工程と、
   を有することを特徴とする請求項１に記載の方法。
8. この方法が、更に、
   ａ）技術ユニット（１）のコンポーネント（４）にインストールされた少なくとも一つのソフトウェア及び／又はファームウェアを特定する工程と、
   ｂ）検査コンピュータシステム（２）により、このソフトウェア及び／又はファームウェアを詳細化する工程と、
   を有することを特徴とする請求項１又は７に記載の方法。
9. この方法が、更に、
   ａ）技術ユニット（１）のコンポーネント（４）にインストールされたソフトウェアを特定する工程と、
   ｂ）このソフトウェアの詳細なバージョンを含むシミュレーションされたモデル変化形態を作成する工程と、
   ｃ）このシミュレーションされたモデル変化形態に基づき安全性値を特定する工程と、
   を有することを特徴とする請求項１、７又は８に記載の方法。
10. 技術ユニット（１）が車両である、特に、ＳＡＥ標準Ｊ３０１６のＳＡＥレベル０～５の中の一つに基づく自律的な車両であることを特徴とする請求項１～９のいずれか１項に記載の方法。
11. コンピュータプログラム製品であって、この製品がデジタルコンピュータの内部メモリに直にロードすることができ、コンピュータ上で動作する時に請求項１～１０のいずれか１項に基づく工程を実施するためのソフトウェアコード部分を有するコンピュータプログラム製品。
12. 検査コンピュータシステム（２）であって、その上で、請求項１１に記載のコンピュータプログラム製品が動作する検査コンピュータシステム。

Images