3.4 传输层对决——CAN与DoIP的共存

两个通道，一台诊断仪

你站在2026年某高端新能源品牌的售后车间里，手中握着最新的诊断仪。这个诊断仪背面有两个数据接口——一个标准的DB9 CAN接口，一个RJ45以太网接口。中间的OBD-II连接器统一了物理形态——但内部并行了CAN_H/CAN_L双绞线和100BASE-T1以太网单对双绞线。

你面对一台全新架构的中央计算平台ECU——它同时支持CAN诊断和DoIP以太网诊断。你该插哪个口？

答案不是“随便哪个都一样“。答案取决于你想做什么。让你来串联两个世界的不是偏好——是用例。

为什么两套传输层必须共存——从OBD-II到Zonal架构

要理解CAN和DoIP的共存逻辑，你首先得理解一个残酷的现实：CAN的物理带宽天花板。

ISO 15765-2定义在经典CAN 2.0B上（1Mbps理论速率）。一根1Mbps的CAN总线上承载着几十个ECU的周期性报文、事件报文、诊断报文——留给诊断的净有效带宽通常不到200kbps。按这个速度，传输4MB固件升级镜像需要多久？

4MB = 4 × 1024 × 1024 = 4,194,304 B
CAN 单帧payload: 7B
需要帧数: 4,194,304 / 7 ≈ 599,186 帧
单帧周期(含CAN ID+CRC+应答): ~130μs at 500kbps
总传输时间: 599,186 × 130μs ≈ 77.9秒
加上STmin=1ms间隔: 77.9 + 599 × 1ms ≈ 679秒 ≈ 11分钟

> 以上为经典CAN（2.0B）计算。如果使用CAN FD（payload 64字节，速率最高8Mbps），同样4MB固件可缩短至约1~2分钟——虽仍不及以太网，但已从"喝杯咖啡"改善到"稍等片刻"。

11分钟传一个固件。在没有以太网的年代，维修技师插上诊断仪，开始刷写，去喝杯咖啡回来——还在传。这是OBD-II时代（乃至早期UDS on CAN时代）的真实工作流。

而同一块固件在100Mbps以太网上：

4,194,304 B / (100Mbps/8) ≈ 335ms 裸文件传输
加上TCP握手、DoIP路由激活、正响应确认: <5秒

从11分钟到5秒——这不是“快了“，这是一个量级的跃迁。当数据量超过某个临界值（约10KB），CAN的传输时间开始变得不可接受。 这是CAN不能替代以太网的第一原因——物理带宽。

但反过来——能不能只用以太网、扔掉CAN？

不能。三个原因：

1. 部分ECU没有以太网PHY。 ABS/ESP、气囊、胎压监测——这些底层ECU用CAN已经几十年了——加一颗100BASE-T1 PHY意味着加0.8美元的BOM成本——乘以一年百万台车的规模——这是不容忽视的成本。而它们在CAN上工作得很好。

2. 以太网的实时性不如CAN。 CAN的仲裁机制提供了天然的实时优先级——一个高优先级的CAN帧在正在发送的低优先级帧结束后立即获得的仲裁——最坏情况延迟是1个最坏帧的时间（~130μs）。而以太网的TCP重传、交换机缓冲——延迟是不可预测的。对安全气囊展开和ABS制动的诊断——CAN的确定性延迟比分发TCP数据包的毫秒级抖动更可靠。

3. 以太网交换机的物理可靠性不如CAN收发器。 在高温、振动、电磁干扰的车载环境下，CAN的差分双绞线+错误检测具有29年的验证历史。100BASE-T1虽然设计指标优秀——但现场实际验证时间还不够长。

结论：CAN和以太网在车载诊断场景里不是替代关系——是互补关系。 CAN负责“频繁、实时、小数据量“的诊断交互——以太网负责“偶尔、批量、大数据量“的诊断传输。

数字对决——全程定量对比

核心洞察：CAN诊断是“打电话“——拨号即通、实时对话、但带宽有限。DoIP诊断是“发电子邮件“——需要建立连接、延迟稍高、但可以传输任意大小的附件。两套体系共享同一个UDS应用层（DCM），这意味着你的0x22读DID的业务逻辑代码同一套——变动的只是传输通道。这正是AUTOSAR架构PduR（PDU Router）的职责——将UDS PDU从通道中抽象出来。

双通道并存的实现挑战——PduR的仲裁艺术

