结论：openpilot 的「回放」有三个入口，用途完全不同：C++ replay 可执行文件发布历史消息与 VisionIPC 视频并驱动终端 UI；Python ui.py 只订阅数据做调试可视化；而 can_replay.py 会直接向 Panda Jungle 发 CAN 帧，是唯一对硬件有直接副作用的入口。三者中最容易被误用的就是把 --allow 当成 CAN TX 防火墙，或把可视化订阅当成只读安全——can_replay.py 不是只读分析工具。
本文基于固定源码快照，静态梳理命令行、终端 UI、Python 调试画面与独立的 CAN 硬件回放脚本。仅做静态阅读，未运行任一回放命令、下载数据、连接/重置/刷写硬件或发送 CAN。CAN 报文解析的健康语义见相邻专题。
三类入口：能力边界必须先分清
C++ Replay 是开发进程，启动时会把日志中的 CarParams 写入本地 Params，并可切换 ZMQ=1 让其他 UI/PlotJuggler 订阅。--prefix 为实例指定前缀，但仅靠服务过滤或视觉界面并不能隔离同机所有消息、参数和设备资源，必须在独立开发环境核对具体命名空间。
| 入口 | 实现 | 能力 | 关键边界 |
|---|---|---|---|
| C++ replay 可执行文件 | main.cc |
发布历史消息与视频、终端 UI、benchmark | 启动改写本地 Params；--cache 最终仍被钳制为至少五段 |
| Python 可视化 | ui.py |
raylib 窗口、相机画面、模型轨迹、告警曲线 | 只订阅数据；曲线是调试可视化，不是严格多主题时间对齐采样 |
| CAN 硬件回放 | can_replay.py |
直接向 Jungle 发 CAN 帧 | 对板卡状态有直接副作用，绝非只读分析工具 |
parseArgs() 解析 --allow/--block、段缓存数、起点、倍速、--auto、--data_dir、--prefix、视频与 benchmark 标志，参数转换用 atoi/atof；缓存和倍速在 main 中按正数过滤，起点由 Replay::start() 处理。未知路段、无可用片段仍在后续加载失败。
main() 随后可选创建 OpenpilotPrefix，实例化 Replay，设置缓存与倍速并加载路段：普通模式启动 ConsoleUI，benchmark 模式直接等待并打印时间线。两个边界要记牢：--cache 最终仍由 setSegmentCacheLimit() 钳制为至少五段；benchmark 只是发布吞吐统计，不是控制算法正确性验证。
终端 UI 与 Python 调试画面
ConsoleUI::exec() 约 20 Hz 刷新终端：空格暂停、s/m 前后跳、e/d/t/i/w/c 按时间轴跳、+/- 变速、回车输入绝对秒数。这里的 seek 输入会先暂停再恢复，但未检查 scanw 返回值；错误输入会保持初始 choice=0 并尝试 seek。这是 UI 层行为，不等同于引擎 seek 的参数校验。
| 函数 | 功能 | 边界 |
|---|---|---|
handleKey() |
空格暂停、+/- 变速、回车输入绝对秒数 |
未检查 scanw 返回值，错误输入仍会 seek |
updateStatus() |
从 carState/vehicleParameters 展示车速与转向参数 |
数据来自回放主题，不是实时车辆状态 |
updateTimeline() |
从 qlog 生成的 Timeline 绘制使能与告警 |
缺 qlog 时时间轴可不完整 |
Python 侧 ui_thread() 创建 raylib 窗口，用 CameraView("camerad", NARROW_ROAD) 读取 VisionIPC，相机画面与消息图层分开获取；SubMaster 订阅车况、规划、控制、雷达、标定、模型、告警等主题。一个明确的窄边界：get_arg_parser() 接受 ip_address 和 --frame-address，但主入口只用 ip_address 设置 ZMQ 并传给 SubMaster，--frame-address 在本文件中没有被传入 CameraView。远端消息可连接不代表远端帧可显示，该参数在当前实现中无效。
CAN 硬件回放：独立且危险的边界
can_replay.py 的四个阶段各有副作用。load_route() 读取 carParams 和所有 can 消息转为逐帧 CAN 列表，无入参时使用默认公开路段；脚本没有依据目标车型、总线拓扑或插入设备自动校验安全适配。connect() 持续枚举 Jungle，每个序列号启动独立发送线程——新连接设备会自动进入发送流程。
| 阶段 | 源码行为 | 安全含义 |
|---|---|---|
| 载入 | load_route() 读 carParams 与全部 can 消息 |
来源与内容必须固定、审计；不自动校验安全适配 |
| 发现 | connect() 枚举 Jungle 并起发送线程 |
新设备自动进入发送流程，不是只读工具 |
| 设备配置 | send_thread() 在 FLASH 存在时调用 flash()，随后 reset()、清缓冲、设 500 kbps、开点火与供电 |
对板卡状态有直接副作用；绝不能连实车总线运行 |
| 发报 | 以 DT_CTRL 节拍按记录帧组循环，仅保留 bus 不高于 2 |
仅过滤总线号不构成安全认证；依赖物理隔离台架 |
FLASH 是「存在即触发」，不是解析布尔值。发送循环仅过滤总线号，空日志会在取模位置失败，USB 超时被吞掉，不能把循环存活视作实际发送成功。
插件化落点与验证顺序
把三类入口分开：ReplayControl 只管理路线、时间、速率和服务白名单；ReplayVisualization 只订阅数据且不得取得 CAN 发送能力；HardwareCanStimulus 必须是独立、显式启用的台架插件，含设备白名单、物理隔离确认、报文/总线过滤、发送上限、急停和全量审计。
- 不能让通用插件注册机制自动发现并启用硬件刺激插件。
- 不能把
--allow当作 CAN TX 防火墙。 - 验证先从固定日志与 mock sink 开始，再查 Params/ZMQ/VisionIPC 隔离、CLI 异常输入、UI 缺主题/缺帧、消息时序。
- CAN 输出仅在独立 HIL 台架上用目标硬件与外部监测完成。
当前目录的 test_route.cc 只覆盖路线范围解析；本文没有运行 GUI、benchmark 或 HIL 测试，也未发现针对上述入口分支的同目录测试。
常见问题
can_replay.py 是只读分析工具吗？
不是。connect() 会持续枚举 Jungle，每个序列号启动独立发送线程；send_thread() 在 FLASH 存在时调用 flash()，随后 reset()、清 CAN 缓冲、设 500 kbps、打开点火与供电。它对板卡状态有直接副作用，绝不能在连接实车总线时运行。
replay 的 –allow 能当 CAN 发送防火墙吗？
不能。--allow/--block 只是服务过滤；can_replay.py 的发送循环仅按记录帧组循环发报、只保留 bus 不高于 2，仅过滤总线号不构成安全认证，脚本依赖物理隔离的 Jungle 台架。
为什么 ui.py 的 –frame-address 不生效？
源码里 get_arg_parser() 接受 ip_address 和 --frame-address，但主入口只用 ip_address 设置 ZMQ 并传给 SubMaster，--frame-address 在本文件中没有被传入 CameraView，所以远端消息可连接不代表远端帧可显示。
replay 曲线是严格时间对齐采样吗？
不是。曲线历史仅在 carState 更新时前移，其余主题值写入最后一行，因此它是调试可视化，不是严格的多主题时间对齐采样；终端时间轴缺 qlog 时也会不完整。
延伸阅读
- C++ Replay 引擎：历史消息与视频是如何被发布的 —— 承接本文的 C++ 入口，展开引擎内部的加载与发布。
- 进程回放的校验：固定日志与 mock sink 怎么用 —— 说明「不连接设备的回放验证」应放在哪一层。
- 安全测试台架与回放证据 —— 解释硬件刺激为什么必须与可视化订阅分离。
- pandad 原生 CAN 编解码与健康契约 —— 补齐 CAN 帧真正上总线的板端一侧。
参考资料
- 项目 02 ——
openpilot-research/REPLAY_FRONTENDS_CAN_DEEP_DIVE.md（取用了 C++/Python/CAN 三类入口的功能矩阵、终端 UI 边界与硬件回放四阶段副作用）。 - 项目 02 ——
openpilot-research/REPLAY_ENGINE_DEEP_DIVE.md（仅用于确认回放引擎的消息发布与加载边界，未取用其未公开内容）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复