AUTOSARで変わる車載ソフトウエア開発（1/4 ページ）

車載ソフトウエアの標準規格AUTOSARの採用に向けた活動が活発化している。規格策定の中心地となっている欧州では、AUTOSAR準拠の車載ソフトウエアを採用した新車が発売されるなど、取り組みが先行している。一方、AUTOSARへの対応が遅れていると言われていた日本でも、JasParの評価活動をはじめさまざまな取り組み事例が報告されるようになった。本稿では、まず既存の車載ソフトウエアとAUTOSAR準拠の車載ソフトウエアの違いについてまとめる。その上で、欧州と日本におけるAUTOSARの実装に向けたさまざまな取り組みを紹介する。

[本誌編集部 取材班，Automotive Electronics]

増大する車載ソフトウエアの規模

　自動車の電子化の進み具合は、いくつかの指標で表現することができる。その指標の1つとして用いられるのが、搭載されるECU（電子制御ユニット）の数である。

　ECUの搭載が始まった1980年代初頭は2〜3個程度だったが、現在は100個以上ものECUを搭載する高級車も存在する。基本的に、それらのECUは、ある1つの自動車システムを制御するために最適化されたハードウエアと車載ソフトウエアから構成されている。各ECUは、ほかのシステムを制御できるような汎用的な作りにはなっていない。例えば、エンジンの燃焼タイミングを制御するエンジンECUは、ステアリングやメーターなどほかのシステムの制御を行うことはできない。

　このように、各ECUの役割が1つのシステムを制御することだけであれば、ECUの搭載数の増加と車載ソフトウエアの規模の増大はほぼ比例することになりそうに思える。しかし、実際にはそのような比例関係は成り立たない。現在の自動車で、あるシステムを制御するには、メインのECUだけでなく、そのシステムとかかわりを持つほかのシステムのECUからの情報が必要になる。そのため、自動車内のECUはネットワークにより接続されており、さまざまな情報を共有している。ECUがネットワークで接続される場合、新たにECUを1個追加するだけでも、既存のECUの車載ソフトウエアに対して、新しいECUに関連する改変を加える必要が生じる。そして、現在の自動車では、このような改変作業が積み重なったことで、ECUの搭載数の増加に対して、車載ソフトウエアの規模が指数関数的に増大しているのだ。

　車載ソフトウエアの規模が増大したとしても、各自動車メーカーの車載ソフトウエアに関する資産を再利用できれば、その影響を最小限にとどめられるはずである。しかし、既存の車載ソフトウエアは、特定の自動車メーカーの特定の車種において、特定のシステムを最適に動作させることを目的として開発されている。そのため、ある自動車メーカーが、自社の新しい車種において既存の車種のソフトウエアを再利用しようとしても、大規模な改変作業が必要になってしまう可能性が高いのだ。

モジュール化で再利用性を高める

　AUTOSAR（Automotive Open System Architecture）は、欧州の自動車メーカーを中心に策定されている標準規格である。その目的は、車載ソフトウエアの爆発的な規模の増大に対して、再利用性を高めることにより対応することだ。また、AUTOSARは、その規格化を進めているコンソーシアムの名称でもある（別掲記事『第3期はエネルギー管理ECUをサポート』を参照）。

図1　従来の車載ソフトウエアとAUTOSARの比較（提供：AUTOSAR）　

　既存の車載ソフトウエアは、ハードウエアやシステムとほぼ1対1で対応するものとして開発されてきた（図1（a））。これに対して、AUTOSARでは、階層化されたソフトウエアアーキテクチャとして車載ソフトウエアのあり方を定義している（図1（b））。各階層で使用するソフトウエアをモジュール化（コンポーネント化）することにより、その再利用が可能になるという仕組みだ。

図2　AUTOSARのソフトウエア構造（提供：AUTOSAR）　アプリケーション層はモジュール化されたソフトウエアコンポーネント（SW-C）で構成される。基盤ソフトウエア（BSW）の各層も複数の細かいモジュールで構成されている。

　図2に示したのが、AUTOSARが定義するソフトウエアアーキテクチャの構造である。上層からアプリケーション層、AUTOSARランタイム環境（Run time Environment：RTE）、基盤ソフトウエア（Basic Software：BSW）の3つに大きく分けることができる。

　アプリケーション層は、モジュール化された複数のソフトウエアコンポーネント（Software Componet：SW-C）で構成される。SW-Cは、これまでECU単位で開発されていた各自動車システムを制御する機能に相当する。ただし、従来の車載ソフトウエアとは異なり、ハードウエアに依存しないので、異なるハードウエア構成のECUでも再利用することができる。

　BSWは、ハードウエアと車載ソフトウエアをつなぐ階層で、従来のOS、ドライバ、ミドルウエアに相当する。BSWは、大まかに、サービス層、ECU抽象化層、マイクロコントローラ抽象化層（MCAL）、複合ドライバ層の4つに分けられる。さらに、この4つの層の中身も、車載ソフトウエアを動作させるための役割に対応する細かいモジュールに分割されている。これらのモジュールも再利用が可能であり、汎用品として販売することもできる。

　RTEは、アプリケーション層内のSW-CとSW-Cとの間、SW-CとBSWの間をつなぐインターフェースである。既存の車載ソフトウエアでは、SW-C間で直接情報をやりとりしているが、AUTOSARでは、RTEを通して情報をやりとりすることになる。もちろん、SW-CとBSWとの間の情報のやりとりについても、RTEを通して行われることになる。

図3　仮想機能バスによる車載ソフトウエア開発の仕組み（提供：AUTOSAR）　

また、AUTOSARでは、ECUを意識することなく車載ソフトウエアを開発できる仕組みが提供されている（図3）。

　まず、自動車メーカーの技術者は、仮想機能バス（Virtual Function Bus：VFB）と呼ばれる抽象的なインターフェースに、自動車の各機能を実現するSW-Cを接続する形で開発を進めることになる。これらのSW-Cは、実際には自動車に搭載されるECU内に組み込まれ、それらのECU間がネットワークで接続されることによって自動車の機能が実現される。仮想機能バスは、ECUへの組み込みやネットワークなど、現実世界で必要なものをすべて模擬するので、自動車メーカーの技術者はECUを意識することなくSW-Cを開発することができる。

　次に、自動車に実際に搭載する各ECUの仕様と、ECUを接続するネットワークのトポロジを決定する。このとき、各ECUでどのようなBSWを使用するかについても決定する。そして、ECUの仕様、ネットワークのトポロジ、使用するBSWに関する情報と、SW-Cを接続している仮想機能バスに関する記述を基に、SW-Cが各ECUに割リ付けられる。同時に、各ECUのRTEも生成される。

　なお、仮想機能バスを使ったSW-Cの動作シミュレーションや、SW-Cの割り付け、RTEの生成は、専用のツールを用いて行う。また、ツール間でやりとりする情報は、XML（Extensible Mark up Language）により記述されることが規定されている。