自動運転車の安全性保証、検証、認証の見直し

2022年2月6日にarXivにアップロードされたレビュー論文「自動運転車の安全性保証、検証、認証：調査」は、米国オハイオ州立大学の著者によって執筆されました。

自動運転に伴う課題は、もはや 自動運転車（AV）  製造ではなく、安全な操作を確保することです。レベル3およびレベル4の自動運転の最近の進歩により、複雑なAV操作の安全性の保証に関するより広範な研究が促進され、これは既知および未知の危険なシナリオを最小限に抑えるというISO 21448（意図された機能の安全性、またはSOTIF）の目標と一致しており、「  ゼロデス（VZ）   ” – 2050年までに交通事故による死亡者をゼロにする。

AVモーションコントロールの安全性を確保するためのアプローチのほとんどは、  フォーマル 特に方法 到達可能性分析 (RA)  システムの動的な進化の数学的モデルに依存して保証を提供します。この論文では、  安全性の検証と検証 そして 認定プロセス  、AVに最適な正式な安全技術を検討しました。

著者らは、完全自律走行車の形式的またはサンプルベースの安全性検証と評価を提供できる、統一されたシナリオカバレッジフレームワークを提案しています。最後に、AV の安全性保証に関する課題と将来の機会について説明します。

自動運転車技術に関するこれまでの調査では、認識、意思決定、車両制御、人間と機械の相互作用など、技術的な課題と実装のさまざまな側面に焦点が当てられてきました。一部の調査では、自動運転車の安全性も取り上げられています。  検証と妥当性確認 (V&V)  質問。

自動運転システムが現実世界に導入されるにつれて、現実世界のシナリオの規模に基づいた多くの検証と検証が必要になります。シナリオの範囲を最大化するための一般的な検証および妥当性確認戦略は、仮想シミュレーションで検証し、生成された多数のシナリオ サンプルをシミュレートすることです。

シナリオ サンプリングに基づく V&V が直面する課題は、合理的なカバレッジを確保するために必要なサンプル サイズを定量化し、それによって自動運転の不適切な運転によって引き起こされるリスクを制限することです。合理的なシナリオ範囲の保証は、高度自動運転車両 (HAV) の導入に関する最近の法律における認証の前提条件でもあります。ただし、形式検証に基づく別のグループのアプローチでは、仕様の満足を通じてシナリオ カバレッジの問題に別の方法で対処します。シナリオカバレッジにおける形式手法の可能性により、新たな研究では、形式プロパティと制御合成および安全性検証を組み合わせることが始まります。

自動運転の定量的な検証の必要性を考慮して、自動運転のシナリオカバレッジにおける未解決の困難を解決するために、ここでは統一されたシナリオカバレッジフレームワークを提案します。単一のシナリオ（例に基づくアプローチの場合）が与えられた場合、許容可能なカバレッジの量、いわゆる「  仕様浸透率 このフレームワークは、安全シナリオカバレッジの統一された定量的定義を提供します。この定量的定義は、サンプルベースと形式的手法を組み合わせて、安全性検証のシナリオカバレッジを提供します。候補となる自律走行車の制御戦略は、指定された範囲で形式的またはサンプルベースの安全性検証によって検証できます。   ODD（操作定義領域）  シナリオは、セキュリティ シナリオの範囲をテストします。著者らは、このような安全性の範囲をどのように達成するか、また、関連するコストやアプローチの議論に基づいて、サンプルベースのアプローチと正式なアプローチの長所と短所を比較しています。

次の表は、自動運転に関する法律の現状を示しています。

責任の決定 これは、自動運転システムの導入において解決する必要がある新たな問題です。レベル3では、予期せぬ状況や困難な状況が事前にドライバーに引き継がれている限り、自動運転システムは限られたODD環境内での安全を確保するだけでよいため、責任を負うことはありません。たとえ人間の運転手が間に合わず運転を引き継げなかったとしても、ブレーキ、停止、ハザードランプの点灯などのフェイルセーフ操作により、自動運転システムの責任はある程度免除される可能性がある。レベル4以上の自動運転車両に正式な安全性検証が搭載されている場合、形式論理を使用して簡素化することができます。  責任の決定 下図に示すように、サンプルの安全性検証に基づいて開発された自動運転システムの場合、責任の形態を決定するために同様の手順がどのように実行されるかは明らかではありません。

