结论：2024 LiveWire S2 Del Mar 的公开 CAN 资料给出了两件东西，用途完全不同：副总线的广播 .dbc（60 条报文、111 个信号）和一份跨 9 个诊断模块的 UDS DID 目录。转速、车速这类实时量直接从广播拿；电池单体电压、ABS 轮速、绝缘电阻这类不广播的数据，必须走 BCM 网关用 0x22 读——把它们混为一谈是初学者最常见的错。
总线事实：先记这四条
这份社区资料把前置条件写得非常干净，接入之前四条必须对齐。
| 维度 | 取值 | 错配后果 |
|---|---|---|
| 速率与类型 | 500 kbit/s，classical CAN，11 位标准 ID | 按 CAN FD 或扩展帧配置时完全解不出帧 |
| 字节序 | big-endian，Motorola 起始位记作 @0 | 多字节信号反向拼接，数值量级明显偏大 |
| 保护机制 | 约 36 个 ID 带 E2E 保护（AUTOSAR Profile-1 风格） | 自定义解析时未跳过校验字节，信号整体错位 |
| 拓扑 | 副总线上只有 BCM、IM、TCU、DLC；电机、BMS、ABS 在主总线 | 在副总线上找电机转速，永远找不到 |
第三条 E2E 保护值得单独说：D7 是 6 位 alive counter，D8 是覆盖 D1 到 D7 的 CRC-8 / SAE-J1850（多项式 0x1D，初值与异或输出均为 0xFF）。它的价值不在于安全，而在于充当解码预言机——位对齐一旦算错，CRC 立即失败，不需要等到物理量不合理才发现问题。这是逆向过程中极少数可以机器判定对错的抓手。
九个模块各管什么
副总线的广播成员是 BCM（网关）、IM（仪表）、TCU、DLC 四个，其余全部在主总线上，通过 BCM 网关用 ISO-TP 上的 0x22 ReadDataByIdentifier 读取。下面这张表是挑选 UDS 模块时的直接依据。
| 模块 | 请求与响应 ID | 角色 | 能拿到的关键数据 |
|---|---|---|---|
| BCM | 0x7E2 → 0x7EA |
车身控制器，副总线网关 | 纵向加速度 ADC 快照、内部 mV 电源轨、时间同步、骑行模式配置表、防盗与钥匙块 |
| VSC | 0x7E4 → 0x7EC |
车辆监控控制器，监管 ABS 与 IMU | 实时电机转速与驱动状态、扭矩记录、油门位置、电池包端电压、当前骑行模式序号及逐模式标定三元组 |
| RESS | 0x7E6 → 0x7EE |
高压电池管理，信息价值最高的模块 | 逐单体电压阵列、逐单体温度阵列、包电流双传感 A/B、SoC/SoE/SoH、累计安时 |
| EHCU | 0x7E7 → 0x7EF |
Bosch ABS 液压单元 | 双路逐轮轮速、前制动压力、制动激活标志、12 V 辅助电源轨、ABS 事件计数器 |
| OBC / HV | 0x7D3 → 0x7DB |
车载充电机，交流充电时才活跃 | 充电器与枪状态、充电电流与功率、充电机散热片温度、母线电压 |
| TCU | 0x7D4 → 0x7DC |
远程通信，含 eSIM 与 GPS，隐私敏感 | GPS 位置、信号强度、归属网络、固件版本 |
表里没有列的还有 LHCM（0x7E3，识别信息与硬件件号，同时携带 VIN）、RHCM（0x7E5，制动激活标志与内部参考电源轨）、以及一个 ID-only ECU（0x7F0 → 0x7F8，只有供应商件号、没有任何实时数据块，属于硬上限）。
需要注意的是，9 个已映射响应者是下限而不是总数。资料明确提到存在一个未映射的响应方（响应 0x6E6 / 请求 0x6DE）被被动观察到，另有目标地址 0x7F2；并且 IMU 本身没有 UDS 地址，它由 VSC 监管。这意味着你在总线上看到的地址比这张表多，是预期行为。
读懂它的置信度标注
这份资料最值得模仿的不是结论，而是它把不确定性强塞进数据结构里：每条信号的行内注释都带四类信息——置信度、标定依据、已撤回的假设与尚未解决的疑问。[CONFIRMED]（两种以上方式交叉验证）、[STRONG]（一次干净抓包且物理一致）、[TENTATIVE]（数据不足）。已撤回的假设会原样保留而不是删除，避免后来者重复尝试同一条死路。
这套标注的实际用法：写解析代码时，只对 [CONFIRMED] 与 [STRONG] 做断言和告警，[TENTATIVE] 一律只记录不做判断。把三级标注 flatten 成一个 schema，等于把作者的证据强度信息彻底丢弃。
它的取证方法也相当严格：单人单次动作隔离抓包 + 差分分析；一次相关只构成假设，必须有第二次「专门设计来推翻它」的抓包失败才算成立；未被动作覆盖的字节标记为未解，而不是当作常量写死。这套流程解释了为什么 111 个信号里真正能用作线上判据的比例并不高——大量位置至今没有足够证据。
三条使用边界
第一，0x27 SecurityAccess 门禁：BCM、VSC、TCU 上有 16 个 DID 被上锁，种子为 128 位随机数，其内容是按相邻关系推测的，不是读出来的。任何把推测值当成实测值的下游都会出错。第二，隐私：车主 PII 在这份公开副本中被抽掉，VIN、模块序列号、GPS 坐标与 SIM 标识都变成占位符，但结构完整，复现时必须自己填自己的值。第三，版本状态：整体标注为 v0.1 进行中，TENTATIVE 条目可能错误或不完整；并且它只描述如何读取与理解总线，不含任何执行动作的方法。
常见问题
电机转速和电池单体电压能不能直接从副总线广播里读？
不能。副总线上的广播成员只有 BCM、IM、TCU、DLC 四个，电机/逆变器、电池、ABS、充电机、远程通信都在主总线上，需要通过 BCM 网关用 ISO-TP 上的 0x22 ReadDataByIdentifier 主动读取。能直接广播读到的只有广播成员的那些信号。
E2E 的 CRC 除了校验还有什么用？
它是逆向时的位对齐预言机。约 36 个 ID 采用 AUTOSAR Profile-1 风格保护，D7 为 6 位 alive counter，D8 为覆盖 D1 到 D7 的 CRC-8 / SAE-J1850，多项式 0x1D、初值与异或输出 0xFF。只要起始位或长度算错，CRC 立即失败，可以在物理量失真之前发现错位。
已映射的 9 个模块是不是这辆车的全部 ECU？
不是，作者明确写这是一个下限。被动观察到的还有一个未映射响应方（响应 0x6E6、请求 0x6DE）以及目标地址 0x7F2；IMU 没有自己的 UDS 地址，由 VSC 监管。也就是说实际地址数会多于这 9 个。
为什么有些 DID 的内容看起来是「猜」出来的？
因为 BCM、VSC、TCU 上有 16 个 DID 被 0x27 SecurityAccess 上锁，种子是 128 位随机数，作者无法读取其值，只能按相邻关系推测其含义。使用这类字段时必须标注为推测值，不能参与任何判定逻辑。
延伸阅读
- UDS 诊断工具为什么不能随手调：只读、会话与写 ECU 的分权设计 —— 什么时候该用 0x22 读，什么时候必须停手
- Indian Springfield 2017：J1939 摩托车 CAN 档案 —— 另一台摩托车的总线拓扑对照
- openpilot legacy 支持矩阵：可读车型与低速边界登记表 —— 同为把已映射数只当作下限的取证口径
- 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查 —— 如何根据置信标注决定信号能否进入产品
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/inklit-livewire-s2-delmar/README.md（500 kbit/s、11 位 ID、Motorola @0、约 36 个 ID 的 E2E 与 CRC-8 参数、60 报文 111 信号、9 个 UDS 模块、CONFIRMED/STRONG/TENTATIVE 标注体系、取证方法论、CC BY 4.0 授权） - 项目 01 ——
public-can-dbc-datasets/additional/inklit-livewire-s2-delmar/MODULES.md（九个诊断模块的请求与响应 ID、角色与关键数据；9 为下限的说明、0x27 上锁 16 个 DID、IMU 无 UDS 地址、PII 抽除说明）
免责声明
本文所述总线参数、模块地址与信号数量均来自社区公开整理的说明文件，属第三方逆向工程产物，未独立实车验证，也不代表 LiveWire 或任何制造商的官方数据。不同年份、市场与固件版本的 ECU 可能存在差异。涉及 0x27 安全访问的字段为作者推测值。任何改动请以实际测量与官方资料为准，操作在用车存在风险。
更新记录
- 2026-10-14 初稿
发表回复