大規模なクラウドベースのシミュレーションのためのバーチャル車両モデルの構築

業界全体の自動車会社は、車両モデルを使用して仮想プロトタイピング、検証、統合を可能にする仮想開発手法をますます必要とするようになっています。このアプローチでは、物理的なプロトタイプが最終検証にのみ使用されるため、コストの節約と開発時間の短縮の両方において大きな利点があります。

しかし、エンジニアリング チームは、仮想開発のメリットを実現するにはいくつかのハードルをクリアする必要があることに気づき始めています。まず、チームは適切な忠実度レベルでバーチャル車両モデルを作成する必要があります。つまり、モデルは、関心のある効果を捉えるのに十分なほど詳細である必要がありますが、シミュレーション時間が長くなるほど詳細であってはなりません。次に、物理プラント モデルとソフトウェア モデルを統合する必要があります。エンジニアリング チームは、閉ループ モデルを実行する運転シナリオを組み込み、シミュレーション結果を視覚化して有用な洞察を得る必要もあります。多くの場合、設計のトレードオフ研究や最適化をサポートするために、大規模なシミュレーションを実行する方法も必要です。

この記事では、これらすべての重要な領域に対応するワークフローについて説明します。ワークフローでは、バーチャル ビークル コンポーザー アプリによってモデルをビルドして、そのモデルをカスタマイズし、それを使用してデスクトップ上でシミュレーションを実行し、その後クラウドに展開して大規模な研究を実行します (図 1)。MathWorks の多くの顧客は、シミュレーションまでの時間を短縮し、クラウドベースのシミュレーションを簡素化し、増え続けるバーチャル車両モデリングのユースケースをサポートするために、すでにこのワークフローまたは類似のワークフローを使用しています。

バーチャル車両モデルの生成とカスタマイズ

車両モデルをゼロから構築するのは簡単な作業ではありません。特定のプロジェクトの要件を満たすようにカスタマイズする前に、参照モデルから始めると非常に役立ちます。これが、 MathWorksが数年前からさまざまな車両テストや操縦のプレビルド版車両参照アプリケーションを提供してきた理由の一つです。R2022a では、 MathWorks はPowertrain Blockset™およびVehicle Dynamics Blockset™で バーチャル ビークル コンポーザー アプリをリリースしました。このアプリにより、エンジニアリング チームは直感的なユーザー インターフェイスを介して、パフォーマンス テストと分析用のバーチャル車両をさらに簡単に構成および構築できるようになります。アプリを使用する場合、エンジニアはまず車両のパワートレイン（2 モーター EV パワートレインなど）を選択し、純粋な縦方向モデルまたは横方向ダイナミクスも含むモデルのいずれかを指定して、車両質量、タイヤ サイズ、最大モーター トルクなどの主要なパラメータを構成します。次に、一連のドライブ サイクルと操作から実行するテスト ケースと、シミュレーション中にログに記録する信号を選択できます。これらの設定を選択すると、クリックするだけでシミュレーションの準備が整ったSimulink ^®モデルが生成されます(図 2)。

バーチャル ビークル コンポーザー アプリを使用すると、チームは数分以内に完全なモデルを構成して生成できます。しかし、さらに重要なのは、結果として得られるモデルは完全にカスタマイズ可能であるため、チームは新しいプラント、コントローラ、またはセンサーモデルの機能、またはCまたはMATLAB ^®で記述された追加機能でモデルを拡張できることです。

ワークフローのこの部分を説明するために、バーチャル ビークル コンポーザー アプリで生成された EV モデルのバージョンをカスタマイズし、それを使用して自動緊急ブレーキ (AEB) システムのパフォーマンスを調査するユースケースを実装しました。

私たちが生成したEVモデルには、AEBテストを実行するために必要なセンサー、制御アルゴリズム、テストシナリオが含まれていなかったため、 Automated Driving Toolbox™ サンプルモデルからこれらのコンポーネントを組み込みました。その時点では、必要な AEB コンポーネントをドラッグ アンド ドロップし、モデルのフレームワークに適合する必要な信号を接続し、AEB サンプル モデルから車両パラメータとコントローラのキャリブレーション データをコピーするだけでした。結果として得られた閉ループ モデルには、EV プラントと AEB コントローラーの両方が含まれており、約 33,000 個のブロックで構成されていました (図 3)。

デスクトップシミュレーションの実行

完全なシステム モデルが組み立てられ、構成されたら、ワークフローの次のステップはデスクトップ上でシミュレーションを実行することです。私たちの使用例の目標は、モデル化した EV に対して AEB 制御アルゴリズムがどの程度機能するかを理解することでした。たとえば、さまざまなシナリオとさまざまな車両重量において、コントローラーが衝突することなく車を安全に停止できるかどうかを知りたいと考えました。また、ブレーキ力（またはブレーキ圧力）の初期の適用やブレーキが完全に適用された特定の瞬間など、主要な制御パラメータも評価したいと考えました（図 4）。デスクトップ シミュレーションは、より包括的な調査に拡張する前に、モデルを検証し、テスト構成を評価し、限られた一連のテスト実行で自動化スクリプトを検証する方法を提供します。

