AEBシステムの継続的開発のストーリー
July 21, 2026 | Jan-Henrik von Reuß | 5 min
現代の自動車開発は、ますます1つの大きな課題に直面しています。それは、複雑で安全性が重要なソフトウェアを、品質を落とさずに、より速く提供する方法をいかに実現するかということです。この課題は、自動運転支援システム(ADAS)、特に自動緊急制動(AEB)で顕著です。わずかな欠陥でも、重大な事態につながる可能性があるからです。
この課題にどう対処するかを示すために、1つの具体的なユースケースを追跡してみましょう。初期の失敗から検証済みのソリューションまで、開発プロセス全体を通じて、シフトレフト戦略がワークフローをいかに根本的に変えるかを見ていきます。
ドライビングシミュレータでの重大インシデント
このストーリーは高精度のドライビングシミュレータから始まります。そこでは車両が詳細に再現された郊外環境を走行しています。シーンはリアルです。交差点、限られた視界、そして突然の予期しない出来事が起こります。車両が交差点を通過した直後、子どもが死角から突然道路に飛び出します。
ドライバは素早く反応しますが、この状況は重大な欠陥を露呈させます。AEBシステムはソフトウェアエラーのため作動せず、ニアミスが発生します。実世界の条件下では、これが容易に事故につながる可能性があります。この欠陥は最終的に製品リコールにつながります。修正内容は、オーバー・ザ・エア(OTA)アップデートとして配信される前に、包括的に検証する必要があります。
ここで、従来の検証方法の限界が明らかになります。実際のプルービンググラウンドでのテストは、費用がかかり、時間がかかり、スケーリングが難しいため、現代の自動車開発の短縮されたサイクルに対応できなくなっています。
検証をシフトレフト: 戦略的な変化
これらの課題に対処するために、シフトレフト戦略は開発プロセスの早い段階にテスト活動を移します。後期段階の検証を待つのではなく、潜在的な問題は開発の早い段階で特定し、解決します。
このシフトにより、開発プロセスは継続的な検証パイプラインへと変わります。3つの主要なフェーズで構成されます。
- モデル・イン・ザ・ループ(MIL)
- フトウェア・イン・ザ・ループ(SIL)
- ハードウェア・イン・ザ・ループ(HIL)
各フェーズは、一貫したテスト基盤を保ちながら、新しいレベルのリアリズムと統合を加えていきます。
モデル・イン・ザ・ループ(MIL): コアアルゴリズムの検証
このステージはモデル・イン・ザ・ループ(MIL)として知られており、アルゴリズム自体の機能的正確性に焦点を当てます。アルゴリズムは通常、MATLABなどの環境で開発されます。
このフェーズの主な利点は、開発の早い段階でリアルなテストシナリオを統合できることです。NCAPで定義されたような標準化されたテストケースは、CarMakerなどの仮想シミュレーション環境で直接実行できます。物理的なインフラストラクチャを必要とせずに、プルービンググラウンドの条件を効果的に再現できます。
効率をさらに高めるために、VIRTOなどのクラウドベースのプラットフォームを使用してシミュレーションを拡張します。これにより、大量のパラメータ化されたテストケースを並列で実行でき、多くの場合は一晩で完了します。結果は開発ワークフローに自動的にフィードバックされます。これらのプロセスをCI/CDパイプラインに統合することで、検証は継続的かつ高度に自動化されます。
このステージの終わりに、AEBアルゴリズムは単独で、また幅広い条件下で徹底的に検証されます。これにより、堅牢な機能的基盤が確立されます。
ソフトウェア・イン・ザ・ループ(SIL): 完全なECUスタックへの拡張
コアアルゴリズムが検証されたので、焦点は完全なECUソフトウェアスタックへと移ります。現代の自動車システムでは、AEBソフトウェアコンポーネントは複雑なアーキテクチャの一部です。このアーキテクチャには、アプリケーションソフトウェアだけでなく、ランタイム環境と基本ソフトウェアレイヤも含まれます。多くの場合、AUTOSAR標準に準拠しています。
ソフトウェア・イン・ザ・ループ(SIL)ステージでは、バーチャルECUがこのソフトウェアスタック全体を再現します。これにより、車両とその環境の閉ループシミュレーション内でテストできるようになります。Synopsys Silverなどのプラットフォームは、バーチャルECUの実行と、CarMakerなどのシミュレーションツールとのシームレスな統合を実現します。
このステージでは、検証は純粋な機能を超えた範囲に広がります。エンジニアは、現実的な通信と障害条件下でシステムがどのように動作するかを分析できます。メッセージ遅延、ドロップされたCANフレーム、チェックサムエラーなどの影響を意図的に導入して、堅牢性を評価できます。システムの複雑さに応じて、異なる統合方法が適用されます。これらは直接モデルカップリングから、仮想バスシステムを介したメッセージベースの通信まで、様々な方法があります。
このように詳細レベルが増しても、SILは仮想テストの効率上の利点を保ちます。シミュレーションは依然としてリアルタイムより速く、並列で実行でき、自動化されたパイプラインに統合できます。したがって、完全なソフトウェアシステムの包括的な検証は、ハードウェアが関与する前に実現できます。
ハードウェア・イン・ザ・ループ (HIL): 実際のECUの導入
バーチャルテストは検証のかなりの部分をカバーしていますが、特定の側面は実際のハードウェアとの相互作用が必要です。これには、ハードウェア固有のタイミング動作と統合特性が含まれます。これらは純粋に仮想環境では完全に再現できません。
ハードウェア・イン・ザ・ループ(HIL)の段階では、実際のECUはリアルタイムで実行されるシミュレーションされた車両環境に接続されます。従来、そのようなセットアップは費用がかかり、拡張性が限定されていました。しかし、現代のアプローチはこれらの制約を大幅に軽減します。
CarMakerなどのシミュレーションソリューションとXpackなどのリアルタイムハードウェアプラットフォームを組み合わせることで、ECU自体のみが物理的に存在し、周囲の車両システムはシミュレートできます。これにより、完全な車両ハードウェアを必要とせずに、効率的なレストバスシミュレーションが実現できます。ユースケースに応じて、セットアップは包括的なHILテストベンチから、標準PCと通信インターフェースを使用した軽量な構成まで、様々な方法があります。
効率をさらに向上させるために、複数のHILシステムをHILファームの一部として並列で運用できます。テストケースはシステム全体に分散され、集中管理され、自動化されたパイプラインに統合されます。これにより、拡張性が仮想環境のそれに近づきます。
継続的な検証チェーン
この開発アプローチの主な強みの1つは、その継続性です。最初からの同じ重大なシナリオ(子どもが道路を横断する)は、プロセスのすべてのステージで一貫して再現し、評価できます。各ステージでの検証内容:
- MIL: アルゴリズムの動作を検証
- SIL: 完全なソフトウェアスタック内の相互作用をテスト
- HIL: 実際のハードウェアに展開されたときの正しいシステム動作を確認
ステージ間のこのシームレスな移行により、開発ライフサイクル全体を通じて知識とテストカバレッジが保持されます。分離された検証ステップではなく、プロセスは統合されたワークフローになります。各ステージが前のステージの上に構築されます。さらに、異なるステージ全体で要件が複数回テストされるのを防ぐことで、冗長な検証活動を最小化します。これにより、不要な努力の重複を回避できます。
これはエンドツーエンドテスト戦略の主な利点です。特にVIRTOとの組み合わせでは、高レベルの透明性とトレーサビリティが確立されます。これにより、すべてのステークホルダーが、どのテストが既に実行されたか、どのステージで実行されたか、どの方法で実行されたか、そしてどのような結果が得られたかを明確に理解できます。
結論:反応から予防へ
シフトレフト戦略は開発タイムラインを加速させるだけではありません。自動車システムにおいて、品質と安全性がどのように達成されるかを根本的に変えます。
早期に、継続的に、複数の抽象化レベル全体で検証することで、問題は単に検出されるだけでなく、システム全体への伝播が防止されます。これはリスクを軽減し、コストを削減し、全体的な信頼性を向上させます。
話をドライビングシミュレータに戻ると、その影響は具体的に見えてきます。以前は重大な失敗を露呈させた同じシナリオが、今は正確に機能するシステムを示しています。子どもが道路に踏み出すと、AEBは即座に応答し、車両は安全に時間内にブレーキをかけます。かつてのニアミスは成功物語になります。これは問題が最後に修正されたからではなく、開発プロセスの最初の段階で対処されたからこそです。
さらに調べる
こちらのビデオでは、ご紹介した記事の内容をより分かりやすくご紹介しています。併せてご確認ください。
Would you like to stay up to date with our blog?
Subscribe to our blog update for new and exciting articles.