SDV時代の車載通信プロトコルの進化——CAN FD・CAN XL・Automotive Ethernetの住み分けとゾーナルアーキテクチャへの統合設計（深掘り#16）

2026年6月28日 09:56

本稿の主な略語

CAN（Controller Area Network）：1986年にBoschが開発した車載バスプロトコル。ISO 11898として規格化
CAN FD（CAN with Flexible Data-rate）：データフェーズの速度とペイロードサイズを拡張したCANの後継規格。ISO 11898-1:2015
CAN XL（CAN with eXtra Long payload）：CAN FDの後継として開発中の規格。ISO 11898-1の改訂版に取り込まれる予定
CAN-in-Automation（CiA）：CANおよびCAN FD・CAN XLの規格策定を担う業界団体
Automotive Ethernet：ノイズ耐性・軽量化のために単線または差動2線（Unshielded Twisted Pair：UTP）で実装した車載向けEthernet
100BASE-T1：IEEE 802.3bwで規定される100Mbpsの車載Ethernet。旧称BroadR-Reach
1000BASE-T1：IEEE 802.3bpで規定される1Gbpsの車載Ethernet
10GBASE-T1：IEEE 802.3chで規定される10Gbpsのマルチギガビット車載Ethernet
OPEN Alliance：Automotive Ethernetの採用推進を目的とする業界コンソーシアム。BroadcomとBMWが2011年に設立
AVB（Audio Video Bridging）：IEEE 802.1BA で規定されるEthernet上のリアルタイムAV転送技術群
TSN（Time-Sensitive Networking）：AVBを拡張した、Ethernet上の決定論的・低遅延通信規格群。IEEE 802.1Qシリーズ
IEEE 802.1AS：gPTP（generalized Precision Time Protocol）。Ethernet上でナノ秒精度の時刻同期を実現する規格
IEEE 802.1Qbv：TSNのスケジュールドトラフィック（タイムゲート）規格。周期的な通信スロットを設けて決定論的レイテンシを保証する
MACsec（Media Access Control Security）：IEEE 802.1AEで規定されるEthernetフレームレベルの暗号化・認証規格
SOME/IP（Scalable service-Oriented MiddlEware over IP）：Automotive Ethernet上でサービス指向通信を行うためのプロトコル。AUTOSAR規格の一部
DoIP（Diagnostic over IP）：車両診断（OBD・UDS）をEthernet/IPで行うためのプロトコル。ISO 13400
ECU（Electronic Control Unit）：電子制御ユニット
LLCE（Low Latency Communication Engine）：NXP S32Gプロセッサが搭載する、CAN/LIN/Ethernetの割り込みレイテンシを極低遅延化した専用通信処理コア
FlexRay：BMW・Daimler・Motorolaが主導した10Mbpsの決定論的車載バス。2007年頃から量産採用されたが現在は新規採用なし
LIN（Local Interconnect Network）：最大20kbpsの低速・低コスト車載バス。マスター・スレーブ構成のシングルワイヤーバス。ドア・シートなどの簡易アクチュエータ制御に使用
CXPI（Clock Extension Peripheral Interface）：トヨタ・ルネサス主導で開発されたLIN後継候補プロトコル。ISO 20890。クロック拡張方式によりLINより高ノイズ耐性・低消費電力を実現
UN-R155：国連欧州経済委員会（UNECE WP.29）が策定した車両サイバーセキュリティ規制。2022年7月以降の新型認証取得車に適用
CSMA/CD：Carrier Sense Multiple Access with Collision Detection。イーサネットの従来型衝突検出型アクセス制御方式
OBD（On-Board Diagnostics）：車載診断インターフェース

はじめに：「線材の重さ」から始まる通信革命

前回（深掘り#15後編）では、AI推論の車載統合をデプロイパイプライン・SOTIF・センサーフュージョンの観点から論じた。今回は、そのAI推論を含むSDVアーキテクチャ全体を支える「インフラ」——車載通信プロトコルに焦点を当てる。

SDVの本質は「ソフトウェア定義」だが、その前提として「通信定義」が必要だ。ECU間でデータが確実に・低遅延に・安全に流れなければ、どれだけ優れたソフトウェアアーキテクチャも成立しない。

現代の量産車にはCAN・CAN FD・LIN・Ethernetが混在した通信ネットワークが張り巡らされており、ハーネス（配線）重量が30〜50kgに達する車種も珍しくない。BMWが2008年にAutomotive Ethernetの採用を検討し始めたきっかけの一つが「ハーネス重量の軽減」だったのは象徴的だ。EV化の文脈では、電費（エネルギー効率）に直結するため、ハーネスの軽量化はコスト削減以上の意味を持つ。

