(1/2)パワートレイン、シャーシ、ボディ電子、そしてカーナビなどの車載情報システムをはじめ自動車機能の電子制御化が進むことで、搭載するECU数が増加している。「ハイブリッド・レクサス」のように、ハイブリッド車かつ高級車ともなるとECU数は100個を超える。ECU数が増えれば、自動車1台あたりの車載ソフトウエアの規模も増大する。その増大率は単純にECU数に比例しない。ある自動車機能を実現する場合に複数のECUが関わることを考えれば、その組み合わせマトリックス数に合わせてソフトウエアが複雑化して、指数関数的に車載ソフトウエアは増大して行くことになる。Architecture)」である。});かつて、パソコンは「ソフトがなければただの箱」と言われたものだが、自動車のECUも同じで、制御のための車載ソフトウエアがなければ空の弁当箱である。1980年代に、エンジンを電子制御するために搭載されたECUのROMにも、もちろん制御ソフトウエアが入っていた。当時の車載ソフトウエアの規模は、Cコードに換算して約2000行程度と言われている(当時の開発はアセンブラで行われていた)。ECUによる制御は、エンジンのみならずトランスミッション、ブレーキ、ステアリング、シート、パワーウインドウなど対象を広げて行き、さらに1990年にはカーナビという大規模プロセッサを必要とするシステムも自動車に搭載されるようになった。車載ソフトウエアの規模は、2000年には1980年の1000倍となる200万行に到達し、2008年現在は約800万行と1000万行はもう目前となっている。今後、各種の安全システムの装備が一般化し、さらに路車間通信や車車間通信を行うITSシステムが実現されるようになれば、早々に1億行に達する可能性もある(図1)。1980年から2000年までの20年間で1000倍となっている。1000万行到達は2015年と言われていたがこれも早まる可能性が高い。自動車メーカーのソフトウエア開発体制が、この状況をより複雑にしている。自動車メーカーは、従来の車載ソフトウエアに接ぎ木するような形で新機能モジュールを組み込んできたため、もはや周辺モジュールとの接続を確認するだけでも新機能開発の2倍以上の工数が必要になっている。自動車メーカーの各システムを担当する事業部は完全に縦割りになっているため、事業部を横断してECUを連携させるような機能を実現する場合には、さらにすり合わせの時間が必要になる。Tier1サプライヤにとっては、ECUソフトウエアの構造やインターフェース形式が自動車メーカー間で異なるため、サプライヤ内でソフトウエアリソースを再利用することが非常に難しく、ますます増大して行くECUソフトウエアの規模に対応できなくなりつつある。この車載ソフトウエア開発の問題に対して、標準化の手法を業界に先駆けて取り入れてきたのが欧州メーカーである。1995年には、車載制御用の組み込みOSの標準「OSEK/VDX」の規格化を開始し、現在はほぼ業界標準となっている。SARは、このOSEK/VDXでの活動をもとに、標準化という概念に通じた欧州メーカーが車載ソフトウエア全体の構造にまで活動を広げることが狙いとなっている。中央のベーシック・ソフトウエア(BSW)は、上層のサービス、中央のECU抽象化複合ドライバ、下層のMCALに分かれる。左端のシステムサービス内にOSが含まれている。AUTOSARにおけるソフトウエアの再利用性は、RTEやハードウエアと接続するMCAL、そして各SWCやBSWのAUTOSARインターフェースにより実現される。Citroen社、トヨタ自動車)、規格策定作業に参加するプレミアム・メンバー54社、文書の閲覧と規格使用が許されているアソシエイト・メンバー80社で構成される。トヨタ自動車が、コア・パートナーとして参加しているという事実は、国内自動車業界も車載ソフトウエアの問題に直面していることを如実に表している。AUTOSARは、各ECUのハードウエアに合わせて最適化しなければならない車載ソフトウエア開発の現状に対して、ソフトウエアを各階層でモジュール化できるようにし、このモジュールを再利用できるように車載ソフトウエアの構造を再定義することを目指している。AUTOSARにおける車載ソフトウエアは、大きく分けて以下の4つの層に分かれる(図2、図3)。Component:SWC)で構成されるこのようにソフトウエア構造を4層に分け、さらにSWCやBSW内のOSや各ミドルウエアをモジュール化するためには、各モジュール間を接続するインターフェースが規格化されていなければならない。そこで、AUTOSARではマークアップ言語のXMLにより、各SWCに規定されるAUTOSARインターフェースや、BSWの標準インターフェースを記述している。RTEは、このXMLで記述されたインターフェースの情報を基に、ツールを使って生成することになる。Layer:MCAL)である。従来のドライバソフトウエアは半導体メーカー単独で提供していたが、MCALについてはBSWベンダと協業することが多い。AUTOSARの標準化により、自動車メーカー、ECUサプライヤ、半導体メーカー、ソフトウエアツールベンダなど、車載ソフトウエア開発に携わるすべてのプロセスで利益を享受できるといわれている。自動車メーカーは、ソフトウエア開発期間の短縮とコスト削減が可能になる。ECUサプライヤは、従来は各自動車メーカー個別に開発していたソフトウエアをSWCとして複数の自動車メーカーに販売できるようになる。半導体メーカーは、ソフトウエアがハードウエアに依存しなくなることにより5〜10年と言われる新規採用までの期間を圧縮できる。ツールベンダにとっては、AUTOSAR準拠のソフトウエア開発では各種ツールの使用が前提になることから、新規市場を獲得するチャンスになる。AUTOSARは、2004年〜2006年にかけてPhase1として基本的な規格策定を進めてきた。2007年〜2009年のPhase2ではPhase1の成果活用と規格の発展を進めることとしている。コア・パートナーは、AUTOSAR準拠のソフトウエアを採用した市販車を、2008年から2012年にかけて発売する計画。採用は、ボディ電子の一部などに限られるものの、2008年末のBMW社とBosch社を皮切りに、2009年には欧米メーカー、2010年にはトヨタが市場投入する見込みだ。AUTOSAR準拠の車載ソフトウエア開発のプロセスは上流側から、(1)要求仕様を基に車両内のECUシステムを設計する、(2)制御モデルからSWCを作成する、(3)SWCとBSWからRTEを生成し車載ソフトウエアとして実装する、という3段階に分けることが可能である。ツールベンダは、各プロセスでAUTOSAR仕様のリリース2.0もしくは2.1に対応した製品の市場投入を進めており、2008年以降は本格的なECU開発に利用できるリリース3.0に対応した製品開発が完了する見通しだ(表1)。Informatik社は、車載ネットワーク関連の開発・テストツール「CANoe」などで有力なツールベンダだ。OSEK/VDX準拠の組み込みOS「osCAN」や、CANの通信スタック「CANbedded」など、組み込みソフトウエアそのもののも提供している。日本法人ベクター・ジャパン組込ソフト部の櫻井剛氏は「当社は、AUTOSAR準拠のソフトウエア開発すべてをカバーする開発ツールと組み込みソフトウエア製品を提供している。自動車メーカーが市販車開発用の仕様として考えているリリース3.0に対応した製品を現時点で市場投入できているのは当社だけ。AUTOSARプラットフォームとして複数の自動車メーカーが採用している」と語る。Suite」と組み込みソフト「MICROSAR」に分けられる(図4)。Designer」、SWC内のタスク割付やRTEの生成を行う「Developer」がある。MICROSARでは、実績の高いCANbeddedやosCANのAUTOSAR対応製品をはじめ、すべてのBSWを提供できるという。「AUTOSARでは、段階的な移行を可能にするために、OSやCANドライバだけを利用することも可能になっている。いった顧客の求めに応じて、BSWをコンポーネント単位で販売することも可能だ」(櫻井氏)という。MCALについては半導体メーカーとの共同開発だけでなく独自に対応することもある。リリース3.0に対応していないMCALと、すでに3.0に対応している上位BSWとの統合などにも実績がある。SuiteとMICROSAR製品のセットだが、CANoeのパソコン接続インターフェースに対応するBSWも追加することで、実マイコンや評価ボードなどを使わずにパソコン上でAUTOSAR対応ソフトウエアの動作検証ができる。SNSfacebooktwitterITmediaはアイティメディア株式会社の登録商標です。