TechEyes

2021/02/17

車載ソフトウェアの標準化~AUTOSAR

近年、車両システムの高度化に伴い、自動車に搭載されるECU※1の数は増加の一途です。高級車種では100個以上のECUが搭載されているようです。ECUに実装されるソフトウェアの規模が比較的小さいECUでは開発期間やコストはそれほど大きな課題とは捉えられていないと思います。それでも、多くの品種を開発するようになると、ソフトウェアの開発費を含めた効率化の向上が必要となってきます。また、ECUの品質面では、市場で発生した不具合の中でソフトウェアが起因となっている事例が増えてきたと思われます。これらの課題に対してソフトウェアの設計標準化が一つの解決策です。標準化されたソフトウェアを流用することで開発費を抑制でき、市場実績により品質の安定化が図られます。従来、開発してきたソフトウェアは自動車メーカやサプライヤが独自に開発してきたプラットフォーム※2で製作されていると思われます。しかし、昨今の自動車には、安全性や利便性向上のために様々な機能が追加されるようになり、ECUのソフトウェア開発規模や複雑さが増大し、また多くの機能を一社で開発することは難しくなってきました。そのため、開発期間やコストの抑制、品質の安定化が急務となっていました。

このような背景から欧州において自動車のソフトウェアを標準化するAUTOSARが設立され活動が始まりました。本稿ではAUTOSARの歴史や利点、体系などを概説します。特に仕様(クラシックプラットフォームやアダプティブプラットフォームの基本的な考え方)についてはわかり易い言葉を選んで説明しました。最後に日本の動向を述べ、関連製品(ソフトウェアツール)を紹介します。
《本稿の記述は、筆者の知見による解釈や、主観的な取り上げ方の面もあることをご容赦ください。また、本稿に記載されている情報は、当社および第三者の知的財産権他の権利に対する保証または実施権を許諾するものではありません。》

※1

(Electronic Control Unit)エンジンやブレーキ、通信機器を制御するユニット

※2

ソフトウェアの基本構成

AUTOSARとは

AUTOSAR(AUTomotive Open System Architecture、オートザーの呼称が一般的)は、自動車メーカや部品サプライヤの他、電機業界、半導体業界、ソフトウェア業界などで構成される団体です。また、ソフトウェアの共通化を図るための仕様の総称でもあります。このことから、ソフトウェアプラットフォームとも言われています。

AUTOSARの歴史

2002年に検討チームが設立され活動がスタートしました。構成される組織はパートナーシップの定義により参加形態が異なっています。パートナーシップについては「AUTOSARの会員制度」の章で説明します。当初の参加企業はコアパートナと定義されています。BMW、ボッシュ、コンチネンタル、ダイムラークライスラ(後にダイムラー)、フォルクスワーゲンです。直ぐにシーメンスVDOが参画しました(2007年にコンチネンタルが買収)。その後、2003年にFORD、PSA、トヨタが、2004年にGMがコアパートナとして参画しました。現時点のコアパートナは9社です。

2003年7月にAUTOSARの最初のドラフトが公開されました。内容については後ほど説明します。また、最初の会員加入が承認されました。同年9月にAUTOSARにとって最初の公式発表がなされ、以降、仕様の改版、各地でのカンファレンスの開催(2010年には東京で開催)などが行われています。2017年には新たな仕様としてアダプティブプラットフォームが公開されました。この時に最初の仕様をクラシックプラットフォームとして定義しアダプティブプラットフォームと区別されました。アダプティブプラットフォームの内容は「AUTOSARの仕様」の章で後述します。AUTOSARに準拠したECUを最初に搭載した車両は2008年に市場で販売されたと言われています。

AUTOSARの会員制度

AUTOSARの会員(partner)は6種類です。各会員の役割や条件を表1にまとめました。

