AUTOSARについて、まとめてみた

公開日: 2024/12/2

AUTOSAR(オートザー)とは、Automotive Open System Architectureの略称で、車載ソフトウェアの共通化を実現するためのプラットフォームの仕様名称でもあります。

1. AUTOSARが生まれた背景


自動車に搭載されるシステムは年々高度化し、ソフトウェアの大規模化・複雑化が進みました。

特にECU(Electronic Control Unit)の搭載が決まった1980年代初頭は車1台あたり2~3個のECUが搭載される程度でしたが、現在では100個以上搭載されていることも珍しくありません。



現在の自動車開発では、新規開発の80%にソフトウェアが深く関与していると言われています。

自動車開発におけるソフトウェアの規模や重要性がますます大きくなっており、現在の自動車業界ではソフトウェア開発が主戦場となっています。


ソフトウェアへの重要度が高まっている現状において、新たな要求に対応するためにソフトウェア開発の規模は増大する一方です。

しかし、開発人数を増やすことは難しく、仮に増やせたとしてもコミュニケーションには限界があり、人海戦術ではいずれ対処が難しくなります。


この問題を解決するためには、自動車業界全体が一丸となって取り組むことが必要です。

過去のソフトウェア資産を有効活用することで、可能な限り開発コストを縮小させていくことが求められます。


その対処のカギとなるのが、過去のソフトウェア資産を「再利用」し、開発工程の「自動化」を進めること、およびその再利用や自動化を進める為に不可欠な「標準化」です。

これらの実現を目的として、2003年にAUTOSARが発足しました。

現在では、AUTOSARにはほぼ全ての自動車関連企業が参加しています。


AUROSARは2008年頃から広く量産車に採用されており、現在では欧州での新規開発では殆どの場合に採用されています。

日本国内の開発においても、採用する動きが活発化しています。


また、静的OS(OSEK/VDX OSベース)を用いた企画であるClassic Platform(CP)に加え、2017年には動的OS(POSIXベース)を用いたAdaptive Platform(AP)も公開されるなど、自動車開発においてAUTOSARの役割はますます重要なものとなっています。

2. AUTOSARによる標準化


従来の開発では、ハードウェアに応じてアプリケーションを大きく変える必要がありました。

つまり、自動車メーカーが変わると、上に乗せるアプリケーションも合わせて変える必要があります。


しかし、アプリケーションとハードウェアの間にAUROSARに準拠した車載ソフトウェアがあれば、ハードウェアに合わせてアプリケーションを変える必要がなくなります。

それによってアプリケーションの再利用が可能になり、効率的な開発を実現することができます。

これが、AUTOSARによるソフトウェアの標準化です。


標準化によって、以下のようなメリットがあります。

 ・アプリケーション間(ECU内、ECU間)で通信プロトコルを意識せずに連携可能

 ・OEMとECUサプライヤの役割分担を明確化し、連携・分業しやすくなる

このようなメリットが、結果として車載ソフトウェアの開発工程の削減に繋がります。


AUTOSARでは目的を定めており、それらはAUTOSARのパートナーに加入する際の契約にも記載されています。

その内容は随時見直されていますが、2020年に見直された現在の目的は以下となっています。


 1. ソフトウェアの授受の支援

 2. 異なるアーキテクチャやハードウェアのバリアントに対するスケラービリティの確保

 3. 広い範囲のドメインへの対応(ドメイン非依存)

 4. 自動車ソフトウェアにおける、オープンアーキテクチャの1つを定義

 5. ディペンダブルシステム開発の支援

 6. パートナー間のコラボレーションの実現

 7. 適用可能な、自動車関連の国際規格や到達技術状況(state of the art)の技術への対応支援

 8. Non AUTOSARシステムとのデータ交換への対応


内容のポイントとして、AUTOSARの規格は、処理性能の限界を引き出すための個別最適化は含まれず、汎用性を相対的に重視したソフトウェアアーキテクチャとなっています。

また、高い汎用性を実現するために、BSW(Basic Software)の設定項目は非常に多く、全ては覚えられないためツールによる補助が不可欠です。

3. AUTOSARを構成する企業・団体


AUTOSARへ加入し車載S/Wの標準化を進める中核企業・団体について紹介します。

また、5つの会員ランク別の役割についても解説します。

1.Core Partner (コアパートナー)

Core Partner (コアパートナー)とは、AUTOSARを設立時から支えており、標準化の定義をする中心企業のことです。

トヨタをはじめ、BMWやフォードなど世界トップクラスの自動車メーカーおよびコンチネンタル(Continental)やボッシュ(BOSCH)などエンジニアリング企業が中心となり、9社が加入しています。

2.Premium Partner Plus (プレミアムパートナープラス)

Premium Partner Plus (プレミアムパートナープラス)とは、標準化推進をサポートする企業のことです。

現在、DENSOとVECTORの2社が加入しています。

3.Premium Partner (プレミアムパートナー)

Premium Partner (プレミアムパートナー) とは、コアパートナー・開発パートナーと協力しAUTOSAR標準の設計し、使用する企業のことです。

