结论：这台 2017 款 Subaru BRZ 的档案记录的不是一张成品信号表，而是一套「怎么读 CAN 帧」的方法笔记：如何区分 Motorola/大端与 Intel/小端、位序号为什么与端序无关、商业仪表工具里的 offset/length/startbit/bitcount 分别指什么，以及用回放脚本在没有实车时验证解码。主素材明确这是进行中（WIP）的工作，配置里的偏移、缩放与标签尚未逐条与保留的抓包核对；因此本文把它当作方法记录，而不是可直接套用的信号定义。下述结论仅限源文档记录的这一台车。
车辆与适用范围
源文档是车主对自己车辆的私有研究记录。按项目的来源说明，车辆是作者的 2017 Subaru BRZ，配置、市场与 ECU 变体未完全说明；仓库没有找到许可或再分发授权，因此属于非公开的研究副本。文档给出的抓包是作者自述的一段「普通短途驾驶」，共 23,451 行数据。
| 项 | 内容 |
|---|---|
| 车型 | 2017 Subaru BRZ（据仓库说明） |
| 年款 / 市场版本 | 2017；源文档未给出配置、市场版本与 ECU 变体 |
| ECU / 改装状态 | 取自 OBD 口的主 CAN 广播；作者用某款 OBD-USB 适配器按 500k 波特率读取 |
| 采集跨度 | 保留一段约 23,451 行数据的短途驾驶日志；来源说明另提到其他抓包未一并保留 |
| 适用范围 | 仅限这一台 2017 BRZ；配置的偏移、缩放与标签尚未与抓包逐条核对 |
总线与寻址
源文档按「8 字节 / 64 位经典 CAN 帧」讲解，没有涉及 CAN FD。示例帧是 0x141: 84 26 95 27 B1 82 A7 00，作者用它演示如何定位第 43 位。文档还提醒：商业仪表工具展示字节顺序的方式与常见约定不同，要单独留意。
| 项 | 内容 |
|---|---|
| 物理层 | 双绞线 CAN；作者按 500k 波特率读取（据文档自述） |
| 链路层 / 比特率 | 500 kbit/s（文档自述） |
| 寻址方式 | 源文档以 11 位示例 ID（如 0x141、0x0d3）讲解，未展开 11 位 / 29 位差异 |
| 端序 | Motorola = 大端，Intel = 小端；小端按递增字节地址读，大端按递减字节地址读 |
| 位序号 | 全帧 64 位序号固定：字节 0 的位 0 是第 0 位，字节 1 的位 0 是第 8 位，依此类推；端序不改变位序号 |
| CAN FD | 源文档未涉及 |
已解码信号
主素材没有给出成品信号表，只给了一个示例帧与若干配置属性。为守住「只抄有证据的条目」这条线，下表登记源文档明确写出的字段与规则，涉及具体缩放/标签的条目一律标注为未逐条核对。
| 字段 / 规则 | 位置 | 解码 / 说明 | 证据 |
|---|---|---|---|
| Custom_Engine_Torque | 0x141，bitcount=15 | 自定义输入；示例未给缩放 | README 示例配置 |
| Engine_Engine_Stop | 0x141，startbit=15，bitcount=1 | 1 位，单位 bit | README 示例配置 |
| Wheel_Torque | 0x141，offset=2（第 3 个字节） | 示例未给长度与缩放 | README 示例配置 |
| 转速类目标值 | 0x141，offset=4，length=6 | 映射到商业仪表工具的 RPM 输入（targetId 37） | README 示例配置 |
| 车速 | 长度不足 8 字节的帧（示例 0x0d3） | 回放补零后读不准，作者说明该信号受补零影响 | README「回放」小节 |
| 帧 ID 写法 | XML 的 frame id | 可为十进制或 0x 前缀十六进制；若外层有 baseId 则最终 ID = baseId + id | README「frame id」小节 |
| 值的 name 与 targetId | XML 的 value | 有 targetId 则写入工具内置输入；否则用 name 新建 ECU-Specific 自定义输入 | README「value」小节 |
| 配置规模 | WIP 配置 | 28 个 frame 元素、145 个 value 元素；偏移、缩放、标签未逐条核对 | 来源说明 |
| 位序号查找法 | 任意帧 | 先把每字节转 8 位，再按全帧序号表定位目标位 | README「位序号」小节 |
读取方法与注意事项
第一条是端序与位序号要分开理解。源文档反复强调「位的位置不会因为端序改变」：不管大端小端，第 43 位永远是第 5 个字节里从右边数第 4 个位（位 3）。端序只影响你按什么顺序把连续的字节拼成一个多字节数值。混用是这类解码最常见的错误来源。
第二条是配置属性的含义——startbit 是开始读的位，bitcount 是一次读多少位，offset 是从哪个字节开始（十六进制），length 是连续读几个字节。作者用一款商业 CAN 数据库编辑器做可视化对照来推导这些含义，因为该工具的术语与仪表工具不同。
第三条是回放验证的坑。源文档说明其回放脚本会把不足 8 字节的帧用零补齐，例如 0x0d3: 00 06 C0 0F 00 00 42 会变成 8 字节。补零等于给多字节字段多加了 16 位，会改变按位计数与端序结果，因此「用回放测车速」这类信号会读不准。作者建议回放时把推送速率设到能产出约 400 帧/秒，以接近实车从 OBD 口 500k 波特率读到的速率。
证据等级与边界
属于方法性、可核对的：端序与位序号的对应规则、配置属性含义、帧 ID 与 baseId 的加法规则。属于未验证的：整套 WIP 配置的偏移、缩放与标签——来源说明写明它们「没有被独立地对照保留的抓包检查过」，而且这套配置是从公开的前代 Subaru DBC 改编而来。
两处不能外推。第一，车辆本身就是单一样本，且配置、市场与 ECU 变体未说明；同型号不同配置不宜套用。第二，回放脚本的补零行为会系统性歪曲短帧信号，任何用回放得到的数值都不能当作这台车的真实解码结果。
关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档记录的解码方法，不涉及对车辆安全机制的规避。
常见问题
大端和小端只影响读的顺序吗？
是的。源文档说明位的位置不会因端序改变，改变的只是你按什么顺序把连续字节拼成多字节数值：小端按递增字节地址读，大端按递减字节地址读。
第 43 位在示例帧里怎么找？
按源文档的全帧序号表，第 43 位位于第 5 个字节（示例中为 0x82）内从右数第 4 位（位 3），该帧此位为 0。这个方法与端序无关。
为什么回放测车速不准？
因为回放脚本把不足 8 字节的帧用零补齐，等于给字段多加 16 位，改变了按位计数与端序结果。源文档明确说车速信号正来自一个不足 8 字节的帧，因此受此影响读不准。
这份配置里的 ID、缩放能直接拿来用吗？
不能直接当作已验证结果。来源说明指出这套 WIP 配置的偏移、缩放与标签尚未与保留抓包逐条核对，且改编自公开的前代 Subaru DBC；使用前需自行复核。
延伸阅读
- VW MLB/PQ 的 CAN 报文构造契约 —— 与本文「按位拼帧」同一层面的工程细节。
- FT86 与 MX-5 的赛道 CAN 信号：RaceChrono 公式表 —— 同一车系 BRZ 的成品 CAN 公式表，可与本文的 WIP 配置对照。
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 承接回放/补零造成的信号失真判读。
- OBD-II PID 入门：车速 0x0D 为什么是整数 —— 对照「广播帧解码」与「PID 请求」两条取数路线。
- Fiat Ducato X250 车身 CAN 档案：50 kbit/s 上的 24 条信号 —— 另一份以「逐字节核验」为纪律的车身网解码范例。
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/painellope-brz-2017/CAN_Decoding/README.md（主来源：CAN 帧阅读方法、示例帧与配置属性说明）。 - 项目 01 ——
public-can-dbc-datasets/additional/painellope-brz-2017/SOURCE.md（快照范围、配置规模与「未逐条核对」的边界提示）。 - 项目 01 ——
public-can-dbc-datasets/additional/painellope-brz-2017/CAN_Decoding/CAN_Frame_Datalogs/fileIndex.md（保留抓包的用途与回放补零说明）。
说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复