現代の自動車開発における最大のボトルネックの一つは、指数関数的に増加するデータ通信量と、それに伴う物理的なワイヤーハーネスの重量増加です。ECU（Electronic Control Unit）の数が100を超える高級車では、従来のP2P（Point-to-Point）接続や低速なバス通信だけでは、ADAS（先進運転支援システム）やインフォテインメントが要求するギガビット級のスループットを処理できません。
本稿では、レガシーながら信頼性の高いCAN (Controller Area Network)と、広帯域通信を担う車載イーサネットの技術的特性を比較し、これらを統合する次世代E/E（Electrical/Electronic）アーキテクチャの設計指針を提示します。
1. CAN：決定論的通信と調停メカニズム
CANが1986年の登場以来、現在もデファクトスタンダードであり続ける理由は、その高い耐ノイズ性と「決定論的（Deterministic）」な動作にあります。パワートレインやシャシー制御など、ミリ秒単位の遅延が許容されないクリティカルなシステムにおいて、CANのアーキテクチャは非常に合理的です。
物理層：差動信号によるノイズ除去
自動車内部はイグニッションやモーター駆動による電磁ノイズが飛び交う過酷な環境です。CANはツイストペアケーブル（CAN_H, CAN_L）を用いた差動信号方式を採用しています。コモンモードノイズ（両方の線に同相で乗るノイズ）は、受信側の差動アンプで相殺されるため、通信の整合性が保たれます。
- ドミナント (0): CAN_H 3.5V / CAN_L 1.5V (電位差 2V)
- リセッシブ (1): CAN_H 2.5V / CAN_L 2.5V (電位差 0V)
CSMA/CRによる非破壊的ビット調停
CANの最大の特徴は、IDベースの優先順位制御です。複数のノードが同時に送信を開始した場合、IDの値が小さい（0が多い）メッセージがバスの電気的特性（ドミナント）によって生き残ります。これにより、高優先度のメッセージは遅延なく送信され、低優先度のメッセージは自動的に再送待ちとなります。
以下は、このビット調停（Arbitration）の論理をシミュレートするPythonコードです。
def simulate_arbitration(node_a_id, node_b_id):
"""
CANバス上のビット調停ロジックのシミュレーション
Bit 0 (Dominant) は Bit 1 (Recessive) に勝つ
"""
# IDを2進数文字列に変換 (例: 11bit標準ID)
bin_a = f"{node_a_id:011b}"
bin_b = f"{node_b_id:011b}"
print(f"Node A: {bin_a}, Node B: {bin_b}")
for i in range(11):
bit_a = int(bin_a[i])
bit_b = int(bin_b[i])
# バス上の状態: 論理積 (0があれば0になる = Wired-AND特性)
bus_state = bit_a & bit_b
# 各ノードはバスの状態をモニタリングし、自身が送信したビットと比較する
if bit_a != bus_state:
print(f"Bit {i}: Node A lost arbitration (Sent 1, Bus 0)")
return "Node B Wins"
if bit_b != bus_state:
print(f"Bit {i}: Node B lost arbitration (Sent 1, Bus 0)")
return "Node A Wins"
return "Collision (Same IDs not allowed)"
# 優先度が高いのはIDが小さい方 (0が多い方)
# ID 0x1A (00000011010) vs ID 0x1B (00000011011)
result = simulate_arbitration(0x1A, 0x1B)
# 結果: Node A Wins (最後のビットで勝敗が決まる)
2. 車載イーサネット：帯域幅とスケーラビリティ
CAN（最大1Mbps）やCAN-FD（最大5Mbps〜8Mbps）では、LiDARの点群データや高解像度カメラ映像の伝送は不可能です。ここで、IT分野で成熟したイーサネット技術が導入されましたが、車載要件（EMC、重量、コスト）を満たすために物理層が変更されています。
100BASE-T1 / 1000BASE-T1 の革新
家庭用のイーサネット（100BASE-TXなど）は2対または4対のケーブルを使用しますが、車載イーサネット（BroadR-Reach技術ベース）は、1対の非シールドツイストペア（UTP）で全二重通信を実現しています。これにより、ワイヤーハーネスの重量を削減しつつ、100Mbps〜1Gbps、さらにはマルチギガビットの帯域を提供します。
| 特性 | CAN-FD | Automotive Ethernet (100BASE-T1) |
|---|---|---|
| トポロジー | バス型 (すべてのノードが共有) | スイッチ型 (P2P + スイッチングハブ) |
| 最大帯域 | ~8 Mbps | 100 Mbps / 1 Gbps / 10 Gbps+ |
| アクセス制御 | イベント駆動 (CSMA/CR) | スイッチング (全二重) |
| ケーブル | ツイストペア (シールド/非シールド) | 単一ツイストペア (UTP) |
| 主な用途 | 制御信号 (エンジン, ブレーキ) | バックボーン, カメラ, LiDAR, OTA |
TSN (Time-Sensitive Networking) の必要性
標準のイーサネットは「ベストエフォート」方式であり、パケットの到達時間は保証されません。しかし、自動運転システムではセンサーフュージョンのために厳密な同期が必要です。IEEE 802.1AS（時刻同期）やIEEE 802.1Qbv（タイムアウェアシェーパー）などのTSN規格群を実装することで、イーサネット上でリアルタイム制御通信が可能になります。
3. ゾーンアーキテクチャとゲートウェイ設計
従来の「ドメイン型アーキテクチャ（機能別）」から、物理的な位置でECUをまとめる「ゾーン型アーキテクチャ」への移行が進んでいます。この移行において、CANとイーサネットの連携は不可欠です。
ハイブリッド構成の実装
- エッジ (Zone ECU): 各ドアや座席付近のセンサー/アクチュエータは、CAN/LINでゾーンECUに接続。
- バックボーン (HPC): ゾーンECU同士およびセントラルコンピュータ（HPC）間は、高速イーサネットで接続。
# 概念的なゲートウェイのルーティングテーブル構造
# CANフレーム ID -> イーサネット IP/Port へのマッピング
routing_table = {
# CAN ID: (Target IP, Target Port, Protocol)
0x123: ("192.168.10.5", 5000, "UDP"), # エンジン回転数 -> メーターパネル
0x456: ("192.168.10.8", 6000, "TCP"), # 故障診断コード -> テレマティクスユニット
}
def gateway_process(can_frame):
if can_frame.id in routing_table:
target = routing_table[can_frame.id]
# CANペイロードをIPパケットにカプセル化
ip_packet = encapsulate(
src_ip="192.168.10.1", # Gateway IP
dst_ip=target[0],
payload=can_frame.data
)
send_ethernet(ip_packet)
else:
# フィルタリング（セキュリティ対策として破棄）
log_security_event("Unauthorized CAN ID detected")
結論：共存による最適化
CANとイーサネットは競合する技術ではなく、補完関係にあります。低レイテンシで堅牢な制御を要する末端部分にはCAN（またはCAN XL）を残し、大容量データ転送とOTA（Over-The-Air）アップデートが必要なバックボーンにはイーサネットを採用するのが最適解です。
エンジニアは、単に帯域幅を広げるだけでなく、TSNによる確定性の確保や、ゾーンゲートウェイによる効率的なルーティング設計を行うことで、SDV（Software-Defined Vehicle）の基盤を構築する必要があります。
Post a Comment