プロトコル

AUTOSARとは？Classic・Adaptiveの違いと3層構造・ARXMLの読み方を実装目線で解説

AUTOSARとは？Classic・Adaptiveの違いと3層構造・ARXMLの読み方を実装目線で解説

AUTOSAR（AUTomotive Open System ARchitecture）は、自動車メーカーと部品メーカーが2003年に始めた、車載ソフトウェアの構造と開発手法を標準化する枠組みです。同じ名前で、規格を作る団体と、その規格群の両方を指します。この記事では2026年10月時点の公式資料（最新はR25-11）をもとに、Classic PlatformとAdaptive Platformの違い、アプリケーション・RTE・BSWの3層構造、設計情報を書くARXMLの実物とPythonでの読み方を整理しました。SDV（ソフトウェア定義車両）で役割がどう変わるか、AUTOSARを採用しない条件も示します。

まとめ｜AUTOSARの全体像と採用を判断するときに見る2つの軸

AUTOSARは1つの規格ではなく、制御系マイコン向けのClassic Platform（CP）、高性能ECU向けのAdaptive Platform（AP）、両者の共通部分を収めたFoundation（FO）の3本立てです。毎年11月ごろに3本そろって改版され、2026年10月時点の最新はR25-11、次のR26-11は2026年12月3日に発表イベントが予定されています。

実装者がまず理解すべきなのはCPの3層構造です。アプリケーションはRTEだけを通じて外とやり取りし、RTEの下にあるBSW（Basic Software）がマイコンや通信を隠す。そして設計情報はコードではなくARXMLというXMLで受け渡されます。

採用の判断は2軸で決まります。量産車のECUとしてOEMやTier1の供給網に入るか、BSWとツールを買う費用を台数で割れるか。どちらかが「いいえ」なら、AUTOSARに合わせる理由は薄い。建機・農機・産業機器のように車載以外の組み込み機器では、汎用のRTOSで組むほうが総額を説明しやすくなります。

AUTOSARの定義と2003年発足の標準化団体が担う役割と運営体制

AUTOSARの規格は、加盟企業がワーキンググループで書き、団体として年次リリースします。誰が書いているかを知ると、規格の性格がつかめます。

2003年7月の発足から2026年1月のコアパートナー追加までの体制

公式のCore Partnerのページによると、AUTOSARは2003年7月、BMW、Robert Bosch、Continental（現AUMOVIO）、Daimler系、Siemens VDO、Volkswagenによって発足しました。同年12月にトヨタ自動車が、翌年11月にGeneral Motorsがコアパートナーに加わっています。

2026年1月には、DENSO、Huawei、Vector Informatikの3社が新たにコアパートナーとなりました。日本の部品メーカーと、AUTOSAR向けツールの大手ベンダーが運営側へ入った形です。2026年10月時点の一覧に載るコアパートナーは10社。コアパートナーは全体戦略とロードマップを決める役割を持ち、規格の方向性はこの10社の意向を強く受けます。

パートナー区分と年会費が決める仕様書の閲覧範囲と商用利用の条件

仕様書のPDFは公式サイトから誰でもダウンロードできます。ただしClassic Platformの配布ページには、公開ファイルは情報提供目的（INFORMATION ONLY）であり、内容を商用に使うにはライセンスが要るため、パートナー契約を申し込むよう注記があります。読むのは自由、製品に組み込んで売るなら契約、という線引きです。

パートナー区分の一覧では、年会費と人的貢献の条件が次のように定められています。

区分 年会費 人的貢献 主な対象
Premium Partner Plus 90,000ユーロ 5FTE＋1FTE 規格策定を主導する大手
Premium Partner 31,000ユーロ 1.5FTE 策定に関与したい企業
Development Partner 10,000ユーロ 0.5FTE 自動車事業100人未満
Associate Partner 21,000ユーロ 不要 規格を使う側
Associate Partner [Light] 無料 不要 バス互換製品の一部範囲

