结论：接入一个新车型，最低工作集是走完一条固定骨架：安全板接收 CAN → 主机车况网关 → 指纹与 ECU 固件匹配 → 生成车型参数与安全模式 → DBC 解析出车况 → 控制器生成候选发送帧 → 回包编码 → 主机到板传输 → 板端安全钩子放行。公开资料在固定快照中核对了 17 个车型实现目录，但「实现入口存在」并不等于已完成某品牌全部平台与年款的报文与安全审计。接入的关键判断有三条：未识别 / 模糊匹配默认被动；品牌目录不能代替平台差异验证；含 ALLOW_DEBUG 条件的模式不等于发布固件可启用执行。
车型实现的共同骨架
公开资料显示，车型实现的加载与运行是一条固定链路，可按下面顺序理解：
- 安全板接收 CAN 帧，交给主机车况网关；
- 网关做指纹识别与 ECU 固件匹配，形成车型参数与安全配置；
- DBC 解析器把原始帧解析为车型车况；
- 控制器消费车况，生成控制意图；
- 车型控制器把控制意图编码为候选发送帧；
- 候选帧经主机发送线程下发，最终由安全固件的发送钩子决定是否放行。
两个结构性事实需要注意：其一，车型接口由一份品牌清单静态加载，不是运行时扫描任意插件目录；其二，每个品牌常规包含车型枚举与物理配置、车型参数与安全模式、接收帧到车况、控制意图到候选帧这几组模块，部分品牌另有雷达接口。这些模块的职责边界，就是后续插件化时「能力契约」的划分依据。
十七个品牌目录与平台差异
固定快照中核对到的车型实现入口如下。每类的接口、状态、控制器与配置模块均已在目录中确认存在，「雷达接口」表示另有雷达相关模块。此表是开发入口索引，不能替代平台差异验证：
| 品牌目录 | 额外雷达接口 | 平台/安全差异 | 当前深度 |
|---|---|---|---|
| body | 无 | 非汽车双轮平台 | 链路已追踪 |
| byd | 无 | 仅调试安全模式 | 单车型转角链路已追踪 |
| chrysler | 有 | 多车型链 | 主要链路已追踪 |
| ford | 有 | 经典 CAN 与 CAN FD | 主要链路已追踪 |
| gm | 有 | ASC M / 相机若干链路 | 主要链路已追踪 |
| honda | 有 | 两套转向实现 | 主要链路已追踪 |
| hyundai | 有 | 经典 CAN 与 CAN FD | 主要链路已追踪 |
| mazda | 无 | 扭矩/速度迟滞 | 主要链路已追踪 |
| mg | 无 | 仅调试安全模式 | 扭矩链路已追踪 |
| mock | 无 | 空发送回退 | 非实车回退已追踪 |
| nissan | 无 | 转角 / 车型取消 | 主要链路已追踪 |
| psa | 无 | 三总线，仅调试安全模式 | 转角链路已追踪 |
| rivian | 有 | 两代硬件 | 主要链路已追踪 |
| subaru | 无 | 含 preglobal 分支 | 主要链路已追踪 |
| tesla | 有 | 转角 / 原车转发 | 主要链路已追踪 |
| toyota | 有 | 逐层样本 | 已逐层追踪 |
| volkswagen | 有 | 多平台安全模式 | 主要链路已追踪 |
特别要注意：安全钩子注册表把若干模式（第三方品牌、部分平台）置于 ALLOW_DEBUG 条件下；实现目录与测试存在，并不表示发布固件可启用执行。目标车型还须以具体平台与固件版本逐一核对。
启动阶段的五道控制门
车型识别与启动阶段依次经过多道门，每道门都可能让系统停留在「被动」状态：
| 入口 | 行为 |
|---|---|
| CAN 指纹 | 在总线上按 CAN 地址与数据长度逐步排除候选；超过限定帧数后停止，不保证未知车型能识别 |
| 指纹确认 | 优先查询 VIN、ECU 存在性及固件版本，再收集 CAN 指纹；单一固件候选可覆盖结果，环境变量可强制指纹（仅用于受控开发） |
| 固件匹配 | 先精确固件匹配，失败再尝试模糊 / 品牌自定义匹配，返回是否精确及候选集 |
| 车型获取 | 无候选时回退空模型；用候选接口生成车型参数并保留 VIN、固件、指纹来源及模糊匹配标记 |
| 控制就绪 | 仅在进程初始化、非被动、控制请求存活的路径调用车型编码形成候选发送帧 |
这里要分清几种状态：空模型、被动、仅仪表记录互不相等，但都不能作为未知车型开始执行的理由；用户配置或环境变量强制指纹也不构成车辆协议兼容性验证。
DBC 编解码的函数级语义
解析与编码是两个方向，公开资料给出的关键语义如下：
| 入口 | 关键含义 |
|---|---|
| DBC 加载 | 加载消息、信号、枚举；按 DBC 系列选择校验算法 |
| 取值 | 按大小端与位提取原始整数；符号、倍率和偏移另行处理 |
| 解析 | 解码信号、计算校验和与计数器；失败返回失败，不把这一帧的部分值提交 |
| 计数器 | 错误计数达阈值则拒绝，有效后逐步恢复 |
| 整帧解析 | 仅接收指定总线与已注册地址，更新值与时间戳，返回成功解析的地址集 |
| 健康位 | 检查最近成功时间、计数器与缺失次数；总线空窗单独观察 |
| 编码 | 反向应用倍率/偏移，自动补计数器与校验和；未知信号仅记录错误并跳过 |
| 组帧 | 返回地址、编码后数据与总线号；未命中消息名时返回空数据 |
最常见误用是只看数值而忽略健康位：解析器保存的是最近一次成功值，若忽略有效位与总线健康，就可能把旧值当成当前观测；编码器只是协议编码，不是转向扭矩或加速度安全门。
样本三层与插件化最低契约
以样本车型看，三层结构最清楚：
| 层 | 已核对决策 |
|---|---|
| 车型能力 | 设定安全模式与助力比例；按平台/固件选择扭矩或角度控制、制动地址、加密、原车/自控纵向能力 |
| ECU 变更 | 特定实验纵向模式会执行 ECU 通信控制，退出时尝试恢复；属车型专属且需单独台架验证 |
| 输入状态 | 区分动力、相机总线与平台标志，解析车门、安全带、制动/油门、轮速故障、转角与驾驶员扭矩 |
| 控制器 | 按驾驶员扭矩与助力限制转向请求；按提醒、纵向能力、车速与加密分支生成候选帧 |
| 固件接收 | 从指定报文维护扭矩、角度、巡航、油门、刹车及车速样本 |
| 固件发送 | 检查转向扭矩/角度速率、纵向加速度、AEB 与诊断报文 |
从这条样本链可以抽出面向插件化的五条最低契约：
- 车型插件声明平台、ECU 固件范围、DBC 版本、总线拓扑、能力位、车型参数与安全模式；未识别 / 模糊匹配默认被动；
- 解码插件输出值、时间戳、来源、校验 / 计数器 / 超时状态，不能把上次成功值伪装成当前有效观测；
- 控制插件只产生结构化控制请求或候选帧，不能自行改固件白名单、安全模式或绕过车况网关；
- 硬件安全控制器独立于应用 CPU 实现收发与转发限制、心跳失效回退与板级故障处理；
- 每个目标车型逐一建立解析、编码、固件安全和回放基线；品牌目录索引不是一套通用线束或固件配置规格。
常见问题
有了某个品牌的车型目录，就能接这个品牌的全部车型吗？
不能。品牌目录只证明实现入口存在，不能代替平台差异验证。目标车型须以具体平台与固件版本逐一核对；同一品牌可能同时存在经典 CAN 与 CAN FD 等不同分支。
未知车型会怎样处理？
无候选时会回退到空模型；未识别或模糊匹配默认被动。被动、仅仪表记录与空模型互不相等，但都不能作为未知车型开始执行的理由。
CAN 解析出的值可以直接用吗？
不能只看数值。解析器保存的是最近一次成功值，必须同时检查有效位、时间戳与总线健康，否则会把旧值误当成当前观测。
安全模式在调试条件下可用，是否代表能上车执行？
不代表。若干模式被置于 ALLOW_DEBUG 条件下，实现目录与测试存在并不表示发布固件可启用执行；实际执行还需台架与受控场地验证。
延伸阅读
- 大型 ADAS 代码库怎么读：四步阅读顺序与三类边界 —— 先建立整体阅读顺序，再进入车型层。
- 车型指纹与 DBC：从总线特征到车型识别的判定链 —— 展开指纹识别的工程细节。
- CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 承接健康位语义。
- 从使能到车轮：执行链上的八道门，以及它们各自不保证什么 —— 承接候选帧到板端放行的门控链。
- 同一个「转向灯」在三家车厂是三种实现：车辆状态归一化的坑 —— 承接跨品牌车况归一化。
参考资料
- 项目 02 ——
openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（取用车型实现骨架、17 个品牌目录索引、启动控制门、DBC 编解码语义、样本三层结构与插件化最低契约）。
说明：本文为对固定源码快照（主仓库提交 c8fb906 及固定的车型协议与安全固件归档）的静态阅读整理，未接入目标车型、线束或安全板，未运行完整测试套件。文中所有入口、状态与目录均出自源文档，样本车型仅为实现链路示例，不是对任何年款或配置的实车适用性声明。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复