AWS クラウド上でのCarMaker実行

この記事の例は、CarMakerを単なるリモートアクセス可能なアプリケーションとしてではなく、より広い概念で捉えています。4つの協調するレイヤで構成された仮想エンジニアリング環境を示しており、各レイヤは管理、標準化されています。ユーザアクセスレイヤは、ユーザの役割に応じた操作ができるWebインターフェースを提供します。環境レイヤは、事前に用意された標準的なマシンイメージを供給し、すべてのエンジニアが同じCarMaker環境で作業できるようにします。実行レイヤは、シミュレーションを実際に実行します。インタラクティブに実行することも、複数の計算を並列で一括実行することもできます。結果レイヤは、シミュレーション結果と主要な性能指標を記録し、監視と分析に使用します。これら4つのレイヤが明確に分離されているため、各レイヤは独立して改善・進化させることができ、全体のワークフローは一貫性を保ちます。

ADAS検証は、処理能力の限界に直面しています。新機能やセンサ構成、規制要件が増えるたびに、テストすべき走行シナリオの数が急増します。さらに、各シナリオについて、多くのパラメータの組み合わせでテストを実行する必要があります。ローカルワークステーションでは、テストを順番に実行するため、テスト数が増えるほど完了までの時間が長くなります。エンジニアは結果を待ち続け、コンピュータは数時間にわたってフル状態で動作し、検証作業の待機リストが溜まっていきます。

重要なのは、問題は単なる計算能力不足ではないということです。ワークフロー自体に問題があります。環境を手作業でセットアップしたり、マシン間でソフトウェアのバージョンがずれたり、ツールのインストール方法がバラバラだったり、同じ設定を何度も手作業で繰り返したりすることで、遅延とエラーのリスクが生じます。2人のエンジニアが、異なる構成のパソコンで同じテストを実行しても、比較できない結果を得てしまう可能性があります。したがって、本当の目標は、単に計算能力を増やすことではなく、シミュレーション作業の定義、実行、追跡、測定方法全体を見直し、最初から「繰り返し可能で、スケーラブル」な仕組みに作り変えることです。

システムは「すべてをコードで定義する(Everything-as-Code(EaC))」という原則に基づいています。ネットワーク、サーバ、コンテナイメージ、アクセス権限、計算リソースなど、すべてのリソースをコードで記述します。ワークフローが実行されるときに自動的に構築され、作業が終わったら自動的に削除されます。使われていないリソースはアイドル状態で実行されているものは何もないため、コストを抑えられます。また、長期間運用されている手作業で管理されるサーバは、時間とともに設定がズレていく(ドリフト)という問題がありますが、このアプローチではそれを避けられます。この方法は CarMakerの特性に合致し、現代的なソフトウェアエンジニアリングで使用されている慣行を反映しています。

アーキテクチャの中心には、Streamlit で作られたウェブインターフェースがあります。これを Docker コンテナにパッケージ化して、Amazon EC2上で動かします。ユーザはこのウェブインターフェースを通じてすべての操作を行います。その背後には 継続的インテグレーション(CI)と継続的デリバリ(CD)レイヤがあり、GitHub、AWS CodePipeline、AWS CodeBuild、Amazon ECR、AWS CloudFormation などが連携して、ユーザのリクエストに応じて必要なものを自動的に構築・デプロイします。

シミュレーション実行には、それを担う2つのコンピュータ環境があります。EC2上で NICE DCV というリモートデスクトップ技術を使い、エンジニアはクラウド上で CarMakerのGUI を使った通常のデスクトップ操作ができます。一方、AWS Batchを使うと、複数のマシンで同時に CarMakerをコマンドラインで実行し、大規模な並列処理が可能になります。これらを支えるのが、ストレージと設定管理のサービスです。Amazon S3はパイプラインの成果物や CarMaker のファイルを保存し、Amazon DynamoDB はシミュレーション実行の履歴を記録します。これらすべてのシステムは、単一の仮想プライベートクラウド(VPC)の中に構築されており、パブリックサブネットとインターネットゲートウェイを通じて、各レイヤが安全に接続されています。

ワークベンチは4つの独立したパイプラインで構成されています。各パイプラインは、ソフトウェア開発で認識されている標準的なワークフローをモデルにしており、共通の基盤の上に構築されています。

1. フロントエンドパイプライン: このパイプラインは、ユーザが操作するウェブインターフェース自体を構築してデプロイします。ユーザはこのウェブインターフェースを通じて、他のすべてのパイプラインを選択・実行します。
2. AMIパイプライン: 標準化された環境イメージを作成します。EC2 Image Builderを使って、CarMakerと必要なファイルをインストールし、再利用可能なマシンイメージ(AMI)として保存します。手作業で構築した「一点物」ではなく、バージョン管理された「テンプレート」になり、オンデマンドで何回でも利用できます。
3. EC2 GUIパイプライン: クラウド上で実行されるCarMakerのデスクトップ環境を提供し、CarMakerを特定の物理ワークステーションから切り離します。これにより、必要に応じていつでも標準化された同一のセッションを開始・利用・終了できるようになり、固定されたローカル環境から、一貫性のあるオンデマンドなリモート環境への移行を実現します
4. バッチパイプライン: パフォーマンス向上の核となるスケールアウト実行を実現します。単一のマシンでシナリオを順次実行するのではなく、利用可能なCarMakerライセンス数に応じて複数のインスタンスへ処理を分散し、並列で実行します。これにより、ターンアラウンドタイムはキュー全体の処理時間から、ほぼ1回分の実行時間へと劇的に短縮されます。

