AUTOSAR

AUTOSAR（オートザー、AUTomotive Open System ARchitecture）は、2003年に発足した自動車業界のグローバル開発パートナーシップである。活動目的は、インフォテインメントを除く領域で、車載電子制御ユニット用の共通標準ソフトウェアアーキテクチャを策定、確立することである。さまざまな車種やプラットフォームに対応できる拡張性、ソフトウェアの可搬性、可用性への配慮、安全要求への対応、多種多様なパートナーとの協業、天然資源のサステナブルな利用、車両の「製品ライフサイクル」 全般にわたる保守性などを目標とする。
AUTOSARの正式名称にOpenがあることから誤解を招いているが、AUTOSARへの対応を謳う場合および、AUTOSAR仕様に基づいた実装をしたものを商用利用する際はAUTOSARへのライセンス料の支払いもしくは団体への所属が必要となる。

**経緯**
AUTOSAR開発パートナーシップは2003年7月、自動車業界共通の標準E/Eアーキテクチャを開発・確立するため、BMW、ボッシュ、コンチネンタル、ダイムラー・クライスラー（当時）、シーメンスVDO（当時）、フォルクスワーゲンの各社が参画して発足した。 同年11月に フォードがコア・パートナーとして参加、さらに12月にはプジョー・シトロエンS.A.（当時）とトヨタ自動車が加わり、2014年11月にはゼネラルモーターズもコア・パートナーとなった。2008年2月にシーメンスVDO がコンチネンタルに吸収された後、同社は単独のコア・パートナーではなくなっている。
2003年以来AUTOSARは、Classic Platform向けに自動車業界標準ソフトウェアアーキテクチャを4回、またアクセプタンステスト1回のメジャーリリースを実施している。AUTOSARのClassic Platformの活動は、次の3つのフェーズに分類することができる：- 第1フェーズ（2004 - 2006年）：標準の基礎開発（リリース1.0、2.0、2.1）- 第2フェーズ（2007 - 2009年）：アーキテクチャとメソドロジー標準の拡張（リリース3.0、3.1、4.0）- 第3フェーズ（2010 - 2013年）：保守と部分的な改善（リリース3.2、4.1、4.2） 
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の階層的ソフトウェアアーキテクチャによって可能になり、メーカーごとに異なる車種やサプライヤーによって異なる電子部品でも利用できるため、研究開発費用を削減し、複雑化する一方の自動車業界の電子ユニットとソフトウェアアーキテクチャに対応できる。この指針に基づき、AUTOSARは性能、安全性、環境適合性をさらに向上させるため革新的な電子システムを開発し、車両のライフサイクル全般にわたるソフトウェアとハードウェアの交換と更新に尽力してきた。AUTOSARはまた、次世代のテクノロジーに対応すると同時に、品質面で妥協することなくコスト効率の改善を目指す。

**ソフトウェアアーキテクチャ**
AUTOSARのアーキテクチャは、次の3つの階層で構成されている。- BSW（Basic SoftWare）：上層ソフトウェアの機能を動かすための必須サービスを提供する標準ソフトウェアモジュール。ほとんどの場合、BSWには上層ソフトウェアに見られるような機能は存在しない。- RTE（Run Time Environment）：アプリケーションソフトウェアのECU内、ECU間通信をネットワークトポロジーに依存せず抽象化するための中間層。- アプリケーション層：アプリケーションソフトウェアのコンポーネント。RTEとやりとりを行う。

**AUTOSAR方法論（methodology）**
 システム設計情報： 全システムの情報を含む。情報は異なるECU間で一致していなければならない（バス信号の定義など）。- ECUエクストラクト情報： システム設計情報から特定のECU に関する部分を抽出した情報（特定のECUが利用する信号など）。- ECU構成（configuration）情報： 特定のECU内のBSW設計情報の全て。実行可能なソフトウェアは、この情報に加え、BSWモジュールのコードと、ソフトウェアコンポーネントのコードからビルドすることができる。

