Toyota 接口：能力参数怎么算，雷达静默事务又证明了什么

结论：Toyota 车型接口把能力参数构建与雷达静默事务分成两件不同的事：前者在 _get_params() 里派生安全参数、转向模式与纵向能力，后者由 init() 通过 UDS 0x28 通信控制向总线 0 地址 0x750 发请求。源文档指出 disable_ecu() 的返回值只反映「本函数的请求路径判定」，而 Toyota.init() 丢弃该返回值、card.controls_update() 在 CI.init() 返回后直接设置 ControlsReady——这是一个确认状态缺口，但不等于任何具体车辆 ECU 实际未静默。本文为静态追踪，没有车辆、台架、UDS 抓包或回放结果。

参数生成的先后次序

get_car() 在指纹和固件识别后，把 alpha_long_allowed、is_release 传给车型 get_params()，再实例化接口。基类 CarInterfaceBase.get_params() 先装配平台质量、轴距、转向比和静态 flags，再调用 Toyota _get_params()，随后增加标准载荷并计算惯量和轮胎刚度。末尾的质量、惯量和轮胎刚度计算依赖 Toyota 已设置的 centerToFront 等值，所以单独调用 _get_params() 或只复制 values.py 的标志，不能重建最终 CarParams。

Toyota safety model 固定为 toyota，safetyParam 先装载该车型 EPS_SCALE，再按动力 DBC、SecOC、角度控制和原车纵向模式叠加标志；ToyotaSafetyFlags 从第 9 位起定义，低字节留给 EPS 比例。换 DBC 或线束地址时，必须同步核对 MCU hook 的解析/白名单，不能把 CarParams 能力位看成安全策略的唯一实现。

注意 TSS2 且 RADAR_ACC 的平台配置还会移除雷达 DBC，因此「未提供雷达解析器」与「已经成功静默雷达 ECU」是两个不同状态。get_pid_accel_limits() 按 CarControllerParams 给出加速度最小/最大值，函数签名中的当前/巡航车速并没有用于动态调整。

纵向能力决策

纵向能力由源码布尔表达式决定，不是对全部平台的实车适用性声明：

autoResumeSng 在 Toyota 分支直接设为 openpilotLongitudinalControl。最低启用速度由 stop-and-go 能力选择 -1 或 19 mph 换算值；TSS2 加 RAISED_ACCEL_LIMIT 时，控制参数上限从 1.5 提升到 2.0 m/s²。发布版 SecOC 车型 dashcamOnly=is_release；card 若判为被动，会把 safety 配置改为 noOutput——这是上线许可门，不是 SecOC 密钥校验。

雷达静默事务：证明了什么、没证明什么

Toyota init() 仅在 DISABLE_RADAR 时调用 disable_ecu()，目标为总线 0、地址 0x750、子地址 0xF；默认请求是 UDS 0x28 的「使能接收/禁用发送」，作用于正常消息。disable_ecu() 最多尝试 10 次，每次先要求扩展会话 0x10 0x03 的 0x50 0x03 前缀响应，再发送通信控制请求。该函数自身注释明确警告此操作会禁用 AEB，应把原车主动安全能力变化纳入车型准入，而非当作普通功能开关。

关键缺口在于：通信控制阶段把期望响应前缀设置为空字节串，调用 query.get_data(0)，却丢弃该调用的返回字典；只要前置扩展会话查询产生条目且通信控制调用没有抛异常，disable_ecu() 就记录「ecu disabled」并返回真。get_data() 对非空响应使用 startswith(expected_response)，空前缀无法鉴别 UDS 正响应内容。加之 Toyota.init() 丢弃 disable_ecu() 返回值，card.controls_update() 在 CI.init() 返回后直接设置 ControlsReady，即便诊断静默请求返回假，也没有从这条返回链阻断就绪。

控制器在 DISABLE_RADAR 时按 20 帧节拍发送 tester-present 候选，但该帧生成并不证明 ECU 进入目标会话，也不证明会话保持或 AEB 真实状态。Toyota.deinit() 定义了相反的「使能接收/使能发送」请求，复用同一路径；但在本快照的运行链检索中未找到它的调用，因此不能把函数存在视为正常退出一定恢复 ECU。

硬件与插件重构边界

车型能力插件应产出期望配置而非宣称已经完成 ECU 改写，至少包含车型/固件/DBC 身份、纵向权限、AEB 影响、safety 模式及版本摘要。受信任诊断服务独占 UDS 写权限，把「请求接受」「正响应校验」「目标 ECU 读回/总线行为确认」「tester-present 存活」「恢复结果」设为独立状态；不满足确认条件时不得授予需要静默雷达的纵向执行能力。这一建议比当前源码多了安全门，属于拟议重构，不是现有实现描述。

验证路径上，可先在无车环境用 alpha_long、RADAR_ACC、SecOC 发布版、不同 Prius EPS 固件和 0x3F6 指纹构造参数矩阵，再用模拟 ISO-TP 正/负响应、无响应及超时检查请求与回执，最后在隔离台架核对 ECU 静默、AEB/FCW、重启与恢复时序。

常见问题

disable_ecu() 返回真，是否说明雷达 ECU 已被静默？

不代表。源文档指出该返回值只反映「本函数的请求路径判定」：通信控制阶段把期望响应前缀设为空字节串并丢弃返回字典，只要前置扩展会话查询产生条目且调用没有抛异常就返回真；get_data() 的 startswith 对空前缀无法鉴别正响应内容。因此这是确认状态缺口，不能断言具体车辆 ECU 的实际状态。

radarUnavailable 是不是在检测雷达是否在线？

不是。radarUnavailable 仅测试该车型 DBC 映射是否包含 Bus.radar，不是运行时雷达在线或健康检测；而 DISABLE_RADAR 反映的是参数层是否要发起诊断静默请求。源文档明确「未提供雷达解析器」与「已经成功静默雷达 ECU」是两个不同状态。

为什么单独调用 _get_params() 复现不了最终 CarParams？

因为基类 get_params() 先装配平台质量、轴距、转向比和静态 flags，再调用 Toyota _get_params()，末尾的质量、惯量和轮胎刚度计算依赖 Toyota 已设置的 centerToFront 等值。所以只复制 values.py 的标志或单独调用 _get_params()，都不能重建最终结果。

两种 EPS 固件的 Prius 为什么处理不同？

因为源码把旧 Prius 由 EPS 固件字节作例外：非指定版本时设 0.25 秒延迟和 0.2 度死区；明确识别到另一不支持的 EPS 版本时标记 dashcamOnly。源文档同时说明，固件列表为空或版本未命中时，不能据此推断该特例得到验证。

延伸阅读

• UDS 诊断工具为什么不能随手调：只读、会话与写 ECU 的分权设计 —— 与本文 disable_ecu() 的会话与写权限边界直接衔接。
• Toyota 的 panda 安全模式 —— 承接参数层之后 MCU hook 的解析与白名单。
• Toyota CarState 输入健康契约 —— 与本文的能力参数、固件特例互为对照。
• 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 解释 Toyota 分支为何要单独处理 EPS 固件与混动标志。

参考资料

• 项目 02 —— openpilot-research/TOYOTA_INTERFACE_CAPABILITY_RADAR_DISABLE_DEEP_DIVE.md（取用了参数生成次序、纵向能力决策表、雷达静默事务的确认状态缺口与插件重构边界）。
• 项目 02 —— openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（仅用于确认 Toyota 品牌目录与启动识别门的总体位置）。

说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

更新记录

首次发布 2026-10-11 最近核对：2026-10-11