AWS における自動車 E/E アーキテクチャのシミュレーション – Part 1： V モデルの高速化

この記事は、Simulating Automotive E/E Architectures in AWS – Part 1: Accelerating the V-Model を翻訳したものである。

過去15年の間に、自動車内の電子制御ユニット（ECU）、関連するセンサー、アクチュエーター、配線を含む自動車の電気／電子（E/E）アーキテクチャの複雑さが増しています。自動車メーカーは、E/E アーキテクチャに新たなハードウェア・コンポーネントを追加し続けるのではなく、小型の単体 ECU を大型の高性能コンピュータ（HPC）に統合し、少数の分散型 ECU を維持する方向にシフトしています。これは、配線の削減や車両の軽量化など、自動車メーカーにメリットをもたらします。これらの HPC の計算能力を利用して、自動車メーカーは、リッチで新しいユーザーエクスペリエンスと頻繁なソフトウェアアップデートを備えたソフトウェアプラットフォーム全体を構築しています。最新の E/E アーキテクチャでは、HPC と単体 ECU が混在して使用されるため、これらの相互運用を検証する必要があります。そのため、自動車業界ではサブシステム全体の仮想検証に対する需要が高まっています。

このブログシリーズは2部構成になっています。パート1では、自動車の E/E アーキテクチャのトレンドと、クラウドを活用した ECU ソフトウェアのシミュレーションに関して自動車メーカーが直面する一般的な概念と課題について説明します。パート2では、自動車メーカーが AWS と dSPACE テクノロジを使用して自動車 E/E アーキテクチャのシミュレーションを行う方法について説明します。dSPACE VEOS とAWS Graviton を活用したネイティブ ARM for HPC のイメージを組み合わせて使用します。

自動車ソフトウェア開発モデル

現代のソフトウェア開発において、開発者は DevOps を取り入れています。DevOps とは、組織がアプリケーションやサービスを高速で提供する能力を高める、文化的哲学、実践、ツールの組み合わせです。継続的インテグレーション（CI）は、開発者が定期的に中央のリポジトリに作業をマージし、そこで自動化されたビルドとテストを実行できるようにするために必要です。CI の主な目標は、ソフトウェアの品質を向上させ、機能のアイデアからリリースまでの時間を短縮するために、バグを早期に発見し対処することです。

しかし、自動車業界では、機能安全に関する ISO-26262 や ASPICE（Automotive Software Process Improvement and Capability dEtermination、ISO/IEC 15504に基づく）のような設計標準が存在し、自動車用ソフトウェアコンポーネントの設計をどのように行うかに対応しています。ISO-26262 と ASPICEは、伝統的なウォーターフォールモデルに基づく開発プロセスである V モデルに基づいています。ウォーターフォールモデルは、ソフトウェア開発に対する直線的なアプローチであり、各フェーズが完了してから次のフェーズに入る。自動車メーカーやサプライヤーが採用しており、開発プロセス全体を通じてテストと検証の必要性を強調しています。Vモデルは2つのフェーズからなり、左側が「設計」フェーズ、右側が「検証フェーズ」です。これを図2に示します。

図2：自動車 V モデル開発プロセス

設計フェーズでは、開発者はテストフェーズで検証を開始する前に、システム設計、仕様、要件を前もって定義します。このプロセスは、リリース・サイクルの遅延やバグやエラーの発見を遅らせる結果になりかねません。自動車メーカーが、最新の DevOps が提供するスピードと俊敏性を利用しつつ、業界が求める設計標準をサポートする方法を必要としていることは明らかです。

“Shift-Left”

AWS と dSPACE は、クラウド上のシミュレーション技術を使用して、車両集中型アーキテクチャシステムの検証と検証を “Shift-Left “することに取り組んでいます。これらのシミュレーション技術により、自動車業界は、テストケースを並行して実行することで、通常 V モデル内で定義される検証プロセスを加速することができます。これには、開発サイクルの早い段階でテストを行い、問題を修正するのが難しくコストもかかるプロセスの右側を待つのではなく、クラウドで大規模にテストを可能にすることが必要です。クラウドネイティブな DevOps とシミュレーションを使用して不具合を早期に発見することで、エンジニアはコストのかかるエラーのリスクを低減し、ソフトウェア全体の品質向上に貢献できます。Shift-Left テストは、より頻繁なフィードバック・ループとコストのかかる問題の早期発見を可能にするため、コスト削減と市場投入のスピードアップにも役立ちます。

“Shift-Left” モデルは、完全なソフトウェア環境で必要とされるテストの数を増やす一方で、HIL（Hardware in the Loop）システムを使用したシステムおよび統合の必要性を減少させるものでありません。Shift-Left モデルは、開発サイクルの早い段階でのテストに重点を置くようにすることです。自動車のソフトウェア開発チームは、より費用対効果の高い SIL(Software-in-the-Loop) テストによって V モデルを迅速に反復することで、クラウドネイティブの DevOps によって提供されるよりアジャイルな開発手法を利用することができます。開発プロセスにこれらの手法を適用することで、品質が向上し、V モデルの意図に忠実であり続けることができます。

