種類 | 開発パートナーシップ |
---|---|
本社所在地 | ドイツ・ ミュンヘン(事務局) |
設立 | 2003年 |
業種 | 自動車業界 |
事業内容 | 自動車、E/E、ソフトウェア、半導体 |
代表者 |
|
従業員数 | 362社(2023年7月) |
外部リンク | http://www.autosar.org/ |
特記事項:活動地域:全世界 |
AUTOSAR(オートザー、英: AUTomotive Open System ARchitecture)は、2003年に発足した自動車業界のグローバル開発パートナーシップである。活動目的は、インフォテインメントを除く領域で、車載電子制御ユニット用の共通標準ソフトウェアアーキテクチャを策定、確立することである。さまざまな車種やプラットフォームに対応できる拡張性、ソフトウェアの可搬性、可用性への配慮、安全要求への対応、多種多様なパートナーとの協業、天然資源のサステナブルな利用、車両の「製品ライフサイクル」[1][2] 全般にわたる保守性などを目標とする。
AUTOSAR開発パートナーシップは2003年7月、自動車業界共通の標準E/Eアーキテクチャを開発・確立するため、BMW、ボッシュ、コンチネンタル、ダイムラー・クライスラー(当時)、シーメンスVDO(当時)、フォルクスワーゲンの各社が参画して発足した。 同年11月に フォードがコア・パートナーとして参加、さらに12月にはプジョー・シトロエンS.A.(当時)とトヨタ自動車が加わり、2014年11月にはゼネラルモーターズもコア・パートナーとなった[3]。2008年2月にシーメンスVDO がコンチネンタルに吸収された後、同社は単独のコア・パートナーではなくなっている[3]。
2003年以来AUTOSARは、Classic Platform向けに自動車業界標準ソフトウェアアーキテクチャを4回、またアクセプタンステスト1回のメジャーリリースを実施している。AUTOSARのClassic Platformの活動は、次の3つのフェーズに分類することができる:
AUTOSARコンソーシアムは業界標準の保守と改善のため、2013年から継続的な活動へと移行している(リリース4.2 およびアクセプタンステスト1.0のリリースを含む)。
2016年にはAdaptive Platformの活動が開始。2017年に最初のリリース(17-03版)が行われ、続いて同年10月に17-10版がリリース、2018年3月には18-03版がリリースされた。目標は2018年10月にAUTOSAR ClassicとAdaptive、Foundationの合同リリースを行い、主要な開発を収束させることである。
AUTOSARはBSW(Basic SoftWare)モジュールを記述する一連の仕様書を提供、アプリケーション・インタフェースを定義し、標準交換フォーマットに基づく共通の開発方法論(methodology)を構築する。BSWモジュールは、AUTOSARの階層的ソフトウェアアーキテクチャによって可能になり、メーカーごとに異なる車種やサプライヤーによって異なる電子部品でも利用できるため、研究開発費用を削減し、複雑化する一方の自動車業界の電子ユニットとソフトウェアアーキテクチャに対応できる[6]。この指針に基づき、AUTOSARは性能、安全性、環境適合性をさらに向上させるため革新的な電子システムを開発し、車両のライフサイクル全般にわたるソフトウェアとハードウェアの交換と更新に尽力してきた。AUTOSARはまた、次世代のテクノロジーに対応すると同時に、品質面で妥協することなくコスト効率の改善を目指す[7][1]。
AUTOSARのアーキテクチャは、次の3つの階層で構成されている[8]。
AUTOSAR Classic Platformは、OSEKをベースとした組込みリアルタイムECU向けの標準規格であり、主要な成果物は仕様書である。AUTOSAR Classic Platformアーキテクチャはマイクロコントローラ上で動作するソフトウェアを、アプリケーション、RTE、BSWの3つの抽象的なレイヤで区別する。アプリケーションソフトウェアの多くはハードウェア非依存である。またソフトウェアコンポーネント間の通信と、RTEを介したBSWへのアクセスはアプリケーションにとって完全なインターフェースを表している。BSWは以下の主要な3つの層と、Complex driversに区別される。
Servicesはさらに、システム、メモリ、通信のインフラを司る機能グループに区別される。
Classic Platformの重要なコンセプトの1つとしてVFB(Virtual Functional Bus)がある。ECU配置が特定していない抽象的なRTEセットが仮想バスであり、アプリケーションを物理的なインフラストラクチャから切り離すことができる。アプリケーションソフトウェア間の通信は特定のポートを介して行われるため、アプリケーションソフトウェアとこれらのポートをマッピングする必要がある。VFBはECU内とECU間の通信を対象としている。アプリケーション開発の視点では、下位層の詳細な知識を要求されてないため、ハードウェア非依存のアプリケーション開発が可能である。
Classic PlatformはFranca Interface Description Language(IDL)を使うことによってGENIVI等の 非AUTOSARのシステムと結合することも可能である。
新しいユースケースに対応するためAdaptive Platformの開発が行われた。代表例は運転者が一時的あるいは部分的に運転を車に任せる高度自動運転である。これには交通インフラ(例. 標識、信号)、クラウドサーバ(例.最新の交通情報や地図データへのアクセス)、並列処理を行うマイクロプロッセサや高性能コンピューティングハードウェア(例.GPU)が必要である。
Car-2-Xアプリケーションでは、車とオフボードシステムとの連携が必要である。これにはセキュアオンボード通信、クロスドメインコンピューティングプラットフォーム、スマートフォン連携、非AUTOSARシステムとの結合などが必要になる。
またクラウドベースのサービスには、クラウドとのやりとりや、緊急車両の運行支援など、セキュリティの専用手段が必要である。これらはリモート診断やOTA(Over The Air)によるソフトウェア更新、修理交換支援などのリモート分散サービスを可能にする。
アプリケーションの動的な配置と、ハイエンドな計算パワーを要するアプリケーション向けの環境を提供するために、AUTOSARは現在AUTOSAR Adaptive Platformの標準化を進めている。その中核となるのはPOSIX標準である。オペレーティングシステムはIEEE1003.13(PSE51)に従いPOSIXのサブセットを介してアプリケーションから使用することができる。
Adaptive Platformの主要機能はサービス指向通信である。
Adaptive Platformではサービス(Services)とアプリケーションプログラミングインターフェース(APIs)の2種類のインターフェースが使用できる。プラットフォームはFunctional Clustersと呼ばれる機能グループで構成されており、Functional ClustersはServicesとFoundationにグループ分けされる。
Functional Clustersの定義は以下:
AUTOSAR Adaptive Platform FoundationにおけるFunctional Clustersは(仮想)マシン毎に少なくとも1つのインスタンスを持つ必要があるが、Servicesは車内のネットワークに分散させることができる。
Adaptive PlatformのServicesには以下が含まれる。
AUTOSAR Adaptive Platformの成果物は仕様書とコードの両方が含まれている。Classic Platformと比較して検証サイクルの短縮と、基本的なコンセプトを説明するためにコードを実装開発している。 この実装はすべてのAUTOSARパートナーが利用可能である。
Foundationの目的はAUTOSARプラットフォーム間の相互運用性を促進することである。FoundationにはAUTOSARプラットフォーム間の共通要件、共通のMethodology、プラットフォーム間で共有すべき技術仕様(例.プロトコル)が含まれる。
AUTOSARアクセプタンステストは、テストの手間とコストを最小化するため2014年に導入された。アクセプタンステスト仕様書は、アプリケーションとバスからアクセスする前提のシステムテスト仕様書である。標準アクセプタンステストの仕様書があれば、時間とコストの削減が可能である[12]。
AUTOSARの技術目標達成の基盤になるのは、メーカーとサプライヤー間の機能的インタフェースの標準化と、異なるソフトウェア層の間のインタフェース標準化である[13]。
AUTOSARの会員(partners)は以下の6種類に分類している。会員の貢献は会員の分類により異なる[14]。
中核会員は、発足時からの会員である BMW、ボッシュ、コンチネンタル、ダイムラー、フォード、ゼネラルモータース、グループPSA(プジョー・シトロエン)、トヨタ自動車、フォルクスワーゲンの各社である[15]。中核会員は、組織の運営、管理、AUTOSAR 開発会員制度の統制に責任をもつ。[14][16]理事会(Executive Board)はこの中核会員によって構成され、総合的な戦略と計画表(roadmap)を決定する。運営委員会(Steering Committee)は、技術面以外の部分での日常業務、会員企業の入会、広報、各種契約業務などを行う[17]。会長(Chairman)は9か月ごとに交代し運営委員会の代表として対外的な意思疎通を担当する。
上級会員(premium partner)と開発会員(development partner)は作業文書(work package)を作る。作業文書は、中核会員が選出した事業指導者班(project leader group)が調整と監視を行う。準会員はAUTOSARが発行した標準文書を使用できる。参加者は現在、学術的な共同作業や非営利事業に参加している[14][18]。
2020年5月時点で、200社以上の企業がAUTOSAR会員制度に参加している[19][20]。
上記組織欄には国内のAutosar加入組織の開発ツールを付記している。ここでは海外の開発ツールとその開発元・提供元を一覧にする。
JASPAR(Japan Automotive Software Platform and Architecture)が日本国内でAUTOSARについての情報交換をしている。2014年11月19日「JASPAR提案仕様(通称:プロファイルコンセプト)のAUTOSAR採用結果」[21]を公表している。また、機能安全関連文書も公表している[22]。
名古屋大学大学院情報学研究科附属組込みシステム研究センター(NCES)では、2011年度から2013年度の3年間、複数企業とともに、AUTOSARプラットフォームの開発を行い、開発したプラットフォームは、TOPPERSプロジェクトから無償で一般公開されている[23]。 2014年度からは、後継プロジェクトとして、APコンソーシアムを開始し、機能安全規格対応や、BSWモジュールの拡充等を行っている[24]。
TOPPERSプロジェクトでは、日本国内でのAUTOSAR仕様に関する情報サイトとして、AUTOSAR情報サイトを運用している[25]。