本稿では、古典CANから始まりCAN FD・CAN XL・Automotive Ethernetに至る技術進化の経緯を整理し、それぞれのプロトコルが担うべき役割と、ゾーナルアーキテクチャへの統合設計上の課題を論じる。

1. 古典CAN（Classical CAN）の歴史と限界

誕生の背景

CANはBoschが1986年に発表し、1993年にISO 11898として規格化された。当時の車載制御はアナログ信号の専用配線が主流で、電子化が進むにつれてハーネスが爆発的に増加していた。CANは「複数のECUが同一のバスを共有し、ブロードキャストでデータを交換する」というシンプルな設計で、この配線問題を劇的に解決した。

技術仕様のポイントを整理しておく。古典CAN（ISO 11898-1）は差動信号の2線バス（CAN-HとCAN-L）で、最大1Mbpsのデータレートを持つ。最大ペイロードは8バイト。アクセス制御はCSMA/CD型に類似したCSMA/CA（衝突回避型）で、「メッセージID（識別子）の数値が小さいほど優先度が高い」という調停（Arbitration）方式により、複数のECUが同時に送信しても優先度の高いメッセージが必ずバスを占有できる。この仕組みはリアルタイム性の保証に優れており、エンジン制御・ABS・エアバッグといった安全系システムへの採用を後押しした。

CANの普及とその強さ

CANが30年以上にわたって車載バスの主役であり続けた理由は複数ある。

第一に実装コストが低い。CANトランシーバーのシリコンコストは数十円から数百円のオーダーであり、配線もUTP（Unshielded Twisted Pair：シールドなし撚り線）の2線で済む。第二に、フォールトトレラント性が高い。1本の線が断線してもシングルワイヤーモードで通信継続できる実装があり、車載用途の信頼性要求に合う。第三に、30年以上の量産実績によりECUのCANソフトウェアスタック（AUTOSARのCom・PDURスタック等）が成熟しており、開発ツール・診断ツールのエコシステムも厚い。

古典CANの限界

2000年代後半からADAS機能が本格化し、カメラ・レーダー・LiDARのデータを複数のECU間でやり取りする要求が増えると、1Mbpsという帯域幅は決定的に不足し始めた。

もう一つの限界はペイロードサイズだ。8バイトというペイロードは、単純な数値（速度・舵角・ブレーキ圧）の交換には十分だが、大きなデータブロック（ソフトウェア更新・コーデックパラメータ・センサー生データの一部）を送るには細切れに分割してシーケンシャルに送る必要があり、スループットとリアルタイム性がさらに低下する。

帯域幅の不足に対する第一の答えがCAN FDだった。

2. CAN FD（Flexible Data-rate）の技術詳細

誕生と規格化

CAN FDはBoschが2011年に提案し、ISO 11898-1:2015として正式に規格化された。名称の「FD（Flexible Data-rate）」が示す通り、データフェーズの通信速度とペイロードサイズを「柔軟に」拡張したプロトコルだ。

アービトレーションフェーズとデータフェーズの分離

CAN FDの最も重要な革新はフレーム内のフェーズ分離だ。古典CANはフレーム全体を通じて同一のビットレートで動作する。CAN FDはフレームを2つのフェーズに分けている。

アービトレーションフェーズ：フレームIDによる調停（優先度決定）を行う区間。古典CANと互換性を持たせるため、最大1Mbps（実装上は多くの場合500kbps）で動作する。物理層の終端抵抗・ネットワーク長の制約が古典CANと共通なのはこのためだ。

データフェーズ：ペイロード（実データ）の転送区間。CAN FDではここで最大8Mbpsまでビットレートを上げることができる。これがFD（Flexible Data-rate）の本質だ。

実装上、データフェーズの速度は2Mbps・4Mbps・5Mbps・8Mbpsの中から選択することが多い。最大8Mbpsは理論値であり、ネットワーク長（ケーブル長）が短い（数メートル以内）ことと、ノード数が少ないこと、高品質な差動ペアケーブルの使用が条件になる。量産車では2〜5Mbpsで安定動作させるケースが現実的だ。

ペイロードの拡張：8バイトから64バイトへ

CAN FDはペイロードを最大64バイトに拡張した。古典CANの8バイトと比べて8倍だ。細切れ分割（マルチフレームセグメンテーション）の頻度が減り、同じデータ量を送るのに必要なフレーム数が激減する。バス利用率が改善し、リアルタイム性も向上する。

DLC（Data Length Code）フィールドもCAN FDでは拡張されており、8・12・16・20・24・32・48・64バイトの9種類のペイロードサイズを選択できる。

CRCの強化

CAN FDではCRC（Cyclic Redundancy Check）も強化された。古典CANは15ビットCRCだったが、CAN FDでは17ビットCRC（ペイロード16バイト以下）または21ビットCRC（17〜64バイト）を使用する。データフェーズのビットレートが上がると単位時間あたりのビット数が増えるため、誤り検出の確度を上げる必要があるためだ。

