補足資料 ADASテスト

この資料はテスト技法セミナーのスライドに関する補助資料です．目次は右側に表示されます．

1 ADAS（先進運転支援システム）の要件定義と検証

ADASの要件は、単に「機能」だけでなく、安全性、動作環境、システム階層など、多角的な視点から分類する必要があります。シーン別の検証を整理する前提として、まずは「ADAS要件の構造的な分類（タクソノミー）」を整理しました。

大きく分けて以下の5つの視点で分類することができます。

1.1 機能・目的による分類（Function & Purpose）

ユーザーにどのような価値や安全を提供するかに基づく、最も基本的な分類です。

  • 安全機能（Safety Critical）
    • 事故を回避、または被害を軽減するための機能。
    • 例: 衝突被害軽減ブレーキ（AEB）、車線逸脱防止（LKA）、緊急時操舵支援。
    • 要件の性質: 誤動作が許されない（高信頼性）、即応性が求められる。
  • 快適・利便機能（Comfort & Convenience）
    • ドライバーの負担を軽減するための機能。
    • 例: アダプティブクルーズコントロール（ACC）、レーンセンタリング（LCA）、駐車支援。
    • 要件の性質: 自然な挙動（乗り心地）、ドライバーへのオーバーライドのしやすさ。
  • 情報提供・警告（Information & Warning）
    • 周辺状況を検知し、ドライバーに注意を促す機能。
    • 例: ブラインドスポットモニター（BSM）、標識認識（TSR）、ふらつき警報。
    • 要件の性質: 適切なHMI（ヒューマンマシンインターフェース）、過剰警報（False Positive）の抑制。

1.2 ODD（運行設計領域）による分類（Operational Design Domain）

「どこで」「どのような条件下で」システムが動作すべきかという環境要件です。シーン別検証において最も重要な軸となります。

  • 道路環境: 高速道路、一般道、交差点、合流地点、カーブの曲率など。
  • 環境条件: 天候（雨、雪、霧）、照度（昼、夜、逆光）、路面状態。
  • 交通状況: 混雑度、他車両の速度域、歩行者・自転車の有無。
  • 自車状態: 速度域（0km/h〜120km/h）、積載状況。

1.3 システム階層による分類（System Hierarchy / V-Model）

開発プロセスのV字モデルに対応した、抽象度のレベルによる分類です。

  • 車両レベル要件（Vehicle Level）
    • ユーザー視点での挙動。「前走車に追従し、設定速度を維持すること」など。
  • システムレベル要件（System Level）
    • センサー構成や認識ロジックへの要求。「150m先の車両を99%の精度で検知すること」「制御周期はXXms以内」など。
  • コンポーネントレベル要件（Component Level）
    • カメラ、レーダー、ECU単体への要求。「カメラの解像度」「レーダーの視野角（FoV）」「アクチュエータの応答遅延」など。

1.4 制御の方向による分類（Directional Control）

車両運動力学の観点からの分類です。

  • 縦方向制御（Longitudinal Control）
    • 「走る・止まる」の制御。
    • 要件例: 加減速のジャーク（躍度）制限、目標車間距離の維持精度。
  • 横方向制御（Lateral Control）
    • 「曲がる」の制御。
    • 要件例: 車線維持の精度、横Gの制限、操舵トルクの上限。
  • 複合制御
    • 縦横を同時に制御する場合（レーンチェンジ支援など）。

1.5 安全規格・品質基準による分類（Safety Standards）

法的規制や国際規格への適合要件です。

  • 機能安全 (ISO 26262)
    • システムが故障した際に危険な状態にならないための要件（ASIL等級など）。
  • SOTIF (ISO 21448: Safety of the Intended Functionality)
    • システムが正常でも、性能限界や環境要因で危険にならないための要件。
    • ※ADASのシーン別検証では、このSOTIF（未知の危険シナリオへの対応）が特に重要です。
  • 法規・アセスメント (UN-R, NCAP)
    • 国連協定規則（UN-R152など）や、自動車アセスメント（Euro NCAP, JNCAP）のスコア獲得要件。

