自動運転タクシー解体新書

自動運転システムの検証環境：HIL, SIL, VIL技術詳解

自動運転システムの検証環境：HIL, SIL, VIL技術詳解

自動運転システムの開発は、極めて高度で複雑なソフトウェアとハードウェアの統合によって成り立っています。この複雑なシステムが安全かつ信頼性高く機能するためには、開発の各段階における徹底的な検証が不可欠です。シミュレーション環境での初期検証に加え、現実世界に近い環境での検証手法が求められます。本稿では、自動運転システム開発において広く利用されている主要な検証環境技術、すなわち Hardware-in-the-Loop (HIL), Software-in-the-Loop (SIL), Vehicle-in-the-Loop (VIL) について、その技術的な仕組み、目的、そしてシステム開発における役割を深掘りして解説します。

検証環境の必要性

自動運転システムの検証が困難である主な要因は以下の通りです。

• 複雑性: センサー、認識、判断、経路計画、制御といった多数のサブシステムが相互に連携して動作します。
• 多様なシナリオ: 予測不可能な交通状況、様々な天候条件、歩行者や他の車両とのインタラクションなど、考えられるシナリオは膨大です。
• 安全性要求: システムの不具合は人命に関わる重大な結果を招く可能性があるため、極めて高い安全性が求められます。

実際の公道での走行試験はコストと時間がかかると同時に、危険を伴います。特に発生頻度の低い危険なシナリオを網羅的にテストすることは現実的ではありません。そのため、開発プロセスにおいては、仮想環境や半仮想環境を用いた体系的な検証が不可欠となります。SIL, HIL, VILは、この体系的な検証プロセスにおいて重要な役割を果たします。

Software-in-the-Loop (SIL)

仕組みと目的

SILは、自動運転システムのソフトウェアモジュールまたはシステム全体を、シミュレーション環境上で実行する検証手法です。ハードウェアは含まれず、すべてのコンポーネントはソフトウェアモデルとして動作します。例えば、認識アルゴリズム、判断モジュール、制御ロジックなどのソフトウェアが、仮想的なセンサーデータを受け取り、仮想的な車両モデルを制御します。

目的は、主に以下の通りです。

• アルゴリズム単体またはサブシステムの機能検証: 個々のソフトウェアモジュールや、それらを組み合わせたサブシステムの論理的な正しさを確認します。
• 早期のバグ検出: ハードウェアが準備できていない開発初期段階からソフトウェアのテストを開始し、早期に不具合を発見・修正します。
• 大規模なテストの実行: 実機に比べて環境構築が容易なため、多くのテストケースや回帰テストを効率的に実行できます。

技術的な構成要素と課題

SIL環境は、以下の要素で構成されます。

• 検証対象ソフトウェア: 認識、判断、制御など、自動運転システムのソフトウェアコード。
• 環境モデル: シナリオに応じた3Dマップ、他の車両、歩行者、障害物などの挙動をシミュレーションするモデル。
• センサーモデル: カメラ、LiDAR、レーダーなどのセンサーが、環境モデルに対してどのようなデータを生成するかをシミュレーションするモデル。
• 車両ダイナミクスモデル: 検証対象の制御出力（アクセル、ブレーキ、ステアリング）に対して、車両がどのように応答するかをシミュレーションするモデル。物理法則に基づいた詳細なモデルが使われます。
• テストフレームワーク: テストシナリオの定義、実行、結果の収集・分析を行うためのソフトウェア。

技術的な課題としては、モデルの精度が挙げられます。特にセンサーモデルや複雑な交通状況のモデリングは難しく、現実世界との乖離が生じる可能性があります。また、実機のソフトウェアが動作するターゲットハードウェアの計算リソースやリアルタイム性を厳密に反映することは困難な場合があります。

Hardware-in-the-Loop (HIL)

仕組みと目的

HILは、自動運転システムの一部または全部の実際のハードウェアを、シミュレーション環境に接続して検証する手法です。一般的には、車両に搭載されるECU（Electronic Control Unit）などの制御ハードウェアが対象となります。シミュレーション環境（ホストコンピュータ）上で環境モデルやセンサーモデルがリアルタイムで動作し、ECUに対して仮想的なセンサーデータやバス信号（CAN, Automotive Ethernetなど）を入力します。ECUはこれらの入力に基づいて演算を行い、アクチュエータ（アクセル、ブレーキ、ステアリングなど）への制御信号を出力します。この出力はシミュレーション環境にフィードバックされ、車両モデルの挙動に反映されます。

