结论：2012 款 Nissan Leaf（ZE0）的只读遥测建立在两件事上：ELM327 走 Car-CAN 的 ISO 15765-4（11 位、500 kbit/s），以及一小撮 UDS 服务 0x21 组读取。这台车的标准 OBD-II PID 完全不实现，模式 01 的请求 0100 只会返回 NO DATA；真正的数据来自电池控制器的六组 UDS 应答。所有信号按「已验证、静态、待定」三档标注，其中最大的坑是第五组的包电流：它是有符号 16 位除以 1024，超出正负 32 A 就会以 64 A 为单位折返。
传输层：先把 ELM327 的几条硬约束定死
这套档案把所有适配器的公共事实放在最前面，因为它们决定了后面所有字节能不能拿到。协议用 ATSP6（ISO 15765-4，11 位，500 kbit/s，引脚 6/14 的 Car-CAN）；UDS 对电池控制器需要一组固定的头与流控设置，而针对 Car-CAN 的被动嗅探必须用 ATCAF0——如果保留 ATCAF1，大部分原始帧会直接打印成数据错误。
| 事实 | 细节 |
|---|---|
| 协议 | ATSP6，ISO 15765-4 CAN，11 位，500 kbit/s，Car-CAN（OBD 引脚 6/14） |
| 标准 OBD-II PID | 这台车不实现，0100 返回 NO DATA |
| 电池控制器 UDS | 请求头 ATSH 79B、应答过滤 ATCRA 7BB、格式 ATCAF1、流控头 ATFCSH 79B、块大小与帧间隔设置，另加 ATFCSM1；由整车控制器在 Car-CAN 与 EV-CAN 之间桥接 |
| 被动嗅探 | 必须用 ATCAF0，否则绝大多数原始帧打印为数据错误 |
| 缓冲区 | 未过滤的 ATMA 约 24 帧就溢出，必须配 ATCRA 过滤 |
| EV-CAN（引脚 12/13） | 标准 6/14 接口下不可达，需要改线的 OBD 延长线 |
| 蓝牙连接 | 每次写入都要带应答标志，否则收不到通知 |
同一份档案还维护了一条替代路径：把一台原生 USB-CAN 控制器直接接到诊断口上，由 USB ID 决定走哪条驱动。
电池控制器：六组 UDS 读数的分工
电池控制器的六组数据按职责分开轮询，而不是一次全读。分组第一、二、四、五组标记为已验证，第三与第六组仍属待定。偏移量是相对 61 NN 之后载荷的 0 基位置。
| 组 | 长度 | 内容 | 状态 |
|---|---|---|---|
| 01 电池状态 | 39 字节 | 高压电流两个传感器、包电压、12 V、绝缘电阻、HX、SOC、容量 | 已验证 |
| 02 单体电压 | 192 字节单体数据，解析填充到 200 字节 | 96 路无符号 16 位毫伏，末位之后用 0xFFFF 填充 |
已验证 |
| 03 | 32 字节 | 字节 10–11 为最高单体毫伏，12–13 为最低单体毫伏，其余未知 | 待定 |
| 04 温度 | 18 字节 | 四组「无符号 16 位原始值 + 有符号 8 位摄氏度」，字节 12 看起来是均值 | 已验证 |
| 05 扩展状态 | 74 字节 | 最高/最低单体、温度原始值、放电标志、包电流、绝缘、分段差值与组电压 | 已验证 |
| 06 均衡 | 25 字节 | 24 个数据字节即 192 位，每单体对 2 位，非零疑似表示正在泄放 | 待定 |
第一组的字节偏移
| 字节 | 字段 | 量纲 |
|---|---|---|
| 0–3 | 高压电流传感器 1 | 有符号 32 位除以 1024 安 |
| 6–9 | 高压电流传感器 2 | 有符号 32 位除以 1024 安；在一次 13 分钟行驶中测到负 66 安，库仑积分占 SOC 乘容量推算值的 96% |
| 18–19 | 包电压 | 无符号 16 位除以 100 伏，与 96 路单体之和相差在 0.1 伏内 |
| 20–21 | 12 V 蓄电池 | 无符号 16 位除以 1024 伏 |
| 22–23 | 绝缘电阻 | 千欧 |
| 26–27 | HX | 无符号 16 位除以 100 |
| 29–31 | SOC | 无符号 24 位除以 10000，单位百分比 |
| 33–35 | 容量 | 无符号 24 位除以 10000 安时，SOH 再除以 66 安时 |
| 4–5、24–25 | 未知，静态 | 样本值分别为 0x0287 与 0x00F2 |
电流传感器的行为也定了处理规则：三个电流来源在怠速时绕着零点漂正负 0.5 安，第五组的放电标志跟着噪声走；传感器 1 很粗，以约 2 安为台阶。500 瓦负载下，传感器 2 与第五组相差在 0.05 安以内。于是读取器以传感器 2 为基准逐周期取值，每 5 秒学一次相对第五组的偏移，再叠加上本车的零位标定，并在控制器报告放电时把正电流钳零；仪表侧把绝对值小于 0.6 安（功率小于 0.25 千瓦）视为怠速。
第五组的电流会折返，不是饱和
这是这套档案里最有决策价值的一条。第五组的包电流是有符号 16 位除以 1024，理论上在正负 32.0 安处就该饱和，但这台车的实际电流远大于此。2026-09-03 的一次 13 分钟行驶给出了答案：171 条记录、92 个新鲜第五组样本，第一组传感器 2 达到负 66.5 安。
| 假设 | 超过正负 32 安样本的中位误差（21 个） |
|---|---|
| 线性延伸（第五组等于传感器 2） | 8.49 安 |
| 在正负 32 安处饱和 | 8.49 安 |
| 另一套斜率（半量程） | 11.88 安 |
| 折返（16 位混叠） | 2.50 安 |
饱和假设被直接证伪：邻域超过 40 安的样本没有一个停在轨值上，全部 169 个样本里只有 4 个落在 30 至 32 安区间，绝对电流分布直到边界都是平滑的；最大值只到 31.919 安，而且跨越边界时符号会翻转——传感器 2 为负 34.11 安时第五组读到正 31.71 安，负 47.50 安时读到正 15.57 安，负 41.13 安时读到正 23.58 安。轨内标度则是对的：在三行窗口内传感器 2 移动小于 3 安的 25 个样本中，两者中位相差 0.27 安、最差 1.43 安，拟合关系为 g05 约等于 0.956 倍传感器 2 减 0.199，R² 0.995。
工程后果很具体：读取策略把传感器 2 当作权威值是对的，但如果它每次都在新鲜第五组样本上学习偏移并在样本间传递，那么超过 32 安时学到的差值本身就是折返误差。那次行驶中，融合后的电流相对传感器 2 中位偏离 5.9 安、九十分位 23.6 安、最差 41.1 安，随后「正在放电却读到正电流就钳零」的规则又把大量行驶行直接归零。修正办法是只在第五组读数明确处于轨内、且两次读数接近时才学习偏移。另有一条仍未解决：传感器 1 在负载下读到的是传感器 2 的中位 1.358 倍（十分位 1.294、九十分位 1.429，48 个超过 15 安的样本），而做库仑积分能与 SOC 对上的是传感器 2。
还有一处信任边界：存入数据库的是控制器报告的原值，不再是策略改写后的值。进程量全部落在 current_adj_a 与 power_adj_kw 上，并用 current_adj_src 注明经过的步骤；任何车型档案的策略都不得改写已报告字段。
Car-CAN 被动帧与其他 ECU 探测
车身侧的被动帧必须靠 ATCAF0 加 ATCRA 逐号抓。下面这批已验证的条目构成了挡位、灯光、车门、门锁与胎压的数据源。
| ID | 字节 | 字段 | 解码 | 状态 |
|---|---|---|---|---|
0x421 |
b0 | 挡位 | 08 停车、10 倒车、18 空挡、20 前进、38 经济 |
已验证，五种全部 |
0x174 |
b3 | 粗挡位 | AA 停车或空挡、99 倒车、BB 前进或经济 |
已验证，无法再细分 |
0x358 |
b2 | 转向灯 | 80 关、82 左、84 右、86 危险灯 |
左右已验证，危险灯为社区值 |
0x385 |
b2–5 | 胎压 | psi 等于原始值除以 4，顺序为左前、右前、右后、左后 | 静态，数值合理；小于 5 psi 视为传感器休眠 |
0x5C5 |
b1–3 | 里程 | 无符号 24 位，单位随 0x355 b6 bit5 |
静态，与仪表一致 |
0x5B3 |
b1 | 仪表 SOH | 原始值右移 1 位，百分比 | 静态，与电池控制器一致 |
0x60D |
b0 | 车门 | 08 驾驶位、10 副驾、20 左后、40 右后、80 尾门 |
已验证 |
0x60D |
b2 | 门锁 | 18 已锁、00 未锁 |
已验证 |
0x60D |
b0 / b1 | 灯光 | 04 示宽、02 近光、08 远光、01 雾灯 |
已验证 |
0x284 |
b4–5 | 车速 | 原始值除以 100 km/h | 待定，只见过 0 |
0x5A9 |
b1–2 | 剩余续航 | 无符号 16 位右移 4 位后除以 5 km | 待定，标度未确认 |
0x180 |
b5 | 加速踏板 | 原始值除以 2，百分比 | 待定 |
0x292 |
b6 | 制动踏板 / 制动灯 | 原始值大于 0 即制动 | 待定 |
其他 ECU 的探测结果基本是负的，构成了边界：整车控制器对所有模式 22 与 0x21 请求都返回否定码 0x80，需要原厂会话与安全访问；逆变器与转向模块完全无应答；ABS、车身模块与助力转向会回应第一组读取，尚未解码。EV-CAN 上的 0x1DB、0x1DA、0x55B 等报文虽然有公开社区可视化的布局记载，但在这台车上从未被看到过，档案只把它们作为待核对的假设放在帧仿真器里，而这些编码器刻意不与真实车辆的解码器放在同一处。
| OBD-II 引脚 | 信号 |
|---|---|
| 6 / 14 | Car-CAN 高低，普通 ELM327 用的就是这一对 |
| 13 / 12 | EV-CAN 高低，电池、逆变器与充电机所在网络 |
| 11 / 3 | AV-CAN 高低，信息娱乐网络，本项目不读 |
| 4 / 5 | 底盘地 / 信号地 |
| 8 | 仅在车辆上电时输出 12 V |
| 16 | 常电 12 V |
原生 USB-CAN 通道带来的量级变化
把 ELM327 换成 CANable 2.0 一类的原生 USB-CAN 控制器后，被动项不再需要 ATCRA 加 ATMA 的停留开销，整个循环坍塌为纯 UDS 请求时间。2026-10-03 在这台车上的实测结果是：蓝牙约 2 秒的完整循环压缩到 0.58 秒，第一组读取 0.07 秒、96 路单体读取 0.29 秒；开单体日志后，全新 96 路读取的中位间隔为 351 毫秒（2.77 次每秒，最大 498 毫秒）。
| 项目 | 实测结果 |
|---|---|
| 识别方式 | USB ID 16d0:117e 为 slcan 固件，1d50:606f 或 1209:2323 为 candleLight，0483:df11 为烧录模式 |
| 被动窗口 | 10 秒内 1,692 帧每秒、49 个报文 ID、0 错误帧 |
| 完整循环 | 0.58 秒，含电池各组、96 路单体、暖通模块三组读取和全部被动 ID |
| ISO-TP 间隔 | 暖通模块 在间隔 0 毫秒时丢连续帧（6 次里只有 3 次完整），5 与 10 毫秒时 6 次全通 |
| 终结电阻 | 适配器跳线必须断开；车辆诊断口在 6/14 与 13/12 间测得约 60 欧 |
| 接线基准 | 优先用引脚 5 信号地，而不是承载车身负载电流的引脚 4 底盘地 |
EV-CAN 那条通道则以只听模式为唯一打开方式：只听模式下的控制器连应答位都不驱动，总线在电气上与没有这个监听节点时完全相同；「曼哈顿 EV-CAN」配置项会强制只听，且不提供覆盖开关。需要注意的细节是，不同固件对只听的实现强度不同：candleLight 需要重新打开设备并回读模式，slcan 的静默命令无法从主机侧确认，而 SocketCAN 由内核强制且可被校验。
常见问题
为什么标准 OBD-II 的 PID 在这台 Leaf 上完全读不到？
因为这台车压根没有实现这套标准诊断服务：模式 01 的 0100 请求直接返回 NO DATA。所以所有可用的数据都要从自定义的 UDS 服务走，主要是电池控制器的 0x21 组读与暖通模块 的 0x21 组读。这也意味着通用诊断 App 在这台车上基本拿不到东西。
第五组的包电流为什么超过 32 安就不可信？
因为它是有符号 16 位除以 1024 的字段，没有更宽的备选字段也没有钳位，真实值超出正负 32 安后就会以 64 安为单位连符号一起折返。13 分钟行驶里，邻域超过 40 安的样本没有一个停在轨值上，且跨越边界时符号必定翻转；四种假设中折返假设的中位误差最小，为 2.50 安。处理方式是把第一组传感器 2 作为权威值，并限制只在轨内学偏移。
换成原生 USB-CAN 控制器后，提升具体体现在哪里？
最直观的是被动项的开销消失：原先每个被动项需要一次「设过滤加监听」的停留，约 0.2 至 0.8 秒；原生控制器一直在收全部帧，被动项退化成一次字典查找。结果是完整循环从蓝牙的约 2 秒降到 0.58 秒，单体日志开启时 96 路新读数中位间隔 351 毫秒。另一个区别是它能挂到 EV-CAN 引脚上，而这在 ELM327 方案里做不到。
想在 EV-CAN 上取数据需要什么条件？
需要一根改线的 OBD 延长线，把母座的 6 与 14 分别接到插头的 13 与 12，或者直接通过引出全部 16 针的直通分流接头取 13/12 两针。两条总线同样是 500 kbit/s、11 位 ID，适配器终结跳线必须断开。软件侧把总线标识明确配置为 EV-CAN，强制以只听模式打开。
数据库里存的是不是控制器原值？
是。策略层不再改写电流与功率字段，保留的就是解码器产出的控制器原值；融合偏移、零位标定与放电钳零这些派生步骤全部落在带后缀的调整字段上，并用专门的字段注明经过哪些步骤。另有测试约束所有车型档案不得改写已报告字段。
延伸阅读
- OBD-II PID 入门：车速 0x0D 为什么是整数 —— 说明标准 PID 通路与这台车的差异
- Palisade 只读 CAN 解码器：9 条报文、28 信号与三条边界 —— 另一种只读范围的划定方式
- Tesla Model3 CAN 仿真档案：67 条报文与 5 个锚点信号 —— 电动车同类总线的跨域对照
- 车型 CAN 数据库 —— 按车型比对 UDS 组读与被动帧覆盖率
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/SIGNALS.md（传输层事实、LBC 六组字节偏移、Car-CAN 被动帧、EV-CAN 引脚表与三档置信度分级） - 项目 01 ——
public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/CAN_TRANSPORT.md（原生 USB-CAN 的实现方式、接线与终结要求、只听模式作用域，以及验证与未验证清单） - 项目 01 ——
public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/README.md（只读边界、安全说明与两个车辆档案的规模）
免责声明
本文所有 CAN ID、字节偏移、缩放系数与置信度标注均来自一台 2012 款 Nissan Leaf 的公开只读遥测档案，属社区逆向工程产物，不代表车辆制造商的官方数据，也未经独立实车复现。不同年款与市场区域的字节偏移可能发生变化，标注为待定的内容不得用于计量、交易或安全判定。文中提及的诊断请求仅用于读取，涉及动手接线时请先确认车辆断电状态与终结电阻，本文不构成任何维修、购买或行驶决策的唯一依据。
更新记录
- 2026-10-15 初稿
发表回复