While previously limited to embedded software, AUTOSAR has now become a strategic pillar supporting the transition to software-defined vehicles (SDV) for automotive OEMs, Tier 1 suppliers, and software development service providers. AUTOSAR serves as the core of modern automotive software architectures, achieving both standardization and scalability.
However, adopting AUTOSAR is only the first step. To effectively utilize it, it is important to consider appropriate architectural design and unify product lines and platforms across regions. It is also important to avoid pitfalls that can delay delivery and increase technical debt. This article explains how AUTOSAR is implemented and highlights key points to consider when developing a next-generation automotive software strategy. Read on.
What is AUTOSAR?
AUTOSAR (Automotive Open System Architecture) was born in 2003. The development project was founded by major players in the automotive industry (BMW, Bosch, Daimler, Continental, Siemens VDO, and Volkswagen) with the clear goal of eliminating the difficulties in developing electronic control units (ECUs). The idea was to use AUTOSAR as a standard to enable ECUs that are scalable, reusable, and capable of handling the complexities of modern vehicles.
Component-Based Architecture
AUTOSAR introduces a component-based architecture rather than building a monolithic architecture. Each software component (SWC) is developed with a clear interface and can be reused across various vehicle models, platforms, suppliers, and generations. This modular design provides the following benefits:
– Shortened development time
– Improved maintainability
– Realization of parallel development by development teams in various countries
Classic platform and Adaptive platform
There are two types of widely used AUTOSAR platforms:
・Classic Platform (CP): It runs on resource-constrained ECUs (powertrain, chassis, body) and is optimized for functions that require real-time processing. It features predictable behavior, is robust and mature, and has a proven track record of implementation in mass-produced vehicles. ・
Adaptive Platform (AP): It is designed for ADAS (advanced driver assistance systems) and computationally intensive ECUs (infotainment, central computing, etc.). It supports a POSIX-compliant OS, dynamic memory management, and service-oriented communication (such as SOME/IP), making it ideal for OTA (over-the-air data communication technology) and SDVs.
Why is AUTOSAR becoming important?
Why is AUTOSAR necessary for SDV?
SDVとは、単にソフトウェアを多く搭載した車ではなく、従来とはまったく異なる製品概念を持つ次世代の車です。AUTOSARの導入に伴う最も目立った変化は、ソフトウェアの開発・導入、そして機能・サプライヤー・ライフサイクルでの進化にあります。
現代の車両には、ブレーキ、ステアリング、インフォテインメント、運転支援まで、100以上のECUが搭載されており、かつてないほど複雑化しています。このような複雑さを構造化せずに維持することは現実的ではありません。その課題を解決するため、AUTOSARは、スケーラブルで長期運用可能なモジュール化された車載ソフトウェアアーキテクチャを提供します。
実際のメリット：
・AUTOSARのコンポーネントを再利用できるため、プラットフォームやサプライヤーごとにソースコードを再構築する必要がない。
・AUTOSARは自動車のミドルウェアとして機能するため、ソフトウェアとハードウェアが分離され、チップセット間の移行やソフトウェアのアップグレードが容易になる。
・安全性・性能・保守性を支える標準インターフェースと診断機能が備わり、システム間の通信を一から設計し直す必要がない。
安全で接続性が高く、常にアップデート可能な車両の提供を求められるプレッシャーが高まる中、分断されたレガシーシステム上でこれらを実現するのが困難になっています。こうした背景から、AUTOSARの採用は単なる流行ではなく、現実の課題を解決できるソリューションとして、将来の車両プラットフォーム構築に取り組むOEMが増えています。
2025年におけるAUTOSARの動向
AUTOSARへの移行はすでに急速に進んでいます。2025年までに、世界中のOEMの半数以上が研究開発の試験的なプロジェクトだけではなく、実際の製品開発においてもAUTOSAR準拠のアーキテクチャを採用することが予測されています。インフォテインメント、ADAS、パワートレイン、ゾーンアーキテクチャなど、全領域での統合が進んでいます。
以下の指標からその戦略的な重要性が明らかになっています。
・AUTOSARミドルウェア市場は、2023年に16.3億ドルに達し、2030年までに約11.1％の年平均成長率（CAGR）で34億米ドルに達すると予測されています。
同期間中、Adaptive PlatformはClassic Platformよりも早く成長し、OEMがセントラルコンピューティング、安全分離対策、OTAを優先する中で、ミドルウェア市場における収益を拡大すると見込まれています。
この成長は世界各地域で均等に見られます。
・ヨーロッパは市場の40％以上を占めており、規制の統一とプラットフォーム標準化により市場をリードしています。
・日本と韓国など、アジア太平洋地域は、EV（電気自動車）、ADAS、ゾーンアーキテクチャの量産により、最も急速に成長しています。
一方、一次サプライヤーは、AUTOSARに合わせてツールと製品戦略を再構築しています。ツールチェーンの互換性、統合支援、ミドルウェアのバージョン管理は、もはやエンジニアリングの問題にとどまらず、経営層が検討すべき課題となっています。
OEMにおけるAUTOSARの活用方法
最新の乗用電気自動車（EV）：CPが主流を維持しつつも、APが急速に成長
パワートレイン・ボディ系統など、時間制約とハードウェア密結合が求められる領域では、CPが依然として強みを発揮しています。AUTOSARツールチェーンの完成度と信頼性の高いRTE自動生成機能が、量産プロセスでの安定稼働を支えています。
一方で、APは今やプロジェクトの中核となりつつあり、ゾーンコンピューティング、インフォテインメント、OTA、ADASなど、多くの領域で活用されています。VolkswagenやStellantisといった大手メーカーでは、サービス指向のAUTOSARアーキテクチャにより、ゾーンECUクラスタへのAP導入を実現しています。AUTOSAR Builderのような自動設定ツールは、サプライヤーからのインプットをもとに、XML記述、RTE生成、BSW階層構成の管理を支援し、一貫性とセキュリティ準拠を確保します。
このような戦略的ワークフローは、初期のPSAパイロットプロジェクトと同様に以下の取り組みを実現します。
・サプライヤーは、標準化されたファイル（.arxml）に基づいてソフトウェアコンポーネント（SWC）を提供します。
・OEMは、既存の信号定義や車両マトリクス形式をインポートし、それらをVFB（仮想機能バス）互換モデルへ変換します。
・ツールは、SCVTのようなモジュールを通じてXMLメタデータと生成されたCコードの整合性とトレーサビリティを検証し、RTE契約コードの最終化前に一貫性を担保します。
プレミアム商用車：運用管理を支えるハイブリッドAUTOSAR
商用車への本格展開には、車両バリエーションの多様化、Uベースモデルへの対応、V2X技術の進化、フリート管理ダッシュボードなど、多くの複雑な要素を統合する必要があります。Volvo TrucksのようなOEMは、これに対して以下のようにハイブリッドアーキテクチャを導入しています。
・CP：時間制約のある制御ロジック
・AP：高度な診断、OTAアップデート、テレマティクスによる分析
ワークフローは、既存のユースケースをもとに、エコシステム内のサプライヤー間で緊密な協力体制を構築できるよう設計されています。AUTOSARツールチェーンを活用することで、以下を実現します。
・複数ベンダーによるSWC検証
・既存のECU定義からのトポロジー・通信マトリクス取り込み
・レガシーデータをもとにBSWモジュールやCOMスタックを自動で構成するスクリプトによる自動化
こうした機能により、フリート全体の稼働率を維持しつつ、異なる車両間でソフトウェア構成を柔軟にスケーリングすることができ、重複する機能ロジックや手作業による負担を大幅に削減します。
自動運転プラットフォーム：AP中心の統合アーキテクチャ
レベル4以上の自動運転車両（L4+）、自動運転シャトル、ロボタクシーなどの開発では、AP型のAUTOSARがランタイムの中核となっています。そのアーキテクチャの選定理由は以下の通りです。
・POSIX OS対応、動的メモリ割り当て、サービス指向通信（例：SOME/IPなど）
・自動運転計算スタックにおける診断・安全分離
・AI/ML処理やモジュール型センサーフュージョンに対応する再構成可能なミドルウェアアーキテクチャ
MobileyeやNAVYAといった企業は、センサーマネジメント、認識サービス、OTA制御を個別のSWCに配置した、完全なAPファーストスタックを実装しています。これらはAUTOSARオーサリングツールを使って検証され、VFBからRTEへの抽象化を管理しつつ、各コンポーネントが規格に準拠し、安全の要件を満たしていることを保証します。
VTIの事例紹介：日本の大手自動車メーカー向けのSAP S/4HANAクラウド移行
AUTOSARのグローバル展開状況
地域によって、AUTOSAR導入の状況や優先事項は大きく異なります。こうした多様なアプローチは、各地域の特性に応じたAUTOSAR戦略展開の好例と言えるでしょう。
ヨーロッパ
ヨーロッパは依然として、世界中で最もAP採用が活発な地域となっています。規制の準拠、セントラルコンピューティングの採用、そして確立された一次サプライヤー基盤が、この動きを後押ししています。Volkswagen、Stellantis、BMWなどの自動車メーカーは、ゾーン型・集中型アーキテクチャにAPを組み込み、ADAS、インフォテインメント、ソフトウェア・オーバー・ジ・エア（SOTA）の高性能アプリケーションを実現しています。
2024年、ヨーロッパのサプライヤーとOEMは、世界のAUTOSARミドルウェア収益の30～35％を占めており、アジア太平洋地域に次ぐ第2位にあります。この成果は、UNECE規制準拠の厳格なスケジュール管理、サプライヤーとの密な連携、イノベーションラボ・本番環境双方への包括的なAP導入により実現されました。
日本
日本におけるAUTOSAR、特にAPの展開は、依然として慎重に進められています。現在も多くの量産モデルでは、ボディ、パワートレイン、シャシーを中心に、CPがECU設計の主流となっています。ただし、ソフトウェアトランスフォーメーションの兆候が見え始めています。
カウンターポイントリサーチ社によると、2025年第1四半期における日本のコネクテッドカーの販売は前年比34%増加し、トヨタはそのT-Connectプラットフォームによって43%のシェアを獲得しました。この成長は、ソフトウェア中心のイノベーションへの明確なシフトを示しており、AP（Adaptive Platform）の導入は主にパイロット段階や高級モデルに限られているものの、確実に進展を見せています。
韓国
ヒュンダイや起亜（Kia）などの韓国のOEM企業は、実用的なアプローチを取っています。まずはCP（Classic Platform）を使ってコントロール機能を提供し、次にAPをインフォテインメント、コネクティビティ、テレマティクスに適用する戦略です。その結果、スケールアップが可能であり、進化に柔軟なハイブリッドアーキテクチャ戦略が急速に進化しています。
AUTOSARベースのプラットフォームは、韓国の急成長中の複数のモデルに採用されています。特に、電動SUVや次世代商用車両の新たなプラットフォームに活用されています。韓国のEV目標とソフトウェア定義のビジョンは、中級のAPの拡張にとって魅力的なテストケースとなっています。
アメリカ
米国では、AUTOSARの採用状況はバラバラで、統一された戦略が見られません。GMやフォードなどの大手OEMは、コア生産車両には主にCPを使用している一方で、EV部門や先進技術チームはAPの可能性を探求しています。APは、コネクテッドサービス、集中型コンピューティング、OTAワークフローのための試みが進められています。
一方で、テスラやリビアンなどの非伝統的なプレイヤーは、AUTOSARを避け、カスタムスタックを採用し続けています。それでも、APはTier-1（一次サプライヤー）のR&D部門やスタートアップ企業、AI駆動の安全システムにおいて確実に存在感を高めています。特にISO 26262やツールチェーンの再利用が重要な分野において、APは着実に支持を集めています。
2025年、OEM企業が見過ごせないAUTOSARの課題とリスク
強力なアーキテクチャを持っていても、適切に実行されなければ失敗に終わることがあります。以下はAUTOSAR戦略が行き詰まる主な要因です。回避できるものばかりですが、放置すれば大きな損失につながります。
不適切なプラットフォーム選定
Classic AUTOSARは、安全性ならびにリアルタイム性が極めて重要な分野において依然として最適な選択肢です。しかし、動的なアップデートやスケーラブルなコンピューティングが求められる分野には限界があります。一方、Adaptive AUTOSAR はそうした要件に対応可能ですが、パフォーマンスオーバーヘッドやハードウェア依存といった課題を抱えています。つまり、用途に合わないプラットフォームを選ぶと、システムの複雑化を招き、解決すべき課題が増加する結果となります。プラットフォームはそれぞれのドメインに最適なものを妥協せずに選択することが重要です。
統合を一度きりのプロジェクトとして扱う
多くのチームがAUTOSARの導入が単発で終わると考えがちですが、実際はそうではありません。ソフトウェアは常に進化し、バージョンも変わり続け、サプライヤーも固定されているとは限りません。統合を一度きりのマイルストーンとして扱い、継続的なプロセスとして管理しないと、ズレや手戻り、遅延が発生します。コンプライアンスは、チェックリストの項目として処理するのではなく、納品サイクルに組み込まれた継続的な取り組みとして定着させるべきです。
ツールチェーンのバラつき
統一されたツールチェーンがないまま開発を進めると、CPとAPの実装に早い段階から見えないズレが生じ始めます。 このズレは当初は顕在化しませんが、やがてXMLの処理の不整合やRTE層のミスマッチ、設定フォーマットの非互換性といった形で、プロジェクトの終わりが近づき、スケジュールが逼迫しているタイミングで一気に表面化するのです。そのため、社内チームやサプライヤーネットワーク全体でツールチェーンを標準化することで、スムーズな引き継ぎとトレーサビリティが確保されます。
SWC（ソフトウェアコンポーネント）の検証不足
サプライヤーが提供するSWCは、システム要件に完全に合致しないことが多く、インターフェースの不一致、未定義の実行可能コード、または規格に準拠しない実装が見受けられます。「プラグアンドプレイ」の前提で進めることは非常にリスクが高いため、XMLレベルでの静的検証およびCコード生成時の検証プロセスを早期に確立することが重要です。
ミドルウェアのバージョン管理の怠り
CP and AP toolchains evolve rapidly. Not tracking middleware versions can lead to unexpected changes in runtime behavior and compliance gaps. Version mismatches often surface during integration, not development, and are very difficult to fix at that point. Therefore, planned version control throughout the supply chain is essential.
The risks of neglecting safety and security traceability
While AUTOSAR supports ISO 26262 and automotive cybersecurity standards, this support is not automatic. Without rigorous traceability from requirements to executable code to tests, certification is vulnerable. Traceability must be built in as part of the process, not bolted on after the fact.
summary
While technical standards such as AUTOSAR are becoming mainstream in the industry, the reality is that the ability to apply and deploy them correctly and effectively in the field has not yet caught up. Designing the architecture correctly is now merely a prerequisite; the real challenge is how to actually deploy it in a scalable manner across multiple vehicle types, suppliers, and regions.
VTI supports OEMs and Tier-1 companies with its proven execution capabilities in addressing the practical challenges of AUTOSAR implementation.
From middleware integration to AP/CP platform standardization, our automotive software development team has the AUTOSAR expertise and production-level engineering capabilities to address complex development challenges. Whether launching a new Software Defined Vehicle (SDV) initiative or modernizing legacy assets, VTI designs performance, scalability, and compliance into its products.
If you want to proceed quickly without compromising on quality, please contact us . We fully understand the seriousness of the issue, and will tackle it sincerely to deliver results that meet your expectations.
