第2章通信协议基础

第1章：通信协议基础——车载网络通信的演进

大家好，我是你们的老朋友。今天咱们聊聊车载通信协议栈的根基——网络通信的演进之路。

说实话，我刚入行那会儿，车上最先进的也就是CAN总线。那时候觉得，能跑1Mbps已经很了不起了。现在回头看，真是感慨万千。

CAN总线，全称Controller Area Network，1986年由Bosch公司发明。它解决了传统点对点布线的问题——你想想看，一辆车里有几十个ECU，如果每个都单独拉线，那线束比车还重。

CAN总线的核心优势：

但CAN也有硬伤。我记得2015年做某个项目时，客户要求传输固件升级包，CAN总线那8字节的数据场，传一个1MB的固件要等半天。这就是CAN FD诞生的直接原因。

CAN vs CAN FD 关键差异

CAN FD最大的改进在于：仲裁段保持原速率，数据段可以提速。说白了，就是该抢总线的时候慢慢来，传数据的时候猛加速。这个设计很聪明，既保证了兼容性，又提升了吞吐量。

我的经验之谈：做CAN FD设计时，千万别把数据段速率设得太高。我曾经在一个项目中把速率调到10 Mbps，结果线束稍微长一点就丢帧。后来老老实实降到5 Mbps，稳如老狗。

到了自动驾驶时代，CAN FD也扛不住了。一个激光雷达每秒产生几十MB的数据，64字节一帧地传，CPU得累死。这时候，车载以太网登场了。

车载以太网和普通以太网有啥区别？

嗯，这里要注意：车载以太网不是简单地把办公室的网线塞进车里。它的物理层完全不同，你拿个普通RJ45水晶头是接不上的。

避坑指南：我曾经见过有人用普通以太网线做车载测试，结果EMC测试直接挂掉。车载以太网的共模扼流圈和端接电阻都有特殊要求，别图省事。

OSI七层模型，学通信的都知道。但它在车上到底怎么用？我给大家画个映射图：

你可能会问：为什么车上要用七层？直接传数据不就行了？

其实，分层的好处在于解耦。我举个例子：你在应用层写UDS诊断服务，根本不用管底层是CAN还是以太网。换总线？改改配置就行，代码几乎不用动。

说完OSI模型，咱们看看实际的车载协议栈长什么样。以AUTOSAR为例：

应用层（SWC）
    ↓↑
RTE（运行时环境）
    ↓↑
BSW（基础软件层）
    ├── 服务层：诊断、存储、通信管理
    ├── ECU抽象层：I/O、ADC、PWM
    └── 微控制器抽象层：MCU驱动、SPI、CAN驱动
    ↓↑
硬件层（MCU、收发器）

通信协议栈在BSW里占了很大一块。具体来说：

我个人习惯把协议栈想象成一根水管。上层是水龙头（应用），下层是水泵（硬件），中间每一层都是不同口径的接头。接头没接好，水就漏了或者流不动。

核心要点：协议栈分层的本质是「关注点分离」。驱动工程师只管收发比特流，网络工程师只管路由转发，应用工程师只管业务逻辑。各司其职，出了问题也好定位。

我记得有一次，客户报故障说CAN报文收不到。我一看，应用层说没收到，驱动层说发成功了。查了半天，发现是CAN接口层配置错了——报文ID过滤设反了。这就是分层的好处，一层一层排查，很快就能定位。

好了，这一章咱们把车载通信的演进脉络理清了。从CAN到CAN FD再到车载以太网，每一步都是为了解决带宽和实时性的矛盾。OSI七层模型和分层架构，则是我们设计复杂系统的利器。

下一章，咱们深入CAN FD的帧结构，看看那64字节的数据场到底怎么玩。到时候我会分享一些我在实际项目中踩过的坑，保证让你少走弯路。

课后思考：为什么CAN FD的仲裁段不能提速？如果仲裁段也跑8 Mbps，会发生什么？想明白这个问题，你就真正理解了CAN总线的精髓。