受託で車載案件に入る会社が最初に検討するのは、規格を使う側のAssociate Partnerです。BSWを自社で実装して販売するのでなければ、市販のAUTOSARスタックを使う形になり、規格の使用条件はスタックのベンダーとの契約にも関わります。アプリケーション層だけを受ける場合は、自社でパートナー契約が要るかを案件ごとに発注元とベンダーへ確認してください。

Classic・Adaptive・Foundationの3規格の分担と年次リリースの番号

「AUTOSARとは」と検索する人が最初につまずくのは、CPとAPの関係です。新旧ではなく、用途の違う2つのプラットフォームが並んでいます。

ハードリアルタイムのCPと高性能計算ECU向けAPの守備範囲の違い

公式の説明では、CPは「ハードリアルタイムと安全上の制約を持つ組み込みシステム」のための規格で、APは「高性能計算ECU」のための規格です。CPはブレーキ、パワートレイン、ボディ制御のように、決まった周期で決まった信号を処理するマイコン上で動きます。タスクも通信経路もビルド時に確定する。

APはPOSIX系OSの上でC++のアプリケーションを動かし、サービスを実行時に見つけて接続します。運転支援や車載インフォテインメントのような計算量の大きい機能と、OTAによる更新を前提にした構成です。APの機能範囲とCPとの5項目の対照は、Adaptive AUTOSARとClassic Platformの違いと使い分けで詳しく整理しました。

両プラットフォームの共通部分を切り出したFoundationの位置づけ

Foundationの公式ページは、その目的を「AUTOSARのプラットフォーム間の相互運用性を担保すること」と説明しています。中身は、CPとAPが共有する要件と、通信プロトコルのような技術仕様です。

実装者がFoundationの文書を開く場面は限られます。代表例は、車載Ethernet上のサービス指向通信であるSOME/IPの仕様と、後述するARXMLの書式規則です。どちらもCPとAPの両方から参照されるため、FO側に置かれています。

R25-11という年次リリース番号の読み方とR26-11までの改版周期

番号の付け方は途中で変わりました。公式の沿革を見ると、CPは2016年10月の4.3.0、2018年10月の4.4.0のように3桁の版番号で、APは2017年3月の開始から「18-03」「18-10」のような年月表記でした。2019年11月に「19-11」で両者がそろい、2020年11月から「R20-11」の形式になっています。

R25-11は「2025年11月版」と読みます。古い資料に出てくる「AUTOSAR 4.x」はCPの旧番号で、R19-11より前の世代を指します。社内文書で版を書くときは「R25-11系（2026年10月時点の最新）」のように時点を添えると、R26-11が出たあとも誤解を生みません。

Classic Platformの3層構造｜アプリケーション・RTE・BSWの分担

CPの公式ページは、ソフトウェアを最上位で3層に分けると定義しています。マイコン上で動くアプリケーション層、RTE（Runtime Environment）、BSWの3つです。

RTEがSWC間通信とBSW呼び出しをECUごとの生成コードで仲介する役割

アプリケーションはSWC（ソフトウェアコンポーネント）という部品に分けて書きます。SWC同士の通信も、BSWの機能の呼び出しも、すべてRTEを経由する。公式の説明では「RTEはアプリケーションに対する完全なインタフェース」です。

RTEは手で書くコードではありません。ARXMLの設計情報から、ECUごとに生成ツールが作ります。そのためSWCは、相手のSWCが同じECUにいるのか、CANの先の別ECUにいるのかを知らずに書ける。この配置の独立性が、AUTOSARが部品の再利用をうたう根拠です。生成されるAPIの種類とSender-Receiver通信の書き方は、AUTOSAR RTEの生成物とSWC間通信・APIの書き方で扱いました。

BSWを構成するサービス層・ECU抽象化層・MCALと複雑デバイスドライバ

