结论：2025 Corolla Hybrid TSS 3.0 的横向与纵向控制都收敛到同一条报文：摄像头发出的 32 字节 CAN FD 帧 0x160，约 40 Hz。加速度是字节 4–5 的 15 位有符号量（0.001 m/s²/count），转向请求是字节 22–23 的大端有符号量（537.7 counts/degree），E2E 保护为对字节 2–31 做 CRC-16/CCITT 并附加小端数据 ID 0x444A。这一条报文也是 Panda 白名单里的唯一入口。
三条总线上的报文分工
移植说明把总线关系写得很清楚：动力总成在 Panda bus 1，被中继的 ADAS 报文对在 bus 0，摄像头在 bus 2。控制指令只在 bus 0 上发出，且只有 32 字节这一种形态被接受。网关发出的 0x1A0 属于另一条路径，该分支从不发送它。
| 总线 | 承载内容 | 在控制链中的角色 |
|---|---|---|
| Panda bus 1 | 动力总成 | 被观测，不作为指令出口 |
| Panda bus 0 | 中继后的 ADAS 报文对 | 唯一允许发送 32 字节 0x160 的出口 |
| 摄像头 bus 2 | 摄像头原始 0x160 | E2E 计数器与未知字节的来源 |
配套的 DBC 规模是 15 条 CAN/CAN FD 报文、120 条信号条目。需要留意的是，DBC 自带的表头写的是「2023 Toyota Corolla」，并标注位位置是从被动日志推断的，而移植目标是 2025 年款。因此它应被当作候选研究定义，而不是已验证的年款网络地图。
0x160 的字段布局与 E2E 校验
E2E 保护是这套控制路径里最容易被低估的部分。它不是简单的校验和，而是 AUTOSAR E2E 风格的「计数器 + CRC」组合：字节 2 是摄像头计数器，字节 0–1 是小端 CRC，CRC 覆盖字节 2–31 并附加小端数据 ID 0x444A。
| 字节位置 | 含义 | 编码 | 换算 |
|---|---|---|---|
| 0–1 | E2E CRC | 小端 16 位 | CRC-16/CCITT，覆盖字节 2–31 + 数据 ID 0x444A |
| 2 | 摄像头计数器 | 8 位 | 控制器每收到一个新计数器只发一次 |
| 4–5 | 加速度请求 | 15 位有符号 | 0.001 m/s²/count |
| 22–23 | 转向请求 | 大端有符号 16 位 | 537.7 counts/degree |
| 其余字节 | 摄像头未知字段 | — | 原样保留，不做猜测 |
控制器的行为边界也由这张布局决定：它只改已知的加速度与转向字段，保留摄像头的未知字节，重算计数器与 E2E 校验，并且当某个轴不由 openpilot 控制时，原样中继该轴的字段。这意味着「替换控制」不是构造新报文，而是在原报文上做最小改动。
为什么 537.7 counts/degree 是关键数字
转向字段的换算系数决定了限幅的实际含义。Panda 侧的转向限幅写的是每接受一帧最多变化 1,500 counts，换算后对应的角度增量才具备物理意义。脱离换算系数去谈限幅是没有意义的——这也是为什么这类移植必须先把 scale 钉死，再谈安全包络。
安全边界：三层限幅与单一白名单
TSS3 的 Panda 模式只有在使用 ALLOW_DEBUG 构建时才存在。它的发送白名单里只有一条指令：bus 0 上的 32 字节 0x160。旧款 8 字节 0x160、0x1A0、老款丰田转向报文以及所有无关地址都被拦在白名单外。
| 约束项 | Panda 侧包络 | 控制器侧实现 |
|---|---|---|
| 加速度 | -3.5 .. 2.0 m/s²（实测原厂中继包络） | 额外夹到 -1.5 .. 1.5 m/s² |
| 转向变化率 | 每接受帧最多 1,500 counts | 被拒绝的帧不推进限幅基线 |
| 发送地址 | 仅 bus 0 的 32 字节 0x160 | 从不发送 0x1A0 |
| 构建开关 | 需 ALLOW_DEBUG | 生产构建会拒绝该输出 |
「被拒绝的帧不推进限幅基线」这一条值得单独注意。如果拒绝帧也推进基线，攻击者或故障状态就能通过连续发送被拒帧把限幅额度消耗掉，进而让下一次合法大动作被吞掉。这里的实现避免了这个问题。
仍然没有闭环的部分
项目明确列出了几项未解决项：转向灯信号不在三条被接的总线上，因此无法用已验证信号来暂停转向；脱手警告看起来由扭矩超时强制执行，未找到可抑制的 CAN 位，仍需手扶方向盘；0xDA 报文里的四个字段尚未可靠区分驾驶员扭矩与 EPS 扭矩，因此 steeringPressed 保持为 false 而不猜测；驾驶员物理扭矩信号已知在 0x030 上，但可接受的超控阈值未做动态验证。车辆参数目前沿用 E210 Corolla 的 3,060 lb、2.67 m 轴距、13.9 转向比。
常见问题
0x160 的 E2E 校验到底覆盖了哪些字节？
覆盖字节 2 到字节 31，算法为 CRC-16/CCITT，并附加小端序的数据 ID 0x444A。字节 0–1 存放小端序的 CRC 结果，字节 2 是摄像头计数器，这两部分不参与自身校验。
为什么必须手动选择车型而不是自动指纹识别？
因为现有的行驶日志无法唯一关联到 2025 年的 F181 身份。已处理的 rlog 在逻辑 bus 1 上有 147 个地址/DLC 对，加上启动段后并集为 152 对，逻辑 bus 0 上有稳定的 22 条报文 ADAS CAN FD 结构；但这一并集与一份 TSS3 Camry 的普查结果重叠，且行驶日志里 carParams 为 MOCK 而非在路上的 F181 响应。自动匹配存在误判车型身份的风险。
生产版 Panda 能用这套控制吗？
不能。TSS3 Panda 模式只在以 ALLOW_DEBUG 构建时编译进固件，生产安全构建不会启用这个实验性白名单，因此会拒绝控制器发出的 0x160 输出。这是有意设置的状态，直到剩余的车辆级策略与验证工作完成。
这份 DBC 能当作 2025 年款的完整网络地图吗？
不能。DBC 表头写的是 2023 Toyota Corolla，并注明位位置由被动日志推断；移植目标却是 2025 年款。上游也明确把若干字段身份、比例与整车标定列为未解决项，另有不透明的 BYTE* 信号与已解释信号重叠，严格解析器可能报重叠。它是候选研究定义。
EPS 应用层的比对结论能推到整车 CAN 信号吗？
不能。证据只支持转移 EPS 应用代码的结论：2025 与 2023 的高应用区从 0x17E00 起逐字节相同，F181 记录为 8965F1208000 与 8A3111213000，MCU 为 R7F701383。这不等于证明每一条整车 CAN 信号与标定都相同。
延伸阅读
- opendbc 车型校验算法族：同名 CRC8 不可替换，RX/TX 共用函数 —— 理解丰田 E2E 校验与通用校验算法族的关系
- 2014 丰田 Yaris Hybrid XP130 的 CAN 信号地图 —— 同品牌另一条总线上的信号布局对照
- 车型协议接入实践：从指纹识别到安全固件的最低契约 —— 手动选车型与指纹收敛之间的取舍
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 40 Hz 控制报文在时间维度上的可用性判断
参考资料
- 项目 02 ——
public-can-dbc-datasets/additional/spanconstant5-corolla-tss3-2025/docs/COROLLA_2025_TSS3_PORT.md（0x160 字段布局、E2E 算法、失败闭合边界与 CAN 普查数据） - 项目 02 ——
public-can-dbc-datasets/additional/spanconstant5-corolla-tss3-2025/README.md（状态表、安全边界、已知车辆行为与离线检查命令） - 项目 02 ——
public-can-dbc-datasets/additional/spanconstant5-corolla-tss3-2025/SOURCE.md（DBC 规模 15 报文 / 120 信号、年款偏差与证据边界）
免责声明
本文所述控制路径来自公开仓库的移植说明，属于实验性研究成果，未经过独立实车验证。文中涉及的报文 ID、字节偏移、换算系数与安全限幅仅适用于该仓库描述的目标车辆与固件状态，不同年款、市场与 ECU 版本可能存在差异。任何涉及车辆控制的实现都必须以实际测量与合规的安全验证为准，本文不构成发送报文的操作指引。
更新记录
- 2026-10-14 初稿
发表回复