---
title: "AUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説"
url: "https://www.issoh.co.jp/tech/details/16838/"
published: 2026-08-23
updated: 2026-08-23
categories: ["アーキテクチャ"]
publisher: "株式会社一創"
---
# AUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説
AUTOSAR開発は、コードを書き始める前に「記述」を積み上げる開発です。車両全体の機能配置からECU1台分の設定までをARXMLという単一のXMLフォーマットで書き、その記述からRTEとBSWのコードを生成する。手で書く範囲はむしろ狭い。この記事では公式配布のMethodology for Classic Platform（文書ID 68・R25-11）に沿って、工程の順序と成果物、設定クラスが決める変更コスト、各社ツールの担当範囲、内製と委託を分ける線を実装目線で整理しました。
## まとめ｜工程の分岐点と内製・委託を分ける二つの判断軸
AUTOSAR開発の工程は、突き詰めると**「記述を誰が書き、誰に渡すか」で形が決まります**。仕様書は二段階開発を明示していて、主体組織（通常はOEM）が全体システムを定義してSystem Extractを配り、複数のサプライヤが並行してサブシステムを設計する。この受け渡しの単位が、そのままプロジェクトの分割単位になります。
手戻りが起きる場所も、ここから逆算できる。実装のバグより、**ECU Extractの更新と設定クラスの選び間違いのほうが工数を食います**。通信マトリクスが更新されればECU設定の再検証が走り、事前コンパイル時と決めたパラメータを後から車種別に振り分けたくなればビルド構成そのものが増える。工程表にはこの2つの戻り工数を見込んでおきます。
内製と委託の線も同じ軸で引けます。判断軸は**ARXMLの所有権を持つかどうかと、量産ECUの機能安全に責任を負うかどうかの2点**。システム記述とECU設定、BSWとMCALの統合は社内側に残る。一方でアプリケーションSWCの機能実装、モデルからのコード生成、ARXMLの差分チェック、テスト自動化、計測データの後段処理は切り出せます。この線を引かずに一式で外注すると、たいてい体制が破綻する。
## AUTOSAR開発が一般の組み込みソフト開発と分かれる三つの前提
### 実装より先に記述があり、コードの大半が生成物として出てくる構造
通常の組み込み開発は、要件から設計へ落として実装します。AUTOSARでは、要件と設計がARXMLというモデルとして先に存在し、そこからRTE・OS・BSW設定コードが生成される。開発者が手で書くのは、SWC（ソフトウェアコンポーネント）のランナブル内部と、標準では受けきれない処理を置くComplex Driversに限られます。
### 組織をまたぐ成果物の受け渡しが、ファイル単位で標準化されている
仕様書のTR\_METH\_01047は、二段階開発を「責任の組織的な分離があるとき」に用いる方式として定義しています。主体組織が第1フェーズで全体システムを定義し、複数の他組織が第2フェーズで並行してサブシステムを定義する。このとき渡されるのがSystem Extractです。
受け取った側は、それをそのまま使う必要はありません。仕様書はSystem Extractを「要件」、受け手が作るECU System Descriptionを「その要件を満たす解」と位置づけている。SWCの構造をECUの都合で組み替える自由が、規格の側から認められています。
### SWCの実装とECUの設定が独立して進む前提でチームを並列化する
TR\_METH\_01110は「SWCの実装はECUの設定からほぼ独立している。これがAUTOSARメソドロジの鍵となる特徴である」と明記します。BSWモジュールについても、VFBに依存しないためECU統合の前ならいつでも開発できるとされている（TR\_METH\_01111）。
この独立性は体制設計にそのまま効きます。SWCチーム、BSWチーム、システム設計チームを並列に走らせられる。ただし後述する契約フェーズを使わないと、この並列性は絵に描いた餅になります。
## R25-11のメソドロジが定める工程の順序と受け渡す成果物の一覧
Methodology for Classic Platformは、工程を「活動」と「成果物」の組で定義しています。図で示される主要な流れを、担い手つきで並べ直したのが下の表です。
### 抽象システム記述から実行ファイルまでの工程と成果物を並べた対応表
| 工程 | 主な成果物 | 主な担い手 |
| ------------ | -------------- | --------- |
| 抽象システム記述（任意） | 機能アーキテクチャ | OEM |
| VFBシステム記述 | SWCとポートの定義 | OEM |
| システム設計 | 通信マトリクスとECU割付 | OEM |
| システム抽出 | System Extract | OEM |
| ECUシステム記述 | サブシステムの構造 | サプライヤ |
| ECU抽出 | ECU Extract | サプライヤ |
| SWC開発（並行） | ランナブルの実装 | サプライヤ・委託先 |
| BSW開発（随時） | BSWモジュールの束 | BSWベンダー |
| ECU統合 | ECU実行ファイル | サプライヤ |
最初の抽象システム記述は任意の活動です。TR\_METH\_01044はこれを機能アーキテクチャの視点で全体を表すものと説明し、省略した場合はVFBシステムの定義から直接始まるとしています（TR\_METH\_01045）。既存の機能配置を引き継ぐ量産プロジェクトでは、VFBから入る形が多い。
### R25-11で入ったクラスタ分割と、そこで外された二つの旧来の仕組み
R25-11（2025年11月27日付）の変更履歴には3行が並びます。CpSoftwareClusterのメソドロジ追加、Data Exchange Pointsの廃止、Franca Integrationの廃止です。
追加されたCpSoftwareClusterは、1台のECUの中をさらに分ける仕組みです。CpSoftwareCluster Extractは、同一のEcuInstance上にある他のクラスタと独立して開発・ビルドできると明記されている。各クラスタでBuild Executableを走らせて部分バイナリを作り、Merge CpSoftwareClusterでMerged ECU Executableにまとめる。高性能ECUに複数サプライヤの機能が同居する構成で、ビルドの独立性を確保する手立てになる。
## VFBからECU Extractへ絞り込む記述の階層と分担の境目
仕様書はシステムのビューを、抽象システム・全体技術システム・サブシステムの3種に区分します。記述はこの順に絞り込まれていきます。
### システム記述が抱える五種類の情報と、二段階に抽出したときのふるまい
System Configuration Descriptionが持つのは、ECU一覧、それらをつなぐ通信系とその設定、フレームの送受信を定めた通信マトリクス、ポートとインタフェースを含むSWCの定義と接続、SWCのECUへのマッピング。この5種類です。通信マトリクスの中身は[CAN通信とは？CANバスの仕組み・アービトレーションとCAN FDの違いを実装目線で解説](https://www.issoh.co.jp/tech/details/16832/)で扱い、方式そのものの選び方は[車載ネットワークとは？CAN・LIN・FlexRay・車載Ethernetの違いと選び方を実装目線で解説](https://www.issoh.co.jp/tech/details/16834/)にまとめています。
System Extractは、この記述と同じフォーマットのまま、サブシステムに関わる部分だけを取り出したもの。まだコンポジション（合成コンポーネント）を含み、完全には分解されていません。対してECU Extractは、TR\_METH\_01109が「完全に分解され、アトミックなソフトウェアコンポーネントのみを含む」と定めている。ECU設定を始められるのは、この2つが揃ってからです。
### ARXMLの参照はパス表記で結ばれ、部品の差し替えが効く構造になる
ARXMLの中身は、要素の入れ子と参照で構成されます。SWCのプロトタイプが型を指す部分は、次のような形です。
```
DoorSensor
/Company/Components/DoorSensorSwc
```
参照はパッケージ階層のパスで書かれます。だからパッケージ名を変えると、離れた記述の参照が一斉に切れる。命名規約とパッケージ構成を初期に固めるのは、この性質への対処です。逆に、型の実体を差し替えても参照側は変わらないため、部品単位の入れ替えは効きます。
## ECUの設定値とRTE生成の順序と設定クラスが決める変更コスト
ECU統合は4つの活動で構成されます。Prepare ECU Configuration、Configure BSW and RTE、Generate BSW and RTE、Build Executable。加えて任意でModel ECU Timingが置かれ、タイミングモデルの結果を設定へ戻す反復が想定されています。
### ECU設定値の集約先が一つに決まっている理由と、入力になる二系統
入力は2系統です。ECU間で合意が要る設定はSystem Configuration Description（とそこから作られるECU Extract）から来る。もう一方は、使うBSWモジュールの実装仕様で、BSW Module Delivered Bundleに含まれる記述が持ちます。
TR\_METH\_01116は、ECU Configuration ValuesがそのECU内の全BSWモジュールの設定を1つの記述に集約すると定めています。RTE、Com、Can、OS、NVRAMといったモジュールが個別の形式を持つのではなく、単一フォーマットに集めて、各モジュールのジェネレータが必要な部分集合を取り出す。だからモジュール間の依存関係を、設定の段階で検証できます。
### 契約フェーズがSWCの実装とECU設定の並列化を成立させる仕組み
「SWCの実装はECU設定から独立している」を実務で成り立たせているのが、RTE生成の契約フェーズです。仕様書のComponent API Generator Toolの項は、SWCの契約フェーズがアプリケーションヘッダファイルを生成し、それが「コンポーネントとRTEの契約」を定めると説明しています。契約フェーズが出したヘッダの中身と、生成されたRTEが実行時にどう振る舞うかは[AUTOSAR RTEとは？生成される実行環境の中身とSWC間通信を実装目線で解説](https://www.issoh.co.jp/tech/details/16840/)で扱っています。BSW側にも同じ考えの契約フェーズがあり、BSW Schedulerとつなぐinterlinkヘッダを生成する。
手順としては、インタフェース定義と内部ふるまいという限られた情報だけでヘッダを先に出し、SWCの実装とコンパイルをそのヘッダに対して進めます。**契約フェーズを工程に入れていないプロジェクトは、SWC実装が統合待ちで止まり、後半に負荷が集中します**。
### 三つの設定クラスと、値を変えたときに戻る工程との対応関係の一覧
ECU設定パラメータは、値が確定する工程によって3クラスに分かれます。プリコンパイル時、リンク時、ポストビルド時です。プリコンパイル時と決めた値は、コンパイル後には変えられない。ポストビルド時のパラメータは、既知のメモリ位置に格納しておく必要があります。
| 設定クラス | 値を変えたとき戻る工程 | 向く用途 |
| -------- | ----------- | ---------- |
| プリコンパイル時 | 再コンパイルから | 開発エラー検出の有無 |
| リンク時 | 再リンクから | 目的コード納品の調整 |
| ポストビルド時 | 書き換えと再検証 | 車種別の通信設定 |
クラスはモジュールの実装バリアントで決まり、実装後は各パラメータのクラスが固定されます。1モジュール内での混在も仕様書は明示的に認めている（TR\_METH\_01115）。設定にまつわるファイル形式として列挙されているのは、.arxml、.exe、.hex、.c、.h、.objの6種です。
選び方の指針はこうです。**車種やグレードで振り分ける値をプリコンパイル時に置くと、バリアントの数だけビルド構成が増えます**。逆に、開発時のエラートレースのように出荷時には落とす仕掛けをポストビルド時へ寄せれば、要らないメモリと検証を抱え込む。分岐の頻度と、その値を誰がいつ決めるかで振り分けます。
### ビルドの工程で出てくる成果物と、計測系につながる出力の扱い方
BSWとRTEを生成したあと、すべてのソースをアプリケーションやライブラリと合わせてコンパイル・リンクし、ECU Executableを作ります。同時に出てくるのがマップファイルと、計測・適合のためのA2Lファイル。リソース使用量を測って実装記述へ書き戻す活動も、工程として定義されています。
デバッグ側では、ARTIが設定されていれば生成時にARTI情報が出力されます。ARTIトレースを有効にする場合、ビルド前にトレースツールが提供する`arti.c`をビルド対象へ加える必要がある。タスクとスケジューリングの基本的な考え方は[RTOSとは？リアルタイムOSの仕組み・主要製品の比較と採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15829/)にまとめています。
## AUTOSAR開発のツールチェーン構成と主要ベンダー製品の担当範囲
仕様書はジェネレータツールの詳細を規定していません。工程は標準、道具は各社という切り分けです。実際には、記述のオーサリング、ECU設定と生成、BSW実装、モデルベース開発、検証の5層で製品を組み合わせます。
### ツールを五つの層に分けたときの代表製品と選定するときの見どころ
| 担当する層 | ツール種別 | 代表製品 |
| ---------- | -------- | -------------------- |
| SWC・システム記述 | オーサリング | DaVinci Developer |
| ECU設定と生成 | コンフィグレータ | DaVinci Configurator |
| ECU設定と生成 | コンフィグレータ | EB tresos Studio |
| ECU設定と生成 | 統合スイート | ISOLAR-A・ISOLAR-B |
| BSW実装 | 基盤ソフト製品 | MICROSAR・RTA-CAR |
| ランナブル実装 | モデルベース開発 | TargetLink・Simulink |
| 機能安全の適合 | 認証パッケージ | RTA-FSQP |
VectorのDaVinci Configurator Classicは、MICROSAR ClassicのBSWとRTEを設定・検証・生成する中心ツールと位置づけられ、OEMのシステム記述と診断記述からBSWを自動でパラメータ設定する機能を持ちます。DaVinci Developerは、Classic PlatformのSWCとシステムを設計するオーサリング側です。
ETASのRTA-CARは、ISOLAR-AとISOLAR-Bという設定ツールに、RTA-RTE・RTA-BSW・RTA-OSという生成側、さらにISO 26262向けのRTA-FSQPを合わせた構成。ElektrobitのEB tresos Studioは、ECU基盤ソフトの設定・検証・生成を単一環境で行うツールで、ISOLARと同じくEclipseベースのため拡張が効きます。
### 製品名を決める前に確認しておきたいツールチェーンの三つの適合条件
1つ目は、対象マイコンのMCALが供給されるか。MCALはマイコンベンダーが提供する層なので、ここが揃わないと他が決まっても動きません。2つ目は、OEMから届くARXMLのリリース版と、ツールが読み書きするスキーマ版が噛み合うか。3つ目は、機能安全の要求水準に対して認証済みのBSWと認証パッケージが用意されているか。
## AUTOSAR開発でつまずきやすい工程と手戻りを招く三つのパターン
### システム記述の更新がECU設定へ波及して再検証が走るパターン
いちばん多いのが、OEM側の通信マトリクス変更です。System Configuration Descriptionが更新されると新しいECU Extractが配られ、取り込んだ時点でECU Configuration Valuesの整合を取り直すことになる。信号の追加1本でも、Comの設定、RTEの生成物、タスクへの割り付けまで影響が及びます。割り付け先となるOS側の仕様は[AUTOSAR OSとは？OSEK由来の仕様とスケーラビリティクラスの選び方を実装目線で解説](https://www.issoh.co.jp/tech/details/16842/)にまとめました。
対処は、取り込みを手作業にしないこと。ARXMLの差分を機械で出し、設定への影響範囲を一覧にしてからマージする仕組みを先に用意しておきます。
### 設定クラスの置き場所を誤ってビルドと検証の構成が増殖するパターン
2つ目は設定クラスです。車種やグレードで変わる値をプリコンパイル時に置いた結果、バリアントごとにビルドと検証が枝分かれする。ポストビルド時に寄せすぎれば、メモリと書き換え手順の検証が増える。実装後はクラスが固定されるため、後から動かすにはBSWモジュールの実装バリアントごと選び直す話になります。**どのパラメータが車両側の都合で変わるのかを、設定を始める前に洗い出しておく**のが唯一の予防策です。
### 契約フェーズを使わないまま統合待ちの行列ができてしまうパターン
3つ目は体制の話です。SWCの実装をECU設定の完了後に始める段取りにすると、前半は人が空き、後半に統合とデバッグが集中します。契約フェーズでアプリケーションヘッダを先に出せば、SWC側はそのヘッダに対してコンパイルとユニットテストを進められる。工程表の前半に、記述レビューの日程を明示的に置いておきます。
## 内製と委託を切り分ける二つの判断軸と、受託側が引き受ける範囲
内製と外注の一般的な判断基準は[組み込みソフトウェア開発とは？工程・費用相場と内製・外注の判断基準を解説](https://www.issoh.co.jp/column/details/16837/)にまとめてあります。ここではAUTOSAR固有の分岐だけを扱います。
### 社内に残す層と外へ切り出せる層を分ける二つの軸と、それぞれの内訳
軸は2つです。ARXMLの所有権を持つかどうかと、量産ECUの機能安全に責任を負うかどうか。この2つに該当する作業は、社内あるいは量産責任を持つTier1の側に残ります。システム記述とECU Extractの管理、BSW・MCALの設定と統合、ISO 26262の適合作業、量産検証です。
逆に、この2軸から外れる作業は切り出せる。アプリケーションSWCの機能実装、モデルからのコード生成とその検証、ARXMLの差分抽出やレビュー支援といったツール連携、テストの自動化、車載から上がってくる計測データの後段処理。いずれも記述の所有権を移さずに委託できます。
### 受託開発として実際に関われる層と、引き受けを見送る条件の線引き
受託側から見た現実的な範囲は、上位アプリケーションとツール・データ側です。当社の場合も、量産ECUのBSW統合そのものではなく、その周辺で発生する開発を引き受ける形になります。センサーから上がるデータの収集と処理、可視化、クラウド側との連携といった[AI・IoT開発](https://www.issoh.co.jp/service/ai/iot/)の領域は、車載側の工程と接続しつつ、ARXMLの所有権を移さずに進められる。
引き受けない条件も明示しておきます。**量産ECUのBSWとMCALの統合、そして機能安全の適合責任を一式で外部に移す形の委託は、成立しにくい**。マイコンとBSWベンダーの選定、ツールライセンス、量産責任が発注側に紐づいたままだからです。工程の一部だけを切り出し、記述と設定の管理は発注側に残す。この形にできるかどうかが、委託の可否を分けます。
なお、Adaptive Platform側の案件は工程の組み立てが変わります。マニフェストと配備が中心になり、ビルドと更新の単位も違う。その差は[Adaptive AUTOSARとは？Classic Platformとの違いと使い分けを実装目線で解説](https://www.issoh.co.jp/tech/details/16836/)で整理しました。
## よくある質問
### AUTOSAR開発ではコードをどこまで手で書くのですか？
手で書くのは、SWCのランナブル内部の処理と、標準のBSWでは受けきれない機能を置くComplex Driversが中心です。RTE、OS、BSWの設定コードは、ECU Configuration Valuesを入力にしてジェネレータが作ります。
### ARXMLは手で編集してよいのですか？
編集できますが、通常はオーサリングツールとコンフィグレータを介します。参照がパッケージ階層のパスで書かれているため、手編集は参照の切断を招きやすい。一方で、差分の確認やレビュー、機械的な一括変換のためにテキストとして扱うのは現実的な手段です。スキーマ検証を通す運用にしておきます。
### System ExtractとECU Extractは何が違うのですか？
粒度と用途が違います。System Extractはサブシステム単位の切り出しで、まだコンポジションを含む未分解の記述。仕様書はこれを受け手にとっての「要件」と位置づけています。ECU Extractは完全に分解され、アトミックなSWCのみを含む記述で、ECU設定を始めるための入力になります。
### AUTOSARの仕様書やツールは無償で入手できますか？
仕様書はautosar.orgのリリースページから、番号ごとにPDFを直接ダウンロードできます。Methodology for Classic Platformは文書ID 68です。一方でBSWの実装、コンフィグレータ、各種ジェネレータは商用製品が中心で、量産に使う構成をライセンスなしで組むのは現実的ではありません。
### Adaptive Platformでも同じ工程で進めるのですか？
大枠の考え方は共通しますが、手順書が別に用意され、成果物も変わります。Classic Platform側がECU Extractとビルド時の設定を中心に回るのに対し、Adaptive側はマニフェストによる配備と実行時のサービス探索が中心。更新の単位もソフトウェアクラスタになります。
## 関連記事
- [Adaptive AUTOSARとは？Classic Platformとの違いと使い分けを実装目線で解説](https://www.issoh.co.jp/tech/details/16836/)：AP側の工程と配備の違い
- [組み込みソフトウェア開発とは？工程・費用相場と内製・外注の判断基準を解説](https://www.issoh.co.jp/column/details/16837/)：内製と外注の一般的な判断軸
- [車載ネットワークとは？CAN・LIN・FlexRay・車載Ethernetの違いと選び方を実装目線で解説](https://www.issoh.co.jp/tech/details/16834/)：通信方式の選定
---
出典: [AUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説]()（株式会社一創）