BSWは3つの層と、層をまたぐComplex Driversに分かれます。Layered Software Architecture（Document ID 53・R25-11）の説明を要約すると次のとおりです。

  • Services Layer：OS、メモリ管理、通信サービス、診断など、アプリケーションが使う基盤機能
  • ECU Abstraction Layer：ECU基板上の周辺機器の違いを隠し、上位にECU非依存のインタフェースを出す層
  • Microcontroller Abstraction Layer（MCAL）：BSWの最下層。マイコンと内蔵周辺機能に直接触るドライバ群で、実装はマイコン依存、上位インタフェースはマイコン非依存
  • Complex Drivers：上記に収まらない特殊なセンサーやアクチュエータ制御を、ハードウェアまで縦に貫いて書く領域

同じ文書には、非標準のモジュールはComplex Driversとして統合でき、それ以上の層は追加できないと書かれています。独自の処理を入れたくなったら、置き場所はアプリケーション層かComplex Driversの2択です。MCALは半導体メーカーが自社マイコン向けに提供するのが通例で、受託側が書く層ではありません。

OSと通信スタックがBSWのどこに入るかとOSEK由来のOS仕様の位置

OSはServices Layerのシステムサービスに属します。AUTOSAR OSは、欧州の車載OS規格OSEK/VDXを土台に、メモリ保護とタイミング保護を足した静的なOSです。タスクやアラームの設計とスケーラビリティクラスの選び方はAUTOSAR OSの仕様とスケーラビリティクラスにまとめました。

通信スタックは、Services LayerのCOMからECU抽象化層のインタフェース、MCALのCANドライバまで縦に連なります。CANやLINのフレームはこのスタックの最下部で扱われ、SWCからは信号として見える。CANそのものの仕組みはCAN通信のフレーム構造とアービトレーション、方式の選び方は車載ネットワークの方式比較を参照してください。

ARXMLで書かれる設計情報の構造とPythonでSWCを一覧する手順

AUTOSARの開発では、SWCの定義、ポートの接続、ECUへの割り当て、BSWの設定値まで、設計情報をARXMLというXMLで受け渡します。OEMとサプライヤの間で交換されるのもARXMLです。中身を読めると、受け取った設計の確認がぐっと速くなります。

R25-11のスキーマAUTOSAR_00054.xsdを宣言した最小のARXML

ARXMLの書式は、FoundationのARXML Serialization Rules（Document ID 779・R25-11）が定めています。名前空間http://autosar.org/schema/r4.0はRelease 4.0.1以降で後方互換を保つ系列を表し、R25-11でも変わりません。スキーマのファイル名はリリースごとに1ずつ増える番号で、同文書の例ではR25-11がAUTOSAR_00054.xsdです。

次の例は、車速を送るSWCと受け取るSWCを、1つのSender-Receiverインタフェースでつないだ最小構成です。speed.arxmlとして保存します。

<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://autosar.org/schema/r4.0 AUTOSAR_00054.xsd">
  <AR-PACKAGES>
    <AR-PACKAGE>
      <SHORT-NAME>Interfaces</SHORT-NAME>
      <ELEMENTS>
        <SENDER-RECEIVER-INTERFACE>
          <SHORT-NAME>VehicleSpeedIf</SHORT-NAME>
          <DATA-ELEMENTS>
            <VARIABLE-DATA-PROTOTYPE>
              <SHORT-NAME>Speed</SHORT-NAME>
            </VARIABLE-DATA-PROTOTYPE>
          </DATA-ELEMENTS>
        </SENDER-RECEIVER-INTERFACE>
      </ELEMENTS>
    </AR-PACKAGE>
    <AR-PACKAGE>
      <SHORT-NAME>Swcs</SHORT-NAME>
      <ELEMENTS>
        <APPLICATION-SW-COMPONENT-TYPE>
          <SHORT-NAME>SpeedSensor</SHORT-NAME>
          <PORTS>
            <P-PORT-PROTOTYPE>
              <SHORT-NAME>SpeedOut</SHORT-NAME>
              <PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">/Interfaces/VehicleSpeedIf</PROVIDED-INTERFACE-TREF>
            </P-PORT-PROTOTYPE>
          </PORTS>
        </APPLICATION-SW-COMPONENT-TYPE>
        <APPLICATION-SW-COMPONENT-TYPE>
          <SHORT-NAME>SpeedMonitor</SHORT-NAME>
          <PORTS>
            <R-PORT-PROTOTYPE>
              <SHORT-NAME>SpeedIn</SHORT-NAME>
              <REQUIRED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">/Interfaces/VehicleSpeedIf</REQUIRED-INTERFACE-TREF>
            </R-PORT-PROTOTYPE>
          </PORTS>
        </APPLICATION-SW-COMPONENT-TYPE>
      </ELEMENTS>
    </AR-PACKAGE>
  </AR-PACKAGES>
