12、车辆信号与诊断：OBD-II 集成，车辆信号抽象层
各位同学，今天我们来聊聊车机系统里一个特别“接地气”的话题——车辆信号与诊断。说白了，就是你的Android Automotive OS怎么跟车里的各种传感器、ECU（电子控制单元）打交道。
我个人习惯把这一章看作是整个车载系统的“神经末梢”。没有它，你的中控屏再炫酷，也读不到车速、转速、故障码这些核心数据。嗯，咱们直接进入正题。
12.1 OBD-II 集成：不只是读个故障码
OBD-II，全称On-Board Diagnostics II，是汽车上的标准诊断接口。很多同学觉得它就是个“读码器”，其实不然。在Android Automotive里，OBD-II是我们获取车辆原始信号的重要通道。
为什么需要OBD-II？
- 标准化：几乎所有2008年后的汽油车都支持，协议统一（ISO 15765-4, ISO 14230等）。
- 低成本：一个蓝牙或Wi-Fi OBD-II适配器，几十块钱就能搞定原型验证。
- 数据丰富：车速、发动机转速、冷却液温度、氧传感器电压……应有尽有。
核心要点：OBD-II在Android Automotive中通常作为“后备数据源”或“调试接口”。量产车上可能用CAN总线直连，但开发阶段OBD-II是救命稻草。
我在项目中遇到过一个问题：某款车型的CAN总线协议不开放，供应商只给了OBD-II接口。我们不得不把OBD-II作为主要数据源，通过蓝牙串口实时读取PID（参数ID）数据。那段时间，我几乎把ISO 15765-4的协议文档翻烂了。
12.1.1 OBD-II 数据读取流程
流程其实不复杂，我画了个图帮你理解：
代码实现上，我建议用Android的BluetoothSocket或WifiManager建立连接，然后通过AT命令和PID请求循环读取。给你看一段核心代码：
// 发送OBD-II PID请求 (以车速为例)
private fun sendObdRequest(socket: BluetoothSocket, pid: String): String? {
val cmd = pid + "\r\n"
socket.outputStream.write(cmd.toByteArray())
socket.outputStream.flush()
// 读取响应 (通常需要等待50-100ms)
val buffer = ByteArray(1024)
val bytesRead = socket.inputStream.read(buffer)
return String(buffer, 0, bytesRead).trim()
}
// 解析车速 (PID 0x0D)
fun parseSpeed(response: String): Int {
// 响应格式: "41 0D 1A" -> 车速 = 0x1A = 26 km/h
val parts = response.split(" ")
if (parts.size >= 3) {
return Integer.parseInt(parts[2], 16)
}
return -1
}小技巧：OBD-II的响应速度很慢（约10-20Hz），别在主线程里读。我习惯用Coroutine或HandlerThread做异步读取，避免卡UI。
12.2 车辆信号抽象层（Vehicle Signal Abstraction）
好了，OBD-II读到了原始数据，但问题来了——不同车型的PID定义可能不一样。有的车车速用km/h，有的用mph；有的发动机转速用0.25 RPM/LSB，有的用0.125。这时候，就需要一个“翻译官”来统一口径。
这个“翻译官”就是车辆信号抽象层。说白了，它把底层乱七八糟的硬件信号，映射成上层应用能理解的统一接口。
12.2.1 为什么需要抽象层？
你想想看，一个车机App要显示车速，它才不管你是从OBD-II读的，还是从CAN总线拿的，甚至是从GPS推算的。它只想要一个getVehicleSpeed()方法，返回一个float值。
抽象层的作用就是：
- 解耦：应用层不依赖具体硬件。
- 归一化：不同信号源统一成标准单位（km/h, RPM, °C等）。
- 可扩展：新增车型只需实现抽象层的接口，不用改上层代码。
避坑指南：我曾经在一个项目里，直接把OBD-II的原始值传给上层。结果换了一款车，车速显示直接翻倍——因为那款车的车速分辨率是0.5 km/h/LSB，而我默认用了1.0。从那以后，我坚持所有信号必须经过抽象层转换。
12.2.2 抽象层的架构设计
在Android Automotive中，这个抽象层通常由Vehicle HAL和CarService共同实现。我画个架构图帮你理清关系：
看到没？App只跟CarService打交道，CarService再通过Vehicle HAL去读硬件。每一层各司其职，互不干扰。
12.2.3 信号映射与转换
抽象层最核心的工作就是信号映射。我举个例子：
| 原始信号源 | 原始值 | 转换公式 | 抽象层输出 |
|---|---|---|---|
| OBD-II PID 0x0D | 0x1A (26) | 值 * 1.0 km/h | 26.0 km/h |
| CAN总线车速信号 | 0x00A3 (163) | 值 * 0.5 km/h | 81.5 km/h |
| GPS速度 | 22.5 m/s | 值 * 3.6 | 81.0 km/h |
在代码层面，我通常用VehiclePropertyConfig来定义每个信号的转换规则：
// 定义车速信号配置
val speedConfig = VehiclePropertyConfig(
propertyId = VehicleProperty.SPEED,
source = VehiclePropertySource.OBD2,
conversion = { rawValue: Int -> rawValue * 1.0f }, // km/h
unit = "km/h",
minValue = 0f,
maxValue = 300f
)
// 在Vehicle HAL中实现
override fun get(property: VehicleProperty): VehiclePropValue {
return when (property) {
VehicleProperty.SPEED -> {
val raw = readObdPid(0x0D) // 读OBD-II
val converted = speedConfig.conversion(raw)
VehiclePropValue(converted, speedConfig.unit)
}
else -> throw IllegalArgumentException("Unknown property")
}
}注意：不同车型的OBD-II协议可能有细微差异。比如有些车需要先发送AT命令设置协议类型（ATSP0），有些车则自动协商。我建议在初始化阶段做一次协议探测，避免硬编码。
12.3 诊断功能集成
除了常规信号，抽象层还要处理诊断信息，比如故障码（DTC）、冻结帧、氧传感器测试等。这部分在Android Automotive里通常通过VehicleDiagnosticService暴露给上层。
诊断数据的读取流程跟普通信号类似，但多了几个步骤：
- 请求诊断会话：发送AT命令进入诊断模式（如ATSH 7E0）。
- 发送诊断请求：如请求故障码（03）、清除故障码（04）。
- 解析响应：提取DTC代码（如P0301表示1缸失火）。
- 映射到抽象层：将DTC转换为
VehicleDiagnosticTroubleCode对象。
我个人习惯把诊断功能单独封装成一个模块，因为它的协议更复杂，而且涉及安全（比如清除故障码需要权限）。
12.4 性能与稳定性考量
最后，聊几个实战中容易踩的坑：
- 轮询频率：OBD-II的响应速度有限，别超过20Hz。我一般设10Hz，兼顾实时性和稳定性。
- 超时处理：OBD-II适配器偶尔会无响应。设置2秒超时，超时后重试3次，再失败就上报错误。
- 数据缓存：抽象层应该缓存最近一次的有效值。万一硬件临时断开，App还能显示旧数据，不至于直接变0。
- 线程安全：Vehicle HAL可能被多个App同时访问。用
ReentrantLock或synchronized保护共享资源。
我的经验：在量产项目中，我建议把OBD-II作为“调试模式”的数据源，正式发布时用CAN总线直连。OBD-II的蓝牙连接在车辆震动环境下容易断连，用户体验不好。
好了，这一章的内容就到这里。车辆信号抽象层是整个车载系统的基石，搞懂了它，你就能理解Android Automotive如何跟车辆硬件“对话”。下一章我们会深入Vehicle HAL的具体实现，到时候再聊。
公众号:蓝海资料掘金营，微信deep3321