3、通信协议基础：CAN/CAN FD总线协议、以太网协议（DoIP）、SOME/IP与服务发现
各位同学，咱们今天聊聊OTA升级的“血管”——通信协议。你想想看，ECU之间要协同升级，数据怎么传？靠什么传？这就是协议干的事。我个人习惯把通信协议比作“语言”，ECU之间得说同一种话，才能把升级包安安稳稳地送过去。
这一章咱们重点啃四个东西：CAN/CAN FD、DoIP、SOME/IP，还有服务发现。嗯，别被名字吓到，咱们一个一个拆开讲。
3.1 CAN与CAN FD：老将与新秀
CAN总线，搞过车载的都知道，这玩意儿太经典了。从90年代用到现在，几乎每个车上都有。但经典归经典，它有个硬伤——带宽太低了。传统CAN最高也就1Mbps，一个报文最多8字节数据。你想想看，一个OTA升级包动不动几十兆甚至上百兆，用CAN传？那得传到猴年马月去。
我在项目中遇到过，早期做某个T-Box的远程升级，用的就是CAN。一个固件包30MB，算下来要传将近400万帧报文。嗯，你没听错，400万帧。结果呢？升级一次要40多分钟，用户投诉电话都打爆了。
所以后来就有了CAN FD。FD就是“Flexible Data-rate”的意思。它有两个核心改进：
- 速率提升：数据段可以跑到8Mbps甚至更高
- 数据长度翻倍：从8字节扩展到64字节
别小看这64字节。同样是30MB的固件，用CAN FD传，时间能缩短到原来的十分之一左右。我建议你在做OTA架构设计时，如果ECU支持CAN FD，优先用CAN FD。实在不行再用传统CAN。
核心要点：CAN FD向后兼容CAN，但需要硬件支持。不是所有ECU都支持CAN FD，老车型尤其要注意。
这里有个避坑指南：我曾经在一个项目中，想当然地认为所有ECU都支持CAN FD，结果发现某个门控模块还是老CAN。没办法，只能做协议转换。所以，做OTA之前，先拉一张ECU通信能力清单，挨个确认。
3.2 以太网与DoIP：高速通道
说到高速，就不得不提以太网。车载以太网现在越来越普及，100BASE-T1、1000BASE-T1这些标准，带宽从100Mbps到1Gbps。这才是OTA升级该用的通道。
但以太网本身只是个物理层和数据链路层的东西，上层怎么传诊断数据？这就引出了DoIP——Diagnostics over Internet Protocol。说白了，就是把UDS诊断协议封装在TCP/IP包里，通过以太网传输。
DoIP的好处很明显：
- 速度快：百兆千兆的带宽，传固件包分分钟的事
- 支持并行：可以同时给多个ECU刷写，不像CAN那样串行
- 远程方便：基于IP，天然支持远程连接
我记得有一次做整车OTA测试，用CAN FD传一个网关的固件要15分钟，换成DoIP后，45秒搞定。你想想看，这差距有多大。
小提示：DoIP的端口号一般是13400，这是ISO 13400标准定义的。做开发时别忘了配置防火墙规则。
但DoIP也有坑。我曾经遇到过一个情况：车辆在行驶过程中，以太网链路不稳定，导致DoIP连接频繁断开。后来加了重传机制和心跳检测，才解决问题。所以，做DoIP OTA时，一定要考虑网络波动场景。
3.3 SOME/IP：服务导向的通信
好，咱们再往上走一层。SOME/IP，全称是Scalable service-Oriented MiddlewarE over IP。名字很长，但核心就一句话：它是一种面向服务的通信协议。
传统CAN通信是“信号导向”的——你发一个ID，我收一个ID，里面塞几个信号。但SOME/IP不一样，它是“服务导向”的——一个ECU提供某个服务，另一个ECU调用这个服务。比如，网关提供“读取车速”服务，其他ECU通过SOME/IP来调用。
这对OTA升级意味着什么？意味着你可以把升级相关的功能封装成服务。比如：
- 刷写服务：负责接收升级包
- 校验服务：负责验证完整性
- 回滚服务：负责失败恢复
每个服务都有独立的接口，互不干扰。我个人习惯用SOME/IP来设计OTA的通信架构，因为它灵活、可扩展。你想想看，以后要加一个新功能，只需要新增一个服务就行，不用改底层协议。
关键点：SOME/IP基于UDP或TCP传输，支持Request/Response和Fire&Forget两种模式。OTA升级一般用Request/Response，确保可靠性。
3.4 服务发现：谁在提供什么服务？
有了SOME/IP，ECU之间可以互相调用服务了。但问题来了：A ECU怎么知道B ECU提供了哪些服务？这就靠服务发现（Service Discovery）了。
服务发现，说白了就是一个“注册与查找”的机制。每个ECU启动时，会广播自己提供的服务。其他ECU收到后，就知道该找谁了。在车载领域，常用的服务发现协议是SOME/IP-SD（Service Discovery）。
它的工作流程大致是这样的：
- Offer Service：服务提供者广播“我提供XX服务”
- Find Service：服务消费者广播“谁提供XX服务？”
- Subscribe/Subscribe ACK：消费者订阅服务，提供者确认
嗯，这里要注意：服务发现不是一次性的。ECU可能随时上线或下线，所以需要定期发送心跳包。我曾经在一个项目中，因为服务发现的心跳间隔设置得太长（30秒），导致OTA升级时找不到目标ECU。后来改成3秒，问题就解决了。
警告：服务发现报文不要发得太频繁，否则会占用大量带宽。一般建议1-5秒一次，具体看网络负载。
好了，咱们总结一下这四种协议在OTA中的角色：
| 协议 | 主要用途 | 带宽 | 适用场景 |
|---|---|---|---|
| CAN | 控制指令、小数据量传输 | ~1Mbps | 老车型、低速ECU |
| CAN FD | 中等数据量传输 | ~8Mbps | 中速ECU升级 |
| DoIP | 大数据量传输、远程诊断 | 100Mbps~1Gbps | 高速ECU、整车OTA |
| SOME/IP | 服务化通信、功能调用 | 依赖底层 | 面向服务的架构 |
最后说一句：做OTA架构设计时，不要只盯着一种协议。实际项目中往往是混合使用的。比如，用DoIP传大固件包，用CAN FD传小补丁，用SOME/IP做服务协调。灵活搭配，才是王道。
下一章咱们聊聊升级包的生成与签名，这可是安全的关键环节。