表1 AUTOSARの会員
会員分類 役割 参加数(2021年1月時点)、条件
中核会員(core partners) 組織の運営、管理 9社
BMW、ボッシュ、コンチネンタル、
ダイムラー、フォード、ゼネラルモータース、
PSA(プジョー・シトロエン)、トヨタ、
フォルクスワーゲン
戦略会員(strategic partners) 中核会員、上級会員、開発会員と協力して
標準類を作成
1社
デンソー
上級会員(premium partners) 中核会員および開発会員と協力して標準類を作成 44社/団体
年会費21,000ユーロ、工数の貢献
(年会費、工数に条件あり)
開発会員(development partners) 中核会員および上級会員と協力して標準類を作成 56社/団体
年会費6,000ユーロ、工数の貢献
準会員(associate partners) AUTOSARが発行した標準文書を使用 142社/団体
年会費15,000ユーロ
参加者(attendees) 標準類の策定に参画 26団体(主として大学)

AUTOSARの狙い

スローガンとして「Cooperate on standards, compete on implementation」を掲げています。「標準化において協力し、実装において競争する」でしょうか。AUTOSARの狙いは、自動車メーカとサプライヤ間で、ソフトウェアの再利用と互換性を高めることで、電気・電子アーキテクチャの複雑さの管理を改善することとされています。例えば、ある車両制御用のソフトウェアモジュールを自動車メーカの車両間で流用できたり、自動車メーカ間、サプライヤ間同士で流用できるようにすることです。これを実現するために、ECUのソフトウェアアーキテクチャ※3を標準化することです。

※3

ソフトウェアの構築方式

AUTOSARのターゲット市場

AUTOSARの主なターゲットは、輸送を目的とした車両です。また、自動車業界と関係のないアプリケーション、例えば鉄道車両、船舶、農業機械、建設機械、発電機、家電なども想定しています。なお、航空・宇宙、原子力、化学、石油化学、軍事などへの適用は除外されています。事業の観点、いわゆるビジネスモデルについては言及していません。あくまでも、技術の観点で活動し仕様を公開しています。

AUTOSARのメリット

基本的なメリットは設計やソフトウェアを標準化することにより、再利用性が向上することです。その結果、開発コストを下げることが可能になります。また、車両全体でもサプライヤ間での再利用性が可能になるため、コスト削減につながるメリットがあります。AUTOSARでは各企業に対するメリットを次のように強調しています。

1)車両メーカにとって

  • サプライヤ間の開発分配が可能になる。
  • 設計の柔軟性を高めて、革新的な機能を競うことができる。
  • ソフトウェアとシステムの統合を簡素化できる。
  • ソフトウェア開発全体のコストを削減できる。

2)サプライヤにとって

  • バージョンの急増を削減できる。
  • OEM間でソフトウェアモジュールを再利用できる。
  • アプリケーション開発を効率化できる。
  • 新しいビジネスモデルが可能になる。

3)ツールメーカにとって

  • 開発プロセスとのインタフェースが可能になる。
  • ツールをツール環境全体に組み込むことができる。

4)新規参入企業にとって

  • 標準化されたインタフェースにより新しいビジネスモデルが可能になる。

AUTOSARの仕様

本章では基本的な考え方を概説します。記載されている技術用語や詳細な技術内容については、AUTOSARのサイトや他の刊行物等の情報源を参照してください。AUTOSARの仕様は大きく分けて2つのプラットフォームについて仕様化されています。設立時点で定義されたクラシックプラットフォームと2017年に公開されたアダプティブプラットフォームがあります。

先ず、AUTOSARプラットフォームの基本的な考え方を説明します。従来型のECUでは搭載されているマイクロコンピュータをはじめとしたハードウェアと複雑に絡まったソフトウェア構造となっています(図1)。AUTOSARは、ハードウェアの依存性をソフトウェア側から見ると隠蔽化します。また、車両を制御するアプリケーションをAUTOSARの標準仕様で設計することで、流用性を高めています。ハードウェアが変更された場合はハードウェアに依存したインタフェースを適合させれば、互換性が保たれることになります。さらに、アプリケーションがAUTOSARに準拠して設計されていれば、他のシステムへの移植が可能となります。なお、AUTOSARではソフトウェア設計に関する仕様だけでなく、開発の方法論(AUTOSARではMethodology)やテスト仕様についても定義されています。