広く使用されている安全ガイダンス規格 ISO 26262「道路車両 - 機能安全」は、既知のコンポーネントの故障（つまり、既知の危険な状態）に関連する既知の不当なリスクを軽減する場合にのみ適用されますが、複雑な環境変数によって引き起こされる自動運転のリスクや、車両に技術的な故障がない場合でも自動運転システムがこれらのリスクにどのように対応すべきかについては対処していません。

上記の安全上の課題を考慮して、ISO 21448 では、図に示すように、自動運転機能設計の既知および未知の危険なシナリオの結果を最小限に抑えるという目標を記述した定性的な目標を提案しています。

しかし、このSOTIFの目標を達成するための課題は、  実地運用試験 ただし、テスト中に自動運転のあらゆるシナリオを網羅することは困難です。課題はあるものの、シミュレーション テストでのシナリオ カバレッジの最大化や形式手法による安全性保証の作成など、ISO 21448 の目標に近づくことができる安全性分析の有望なアプローチと方向性がいくつかあります。

技術的には、「十分に安全」とは通常、指定された ODD シナリオに対する完全または適切なシナリオ カバレッジを意味します。実際、既存の規制の要件は比較的弱く、「いくつかの主要なシナリオ」のみをチェックする必要があるだけです。

離散シーンの周囲に「δ 近傍」を導入してシーン サンプルに「ボリューム」を割り当てることは、有望な試みです。 Tワイズやポアソン過程などの数学的アルゴリズムは、   「ほぼ満杯  ” 統計報道。

この定量的なカバレッジがコミュニティ全体で解決され受け入れられると楽観的に仮定すると、サンプルされた各シナリオには「  報道量 サンプル アプローチに基づく完全なシナリオ カバレッジ タスクでは、十分な数のサンプリング検証テストを実行して、「カバレッジ ボリューム」の各単位が少なくとも 1 つの安全性テスト結果に関連付けられていることを確認します。

実際、シーン空間のいくつかの側面により、安全なテスト結果を生成できない場合があります (たとえば、障害物に対する反応距離が小さすぎるなど)。このような場合、これらのシナリオが実際に安全でないことを確認するために追加の作業が必要になります。型式承認と認証に関しては、権力者は国民の期待に応える許容可能な成功基準を設定する必要があります。最も単純なしきい値は、安全性を確認するさまざまなテストの数と、ODD シナリオをテストするために必要な最小テスト数の比率です。

多様なテストシナリオのサンプリングは、自動運転の開発段階で安全管理を強化するための主な方法の 1 つです。既知および未知の危険なシナリオを最小限に抑えるという SOTIF 最適化の目標を達成するという点では、サンプルベースの方法は、未知の危険なシナリオを発見する際のバイアスが少なく、探索能力が高く、未知から既知へのプッシュは「水平」です。つまり、サンプルされたすべてのシナリオは通常、一貫したシミュレーション環境にあり、忠実度も同じレベルです。

図に示すように、形式手法とサンプルベースの手法のシナリオカバレッジを比較すると、形式手法はより抽象的なレベルの安全仕様から始まり、シナリオ空間で単一のカバレッジがより大きくなる可能性がありますが、形式仕様を制御合成または監視に統合するプロセスはコントローラーの数学に依存する可能性があり、面倒です。ランダム生成プロセスのため、サンプルベースの手法のシナリオカバレッジはより散在していますが、ケースはシミュレーション層から直接カバーされるため、サンプリングプロセスがシンプルで実装が容易になります。どちらのアプローチも、最大限の検証シナリオを実際の運転に投影しようとしますが、シミュレーション レイヤーと実際の運転の間には常に違いが存在します。

