第二讲：通信架构基础

车载网络拓扑结构

做域控制器这些年，我见过最头疼的事，就是不同ECU之间“鸡同鸭讲”。

车载网络拓扑，说白了就是车上这些电子单元怎么连、怎么聊。早期车很简单，一个CAN总线把所有节点挂上去就完事。但现在不行了——传感器多了，数据量大了，实时性要求也高了。

目前主流的拓扑结构，我归纳为三种：

• 集中式拓扑：所有传感器数据都往一个中央域控送。好处是处理集中，坏处是线束重、单点故障风险大。我在2019年做过一个项目，客户非要这么搞，结果散热和布线成本直接翻倍。
• 分布式拓扑：每个功能域（智驾、座舱、车身）各自为政，通过网关交换数据。这是目前最成熟的方案，但跨域通信延迟是个坑。
• 混合式拓扑：现在的主流。比如智驾域内部用高速以太网，和车身域之间用CAN FD桥接。我个人习惯用这种，灵活且好调试。

OSI七层模型在车载中的应用

很多工程师觉得OSI模型是课本上的东西，实际用不上。嗯，我以前也这么想，直到被一个物理层问题坑了三天。

OSI七层在车载里，其实每一层都有对应：

OSI层	车载对应	我踩过的坑
物理层	100BASE-T1 / CAN 收发器	线束阻抗不匹配，信号反射导致丢包
数据链路层	MAC、VLAN、CAN ID 过滤	曾经忘记配VLAN，两个域控互相广播风暴
网络层	IPv6 / SOME/IP 路由	多网段路由表配错，摄像头数据死活过不去
传输层	UDP（传感器流）、TCP（诊断）	激光雷达用TCP，延迟直接飙到50ms
会话层	DoIP 会话管理	诊断会话超时，刷写一半断连
表示层	数据序列化（比如Protobuf）	字节序搞反，解析出来的坐标全是负数
应用层	ADAS 算法、HMI 显示	应用层不校验，收到脏数据直接误刹车

为什么会这样？因为车载通信对实时性和确定性要求极高。你想想看，物理层一个抖动，到了应用层可能就是一次误触发。

车载通信的关键指标

做域控通信架构，说白了就是跟几个数字较劲。我列一下最关键的：

• 延迟（Latency）：从传感器采集到域控处理完成的时间。L3级要求端到端<100ms，L4要求<50ms。我曾经测过一个方案，CAN总线转发就占了30ms，直接不合格。
• 带宽（Bandwidth）：摄像头数据流，一个800万像素的摄像头，30fps，H.265压缩后也要50Mbps。4个摄像头就是200Mbps。CAN FD那点带宽根本扛不住。
• 可靠性（Reliability）：丢包率、误码率。以太网要求<10^-9，CAN要求<10^-6。但实际项目中，线束老化后误码率会飙升。
• 确定性（Determinism）：这是最容易被忽略的。通信延迟不能忽高忽低。我见过一个方案，平均延迟5ms，但最大延迟200ms——这种车谁敢开？

嗯，这里要注意：指标之间是互相制约的。带宽高了，延迟不一定低；可靠性高了，成本一定高。做架构设计，就是在这几个指标之间找平衡。

我个人习惯，先定延迟预算，再算带宽需求，最后看可靠性能不能满足。如果不行，就调整拓扑或者换通信介质。比如，把CAN FD换成车载以太网，或者把集中式改成分布式。

好了，这一讲就到这里。下一讲我们聊聊具体的通信协议——SOME/IP和DDS，这两个是目前域控里最常用的。