古典CANとの後方互換性

CAN FDはフレームフォーマットにFDFビット（FD Format）を追加することで、古典CANノードがCAN FDフレームを「エラー」として扱わずに無視できるよう設計されている（ただし古典CANノードがバスに残っている場合の共存には注意が必要で、全ノードがCAN FDに対応していることを確認する必要がある）。

この後方互換性の設計は重要だ。車載ネットワークは一度設計すると10〜15年以上の製品サイクルにわたって使われ続ける。既存のCANインフラを活かしつつ、CAN FD対応のECUを徐々に追加できる移行パスが設計されている。

量産採用状況

CAN FDは2014年頃からBMW・GM・VWグループが量産車に採用を開始し、2020年代に入ってからは新型車における採用が急速に標準化した。現在の高級車・EV向けプラットフォームでは、CAN FDがパワートレイン・シャシー制御系の主要バスとして定着している。

3. CAN XL：次の壁を超えるための規格

なぜCAN XLが必要か

CAN FDでも解決できない課題が2010年代後半から顕在化してきた。主な要因は三つだ。

第一はさらなる帯域要求だ。ADASのセンサーデータ・V2X（Vehicle-to-Everything）通信のペイロード・OTAソフトウェア更新のデータ量が増大するにつれ、CAN FDの最大8Mbps・64バイトペイロードでも不足するユースケースが増えてきた。

第二はEthernetとの共存コストだ。CAN FDとAutomotive Ethernetが混在するネットワークでは、ECU設計がCANトランシーバーとEthernetトランシーバーの両方を搭載する必要があり、コストと基板面積の負担が生じる。CAN FDとEthernetの中間に位置するプロトコルがあれば、この問題を緩和できる。

第三はゾーナルアーキテクチャとの相性だ。後述するゾーナルアーキテクチャでは、ゾーンECUが多数のセンサー・アクチュエータをアグリゲートする役割を担う。このゾーンECUと各サブシステム間の通信に、CAN FD以上・Ethernet未満の帯域幅・汎用性を持つプロトコルへの需要がある。

CAN XLの規格概要

CAN-in-Automation（CiA）が策定を進めているCAN XLは、2023年にCiA 610規格として公開されたが、ISO 11898-1への統合は現在進行中だ。完全な量産対応規格としての成熟は2025〜2026年を見込む状況で、本稿執筆時点では規格の主要仕様は固まっているが、量産採用の事例はまだ限定的だ。

主要技術パラメータを整理する。

データレート：データフェーズで最大20Mbps（目標値）。アービトレーションフェーズはCAN FDと同様に1Mbps以下で動作し、後方互換性を持つ。

ペイロードサイズ：最大2,048バイト（2KB）。CAN FDの64バイトに対して32倍の拡張だ。この容量があれば、Ethernetフレームのジャンボフレーム相当のデータをCAN XLの単一フレームで転送できる。

SIC（Signal Improvement Capability）物理層：CAN XLはCAN FD用のトランシーバーとは異なる新しい物理層トランシーバーが必要だ。SICはリンギング（信号の反射ノイズ）を積極的にキャンセルする仕組みを持ち、これにより従来のCANより長いネットワーク長でも高ビットレートを維持できる。

フレームフォーマット：CAN XLのフレームはCAN FDフレームと構造的に異なるが、アービトレーションフェーズの仕様を共有することで、CAN FDバスとCAN XLバスが同一ネットワーク上で混在できるよう設計されている（厳密な条件あり）。

Ethernetフレームのトンネリング：CAN XLは最大2KBのペイロードを活かして、Ethernetフレームをそのままカプセル化して転送する「Ethernetペイロードモード」をサポートする予定だ。これはCAN XLとEthernetが連続したネットワークを形成する際に、Ethernet用のスタックをCAN XL区間でも再利用できることを意味し、ソフトウェアアーキテクチャの一貫性を保ちやすい。

NXPのCAN XL対応

NXPはCAN XLへの対応を早期から進めており、S32G・S32EシリーズのLLCE（Low Latency Communication Engine）コアをCAN XL対応に拡張するロードマップを公表している。また、TJA1153等のCAN XL対応トランシーバー製品を展開しており、SIC物理層の実装も含む。業界の議論に携わる立場から見ると、OEMからの量産採用要求が本格化するのは2026〜2027年頃と見ている。

4. Automotive Ethernet：車載ネットワークの骨格になりつつある技術

なぜ民生品Ethernetでなく「Automotive」なのか

データセンター・オフィスで使われる民生品Ethernet（IEEE 802.3準拠）は、車載環境に直接適用できない。主な理由は三つだ。