テストベースのセキュリティ検証および保証方法と比較して、形式手法は厳密な論理的基礎を備えているため、ステートメントの信頼性が高くなります。

自動運転車の安全性において一般的に使用される正式なアプローチには、次のものがあります。  モデル検査  、  到達可能性分析 そして 定理の証明  。  モデル検査 ソフトウェアの動作が設計仕様に準拠していることを確認するためのソフトウェア開発から生まれました。安全性の仕様が公理と補題で表現される場合、次のように表現できる。  定理の証明 最悪の事態を想定した安全性を検証します。  到達可能性分析 この分析は、動的運転タスク (DDT) の主な特性を捉え、動的システムの安全性ステートメントを生成する固有の機能を備えているため、これら 3 つの分析の中で特別な位置を占めています。

実際の道路テストまたは フィールド運用テスト (FOT)  これは、自動運転車の検証と妥当性確認 (V&V) の最終ステップであり、費用のかかる方法です。ある意味、これが検証する唯一の方法です。しかし、FOT の欠点も明らかです。候補となる自動運転コントローラが車両に搭載されている場合、十分なシナリオ カバレッジ機能 (特に衝突寸前や衝突のシナリオ) が欠けています。この図は、サンプルベース、形式、および現場運用テスト (FOT) 方式の比較を示しています。スコアの範囲は 0 から 10 で、10 が最高の満足度を表します。

形式手法 数学の厳密な手法 (通常は論理計算の形式) をソフトウェアおよびエンジニアリング設計の仕様と検証に適用する一連の方法。定義上、安全性検証タスクには固有の利点がありますが、継続的なダイナミクスを伴うシステムの複雑さが高く、スケーラビリティによって生じる困難さが、自動運転への広範な適用を制限する主な要因となっています。技術的に言えば、形式手法は、制御されたシステムの動作が規定された仕様を満たすことができるように、抽象的な仕様をシステム制御アルゴリズム/手順に実装または変換するプロセスとして要約できます。

定義された動的システム:

最大前方到達可能集合 定義は以下のとおりです

前方到達可能セット (FRS) は、初期時間 t0 から始まり、将来の時間 t 内のすべての可能な到達可能な状態にダイナミクスを伝播します。

対照的に、後方到達可能集合（BRS）の後方伝播は、現在の時刻t0における特定の目標状態集合Xgoalにつながる、前の時刻tからのすべての可能な状態を見つける。これは次のようになる。  最大後方到達可能集合 意味

さらに、最小 BRS は次のように定義されます。

場合によっては、定義された時間枠内での到達可能性がより重要になります。したがって、定義は現在時刻から時間範囲の終了までを含むように拡張され、たとえば、最大前方到達可能セットの定義は次のように修正されます (他の類似点):

さまざまな交通関係者間の相互作用が重要な役割を果たす場合、参加するエージェントや時には敵対するエージェントの影響をアクセシビリティ分析に組み込む必要があります。この場合、動的システムは、この敵対的制御入力を表すために追加の入力 d を導入します。

このように、システムにおける敵対的入力の影響は自車両の制御に依存せず、最悪のシナリオで安全性を保証するためには保守的にモデル化する必要があります。

以下は、敵対勢力の影響をさらに制限する最大 FRS の定義です。

コンピュータサイエンスとロボット工学では、  信号時間領域ロジック (STL)  これは、連続変数を含む時間的に重要な要件を表現および指定するための汎用言語です。次の表は、STL の基本的なセマンティクスを示しています。つまり、STL は、変数などの非論理オブジェクトを定量化する一連の形式システムの定義である一階述語論理を使用して、変数の時間的変化を記述します。

次の表は、基本的な STL セマンティクスを示しています。

