14、诊断系统（OBD-II）：车载诊断接口、故障码读取、远程诊断实现
各位同学，今天我们来聊聊车载诊断系统。说实话，OBD-II 这个接口，在传统燃油车上已经存在二十多年了。但在 Android Automotive 上，它的玩法完全不一样了。我最早接触这个模块时，以为就是读个故障码那么简单。后来才发现，这里面的坑，一个比一个深。
14.1 OBD-II 接口：车上的“黑匣子”
OBD-II，全称是 On-Board Diagnostics II。说白了，就是车上的自诊断系统。它最早是为了监控排放而生的。但现在，它的功能远不止于此。
在 Android Automotive 中，OBD-II 接口通常通过以下几种方式接入：
- 蓝牙适配器：最常见的方式。买个 ELM327 或 STN1170 芯片的蓝牙 OBD 适配器，插到车上的 OBD 接口上。然后车机通过蓝牙连接它。
- USB 直连：有些车机直接通过 USB 线连接到 OBD 接口。这种方式更稳定，延迟更低。
- CAN 总线直连：这是最“硬核”的方式。车机直接通过 CAN 总线与 ECU 通信。不需要额外的适配器。但需要硬件支持。
核心要点：在 Android Automotive 上，我们通常通过 BluetoothSocket 或 UsbDeviceConnection 与 OBD 适配器通信。通信协议是 ISO 15765-4 (CAN) 或 ISO 9141-2 (KWP)。
14.2 故障码读取：DTC 的“前世今生”
故障码，也就是 DTC (Diagnostic Trouble Code)。每个 DTC 由 5 个字符组成。比如 P0301，意思是“气缸 1 失火”。
读取故障码的流程，我习惯这样分步走：
- 建立连接：发送 ATZ 命令复位适配器。然后发送 ATSP0 命令让适配器自动选择协议。
- 请求故障码：发送 03 命令请求当前故障码。或者发送 07 命令请求待定故障码。
- 解析响应：适配器返回的是一串十六进制数据。需要按照 SAE J2012 标准解析。
- 清除故障码：发送 04 命令清除故障码。注意，这个操作会清除所有故障码，包括历史记录。
这里有个坑。我曾经在项目中发现，有些车的 ECU 对 03 命令的响应特别慢。等了 5 秒都没反应。后来我加了个超时机制，3 秒没响应就重试一次。如果还不行，就报“通信超时”。
// 读取故障码的核心代码片段
public List<DtcCode> readDtcCodes() {
List<DtcCode> codes = new ArrayList<>();
try {
// 发送请求当前故障码的命令
sendCommand("03");
String response = readResponse();
// 解析响应
// 响应格式: 43 01 03 00 00 00 00 00
// 其中 43 是响应头，后面的字节是故障码数据
if (response != null && response.startsWith("43")) {
String[] bytes = response.split(" ");
for (int i = 1; i < bytes.length - 1; i += 2) {
String dtc = parseDtc(bytes[i], bytes[i + 1]);
if (dtc != null) {
codes.add(new DtcCode(dtc));
}
}
}
} catch (IOException e) {
Log.e(TAG, "读取故障码失败", e);
}
return codes;
}小技巧：解析 DTC 时，第一个字节的高 4 位表示系统类型。P 代表动力系统，B 代表车身，C 代表底盘，U 代表网络通信。记住这个规律，调试时能省不少时间。
14.3 远程诊断实现：从“本地”到“云端”
远程诊断，说白了就是把车上的诊断数据传到云端。这样维修技师不用到现场，就能知道车出了什么问题。
实现远程诊断，我建议分三层：
- 数据采集层：车机上的诊断服务定时读取 OBD 数据。包括故障码、传感器数据、冻结帧等。
- 数据传输层：通过 MQTT 或 HTTP 协议，把数据上传到云端。MQTT 更适合实时性要求高的场景。
- 云端处理层：云端接收数据后，进行存储、分析和告警。
这里有个关键点：数据量控制。你想想看，如果每秒钟都上传所有传感器数据，流量会爆炸。我一般这样处理：
- 故障码：有变化就上传。
- 传感器数据：每 5 分钟上传一次快照。
- 冻结帧：只在故障发生时上传。
注意：远程诊断涉及用户隐私。一定要在用户同意的情况下才能上传数据。而且，上传的数据要加密。我曾经见过一个项目，直接把明文数据传到云端，结果被黑客截获了。嗯，那场面，相当尴尬。
14.4 知识体系图
下面这张图，是我梳理的 OBD-II 诊断系统的核心逻辑。从硬件接口到云端服务，一目了然。
14.5 实战经验：避坑指南
做 OBD-II 开发，有几个坑是绕不开的。我一个个说：
- 协议自动识别不靠谱：ATSP0 命令让适配器自动选择协议。但有些车的 ECU 会返回错误信息。我建议手动指定协议。比如 ATSP6 强制使用 CAN 11bit 500kbps。
- 蓝牙连接不稳定：车机蓝牙和手机蓝牙不一样。车机蓝牙的兼容性更差。我遇到过适配器连上后，发几个命令就断连的情况。解决方案是加心跳包。每 10 秒发一个 AT 命令，保持连接。
- 数据解析要严谨：有些 ECU 返回的数据格式不标准。比如本该返回 43 01 03，结果返回了 43 01 03 00。多了一个字节。解析时要做容错处理。
- 权限问题：Android 11 以后，蓝牙权限管理更严格了。需要动态申请 BLUETOOTH_CONNECT 权限。而且，有些车机厂商会限制第三方 App 访问 OBD 接口。
核心建议：如果你刚开始做 OBD-II 开发，我建议先买个 ELM327 蓝牙适配器，用手机 App 测试一下。确认车能正常通信后，再在车机上开发。这样可以排除很多硬件问题。
14.6 远程诊断的“最后一公里”
远程诊断的实现，不仅仅是技术问题。还有业务逻辑。比如：
- 诊断请求的优先级：紧急故障（如发动机熄火）要立即上传。非紧急故障（如空调故障）可以延迟上传。
- 数据压缩：上传的数据要压缩。我一般用 GZIP 压缩，能减少 60% 的流量。
- 离线缓存：车机没网时，诊断数据要缓存起来。等有网了再上传。缓存大小建议控制在 10MB 以内。
嗯，关于诊断系统，今天就聊这么多。记住，OBD-II 是车机与 ECU 沟通的桥梁。掌握了它，你就掌握了车辆状态的第一手信息。
公众号:蓝海资料掘金营，微信deep3321