结论：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 和物理台架验收承担，并且本专题没有实板证据。
延伸阅读
- CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 校验失败如何与 counter、总线超时共同决定一帧是否可信。
- opendbc 的 DBC 过滤与 PID 跨仓契约 —— 同属 opendbc 层，解释协议元数据如何跨仓库绑定。
- 车型识别不是一眼看穿：DBC 指纹与固件匹配的两道关口 —— 承接校验算法被 DBC 名称和信号名绑定的前提。
- Ford CAN 构帧契约：帧长、字段与校验的绑定 —— 从另一家车厂角度看字段位置为何是协议的一部分。
- pandad 原生 CAN 编解码与健康契约 —— 主机侧编解码之后的下一段链路上，健康位如何传递。
参考资料
- 项目 02 ——
openpilot-research/OPENDBC_CHECKSUM_ALGORITHM_FAMILY_RX_TX_CONTRACT_DEEP_DIVE.md（取用了校验函数目录、RX/TX 共用函数的语义、三个隔离探针结果与插件验收字段清单）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复