</AUTOSAR>

要素はすべてAR-PACKAGEの入れ子に置かれ、名前はSHORT-NAMEで付けます。別の要素を指すときは、/Interfaces/VehicleSpeedIfのようにパッケージ名をつないだパスで参照する。DEST属性は参照先の要素型です。この例は構造の説明用で、データ型の定義を省いているため、スキーマ検証までは通りません。なお、同文書は中身の無いAR-PACKAGESを不正な例として挙げています。

標準ライブラリのElementTreeでSWCとポートの接続先を確かめるスクリプト

市販の設計ツールが無くても、ARXMLはふつうのXMLとして読めます。次のスクリプトは、ファイル内のSWCとポートを一覧し、ポートが参照するインタフェースがファイル内に定義されているかを確かめます。外部ライブラリは使いません。

import sys
import xml.etree.ElementTree as ET

NS = {"ar": "http://autosar.org/schema/r4.0"}
SWC_TAGS = {"APPLICATION-SW-COMPONENT-TYPE", "SENSOR-ACTUATOR-SW-COMPONENT-TYPE",
            "COMPOSITION-SW-COMPONENT-TYPE"}
PORT_TAGS = {"P-PORT-PROTOTYPE": ("P", "PROVIDED-INTERFACE-TREF"),
             "R-PORT-PROTOTYPE": ("R", "REQUIRED-INTERFACE-TREF")}


def local(tag):
    return tag.split("}")[1]


def walk(node, path):
    for pkg in node.findall("ar:AR-PACKAGES/ar:AR-PACKAGE", NS):
        name = pkg.findtext("ar:SHORT-NAME", namespaces=NS)
        for el in pkg.findall("ar:ELEMENTS/*", NS):
            yield f"{path}/{name}", el
        yield from walk(pkg, f"{path}/{name}")


def main(arxml):
    root = ET.parse(arxml).getroot()
    elements = {f"{p}/{el.findtext('ar:SHORT-NAME', namespaces=NS)}": el
                for p, el in walk(root, "")}
    for ref, el in elements.items():
        if local(el.tag) not in SWC_TAGS:
            continue
        print(f"{ref} ({local(el.tag)})")
        for port in el.findall("ar:PORTS/*", NS):
            if local(port.tag) not in PORT_TAGS:
                continue
            kind, tref = PORT_TAGS[local(port.tag)]
            iface = port.findtext(f"ar:{tref}", namespaces=NS)
            status = "OK" if iface in elements else "NOT FOUND"
            name = port.findtext("ar:SHORT-NAME", namespaces=NS)
            print(f"  [{kind}] {name} -> {iface} {status}")


if __name__ == "__main__":
    main(sys.argv[1])

Python 3.14.7で実行した結果が次の出力です。参照先の綴りを1文字変えたファイルでは、該当ポートがNOT FOUNDになります。

$ python list_swc.py speed.arxml
/Swcs/SpeedSensor (APPLICATION-SW-COMPONENT-TYPE)
  [P] SpeedOut -> /Interfaces/VehicleSpeedIf OK
/Swcs/SpeedMonitor (APPLICATION-SW-COMPONENT-TYPE)
  [R] SpeedIn -> /Interfaces/VehicleSpeedIf OK

$ python list_swc.py speed_typo.arxml
/Swcs/SpeedSensor (APPLICATION-SW-COMPONENT-TYPE)
  [P] SpeedOut -> /Interfaces/VehicleSpeedIf OK
