環境センサはいくつ必要か
乗用、農業用、鉱業用などの自動運転車業界の企業は、今後の数年で自動運転レベル3および4を達成するべく事業活動を加速させることが見込まれます。しかし、これらの自動運転レベルに到達するには、認知センサの数を大幅に増やさねばなりません。つまり、業界関係者にとって「自動運転レベル3および4の実現に必要な環境センサの数は。」や「新たな課題は。」といった問いに答えを出す時期に差し掛かっているということです。
マルチセンサアプリケーション開発の課題を過小評価してはならない
OEMメーカー各社は現在すでに、将来の高度な自動化に求められるハードウェア自体は自社の開発車両に搭載しています。しかし、上記の自動運転レベルの達成には20～30個のセンサが必要であろうと見込まれるため、カメラ、レーダー、LiDAR、音響、超音波、GPS/GNSSなど、ますます多くの環境センサの搭載が進んでいます。これらのセンサはそれぞれ異なるサンプリングレート、データインターフェース、およびデータ形式があり、それゆえに複雑なソフトウェア（SW）機能の開発には、多種多様な部門、チーム、パートナー、および専門家が関与することになります。つまり、自動運転車両向けのマルチセンサアプリケーション開発において、課題を過小評価することは禁物ということです。
ADAS/ADアプリケーションの開発要件
センサおよびI/Oデバイス用インターフェース
ADAS/ADの開発者は、下流コンポーネントが対応し得るフォーマットを用いて、センサやバスからのデータにアクセスするためのインターフェースを開発しなければなりません。また、エンジニアや開発者は、生データや広帯域幅データの取得、データ処理、データ同期、およびデータフュージョンの際に用いる効率的かつ汎用的なツールを開発する必要があります。
ラピッドプロトタイピングと量産実装
どんなに精密にプロトタイプを作成しても、量産環境にデプロイできない場合、それは何の役に立つのでしょうか。これは、多くのADAS/ADソフトウェア開発チームが陥る悩ましい状況です。多くのエンジニアは、Robot Operating System（ROS）などのオープンソースソフトウェア（OSS）を使用しています。これらのツールは、自動車のISO 26262、農業機械のISO 25119、土木機械のISO 219014-1や他の機能安全規格には対応しておらず、CAN、CAN FD、Ethernetなどの規格についても、強固なサポートがない状態です。
協力の構築
最先端のアプリケーションを開発するうえで重要な要素となるのは、チーム間やさまざまなパートナーとの連携です。この要件は、プロジェクトチームが地理的に多様な場所に存在する多国籍企業の場合、さらに決定的に重要となります。多様なパートナー、チーム、および専門家の間の連携には、全員にとって使いやすいソフトウェア開発フレームワークが必要です。そしてそのフレームワークは、パートナー同士の共同開発を許容しながらも、知的財産（IP）を外部に露見させるリスクのない、理想的な知的財産保護を与えるものでなければなりません。また、PythonやSimulinkなどのさまざまなプログラミング言語のサポートも必要です。
コード／アルゴリズムの再利用
ADAS/AD向けアルゴリズムの開発は、大量のリソースを消費します。本質的には、開発したコードやアルゴリズムが他のプロジェクトや将来において再利用できるということが重要です。加えて、コードテンプレートやコーディングガイドラインを統一してSW機能の保守性を高めることで、アプリケーションの信頼性を確保することも必要です。このような場合、さまざまな開発元のOSSを使用していると、これを達成するのは潜在的に難しくなりますが、コンポーネントベースのプログラミングを活用すれば、コンポーネントを安定して再利用できるだけでなく、それらの共有も容易になります。
使いやすいデバッグアプリケーション
ADAS/AD機能の開発プロジェクトは複雑であり、それらの機能を車両に安全に実装するためには多数のアプリケーションが必要となりますが、一方でやはりスピード感は絶対に必須で、アプリケーションを速やかに市場に出すことが重要です。本質的には、アプリケーションに対するすばやいデバッグ能力が決定打となります。これがアプリケーションの開発、テスト、およびデプロイにかかる時間を削減するためです。
ADAS/ADソフトウェア開発プラットフォームとしてのRTMaps
RTMaps（Real Time Multi-Sensor Applications）は、開発の早期の段階におけるプロトタイピングから量産段階に至るまで、多様な状況に対応できるソフトウェア開発プラットフォームであり、各開発チームがRTMapsの次の特長を駆使すれば、ソフトウェア開発が促進されます。
プロトタイピングから量産まで対応
ADAS/ADアプリケーションの機能開発では、アプリケーションを量産環境にデプロイする際に課題が生じ、そのプロセスは遅れがちになります。ROSなどの既存のソリューションの多くには、量産のための装備がありません。高レイテンシ、非確定な動作、機能安全サポートの欠如が、OSSの使用にまつわる主要な障壁です。一方RTMapsは量産段階に対応しているので、Linux、Windowsを問わずアプリケーションの開発が可能なうえ、QNXなどのRTOSにもデプロイすることができます。また、RTMapsはX86やARMベースのデバイスで動作するため、ハードウェアの抽象化も可能です。
ソフトウェア開発における複雑さを軽減
RTMapsでもスクリプトを記述することはできます。しかし、ソフトウェア開発の複雑さを軽減するうえで命綱となるのは、コンポーネントベースの開発環境です。コンポーネントベースの開発は、アプリケーションのデバッグ、テスト、さらにはチーム間の連携をシンプルにやりやすくするだけでなく、そのうえ、要件定義を容易に行い、アプリケーションの動作をさまざまな入力に適用してテストすることで、テストの複雑性を減少します。
ISO 26262認証
各業界で使用されるセーフティクリティカルなアプリケーションには認証が義務付けられており、自動車業界においてはISO26262が満たすべき規格です。自動運転車両はその枠組みの全体について認証を受けなければならないのですが、ここで重要なことは、既に認証済みのミドルウェアの使用によって、認証取得に必要なリソースと労力が削減できるということです。つまり、ISO26262 ASIL-B準拠の認証を近く取得するRTMapsを使用すれば、QNXやEmbedded Linuxなどの各種RTOSで安全にマルチコア機能を実行し、ゼロコピー手法でデータを処理し、dSPACEの量産コード生成ツールであるTargetLinkからRTMapsコンポーネントを生成したうえで、さまざまなコンポーネントのレイテンシを容易にモニタリングすることができるのです。
600以上のセンサとI/Oコンポーネント
CAN、CAN FD、Ethernetなどのバス経由でLiDAR、レーダー、カメラなどのセンサを接続できる多数のコンポーネントを備えたプラットフォームは非常に重宝します。ROSなどのOSSには多くの場合、コミュニティによって開発されたノードやインターフェースが含まれていますが、RTMapsは特にソフトウェアのプロトタイピング用として、すぐに使えるROS向けのインターフェースを提供しているため、双方のアプリケーションを容易に接続できます。また、量産開発にOSSを使用する場合は通常、これらのコンポーネントの検証や保守のために多大なリソース投資をしなければなりませんが、RTMapsにはプロにより開発・保全された600以上のすぐに使えるコンポーネントが用意されています。さらに、RTMapsのAIストアを使用すれば、パートナーが開発した最先端のAIモデルにアクセスすることも可能です。
このように、RTMapsは理想的なプラットフォームであり、ADAS/ADアプリケーションの開発を加速化し、総コストを抑えながらマーケットへの高速の近道を入手できます。
