車載ネットワーク概要解説

1. 車載ネットワークとは

現代の自動車は「走る・止まる・曲がる」といった基本機能にとどまらず、快適性・安全性・自動運転機能を含む高度なシステムの集合体となっています。その中枢であるECU（Electronic Control Unit：電子制御ユニット）は数十から数百に及び、車両1台において複雑に配置されています。

車載ネットワーク

これらのECUはセンサやアクチュエータと接続され、情報を収集・処理し、制御を行います。しかしECU単体では完結せず、車載ネットワークによって連携することで車両全体として最適な制御が可能となります。

例えば、ブレーキECUは車速情報をエンジンECUや車体制御ECUから受け取り、制動力を調整します。エアバッグECUは衝突センサーのデータを受信し、ミリ秒単位で展開を判断します。

車載ネットワークはこのように「自動車をひとつの大規模分散システムに変える通信基盤」であり、現代のモビリティにおいて必須の技術領域となっています。

2. 車載ネットワークの課題と技術的背景

自動車特有の制約は、一般的なITネットワークと大きく異なります。以下の観点が特に重要です。

2.1 リアルタイム性

自動車制御は「応答が遅れると事故につながる」環境で行われます。
例えばABS（アンチロックブレーキシステム）は車輪回転数を数ミリ秒単位で監視し、ブレーキ圧を制御します。通信遅延が10msを超えると制御精度に大きく影響を与えます。そのため、車載ネットワークには低遅延・高決定性通信が求められます。

2.2 高信頼性とエラー検出

車両環境は温度変化（-40℃～+125℃）、強い振動、電磁ノイズにさらされます。そのような環境の中でも、人命に関わる自動車制御の通信は確実に伝達する必要があります。

車載通信のCANやFlexRayなどのプロトコルは、CRC（巡回冗長検査）やACK機構によってエラー検出と再送を行います。
高信頼性を確保するためには「プロトコルレベルでのエラー耐性」が不可欠です。

2.3 コストと配線量

車両1台のワイヤーハーネスは数十kgに達する場合があります。配線量が増えると重量・コストが増大し、燃費にも悪影響を与えます。
そのため、必要な箇所には高機能なEthernet、補助的な箇所にはLINといったハイブリッド設計が実施されます。

2.4 消費電力と電源管理

電動化が進むにつれ、省電力設計はさらに重要となっています。
エンジン停止中もECUは待機状態にあり、ドアロック・キーレスエントリー・防犯システムが常時動作します。
これを効率的に管理するため、Sleep/Wake Up制御が導入されています。

3. 主な車載通信規格とユースケース

自動車には複数の通信規格が共存しています。それぞれが異なる性能・コスト・信頼性を持ち、適材適所で選択されます。

車載通信プロトコル比較

3.1 CAN（Controller Area Network）

1986年にBosch社が提案。ISO 11898として標準化。
マルチマスタ方式を採用し、複数ノードが同時送信しても「優先度仲裁（IDの数値比較）」により、重要なメッセージが必ず送信される仕組み。
通信速度は最大1Mbps。エンジン制御やパワートレイン系に広く利用。
自動車制御の主要通信だが、データ長が8バイトに制限されることや帯域不足により、CAN FDや車載Ethernetへの部分的な置き換えが進んでいる。

3.2 CAN FD（Flexible Data Rate）

標準CANの拡張規格。
データ長が最大64バイトに拡張され、高速位相では最大8Mbpsを実現。
センサー統合やADASに必要な大容量データ転送に対応。
既存のCANインフラとの後方互換性を持ちつつ、移行が進んでいる。

3.3 LIN（Local Interconnect Network）

最大20kbpsの低速通信。低コスト・簡素な実装が可能。
シングルマスタ・マルチスレーブ方式で通信を管理。
主にボディ制御（パワーウィンドウ、シート、ドアミラー等）で利用。
低コストが魅力だが、エラー検出は限定的で冗長性に欠ける。

3.4 CXPI（Clock Extension Peripheral Interface）

日本主導で規格化。LINの後継的立場。
同期通信を可能とし、低速ながらリアルタイム性を強化。
エアコン、照明制御、ハンドルスイッチ等に応用されている。

3.5 FlexRay

タイムトリガ通信を採用し、遅延が極めて小さい。
データ速度は最大10Mbps。冗長チャネル構成により高信頼性を実現。
ステアバイワイヤやブレーキバイワイヤといった安全系に利用。
実装コストが高いため、現在はEthernetへの移行が進む傾向。