シミュレーションモデル

完全に仮想化されたシミュレーションシステムを組み合わせ、実験を行い、テストを自動化する前に、E/E のすべてのコンポーネントが仮想環境に適していなければなりません。車両集中型アーキテクチャの場合、これらのコンポーネントにはエッジ、ゾーン ECU、HPC が含まれます。バーチャル ECU を入手できない場合は、実際のセンサーやアクチュエーターの特性をエミュレートするシミュレーションモデルを作成することができます。シミュレーションモデルにはいくつかの種類があり、プラントモデル、環境モデル、レストバスモデルに分類できます。すべての仮想コンポーネント間の通信を確立するためには、必要に応じて仮想 I/O 接続とバスを設定することも重要です。図3は、目標とするシミュレーション・システムの代表的なブロック図です。

図3：シミュレーションシステムの I/O とモデル表現

すべての制御ユニットを仮想化することが、仮想シミュレーションシステムを構築するための鍵となります。一般的なアプローチを説明するために、ECU と HPC の4つの主要レイヤーを図4に示すハイレベルスケッチで考えてみましょう。

図4：ECU レイヤーのブロック図

特定の周辺機器や接続を備えたターゲット・ハードウェアに依存する代わりに、コンポーネントはターゲット・ハードウェアから切り離された開発環境内で実行できるようにする必要があります。

さらに説明するために、ゾーン・アーキテクチャに関連する2種類のオペレーティング・システムを区別することが役に立ちます： OSEK OS-like と POSIX である。これらのオペレーティングシステムは、異なる組み込みプラットフォーム間での互換性を可能にする標準に準拠しているため、ハードウェア依存からソフトウェアを抽象化する上で重要です。

エッジ ECU とゾーン ECU は、一般的に OSEK OS のような OS の上に構築されています。これらはマイクロコントローラ上で動作し、フットプリントが小さくリアルタイムアプリケーションに最適化されているため、組み込みプログラミングに非常に適しています。AUTOSAR Classic プラットフォームは、OSEK-like なスタックの一例です。dSPACE VEOS の主な機能の1つに、この種のコンポーネントのシミュレーションがあります。

dSPACE VEOS のクラウドベースのシミュレーション

dSPACE VEOS は、ECU ソフトウエア検証用のシミュレーションプラットフォームです。特定のシミュレーションハードウエアに依存することなく、ファンクションモデル、FMU（Functional Mock-up Unit）、仮想 ECU（V-ECU）、車両モデルなど、さまざまなモデルを幅広くサポートしています。

VEOS は、車載イーサネット、CAN、LIN バス通信を、バス特有の効果をすべて含めて、ハードウェアを追加することなくシミュレートできるため、仮想 ECU ネットワークに関連するバスシミュレーションのニーズにも対応します。

既存のツールを接続して使用するためのオープンインターフェースにより、VEOS は、異なるサブシステムを分散してモデリングおよびシミュレーションできる、コ・シミュレーションセットアップもサポートしています。コ・シミュレーションにより、異なるツール間での時間同期や相互作用が可能になります。

VEOS は標準的な PC（Windows および Linux）上で動作し、クラウドベースのソリューションへの統合も容易なため、機能開発者、ソフトウェアアーキテクト、ECU テスターは、SIL テストのためのさまざまな貴重な選択肢を得ることができます。

エッジ ECU とゾーン ECU をシミュレートするために、VEOS は、アプリケーションレイヤーと基本ソフトウェアのさらなる部分を VEOS で実行し、x86環境で実行できるように調整された OS を提供します。

VEOS は、I/O とバスドライバーを抽象化するためのモジュールをいくつか提供しています。そのため、OSEK ベースのコンポーネントを実行し、I/O およびバスレベルで接続することができます。

図5：AWS 上でのエッジ/ゾーン ECU シミュレーション

OS / Kernel /ドライバーレイヤーを調整することで、チップシミュレーションを回避し、シミュレーションの妥当なパフォーマンスを達成することも可能です。もちろん、意味のあるシミュレーション結果を得るためには、その調整が動作に大きな影響を与えないようにする必要があります。

もう一つのカテゴリーである POSIX は、一般的にゾーン・アーキテクチャの高性能コンピュータ（HPC）に関連しています。HPC は、性能、アーキテクチャの点で IT サーバーに近く、要求の厳しいアルゴリズムを実行する機能を提供する一方で、高い信頼性を維持する必要があります。

高性能である一方、エネルギー効率に優れている必要があり、自動車メーカーは、HW アクセラレータと組み合わせて、このような HPC の計算コアとして Arm ベースのプロセッサを採用しています。HPC は、車載インフォテインメントや ADAS のようないくつかの領域ですでに好まれており、SDV（Software-Defined Vehicle）における計算環境の成功要因になることが期待されています。