如果一个ECU同时打开CAN诊断和DoIP诊断两个通道，架构上会发生什么？

                    ┌──────────UDS Application──────────┐
                    │         DCM (Diagnostic            │
                    │     Communication Manager)         │
                    │           │                        │
                    │      PduR (PDU Router)             │
                    │         /          \               │
                    │   PduRCanTp     PduRDoIP           │
                    │       │              │              │
                    └───────┼──────────────┼──────────────┘
                            │              │
                    ┌───────┼──────────────┼──────────────┐
                    │ CanTp │         DoIP │              │
                    │ (ISO  │     (ISO     │              │
                    │15765-2│     13400)   │   Transport  │
                    │   │   │         │    │   Layer      │
                    │ CAN  │    TCP/IP    │              │
                    │  IF  │    Stack     │              │
                    └──┬───┴──────┬──────┴──────────────┘
                       │          │
                ┌──────┴───┐ ┌───┴──────┐
                │ CAN Bus  │ │Ethernet  │
                │          │ │  Switch  │
                └──────────┘ └──────────┘

挑战1：会话竞争——两个诊断仪、一个ECU

最激烈的冲突场景：两个不同的诊断仪——一个通过CAN、另一个通过以太网——同时向同一个ECU发起物理寻址诊断请求。

时间线:
T=0    CAN诊断仪 → ECU:  0x10 0x03 (切换到扩展会话)
T=1ms  ECU → CAN诊断仪:   0x50 0x03 (OK——CAN诊断仪获得了会话控制权)

T=20ms 以太网诊断仪 → ECU: 0x10 0x03 (也切换到扩展会话)
T=21ms ECU内部：冲突检测——当前已有一个物理会话在CAN通道上活跃
         →
         根据ISO 14229-2的会话抢占规则：
         - 后来的physical addressing请求可以抢占前一个
         - 前一个被抢占方收到Session Timeout Notification
         → ECU → 以太网诊断仪: 0x50 0x03 (OK——抢占成功)
         → ECU → CAN诊断仪:   S3Server Timer重置为默认会话倒计时

会话抢占是ECU DCM的一个关键设计——同一时刻只允许一个物理寻址方控制诊断会话。 后来的抢占先前的——这是ISO 14229-2明确规定的规则。如果你不实现抢占——两个诊断仪同时向ECU发包——结果完全不可预测。

挑战2：资源竞争——共用的内存池和计算资源

CAN处理链路和DoIP处理链路共享同一个ECU的诊断处理的资源池：

资源冲突的典型场景:
  1. 诊断缓冲区(DiagBuffer)只有一个——不能同时被两路请求使用
  2. NvM的读写队列是串行的——CAN通道在执行NvM读时，DoIP不能同时读
  3. P2/P2*定时器是全局的——CAN请求触发了P2，DoIP也需要等待
  4. 安全访问状态(seed/key)是全局的——一条通道解锁≠另一条自动解锁

解决方案： PduR（或更上层的DCM）实现了请求队列（Request Queue）——将来自不同通道的UDS请求按到达时间顺序排列、逐一处理。如果一条通道的请求正在处理中——另一条通道的新请求在队列中等待，如果等待时间超过P2——发送NRC 0x78(RCRRP)给发送方以示“正在处理中“。

挑战3：时序同步——全局定时器的误导

问题:
  CAN发送方使用了P2=50ms的默认时间窗口
  DoIP发送方等待TCP ACK和响应也需要确认P2

  如果ECU对所有通道共享同一个P2定时器：
    - CAN侧的请求用了40ms处理——DoIP侧只有10ms剩余时间
    - DoIP侧请求的数据量更大——10ms根本不够
    - 结果: DoIP请求超时——即使ECU还在正常工作

最佳实践： 大多数实现为每个通道维护独立的P2/P2*定时器实例——而不是全局单例。CAN侧的超时窗口和DoIP侧的超时窗口各自独立运行——互不干扰。

实战策略——什么场景选什么通道

快速诊断查询——走CAN：

诊断仪要做的事: 读取发动机ECU的3个当前DTC
数据量: 请求7B + 响应约50B
最佳通道: CAN

理由:
  1. 50B在CAN上通过SF或少量CF即可完成——不需要TCP握手开销
  2. TCP握手=3次往返(~5ms)比CAN的直接SF(0.13ms)慢40倍
  3. 不需要维护TCP连接状态——简单、确定性高

场景文本:
  你开着诊断仪在车间快检——插上OBD、读取DTC、3秒出结果。
  用CAN，诊断仪和ECU之间的交互就像面对面问诊。

固件升级——走DoIP：

诊断仪要做的事: 刷写中央计算平台ECU的新版固件
数据量: 单个固件镜像 ~120MB
最佳通道: DoIP (Ethernet)

理由:
  1. 120MB在500kbps CAN上需要约55分钟
  2. 120MB在100Mbps以太网上需要约11秒 (纯数据)
  3. DoIP的段式传输(TransferData)天然适合TCP流的大块输送
  4. 升级过程中的完整性校验(CRC32)在带宽充足的通道上几乎不影响整体时间

场景文本:
  车间技师在诊断仪屏幕上点下"开始升级"——
  DoIP通道在30秒内完成了固件传输+校验+ECU复位。
  如果用CAN，技师得等一个小时——意味着这台车的升级服务费要涨
  好几个工时。

实时参数监控——走CAN：

诊断仪要做的事: 在路试中实时画出发动机转速、车速、增压压力、爆震计数——每秒刷新10次
数据量: 每个周期约20B，每秒10次 = 200B/s
最佳通道: CAN

理由:
  1. 200B/s远低于CAN有效带宽——完全不是瓶颈
  2. CAN的确定性延迟确保每个刷新周期的数据在固定时间窗口内到达
  3. TCP的Nagle算法和延迟ACK可能引入不可预测的抖动——
     在速度-时间图上表现为"画面一卡一卡
  4. 以太网在车辆行驶中的物理连接可靠性不如CAN

场景文本:
  你坐在副驾，诊断仪屏幕上六条彩色曲线跟随引擎的咆哮实时跳动。
  每一帧数据都在固定的10ms窗口内刷新——CAN的确定性让你看到的
  不是回放，是实时。

远程OTA升级——只能走DoIP：

诊断仪(云服务器)要做的事: 通过互联网远程推送安全补丁
数据量: 差异包 ~5MB
最佳通道: DoIP (Ethernet → OTA Gateway → 车内以太网)

理由:
  1. CAN不经过IP网络——物理隔绝了远程访问
  2. DoIP基于TCP/IP——网关可以将请求路由到TBox然后进车内以太网
  3. 安全性——DoIP支持TLS加密——这是CAN完全没有的能力

场景文本:
  凌晨2点，云端服务器向全球车队推送了一个安全补丁。
  车辆停在地下车库，通过TBox的4G/5G连接接收更新——
  补丁通过DoIP→车内以太网→目标ECU→自验证→自安装。
  第二天早上车主启动车辆——更新已经完成且静默生效。

未来展望——CAN XL与10BASE-T1S

双通道共存的格局在可见的未来不会改变——但两个通道自身都在进化：

CAN侧：

• CAN FD（Flexible Data-rate）：payload从8字节扩展到64字节——大幅减少了多帧传输的CF帧数量。一个260字节的响应只需要4个CAN FD帧——而不是37个经典CAN帧。
• CAN XL：payload扩展到2048字节，速率提升到10Mbps+ —— 对于中等规模的诊断操作（如小型固件升级包），CAN XL可以吃掉过去只能走以太网的使用场景。

以太网侧：

• 10BASE-T1S：10Mbps单对双绞线以太网——物理层成本逼近CAN收发器——专为成本敏感的底层ECU设计。如果1美分的10BASE-T1S PHY可以装进ABS ECU——那ABS也可以享受DoIP的带宽。
• TSN（Time-Sensitive Networking）：为以太网增加了确定性延迟保证——填补了CAN在实时性上的独特优势。如果TSN成熟——以太网将同时拥有带宽和实时性。

但本质格局不变：低延迟+确定性→CAN（及其进化版），高带宽+IP路由→以太网。两者不是替代——是UDS诊断体系的南北两极。

本篇小结

1. CAN和以太网在车载诊断中不是替代关系而是互补关系——CAN提供实时、轻量、低成本的诊断交互通道，以太网提供高带宽、可远程、大数据量的诊断传输管道。两者共享同一套UDS应用层（DCM），通过PduR实现通道抽象。
2. 定量对比：CAN的有效诊断带宽约200kbps、最坏延迟可精确计算(~130μs)、硬件成本约$0.15；DoIP的有效带宽约95Mbps、延迟有TCP抖动不可预测、硬件成本约$1.50。差距在各维度上都是数量级的。
3. 双通道并存的三大挑战：会话竞争（后来的抢占先前的——ISO 14229-2规则）、资源竞争（共用诊断缓冲区/NvM/P2定时器——需要PduR请求队列管理）、时序同步（每个通道应维护独立的P2/P2*定时器）。
4. 实战策略：快速查询(读DTC/读DID)走CAN——省去了TCP握手开销；固件升级/大数据回读走DoIP——带宽优势碾压；实时参数监控走CAN——确定性延迟无抖动；远程OTA只能走DoIP——TCP/IP是远程访问的物理基础。
5. 未来趋势：CAN FD/CAN XL将扩展CAN的payload和速率；10BASE-T1S将降低以太网的硬件成本门槛；TSN将为以太网注入确定性。但在可预见的未来，双通道共存是UDS诊断的常态架构。

【下集预告】：你已经掌握了UDS在两个主流传输层上的编码方式——ISO 15765-2在CAN上的单帧/多帧/流控机制，以及ISO 13400 DoIP基于TCP/IP的诊断传输。下一步——拆开真实生产级ECU诊断源码——进入第4章——Arctic Core源码解析——看一个AUTOSAR兼容的DCM如何把第2章的全部协议逻辑翻译成C代码。