コトラ（広報チーム） 
AUTOSARとは何か
車載ソフトウェア開発の共通ルール
AUTOSARは、AUTomotive Open System ARchitectureの略称で、自動車に搭載される電子制御ユニットであるECUのソフトウェアを、共通の考え方と仕様に基づいて開発するための枠組みです。特定の製品や開発ツールの名称ではなく、自動車メーカー、部品メーカー、半導体メーカー、ソフトウェア企業などが利用するソフトウェアアーキテクチャの標準です。
AUTOSARでは、ソフトウェアの構造、部品同士のつなぎ方、通信方法、設定情報の交換形式などを定めます。これにより、異なる会社や開発チームが作成したソフトウェアであっても、定められたルールに沿って組み合わせやすくなります。
AUTOSARが標準化された背景
自動車には、エンジン、ブレーキ、操舵、照明、空調、ドア、メーター、運転支援など、多数の機能が搭載されています。それぞれの機能を制御するECUにはソフトウェアが必要であり、車両の高機能化に伴って、開発するソフトウェアも大規模かつ複雑になっています。
従来は、自動車メーカーや部品メーカーごとに独自のソフトウェア構造や接続方法を採用するケースが多くありました。この場合、車種やECU、使用するマイコンが変わるたびに、既存ソフトウェアを大きく修正しなければならないことがあります。また、複数の会社が関わる開発では、仕様のすり合わせや統合作業の負担も増えます。
こうした課題に対応するため、AUTOSARは2003年に発足しました。ソフトウェアの共通ルールを設け、再利用性、移植性、連携のしやすさを高めることが、標準化の主な目的です。
分業と部品の再利用を支える仕組み
AUTOSARの重要な特徴は、ソフトウェアを機能ごとの部品として扱いやすくする点です。例えば、ある制御機能をソフトウェアコンポーネントとして設計し、入出力の仕様を明確にしておけば、別のECUや車種へ展開しやすくなります。
また、AUTOSARはアプリケーションの内部アルゴリズムそのものを一律に決めるものではありません。競争力につながる制御ロジックは各社が設計しつつ、ソフトウェア部品間で受け渡す情報や接続方法を共通化します。つまり、独自性を保つ部分と、連携のために標準化する部分を分ける考え方です。
開発に必要な情報は、AUTOSAR XMLと呼ばれる形式で記述されます。この記述には、ソフトウェア部品の構成、入出力、ECUへの配置、通信設定などが含まれます。ツール間で設定情報を受け渡しやすくなるため、複数の組織や工程にまたがる開発を進めやすくなります。
AUTOSARが使われるECUの例
AUTOSARは、車両内の幅広いECUで活用できる考え方です。特にClassic Platformは、決められた周期で確実に処理を実行する必要がある制御系ECUに適しています。
対象となるECUの例には、次のようなものがあります。
- エンジンや電動モーターを制御するECU
- 変速機を制御するECU
- 電子安定制御や電動パーキングブレーキなどを扱うシャシー系ECU
- ドア、ワイパー、ライト、空調などを制御するボディ系ECU
- 駐車支援、盗難防止、リモートキーなどを扱うECU
- 電池管理や充電制御を担う電動車向けECU
一方で、高い演算性能を必要とする運転支援、車両情報サービス、統合コックピットなどでは、Adaptive Platformが利用される場面があります。
AUTOSARが目指す車載ソフト開発
ソフトウェアとハードウェアを分けて考える理由
AUTOSARは、車両の機能を実現するアプリケーションソフトウェアと、マイコンや通信回路などのハードウェアに近いソフトウェアを分けて考えます。この分離により、ハードウェアの変更があっても、上位の制御ロジックに与える影響を抑えやすくなります。
例えば、同じ制御機能を別のマイコンへ移す場合、ハードウェアに直接依存した作りでは、多くのソースコードを見直す必要があります。AUTOSARでは、ハードウェアとの差を基本ソフトウェアが吸収するため、アプリケーションの変更範囲を限定しやすくなります。
この仕組みは、複数の車種やグレードで共通のソフトウェアを使う場合にも有効です。共通部分を活用しながら、車種ごとの仕様差に対応しやすくなります。
開発会社や部門をまたぐ連携
車載ソフトウェア開発では、自動車メーカー、部品メーカー、ソフトウェア開発会社、半導体メーカーなど、多くの関係者が関わります。社内でも、システム設計、アプリケーション開発、基本ソフトウェア設定、通信設計、テストなど、役割が分かれます。
AUTOSARは、部品同士の接続方法や設定情報の表現を共通化することで、こうした分業を支えます。誰がどの機能を担当するかを明確にし、決められたインターフェースで成果物を渡すことで、統合時の認識違いを減らすことが可能です。
ただし、AUTOSARを採用すれば自動的に連携が円滑になるわけではありません。インターフェースの責任範囲、設定変更の手順、バージョン管理、テスト分担などを、開発体制として整備する必要があります。
品質と安全性を高める考え方
自動車の制御ソフトウェアには、高い信頼性が求められます。特にブレーキ、操舵、駆動、乗員保護に関わる機能では、異常が重大な事故につながる可能性があります。
AUTOSARは機能安全規格そのものではありませんが、責任範囲を分け、インターフェースを明確にし、共通機能を標準化することで、安全性や品質を考慮した設計を進めやすくします。診断、通信、メモリ管理、監視などの基本機能を体系的に扱える点も特徴です。
品質を高めるには、AUTOSARの構造だけでなく、要求の明確化、レビュー、単体テスト、結合テスト、実機テスト、変更管理を一貫して行う必要があります。AUTOSARは、そのための開発基盤の一部と位置付けることが重要です。
仕様を共通化することの重要性
異なる会社が作ったソフトウェアを組み合わせるには、データの意味、単位、更新タイミング、異常時の扱いなどを一致させなければなりません。単に通信できるだけでは、正しく連携できるとは限りません。
AUTOSARでは、ソフトウェア部品の接続口であるポートや、送受信するデータ、サービスの呼び出し方などを定義します。共通仕様を用いることで、開発者は相手側の内部実装を細かく知らなくても、必要な情報を利用しやすくなります。
特に複数ECUにまたがる機能では、仕様の共通化が重要です。車両全体としてどのECUが何を担当し、どの信号をどこへ送るかを整理することで、統合作業や変更時の影響確認を進めやすくなります。
AUTOSAR Classic Platformの3層構造
アプリケーション層の役割
Classic Platformは、マイコン上で動作するソフトウェアを大きく3層に分けます。最上位にあるのがアプリケーション層です。この層には、車両機能を実現するソフトウェアコンポーネントが配置されます。
ソフトウェアコンポーネントは、例えばモーター制御、ランプ制御、温度制御、故障判定といった個別機能を担います。各コンポーネントは、必要なデータを受け取り、計算や判断を行い、結果を別のコンポーネントや下位ソフトウェアへ渡します。
アプリケーション層は、できるだけハードウェアから独立した形で設計されます。そのため、制御対象や入出力の意味に集中して開発しやすくなります。
RTEが担うソフトウェア間の橋渡し
RTEはRuntime Environmentの略で、アプリケーション層と基本ソフトウェアの間に置かれる橋渡しの仕組みです。アプリケーション層のソフトウェアコンポーネント同士の通信や、コンポーネントから基本ソフトウェアの機能を利用するための接続を担います。
RTEを介することで、アプリケーションは、相手のソフトウェアが同じECU内にあるか、別のECUにあるかを意識せずに設計しやすくなります。通信の実装やハードウェアの違いを、アプリケーションから見えにくくする役割を持ちます。
RTEは一般に、ECUごとの構成情報に基づいて生成されます。どのソフトウェアコンポーネントをどのECUに配置するか、どのデータをどの通信経路で送るかといった設定に応じて、必要な接続処理が作られます。
BSWが担う車両や機器との接続
BSWはBasic Softwareの略で、アプリケーションが動作するための土台となる基本ソフトウェアです。通信、診断、メモリ、OS、入出力、マイコン制御など、車両やECUを動かすための共通機能を提供します。
アプリケーション層が車両機能の判断や制御内容を担うのに対し、BSWはCANやEthernetなどを用いた通信、センサーやアクチュエーターへの接続、不揮発性メモリへの記録、異常情報の管理などを担います。
BSWは、サービス層、ECU抽象化層、マイコン抽象化層に分けられます。さらに、標準的な構成では対応しにくい特殊なハードウェアや処理に対応するため、複合ドライバも用意されています。
3層構造による変更しやすさと再利用性
3層構造の狙いは、変更の影響を局所化することです。例えば、アプリケーション層の制御ロジックを改善する場合、通信ドライバやマイコン制御の処理まで直接修正しなくて済むように設計します。
反対に、使用するマイコンや周辺回路を変更する場合も、主に下位層を見直すことで、アプリケーションの修正量を抑えられる可能性があります。すべての変更を完全に吸収できるわけではありませんが、責任範囲が分かれているため、影響を把握しやすくなります。
また、一定のインターフェースに沿って作られたソフトウェアコンポーネントは、別の車種やECUに展開しやすくなります。再利用する際も、どの部分が共通で、どの部分を設定変更すべきかを整理しやすい点が利点です。
VFBで実現する機能中心の設計
VFBはVirtual Functional Busの略で、日本語では仮想機能バスと表現されます。これは、アプリケーションを実際のECUや通信方式から切り離し、機能同士のつながりを先に考えるための概念です。
VFBでは、ソフトウェアコンポーネントが専用のポートを通じて情報をやり取りします。この段階では、通信がCANなのかEthernetなのか、同じECU内の通信なのか別ECU間の通信なのかを細かく意識しません。
その後、車両全体の設計に基づいて、各機能をどのECUに配置するかを決めます。VFBの考え方を用いることで、ハードウェア構成より先に車両機能を整理し、設計変更にも対応しやすくなります。
BSWの主な構成と役割
サービス層が提供する共通機能
サービス層は、ECU全体で利用する共通機能を提供する層です。代表的な機能には、OS、通信、診断、メモリ管理、ECU状態管理、監視、暗号関連のサービスなどがあります。
通信サービスは、アプリケーションからのデータを車載ネットワークで送受信するための処理を担います。メモリサービスは、設定値や故障情報などを不揮発性メモリに保存する際に利用されます。診断サービスは、外部の診断機器との通信や、故障情報の管理を支えます。
これらの機能を共通部品として扱うことで、各アプリケーションが個別に通信やメモリ制御を実装する必要を減らせます。
ECU抽象化層が吸収する機器ごとの差
ECU抽象化層は、センサー、アクチュエーター、外部メモリ、通信装置など、ECUに接続される機器の違いを上位層から隠す役割を担います。
例えば、上位のソフトウェアが特定のセンサー値を取得したい場合、センサーの接続方法や部品ごとの細かな違いを直接意識しないようにします。これにより、部品変更やECU構成変更が発生した場合でも、上位ソフトウェアへの影響を抑えやすくなります。
ECU抽象化層は、車両やECUの構成に近い部分を扱うため、プロジェクトごとの設定や実装が必要になることがあります。
マイコン抽象化層が担うハードウェア制御
マイコン抽象化層は、MCALとも呼ばれます。マイコンに内蔵されているタイマー、入出力端子、アナログ入力、通信機能、メモリなどを制御するための標準的なインターフェースを提供します。
マイコンごとに、周辺機能のレジスタ構成や制御方法は異なります。MCALはこうした差を吸収し、上位ソフトウェアがマイコン固有の細部に依存しないようにします。
MCALの品質や対応範囲は、ECU開発の安定性に大きく影響します。利用するマイコン、必要な通信方式、入出力、性能要件に対して、必要な機能が提供されるかを事前に確認することが重要です。
複雑な制御に対応する複合ドライバ
複合ドライバは、標準的なBSWやMCALだけでは対応しにくい機能を扱うための仕組みです。特殊なハードウェア、厳しい時間制約、独自の制御方式などがある場合に利用されます。
例えば、特定の周辺回路に対して独自の制御が必要な場合や、標準モジュールを経由すると性能要件を満たしにくい場合に、複合ドライバを検討します。ただし、複合ドライバを増やしすぎると、標準化による再利用性や保守性が低下するおそれがあります。
導入する際は、なぜ標準モジュールでは対応できないのかを明確にし、アプリケーション層やRTEとの接続方法、テスト方法、保守責任を整理する必要があります。
Classic PlatformとAdaptive Platformの違い
Classic Platformが向く制御の特徴
Classic Platformは、マイコン上で動作する組込み制御向けのプラットフォームです。あらかじめ構成を決めておき、定められた周期や条件で処理を実行する用途に向いています。
ブレーキ、操舵、駆動、ボディ制御などでは、処理時間の予測しやすさと安定した動作が重視されます。Classic Platformは、このようなリアルタイム性が求められるECUで活用されています。
アプリケーション、RTE、BSWという3層構造を中心に、限られたメモリや処理能力の中で、必要な制御を確実に実行することを重視しています。
Adaptive Platformが向く高性能な処理
Adaptive Platformは、高性能なプロセッサを使い、より柔軟なアプリケーション実行を必要とする用途に向いています。運転支援、自動運転に関わる処理、統合コックピット、車両データ活用、外部サービスとの連携などが主な対象です。
これらの機能では、大量のセンサーデータを扱ったり、複数のアプリケーションを並行して動かしたり、機能追加や更新に対応したりする必要があります。Adaptive Platformは、こうした高い演算能力と変化への対応力を求める領域を想定しています。
POSIXに基づくOS環境を利用できる点も特徴です。従来のマイコン向けECUよりも高性能な計算機上で、複数のアプリケーションを実行しやすい構成となっています。
通信方式と実行環境の違い
Classic Platformでは、CAN、LIN、FlexRay、Ethernetなどの車載通信を利用し、あらかじめ定義した設定に従って通信や処理を実行する構成が中心です。RTEがアプリケーションとBSWの間をつなぎ、コンポーネントベースで機能を組み立てます。
Adaptive Platformでは、サービス指向の考え方が重要になります。アプリケーションは、提供されているサービスを探し、必要に応じて利用します。通信では、Ethernetを基盤としたSOME/IPなどが活用されます。
また、Classic Platformでは静的な構成が基本であるのに対し、Adaptive Platformではアプリケーションの配置、起動、停止、更新などをより柔軟に管理することが想定されています。
ECUの用途に応じた使い分け
Classic PlatformとAdaptive Platformは、どちらか一方が常に優れているわけではありません。求められる性能、時間制約、ハードウェア資源、更新頻度、安全要求に応じて選ぶ必要があります。
Classic Platformは、決まった処理を安定して繰り返す制御系ECUに適しています。Adaptive Platformは、高い演算性能、サービス連携、動的な更新や拡張が必要なECUに適しています。
実際の車両では、両方のプラットフォームを組み合わせる構成も考えられます。例えば、車両を直接制御する機能はClassic Platformで実装し、高度な認識・判断や外部連携を行う機能はAdaptive Platformで扱うといった分担です。
SDVでAdaptive Platformが注目される理由
SDVはSoftware Defined Vehicleの略で、ソフトウェアによって車両の機能や価値を継続的に高めていく考え方です。車両販売後も、ソフトウェア更新によって機能追加や改善を行うことが重視されます。
Adaptive Platformは、アプリケーションの更新、サービス間連携、高性能な計算機の活用に対応しやすいため、SDVの実現に向けた基盤の一つとして注目されています。運転支援、コネクテッドサービス、統合ECUなどでは、従来よりもソフトウェアの変更頻度が高まることが想定されます。
ただし、SDV対応はAdaptive Platformの導入だけで実現するものではありません。ソフトウェア更新の仕組み、セキュリティ対策、車両全体のE/Eアーキテクチャ、運用体制、検証体制を含めて設計することが必要です。
AUTOSAR導入のメリットと課題
ソフトウェアを再利用しやすくなる
AUTOSARの大きなメリットは、ソフトウェア部品を再利用しやすくなることです。アプリケーションの接続方法や基本ソフトウェアの構造を標準化することで、すでに開発・検証した資産を別の車種やECUへ展開しやすくなります。
再利用できるのは、アプリケーションの制御ロジックだけではありません。通信、診断、メモリ管理などの共通機能についても、標準モジュールや設定資産を活用できる可能性があります。
ただし、再利用性は設計品質に左右されます。特定車種の信号名やハードウェア条件をアプリケーション内部に直接書き込むと、他案件への展開は難しくなります。再利用を前提とした責任分割とインターフェース設計が重要です。
開発の役割分担を進めやすくなる
AUTOSARでは、アプリケーション開発、RTE設定、BSW設定、マイコン制御、統合テストなどの役割を整理しやすくなります。各担当が作成する成果物と、他チームへ渡す情報を明確にすることで、大規模開発における連携を進めやすくなります。
また、AUTOSAR XMLによる情報交換を用いることで、ツールや組織が異なる場合でも、構成情報を共有しやすくなります。システム全体の設計からECU単位の設定まで、情報のつながりを管理しやすい点も利点です。
一方で、分業が細かくなりすぎると、全体を把握する人材が不足するおそれがあります。部門間の受け渡しだけでなく、車両全体の機能、通信、性能、安全性を横断して確認する体制が必要です。
品質管理と安全設計に取り組みやすくなる
標準化された構造を利用すると、各機能の責任範囲や接続条件を明確にしやすくなります。これは、レビュー、テスト、異常時の確認、変更影響の調査を行ううえで有効です。
例えば、診断、監視、通信、メモリ保存といった共通機能を体系的に扱えるため、品質上の抜け漏れを減らすための土台になります。ソフトウェア部品ごとの入出力や実行条件を管理することで、テスト観点も整理しやすくなります。
ただし、AUTOSAR準拠であること自体が品質や安全性を保証するものではありません。要求定義、設計、実装、検証、変更管理を適切に実施し、機能安全やサイバーセキュリティに関する要求を個別に満たす必要があります。
設定作業や学習にかかる負担
AUTOSARの導入には、一定の学習コストと設定作業が伴います。アプリケーションを作るだけでなく、ソフトウェアコンポーネントの定義、ECUへの配置、通信、診断、OS、メモリなど、多くの設定項目を理解する必要があります。
特に初学者にとっては、RTE、BSW、MCAL、VFB、ポート、AUTOSAR XMLといった用語が多く、全体像をつかみにくい場合があります。また、設定ツールの使い方や、生成されたコードの確認方法を習得することも必要です。
導入初期には、必要以上に多くのモジュールを使おうとせず、対象ECUに必要な範囲を見極めることが重要です。小規模なECUや限定した機能で経験を積み、設計・設定・テストの流れを理解したうえで適用範囲を広げる方法が有効です。
導入前に確認したい開発体制と対象範囲
AUTOSARの導入を検討する際は、最初に対象ECUと目的を明確にする必要があります。再利用性を高めたいのか、複数社での連携をしやすくしたいのか、将来の車種展開に備えたいのかによって、適した進め方は異なります。
確認すべき主な項目は次のとおりです。
- 対象ECUがClassic PlatformとAdaptive Platformのどちらに適するか
- 使用するマイコンやプロセッサに必要な基本ソフトウェアが対応しているか
- 通信、診断、メモリ、セキュリティなどで必要な機能は何か
- アプリケーション、BSW、統合、テストを誰が担当するか
- AUTOSAR XMLを含む設定情報をどのように管理するか
- 既存ソフトウェアをどこまで移行し、どこをそのまま活用するか
- テスト環境と変更管理の手順をどう整備するか
AUTOSARは、車載ソフトウェア開発における分業、再利用、品質向上を支える有力な共通基盤です。一方で、効果を得るには、標準を導入することだけを目的にせず、自社の開発対象、組織体制、既存資産、将来の製品計画に合わせて適用範囲を設計することが重要です。