ワークベンチを単なるリモート実行環境ではなく、真のエンジニアリング・プラットフォームへと進化させる2つの重要なコンセプトがあります。1つ目は「変更駆動リグレッション(Change-driven regression)」です。 システム全体がコードで定義され、パイプラインによってオーケストレーションされているため、機能、モデル、またはシナリオに変更が加えられると、関連するシミュレーションが自動的にトリガされます。これにより、検証作業は開発の傍らで実行される手動ステップではなく、開発プロセスに不可欠かつ自動化された「継続的インテグレーション(CI)」の一部として機能するようになります。エンジニアは何かを変更するたびに、迅速で一貫したフィードバックを得ることが可能です。

2つ目は「可観測性(Observability)」です。 「測定できないものはスケールできない」というシンプルな原則に基づいています。フロントエンドにはAmazon CloudWatchダッシュボードがネイティブに統合されており、すべてのシミュレーション、ブレーキング、ロールオーバ、ハンドリング、安定性といったKPIセクションごとに整理されています。さらに高度な分析を行う場合は、KPIデータセットをAmazon QuickSightにエクスポートできます。具体的には、Amazon S3内の結果をスキャンして実行レベルのサマリCSVデータセットを公開し、それをサポートするAWS GlueおよびAmazon Athenaのテーブルを自動的にセットアップします。週あたりの実行数などのメトリクスはシミュレーション・ワークフロの背後で管理されるため、チームはスループットの可視化やボトルネックの特定を行い、スケーリングの判断をデータに基づいて的確に下すことができます。

実際のエンジニアリング組織において、単一の画一的なツールチェーンが運用されることはなく、本ワークベンチもそれを強要しません。CarMakerをシミュレーションの核としつつ、その周辺レイヤであるアプリケーションやソフトウェアコード、Simulink等で構築されたモデルベース設計、CI/CDによる自動化とオーケストレーション、そしてAWS上のクラウド運用にいたるまで、各チームの要件に合わせて柔軟に構成を変更できます。このように意図的に分離された構造を採用することで、組織全体への導入をチーム単位で段階的に進めることが可能になり、破壊的な「ビッグバン・マイグレーション」を回避できます。各グループは、既存の専門ツールを継続して活用しながら、それぞれのペースで着実にクラウドワークフローへと移行できるメリットがあります。

この例は、2つの相補的な役割（ロール）を中心に構成されており、幅広いAWSサービスを意図的に組み合わせることで、各サービスがCarMakerとどのように連携するかを実証しています。「クラウド開発者」 は、クラウドシステムの構築に精通したエキスパートとして、例の実装や基盤・パイプラインのデプロイ、AWS上でのワークベンチの立ち上げを担います。この例を導入する際、この担当者は関連するAWSサービスの内容と、それらがシステム全体の中でどのように組み合わされているかを理解する必要があります。

対照的に 「CarMakerユーザ」 は、ワークベンチを日常的に利用するエンドユーザです。このエンジニアは、ウェブフロントエンドからリモートのCarMakerセッションを開始したり、大規模なシナリオセットを並列実行のために投入したりします。その際、基盤となるインフラストラクチャを管理する必要は一切ありません。このように役割を明確に分担することで、シミュレーションエンジニアには簡便な操作環境を提供しつつ、プラットフォームチームにはリソースの構築やガバナンスに対する完全な統制権を確保させています。

全体として、このモデルプロセスは、CarMakerがクラウドネイティブかつオンデマンドなエンジニアリングプラットフォームとしてどのように機能するかを提示しています。単一のウェブインターフェースが、フロントエンドの構築、バージョン管理された環境の生成、インタラクティブなリモートセッションの起動、そして大規模並列バッチシミュレーションの実行という4つの自動化パイプラインを駆動します。これらはすべて「コードとしてのインフラ(IaC)」として定義され、必要な時にのみプロビジョニングされます。変更駆動型のリグレッションテストと組み込みの可観測性(Observability)により、シミュレーションは測定可能かつ継続的なエンジニアリングプロセスの一環へと統合されます。この設計は、膨大な工数を要するADASの検証において、再現性、測定可能性、保守性を維持したままAWS上で弾力的にスケールできることを証明しており、従来のワークステーションモデルを制限していたスケーラビリティの壁を打破します。

実装にあたっては、2つの実用的な注意点があります。第一に、本事例の位置づけについて。 本事例は概念実証および関連するAWSサービスの紹介を目的とした例示的なサンプルであり、完成された製品ではありません。本番運用に際しては、各チームで独自の実装設計と堅牢化を行う必要があります。第二に、ライセンス管理について。 本事例はCarMakerの電子ライセンス管理にIPGLockを使用しています。これはターゲットVPC内でセットアップおよび稼働している必要があり、インタラクティブ操作か並列バッチ実行かを問わず、実行されるCarMakerの各インスタンスに対して1つのライセンスが必要です。

クラウドソリューションにご興味のある方は、ぜひVIRTOのページも併せてご確認ください。