1.6 まとめ：検証に向けた構造化

これらを整理すると、検証シナリオを作成する際には、以下のような掛け合わせが必要になることがわかります。

「どの機能（ACC）」を、「どのODD（雨天の高速道路）」で、「どの階層（車両挙動）」において、「どの基準（SOTIF/NCAP）」で満たしているか？

[Image of V-model for automotive software development]

ADASの検証における「シナリオベース検証」は、近年の自動運転・ADAS開発の主流となっているアプローチです。

かつては「ひたすら公道を走り込んで距離を稼ぐ（Distance-based）」手法が取られていましたが、レアな危険事象に遭遇する確率が低く効率が悪いため、「重要な局面（シーン）を抽出して、シミュレーションやテストコースで重点的に検証する」という手法にシフトしました。これがシナリオベース検証です。

2 シナリオの階層構造

2.1 . シナリオの階層構造（抽象度による3段階分類）

ドイツのPEGASUSプロジェクトなどで提唱され、現在ISO等の標準でも採用されている**「3つの抽象レベル」**で理解するのが業界標準です。

これらを上から順に定義・詳細化（具体化）していくプロセスで検証が進みます。

レベル 名称 定義・内容 具体例
Level 1 機能的シナリオ
(Functional)		 言語で記述された抽象的なシナリオ。人間が理解するためのもの。 「高速道路で、自車の前に他車が割り込んでくる（Cut-in）」
Level 2 論理的シナリオ
(Logical)		 機能的シナリオに対し、パラメータの範囲（定義域・分布）を与えたもの。シミュレーション空間での定義に使われる。 ・自車速度: 80〜100km/h
・割込車速度: 85〜105km/h
・車間距離: 10〜50m
・TTC（衝突余裕時間）: 2〜4秒
Level 3 具体的シナリオ
(Concrete)		 論理的シナリオから、特定の1つの値を選び出したもの。実際のテストケース（テストベクトル）。 ・自車: 90km/h
・割込車: 95km/h
・車間距離: 30m
・天候: 快晴

検証の流れ: まずLevel 1で「どんな危険があるか」を網羅し、Level 2で「限界値」を探り、Level 3で「何万通りものテスト」をシミュレーションで実行する、という形になります。

2.2 . シーン（事象）の内容による分類

「具体的にどんな場面を検証すべきか」という、中身による分類です。大きく分けて以下の3つの軸で整理されます。

A. 交通イベント（ダイナミックな他者との関係）

ADASが最も対処しなければならない、動的なイベントです。

  • Cut-in (割り込み): 隣接車線から自車の前に車両が入ってくる。
  • Cut-out (離脱): 前走車が急に車線変更し、その前方にあった障害物（停止車両や落下物）が突然現れる。
  • Deceleration (急減速): 前走車が急ブレーキをかける。
  • Crossing (横断): 交差点などで歩行者や自転車、車両が横切る（NCAP等で重視）。
  • Oncoming (対向): 対向車線へのはみ出しや、対向車とのすれ違い。

B. 道路形状・静的環境（スタティックな条件）

センサー認識や制御を難しくする道路自体の特徴です。

  • カーブ形状: 曲率半径（R）がきついカーブ、S字カーブ。
  • 勾配: 急な上り坂・下り坂（レーダーの検知範囲外になりやすい）。
  • 合流・分岐: ジャンクションや料金所付近。
  • 路面標示: 白線のかすれ、二重線、工事区間の複雑な線。

C. 環境条件（ノイズ・外乱）

認識性能を低下させる外部要因です。

  • 天候: 雨（水しぶき）、雪、霧。
  • 照明: 逆光（西日）、トンネル出入り口の明暗差、夜間の街灯なし。
  • オクルージョン（遮蔽）: 駐車車両の陰から歩行者が飛び出すなど、センサーの視界が遮られる状況。

2.3 . 検証フェーズごとの使い分け