自動運転車の暫定的な安全仕様の例としては、「交通事故を起こさない」などが挙げられますが、STL 仕様に変換すると、暫定仕様の曖昧さの一部を排除する必要があります。まず、「原因」という用語は、衝突責任の決定の複雑さを伴うため、STL では明確に定義されておらず、責任に中立的な用語である「起因」という用語に置き換える必要がある場合があります。その後、一時的な規範は「交通事故に遭わないこと」になりました。 2 番目に、STL では仕様に正確に定義された時間範囲が必要です。自動運転の場合、時間範囲の概念は、時間範囲を実用的で扱いやすいレベルに短縮するためによく使用されます。したがって、暫定仕様は、「（時間枠内で）衝突しない」とさらに修正される可能性があります。

上記の STL から変換された安全仕様は、アセンブリ言語では依然として抽象レベルのままです。仕様をコントローラ アーキテクチャに統合するか、十分な信頼性または決定的な証拠に基づいて設計されたコントローラの安全性検証を実行して仕様を満たしていることを確認するのは、自律走行車の制御アルゴリズムの設計者の責任です。

制御合成に加えて、STL で表現された安全仕様は、コントローラのプロトタイピング中に安全違反を示すアサーションとして使用できるため、開発者は制御設計中に常に安全仕様を意識できます。安全仕様を決定する論理計算は、通常、決定を解くことによって解決される。  充足可能性法理論 (SMT)  問題は解決済みです。

サンプリングベースの方法 多数のシーンのサンプルを入力して、シーンの変化を確認します。サンプリングベースの方法とは異なり、形式検証は、コントローラーに安全仕様を実装し、環境シミュレーションで一定レベルの現実性を実現することに重点を置いています。これは、セキュリティを検証するためのメカニズムが異なるためです。正式な安全哲学では、安全仕様は満たされるか違反されるかのいずれかであり、仕様の満足度はモデルベースの制御設計に統合されます。設計が完了すると、運用中の実装を保証する責任は、モデルの正確性のオンライン検証に移行します。制御指向モデルが正しいことが検証され、コントローラーが包括的な安全仕様に従って動作する限り、システムの安全性が証明されます。

一般性を失うことなく、安全仕様 φ は、場合によっては実現できない可能性があります (例: 避けられない衝突)、 ∀u,(s,t)/| = φ。この場合、φ 統合コントローラは、φ を達成するための実行可能な制御シーケンスを見つけることができず、せいぜい、状況を計画された緊急事態または偶発的対応戦略 (衝突衝撃準備など) に引き上げることになります。いずれにしても、設計された φ 合成コントローラは利用可能なアクションを使い果たし、それでも φ を満たすアクションを見つけることができないため、コントローラは避けられない損傷のために故障することはありません。

ISO 21448によれば、  シナリオ シリーズです シーン 複数のシナリオ間の時間的発展の説明。シナリオは環境のスナップショットであり、  景色  、動的要素、すべての参加者と観察者の自己表現、およびこれらのエンティティ間の関係。この定義に基づくと、定義された OOD で完全な安全性を確保するタスクは、ODD のすべての可能なシナリオのバリエーションに対して安全性の検証と検証 (V&V) を実行することとして説明できます。 ODD におけるシーンの変化には、最初のシーンの変化と、最初のシーン以降の時間的展開の変化という 2 つの側面があります。シーンの変化のさまざまな次元が図に示されています。

サンプルベースの方法では、各シーン サンプルが基本的でサイズが小さいため、各サンプル シーンに明示的に関連付けられたボリューム属性はありません。両方の安全性検証方法を統一的に比較し、活用するためには、サンプルベースの方法にシナリオボリュームの概念を割り当てる必要があります。簡単にするために、連続する N 次元がすべて互いに直交していると仮定し、N 次元シーン空間内の軸に沿ったポリゴン ボリューム「p01、p02、...、p0N」を、パラメーター セットで指定されたシーン サンプルに割り当てます。