**Classic Platform**
AUTOSAR Classic Platformは、OSEKをベースとした組込みリアルタイムECU向けの標準規格であり、主要な成果物は仕様書である。AUTOSAR Classic Platformアーキテクチャはマイクロコントローラ上で動作するソフトウェアを、アプリケーション、RTE、BSWの３つの抽象的なレイヤで区別する。アプリケーションソフトウェアの多くはハードウェア非依存である。またソフトウェアコンポーネント間の通信と、RTEを介したBSWへのアクセスはアプリケーションにとって完全なインターフェースを表している。BSWは以下の主要な3つの層と、Complex driversに区別される。- Services- ECU abstraction - Microcontroller abstraction
Servicesはさらに、システム、メモリ、通信のインフラを司る機能グループに区別される。
Classic Platformの重要なコンセプトの１つとしてVFB（Virtual Functional Bus）がある。ECU配置が特定していない抽象的なRTEセットが仮想バスであり、アプリケーションを物理的なインフラストラクチャから切り離すことができる。アプリケーションソフトウェア間の通信は特定のポートを介して行われるため、アプリケーションソフトウェアとこれらのポートをマッピングする必要がある。VFBはECU内とECU間の通信を対象としている。アプリケーション開発の視点では、下位層の詳細な知識を要求されてないため、ハードウェア非依存のアプリケーション開発が可能である。
Classic PlatformはFranca Interface Description Language（IDL）を使うことによってGENIVI等の 非AUTOSARのシステムと結合することも可能である。

**Adaptive Platform**
新しいユースケースに対応するため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の定義は以下：- Adaptive Platformの機能をアセンブル- クラスタリング毎にRequirements Specification（RS）を定義- アプリケーションとネットワークの観点でソフトウェア・プラットフォームの振る舞いを規定- ただし、最終的なソフトウェア設計は制約しない
AUTOSAR Adaptive Platform FoundationにおけるFunctional Clustersは（仮想）マシン毎に少なくとも1つのインスタンスを持つ必要があるが、Servicesは車内のネットワークに分散させることができる。
Adaptive PlatformのServicesには以下が含まれる。 - Update and Configuration management（ソフトウェアの更新管理）- State Management（状態管理）- Network Management（ネットワーク管理）- Diagnostics（診断）
AUTOSAR Adaptive Platformの成果物は仕様書とコードの両方が含まれている。Classic Platformと比較して検証サイクルの短縮と、基本的なコンセプトを説明するためにコードを実装開発している。 この実装はすべてのAUTOSARパートナーが利用可能である。

**Foundation**
Foundationの目的はAUTOSARプラットフォーム間の相互運用性を促進することである。FoundationにはAUTOSARプラットフォーム間の共通要件、共通のMethodology、プラットフォーム間で共有すべき技術仕様（例.プロトコル）が含まれる。

**アクセプタンステスト**
AUTOSARアクセプタンステストは、テストの手間とコストを最小化するため2014年に導入された。アクセプタンステスト仕様書は、アプリケーションとバスからアクセスする前提のシステムテスト仕様書である。標準アクセプタンステストの仕様書があれば、時間とコストの削減が可能である。

**標準アプリケーション・インタフェース**
AUTOSARの技術目標達成の基盤になるのは、メーカーとサプライヤー間の機能的インタフェースの標準化と、異なるソフトウェア層の間のインタフェース標準化である。

**組織**
AUTOSARの会員（partners）は以下の6種類に分類している。会員の貢献は会員の分類により異なる。- 中核会員（core partners）- 上級会員プラス（premium partner plus）- 上級会員（premium partners）- 開発会員（development partners）- 準会員（associate partners）- 参加者（atendee）
中核会員は、発足時からの会員である BMW、ボッシュ、コンチネンタル、ダイムラー、フォード、ゼネラルモータース、グループPSA（プジョー・シトロエン）、トヨタ自動車、フォルクスワーゲンの各社である。中核会員は、組織の運営、管理、AUTOSAR 開発会員制度の統制に責任をもつ。理事会（Executive Board）はこの中核会員によって構成され、総合的な戦略と計画表（roadmap）を決定する。運営委員会（Steering Committee）は、技術面以外の部分での日常業務、会員企業の入会、広報、各種契約業務などを行う。会長（Chairman）は9か月ごとに交代し運営委員会の代表として対外的な意思疎通を担当する。
上級会員（premium partner）と開発会員（development partner）は作業文書（work package）を作る。作業文書は、中核会員が選出した事業指導者班（project leader group）が調整と監視を行う。準会員はAUTOSARが発行した標準文書を使用できる。参加者は現在、学術的な共同作業や非営利事業に参加している。
2020年5月時点で、200社以上の企業がAUTOSAR会員制度に参加している。

**中核会員**
 BMW- ボッシュ（Bosch）- コンチネンタル（Continental）- ダイムラー（Daimler）- Ford- ゼネラルモーターズ （GM: General Motors）- グループPSA（Peugeot Societe Anonyme）- トヨタ自動車- フォルクスワーゲン（Volkswagen）

**上級会員プラス**
 デンソー- Vector- Huawei

