星核火花赛车科技

标签： DBC

  • opendbc 车型校验算法族：同名 CRC8 不可替换，RX/TX 共用函数

    结论：opendbc 的车型校验不是「一种 CRC8 走天下」，而是按品牌/平台硬绑定的一族函数：Honda 用半字节补码、Toyota 把帧长本身算进和、Chrysler 用 CRC8 J1850（初值与末异或均为 0xFF）、Hyundai CAN FD 用 CRC16 XMODEM、VW MQB/MEB 用 CRC8 H2F 再追加地址常量。同名「CRC8」只代表多项式查找表相同，地址、帧长、字节顺序与最终 XOR 各不相同，不构成车型间可替换的插件接口。更关键的是，RX 校验与 TX 生成共用同一个函数，任何「只改发送端」的假设都必须重新核对。

    每个校验函数都写死了覆盖字节与校验位位置

    在固定源码快照里，get_checksum_state() 按 DBC 名称与信号名把每帧绑定到一个具体函数。所谓「算法」其实由四件事共同决定：哪些字节进入计算、校验字段在哪个字节或半字节、初始值与末异或是什么、帧长是否参与。源文档明确指出，帧长度和字段位置本身就是协议的一部分，不能当作可省略的装载细节。

    下面的函数目录来自源文档的逐函数静态核对。注意「参与计算的内容」一列——同一种「CRC8」在 Chrysler、VW、body 三处覆盖的字节范围完全不同。

    家族 / 函数 实际参与计算的内容 重要前提
    honda_checksum() 地址各半字节、每个载荷字节的高低半字节；末字节仅取高半字节，结果为 8 - sum，扩展 ID 再加 3，截 4 位。 假定校验位在最后字节低半字节；扩展地址判据是 address > 0x7FF。
    toyota_checksum() len(d)、地址各字节和除最后一字节外的载荷字节，相加截 8 位。 假定校验在末字节，帧长本身参与计算。
    subaru_checksum() 地址各字节与除第一字节外的载荷，相加截 8 位。 Global 版本校验位默认在首字节；和 pre-global 手动辅助函数不是同一算法。
    chrysler_checksum() 对末字节以外数据查 CRC8 J1850 表，初值和末异或均为 0xFF。 不把地址计入此函数；checksum 按末字节处理。
    fca_giorgio_checksum() 同表、初值 0，末异或按地址 0xDE/0x106/0x122/其他 分别为 0x10/0xF6/0xF1/0x0A。 未识别地址落入通用 0x0A 分支；不能把四组样本扩大为所有 FCA 报文。
    hkg_can_fd_checksum() 从第 2 字节到末尾做 CRC16 XMODEM，再加入地址低、高字节；仅 8/16/24/32 字节追加特定末异或常量。 前两字节视作校验字段；其它长度不加表中常量，但函数自身不会拒绝。
    volkswagen_mqb_meb_checksum() 初值 0xFF，对第 1 字节起载荷做 CRC8 H2F；已知地址再按第二字节低半字节选 16 项常量追加一步，最终异或 0xFF。 首字节为校验位；未在常量表中的地址跳过附加常量步骤。
    tesla_checksum() 地址低、高字节加上除 checksum 字节外的所有载荷，截 8 位。 校验位置由 sig.start_bit 决定，不限固定末字节。
    body_checksum() 从倒数第 2 字节向首字节反向迭代做 CRC8 BODY，初值 0xFF。 仅最后一字节不进入计算，函数不检查其字段含义。
    byd_checksum() 前七字节之和按位取反再截 8 位。 固定覆盖前七字节；不是通用「跳过任意校验字段」的算法。
    psa_checksum() 地址选择 4 位初值，先在传入 bytearray 中清除校验半字节，再把全帧高低半字节求和，从初值中减去并截 4 位。 函数就地修改传入缓冲；RX 解析器传副本，TX packer 传当前构帧缓冲。

    CRC8H2F、CRC8J1850、CRC8BODY、CRC16_XMODEM 只是按多项式生成的查找表。查找表可以共享，但函数外层的地址、帧长、字节顺序和最终 XOR 无法共享，这正是「同名不同义」的根源。

    RX 校验与 TX 生成共用同一个函数

    源文档反复强调一个契约：RX 验证和 TX 生成走的是同一份实现，而不是「接收一套、发送另一套」。这带来两个直接后果。第一，校验位的位置往往由信号元数据决定，例如 tesla_checksum() 的校验位置由 sig.start_bit 决定，并非固定在末字节。第二，某些函数带有副作用，例如 psa_checksum() 会就地清除并回写传入缓冲里的校验半字节。

    副作用的差别决定了移植风险：接收解析器传入的是 bytearray(dat) 副本，因此就地修改不影响原始帧；而发送打包器传入的是当前工作缓冲。把这类函数当成无副作用纯函数重用，会直接改变构帧结果。同时，VW MLB 的 XOR 变体以 sig.start_bit // 8 定位整字节，说明「校验在哪个字节」不是全局常量，而是逐信号给定的。

    按「接收帧已有校验字节」选择变体，而不是按算法优劣

    VW MEB 提供了一个容易被误读的变体函数 volkswagen_meb_alt_crc_checksum()：它对备用表内六个地址先按指定长度算另一组 CRC，只有候选值等于输入 d[0] 时才返回，否则退回标准 MQB/MEB CRC。这个语义是按接收帧里已经带着的校验字节来「认领」变体，并不代表发送端会主动优先采用备用值。

    源文档用三个隔离探针把边界固定下来，结果如下表。它们都使用原版函数与真实查找表，但只在纯函数层面运行，未加载完整车型 DBC、未发 CAN、未测 ECU。

    探针 输入 观察结果 结论边界
    MEB 双 CRC 选择 地址 0x0DB、64 字节零缓冲 备用长度 42，备用结果 0xEB、标准结果 0xED；d[0]=0 时选 0xED，改成 0xEB 时才选 0xEB CANPacker.pack() 默认从零缓冲开始，故不能凭接收端可识别备用 CRC 就推断发送端会按备用算法生成
    Hyundai 长度分支 长度 8/12/16/24/32 的全零缓冲 各长度均给出结果；12 字节路径不会被拒绝，只是不使用四种已列长度常量 仅验证函数分支，不代表 12 字节是该平台合法帧长
    PSA 就地修改 0x452、start_bit=0、输入 AB CD 返回校验半字节 1，同时把首字节原地改为 A0 移植时不能把该函数当无副作用纯函数

    把这几条合起来看：一个「接收端能认」的校验并不自动意味着「发送端会这么写」。当前实际发送函数是否涉及 MEB 那六个地址，需要按车型另做核对，本篇探针不说明已有车型发生过错误发送。

    「跳过校验字节」不是通用能力

    Subaru 有两个函数常被混为一谈：subaru_checksum() 是 Global 版本，校验位默认在首字节；subaru_preglobal_checksum() 则先用 packer 生成字节，再对除 checksum_byte 指定字节（默认第 7 字节）外的字节求和。后者由 pre-global 构帧函数显式填写 Checksum，不由 DBC.get_checksum_state() 自动绑定。同理，byd_checksum() 固定覆盖前七字节，也是一种特定布局，而不是「跳过任意校验字段」的通用规则。

    这些差异说明：校验算法必须和 DBC 名称、报文地址、DLC、校验字段位位置、覆盖字节范围、counter 位置一起版本化。只声明「用了 CRC8」在车型之间没有任何可迁移性。

    给协议插件的验收底线

    新车型的协议插件应把下列字段作为一个整体来管理和验收，缺一项都可能造成接收能过、发送写错，或反之。

    必须版本化的字段 为什么不能省
    DBC 名称、报文地址、DLC 决定帧长与字段位置，帧长本身参与部分算法（如 Toyota）。
    校验字段位位置、覆盖字节范围 Tesla 由 sig.start_bit 决定、Honda 在低半字节，不能固定假定末字节。
    counter 位置 与 checksum 同级参与健康判定，不能只看数值。
    CRC 多项式 / 初值 / 末异或 Chrysler 与 FCA Giorgio 同表不同初值与末异或。0x10/0xF6/0xF1/0x0A
    长度变体与 RX/TX 选择规则 MEB 备用 CRC 只在匹配接收字节时启用；Hyundai 只在 8/16/24/32 追加常量。

    测试层面，应在参考载荷上直接比对计算值与输出字节，并确认解析器确实接受本帧；还要覆盖坏 checksum、截短/超长帧、counter 回绕与未知地址。需要提醒的是，checksum 只检测某类传输错误，不提供发送身份认证，也不构成执行器安全约束——这些仍由可信的车型逻辑、panda safety 和物理台架验收承担。

    常见问题

    为什么同为「CRC8」，不同车型的校验函数不能互相替换？

    因为查找表相同不代表算法相同。Chrysler 用 CRC8 J1850 且初值与末异或均为 0xFF，VW MQB/MEB 用 CRC8 H2F、初值 0xFF 并追加地址常量，body 则从倒数第二字节反向迭代。地址、帧长、字节顺序和最终 XOR 各不相同，源文档明确指出相同「CRC8」名称不构成车型间可替换的插件接口。

    接收端能校验通过的备用 CRC，发送端也会照此生成吗？

    不会自动如此。MEB 备用函数只有候选值等于输入 d[0] 时才返回，否则退回标准 CRC，这是「按接收帧已有校验字节选择变体」的语义；而 CANPacker.pack() 默认从零缓冲开始，不会凭接收可识别就优先采用备用值。当前发送函数是否涉及那六个地址需按车型另核。

    PSA 校验函数可以直接当纯函数复用吗？

    不可以。源文档探针显示，psa_checksum() 对 0x452、start_bit=0、输入 AB CD 返回校验半字节 1 的同时，把首字节原地改成了 A0。接收解析器传的是副本，发送打包器传的是原始工作缓冲，移植时必须区分。

    checksum 通过是否等于报文安全可信？

    不等于。checksum 只检测某类传输错误，不提供发送身份认证或执行器安全约束。源文档明确这些仍由可信的车型逻辑、panda safety 和物理台架验收承担，并且本专题没有实板证据。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/OPENDBC_CHECKSUM_ALGORITHM_FAMILY_RX_TX_CONTRACT_DEEP_DIVE.md（取用了校验函数目录、RX/TX 共用函数的语义、三个隔离探针结果与插件验收字段清单）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

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

  • Fisker Ocean 2023-24 的 ADASBUS：单总线取数与 92 个地址

    结论：这台 Fisker Ocean 2023-24 的 CAN 数据特征不是「OBD 口后面有没有网关」，而是整车信号被网关镜像到一条 ADASBUS 上：只需要接一条 CAN-FD 总线就能读到车身与 HMI 信号。源文档记录，panda 以摄像头转接线束插在原车网关侧（bus 0）与 OEM ADAS 模块侧（bus 2）之间，bus 1 未使用；bus 0 一次实车指纹抓取到 92 个地址（网关镜像的车身/HMI 加上 ESP、EPS、YRS、BCM、VCU、MFS、ICC），bus 2 约 65 个地址且全部由 ADAS 发出。下述结论仅限源文档记录的这一台车与 2023-24 年款，不代表同型号全系。

    车辆与适用范围

    源文档是一份开源 ADAS 项目里的车型平台定义，属于单车型移植（single-model port），不是车厂或第三方机构的批量采集。文档明确说明固件版本指纹被故意留空，识别以 CAN 指纹为准，因此「适配到哪一台车」由这一次实车抓包决定。

    项 内容
    车型 Fisker Ocean 2023-24（源文档记为 Ocean Extreme 整备质量口径）
    年款 / 市场版本 2023-24；市场版本源文档未确认
    ECU / 改装状态 摄像头转接线束（camera-splice harness）；panda 接在车辆侧网关与 OEM ADAS 模块之间；bus 1 未使用
    采集跨度 源文档只写「来自一次实车指纹抓取（live fingerprint capture）」，未给出日志数或帧数
    适用范围 仅限该次抓取的一台 2023-24 Ocean；轴距、方向盘比、轮胎刚度等车辆模型参数仍标注为待阶跃响应日志复核

    总线与寻址

    源文档把总线分成两侧：车辆侧（bus 0）与 OEM ADAS 模块侧（bus 2）。因为网关把车身/HMI 信号镜像到同一条总线上，移植只需要接一条总线；bus 1 在代码里被标为未使用。报文 ID 都是 11 位，ADAS 侧除固定报文外还有一段雷达目标列表。

    项 内容
    物理层 CAN-FD 双绞线；源文档注明 ADASBUS 为 CAN-FD
    链路层 / 比特率 源文档未给出比特率数值
    寻址方式 11 位 ID，例如 0x117、0x118、0x121、0x1C0、0x1D0、0x313、0x314、0x315、0x316、0x317、0x31A、0x31C
    总线划分 bus 0 = 车辆侧（网关镜像）；bus 2 = OEM ADAS 模块侧；bus 1 未使用
    CAN FD 是；源文档按 CAN-FD 处理
    SecOC 0x1D0 与 0x121 受 SecOC 保护；同步报文 0x20 GW_Syn_All，50 ms，线上 40 位 freshness

    已解码信号

    下表只登记源文档里带证据或明确标注状态的条目。挡位枚举与按键映射直接来自平台定义中的 DBC 值表与按键映射表；转向与加速度指令给出缩放与周期，但周期条目原文标注为「需从日志确认」。雷达目标只给 ID 区间，未给字段定义。

    信号 / 功能 位置（ID / 来源） 解码 证据
    挡位 VCU_GearSig 网关镜像到 bus 0 的 VCU 报文 枚举 1=P、2=N、3=R、4=D、6=E、7=S 平台定义 DBC VAL_ 注释
    转向角指令 ADAS_LatCtrl_SteerAnReq 0x1D0（ADAS 侧） 0.0625°/LSB，量程 ±780°；周期 10 ms（≈100 Hz），原文标注需从日志确认 平台定义注释
    加速度指令 ADAS_LgtCtrl_AccelReq 0x121 0.0004882 m/s²/LSB，偏移 −16 平台定义注释
    驾驶员转向力矩 EPS_DrvrSteerTq 网关镜像的 EPS 报文 0.01 Nm/LSB；驾驶员接管阈值 0.5 Nm 平台定义注释
    巡航主开关 MFS_RiBtnNorth MFS（方向盘多功能开关） 映射为 mainCruise（ADAS 总开关） 按键映射表
    巡航设定 MFS_LeRollPress MFS 映射为 setCruise（接合巡航） 按键映射表
    加速 / 减速 MFS_LeRollUp、MFS_LeRollDwn MFS 映射为 accelCruise / decelCruise 按键映射表
    LKAS 开关 MFS_RiBtnSouth MFS 映射为 lkas 按键映射表
    取消 / 恢复 / 车距调节按键 MFS 源文档标注为 TBD（待台架测试确定） 按键映射表注记
    雷达目标列表 0x2C7…0x2E9（ADAS 侧） 源文档只给 ID 区间，未给字段定义 总线说明
    网关镜像的车身/HMI 信号 bus 0 挡位、踏板、车门、安全带、转向灯、MFS 按键 总线说明

    读取方法与注意事项

    第一条是取数路径：因为网关把车身/HMI 信号镜像到 ADASBUS，移植只接一条总线，摄像头转接线束让 panda 落在车辆侧网关与 OEM ADAS 模块之间。源文档强调 bus 1 未使用，因此不要把抓不到流量归因于「少接了一条线」。

    第二条是 SecOC：转向角指令与加速度指令在 ADAS 侧受 SecOC 保护，需要同步报文 0x20 GW_Syn_All 提供的 40 位 freshness，同步报文周期 50 ms。源文档说明这些数据 ID 在 AUTOSAR Short SecOC 口径下等于 CAN 报文 ID。任何只解析载荷、不做 freshness 校验的读取方式，都拿不到可信的指令值。

    第三条是周期：0x1D0 每个控制帧都发送，源文档把周期记为 10 ms（≈100 Hz），但同一行原文写了「需从日志确认周期」，因此本条保留不确定性，不作为实测结论。第四是识别：固件版本指纹被故意留空，品牌不参与固件版本匹配，CAN 指纹是唯一依据。

    最后是车辆模型参数：轴距按公布数据从 2.99 改成 2.921（源文档给出理由：原值让横向模型预期更慢的入弯、导致 MPC 在弯道入口过度指令转角），steerRatio 15.0 记为「first-cut」，tireStiffnessFactor 0.85 记为「crossover-typical」。这些都属待复核值，不应作为 Fisker Ocean 的通用参数。

    证据等级与边界

    可视为实车观测的是总线地址数量（bus 0 约 92 个、bus 2 约 65 个）与两侧总线的分工，它们来自一次实车指纹抓取；挡位枚举和按键映射来自 DBC 值表与映射表，属文档级证据。属于待复核或推测的是转向角周期、steerRatio、tireStiffnessFactor，以及取消/恢复/车距调节三个按键。

    不能外推的地方有三处。第一，源文档是单车型移植，固件指纹为空，挡位与按键映射只在这台车上被记录，其他年款、市场版本的报文布局未验证。第二，雷达目标列表只给了 ID 区间，字段含义未知，不能据此宣称读到了目标距离或速度。第三，车辆模型参数是工程首值，不是实测标定，换车即失效。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档登记的广播信号与指令定义，不涉及对车辆安全机制的规避。

    常见问题

    Fisker Ocean 是从 OBD 口取数，还是接别的总线？

    源文档没有走 OBD 诊断口，而是接 ADASBUS：panda 以摄像头转接线束落在车辆侧网关（bus 0）与 OEM ADAS 模块（bus 2）之间。OBD 口在本车是否可读这些报文，源文档未给出结论，因此不能据此推断。

    为什么只需要接一条 CAN 总线？

    因为网关把车身/HMI 信号（挡位、踏板、车门、安全带、转向灯、MFS 按键）镜像到 ADASBUS 上，源文档说明移植只接一条总线即可；bus 1 未使用。

    转向角和加速度指令为什么不只解载荷？

    因为 0x1D0 与 0x121 受 SecOC 保护。源文档说明需要同步报文 0x20 GW_Syn_All（50 ms、40 位 freshness）才能得到可信指令值，只解析载荷不做 freshness 校验拿不到可信值。

    挡位信号在哪条总线上？

    挡位来自网关镜像到 bus 0 的 VCU 报文，源文档的 DBC 值表给出 1=P、2=N、3=R、4=D、6=E、7=S 的枚举。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/jos-technion-fisker-ocean/README.md（主来源：该项目保留的开源 ADAS 项目根文档）。
    • 项目 01 —— public-can-dbc-datasets/additional/jos-technion-fisker-ocean/opendbc/car/fisker/values.py（平台常量、总线划分、挡位与按键映射、SecOC 说明）。

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

    更新记录

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

  • 丰田 RAV4 TSS2 雷达 ARS510：0x80 对象列表与 0x85 元数据

    结论：在一辆车主自有的 2022 款丰田 RAV4（TSS2，前向雷达固件 8821F0R03100，雷达在 0x750/0x0f）上，ARS510 前向毫米波雷达的对象列表是可以被动解码的广播数据：它走雷达总线，以 0x80 分 106 帧拼成一条 742 字节记录，每个对象槽 36 字节，直接给出纵向距离、横向偏移、对地速度、车道权重和类别。这个结论只覆盖这一辆车这一次固件记录——文档明确把「字段比例与零点」标为名义值、多处置信度存疑，不能外推到 RAV4 其他年款或其他雷达固件。

    本文整理自一份针对这台车雷达的开源解码与集成文档。该文档把「原始解码」「物理量校准」「实车结论」分层标注，本文保留这套分级，不将其拔高为「RAV4 全系通用」。

    车辆与适用范围

    数据来自一位车主的一辆 2022 RAV4，用 openpilot 记录。文档给出的证据结构是：3 段参考行程（开发、城市、高速，共 88 分钟）带摄像头与里程计参照；24 段行程中的 399 个一分钟片段用于字段统计；20 段留出行程（4.6 小时）做回放对照；6 段新行程（1.9 小时）与多套分支上的闭环路测。

    项 内容
    车型 丰田 RAV4（TSS2，对应 openpilot 的 2022 / 2023 平台标识）
    年款 / 市场版本 2022（源文档未给出销售市场，也未确认具体配置）
    ECU / 改装状态 前向雷达固件 8821F0R03100；由 openpilot 采集，非量产改装
    采集跨度 3 段参考 88 分钟 + 399 个一分钟片段（来自 24 段行程）+ 20 段留出 4.6 小时
    适用范围 仅这一辆车的雷达与这一次固件；比例与零点多为名义值

    总线与寻址

    文档按 openpilot 的总线编号描述器件：雷达本身与其 ACC 目标帧在 bus 1，车速来自 bus 0 的车体帧 0xB4。对象列表在 bus 1 的 0x80，以 106 帧拼成一条 742 字节记录：头部、20 个 36 字节对象槽、一个 CRC32。雷达周期约 60 毫秒，解码后以约 16.7 Hz 输出对象点。

    文档没有描述这台车的 OBD 口之后是否存在网关，也没有给出 11 位 / 29 位寻址或 CAN FD 的结论——这几项属于源文档未覆盖的范围，本文不补。

    项 内容
    物理层 车用 CAN，分为雷达总线（bus 1）与车体总线（bus 0）
    链路层 对象列表 0x80 分帧传输（106 帧 → 742 字节记录）
    寻址 源文档未给出 11 位 / 29 位结论
    CAN FD 源文档未提及
    记录完整性 CRC32/ISO-HDLC（小端）覆盖记录第 1 至 140 字节

    已解码信号

    下表从源文档的对象槽与 0x85 元数据记录中抽取代表性字段。置信度沿用文档符号：● 已确认、◐ 可能、○ 候选。位宽写法如 32|12 表示起始位 32、宽 12 位。

    信号 位置（ID / 位域） 解码 证据
    dRel（纵向距） 0x80 槽 32|12 (code − 160) / 16 米 ● 字段布局确认；零点与比例见准确度文档
    yRel（左为正横向偏移） 0x80 槽 44|12 (code − 2048) / 64 米 ● 同上，比例标称 ±10%
    对地速度 0x80 槽 64|10 (code − 510.5) × 0.15 米/秒；相对速度 = 该值 − 自车速度 ● 运动解释确认
    age（航迹年龄） 0x80 槽 24|7 雷达周期数；重启即视为新航迹 ●
    车道权重（右 / 左 / 自车） 0x80 槽 148|4、152|4、156|4 0–15，三者之和为 15 或 16 ●
    类别 class 0x80 槽 163|3 1 新建、2 车、3 大型车、4 行人、5 暂定、6 两轮车 ●；5 为 ○ 候选
    ACC 目标 0x235 / 0x237，50 Hz 原始字段 ● 原始字段；◐ 名义单位换算
    目标摘要 0x191–0x194 原始结构 ● 原始结构；◐ 解释，需度量与类别校准
    事件对 0x195 / 0x196 原始载荷；10 位短时距碰撞码领先本车减速 ● 原始载荷；◐ 状态解释
    元数据 c0 偏移 0x85 单元 32|12 (code − 2000) × 0.01 米 ◐ 比例约 ±10%
    元数据 c1 航向 0x85 单元 48|16 −1.8e-5 × (code − 31200) 弧度/码，零点 31100–31300 ◐ 符号与零点；单位有界 1.6–2.2e-5
    元数据 c2 曲率 0x85 单元 64|15 +2.5e-6 × (code − 16020) 1/米/码 ◐ 符号与零点；单位有界 2.0–2.7e-6
    元数据 c3 曲率变化率 0x85 单元 10|10 +4e-6 × (code − 500) 1/米²/码 ◐ 符号、零点；单位仅到量级

    读取方法与注意事项

    拼接与校验。0x80 记录按 106 帧重组后，用 CRC32/ISO-HDLC（小端）校验；0x85 记录的 147 字节同样按 21 帧重组成，CRC32 覆盖第 1 至 140 字节。文档报告自带样本与七份完整日志的全部记录均通过校验。

    配对要按计数器，不要按到达时间。0x85 前缀与 0x80 头部共享一个时钟和记录计数器；用「最近的到达时间」配对，约有三分之一的机会会配到相邻周期，因此文档要求按计数器配对，并报告在 28 段行程、446371 组配对中覆盖了超过 99.96% 的 0x80 记录。

    速度外溢是这套解码目前最大的问题。文档记录了一个缺陷：出现 1 至 10 秒的假接近，距离超过 40 米。默认的 anchor 配置用雷达自车 ACC 目标给前车速度加界，并叠加 steady 的护栏与平滑；两者合起来在 20 段留出行程上把硬假刹车从 93 个 tick 降到 48 个 tick，响应时间不变。文档另给出 steady（不含 ACC 目标）与 stock（纯解码，外溢直达规划器）两个配置。

    证据等级与边界

    文档用 ●／◐／○ 三级标注：● 已确认、◐ 可能、○ 候选。所有比例与零点都被写明是名义值。也就是说，「(code − 160) / 16」这类公式是文档给的标称关系，并非经独立测量标定的绝对定标。

    另一层边界在来源：全部统计都出自这位车主这一辆车、这一次雷达固件与这批日志。车道单元的分配、航向与曲率的相关性、以及与摄像头车道线的中位误差，都只在记录范围内成立；据此，任何字段含义与比例都不能外推到其他 RAV4、其他年款或其他固件版本。

    常见问题

    这辆 RAV4 的雷达对象列表，能从 OBD 口直接读吗？

    源文档没有涉及 OBD 口这一层，它只按 openpilot 的总线编号给出「雷达在 bus 1、车速在 bus 0」。OBD 口之后是否存在网关、能否直达雷达总线，文档未记录，本文不据此下结论。

    为什么对象列表和 0x85 要按计数器配对，而不是按到达时间？

    因为两条记录的时间戳邻近，用「最近到达时间」配对约有三分之一的机会会配到相邻周期，把不同周期的对象和车道曲线混在一起。文档改用共享的时钟与记录计数器配对，并在 28 段行程、446371 组配对中把覆盖提高到 99.96% 以上。

    文档里说的「速度外溢」是什么，怎么缓解？

    它是这套解码目前最大的已知缺陷：在 1 至 10 秒窗口内出现距离超过 40 米的假接近。默认 anchor 配置用雷达自车 ACC 目标给前车速度加界，叠加 steady 的护栏与平滑，在 20 段留出上把硬假刹车从 93 降到 48 个 tick，响应不变；stock 配置不做过滤，外溢会直达规划器。

    这些字段比例与零点，能套到别的 RAV4 或其他年款吗？

    不能。比例与零点在源文档里都是名义值，全部结论只覆盖这一辆车、这一次固件与这批日志。其他年款、其他雷达固件是否一致，文档未验证。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/toyota-ars510-radar-48b9508/README.md（本项目车型档案主来源，取用了对象列表与总线的总体结论）。
    • 项目 01 —— public-can-dbc-datasets/additional/toyota-ars510-radar-48b9508/docs/04_metadata_record_0x85.md（取用了 0x85 记录的布局、配对规则与车道边界单元字段）。

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

    更新记录

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

  • Mercedes-Benz W212 仪表台：CAN E 状态图与唤醒帧

    结论：2010 款 Mercedes-Benz E350（W212）的组合仪表是一个可以单独上台架的 CAN 节点：20 针连接器里只有 7 针有关，接上 500 kbit/s 的 CAN E 就能点亮。源文档用「试验法」（逐位扫描观察仪表反应）找出了 0x001 的状态编码与唤醒帧，并把 CAN E 的上电状态整理成一张状态图。以下所有结论仅限源文档记录的这一个仪表台。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 W212 E350 组合仪表的台架逆向记录。项目的目标是把这个仪表台用于模拟赛车，因此在台架上重建了它的供电与 CAN 环境，再逐条找出让它显示、点亮的报文。

    项 内容
    车型 Mercedes-Benz E350（W212），2010 年
    对象部件 组合仪表（cluster）；20 针 A1 连接器，其中只有 7 针有关：1 / 4 / 6 为供电，12 / 13 为 CAN E，17 / 18 为 CAN B
    台架硬件 Arduino Mega 2560 加 Seeed CAN-BUS Shield V2.0（MCP2515 控制器）；两个 120 Ω 终端电阻
    台架参数 500 kbit/s；MCP2515 晶振 16 MHz；串口 115200 baud
    适用范围 仅限源文档记录的这个仪表台；不适用于其他年款或其他配置的 W212

    总线与寻址

    因为是「只把一个仪表台搬上台架」，环境被大大简化：没有整车、没有网关，只有仪表自身与台架控制器之间的两条总线。

    项 内容
    总线 CAN E（引脚 12 / 13）、CAN B（引脚 17 / 18）
    速率 500 kbit/s
    终端 两个 120 Ω 电阻
    控制器 MCP2515（经 Arduino Mega 2560 驱动）
    ID 约定 源文档的 DBC 中消息 ID 记为十进制，使用前必须转成十六进制
    状态可读性 仪表上电后自身会发出若干帧（0x015、0x39D），可作为机器可读的状态指示

    已解码信号

    下表从源文档的记录中抽取。项目把已确认的编码与仅来自 DBC 命名、尚未在台架上触发的条目分开，本文原样保留标注。

    信号 位置（ID / DID / 字节） 解码 证据
    CAN E 状态 0x001 B0 枚举：00=OFF、04=Minimal full ON、C2=Limited/ACC-like、CC=Alternate full ON、CF=Delayed OFF、07=过渡候选 已确认（试验法逐位扫描）
    唤醒 0x045 载荷 00 00 00 00 FF 00 00 00 已确认
    OK 按钮 0x045 载荷 00 00 00 00 FF 02 00 00 已确认
    车门状态 0x283 55 = 全关；56 = 左前门开 已确认
    状态指示 A 0x015 3D FE 00 00 与 00 FE 00 00 两种 标定记录
    状态指示 B 0x39D B0 及末字节 B0：80 或 FF；末字节为存活计数器（07, 0F, …, 7F） 标定记录
    驱动控制（DRIVER_CONTROLS） 0x045（DBC 十进制 69） — 标定记录
    点火（IGNITION） 0x245（DBC 十进制 581） — 未确认（静态搜索无响应）
    轮速（WHEEL_SPEEDS） 0x203（DBC 十进制 515） — 标定记录
    安全带（SEATBELT_SENSORS） 0x375（DBC 十进制 885） — 标定记录
    油门（GAS_PEDAL） 0x105（DBC 十进制 261） — 标定记录
    挡杆（GEAR_LEVER） 0x06D（DBC 十进制 109） — 标定记录
    挡位包（GEAR_PACKET） 0x073（DBC 十进制 115） — 标定记录

    读取方法与注意事项

    第一条是接线与终端。20 针连接器里真正有用的是 7 针：1 / 4 / 6 是供电，12 / 13 是 CAN E，17 / 18 是 CAN B。台架上需要接两个 120 Ω 终端电阻，否则总线反射会让通信不稳定。

    第二条是 ID 进制。源文档的 DBC 把消息 ID 记成十进制（如 69、581、515），而 CANID 是十六进制的——所以 DRIVER_CONTROLS 十进制 69 对应 0x045，IGNITION 十进制 581 对应 0x245。解析前必须先做这个换算，否则会对着错误的 ID 收发。

    第三条是「试验法」。项目找编码的方式是逐位扫描 0x001 的字节并观察仪表反应，从而归纳出 ON/OFF 的取值（如 00 表示 OFF、04 表示最小开启、C2 表示受限/类似 ACC、CC 表示另一种全开）。源文档还记录了一个细节：让保持开启成立的是约 450 毫秒的 07 脉冲。

    证据等级与边界

    项目有一条很好的「机器可读验证」手段：仪表上电后自身会发回 0x015（其值在 3D FE 00 00 与 00 FE 00 00 之间变化）和 0x39D（首字节 80 或 FF，末字节是存活计数器），因此台架可以用这些回发帧判断仪表当前处于什么状态，而不必靠肉眼观察。这比单纯看背光亮不亮更可靠。

    但也存在明确未解项。0x245（IGNITION）在静态搜索下没有任何响应，源文档把它归入未解与下一步清单。此外，若干信号（轮速、安全带、油门、挡杆、挡位包）只是按 DBC 命名列出，尚未在台架上逐一触发验证，本文按「标定记录」而非「已确认」标注。

    边界上必须强调：以上编码、载荷与状态图都限定在源文档记录的这个仪表台（2010 款 W212 E350）上。台架环境与整车环境不同——整车上有网关与其它节点参与，仪表台在整车上的行为未必与台架一致；不同年款或配置的仪表也可能使用不同的编码。

    常见问题

    为什么只接 7 根线就能点亮这个仪表？

    因为源文档确认 20 针连接器里只有 7 针有关：1 / 4 / 6 供电，12 / 13 为 CAN E，17 / 18 为 CAN B。其余针脚在该用途下不需要。台架上再接两个 120 Ω 终端即可组成可通信的最小系统。

    0x001 的状态值是怎么找出来的？

    用试验法：逐位扫描 0x001 的字节并观察仪表反应，归纳出各取值的含义（00=OFF、04=最小开启、C2=受限/类似 ACC、CC=另一种全开、CF=延时关闭、07=过渡候选）。源文档还指出让「保持开启」成立的是约 450 毫秒的 07 脉冲。

    怎么判断仪表当前处于什么状态？

    用仪表自己发回的帧作为机器可读指示：0x015 的值在 3D FE 00 00 与 00 FE 00 00 之间切换，0x39D 的首字节为 80 或 FF、末字节是存活计数器（07, 0F, …, 7F）。据此判断状态比看背光是否点亮更可靠。

    台架上找出来的结论能直接用到整车上吗？

    不能直接套用。台架是把这个仪表台从整车中独立出来，缺少网关与其它节点。同一仪表台在整车上的行为可能与台架不同，不同年款或配置的仪表也可能使用不同编码。实车使用前必须重新验证。

    延伸阅读

    参考资料

    • 项目 10 —— public-can-dbc-datasets/additional/izakulus-w212-cluster-notes/README.md（本项目车型档案主来源：接线、台架参数、状态图与未解清单）

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

    更新记录

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

  • Tesla 分总线 DBC 档案：同一 CAN ID 的两种报文

    结论：这份档案的对象是随某类商业诊断工具发布的一套 Tesla 平台 DBC，按「一条总线一份 DBC」拆分，另有一份 _shared 文件承载确实跨多总线的报文。它的数据特征不是某个信号的值，而是「同一个 CAN ID 在不同总线上是不同的报文」：例如 0x3D8 在动力总线上可能是 3 字节的 DC-DC 变换器状态，在底盘总线上却是 8 字节的 GPS 位置——一个编号、两条无关报文。正因如此，源文档给出的定位原则是用发送者（transmitter）字段标注报文属于哪条总线。源文档明确这套 DBC 「仅供参考、不受支持」，且其发布方不逆向信号，因此本文只记录结构与少数示例，不构成完整信号地图。

    车辆与适用范围

    源文档是一份 DBC 仓库说明加许可证。它描述的是数据组织方式与使用约定，而非某一台车的采集记录。

    项 内容
    车型 Tesla 各平台（源文档按「每个平台若干份 DBC」组织，未逐一点名具体车型）
    年款 / 市场版本 源文档未确认；并提示 Tesla 可能在不通知的情况下更新信号
    ECU / 改装状态 无改装；表现为可导入诊断工具的 DBC 定义文件
    采集跨度 源文档未提供日志数或帧数（其致谢提及来自社区提供的总线日志）
    适用范围 仅作参考、不受支持；发布方不逆向信号，用户须自行编辑与维护解码信息

    总线与寻址

    源文档的组织原则是「一个总线一个 DBC」，核心动因就是 ID 复用问题。

    项 内容
    物理层 / 比特率 源文档未给出
    寻址方式 源文档未给出；示例 ID 为 11 位量级（0x102、0x399）
    组织方式 按总线拆分：动力、底盘等各一份，另加一份 _shared 承载真正跨总线的报文
    跨总线识别 约定用发送者字段标识报文所在总线；_shared 内报文不带总线标签，在每个通道上都解码
    CAN FD 源文档未提供
    ID 复用示例 0x3D8：动力总线为 3 字节 DC-DC 状态；底盘总线为 8 字节 GPS 位置

    已解码信号

    源文档是 DBC 的说明文档，只举了少量示例。下表登记源文档实际给出的条目（含两个示例信号、一个 ID 复用示例与两类属性约定），并逐条标注出处；源文档没有提供逐信号清单，这一点在表格之后另有说明。

    条目 位置（ID / 属性） 含义 / 解码 证据
    BMS_packCurrent ID 258（0x102） 高压电池电流；被赋显示名「HV Battery Current」 显示名属性示例
    DAS_autopilotState2 ID 921（0x399） 枚举含 DISABLED/UNAVAILABLE/AVAILABLE/ACTIVE_NOMINAL/ACTIVE_RESTRICTED/ACTIVE_NAV/ACTIVE_FSD/ABORTING/ABORTED/FAULT/SNA 取值配色属性示例
    DC-DC 变换器状态 0x3D8（动力总线） 3 字节报文 ID 复用说明
    GPS 位置 0x3D8（底盘总线） 8 字节报文；与上面同编号但无关 ID 复用说明
    显示名属性 属性名（源文档用到具体属性键） 为信号指定在界面上显示的名称 属性说明
    取值配色属性 属性名（源文档用到具体属性键） 为枚举值指定颜色；合法值含 NONE、BLUE、GREEN、INDIGO、ORANGE、PINK、PURPLE、RED、TEAL、YELLOW、WHITE、BLACK、GRAY，也接受 3 字节十六进制色 属性说明
    _shared 报文 _shared 文件 不带总线标签，在每个通道上都解码 组织说明
    发送者字段 报文属性 按约定标明报文所在总线，导入时须开启「按发送者分配总线」 导入说明
    车辆无关定位 项目说明 工具定位为车无关，授权用户自行编辑并维护解码信息 项目说明

    读取方法与注意事项

    导入流程有一条关键约束：源文档说明在某版本的工具中，要把多份 DBC 导入同一个预设，须使用信号列表上的导入功能，因为主菜单的「打开文件」一次只能打开一份。同时有三个开关需要留意——保留不在该 DBC 内的信号/报文（以保住此前手工创建的内容）、按发送者名称尝试分配总线（必须开启）、以及保留计算信号（避免导入时删除默认预设里的计算信号）。这三项决定了导入结果是否与预期一致。

    由于 ID 复用，解析时不能只按编号索引。正确做法是：先确定当前监听的是哪条总线，再用「总线 + ID」的组合去查报文；对 _shared 中的报文才允许跨通道解码。若只有编号没有总线归属，0x3D8 这类报文会被错误地解码成另一条总线的含义。

    数据性质的提醒同样重要：源文档明确发布方不逆向 CAN 信号，并把它描述为一场「猫鼠游戏」——Tesla 可能不通知就更新信号，也不提供总线报文与信号说明。因此这套 DBC 只应作为起点，任何用于关键判断的信号都应在本车日志上复核；改进与修正通过提交合并请求汇集，可能随工具后续版本一起发布。

    证据等级与边界

    本文的证据等级是「项目说明级」：组织原则、ID 复用示例、两类属性与导入约定都能在源文档逐条核对，属直接证据；但源文档没有逐信号清单、没有比特率，也没有实车日志，因此本文只记录结构与少数示例，不提供完整信号地图。这一点与源文档「仅供参考、不受支持」的定位一致。

    两点不能外推。第一，Tesla 各平台之间的报文与信号可能不同，源文档按平台分别组织 DBC，把某一平台的条目外推到另一平台属于超范围。第二，信号可能随 Tesla 的更新而变化，源文档对此已明确提示；任何跨时间、跨软件版本的外推都缺乏依据。此外须注意许可：设备与设计文件采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布，商用前应先核对条款。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理 DBC 的组织与示例。

    常见问题

    为什么这些 DBC 要按总线拆成好几份？

    因为 Tesla 可能在不同总线上复用同一个 CAN 编号。源文档举 0x3D8 为例：动力总线上是 3 字节的 DC-DC 状态，底盘总线上是 8 字节的 GPS 位置，两者无关。按总线拆分并用发送者字段标注归属，才能避免解码串线。

    导入多份 DBC 时要注意什么？

    源文档提示：要在同一预设里导入多份 DBC，须用信号列表上的导入功能（主菜单「打开文件」一次只能开一份）；并按需处理三个开关，其中「按发送者名称尝试分配总线」必须开启，否则总线归属会错。

    这套 DBC 能直接用于关键判断吗？

    不建议。源文档明确发布方不逆向信号，把维护描述为「猫鼠游戏」，Tesla 可能不通知就更新信号，且这套 DBC「仅供参考、不受支持」。用于关键判断的信号应在本车日志上复核，也可通过提交修正参与维护。

    许可上有什么限制？

    该数据集采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布；商用或打包分发前应先核对条款。原文中出现的第三方贡献者名单与本档案无关，未予引用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/README.md（本项目车型档案主来源：按总线拆分 DBC 的原则、ID 复用示例、两类属性与导入约定）。
    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/LICENSE.md（CC BY-SA 4.0 许可条款）。

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

    更新记录

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

  • 车型文档与线束清单：CarDocs、SupportType 与 CARS.md

    结论：车型支持文档系统是一条「car_docs → PLATFORMS/EXTRA_PLATFORMS → get_params_for_docs() → 品牌 init_make() + CarDocs.init() → 自然排序 → 两种 Markdown 输出」的生成链，它产出的是展示/采购文档，不是车型识别、上车认证或电气设计规范。三个状态必须分开：车型可展示、线束可购买、车型协议已识别、发布固件允许发送，CarDocs 与 SupportType 都不能直接授予 CAN 写入权。以下为固定提交 c8fb906 的静态阅读与隔离探针分析。

    数据与生成顺序

    get_all_car_docs() 汇合正常平台与 extra_cars.py 的额外目录，为每个平台调用 get_params_for_docs()，再对每个车型文档项依次执行品牌 init_make()、共同 CarDocs.init()，最后按自然顺序排序。一个平台可包含多个市场车型/年款条目，因而文档行数不等于车型接口数量。

    关键是 get_params_for_docs() 的输入：它以空 CAN 指纹、一个占位 CarFw、alpha_long=True、is_release=True、docs=True 调用车型 get_params()；额外目录中没有运行时接口的平台使用 MOCK 参数。这样的 CP 是排版/说明输入，既未验证目标车辆固件，也不代表该车能执行控制。

    阶段 入口 产出与边界
    数据汇合 car_docs + PLATFORMS + EXTRA_PLATFORMS 正常平台与额外目录合并，文档行数不等于车型接口数量。
    模拟参数 get_params_for_docs() 空指纹、占位 CarFw、alpha_long=True、is_release=True；无接口平台用 MOCK。
    品牌钩子 品牌 init_make() 品牌级展示字段调整为排版输入，非运行时 CP。
    共同派生 CarDocs.init() 计算 ACC、最低速度、自动起步、转向星级、支持级别与详情句；展示值可能被文档字段覆写。

    展示字段与派生逻辑

    split_name()、get_year_list() 从名称分离品牌、型号、年款并展开年款范围，依赖名称格式和 20YY 结束年推断，不是 VIN/车型年款校验器。CarDocs.init() 从 CP 和文档覆写计算展示列，其中 min_steer_speed、min_enable_speed 等可由文档字段覆写，展示值未必直接等于运行时 CP。

    CarDocs.init() 在 CP.dashcamOnly 且 merged=True 时通常把支持级别降为 DASHCAM，但 CUSTOM 和 REVIEW 是例外；ExtraCarDocs 默认 merged=False、INCOMPATIBLE，社区/安全限制类型由额外目录的子类钩子改写。SupportType 的 UPSTREAM、REVIEW、DASHCAM、COMMUNITY、CUSTOM、INCOMPATIBLE 是文档分类，不是运行时安全模式。

    线束清单以 Device.four 及常见附件为基础，品牌/平台可加入特定接头和工具；CarHarness 枚举包含摄像头/网关/OBD 类接头，并有 has_connector 展示标记。CarParts.common() 会加入默认设备并按 remove 列表过滤，但不做去重；递归展开也可能包含共享子件，数量显示在 CarDocs.init() 统计结果中。这些清单列出的是营销/采购名称，不含供电、针脚、隔离、保险丝或失效态参数。

    两种 Markdown 输出

    输出 入口 范围
    opendbc docs/CARS.md opendbc.car.docs.generate_cars_md() 对传入的全部条目构造简化列，包含不同 SupportType 的支持级别。
    openpilot docs/CARS.md openpilot.selfdrive.car.docs.generate_cars_md() 只筛 SupportType.UPSTREAM，生成 ACC/ALC/硬件/视频等宽表及脚注。

    两个生成器都是模板替换，作为 CLI 执行时会覆写各自的输出文件；get_all_car_docs() 和生成函数的注释明确说明它们也被外部网站调用，因此字段语义变化有仓库外消费者。openpilot 生成器的 _build_cars_table() 按 Column 枚举顺序取列，把 Hardware Needed 表头替换为含宽图片的 HTML 片段，前三列左对齐、其余居中。**kwargs 被直接丢弃，是兼容调用签名而非扩展参数。

    脚注按 get_all_footnotes() 映射的键迭代顺序重新编号，不使用映射值中的编号；只移除字面量 </br>，不移除 <br>。模板使用严格 Template.substitute()，未定义占位符会抛 KeyError。build_sorted_car_docs_list() 只在文档对象尚无 row 时初始化它；后续对同一内存对象再次生成时，已派生的行不会随新的 CP 或脚注参数自动重算。这是生成过程的状态边界，适合把文档项当一次性构建对象。

    对自制硬件与插件化的含义

    源文档给出的是一组建议而非现有代码已实现的保障：把「车型可展示」「线束可购买」「车型协议已识别」「发布固件允许发送」定义为四个不同状态，插件目录只展示已验证字段，不用 CarDocs 或 SupportType 直接授予 CAN 写入权；自制硬件物料表应另存电气契约（接头 pinout、线序、额定电流、供电/点火检测、隔离、ESD、保险与断电默认态），并逐车/年款验证，文档 CarParts 只能作高层采购提示；文档生成改为按版本快照纯计算，记录来自哪个 CarParams、DBC、固件数据库和硬件 BOM。

    测试与缺口

    opendbc 文档测试检查年款重复、命名、部分星级假设和上游线束清单；openpilot 生成器测试主要确认模板能生成。四项原函数隔离探针以临时模板和假 CarDocs 核对上游筛选、列顺序/对齐、调用参数、脚注编号与严格占位符；没有导入完整 opendbc，也未执行真实车型目录生成或覆写归档 CARS.md。这些测试不验证真实线束电气连接、商城库存、车型硬件兼容性或实际发布固件的执行能力。

    常见问题

    被列为 UPSTREAM 就等于该车型已获安全许可吗？

    不等于。SupportType 是文档分类而不是运行时安全模式；文档生成用的是带空 CAN 指纹与占位 CarFw 的模拟参数，不能直接授予 CAN 写入权。

    get_params_for_docs() 得到的参数能上车吗？

    不能。它以空 CAN 指纹、一个占位 CarFw、alpha_long=True、is_release=True、docs=True 调用车型 get_params()，是排版/说明输入，既未验证目标车辆固件，也不代表该车能执行控制。

    线束清单能当电气设计依据吗？

    不能。CarParts.all_parts() 列出的是营销/采购名称，不含供电、针脚、隔离、保险丝或失效态参数；自制硬件应另存电气契约并逐车/年款验证。

    为什么再次生成文档时行不刷新？

    因为 build_sorted_car_docs_list() 只在文档对象尚无 row 时初始化它，已派生的行不会随新的 CP 或脚注参数自动重算，这是生成过程的状态边界。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_DOCS_SUPPORT_HARNESS_DEEP_DIVE.md（生成顺序、展示派生逻辑、两种 Markdown 输出与测试缺口）。
    • 项目 02 —— openpilot-research/ 同目录平台参数与自制硬件方案专题（作为相邻边界参考）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

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

  • opendbc 车型档案：DBC 结构、指纹与安全模式

    结论：这份档案记录的是 opendbc——一个「用 Python 读写你的车」的开源库与 DBC 仓库集合，目标是让带 LKAS + ACC 的车（多为 2016 年后）都能被读状态、控油门刹车与转向。它最值得记录的不是某一辆车的信号，而是三件工程约定：DBC 预处理器把品牌级与车型级 DBC 合成 _generated 文件；指纹（fingerprinting）用 ECU 固件版本识别车型；安全模型让 panda 上电默认处于 SAFETY_SILENT（总线静默），必须先选安全模式才能发报文。逐条信号定义在各自的 DBC 里，本文只登记文档明确写出的示例与能力。

    车辆与适用范围

    源文档是 opendbc 项目的总说明与其 DBC 目录说明。它覆盖的车辆范围很宽，但支持清单放在被引用的 docs/CARS.md（本快照未包含）。

    项 内容
    车型 多品牌；指向「支持车型清单」与约 300 个车型的公开 CAN 数据集
    年款 / 市场版本 多为 2016 年后具备电子可执行转向、油门、刹车的车（因 LKAS/ACC 普及）
    ECU / 改装状态 通过 comma four 与车型线束接入两条 CAN 总线，其中一条被拆开用于注入本系统的执行报文
    采集跨度 源文档未给出统一跨度；提供约 300 车型的 CAN 片段数据集
    适用范围 仅限被登记支持并可被指纹识别的车型；自定义安全模式需自行编译烧录

    总线与寻址

    项目结构分为四层：opendbc/dbc/（DBC 仓库）、opendbc/can/（从 DBC 解析与构造报文的库）、opendbc/car/（与车辆交互的高层 Python 库）、opendbc/safety/（功能安全）。这些层共同决定「一辆车能被读到什么、能写什么」。

    项 内容
    物理层 由车型线束决定；线束接两条 CAN 总线并拆开其中一条用于注入
    链路层 / 比特率 源文档未给出（随车型 DBC 与适配器）
    寻址方式 源文档未给出；DBC 内以报文与信号为单位
    CAN FD 源文档未提及
    承载硬件 comma four + 车型线束 + panda；自定义安全模式需自行编译固件

    已解码信号

    源文档是项目总说明，不是逐车信号清单。下表登记文档中明确写出、可核对的示例与能力条目：信号示例来自 DBC 目录说明的书写范例，其余来自项目总说明的术语与结构。具体每辆车的完整信号以各自 DBC 为准。

    条目 位置 解码 / 含义 证据
    车速 DBC 信号示例 7|15@0+ (0.00278,0) [0|70] "m/s" dbc/README 书写范例
    加速踏板位置 DBC 信号示例 6|7@0+ (1,0) [0|100] "%"（留出首比特不分配） dbc/README 书写范例
    纵向加速度 报文 490 / LONG_ACCEL 注释原文：轮速导数，噪声大且会吸附到零 dbc/README 注释范例
    转向角 car 库读取 读出转向角等状态 README 首段
    油门 / 刹车 / 转向控制 执行器写入 控制油门、刹车、转向 README 首段
    EV 充电状态 读写目标 目标之一：读取并写入充电状态 README 首段
    门锁开 / 关 读写目标 目标之一：读写信门锁 README 首段
    雷达解析 radar_interface.py 解析（若车辆配备） README「Structure of a port」
    指纹 fingerprints.py ECU 固件版本数据库，用于识别车型 README「Structure of a port」
    安全模式状态 SAFETY_SILENT / SAFETY_ALLOUTPUT 上电默认静默；部分模式在发布固件中被禁用 README「Safety Model」
    DBC 预处理器产物 *_generated 由品牌 DBC + 车型 DBC 合成 dbc/README「DBC file preprocessor」
    公开 CAN 数据集 commaCarSegments 约 300 个车型的 CAN 数据 README「More resources」

    读取方法与注意事项

    接入第一步是硬件：拿到兼容车型的线束（若没有现成的，就从「开发者线束」起，再压接所需连接器），线束会把你接到两条 CAN 总线并暴露注入点。第二步是反向工程：先录一段包含丰富事件（开启 LKAS 与 ACC、把方向盘打到两端等）的 route，再用 cabana 打开分析。

    一个车型端口的代码结构很固定：carstate.py 解析状态、carcontroller.py 输出控制、<brand>can.py 是围绕 DBC 的构造辅助、fingerprints.py 存 ECU 固件版本、interface.py 是高层接口、radar_interface.py 解析雷达、values.py 枚举该品牌车型。

    DBC 层面有一个实用的约定：同一个品牌下不同车型的 DBC 大量重叠，因此项目提供预处理器，从「品牌 DBC + 车型 DBC」生成输出文件（_generated 后缀）。改动了源文件需重新运行生成脚本。文档还给出两条书写规范：注释直接写进 DBC（便于在 cabana 里查看/编辑），以及信号只用最少的比特——若不能确定某比特归属，就把它留空不分配，以避免误读。

    证据等级与边界

    本档案属于项目登记。可核对的是结构、命名、安全模型与文档示例；不支持据此列出任何一辆车的完整信号表，因为逐车定义在被引用但未包含在本快照内的 DBC 与 docs/CARS.md 里。

    三处不能外推。第一，「支持某品牌」不等于「支持某年款某配置」——支持清单以车型为单位，文档用术语明确区分 port（某车型的集成）与 brand（品牌）。第二，安全模式不是默认可用：panda 上电默认 SAFETY_SILENT，且 SAFETY_ALLOUTPUT 之类在发布固件中被禁用，需要自行编译烧录才能用。第三，DBC 示例里的数值（如 0.00278 的 m/s 系数）只是书写范例，不代表任何真实车型的标定。

    关于「安全访问」类问题：本文只整理公开文档登记的结构与安全模型，未涉及安全访问的绕过；源文档未提供绕过方法，且不建议尝试。

    常见问题

    opendbc 支持哪些车？

    见被引用的支持车型清单：任何具备 LKAS 与 ACC 的车都可能被支持，多为 2016 年后的车型。本快照只含项目总说明与 DBC 目录说明，未包含完整支持清单。

    怎么给一辆新车加支持？

    按「车型端口」的结构来做：先连上硬件并录一段含丰富事件的 route，再用 cabana 反向工程；随后补齐状态解析、控制输出、指纹与车型枚举等文件。相似车型已有支持时，大部分工作可能已经完成。

    panda 上电后能直接发报文吗？

    不能。上电默认处于 SAFETY_SILENT，总线被强制静默；必须先选择一个安全模式才能发送报文。部分模式（如 SAFETY_ALLOUTPUT）在发布固件中被禁用，需要自行编译烧录。

    DBC 里的 _generated 文件是怎么来的？

    由预处理器从「品牌 DBC + 车型 DBC」合成。源文件改动后需重新运行生成脚本，产物放在仓库根目录并带 _generated 后缀。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/commaai-opendbc-master-20261004/README.md（本项目车型档案主来源：项目结构、安全模型、端口结构与反向工程流程）。
    • 项目 01 —— public-can-dbc-datasets/additional/commaai-opendbc-master-20261004/dbc/README.md（DBC 目录说明：书写规范、预处理器与示例）。

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

    更新记录

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

  • Chevrolet Impala 2008：怠速采集的 50 个 ID

    结论：Chevrolet Impala（2008 款）是一辆典型的「HS-CAN 直读」车：500 kbps、11 位标准帧，源文档在 6 次采集中识别出 50 个唯一 ID，并把解码整理成 22 条消息、71 个信号的 DBC。但它有一个必须说清的限制：所有采集都在静止怠速下完成，因此车速与轮速的换算公式从未被运动数据验证过。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 2008 款 Chevrolet Impala 的 HS-CAN 采集与解码。项目用多次定向采集诱发特定开关动作，再结合公开的 GM 数据库做交叉对照。

    项 内容
    车型 Chevrolet Impala，2008 款
    年款 / 市场版本 2008 款；具体市场版本源文档未确认
    采集构成 5 次约 15 秒的定向采集（用于诱发特定开关），加 1 次约 90 秒的基线采集
    采集状态 全部为静止怠速；源文档明确此时没有轮速与车速数据
    适用范围 仅限源文档记录的这一台车；结论不适用于其他年款或平台

    总线与寻址

    这辆车没有复杂的多总线结构或隐藏网关，接入相对直接。它的问题不在「能不能抓到」，而在「抓到后能证明到哪一步」。

    项 内容
    总线 HS-CAN；OBD-II 引脚 6 / 14
    速率 / 帧格式 500 kbps；11 位标准帧
    唯一 ID 数 50 个（6 次采集合计）
    DBC 22 条消息、71 个信号
    外部交叉引用 与公开的现代 GM Global A 数据库比对，50 个 ID 中有 20 个能匹配
    网关 源文档未记录网关行为；按同年款 GM 车的一般结构为单一 HS-CAN

    已解码信号

    下表从源文档的 Quick-Reference 解码表中抽取。项目对已被运动数据验证过的条目与仅靠怠速数据推出的条目做了区分，本文原样保留「未验证」标注。

    信号 位置（ID / DID / 字节） 解码 证据
    发动机转速 0x0C9 源文档更正：byte 0 是高半字节滚动计数器，不参与 RPM 计算 已确认
    制动开关 0x0C9 位标志 已确认
    制动压力 0x0F1 — 已确认
    挡位 PRNDL 0x1F5 枚举 已确认
    喷油脉宽 0x191 — 已确认
    冷却液温度 / 进气温度 0x4C1 — 已确认
    机油温度 0x4D1 — 已确认
    燃油轨压 0x4F1 — 已确认
    VIN 0x514 / 0x4E1 / 0x52A 多帧拼接为文本 已确认
    方向盘转角 / 角速度 0x1E5 — 已确认
    横加速度 / 横摆率 0x1E9 — 已确认
    电源模式 0x1F1 枚举 已确认
    车门 / 安全带 0x12A 位标志 已确认
    车速 0x3E9 公式存在，但未由运动数据验证 未验证
    轮速 0x348 / 0x34A 公式存在，但未由运动数据验证 未验证

    读取方法与注意事项

    第一条是采集设计。由于全部采集都在静止怠速下完成，任何与「车在动」相关的量都无法闭环：车速与轮速的换算公式虽然在文档里给出了，但没有运动数据能证明它对。若要把这些公式当作可用结论，必须补做一次实际行驶的采集。

    第二条是数据字段的坑。转速信号的 byte 0 曾被当成数据参与计算，源文档更正指出它其实是高半字节滚动计数器——这类「带头字节」的报文在很多车上都存在，把计数器当数据会引入周期性误差。处理多字节数值前，应先确认前导字节是否为计数器或状态位。

    第三条是外部对照的限度。项目把本车的 50 个 ID 与公开的现代 GM Global A 数据库比对，有 20 个能匹配。但这是跨世代的对照，只能作为线索，不能代替在本车上的实测——匹配上了不代表字节位置与刻度在本车上也一致。

    证据等级与边界

    源文档区分了「已确认」与「未验证」两类。已确认的多为怠速下就能观测的开关量、温度与静态值；未验证的集中在与运动强相关的车速与轮速。此外源文档指出，转向灯信号在这辆车的 HS-CAN 上并没有被找到——这是一个负向结论，说明该信号可能在别的总线或不经 CAN 传输。

    还有三处必须如实交代的边界。第一，源文档的 DBC 中，加速踏板位置字段从 bit 48 开始，但该消息被声明为 3 字节，两者不一致，说明这一条布局尚未定稿；第二，声称的原始采集文件并不在项目快照中，因此无法用原始数据复现结论；第三，上游 DBC 文件缺少仓库许可证信息，使用时需自行确认授权。

    适用范围上必须强调：以上 ID、字段与公式都限定在这一台 2008 款 Impala 上，且以怠速数据为主。不同年款、不同平台的车辆，ID 布局与刻度都可能变化；跨车使用前必须重新采集验证。

    常见问题

    为什么车速与轮速被标为「未验证」？

    因为全部 6 次采集都在静止怠速下完成，源文档明确此时没有轮速与车速数据。虽然文档给出了换算公式，但没有任何运动数据能证明它对。要确认这些公式，必须补做一次实际行驶的采集。

    转速信号里为什么要排除 byte 0？

    因为源文档更正指出 byte 0 是高半字节滚动计数器，不参与转速计算。早期把 byte 0 当数据会引入周期性误差。这类「带头字节」在车上很常见，解析多字节数值前应先确认前导字节是否为计数器或状态位。

    和公开 GM 数据库匹配上就代表正确吗？

    不代表。项目只做到 50 个 ID 里有 20 个能匹配现代 GM Global A 数据库，但这是跨世代对照，只能作为线索。匹配成功不等于字节位置与刻度在本车上也一致，仍需在本车实测确认。

    这份 DBC 可以直接拿来做产品吗？

    需谨慎。源文档已指出三处问题：加速踏板字段位置与消息长度声明不一致、原始采集文件不在快照中（无法复现）、上游文件缺少许可证信息。使用前应自行确认授权并补做缺失的验证。

    延伸阅读

    参考资料

    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/analysis/gm/chevy_impala_2008.md（本项目车型档案主来源：解码表、ID 清单与置信度）
    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/can_data/README.md（车辆覆盖与 DBC 文件清单）
    • 项目 09 —— public-can-dbc-datasets/additional/dwilson2547-impala-2008/SOURCE.md（采集状态、DBC 规模与已知问题）

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

    更新记录

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

  • CarCluster 仪表注入：13 个 Simhub 字段与 13 款仪表盘

    结论：这份档案记录的是一个反方向的 CAN 项目：不是从车上读信号，而是用 ESP32 + MCP2515 把 PC/游戏数据注入真实仪表盘，让一台退役的原车仪表在桌面上工作。源文档最可直接引用的是它的输入字段表——Simhub 集成示例把 13 个字段（车速、挡位、转速、最大转速、左右转向、机油温度、暂停、运行、油量百分比、手刹、ABS、TC）映射进这套固件。硬件与支持的仪表清单同样值得记录，但要注意：多款较新仪表（如 T-Cross）存在组件保护，一旦触发无已知解法。

    车辆与适用范围

    源文档是一个开源桌面项目，目标是驱动真实仪表盘，主要用于游戏，也可作时钟等用途。硬件极简：一块 ESP32、一个 MCP2515 CAN 模块、一个 12V 电源。

    项 内容
    车型 面向多种车型仪表盘（VW PQ35/MQB/PQ46、BMW F/E 系、Mercedes W204/W221、Mini F55/F56/F57、Opel Corsa E 等）
    年款 / 市场版本 随平台不同；源文档未统一给出年款，示例为 VW Polo 5、Golf 7、Škoda Superb 2、BMW F10/F30 6WA、E60、E46、W204/W221 等
    ECU / 改装状态 退役仪表盘 + 自制电源/线束；部分平台需逻辑电平转换（如 E46）、数字电位器模拟油位
    采集跨度 源文档未给出；无整车采集，数据来自游戏或网页界面
    适用范围 仅限源文档明确「已完整测试并支持」的仪表型号；相近平台「可能可用但需按具体车型修改」

    总线与寻址

    物理连接对普通爱好者很友好：ESP32 Devkit 板 + 通用 MCP2515 CAN 模块，另可用项目自制的转接 PCB 或跳线/面包板两种接法。仪表侧接线按平台各有专门文档。

    项 内容
    物理层 ESP32 板 + MCP2515 CAN 模块 + 12V 电源；E46 需逻辑电平转换
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出
    CAN FD 源文档未提及
    仪表侧接线 按平台各有一份接线文档（PQ/MQB/BMW F/E60/E46/MB W204/W221/Opel Corsa E）

    已解码信号

    这份主素材不是从整车抓包的信号表，而是注入端的数据字段映射。下表逐条来自源文档给出的 Simhub 集成更新消息格式，是文档中唯一逐字段列出的信号清单，括号内为默认值（若有）。

    字段 键名 含义 / 默认值 证据
    车速 spe 车速（km/h），取整 Simhub 更新消息示例
    挡位 gea 挡位字符串，空值默认 P Simhub 更新消息示例
    转速 rpm 当前转速，空值默认 0 Simhub 更新消息示例
    最大转速 mrp 红线转速，空值默认 8000 Simhub 更新消息示例
    左转向灯 lft 左转向指示，默认 0 Simhub 更新消息示例
    右转向灯 rit 右转向指示，默认 0 Simhub 更新消息示例
    机油温度 oit 机油温度，默认 0 Simhub 更新消息示例
    游戏暂停 pau 是否暂停，默认 0 Simhub 更新消息示例
    游戏运行 run 是否运行，默认 0 Simhub 更新消息示例
    油量百分比 fue 计算得到的燃油百分比，默认 0 Simhub 更新消息示例
    手刹 hnb 手刹状态，默认 0 Simhub 更新消息示例
    ABS abs ABS 是否激活，默认 0 Simhub 更新消息示例
    TC tra 牵引力控制是否激活，默认 0 Simhub 更新消息示例

    读取方法与注意事项

    初始化流程在源文档里很明确：下载项目后用 Arduino IDE 打开 Carcluster.ino，在 BEGIN USER CONFIGURATION 段选择目标仪表盘（例如把 #define CLUSTER 1 改成 3 使用 Golf 7 仪表），其余参数按具体仪表配置；项目已内置所需库，无需额外安装。烧录后 ESP32 会开一个名为 CarCluster 的 Wi-Fi 热点（密码 carcluster），连上后跳转 192.168.4.1 选择要接入的网络；若 3 分钟内未配置，则进入串口模式，可配合 Simhub 使用。

    两个易踩的坑：一是接上 CAN 模块时可能无法烧录，需先断开再上传；二是部分 ESP 板的串口不支持全速，会出现「板子无响应」之类错误，此时把 SERIAL_BAUD_RATE 改成 460800，并同步修改串口监视器、Simhub 与 Arduino 的上传速度。仪表侧的功能自测可以用网页界面（可设转速、车速等）来验证。Simhub 目前只支持 USB 连接、不支持 Wi-Fi。

    证据等级与边界

    本档案属于项目登记 + 集成示例。字段表本身是源文档写死的键名，可核对；「某款仪表盘被完整支持」是作者自测结论；至于实车报文，本项目并不产生——它是把游戏/PC 数据注入仪表，信号方向与整车抓包相反。

    三处不能外推。第一，字段表是注入协议，不是任何一辆车的 CAN 信号定义，不能当成车型档案使用。第二，平台相近不等于可用：源文档明说「相近平台可能可用，但需按具体车型修改」。第三，组件保护是硬边界：较新的 MQB 仪表（如 T-Cross）在未知时间后会进入组件保护模式，闪屏且多数指示灯失效，目前无已知解法，应避免使用。

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

    常见问题

    CarCluster 是从车上读信号吗？

    不是，方向相反。它把 PC/游戏的数据注入真实仪表盘，让仪表显示外部数据；项目目的是在桌面使用退役仪表，而非从整车抓包。

    为什么有些仪表盘不能用？

    以 VW T-Cross 为代表的新款 MQB 仪表会在未知时间后进入组件保护模式，闪屏且多数指示灯失效，源文档明说目前无已知解法，建议改用较老的 Golf 7 等。

    哪些仪表盘支持得最好？

    源文档给出的入门推荐顺序是：Mercedes 某几款仪表、BMW F 系仪表、VW MQB 系仪表；并列出已完整测试支持的具体型号，其中 W204/W221、BMW F10/F30 6WA、E46 等标为完整支持，E60 标为「部分支持、开发中」。

    注入的信号都有哪些？

    源文档的 Simhub 集成示例列出 13 个字段：车速、挡位、转速、最大转速、左右转向灯、机油温度、暂停、运行、油量百分比、手刹、ABS、TC。它们都有默认值，缺省时按默认显示。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/r00li-carcluster/README.md（本项目车型档案主来源：硬件、支持的仪表清单、Simhub 字段映射与安装说明；本快照仅含此文件）。

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

    更新记录

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

  • Nissan Leaf ZE0：LBC 块数据与只读遥测

    结论：Nissan Leaf（ZE0，2011–2012）最反直觉的一点是：它不实现标准 OBD-II PID——连发送 `0100` 都返回 NO DATA。要读电池，必须用 UDS 服务 0x21 向 LBC（锂电池控制器）索取整块数据（如 39 字节一组的电流、电压、SOC、容量）。同时 Car-CAN 上还有一批被动广播帧（档位、转向灯、里程、车门等）可直接监听。源文档的架构默认只读，从不发送会改变车辆状态的指令。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目为 Nissan Leaf 开发的只读遥测仪表盘。项目通过 ELM327 适配器读取标准与非标准数据，并用离线回放、模拟与 MQTT 等多种无车模式做测试，源码中带有大量离线测试用例。

    项 内容
    车型 Nissan Leaf（ZE0 世代）
    年款 2011–2012
    接入方式 ELM327（BLE 或 USB）；源文档另记录自 2026-10-03 起用 CANable 2 接入 Car-CAN
    采集跨度 两个车辆 profile：Leaf 版 18 项 / 61 个信号 / 33 条历史列；另一台对照车为纯标准 Mode 01（19 项 / 20 个信号）
    适用范围 仅限源文档记录的这台 Leaf；年份、电池版本与固件差异都可能改变可用数据块

    总线与寻址

    这辆车的读取要分两条路走：一条是主动的 UDS 块数据读取，另一条是被动的广播帧监听。两者的传输参数完全不同。

    项 内容
    Car-CAN 500 kbit/s；11 位标准帧；引脚 6 / 14
    EV-CAN 引脚 13 / 12；源文档要求强制只监听
    适配器参数 `ATSP6`（ISO 15765-4，11 位 500 kbit/s）
    UDS 寻址 向 LBC 请求用 `ATSH 79B`，接收用 `ATCRA 7BB`；读取服务为 0x21
    被动监听 必须关闭自动格式化（`ATCAF0`）才能拿到原始帧
    标准 OBD-II 本车不实现标准 PID，发送 `0100` 返回 NO DATA
    实测吞吐 CANable 2 在 Car-CAN 上约 1,692 帧/秒、49 个 ID、0 错误帧

    已解码信号

    下表从源文档的信号清单中抽取。项目的置信度分三档：verified（已确认）、static（静态常量）、tentative（暂定），本文按源文档标注保留。

    信号 位置（ID / DID / 字节） 解码 证据
    高压电流 LBC 数据块 01 s32 ÷ 1024 A verified
    电池包电压 LBC 数据块 01 u16 ÷ 100 V verified
    12 V 电压 LBC 数据块 01 u16 ÷ 1024 V verified
    绝缘电阻 LBC 数据块 01 kΩ verified
    SOC（荷电状态） LBC 数据块 01 u24 ÷ 10000 % verified
    可用容量 LBC 数据块 01 u24 ÷ 10000 Ah verified
    单体电压 LBC 数据块 02 96 × u16，单位 mV，量程 3000–4200 mV verified
    电流（第二通道） LBC 数据块 05 16 位回绕：±32 A 之外按 64 A 折叠 verified（2026-09-03 定案）
    档位 Car-CAN 0x421 枚举 verified
    转向灯 Car-CAN 0x358 位标志 verified
    整车里程 Car-CAN 0x5C5 — verified
    车门 / 锁 / 灯 Car-CAN 0x60D 位标志 verified
    车速 Car-CAN 0x284 — verified
    续航 Car-CAN 0x5A9 — verified

    读取方法与注意事项

    第一条是「不按标准 OBD 走」。多数车用 Mode 01 就能读到车速、转速等，但本车不实现标准 PID：`0100`（查询支持哪些 PID）返回 NO DATA。因此不能指望通用的 OBD 诊断 App 直接读出电池信息，必须走 UDS 服务 0x21 向 LBC 请求数据块。

    第二条是块数据的规模与时序。LBC 的第一个数据块约 39 字节，包含电流、电压、SOC、容量等多个字段；单体电压块则是 96 个 16 位值（对应电池单体），量程约 3000–4200 mV。源文档实测在 CANable 2 上，Car-CAN 约 1,692 帧/秒、49 个 ID、零错误帧，一次完整的 96 节电芯读取约 351 毫秒——这给出了「块读取能不能满足刷新需求」的量化参考。

    第三条是回绕陷阱。数据块 05 的电流是 16 位字段：当真实电流超出 ±32 A 时，读数会按 64 A 折叠回绕。也就是说，读到一个看似很低的电流，可能其实是对应的大电流。源文档在 2026-09-03 把这一行为定案。

    证据等级与边界

    源文档的置信度分三档：verified 表示已在实车或离线回放中确认；static 表示该字段在该车上恒为常量；tentative 表示暂定。表中所列以 verified 为主，原样保留标注。此外项目还保留一台对照车的纯标准 Mode 01 profile，用来区分「Leaf 特有的非标准读取」与「通用 OBD 路径」。

    安全边界方面，源文档明确记录了这套工具会发送与不会发送的内容：只发送 UDS 服务 0x21（只读）、标准 Mode 01/03/07，以及适配器自身的监听模式；从不发送会清除或改写 ECU 的指令。EV-CAN 上强制只监听。这一设计把「读车」与「改车」彻底分开。

    适用范围上必须强调：以上数据块布局、字段刻度与广播 ID 都限定在这一台 2011–2012 年的 ZE0 上。不同年份、不同电池容量版本（如 24/30/40 kWh）的 Leaf，其数据块与可用 PID 都可能不同，跨车使用前必须重新核对。

    常见问题

    为什么普通的 OBD 诊断 App 读不到这辆车的电池？

    因为本车不实现标准 OBD-II PID，发送 `0100` 会返回 NO DATA。通用 App 依赖标准 PID，自然读不到。要读电池必须用 UDS 服务 0x21 向 LBC（用 `ATSH 79B`、`ATCRA 7BB`）索取数据块。

    为什么读到的电流有时明显偏小？

    因为数据块 05 的电流是 16 位字段，真实值超出 ±32 A 时会按 64 A 折叠回绕。看到的低值可能对应实际的大电流，需要按回绕规则还原。源文档在 2026-09-03 确认了这一行为。

    被动监听需要什么特殊设置？

    源文档要求关闭自动格式化（`ATCAF0`），否则适配器会把原始帧「翻译」成标准格式，丢失块数据所需的信息。EV-CAN 上则强制只监听。整轮循环在实测硬件上约 0.58 秒完成。

    这套读取方式安全吗？

    源文档的设计是只读：只发送服务 0x21、标准 Mode 01/03/07 与监听模式，从不发送清除或改写指令，EV-CAN 强制只监听。即便如此，任何实车操作仍应自行复核并遵守当地法规。

    延伸阅读

    参考资料

    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/README.md（本项目车型档案主来源：只读架构、profile 与安全边界）
    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/SIGNALS.md（数据块字段、置信度分级与广播帧表）
    • 项目 08 —— public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/CAN_TRANSPORT.md（适配器参数与实测吞吐）

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

    更新记录

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