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

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

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

AUTOSAR実装に向けた取り組み

　AUTOSARの活動は欧州を中心に行われている。そのため、AUTOSARの規格は、主に欧州の自動車メーカー、ティア1サプライヤなどからの要望を反映したものとして策定されている。また、量産車への採用でも欧州メーカーが先行している。AUTOSAR対応の開発ツールやBSWも、ほとんどが欧州のツールベンダーから供給されている。

　しかし、2009年に入り、日本でもAUTOSARに対するいくつかの取り組み事例が見られるようになっている。ここでは、欧州と日本におけるAUTOSARの実装に向けた取り組みを紹介する。

Bosch社のロードマップ

　欧州のティア1サプライヤの中でも、AUTOSARに対して最も積極的な取り組みを進めているのがドイツRobert Bosch社である。

図4　Bosch社の想定するAUTOSAR導入の状態/段階（提供：Bosch社）　この図では、従来から用いられていたSW-CやBSWに相当するものを「既存のSW-C」、「既存のBSW」と表している。一方、AUTOSARに準拠するSW-C、BSWについては、それぞれ「AUTOSARSW-C」、「AUTOSARBSW」としてそのことを明示した。

　まず、Bosch社は、車載ソフトウエアへのAUTOSARの適用に向けて、AUTOSARの導入されている状態/段階を規定した（図4）。Bosch社の車載ソフトウエアは、AUTOSAR準拠ではないものの、従来からSW-CやBSWに相当する階層の概念を用いて構成されていた。そして、既存の車載ソフトウエアの状態を「Status A」、AUTOSAR準拠のBSWのうち通信モジュールだけを採用した状態を「Status B」、AUTOSAR準拠のSW-CとRTEを部分的に採用した状態を「Status C」とする。そして、AUTOSARに準拠した複数のSW-C、RTE、BSWを本格的に採用する段階が「Step 1」となる。Step 1では、半分以上のソフトウエアがAUTOSARに準拠している状況になる。続く「Step 2」では、ほとんどのソフトウエアがAUTOSARに準拠することになる。

　Bosch社は、Status Aから、各自動車システムにおいてどのようにAUTOSARを導入していくかを示すロードマップも策定した。まず、Status B/Cへの移行は、パワートレインが2006年後半から、横滑り防止装置（ESC）、アダプティブクルーズコントロール（ACC）、ゲートウエイECUが2008年から、ボディ系システムと自動駐車システムが2009年から始まっている。Step 1への移行は、パワートレインが2009年後半から、ESC、ACC、ゲートウエイECU、ボディ系システムが2011年から始まる予定である。最終段階となるStep 2には、パワートレインが2011年、ESCやACCが2012年、ボディ系システムが2012年後半、ゲートウエイECUが2013年後半に移行する。なお、自動駐車システムは、2011年からStep 1を飛び越して、Step 2に移行する見込みである。

JasParは独自仕様で効率を向上

表1　AUTOSARのメリットとデメリット　

　先に述べたように、AUTOSARは、ソフトウエアの再利用性に重点を置いて規格化されている。AUTOSARに準拠することで、車載ソフトウエアの開発にはさまざまなメリットがもたらされることになる（表1）。

　これらのメリットに対して、AUTOSARの導入によるデメリットも指摘されている。それは、ソフトウエアの処理効率が低い、ソフトウエアが“重い”ということである。従来の車載ソフトウエアは、再利用が難しい反面、ECUに搭載されているマイコンの性能やメモリーの容量で実行できるように最適化されている。しかし、同じ車載ソフトウエアをAUTOSAR準拠で再構成した場合、それまでは存在しなかった階層間やモジュール間を結ぶインターフェースなどの影響により、従来のECUよりも高性能のマイコンや大容量のメモリーが必要になるというのである。

　特に、主力モデルが小型車やミニバンである日本の自動車メーカーにとって、このデメリットの影響は大きい。たとえどのようなメリットがあったとしても、高価なECUが必要になるのであれば、AUTOSARの導入には消極的にならざるを得ないからだ。