3.6 車載Ethernet

高速通信（100Mbps～1Gbps）を実現。画像処理や自動運転に不可欠。
100BASE-T1（シングルペアEthernet）や10BASE-T1Sが実用化。
TSN（Time-Sensitive Networking）によってリアルタイム性を担保。
今後の自動運転ECUの基盤となる規格。

4. リアルタイム通信と協調制御

自動車のECUは単独ではなく、複数のECUがリアルタイムに協調して制御を行うことにより、安全性と快適性を実現しています。これを「協調制御（Cooperative Control）」と呼びます。協調制御の特徴は、単に情報を共有するだけではなく、複数の制御が時間的に厳密に同期して動作する点にあります。このため、通信レイテンシやジッタ（ばらつき）が大きいと、制御の安定性が失われ、最悪の場合は事故につながるリスクがあります。

4.1 協調制御の例

ABSとESCの連携
ABSは急ブレーキ時に車輪ロックを防止する制御を担当しますが、横滑り防止装置（ESC）は車両全体の挙動を安定化させる役割を持ちます。両者は車輪回転数、舵角センサー、ヨーレートセンサーなどの情報を共有し、ABSが単独で動作する場合よりもはるかに安定した制御を実現します。ここでは数ms単位のデータ伝達が必要であり、CANやFlexRayのようなリアルタイム性を担保できるプロトコルが利用されます。
ADASの連携
先進運転支援システムでは、レーダーECUやカメラECUが検出した物体の情報を、ブレーキECUやステアリングECUがほぼ即時に受け取る必要があります。例えば「前方車両との衝突リスク」を検知してからブレーキ制御に反映するまでの遅延は数十ms以内でなければなりません。ここでEthernetとCAN FDが組み合わされ、大容量画像データはEthernet、緊急制御信号はCAN FDという棲み分けが行われています。
HV/EVの制御
ハイブリッド車やEVでは、バッテリーECUとモータECUが高頻度でデータを交換し、電力配分や充放電の安全管理を行います。この際、電流・電圧情報はms単位で更新されるため、リアルタイム性が欠如すると「加速レスポンスの低下」や「過放電による電池劣化」が発生します。

4.2 リアルタイム性の要求

制御周期と通信規格の選択
制御周期が10ms以下を要求するシステムでは、遅延やジッタを最小限に抑える必要があるため、CANやFlexRayが選択されます。特にFlexRayはタイムトリガ通信により送信タイミングが保証されるため、車体安定化制御に適しています。
大容量データ通信の課題
自動運転やADASではカメラやLiDARが数百Mbps規模のデータを生成します。これらはEthernetによる高速通信でなければ扱えませんが、Ethernetは標準仕様では決定性が弱いという課題がありました。その解決策がTSN（Time-Sensitive Networking）で、これによりEthernetも制御系に応用可能となりつつあります。
複数ネットワークの統合
実際の車両では、CAN FD・LIN・Ethernetが混在して使われています。システム設計者は用途に応じて適材適所で規格を選び、ゲートウェイECUで複数プロトコルを中継して全体を統合します。この構成管理が車載ネットワーク設計の難しさであり、開発ツールやシミュレーション環境が不可欠です。

5. OSI参照モデルと車載通信

OSI（Open Systems Interconnection）参照モデルは、通信機能を7つの階層（レイヤー）に分けて定義した概念モデルです。各レイヤーが特定の役割を担い、通信プロトコルを効率的かつ明確に整理しています。

各通信レイヤーでは、そのレイヤー固有のPDU（Protocol Data Unit：データ単位）が使用され、通信機器間の対応するレイヤー同士で1対1や1対多の通信が行われます。

レイヤーごとにPDUのデータ構成が異なるのは、上位レイヤーから下位レイヤーへデータが渡されるたびに、そのレイヤーに固有の制御情報（ヘッダ）がPDUに付加される仕組みのためです。このようにレイヤーごとに制御情報を付加する処理を「カプセル化（Encapsulation）」、逆に付加された制御情報を取り除いてデータを復元する処理を「非カプセル化（Decapsulation）」と呼びます。

車載ネットワークを理解する上で、OSI参照モデルは単なる教科書的な知識にとどまらず、通信不具合解析や規格適合性検証における必須フレームワークです。

