星核火花赛车科技

标签： DBC

  • 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查

    结论：挑选公共 CAN / DBC 数据集，先按四类来源分流：DBC 定义、原始日志、信号笔记、配套工具。四类的可用性和风险完全不同——DBC 只描述帧、位段、缩放与枚举，不构成适配保证；原始日志需要自己解码；信号笔记多为社区假设；工具本身不含车辆数据。第二道筛选是许可证：同一批数据里既有 MIT、Apache-2.0、CC BY 与 CC0，也有 GPL 系与「无许可证」文件，商用再分发前必须逐个文件核对。

    先分清四类来源

    公开资料把收集到的资源分成几类，混用会直接导致误判：

    来源类型 内容 能直接做什么
    DBC 定义 帧、信号、位段、缩放、单位、枚举 按定义解码已覆盖的报文
    原始 CAN 日志 带时间戳的帧与载荷 需要自行解码或配合定义复盘
    信号笔记 ID、字节、公式、置信度说明 作为假设，待只读采集验证
    配套工具 采集、可视化、格式转换软件 分析手段，本身不含车辆数据

    规模上，公开资料记录到 2,330 份 DBC 文件副本，分布在 294 个 DBC 来源集合中，另含若干车型的原始 CAN 日志与信号笔记（例如某型商用车的 6 份 CAN 日志、某型 PHEV 的 11 份 CSV 采集、某型踏板的 5 份 SLCAN 采集等）。需要特别注意：部分文件在不同来源快照间重叠，因此应保留各自的来源目录以维持溯源。

    其中一份本地副本为公开 DBC 的工作区快照，含 119 个 DBC 文件，覆盖多个品牌与平台的模型 / 平台定义、雷达与总线定义，采用 MIT 许可。

    许可证是第二道筛选

    公开资料中出现的许可证类型很杂，选型前应先看许可证再看内容：

    许可证 再分发提示
    MIT / Apache-2.0 相对宽松，通常需保留署名
    CC BY 4.0 / CC0 1.0 署名或公有领域；仍应保留来源信息
    CC BY-SA 4.0 署名且相同方式共享
    GPL 系（GPL-3.0 / AGPLv3 / LGPL-2.1） 涉及衍生作品传播的义务，建议单独隔离
    无许可证文件 仅作离线研究副本，再分发前必须确认权利

    公开资料明确：即使上游仓库带 MIT 许可，个别车辆定义仍可能带有仓库许可未解决的第三方权利；对没有许可证文件的集合，应确认权利后再考虑再分发。工程上可操作的做法是把 GPL 系集合单独隔离，把无许可证文件仅保留为离线研究副本。

    三道筛查：来源、匹配、可复现

    通过许可证筛查后，按下面三步判断一份数据集是否可用：

    1. 溯源：确认来源仓库与固定版本。公开资料指出，部分本地副本是工作区快照，原始提交不可记录；其余下载来源带有固定的版本号。使用前应查上游历史，别依赖某个来路不明的修订。
    2. 匹配：核对车型年款、市场、动力总成、ECU 与总线拓扑。DBC 只解码标识符、位段、缩放、单位与枚举，不是通用适配保证；同名文件可能对应不同年款，甚至同一文件被同时映射到不同车型。
    3. 可复现：把信号名与缩放当作假设，直到用只读采集与独立测量验证。公开资料明确指出社区派生数据可能不完整，需以采集数据复核。

    这三步的顺序不能颠倒：先确认权利，再确认匹配，最后才是复现。跳过任何一步都可能把「看起来能解码」当成「确实正确」。更实际的做法是为每份数据集建立一页记录：来源与版本、许可证、目标车型与总线、已通过只读采集验证的信号清单，以及仍标为假设的字段。

    使用与质量注意事项

    • DBC 解码的是 CAN 标识符、位段、缩放、单位与枚举，不是万能适配保证；务必对照目标车辆的年款、市场、动力总成、ECU 与总线拓扑逐项核对。
    • 信号名与缩放可能是社区派生且不完整的，在只读采集与独立测量验证之前，应把数值当作假设。
    • 本地公开 DBC 副本是工作区快照，其原始提交不可记录；其余下载来源带有固定版本。依赖某个具体修订前，先查上游历史。
    • 上游仓库带 MIT 许可，但个别车辆定义仍可能带有单独的权利；保留署名，并在商业再分发前自行审查。

    常见问题

    有了一份 DBC 就能解出目标车型的全部信号吗？

    不能。DBC 只描述它已覆盖的帧与位段，且不是适配保证。必须先核对车型年款、市场、动力总成、ECU 与总线拓扑，再用只读采集验证。

    「文件数」能代表覆盖范围吗？

    不能。公开资料记录到 2,330 份 DBC 副本分布在 294 个来源集合中，但其中部分文件在不同快照间重叠；而且文件数不代表覆盖范围或已验证程度。

    上游是 MIT，是不是就能自由再分发？

    不一定。公开资料明确指出，个别车辆定义可能带有仓库许可未解决的第三方权利；对没有许可证文件的集合，应确认权利后再考虑再分发，并保留署名。

    社区信号笔记可以直接当结论用吗？

    不建议。信号名与缩放可能是社区派生且不完整的，应在只读采集与独立测量验证之前视为假设，并留意作者自己标注的置信度与未验证字段。

    延伸阅读

    参考资料

    • 项目 01 —— car-scanner-research/public-can-dbc-datasets/README.md（取用四类来源划分、文件规模与重叠提示、许可证类型、使用与质量注意事项）。

    说明：本文仅取用公开资料对 CAN / DBC 数据集的来源分类、许可证与质量口径，未部署任何工具、未连接总线或车辆、未进行通信抓包，也未核验各数据集的解码准确性与适配范围。文中所有规模、许可与注意事项均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

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

  • 凯旋 Speed 400 的广播信号图：0x25A 转速与三种车速

    结论：这份档案针对凯旋 Speed 400 与 Scrambler 400 X（Bajaj 生产 398 cc 单缸、Bosch 电喷），是对诊断接插件被动监听得到的广播信号图。总线是 500 kbit/s、11 位标准 ID，钥匙打开即上线（即使发动机不转），总线负载约 1400 帧/秒、约 32 个不同 ID。最有辨识度的发现是三条：转速在 0x25A 上以 1 转/分分辨率给出；车速存在三个彼此不同的值（ECU 值、仪表值、GPS 真值）；而总里程、进气温度、歧管压力不在广播里，只能 OBD 轮询读到。边界：用未端接的 DIY 抽头主动发送可能把控制器推向 bus-off，因此内容全部来自只监听；且克隆板与年款有别，需逐车复核。

    本文整理自该项目的广播信号图与说明。文档用星级给出置信度，本文原样保留。

    车辆与适用范围

    对象是凯旋 Speed 400 与 Scrambler 400 X 两款摩托。采集方式为对诊断接插件被动嗅探：用 ESP32 的 TWAI 控制器设成只监听模式，配一只 SN65HVD230 收发器（去掉 120 Ω 终端），抽头取 OBD 引脚 6（CAN-H）、14（CAN-L）与 12 V / 地。信号是通过刻意激励（刹车、离合、挡位、转向灯）与一次真实骑行确认的。

    项 内容
    车型 凯旋 Speed 400 与 Scrambler 400 X（Bajaj 生产 398 cc 单缸，Bosch EMS）
    年款 / 市场版本 源文档未确认（未绑定具体年款、ECU 版本或跨车适配）
    ECU / 改装状态 原厂 Bosch EMS；采集为非侵入式被动监听，无改装
    采集跨度 含一次真实骑行与多次刻意激励；文档未给出总时长
    适用范围 广播信号图为部分映射；克隆板与年款有别，需逐车复核

    总线与寻址

    文档给出链路层轮廓：500 kbit/s、11 位标准 ID、钥匙打开即上线，总线负载约 1400 帧/秒、约 32 个不同 ID。它是一张广播面的图，不是整车网络或诊断库。

    项 内容
    物理层 诊断接插件抽头（OBD 引脚 6 CAN-H、14 CAN-L）
    链路层 500 kbit/s，11 位标准 ID
    上线时机 钥匙打开（即使发动机不转）
    总线负载 约 1400 帧/秒，约 32 个不同 ID
    CAN FD 源文档未提及

    已解码信号

    下表从文档信号表抽取代表性条目。bN 为第 N 字节，bN:k 为第 N 字节第 k 位（bit 0 最低），bN:bM 为大端 16 位。星级沿用文档：三星为多会话复现或有物理证据、二星为单次会话强证据、一星为候选。

    信号 位置（ID / 字节） 解码 置信度
    发动机转速（细） 0x25A b5:b6（大端） rpm = raw，1 转/分分辨率，验证到 9271 三星
    发动机转速（粗） 0x140 b6 rpm = raw × 40，与 0x25A 一致（r = 1.00） 三星
    节气门（TPS1 / TPS2） 0x142 b0 / b1 % = (raw − 128) × 100 / 96，双线控传感器，基准 0x80 三星
    接合挡位 0x142 b3 0 为空挡，1 至 6 为挡位；按停留判定为「已接合挡」 三星
    车速（ECU 值） 0x296 b3:b4（大端） km/h = raw × 0.01；GPS 标定得 raw = 1.317 × 真值（r = 0.965） 三星
    车速（轮速） 0x102 b1:b2 / b3:b4（大端） km/h = raw × 0.0625（1/16），接近真实地面速度 三星
    冷却液温度（显示） 0x405 b7 °C = raw − 40；这是显示值，非原始传感器 三星
    环境气温 0x147 b3 °C = raw − 40；随天气在约 12 至 28 摄氏度之间 三星
    燃油液位 0x555 b1 raw 0 至 255（非线性）；低油位灯在 raw 约 90 点亮 三星
    电池电压 0x142 b7 V = raw × 0.1（充电 14.2 V，熄火 12.7 V） 三星
    侧撑 0x142 b6.1 该位为 1 表示放下 三星
    刹车 0x146 b1.0 该位为 1 表示正在刹车 二星
    转向灯 0x536 b2.0 该位为 1 表示激活（左 / 右尚未区分） 三星
    水箱风扇 0x405 b5.5 该位为 1 表示风扇开启 三星
    机油压力灯 0x400 b3.7 低有效（为 1 表示正常） 三星
    ABS 状态 0x121 ID 已确认（原厂故障码 U1000），具体字节尚未定位 一星

    读取方法与注意事项

    只监听，别主动发。文档最重的注意事项是：不要用廉价适配器主动轮询——在这个平台上，从未端接的 DIY 抽头发送可能把 CAN 控制器推向 bus-off 并中断接收。不过文档也澄清：用已正确端接的适配器做 OBD 轮询，实测整趟骑行没有 bus-off，因此该风险特定于「DIY 抽头在发送」，而非「合规适配器的轮询」。

    车速有三个，不要混用。文档用 GPS 对齐（r = 0.965）得到三套关系：ECU 值 0x296 × 0.01 = 1.317 × GPS 真值；骑手看到的仪表值 = raw × 0.89（约比 GPS 高 17%）；真正的地面速度 = raw × 0.76。文档另指出轮速 0x102 × 1/16 约等于 0.87 × raw，与结论自洽。

    挡位是「已接合挡」。文档用停留时间来论证：日常巡航时该值能保持数百帧不变（换挡杆输入会松手回中）；另有一个瞬时换挡信号在 0x406 / 0x407 上。

    温度要分清「显示值」与「真实值」。文档通过诊断对照发现：0x405 b7 是显示值（冷车时被钉在约 90 摄氏度，真实传感器冷态只有 28 摄氏度），真实冷车 / 过热应看 OBD 0105；0x147 b3 是环境气温而非进气温度。

    证据等级与边界

    文档星级即硬边界：三星为多会话复现或有物理证据，二星为单次会话强证据，一星为候选。表中二星与一星条目（如刹车、ABS）尚未达到确认级别。

    来源说明还列出几层限制：精确年款、ECU 版本与跨车适配未建立；仓库未附带原始 CAN 采集，无法独立回放；候选字段与尚未解决的左右转向灯区分不应被视为已确认；该 DBC 只是部分广播映射，不是完整的摩托网络或诊断库。文档也说明它是社区逆向成果，不隶属于凯旋或 Bajaj，并建议依赖任何结论前先在你自己的车上验证。

    据此，全部信号含义、比例与「不广播」的结论都不能外推到其他 Speed 400 / Scrambler 400 X 或其他车型，克隆板与年款差异更需逐车核对。

    常见问题

    Speed 400 的广播里能读到哪些量？

    文档记录的有：转速（0x25A 细、0x140 粗）、节气门、已接合挡位、车速与轮速、冷却液显示温度、环境气温、燃油液位、电池电压，以及侧撑、刹车、转向灯、水箱风扇、机油压力灯等开关量。

    为什么这台车的车速有三个不同的值？

    因为 ECU 值、仪表值与真实地面速度是三回事。GPS 标定得 ECU 值 0x296 × 0.01 约等于 1.317 倍真值，仪表显示约为 raw 的 0.89 倍（比 GPS 高约 17%），真实速度约为 raw 的 0.76 倍。

    为什么强调只监听、不主动轮询？

    文档记录：在这个平台上，从未端接的 DIY 抽头发送可能把 CAN 控制器推向 bus-off、中断接收，因此全部信号都靠只监听获得。但用一只正确端接的适配器做 OBD 轮询，实测整趟骑行也没有 bus-off，所以该风险特定于 DIY 抽头在发送。

    总里程、进气温度、歧管压力为什么读不到？

    因为它们不在广播里。文档逐字节、全字节宽、两种字节序地找过，都没匹配；这些量由 Bosch ECU 内部保留，只能通过诊断通道轮询（如 010B、010F、0105）取得。总里程甚至不在模式 01 中，只由仪表显示。

    转向灯的左右能区分吗？

    目前不能。0x536 的 b2.0 只报「激活」，左右之分需要一个带标注「先左后右」的采集才能确定，文档把它列为尚未解决项。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/tbtanmay111-triumph-speed-400/SIGNALS.md（本项目车型档案主来源，取用了逐信号表与置信度星级）。
    • 项目 01 —— public-can-dbc-datasets/additional/tbtanmay111-triumph-speed-400/README.md（取用了总线、采集方式与 OBD 轮询说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/tbtanmay111-triumph-speed-400/SOURCE.md（取用了「未建立年款 / ECU 版本、无原始采集」等边界说明）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • Honda CL250 诊断档案：5 个 DID 与 UDS 轮询

    结论：这份 Honda CL250（摩托车）档案的一个关键事实是：源文档目前没有已知的 CL250 广播报文——它的 cl250.dbc 是零报文、零信号的骨架。可用的数据来自主动 UDS 轮询 5 个 DID：转速、车速、节气门绝对位置、冷却液温度与电池电压，经 ISO 15765-2 单帧传输，主寻址是 29 位 0x18DA10F1（ECU 地址 0x10、测试仪 0xF1），回退到 11 位 0x7E0/0x7E8。工程约束也被写得很细：单请求在飞、基础超时 100 ms、响应挂起（NRC 0x78）翻倍超时、连续 5 次超时跳过该 DID 5 秒。下述内容仅限源文档记录的这一套定义。

    车辆与适用范围

    源文档来自一个摩托车车载平台项目，它把 CL250 的 ECU 定义与一张项目自建 CAN 分开管理。定义文件说明每个数值都从一份旧固件项目提取，而该旧固件自述「已在真实摩托车上验证过 CAN/UDS 通路」；但来源说明同时指出，那份被引用的仓库在核对时已无法公开访问，没有原始抓包被独立检查过，且部分轮询周期与 11 位回退寻址在源文档里明确标注为未验证。

    项 内容
    车型 Honda CL250（摩托车），ECU 记为 CL250_ECU
    年款 / 市场版本 源文档未给出年款与市场版本
    ECU / 改装状态 原厂 ECU；读取侧是一个测试仪节点（rt-core 或连接节点），只读轮询
    采集跨度 源文档未给出日志数；数值来源为一份旧固件项目的提取
    适用范围 仅限本套定义；被引用的旧固件仓库核对时不可公开访问，原始抓包未独立检查

    总线与寻址

    源文档把总线参数标为「已验证」的是经典 CAN 500 kbit/s；主寻址与回退寻址分开列出，并明确回退寻址「ECU 实际应答哪一个未被记录」。此外还列了两个只监视（watch-only）的功能地址，用于探测是否存在第二个测试仪。

    项 内容
    物理层 双绞线 CAN；经典 CAN（classic_can）
    链路层 / 比特率 500 kbit/s（源文档标 verified）
    主寻址 29 位固定寻址：请求 0x18DA10F1、响应 0x18DAF110；ECU 地址 0x10、测试仪 0xF1
    回退寻址 11 位：请求 0x7E0、响应 0x7E8；标为未验证（未记录 ECU 应答哪个）
    只监视地址 功能地址 0x7DF 与 0x18DB33F1，只看不发
    传输层 ISO 15765-2；帧 DLC=8；补齐字节 0xAA；旧固件只处理单帧

    已解码信号

    下表登记 5 个 DID 的解码，以及关键的服务与会话定义。DID 的公式与「已验证」标记按源文档原样保留；轮询周期一行给出旧固件值与平台建议值，并保留「平台值为暂定」的标注。

    信号 / 项目 位置（DID / 命令） 解码 / 说明 证据 / 置信度
    转速 ENGINE_SPEED DID 0xF40C（OBD PID 0x0C） (A×256 + B) / 4 → rpm，量程 0–16383.75 源文档标 verified；旧固件轮询 50 ms，平台建议 110 ms（暂定）
    车速 VEHICLE_SPEED DID 0xF40D（PID 0x0D） A → km/h，量程 0–255 标 verified；优先级 high；平台建议 110 ms（暂定），新鲜度 300 ms
    节气门绝对位置 THROTTLE_POS DID 0xF411（PID 0x11） A × 100 / 255 → %，量程 0–100 标 verified；平台建议 200 ms（暂定）
    冷却液温度 COOLANT_TEMP DID 0xF405（PID 0x05） A − 40 → °C，量程 −40–215 标 verified；平台建议 800 ms
    电池电压 BATTERY_VOLTAGE DID 0xF442（PID 0x42） (A×256 + B) / 1000 → V，量程 0–65.535 标 verified；旧固件的 A/10 启发式未沿用
    诊断会话 请求 0x10 0x03 → 正响应 0x50 扩展会话；未确认前每 2000 ms 重试 标 verified
    TesterPresent 0x3E 0x80 每 1000 ms 无条件发送（抑制正响应） 标 verified
    允许的服务白名单 0x10/0x3E/0x22/0x19/0x01/0x09 只读与会话类；禁止 0x11/0x14/0x27/0x2E/0x2F/0x31/0x34/0x36/0x37，并禁止 0x10 子功能 0x02 平台策略（D-020）
    功能地址监视 0x7DF、0x18DB33F1 只看不发；看到帧即说明存在第二个测试仪 标未验证（标准值，非取自旧固件）
    项目自建总线转发 dbc/platform.dbc 9 条报文、52 条信号；把轮询到的值再发布出去，不是 OEM Honda 库 来源说明

    读取方法与注意事项

    第一是时序预算。源文档记录：同时只有一个请求在飞（IDLE → WAITING → 完成/超时 → IDLE）；基础超时 100 ms；收到 NRC 0x78（响应挂起）时重置并把超时翻倍、上限 2000 ms，且请求仍留在等待态；其它 NRC 则把请求判为完成。连续 5 次超时的 DID 会被跳过 5000 ms。ECU 只要在最近 3000 ms 内有过正响应或任何 NRC，就视为「在线」。

    第二是优先级。DID 被分成 high / normal 两类，在同时到期的请求里先服务所有 high（本例中车速为 high，因为它喂给上游的航向估计），列表顺序只作同类内的平局判定。源文档强调优先级只改顺序、不改内容，且每个到期 DID 仍须在其新鲜度窗口内被服务。

    第三是 ISO-TP 首帧陷阱。旧固件只处理单帧（PCI 高半字节 0x0）；若收到首帧（PCI 0x1X），其 data[1] 是长度字段的一部分、不是 SID，按 SID 解析会破坏状态。旧固件直接丢弃非单帧帧；由于当前所有 DID 都能放进单帧，这只防未来响应变长。源文档据此写明：完整的 ISO-TP 多帧（首帧 + 流控 + 连续帧）需在新实现里从头做。

    第四是总线恢复。进入总线关闭后按指数退避重试：起始 1000 ms、每次翻倍、上限 30000 ms。

    证据等级与边界

    可视为「文档级已验证」的是 5 个 DID 的公式与主寻址，以及会话/超时/退避这些时序常量——它们都带证据引用。属于明确未验证的是：11 位回退寻址（未记录 ECU 应答哪个）、功能地址监视（标准值，非取自旧固件）、以及平台的轮询周期（源文档标注为暂定，与旧固件周期不同）。

    两处不能外推。第一，公式与 DID 只针对 CL250 这一辆车的 ECU 定义；换到其它 Honda 车型需要重新核对。第二，来源说明指出被引用的旧固件仓库在核对时已无法公开访问，原始抓包未被独立检查，因此「已在该车验证」属于源文档的转述，不是本项目的独立复现。

    关于「安全访问」类问题：源文档把 0x27（SecurityAccess）列为禁止服务，且未提供任何绕过方法，不建议尝试；本文只整理公开文档登记的只读轮询，不涉及写 ECU 或绕过安全机制。

    常见问题

    CL250 的报文能不能直接从总线上监听？

    源文档表示目前没有已知的 CL250 广播报文，cl250.dbc 是零报文、零信号的骨架；可用的数据来自主动 UDS 轮询 5 个 DID。

    轮询哪 5 个值？周期是多少？

    转速（0xF40C）、车速（0xF40D）、节气门绝对位置（0xF411）、冷却液温度（0xF405）、电池电压（0xF442）。旧固件周期为转速 50 ms、其余 800 ms；平台建议值为 110/110/200/800/800 ms，并标注为暂定。

    超时和响应挂起怎么处理？

    基础超时 100 ms；收到 NRC 0x78 时重置并把超时翻倍、上限 2000 ms，请求保持等待；其它 NRC 判为完成；连续 5 次超时的 DID 跳过 5000 ms。

    用 11 位还是 29 位地址？

    主寻址是 29 位 0x18DA10F1（响应 0x18DAF110）；11 位 0x7E0/0x7E8 是回退，源文档标注为未验证——未记录 ECU 实际应答哪一个。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/moto-platform-cl250/docs/legacy-telemetry-notes.md（主来源：UDS 状态机、NRC 表、总线恢复与 ISO-TP 陷阱）。
    • 项目 01 —— public-can-dbc-datasets/additional/moto-platform-cl250/uds/vehicle_cl250.yaml（DID 定义、寻址、会话与轮询时序）。
    • 项目 01 —— public-can-dbc-datasets/additional/moto-platform-cl250/README.md（项目结构、平台总线与 CL250 骨架的区分）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • Volvo P1 双 CAN 档案：HS 500 kbit/s 与 LS 125 kbit/s

    结论：Volvo P1 平台（V50 / S40 / C30 / C70）不是一张 CAN，而是两张经 CEM 网关相连的网络：高速网（HS）跑 500 kbit/s，承载发动机、助力转向、制动/ABS、方向盘传感器与踏板；低速网（LS）跑 125 kbit/s，承载收音机、车门模块、仪表（DIM）、空调（CCM）与 CEM。所有 ID 都是29 位扩展帧。更关键的一条边界是：较早年款需要先通过 K 线激活诊断继电器，CAN 才会出现在 OBD2 接口上。源文档的 HS 表来自 18 份实车日志（约 94.8 万帧）、LS 表来自另一台 C30，两者都不是全平台验证。下述结论仅限源文档记录的这些车辆与年款。

    车辆与适用范围

    源文档是一份公开研究整理的 CAN 参考表（原文为捷克语），同时给出拓扑、ID 表、若干字节拆分与一个「助力转向泵完整配方」。它自述 HS 表来自某个 V50 项目的 18 份抓包，LS 表来自一台 C30 T5 2011 加另一套 CCM/CEM 仿真。

    项 内容
    车型 Volvo P1 平台：V50 / S40 / C30 / C70
    年款 / 市场版本 HS 表来自一台柴油 V50（未给年款）；LS 表来自一台 C30 T5 2011；汽油版与其他年款未独立确认
    ECU / 改装状态 原厂网络；HS 侧含 ECM、助力转向（PSP）、制动/ABS、方向盘传感器、踏板；LS 侧含收音机、车门模块、DIM、CCM、CEM
    采集跨度 HS：18 份抓包、约 948,000 帧（一台车）；LS：一份 C30 2011 的接收列表 + CEM/CCM 仿真观察
    适用范围 仅限源文档记录的这两台车与其年款；HS DBC 自述「建立在一台具体 V50 的日志上」

    总线与寻址

    源文档把拓扑画得很清楚：两张网经 CEM 网关相连。HS 与 LS 的速率不同，且都是 29 位扩展 ID；生成的 DBC 需要设扩展标志（0x80000000），否则多数工具会当成标准帧。HS 表还给出一条很有用的启发式——每字节的「变化度」列（X 表示变化大、点表示变化小、横线表示恒定），用来判断哪里值得找信号。

    项 内容
    物理层 双绞线 CAN，两张网经 CEM 网关互连
    链路层 / 比特率 HS 500 kbit/s；LS 125 kbit/s
    寻址方式 29 位扩展 ID（DBC 需带 0x80000000 标志）
    CAN FD 否；按经典 CAN 处理
    OBD 可达性 较早年款需先经 K 线激活诊断继电器，CAN 才在 OBD2 接口可用

    已解码信号

    下表抽取 HS 与 LS 的代表性条目，并附一段诊断读数。源文档大量字段标注为「未解码」「仅推测」，这些标注按原样保留；LS 侧尤其如此。

    信号 / 功能 位置（ID / 字节 / 位） 解码 / 说明 证据
    发动机转速 HS 0x00800006 ECM_EngineData，B7 原始值 110 = 0 rpm（原始值口径，未给完整换算） 18 份实车日志
    仪表背光亮度 HS 0x0100082C Dashboard，B0 低半字节 调整亮度 实车日志
    光敏（环境光） HS 0x0100082C，B1 位 7 位 实车日志
    油门/离合器踏板传感器 HS 0x0110483C PedalSensors 源文档未细分到具体位 实车日志
    助力转向速度指令 HS 0x02104136 PSP_SpeedCmd，B6-B7 0x0001 = 满转速；值越大越慢，范围 1–6000 助力转向协议（第三方）
    制动 / 油门 HS 0x0300410E BrakeThrottle 源文档未细分到具体位 实车日志
    方向盘传感器 HS 0x0340412E SteeringWheelSensors 转角 / 角速度（未细分到具体位） 实车日志
    方向盘按键 HS 0x19000026，B7 按键码（已知 0x20） 实车日志
    点火状态 HS 0x19E00006 Ignition，B6 位 6 位 实车日志
    助力转向 keep-alive HS 0x1AE0092C，B1 轮转序列 0x00 → 0x40 → 0x80 → 0xC0；样例帧 00 00 22 E0 41 90 00 00 第三方协议 + 实车日志（周期 2000 ms vs 日志约 420 ms）
    助力转向状态 HS 0x1B200002，12 位 ((B6 & 0x0F) << 8) | B7 1105 初值 / 3953 怠速 / 3955 运转，三值均在实车日志出现 实车日志
    仪表控制（关键） LS 0x09C050B8 GaugeCluster_Ctrl B0 上 nibble 0x40、下 nibble = 背光亮度 0–15；B1 里程增量；B3/B4 转速 16 位；B5 低 nibble 显示消息码 CEM/CCM 仿真字节拆分
    中控按键 LS 0x05704000 B4 位 0-1/2-3/6-7 = EXIT/MENU/POWER；B5 位 6-7 = ENTER；B7 = UP/DOWN/LEFT/RIGHT 仿真字节拆分
    空调设置 LS 0x12404002 B0 右侧温度、B1 左侧温度、B4 常量 0x43 仿真字节拆分
    油量 LS 0x1AD10068 B0 = 油位；B1 = 0x04 仪表运行 / 0x07 熄火 仿真字节拆分

    另有一段诊断读数：源文档描述的一种厂方诊断风格协议，首个字节是长度、第二个是 ECU 地址，形如 [0xC8+字节数][ECU 地址][命令][参数…]；ECM 地址为 0x7A，读数据用 0xA6。已记录的缩放入下：

    标识 含义 缩放
    0x101D 转速 × 40 rpm
    0x1140 车速 × 1.25 km/h
    0x9D 增压压力 × 10 hPa
    0xD8 / 0xCE 冷却液 / 进气温度 × 0.75 − 48 → °C
    0x36 点火提前角 × 191.25 / 255

    读取方法与注意事项

    第一是可达性：源文档说较早年款要先经 K 线激活诊断继电器，CAN 才会出现在 OBD2 接口上；否则在标准诊断口上可能什么都看不到，且这容易被误判为「车不支持」。

    第二是寻址位数：所有 ID 都是 29 位扩展帧。源文档提醒，生成 DBC 时必须设扩展标志 0x80000000，否则多数工具会把 ID 当成标准帧，导致匹配失败。

    第三是「哪些字节值得看」。HS 表为每个 ID 都标了 B0–B7 的变化度（X / 点 / 横线），这是最快的筛选手段——恒定字节不用找信号，变化大的字节优先。未解码报文在 DBC 里只对「日志中确实变化」的字节生成占位信号（<名称>_B0 … _B7），可直接在抓包工具里画图找相关性。

    第四是助力转向泵需要「两条报文同时在线」：keep-alive（0x1AE0092C，只看 B1 的轮转）与速度指令（0x02104136，B6-B7）。源文档记录：没有 CAN 时泵按固定约 75% 功率运行；丢失 keep-alive 后约 5 秒进入失效保护，但保持最后下发的转速。这里只做整理，不建议照此在实车上驱动执行器。

    证据等级与边界

    可视为实车证据的是 HS 表（18 份抓包、约 94.8 万帧）与三条助力转向状态的取值；属于仿真/文档级的是 LS 侧的字节拆分（来自 CCM/CEM 仿真）与部分周期；属于明确未解码的是 HS 与 LS 表里大量标注为「未解码」的 ID。

    不能外推的地方有三处。第一，HS DBC 明确自述「建立在一台具体柴油 V50 的日志上」，汽油版与其他年款可能有 ID 的子集或超集。第二，LS 表来自一台 C30 2011 加仿真，并非 P1 全系；例如遥控电池 ID 在日志里是 0x1E30104A，而 CEM 仿真用 0x1E30106A，源文档自述「其一为笔误，或按年款不同」。第三，源文档保留了「未解码/仅推测」的字段，这些不能当作已确认信号。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试。它列出的厂方诊断风格命令里包含激活类服务，本文不展开，也不建议在实车上执行写入或激活操作。

    常见问题

    为什么在 OBD2 口上抓不到 Volvo P1 的 CAN？

    源文档说明较早年款需要先通过 K 线激活诊断继电器，CAN 才会出现在 OBD2 接口上；否则标准诊断口上可能没有流量。

    HS 和 LS 是一张网吗？

    不是。P1 有两张网经 CEM 网关相连：HS 500 kbit/s（发动机、助力转向、制动、方向盘传感器、踏板）与 LS 125 kbit/s（收音机、车门模块、DIM、CCM、CEM）。

    这些 ID 是 11 位还是 29 位？

    全部是 29 位扩展 ID。源文档提醒生成 DBC 时要设扩展标志 0x80000000，否则会被当成标准帧而匹配失败。

    助力转向泵为什么需要两条报文？

    源文档记录它需要 keep-alive（0x1AE0092C，看 B1 的轮转）与速度指令（0x02104136，B6-B7 的 0x0001 表示满转速）同时在线上；缺 keep-alive 约 5 秒后进入失效保护。本文只整理协议，不建议照此驱动执行器。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/chuck3cz-volvo-p1/UPSTREAM_README.md（主来源：拓扑、HS/LS ID 表、字节拆分与助力转向协议）。
    • 项目 01 —— public-can-dbc-datasets/additional/chuck3cz-volvo-p1/VOLVO_P1_CAN_REFERENCE.md（同内容的参考表）。
    • 项目 01 —— public-can-dbc-datasets/additional/chuck3cz-volvo-p1/SOURCE.md（快照范围、DBC 报文/信号条数与证据边界）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • 宝马 E9X 集成模块：K-CAN、PT-CAN 与 D-CAN 的消息翻译

    结论：这份档案来自一台 2008 年 E92 335i 上自制的 CAN 集成模块，它同时接入了 K-CAN、PT-CAN 与 D-CAN 三条总线。文档给出的速率是 K-CAN 100 kbit/s、模拟的 KCAN2 500 kbit/s；PT-CAN 与 D-CAN 的速率文档未标注。模块的核心工作是把老一代 BN2000 的消息翻译成新主机（NBT）能认的 BN2010 格式，并把一部分消息改走 K-CAN 以绕开网关延迟。边界有三条：代码与消息逻辑是「为这一辆 2008 E92 335i 定制的」；随附的两份 DBC 是该项目参考素材、不是经过验证的整网定义；文档还涉及对 DME 固件的定义修改，本文不复述其地址与字节，也不建议照做。

    本文整理自该项目的 README 与一份 BN2000 至 NBT 的消息翻译清单。文档本身多次强调其车型特定性，本文原样保留这层限定。

    车辆与适用范围

    项目对象是一辆 2008 年 E92 335i。文档在开头就写明：「代码对我这台车相当特定，但很多 CAN 消息逻辑可能有用。」硬件为一块 Teensy 4.0 三路 CAN 板（两路 CAN 2.0B、一路 CAN FD）配额外的一块 CAN 控制器用于主机模拟。

    项 内容
    车型 宝马 E92 335i（E9X 一代）
    年款 / 市场版本 2008（源文档未给出市场版本）
    ECU / 改装状态 自制集成模块，接入 K-CAN / PT-CAN / D-CAN；集成 F 系列主机（NBT / iDrive）
    采集跨度 源文档未给出；以功能清单与消息翻译清单形式记录
    适用范围 仅这一辆车；随附 DBC 为参考素材，非整网定义

    总线与寻址

    模块同时处理三条总线。文档明确的两处速率是：把 CAN 适配器速度设为 100000 对应 K-CAN、设为 500000 对应模拟的 KCAN2。PT-CAN 承载发动机扭矩等数据，D-CAN 用于诊断访问。文档说明消息发送被优化为走最短路径：需要送到仪表（KOMBI）的消息即使原厂走 PT-CAN，也会改发到 K-CAN，以绕开网关延迟。

    项 内容
    K-CAN 100 kbit/s（文档明确）
    KCAN2（模拟） 500 kbit/s（文档明确）
    PT-CAN 存在（承载发动机扭矩等）；速率源文档未给出
    D-CAN 存在（诊断访问）；速率源文档未给出
    寻址 消息以 11 位标准 ID 列出；CAN FD 能力由硬件支持

    已解码信号

    下表取自「BN2000 到 NBT」的消息翻译清单：左列为发往主机（NBT）的帧，右列为它的来源或处理方式。这些条目是该模块主动构造或翻译的消息映射，而不是某台车出厂网络的完整定义。

    帧 / 信号 ID 来源或处理 证据
    车辆状态 0x3C 由 BN2000 0x130 翻译 项目翻译清单
    终端状态 0x12F 由 BN2000 0x130 翻译 项目翻译清单
    道路倾角 0x163 经 0x6F1 取自报警器（SINE） 项目翻译清单
    俯仰角 X_VIEW 0x180 经 0x6F1 取自报警器（SINE） 项目翻译清单
    偏航率（陀螺） 0x19F 由 BN2000 0x1A0 翻译；NBT 硬件 10 及以上需要 项目翻译清单
    车速 0x1A1 由 BN2000 0x1A0 翻译 项目翻译清单
    距离 0x1C4、0x1C5 由 BN2000 0x1A6 翻译 项目翻译清单
    运动显示数据 0x253 运动显示相关 项目翻译清单
    亮度 0x2A5 由 BN2000 0x314 翻译 项目翻译清单
    PDC 状态 0x2C1 由 BN2000 0x3AF 翻译 项目翻译清单
    静止状态 0x2ED 由 BN2000 0x1A0 翻译 项目翻译清单
    转向角 / 有效转向角 0x301、0x302 由 BN2000 0xC8 翻译 项目翻译清单
    驱动模式开关 0x3A7 由 mdrive_status 与 dsc_program_status 适配 项目翻译清单
    MDrive 状态 0x42E 由 BN2000 0x399 翻译 项目翻译清单
    iDrive 音量 / 网关 0x6F1 承载 iDrive 音量与 SVT_70 网关等；检测到 OBD 工具在 D-CAN 通信时该组功能被关闭 项目 README

    读取方法与注意事项

    最短路径发送与队列。文档说明消息发送被优化为走最短路径以尽快到达接收模块，并用 FIFO 队列保证读写不被延迟阻塞。

    诊断访问下的自保。凡用到 0x6F1 的功能（如 iDrive 音量、SVT_70 网关），在检测到某个外部诊断工具于 D-CAN 上通信时会被停用。

    硬件与启动。文档列出的硬件包括 Teensy 4.0、MCP2562 收发器与用于主机模拟的 MCP2515 板；并提示为让部分启动时序敏感功能工作需修改 Teensy 启动代码。USB 类型随用途变化（单口常规、双口状态、三口 CAN USB 接口）。

    关于固件修改。文档提到对发动机 ECU 固件中与 CAN 消息表、CAN 过滤器相关的定义做过修改，并需要重算校验；还提到停用一部分原厂驾驶模式相关逻辑。这类操作属于对发动机 ECU 的固件改动，风险高且与本文主旨无关，本文不复述其地址、字节或步骤，也不建议照做。源文档未提供任何安全访问绕过方法。

    证据等级与边界

    来源说明把两份 DBC 的性质写得很清楚：EXX-BN2000.dbc（131 条消息、552 条信号行）与 FXX-BN2010.dbc（70 条消息、248 条信号行）是该项目的参考素材，不是针对每一款宝马 E / F 车型或年份验证过的整网定义；其中 EXX-BN2000.dbc 还在独立信号块里重复出现 TPCI、TA 等信号名，严格解析器可能拒绝；其他消息布局与 NBT 翻译未在本归档内对照实车核对。

    第二层边界来自项目自述：代码与 CAN 消息逻辑是为这一辆 2008 E92 335i 定制的，很多功能依赖具体选装件。因此文中列出的翻译关系与行为，只能视为「这台车 + 这套模块」的实现记录。

    据此，任何帧含义、来源映射或发送策略都不能外推到其他 E9X 或其他宝马车型；需要真值时应以本车抓包与独立复核为准。

    常见问题

    E9X 上有哪几条 CAN 总线？

    文档涉及三条：K-CAN、PT-CAN 与 D-CAN。其中明确给出速率的是 K-CAN（100 kbit/s）与模拟的 KCAN2（500 kbit/s）；PT-CAN 与 D-CAN 的存在可以确认，但速率源文档未标注。

    为什么要把消息改发到 K-CAN 上？

    为了走最短路径。文档说明：需要送达仪表（KOMBI）的消息，即使原厂会经 PT-CAN，也被改发到 K-CAN，以绕开网关（JBE）带来的延迟。

    随附的 DBC 能当整网定义用吗？

    不能。来源说明写明两份 DBC 是该项目的参考素材，不是针对每一款车型或年份验证过的整网定义；EXX-BN2000.dbc 还存在重复信号名，严格解析器可能拒绝。未在本归档内做实测核对。

    0x6F1 相关的功能什么时候会失效？

    文档记录：当检测到某个外部诊断工具在 D-CAN 上通信时，凡用到 0x6F1 的功能（如 iDrive 音量、SVT_70 网关）会被停用，以避免冲突。

    本文会给出 DME 固件修改的步骤吗？

    不会。文档确实提到对发动机 ECU 固件里 CAN 消息表与过滤器的定义做过修改并需重算校验，但这类操作风险高，本文只作事实提及，不复述地址、字节或步骤，也不建议照做；源文档未提供任何安全访问绕过方法。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/superwofy-bmw-e9x-can/README.md（本项目车型档案主来源，取用了总线、硬件与功能清单）。
    • 项目 01 —— public-can-dbc-datasets/additional/superwofy-bmw-e9x-can/Message translation for NBT.txt（取用了 BN2000 至 NBT 的消息翻译清单）。
    • 项目 01 —— public-can-dbc-datasets/additional/superwofy-bmw-e9x-can/SOURCE.md（取用了两份 DBC 的规模与「非整网定义」边界）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • 车型协议接入实践：从指纹识别到安全固件的最低契约

    结论：接入一个新车型，最低工作集是走完一条固定骨架：安全板接收 CAN → 主机车况网关 → 指纹与 ECU 固件匹配 → 生成车型参数与安全模式 → DBC 解析出车况 → 控制器生成候选发送帧 → 回包编码 → 主机到板传输 → 板端安全钩子放行。公开资料在固定快照中核对了 17 个车型实现目录，但「实现入口存在」并不等于已完成某品牌全部平台与年款的报文与安全审计。接入的关键判断有三条：未识别 / 模糊匹配默认被动；品牌目录不能代替平台差异验证；含 ALLOW_DEBUG 条件的模式不等于发布固件可启用执行。

    车型实现的共同骨架

    公开资料显示，车型实现的加载与运行是一条固定链路，可按下面顺序理解：

    1. 安全板接收 CAN 帧，交给主机车况网关；
    2. 网关做指纹识别与 ECU 固件匹配，形成车型参数与安全配置；
    3. DBC 解析器把原始帧解析为车型车况；
    4. 控制器消费车况，生成控制意图；
    5. 车型控制器把控制意图编码为候选发送帧；
    6. 候选帧经主机发送线程下发，最终由安全固件的发送钩子决定是否放行。

    两个结构性事实需要注意：其一，车型接口由一份品牌清单静态加载，不是运行时扫描任意插件目录；其二，每个品牌常规包含车型枚举与物理配置、车型参数与安全模式、接收帧到车况、控制意图到候选帧这几组模块，部分品牌另有雷达接口。这些模块的职责边界，就是后续插件化时「能力契约」的划分依据。

    十七个品牌目录与平台差异

    固定快照中核对到的车型实现入口如下。每类的接口、状态、控制器与配置模块均已在目录中确认存在，「雷达接口」表示另有雷达相关模块。此表是开发入口索引，不能替代平台差异验证：

    品牌目录 额外雷达接口 平台/安全差异 当前深度
    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 与诊断报文

    从这条样本链可以抽出面向插件化的五条最低契约：

    1. 车型插件声明平台、ECU 固件范围、DBC 版本、总线拓扑、能力位、车型参数与安全模式；未识别 / 模糊匹配默认被动；
    2. 解码插件输出值、时间戳、来源、校验 / 计数器 / 超时状态，不能把上次成功值伪装成当前有效观测；
    3. 控制插件只产生结构化控制请求或候选帧，不能自行改固件白名单、安全模式或绕过车况网关；
    4. 硬件安全控制器独立于应用 CPU 实现收发与转发限制、心跳失效回退与板级故障处理；
    5. 每个目标车型逐一建立解析、编码、固件安全和回放基线；品牌目录索引不是一套通用线束或固件配置规格。

    常见问题

    有了某个品牌的车型目录，就能接这个品牌的全部车型吗？

    不能。品牌目录只证明实现入口存在，不能代替平台差异验证。目标车型须以具体平台与固件版本逐一核对；同一品牌可能同时存在经典 CAN 与 CAN FD 等不同分支。

    未知车型会怎样处理？

    无候选时会回退到空模型；未识别或模糊匹配默认被动。被动、仅仪表记录与空模型互不相等，但都不能作为未知车型开始执行的理由。

    CAN 解析出的值可以直接用吗？

    不能只看数值。解析器保存的是最近一次成功值，必须同时检查有效位、时间戳与总线健康，否则会把旧值误当成当前观测。

    安全模式在调试条件下可用，是否代表能上车执行？

    不代表。若干模式被置于 ALLOW_DEBUG 条件下，实现目录与测试存在并不表示发布固件可启用执行；实际执行还需台架与受控场地验证。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_PROTOCOL_IMPLEMENTATIONS.md（取用车型实现骨架、17 个品牌目录索引、启动控制门、DBC 编解码语义、样本三层结构与插件化最低契约）。

    说明：本文为对固定源码快照（主仓库提交 c8fb906 及固定的车型协议与安全固件归档）的静态阅读整理，未接入目标车型、线束或安全板，未运行完整测试套件。文中所有入口、状态与目录均出自源文档，样本车型仅为实现链路示例，不是对任何年款或配置的实车适用性声明。

    更新记录

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

  • 菲亚特 Fiorino 的 B-CAN：50 kbps 上的车速、转速与油量

    结论：菲亚特 Fiorino（Fiat Mini 平台）的 B-CAN 是 CAN 2.0B、29 位扩展标识符、ISO 11898-3 低速容错物理层、50 kbps、大端（Motorola，MSB 在前）。文档记录了一个紧凑的帧矩阵：车速、转速、冷却液温度、喷油量、续航、油量等都能从几条固定 ID 上被动读到。这套解码背后有一个现实动机——Fiat Mini 平台的仪表存在一个出厂软件缺陷，总里程一到 399999 公里就永久冻结；作者因此让 ESP32 自行计算并存储里程，且系统随车通过了西班牙官方的 ITV 检验。边界：帧矩阵按平台记录，具体到某一辆车仍需核对，任何改动都应先在台架确认。

    本文整理自该项目的 CAN 矩阵文档与工程说明。文档把帧矩阵定义为「逆向得到的 Fiat Mini 平台 B-CAN 网络」，本文保留这一来源限定。

    车辆与适用范围

    项目以一辆 Fiat Fiorino 为对象，用一块 ESP32 加自定义载板替换原厂中央单色液晶，读 B-CAN 实时遥测并渲染自定义界面。文档提到同类平台的车型（Fiorino、Grande Punto、Alfa Romeo MiTo）共享这套仪表缺陷，因此帧矩阵按 Fiat Mini 平台陈述。

    项 内容
    车型 菲亚特 Fiorino（Fiat Mini 平台；同平台另有 Grande Punto、Alfa Romeo MiTo）
    年款 / 市场版本 源文档未给出具体年款；项目语境为西班牙市场（需通过 ITV 检验）
    ECU / 改装状态 用 ESP32 + 自定义载板替换原厂中央单色液晶；原厂仪表仍作为被替换对象存在
    采集跨度 源文档未给出；随车通过了西班牙官方 ITV 检验
    适用范围 按 Fiat Mini 平台记录的帧矩阵；逐车细节仍需核对

    总线与寻址

    文档把 B-CAN 定义为 CAN 2.0B、29 位扩展标识符，物理层是低速容错 CAN（ISO 11898-3），50 kbps，字节序为大端（Motorola，MSB 先）。接入侧使用 TJA1055T（低速容错 B-CAN 收发器），配合电平转换芯片适配 3.3 V / 5 V。

    项 内容
    物理层 低速容错 CAN（ISO 11898-3），50 kbps
    链路层 CAN 2.0B，29 位扩展标识符
    字节序 大端（Motorola，MSB 在前）
    收发器 TJA1055T 低速容错 B-CAN 收发器 + 电平转换
    CAN FD 源文档未提及

    已解码信号

    下表逐条取自文档帧矩阵。解码式中 B_n 表示第 n 个字节，位移写法保留原文。

    信号 位置（ID / 字节） 解码 证据
    发动机转速 0x04214001 字节 6 Byte[6] × 32（32 转/分/位） 文档帧矩阵
    喷油量 0x04214001 字节 4、5 ((B4 左移 8) 或 B5) ÷ 100.0，单位 mm³/行程 文档帧矩阵
    发动机温度 0x04214001 字节 3 B3 − 40，摄氏度 文档帧矩阵
    燃油消耗（推导） 0x04214001 字节 3 至 6 (raw_iq × RPM × 1.2) ÷ 1e6，升/小时（按 4 缸 4 冲程推导） 文档帧矩阵（派生量）
    总里程 0x0C014003 字节 1 至 3 (B1 左移 16) 或 (B2 左移 8) 或 B3，公里 文档帧矩阵；不采用，见下（399999 公里后冻结）
    续航 0x0C014003 字节 4、5 ((B4 与 0x03) 左移 8) 或 B5（字节 4 需掩码） 文档帧矩阵
    车速 0x04394000 字节 0、1 ((B0 左移 8) 或 B1) × 0.0625，km/h 文档帧矩阵
    燃油液位 0x06214000 字节 5 Byte[5]，直接取百分比 文档帧矩阵

    读取方法与注意事项

    先查 DLC，再取载荷。文档把「提取载荷前必须检查 DLC」列为安全要求，用于防止缓冲区越界读。这一条对 0x04214001 这类大端多字节字段尤其重要。

    0x0C014003 是复用帧。文档说明这一帧同时承载「总里程」和「续航」两组信息（多路复用），解析时要按同一帧内的不同字节段分别取用，不能只当一种含义。

    里程为何要自己算。这是本项目的核心动机：Fiat Mini 平台的仪表存在出厂缺陷，总里程到达 399999 公里后永久冻结、不再记录。文档因此让单片机从 B-CAN 实时遥测独立计算并安全存储总里程，并把它写入外部的 AT24C32 EEPROM（经 I2C，配合 DS3231 实时时钟），以避免磨损 ESP32 内部闪存。文档记录：该车带着这套系统通过了西班牙官方的 ITV 检验，作为可靠性的一次实证。

    两条核对手段。固件提供「被动 CAN ASCII 流式输出」（用一个编译开关打开），按标准 LAWICEL/SLCAN 格式（如 t1238…）把原始 B-CAN 帧输出到串口，便于用任意串口终端或自写脚本记录；界面上还有硬件状态浮层，用于提示 EEPROM 状态、熄火保存与内存损坏错误。

    证据等级与边界

    文档给出的帧矩阵被明确定义为「逆向得到的 Fiat Mini 平台 B-CAN 网络」，属于社区工程结果，而不是厂家规格。其中「燃油消耗」被文档自述为派生量（由喷油量与转速按 4 缸 4 冲程推导），而非总线上直接广播的字段；「总里程」虽可从帧中解出，但文档明确不采用该值，原因是它在 399999 公里后冻结。

    验证层面有两处相对硬的证据：其一，该车带着这套嵌入式方案通过了西班牙官方的 ITV 检验，文档把它作为「可靠且准确」的实证；其二，项目提供了原始 B-CAN 帧的被动流式输出，便于独立复核。但文档未给出逐信号置信度，也未绑定具体年款与配置。

    因此边界是：帧矩阵按 Fiat Mini 平台陈述，同平台车型（Fiorino、Grande Punto、MiTo）可能共享，但具体到某一辆车、某一年的配置仍需逐车核对；更换仪表属对车辆电气系统的改动，任何操作都应在台架或合规前提下进行。

    常见问题

    Fiorino 的 B-CAN 是什么协议和速率？

    文档定义为 CAN 2.0B、29 位扩展标识符、ISO 11898-3 低速容错物理层，速率 50 kbps，字节序为大端（Motorola，MSB 在前）。收发器用的是低速容错型号 TJA1055T。

    为什么不用总线上读到的总里程？

    因为 Fiat Mini 平台的仪表存在出厂缺陷：总里程到达 399999 公里后永久冻结、不再记录。项目因此让 ESP32 从实时遥测独立计算总里程，并写入外部 EEPROM 保存，而不是直接采信被冻结的广播值。

    车速和转速的解码式分别是什么？

    车速在 0x04394000 字节 0、1：((B0 左移 8) 或 B1) × 0.0625 km/h。转速在 0x04214001 字节 6：Byte[6] × 32，分辨率 32 转/分。

    解析时有哪些必须注意的工程细节？

    三点：提取载荷前先检查 DLC，防止越界读；0x0C014003 是复用帧，同时承载总里程与续航，要分段取用；全程按大端解析多字节字段。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/raul-fiat-fiorino-can/docs/Can_Matrix.md（本项目车型档案主来源，取用了总线规格与帧矩阵）。
    • 项目 01 —— public-can-dbc-datasets/additional/raul-fiat-fiorino-can/README.md（取用了 399999 公里冻结背景、硬件选型与 ITV 检验结论）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • 比亚迪 BYD 全车系 DBC 档案：7 个候选文件的报文规模

    结论：这份档案记录的不是一台车，而是一组面向比亚迪（BYD）与吉利车型的候选 DBC 文件：来源快照保留 7 个字节互不相同的 DBC，报文数从 4 条到 124 条不等。它的价值在于给「国产新能源整车的报文规模」提供了一份可核对的清单，但来源说明明确指出——项目文档里那张宽泛的车型列表并不能确立每个 DBC 对每种车型的适配，很多字段还用了占位名，且仓库快照里找不到许可文件（README 只有 MIT 徽章）。因此本文只登记文件与规模，不做「某款车某信号」的断言。下述内容仅限源文档记录的这一批候选文件。

    车辆与适用范围

    源文档是一个开源辅助驾驶适配项目的说明。项目自述针对「比亚迪全系与吉利」做适配，并提供了实车 DBC 报文数据库；但来源说明的措辞更谨慎：这些是「候选的逆向定义」，上游 README 的宽泛车型列表不构成逐车型的已核验适配。车型代号在 README 里列得很细（汉 DM/EV、唐 DM-i/DM-p、宋 PLUS/Pro/L、秦 PLUS/L、元 PLUS、海豹、护卫舰、腾势 D9 等），但它们属于文档级声称。

    项 内容
    车型范围 项目自述覆盖比亚迪（汉 / 唐 / 宋 / 秦 / 元 / 海豹 / 驱逐舰 / 腾势）与吉利（缤越）多款车型
    年款 / 市场版本 README 按年款列出代号（如 2020 汉 DM、2022 汉 DM-i、2022 元 PLUS / ATTO 3）；来源说明未确立逐车型适配
    ECU / 改装状态 面向车机端开源辅助驾驶项目；包含 EPS、ADAS、RADAR、CAMERA、BCM、VCU、BMS 等节点的报文
    采集跨度 快照保留 7 个字节互不相同的 DBC；上游还以嵌套目录重复了其中几个，快照已省略重复项
    适用范围 仅限这一批候选文件；跨车型、跨年款适用性未验证，且部分文件用占位名

    总线与寻址

    来源说明没有给出比特率、寻址位数这类总线参数——它登记的对象是 DBC 文件本身，而非一次抓包。因此本文按「文档级」记录：能确定的只有 DBC 这一载体、报文数与文件来源位置；总线物理参数应视为源文档未提供。

    项 内容
    载体 DBC 文件（报文 + 信号的数据库描述），非原始抓包
    物理层 / 比特率 源文档未提供
    寻址方式 源文档未提供 11 位 / 29 位说明
    CAN FD 源文档未提供
    节点覆盖（README 声称） EPS 转向、ADAS 辅助驾驶、RADAR 雷达、CAMERA 前视相机、BCM 车身、VCU 整车控制、BMS 电池

    已解码信号与文件清单

    由于主素材给的是 DBC 文件而非成品信号表，下表按「文件 / 条目」登记规模与来源说明原样保留的注意事项，不代填任何信号名或缩放。

    条目 上游位置 规模 / 内容 证据 / 注意
    byd_han_dmev_2020.dbc BYD_Files/opendbc/dbc/ 16 条报文 与已归档的另一副本不同：改动两个踏板缩放、省去 4 条报文
    byd_generic_pt.dbc byd2/ 19 条报文 通用动力总成候选文件
    byd_tangdm_radar.dbc byd2/ 4 条报文 唐 DM 雷达相关
    byd_generic_pt_v2.dbc 嵌套目录内的 opendbc/dbc/ 19 条报文 与上一份布局大体重叠，但报文明/信号名被混淆成不同写法
    byd_all.dbc byd大全.dbc 124 条报文 头部注明由运行时/导出资源重建，许多字段为占位名
    byd_song.dbc 比亚迪3/Bydsong(1).dbc 89 条报文 同目录 generated(1).dbc 与其字节相同
    byd_tang_dmp_based_on_han.dbc 比亚迪3/唐DMP_based_on_han.dbc 88 条报文 文件名即说明「基于汉架构扩展」
    车型代号表 项目 README 数十个代号 README 声称的适配范围，非逐车型已核验
    横向力矩曲线参数 LAT_SIGLIN_TABLE 项目 README 调参节 示例 [4.867, 1.09, 0.243] 调参说明，非 DBC 内信号
    吉利缤越相关参数 项目 README 50 Hz 控制频次、最大转向力矩 598 README 自述规格

    读取方法与注意事项

    第一，先把「文件」和「已核验适配」分开。来源说明写得很清楚：上游 README 的宽泛车型列表不确立每个 DBC 对每种车型的适配，而 byd_all.dbc 的头部自述是「由运行时/导出资源重建」，因此其中的字段名多为占位名。把这样的文件直接当作某车某信号的权威定义，会混淆「存在」与「正确」。

    第二，同名不同内容要留意。快照里两份 byd_generic_pt 变体布局大体重叠，但报文明和信号名被改写成不同写法；byd_han_dmev_2020.dbc 也与之前归档的副本不同（改了两个踏板缩放、少了 4 条报文）。同名文件的差异本身就是证据链的一部分，不能互相替代。

    第三，权利层面要谨慎。来源说明指出：仓库快照里找不到许可文件，尽管 README 带 MIT 徽章。因此这些文件只适合作为私有研究副本，在对外分发或整合前应先确认原作者与再分发权利。

    第四，README 里的调参项（转向速率上限/回正速率、力矩模式表、离手维持参数）属于控制侧参数，不是 CAN 信号；它们与 DBC 里的报文定义分属两层。

    证据等级与边界

    可视为可核对的是「快照里实际存在这 7 个文件、各自多少条报文」——这来自来源说明的逐条登记。属于未确立的是各文件对应的具体车型适配：来源说明用「候选的逆向定义」来描述它们，并指出部分字段是占位名。

    不能外推的地方有三处。第一，DBC 里有报文不等于该车型在总线上真的以这个布局广播；需要实车抓包核对。第二，混淆/占位名使得信号语义不可靠，不能据此命名功能。第三，不同年款之间的报文集合可能有子集或超集关系，跨年款套用没有证据。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档登记的文件与规模，不涉及对车辆安全机制的规避，也不涉及任何报文写入操作。

    常见问题

    这些 DBC 能直接说明某款比亚迪车的某个信号定义吗？

    不能。来源说明指出这些是候选的逆向定义，上游 README 的宽泛车型列表不确立逐车型适配，且 byd_all.dbc 的字段多为占位名；要确认某个信号，需要实车抓包核对。

    为什么有两个名字几乎一样的通用 DBC？

    来源说明登记了两份 byd_generic_pt 变体：布局大体重叠，但报文明与信号名被改写成不同写法；它们是同名不同内容，不能互相替代。

    这些文件有开源许可吗？

    来源说明称仓库快照里找不到许可文件，尽管 README 带 MIT 徽章；因此应先确认原作者与再分发权利，仅作私有研究副本使用。

    文件里的报文数加起来代表整车所有报文吗？

    不代表。各文件是不同来源与年份的候选集合，byd_all.dbc 有 124 条、byd_song.dbc 有 89 条、雷达到只有 4 条；它们不是同一辆车的完整报文表。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/yuluoqingcheng-byd-dbc/README.md（主来源：项目自述、车型代号表与调参说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/yuluoqingcheng-byd-dbc/SOURCE.md（快照范围、7 个 DBC 的报文数与许可提示）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • 菲亚特 Grande Punto：29 位 UDS 与 105 个 DID 的读取边界

    结论：在一辆南非市场的菲亚特 Grande Punto（平台 199）1.4 8V（发动机 350A1000，Magneti Marelli IAW 5SF9 发动机 ECU）上，诊断走 29 位标识符、500 kbps 的 C-CAN，应用层是 UDS（ISO 14229），传输层是 ISO 15765-2，采用常规固定寻址（请求 18DAxxF1、应答 18DAF1xx）。这台车最关键的一条工程特性是：发动机 ECU 只接受不填充的帧，数据长度必须等于真实长度，这正是自动协议搜索与多数通用 OBD 应用连不上的原因；标准 OBD-II（模式 01 至 0A）也不应答，属非 EOBD 合规。边界：全部结论出自这一辆车与这份只读研究，不能套到其他校准或车型。

    本文整理自该项目的协议文档与示例结果。文档把每条记录分为「Observed（本车读出）」与「Published（取自公开来源、未在本车确认）」，本文保留这一区分。

    车辆与适用范围

    数据来自一位研究者的这一辆 Grande Punto，用一款 ELM327 兼容蓝牙适配器加一台 Linux 主机接入。工作方式偏保守：先适配器自身，再被动监听，然后标准请求，最后才是有寻址的厂家请求；并且全程只读，不发送清除、写入、执行器测试、安全访问或编程会话。

    项 内容
    车型 菲亚特 Grande Punto（平台 199）1.4 8V，发动机 350A1000，南非市场
    年款 / 市场版本 源文档未给出具体年款；市场为南非
    ECU / 改装状态 发动机 ECU：Magneti Marelli IAW 5SF9，名称 5SF9AG，硬件 IAW5SFHW405，软件 881AW23E，Fiat 件号 51926690
    采集跨度 若干次只读会话；一次怠速分析含 6 段共 5995 帧
    适用范围 仅这一辆车与这一套校准；不得假设其他校准或车型相同

    总线与寻址

    物理层是 OBD 引脚 6 / 14 上的 C-CAN，500 kbps，29 位标识符；传输层为 ISO 15765-2 常规固定寻址（请求 18DA + 目标 + F1，应答 18DAF1 + 目标）。本车一大特性是不能填充，数据长度须等于真实长度；流控帧为三字节 30 00 00，须在首帧后数毫秒内跟上。

    项 内容
    物理层 C-CAN，OBD 引脚 6 / 14，500 kbps
    链路层 29 位标识符；ISO 15765-2（ISO-TP）常规固定寻址
    寻址 请求 18DA + 目标 + F1；应答 18DAF1 + 目标
    帧填充 发动机 ECU 不接受填充，数据长度须等于真实长度
    流控 30 00 00 三字节，须在首帧后数毫秒内
    应用协议 UDS（ISO 14229）；标准 OBD-II 模式 01 至 0A 不应答

    已解码信号

    下表混合数据标识符（DID）与广播帧字段两类。证据一列沿用文档口径：「本车读出」为在本车实测，「公开来源」为取自 Fiat 500 等同平台资料、未在本车独立确认。文档还提示：公开定义里发动机转速位偏移比本车实际晚一个字节，公开偏移应视为起点。

    信号 位置（DID / 帧） 解码 证据
    发动机转速 DID 1000 原始值 ÷ 4，转/分 本车读出；与广播 0618A001 交叉核对
    冷却液温度 DID 1003 原始值 − 40，摄氏度 跟随广播 0A18A001 字节 3；偏移为假设
    电池电压 DID 1004 原始值 ÷ 10，伏 本车读出；与适配器电压表一致
    运行计数 DID 1008 运行时约每分钟 +1，可能是分钟计 本车读出
    启动后计时 DID 1009 约每 15 秒 +1，单位未知 本车读出（刚启动后读数为 1）
    目标怠速 DID 186B 原始值 ÷ 4，转/分（700；开空调 850） 本车读出；转速 1000 随后一拍跟随
    大气压 DID 1956 毫巴 可能（静止且数值符合海拔）
    进气歧管压力 DID 181F 毫巴 可能（随负荷变化）
    电池电压（第二路） DID 197D、197E 原始值 ÷ 10，伏 本车读出；与 1004 一致
    氧传感器电压 DID 1898、189A 毫伏（在稀 / 浓之间摆动） 可能
    发动机转速（广播） 帧 0618A001 字节 2-3（大端） 1 转/分/位；字节 7 为油门踏板 转速与 1000 一致；踏板为公开来源
    冷却液温度（广播） 帧 0A18A001 字节 3 原始值 − 40，摄氏度 跟随 1003；比例为公开来源
    节气门位置（广播） 帧 0628A001 字节 4 怠速时 4 至 7 个计数 公开来源
    备件号 DID F187 文本 51926690 本车读出

    读取方法与注意事项

    先做被动监听。先静默监听确认总线活着，再用最简请求（TesterPresent）扫地址。这台车上，3E 00 得到干净的 7E 00，证明它讲 UDS；而 1A 80 得到 7F 1A 11（服务不支持），说明它不讲 KWP2000。否定应答也是成功，因为它证明寻址与帧格式是对的。

    不填充与流控交给适配器。关键一步是关闭格式化（ATCAF0）并启用可变数据长度（ATV1），由自己写 ISO-TP 长度字节。长应答以首帧发出后需流控；经蓝牙往返太慢时发动机 ECU 会放弃，故让适配器自行发送三字节流控。

    读取成本要知道。一次遍历 105 个标识符约需 14.4 秒，因此比这更快的信号都会被欠采样；模块地址扫描（256 个）约 54 秒，整个 16 位空间约需 3.6 小时。

    只读边界。文档强调这是只读研究：写入、清除、例行程序、安全访问与复位服务从未发送。本文同样不涉及安全访问绕过；源文档未提供此类方法，也不建议尝试。

    证据等级与边界

    文档用「Observed」标记本车读出，用「Published」标记取自 Fiat 500 等同平台资料、未在本车独立确认的内容。因此表中带「公开来源」「可能」「假设」字样的条目尚未在本车成立。

    识别侧证据较硬：F187 备件号、F192 供应商硬件号、F194 供应商软件号、F196 ECU 名称都能读出；发动机 ECU 的 VIN 字段（F190）为空，VIN 由地址 40 的车身电脑返回。应答模块只有四个：10 发动机、28 ABS、30 电动助力转向、40 车身电脑，其余全静默。

    来源说明把范围写得很清楚：只有这一辆南非市场的 Grande Punto 1.4 8V，不要假设其他校准或车型布局相同；这是「诊断 / 信号研究集合，而非 DBC」。据此，本文的 DID 含义、比例与广播偏移不能外推到其他 Grande Punto 或其他 Fiat 车型。

    常见问题

    为什么通用 OBD-II 读不到这台车？

    因为这台发动机 ECU 非 EOBD 合规，标准 OBD-II 模式 01 至 0A 在任何协议上都不应答；加上它只接受不填充的帧，自动协议搜索与多数通用应用都会失败。作者改用 29 位寻址加不填充帧后才得到首个应答（还是否定的 7F 1A 11）。

    为什么这台车要求帧不填充？

    文档实测：发动机 ECU 只接受数据长度等于真实长度的帧，填充帧得不到应答。ISO 15765 允许填充，多数 ECU 两种都收，但这台不收——文档指出，正是这一个细节让自动检测与通用应用全部失败。

    用服务 22 读 DID 需要先进入扩展会话吗？

    不需要。文档记录 22 xxxx（ReadDataByIdentifier）在默认会话即可工作，且进入扩展会话（10 03）并未解锁测试范围内的额外标识符。

    为什么用掩码 FF 读故障码会返回 27 条？

    因为掩码 FF 返回的是 ECU 能够 设置的记录、状态为 40（本周期未完成测试），那是监控项清单而非故障清单。文档建议用具体掩码：08 读已确认、04 读待定、01 读当前正在发生。

    这些 DID 能套到别的 Grande Punto 吗？

    不能。来源说明写明只有这一辆南非市场的 1.4 8V 车，且这是一个研究集合而非 DBC；不同校准或车型的布局可能不同，需逐车复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/ryancoxrbc-fiat-grande-punto/docs/protocol.md（本项目车型档案主来源，取用了物理层 / 传输层、DID 表与广播帧表）。
    • 项目 01 —— public-can-dbc-datasets/additional/ryancoxrbc-fiat-grande-punto/docs/example-results.md（取用了怠速捕获统计与读取耗时）。
    • 项目 01 —— public-can-dbc-datasets/additional/ryancoxrbc-fiat-grande-punto/SOURCE.md（取用了「仅此一辆车、研究集合而非 DBC」的边界说明）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

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

  • 大型 ADAS 代码库怎么读：四步阅读顺序与三类边界

    结论：读一个大型 ADAS 代码库，正确顺序不是从目录名或进程启动顺序开始，而是按职责与信任边界组织：先分清运行底座、输入感知、状态估计、车辆接入、决策执行、旁路验证六大块，再沿「车况从 CAN 进来到控制从 CAN 出去」这条链逐层追。本文给出一条可复用的四步阅读顺序——从进程与消息契约出发，追车况解析、追使能状态机、追候选发送与板端安全钩子——并强调三类不能混同的边界。源代码根提交为 c8fb906，归档缺少模型权重实体，以下为静态分析，不代表构建通过或实车验证。

    按职责与信任边界看，而不是按目录名

    这个代码库的关键结构不是「哪个目录属于哪个功能」，而是各部分所处的信任层级。可以用一张源码目录地图定位：

    目录 在系统中的位置 主要产物或边界
    系统与平台目录 设备与运行平台 进程管理、相机与传感器采集、记录、设备状态与远程服务
    消息契约与传输 数据契约与传输 日志结构定义、服务频率定义、跨进程消息队列与图像缓冲
    共享运行时 共享基础 参数持久化、时间与调度、日志、设备抽象与版本信息
    视觉推理目录 视觉推理 道路与驾驶员模型输入处理与推理输出；模型权重属于缺失的实体
    定位与监控目录 状态估计 定位、标定、车辆参数学习与驾驶员注意力策略
    车辆 I/O 目录 主机侧车辆 I/O 车况标准化、候选发送帧生成、与安全板通信
    决策与控制目录 决策与执行请求 雷达融合、纵向规划、控制器与使能告警状态机
    车型协议与安全目录 车型协议与独立安全边界 DBC、车型状态与控制、safety 规则；安全 MCU 执行收发与发送限制
    开发验证目录 开发验证 回放、仿真、CAN 分析与诊断，不属于车上实时控制路径

    要特别记住一点：安全板固件、车型协议、跨进程通信与推理运行时分别位于不同的源码归档，不要把它们误认为同一个可热插拔模块。这条边界决定了后面所有替换与移植工作的可行性。

    对照这张地图时，一个实用判断是看某模块是否参与了实时控制路径：属于开发验证的部分不应成为车上的必要依赖，而安全相关部分则必须与车型、总线与固件联合版本化。

    四步阅读顺序

    公开资料给出了一条从函数追到消息的阅读顺序，可以照此执行：

    1. 从进程配置与进程管理函数找到运行进程，再对照服务频率定义与日志结构定义的主题字段；
    2. 从车况更新函数追车型接口更新、车型状态与雷达轨迹，再追模型输出、雷达状态、纵向计划的生产者；
    3. 从事件汇总与状态机更新的函数追使能 / 退出条件，再看控制器如何生成执行请求；
    4. 从车型编码函数追车型控制器的更新、候选发送帧、主机到板传输与板端安全钩子；任何可替换模块都不能跨越最后一层安全门。

    顺序的关键在最后一步：候选发送帧在到达总线之前，必须经过安全 MCU 的独立检查。也就是说，主机侧插件、车型控制器和配置项都不能替代板端规则。

    这四步的意义在于把「消息契约」放在第一位：先知道有哪些主题、频率与字段，再去看谁生产它们。否则很容易在某个子目录里困住，却不知道它在闭环中的位置。追控制链时，建议始终回到「车况进来、控制出去」这两条主线上做交叉验证。

    运行阶段与消息速查

    下表按理解闭环的顺序排列，不是全局同步调用栈。进程各自运行，消息的发布、接收与板端执行发生在不同时间，表内的「输出」也不等于车辆已经执行：

    阶段 主要输入与产出 硬件或插件边界
    设备与进程 板 / 电源 / 温度等状态形成设备启动状态，进程管理据此增减受管进程 新平台必须先可靠报告点火、热状态和电源；进程启动不代表传感器健康
    物理采集 相机图像进入模型；CAN 经车型解析形成车况与雷达轨迹 帧时间、坐标系、CAN 来源总线及采样年龄必须随适配器一起验收
    观测发布 分别发布模型输出、相机里程计、车况与雷达轨迹 同一发布周期内的多个主题也可能有不同有效条件
    融合与规划 雷达轨迹与模型输出形成雷达状态；模型更新触发纵向计划 规划插件须声明输入时间轴、有效性和输出期限；计划存在不等于控制获准
    使能与控制 事件产生使能状态；控制器综合车况、模型和计划发布控制请求 使能、横向、纵向是不同权限；控制请求的 valid 不是最终硬阻断
    车型编码 控制请求经车型转换成为候选发送帧 主分支检查控制请求存活，不统一检查其有效位
    主机到 MCU 主机按消息年龄发送候选帧，另维护板状态与心跳 消息年龄门和心跳不是逐帧安全授权
    板端安全 按安全模式、发送白名单、车型钩子及故障决定是否接受候选帧 车型 / DBC / 安全参数 / 固件必须联合版本化

    建议先用只读 CAN 与图像采集验证前四阶段，再以离线回放验证控制请求，最后独立验证网关与 MCU 的拒帧、超时及故障退化。

    三类边界：输入、能力与验证

    从源码职责推导，面向自制硬件与插件重构有三条边界，对应四类插件：

    插件类型 可定义的契约 不可交给插件自我授权的部分
    传感器 / 感知 时间戳、坐标系、健康状态和标准消息输出 无效或过期输入继续参与控制的许可
    车型适配 指纹、DBC、车况与控制帧、受控总线清单 安全模式、发送白名单、驾驶员覆盖规则
    规划 / 控制 标准模型 / 雷达 / 控制契约及回放等价性 无条件接管发送或绕过使能状态机
    记录 / UI / 远程 只读订阅、存储和远程诊断能力 将远程命令直接转为车辆控制权限

    第一条边界是物理输入与安全发送：车型、总线、线束、摄像头时间戳以及安全板配置必须版本绑定。第二条是算法与辅助能力：感知、定位、日志和 UI 可以探索可替换接口，但控制相关组件不能仅凭「插件已安装」取得发送权。第三条是验证：先只读采集、进程回放和故障注入，再做台架与受控场地测试；这类文档不是接线图或上车许可。

    常见问题

    能不能只看目录名理解这套代码？

    不建议。应优先按职责与信任边界组织：安全板固件、车型协议、跨进程通信和推理运行时分别位于不同源码归档，按目录名会被误导。可用文中的目录地图定位各部分所处层级。

    控制请求发出去了就等于车辆执行了吗？

    不等于。候选发送帧在到达总线前还要经过安全 MCU 的独立检查；主机侧的消息年龄门和心跳也不是逐帧安全授权。文中所有表中的「输出」都不等于车辆已经执行。

    使能、横向、纵向是同一个开关吗？

    不是。公开资料特别指出它们是不同权限，且控制请求的 valid 不是最终硬阻断。判断能否执行应回到使能状态机与板端安全规则，而不是单一布尔值。

    这份分析能作为上车依据吗？

    不能。归档缺少模型权重实体，本文为静态源码分析，不代表构建通过或实车验证；它不是接线图或上车许可，任何执行能力都需要台架与受控场地另行验证。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/ARCHITECTURE_GUIDE_CN.md（取用源码目录地图、四步阅读顺序、运行阶段与消息速查、三类边界与插件类型表）。

    说明：本文为对固定源码快照（根提交 c8fb906）的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有入口、阶段与边界均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

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