　日本におけるAUTOSARの導入を促進するために、このデメリットの影響をできる限り小さくするための活動が進められている。その活動の中心となっているのがJasParだ。JasParは、日本国内のメーカーを中心に車載ソフトウエアの開発/標準化を推進している業界団体である。JasParの副運営委員長で、日産自動車 EV技術開発本部 EVパワートレイン開発部 エキスパートリーダーを務める安達和孝氏は、「現在、JasParでは、AUTOSARをリファレンスとして実装するのに必要な仕様（以下、JasPar仕様）を策定している。これは、AUTOSARという標準規格について、日本の自動車メーカーやサプライヤにとって、どうすれば実装しやすくなるのかという観点から、JasParが解釈したものになっている」と語る。

　JasParが行っているAUTOSAR関連の活動は、次の3つに分けられる。BSWの評価基準の策定、JasPar仕様に必要な開発ツールとBSWの仕様策定、AUTOSARコンソーシアムとの連携である。

　AUTOSARを導入する場合、BSWの性能や、実現しようとする機能/用途に対するBSWの適性が低いと、より高性能のECUが必要になると言われている。そこで、BSWの評価基準の策定では、自動車メーカー、ティア1サプライヤ、ツールベンダーなどが開発/使用することになるBSWについて、そのベンチマーキングを行うための評価基準を定めた。この評価基準は、ISO 9126で規定されているソフトウエアの品質6特性に基づくものとなっている。

　また、車載ソフトウエア全体の性能（処理効率やリソース消費量）と再利用性を両立したBSWの開発や構築が可能になるような、2つの手法を検討している。1つは、機能の絞り込みを行うための「プロファイル」である。BSWをコア機能とオプション機能に分類した上で、求める機能に合わせてコア機能とオプション機能を組み合わせたプロファイル（機能サブセット）を選択するというものだ。もう1つが、BSWのモジュールを統合する「クラスタ化」である。AUTOSARに準拠した車載ソフトウエアの開発において、ECUで使用できるようにBSWを仕上げるプロセスはティア1サプライヤが担当することになる。しかし、実際の作業において、ティア1サプライヤは、個別のモジュールとしてBSWを構成するのではなく、下請けのティア2サプライヤが機能別にモジュールを統合したクラスタを使って行うことになる。「AUTOSARでは、このティア2サプライヤが行うプロセスについての規定がない。そこで、JasParでは、機能の互換性を維持できるような仕組みを作ることにした」（安達氏）という。

　上述したプロファイル、クラスタ化を適用すると、既存のAUTOSAR対応ツールではソフトウエア開発が行えない。そこで、これらに対応したツールの仕様策定も同時に進められている。

　AUTOSARでは、AUTOSAR準拠のソフトウエア開発を実現する方法論（メソドロジ）のみを規定しているだけで、ツールの仕様についての規定はない。AUTOSAR準拠の車載ソフトウエア開発では、自動車の電子システム全体を設計する「システム設計ツール」、各ECUにおけるソフトウエアの構成を決定する「コンフィギュレーションツール」、組み込みコードを生成する「ジェネレータツール」が用いられる。安達氏によれば、「現在販売されている欧米ベンダーのAUTOSAR対応ツールは、各プロセスにおけるパラメータの受け渡しなどがブラックボックス化されており、JasPar仕様のAUTOSAR開発でそのまま使用することができない。そこで、JasParとして、AUTOSARにおける設計から検証までをカバーするツールチェーンを規定した。また、各プロセスで異なるベンダーのツールを用いたとしてもきちんと連携できるように、ツールのフレームワークについても規定する」という。

　AUTOSARコンソーシアムとの連携としては、2009年末に発表されるAUTOSARリリース4.0、JasParからの技術要求が一部盛り込まれる予定である。盛り込まれるのは、FlexRayに関連する仕様となる予定だ。