4. 车载网络与工业网络概览
在中央计算平台出现之前，汽车电子电气架构长期以“分布式 ECU + 多总线”为主：不同功能域使用不同总线，各自满足成本、带宽、实时性与可靠性要求。理解 CAN、CAN FD、LIN、FlexRay、以太网与 TSN 的基本特点与适用场景，是理解中央计算平台通信与中间件设计的前提。本节从“为什么需要多种协议”出发，建立一张可对照的网络选型地图。
一、核心原理：协议差异来自三类约束
车载与工业网络协议的分化，本质上由三类约束共同决定：带宽（每秒能传多少数据）、实时性（最坏情况下的确定性时延）、成本与拓扑（线束、节点数、供电与布线复杂度）。CAN 与 LIN 以低成本、多节点、广播式通信见长；FlexRay 强调时间触发与容错；以太网提供高带宽与灵活拓扑；TSN 则在以太网上叠加时间同步与流量调度，使其具备确定性。
从通信模型看，CAN、CAN FD、LIN、FlexRay 都属于“总线型、广播、基于报文 ID 或时隙”的通信；以太网是“交换式、点对点、基于 MAC/IP 与 VLAN”的通信；TSN 是 IEEE 802.1 系列标准的集合，核心机制包括 gPTP 时间同步、时间感知整形（TAS）、帧抢占、信用整形等。中间件在中央计算平台中要做的，正是把这些异构链路抽象为统一的通信服务。
二、方法流程：从需求到协议选型
协议选型不是“越新越好”，而是按需求逐层筛选。建议按以下流程推进：
- 明确数据特征：周期/事件、单帧大小、发送频率、是否多播。
- 确定实时性等级：软实时（百毫秒级）、硬实时（毫秒级）、确定性（微秒级抖动）。
- 评估拓扑与成本：节点数量、线束长度、是否需要供电、是否可复用现有线束。
- 匹配协议能力：对照带宽、时延、容错、诊断与安全能力。
- 验证与回归：用总线负载率、时延分布、丢帧率等指标验证。
选型口诀：低速执行看 LIN，车身控制看 CAN，大数据量看 CAN FD，高可靠底盘看 FlexRay，高带宽与域集中看以太网，确定性融合看 TSN。
三、案例/场景：中央计算平台中的分层组网
以典型“中央计算 + 区域控制器”架构为例：中央计算单元与区域控制器之间使用千兆以太网，承载摄像头、激光雷达、OTA 与诊断数据；区域控制器向下连接 CAN FD，接入车身、动力与底盘 ECU；车门、座椅、灯光等低速节点使用 LIN；线控底盘等安全关键回路可保留 FlexRay 或采用 TSN 以太网。中间件需要同时提供 CAN 报文收发、SOME/IP 服务发现、DDS 发布订阅与 TSN 时间同步接口。
# 典型链路参数示例（用于负载与时延评估）
CAN : 500 kbit/s, 负载率 < 50%, 周期报文 10 ms
CAN FD: 2 Mbit/s 数据段, 有效载荷 32 B, 周期 5 ms
LIN : 19.2 kbit/s, 主节点调度表 20 ms
FlexRay: 10 Mbit/s, 静态段 5 ms 周期, 双通道冗余
Ethernet: 1000BASE-T1, VLAN 10/20/30, 帧长 128~1500 B
TSN : gPTP 同步精度 < 1 us, TAS 门控周期 1 ms四、对比清单：六类协议关键特性
| 协议 | 带宽 | 实时性 | 拓扑 | 典型场景 |
|---|---|---|---|---|
| LIN | ≤20 kbit/s | 软实时 | 单主多从 | 车门、座椅、雨刮 |
| CAN | ≤1 Mbit/s | 事件触发，优先级仲裁 | 总线 | 车身、动力、诊断 |
| CAN FD | 数据段 ≤8 Mbit/s | 较 CAN 提升 | 总线 | 域控制器、刷写、大数据量信号 |
| FlexRay | ≤10 Mbit/s | 时间触发，确定性高 | 双通道总线 | 线控底盘、安全关键 |
| 车载以太网 | 100M/1G/10G | 尽力而为，需上层保障 | 交换式星型 | 摄像头、雷达、OTA、诊断 |
| TSN | 同以太网 | 确定性时延与同步 | 交换式，支持冗余 | 域集中、区域控制器骨干 |
五、误区与复盘
常见误区一：认为以太网可以完全替代 CAN。实际上，CAN 在低成本、多节点、短帧广播与故障容错方面仍有优势，中央计算平台通常是“以太网骨干 + CAN/LIN 边缘”的混合架构。
常见误区二：把 TSN 当成“更快的以太网”。TSN 的价值在于时间同步与流量调度带来的确定性，而不是单纯提升带宽；若没有 gPTP 与门控配置，普通以太网仍无法保证硬实时。
常见误区三：忽略总线负载率。CAN/CAN FD 在负载率超过 50% 后，最坏时延会显著上升，必须通过报文合并、周期调整或分段组网来优化。
复盘时建议记录三类数据：各链路的峰值负载率、关键报文的最坏时延、以及跨协议转换节点的丢包与抖动。只有把这些指标与协议特性对应起来，才能在中央计算平台的中间件设计中做出可验证的通信方案。