図1 従来ECUとAUTOSARとの比較
図1 従来ECUとAUTOSARとの比較

出典:AUTOSARの資料を元に作成

次に、クラシックプラットフォームとアダプティブプラットフォームの概要を説明します。アダプティブプラットフォームが公開された際、当初のAUTOSARをクラシックプラットフォームと呼ぶようになりました。また、Foundationと定義される共通部分もこのタイミングで定められました。Foundationについては「標準類の体系」の章で概説します。

1)クラシックプラットフォーム

クラシックプラットフォームは図2に示すとおり、階層化構造となっています。各層はマイクロコントローラ側から基本ソフトウェア(Basic Software(BSW))、ランタイム環境(Runtime Environment(RTE))、アプリケーション層(Application Layer)です。

図2 クラシックプラットフォームの階層構造
図2 クラシックプラットフォームの階層構造

出典:AUTOSARの資料を元に作成

Application LayerはECUの機能を実現するソフトウェアの集合体です。RTEはアプリケーション層と基本ソフトウェア(BSW)とのインタフェースをつかさどります。よって、ECUが変わっても、アプリケーションを再利用することが可能となります。BSWはECUの基本ソフトの土台となる部分です。色々なECUと共通化ができます。BSWをさらに精緻化すると図3となります。

図3 BSWの構造
図3 BSWの構造

出典:AUTOSARの資料を元に作成

BSW内各層の役割は表2の通りです。

表2 BSW内の各層
BSW内の各層 目的
Service Layer BSW層で最上位のソフトウェア。OS機能、車両ネットワーク通信、不揮発性メモリの管理、故障診断などをつかさどる。
ECU Abstraction Layer マイクロコントローラ内の資源の制御、マイクロコントローラ外の機能に対する制御を行い、上位層のソフトウェアをECUのハードウェアに依存させないようにする。
Microcontroller Abstraction Layer マイクロコントローラに内蔵されている機能などを直接操作するソフトウェア。上位層のソフトウェアをマイクロコントローラに依存させないようにする。一般的にMCALと呼ばれている。
Complex Drivers センサやアクチュエータをタイミングなどの特殊な操作を行うため、他の層で扱えないマイクロコントローラを直接操作する。AUTOSAR対応でない既存のソフトウェアを実装することもある。

2)アダプティブプラットフォーム

自動車を取り巻く環境が急速に変化し、高度な自動運転、外部との通信、IoTやクラウドサービス、処理デバイスの進化、セキュリティなどへの対応が求められてきました。そのために、従来のAUTOSARを継承しつつ新たなプラットフォームとしてアダプティブプラットフォームが定義されました。最初の公開は2017年です。アプリケーションとしてはADAS(Advanced Driver-Assistance Systems 先進運転支援システム)を想定しています。アダプティブプラットフォームは3つの特徴があります。

1. 安全・安心

ECU内の通信だけでなく、車両内や車両外部との通信を安心・安全に行えるようにする。

2. 接続性

ECUと関係する色々な接続をサポートする。

3. 動的・更新可能

ECUのソフトウェアを通信などで経由して更新できるようにする。

アダプティブプラットフォームと比較するためにクラシックプラットフォームの特徴をあらためてまとめました。

機能安全対応

  • ウォッチドッグなどの成熟した安全機能
  • QMからASIL Dまで対応

効率性

  • AUTOSAR対応のソフトウェアモジュールがさまざまなサプライヤから提供されている。
  • 幅広いマイクロコントローラがサポートされているので開発費を抑制できる。

市場で実績

  • 長年の適用により成熟している。
  • 広範なアプリケーションで実装されているので高品質である。
  • 開発プロセスが確立されている。

パフォーマンス性

  • リアルタイム性が高い。
  • イベントトリガーアプリケーションに適している。
  • 幅広いプロトコルとネットワークをサポートする柔軟性がある。
  • 構成変更がしやすい。

標準類の体系

AUTOSARの標準類は以下の体系で構成されています。標準類についてはAUTOSARのサイトで閲覧することが可能です。クラシックプラットフォームに関連する文書だけでも数万ページ以上あるようです。

