结论：Toyota 雷达接口不是「每帧到达就出结果」，而是跨轮聚合 A 槽、以最后一个 B 槽作为发布触发的观测链：只有 B 槽到达时才调用 _update() 并清空集合，否则返回 None。这带来三个可复核边界：触发长期缺失时不会生成新 RadarData 或错误事件；can_valid 只在 _update() 时被读取；无解析器时基类每五次调用输出空点，且外层 valid 为真并不代表实体雷达正常。ECU 禁用是独立的通信控制动作，与雷达观测插件必须分权。
可用性由 DBC 决定，与 ECU 通信控制是两件事
radarUnavailable 由 DBC 配置决定：TSS2 配置默认含雷达 DBC，而 RADAR_ACC 平台配置会移除雷达总线 DBC。源文档明确，radarUnavailable 表示当前适配没有可解析的雷达 DBC，不等于物理雷达不存在。该路径实例化的 RadarInterface 没有解析器，落入基类定期输出空点的路径。
与可用性并列、但属另一层的是 ECU 通信控制：RADAR_ACC 且打开实验纵向时设置 DISABLE_RADAR，初始化时向 ECU 发通信控制，控制器周期发送 tester present。源文档强调这是车辆通信与纵向配置动作，不是 RadarInterface 的运行时健康开关，不能在没有车型、线束和安全审查时照搬。
A/B 槽聚合与发布触发
_create_radar_can_parser() 按车型选地址组与总线：TSS2 用 A 0x180..0x18f、B 0x190..0x19f；传统用 A 0x210..0x21f、B 0x220..0x22f。A/B 注册 20 Hz，STATUS_MSG 注册 10 Hz，总线为 1。
| 解析组 | 地址范围 | 名义频率 | 总线 |
|---|---|---|---|
| TSS2 A 槽 | 0x180..0x18f |
20 Hz | 1 |
| TSS2 B 槽 | 0x190..0x19f |
20 Hz | 1 |
| 传统 A 槽 | 0x210..0x21f |
20 Hz | 1 |
| 传统 B 槽 | 0x220..0x22f |
20 Hz | 1 |
STATUS_MSG |
源文档未给出具体地址 | 10 Hz | 1 |
RadarInterface.update() 把解析器本轮成功解析地址并入跨轮集合；仅当最后一个 B 槽出现时才调用 _update() 并清空集合，否则返回 None。_update() 查询 can_valid 与状态/预故障，只处理累计集合里的 A 槽，按 VALID、LONG_DIST、NEW_TRACK、valid_cnt、对应 B 槽 SCORE 新建、延续或删除点。
两处细节值得单独指出：B 的 SCORE 从 vl 当前缓存读，源文档指出它未要求 B 与 A 同周期；VALID 为真时直接满足发布条件，SCORE>50 仅为替代路径。A 槽中 NEW_TRACK 或距离越界会先清 valid_cnt，有效近距测量再加一；NEW_TRACK 新建 trackId，否则保留槽位现有点。
健康与发布的三个缺口
| 缺口 | 静态表现 | 结论边界 |
|---|---|---|
| B 触发长期缺失 | 无 B 触发时不发布新消息，也不生成错误事件；历史地址仍在集合里 | 适配层不会主动汇报该故障 |
健康门只在 _update() 读取 |
can_valid 与 STATUS_MSG 只在生成结果时变成 RadarData.errors |
触发丢失时错误来不及成为事件 |
| 无解析器的空点路径 | 基类每五次调用产生空 RadarData；card 仅非 None 时发布 |
外层 valid 为 errors 全假，不代表实体雷达正常 |
CANParser.update() 只返回本轮成功解析地址集，vl 保留各信号最近值；can_valid 检查注册消息缺失/超时和计数器，并有失效计数门。源文档明确 can_valid 只在 _update() 时被读取。无解析器时，RadarInterfaceBase.update() 每五次调用产生空 RadarData，card 仅在返回非 None 时发布 radarTracks，外层 valid 为 errors 全假。因此空点且外层 valid=True 不是「实体雷达正常」的证明，订阅者还要同时看 CarParams 与数据年龄。
几何约定与插件重构验收
几何输出为 dRel=LONG_DIST、yRel=-LAT_DIST、vRel=REL_SPEED。插件移植要锁定坐标约定、单位、测量时刻和传感器安装位姿，不能只复制数值字段。上游 radard 以 modelV2 为轮询源，读取最近的 radarTracks 和车况后发布 radarState；源文档提醒，上游不发布时融合循环仍按模型帧推进，不能把输出频率理解成雷达采样频率。
插件输出应包含 sensor_id、车型/DBC 版本、采样时戳、扫描周期 ID、A/B 配对依据、点年龄、健康原因码和观测状态，并区分「不适用、被禁用、未收到、CAN 不健康、状态故障、正常空点」。接入 radard 前，用只读回放验证 16 组 A/B 顺序错乱、B 槽丢帧、状态报文丢失、NEW_TRACK 复用、距离 255 门槛、VALID 与低 SCORE 组合以及总线超时。
源文档还给出触发缺失时的要求：应由独立 deadline 产生超时健康事件，而不是等待某个 B 地址恢复后才汇报；历史槽位与 SCORE 必须有最大年龄。这与「以最后一个 B 槽作为发布触发」的机制互补，提醒订阅者不能只依赖适配层的自行汇报。
最后是分权：ECU 禁用/恢复与雷达观测插件分权，属受信任车辆网关能力，不要把诊断写操作授权给普通传感器插件。本篇未运行测试；上述风险是源码条件推论，不是已复现的实车缺陷。
常见问题
radarUnavailable 是不是代表车上没有雷达？
不代表。源文档明确 radarUnavailable 由 DBC 配置决定：RADAR_ACC 平台配置移除了雷达总线 DBC，所以该路径没有可解析的 DBC，这不等于物理雷达不存在。
为什么雷达偶发不出结果却不报故障？
因为发布触发是最后一个 B 槽。源文档指出，B 触发长期缺失时不会生成新的 RadarData 或错误事件，历史地址仍在集合里；can_valid 也只在 _update() 时被读取，所以触发丢失时适配层不主动发布故障。
没有雷达解析器时输出空点且 valid 为真，能认定雷达正常吗？
不能。无解析器时基类每五次调用产生空 RadarData，card 仅在返回非 None 时发布，外层 valid 为 errors 全假。源文档明确这不能作为实体雷达正常的证明。
DISABLE_RADAR 是雷达观测的健康开关吗？
不是。源文档指出它是车辆通信与纵向配置动作：RADAR_ACC 且打开实验纵向时设置，并向 ECU 发通信控制、周期发送 tester present，与 RadarInterface 的运行时健康状态是两件事。
延伸阅读
- radard 前车融合 —— 融合循环如何以模型帧为轮询源消费
radarTracks。 - Toyota 车况输入与健康契约 —— 同一品牌的输入健康判定对照。
- 传感器融合健康位 —— 健康原因码如何区分「未收到」与「故障」。
- Toyota 接口能力与雷达禁用 —— 雷达能力开关在上层如何被表达。
参考资料
- 项目 02 ——
openpilot-research/TOYOTA_RADAR_ADAPTER_DEEP_DIVE.md（取用了地址组与名义频率表、A/B 槽聚合触发语义、健康发布缺口与插件重构验收清单）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复