第二章 整车网络通信基础：CAN/CANFD、LIN、以太网、FlexRay基础原理与对比
各位同学，大家好。今天我们聊聊整车网络通信。
说实话，刚入行那会儿，我觉得网络协议就是一堆枯燥的帧格式。直到有一次，我在台架上调试一辆车，CAN总线莫名其妙丢帧，查了三天才发现是终端电阻虚焊了。从那以后，我深刻理解了——搞懂网络基础，是架构师的必修课。
2.1 为什么需要这么多网络协议？
你想想看，一辆新能源车上有上百个ECU。有控制安全气囊的，有控制车窗的，还有控制电机和电池的。它们的实时性要求、数据量大小、成本敏感度完全不同。
举个例子：
- 安全气囊触发信号，延迟超过1ms就可能出人命
- 车窗升降指令，延迟100ms也没人察觉
- OTA升级时，需要一次传输几兆甚至几百兆的数据
所以，没有一种协议能包打天下。我们需要根据场景选型。
核心原则：合适的协议用在合适的位置。成本、带宽、实时性、可靠性，四者之间做权衡。
2.2 CAN总线——老当益壮的主力军
CAN总线，1980年代由博世发明。说实话，它年纪比在座很多同学都大。但直到今天，它依然是车载网络的中流砥柱。
2.2.1 基本原理
CAN是差分信号传输，两根线：CAN_H和CAN_L。逻辑1叫隐性，逻辑0叫显性。显性可以覆盖隐性——这就是仲裁的基础。
我习惯用一句话概括：谁先发0，谁就赢。
为什么？因为多个节点同时发送时，总线通过线与机制仲裁。ID小的优先级高。这保证了高优先级消息的实时性。
2.2.2 帧结构
CAN有标准帧（11位ID）和扩展帧（29位ID）。我建议你重点记住数据帧：
SOF + 仲裁场 + 控制场 + 数据场 + CRC + ACK + EOF数据场最多8字节。嗯，这就是CAN最大的痛点——带宽不够。
我的经验：在项目中，CAN总线负载率建议控制在30%以下。超过40%就要小心了。我曾经见过一个项目，负载率飙到70%，结果转向灯信号偶尔丢失，查得我头秃。
2.3 CAN FD——CAN的升级版
CAN FD，全称CAN with Flexible Data-Rate。说白了，就是给CAN打了鸡血。
2.3.1 两大改进
- 数据场扩展：从8字节扩展到最多64字节
- 可变速率：数据段可以切换到更高的波特率（比如2Mbps甚至5Mbps）
你想想看，原来发一个诊断请求要拆成好几帧，现在一帧搞定。效率提升不是一星半点。
2.3.2 兼容性
CAN FD向下兼容CAN。但要注意：CAN FD节点和CAN节点混用时，CAN FD节点必须能识别CAN帧，反之则不行。
避坑指南：我曾经在一个项目中，把CAN FD节点接入了纯CAN网络。结果CAN FD节点发送了FD帧，老节点直接报错，总线瘫痪。所以，混网时一定要配置好。
2.4 LIN总线——低成本的小弟
LIN总线，说白了就是CAN的廉价替代方案。单线传输，成本极低，但速度也慢——最大20kbps。
2.4.1 主从架构
LIN网络只有一个主节点，多个从节点。主节点负责调度，从节点只能响应。我习惯把LIN比作「老师点名」——老师问谁，谁才能回答。
2.4.2 典型应用
- 车窗开关
- 座椅调节
- 车灯控制
- 雨刮器
这些功能对实时性要求不高，用LIN刚刚好。一个LIN网络最多挂16个节点，够用了。
我的建议：能用LIN的地方，别用CAN。省下的成本，够你吃好几顿火锅了。但要注意，LIN的EMC性能不如CAN，布线时尽量远离高压线束。
2.5 FlexRay——为安全而生
FlexRay，这个名字你可能不太熟悉。它主要用在高端车型的线控制动、线控转向等安全关键领域。
2.5.1 核心特点
- 双通道：冗余设计，一个通道坏了，另一个顶上
- 时间触发：确定性通信，延迟可预测
- 高速率：单通道10Mbps，双通道20Mbps
为什么需要时间触发？因为CAN是事件触发，消息多了会排队。FlexRay不一样，每个消息的发送时刻是预先规划好的。说白了，就是「排班表」式的通信。
2.5.2 现状
说实话，FlexRay在乘用车领域用得越来越少。为什么？因为以太网来了。但它在一些商用车和特种车辆中还有应用。
一句话总结：FlexRay很强，但太贵、太复杂。除非你搞线控底盘，否则大概率用不上。
2.6 车载以太网——未来的主角
车载以太网，这是目前最火的方向。100BASE-T1、1000BASE-T1，速率从100Mbps到1Gbps。
2.6.1 为什么需要以太网？
- OTA升级：几百兆的固件，用CAN传？传到你怀疑人生
- 自动驾驶：激光雷达、摄像头的数据量，CAN根本扛不住
- 域控制器架构：域间通信需要高带宽
2.6.2 与传统以太网的区别
车载以太网用的是单对差分线，不是传统的四对线。为什么？为了减重、降成本。而且，它支持PoDL（供电），一根线既传数据又供电。
注意：车载以太网的物理层和标准以太网不同。别想着拿个普通网线就往车上怼。我曾经见过有人用标准RJ45接口做测试，结果EMC过不了，干扰得一塌糊涂。
2.7 协议对比总结
好了，我们做个对比。我习惯用一张表来总结：
| 协议 | 速率 | 数据场 | 拓扑 | 成本 | 典型应用 |
|---|---|---|---|---|---|
| CAN | 最高1Mbps | 8字节 | 总线型 | 低 | 动力、车身、诊断 |
| CAN FD | 最高5Mbps | 64字节 | 总线型 | 中 | 动力、OTA、诊断 |
| LIN | 20kbps | 8字节 | 主从型 | 极低 | 车窗、座椅、车灯 |
| FlexRay | 10Mbps/通道 | 254字节 | 星型/总线型 | 高 | 线控、安全系统 |
| 以太网 | 100Mbps~1Gbps | 1500字节+ | 星型 | 中高 | ADAS、OTA、域间通信 |
2.8 如何选型？
我个人习惯按以下思路来：
- 先看带宽需求：数据量大？上以太网。数据量小？CAN或LIN。
- 再看实时性：安全关键？考虑FlexRay或时间敏感以太网。
- 最后看成本：能省则省。车窗控制用LIN，别用CAN。
核心观点：没有最好的协议，只有最合适的协议。未来的趋势是混合网络——CAN FD做骨干，LIN做末梢，以太网做高速通道。
2.9 小结
这一章我们聊了五种网络协议。说实话，内容不少，但都是干货。
你想想看，搞懂这些基础，你就能理解为什么一辆车里有这么多「语言」在同时交流。作为架构师，你的任务就是让它们和谐共处，不出乱子。
下一章，我们会深入聊聊网络拓扑设计。到时候，我会分享一些实际项目中的踩坑经历。嗯，保证精彩。
课后思考：如果你要设计一个纯电动车的网络架构，你会怎么选型？动力域、车身域、智能驾驶域，分别用什么协议？试试看。