目的は、主に以下の通りです。

• ハードウェアを含むシステム全体の機能検証: 実際のハードウェアとソフトウェアが連携して正しく動作するかを確認します。
• リアルタイム性能の検証: ターゲットハードウェア上でのソフトウェアの実行時間や、システム全体の応答性がリアルタイム要件を満たすかを確認します。
• インターフェース検証: ハードウェア間の信号や通信プロトコルが正しく機能するかを確認します。
• 耐故障性の評価: センサー信号異常や通信エラーなどを意図的に発生させ、システムが安全な状態に移行するか（フェイルセーフ、フェイルオペレーショナル）を評価します。

技術的な構成要素と課題

HIL環境は、以下の要素で構成されます。

• 検証対象ハードウェア: 自動運転ECU、センサー処理ユニット、ゲートウェイECUなど、実機のハードウェア。
• リアルタイムシミュレータ: 環境モデル、センサーモデル、車両ダイナミクスモデルをリアルタイムで実行する高性能コンピュータ。ターゲットハードウェアとの間で厳密な時間同期が求められます。
• I/Oインターフェース: ターゲットハードウェアとシミュレータの間で信号やデータをやり取りするためのハードウェア。アナログ/デジタル信号、CAN, LIN, FlexRay, Automotive Ethernetなどのバス通信、Ethernetによる大量データ（仮想カメラ映像など）転送に対応します。
• 信号調節ハードウェア: ターゲットハードウェアの期待する信号レベルや形式に合わせて信号を調整する機器。
• テスト自動化ソフトウェア: テストシナリオの実行、パラメータ設定、結果計測、自動評価を行うためのソフトウェア。

技術的な課題は多岐にわたります。リアルタイム性能の確保は最も重要であり、シミュレーションの計算負荷、I/O遅延、ターゲットハードウェアとの同期が課題となります。複雑なセンサー（LiDAR, カメラ）からの大量データをリアルタイムでエミュレートし、ECUに入力することも高度な技術を要します。また、様々なハードウェアの組み合わせやインターフェースに対応するためのシステム構築と保守も複雑になります。モデルの精度も引き続き重要です。

Vehicle-in-the-Loop (VIL)

仕組みと目的

VILは、実際の車両全体を、実験室などの制御された環境内に設置し、外部の環境シミュレーションと連携させて検証する手法です。車両はシャシーダイナモメータ上に置かれ、タイヤの回転などがシミュレートされます。車両に搭載された実際のセンサー（カメラ、LiDAR、レーダー）には、プロジェクションシステムやディスプレイ、またはセンサー自体を動かすメカニズムを用いて、仮想的な環境や他の交通参加者が提示されます。車両からの制御出力（ステアリング角度、アクセル開度など）は、シャシーダイナモメータや環境シミュレーションにフィードバックされ、車両の運動やセンサー入力が変化します。

目的は、主に以下の通りです。

• 車両全体としての機能検証: 実際のセンサー、ECU、アクチュエータ、車両プラットフォームが統合された状態での挙動を確認します。
• 物理的なセンサー入力と制御出力を含むシステム全体の検証: 実際のセンサーの特性やノイズ、アクチュエータの遅延や非線形性を含めた検証が可能です。
• 複雑なシナリオの再現: 公道では危険または再現が困難なシナリオ（急な割り込み、センサーの意図的なブロックなど）を安全な環境で繰り返し実行できます。

技術的な構成要素と課題

VIL環境は、以下の要素で構成されます。

• 検証対象車両: 実際の自動運転車両。
• シャシーダイナモメータ: 車両のタイヤを支持し、走行抵抗や慣性をシミュレートする装置。
• 環境提示システム: カメラ用のプロジェクションスクリーンやディスプレイ、LiDAR/レーダー用のターゲットシミュレータや物理的なオブジェクトを動かすロボットアームなど。
• リアルタイムシミュレータ: 環境モデル、他の交通参加者モデル、センサー入力生成、車両ダイナミクス（シャシーダイナモメータ制御）などをリアルタイムで実行するシステム。
• 同期システム: センサー入力提示と車両制御出力、シャシーダイナモメータ制御などを厳密に同期させるための高精度なシステム。

