上一回介绍了用 AI 编写 OBD 采集程序，并保留车辆返回的应答。这一回，我们来读 2009 年款 Mercedes-Benz W204 C63 AMG 的第一次日志。标准 OBD 的存储与待定故障码为 0 条。即便如此，启动不良的原因仍未确定。

查看故障码条数时，需要同时确认“这是对哪个范围查询的结果”。下面整理这一次采集弄清了什么，又给下一次测量留下了什么。

DTC 是 Diagnostic Trouble Code 的缩写，指诊断时读取的故障码。

钥匙 ON 时采集的数据 #

测量日期为 2026 年 10 月 13 日。将 OBDLink EX 连接到车辆的 OBD 接口和 Windows PC，在钥匙 ON、发动机停止的状态下进行采集。通信指定为 ISO 15765、11-bit、500 kbit/s，在约 4.4 秒的采集过程中，有两个应答地址作出了回复。这不是自动检测的结果，而是在该设定下确认通信的记录。

7E8 和 7E9 是回复的地址。尚未与 Mercedes 的具体控制单元名称进行对照。VIN（车辆识别号）也已取得，但本文不刊载任何可识别具体车辆的信息。

由于发动机处于停止状态，转速 0 rpm 与该测量条件一致。另一方面，节气门绝对位置 16.08 % 并不表示踏板被踩下了这个比例。准确保留项目名称，可以减少只看数字而产生的误读。

区分 0 条与未取得 #

标准 OBD 按用途设有不同服务，例如读取存储 DTC 的 Mode 03、读取待定 DTC 的 Mode 07、读取永久 DTC 的 Mode 0A 等。解读结果，要从区分采集对象的类别开始。（OBD Solutions 服务一览）

这次的存储 DTC 请求记录到了以下应答。

请求 03
应答 7E9 02 43 00
应答 7E8 02 43 00

根据这两个地址的回复，我们解读为存储的标准 OBD DTC 为 0 条。待定 DTC 也为 0 条。但是，这次的程序没有查询 SAM、EIS、ESP 等厂商专有的故障存储器。不能把标准 OBD 的 0 条扩大解释为“整车所有系统均无错误”。

永久 DTC 返回了 NO DATA。在分析结果中，我们没有把条数记为 0，而是记为“未取得”。因为仅凭没有应答，无法区分是没有故障码，还是支持范围或通信条件的问题。制作汇总表时如果把空栏全部转换成 0，含义就会在这里发生改变。

我们会让 AI 对结果进行摘要，但输入中一定附上服务编号、应答地址、原始回复和解析状态。做成在对结论存疑时能够回到原始应答的形式，比只有文字说明更有用。

把症状与测量条件放在一起 #

过去曾有报告称，冷启动后冷却风扇立即高速运转。这次在钥匙 ON、发动机停止的状态下没有高速运转。虽然也得到了水温 21 ℃，但启动后与发动机停止时的条件不同。我们没有仅凭这个结果就判断风扇症状已经消除。

关于启动操作，有报告称起动机短暂带动发动机转了一下就停了。这与过去完全没有反应的状态分开记录。这次的日志没有测量那一瞬间，因此不能把 0 rpm 或 11.6 V 当作启动操作中的数据使用。

钥匙 OFF 时取得的 OBD 接口电压为 11.9 V，钥匙 ON 的第一次采集为 11.6 V。这些是适配器一侧读到的数值，并不是直接测量蓄电池端子的静态电压或启动时电压降的结果。下一步计划先准备好能够充电和测量的条件，再确认蓄电池和主电源供应。仅凭目前的数值，还不到决定更换蓄电池的阶段。

整理交给 AI 的信息 #

这次采集所能确认的，是在指定条件下标准 OBD 作出了应答，并且保存了若干数值。启动许可、整车 CAN 通信以及各模块是否正常，目前还不清楚。

与 AI 一起推进诊断时，把已取得的项目、未取得的项目和人观察到的症状分开交给它，更容易讨论下一步该确认什么。

这次的方针是优先确认电源状态，之后再进入厂商专有诊断。下一回将介绍，为了用现有的 OBDLink EX 尝试这种诊断，我们调查了什么、程序准备到了什么程度。