第一に、民生品Ethernetは4ペアケーブル（CAT5e/CAT6）を使うが、これは車載用途には重すぎる。第二に、EMC（電磁両立性）の要件が異なる。車室内はエンジン点火ノイズ・モーター駆動ノイズ・電源ノイズが混在する厳しい電磁環境で、シールドケーブルを使わずに通信を成立させる工夫が必要だ。第三に、標準Ethernet（100BASE-TX等）はPHY（物理層IC）が2対のケーブルを使う設計だが、配線数を減らしたいという車載の要求と矛盾する。

Automotive Ethernetはこれらの課題を解決するため、「単線または差動2線（1ペア）のUTPケーブルで、EMC耐性を持ちながら高速データ転送を実現する」という設計思想に基づいている。

100BASE-T1（旧BroadR-Reach）

100BASE-T1はBroadcomが「BroadR-Reach」という名称で開発し、OPEN Allianceがケーブル・コネクタ仕様を策定、最終的にIEEE 802.3bwとして2015年に規格化された。

技術的な核心は「Echo Cancellation（エコーキャンセル）」と「3値PAM（Pulse Amplitude Modulation）符号化」の組み合わせだ。単線（1ペア）で双方向通信を実現するために、自分が送信した信号の反響（エコー）をDSPで精密にキャンセルし、相手の信号だけを抽出する。この技術により、シールドなしの2線で100Mbpsの全二重通信が実現できる。

BMW・Daimlerが2012〜2014年頃から量産車への採用を開始し、現在ではカメラ・ADAS ECU間の主要バスとして定着している。

1000BASE-T1

1000BASE-T1はIEEE 802.3bp（2016年規格化）で定義される1Gbpsの車載Ethernetだ。PAM-3符号化と750MHzのシンボルレートを組み合わせることで1Gbpsを1ペアの配線で実現する。ケーブル長は最大15m（標準）または40m（短距離）に制限されるが、車内の配線には十分だ。

1000BASE-T1はADAS ECUとドメインコントローラー間・ゾーンECUとゾーンコントローラー間など、大容量データの幹線用途に使われる。カメラの非圧縮映像ストリーム（1080p・30fps：約1.5Gbps）の転送には帯域不足だが、H.264/H.265で圧縮されたカメラ映像であれば十分だ。

10GBASE-T1（Multi-Gig：2.5G/5G/10G）

IEEE 802.3ch（2020年規格化）は、2.5Gbps・5Gbps・10Gbpsの3つのデータレートを単線1ペアで実現するマルチギガビット車載Ethernet規格だ。いわゆる「MultiGig」または「10GBASE-T1」と呼ばれる。

10Gbpsは符号化に高次のPAM-4（Pulse Amplitude Modulation 4値）を使い、シンボルレートは約5Gバウドになる。物理層の実装複雑度・PHYコスト・消費電力が100BASE-T1や1000BASE-T1より高く、現時点では中央演算ユニット（Vehicle Computer）とドメイン/ゾーンコントローラー間のバックボーン、LiDARの生点群データストリームなど、本当に大容量が必要なリンクへの適用が主な用途だ。

NXPはTJA1120（1000BASE-T1 PHY）・TJA1110（100BASE-T1 PHY）を主要製品として展開している。10GBASE-T1 PHYはSemtech・Marvellなどが先行しており、NXPも製品ラインナップを拡充中だ。

TSN（Time-Sensitive Networking）：Ethernetに決定論性を与える

標準Ethernetの最大の弱点は「決定論的レイテンシの欠如」だ。CANはCSMA/CAの調停機能によって優先度の高いメッセージの最悪レイテンシを保証できるが、標準EthernetのCSMA/CD（衝突検出）ベースのアクセス制御では、バスが混雑すると送信のタイミングが不確定になる。

TSN（Time-Sensitive Networking）はIEEE 802.1Qシリーズの拡張規格群で、Ethernet上に決定論的通信を実現する技術体系だ。車載TSNで特に重要なものを整理する。

IEEE 802.1AS（gPTP）：全ノードにわたるナノ秒精度の時刻同期を実現する。センサーフュージョン・SOME/IPの時刻ベースのサービス・TSNのスケジューリングの前提条件になる。gPTPは従来のPTP（IEEE 1588）を車載・ブリッジドネットワーク向けに最適化したものだ。

IEEE 802.1Qbv（Enhancements for Scheduled Traffic）：タイムゲート（Time-Aware Shaper：TAS）を使い、送信キューをタイムスロット単位で制御する。高優先度のリアルタイムトラフィック（ADAS制御）専用のタイムスロットを確保することで、バックグラウンドのベストエフォートトラフィック（OTA更新データ等）に邪魔されることなく決定論的に送信できる。