/Swcs/SpeedMonitor (APPLICATION-SW-COMPONENT-TYPE)
  [R] SpeedIn -> /Interfaces/VehicleSpeedIF NOT FOUND

実務のARXMLは複数ファイルに分かれ、1つのファイルの参照先が別のファイルにあるのが普通です。その場合は全ファイルをelements辞書へ読み込んでから照合します。このスクリプトは参照パスを文字列のまま照合するため、大文字小文字の違いも参照切れとして出ます。受け取ったファイルでNOT FOUNDが出たら、まず綴りとパッケージの階層を疑ってください。

ARXMLからRTEとBSWを生成する開発工程とツールチェーンの全体像

ARXMLは書いて終わりではありません。システム全体の記述からECUごとの抽出（ECU Extract）を作り、BSWとRTEの設定値を足し、生成ツールでCのコードを出してビルドする。この流れがAUTOSARの開発手法（メソドロジ）です。工程ごとの成果物、設定クラス、Vector・ETAS・Elektrobitなどのツールの担当範囲は、AUTOSAR開発の工程とARXMLの受け渡しで解説しています。

SDVとE/E構成の集約でCPとAPが分担する役割の変化と車外との接点

SDVの議論でAUTOSARは「古い規格」と扱われがちです。実際には、CPは末端の制御に残り、APが集約ECU側を受け持つという分担へ移っています。

集約ECUにAPを置き末端の制御ECUにCPを残す構成とSOME/IPの接続

これまでの車は、機能ごとに小さなECUを置き、CANでつないできました。SDVでは、計算をいくつかの高性能ECUへ集め、車内を区画（ゾーン）ごとのECUで束ねて車載Ethernetでつなぐ構成が増えています。集約ECUはAP、ゾーンの先にある制御ECUはCPという割り当てが基本形です。

両者の接続に使われるのは、CPとAPの両方が実装するSOME/IPです。Adaptive Platformの公式ページは、車両の信号と制御値の多くは今もCPが供給・処理しているとしたうえで、APがそれらをつなぐ仕組み（Signal-to-Service Translation）を持つと説明しています。CPが消える前提で設計を組むと、この接続部分で手戻りが出やすくなります。

R24-11のAutomotive APIとOTA更新が車外システムへ広げた接点

同じ公式ページには、R24-11から導入されたAutomotive APIにより、クラウドのような外部システムとの連携が可能になったとあります。OTA更新の仕組みと合わせ、車両側のソフトウェアと車外のサービスが標準化されたインタフェースでつながる方向です。

受託開発会社にとっての接点はここにあります。車両から上がるデータを受け取るクラウド側の基盤、更新を配る配信系、診断データの分析は、AUTOSARそのものの実装経験が無くても引き受けられる層です。

AUTOSARを採用しない条件と受託開発会社が担当できる領域の線引き

AUTOSARの解説記事は、採用する前提で書かれたものがほとんどです。ここでは見送る条件を先に言い切ります。

車載の量産ECU以外でAUTOSARを見送る4つの条件と代わりの構成

次の4つのうち1つでも当てはまるなら、AUTOSARは採用しません。

  1. 供給先のOEMやTier1、あるいは業界の調達条件として、AUTOSAR準拠を求められていない
  2. 量産台数が数千台規模に留まり、BSWスタックとツールのライセンス費を台数で割れない
  3. 社内にARXMLと生成ツールを扱える技術者がおらず、外部から継続的に確保する目処も無い
  4. 求めているのが「部品の再利用」だけで、層構造の規律はRTOSとモジュール設計で代替できる

AUTOSARは2016年から自動車以外の用途にも開放されており、公式は農業機械・鉄道・産業オートメーション・医療技術などを例に挙げています。それでも、建機・農機・産業用ロボットのような台数の限られる機器では、条件1と2に当てはまる案件が大半です。この場合はITRON系や商用RTOSの上に自社のミドルウェアを載せる構成のほうが、総額も体制も説明しやすい。OSの選び方は組み込みOSの3分類と選定判断で整理しています。逆に、供給先のOEMがAUTOSAR準拠を調達条件にしているなら、検討の余地はありません。準拠する前提で、どの層を買いどの層を書くかを決める段階です。

