🐥

【Coursera】Introduction to Self-Driving Cars: Week3

2022/09/23に公開

Courseraのトロント大学が提供している専門講座Self-Driving CarsIntroduction to Self-Driving Carsコースのメモ

https://imp.i384100.net/c/4062842/1242836/14726?prodsku=crse%3Ap2jYHVPxEein9xItvIlMSA&u=https%3A%2F%2Fwww.coursera.org%2Flearn%2Fintro-self-driving-cars&intsrc=PUI2_9419

Week2はこちら
https://zenn.dev/atfujita/articles/5b3673551113fb

Lesson 1: Safety Assurance for Self-Driving Vehicles

自動運転システムで起きた事故の事例

  • 2016年: Waymo、2017年: Uber、GM、2018年: Uber
  • 2018年のUberの事故は悲惨で複数の誤りによるもの。
    • 監視役であるドライバーのモニタリングをしていなかった(ドライバーは車内でHuluを観ていた)。
    • 道路を横断中の歩行者をシステムは最初に未知オブジェクトとして認識。次に自動車、次に自転車と認識。最終的にシステムは検出したオブジェクトの信頼度が低いと無視する判断をとった。
    • 走行車両のVolvoの緊急ブレーキシステムが作動していたが、Uberは自動運転中にVolvoのシステムが作動しないようにしていた。

自動運転における主要なHazard Sourceとしてメカニカル、エレクトリカル、ハードウェア、ソフトウェア、センサー、アクションプランニング、Fallback、サイバーセキュリティが挙げられる。

National Highway Transportation Safety Administration (NHTSA)の安全性評価フレームワークについて

このフレームワークは議論の出発点として使われる。

  • 安全のためのシステム設計: まず第一に優先されるべき
  • 自動運転システムのデザイン
    • ODD: 詳細に定義されていること
    • OEDR: 十分にテストされていること
    • Fallback: ドライバーへの警告、安全な場所での停車機能など
    • 交通ルール: 各エリアの交通ルールに従う
    • サイバーセキュリティ: 悪意のあるエージェントから運転システムを保護する
    • HMI: システムはドライバーに状況をうまく伝えられる
  • テストとクラッシュ軽減
    • テスト: 強力で広範なテストプログラム
    • 衝突軽減: 衝突における影響を最小化する
    • クラッシュ後の動作: 二次災害が広がらないようなアクション
    • データ収集: 事故原因の究明のためのデータの収集
    • ユーザの教育: 自動運転の機能と制限を理解してもらう

Lesson 2: Industry Methods for Safety Assurance and Testing

WaymoとGMのレポートで公表された安全性フレームワークについて

Waymo

  • コンセプト: NHTSAの12のコンセプトを全てカバーしているが、5つのレベルの安全アプローチにアレンジしている。
    1. 行動レベル: 交通ルールを遵守し、ODDの下、幅広いシナリオへ対応できる。
    2. システムのバックアップと冗長性: システムに故障、障害が発生しても次のバックアップシステムによってリスクを最小化する。
    3. 衝突安全性: NHTSAの推奨する衝突安全性を重視。
    4. 運用上の安全性: インタフェースは使いやすく、便利で直感的であるべき。
    5. 非衝突安全性: 自動運転システムとやりとりする可能性のある人々の危険を最小化するシステム設計をする。
  • テスト: 危険シナリオの特定、危険の評価(Fault tree analysis, FMEA)、多くのテストによる要件が満たされているかどうかの確認。
    • ソフトウェアテスト: ソフトウェア変更のテストでは、1日あたり1000万マイルのオーダーでシミュレーションする。安全容認に対して期待される改善が見られるか確認する。次に体系的なシナリオで位置や環境の速度パラメータを変更しながらエッジケースを見つける。
    • クローズドコーステスト: UCバークレーの研究で特定された28のコアシナリオとWaymoが追加した19のシナリオをテストする。これらのシナリオは追突、交差点、道路逸脱、車線変更の4つの最も一般的なシナリオ(これらは衝突事故の84%以上を占める)を回避するために作られている。
    • リアルワールドテスト: 少数の車から始めて徐々に増やしていく。これまでのテストでカバーできていない条件がないかの確認、Fallbackのテストを行う。

