结论：这份 Honda CL250（摩托车）档案的一个关键事实是：源文档目前没有已知的 CL250 广播报文——它的 cl250.dbc 是零报文、零信号的骨架。可用的数据来自主动 UDS 轮询 5 个 DID：转速、车速、节气门绝对位置、冷却液温度与电池电压，经 ISO 15765-2 单帧传输，主寻址是 29 位 0x18DA10F1（ECU 地址 0x10、测试仪 0xF1），回退到 11 位 0x7E0/0x7E8。工程约束也被写得很细：单请求在飞、基础超时 100 ms、响应挂起（NRC 0x78）翻倍超时、连续 5 次超时跳过该 DID 5 秒。下述内容仅限源文档记录的这一套定义。
车辆与适用范围
源文档来自一个摩托车车载平台项目，它把 CL250 的 ECU 定义与一张项目自建 CAN 分开管理。定义文件说明每个数值都从一份旧固件项目提取，而该旧固件自述「已在真实摩托车上验证过 CAN/UDS 通路」；但来源说明同时指出，那份被引用的仓库在核对时已无法公开访问，没有原始抓包被独立检查过，且部分轮询周期与 11 位回退寻址在源文档里明确标注为未验证。
| 项 | 内容 |
|---|---|
| 车型 | Honda CL250（摩托车），ECU 记为 CL250_ECU |
| 年款 / 市场版本 | 源文档未给出年款与市场版本 |
| ECU / 改装状态 | 原厂 ECU；读取侧是一个测试仪节点（rt-core 或连接节点），只读轮询 |
| 采集跨度 | 源文档未给出日志数；数值来源为一份旧固件项目的提取 |
| 适用范围 | 仅限本套定义；被引用的旧固件仓库核对时不可公开访问，原始抓包未独立检查 |
总线与寻址
源文档把总线参数标为「已验证」的是经典 CAN 500 kbit/s；主寻址与回退寻址分开列出，并明确回退寻址「ECU 实际应答哪一个未被记录」。此外还列了两个只监视（watch-only）的功能地址，用于探测是否存在第二个测试仪。
| 项 | 内容 |
|---|---|
| 物理层 | 双绞线 CAN；经典 CAN（classic_can） |
| 链路层 / 比特率 | 500 kbit/s（源文档标 verified） |
| 主寻址 | 29 位固定寻址：请求 0x18DA10F1、响应 0x18DAF110；ECU 地址 0x10、测试仪 0xF1 |
| 回退寻址 | 11 位：请求 0x7E0、响应 0x7E8；标为未验证（未记录 ECU 应答哪个） |
| 只监视地址 | 功能地址 0x7DF 与 0x18DB33F1，只看不发 |
| 传输层 | ISO 15765-2；帧 DLC=8；补齐字节 0xAA；旧固件只处理单帧 |
已解码信号
下表登记 5 个 DID 的解码，以及关键的服务与会话定义。DID 的公式与「已验证」标记按源文档原样保留；轮询周期一行给出旧固件值与平台建议值，并保留「平台值为暂定」的标注。
| 信号 / 项目 | 位置（DID / 命令） | 解码 / 说明 | 证据 / 置信度 |
|---|---|---|---|
| 转速 ENGINE_SPEED | DID 0xF40C（OBD PID 0x0C） | (A×256 + B) / 4 → rpm，量程 0–16383.75 | 源文档标 verified；旧固件轮询 50 ms，平台建议 110 ms（暂定） |
| 车速 VEHICLE_SPEED | DID 0xF40D（PID 0x0D） | A → km/h，量程 0–255 | 标 verified；优先级 high；平台建议 110 ms（暂定），新鲜度 300 ms |
| 节气门绝对位置 THROTTLE_POS | DID 0xF411（PID 0x11） | A × 100 / 255 → %，量程 0–100 | 标 verified；平台建议 200 ms（暂定） |
| 冷却液温度 COOLANT_TEMP | DID 0xF405（PID 0x05） | A − 40 → °C，量程 −40–215 | 标 verified；平台建议 800 ms |
| 电池电压 BATTERY_VOLTAGE | DID 0xF442（PID 0x42） | (A×256 + B) / 1000 → V，量程 0–65.535 | 标 verified；旧固件的 A/10 启发式未沿用 |
| 诊断会话 | 请求 0x10 0x03 → 正响应 0x50 | 扩展会话；未确认前每 2000 ms 重试 | 标 verified |
| TesterPresent | 0x3E 0x80 | 每 1000 ms 无条件发送（抑制正响应） | 标 verified |
| 允许的服务白名单 | 0x10/0x3E/0x22/0x19/0x01/0x09 | 只读与会话类；禁止 0x11/0x14/0x27/0x2E/0x2F/0x31/0x34/0x36/0x37，并禁止 0x10 子功能 0x02 | 平台策略（D-020） |
| 功能地址监视 | 0x7DF、0x18DB33F1 | 只看不发；看到帧即说明存在第二个测试仪 | 标未验证（标准值，非取自旧固件） |
| 项目自建总线转发 | dbc/platform.dbc | 9 条报文、52 条信号；把轮询到的值再发布出去，不是 OEM Honda 库 | 来源说明 |
读取方法与注意事项
第一是时序预算。源文档记录：同时只有一个请求在飞（IDLE → WAITING → 完成/超时 → IDLE）；基础超时 100 ms；收到 NRC 0x78（响应挂起）时重置并把超时翻倍、上限 2000 ms，且请求仍留在等待态；其它 NRC 则把请求判为完成。连续 5 次超时的 DID 会被跳过 5000 ms。ECU 只要在最近 3000 ms 内有过正响应或任何 NRC，就视为「在线」。
第二是优先级。DID 被分成 high / normal 两类，在同时到期的请求里先服务所有 high（本例中车速为 high，因为它喂给上游的航向估计），列表顺序只作同类内的平局判定。源文档强调优先级只改顺序、不改内容，且每个到期 DID 仍须在其新鲜度窗口内被服务。
第三是 ISO-TP 首帧陷阱。旧固件只处理单帧（PCI 高半字节 0x0）；若收到首帧（PCI 0x1X），其 data[1] 是长度字段的一部分、不是 SID，按 SID 解析会破坏状态。旧固件直接丢弃非单帧帧；由于当前所有 DID 都能放进单帧，这只防未来响应变长。源文档据此写明：完整的 ISO-TP 多帧（首帧 + 流控 + 连续帧）需在新实现里从头做。
第四是总线恢复。进入总线关闭后按指数退避重试：起始 1000 ms、每次翻倍、上限 30000 ms。
证据等级与边界
可视为「文档级已验证」的是 5 个 DID 的公式与主寻址，以及会话/超时/退避这些时序常量——它们都带证据引用。属于明确未验证的是：11 位回退寻址（未记录 ECU 应答哪个）、功能地址监视（标准值，非取自旧固件）、以及平台的轮询周期（源文档标注为暂定，与旧固件周期不同）。
两处不能外推。第一，公式与 DID 只针对 CL250 这一辆车的 ECU 定义；换到其它 Honda 车型需要重新核对。第二，来源说明指出被引用的旧固件仓库在核对时已无法公开访问，原始抓包未被独立检查，因此「已在该车验证」属于源文档的转述，不是本项目的独立复现。
关于「安全访问」类问题：源文档把 0x27（SecurityAccess）列为禁止服务，且未提供任何绕过方法，不建议尝试；本文只整理公开文档登记的只读轮询，不涉及写 ECU 或绕过安全机制。
常见问题
CL250 的报文能不能直接从总线上监听？
源文档表示目前没有已知的 CL250 广播报文，cl250.dbc 是零报文、零信号的骨架；可用的数据来自主动 UDS 轮询 5 个 DID。
轮询哪 5 个值？周期是多少？
转速（0xF40C）、车速（0xF40D）、节气门绝对位置（0xF411）、冷却液温度（0xF405）、电池电压（0xF442）。旧固件周期为转速 50 ms、其余 800 ms；平台建议值为 110/110/200/800/800 ms，并标注为暂定。
超时和响应挂起怎么处理？
基础超时 100 ms；收到 NRC 0x78 时重置并把超时翻倍、上限 2000 ms，请求保持等待；其它 NRC 判为完成；连续 5 次超时的 DID 跳过 5000 ms。
用 11 位还是 29 位地址？
主寻址是 29 位 0x18DA10F1（响应 0x18DAF110）；11 位 0x7E0/0x7E8 是回退，源文档标注为未验证——未记录 ECU 实际应答哪一个。
延伸阅读
- UDS 诊断工具为什么不能随手调：只读、会话与写 ECU 的分权设计 —— 与本文「只读服务白名单、禁止 0x27」的边界一致。
- OBD-II PID 入门：车速 0x0D 为什么是整数 —— 解释本文 DID 对应的 PID 0x0C/0x0D/0x11/0x05/0x42。
- CAN 报文解析的「健康位」在说什么：校验、计数器与总线空窗 —— 承接本文的 ECU 在线判定与总线关闭恢复。
- 车电接入：为什么 ESP32 的 TWAI 不等于 OBD 接口 —— 说明轮询用到的总线与诊断口的关系。
- 汽车 / 摩托 / 自行车：三类骑行场景对仪表的需求差异 —— 从摩托车场景看这 5 个值的取舍。
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/moto-platform-cl250/docs/legacy-telemetry-notes.md（主来源：UDS 状态机、NRC 表、总线恢复与 ISO-TP 陷阱）。 - 项目 01 ——
public-can-dbc-datasets/additional/moto-platform-cl250/uds/vehicle_cl250.yaml（DID 定义、寻址、会话与轮询时序）。 - 项目 01 ——
public-can-dbc-datasets/additional/moto-platform-cl250/README.md（项目结构、平台总线与 CL250 骨架的区分）。
说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11