IEEE 802.1Qbu/IEEE 802.3br（Frame Preemption）：高優先度フレームが送信中の低優先度フレームを「割り込んで」中断させる機能。大きなデータフレームが送信中でも、高優先度の制御フレームを割り込みで先に送れる。

これらのTSN機能がAutomotive Ethernetスイッチ（車載Ethernetスイッチ）で実装されることで、CANが長年担ってきた「決定論的リアルタイム通信」の機能をEthernet上で再現できる。ただし実装の複雑度は高く、TSN設定（帯域予約・スケジューリングパラメータ）の設計・検証はツール（Siemens Simcenter等のネットワーク設計ツール）の支援がなければ非常に難しい。

5. 各プロトコルの住み分け：何を何で繋ぐか

プロトコル選定の判断基準

プロトコル選定は「帯域幅・決定論性・コスト・ペイロードサイズ・既存エコシステムとの連続性」の組み合わせで決まる。現時点での量産車における住み分けを整理する。

LIN（Local Interconnect Network）
最大20kbps。マスター・スレーブ構成のシングルワイヤーバスで、プロトコル設計は極限までシンプルだ。クロック信号をデータに埋め込んだ自己同期式であるため、スレーブノードはクロック源を必要とせず、ECUコストは数十円オーダーまで下がる。ドアミラー・シート位置調整・ウィンドウスイッチ・照明調光など、データレートとリアルタイム性の要求が低く、コスト感度が高い末端ノードに今後も残り続ける。

CXPI（Clock Extension Peripheral Interface）
トヨタとルネサスが主導しISO 20890として標準化された、LINの後継候補プロトコルだ。データレートはLINと同等の最大20kbpsだが、マスターが明示的なクロック信号を供給する「クロック拡張方式」を採用することで、ノイズ耐性と低消費電力を改善している。2015〜2016年頃からトヨタ・レクサス車の照明制御・スイッチ入力・空調パネルなどに採用されている。ただし、採用はトヨタを中心とした日系OEMに留まっており、VW・BMW・GMなど欧米OEMはLINからの移行先としてCXPIを選ばず、CAN FDかLIN継続を選択する傾向にある。「技術的改善と普及は別問題」の典型事例であり、IPライセンシングとエコシステム形成の観点から次回（深掘り#17）で改めて取り上げる。

古典CAN（1Mbps）
既存の量産ラインと診断ツール・CAN IDベースのログシステムの慣性が大きく、部品交換・メンテナンス向けの診断フレーム（OBD-II）やレガシー制御ECUに残存する。新規設計での採用は減少しているが、完全に消えるには10年以上かかると個人的には見ている。後述の「古典CANが残り続ける理由」で詳述する。

CAN FD（最大8Mbps・64バイトペイロード）
パワートレイン・シャシー・ボディ制御など、中高速の制御データ交換の主役。「CANの後継」として最も量産実績が積み上がっており、CAN FD対応のAUTOSARソフトウェアスタック・診断ツール・CANanalyzer等の開発ツールエコシステムも成熟している。今後5〜10年の新型車設計においても制御系バスの中心になる。

CAN XL（最大20Mbps・2KBペイロード）
CAN FDでは帯域不足だがEthernetのコスト・実装複雑度は避けたいユースケース、またはゾーナルアーキテクチャのゾーンECU〜サブシステム間の集約バスとして期待される。量産採用は2026〜2027年頃から本格化する見通し。ただし規格の成熟とトランシーバーの量産価格低下が前提だ。

100BASE-T1（100Mbps）
カメラ・ADASセンサーとADAS ECU間、コックピット映像系など、中容量の映像・センサーデータのリンクに使われる。すでに多くの量産車に採用されており、今後も継続採用が続く。

1000BASE-T1（1Gbps）
ドメインコントローラー間・ゾーンECUとゾーンコントローラー（CZC：Central Zone Controller）間の幹線。SOME/IPベースのサービス通信・DoIPの主要バスとして機能する。

10GBASE-T1（2.5G/5G/10Gbps）
Vehicle Computer（中央演算ECU）とドメイン/ゾーンコントローラー間のバックボーン、LiDARの生点群データ転送、OTA更新の大容量データ配信に使われる。コスト・消費電力の観点からまだプレミアム車中心の採用だが、2027〜2030年にかけて普及車へ展開していく見通しだ。

6. ゾーナルアーキテクチャへの統合設計

ドメインアーキテクチャからゾーナルアーキテクチャへ

従来の車載電子アーキテクチャは「ドメイン分散型」だった。パワートレインECU群・シャシーECU群・インフォテインメントECU群・ADASドメインコントローラーという機能領域（ドメイン）ごとに専用のECU群が設計され、各ドメイン内でCANバスが完結していた。

