发动机无法启动。以前冷启动后冷却风扇会立刻高速运转。面对这样的症状，人们往往想马上知道原因或该换什么零件。这次的对象是一辆 2009 年款 Mercedes-Benz W204 C63 AMG。在借助 AI 推进诊断时，我们最先做的，是把车辆返回的信息连同条件一起保存下来。

本连载会把在实车上已确认的内容和尚未确认的内容区分开来，介绍整个过程。目前，无法启动和风扇异常的原因都尚未确定。第一次的成果是留下了可供下一次诊断使用的原始记录，并梳理出了需要调查的要点。

OBD 能读到什么 #

OBD 是 On-Board Diagnostics（车载自诊断）的缩写。通过与车辆的电子控制单元（ECU）通信，可以读取故障码、温度、转速等信息。不过，标准 OBD 能处理的项目与厂商专有诊断处理的项目需要区分开。故障码、实测值和车辆信息各有不同的读取服务，支持范围也因车而异。（OBD Solutions 服务一览）

这次连接 PC 与车辆的是 USB 接口的 OBDLink EX。连接后读取了设备的型号名和固件应答，确认实物确实是 OBDLink EX。

人与 AI 的分工 #

AI 并没有站在车前。设备返回的数值与人看到、听到并报告的症状，在记录上也分开处理。

例如“钥匙 ON、发动机停止”是读取温度和转速时的重要条件。我们没有凭猜测钥匙位置就开始通信，而是确认现场的报告后再进行。如果没有测量启动操作那一瞬间，就不能把停机时取得的电压当作启动时的电压来使用。这种条件上的差异会左右之后的解读。

确定第一次采集的范围 #

程序的范围也事先定好了。第一次只做适配器识别和电压确认，接着读取标准 OBD，没有清除故障码。也没有进行 ECU 复位、执行器测试、编码或刷写。为了调查故障状态，方针是先保留清除之前的应答。

“读取”这个词需要注意。在这次标准 OBD 读取中，我们向车辆发送了请求帧，并接收了其应答。这与不发送任何数据的 CAN 被动监听在步骤上是不同的。

OBDLink 的官方手册也把面向适配器的命令和发往车辆的 OBD 请求区分开来。实现上采用了只发送已许可请求的结构。（OBDLink 官方编程手册）

保留原始日志与采集结果 #

保存的不只是加工成易读形式的数值。我们保留了发送的命令、收到的字符串和原始字节序列、日期时间、设备以及钥匙状态，之后再另行生成解码结果。这样即使日后修正了解码方法，也能回到采集时的原始记录进行核对。在屏幕上显示“水温 21 ℃”，与保存得出该数值的应答，各有各的作用。

我们还决定，不用正常值去填补没有得到应答的项目。

我们也避免把只收到一部分的应答当作完整列表来解读。越是把分析交给 AI，就越需要不模糊这些区别的记录。

第一次的结果与下一次测量 #

在第一次短时间采集中，标准 OBD 正常应答，确认了水温 21 ℃、发动机转速 0 rpm 等数值。在有应答的范围内，存储故障码和待定故障码均为 0 条。另一方面，永久故障码未能取得。仅凭标准 OBD 的结果，无法判断包括启动许可、照明等在内的整车是否正常。

适配器读到的电压为钥匙 OFF 时 11.9 V、钥匙 ON 时 11.6 V。这些是 OBD 接口一侧的数值。我们没有在蓄电池端子处测量，也没有取得起动机运转期间的电压。它们可以作为下一步确认电源状态的材料，但还不到仅凭这些就决定蓄电池寿命或是否需要更换的阶段。

症状报告也有变化。这次钥匙 ON 时风扇没有高速运转；进行启动操作时，有报告称起动机短暂转动了一下。以前“完全没有反应”的报告作为当时的历史保留。我们也没有根据这次发动机停止状态下的观察，判断冷启动后的风扇异常已经消除。

到此实车作业暂告一段落，决定下次先整顿好电源状态再继续确认。厂商专有诊断的程序也已准备，但基于模拟应答的测试与实车采集是分开的。程序通过测试，并不能证明已与这辆车的各控制单元通信成功。

借助 AI，资料整理、通信处理的实现和日志比对都更容易推进。支撑这些判断的，是在现场确认的条件和未经加工的应答。

下一回，我们将按照采集结果，看看如何解读第一次的日志，弄清了什么、还有什么不清楚。