図4 AUTOSARの文書体系
図4 AUTOSARの文書体系

1)受入テスト

AUTOSARの機能をテストする要件を定めています。個々のECUでテスト仕様を定めてテストするのではなく、共通の仕様でソフトウェアの受入テストを実施することで、テスト仕様の策定や時間の削減につながるとともに、ソフトウェア品質の向上につながります。

2)アプリケーションインタフェース

ソフトウェアの再利用性を実現するためのインタフェース仕様を定義しています。アプリケーションの仕様そのものについてはAUTOSARでは扱いません。

3)共通仕様(Foundation)

クラシックプラットフォームとアダプティブプラットフォームとは完全に独立した仕様ではありません。実際の車両では両方の仕様で設計されたECUがCANなどのネットワークに接続されます。そのためにはネットワークの仕様に準拠することが必要となります。そこで、ネットワークなど共通部分を仕様化したものがFoundationです。

日本におけるAUTOSARに関する動向

AUTOSARの生い立ちが欧州のため、市場実績は欧州のソフトウェアサプライヤが主です。海外の有力なベンダとしては、VECTOR(ベクター ドイツ 独立系)、Elektrobit(エレクトロビット ドイツ コンチネンタル系列)、Mentor(メンター シーメンス系列)、ETAS(イータス ボッシュ系列)、KPIT(インド 独立系)などです。日本では、JASPAR※4がAUTOSARへ仕様の提案を行い採用されていますが、日本のソフトウェアサプライヤがAUTOSARを供給した実績はそれほど多くありません。今のままでは海外系サプライヤに寡占されかねないと危惧されます。現時点の国内サプライヤに関する状況を表4にまとめました。

※4

(Japan Automotive Software Platform and Architecture)自動車メーカやサプライヤなどが参加し、車載ネットワーク、ソフトウェア、情報セキュリティに関連する標準化を推進する一般社団法人。ジャスパーの呼称が一般的。

表3 日本のAUTOSAR関連のサプライヤ
事業体 APTJ系 SCSK系 オーバス系
設立年月 2015年9月 2015年10月QINeS-BSWの提供開始※5 2016年4月
企業情報 名古屋大学発のスタートアップ企業:富士ソフト、キャノンITS、サニー技研、東海ソフトなど SCSK、豆蔵、キャッツなど 3社の出資:デンソー(51%出資)、イーソル、NEC通信システム
サービス概要 AUTOSARに準拠したJulinar※5などによるサービス AUTOSARに準拠したソフトウェア(QINeS-BSW)などを中心としたサービス AUTOSARに準拠したソフトウェア開発などのサービス
※5

JulinarおよびQINeSは各企業の登録商標です。紹介した企業、事業内容については各社のサイトで確認してください。

関連製品(ソフトウェアツール)の紹介

AUTOSARに対応したECUのソフトウェア開発環境の製品例です。各製品の仕様はカタログで確認ください。

ETAS製 COSYM
仮想シミュレーション環境
ETAS製 COSYM 仮想シミュレーション環境
dSPACE製 TargetLink
AUTOSAR対応モジュール
dSPACE製 TargetLink AUTOSAR対応モジュール

製品カタログ(会員限定)

おわりに

欧州の自動車メーカやサプライヤは以前から製品によってはAUTOSARの準拠を要求していますが、日本国内の自動車メーカやサプライヤでは、独自の手法でソフトウェアを開発してきた経緯があるので、AUTOSARの普及が遅れていると思われます。しかしながら、機能安全規格(ISO26262)やサイバーセキュリティへの対応、高機能で大規模なソフトウェアを開発するためには標準化されたソフトウェアプラットフォームの対応が必要になると推察できます。本稿で述べた通り、AUTOSARを適用することは解決策の一つになると言えます。

ただし、AUTOSARは標準規格であって製品ではないのでソフトウェアの実装面ではハードウェアに依存する面もあること、ECUの機能や規模によっては最適解にならないかもしれないこと、今後も技術進化や市場実績のフィードバックなどにより仕様が変化していくことなどの認識と対応が必要でしょう。


自動車関連の他の記事はこちらから