3.1 通信栈

3.1 通信栈

本节摘要：Classic 通信栈不是 CAN 驱动的别名，而是一层层语义转换：应用端口上的工程值，经通信模块变成信号，打进协议数据单元，由路由决定走哪条总线，再经接口和驱动变成物理帧。读完应能把一次发送拆到层，并说明传统总线与车载以太网在治理上为何不能互相冒充。

本节导读

阅读完本节，你应当能够：

1. 画出从 Rte_Write 到引脚的下行路径。
2. 说明信号、PDU、帧三者不是同一个东西。
3. 区分 CAN/LIN 的周期确定性与以太网的带宽角色。
4. 在“没发出去”时按层提问，而不是直接换驱动。

一、从搬运工到翻译官

自适应巡航要前车距离。距离可能来自雷达控制器，经网关，再进控制算法所在的 ECU。若每个应用都为对方写私有解析，代码和验证会一起炸。通信栈在应用侧提供统一的读端口；在中间把读取映射为逻辑 PDU；在下面选择 CAN 传输协议、直接帧，或以太网诊断封装。三次跃迁同时发生：语义从“我要距离”变成 PDU 标识；拓扑从逻辑关系到物理路径；时间从功能周期变成报文周期和中断响应。

它不承诺绝对最低延迟，但承诺在已知负载和配置下延迟可建模。网络管理和诊断通信管理让异常可被定位。这叫确定性语义管道，不是“越快越好的网线”。

图：PDU 在通信栈中的路径

二、异构总线的统一抽象与差异治理

栈必须同时面对 CAN、LIN、FlexRay 遗产和车载以太网。统一的是 PDU 这一逻辑搬运单位，以及接口层把“发一个 PDU”翻译成具体控制器操作。不统一的是时间哲学。CAN/LIN 以周期和网络管理为生命线：节点何时睡眠、何时被唤醒、报文是否按表发送，直接决定功能是否还活着。以太网带来带宽和基于 IP 的服务，但也带来缓冲、桥接和更复杂的唤醒。把以太网当“更快的 CAN”用，会既失去确定性，又用不好带宽。

传输协议负责长数据分段重组，诊断刷写尤其依赖它。应用仍然不该自己实现分段。网关是路由的物理体现：描述里写明哪些 PDU 可以过桥，哪些必须被挡住。安全相关信号过网关时，还要考虑是否需要安全车载通信那一层认证，那是第 6 章的叠加，不是通信栈的日常默认。

网络管理常被当成附属。实际上它决定“这根总线还在不在集体生命里”。应用在总线睡眠时仍写端口，数据只会堆在本地，直到唤醒策略允许发送。现场“偶发丢值”有时不是丢帧，是没醒。

三、配置纪律决定性能

同一车门锁状态若为每个接收者各配一套发送 PDU，内存和总线负载会成倍涨。更干净的做法是语义聚合：一个信号进入一个组，一次打包，一次发送，多个组件读同一映射。第 7.3 节引用的资源基准说明：抽象本身有成本，但未约束的配置自由度往往更贵。通信栈是重灾区。

发送模式也要显式：周期、事件、混合。控制类信号常用周期加变化触发；配置类可以用事件。模式选错，总线要么吵死，要么功能侧饿死。无效值和超时必须在信号配置里出现，否则应用读到的“最后一个数”可能是事故前的数。

⚠️ 常见坑：在应用里指定帧标识符和周期。那是接口层和 COM 的事。应用一写死，换矩阵就要改功能代码。
💡 关键直觉：先问“这一跳在哪一层”，再决定用总线分析仪还是用配置工具。

四、和 Adaptive 通信的边界

Classic 通信是面向信号、静态绑定。Adaptive 通信是面向服务、可发现。混合车上两者会在网关相遇：一边是周期信号，一边是方法调用。翻译必须带单位、时效、安全等级，不能只拷贝四个字节。那是第 7.1 节的主题。本节先把 Classic 这一侧的层走稳，否则网关两侧都说不清自己交出的是什么。

五、网络管理、信号组与安全叠加

网络管理决定节点何时睡眠、何时被唤醒。应用在总线睡眠时仍写端口，数据只会停在本地缓冲，直到唤醒策略允许发送。现场“偶发丢值”有时不是丢帧，是没醒。唤醒谁来触发、超时多久再睡，属于通信栈与模式管理的联合配置，应用不该自己点亮收发器引脚来“保证发出去”。那会击穿 ECU 抽象，也会让网络管理的集体生命失效：一颗控制器不肯睡，整根总线的功耗预算就破了。

信号组把多个信号打进同一 PDU，是资源优化的正路，也是一致性的来源：同一帧里的几个信号共享同一时间戳。控制律若需要“同时采到的一组”，应优先用组，而不是在应用里用三次读碰运气。组的发送模式仍要显式：周期、事件、混合。门锁状态用事件加周期保活，往往比纯周期更省；轮速常用周期，因为控制侧不能等变化才来。

