自律走行車（AV）のエンジニアリング企業の多くは、開発ツールの自社開発と購入のジレンマに直面しています。自社開発のツールは、特定のビジネス課題を解決するために作られているという利点がある一方で、開発やメンテナンスに多大な時間とリソースを費やす必要があります。一方、実績のあるサードパーティ製のツールを使用する場合、エンジニアリングチームには先行して購入コストがかかります。しかし、このアプローチでは、エンジニアリングチームはすぐに構築を開始し、生産性を高め、市場投入までの時間を短縮することができます。
このブログ記事では、先進運転支援システム（ADAS）やAVのテスト・開発に適したツールを選択する際に考慮すべきポイントを紹介しています。また、サードパーティ製の市販ツールを使用することで、安全な自律走行システムを迅速に導入することができることを紹介します。本記事では、以下の質問にお答えします。
- 自社でツールを構築することと、信頼できるサードパーティからツールを購入することのメリットとデメリットは何ですか？
- なぜ開発チームは、無料のオープンソースツールを採用する代わりに、商用ツールにお金を払う必要があるのでしょうか？
- エンド・ツー・エンドのツールチェーンは、ベンダーロックインにつながるのでしょうか？
1.ビルド vs バイ
ADASやAVの開発チームが、自社でインフラツールを構築するか、実績のあるサードパーティ製ツールを購入するかを決定する際に、一般的に評価する基準が6つあります（表1）。以下、それぞれの基準について詳しく説明します。
A) スピード
ADASやAV企業は、世界で最も安全な完全自律型システムを市場に投入するために競争しています。これらの企業にとっての競争力は、開発プロセスを可能にするツールではなく、アルゴリズムにあります。実際、サードパーティ製のツールは、ADAS/AVチームの市場投入までの時間と開発サイクルを短縮するのに役立ちます。ベンダーは多くの場合、初期の統合プロセスを支援します。彼らは、統合時にすぐに使用できるツールを用意し、それをフルタイムで管理する大規模な専門チームを持っています。同じような品質の自社ツールを構築する場合、開発チームは新しいソリューションをゼロから計画、設計、構築、テスト、統合する必要があるため、はるかに長い時間がかかる可能性があります。その上、社内ツールの開発とメンテナンスは、外部向けの収益を生み出す製品に優先してしまうリスクがあります。
B) 製品の複雑さ
シミュレーションをはじめとするADASやAVのインフラツールは構築が難しいため、製品の深みと品質を実現するには専門知識が不可欠です。ADAS・AVチームは、シミュレーション、データ処理、テスト、V&V（Verification and Validation）を重要な開発プロセスと考えているかもしれませんが、これらの各領域を実現するツールを構築・維持するためのリソースは限られていることが多いです。また、各領域の経験豊富な技術者を採用し、チームを構築することは、競争の激しい今日の労働市場では容易ではありません。サードパーティベンダーは、継続的に製品調査を行い、お客様からのフィードバックを収集し、製品の機能を拡張し、エラーを検出して解決するための時間とリソースを持っているため、これらのツールを構築する上でのサブジェクト・マター・エキスパートとなります。
シミュレーションツールを自社開発するほうが、自社でどの機能が必要かを判断し、正確に構築できるメリットがあると思われるかもしれません。一方、サードパーティ製のツールでは、さまざまなユースケースをカバーする多様な機能があらかじめ用意されています。実際、サードパーティ製ツールは、お客様のニーズに合わせて機能をカスタマイズすることもできます。例えば、Applied Intuitionでは、Object Sim*のインテリジェントな車線変更機能（図1）のような高度な機能を、わずか数週間で開発することができます。
C)製品の品質とメンテナンス
ツールを自社開発するか購入するかの判断は、導入時だけでは終わりません。製品の品質を維持するためには、ツールの継続的なメンテナンスが必要ですが、これは無視されがちです。サードパーティ製のツールを購入すれば、ADASチームやAVチームは、リソースを必要とするメンテナンス作業を自社で継続的に行う必要がなくなり、ベンダーに移管することができます。
D) カスタマイズ性と拡張性
ゼロから作った自社製ツールほど、カスタマイズ性に優れたツールはありません。しかし、この柔軟性にはスピードとコストのトレードオフがつきものです。既製の高品質なサードパーティ製ツールは、通常、AVプログラム特有のODD（建築物や自律移動ロボットなど）やアルゴリズム開発のニーズに対応するための十分なカスタマイズが可能です。
ADASおよびAVチームは、ユースケースや開発ニーズに合わせてシミュレーションツールやインフラツールをカスタマイズするだけでなく、これらのツールの上に独自のワークフローを拡張・構築する必要があります。自社開発のツールはその性質上、常に拡張可能ですが、サードパーティ製ツールの多くは、様々なワークフローをサポートするプラグインなどのソリューションを提供しています。例えば、シミュレーションツールのプラグインを使えば、開発チームが独自のアクターの動作をシミュレーターに追加することができます。
E) 互換性
社内のチームは、サードパーティのツールが自分たちがすでに使用しているツールと統合できるかどうかを心配される場合があります。幸い、信頼できるベンダーの中には、サードパーティ製ツールをエコシステム内の他の製品と互換性を持たせるAPIソリューションを提供しているところがあります。これにより開発チームは、サードパーティ製ツールを、既存のビークルダイナミクスモデル、ドライブデータ解析プラットフォーム、HILインフラ、要件管理ツールなどと統合することができます。
F) TCO（トータル・コスト・オブ・オーナーシップ）
サードパーティ製のツールは、初期の購入コストが大きいものの、同程度の品質の自社製ツールに比べて、TCOが低い場合があります。他の製品と同様に、ソフトウェアツールは、構築した後、継続的にメンテナンス（バグの監視と修正、機能の追加と廃止など）を行う必要があります。メンテナンスには多大なエンジニアリングリソースが必要になります。。開発チームは、自社のツールを良好な状態に保つために、かなりのリソースを費やす場合があります。
要約
社内のチームがサードパーティ製ツールに対して抱く懸念の多くは、他の製品との統合をサポートする高品質でカスタマイズ可能なツールを選択することで解消されます。多くのユースケースや開発ニーズにおいて、適切なサードパーティ製ツールは、ADASおよびAVチームにクラス最高の製品の深さと機能の質を提供し、時間とエンジニアリングリソースを節約することで利益をもたらします。
2.商用 vs オープンソース
シミュレーションソフトウェアのカテゴリーには、商用ツールとオープンソースツールがあります。オープンソースのシミュレータに無料でアクセスできるのに、エンジニアリングチームはなぜ有料の商用ツールを選ぶのでしょうか？一般的には、以下のようなことが考えられます。
A) 開発スピードと製品の複雑さ
オープンソースのプロジェクトでは、開発チームがプロジェクトのソースコードを直接使用したり、ニーズに合わせて変更したりすることができるため、開発チームは迅速に反復作業を行うことができます。しかし、商用ベンダーは、毎日さまざまな顧客と直接仕事をしているため、業界特有の問題をよりよく理解し、センサーモデルなどの正確で堅牢な製品機能を構築できることが多い（図3）。
B) 認証
商用ツールは、オープンソースのツールに比べて認証が容易です。ADASやAVチームにとって、ISO 26262やSOTIFなどの安全規格に準拠したシステムを認証してもらうことは、製品化に向けた重要なステップです。オープンソースのソフトウェアは、誰でも自由に変更できるため、市販のツールに比べて認証が複雑になります。
C)本番環境への対応
市販のシミュレーターやインフラツールは、本番環境での使用に適しています。市販のベンダーは、実世界の問題を解決するために、反復的な開発サイクルでソフトウェアを開発し、改良しています。実際のテストや開発の中で、お客様が問題に直面したり、新たなビジネスニーズを発見したりすると、ベンダーは常にフィードバックを受け取ります。オープンソースのソフトウェアは、大学の研究室で作られ、一般の研究コミュニティで使用されることが多く、産業界からのフィードバックループはありません。
3.エンド・ツー・エンドのツールチェーンとベンダーロックイン
ADAS/AVエンド・ツー・エンド・ツールチェーンとは、ADAS/AV開発サイクルのさまざまなステップをサポートするために連携して動作する複数のツールの集合体です。エンド・ツー・エンドのツールチェーンは、シミュレーション、データ処理、テスト、V&Vを複数のベンダーで行う代わりに、開発チームが同じベンダーのツール群を統合的に使用することを可能にします。
エンド・ツー・エンドのツールチェーンを提供しているプロバイダーを使っても、開発チームが他のベンダーのツールは使えないということはありません。その理由は以下の通りです。
A) モジュール化
ADAS/AVチームの多くは、エンド・ツー・エンドのツールチェーンの使用をためらっています。その理由は、すでに開発サイクルのさまざまな部分で異なるツールを使用しており、エンド・ツー・エンドのツールチェーンを使用すると、既存のツールをすべて交換しなければならないのではないかと懸念しているからです。しかし、エンド・ツー・エンドのツールチェーンを構成するコンポーネントは、通常モジュール化されており、他のツールとの互換性があるため、チームは必要な製品を選択することができます。例えば、当社のV&VプラットフォームであるValidation Toolset*は、あらゆるシミュレータでシミュレーションを実行することができ、開発チームは抽象的なシナリオを作成し、あらゆるODDに対して論理的なシナリオを生成することができます（図4）。また、Validation Toolsetを当社の地図編集ツールMap Toolset*と併用することで、Applied Map Sweepsのようなクラス最高の独自機能を活用することもできます。
.png)
B) データの共有とアクセス性
さまざまな種類のデータをツール間で共有し、そのデータにどこからでもアクセスできるようにするという点も懸念されます。モジュール式のエンド・ツー・エンドのツールチェーンは、すべてのパーツが相互に通信し、OpenX規格などの共通データフォーマットをサポートしているため、この目的に最適です。このようにエンド・ツー・エンドのツールチェーンは、開発チームがシナリオ、要件、テストケースを共有し、それらがオンプレミスやクラウドに保存されているかどうかに関わらず、アクセスすることを可能にします。チームがすでにいくつもの異なるツールを使用していても、他のすべてのツールの間をつなぐ組織としてエンド・ツー・エンドのツールチェーンを活用することは有益なことです。
Applied Intuitionの取り組み
今回の記事では、ADASやAVの開発用にサードパーティ製ツールを購入する際によくある質問にお答えしました。Applied Intuitionでは、あらゆる規模のADAS/AVプログラムのさまざまな開発ユースケースをサポートする、最先端の本番環境に対応可能ななツールを構築しています。Applied Intuitionのエンドツーエンドのツールチェーンの詳細や、お客様のツールニーズへの適応については、ADAS・AVエンジニアチームにお問い合わせください。
*注：過去のObject SimはSimian、Validation Toolsetは以前はBasis、Map Toolsetは以前はMeridianと呼ばれていました。
.webp)
.webp)