この設計の問題点は、SDVが要求する「ソフトウェアの柔軟な更新・追加」との相性が悪いことだ。機能を追加するたびにECUを追加しなければならず、ハーネスが増殖し、ECU間の依存関係がスパゲッティ化する。

ゾーナルアーキテクチャは、車両を「フロント左・フロント右・リア左・リア右・天井/中央」などの物理ゾーンで分割し、各ゾーンに「ゾーンECU」（またはゾーンコントローラー）を配置する設計だ。ゾーンECUは自ゾーン内のセンサー・アクチュエータを集約し、中央のVehicle Computer（または高機能ドメインコントローラー）との通信インターフェースを提供する。

ゾーン内バスとバックボーンバスの二層設計

ゾーナルアーキテクチャの通信設計は、自然と二層構造になる。

ゾーン内バス（ゾーンECU〜末端ECU間）：CAN FD（またはCAN XL）が主役。末端のセンサー・アクチュエータはコスト・消費電力の制約が大きく、Ethernetは過剰だ。CAN FDの成熟したエコシステムと低コスト実装が適合する。ゾーンECUはこのCAN/CAN FDバスの「ゲートウェイ」機能を担い、CANフレームをEthernetに変換してバックボーンに送出する。

バックボーン（ゾーンECU間・Vehicle Computer間）：Automotive Ethernetが主役。1000BASE-T1または10GBASE-T1でゾーンECUとVehicle Computerを結ぶ。ソフトウェア更新（OTA）・センサーフュージョン用の大量データ・SOME/IPのサービス通信・DoIPの診断パケットがここを流れる。

ゾーンECUのゲートウェイ機能の実装

ゾーンECUのゲートウェイ機能は実装難度が高い。CAN FDフレームをEthernetに変換する際に、プロトコル変換・ペイロード再構成・タイムスタンプ付与を行う必要がある。

CAN FDのデータフレームをEthernetのUDPペイロードにカプセル化するアプローチ（XCP on IP等）と、SOME/IPサービスとして再パッケージする（Service-Oriented実装）アプローチの二種類がある。後者は柔軟性が高いが実装コストも高く、またAUTOSARのCOMスタックとの整合設計が必要だ。

タイムスタンプの連続性も課題だ。CAN FDフレームには高精度のタイムスタンプが付かないが、EthernetにはgPTP（IEEE 802.1AS）による時刻同期がある。ゾーンECUがCAN FDフレームを受信した瞬間のgPTPタイムスタンプを付与してEthernetに送出する設計が必要で、これがセンサーフュージョンのデータアライメント精度を左右する。

NXP S32G・S32EとLLCE

NXP S32Gプロセッサは、ゾーナルアーキテクチャのゾーンECUを想定した設計だ。特に「LLCE（Low Latency Communication Engine）」は、CAN/CAN FD/LIN/Ethernetの各プロトコルの割り込みハンドリングをコアCPUに依存せず、専用ハードウェアで超低レイテンシ（マイクロ秒以下）処理する独自の通信処理エンジンだ。

S32Gは最大32個のCAN FDコントローラーと複数の1000BASE-T1ポートを統合しており、「CAN FDバスのゲートウェイ機能とEthernetスイッチ機能を単一チップで担う」という用途に設計されている。BMW・一部の日系OEMがS32Gをゾーンコントローラーまたはゲートウェイとして採用した実績がある。

FlexRayについては、一時期BMW・Daimler等が採用したが、2020年代に入ってからの新規採用は事実上なくなっている。S32Gも当初FlexRayコントローラーを統合していたが、後継製品ではFlexRayへの投資は継続されない方向だ。FlexRay対応ECUの延命は継続するが、新規プラットフォームではCAN FD＋Ethernetの組み合わせに置き換わっていく。

7. Automotive EthernetとMACsec・UN-R155

なぜEthernetはCybersecurityの標的になりやすいか

CANはネットワーク設計上、外部からの直接アクセスが限られており、物理的にバスに接触しなければ攻撃が難しい（ただし、OBD-IIポートからのCANへのアクセスは例外だ）。Automotive Ethernetはバックボーンに配置され、OTA更新・診断（DoIP）・SOME/IP通信が集中するため、攻撃者にとって「最も多くのECUにアクセスできるレイヤー」になる。

IP層（IPv4/IPv6）を使うAutomotive EthernetはTCP/UDPスタックを持つため、既知のIPネットワーク攻撃（Man-in-the-Middle・スプーフィング・サービス妨害等）がそのまま適用されうる。

MACsec（IEEE 802.1AE）

MACsecはEthernetフレーム（L2レイヤー）レベルで暗号化・完全性確認・再生攻撃防止を行う規格だ。車載での役割を具体的に説明する。