テスト用の合成運転シナリオを設計するために、Automated Driving Toolboxのインタラクティブなドライビング シナリオ デザイナー アプリを使用しました。このToolboxは、 AEB と衝突回避のアプリケーション例を提供しています。各シナリオには簡単な合格/不合格基準がありました。自車両が進路上の車両、歩行者、または障害物に衝突する前に停止した場合、テストは合格となります (図 5)。

複数のテスト ケースを実行する必要があったため、 MATLABスクリプトまたはSimulink Test™ を使用してテスト実行を自動化することにしました。デスクトップ シミュレーションの最初のラウンドでは、プラントと制御アルゴリズムの両方で車両速度などのさまざまなパラメーターとテスト シナリオを使用して 16 種類のテストを実行し、さまざまな条件でシステムをテストすることにしました。単一の処理コアでは、この 16 回の実行スイープが完了するまでに約 23 分かかりました。シミュレーション時間を短縮するために、 Parallel Computing Toolbox™を使用して、同じテストを 4 つのコアで並列に実行しました。これにより、シミュレーション時間が 7 分強に短縮されました。しかし、この速いペースでも、何千ものシミュレーションを含む、私たちが実行したい完全因子研究を完了するには数日かかります。このような大規模な研究はクラウドに最適です。この小規模なパラメータ スイープを最初にデスクトップで実行することで、シミュレーションを実行し、合格/不合格基準をチェックするための自動化スクリプトが意図したとおりに機能していることを確認できました。その結果、クラウド内のテスト条件のより大規模な組み合わせに対して研究を拡大する自信が生まれました。

クラウドで大規模なシミュレーション研究を実行する

クラウドでシミュレーションを実行する理由はたくさんあります。スケーリングによって、より多くの計算リソースを活用することが、共通する動機です。エンジニアは、メインのワークステーションから計算ジョブを単純にオフロードしたい場合もあれば、チームが、時々しか必要のない特殊な計算ハードウェアにオンデマンドでアクセスしたい場合もあります。

MATLABで作業する場合、デスクトップからクラウドへの移行は簡単です。スクリプトやアルゴリズムを書き直す必要はありません。MathWorks は、クラウド内の仮想マシン (VM) 上でMATLABとSimulink を実行するためのリファレンス アーキテクチャと、クラウドに展開できる構築済みコンテナーを提供しています。

私たちの研究では、 Amazon® Web Services 上で MATLAB Parallel Server™  を実行するためのリファレンスアーキテクチャを使用しました。GitHub^®で利用可能な、このリファレンスアーキテクチャにより、クラウドの経験がほとんどまたはまったくないチームでも、最新のプリビルドされたMathWorks^®Amazon マシンイメージ (AMI)に基づくWindows^®またはLinux ^®の仮想マシンインスタンス起動が容易になります。インスタンスが起動したら、リモート デスクトップ経由でインスタンスに接続し、テスト セットアップ ファイルをアップロードして、4 台の 32 コア マシンを備えた Linux VM クラスターでテストを実行する準備が整いました。

私たちは、28 のシナリオ、プラント モデル パラメータの 16 の値、および 2 つの制御パラメータそれぞれに 5 つの値を含む完全因子研究を実行しました。その結果、11,200 のシミュレーション テスト スイートが作成されました。クラウドでは、テスト実行は約 90 分で完了しましたが、4 コアのワークステーションでは、同じ調査に約 2 日かかりました。

この研究の結果を検討した結果、AEB コントローラーはすべてのテストで十分に堅牢であることが確認されました。バーチャル車両が時間内に停止できなかったという失敗例がいくつかありました (図 6)。一般的なワークフローでは、これらのケースはデスクトップに戻ってより詳細に検討され、エンジニアはMATLABとSimulinkで結果を分析して障害の根本原因を特定し、問題の修復方法 (コントローラー パラメーターの調整など) を決定し、必要に応じてモデルを更新してクラウドでフォローアップ テストを実行します。バーチャル車両モデルを使用した大規模なシミュレーション研究なら、これらの潜在的な故障ケースをより簡単に特定できるようになり、エンジニアリング チームは設計プロセスの早い段階で潜在的に重大な問題に集中できるようになります。

まとめ

バーチャル車両開発が自動車のワークフロー全体の中心となるにつれて、エンジニアリング チームは、増え続けるシミュレーションの需要に対応する方法が必要になります。バーチャル ビークル コンポーザーは、適切な車両モデルを迅速に構成できるようにすることで、この分野でチームに大きな生産性の利点を提供します。これらのモデルはブラック ボックスではないため、エンジニアはプロジェクトの特定のニーズに合わせてSimulinkでモデルを迅速に拡張およびカスタマイズできる柔軟性を備えています。さらに、チームは引き続きMATLABとSimulink をクラウド コンピューティングとともに使用して、大規模なシミュレーション研究を自動化し、さまざまな条件でシステムを分析して潜在的な問題を特定し、設計のトレードオフを評価し、最適化を実行できます。