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

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

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

「AUTOSARカー」で実装評価

　JasParでは、AUTOSARをベースとしたJasPar仕様の策定のみならず、それらの実装評価も行っている。

　まず、BSWの評価基準を策定する活動において、モーター制御ECUについて、AUTOSARのリリース2.1とリリース3.0に準拠した車載ソフトウエアを開発し、その性能の評価を行った。リリース2.1の段階では、モーターの制御成立時間が85μs、必要なROM容量が40Kバイト、RAM容量が2.5Kバイトであった。これに対して、さらに仕様としての完成度が高まったリリース3.0では、モーターの制御成立時間が50μs、ROM容量が35Kバイト、RAM容量が0.7Kバイトと大幅な性能の向上とリソースの削減を実現することができた。しかし、JasPar仕様としての性能目標は、モーターの制御成立時間が50μs、ROM容量が10Kバイト、RAM容量が100バイトとなっている。安達氏は、「モーターの制御成立時間は達成できたが、メモリー関連は未達の状態。プロファイルとクラスタ化を導入することで、目標達成に近づけられる」と見ている。

　また、JasParのメンバーであるトヨタ自動車、日産自動車、本田技研工業は、2010年2月を目処に、AUTOSARのJasPar仕様に準拠した車載ソフトウエアを採用した「AUTOSARカー」を試作している。まず、トヨタ自動車は、「レクサスLS460」に、前方カメラと後方カメラをFlexRayで接続し、AUTOSARで動作させる安全システムを搭載する。日産自動車は、「フーガ」をベースに、FlexRayとAUTOSARを使って、モーターと電気信号だけでステアリング操作を可能にするステアリングバイワイヤーシステムを搭載する。本田技研工業は、「レジェンド」をベースに、AUTOSARで動作するACCシステムとメーターを搭載する。

　なお、これらのJasParの取り組みは、経済産業省から委託された2007年度〜2009年度の開発プロジェクトとなっている。

新たな開発プロセスの導入

　AUTOSARを導入する場合に、車載ソフトウエア開発の技術者が知りたいのは、現在の車載ソフトウエアの開発プロセスと比べて、何が変わるのか、何が必要になるのかについてであろう。

　デンソーとデンソークリエイトは、AUTOSARに対応する新たな開発プロセスとして、「アーキテクチャベース開発」を共同で開発した。

　現在の開発プロセスでは、最上流に機能構造の設計者が位置し、その下流に、制御ロジックの設計者、ネットワークシステム設計者、ECUソフトウエアの設計者、ECUソフトウエアの実装者が位置する。両社は、AUTOSARを導入した場合に、各技術者が抱えるであろう課題について検討した。その結果、以下のような事例が想定された。

　自動車メーカーで働く機能構造の設計者は、「SW-Cの記述において、ランナブル（Runnable）と呼ばれる関数レベルの単位まで定義することができることはわかっているが、システムレベルの構想段階でECUに搭載されるすべてのランナブルを定義するのは現実的に言って無理だろう」と考えている。これに対して、ティア1サプライヤのECUソフトウエア設計者は、「（実際には、機能構造の設計者はそこまでは無理だと考えているわけだが）仮にシステムレベルでランナブルの単位までの決定が行われると、ECUとして実現すべき性能が実現できない可能性がある。SW-CやランナブルなどのECUへの実装にかかわる部分の設計はわれわれに任せてほしい」と考えているというのである。デンソークリエイトでプロジェクトセンターデスクを務める小林展英氏は、「この事例が示すように、AUTOSARを現場へ導入する場合、システム設計から実装に至るまで、開発プロセスにおける各技術者の役割を明確にしておかなければ、『誰がどこまで設計すべきかわからない』という役割分担上の問題が発生する可能性が高い」と語る。

図5　アーキテクチャベース開発による開発プロセス（提供：デンソークリエイト）　画緑色の矢印に従って開発プロセスが進行し、最終的にはECUへのソフトウエア実装が行われる。

　そこで、アーキテクチャベース開発では、行（横）方向をアーキテクチャと振る舞い、列（縦）方向を機能開発、ネットワークシステム開発、ソフトウエア開発に分割した表を作成し、6つのプロセスとその流れを規定した（図5）。そして、各プロセスで行われる業務と必要なスキル、現在の技術者がどのプロセスを分担するかを決定した。そして、このアーキテクチャベース開発に従い、車載ソフトウエア開発を試行した。この試行は、既存のソフトウエアをAUTOSAR構造に合わせて再構築することを前提に行われた。その結果、制御モデル設計とネットワークトポロジ設計のプロセスについては、現在の技術者が有している技術だけでも、AUTOSARに対応できることがわかった。一方、機能アーキテクチャ設計、機能マッピングと通信設計、ソフトウエア構造設計、実装可能モデル設計のプロセスについては、AUTOSAR対応ツールやAUTOSARに関する専門知識が必要であることが明らかになった。

　この車載ソフトウエア開発の試行において、最も人月工数がかかったのが、ソフトウエア構造設計と実装可能モデル設計のプロセスである。「特に、各社が蓄積してきた実装ノウハウによって最適化してきた既存ソフトウエアのドライバ層を、AUTOSARで規格化された枠組みで再構築する必要があったため、苦労が多かった。なお、今後、AUTOSARが目指すソフトウエア部品としての再利用性を考慮すると、従来のアプリケーション層をどのような粒度で切り出したり取り扱ったりするのか、といったことも課題になってくるだろう」（小林氏）という。