星核火花赛车科技

标签： 车型档案

  • Talaria 电摩 CAN 档案：250 kbit/s 的 15 个 ID

    结论：Talaria 电动摩托的总线是一条 250 kbit/s、11 位标准帧的小型 CAN：源文档记录 15 个 ID、约 92 帧/秒，并把其中的 9 条消息、26 个信号行整理成 DBC。这条总线的价值在于「小而有坑」——源文档明确记录了三处「看起来像但并不是」的误判（电池百分比、里程、温度），还修正了里程字段并标注为临时值。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 Talaria 电动摩托的 CAN 解析。项目用只监听方式读车，DBC 基于更早的第三方整理做了修订，并把每个信号的溯源写在注释里。

    项 内容
    车型 Talaria 电动摩托；具体型号源文档未确认
    电池包 16S；源文档由「电芯高/低平均 × 16」与包电压吻合到 0.02 V 推出
    采集硬件 ESP32-S3 加 SN65HVD230 收发器；默认只监听
    采集跨度 多条骑行日志与台架检查；源文档记录总线约 92 帧/秒、15 个 ID
    适用范围 仅限源文档记录的这一台车；源文档另指出另一台参考车上的字节偏移不同

    总线与寻址

    这条总线的规模很小，接入门槛不高，但正因为 ID 少、字段挤，误判的风险反而更高。识别要点是速率、位宽与终端电阻三件事。

    项 内容
    速率 / 帧格式 250 kbit/s；11 位标准帧
    总线规模 15 个 ID，约 92 帧/秒
    终端 车端已两端终端，整对约 60 Ω；采集器若自带 120 Ω 终端应拆除，否则会降到约 40 Ω
    采集方式 只监听（listen-only）；收发器不驱动总线也不应答，因此速率设错也不会干扰车辆
    DBC 规模 9 条消息、26 个信号行；基于第三方先期整理修订

    已解码信号

    下表从源文档的解码清单中抽取。项目对未确认的条目明确标注「单位未确认」或「临时值」，本文原样保留这些标注。

    信号 位置（ID / DID / 字节） 解码 证据
    车速 0x303 B0:B1（小端） 0.1 km/h 已确认（与转速比值恒定 5.887，r=0.999）
    电机转速 0x203 B0:B1（小端） 1 rpm 已确认（同上）
    功率 0x203 B2:B3（小端） 1 W 标定记录
    电流 0x302 B4:B5（小端） 0.1 A 标定记录
    包电压 0x101 B0:B1（小端） 0.1 V 已确认（电芯高低平均 × 16 吻合到 0.02 V）
    电池百分比 0x401 B0 1 % 标定记录
    最高电芯 + 编号 0x201 B0:B1、B4 1 mV 标定记录
    最低电芯 + 编号 0x201 B2:B3、B5 1 mV 标定记录
    侧撑 0x202 B0 bit7 1 = 放下 标定记录
    骑行模式 0x202 B0 bits5:4 1 Eco、2 Sport 标定记录
    回充等级 0x490 B0 bits2:0 1–4 标定记录（须按 3 位掩码）
    骑行模式（仪表指令） 0x490 B0 bits5:3 1 Eco、2 Sport 标定记录
    里程 0x402 B2:B3（小端） 1 km 临时值（源文档要求增量复核）
    油门需求 0x202 B3:B4（小端） 单位未确认 未确认

    读取方法与注意事项

    第一条是终端电阻。车端已经在两端做终端，整对读下来约 60 Ω；如果采集器再挂一个 120 Ω 终端，会把阻抗拉到约 40 Ω，可能影响总线。源文档建议把采集模块自带的终端拆掉。

    第二条是「看起来像但不是」的三处误判。其一，某个字节被当成电池百分比，其实是恒定的 100，源文档判断它更可能是健康状态而非荷电状态；其二，某个字段单调递增，看着像里程，但它与车速的相关系数只有 −0.0005，且每公里计数在两次骑行间相差 34%——真正的里程在另一个 ID 上；其三，某个字节既不是温度也不是单一字段，它同时承载模式位与回充位，必须按 3 位掩码拆开。

    第三条是写入操作的风险边界。源文档记录了对「模式/回充指令所在 ID」是仪表下发还是控制器回显的讨论，并做了注入实验来判断控制权归属。这类对车辆控制总线的写入涉及安全风险，本文不复述具体做法，也不建议尝试。

    证据等级与边界

    项目对已确认信号给出了可复现的依据：车速与转速在两个独立骑行中保持固定比值 5.887（r=0.999），电芯高低平均 × 16 能把包电压还原到 0.02 V。这两条互相独立的证据把「车速、转速、包电压、16S 结构」串成了可信的一组。

    里程是新近发现的字段，源文档明确标注为临时值：它是靠「车自己显示的 400 km」与一次全总线采集里的数值匹配找到的，但只匹配了一次。源文档提醒这条总线上有整数常量（例如某两个 ID 里都出现 1200），所以一次与整数吻合只是「有说服力」，不是证明——必须等到一次骑行里看到它递增才能定案。

    边界上必须强调：以上字段位置与刻度限定在这一台车与这一版固件。源文档已指出另一台参考车上的油门字节偏移就不同（本车在 0x202 的 B3:B4，参考车在 B2:B4 且并不跟随油门）。换车使用前必须重新核对偏移。

    常见问题

    为什么里程字段被标成「临时值」？

    因为它只被匹配到一次：源文档读到车辆自身显示的 400 km，并在一次全总线采集的某个 ID 里找到同样的 400。但这条总线上存在整数常量，单次与整数吻合不能排除巧合，必须等一次骑行里看到该值递增才能确认。

    那个恒定 100 的字节是什么？

    源文档明确它「不是电池百分比」——它在实际电量变化时仍读 100，因此更可能是健康状态之类的字段。不要把它当作荷电状态使用。

    回充等级为什么容易读错？

    因为它与骑行模式共用同一个字节，且只能按低 3 位掩码读。若按整个低半字节（4 位）读，在 Eco 模式下 bit3 会被置位，本该读成 1 的回充等级会读成 9。源文档强调「掩 3 位，不是 4 位」。

    这条总线上有哪些信号是找不到的？

    源文档记录喇叭与灯光不经过总线，它们是来自车把开关的 12 V 通断电路；刹车拉杆只出现在部分车型上，不带传感器的改装拉杆则什么都不产生。因此这些量无法从 CAN 上读到。

    延伸阅读

    参考资料

    • 项目 07 —— public-can-dbc-datasets/additional/kbirand-talaria-tripper/README.md（本项目车型档案主来源：解码清单、陷阱与硬件说明）
    • 项目 07 —— public-can-dbc-datasets/additional/kbirand-talaria-tripper/SOURCE.md（DBC 规模、先期工作与许可证说明）

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

    更新记录

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

  • VinFast VF8/VF9 诊断档案：7 个 CAN 矩阵与 UDS

    结论：这份档案记录的是 VinFast VF8 / VF9 的诊断侧资料：一个基于 OpenXC 或 ELM327、通过 UDS（ISO 14229）读写故障码的桌面工具，以及七份 CAN 网络矩阵（合计约 1,027 条报文、8,684 条信号）与九份信号转发路由表。要点是两条：诊断 CAN 总线为 500 kbit/s，而 VF8 的多数子系统是藏在 XGW 网关之后的 CAN 节点，必须按逻辑地址寻址、由网关转发；读取故障码在默认会话常可用，但清除故障码往往需要安全访问（0x27）。需要提醒的是，工具里随附的逻辑地址是占位符、不是官方地址。

    车辆与适用范围

    源文档是一个面向 VinFast VF8/VF9 的诊断应用仓库。它把「固件反推得到的事实」与「一次实车观测」分开陈述，这个分层在下文原样保留。

    项 内容
    车型 VinFast VF8 / VF9（BEV）
    年款 / 市场版本 实车观测为 2024 款美规 VF8；VF9 的适配性源文档未确认
    ECU / 改装状态 原车；通过 OpenXC 车辆接口或 ELM327 适配器接入诊断总线
    采集跨度 源文档给出一次实车观测；其余为固件与矩阵文档
    适用范围 仅限源文档记录的 2024 美规 VF8 观测；七份 DBC 与实车捕捉的对应关系未被独立验证

    总线与寻址

    VF8 的诊断总线比特率在出厂脚本里写死为 500 kbit/s。部分子系统位于 XGW 网关之后，需要按逻辑地址寻址、由网关把请求路由到对应 CAN 网络。工具另支持 MS-CAN 的 125 kbit/s 与 250 kbit/s 两档，物理拨档需与所选总线一致。

    项 内容
    物理层 OpenXC 车辆接口（USB 或蓝牙 SPP）或 ELM327 v1.5（USB/蓝牙串口）
    链路层 / 比特率 诊断 CAN 500 kbit/s；MS-CAN 支持 125 kbit/s（ELM 协议 B）与 250 kbit/s
    寻址方式 逻辑地址寻址，网关转发到 CAN；CAN ID 映射默认为 请求 = 0x700 + (addr & 0xFF)、响应 = 请求 + 0x08
    CAN FD 源文档未提及
    地址默认值 测试端源地址默认 0x0E80；功能地址默认 0xE400（占位符，须按实车设置）

    已解码信号

    下表把源文档的固件事实、路由表条目与实车观测分开列，逐条注明证据来源。涉及安全访问的条目只说明「存在该会话要求」与「密钥来源」，不展开任何算法或密钥细节。

    条目 位置（ID / 服务 / DID） 含义 证据
    诊断 CAN 比特率 — 500 kbit/s（出厂脚本设定） 固件事实（init-can.sh）
    读取故障码 UDS 0x19 / 0x02 读取 DTC，默认会话通常可用 README「Features」
    清除故障码 UDS 0x14 会先进入扩展会话，需确认；常需安全访问 README「Features / Realistic expectations」
    诊断会话控制 UDS 0x10 默认/扩展会话切换，配合 TesterPresent 保活 README「Session & security」
    安全访问 UDS 0x27（seed / key） 密钥为「每 ECU / 每安全等级」的机密，不在固件明文，须取自本车 README「Realistic expectations」
    读取身份 / VIN UDS 0x22 / DID F190 读 VIN 等身份信息 README「Per-ECU actions」
    例程结果（只请求不启动） UDS 0x31 03 FFFF 只请求例程结果，绝不启动例程 README「Safe ECU capability research」
    归还 I/O 控制 UDS 0x2F FFFF 00 把 I/O 控制权交回 ECU README「Safe ECU capability research」
    诊断会话计数 UDS 0x19 01 FF 报告故障码数量 README「Safe ECU capability research」
    BCM 诊断响应信号 Diag_CAN 0x601 ← Body_CAN 0x601 车身控制模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    MHU 诊断响应信号 Diag_CAN 0x604 ← Info_CAN 0x604 车机模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    AMP 诊断响应信号 Diag_CAN 0x605 ← Info_CAN 0x605 功放模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    ACM 诊断响应信号 Diag_CAN 0x608 ← Body_CAN 0x608 音响/空调模块诊断响应数据 路由表 ToDiag_v10.7.5.csv
    XGW 隧道候选 0x682（Info-CAN 隧道路径） 首选隧道 ID，仍是候选，未获实车匹配响应 实车观测
    OBD 物理回退 0x7E0 标准 OBD 物理回退地址，同为候选 实车观测

    读取方法与注意事项

    源文档把「安全的能力指纹」做成了默认动作：对已确认可达的 ECU，只发六条只读/归还类服务——0x3E 00（TesterPresent）、0x19 01 FF（报告 DTC 计数）、0x22 F190（读 VIN/身份）、0x31 03 FFFF（只请求例程结果）、0x2F FFFF 00（归还 I/O 控制）、0x83 01（读扩展时序上限）。结果区分「肯定响应」「识别到服务但返回否定码」「明确的服务不支持 0x11」「无响应」四种，每行记录 ECU 地址、会话、请求/响应字节与否定码。这一工作流刻意排除了复位、清除 DTC、写入、安全访问与文件传输等服务。

    实车那一侧的观察需要谨慎解读：在参考的 2024 美规 VF8 上，用 OpenXC 发出 diagnostic_request（总线 1、ID 0x682、UDS 0x22 F190），主机侧确认收到了指令，但 3 秒内没有收到 diagnostic_response。源文档据此只说「电脑到车辆接口的链路工作正常」，并明确这不能证明车辆接口的 CAN 发送、物理 OBD 网络、XGW 唤醒状态，也不能证明 0x682 在连接口可达；超时不等于某个 ECU 不存在。

    关于安全访问，源文档的结论是：密钥不在固件中以明文存在，而是每 ECU、每安全等级各自持有的机密，必须从本车自身的配置数据中取得。源文档未提供任何绕过安全访问的方法，且不建议尝试。

    证据等级与边界

    证据分三层，源文档自己就分开了。固件事实（诊断总线 500 kbit/s、各 UDS 服务的存在）来自对车载 TBOX 根文件系统的反推，可核对。路由表条目（0x601/0x604/0x605/0x608 等）来自随附的九份转发 CSV，是信号转发参考数据，不构成执行器或写流程。实车观测只有一次，且只证明链路连通。

    三处不能外推。第一，源文档明说原始适配器帧不标识自己属于哪个网络，因此为某一帧选用某个 DBC 是一种「解码假设」，不是检测出的总线身份。第二，实车观测既未证明 VF9 装配、也未证明全部网络访问路径，不能把 VF8 的观察推广到 VF9 或其他年款。第三，矩阵文档的 1,027 条报文与 8,684 条信号与实车捕捉的对应关系未被独立验证，且来源说明指出这些矩阵的原始出处与再分发授权均未声明。

    常见问题

    VF8 的故障码能免密清除吗？

    通常不能。源文档指出读取 DTC 在默认会话往往可用，但清除往往需要安全访问（0x27）。密钥不在固件明文里，须从本车自身的配置数据取得；源文档未提供绕过方法，且不建议尝试。

    工具里内置的逻辑地址能直接用吗？

    不能。源文档明确这些 VinFast 逻辑地址是占位符、非官方地址，须用「探测 ECU 地址」逐个试出真正响应的地址后再配置。

    七份 DBC 是按什么划分的？

    按网络划分，分别对应信息、车身、诊断、动力、底盘、电池与一条 ASU 私有车身总线。由于原始帧不携带网络标识，为某帧选用某个 DBC 属于解码假设；路由 CSV 是信号转发参考，不定义执行器或写流程。

    那次实车观测说明了什么？

    只说明电脑到车辆接口的链路可用。3 秒内没有响应不能证明车辆接口的 CAN 发送、物理 OBD 网络或 XGW 唤醒状态，也不能证明 0x682 在连接口可达；超时不等于 ECU 不存在。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/cmarshall108-vinfast-vf8-vf9/README.md（本项目车型档案主来源：UDS 工具说明、固件事实与实车观测）。
    • 项目 01 —— public-can-dbc-datasets/additional/cmarshall108-vinfast-vf8-vf9/SOURCE.md（七份 CAN 矩阵与路由表的规模、校验值，以及「未独立验证」的边界声明）。
    • 项目 01 —— public-can-dbc-datasets/additional/cmarshall108-vinfast-vf8-vf9/assets/can/routing/ToDiag_v10.7.5.csv（诊断网络信号转发条目示例）。

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

    更新记录

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

  • Opel Astra H 的 LS-CAN 与 MS-CAN 解码档案

    结论：这份档案记录的是欧宝 Astra H 的两条总线：单线的 LS-CAN（即 SW-CAN / GMLAN） 与 MS-CAN。在 LS-CAN 上，源文档把车速、转速、行驶距离、燃油喷射、冷却液温度、燃油液位、系统时间、电压与 TPMS 都逐字节解了出来；例如车速在 0x108 上除以 128、燃油液位是 94 - (值/2) 升。它是一份「按地址逐字节标注」的观测表，而不是厂商规格：大量字段被标为 ?? 或「见过 N 种取值」，这些不确定标记必须原样保留。

    车辆与适用范围

    源文档是一份公开的「车辆 CAN 报文数据库」，按 品牌/型号/代/总线/部件.md 组织。Astra H 这一支同时给出 LS-CAN 与 MS-CAN 两个目录，其中 LS-CAN 以 ALL_TYPES.md 汇总全部观测值。

    项 内容
    车型 Opel Astra H（MS-CAN 文档中点名发动机为 Z16XEP 1.6L）
    年款 / 市场版本 源文档未给出具体年款与市场版本
    ECU / 改装状态 源文档未给出；为车主对原车的观测
    采集跨度 源文档未给出日志数或帧数；部分报文注出周期（如 0x108 约 50ms、0x190/0x440 为 1000ms）
    适用范围 仅限源文档记录的这一台 Astra H；数值标定含多项未确认项

    总线与寻址

    这台车同时有 LS-CAN 与 MS-CAN。LS-CAN 被文档标注为「SW-CAN——单线或 GMLAN」，是单线制总线；MS-CAN 承载车身、信息显示等部件。两条总线都以小写十六进制地址登记（如 0x108、0x530、0x684）。

    项 内容
    物理层 LS-CAN：单线（SW-CAN / GMLAN）；MS-CAN：源文档未给出
    链路层 / 比特率 源文档未给出
    寻址方式 表中地址为小写十六进制（如 100、530），源文档未标注位宽
    CAN FD 源文档未提及
    多帧报文 MS-CAN 的 Info-Display 报文超过 8 字节，使用 ISO-15765-2 分包

    已解码信号

    下表抽取 15 条最有代表性的条目，横跨 LS-CAN 与 MS-CAN。凡源文档标为 ??、「见过 N 种取值」或「计算取决于传感器/有时反向」的，均在证据列保留说明。

    信号 位置（ID / 字节） 解码 证据 / 置信度
    车速 LS-CAN 0x108 byte2+3 值 / 128 = km/h（例 0x2098=65.19） 源文档示例与说明
    发动机转速 LS-CAN 0x108 byte5+6 16 位（例 0x04E5=1253 rpm） 源文档示例；MS-CAN 版本在 0x4E8 上为「RPM/4」
    行驶距离（每驱动轮） LS-CAN 0x110 byte2+3 / byte4+5 一次增量 = 1.5748 cm；16 位满周期约 1032 m 源文档说明
    燃油喷射量 LS-CAN 0x130 byte2+3 一次增量 = 0.03054 ml（1.6L 机）；满周期约 2 升 标定基于作者 1.6L 发动机
    冷却液温度 LS-CAN 0x145 byte4 值 – 40 = °C（例 0x28→-2 °C） 源文档示例
    发动机/点火状态 LS-CAN 0x145 byte1–3、5 多字节状态码（如 0x20=点火开未着、0x00=运行） 源文档逐值说明
    巡航控制状态 LS-CAN 0x145 byte6 0x04=未激活 / 0x06=激活 源文档说明
    转向灯/拨杆状态 LS-CAN 0x175 byte3 0x01～0x04 表示半推/半抬/全推/全抬 源文档说明
    转向灯控制帧 LS-CAN 0x260 三字节组合区分左/右/双闪 源文档逐组合表
    总里程 LS-CAN 0x190 byte3–5 里程量（周期 1000ms） 源文档标注；单位与系数未在本文展开
    燃油液位 LS-CAN 0x375 byte2 94 – (值/2) = 升（例 0xA0→14.0 L） 「计算取决于传感器，有时反向」
    系统时间 LS-CAN 0x440 byte1–3 时 : 分 : 秒÷4 源文档说明
    户外温度 LS-CAN 0x445 byte2 MS-CAN 同义项 0x682 为「值/2 – 40 = °C」 源文档说明
    电压 LS-CAN 0x500 byte2 源文档标注为电压（周期约 1500ms） 源文档标注；换算未在本页给出
    胎压 TPMS LS-CAN 0x530 byte3–6 每轮 值/25 = Bar；byte1/2 为前/后传感器状态 MS-CAN 版本在 0x684 上同式

    读取方法与注意事项

    源文档的记法本身就是方法约束：页首声明斜体值表示「至今只见固定值」，粗体值表示已被单独页面解释，括号中的数字是见过的不同取值个数。也就是说，一个标了 ? (4) 的字节，作者只见过 4 种取值——它可能是枚举状态，也可能是「从未触发的故障位」，文档对后者也如实保留。

    对使用者而言，最实际的两点：其一，MS-CAN 的 Info-Display 报文超过 8 字节，用 ISO-15765-2 打成多帧，数据块结构是「两字节命令 + 一字节负载长度 + 一字节消息类型 + 若干子包（ID + 字符数 + UTF-16 字符）」；文档给了 AC、音频、导航等消息类型与各类型下的行 ID 清单。其二，按位复用的字节必须做位运算（拨杆/方向盘按键就是「函数由位编码」）。

    证据等级与边界

    本档案属于单车观测：所有条目都来自一位车主对一台 Astra H 的记录，没有第三方旁证，也没有反汇编或厂商规格支撑。可核对的是「作者给出的一条条示例」（如 0x108 的 0x2098→65.1875 km/h、0x375 的 0xA0→14.0 L）；不可核对的是这些标定是否适用于其他车。

    三处不能外推。第一，改装的线束、传感器与仪表版本会让个别字节不同，燃油液位文档自己就注明「取决于传感器，有时反向」。第二，作者在页首明说斜体值「可能是从未触发的故障指示」，把「只见固定值」当成「恒为定值」是过度解读。第三，发动机相关标定（燃油喷射的 0.03054 ml）是用作者自己的 1.6L 发动机推出来的，换机型即失效。

    关于「安全访问」类问题：本文只整理被动观测到的广播报文，未涉及任何诊断写入或安全访问绕过；源文档未提供绕过方法，且不建议尝试。

    常见问题

    Astra H 的 LS-CAN 和 MS-CAN 有什么区别？

    LS-CAN 被文档标注为单线的 SW-CAN / GMLAN，承载车速、转速、燃油、里程、TPMS 等；MS-CAN 承载车身与 Info-Display 等。两者的地址与编码各自独立。

    车速是怎么算出来的？

    在 LS-CAN 的 0x108 上取 byte2+3 组成 16 位值，再除以 128。文档示例：0x2098 = 8344，8344 / 128 = 65.1875 km/h。

    燃油液位为什么有时反向？

    文档注明该值「计算取决于传感器，有时反向」，公式为 94 - (值/2) 升。因此同一公式在不同传感器配置下可能得出相反趋势，不能无条件套用。

    Info-Display 的报文为什么超过 8 字节？

    因为它用 ISO-15765-2 把长报文分成多个 CAN 帧（首帧 + 连续帧）。数据块由两字节命令、一字节负载长度、一字节消息类型和若干子包组成，子包再带行 ID、字符数与 UTF-16 字符。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/trueffelwurm-opel-astra-h/Opel/Astra/H/LS-CAN/ALL_TYPES.md（本项目车型档案主来源：LS-CAN 全部观测值与逐条说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/trueffelwurm-opel-astra-h/Opel/Astra/H/MS-CAN/Body.md（MS-CAN 的底盘与发动机条目）。
    • 项目 01 —— public-can-dbc-datasets/additional/trueffelwurm-opel-astra-h/Opel/Astra/H/MS-CAN/Info-Display.md（Info-Display 的 ISO-15765-2 分包与消息类型表）。

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

    更新记录

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

  • Kia Soul OSCC 档案：归一化命令与 200 ms 保活接口

    结论：这份档案的对象是一套面向 2014 年及以后 Kia Soul（汽油与纯电）的开源车辆控制项目（OSCC），它把「读取车辆状态」和「下发控制命令」拆成 API 与固件两层：固件侧用专门的模块通过转向力矩/油门位置/制动位置传感器与 OBD-II CAN 交互，API 侧用归一化数值下发命令、并通过回调接收回报。它的数据特征是命令归一化 + 200 ms 保活：制动与油门为 [0.0, 1.0]、转向为 [-1.0, 1.0]，且每个发布函数必须至少每 200 ms 调用一次，否则模块判为通信丢失并自行禁用。源文档未给出比特率、寻址方式与逐字节定义，其结论仅限 2014 年起的 Kia Soul 平台。

    车辆与适用范围

    源文档是一个软硬件项目仓库的说明：它描述 API、固件与硬件三部分，以及可扩展的车型头文件机制。数据来自项目文档，不是某台实车的采集记录。

    项 内容
    车型 Kia Soul（2014 年及以后，汽油与纯电）；构建目标另含 Kia Niro
    年款 / 市场版本 源文档以「Kia Soul PS（2014–2018）」指代已整理信息的平台；其他年款与市场版本未确认
    ECU / 改装状态 加装 OSCC 模块：传感器接口板（转向/油门）、整车控制模块（纯电制动）或执行器控制板（汽油制动），外加 CAN 网关
    采集跨度 源文档未提供（无日志数或事务数）
    适用范围 源文档明确「目前仅支持 2014 年起的 Kia Soul」，API 与固件按易扩展设计，但其他车型属未来扩展

    总线与寻址

    源文档把总线分成「车辆 OBD-II CAN」与「OSCC 控制 CAN」两条，固件用 CAN 网关模块在两段之间转发；但未描述物理层与标识符细节。

    项 内容
    物理层 / 比特率 源文档未给出
    总线划分 车辆 OBD-II CAN 网络（读状态、发命令、接收回报）；OSCC 控制 CAN（API 与固件模块之间）
    寻址方式 源文档未给出；API 以「CAN 通道 + 标准化信号名」抽象，不暴露标识符
    CAN FD 源文档未提供
    接口形态 固件以 Arduino + 专用扩展板实现，经 USB 串口烧写与监控

    已解码信号

    下表登记源文档明确给出的接口面（命令、回报与关键参数）。位置列写接口名而非字节偏移，因为源文档只以标准化信号与回调形式暴露它们；「证据」一列注明其出处为 API 说明、固件说明或构建选项。

    信号 / 接口 位置（API / 模块） 取值与含义 证据
    制动位置命令 publish_brake_position() 归一化 [0.0, 1.0]，转发到制动固件模块 API 说明
    转向力矩命令 publish_steering_torque() [-1.0, 1.0]，-1 为逆时针、+1 为顺时针 API 说明
    油门位置命令 publish_throttle_position() 归一化 [0.0, 1.0] API 说明
    制动回报 oscc_brake_report_s 通过 subscribe_to_brake_reports() 回调 API 说明
    转向回报 oscc_steering_report_s 含转向角；通过 subscribe_to_steering_reports() 回调 API 说明
    油门回报 oscc_throttle_report_s 通过 subscribe_to_throttle_reports() 回调 API 说明
    故障回报 oscc_fault_report_s 通过 subscribe_to_fault_reports() 回调 API 说明
    OBD 原始帧 subscribe_to_obd_messages() 转发车辆 OBD-II CAN 上的非 OSCC 帧，按帧 ID 自行解析 API 说明
    轮速 车辆回报（当前控制状态） 源文档以「转向角与轮速」为例说明可回报的车辆控制状态 项目说明
    使能 / 禁用 oscc_enable() / oscc_disable() 只影响是否可发送命令；回报随时可收 API 说明
    通道开关 oscc_open(channel) / oscc_close() 打开/关闭与 OSCC 控制 CAN 的套接字连接 API 说明
    保活超时 三个发布函数 每个须至少每 200 ms 调用一次，否则模块判失联并自禁用 API 说明
    转向过载阈值 TORQUE_DIFFERENCE_OVERRIDE_THRESHOLD 调整转向人工接管灵敏度；过低会误判、过高难接管 构建/配置说明
    电压范围检查 API 内部安全校验 拒绝发送超出车辆预期范围的电压 API 说明

    读取方法与注意事项

    生命周期由三组调用界定：oscc_open(channel) 打开控制 CAN 的套接字，oscc_enable() / oscc_disable() 决定是否允许发送命令，oscc_close() 结束。源文档提示 API 会捕获 CAN 帧到达时的 SIGIO 信号并注册处理器转发有效帧，因此在容易被中断冲突的代码段应临时屏蔽该信号、之后再解除。

    最关键的运行约束是节拍：三个发布函数每个都必须至少每 200 ms 调用一次，否则固件模块会判定与上位机失去通信并自行禁用。也就是说，「不发命令」本身是一种保护动作；程序崩溃或卡顿时会自动退出控制，这是设计意图而非缺陷。

    人工接管方面，源文档默认对所有模块启用接管检测，但明确提示：系统激活时试图抓方向盘可能造成严重伤害，推荐用制动踏板或急停按钮作为转向接管手段；如需关闭转向接管检测，可在构建时传 -DSTEERING_OVERRIDE=OFF。构建还需按车型选择标志（-DVEHICLE=kia_soul、kia_soul_ev 或 kia_niro）；对早于 1.2.0 的执行器控制板，需加 -DBRAKE_STARTUP_TEST=OFF 以跳过与该板不兼容的启动测试。

    证据等级与边界

    本文的证据等级是「项目文档级」：命令取值区间、回调接口、200 ms 保活与构建标志都可在源文档逐条核对，属于直接证据；但源文档没有逐信号解码表，也没有实车日志，因此本文不提供标识符、字节偏移或缩放系数。要落到具体字节，需回到固件与车型头文件（本快照未包含逐字节定义）。

    两点不能外推。第一，源文档明确「目前仅支持 2014 年及以后的 Kia Soul」（汽油与纯电），Kia Niro 为构建目标；把接口面外推到其他起亚车型或其他品牌属于超范围。第二，各模块的板卡版本与固件版本需按源文档的对应表配套使用，混用可能触发已知安全问题的旧版本；源文档特别强调应及时更新。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；项目自述其设计不改变厂方安全用例、不伪造 CAN 消息、不入侵 ADAS 功能，本档案仅描述这一接口面。

    常见问题

    为什么命令必须每 200 ms 发一次？

    因为固件模块以 200 ms 作为与上位机的通信存活判据：任一发布函数连续超过该时间未被调用，模块就判为失联并自行禁用。这是有意的失效保护——程序卡死时会自动退出控制，而不是保持最后一个命令。

    转向接管该怎么做？

    源文档建议用制动踏板或急停按钮，而不是直接抓方向盘——后者在系统激活时可能造成严重伤害。若确实要关闭转向接管检测，可用 -DSTEERING_OVERRIDE=OFF 构建；保留检测时，灵敏度由 TORQUE_DIFFERENCE_OVERRIDE_THRESHOLD 调整，过低会在大扭矩区误判、过高则难以手动接管。

    能从这套系统直接读到车辆的所有信号吗？

    不能仅凭本文判断。API 提供的是结构化回报（制动/转向/油门/故障）与一个 subscribe_to_obd_messages() 回调，后者转发车辆 OBD-II CAN 上的非 OSCC 帧，需要按帧 ID 自行解析。源文档未给出这些帧的逐字节定义。

    这套接口能套用到别的起亚车型吗？

    源文档明确目前仅支持 2014 年起的 Kia Soul（汽油与纯电），Kia Niro 为构建目标；API 与固件按易扩展设计，但新增车型需按车型头文件格式补齐信息。直接外推到其他车型超出源文档证据范围。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/polysync-oscc/README.md（本项目车型档案主来源：API 与固件接口、命令归一化范围、200 ms 保活、构建标志与支持车型）。
    • 项目 01 —— public-can-dbc-datasets/additional/polysync-oscc/LICENSE.md（硬件为 CC BY-SA 4.0、固件与软件为 MIT 的许可划分）。

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

    更新记录

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

  • SAM 项目车 CAN 档案：125 kbit/s 与 37 条消息

    结论：SAM 项目车是一台 125 kbit/s、11 位标准帧的小型电动车，其 CAN 数据档案的价值不在「抓到多少」，而在「修正了多少」：源文档的 DBC 共 37 条消息、161 个信号，并对早期手工整理的布局逐条做了修正——多处把原本当成无符号的字段改正为有符号，还把两个电压刻度由「1」改为实测拟合值。源文档同时明确区分「该车的总线」与「另一台装原厂 BMS 的车」。以下所有结论仅限源文档记录的车辆。

    车辆与适用范围

    本文数据来自第三方开源项目对 SAM 项目车的 CAN 记录与 DBC 修正。项目用某类商业 CAN 记录仪采集 trace，并开发了一个查看器来浏览器与逐帧回放；DBC 的修正以注释形式叠加在文件内。

    项 内容
    车型 源文档以 SAM 指代的一台项目车；具体量产车型未确认
    年款 / 市场版本 源文档未确认
    电控与改装 车上装有自研仪表（STM32）与自研 BMS；源文档同时对照另一台仍装原厂 BMS 的车（在参考日志中的那台）
    采集跨度 两种记录格式（某类商业 CAN 记录工具导出的 `.trc` v2.0 文件，与 SAM 侧记录器导出的纯文本），覆盖行驶、充电与静置场景
    适用范围 仅限源文档记录的这两台车；两车的 BMS 变体不同，报文与周期存在差异

    总线与寻址

    这是一条相对「干净」的台架总线：速率不高、ID 位宽是标准 11 位，车的电控又是自己开发的，因此信号的字节布局大体可从自身设计反推——但仍有多处需要靠实测数据才能定标。

    项 内容
    速率 / 帧格式 125 kbit/s；11 位标准帧
    DBC 规模 37 条消息（`BO_`）、161 个信号（`SG_`）
    修正方式 修正以 `CM_` 注释形式叠加在 DBC 内，逐条标注依据与是否已确认
    多路复用 存在被多路复用的消息（如充电机信息与仪表时间同步共用同一 ID）
    对照来源 除实车 trace 外，还用车辆仪表的报文处理逻辑做交叉对照

    已解码信号

    下表从源文档的修正记录中抽取。项目把依据分成几类：与仪表固件一致（可认为已确认）、与另一条可信信号比值拟合（已确认）、以及仅从原始数据推断、尚无固件旁证（标注为推断）。本文原样保留这些标注。

    信号 位置（ID / DID / 字节） 解码 证据
    电池电压 0x186（消息 390） 每计数 0.0625 V 已确认
    电池电流 0x386（消息 902） 有符号；10 Hz 已确认（由无符号改为有符号）
    电机转速 0x390（消息 912） 有符号 已确认（由无符号改为有符号）
    电机扭矩（实际，skai_torque） 0x290（消息 656）内的 int16 字段 刻度为推断 非固件确认（源文档明确标注）
    直流母线电压 0x290（消息 656） 因子由 1 改为 0.1 已确认（与电池电压比值 0.0997±0.002）
    12 V 电压 0x291（消息 657） 无符号 已确认（由有符号改为无符号；读数约 13.8 V）
    充电机高压 VoltageHV 0x1C0（消息 448） 因子由 1 改为 0.0625 已确认（比值 0.06211±0.00001）
    充电机温度 / 散热器温度 0x1C0（消息 448） 有符号修正 已确认
    电芯电压 0x406，轮转槽位 mV 标定记录（新 BMS 轮转 37 槽，原 BMS 以 cell 0 作填充）
    电芯温度 0x406 摄氏度 标定记录
    BMS 状态 / 剩余能量 0x306（消息 774） — 标定记录（新 BMS 变体下为占位值，原 BMS 为真实值）
    FECU 故障位掩码 0x292（消息 658）B5:B7 位掩码，需按仪表固件的字节序重建 已确认（与仪表报文处理逻辑交叉核对）
    请求扭矩 requested_torque 0x191（消息 401） — 未固件确认

    读取方法与注意事项

    第一条是字节序与符号位。源文档对若干字段做了符号修正：电池电流、电机转速原本被当成无符号，实际是有符号；而 12 V 电压则相反，原本当成有符号，实际是无符号。这类错误不会让程序报错，只会让数值在某个区间里「看起来合理、其实错位」，所以必须逐字段核对。

    第二条是多路复用。源文档指出有消息在仪表侧被复用于多个子报文，例如充电机信息与仪表时间同步共享同一 ID；解析时必须先按子报文的标志位区分，否则会把时间同步的字节当成充电机参数读。项目对涉及掩码的字段做了专门的屏蔽处理。

    第三条是校验和字节序重建。故障位掩码所在的字段不是简单的 24 位小端，源文档依据仪表固件的处理逻辑做了字节序重建，并用一条实车记录验证了修正前后的差异（修正后的取值与预期一致）。这说明「字段看起来是连续的」并不等于「可以直接按小端读」。

    证据等级与边界

    源文档把修正依据分层：与仪表固件一致、或与另一条可信信号做比值拟合的，标为已确认；仅从原始数据推断、没有固件旁证的，明确标注为推断。例如电机扭矩的刻度就是推断值——虽然原始 int16 字段的位置确定，但「一计数等于多少牛米」尚未被固件证实。

    另一条重要边界是「BMS 变体」。源文档把车分成两类：一台装新开发的 BMS（参照原厂设计但不完全相同），另一台在参考日志里仍装原厂 BMS。两者在若干报文上的行为不同——例如电芯电压轮转的填充槽位、某些报文的周期（1 Hz 与 10 Hz）。因此同一辆车的档案也要先确认 BMS 变体。

    边界上必须强调：以上信号位置与刻度都限定在源文档记录的这些车辆与这一版 DBC。不同 BMS 变体、不同固件之间差异明显，跨车使用前必须重新核对。

    常见问题

    为什么这辆车的 DBC 要反复修正？

    因为早期 DBC 是手工整理的，存在真实错误：多个字段被错判符号（电池电流、电机转速被当成无符号；12 V 电压被当成有符号），两个电压的刻度也不对（由 1 改为实测拟合值）。源文档逐条记录了修正依据，并区分「已确认」与「推断」。

    电机扭矩的刻度为什么只标「推断」？

    因为该字段的位置是确定的原始 int16，但「一计数等于多少牛米」没有得到仪表固件的证实，只能从数据推断。源文档没有把它当作已确认值，使用时应保留这一不确定性。

    同一车系为什么会有两套 BMS 行为？

    因为源文档对照了两台车：一台装新开发的 BMS，另一台仍装原厂 BMS。两者在报文周期与电芯电压轮转的填充方式上都不同（例如新 BMS 轮转 37 槽而原 BMS 以 cell 0 填充）。解析前必须先确认 BMS 变体。

    这些修正能直接套到别的车上吗？

    不能。源文档的结论限定在被记录的车辆与 DBC 版本上，不同 BMS 变体与固件之间的差异已被证实存在。跨车使用前必须重新核对。

    延伸阅读

    参考资料

    • 项目 06 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/PROJECT_NOTES.md（本项目车型档案主来源：DBC 修正项、BMS 变体与效率图方法）
    • 项目 06 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/README.md（查看器与记录格式说明）
    • 项目 06 —— public-can-dbc-datasets/additional/janniksteiner-sam-can/SOURCE.md（DBC 规模与来源说明）

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

    更新记录

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

  • Ioniq 5 电池预热的 CAN 报文：两段最小可复用样本

    结论：这份档案记录的是现代 Ioniq 5 / 6 / EV6（E-GMP 第一代）电池预热（preconditioning）手动开关背后的最小可用 CAN 报文集合（MWE）。源文档把 2021–2024 年 E-GMP 车上的「触发预热」与「取消预热」压缩成两份可回放的报文集，其中主触发报文 ID 为 0x4ED，取消报文涉及 0x0C7。要点在于：预热可以只用少数几条报文、靠被动旁听加回放实现，不需要车机越狱。需要注意，随本快照归档的是作者过滤后的回放样例，不是原始全总线抓包，也没有配套 DBC。

    车辆与适用范围

    源文档是一个硬件改装的公开文档仓库，围绕「给 Ioniq 5/6/EV6 增加一个手动预热按钮」展开，CAN 报文逆向是其中一环。

    项 内容
    车型 Hyundai Ioniq 5 / Ioniq 6 / Kia EV6（E-GMP 第一代，带电池 PTC 加热器）
    年款 / 市场版本 源文档讨论 2021–2024 年 E-GMP 车；这两份 CSV 的采集车年款/配置/市场/固件未指定
    ECU / 改装状态 加装微控制器注入 CAN 报文（WiCAN 系硬件）+ 线束；也用 WiCAN 网页远程开关
    采集跨度 两份最小可用样本：MWE_preconditioning.csv（230 行）与 MWE_cancel_preconditioning.csv（5 行）
    适用范围 仅限带 PTC 加热器且已启用预热模式的 E-GMP 车；源文档称必要报文于 2026 年 3 月分离出来

    总线与寻址

    源文档的样本以 SavvyCAN 兼容文本保存（时间戳单位为微秒），列含 ID、扩展帧标志、方向、长度与数据字节。抓取工具为 WiCAN Pro（另一份清单说明还用了 SavvyCAN）。下表按这两份 CSV 可确认的内容填写，未给出的一律标注「源文档未给出」。

    项 内容
    物理层 源文档未给出（经 OBD 形态的 WiCAN 接入）
    链路层 / 比特率 源文档未给出
    寻址方式 样本中报文均为 11 位标准帧（Extended=false）
    CAN FD 样本未包含 CAN FD 帧；文档另提及第二代原型机才有一个 CAN FD 接口
    时间戳单位 微秒（SOURCE 说明）

    已解码信号

    下表登记的是这两份 CSV 里可核对到的报文与字段模式，逐条纹目均给出证据（文件名与行数）。源文档把整份材料定位为「MWE 回放样例」，因此没有更细的位域命名与缩放系数；相关的 DBC 由另一项目维护，不在本快照内。

    条目 位置（ID / 字节） 观测载荷（十六进制） 证据
    触发预热帧 0x4ED（8 字节） 00 00 00 00 00 FF FF 1F MWE_preconditioning.csv（230 行）
    触发帧的充电态变体 0x4ED D6–D8 00 00 00 00 00 09 90 00 同上
    取消预热帧 0x0C7（8 字节） 00 00 00 E0 07 00 00 00 MWE_cancel_preconditioning.csv（5 行）
    取消帧的状态字段 0x0C7 D4–D5 E0 07 同上
    触发日志中的另一变体 0x0C7 D4–D5 40 03 MWE_preconditioning.csv
    空闲/复位帧 0x0C7（全零） 00 00 00 00 00 00 00 00 两份 CSV 首帧
    采样工具 — SavvyCAN + WiCAN Pro README「Contents」
    样本规模 — 触发 230 行 / 取消 5 行 SOURCE 说明表

    读取方法与注意事项

    源文档给出一条很实用的方法论主张：一两份好日志比十份可疑日志更有价值。作者建议把日志采集当成一次科学实验——设计「测试条件」与「对照条件」，例如把导航设到附近的充电桩 vs. 设到附近的学校。若都没把握，就对大范围报文画时间曲线找线索。

    数据清理同样关键：作者提到清洗日志（例如剔除带缓冲数据造成的超范围时间戳）后才取得更好效果。文档还列出成套公开工具（含 SavvyCAN 社区分支、DBC 结构入门、基于 DBC 的绘图库等）。

    工程实现上，这套方案由五部分构成：CAN 报文、注入报文的微控制器、该微控制器的固件、把微控制器接到车的线束、以及触发预热的用户界面。触发方式从「用笔记本」到「用 panda 上的星形按钮」都有演示，当前用户界面支持映射到车上既有按钮，物理按钮仍在开发。作者也提醒：另一条「车机越狱」路线更偏技术、没有恢复出厂设置的兜底，且可能被后续 OTA 封堵。

    证据等级与边界

    本档案的证据层级需要分清。可核对的是文件与行数（230 行、5 行）、报文 ID 与字节（0x4ED、0x0C7 的观测载荷），以及工具链（SavvyCAN、WiCAN Pro）。而「这些报文在另一台车上就能触发预热」属于作者自述、未被本归档独立验证——来源说明明确写道：上游称这些报文能在带 PTC 的 Ioniq 5 上启动/取消预热，但本归档未独立复核解码、回放行为或兼容性。

    三处不能外推。第一，这是作者过滤后的回放样例，不是原始全总线抓包，也不是 DBC，因此不能据此推出整车信号全集。第二，采集车的具体年款/配置/市场/固件未指定，不能默认对所有 E-GMP 车成立。第三，文档提到后续 E-GMP 平台与软件版本可能变化，且越狱路线曾多次被封堵，说明结论有时效性。

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

    常见问题

    预热功能是主动问出来的还是被动听到的？

    这份材料记录的是可回放的最小报文集合：两段日志里反复出现的少数几条报文，被整理成可发送的样例。它不涉及对某个 ECU 的主动诊断轮询。

    0x4ED 和 0x0C7 分别是什么？

    按样本，0x4ED 出现在触发预热日志里（230 行，载荷在 FF FF 1F 与 09 90 00 之间切换），0x0C7 出现在取消日志里（5 行，含 E0 07）。本档案只登记观测到的载荷，不代填位域语义。

    能不能套用到其他 E-GMP 车？

    不能默认成立。来源说明指出，这两份 CSV 的采集车年款、配置、市场与固件均未指定，且本归档未独立复核解码与回放行为；要用于其他车辆须自行在实车上验证。

    这套方案需要车机越狱吗？

    不需要。源文档给出的主线是「微控制器 + 线束 + 用户界面」注入报文；文档另提到一条车机越狱路线，但指出它更偏技术、缺少恢复兜底，且可能被后续 OTA 封堵。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/tylerharvey-ioniq5-preconditioning/README.md（本项目车型档案主来源：项目背景、MWE 报文、方法论与工具清单）。
    • 项目 01 —— public-can-dbc-datasets/additional/tylerharvey-ioniq5-preconditioning/SOURCE.md（两份 CSV 的行数、校验值，以及「未独立验证」的边界声明）。
    • 项目 01 —— public-can-dbc-datasets/additional/tylerharvey-ioniq5-preconditioning/preconditioning_messages/MWE_preconditioning.csv（触发预热的最小可用样本）。

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

    更新记录

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

  • Ram ProMaster 2022：三总线与 19 个 UDS 模块

    结论：Ram ProMaster（2022 款，3.6 L Pentastar 配 ZF 948TE 变速箱）是典型的「三总线 + 安全网关」结构：C-CAN / HS-CAN（500 kbit/s，引脚 6/14）、B-CAN / CAN IHS（125 kbit/s，引脚 3/11）、CAN CH（500 kbit/s，引脚 12/13）三条总线速率与用途各不相同，OBD 口后面还有 SGW 安全网关。车速与整车里程在两条不同总线上各有来源，且源文档记录了两者不一致的验证结果。以下所有结论仅限源文档记录的这一台车。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 2022 款 Ram ProMaster 的总线映射与信号分析。项目先用双通道适配器分别接入不同总线，再通过 UDS 读取模块内的数据块，并对同一物理量在不同总线上的表现做交叉验证。

    项 内容
    车型 Ram ProMaster，2022 款
    动力总成 3.6 L Pentastar 发动机（PCM）；ZF 948TE 变速箱（TCM）
    采集硬件 双通道 USBCANFD 适配器，两路分别映射到不同总线（源文档记录了通道与总线的对应关系）
    采集跨度 多次行车与静态采集，涵盖车速、里程、挡位与机油寿命等验证
    适用范围 仅限源文档记录的这一台车；不同年款或不同配置的总线拓扑与 UDS 地址都可能不同

    总线与寻址

    这辆车的接入难点在于「多条总线、多个速率，且后面有网关」。只有先确定每个物理接口对应哪条总线，后续的波形才有意义。

    项 内容
    C-CAN / HS-CAN 500 kbit/s，OBD-II 引脚 6 / 14；OBD 口后面存在 SGW（安全网关）
    B-CAN / CAN IHS 125 kbit/s，OBD-II 引脚 3 / 11
    CAN CH 500 kbit/s，OBD-II 引脚 12 / 13
    诊断寻址 29 位 ISO-TP 物理寻址，形如 18DAxxF1；源文档记录了 19 个模块的地址
    网关 SGW 位于 OBD 口之后；源文档中部分内部总线需要物理接入方式才能观察到，本文不复述具体做法，也不建议尝试

    已解码信号

    下表从源文档的行车分析与离线验证记录中抽取。项目对每一条都注明了验证方式（载体验证、相关系数或读取值），本文原样保留；被否决的条目也一并列出，以说明边界。

    信号 位置（ID / DID / 字节） 解码 证据
    车速 C-CAN 0x101 B0:B2 speed_raw = ((B0 & 0x01) << 11) | (B1 << 3) | (B2 >> 5) 已确认（轮速载体验证）
    车速（第二来源） C-CAN 0x0EE 约等于 8 × speed_raw 已确认（相关 r=0.9999919）
    输出轴转速 0x1F7 rpm 标定记录
    涡轮转速 0x1F7 rpm 标定记录
    整车里程 0x760（从位 8 起的 17 位大端） km 标定记录
    整车里程（ICS） B-CAN，UDS 服务 22 / DID 0x2001 u24 大端 × 0.1 km 已确认（与 0x760 交叉对照）
    机油寿命 PCM，UDS 服务 22 / DID 0x2185 百分比读数 已确认（读取值显示 82%）
    帧校验 0x101 B7 CRC-8 / SAE-J1850 标定记录
    变速箱挡位（候选） 0x1F4 内的 nibble 枚举 被否决（源文档否定该位置）

    读取方法与注意事项

    第一条是「先认总线，再看信号」。三条总线的速率分别是 500、125、500 kbit/s，若适配器接错引脚或用错速率，会直接抓不到帧。源文档为此专门记录了双通道适配器的角色映射，把每一路固定到指定总线。

    第二条是同一物理量的多来源问题。车速在 C-CAN 的 0x101 与 0x0EE 上都有表现（后者约为前者的 8 倍，相关系数 0.9999919），整车里程同时在 0x760 与 B-CAN 的 ICS 数据块里出现（后者由 UDS 服务 22 读 DID 0x2001 得到，u24 大端 × 0.1 km）。使用前应确定以哪一路为准，并核对两路是否一致。

    第三条是负向结果同样重要。源文档明确指出，CAN CH 上的七个高速 ID 都没有通过轮速载体验证——也就是说它们看起来像车速信号，但不能被证实。类似地，0x1F4 里被怀疑是挡位的那个 nibble 已被否决。这些「证伪」结论能避免后续误用。

    证据等级与边界

    源文档的验证手段主要有两类：一类用「轮速载体」做参照，把候选信号与已知的轮速做一致性比对；另一类用 UDS 读取模块自身的数据块（如机油寿命、ICS 里程）作为可信基准。通过比对的标为已确认，未通过的明确记为被否决，处于中间状态的则作为候选保留。

    关于网关，需要格外谨慎：OBD 口后的 SGW 会限制可观察范围，源文档记录的部分内部总线访问方式涉及对车辆网络的物理改动，本文不复述具体做法，也不建议尝试——这类改动有损坏车辆网络的风险，且可能不符合当地法规。

    边界上必须强调：以上总线拓扑、UDS 地址与信号刻度都限定在这一台 2022 款 ProMaster 上。不同年款、不同市场版本的模块地址、总线划分与信号位置都可能变化，跨车使用前必须重新验证。

    常见问题

    为什么这辆车要在三条总线上分别接线？

    因为三条总线的速率与用途不同：C-CAN / HS-CAN 是 500 kbit/s（引脚 6/14），B-CAN / CAN IHS 是 125 kbit/s（引脚 3/11），CAN CH 是 500 kbit/s（引脚 12/13）。用单一速率接单一引脚只能看到其中一部分数据，必须按总线分别接入并设置正确速率。

    车速信号有两个来源，该信哪个？

    0x101 与 0x0EE 上的车速高度相关（r=0.9999919，后者约为前者的 8 倍）。理论上两者一致即可互换使用，但源文档并未就此给出统一建议，使用前应自行在本车上核对两路是否始终一致，并确定以哪一路为准。

    被否决的信号还有参考价值吗？

    有。被否决说明「某位置不是挡位」这类边界已被排除，能避免后来者重复踩坑。源文档同时记录了「CAN CH 上七个高速 ID 均未通过轮速载体验证」这样的负向结论，同样缩小了搜索空间。

    这些 UDS 地址能直接用于别的 ProMaster 吗？

    不能。源文档记录的 19 个模块地址限定在这一台车上，不同年款或市场版本的模块地址可能不同。换车使用前必须重新枚举并复核。

    延伸阅读

    参考资料

    • 项目 05 —— public-can-dbc-datasets/additional/jakeiwen-promaster-2022/docs/bus-map.md（本项目车型档案主来源：三总线映射与 UDS 模块地址表）
    • 项目 05 —— public-can-dbc-datasets/additional/jakeiwen-promaster-2022/findings/2026-07-19_ccan_drive_signal_analysis.md（C-CAN 车速信号与 CRC 分析）
    • 项目 05 —— public-can-dbc-datasets/additional/jakeiwen-promaster-2022/findings/2026-09-22_gear_and_oil_life_offline.md（挡位否决与机油寿命读取）

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

    更新记录

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

  • PACMod 线控 v3 平台档案：4.0.0 到 14.1.0 演进

    结论：这份档案的对象是一套线控（drive-by-wire）硬件改装平台 PACMod 的 DBC 定义，适用于硬件版本 3 及以上，而不是某一款量产车型。它的数据特征不在「某条报文的第几字节」，而在协议随版本演进：源文档是一份从 4.0.0 一路记到 14.1.0 的变更日志，逐版列出新增/删除/改名的报文与信号，并记录了对缩放因子、DLC 与枚举值的破坏性修改。因此它的结论是「哪个版本有哪个信号」，而不是「某一辆车的信号地图」；源文档未给出比特率、寻址方式或逐字节定义，也未指定任何具体车型与年款。

    车辆与适用范围

    源文档是一份随线控硬件项目公开的 DBC 变更记录：它描述该平台对外的 CAN 协议面，用于兼容多种被改装的车辆，而非绑定单一车型。

    项 内容
    车型 搭载 PACMod 线控硬件（rev 3 及以上）的被改装车辆；源文档未指定具体车型
    年款 / 市场版本 源文档未确认
    ECU / 改装状态 线控改装平台，协议覆盖转向、制动、油门、变速箱、灯光、雨刮等子系统的命令与回报
    采集跨度 源文档为发布变更日志（记录至 14.1.0），不含实车日志或事务数
    适用范围 仅对应硬件版本 3 及以上的 DBC；版本不匹配时的报文/字段不可直接套用

    总线与寻址

    源文档以变更日志形式呈现，未描述物理层；它在一条沿革记录里提到曾把比特率补进协议说明文档，但本快照未给出该数值。

    项 内容
    物理层 / 比特率 源文档未给出（仅记录「已把比特率加入协议文档」）
    寻址方式 源文档未给出；命令与回报按 0x600–0x6FF 等地址段预留的描述出现过
    帧长度（DLC） 多次变更：如组件回报从 8 改为 4 字节；车速回报从 2 改为 1 字节
    CAN FD 源文档未提供
    命名约束 受 DBC 规范的 32 字符名称上限约束，超长信号名曾被统一缩短

    已解码信号

    下表抽取源文档变更日志中最有代表性的条目。位置列以「报文 / 信号」表示，解码列记录该版本发生的结构性变化（缩放、DLC、枚举、位域），证据列注明出现的版本号。

    信号 所属报文 该版本的变化 / 含义 证据（版本）
    CONTROL_STATUS / CONTROLLING_SYSTEMS / PERFORMANCE_STATUS TIPPER_BODY_RPT_00/01/02 新增状态字节信号 14.1.0
    DBW_WARNING_LEVEL DBW_HEALTH_RPT_00/01 及 COMPONENT_RPT_00–05 新增线控健康告警等级 14.1.0
    SELF_TEST_STATUS DBW_HEALTH_RPT_00/01 新增自检状态 14.1.0
    SELF_TEST_ALLOWED SAFETY_FUNC_RPT_2 新增是否允许自检 14.1.0
    DOOR_ANGLE / BODY_ANGLE TIPPER_BODY_AUX_RPT_00/01/02 由 ROLL_ANGLE/PITCH_ANGLE 改名而来 14.0.0
    VEHICLE_SPEED VEHICLE_SPEED_RPT 移除 VEHICLE_SPEED_VALID，改为 ERROR/NOT_AVAIL 枚举；DLC 由 2 改为 1 14.0.0
    ANGULAR_SPEED BRAKE_MOTOR_RPT_2 / STEERING_MOTOR_RPT_2 缩放因子由 0.1 改为 0.001 14.0.0
    （组件回报结构） COMPONENT_RPT 移除组件类型、系统存在标志、监督信号与 CAN 超时故障；新增本地状态机状态；DLC 由 8 改为 4 14.0.0
    GEAR_CMD / GEAR_RPT GEAR_CMD / GEAR_RPT 新增挡位命令与回报 13.2.0
    ACCEL_PEDAL_POSITION_VOLTAGE_RPT 等四路电压回报 同名回报报文 新增油门/制动/转向的电压型回报 13.2.0
    BRAKE_PRESSURE_2 / BRAKE_PRESSURE_2_AVAIL BRAKE_AUX_RPT / BRAKE_AUX_RPT_2 新增第二路制动压力及其可用位 13.1.0
    STEERING_FLUID_PRESSURE STEERING_AUX_RPT / STEERING_AUX_RPT_2 新增转向油压 13.1.0
    GNSS_TIME — 新增 GNSS 时间 13.1.0
    ACTUAL_GEAR_RATIO / DRIVELINE_ENGAGED / SHIFT_IN_PROGRESS SHIFT_AUX_RPT 新增实际传动比、传动系结合与换挡进行标志 12.2.0
    COUNTER / COMPLEMENT / SANITY_CHECK_REQUIRED GLOBAL_CMD 新增计数器、补码与合理性检查；配套定义全局命令合理性规则 11.1.0

    读取方法与注意事项

    源文档的读取要点可以归纳为一句：先锁版本，再谈解析。多处变更会破坏向后兼容：车速回报的 DLC 由 2 改为 1 字节，同时把原来的 VALID 位改为 ERROR/NOT_AVAIL 枚举；制动与转向电机回报的角度缩放从 0.1 改为 0.001；组件回报的 DLC 从 8 缩减到 4 并删除了若干字段。用错版本的解析器不会报错，只会静默给出量级错误的结果。

    信号语义方面，源文档反复强调三层数据状态的设计：命令类子系统普遍带 MANUAL_INPUT（人工输入）、COMMANDED_VALUE（被命令值）、OUTPUT_VALUE（实际输出值）三个信号，用来区分「人做了什么」「系统要求什么」「设备实际做了什么」；后续版本又为大量信号补上了 ERROR 与 NOT_AVAIL 枚举值，使「无效」与「不可用」可以被显式表达。解析时不能把这三层当成同一个量。

    命名与数值细节也需留意：负数按二进制补码表示（源文档在 13.0.0 明确写入协议说明）；名称长度受 32 字符上限约束，因此会出现被缩短的名字；雨刮等子系统的高低中枚举值一度从 253/254/255 挪到 248/249/250，旧的硬编码会失配。此外，源文档把 VIN_RPT、WATCHDOG_RPT、YAW_RATE_RPT 标注为「不用于新开发」，其中 YAW_RATE_RPT 已在 14.0.0 被删除——任何依赖它的解析都应及时迁移。

    证据等级与边界

    本文的证据等级是「发布记录级」：每一条都能在变更日志里按版本号核对，属于源文档直接证据；但源文档没有任何实车观测或逐字节定义，因此本文不给比特位置、缩放公式的完整定义，只记录「发生过的变化」。要落到具体字节，必须回到对应版本的 DBC 文件与协议说明文档（本快照未包含）。

    两点不能外推。第一，本档案对应的是硬件 rev 3 及以上；更早硬件、或不同版本 DBC 之间的字段差异，源文档只以变更形式记录，不能假定向下兼容。第二，源文档未指定车型与年款，把某条信号的存在性外推到具体的被改装车辆上属于超范围推断。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只梳理协议面。

    常见问题

    为什么这份档案不写具体字节位置？

    因为主素材是发布变更日志，只记录各版本「新增/删除/改名/改 DLC/改缩放」的结构性变化，逐字节定义在被引用的 DBC 与协议说明文档里，本快照未包含。给出不存在的位域会违背「只写源文档里有的事实」。

    版本不一致会带来什么后果？

    会静默出错。例如车速回报 DLC 由 2 改 1、角度缩放由 0.1 改 0.001、组件回报 DLC 由 8 改 4，用错版本的解析器不会报错，只会给出量级错误的结果。因此必须先锁定硬件与 DBC 版本。

    MANUAL_INPUT、COMMANDED_VALUE、OUTPUT_VALUE 有什么不同？

    三者分别表示人工输入、系统命令值与设备实际输出值。源文档把这三个信号作为命令类子系统的标准配置，用于区分「人做了什么」「系统要求什么」「设备实际做了什么」，不能当作同一个量读取。

    YAW_RATE_RPT 还能用吗？

    源文档在 11.2.0 把 YAW_RATE_RPT 标注为「不用于新开发」，并在 14.0.0 将其移除。依赖它的解析应迁移到替代信号；继续使用旧字段会与新版协议失配。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/astuff-pacmod-v3/doc/changelog.md（本项目车型档案主来源：从 4.0.0 到 14.1.0 的报文与信号变更记录）。
    • 项目 01 —— public-can-dbc-datasets/additional/astuff-pacmod-v3/README.md（DBC 适用范围为硬件 rev 3 及以上，及对外文档入口）。

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

    更新记录

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

  • Waterloo 2024CAR DBC 档案：115 个报文与 890 条信号

    结论：这份档案记录的是滑铁卢大学电动方程式的整车固件仓库，以及其中归档的一份 2024CAR.dbc：115 条报文、890 条信号，另含一份 Vector 独立信号伪报文与逆变器、绝缘监测（IMD）等第三方部件的报文。它不是某一辆车的逐条解码结果，而是「一支学生车队把整车 CAN 定义放进一个固件 monorepo」的处置样本。需要明确两点边界：本快照只包含 README 与来源说明，DBC 本体未包含在内；且来源方声明车辆赛季、硬件装配、物理标度与原始数据权利均未独立核实。

    车辆与适用范围

    源文档来自一支 Formula Student 电动赛车队（UW Formula Electric）的固件主仓库。这里没有「某台实车采集了多少时长」的信息，只有一份被归档的整车 DBC 与它的来源记录。

    项 内容
    车型 车队 2024 赛季电动方程式赛车（由 2024CAR.dbc 文件名标识）
    年款 / 市场版本 源文档未确认具体赛季；命名为 2024，但「车辆赛季未被独立核实」
    ECU / 改装状态 车队自研整车固件，含车辆/HIL 板固件、电池单体测试固件与固件验证台架
    采集跨度 源文档未给出日志数或帧数；仅给出 DBC 的规模数字
    适用范围 仅限该队列的这份 DBC 快照；源文档明确「硬件装配与物理标度未独立验证」，不得当作通用定义

    总线与寻址

    源文档不描述物理层与寻址方式的细节，只在来源说明里交代 DBC 的规模与内容构成。因此下表大部分项标注为「源文档未给出」，而不是代填。

    项 内容
    物理层 源文档未给出（README 仅指向一份通用 CAN 协议教程）
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出
    CAN FD 源文档未提及
    规模 2024CAR.dbc：115 条报文行、890 条信号行
    完整性校验 Git blob 6f64218…；SHA-256 b2901a5c…（源文档给出前段）

    已解码信号

    本快照不包含 DBC 本体，只有 README 与来源说明，因此无法提供逐字节解码。为守住「只抄源文档里有证据的条目」这条线，下表登记来源说明中明确写出的数据资产与部件类别，并逐条注明证据页；任何具体字节、位域与缩放系数，源文档均未提供。

    条目 承载 / 归属 说明 证据
    2024CAR.dbc（整车） — 115 条报文、890 条信号 SOURCE 说明
    Vector 独立信号伪报文 DBC 内 上游工具约定的伪报文，非真实总线流量 SOURCE 说明
    逆变器（inverter）报文 DBC 内 第三方部件流量 SOURCE 说明
    绝缘监测（IMD）报文 DBC 内 第三方部件流量 SOURCE 说明
    ChargerMessages.dbc 仓库内另存 充电机相关，未随本快照复制 SOURCE 说明
    HIL 测试 DBC 仓库内另存 硬件在环测试用，未随本快照复制 SOURCE 说明
    VCU 板固件 make vcu 整车控制单元构建目标 README「Quick start」
    BMU 板固件 make load LOAD_TARGET=bmu 电池管理单元构建/烧录目标 README「Quick start」
    单体测试固件 / 验证台架 仓库内 电池单体测试与固件验证 README 首段

    读取方法与注意事项

    源文档给出的可用操作集中在开发与构建层面：贡献者通过预构建的多架构 dev container 获得统一工具链（ARM GCC、Python 依赖），Windows 走 WSL2 + Dev Containers，构建用 make <board>、make all、make clean，烧录用宿主机的 make load LOAD_TARGET=<board> 或 STM32CubeProgrammer。这一层能保证固件可编译，但不等于能解出实车信号。

    要真正解析这份 DBC，需要把 DBC 文件本身载入基于 DBC 的解析库（README 提到仓库环境使用 cantools，并要求其特定版本）。由于本快照未包含 DBC，本文无法代做任何逐字节解析。标度与物理单位必须以 DBC 文件内容为准，源文档特意提醒「物理标度未独立验证」。

    还有一层法律与合规注意：来源说明指出，在该版本上未找到任何顶级许可证文件或声明的 GitHub 许可证，因此应把它保留为私有离线研究副本，再分发或集成交付前须先确认来源与权利。

    证据等级与边界

    本档案属于项目登记，既不是实车观测，也不是第三方旁证。可以核对的是数字本身（115 条报文、890 条信号、blob 与 SHA-256），以及仓库确是这支车队的固件 monorepo；不能据此认定这些定义能套用到任何一辆实车。

    三处不能外推。第一，「2024CAR」是文件名推断，源文档明确车辆赛季、硬件装配与原始数据的厂商权利均未被独立验证。第二，DBC 里混有第三方部件（逆变器、IMD）与 Vector 伪报文，这些条目代表部件厂商或工具的约定，不是整车厂的车身定义，不能与自研 VCU/BMU 信号混为一谈。第三，快照不完整：ChargerMessages.dbc 与 HIL 测试 DBC 未复制进来，因此不能对整车网络做「全覆盖」结论。

    关于「安全访问」类问题：本文只整理公开文档登记的数据资产，未涉及任何诊断会话或安全访问；源文档未提供绕过方法，且不建议尝试。

    常见问题

    2024CAR.dbc 里有多少报文和信号？

    据来源说明，这份 DBC 有 115 条报文行与 890 条信号行，另含一条 Vector 独立信号伪报文以及逆变器、IMD 等第三方部件报文。

    这份档案为什么没有逐条信号解码？

    因为本快照只包含 README 与来源说明，DBC 本体未包含在内。逐字节、位域与缩放系数都在 DBC 文件里，不在文档中，这是素材边界而非解析遗漏。

    能不能直接用于实车？

    不能。来源方声明车辆赛季、硬件装配与物理标度均未独立核实；同时该版本未声明任何许可证，应仅作为私有离线研究副本，复用前须确认来源与权利。

    这份固件怎么构建和烧录？

    用预构建 dev container 提供统一工具链，构建命令为 make vcu、make all 等；烧录在宿主机用 make load LOAD_TARGET=bmu 或 STM32CubeProgrammer。这只是构建流程，与解析实车信号无关。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/uwaterloo-2024car/README.md（本项目车型档案主来源：固件 monorepo 的结构、构建与烧录流程）。
    • 项目 01 —— public-can-dbc-datasets/additional/uwaterloo-2024car/SOURCE.md（DBC 规模、blob/SHA-256、以及「未独立验证」的边界声明）。

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

    更新记录

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

  • Tesla iBooster Gen1 CAN 档案：两总线与只读踏板信号

    结论：这份档案的对象不是整车，而是一台 Bosch iBooster Gen1 制动助力器的 CAN 输出（Tesla 件号 1037123-00-B，清单标注适配 2016–2020 Model S），被装在 1987 年款的一台改装车上只读采集。它的数据特征是两条 500 kbps 总线、全部只读、状态藏在位置报文里：25/16 引脚的「Vehicle CAN」承载 16 位踏板行程 0x39D，18/10 引脚的「YAW CAN」承载 12 位位置 0x38E 与状态字节 0x38F；助力器只要接通 12V、地、点火即自行助力，不需要任何 CAN 输入。所有数值均为该实物单元的台架实测，不外推到其他 iBooster 变体、其他件号或其他车辆。

    车辆与适用范围

    源文档明确：这里的每一项都在本台实物上测得，不是从社区资料继承的；未验证的内容另列在待验证清单里。以下范围仅对应这一台助力器。

    项 内容
    车型 Bosch iBooster Gen1，Tesla 件号 1037123-00-B（清单标注适配 2016–2020 Model S）；采集对象是助力器本身，非整车
    年款 / 市场版本 件号适配范围由源文档以清单形式标注；具体车辆年款未确认
    ECU / 改装状态 改装车（1987 年款）上的助力器，只读旁听，永不向助力器发送
    采集跨度 多份台架日志：0x38E 46,960 帧 + 0x38F 23,478 帧（合计 70,438 帧，跨四次上电）；0x39D 校验在 2,250 帧上 100% 通过
    适用范围 仅本台实物；触点、装配与固件版本变化都可能改变结论

    总线与寻址

    两条独立总线均为 500 kbps、经典 CAN、11 位标识符，助力器对两条总线都不做内部终端。源文档特别强调：总线要靠内容识别，不能靠适配器索引或 USB 顺序。

    项 内容
    物理层 / 比特率 两条总线均 500 kbps；无内部终端
    「Vehicle CAN」 引脚 25 = CAN-H，16 = CAN-L，静止 36 fps，静止 4 个 ID、踏板活动时 11 个
    「YAW CAN」 引脚 18 = CAN-H，10 = CAN-L，静止约 149.5 fps，2 个 ID
    寻址 / 帧格式 经典 CAN，11 位标识符；0x39D 为 DLC 4，其余多见 DLC 8
    CAN FD 源文档未使用
    供电引脚 引脚 1 = 12V，引脚 9 = GND，引脚 20 = 点火

    已解码信号

    下表抽取源文档中最有代表性的条目，位置与解码保留原文写法（含位运算）。证据一列保留源文档的实测口径：有精确帧数、运行次数与相关系数，也有明确标注为「未解析」「受污染不可引用」的项。

    信号 位置（ID / 字节） 解码 证据
    踏板行程 0x39D b2:b3，DLC 4，25.0 Hz uint16 小端；静止约 262，最大观测 14070；端位 13606 = 43.4 mm 双点标定；mm=(counts-3.3)/320.68（合并拟合）
    行程校验 0x39D b0 (b1+b2+b3+0xA0) & 0xFF 2,250 帧 100% 通过
    存活计数 0x39D b1 每帧 +1 取模 16，高半字节恒 0 实测
    位置（12 位） 0x38E b3 与 b4 低半字节 position = b3 | ((b4 & 0x0F) << 8)；静止 320，满行程约 3052 与 0x39D 两次运行 r=0.999627 / 0.999853
    位置换算 mm 0x38E mm = 0.015207 * position - 4.072（静止 320 → 0.79；满 3052 → 42.34） 偏置为负，为已验证的两种形式之一
    状态枚举 0x38E b4 高半字节 0=初始化、1=正常、2=故障闭锁 断开行程传感器诱导故障确认
    制动标志 0x38E b6 1 位制动应用标志；上沿 2.18–2.42 mm，下沿 1.72–1.75 mm 约 0.55 mm 回差；四次上电下沿复现到 2 counts
    状态字节 0x38F b2 bit 0 = 第二个制动标志（1.45–1.66 mm）；bits 5:3 = 行程/健康状态 四种状态值实测；释放沿受速率限制、不可引用数值
    消息校验 0x38E/0x38F b0 CRC-8/SAE-J1850，poly 0x1D、init 0x00、xorout 0x0A，覆盖 b1..b7 70,438 帧 100% 通过，两个 ID 参数相同
    峰值行程（事件） 0x38D b5:b6 uint16 小端，129.3 counts/mm r=0.99975；与标定行程在 34 mm 内吻合 0.66 mm（n=10）
    制动持续时长 0x37D b0:b1 uint16 小端，27.50 ticks/s r=0.99877；tick 非整数倍，未定（n=10）
    运行时长 0x31D/0x3AD b0:b1 uint16 小端计数，9.99 ticks/s（100 ms） 四次运行确认；分析中作对照列，防伪相关
    静态身份 0x32D（b0 多路复用，0.5 Hz） 五帧按 b0 轮转，四次上电逐字节相同 件号/标定 ID 类数据，与踏板无关
    踩下后事件 0x33D 9.5 Hz，99.8% 时间为全 FF；触发为松开制动后 0.64–2.20 s 与 0x31D 等构成「踩后突发」组，n=10
    故障哨兵值 0x39D 行程 故障时钉在 16354（0x3FE2），校验仍有效 物理不可达，可按范围直接拒绝

    读取方法与注意事项

    三条工程纪律都来自实测教训。第一，必须在 ACK 模式采集：这是一个两节点总线，若用只听（listen-only）模式，没有人应答会导致错误计数每次尝试 +8、约 32 ms 进入 bus-off 后自动恢复并循环，同一 12 秒窗口下表现为 1006 fps 的单 ID 重传风暴，并且会掩盖四个 ID 中的三个；改用 ACK 模式则为 37 fps、四个 ID。ACK 是链路层比特、不是命令，只读采集仍会应答。

    第二，先确认连接可靠。源文档记录：六轮排查（比特率扫描、极性互换、主机供电、ACK 模式）最终发现是助力器端接触不良。要用万用表从适配器接线端子一直通断到助力器引脚，而不是只看夹子「搭在上面」。

    第三，别把总线识别挂在索引上。USB 索引会随重新插拔重排，适配器名称跟随适配器而非线束；识别哪块适配器在哪条总线要按内容——看到 0x39D 的就是 25/16。另一条独立现象是：已供电的收发器在 ECU 未运行时也会停在 2.5V，这只能证明收发器有电，不能证明 ECU 在跑。传感器上电后约 1.47 s 才初始化完成，此前的读数应视为无效。台架接线时，助力器两侧都不做终端，适配器一侧 R120 置 ON。

    证据等级与边界

    本档案是本台实物的台架观测，不是文档推测，也不是外部旁证。最硬的证据是校验与拟合：0x39D 的加和校验在 2,250 帧上 100% 通过；0x38E/0x38F 的 CRC-8 在 70,438 帧上零失败；位置与行程两条独立总线的拟合两次运行在斜率上仅差 0.13%、截距差 0.12%，远紧于它们与标尺的一致度，反过来证明「运行间标定冲突」是测量误差而非传感器问题。

    三处必须原样保留的边界。其一，行程标定精度约 ±2 mm，瓶颈在标尺不在数据：单次保持内信号重复到约 ±20 counts = 0.062 mm，而两次运行之间最多相差 4.4 mm；死区（约 3.5 mm 自由行程）既未被确认也未被否证，因为差额被运行间误差淹没。其二，「踩后突发」组的每个结论都建立在 n=10 的事件上，候选字节远多于事件数；两个 0.999 拟合通过了 20,000 次置换检验，但低于 |r|≈0.9 的一律只作线索，且峰值与时长在本次采集里部分混淆（深踩往往也踩得久）。0x37D b5 与 0x34D b5 因与运行时长混淆，源文档明确不得引用。其三，status == 2 表示「助力不可用」，不是「位置无效」：传感器重连后位置恢复更新而状态仍为 2、助力仍关闭；0x38E 这时是唯一的活动位置来源，0x39D 仍钉在哨兵值。故障会闭锁，只有循环点火才能恢复。

    不能外推的部分：以上数值只对应本台件号的这台实物；源文档列出的踏板传感器引脚（2、8、22、23）等条目来自其他 iBooster 变体的社区资料，属未验证假设，不能写进固件、DBC 或线束。另一个平台（GM Volt）的制动力命令/状态 ID 也被源文档明确标注「不可用于本机」。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只描述只读采集。最后须重申：这是制动执行器，本档案的一切都是读取，没有任何一项是向它下命令。

    常见问题

    为什么不能用只听（listen-only）模式采集？

    因为这是两节点总线：没有 ACK 就没有人应答，助力器的错误计数每次尝试上升 8、约 32 ms 进入 bus-off 后自动恢复并循环。同一 12 秒窗口下，只听模式表现为 1006 fps 的单 ID 重传风暴，并掩盖四个 ID 中的三个；ACK 模式则为 37 fps、四个 ID。ACK 是链路层比特而非命令，只读采集仍会应答。

    故障状态 2 是不是「位置数据无效」？

    不是。它表示「助力不可用」。源文档通过重连实验证明二者不同：传感器重连后位置恢复更新，但状态仍为 2、助力仍关闭，只有循环点火才恢复。因此位置的有效性要按范围单独判断——例如直接拒绝 0x39D 行程大于 13700 的读数。

    踩下踏板的峰值行程与持续时长可信吗？

    在 n=10 事件下，两者拟合分别为 r=0.99975（129.3 counts/mm）与 r=0.99877，且通过了 20,000 次置换检验，可作结论使用；但峰值与时长在本次采集中部分混淆（深踩往往也久），0x37D b5、0x34D b5 与运行时长混淆、源文档明确不得引用。低于 |r|≈0.9 的只算线索。

    12 位位置 0x38E 与 16 位行程 0x39D 该用哪个？

    0x39D 分辨率更高（约 0.003 mm/count 对约 0.016 mm/count），但只有 25.0 Hz；0x38E 为 99.7 Hz、快约 4 倍。对速率敏感的场景，频率比分辨率更重要。另须注意 0x38E 的换算偏置是负的：mm = 0.015207 * position - 4.072。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/pelosim-tesla-ibooster/docs/DECODE.md（本项目车型档案主来源：已确认信号定义、标定与故障信号）。
    • 项目 01 —— public-can-dbc-datasets/additional/pelosim-tesla-ibooster/README.md（只读设计、两条总线的引脚与帧率、采集模式与接线要点）。
    • 项目 01 —— public-can-dbc-datasets/additional/pelosim-tesla-ibooster/docs/PINOUT.md 与 VERIFY_FIRST.md（引脚实测与未验证条目清单、置信度边界）。

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

    更新记录

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