BSWとツールは購入しアプリ層と車外システムを外注する分担の決め方

AUTOSAR案件を自社で抱えきれないとき、分け方の原則は1つです。BSWとRTE生成ツールは市販品を買い、差別化に効く層だけを書く。MCALは半導体メーカー、BSWとツールはVectorやETAS、Elektrobitなどの専業ベンダーから調達し、アプリケーションのSWCと、車両データを使う車外システムに開発の手を集めます。

内製と外注の一般的な判断軸は組み込みソフトウェア開発の工程と内製・外注の判断基準で解説しました。当社が引き受けるのは、車両や機器から上がるデータをクラウド側で処理する層と、センサーを含む機器側のソフトウェア開発です。車載機と車外システムの境界をまたぐ案件は、AI・IoTソリューション開発として相談を受け付けています。ASIL認証が必要な制御ソフトウェアそのものは対象外です。

よくある質問

AUTOSARを初めて調べる実装者や技術選定者から出やすい質問を、2026年10月時点の公式資料に基づいて整理しました。

AUTOSARの読み方と正式名称は何ですか？

日本では「オートザー」と読まれるのが一般的です。正式名称はAUTomotive Open System ARchitectureで、大文字の部分をつなげた略称になっています。団体（開発パートナーシップ）と、その団体が発行する規格群の両方を指す言葉なので、文脈によって意味が変わります。

AUTOSARの仕様書は無料で読めますか？

無料で読むことが可能です。公式サイトの標準ページから、リリース番号ごとにPDFを会員登録なしでダウンロードできます。ただし公開は情報提供目的とされ、内容を製品に組み込んで商用に使うにはライセンスが必要で、公式はそのためのパートナー契約を案内しています。市販のAUTOSARスタックを使う場合は、まずベンダー側の契約範囲を確認してください。

Classic PlatformとAdaptive Platformはどちらを選べばよいですか？

ECUの性格で決まります。決まった周期で制御信号を処理するマイコンならClassic Platform、POSIX系OSが動くSoCで機能を後から追加・更新するならAdaptive Platformです。両者は置き換えの関係ではなく、1台の車の中で同居させ、SOME/IPでつなぐのが標準的な構成です。迷う場合は、出荷後にソフトウェアを入れ替える計画があるかどうかで判断します。

AUTOSARの開発に使うプログラミング言語は何ですか？

Classic PlatformはC言語が中心で、RTEとBSWも生成ツールがCのコードとして出力します。Adaptive PlatformはC++が基本で、R23-11以降はRustで書くための説明文書も収録されています。どちらの場合も、設計情報はARXMLで記述し、コードはそこから生成または実装するという流れは共通です。

AUTOSARは車載以外の組み込み機器にも使えますか？

使えます。AUTOSARは2016年から非自動車用途への利用を開放しており、公式は農業機械や産業オートメーション、医療技術などを例に挙げています。ただし仕様書の注記は、規格が自動車用途のために作られ、それ以外の用途では開発も試験もされていないと明記している。可否は案件ごとに開発契約に照らして判断する扱いです。台数の限られる機器では、BSWとツールの費用を回収しにくい点を先に試算してください。

関連記事

お気に入りに入れた記事の一覧

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.23　テックブログ Renta!不正アクセスでサービス停止：再開未定の現状と運営側の停止判断・証拠保全・段階的再開
  2. 2026.10.21　テックブログ ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期
  3. 2026.10.14　テックブログ ローソンID不正アクセス：215万件漏えいの対象確認と本物メールの見分け方
  4. 2026.10.24　テックブログ ブラストメール不正アクセス：配信先288件の漏えいと利用企業の報告・通知の手順
  5. 2026.10.22　テックブログ お名前.com デスクトップクラウドの不正アクセス｜MT4口座の不正操作と対象・今すること

RELATED POSTS 関連記事

一覧へ戻る

目次