サンプルベースのアプローチでは、シミュレートされたシナリオの安全性が各シナリオ サンプルでチェックされます。一方、形式手法では、通常、シミュレーションを実行する前に安全性の仕様から開始し、次にその仕様を線形時相論理 (LTL) や信号時相論理 (STL) などの機械が理解できる言語ステートメントに変換します。変換された仕様は、シミュレーション/実際のテストで仕様の妥当性をチェックするか、制御合成中に仕様をシステム制約またはその他の制御設計機能に変換することによって適用されます。

理想的には、形式手法の場合、すべての安全関連の仕様が最初に現実的に機械が理解できるステートメントに翻訳され、合成コントローラがこれらのステートメントを完全に尊重し、モデルベースのコントローラを使用して（シミュレートされた）環境を完全にモデル化した場合、シミュレーション層に関するシナリオ カバレッジは 100% になります。

たとえば、「自律走行車は常に衝突しないはずである」という表現は、自律走行車とシミュレーション モデル内の他のターゲット間の占有重複を評価し、シミュレーションで重複が発生した場合に true を返す数学関数の形式で検証可能な表現に変換できます。

しかし、次のような理由から、実際的な課題により、正式な安全仕様を 100% 理想的に翻訳することが妨げられています。まず、形式手法は現実世界の抽象化に基づく視点に依存しているため、抽象化と現実の間に (大小を問わず) 差異が生じ、効果的な安全保証が損なわれます。第二に、実際に開発されるコントローラにはパフォーマンス上の制限があり、いかなる状況でも安全仕様を満たすことができない場合がよくあります。第三に、正式な安全仕様を安全性検証または制御合成に変換する場合、実用的なスケーラビリティの困難が生じます。つまり、現実には形式手法の普及率は 100% 未満であることが多いのです。正式には、浸透率は、正式な安全仕様で指定されたシナリオ サブスペース内の検証可能なシナリオの割合として定義されます。

実際には、特定の ODD における自律走行車の候補コントローラの仕様浸透度を調べることは困難な場合があります。まず、定理証明などの演繹的形式手法は、比較的単純な離散動的システムに限定されます。定理証明を連続動的システムに拡張するには、さらなるフレームワークの構築と相当な計算リソースが必要です。第二に、モデル検査などの従来のアルゴリズム形式手法は、連続的な動的システムには適用できません。連続的なアクション空間を細かく離散化する必要がある場合、すべての可能なアクションを徹底的にテストすると、コンピューティング リソースの問題も発生します。しかし、STL と到達可能性解析を組み合わせた最近の進歩により、ODD シナリオ空間で候補コントローラの検証演算を計算し、候補コントローラが STL 仕様を満たさない体積分率を予測することで、この侵入を評価できるようになりました。標準的な透過率計算の問題は未解決のままであり、将来の研究では演繹的およびアルゴリズム的なさまざまな証拠収集方法を組み合わせて、さまざまな代替手段が提供されるかもしれません。

シナリオ カバレッジを完了するためのルートを図に示します。形式手法とサンプル ベースの手法はどちらも、自動運転車の安全制御の弱点を発見するのに役立つ効果的なツールです。自動運転車の制御開発者は、利便性と好みに応じて、これらの手法のいずれかまたは両方を選択できます。

この図は、実際にはセキュリティ検証のための制御ポリシーの進化を示す概略図です。 (a)-(e) では、形式手法は ODD のセキュリティ仕様 (a) から開始し、その後、初期セキュリティ仕様の侵入テストを実行して、セキュリティ仕様がどの程度適切に保持されているかを確認します (b)。次に、実現可能性チェックを実行して、実際に安全に実行可能な障害シナリオがいくつあるかを確認します (c)。次に、自律走行車のコントローラを再設計して障害シナリオ領域 (d) を修正し、最後に候補となる自律走行車コントローラを使用して、すべての安全で実行可能なシナリオの安全性を検証します。 (f)-(j)では、サンプルベースのアプローチは、まずODDを検証可能なシナリオ単位に分割し(f)、次に不完全なサンプリング安全性テストを実行して、候補となる自律走行車コントローラの主な問題を確認します(g)。次に、シーンのカバレッジを確実にするために、完全に飽和したサンプリングが実行されます (h)。完全なシナリオカバレッジテストの後、コントローラーの弱点が明らかになり、再設計プロセスが繰り返されます (i)。最終的には、コントローラの弱点は減少しなくなり、コントローラの再設計プロセスが終了する可能性があります (j)。形式手法により、安全な実行不可能なシナリオ領域を決定でき、安全な実行不可能なシナリオ ボリュームを除く ODD 内のすべてのボリュームが検証されると、それ以上の再設計は必要なくなることに注意してください。

