结论：openpilot 的系统底座由四类互不等价的服务组成：manager 是进程生命周期的控制平面，cereal／msgq 是实时结构化消息数据平面，VisionIPC 单独传图像缓冲，Params 保存跨重启配置。不能把它们合并理解为一个「事件总线」，因为四者对可靠性、持久性和时序的承诺完全不同：msgq 是可被新写入覆盖的实时队列，而 Params 才承担持久化。本文为固定源码快照 c8fb906 的静态阅读，未在真实设备上启动完整系统、未验证断电与共享内存溢出的实际时序。
控制平面与数据平面：四类服务的分工
把 manager、cereal、VisionIPC 和 Params 当成同一类基础设施，会导致对可靠性和时序的错误假设。它们的职责边界在源码里是清晰分离的：manager 负责进程启停，cereal／msgq 负责实时消息，VisionIPC 负责图像缓冲的文件描述符传递，Params 负责跨重启的键值配置。
| 层 | 代表入口 | 语义边界 |
|---|---|---|
manager 控制平面 |
manager_init()、manager_thread()、ensure_running() |
订阅 deviceState、carParams、pandaStates，按 started 与点火边沿管理进程；状态消息是报告，不是安全固件许可 |
cereal／msgq 数据平面 |
new_message()、PubMaster.send()、SubMaster.update() |
实时结构化消息；新插件若依赖每帧必达，需自建可靠传输，不能把该队列当事务消息系统 |
VisionIPC |
VisionIpcServer::listener()、VisionIpcClient::recv() |
只传图像缓冲索引与元数据，图像内容不复制进普通 Event |
Params |
Params::put()、Params::get()、Params::clearAll() |
持久配置与少量控制状态，按生命周期标志清理；不适合替换高频 cereal 消息 |
启动与进程管理
manager_init() 清理按生命周期标志定义的参数，填默认值和版本／设备信息，建立共享内存路径并注册设备；注册失败会抛异常，因此不能假定 manager_thread() 已经开始。manager_thread() 订阅 deviceState、carParams、pandaStates，按 started 与点火边沿清理参数、更新 IsOffroad、调用 ensure_running() 并发布 managerState。NOBOARD、BLOCK 等配置会排除对应进程。
| 入口 | 已核对行为 | 关键边界 |
|---|---|---|
ensure_running() |
用 enabled、排除列表及 should_run(started, params, CP) 判定每个进程的目标状态，先停后启 |
条件按每次循环重算，不能假定 44 个进程同时运行 |
ManagerProcess.stop() |
先发 SIGINT 或指定信号，等待后必要时 SIGKILL | block=False 只发起停止，下次启动会等待停止完成 |
PythonProcess.start() / NativeProcess.start() |
分别用多进程包装 Python 模块与原生可执行文件 | 插件进程若纳入管理，需保留进程状态与退出语义 |
DaemonProcess.start() |
用持久 PID 与 /proc 命令行子串判断是否复用守护进程 |
不设置普通 proc 对象，stop() 为空 |
进程的入口和运行条件由 process_config.py 的静态表决定，因此插件化不能只实现动态 import，还需定义能力声明、依赖、健康状态及受管退出协议。收到卸载、关机、重启参数会退出循环，manager_cleanup() 清理受管进程后由 main() 调硬件关机或重启。此外，manager_thread() 仅在 deviceState 的存活、平均频率和有效位检查通过时更新电源监控看门狗文件，但进程启停仍读取缓存的 started，不受该健康门直接阻断。
消息契约与底层队列
log.capnp 与 services.py 分别定义 Event 的结构字段与主题清单、标称频率、日志选项和队列容量，改 schema 与服务表要同步消费者。new_message() 新建消息默认 valid=False 并写单调时钟 logMonoTime，生产者需要显式设置有效性；SubMaster.update() 轮询指定主题，更新帧号、消息时间与有效位；SubMaster.all_checks() 合并存活、平均频率和消息有效位，模拟模式会放宽部分时序检查。频率追踪以长期和近期平均频率判断接收速率，不是硬实时截止时间证明。
底层 msgq_new_queue() 在 /dev/shm（macOS 为 /tmp）建立 mmap 队列，msgq_msg_send() 检查发布者 UID 后向环形缓冲写入长度与负载并唤醒读者，msgq_msg_recv() 在读者被逐出或读指针失效时重置到当前写指针，旧消息不保证可补读。SubMaster 的 conflate=True 订阅意味着主要消费最新状态。因此 services.py 里的频率只是契约／健康检查参考，并不表示所有消息在该频率上严格同步。图像则单独走 VisionIPC：VisionIpcServer::send() 只向 msgq 发送缓冲索引、服务器 ID 和帧附加元数据，VisionIpcClient::recv() 用服务器 ID 与索引确认缓冲仍属于当前服务端。
Params 与生命周期配置
Params 是 C++ 实现的 Python 绑定。底层 Params::put() 先写临时文件、fsync、加锁、原子 rename 并同步目录；Params::get() 可阻塞等待非空值；Params::clearAll() 依键标志清除指定生命周期数据，并清理未登记键。它适合持久配置和少量控制状态，不适合替换高频 cereal 消息。插件应声明键名、类型、默认值、清理标志与迁移版本，避免私自写未登记键后被 clearAll() 删除。
设备启动门、记录与空间回收
hardware_thread() 订阅 panda、外设、定位与辅助驾驶状态，生成 deviceState；点火／连接状态形成行车条件，热状态、启动训练、条款、空间、系统启动完成、更新状态及设备注册等构成启动门。进入行车后仍持续检查点火与严重过热，panda 超时会清除点火条件。需要强调：deviceState.started 是 manager 启停 onroad 进程的信号，不是 selfdriveState.enabled 或 panda 的 controls_allowed。硬件移植必须实现 HardwareBase 的平台能力并处理相机、IMU、温度、供电及看门狗；当前硬件选择仅按 /AGNOS 在设备与 PC 两个实现间切换。
| 组件 | 关键函数 | 边界 |
|---|---|---|
loggerd |
loggerd_thread()、rotate_if_needed() |
记录服务消息并按编码器就绪或超时旋转分段，无相机包时有兜底旋转 |
encoderd |
encoder_thread() |
图像流编码与分段配合；日志索引和视频负载是不同文件／主题 |
uploader |
Uploader.list_upload_files()、upload() |
跳过锁定或已上传文件；计费网络限制视频上传 |
deleter |
deleter_step() |
空间不足时优先删除可回收旧分段，避开锁定目录 |
日志、上传与删除是旁路服务，不应成为转向／制动控制的同步前置条件。插件若新增高频主题，还需决定是否记录、抽样、队列容量与磁盘配额——仅在 services.py 注册主题并不足以保证长期可运维。
常见问题
msgq 队列能保证每条消息都被消费到吗？
不能。msgq 是可被新写入覆盖的实时队列，读者被逐出或读指针失效时会重置到当前写指针，旧消息不保证可补读。依赖每帧必达的插件应自行定义可靠传输或落盘机制。
deviceState.started 等于车辆已被使能吗？
不等于。started 是 manager 启停 onroad 进程的信号，与 selfdriveState.enabled 和 panda 的 controls_allowed 是不同层概念，不能相互替代。
为什么 Params 不适合传高频数据？
Params 每次写入都要写临时文件、fsync、加锁并原子 rename 并同步目录，面向持久配置而非高频流。高频结构化消息应走 cereal／msgq。
插件的参数键可以随便写吗？
不建议。Params::clearAll() 会依生命周期标志清理未登记键，插件应声明键名、类型、默认值、清理标志与迁移版本，否则可能被意外删除。
延伸阅读
- openpilot 的 100 Hz 控制回路：开源 ADAS 能给车载设备什么 —— 承接本文消息平面之上的控制实时性约束。
- openpilot 感知到控制：四条数据流与 100 Hz 闭环 —— 展示本文四类服务之上的具体数据流。
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 与本文
all_checks()的存活／频率／有效位检查相互印证。 - 从使能到车轮：执行链上的八道门，以及它们各自不保证什么 —— 说明
started与安全使能为何必须分层。
参考资料
- 项目 02 ——
openpilot-research/SYSTEM_FOUNDATION_DEEP_DIVE.md（取用了控制平面与数据平面分工、启动与进程管理、消息契约与 msgq 队列、Params生命周期，以及设备启动门与旁路服务）。 - 项目 02 ——
openpilot-research/HARDWARE_BACKEND_USB_SNAPSHOT_CONTRACT_DEEP_DIVE.md（仅用于确认硬件选择与deviceState的衔接位置）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复