**上級会員**
 Altran- アプティブ（Aptiv）- APTJ
**  Julinar- Assystem- オートリブ（Autoliv）- Baidu- BlackBerry- キャップジェミニ（Capgemini）- 原子力・代替エネルギー庁（CEA）- デロイト トウシュ トーマツ（Deloitte GmbH）- Dassault Systems- dSPACE- Elektrobit - イーソル（eSol）
**  eSOL ECUSAR- ETAS- フラウンホーファー研究機構（Fraunhofer-Gesellschaft）- 長城汽車（Great Wall Motor）- Green Hills Software- HCL Technologies Limited- ヘラー（Hella）- 本田技研工業- ファーウェイ（Huawei Technologies Co., Ltd.）- 現代自動車（Hyundai）- IAV- インフィニオン・テクノロジーズ（Infineon Technologies AG）- インテル（Intel）- ITK Engineering- iSOFT- ixia- ジェイテクト- KPIT Technologies- ラーセン&トゥブロ（Larsen and Toubro Limited）- Lear Corporation- Luxoft- The MathWorks- メンター・グラフィックス（Mentor Graphics Corporation）- 三菱電機- NEC- 日産自動車- NVIDIA- NXPセミコンダクターズ- パナソニック- ルネサスエレクトロニクス
**  AUTOSARソリューション
**  AUTOSAR OS- SCSK
**  QINeS-BSW- Sodius SAS- STマイクロエレクトロニクス- 住友電気工業- TATA- ティッセンクルップ（ThyssenKrupp）- Valeo SAS- ベクター・インフォマティック（Vector）- ボルボ・グループ（AB Volvo）- ボルボ・カーズ（Volvo Car Corporation）- ウインドリバー・システムズ（Wind River Systems, Inc.）- ZFフリードリヒスハーフェン（ZF Friedrichshafen AG）

**開発会員**
 FPT- ガイオ・テクノロジー- 名古屋大学大学院情報学研究科附属組込みシステム研究センター（NSES）- PRQA

**準会員**
 アイシン- アテック- アルパイン- アルプス電気- カルソニックカンセイ- クラリオン
*CISCO- 永和システムマネジメント
**  AUTOSAR RTE
**  ARTEC VFBS
**  ARTEC CDK- 富士ソフト
**  AUTOSAR開発体験キット- 富士通- 萩原電気- 日立オートモティブシステムズ- いすゞ- ケーヒン- 小糸製作所- クボタ- 豆蔵
*Microchip- マツダ- 三菱自動車工業
*National instruments- 村田製作所- ニデック- 日本精機- 日本精工（NSK）- オムロン- OTSL- パーソルR&D- パイオニア- ルネサスイーストン- 菱電商事- 新光商事- スバル
*SAMSUNG- サニー技研
**  AUTOSAR準拠オールインワンフレームワーク CioRy- スズキ- TDK- 東海理化- 東海ソフト- 東芝- 豊田自動織機- 豊田通商- 株式会社ヴィッツ
**  Owls-AUTOSARdate=2021-06-03- ヤマハ発動機- 矢崎総業

**参加者**
 ブダペスト大学

**開発ツール**
上記組織欄には国内のAutosar加入組織の開発ツールを付記している。ここでは海外の開発ツールとその開発元・提供元を一覧にする。- Vector
** DaVinci Developer- Elektrobit 
**  tresos - Mathworks
**  AUTOSAR Blockset- dSPACE
** systemdesk
*ETAS
** AUTOSAR solution
*Mentor Graphics
** volcano- Sparxsystems（非会員）
**  Enterprise Architect (EA) Autosarの公式文書の図がEAの書式で配布されている。- Parasoft（非会員）
** C++TEST

**国内の動向**
JASPAR（Japan Automotive Software Platform and Architecture）が日本国内でAUTOSARについての情報交換をしている。2014年11月19日「JASPAR提案仕様（通称：プロファイルコンセプト）のAUTOSAR採用結果」を公表している。また、機能安全関連文書も公表している。
名古屋大学大学院情報学研究科附属組込みシステム研究センター（NCES）では、2011年度から2013年度の3年間、複数企業とともに、AUTOSARプラットフォームの開発を行い、開発したプラットフォームは、TOPPERSプロジェクトから無償で一般公開されている。
2014年度からは、後継プロジェクトとして、APコンソーシアムを開始し、機能安全規格対応や、BSWモジュールの拡充等を行っている。
TOPPERSプロジェクトでは、日本国内でのAUTOSAR仕様に関する情報サイトとして、AUTOSAR情報サイトを運用している。

**脚注 ==