OSI参照モデルレイヤー	説明	車載通信での具体的解説
アプリケーション層（Layer7）	通信するアプリケーション間のインターフェースを提供	UDS（Unified Diagnostic Services, ISO 14229）は代表的なアプリケーション層プロトコルです。OBD-II（車載故障診断）やAUTOSARアプリケーション層もここに位置します。アプリ層で定義された仕様が、下位のTPやフレームにどうマッピングされるかを理解することが、診断機器とECU間の互換性検証には欠かせません。
プレゼンテーション層（Layer6）	データ形式の変換、圧縮、暗号化を担当	車載通信では独立した層として意識されにくいですが、セキュリティやデータ表現の互換性に深く関わります。たとえばTLSベースのセキュア診断通信（DoIP over TLS）や、AUTOSAR SecOC（Secure Onboard Communication）では、メッセージ認証や暗号化・復号化処理がこの層に対応します。また、車載Ethernetで動画ストリームを扱う場合、エンコード方式の共通化が重要となり、これもプレゼンテーション層の役割と捉えられます。つまり、この層は「異なるECUや診断ツール間で、意味のあるデータとしてやり取りできる状態に整える」ことを担っています。
セッション層（Layer5）	通信の開始・終了や通信状態の管理	車載システムでは「通信の確立と維持」を担当します。典型例が診断通信（UDS）におけるセッション管理で、通常セッションからプログラミングセッションに切り替えるなど、ECUが異なる動作モードに入るための制御が含まれます。また、Ethernet経由のDoIP（Diagnostics over IP）ではTCPセッションが利用され、通信確立／切断の制御が明確になります。この層を理解することで「なぜ通信が途中で切れるのか」「再接続の条件は何か」といった実務的な疑問を整理できます。
トランスポート層（Layer4）	エラー訂正やデータ転送の信頼性を管理	車載通信ではISO 15765-2（CAN TP）が広く使われ、長大なデータを複数フレームに分割し再構成します。トランスポート層の理解がないと、UDS診断など大容量データ通信のトラブルシュートは困難です。Ethernetを利用する場合には、TCP/UDPがこの層を担い、DoIPやTSNの基盤を支えています。
ネットワーク層（Layer3）	通信経路の選択やルーティングを担当	CANやLINにはネットワーク層の概念は存在せず、基本的には同一バス内で完結します。しかし、Ethernetベースの通信ではIP（IPv4/IPv6）が導入され、ゲートウェイECUが異なるサブネット間の通信を中継します。ADASや自動運転システムでは「カメラECU → 画像処理ECU → 制御ECU」のように複数の経路を経由するため、ネットワーク層の設計がボトルネックになります。また、VLANを用いた論理的分割やQoS（Quality of Service）による優先度制御は、この層における重要な技術要素です。
データリンク層（Layer2）	隣接するノード間の通信制御とエラー検出	CANではID仲裁が行われ、優先度の高いメッセージが衝突時に勝ち残ります。EthernetではCSMA/CDが標準でしたが、スイッチング技術やTSNの導入で決定性が強化されています。データリンク層の挙動を理解することは「なぜ特定のメッセージが遅延するか」を分析する手がかりになります。
物理層（Layer1）	物理的な通信媒体を通じての電気的・機械的接続	CANでは差動信号を利用して外来ノイズに強い設計となっています。Ethernetでは「シングルペアツイストケーブル」が使われ、軽量化とコスト削減が可能です。物理層を理解することは、実際の不具合（断線、ノイズ混入、インピーダンス不整合）解析に直結します。

この階層的な見方を身に付けると、通信ログ解析時に「どの層で問題が発生しているか」を迅速に切り分けられるようになります。

6. ソフトウェアアーキテクチャ標準化

車載ネットワークの複雑化に伴い、ソフトウェアの標準化が不可欠となりました。その中心となるのがOSEK/VDXとAUTOSARです。

6.1 OSEK/VDX

1990年代、ECUごとに異なるリアルタイムOSや通信仕様を統合する目的で策定されました。
OSEK OSはマルチタスクを効率的にスケジューリングし、ECUの制御をリアルタイムに処理します。
COM機能（通信抽象化）は、異なる通信方式を意識せずにアプリケーションを記述できる利点を持ちます。
NM機能（Network Management）はECUのSleep/Wake Upを制御し、省電力設計に寄与します。

OSEKの登場により、ECU開発の再利用性と移植性が大幅に向上しましたが、ソフトウェア規模の拡大に伴い限界を迎えたため、次世代規格としてAUTOSARが生まれました。

