BESTNET TECH BLOG
区分适配器的通信功能与车型专属诊断定义,把厂商诊断程序作为尚未经实车验证的准备阶段整理好
即使能通过标准 OBD 与车辆通信,也不代表故障诊断就此完成。对于这辆 2009 年款 W204 C63,除了标准 OBD 得到的信息之外,我们还希望确认 SAM、EIS、ESP 的信息。于是,我们推进了使用手头 OBDLink EX 进行厂商专有诊断的准备工作。
目前完成的是读取程序和离线验证。尚无在这辆车上读到 SAM、EIS、ESP 的实绩。
SAM 是指信号采集与执行控制单元,EIS 是指电子点火开关,ESP 是指车身电子稳定系统。目的是确认这次标准 OBD 没有调查的这些系统的状态。
准备工作的进展 #
| 项目 | 状态 |
|---|---|
| 读取程序 | 已编写 |
| 离线验证(模拟应答) | 51 项通过 |
| EIS、ESP 的通信路径 | 源自其他车辆的候选 本车尚未验证 |
| SAM 的通信路径 | 未确定 从识别开始确认 |
| 在本车上的实际读取 | 下一回 |
适配器的规格与车型专属诊断定义 #
首先梳理的,是适配器的通信能力与车型专属诊断定义之间的区别。即使有能连接 CAN 的硬件,发往哪个目标、使用哪种协议、请求什么内容,仍需另行掌握。还必须了解返回数据的格式和含义。仅凭“设备支持 CAN”这一信息,不能判断能够诊断特定年款的 SAM。
在 OBDLink 的官方资料中,可以确认在 CAN 上传送分段消息的 ISO-TP、接收过滤器以及流控制的设置。这些是构建读取处理的基础。另一方面,各车型的 ECU 地址表和故障码说明并不能从该资料中获得。这次我们同样把硬件规格的确认与车辆通信定义的调查分开进行。(OBDLink 官方规格)
从其他车辆的资料中准备候选 #
EIS 和 ESP 的候选,使用的是原开发者公开的 2011 年款 C207 的通信记录。其中保留了具体的收发路径、诊断会话以及对故障码请求的应答。但它的对象与这次的 2009 年款 W204 C63 不同。资料中有实测值,与该设定是否适用于手头这辆车,是两项不同的确认事项。实现中也保留了“候选”标签,默认不执行。(MBLINK 公开定义、C207 应答记录)
公开记录的格式也有局限。其中记录的是整理后的诊断消息,并不是 CAN 原始帧本身。仅凭该记录,无法断定分段通信的控制信息或是否使用扩展地址。下一次需要保存实际应答,不仅核对目标地址,也要核对帧的格式。
关于 SAM,前后两个都尚未找到可用于这辆车的确定路径。我们没有直接套用其他车型的地址,而是先设置了获取识别信息的阶段。设计上利用公开资料中候选路径的规律,每次只确认少量。通常一次以 6 个槽位为对象,没有做成自动遍历全部 47 条路径的动作。候选数量并不代表已实测的模块数量。
发往未识别路径的只有固定的识别请求。即使有应答,也不会从那里自动扩展到读取故障码或切换会话。确认返回的识别字符串和其他依据后,才反映到车辆用的定义中。如果没有回复,仍需确认目标地址、协议、电源状态等。仅凭无应答,不能断定 SAM 存在故障。
区分应答的状态 #
即使能够接收,结果的分类也很重要。我们把故障码正常返回 0 条的情况与未能取得的情况分开。NO DATA、否定应答、等待应答、中途截断,均按各自的状态原样记录。
UDS(Unified Diagnostic Services)是 ECU 与诊断仪交换信息所用的诊断服务。在其故障码应答中,我们按长度检验代码与状态信息是否成对。即使看到像故障码的数值,只要缺少最后的状态信息,就不作为完整结果采用。
这种区分在审查 AI 生成的处理时也很有帮助。我们使用在正常空列表中混入 CAN 错误的模拟应答,验证了不会被判定为 0 条。结构上先判断通信错误,保留原始数据并中止采集。在生成易读的摘要之前,需要先确认应答是否有效。对于无法确认含义的厂商专有代码,我们没有附加推测性的说明。
运行条件与离线验证 #
另外,即使是“只读”,也会向车辆发送请求。标准 OBD 也是请求信息并接收应答的通信。在接收分段应答时,还会发送必要的流控制消息。在这次的设计中,读取请求是固定的,清除 DTC、ECU 复位、安全访问、写入、执行器测试等都没有列入许可清单。切换诊断会话需要另行明确指定,并且仅限于有资料可依的 EIS 和 ESP 候选路径。
下一次的实车模式需要钥匙 ON、发动机停止、稳定的电源,以及执行候选的指定。程序会核对所连接的设备与目标车辆,并在中途持续确认电压。默认的电压下限 12.0 V 和追加请求的时间上限 30 秒,是本程序设定的停止条件,不能作为厂商的维修规定值引用。即使条件不满足,也按设计保留到中途为止的证据。
目前为止通过的 51 项测试,是使用内存中的模拟设备和应答进行的离线验证。在这次厂商诊断准备中,发往实车的请求为 0 条。我们确认了对分段应答、目标不符、电压下降、禁止请求、中途截断等情况的处理,但这些并不是证明 Windows 实际端口收发以及 W204 厂商诊断成功的测试。
借助 AI 推进的,是资料整理、候选的实现以及包括异常应答在内的验证。接下来要确认的是:候选路径在实车上能否成立、是哪个 ECU 在回复、能否正确组装应答。只有结果齐备的项目才会采用到车辆设定中,未确定的项目将继续按未确定处理。