结论：Nissan Leaf（ZE0，2011–2012）最反直觉的一点是：它不实现标准 OBD-II PID——连发送 `0100` 都返回 NO DATA。要读电池，必须用 UDS 服务 0x21 向 LBC（锂电池控制器）索取整块数据（如 39 字节一组的电流、电压、SOC、容量）。同时 Car-CAN 上还有一批被动广播帧（档位、转向灯、里程、车门等）可直接监听。源文档的架构默认只读，从不发送会改变车辆状态的指令。以下所有结论仅限源文档记录的这一台车。
车辆与适用范围
本文数据来自第三方开源项目为 Nissan Leaf 开发的只读遥测仪表盘。项目通过 ELM327 适配器读取标准与非标准数据，并用离线回放、模拟与 MQTT 等多种无车模式做测试，源码中带有大量离线测试用例。
| 项 | 内容 |
|---|---|
| 车型 | Nissan Leaf（ZE0 世代） |
| 年款 | 2011–2012 |
| 接入方式 | ELM327（BLE 或 USB）；源文档另记录自 2026-10-03 起用 CANable 2 接入 Car-CAN |
| 采集跨度 | 两个车辆 profile：Leaf 版 18 项 / 61 个信号 / 33 条历史列；另一台对照车为纯标准 Mode 01（19 项 / 20 个信号） |
| 适用范围 | 仅限源文档记录的这台 Leaf；年份、电池版本与固件差异都可能改变可用数据块 |
总线与寻址
这辆车的读取要分两条路走：一条是主动的 UDS 块数据读取，另一条是被动的广播帧监听。两者的传输参数完全不同。
| 项 | 内容 |
|---|---|
| Car-CAN | 500 kbit/s；11 位标准帧；引脚 6 / 14 |
| EV-CAN | 引脚 13 / 12；源文档要求强制只监听 |
| 适配器参数 | `ATSP6`（ISO 15765-4，11 位 500 kbit/s） |
| UDS 寻址 | 向 LBC 请求用 `ATSH 79B`，接收用 `ATCRA 7BB`；读取服务为 0x21 |
| 被动监听 | 必须关闭自动格式化（`ATCAF0`）才能拿到原始帧 |
| 标准 OBD-II | 本车不实现标准 PID，发送 `0100` 返回 NO DATA |
| 实测吞吐 | CANable 2 在 Car-CAN 上约 1,692 帧/秒、49 个 ID、0 错误帧 |
已解码信号
下表从源文档的信号清单中抽取。项目的置信度分三档：verified（已确认）、static（静态常量）、tentative（暂定），本文按源文档标注保留。
| 信号 | 位置（ID / DID / 字节） | 解码 | 证据 |
|---|---|---|---|
| 高压电流 | LBC 数据块 01 | s32 ÷ 1024 A | verified |
| 电池包电压 | LBC 数据块 01 | u16 ÷ 100 V | verified |
| 12 V 电压 | LBC 数据块 01 | u16 ÷ 1024 V | verified |
| 绝缘电阻 | LBC 数据块 01 | kΩ | verified |
| SOC（荷电状态） | LBC 数据块 01 | u24 ÷ 10000 % | verified |
| 可用容量 | LBC 数据块 01 | u24 ÷ 10000 Ah | verified |
| 单体电压 | LBC 数据块 02 | 96 × u16，单位 mV，量程 3000–4200 mV | verified |
| 电流（第二通道） | LBC 数据块 05 | 16 位回绕：±32 A 之外按 64 A 折叠 | verified（2026-09-03 定案） |
| 档位 | Car-CAN 0x421 | 枚举 | verified |
| 转向灯 | Car-CAN 0x358 | 位标志 | verified |
| 整车里程 | Car-CAN 0x5C5 | — | verified |
| 车门 / 锁 / 灯 | Car-CAN 0x60D | 位标志 | verified |
| 车速 | Car-CAN 0x284 | — | verified |
| 续航 | Car-CAN 0x5A9 | — | verified |
读取方法与注意事项
第一条是「不按标准 OBD 走」。多数车用 Mode 01 就能读到车速、转速等，但本车不实现标准 PID：`0100`（查询支持哪些 PID）返回 NO DATA。因此不能指望通用的 OBD 诊断 App 直接读出电池信息，必须走 UDS 服务 0x21 向 LBC 请求数据块。
第二条是块数据的规模与时序。LBC 的第一个数据块约 39 字节，包含电流、电压、SOC、容量等多个字段；单体电压块则是 96 个 16 位值（对应电池单体），量程约 3000–4200 mV。源文档实测在 CANable 2 上，Car-CAN 约 1,692 帧/秒、49 个 ID、零错误帧，一次完整的 96 节电芯读取约 351 毫秒——这给出了「块读取能不能满足刷新需求」的量化参考。
第三条是回绕陷阱。数据块 05 的电流是 16 位字段：当真实电流超出 ±32 A 时，读数会按 64 A 折叠回绕。也就是说，读到一个看似很低的电流，可能其实是对应的大电流。源文档在 2026-09-03 把这一行为定案。
证据等级与边界
源文档的置信度分三档：verified 表示已在实车或离线回放中确认；static 表示该字段在该车上恒为常量；tentative 表示暂定。表中所列以 verified 为主，原样保留标注。此外项目还保留一台对照车的纯标准 Mode 01 profile，用来区分「Leaf 特有的非标准读取」与「通用 OBD 路径」。
安全边界方面，源文档明确记录了这套工具会发送与不会发送的内容：只发送 UDS 服务 0x21（只读）、标准 Mode 01/03/07，以及适配器自身的监听模式；从不发送会清除或改写 ECU 的指令。EV-CAN 上强制只监听。这一设计把「读车」与「改车」彻底分开。
适用范围上必须强调：以上数据块布局、字段刻度与广播 ID 都限定在这一台 2011–2012 年的 ZE0 上。不同年份、不同电池容量版本（如 24/30/40 kWh）的 Leaf，其数据块与可用 PID 都可能不同，跨车使用前必须重新核对。
常见问题
为什么普通的 OBD 诊断 App 读不到这辆车的电池？
因为本车不实现标准 OBD-II PID，发送 `0100` 会返回 NO DATA。通用 App 依赖标准 PID，自然读不到。要读电池必须用 UDS 服务 0x21 向 LBC（用 `ATSH 79B`、`ATCRA 7BB`）索取数据块。
为什么读到的电流有时明显偏小？
因为数据块 05 的电流是 16 位字段，真实值超出 ±32 A 时会按 64 A 折叠回绕。看到的低值可能对应实际的大电流，需要按回绕规则还原。源文档在 2026-09-03 确认了这一行为。
被动监听需要什么特殊设置？
源文档要求关闭自动格式化（`ATCAF0`），否则适配器会把原始帧「翻译」成标准格式，丢失块数据所需的信息。EV-CAN 上则强制只监听。整轮循环在实测硬件上约 0.58 秒完成。
这套读取方式安全吗？
源文档的设计是只读：只发送服务 0x21、标准 Mode 01/03/07 与监听模式，从不发送清除或改写指令，EV-CAN 强制只监听。即便如此，任何实车操作仍应自行复核并遵守当地法规。
延伸阅读
- UDS 诊断工具为什么不能随手调 —— 只读、会话与写 ECU 的分权，正好说明本文为什么把「读车」与「改车」分开
- 84% 的 PID 没有公开证据 —— 与本文「本车不实现标准 PID」构成了私有协议解析的现实背景
- OBD-II PID 入门：车速 0x0D 为什么是整数 —— 对照本文「连 0100 都返回 NO DATA」的反例
- Talaria 电摩 CAN 档案 —— 同批另一篇电动车档案，对照两车「只监听读车」的不同实现
参考资料
- 项目 08 ——
public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/README.md（本项目车型档案主来源：只读架构、profile 与安全边界） - 项目 08 ——
public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/SIGNALS.md（数据块字段、置信度分级与广播帧表） - 项目 08 ——
public-can-dbc-datasets/additional/davidkarnowski-leaf-ze0/docs/CAN_TRANSPORT.md（适配器参数与实测吞吐）
说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复