TN-18 · 2026-09-12 · XiL 领域系列 · 第 4 篇

总线的说与听：RX/TX、残余总线仿真与 XCP

总线通信里有三个基础问题，恰恰都容易被想当然：这一帧算“收”还是算“发”？被测件的那些“同事”不在场怎么办？它脑子里在想什么，能不能看见？这篇把三件事一次讲清：RX/TX 的方向纪律、残余总线仿真、XCP。

一、RX/TX：先问“从谁的视角看”

基本定义一句话：

• TX = Transmit，发送：数据从设备流出去；
• RX = Receive，接收：数据从外面流进设备。

名字来源很直接——MCU 的 UART/CAN 控制器引脚就叫 TXD/RXD，收发器芯片上印的也是这两个词。

坑在于：方向永远是“相对于谁”说的。打电话时，你的嘴（TX）对着对方的耳朵（RX）——同一句话，你这边叫“发”，他那边叫“收”。总线上一模一样：

测试平台                          SUT（域控制器）
─────────                         ───────────────
平台 TX ──────── 一帧雷达数据 ────────▶ SUT RX
平台 RX ◀──────── 一帧制动请求 ──────── SUT TX

平台发出雷达目标帧：从平台看是 TX，从 SUT 看是 RX。同一帧，两个名字，都对。 所以谈方向之前，必须先问一句：“从谁的视角看？”

二、参照物统一选 SUT

行业惯例（HiL 台架文档也这么标）是用 SUT 视角统一命名方向：

为什么 TX 方向的注入有价值？因为真实世界里 SUT 自己也可能坏（RAM 位翻转、软件 bug），它发出的错误帧会流到制动、转向这些执行器。ISO 26262 要求通信链路有 E2E 保护，而验证“保护真的有效”的办法，就是在 TX 方向故意把帧改坏，看下游抓不抓得住。

三、视角混用是日志里最常见的坑

把方向标在数据路径上看：

RX 方向（喂给 SUT）：
  回放/故障规则 → 故障注入管道 → 总线适配层 → SUT
                  ↑ 在这里丢帧、改值，SUT 收到的就是异常输入

TX 方向（SUT 发出）：
  SUT → 总线适配层 → 故障注入管道 → 总线日志/下游节点
                      ↑ 在这里篡改，下游看到的就是“发疯的 SUT”

注意平台视角恰好反过来：适配层的 sendToSut() 是平台的 TX、SUT 的 RX；receiveFromSut() 是平台的 RX、SUT 的 TX。这就是为什么命名要坚持用 SUT 视角统一——混用视角是日志分析和代码评审里最常见的 bug 源头之一。

三条工程纪律：

1. 把视角写进名字：别叫裸的 rxPipe/txPipe，叫 sutRxPipe/sutTxPipe，或更直白的 intoSutPipe/fromSutPipe——三个月后回看不会懵；
2. 日志里每帧标注方向：帧记录里加一个 direction 字段（SUT_RX/SUT_TX），离线分析不用靠猜；
3. 注入规则里显式声明方向：direction: rx 还是 tx，别让注入点靠隐式推断——同一条 drop 规则，打在 RX 是“SUT 瞎了”，打在 TX 是“SUT 哑了”，测的是完全不同的安全机制。

一句话：RX 和 TX 描述的是数据穿过边界的方向，参照物通常选 SUT——RX 是“喂进去”（测 SUT 的抗打击能力），TX 是“发出来”（测别人防不防得住 SUT 发疯）。

四、残余总线仿真：补全环境的半边

方向厘清了，下一个问题是：被测件的“同事”不在场怎么办？

一个 ECU 上车后，总线上有十几个“同事”按各自周期给它发消息：ESP 发车速、BCM 发车灯状态、网关转发别的网段的信号……它天生假设这些消息都在。

HIL 台架上只有这一个真实 ECU，其它都不在场。残余总线仿真就是：由台架扮演所有缺席的 ECU，把它们该发的帧一帧不差地发出去——周期对、信号值合理、rolling counter 和 checksum 按算法滚动。

“残余”的含义：整辆车 = 完整的总线，被测件拿掉后，剩下的那部分总线由仿真补齐。

五、没有它，连锁反应立刻发生

被测 ECU 不是孤儿，行为依赖总线输入。没有残余总线仿真：

1. 通信丢失故障：收不到期望的周期帧（超时几百 ms 到几秒），ECU 判“某某 ECU 挂了”，记录 DTC 故障码、点亮故障灯；
2. 功能降级：很多 ECU 检测到通信丢失会进 limp-home 降级模式——你测的不再是正常功能，而是故障应对；
3. 用例全废：想测“AEB 在 50kph 下触发”，但 ESP 的车速帧没人发，被测件以为车静止——激励根本进不去。

一句话：HIL 测的是“ECU 在正常整车环境里的行为”，残余总线仿真就是这个环境的总线半边（另半边是电气 I/O，由板卡负责）。它是台架搭建的工作量大头。

六、配置里真正费劲的三个点

• rolling counter / checksum：现代报文带防重放的滚动计数器和 CRC（AUTOSAR E2E 保护），仿真必须按正确算法逐帧更新；发固定值会被判“数据不可信”；
• 信号值要“合理”：档位、转速、车速之间有物理一致性，胡乱搭配会触发被测件的合理性检查；
• 多网段：FD 段、经典段、以太网段，网关路由关系也要仿对。

七、XCP：从“听总线”到“看内存”

残余总线仿真解决了“环境的半边”，还剩一个问题：被测件脑子里在想什么，能不能看见？ 普通总线监听做不到，XCP 能。两者是两种完全不同的姿态：

八、三个监听永远做不到的能力

1. 看内部中间量：总线上只有输入帧和输出帧，中间是黑盒。积分项饱和了没、状态机卡在哪步、TTC 算出来是多少——只有 XCP 能直接读；
2. DAQ 高速同步采集：让 ECU 在自己的任务周期里主动把指定变量按事件推出来，与控制周期严格同步、带时间戳——100 µs 控制环的每个点都能采到；
3. 在线标定：改阈值不用重新编译烧写——XCP 直接写 ECU 的 RAM（参数页切换），改完下一拍生效。这是 CANape/INCA 的立身之本。

进阶还有 bypass：把 ECU 里某段算法整个旁路，由外部模型算出结果注回去——快速原型（RCP）的玩法。

九、观测纵深是有代价的

• 判定的观测深度不同：监听只能判“输出对不对”，XCP 能判“内部过程对不对”——功能安全审核要的证据经常是后者；
• 代价：XCP 要 ECU 配合（集成驱动、占资源），生产件可能关掉；监听永远可用。

回看这三个概念，它们回答的是同一条链上的三问：RX/TX 定方向——谈“说与听”之前先锁定参照物；残余总线仿真补环境——让被测件以为自己在真车上；XCP 开纵深——让测试看见被测件的脑子里在想什么。 参照物错了，日志全拧；环境缺半边，激励进不去；观测没纵深，判定只能停在“输出对不对”。三件事凑齐，总线这一层才算真正受控。

附：名词解释（按出场顺序）