第三讲：XCP传输层（TL）——从CAN到以太网，总有一款适合你

大家好，欢迎来到第三讲。

上一讲我们聊了XCP协议的基础框架，说白了就是知道了XCP能干什么。但有个关键问题没解决：数据到底是怎么在总线上跑的？

这就是我们今天要讲的传输层（Transport Layer，简称TL）。

我个人习惯把传输层理解为XCP的“腿”。没有腿，你脑子里再有想法也走不动。XCP之所以强大，就是因为它能“长”在不同的总线上——CAN、CAN FD、以太网、FlexRay，甚至还有LIN和SENT（虽然用得少）。

今天我们就重点聊聊最常见的几种：CAN传输层、CAN FD传输层、以太网传输层，以及FlexRay传输层。

一、CAN传输层详解：CTO与DTO

先讲最经典的CAN传输层。这是XCP的“老本行”，也是目前量产项目里用得最多的。

CAN传输层里有两个核心概念：CTO（Command Transfer Object） 和 DTO（Data Transfer Object）。

说白了：

• CTO：主设备发给从设备的命令，比如“给我读这个地址的数据”。
• DTO：从设备回复给主设备的数据，比如“你要的数据是0x1234”。

嗯，这里要注意：CTO和DTO都是通过CAN报文来传输的。但CAN报文长度有限（标准帧8字节，扩展帧也是8字节），所以XCP协议做了非常精巧的设计。

1. CTO的结构

一个CTO报文长这样：

| 字节0 | 字节1 | 字节2 | 字节3 | 字节4 | 字节5 | 字节6 | 字节7 |
| PID  | 命令  | 参数  | 参数  | 数据  | 数据  | 数据  | 数据  |

• PID（Packet Identifier）：标识这个包的类型。比如0x00表示CMD（命令包），0x01表示EV（事件包），0x02表示SERV（服务包）。
• 命令：具体的XCP命令，比如CONNECT（连接）、GET_ID（获取ID）、SHORT_UPLOAD（短上传）等。
• 参数/数据：命令的附加信息。

我在项目中遇到过一个问题：PID和CAN ID容易搞混。PID是XCP协议层的标识，而CAN ID是总线层的标识。两者完全不是一回事。刚开始做标定的同事经常问我：“为什么我改了CAN ID，PID就不对了？”——嗯，这个问题其实问错了方向。

2. DTO的结构

DTO是响应包，结构类似：

| 字节0 | 字节1 | 字节2 | 字节3 | 字节4 | 字节5 | 字节6 | 字节7 |
| PID  | 数据  | 数据  | 数据  | 数据  | 数据  | 数据  | 数据  |

DTO的PID通常用来表示响应类型，比如0xFF表示RES（响应包），0xFE表示ERR（错误包）。

3. 避坑指南：CAN ID的分配

我曾经在一个项目里，因为CAN ID分配不当，导致标定和刷写冲突。具体来说：

• 标定用的CAN ID是0x700（发送）和0x708（接收）。
• 刷写用的CAN ID也是0x700和0x708。
• 结果标定工具和刷写工具同时发命令，ECU直接懵了。

二、CAN FD传输层特性

CAN FD（CAN with Flexible Data-Rate）是CAN的升级版。最大的变化就是：数据场从8字节扩展到了最多64字节。

你想想看，原来8字节的时候，一个CTO命令可能还要拆成两帧发。现在64字节，一个命令+参数+数据全塞进去，还绰绰有余。

我个人习惯在CAN FD项目里，把CTO和DTO都设计成64字节。这样：

• CTO：命令+参数+数据，一帧搞定。
• DTO：响应数据，一帧搞定。
• DAQ（数据采集）：原来要发8帧的数据，现在1帧就发完了。

但要注意：CAN FD的波特率可以更高。数据段可以跑到2Mbps甚至5Mbps，而仲裁段还是原来的500kbps。这就意味着：

• 仲裁段：兼容CAN 2.0，不影响总线仲裁。
• 数据段：高速传输，减少总线负载。

不过，CAN FD也有个坑：不是所有ECU都支持CAN FD。有些老平台只支持CAN 2.0，你强行用CAN FD，ECU直接不理你。所以，项目初期一定要确认好硬件支持情况。

三、以太网传输层（TCP/UDP）

以太网传输层，说白了就是XCP跑在以太网上。这玩意儿在ADAS、自动驾驶项目里用得特别多，因为数据量大，CAN根本扛不住。

XCP over Ethernet有两种模式：TCP 和 UDP。

1. TCP模式

• 面向连接：先建立连接，再传输数据。
• 可靠传输：丢包了会自动重传。
• 适合：标定、刷写等需要可靠性的场景。

我记得有一次，用UDP做标定，结果网络稍微有点抖动，数据就丢了。ECU那边收不到命令，直接超时断开连接。后来换成TCP，问题就解决了。

2. UDP模式

• 无连接：直接发，不管对方收没收到。
• 不可靠：丢包了不重传。
• 适合：DAQ数据采集，丢几帧无所谓，实时性更重要。

3. 以太网传输层的优势

• 带宽大：100Mbps、1Gbps，甚至更高。
• 延迟低：微秒级延迟，比CAN的毫秒级好太多。
• 数据量大：一个以太网帧可以带1500字节的数据，CAN只能带8字节。

但以太网也有缺点：实时性不如CAN。CAN是事件触发+优先级仲裁，以太网是CSMA/CD（载波监听多路访问/冲突检测），在高负载下可能会有抖动。

四、FlexRay传输层简介

FlexRay，说实话，现在用得越来越少了。但在一些老项目（比如宝马、奥迪的底盘控制）里还能见到。

FlexRay的特点：

• 时间触发：每个节点在固定的时间槽里发送数据，确定性极高。
• 双通道：可以冗余传输，提高可靠性。
• 高速率：最高10Mbps。

XCP over FlexRay的传输层设计，跟CAN类似，也是CTO和DTO。但因为FlexRay的数据场更大（最多254字节），所以传输效率比CAN高。

不过，FlexRay的配置非常复杂。我曾经在一个项目里，光配置FlexRay的调度表就花了两周。而且，FlexRay的工具链也不如CAN和以太网成熟。

五、总结与对比

好了，我们来快速总结一下今天的内容：

传输层类型	最大数据场	典型速率	适用场景	我的评价
CAN	8字节	500kbps	传统动力总成、车身控制	经典，但老了
CAN FD	64字节	2-5Mbps	新一代动力总成、ADAS	性价比之王
以太网（TCP）	1500字节	100Mbps-1Gbps	标定、刷写	可靠，但延迟略高
以太网（UDP）	1500字节	100Mbps-1Gbps	DAQ数据采集	快，但不可靠
FlexRay	254字节	10Mbps	底盘控制、安全系统	强大，但复杂

下一讲，我们会深入XCP的命令层，聊聊那些常用的命令——CONNECT、GET_ID、SHORT_UPLOAD等等。到时候我会分享一些实际项目中的踩坑经验，敬请期待。

公众号:蓝海资料掘金营，微信deep3321