安全性検証は、予測モジュールを使用してシミュレーション中（オンライン）またはシミュレーション後（オフライン）に実行できます。結果を確認するだけです。図は、さまざまな検証スキームの概要を示しています。

自車両と参加する交通エージェントの制御戦略が既知（ホワイトボックス制御）または部分的に既知（グレー制御）の場合、形式手法はこの情報を活用して到達可能なセットを絞り込み、車両の動きの「より厳密な」予測を提供して、オンラインの安全性監視や検証などの貴重なアプリケーションにつながります。対照的に、制御戦略が独自のものであり、完全に不明な場合（ブラックボックス制御）、安全性検証プロセスには、各シミュレーション後のブラックボックス コントローラーの動作の統計的学習が含まれる必要があり、これにより、反例をより適切にターゲットとするためにテストする次のシナリオの選択がガイドされます。

• A. 既知の制御ポリシーの正式なセキュリティ検証  。制御戦略が完全にわかっている場合（通常は自車両に限定されます）、安全性検証を高い確実性で実行でき、到達可能性解析（RA）で制御変数 u を効果的に排除できます。これは通常、制御対象車両の到達可能セットを計算し、関連する時間間隔中の障害物占有セットと比較することによって実現されます。
• B. ブラックボックス制御ポリシーの正式なセキュリティ検証  。制御戦略が完全に不明な場合、検証では、制御戦略情報を必要としない、より一般的な計画にフォールバックする必要があります。このようなプログラムは、コントローラーとプラットフォームを全体的なシステムとして考え、システム全体への入力 (外乱など) がどのようにして望ましくない出力 (安全違反など) につながる可能性があるかを調査します。ブラックボックス検証に関するレビュー論文には、シミュレーテッドアニーリング、進化アルゴリズム、ベイズ最適化、拡張アリコロニー最適化などのいくつかの方法がリストされています。
• C. グレーボックス制御ポリシーの正式なセキュリティ検証  。制御戦略が部分的にわかっている場合は、修正された到達可能性解析 (RA) 形式手法を実行できます。半自動運転車の設定では、人間のドライバーの行動はせいぜい推定することしかできず、部分的に既知の制御戦略（この場合は、人間のドライバーの戦略）を使用して安全性を検証する必要があります。この設定では、人間のドライバーのステアリング戦略を既知で不変と見なし、人間のドライバーの加速戦略を未知で可変と見なす特定の車線維持支援コントローラが設計されています。この処理アプローチにより、到達可能性分析 (RA) は適切な時間枠内で車両の到達可能な状態範囲を予測することができ、システムは現在の車両の状態を後方到達可能安全セット (BRS) と比較することで人間の運転手に支援が必要かどうかを判断できます。制御戦略または機能の少なくとも定性的な目標がわかっている場合（たとえば、ドライバーのエラーによる回避可能な衝突を回避するために介入をアクティブにするなど）、到達可能性分析（RA）を使用して、そのような制御戦略または機能がその定性的な説明に忠実であるかどうかを検証できます。たとえば、衝突回避システムが介入する機会を逃したか、または悪用したかどうかを判断するために使用できます。

次の表は、到達可能性分析 (RA) 展開の形式化と提供される保証の種類を示しています。

形式手法は、現在の運転状況の重大性に関する有用な情報を提供することができます。この情報を使用して、安全性が重要なシナリオから自車両を安全な状態に保つために、異なる制御スキームが必要かどうかを判断するための標準を開発できます。

