1. CAN总线基础回顾：CAN协议帧结构、CAN总线物理层、CAN网络拓扑、CAN报文周期与ID分配
好，咱们开始第一课。说实话，很多从CAN往SOME/IP迁移的工程师，最容易犯的毛病就是——把CAN那套思维直接套到以太网上。结果呢？项目做到一半发现根本跑不通。所以，在动刀之前，我建议咱们先把CAN的老底儿翻出来，彻底捋一遍。
你想想看，CAN总线在汽车里摸爬滚打了三十多年，它的设计哲学和SOME/IP完全不同。不理解CAN的“硬实时”基因，你就理解不了为什么SOME/IP要搞那么多“软实时”的妥协。嗯，咱们开始吧。
1.1 CAN协议帧结构：报文长什么样？
CAN报文的结构，说白了就是一套“短小精悍”的通信格式。我当年刚入行时，师傅跟我说：“记住，CAN报文最长也就8个字节的数据。” 当时我不理解，为什么这么短？后来在调试一个刹车系统时，我才真正体会到——短，是为了快，为了确定性。
标准CAN帧（11位ID）的结构如下：
SOF | 11位ID | RTR | IDE | r0 | DLC | 数据段(0-8字节) | CRC | ACK | EOF每个字段的含义，我列个表，你一看就明白：
| 字段 | 长度 | 说明 |
|---|---|---|
| SOF | 1 bit | 帧起始，同步信号 |
| ID | 11 bits (标准) / 29 bits (扩展) | 报文标识符，决定优先级 |
| RTR | 1 bit | 远程帧标志，0=数据帧，1=远程帧 |
| DLC | 4 bits | 数据长度，0~8 |
| 数据段 | 0~64 bits | 实际载荷，最多8字节 |
| CRC | 15 bits | 循环冗余校验 |
| ACK | 2 bits | 应答槽，接收节点确认 |
| EOF | 7 bits | 帧结束 |
核心要点：CAN的ID不仅仅是地址，它直接决定了总线的仲裁优先级。ID越小，优先级越高。这一点和以太网的MAC地址完全不同——以太网没有“优先级”这个概念。
我在项目中遇到过一件事：一个同事把两个ECU的CAN ID设反了，结果高优先级的报文总是被低优先级的堵住。查了两天才发现，原来是ID分配时没按“紧急程度”来排。嗯，这里要注意：ID分配不是随便写的，它背后是整车优先级策略。
1.2 CAN总线物理层：差分信号与电平
CAN的物理层，用的是差分信号。说白了就是两根线——CAN_H和CAN_L，通过电压差来传递0和1。为什么用差分？抗干扰啊。你想想看，车里的电磁环境多恶劣，发动机点火、电机启停，到处都是噪声。差分信号能把这些共模噪声抵消掉。
CAN总线的电平定义：
- 显性电平（Dominant）：CAN_H ≈ 3.5V，CAN_L ≈ 1.5V，压差约2V，代表逻辑0
- 隐性电平（Recessive）：CAN_H ≈ 2.5V，CAN_L ≈ 2.5V，压差约0V，代表逻辑1
这里有个关键点：显性电平会“覆盖”隐性电平。也就是说，只要有一个节点发送显性电平，总线就是显性的。这就是CAN仲裁的物理基础——谁先拉低总线，谁就赢。
个人经验：我曾经在测试一个混合动力车型时，发现CAN总线偶尔出现通信中断。排查到最后，发现是CAN_H和CAN_L的线束绞距不够。CAN对线束的绞距有严格要求，一般是每米30-40绞。别小看这个，绞距不对，共模抑制能力就下降，高速通信时容易丢帧。
CAN总线的终端电阻也很关键。标准要求两端各接一个120Ω电阻，并联后等效60Ω。为什么是120Ω？因为CAN线缆的特性阻抗大约是120Ω，匹配电阻能减少信号反射。我见过有人图省事只接了一个终端电阻，结果总线在长距离传输时波形严重畸变。嗯，别省这个。
1.3 CAN网络拓扑：总线型结构
CAN的网络拓扑，典型的就是总线型。所有节点都挂在一根总线上，像一串葡萄。这种拓扑的好处是简单、成本低、可靠性高。坏处呢？单点故障可能影响整个网络——如果某个节点的CAN收发器短路了，整条总线都可能被拉死。
常见的CAN网络拓扑：
- 直线型总线：最标准的形式，节点通过短支线接入主干
- 星型：通过集线器连接，但实际应用中较少
- 混合型：主干+支线，支线长度一般不超过0.3米
避坑指南：我曾经在一个项目中，为了布线方便，把支线拉到了1.5米。结果高速CAN（500kbps）通信时，支线末端的节点频繁出错。后来查资料才知道，支线长度超过0.3米就会产生明显的信号反射。所以，支线越短越好，最好直接焊在主线上。
CAN总线的最大节点数，理论上可以到110个左右，但实际中我建议不要超过30个。为什么？因为节点越多，总线负载越重，信号质量也会下降。而且每个节点的CAN收发器都有输入阻抗，节点多了，等效阻抗会降低，影响信号幅度。
1.4 CAN报文周期与ID分配：时间触发与优先级
CAN的报文发送，有两种模式：周期发送和事件触发。周期发送最常见，比如发动机转速报文每10ms发一次，车速报文每100ms发一次。事件触发呢，比如故障码，只在故障发生时发送。
报文周期的设计，其实是个平衡艺术。周期太短，总线负载高；周期太长，实时性不够。我一般遵循一个原则：
- 安全相关（刹车、转向）：1-10ms
- 动力相关（发动机、变速箱）：10-50ms
- 车身相关（车窗、灯光）：50-200ms
- 信息娱乐（导航、音乐）：200-1000ms
ID分配呢，更是门学问。CAN的ID决定了优先级，所以ID分配必须和报文的紧急程度挂钩。我见过一个典型的ID分配方案：
| ID范围 | 优先级 | 典型应用 |
|---|---|---|
| 0x000 - 0x0FF | 最高 | 安全系统（刹车、气囊） |
| 0x100 - 0x2FF | 高 | 动力系统（发动机、变速箱） |
| 0x300 - 0x4FF | 中 | 底盘系统（转向、悬架） |
| 0x500 - 0x6FF | 低 | 车身系统（灯光、车窗） |
| 0x700 - 0x7FF | 最低 | 诊断、配置 |
关键提醒：ID分配时，一定要预留扩展空间。我见过一个项目，ID分配得太满，后来要加一个新功能，发现没有合适的ID可用。最后只能重新分配ID，导致所有ECU都要更新软件。那叫一个痛苦。
另外，CAN的ID还有一个隐藏属性——它决定了报文在总线上的“等待时间”。你想想看，如果两个节点同时发送，ID小的会赢得仲裁，ID大的只能等下次。所以，如果某个报文的ID分配得太小，它可能会频繁打断其他报文，导致其他报文延迟。这就是所谓的“优先级反转”问题。
好了，CAN的基础就回顾到这里。这些内容看似简单，但它们是理解SOME/IP的基石。下一章，我们会聊聊CAN的局限性——为什么我们需要迁移到SOME/IP？嗯，到时候你就明白了。