VOLVO・NISSANなどの自動車メーカーやPanasonicなどの電機メーカー、HUAWEIなどの電子機器メーカーなどを中心に58社が加入しています。

4.Development Partner (開発パートナー)

Development Partner (開発パートナー) とは、AUTOSAR規格を定義するために、コアおよびプレミアム パートナーと協力する企業のことです。

現在、名古屋大学のNCESなど76社が加入をしています。

5.Associate Partner (加入パートナー)

Associate Partner (加入パートナー) とは、AUTOSAR がすでにリリースしている標準仕様を使用する企業のことです。

富士通や三菱、YAMAHAをはじめ、159社が加入しています。

6.Attendee (出席者)

Attendee (出席者) とは、AUTOSAR規格の定義をサポートする大学や非営利団体のことです。

大学や研究所など37の団体が加入しています。

7.AUTOSAR Classic Platform(CP)とAUTOSAR Adaptive Platform(AP)の違い

AUTOSARでは、静的OS(OSEK/VDX OSベース)を用いた規格Classic Platform(CP)に加えて、2017年に動的OS(POSIXベース)を用いたAdaptive Platform(AP)が公開されました。

従来の静的なOSをベースとしたCPでは実現が難しい、次世代自動車向けのプラットフォームが動的OSをベースにしたAPです。

APはCPの上位バージョンではありません。

それぞれ適材適所によって使い分けされるプラットフォームです。

よって、APの登場によりCPがなくなるというわけではありません。

4. AUTOSAR Classic Platform (CP)とソフトウェア構成


CPは静的なOSEK/VDX OSベースになっており、リアルタイム性が求められるが、計算能力はそれほど必要とされないECU用のソフトウェアプラットフォームです。

S/Wは上から順番に「Application Layer」「Runtime Environment(RTE)」「Basic Software(BSW)」の3つのレイヤー(層)で分かれています。

1.Application Layer

Application Layerは、ライトやワイパーなど、それぞれのECUに応じた様々なアプリケーションを配置します。

2.Runtime Environment(RTE)

Runtime Environment(RTE)は、上記アプリケーションと下記基本ソフトウェア(BSW)を接続する役割を担っています。

3.Basic Software(BSW)

Basic Software(BSW) は、ECUの基盤となる基本ソフトウェアで、様々な機能を提供する役割があります。さらに、「Basic Software」は4つの領域に分けられ、ハードウェアを段階的に抽象化します。

 ・Services Layer

  Services Layer は、BSWの最上位のレイヤーで、基本的なサービスと基本ソフトウェアモジュールをアプリケーションに提供することが役割です。

  具体的には、OSやネットワーク、ECUの状態管理などの機能を提供しています。


 ・ECU Abstraction Layer

  ECU Abstraction Layerには、下記のMCALのインターフェースとしての役割があります。

  ECUのH/W構成を抽象化し、周辺機器・デバイスへのアクセスを担うレイヤーです。


 ・Microcontroller Abstraction Layer(MCAL)

  Microcontroller Abstraction Layer(MCAL)は、デバイスドライバーとして、外部デバイスに直接アクセスするためのソフトウェアモジュールです。

  マイコンの抽象化によりペリフェラル(周辺装置)の違いを吸収し、上位ソフトウェアレイヤーがマイコンに依存しないようにするためのレイヤーです。


 ・Complex Drivers

  Complex Driversは、他レイヤーに分類できない機能や高いレスポンスを求められる場合に使用されるレイヤーです。

  上位レイヤーから直接マイコンにアクセスできる役割を担っています。

5. AUTOSAR Adaptive Platform (AP)とソフトウェア構成


APは動的なPOSIXベースで、演算能力が高いという特徴があります。

そのため、自動運転などに活用されることが多く、世界トップクラスの自動車メーカーなどで採用されています。

構成は、「Machine/Hardware」の上に「AUTOSAR Runtime for Adaptive Application(ARA)」があり、そこに「User Application」が載っているという形です。

1.Machine/Hardware

Adaptive Platformを動作させる部分。

2.AUTOSAR Runtime for Adaptive Application(ARA)

様々なアプリケーションを適切にシステムに統合するためのインターフェースが複数用意されています。

ここには、ユーザーはネットワークマネージメントなどの基本的なサービスへのアクセスやECUを最大限に活用するためのメカニズムが用意されています。

3.User Application

ARAに乗る形で用意されています。

APに準拠したApplicationと、準拠していないものの2種類に対応しています。

6. AUTOSARの導入方法


AUTOSARの導入にはいくつかの方法があります。

ひとつは、AUTOSARのパートナーシップと連携し導入する方法です。

その他に、サードベンダー製のAUTOSARコンフィギュレーションツールを使用し、車載システムを開発しているサプライヤと連携する方法もあります。

7. まとめ

AUTOSARは、車載ソフトウェアの共通化を実現するためのプラットフォームです。

開発方法・アプリケーションインターフェース・レイヤードアーキテクチャの3つを標準化し提供しています。

これにより、異なるメーカー、サプライヤ、開発者間でのソフトウェアの相互運用性が改善され、コストの削減や開発効率の上昇が期待されています。


車載ソフトウェア開発を行うにあたっては、今後、必要な知識となるので、備えておきましょう。