ゾーンECUとVehicle Computer間のEthernetリンクにMACsecを適用すると、2点間のリンク上を流れるすべてのEthernetフレームがAES-GCM（256ビット）で暗号化され、フレームのタグ（SecTAG）にICV（完全性確認値）が付加される。攻撃者がバスに物理的に接触してフレームをキャプチャしても、鍵なしには内容を解読できない。また、キャプチャしたフレームを後で再送する「再生攻撃」もシーケンス番号で検出・排除される。

MACsecはポイント・ツー・ポイントのリンク単位で保護する設計のため、Ethernetスイッチを経由する場合はスイッチ内部での復号・再暗号化が必要になる（ホップ・バイ・ホップ方式）。これはスイッチのハードウェアコスト（MACsec対応ポートが必要）と鍵管理の複雑化を招く。

UN-R155とEthernet

UN-R155（UNECE WP.29）は2022年7月以降の新型認証取得車に適用される車両サイバーセキュリティ規制だ。具体的に何を要求するかをEthernetとの関係で見ると、「車両と外部通信（V2X・OTA・診断）のインターフェースで適切な認証・暗号化を実施すること」と「サイバー脅威のリスクアセスメントと継続的な監視・対応（CSMS：Cybersecurity Management System）」が求められる。

Automotive Ethernetがバックボーンになる設計では、MACsecによるリンク保護、TLSによるアプリケーション層の保護、DoIP（診断）通信の認証制御が主なセキュリティ実装の柱になる。日本でも2024年10月以降の新型認証取得車に国土交通省がUN-R155相当の要件を適用しており、現在進行中の新型車プラットフォーム開発では必須事項になっている。

8. 著者の視点

古典CANが残り続ける理由

「CAN FDがあるのになぜ古典CANが残るのか」という疑問を業界外の技術者から受けることがある。答えは「車のライフサイクルとサプライチェーンの慣性」だ。

一台の車は設計から廃車まで15〜20年のライフサイクルを持つ。2010年代前半に設計されたプラットフォームには古典CANが使われており、そのプラットフォームは2020年代後半まで生産が続く。ディーラーの診断ツール（スキャンツール）・部品商社のCANロガー・工場の製造ライン検査装置も古典CAN（OBD-II）に依存している。これらのエコシステム全体を一斉に更新するコストは膨大で、単体のプロトコル移行コストをはるかに上回る。

さらに、末端のシートポジションモーターやウィンドウスイッチのような極低速アクチュエータにとって、1Mbpsでも過剰な帯域だ。これらのECUを古典CAN（またはLIN）から更新するROI（投資対効果）は、量産コスト観点からは正当化しにくい。

結論として、古典CANはハイエンド・EV中心の新規プラットフォームでは徐々に消えていくが、バジェット車・商用車・アフターマーケット市場では2030年代まで残り続けると個人的には見ている。

CAN XLの普及見通し

CAN XLへの期待と実態のギャップについて、率直に書いておきたい。

CAN XLの規格仕様は技術的に魅力的だ。20Mbps・2KBペイロードというスペックはCAN FDとAutomotive Ethernetの間を埋める設計として理にかなっている。Ethernetペイロードモード（CAN XL上でEthernetフレームをトンネリングする）は、Ethernetベースのソフトウェアスタックをゾーン内のバスにも適用できるため、アーキテクチャの一貫性を高める効果がある。

ただし、普及にはいくつかの壁がある。

第一に、トランシーバーの量産価格だ。CAN XLのSIC物理層対応トランシーバーはまだ量産初期で、CAN FDトランシーバーより高価だ。大量採用が始まって初めて価格が下がる「鶏と卵」の問題がある。

第二に、「CAN FDで何とかなる」という空気だ。ゾーンECU〜サブシステム間のユースケースの多くはCAN FD（8Mbps・64バイト）で設計上成立する。CAN XLに移行するコスト（トランシーバー更新・ソフトウェアスタック更新・検証コスト）を正当化できるユースケースがどれだけあるか、OEMサイドで精査が続いている段階だ。

私の見通しでは、CAN XLの本格的な量産採用は2027年以降、EV・SDVプラットフォームの次世代刷新を機にゾーナルアーキテクチャの標準バスとして採用されるシナリオが最も現実的だ。それまでの期間は、CAN FD＋Automotive Ethernetの二本立てが主役であり続ける。

Automotive Ethernetが突きつける設計の難しさ

Automotive Ethernetは帯域幅・サービス指向アーキテクチャへの親和性という点でCANを大きく上回る。しかし実装の難しさもCANを大きく上回る。

