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

» 2009年10月01日 00時00分 公開
[本誌編集部 取材班,Automotive Electronics]
前のページへ 1|2|3|4       

国内ベンダーがツールを発売

 AUTOSARは、自動車メーカー、ティア1サプライヤ、半導体メーカー、ツールベンダーなど、車載ソフトウエアの開発にかかわるすべての企業が、AUTOSARの導入によって利益を享受し得ることを前提として規格化された。中でも、新たな市場が生み出されると期待されているのが、AUTOSAR対応の開発ツールとAUTOSAR準拠のBSWの領域である。AUTOSAR対応の開発ツールは、システム設計ツール、コンフィギュレーションツール、ジェネレータツールで構成される。これらのうち、システム設計ツールとコンフィギュレーションツールが新規のものであり、1つのツールとしてまとめられていることも多い。ジェネレータツールは、モデルベース設計ツールの組み込みコード生成機能に相当するツールである。


表2 各ベンダーが提供するAUTOSAR対応ツール 表2 各ベンダーが提供するAUTOSAR対応ツール 

 表2に、主なベンダーが提供しているシステム設計/コンフィギュレーションツール、ジェネレータツール、BSWをまとめた。この分野で先行するのも欧州の企業である。ドイツのVector Informatik社、dSPACE社、ETAS社、フランスGeensys社、フィンランドElektorbit社などが2006年〜2007年にかけて、AUTOSAR対応ツール/BSWの市場投入を開始している。また、モデルベース設計ツールで最も高いシェアを持つ米The MathWorks社の「MATLAB/Simulink」は、2008年にAUTOSARコードの生成への対応を開始した。

 現在もこの市場への新たな企業の参入が相次いでいる。Bosch社は、Boschグループ全体でAUTOSARという標準規格の登場をビジネスチャンスとしてとらえている。そして、Bosch社のインド法人でソフトウエアの受託開発を行っているRobert Bosch Engineering

and Business Solutions(RBEI)社は、AUTOSAR対応ツールの「iSOLAR」とBSWの「CUBAS」を2008年末に発売した。同じくBosch社の子会社であるETAS社のジェネレータツール「ASCET」がAUTOSARに対応しているので、Boschグループの製品だけでAUTOSARに対応するECUを開発することが可能だ。なお、CUBASのOSは、ETAS社がライセンス提供する「RTA-OSEK」である。

 CASE(Computer Aided Software Engineering)ツール「ZIPC」で知られるキャッツは2009年3月、システム設計/コンフィギュレーションツール「ZIPCAUTOSAR」を発売した。同製品は、国内ベンダーが初めて販売するAUTOSAR対応ツールである。ZIPCは、ソフトウエアの振る舞い設計に用いるツールだが、ZIPC AUTOSARは、ZIPCの名前が付いているものの、ソフトウエアの構造設計ツールとなっている。キャッツは、「20年の歴史を持つZIPCにより、振る舞い設計ツールの実績は十分に積み上げることができた。そして、ソフトウエア開発ツールの展開を拡大するとしたら、構造設計ツールが必要になると考えた。その典型的な適用事例として、まずAUTOSARに対応するZIPC AUTOSARを投入することにした。今後は、ZIPC AUTOSARをベースに構造設計ツールの開発を進める方針だ」としている。ZIPC AUTOSARは、すでに、数社の国内ティア1サプライヤが採用している。

BSWベンダーは少数

 Bosch社の事例のように、AUTOSARへの移行は段階的に進んでいくと考えられる。その最初の段階では、AUTOSAR準拠のBSWを部分的に導入するというのが一般的なアプローチであろう。しかしながら、AUTOSARにのっとって実装を行う際に最も手間がかかるのが、BSWの構築であり、ソフトウエアの性能を左右するのもBSWである。

 BSWを供給するベンダーは、BSWを顧客の要求に合わせてカスタマイズするという作業に追われることになる。また、AUTOSARではカバーしていない機能についても、独自にBSWとして提供するなどの努力が求められる。こうしたことから、BSWを販売しているベンダーの数は、AUTOSAR対応の開発ツールを手掛けるベンダーよりも少ない。

 Vector Informatik社は、BSWの展開に最も力を入れているベンダーだと言える。同社は、「特に、半導体メーカーが提供するマイクロコントローラ抽象化層のBSWは、ハードウエアとの接点に当たり、開発に時間がかかるため、ほとんどがリリース3.0には対応していない。一方で、マイクロコントローラ抽象化層より上層のBSWは、ほとんどがリリース3.0に対応している。そして、リリース2.1対応のマイクロコントローラ抽象化層と、リリース3.0対応のBSWの統合は、バージョンが異なるためかなり困難な作業になる。AUTOSARへ段階的に移行するのであれば、こういった作業を行わなければならなくなるが、当社にはその実績がある」と意気込みを見せている。

第3期はエネルギー管理ECUをサポート

 コンソーシアムとしてのAUTOSARは、欧州の自動車メーカーが中心になって2003年に設立された。その活動は、3年をひと区切りとした期間に分けられている。2004年〜2006年の第1期には、標準規格としての基本仕様の策定を行った。そして、2007年〜2009年の第2期は、規格の運用と実車への採用を始める段階となっている。

 コンソーシアム活動の進展に合わせて、規格としてのAUTOSARの仕様もバージョンアップを果たしている。現在の最新バージョンは、2008年8月に発表されたリリース3.1である。そして、2009年末には、第2期として最後のバージョンアップとなるリリース4.0の発表を予定している。リリース4.0では、マルチコアプロセッサや自動車の機能安全規格(ISO 26262)などへの対応を予定している。

写真A AUTOSARのJürgenMössinger氏 写真A AUTOSARのJürgenMössinger氏

 2010年〜2012年には、第3期として活動を継続する方針である。AUTOSARスポークスパーソンであり、ドイツRobert Bosch社でオートモーティブシステムインテグレーション部門の部長を務めるJürgen Mössinger氏(写真A)は、「第3期には、規格の仕様をより充実させるとともに、10個以上のプロセッサコアを用いるメニーコア処理や、イーサーネット、MOST(Media Oriented Systems Transport)など従来カバーしていなかったネットワークプロトコルのサポートを進める。機能安全規格についても、すべての仕様が決定されるのが2010年以降になるので、引き続き対応を進める必要があるだろう」と語る。

 Mössinger氏が、第3期の活動で、最大のテーマの1つとして挙げるのが、エネルギー管理ECUへの対応である。「需要が高まっているハイブリッド車や電気自動車において、電気エネルギーの生成と消費を管理するエネルギー管理ECUは、非常に重要な役割を果たしている。AUTOSARとしても対応を進める必要がある」(同氏)という。


前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.