GM

  • コンセプト: NHTSAの12のコンセプトに非常に近いが実施戦略に焦点を当てている。
    • 反復デザイン: シナリオ分析→ソフトウェア開発→シナリオのシミュレーション→路上テストを繰り返すプロセス。
    • GMはOEMなので、ハードウェア設計から一貫した自動運転システムの品質基準をもつ。
  • テスト: 演繹分析(Fault tree analysis)、帰納分析(FMEA)、探索的分析(HAZOP)
    • Fail safes: メインシステムが故障、障害があった際にセカンドシステムの冗長性によってシステムが動作できること。
    • SOTIF: 全ての重要な機能は既知、未知の両方のシナリオで評価する。
    • パフォーマンステスト、コンポーネントレベルでの要件の検証、障害挿入テスト、耐久性テスト、シミュレーションテストの全ての厳しい安全基準を適用する。

これらのテストが本当に自動運転システムが安全かどうかを正確に評価できるか?少なくとも人間のドライバーよりも安全か?

自動運転システムの安全性評価には分析的アプローチとデータドリブンアプローチが考えられる。

  • 分析的アプローチ
    • 定量化可能な安全性能や危険シナリオでの失敗率などシステム全体の失敗率を特定できれば安全性の強力なガイダンスを提供できる(スペースシャトルの計画のように)。
    • しかし、自動車の周りで起きる無限のシチュエーションを考えれば、あくまでガイダンスの提供であり、結局は経験を通じて検証する必要がある。
  • データドリブンアプローチ
    • 経験を評価するアプローチ。経験はある特定のODDとソフトウェアバージョン下で望ましい失敗率になることを実証する。これは人間のドライバーのパフォーマンスと比較できる。
    • 一方で、人間のドライバーとの比較を厳密に行うのは難しく、RAND社のレポートでは死亡事故が人間のドライバーよりも少ないことを統計的に実証するには、死亡事故自体が稀な現象で多くの要因が考慮されるため、車100台で24時間365日で400年くらいの走行(80億マイル)を必要とするとの試算もある。

これらから自動運転システムの安全性評価では、単一アプローチではなく、多面的なアプローチが必要になる。

Lesson 3: Safety Frameworks for Self-Driving

一般的な安全フレームワークについての解説

  • Fault tree analysis
    • 予備的な分析フレームワークとして使用でき、拡張性がある。
    • トップダウンフローで、回避すべき障害が起きうる全ての下位レベルのイベントを特定する。トップノードが最上位イベントで中間ノードが論理ゲートになり、詳細レベルまで分解される。ブーリアンではなく、確率を使用することもできる。
  • FMEA(故障モード影響解析)
    • Fault tree analysisとは逆にボトムアップアプローチで失敗の原因を特定する。多くの場合、Fault tree analysisと一緒に使用される。
    • 特定のコンポーネントが原因でシステムに障害が発生する可能性を分析する。多くの場合、最も故障による影響が大きい部分を特定し、設計の改善につなげ、冗長性や信頼性を向上させる。
    • 故障モードは、どの程度影響が大きいか、どの程度の頻度で起きるか、どの程度簡単に検出できるかでスコアリングとカテゴライズを行い、優先順位を付ける。
  • HAZOP(Hazard and Operability Studies)
    • FMEAの派生フレームワーク。定性的なアプローチをとり、設計の早い段階で使用される。主な目的は発生する可能性のある一連の危険について効果的にブレインストーミングすること。
    • 無、大、小、早、遅などのガイドワードを使用して、ブレインストーミングを行う単純化されたFMEAアプローチ。

自動車の安全フレームワークについての解説

  • FUSA(Functional Safety)
    • ISO 26262で定義された安全フレームワーク
    • 自動車のハードウェアとソフトウェアの障害によって引き起こされる誤動作、意図された設計で生じる意図しない動作による予期しないリスクを評価する。
    • V字型のプロセスをとる。要件仕様の決定→危険、リスク分析(最悪のケースを想定)→機能の実装→単体テストなどの低水準テスト→シミュレーションやテストトラック、路上でのテストで結合テストと全体テストを実施。最後にテストに含まれていなかったリスクを評価してシステムが許容できる安全レベルに達しているかを評価する。
  • SOTIF(Safety of the Inteded Functionality)
    • ISO/PAR 21448.1で定義された安全フレームワーク
    • SOTIFはシステムの限界や予測を使用するシステムのエラーや障害に関心を持っている。具体的にはセンサーの性能・ノイズなどに対する限界、物体検出アルゴリズムの限界、アクチュエータ技術の限界など。ユーザの混乱、過負荷、自信過剰などユーザによる誤用も対象に含んでいる。ハードウェアとソフトウェアの障害は範囲外。自動運転システム用のフレームワークともみなせ、level 0-2を対象としているが、3-5へも拡張可能としている。
    • FUSAと同様にV字型のプロセスで危険、リスク分析も同様に行う。

Week3はこれにて終了。
Week4はこちら
https://zenn.dev/atfujita/articles/47b63638bd20b2

Discussion