自動運転量産化を実現するための３つのポイント

高度自動運転車の量産化が一向に進まない要因の一つとして、多様な状況に対応しつつ、一定の機能安全を確保するソフトウェア開発の難しさが挙げられる。

ドイツのソフトウェア開発会社で、Continentalの100%子会社であるElektrobit Automotive (以下、Elektrobit)は、このような困難を克服するために、プログラミングの単純化、再利用、標準化を提唱している。

今回はElektrobitの提唱する自動運転量産化の鍵となるプログラミングの単純化、再利用、標準化に加え、その一例としてElektrobitのソフトウェアEB robinosについて解説する。

単純化、再利用、標準化

競争力を保つために、ソフトウェア業界は三つのことに取り組むべきである。第一に単純化である。高度なプログラミングを捨て、なるべく単純な要素に切り分けていく。
第二に再利用の推進である。使い回せるものを極力再利用する。
第三に標準化である。再利用する中で、時には自分で作ったものだけではなく他から買い求める。それは標準化によってのみ可能になる。

単純化は、ソフトウェアをハードウェアと切り分けることによって実現される。
E/Eアーキテクチャは、NCAP的な機能やインフォテイメント、ネットワークなど、様々な機能と結びつき、それらの制約を受けている。このE/Eアーキテクチャを切り離し、ソフトウェアの部分だけに単純化すると、開発を飛躍的に早めることができる。

ECUとも切り離されるため、どのようなECU、どのようなネットワークでも作動するソフトウェアとなる。すなわち、特定のハードウェアに依存せずに、ソフトウェアを開発することが非常に重要である。 さらにこのソフトウェアも、センサーデータフュージョン、モーションマネジメント、HMIというように機能別にいくつかに切り分けモジュール化する。

そして、それぞれのソフトウェアのコンポーネントでは、しっかりとしたコアを形成することが必要になる。コアは硬く、シェルは軟らかい、アボカドのようなソフトウェアが必要である。

現在の車載ECUには再利用可能なソフトウェアのコアが存在する。できればそれらを積極的に活用し再利用する必要がある。
例えば、フリースペースモデルとオブジェクトモデルを組み合わせて、車が走行可能な領域を特定するソフトウェアがひとたび量産採用されれば、それは既に認証を受けているのだから、試作から量産まで、あるいは次の世代のモデル、別のラインアップモデルにも全てに利用することができる。
その際には多様なインターフェイスに対応することが重要になる。束ね方を把握しやすい、コンポーネントベースのソフトウェアアーキテクチャが必要である。

＜柔軟なインターフェイスで開発の全段階に共通利用＞

ElektrobitのソリューションEB robinos

Elektrobitは自社のソフトウェアとしてのEB robinosの他に、オープンアーキテクチャによるOpen robinosも開発している。これはレベル5までの自動運転に向けたリファレンスプラットフォームとして、常に最新の状態に保つようにしている。このリファレンスプラットフォームによって、アーキテクチャやインターフェイス、データの流れを規定している。
これはクリエイティブ・コモンズに基づき、誰でも自由にダウンロードして活用できる状態にある。多くのソフトウェア開発者がこれを利用し、改良し、フィードバックしてくれることを望んでいる。

ElektrobitのEB robinosはコンポーネントベースのソフトウェアアーキテクチャの一例である。
robinosでは、センサーフュージョンにもさらに細かくいくつかのコンポーネントがある。ポジショニングは、ソナーやカメラセンサーの情報をもとに自車位置を特定するもの、オブジェクトフュージョンは歩行者や他車、障害物を認識するもの、グリッドフュージョンは、障害物に占拠されたスペースとフリースペースを区分するもの、ロード&レーンフュージョンはどちらに曲がるのかどの車線を走行すべきかを特定するものである。
そして車両データベースのコンポーネントがある。

その次に、これらのデータフュージョンを受けて行動決定を行う必要がある。例えば、前方に遅いトラックが走行している場合に、車線変更して追い越すのか、そのまま車線にとどまるべきか。そして、その決定を受けて、軌道制御、縦横方向の制御が決まり、エンジンやブレーキ、ステアリングのアクチュエーターに伝えられる。その際、HMIは独立して管理される。
レベル3やレベル4では、運転しているのがドライバーなのか機械なのかを明確にする必要があるからである。ドライバーがハンドルを握っているか否かといったHMIの要素は自動運転のコアの部分にかかわってくる問題である。その上で、セーフティマネジメントというコンポーネントが全体に横串で通る。

コンポーネントアーキテクチャの利点

これらのコンポーネントアーキテクチャが成立すれば、任意のECUにマッピングすることができる。中央統合型のECUである必要がなくなる。中央統合型ECUより優れた代替案が世の中には登場しつつある。
各コンポーネントはそれぞれ独立した機能を持っており、個別に差し替えることが可能であるため、スポーティなモデル、安全快適を重視したモデルなど、モデルの特徴やグレードに合わせた差別化も容易になる。自動車メーカーやTier 1サプライヤーが独自に開発したモジュールや、サードパーティ製のモジュールを用いても良いだろう。

コンポーネントの一部を搭載しNCAPに対応するだけの安全機能を持つソフトウェアを、例えばOTA (Over The Air programming)によって追加コンポーネントを含むものにアップグレードすれば、高度自動運転にも対応できるようになる。
全てのコンポーネントが全て試験実施済みで認証されていれば、組み合わせも容易である。先に開発されたコンポーネントを再利用すれば、開発期間は短縮され、複雑度も下がる。そして、上位から下位のモデルまで、ラインアップの全てに同じアーキテクチャのソフトウェアをスケーラブルに行き渡らせれば、スケールメリットが得られる。

標準化のメリット

標準化は業界全体にもメリットをもたらす。例えば、自動車メーカーやサプライヤーは、ソフトウェアベンダーを特定の企業に固定する必要がなくなる。
逆にベンダーにとっても、自動運転業界に参入する障壁が下がることになる。例えば、ある特定のモジュール、コンポーネントにのみ特化したソフトウェアを開発することも可能になる。
また、機能安全を同業他社との間で共有することも可能になる。実際の走行時に正しく安全が担保されていることを互いに確認することができる。

columnElektrobit、EB robinosの概要

（Dr. Björn Giesler氏 (Elektrobit, Head of Driver Assistance)のTU Automotive 2017講演および広報資料を基にFOURIN構成）

＜FOURIN世界自動車技術調査月報（FOURIN社 転載許諾済み）＞