技術的な課題は、環境提示のリアリティと精度、そしてシステム全体の複雑性です。特に、複数の異なる原理のセンサーに対して、現実世界に近い一貫性のある入力をリアルタイムで提示することは極めて困難です。また、大規模で高価な設備が必要であり、構築・運用コストが高いことも課題です。シャシーダイナモメータの応答性や、タイヤとローラ間の滑りなどもシミュレーション精度に影響を与える可能性があります。

各検証手法の役割分担と連携

SIL, HIL, VILは、開発ライフサイクルの異なる段階や、異なる検証目的のために使い分けられます。

• SIL: 開発初期のソフトウェアロジック検証、アルゴリズムの基本性能評価、多数のテストケースによる回帰テストなど、コストを抑えつつ広範なソフトウェアレベルの検証に適しています。
• HIL: 実際のECUを用いたリアルタイム性能検証、ハードウェア/ソフトウェア統合検証、インターフェース検証、機能安全に関連する故障注入テストなどに不可欠です。SILで検出されたバグが修正された後、ハードウェアを含めた検証に進みます。
• VIL: 開発終盤における車両全体としての挙動検証、複雑なシナリオにおけるシステム応答評価、物理的なセンサーやアクチュエータ特性を含めた最終的な性能・安全性評価に用いられます。公道試験の前に、より網羅的かつ安全な環境で最終確認を行います。

これらの手法は相互補完的であり、段階的に適用することで、システムの品質と安全性を高めていきます。例えば、SILでアルゴリズムの論理検証を行い、HILでECUのリアルタイム性能を確認し、最終的にVILで車両全体の挙動を検証するという流れが一般的です。各段階で得られた知見は、モデルの改善やソフトウェアの修正にフィードバックされます。

将来展望と課題

HIL/SIL/VIL検証技術の今後の展望としては、以下のような方向性が考えられます。

• モデルの高精度化: より複雑で予測困難なシナリオに対応するため、環境、センサー、車両ダイナミクスモデルの精度とリアルタイム性をさらに向上させる必要があります。特にAIベースの認識・判断モジュールに対応した、より現実的なセンサーノイズや異常事象のモデリングが求められます。
• クラウドベースの検証: SIL環境を中心に、クラウドコンピューティングを活用することで、より大規模で並列的なテスト実行が可能になります。HILやVILの一部機能（例：環境モデルの実行）をクラウド化する取り組みも進む可能性があります。
• AI技術の活用: テストシナリオの自動生成（例：敵対的生成ネットワークによる難易度の高いシナリオ生成）、テスト結果の自動分析、デバッグ支援などにAI技術が応用される可能性があります。
• 標準化とツール連携: 異なるベンダーが提供するシミュレーションツールやハードウェアを円滑に連携させるための標準化が進むことが期待されます。
• 物理シミュレーションとデータ駆動型アプローチの融合: 物理モデルに基づいたシミュレーションと、実際の走行データや事故データから学習したモデルを組み合わせることで、より現実的で網羅的な検証が可能になるでしょう。

主要な課題は、依然として検証の網羅性です。自動運転システムの潜在的な挙動空間は非常に広大であり、考えられる全てのシナリオをテストすることは不可能です。いかに効率的かつ効果的にリスクの高いシナリオを特定し、検証するかは継続的な課題です。また、ソフトウェアアップデートや車両バリエーションの増加に伴い、検証のスケーラビリティとメンテナンス性をいかに確保するかも重要な技術的課題と言えます。

まとめ

本稿では、自動運転システムの開発において重要な役割を果たすHIL, SIL, VILという3つの主要な検証環境技術について解説しました。SILは開発初期のソフトウェア単体検証、HILは実際のハードウェアを含むシステム統合検証とリアルタイム性能評価、そしてVILは車両全体としての最終検証にそれぞれ適しています。これらの手法は、開発の各段階で連携し、システムの機能、性能、特に安全性を担保するために不可欠な技術基盤を提供しています。モデル精度の向上、クラウド化、AI活用など、今後の技術発展により、自動運転システムの検証はさらに高度化していくと考えられます。しかし、システムの複雑性と安全性への要求から、検証技術そのものも常に進化し続ける必要があります。