结论：Honda Civic FL5 的数据特征与多数车相反：OBD 口后面存在网关，且总线上几乎抓不到周期性广播帧——必须用 UDS 服务 22（ReadDataByIdentifier）主动向四个模块索取 DID，才能读到 25 个 DID、109 个信号。正因为如此，DBC 不适合做这辆车的主格式。以下所有结论仅限源文档记录的这一台车与其固件版本，不代表同型号其他车辆。
车辆与适用范围
本文数据来自第三方开源项目对一台 Honda Civic FL5 的诊断数据整理。项目以 UDS 服务 22 的读取结果为基础，按模块组织成 DID 与信号清单，并对每条信号标注了证据等级。
| 项 | 内容 |
|---|---|
| 车型 | Honda Civic FL5 |
| 年款 / 市场版本 | 源文档未确认 |
| ECU / 模块 | 共 4 个：0x10 ECM、0x28 VSA、0x30 EPS、0x60 仪表（组合仪表） |
| 采集跨度 | 数据集 25 个 DID、109 个信号；源文档记录版本 1.0.1 |
| 适用范围 | 仅限源文档记录的这一台车与其固件；DID 布局与信号刻度不保证适用于其他年款或市场版本 |
总线与寻址
这辆车是经典 CAN 加主动诊断读取的典型：总线上没有可供解析的周期广播流，价值的全部来源是「问—答」。因此寻址方式、传输层时序与请求节奏比 DBC 更重要。
| 项 | 内容 |
|---|---|
| 物理层 / 速率 | 经典 CAN 2.0B，500 kbit/s，无 CAN FD |
| 接入点 | 标准 OBD-II（J1962）引脚 6 / 14 |
| 网关 | OBD 口后存在网关；源文档实测总线上为零周期性广播帧 |
| 诊断寻址 | 29 位 ISO 15765 物理寻址：请求 18DA<目标>F1，应答 18DAF1<目标>，诊断仪地址固定为 F1；功能广播为 18DB33F1 |
| 传输层 | ISO-TP（ISO 15765-2）：首帧宣告长度，随后连续帧，接收方回 30 00 00 流控帧；数据区 54–63 字节，填充 0xAA |
| 11 位寻址 | 在 7E0 / 7E8 上发标准 Mode 01 无应答 |
已解码信号
下表从源文档的信号清单中抽取最具代表性的条目。项目的置信度分为「已确认（研究级）」「中」「低-候选」三档，表中原样保留该标注；标为「中」的条目表示解码方向明确但仍缺独立旁证。
| 信号 | 位置（ID / DID / 字节） | 解码 | 证据 |
|---|---|---|---|
| ENGINE_RPM（发动机转速） | DID 0x2610 B6:B8 | raw × 0.25 rpm | 已确认（研究级） |
| MAP_ABS（绝对进气压力） | DID 0x2610 B9:B11 | raw × 0.0078125 kPa | 已确认（研究级） |
| ECT（冷却液温度） | DID 0x2610 B11 | raw − 40 ℃ | 已确认（研究级） |
| VEHICLE_SPEED（车速） | DID 0x2610 B18 | raw km/h | 已确认（研究级） |
| OIL_PRESSURE（机油压力） | DID 0x2610 B44:B46 | raw kPa | 已确认（研究级） |
| OIL_TEMP_MODEL（机油温度模型） | DID 0x268F B15 | raw − 40 ℃ | 已确认（研究级）；源文档标注该信号在公开资料中无先例 |
| BRAKE_PRESSURE（制动压力） | DID 0x4005 B7:B9 | raw − 25 bar | 已确认（研究级） |
| STEER_ANGLE（方向盘转角） | DID 0x48BD B11:B13 | s16 × 0.1° | 已确认（研究级） |
| WHEEL_SPEED_FL / FR / RL / RR | DID 0x48C4 B23:B31 | raw × 0.01 km/h | 已确认（研究级） |
| STEER_MODE（转向模式） | DID 0x48AC B1 | 枚举 | 中 |
| FUEL_LEVEL（燃油液位） | DID 0x7029 B12:B14 | raw × 0.01 L | 已确认（研究级） |
| AMBIENT_TEMP（环境温度） | DID 0x7028 B17 | raw ℃ | 已确认（研究级） |
读取方法与注意事项
这辆车读数据必须走 UDS 服务 22。请求用 29 位物理寻址发到 18DA<目标>F1，模块在 18DAF1<目标> 上应答；诊断仪地址固定为 F1，功能广播是 18DB33F1。注意 11 位寻址（7E0 / 7E8）上的标准 Mode 01 在本车上没有应答。
一旦某个 DID 的应答超过单帧容量，就会落到 ISO-TP 分段传输：模块先发一个首帧（形如 10 29 …）宣告总长度，再发若干连续帧，诊断仪需要及时回一个流控帧 30 00 00 授权它继续。源文档特别指出，流控帧如果晚回几毫秒，ECU 会放弃整笔传输——所以「问得到」不等于「收得全」，接收端的流控时机是硬约束。
工程上还要考虑读取节奏：同一模块上多个 DID 需要轮流询问，模块之间（ECM / VSA / EPS / 仪表）也要分配请求配额，否则在高频轮询时容易触发超时或让 ECU 返回否定应答。源文档记录了若干次安全访问被拒的情形，未提供绕过方法，也不建议尝试。
证据等级与边界
项目的证据等级分「已确认（研究级）」「中」「低-候选」三档。已确认条目既有编码依据也有行为或参考交叉验证；「中」表示解码方向明确但缺少独立旁证；「低-候选」则是尚未闭环的猜测。本文抽取的信号以已确认为主，并原样保留了 STEER_MODE 的「中」标注。
项目文档中有一节专门列出「已推翻的说法」，条目数量在三十条以上——说明这辆车的诊断数据在公开讨论里存在大量误传。阅读时要把「已推翻」与「已确认」严格分开，不要把早期猜测当作结论使用。
边界上必须强调：25 个 DID 与 109 个信号全部来自这一台车的这一版固件。不同年款、不同市场版本的 DID 编号、字节偏移与刻度都可能变化；同一 DID 在不同固件下含义也未必一致。任何实车读取都应在目标车上逐条复核。
常见问题
为什么这辆车用 DBC 解析不出来东西？
因为源文档实测其总线上没有周期性广播帧，OBD 口后还有网关。DBC 描述的是「谁在什么时刻广播什么布局的帧」，而这辆车的数据要靠 UDS 服务 22 主动索取，表现形式是「问—答」而非广播，所以 DBC 不适合作主格式。
读一个 DID 需要满足哪些传输层条件？
用 29 位寻址发请求到 18DA<目标>F1，模块在 18DAF1<目标> 应答；如果应答超过单帧，模块会先发 ISO-TP 首帧宣告长度，诊断仪必须及时回 30 00 00 流控帧。源文档指出流控晚回几毫秒 ECU 就会放弃整笔传输。
标准差一点的信号还能用吗？
要按证据等级区分。标为「已确认（研究级）」的可以直接用；标为「中」的（如 STEER_MODE）解码方向明确但缺独立旁证，使用前应自行验证；「低-候选」的不要作为结论。源文档对每一条都保留了原始标注。
这些 DID 能套用到别的 Civic 上吗？
不能。源文档的全部结论限定在这一台车与其固件版本上，且明确 DID 编号、字节偏移与刻度都可能随年款或市场版本变化。换车使用前必须重新读取并复核。
延伸阅读
- UDS 诊断工具为什么不能随手调 —— 只读、会话与写 ECU 的分权，正好解释了本文为什么只谈服务 22 的读取
- 84% 的 PID 没有公开证据 —— 与本文「25 个 DID 逐条标注证据等级」是同一套方法论
- OBD-II PID 入门：车速 0x0D 为什么是整数 —— 对照本文「11 位寻址上 Mode 01 无应答」的差异
- Vtrux 与 Coda EV 的 CAN 信号档案 —— 同批另一篇车型档案，对照「零广播帧」与「多总线广播」两种极端
参考资料
- 项目 02 ——
public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/README.zh-CN.md（本项目车型档案主来源） - 项目 02 ——
public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/CHANGELOG.md（版本与已推翻说法的变更记录） - 项目 02 ——
public-can-dbc-datasets/additional/caldis-honda-civic-fl5-dids/SOURCE.md（数据集版本与来源说明）
说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复