HPC シミュレーションのための AWS Graviton

AWS は、AWS Graviton と呼ばれるカスタム64ビット Arm ベースプロセッサを提供しており、クラウドワークロード向けに最大40%の最適価格での性能向上を実現するよう設計されています。HW アクセラレータを含む、より多くのインスタンスタイプにこれらのプロセッサオプションを搭載することで、自動車開発者は、組み込み自動車プラットフォームでも使用されている同じ Arm の知的財産（IP）とツールを使用して、POSIX ベースの HPC アプリケーションとツールチェーンを開発し、実行することができます。これにより、クロスコンパイルの必要なく、Arm 命令セット・アーキテクチャを直接実行することができます。

図6：AWS 上の HPC シミュレーション

しかし、AWS Graviton ベースのシステムは、車両で利用される SoC や ECU と100％同一ではないことに注意することが重要です。たとえば、これらのクラウドシステムには物理的な CAN バスはありません。AWS と dSPACE は、開発サイクルのかなり早い段階で SIL 機能を解放および強化することにより、価値の提供を支援しています。したがって、HIL 検証も引き続き必要条件となります。CPU パリティなどの側面を直接考慮し、入力と出力の違いを再生メッセージングを使用してさらにシミュレートすることができます。自動車エンジニアは、システムに存在しないハードウェア周辺機器をシミュレートまたはエミュレートすることもできます。

このアプローチを成功させるためには、自動車分野で利用されるハイパーバイザーやオペレーティングシステムを開発しているソフトウェアベンダーも AWS Graviton 上で動作させるように協力していく必要があります。今日、我々は、Blackberry QNX や組み込み Linux のような、自動車で使用されるいくつかのAmazon Machine Images（AMI）がすでに AWS Graviton 上でネイティブに動作する形で提供されています。

まとめ

このブログシリーズ Part2では、dSPACE と AWS がどのように AWS 上で自動車 E/E アーキテクチャのシミュレーションを実現しているかをご紹介します。このブログでは、ソリューションの技術的な詳細とスケールを実現するためのアプローチについて説明します。

このソリューションの詳細については、dSPACE または AWS にお問い合わせください。

TAGS: automotive, hpc, Simulation, software defined vehicle

Fabian Bronner

Fabian Bronner は、自動車業界向けの Software-in-the-Loop ソリューションに特化した dSPACE のビジネスデベロッパーです。完全に仮想化された環境で自動車用ソフトウェアを大規模にテストする機能を開始または拡張したいお客様をサポートしています。新しい要件や課題について学ぶと同時に、パートナーやお客様と一緒にコンセプトを開発し、急速に進化する業界を一緒に形成しています。デジタルとコネクテッドな世界のバランスを取るために、ファビアンはオフラインでヨットに乗ることを楽しんでいる。

Jeremy Dahan

Jeremy Dahan は、Amazon Web Services の Automotive Compute Sr Tech GTM Specialist です。クラウド機能を活用して、自動車用ソフトウェアに関する最も困難な問題に取り組む顧客やパートナーを支援している。自動車業界で10年以上の経験があり、特に組込みソフトウェアと最近ではクラウドに詳しい。AWS上でプロダクトを構築していないときは、自動車/IoT センサーをいじっている。

Jerry Bonnah

Jerry Bonnah は、Amazon Web Services のシニアパートナー・ソリューションアーキテクトです。コネクテッド・ビークル・テクノロジーを中心とした自動車業界を専門とし、パートナーと緊密に連携してこの分野の新製品や新機能の設計、共同開発、共同開発を行う。テクノロジーリーダーシップ、ソリューションアーキテクチャ、新製品立ち上げにおいて10年以上の経験を持つ。AWS 上でプロダクトを構築していないときは、AWS 上で次に何を構築できるかを考えている。

Luke Harvey

Luke Harvey は、Amazon Web Services のプリンシパル・パートナー・ソリューション・アーキテクト。AWS のグローバル自動車パートナー戦略の責任者であり、戦略パートナーがクラウドを活用して最先端のソリューションを構築、マーケティング、販売できるよう支援する。自律走行車とコネクテッド・ビークルのテクノロジーにおいて、10年以上自動車業界をリードしてきた経験を持つ。AWS で物事を構築していないときは、ミシガン州で家族と養蜂に時間を費やしている。

Moritz Schniedermann

Moritz Schniedermann は dSPACE のアプリケーションエンジニアで、エンジニアリングおよび事前開発活動を担当しています。ECU のデータ再生と仮想化に関する専門知識を生かし、自動車用ソフトウエアがハードウエア段階に到達する前に、その機能性と信頼性を保証しています。SIL シミュレーションをさまざまなコシミュレーションシナリオで活用することにより、自動車業界における最先端のシミュレーションソリューションの発展に貢献しています。

このブログは、シニアソリューションアーキテクトの渡邊翼が翻訳しました。

Amazon Web Services ブログ