6.2 AUTOSAR

2003年に発足した国際標準化プロジェクト。世界中のOEMやサプライヤが参画。
Classic Platform（CP）は従来型ECU向けで、CANやLINを用いた制御システムに対応。
Adaptive Platform（AP）は自動運転やクラウド連携を前提にし、POSIX準拠OS上で動作。C++ベースのアプリケーション開発が可能。
AUTOSARの利点は、ソフトウェアコンポーネントの再利用、セーフティ・セキュリティ対応、異メーカー間での互換性にあります。

例えば、異なるサプライヤが開発したECUを一台の車両に搭載する際、AUTOSAR準拠であれば統合がスムーズになります。これは現在の複雑化したサプライチェーンにおいて必須の要素です。

7. 省電力制御：Sleep/Wake Up

自動車の電装システムは、エンジンが停止していても常に一部が動作しています。キーレスエントリー、セキュリティアラーム、テレマティクス通信などは待機状態でも稼働しなければならず、これがバッテリー消費の要因となります。

Sleepモード
ECUを低消費電力状態に移行させ、必要最小限の回路だけを残します。例えばマイコンのクロックを停止し、RAM保持回路だけを動作させるといった工夫がなされます。
Wake Upモード
ドア開錠、衝撃検出、CANメッセージ受信などの外部イベントにより復帰します。CANでは「Wake Upパターン」と呼ばれる特定の信号列を受信するとスリープ解除が行われます。
課題と対策
設計が不適切だと、不要なWake Upが頻発し、数日でバッテリーが上がるという事例があります。これを防ぐため、ネットワークマネジメント（NM）が導入され、ECU同士が協調してスリープ・起動を制御します。さらに近年はバッテリーマネジメントシステム（BMS）と連携し、残容量に応じて動作制御を行う仕組みも一般化しつつあります。

この領域は電動化が進む今後さらに重要性を増し、単なるECU設計技術ではなく「車両全体のエネルギーマネジメント戦略」の一部として捉える必要があります。

8. サニー技研のソリューション

CioRy（車載通信コンパクトソフトウェアプラットフォーム）

CAN / CAN FD / LIN / CXPIに対応。
設定ツールにより、通信マトリクスをGUIで簡易設定可能。
開発初期段階で通信検証を行い、実機評価前に設計品質を確保。
セキュリティ拡張に対応し、次世代ECU開発に活用可能。

MicroPeckerX（車載通信アナライザ）

CAN/CAN FD/LINのリアルタイム解析。
ECUとの模擬通信ノードとして動作可能。
通信ログ解析、異常シナリオ再現、タイミング測定により開発効率を大幅に改善。

車載受託ソフトウェア開発

車載通信ソフトウェア開発、AUTOSAR PF組込み開発。
車載マイコンセキュリティ技術導入サポート、PF組込み開発。
OTA、FBL、ダイアグ組込み開発。

サニー技研は、CioRyやMicroPeckerXといった車載ツール製品を展開するとともに、車載ソフトウェア開発の受託サービスも提供しています。 AUTOSAR準拠の通信制御や診断ソフトの開発、車載マイコンへのセキュリティ機能導入、さらに OTA（Over-The-Air）や FBL（Flash Boot Loader）、ダイアグ機能の実装まで幅広く対応可能です。これにより、車載製品とソフトウェアサービスの両面から開発者を支援し、次世代ECU開発に必要なセーフティ・セキュリティ要件を満たす高品質なソフトウェア開発を実現します。

9. 最新動向と展望

SDV（Software Defined Vehicle）：ハード中心からソフト中心の設計へ移行。
TSN（Time Sensitive Networking）：Ethernetのリアルタイム化。
仮想ECU（vECU）：クラウド上で動作するECUモデルを活用し、開発を前倒し。
OTAアップデート：無線経由でソフト更新が可能となり、セキュリティ対策も重要に。
ISO 26262・Cybersecurity：安全性とセキュリティは車載開発の必須要件に。

10. まとめ

車載ネットワークは自動車制御の根幹技術であり、安全・快適性に直結する。
各通信規格は用途に応じて適材適所で利用される。
ソフトウェア標準化（AUTOSAR）や省電力制御が進み、開発効率と品質が向上。
サニー技研は、ソフトウェアプラットフォームから解析ツールまで包括的なソリューションを提供し、開発者を支援します。