仲裁基準の一つは、車両が 衝突不可避状態（ICS）  これは、ISO26262 の自動車安全度水準 (ASIL) を決定する上で重要な量である衝突頻度を推定する際に、衝突までの時間 (TTC) などの従来の脅威指標よりも衝突の近接性を測る信頼性の高い指標であると主張されています。車両がこの状態になった場合、衝突は避けられないため、衝突に備える必要があります（通常はブレーキをかけて減速するか、無過失の軌道をたどる）。このコンセプトは、自動緊急ブレーキ（AEB）をいつ作動させるか、衝突回避操作を実行するかを決定するなどの ADAS 機能のプロトタイプ作成にすでに使用されています。このような ICS を決定するには、通常、到達可能性分析 (RA) が使用されます。動的な交通シナリオにおいて移動する障害物の予測が重要である場合に、ICS の確率的等価性を作成するための確率的フレームワークが提案されています。特定の半自動運転または ADAS 機能の場合、システムが衝突回避不可能な状態 (ICS) にあるかどうかを判断すると、ADAS の介入が見逃されたか、または不要であったかどうかを判断するのに役立ちます。

もう 1 つの調停基準は、システムの現在の動作モードで目標状態が達成可能かどうかです。たとえば、トリムされた軌道の概念は、動きを維持するために必要な一定の入力を特徴とする車両の動きのパターンを分類するために使用されます。システムの軌道のライブラリを作成し、コントローラーが選択できるようにすることができます。この文脈では、追い越し、混雑した高速車線への合流、高速での障害物の回避など、より高度なタスクを確実に完了するには、継続的な実現可能性と制御の活発さが重要な要素となります。大規模で複雑、かつ動的なパターン ライブラリからのパターン選択に計算が必要な場合は、学習ベースの方法 (強化学習など) を使用して、環境に基づいて適切なパターン仲裁決定を効率的に学習できます。

到達可能性は、制御システムに「いつでも」直接統合して、現在のコントローラーに継続的なガイダンス/傾斜を提供し、制御不能によって引き起こされる壊滅的なイベントを回避することもできます。

直接制御統合方法の1つは モデル予測制御 (MPC)  図に示すように、形式手法、特に到達可能性解析 (RA) を使用して堅牢な MPC アルゴリズムを開発できます。到達可能性解析は、各 MPC 計画期間の実行可能な状態セットを見つけるために使用され、生成された MPC アルゴリズムは実行不可能な領域で最適解を見つけようとしません。実行不可能な領域では、不安定性や制御障害が発生するためです。

これは、再帰的実現可能性または永続的実現可能性とも呼ばれます。到達可能性セットの制約が確率的である場合、ロバスト MPC の確率的等価物となるモデルを開発できます。堅牢性と実現可能性の保証に加えて、RA を MPC に適用するその他の利点には、システムの入力から状態の安定性を確立する潜在的な方法、MPC の堅牢性とパフォーマンスの分離を学習することによる MPC の複雑さの明示的な削減、および到達できない領域の削除が含まれます。

正式な安全性を制御設計に統合するもう 1 つの方法は、図に示すように、安全な参照軌道を生成することです。到達可能性は、軌道計画段階で使用して、下位レベルのコントローラーが従う最も安全で物理的に実現可能な軌道を生成できます。

最後に、セキュリティに関する未解決の問題とリソースがあります

1 未解決の質問

• 1) 忠実度と速度のトレードオフ
• 2) 到達可能性に対するデータ駆動型アプローチ
• 3) バイナリセキュリティ検証を超えて
• 4) セキュリティ記述のための新しいロジックの構築
• 5) アクセシビリティを考慮した倫理的検証

2 リソースの問題

1) 到達可能性解析のための数値的手法

次の表にリストを示します。

2) 到達可能性分析のためのソフトウェアツール

次の表にリストを示します。