車載ネットワーク
車載ネットワークとは
自動車の電子化が急速に進む中、ECU（電子制御ユニット）間の効率的かつ信頼性の高い通信を可能にする車載ネットワーク技術が重要性を増しています。車載ネットワークは、異なるECU間を相互接続し、車両全体の効率的な制御・監視を実現するための基盤技術です。
車載ネットワークとは、車両内の複数のECU（電子制御ユニット）が互いに通信するための通信基盤やシステムを指します。このネットワークがあってこそ、各ECUは情報を共有でき、全体として連携した動作が可能になります。
目次
車載ネットワーク通信の特長
主な車載ネットワーク規格
車載ネットワークには、用途や性能に応じてさまざまな通信規格があります。以下は車載制御通信で使用されている通信規格です。
自動車の基本的な通信規格として広く普及しているCANは、信頼性が高く、リアルタイム制御を必要とするエンジンやブレーキなど重要なシステムで利用されています。
従来のCANを拡張した規格で、通信速度とデータ容量を向上させ、より多くの情報を高速で処理できるようにしています。
低コスト、低速な通信を目的としており、パワーウィンドウやドアロックなど、比較的シンプルな機能の制御に適しています。
日本で規格化された通信プロトコルで、LINとCANの中間的な位置付けです。同期通信が必要な照明制御やエアコン制御に利用されています。
安全性と高速通信が要求される先進運転支援システム（ADAS）やステアリング、ブレーキ制御など、安全に関わるシステムに用いられています。
車両の情報量が増える中、カメラやレーダーなど高速通信を要求されるシステムで利用が拡大しています。規格には100BASE-T1や10BASE-T1Sなどがあります。
図：車載通信プロトコル比較
各ネットワーク規格の特性比較
車載制御通信規格は、それぞれにリアルタイム性、信頼性、遅延特性が異なります。
| 通信プロトコル | リアルタイム性 | 信頼性 | 用途 |
|---|---|---|---|
CAN | 短い遅延での通信が可能。割り込み処理により高い反応性を実現しています。 | エラー検出やリトライ機構が充実しており、堅牢な通信を提供 | エンジン制御やブレーキ制御など、ミッションクリティカルなシステムで広く採用 |
CAN FD | 標準CANよりも高速なデータ転送が可能 | 1フレームあたり最大64バイトまでのデータ転送をサポートし、複雑な制御情報のやり取りが容易 | 高速かつ大量のデータが必要なアプリケーション（例えば、先進運転支援システム）で採用される |
LIN | CANに比べ遅延はやや大きいが、低速通信で十分な制御が可能 | シンプルな構造のためコストパフォーマンスが高いが、エラー処理はCANほど高度ではない | パワーウィンドウやシート調整など、低速・低コストな車載機能に適用 |
CXPI | 低速通信ながらも、リアルタイム性を確保しつつシンプルな通信を実現 | マスター・スレーブ方式を採用し、低コストで実装できることが強み | エアコン、照明制御など、コスト重視かつ非クリティカルなシステム向けに最適化されている |
FlexRay | 高いデータ転送速度と、非常に短い遅延での通信が可能 | 冗長性のある通信路設計が施され、耐障害性が高い | 先進運転支援システム（ADAS）や自動運転システムなど、クリティカルなアプリケーション向け |
車載Ethernet | 従来のイーサネットよりもリアルタイム性を強化した仕様（例：Time-Sensitive Networking: TSN）が採用されている | 大容量データの伝送や複雑なネットワーク構成が可能で、拡張性に優れる | インフォテインメントシステムや高帯域幅を必要とするデータ通信に適用 |
各通信規格の概要解説は以下のページをご覧ください。
協調制御とリアルタイム通信の重要性
各ECUは、車両の安全や快適な走行を実現するために、互いにリアルタイムで情報交換を行いながら協調制御を実現しています。リアルタイム通信により、各ネットワーク規格が持つ特性（低遅延、高信頼性、高速伝送など）を活かし、各ECUが連携して迅速な制御判断を下すことが可能となります。これにより、緊急時の迅速な対応や、車両全体の動作の最適化が図られ、全体としての安全性と信頼性が向上します。
リアルタイム通信が正確かつ迅速に行われることは、各ECUが協調して動作する上で不可欠です。
協調制御とは、車載ネットワークを活用して、複数のECUが互いに連携しながら最適な制御判断を行い、車両全体の性能や安全性を高める制御方式です。
車載ネットワークでは、各ECU（電子制御ユニット）は独立して単独で動作するのではなく、互いにリアルタイムで情報を交換しながら連携して制御を行います。たとえば、エンジン制御、ブレーキ、ステアリングなどの主要な機能は、各ECUが自らのデータだけでなく、他のECUから受信する情報を基に協調動作を実現するため、車両全体として安全かつ効率的な運転が可能となります。
つまり、車載ネットワークの信頼性、安全性、安定性は、自動車の総合的な安全と安心に直結します。各ECU間の情報交換が正確かつ迅速に行われることで、緊急時の適切な対策が可能となり、予期せぬトラブルの発生リスクを低減します。こうした高い信頼性と安定性が確保されることにより、車両全体の制御システムが常に最適な状態で動作し、乗員に対して安全で安心な走行環境を提供する基盤となります。
遅延の低減とコストのバランス
各通信規格は、その特性に応じたリアルタイム性を持ち、システム全体の応答速度向上に寄与します。例えば、CANやFlexRayは低遅延で高い信頼性を実現する一方、CAN FDは高速なデータ転送と大容量データの送受信を可能にします。しかし、これらの規格には実装や運用にかかるコストも存在します。
通信規格の選択にあたっては、必要なリアルタイム性や信頼性だけでなく、システム全体のコストとの兼ね合いを考慮する必要があります。高性能なネットワークは開発コストやハードウェアコストが高くなる可能性があるため、用途に応じて最適なバランスを取ることが重要です。つまり、要求される応答速度と安全性を満たしながら、コストパフォーマンスに優れた規格を採用することが、車載ネットワーク全体の効率と経済性を向上させるポイントとなります。
車載ネットワークとOSI参照モデルの基礎
自動車は高度な電子化が進んでおり、例えばエンジン制御、ブレーキ制御、ADAS（先進運転支援システム）など、多くの制御ユニット（ECU）が連携して動作しています。こうした連携には、安定かつ確実な通信が必要です。その通信規格を理解する上で欠かせないのがOSI参照モデルです。
車載ネットワークにおけるOSI参照モデルの理解は、通信規格やECU間の連携を効果的に設計・管理するための基本的な知識となります。特にCAN通信やAUTOSARの各モジュールがOSIモデルのどの階層に対応するかを把握することが、適切なシステム設計および運用において非常に重要となります。
OSI参照モデル
OSI（Open Systems Interconnection）参照モデルは、通信機能を7つの階層（レイヤー）に分けて定義した概念モデルです。各レイヤーが特定の役割を担い、通信プロトコルを効率的かつ明確に整理しています。
各通信レイヤーでは、そのレイヤー固有のPDU（Protocol Data Unit：データ単位）が使用され、通信機器間の対応するレイヤー同士で1対1や1対多の通信が行われます。
レイヤーごとにPDUのデータ構成が異なるのは、上位レイヤーから下位レイヤーへデータが渡されるたびに、そのレイヤーに固有の制御情報（ヘッダ）がPDUに付加される仕組みのためです。このようにレイヤーごとに制御情報を付加する処理を「カプセル化（Encapsulation）」、逆に付加された制御情報を取り除いてデータを復元する処理を「非カプセル化（Decapsulation）」と呼びます。
| OSI参照モデル レイヤー | 説明 |
|---|---|
第7層（最上位） アプリケーション層 | 通信するアプリケーション間のインターフェースを提供 |
第6層 プレゼンテーション層 | データ形式の変換、圧縮、暗号化を担当 |
第5層 セッション層 | 通信の開始・終了や通信状態の管理 |
第4層 トランスポート層 | エラー訂正やデータ転送の信頼性を管理 |
第3層 ネットワーク層 | 通信経路の選択やルーティングを担当 |
第2層 データリンク層 | 隣接するノード間の通信制御とエラー検出 |
第1層（最下位） 物理層 | 物理的な通信媒体を通じての電気的・機械的接続 |
コラム：フレーム、メッセージ、シグナルの違い
CAN通信を扱っていると「CANフレーム」や「CANメッセージ」「シグナル」という用語が出てきますが、これらの違いは、OSI参照モデルのどのレイヤーの視点でデータを捉えているかに起因しています。
「フレーム」という用語は一般的に、OSI参照モデルのデータリンク層（第2層）のデータ単位を指します。
CANフレームには以下のような構成要素があります。
これらは、CANプロトコルが通信媒体上でデータを送信するために必要な基本的な構成要素です。
つまり、「CANフレーム」は主に、CANの通信規格そのものをデータリンク層（第2層）の視点で表現したものです。
「CANメッセージ」という用語は、OSI参照モデルのアプリケーション層（第7層）で扱う論理的なデータを指す場合に用いられることが多いです。
CANメッセージは、アプリケーション視点での「意味のあるデータ」や、「送信元のECUが他のECUへ伝えたい特定の情報」を指します。
例えば、以下のようなデータがCANメッセージの一例です。
また、アプリケーション層のプロトコル（例えば CANベースの診断プロトコルUDS、CANopen、J1939 など）から見た場合、それぞれ固有のフォーマットやID体系を持ったメッセージをCANフレームに載せて通信しています。このアプリケーション層の論理的なデータ単位が「CANメッセージ」です。
「シグナル」という用語は、OSI参照モデルの アプリケーション層（第7層） で定義される、CANメッセージ内の個々のデータ項目を指します。
例として、以下のような構成を持つCANメッセージ（ID: 0x100, 8バイト）を考えます。
このように、一つのCANメッセージには、複数のシグナルが含まれることがあります。
シグナルはCANメッセージの一部を構成する個々のデータ項目であり、アプリケーション視点での「意味のある情報」です。
それらをまとめて送信する単位が「CANメッセージ」になります。
CAN通信および診断通信のOSI参照モデルと規格概要
以下は、CAN関連プロトコル（OSEK/VDX CAN通信、AUTOSAR）および代表的な車載診断通信（UDS、OBD）のOSIモデルにおける位置付けと規格概要を示したものです。
自動車のネットワーク通信で広く使用されているCAN（Controller Area Network）は、OSI参照モデルの第1層と第2層を中心に規定されています。
また、CAN通信では、さらに上位の通信制御としてCAN COM（Communication）やCAN NM（Network Management）が存在します。
AUTOSAR（Automotive Open System Architecture）で用いられるダイアグ（診断）およびリプログ（再プログラミング）モジュールは、主にOSI参照モデルの第7層（アプリケーション層）に該当します。これらは高次のサービスとして動作し、診断情報の送受信やソフトウェアアップデート処理を提供します。
| レイヤー | OSEK/VDX CAN通信 | AUTOSAR CAN関連モジュール | UDS (Unified Diagnostic Services) | OBD (On-Board Diagnostics) |
|---|---|---|---|---|
アプリケーション層 | ー | Dcm, Dem, FiM, FBL, NvM | 診断通信 (ISO14229-1) | OBD診断通信 (ISO15031-5) |
プレゼンテーション層 | ー | ー | ー | ー |
セッション層 | NM機能（OSEK NM, ISO17356-5） | CanNm, CanSM | UDSセッション制御 (ISO14229-2) | ー |
トランスポート層 | COM機能（OSEK COM, ISO17356-4） | CanTp, Com, PduR | 診断通信トランスポート (ISO15765-2) | ー |
ネットワーク層 | ー | CanIf | 診断通信ネットワーク (ISO15765-2) | OBD診断ネットワーク (ISO15765-4) |
データリンク層 | CAN通信（ISO11898-1） | CanDrv | CANデータリンク (ISO11898-1) | OBD診断データリンク (ISO15765-4) |
物理層 | CAN物理層（ISO11898-2） | CAN物理層 | CAN物理層 (ISO11898-2) | OBD診断物理層 (ISO15765-4) |
ソフトウェアアーキテクチャの統一
自動車が高度化する現代、エンジン制御、ブレーキ、車内インフォテインメント、先進運転支援システム（ADAS）など、各種機能を担う電子制御ユニット（ECU）の数は年々増加しています。これらのECUが個別に開発される中で、全体としてシームレスに連携し、車両全体の安全性や効率性を確保するためには、統一されたソフトウェアアーキテクチャが不可欠です。
統一アーキテクチャがもたらすメリット
各ECUが異なるメーカーやサプライヤーによって開発されると、ソフトウェアや通信プロトコルの違いにより、互いの連携が難しくなる場合があります。統一されたアーキテクチャを採用することで、共通の通信プロトコルやインターフェースが定義され、部品同士の互換性が向上し、システム全体の統合が容易になります。
統一アーキテクチャに基づく開発では、既存のソフトウェアコンポーネントやモジュールを複数のプロジェクトで再利用できるため、新たにゼロから実装する必要がなくなります。これにより、開発期間の短縮やコスト削減が実現され、迅速な市場投入が可能になります。
車載システムはリアルタイム性と安全性が非常に重要です。統一されたOSや通信仕様（たとえば、OSEK/VDKやAUTOSAR）を採用することで、各ECU間のタスク管理、割り込み処理、通信エラーの検出・再送制御、ネットワーク管理などが統一されたルールに基づいて行われ、全体として信頼性が向上します。
統一アーキテクチャは、業界全体での共通規格として機能するため、企業間の連携や情報共有が容易になり、全体としての技術水準向上につながります。これにより、自動車業界全体が、将来的な自動運転やコネクティビティなどの新たな要求に柔軟に対応できる基盤が整います。
車載システムに関わる代表的な規格：OSEK/VDKとAUTOSAR
OSEK/VDKは、1980年代後半から1990年代にかけて策定された車載システム向けリアルタイムOSの標準規格です。OSEK（Open Systems and their Interfaces for the Electronics in Motor Vehicles）は、ECU間で共通のソフトウェアプラットフォームを提供するための仕様であり、VDK（Virtual Development eXecutive）はその実装例や開発支援ツールを指します。
OSEK/VDKは、タスク管理、割り込み処理、通信（COM機能）、ネットワーク管理（NM機能）といった基本機能を統一的に提供することで、複数のECU間の互換性や再利用性を高め、全体としての安全性とリアルタイム制御を実現してきました。
2000年代に入り、車載システムの複雑化や安全性、機能拡張の要求が高まる中で、OSEK/VDKの概念を受け継ぎながらさらに拡張されたのがAUTOSARです。AUTOSAR（Automotive Open System Architecture）は、基本ソフトウェア層（BSW）、ミドルウェア、アプリケーション層など、多層構造により車載ネットワーク全体を包括的にカバーする統一プラットフォームです。通信、診断、安全機能など、幅広い要件に対応し、ECU間の連携をさらに強固なものにしています。
統一されたアーキテクチャが車載ネットワークに与える影響
統一されたソフトウェアアーキテクチャを採用することで、車載ネットワーク全体の設計がシンプルになり、各ECU間の通信が標準化されたルールに基づいて行われるようになります。結果として、互換性と再利用性が向上し、開発コストが削減されるだけでなく、システム全体の安全性や信頼性も高まります。
また、業界全体での標準化が進むことで、各社が共同で技術開発に取り組む環境が整い、将来的な自動運転技術やコネクティビティへの対応もスムーズに進むことが期待されます。
OSEK/VDX
OSEK/VDKは、1980年代後半から1990年代にかけて策定された、車載システム向けリアルタイムOS（RTOS）の標準規格です。自動車の電子制御ユニット（ECU）は、エンジン制御、ブレーキ、車内情報システムなど多様な機能を担っていますが、各ECUは異なるメーカーや部品ごとに開発されるため、システム全体の安全性や効率性を確保するには、統一されたソフトウェアアーキテクチャが必要不可欠です。
OSEK/VDKは、こうした背景のもと、タスク管理、割り込み処理、通信（COM機能）およびネットワーク管理（NM機能）といった基本的なOS機能を一元的に提供することで、複数のECU間での互換性とソフトウェアの再利用性を高めることを目的としています。
OSEK/VDKは、車載ネットワークにおけるリアルタイム制御と信頼性の高い通信基盤を実現するための中核技術として、自動車業界で長年にわたり利用されてきました。
OSEK/VDXの基本構成
OSEK/VDXは、OSとしての基本機能だけでなく、通信機能（COM機能）、ネットワーク管理（NM機能）など、車載システム固有の要件に対応するモジュールが組み込まれています。
リアルタイムOSとしての基盤提供
OSEK/VDKは、車載システムにおけるタスク管理、スケジューリング、割り込み処理など、リアルタイム性が求められる機能を統合したOSとして動作します。これにより、各ECUが複数のタスクを効率的に並行処理し、タイムクリティカルな制御を確実に実施できます。
通信サービスの標準化
OSEK/VDKは、COM機能やNM機能を含む通信サービスを標準化しています。
図：CAN通信におけるCOM，NM機能
OSEK/VDXのCOM機能は、上位アプリケーションとCANやLINなどの車載通信ハードウェアとの間のデータの送受信を抽象化します。これにより、アプリケーションはハードウェアの詳細を意識せずに信頼性の高いデータ転送が可能となります。さらに、再送制御やエラー検出といった信頼性確保の機能も備え、トランスポート層の役割を果たしています。
NM機能は、各ECUの状態監視、ノードの起動・スリープ管理、通信セッションの確立と終了など、セッション層に相当する機能を提供します。これにより、車載ネットワーク全体の健全性が維持され、障害発生時の再同期や復旧が円滑に行われます。
OSEK/VDXの特徴と利点
OSEK/VDXは業界標準として採用されているため、複数のメーカーが共通のプラットフォーム上で開発を行うことができます。これにより、ソフトウェアの再利用性が高まり、開発コストの低減と製品の互換性向上が実現されます。
リアルタイムOSとして、厳しいタイムクリティカルな環境下でも確実なタスク管理やエラー処理を提供するため、車載システムに要求される安全性を担保します。エラーチェック機能や再送制御、ネットワーク管理機能が統合されており、万一の障害発生時にも迅速な復旧が可能です。
COMおよびNM機能によって、各ECU間の通信が効率的かつ堅牢に行われるため、システム全体のパフォーマンスと信頼性が向上します。これにより、車載ネットワークの統合制御が円滑に実現されます。
自動車産業におけるOSEK/VDXの意義
OSEK/VDXは、車載ECU間の協調動作と安全な通信を実現するために設計されたリアルタイムOSの仕様です。自動車業界では、ECUの高度な制御と安全性が求められる中で、OSEK/VDXはその要求に応えるための基盤技術となっています。
タスク管理、通信サービス、ネットワーク管理といった多岐にわたる機能を統合することで、車載システムの複雑な要求に応え、高い信頼性と安全性を提供します。自動車業界において、共通の開発プラットフォームとしての役割を果たし、製品の品質向上や開発効率の改善に大きく寄与していると言えるでしょう。
AUTOSARとは
AUTOSAR（Automotive Open System Architecture）は、世界中の自動車メーカーや部品サプライヤーが連携して車載ソフトウェアの標準化を目的としたコンソーシアムであり、そのコンソーシアムが策定した標準仕様の両方を指します。AUTOSARでは、自動車メーカーや部品サプライヤーが開発したECU（Electronic Control Unit：電子制御ユニット）やソフトウェアの再利用性と相互運用性の向上を目的として統一されたソフトウェアアーキテクチャを定義しています。
2000年代に入ると、車載システムの複雑化や安全性・機能拡張の要求が高まったことから、AUTOSARは従来の枠組みを超え、基本ソフトウェア層（BSW）、ミドルウェア、アプリケーション層などの複数のレイヤーにより、通信、診断、安全機能など幅広い要件に対応する統合プラットフォームとして策定されました。これにより、各ECU間の連携が容易になり、システム全体の信頼性と効率性が大幅に向上しています。
AUTOSAR™ は AUTOSAR GbR の登録商標です。株式会社サニー技研は、AUTOSAR Associate Partnerです。
なぜAUTOSARが必要なのか
従来のECU開発では、各自動車メーカーや部品サプライヤーが独自にソフトウェアを開発しており、以下のような課題がありました。
AUTOSARは、共通のソフトウェアアーキテクチャを定めることで、開発の効率化とコスト削減を目指しています。
特に自動車メーカーは、部品サプライヤー各社が開発するECUの通信互換性を確保するため、AUTOSAR準拠のソフトウェアプラットフォームの導入を推進するケースが増えています。
AUTOSARの目的と導入のメリット
AUTOSARは、車載ソフトウェアの標準化を推進することで、開発の効率化や安全性の向上を図ることを目的としています。
具体的には、以下の5つの主要な目的を掲げ、業界全体の発展に貢献しています。
従来の車載ECU開発では、自動車メーカーが独自の要求や仕様を定める一方で、部品サプライヤーはそれぞれの要件に合わせた独自のソフトウェアや通信プロトコルを採用していました。その結果、異なる自動車メーカーやサプライヤーが提供するECU間で互換性や相互運用性に課題が生じ、車載ネットワークでの統合時にトラブルが発生することがありました。
AUTOSARは、標準化されたソフトウェアアーキテクチャと通信プロトコル（CAN、LIN、FlexRay、Ethernetなど）を採用することで、各自動車メーカーや部品サプライヤーが開発するECUの互換性を大幅に向上させます。これにより、ECU間の統合がスムーズになり、開発の柔軟性が向上するとともに、システム全体の信頼性も高まります。
従来のECU開発では、自動車メーカーと部品サプライヤーがそれぞれ独自の要求に応じたソフトウェアソースコードを開発していました。特に部品サプライヤーは、各自動車メーカーごとに異なる仕様や通信プロトコルに合わせ、機能の実装を一から、もしくは大部分を新規に開発するケースが多く、その結果、重複した開発作業や非効率な工程が生じ、全体のコストが膨らんでいました。
AUTOSARの導入により、共通のソフトウェアアーキテクチャや通信プロトコルを利用できるようになるため、既存の開発資産やコンポーネントの再利用が容易になります。特に、前回のECU開発で使用したマイコンやハードウェアが変更された場合でも、ソフトウェアコンポーネントは標準化されたインターフェースを通じて利用可能であり、必要な差分部分のみを効率的に開発することが可能となります。これにより、自動車メーカーと部品サプライヤーの両者において、開発コストの大幅な削減、開発期間の短縮、そして保守性の向上が実現されます。
従来のECU開発では、新しい車両モデルの開発にあたって、基本設計の再利用が行われる一方で、既存のソフトウェアとの差分部分のみを実装する差分開発が一般的でした。しかし、車種やシステムの要求が大幅に変わる場合、既存のソフトウェアでは対応が難しくなることもありました。
AUTOSARでは、「ソフトウェアコンポーネント」として機能をモジュール化する仕組みを導入しており、既存の開発資産を活用しつつ、必要な変更部分や新機能の追加を効率的に行える環境を提供します。これにより、前回のソフトウェアとの差分開発が容易になり、全体の再構築を避けながらも高い再利用性を実現しています。
車載ECUは、ブレーキやステアリング制御などの重要な機能を担っており、安全性が最も重要視されます。 ISO 26262は、車載電子システムの機能安全を確保するための国際規格であり、AUTOSARはこの規格に準拠した設計を可能にする仕組みを備えています。
標準化されたソフトウェアの構造や診断機能、フェイルセーフメカニズムなどを取り入れることで、安全性を向上させ、車両の誤動作や事故のリスクを低減できます。
近年の自動車は、車載EthernetやOTA（Over-the-Air）アップデートなどの技術導入により、ネットワーク接続の機会が増えています。その一方で、ハッキングや不正アクセスなどのサイバー攻撃のリスクも高まっています。
AUTOSARは、セキュアブート、暗号化、メッセージ認証、侵入検知システム（IDS）などのセキュリティ対策を標準仕様として提供し、ECUのセキュリティレベルを向上させています。これにより、不正なソフトウェアの改ざんやデータの漏洩を防ぎ、車両全体の安全性を確保します。
AUTOSAR導入のハードル
AUTOSAR導入は多くのメリットをもたらしますが、一方でいくつかのデメリットや導入ハードルも存在します。以下に、主な課題とその背景をまとめます。
AUTOSAR対応のソフトウェアプラットフォームを導入するには、新たな開発ツール、トレーニング、システム環境の整備が必要となります。これらの初期投資は中小規模の開発組織にとって負担となる可能性があります。
AUTOSARは非常に包括的かつ複雑な仕様を持っており、各種コンポーネントやインタフェースの理解・運用に高い専門知識が要求されます。そのため、開発者は新たな知識習得に時間と労力を費やす必要があります。
そのため、専門的なトレーニングプログラムや教育機会を整備し、技術者のスキルアップを図らなければ、仕様の理解不足や導入ミスにつながるリスクがあります。
従来の自社開発システムや部品ごとの独自仕様との互換性確保が難しい場合があり、既存資産との統合や移行プロセスにおいて追加のコストや工数が発生する可能性があります。
標準化されたソフトウェアコンポーネントは多機能かつ汎用性を持つため、必要以上にリソース（メモリや処理能力）を消費する場合があります。特にリアルタイム性が求められるシステムでは、パフォーマンス調整が求められることがあります。
AUTOSARは標準化を目指すため、仕様から逸脱した独自機能の実装が難しい場合があります。特殊な機能や高いパフォーマンスが求められる場合、標準コンポーネントの範囲内で対応できない可能性があるため、カスタマイズに制約が出ることもデメリットの一つです。
OSEK/VDKとの関係性
OSEK/VDKは、初期の車載RTOSとして確立された基盤技術であり、その概念や設計思想は、後のAUTOSARの開発にも影響を与えています。
AUTOSARは、OSEK/VDKの基本概念を継承しつつ、より拡張された機能群や安全性、セキュリティ、柔軟性を提供する形に進化しました。。
現場では、従来のOSEK/VDKベースのシステムからAUTOSARへの移行が進められている場合もあり、両者の間で一定の互換性や移行支援がなされることもあります。つまり、OSEK/VDKが築いた基盤上に、さらに高度な機能や拡張性を求める形でAUTOSARが登場したと考えることができます。
OSEK/VDKは、車載システムに必要な基本機能の提供に特化していたのに対し、AUTOSARはその枠を超えて、車載ソフトウェア全体の開発プロセスの標準化、再利用性の向上、そして将来的な自動運転やコネクティビティといった新たな要求に対応するための総合プラットフォームとして位置づけられています。
AUTOSARソフトウェアプラットフォーム
AUTOSARソフトウェアプラットフォームとは、車載ECU（電子制御ユニット）の開発における共通基盤を提供する標準仕様のことです。これにより、自動車メーカーや部品サプライヤーが個別に開発していたソフトウェアや通信プロトコルのばらつきを解消し、異なるECU間での再利用性や互換性を高めることが可能になります。
AUTOSARソフトウェアプラットフォームには、大きく分けて以下の2種類が存在します。
クラシックプラットフォーム（Classic Platform：CP）
従来の車載制御システム（走行制御や基本的な安全機能など）に用いられ、リソースが限られた環境で高い信頼性を実現するために設計されています。
アダプティブプラットフォーム（Adaptive Platform：AP）
自動運転や先進運転支援システム（ADAS）など、より高度な処理能力や柔軟性が求められる用途に対応するためのプラットフォームです。
リアルタイム性よりも高い計算能力と柔軟なソフトウェア更新機能を重視しています。
近年では、信頼性が求められる車載通信（CANなど）を司るECUにおいて、AUTOSAR CPのBSW（ベーシックソフトウェア）の導入が進んでいます。
基本構成と主要要素
AUTOSARソフトウェアプラットフォームは、車載ECUの開発効率と互換性・再利用性を高めるための標準仕様であり、システムは大きく4つのレイヤーに分かれています。
図：AUTOSAR Classic Platform BSW 基本レイヤ構成（当社作成）
参考文献：AUTOSAR Classic Platform標準仕様書（Layered Software Architecture） Release R24-11
アプリケーション層（Software Component）
各車両やシステムに固有の機能（エンジン制御、ブレーキ制御、インフォテインメントなど）を実装する部分です。これらのソフトウェアコンポーネントは、上位レベルのアプリケーションとして、業務ロジックや機能実現に専念できます。
API提供レイヤ（Run Time Environment：RTE）
アプリケーション層と下位の基本ソフトウェア（BSW）との間で、標準化されたAPIを提供します。RTEは、アプリケーションが車載ネットワークの詳細（例えば、CAN、LIN、FlexRay、Ethernetなどの通信プロトコル）を意識せずに機能を呼び出せるように抽象化されたインターフェースを提供し、移植性や再利用性を向上させます。
基本ソフトウェア（Basic Software：BSW）
ECUの共通の基盤機能を提供するモジュール群です。
BSWは、下記のようなレイヤ構造になっており、各レイヤーがハードウェア固有の違いを吸収します。
OS機能、ネットワーク通信、メモリサービス、ECU状態管理などの高レベルなサービスを提供します。特に、サービスレイヤーの通信モジュールは、車載ネットワークに一様なインターフェース（例えば「シグナル」として抽象化されたデータ単位）を提供し、上位のアプリケーションはどのバス（CAN、LIN、FlexRay、Ethernetなど）を使用しているかを意識せずに済みます。
マイコン内部・外部にかかわらず、周辺機器やデバイスへのアクセス機能を提供し、ハードウェアの違いを吸収します。
マイコン内蔵の周辺機能や、メモリにマッピングされた外部デバイスへ直接アクセスする機能を提供し、低レベルのハードウェア操作を統一します。
標準のBSWモジュールで対応しきれない、特殊なハードウェア機能やデバイスに対して、カスタムドライバを実装するための拡張機能です。CDDは、特定のハードウェアに固有の制御や機能を柔軟に実装できるようにするため、システム全体の拡張性を高め、再利用性をさらに促進します。
ハードウェア層
ECUに搭載されるマイコン、センサー、アクチュエータなど、実際の物理コンポーネントです。AUTOSARの上位レイヤーは、このハードウェアの詳細から独立して開発されるため、異なるハードウェア環境に柔軟に対応できます。
AUTOSAR CP BSWモジュール
AUTOSARのCAN通信スタック内で、各モジュールは緊密に連携し、それぞれの役割を果たしています。
図：AUTOSAR Classic Platform BSWモジュールのレイヤ構成（当社作成）
参考文献：AUTOSAR Classic Platform標準仕様書（Layered Software Architecture） Release R24-11
※Off-board Communication Stack – European Vehicle-2-X
AUTOSAR レイヤの分類説明
ECU 全体で共通に必要とされる基本サービス群。リアルタイムOS（タイマ、タスク管理）、エラーマネージャ、ウォッチドッグマネージャ、ECU ステートマネージャなどを含み、他レイヤやアプリケーションから呼び出されます。
ECU に搭載されたセンサーやアクチュエータ、周辺デバイス（ADコンバータ、PWM出力など）へのアクセスを抽象化するレイヤ。後段のドライバ実装やハードウェア依存コードを隠ぺいし、上位モジュールに統一インターフェースを提供します。
マイクロコントローラ（μC）固有のレジスタ操作や内部ペリフェラル（タイマ、UART、ADC、GPIO など）を直接制御する最下層ドライバ群。CPU コア・ペリフェラルへのバイナリマップ的アクセスを担います。
不揮発性メモリ（フラッシュやEEPROM）への読み書きを、高レベルAPIで提供するレイヤ。書き込み耐久性制御や整合性チェック、データ凝集管理などを行い、アプリケーションや上位BSWモジュールに安定したメモリ操作手段を提供します。
フラッシュやEEPROMなど各種メモリデバイス固有の制御手順（ページ消去、書き込みシーケンス、ステータスチェックなど）を抽象化するレイヤ。Memory Drivers と Memory Services の仲介役となり、デバイス種別に依存しないインターフェースを実装します。
上位の Memory Hardware Abstraction が呼び出す、各メモリデバイス専用の低レベルドライバ。メーカー・モデルごとの細かなコマンドシーケンスを実装し、実際のメモリ書き込みや消去動作を行います。
暗号化／復号化、署名、ハッシュ生成などの高レベル暗号処理機能を提供するレイヤ。セキュリティ要件を満たす API 群を通じて、上位モジュールやアプリケーションに暗号機能を提供します。
暗号化処理を行うプリミティブ（SHE、HSM、ソフトウェアライブラリなど）がどこで実装されているか（内部ハードウェア／外部ハードウェア／ソフトウェア）を隠し、統一的な暗号APIを提供するレイヤです。
HSM（Hardware Security Module）や専用暗号アクセラレータといったハードウェア暗号ユニットを直接制御するドライバ群。鍵ストレージ制御や暗号演算要求のキューイング、ステータス監視などを担います。
車外（V2X）通信向けの高レベル機能群。メッセージ生成／解析、クロスレイヤ管理（輻輳制御、セキュリティ、位置・時間同期）などを実装し、上位アプリケーションが V2X を利用できるようにします。
Wi-Fi、DSRC、C-V2X など、オフボード無線通信モジュールのハードウェア依存部分を抽象化するレイヤ。送受信設定やステータス参照のインターフェースを統一化します。
無線チップセットベンダー固有のドライバ。PHY／MAC レジスタ操作、チャネル設定、フレーム送受信要求などを直接扱います。
CAN, LIN, FlexRay, Ethernet などの車載ネットワーク向けに、メッセージ送受信や信号／PDU 単位の取り回しを行う高レベル機能群。通信スタック上位のアプリケーション向けに、整合性チェックやタイミング保証を含めたサービスを提供します。
コントローラ（CAN コントローラ、Ethernet MAC など）固有の制御ロジックを隠し、上位の Communication Services に対して統一的な送受信インターフェースを提供するレイヤです。
CAN トランシーバ、Ethernet PHY／MAC、LIN トランシーバといった通信ペリフェラルを直接制御する最下層ドライバ群。フレームレジスタの読み書きや割り込み管理を担います。
GPIO、ADC、PWM などの汎用入出力デバイスのハードウェア依存部分を抽象化し、上位モジュールに対して統一的な入出力インターフェースを提供します。
GPIO ポートや ADC チャネルを直接操作する最下層ドライバ。レジスタマップに基づく読み書きを通じて、物理的なピン設定やデータ取得・出力を実現します。
AUTOSAR CAN関連モジュール
| AUTOSARレイヤー | モジュール略称 | モジュール名称 | 機能概要 |
|---|---|---|---|
System Services | Dcm | Diagnostic Communication Manager | 診断通信管理、外部診断ツールとの通信 |
System Services | Dem | Diagnostic Event Manager | 異常イベント監視、DTC管理 |
System Services | FiM | Function Inhibition Manager | 障害時の機能制限 |
System Services | FBL | Flash Boot Loader | ECUソフトウェアアップデート |
System Services | NvM | Non-Volatile Memory Manager | 不揮発性メモリ管理 |
Application Layer | CanTSyn | CAN Time Synchronization | ECU間タイムスタンプ同期管理 |
Communication Services | CanNm | CAN Network Management | ECU間通信状態(Sleep/Wakeup等)管理 |
Communication Services | CanSM | CAN State Manager | CANネットワークのセッション管理 |
Communication Services | COM | Communication | PDUメッセージ送受信管理 |
Communication Services | PduR | PDU Router | PDUルーティング管理 |
Communication Services | CanTp | CAN Transport Protocol | 大容量データ送受信管理 |
ECU Abstraction | CanIf | CAN Interface | CANドライバと上位層間のデータ送受信管理 |
Microcontroller Abstraction | CANTrcv | CAN Transceiver Driver | CANトランシーバ制御、物理層通信制御 |
車載ネットワークのSleep/Wake Up機能
車載ネットワークは、車両内の複数のECU（電子制御ユニット）が連携して各種制御を行うシステムですが、電源管理や省エネルギーが極めて重要な課題となっています。特に、車両が停止している状態でも、必要最低限の監視や制御を行うために、Sleep（低消費電力モード）とWake Up（動作再開モード）の切り替え機能が採用されています。
なぜSleep/Wake Upが必要なのか
バッテリー電力の制約
車両がエンジン停止状態になると、発電機（オルタネータ）からの電力供給が停止し、バッテリーからのみ電力が供給されます。バッテリー容量は限られているため、すべてのECUを常時フル稼働させると、短時間で電力が消耗し、最悪の場合、バッテリー上がりにつながる恐れがあります。
必要最低限の機能維持
車両停止中でも、ドアの解錠、キーレスエントリー、セキュリティシステムなど、最低限必要な機能は稼働させる必要があります。しかし、それ以外の不要な機能は停止し、消費電力を抑えることが求められます。
適切なタイミングでの復帰
ドライバーが車両に接近した際や、特定のイベント発生時に迅速に必要なECUを起動させることで、安全な車両運行を支えます。たとえば、ドアを開けるときにすぐに各ECUが動作しなければ、解錠や各種制御が遅れる恐れがあります。
不要な起動の防止
逆に、必要のないECUまでWake Upしてしまうと、無駄な電力消費となり、全体の省電力性能が低下します。したがって、どのECUをどのタイミングでWake Upさせるかの調整が重要です。
Sleep/Wake Upの仕組み
基本的な動作
車両が停止しているとき、各ECUは省電力状態に切り替え、必要最低限の回路（例えば、監視や通信に必要な回路）だけを動作させます。これにより、全体の消費電力が大幅に削減されます。
外部からの信号（例えば、キーレスエントリーの無線信号、ドアセンサー、衝撃センサーなど）により、必要なECUが起動状態に戻ります。Wake Up信号は、ネットワーク上で他のECUにも伝播され、システム全体の連携を促します。
通信ネットワークにおける実装例
車載通信システムでは、SleepとWake Upの状態管理はネットワークマネジメント機能として実装されています。各ECUは、通信バスを通じて自身の電源状態や起動要求を交換し、全体として最適な省電力運用を行います。
Wake Up信号が送出された場合でも、全ECUが同時に起動するとバッテリーに過大な負荷がかかるため、起動タイミングに遅延や順序を持たせる設計が採用されることが多いです。これにより、必要なECUのみが迅速に動作し、他のECUは順次復帰する仕組みが構築されます。
車載ネットワーク通信ソフトウェア
これまで見てきたとおり、車載ネットワークには通信制御ソフトウェアの存在が欠かせません。
特に近年では、自動車がより複雑化・高性能化する中で、各ECU間の迅速かつ確実な情報交換が求められています。このため、車載ネットワークの通信制御ソフトウェアには高度な信頼性と柔軟性が不可欠となっています。
車載通信コンパクトソフトウェアプラットフォーム CioRy
サニー技研が提供する車載通信コンパクトソフトウェアプラットフォーム「CioRy（シオリー）」は、車載通信におけるこれらの課題を効果的に解決します。CioRyは、CAN, CAN FD,LIN,CXPIの各プロトコルに対応し、付属のコンフィグレーションツールで、ECU間の通信をシンプルに設定可能。開発期間の短縮、コスト削減、そして高い信頼性を同時に実現することが可能です。
また、CioRyは最新のセキュリティ機能にも対応し、通信の安全性を強化にも対応します。
詳細な製品情報については、以下の製品紹介ページをご覧ください。
システム統合とテスト手法
車載ネットワークシステムは、複数のECU、各種通信プロトコル、そして多様なハードウェアとソフトウェアが複雑に連携して動作するシステムです。このため、システム統合と検証は、全体の信頼性と安全性を担保する上で非常に重要なプロセスとなります。
以下では、その重要性と具体的な手法について詳しく解説します。統合と検証の重要性
各コンポーネント（ECU、センサ、アクチュエータ、通信モジュールなど）は、単独では正しく動作していても、全体として連携する際には想定外の相互作用や通信の不整合が発生する可能性があります。
個々のコンポーネントを小規模なグループに分け、部分的な連携や通信を検証することで、初期段階から不具合を発見しやすくなります。
すべてのコンポーネントを統合し、実際の車両運転シナリオを模したテストを行うことで、システム全体の挙動と安全性、そして協調制御が正常に機能するかを評価します。
シミュレーションツールとテストプロセス
通信アナライザツールなどのシミュレーションツールや仮想環境を用いることで、実際のハードウェアに依存せずに車載ネットワークの挙動を再現できます。これにより、以下のメリットがあります。
ECU間の通信、エラー発生時の挙動、障害復旧のプロセスなどを事前に検証し、現場テスト前に潜在的な問題を洗い出すことが可能です。
シミュレーションツールによる検証は、実際のハードウェアを多数用意する必要がなく、開発コストや時間の削減に寄与します。
アナライザツールの導入
車載ネットワークの検証には専用のアナライザツールが欠かせません。
各ネットワーク（CAN、CAN FD、LIN、FlexRay、Ethernet、CXPIなど）のデータ通信をリアルタイムで解析し、プロトコルレベルのエラーや異常を特定します。
また、通信アナライザからECUとの間でデータ送受信を行い、模擬ノードとしてECU評価を行うこともできます。
各ECUからの出力データや通信ログを詳細に解析することで、システム統合時の微妙な通信不整合やタイミングの問題を特定し、迅速な修正を支援します。
サニー技研では、CAN/CAN FD通信、LIN通信に対応したアナライザツールを販売しています。
車載ネットワークの品質とは
車載ネットワークにおいて、通信品質が極めて重要であることは言うまでもありません。CAN通信やLIN通信などの各種通信プロトコルは共通の仕様に基づいて設計されているため、「仕様通りに通信ソフトウェアを作れば問題なく通信が実現できる」と誤解されがちです。
しかし、実際の車両環境では、電源の変動、温度変化、ノイズなどの外部要因や、複雑な制御シナリオが存在するため、単に仕様を満たすだけでは十分ではなく、様々な追加的な配慮が必要となります。
例えば、現代の自動車は従来の機械式の鍵による電源ON/OFFから、電子および無線による制御へと移行しており、ドライバーがエンジンを停止し、ドアを閉めた状態でも、複数のECU（車載コンピュータ）が常時動作して車両状態を監視しています。
具体的には、キーレスエントリー用の無線を監視するECU、人の接近を検知するECU、鍵の制御を行うECUなどが、CAN通信やLIN通信を介して連携しています。また、エンジン停止時はオルタネータからの電力供給が停止し、限られたバッテリー電力で動作しなければならないため、各ECUには省電力制御が求められます。
車載通信システムでは、必要最低限の通信のみを実施し、通信完了後に不要な回路を即座にOFFにする「Sleep（低消費電力モード）」と「Wake Up（動作再開モード）」の間欠動作が実装されています。この機能により、車両全体の電力消費を最小限に抑えることが可能となります。
しかし、適切な調整が行われなければ、例えば鍵を開けた際に関係のないエアコン制御ECUまで不必要にWake Upしてしまい、結果として無駄な電力消費が生じる可能性があります。こうした不必要なWake Upが頻発すると、バッテリーの消耗が急速に進み、最悪の場合はバッテリー上がりという致命的な問題に発展する恐れがあります。
現代の車両では、コンピュータが動作しなければドアの解錠すらできなくなるため、バッテリー消耗の管理は極めて重要です。
車載ネットワークの困り事はサニー技研へ
このように、車載ネットワークが仕様通りに通信を実現するためには、単なる規格の遵守だけでなく、実車環境の多様な条件を考慮した高度な技術とノウハウが必要です。サニー技研は、車載通信のエキスパートとして豊富な実績と高度な技術力を有し、高品質な車載ネットワークソリューションを提供しています。
サニー技研では車載通信のみならず、車載マイコンセキュリティ、OTAアップデート、仮想化技術など最新技術にも取り組んでおり、パワートレイン系、ボディ系、シャシー系、安全系などあらゆる領域でその技術が採用されています。
今後、ADAS、自動運転、IT融合の進展に伴い、車載ネットワークの重要性はますます高まるでしょう。サニー技研が皆様をサポートします。