安全车载通信会在信号或 PDU 上叠加认证码和新鲜性。它不改变本节的层路径，只在路径上增加检查。检查失败应进入诊断事件，而不是把错误值当零。应用仍然只看见端口。若应用开始解析认证字段，坐标系再次失真。第 6.2 节会把密钥和纵深展开；本节只要记住：认证是通信栈上的叠加层，不是应用的私活。

问题：分析仪上看不到帧，第一步不该换驱动的理由是什么？

因为帧是路径的最后一跳。前面还有端口有没有写、信号有没有进 PDU、路由有没有选这条总线、网络管理有没有允许发送、抽象层有没有使能收发器。从最后一跳往前拆，会把配置错误当成芯片问题，于是开始换 MCAL 版本。版本一换，对照实验消失，问题变成传说。正确顺序是从应用到线，或至少从 PDU 计数开始。计数在通信模块里增加却线上没有，才轮到接口和驱动。计数不增加，问题还在 RTE 或 COM 配置。

问题：为什么以太网不能当更快的 CAN 用？

CAN 的治理是周期和网络管理，以太网的治理是带宽、桥接、缓冲和基于 IP 的服务。把周期信号原样搬到以太网而不重新设计时效和唤醒，会既失去格子里的确定性，又用不好带宽。需要带宽的是摄像头和部分服务；需要格子的是闭环执行量。两者可以在网关相遇，但相遇时要翻译，不能假装介质可互换。介质可互换是分层的理想，治理不可互换是工程的现实。

信号、PDU、帧三者的混淆，是通信栈排错里最贵的词汇错误。信号是应用语义上的数据元素，带单位和无效值。PDU 是可被路由的打包单位，路由表认的是它。帧是某条总线上的物理传输单位，分析仪认的是它。把三者叫成同一个“报文”，会议会很长，因为每个人指着不同的层还以为在争论同一件事。建立共同语言的办法是强迫发言者先报层：你说的是端口、是 PDU，还是线上的标识符。报得出层，分析仪和配置器才能轮流上场。报不出层，只能换驱动版本。换版本是沟通失败的硬件化。硬件化解决不了词汇问题，只会让对照实验消失，于是问题成为传说，传说会进入下一款车的风险清单，清单很长，项却都不在坐标上。

把网络管理从附属位置拉回主线。节点集体睡眠是功耗设计，也是功能可用性设计。一颗控制器为了“保证发出去”私点收发器，整根总线的睡眠协议就被击穿，功耗预算和唤醒风暴会一起到来。风暴在分析仪上像突发流量，在架构上像越层。越层的诱惑叫实时，实时的正确做法是配置唤醒源和超时，而不是应用去拧引脚。引脚属于抽象层。应用拧引脚的项目，换板时会把通信栈一起拧断。拧断之后人们会说标准太重。重的其实是私货。把私货搬回去，周期报文会按表发送，事件报文会按组打包，安全认证会叠加在 PDU 上而不是叠加在应用分支里。叠加位置正确，第 6 章才有地方挂机制。挂不上去的机制只能停留在规范书，规范书开不了车。
把信号组当成一致性工具而不仅是省带宽工具。同一帧里的几个信号共享时间，控制律若需要同时采到的一组，应优先用组。三次分开读再在应用里对齐，对齐窗口会被调度抖动撕开，撕开后看起来像传感器噪声。噪声其实是配置没表达“同时”。表达同时是通信栈的职责之一，职责被应用抢走后，滤波会越做越肥，肥滤波会吃掉你本想靠删 RTE 省下的那点 CPU。所以省资源的正路是让栈做它该做的打包，而不是让应用做它不该做的对时。对时在格子里由调度表完成，在总线上由帧完成。两处都不该由业务 if 完成。

PDU 路由表是拓扑跃迁的法律文本。表在编译期生成，运行时按标识转发，不按应用临时指定的目的地转发。应用若开始填写目的控制器名，通信栈就从市政服务退化成快递柜密码本。密码本无法做最坏负载分析，因为目的地集合不再封闭。封闭集合是 Classic 能算总线负载的前提。负载算不清，周期报文会在峰值时互相挤压，挤压看起来像偶发丢失。丢失会诱使人们缩短周期，缩短又让峰值更尖。循环的出口是回到路由表：谁允许跟谁说话，写在表里，不写在应用分支里。

一节小结

• 三次跃迁：语义、拓扑、时间，通信栈同时做这三件事。
• 信号、PDU、帧分层：混淆三者就会找错工具。
• 路由编译期绑定：不是运行时随便改道。
• 总线治理有差异：周期生命线 vs 带宽与 IP。
• 配置聚合能省资源：不要为每个读者复制一套发送。
• 应用只看见端口：帧 ID 不属于应用主权。

下一节诊断栈会骑在通信之上：统一诊断服务请求如何变成故障码、抑制和售后可读的状态。