これらのシナリオを、開発のどの段階でどう使うかも重要です。

  1. Model-in-the-Loop (MIL) / Software-in-the-Loop (SIL):
    • PC上のシミュレーション。**数万〜数百万通りの「具体的シナリオ」**を自動生成し、パラメータを少しずつ変えて限界性能（どこでぶつかるか）を探ります。
  2. Hardware-in-the-Loop (HIL):
    • 実機ECUやセンサーを使ったシミュレーション。リアルタイム性が求められる急な割り込みなどの検証に使います。
  3. Proving Ground (テストコース):
    • NCAP（自動車アセスメント）で規定されている標準的なシナリオ（Cut-in、歩行者飛び出し）をダミー人形などを使って実車で確認します。
  4. Public Road (公道):
    • シナリオベースではカバーしきれない「未知の状況」や「複合的な要因（雨＋工事＋割り込み）」の確認。

2.4 まとめ

ADASのシーン別検証とは、「言語定義（Lev.1）」→「パラメータ範囲定義（Lev.2）」→「テストケース生成（Lev.3）」 という手順を踏みながら、**「交通イベント」「道路形状」「環境条件」**の3要素を組み合わせて網羅的にテストすること、と言えます。

3 NCAP（自動車アセスメント）の例

簡単に言うと、「前方に停まっている車に対して、自車がぶつからずに止まれるか？」というテストです。

3.1 シミュレーション（および実車試験）への入力

「論理的シナリオ」として定義されたパラメータに対して、具体的な数値を刻んで大量のパターンを入力します。

  • シナリオ構成:
    • VUT (Vehicle Under Test): 自車（テスト対象車両）。
    • GVT (Global Vehicle Target): ターゲット車（標準化されたダミー風船の車）。
  • 主な入力パラメータ（変化させる条件）:
    1. 自車速度 (VUT Speed):
      • 例: 10km/h 〜 50km/h（市街地想定）や 80km/h まで。
      • 5km/h刻みなどで細かくテストします。
    2. ラップ率 (Overlap):
      • 相手の真正面から突っ込むか、少しズレて突っ込むか。
      • 例: 100%（真正面）、-50%（左に半分ズレ）、+50%（右に半分ズレ）。
      • ※センサーによっては端っこの検知が苦手なため、ズレた条件が重要です。

シミュレーションでの指令: 「自車速度40km/h、ラップ率50%で、前方100mの静止ターゲットに向かって走行せよ」

3.2 結果の評価観点（アウトプット）

シミュレーション結果として得られた「衝突時の速度」や「車間距離」をもとに、以下の観点で点数化（スコアリング）します。

A. 判定基準（Pass/Fail）

最も重視されるのは「速度低減量（Speed Reduction）」です。

  1. 回避 (Avoidance):
    • 衝突前に完全に停止した。
    • 評価: 満点（Green）
  2. 被害軽減 (Mitigation):
    • ぶつかってしまったが、ブレーキにより速度が落ちていた。
    • 例: 50km/hで接近し、衝突時は20km/hまで落ちていた。
    • 評価: 減速量に応じて部分点（Yellow / Orange）
  3. 失格 (Fail):
    • ブレーキがかからず、初期速度のまま衝突。
    • 評価: 0点（Red）

B. 評価の可視化（カラーマップ）

NCAPのレポートでは、横軸に「ラップ率」、縦軸に「自車速度」をとったグリッド表（マトリクス）で結果が示されます。

  • 低速域: すべて「緑（回避）」であることが求められる。
  • 高速域: 物理的に停止が間に合わない場合でも、「黄色（被害軽減）」であることが求められる。

3.3 まとめ：このテストで何が見られているか？

このシンプルなテストで、メーカーは以下の性能を証明する必要があります。

  1. 認識性能: 遠くの静止物体を「車」と正しく認識できるか？（誤検知で急ブレーキをかけないか）
  2. 判断速度: 衝突の危険を察知してから、ブレーキ指令を出すまでのラグが短いか？
  3. 制動性能: タイヤと路面の摩擦限界ギリギリを使って、最短距離で止まれる制御ができているか？