TSNのスケジューリング設定は、ネットワーク全体のトラフィックフロー・帯域予約・タイムスロット設計を事前に正確に把握していなければ正しく設定できない。CANの調停（自動的に優先度が決まる）と比べると、設計の手間が格段に増える。ネットワーク設計ツールなしに手作業でTSNパラメータを設定することは現実的ではなく、AUTOSAR配線記述（ARXML）とTSN設定ツールの連携が設計フローとして確立されていないOEMでは、Automotive Ethernet採用後の統合フェーズで多大な工数が発生する。

MACsecの鍵管理も実装難度が高い。ゾーンECUごとに異なる鍵を管理し、OTA更新で鍵をローテーションし、特定ECUが盗難・侵害された場合に鍵を失効させる——この一連の「PKI（公開鍵基盤）管理」は、既存のCAN中心の組織には新しいケイパビリティを要求する。

実装現場では「Ethernetに移行したら決定論性が担保できないのではないか」という懸念も根強い。TSNを正しく設定すれば理論上は決定論的だが、テスト・検証の工数がCANより大幅に多い。この「テスト難度の増加」が、ゾーナルアーキテクチャへの移行スピードに影響を与えていると感じる。

半導体ベンダーの通信戦略

Automotive Ethernetの競合状況についても触れておきたい。PHYのレイヤーではBroadcom・Marvell・TI・NXP・Microchipが主要ベンダーだ。EthernetスイッチのレイヤーではNXP（SJA1110・SJA1124）とBroadcom（BCM8988xシリーズ）がTSN対応の車載スイッチ市場を争っている。

NXPのSJA1110は8ポートのTSN対応車載Ethernetスイッチで、gPTP・IEEE 802.1Qbv・MACsecを統合したSoCだ。S32GプロセッサとSJA1110を組み合わせる構成が「ゾーナルゲートウェイ」の典型的なリファレンスデザインになっており、複数のOEM向けプロジェクトで採用実績がある。

CAN XLについては各社のロードマップが固まりつつある段階で、NXP・Infineon・TexasInstrumentsが先行してCAN XL対応トランシーバーのサンプル提供を進めている。量産価格が成立する規模感になるには、主要OEMからの正式採用が最低でも2〜3プラットフォーム必要だ。

まとめ

LINとCXPIは末端ノードの住み分け：LIN（最大20kbps・シングルワイヤー・マスタースレーブ）はドア・シート・照明など低速アクチュエータの最安値解として残存する。CXPIはトヨタ・日系OEM中心のLIN後継候補だが、欧米OEMはCAN FDかLIN継続を選択しており、グローバルスタンダードには至っていない
CANの技術的遺産は巨大：古典CAN（1Mbps・8バイト）は30年の量産実績・エコシステム・診断ツールの慣性により、バジェット車・商用車では2030年代まで残り続ける。完全移行には設計サイクルを超えた時間がかかる
CAN FDはすでに実質標準：最大8Mbps・64バイトペイロードは制御系バスとして十分であり、量産実績・ツールエコシステムの成熟度でCAN FDが今後5〜10年の制御系バスの中心になる
CAN XLは有望だが普及は2027年以降：20Mbps・2KBペイロード・Ethernetトンネリングは技術的に魅力的だが、量産トランシーバー価格とOEMの採用判断が遅れている。本格普及は次世代SDVプラットフォームの刷新タイミングを待つ
Automotive EthernetはSDVの骨格：100BASE-T1→1000BASE-T1→10GBASE-T1の三層がセンサー・ドメイン・バックボーンを担い、SOME/IP・DoIP・TSNがEthernet上のサービス指向アーキテクチャを実現する
TSNは不可欠だが設定が難しい：IEEE 802.1AS（gPTP）・Qbv（タイムゲート）・FramePreemptionの組み合わせでCAN並みの決定論性をEthernet上で実現できるが、設計・検証コストはCANより格段に高い
ゾーナルアーキテクチャは二層設計が現実解：ゾーン内はCAN FD（低コスト・成熟）、バックボーンはAutomotive Ethernet（高帯域・SOME/IP対応）の組み合わせが量産設計として定着しつつある
MACsecとUN-R155は不可避：Automotive Ethernetがバックボーンになる設計では、MACsecによるリンク暗号化とPKI鍵管理がUN-R155対応の中核になる。既存組織が持っていないケイパビリティの確立が必要だ
NXP S32G＋SJA1110がゾーナルゲートウェイの典型構成：LLCE（超低遅延通信エンジン）・32 CAN FDコントローラー・TSN対応Ethernetスイッチを組み合わせた「CANとEthernetのゲートウェイ」が実用設計として採用されている

次回（深掘り#17）は、CANそのものを深掘りする。BoschがなぜCANをISO標準化しながらIPライセンシングで成功させたか、CANopenによって産業機器市場にも展開しながら最終的にEthernetベースのプロトコルに置き換えられた経緯、そして車載では今も残り続ける理由——を取り上げる予定だ。