一、物流系统的"盲区"在车厢里，不在系统里
一个成熟的物流系统 可以精确追踪包裹到了哪个分拨、上了哪辆车、预计何时送达。但它对车辆本身的状态几乎一无所知：发动机是否过热、油耗是否异常、冷机车厢温度是否达标、刹车片是否即将磨损。
这些信息不在 TMS 的运单表里，而在车辆的 CAN 总线上。CAN 总线是车辆内部各电子控制单元（ECU）之间的通信网络，发动机转速、车速、油耗、冷却液温度、故障码------所有传感器数据都在这条总线上流动。OBD-II 接口则是通往这条总线的"门"。
德邦物流的车联网平台给出了一个可参照的工程规模：超过 2 万辆运输车辆，车载终端集成 OBD-II 接口和北斗/GPS 双模定位，每 2 秒采集一次车辆数据，通过 MQTT 上传，系统每秒处理超 10 万条设备数据。
二、CAN 总线数据采集：协议解析是核心难点
2.1 OBD-II 是入口，CAN 是内容
OBD-II 接口在物理层是标准的 16 针插座，但协议层因车型而异。常见的协议包括 ISO 15765（CAN）、ISO 9141、SAE J1850 等。对于 2008 年后的乘用车和大部分商用车，ISO 15765（CAN 总线）是主流。
通过 OBD-II 请求车辆数据时，发送的是PID（Parameter ID）请求帧 ，ECU 在 CAN 总线上返回对应的数据帧。例如，请求发动机转速的 PID 是 0x0C，返回的数据帧中前两个字节组合后除以 4 即为转速值。
2.2 厂商自定义 CAN 帧：真正的工程深水区
标准 OBD-II PID 只覆盖了一部分参数（转速、车速、冷却液温度等）。油耗、变速箱状态、ABS 状态、冷机车厢温度 这些关键数据，往往由厂商使用自定义 CAN ID 和字节布局传输，不在任何公开标准中。
专利文献给出了一个识别厂商自定义 CAN 数据的思路：利用已知变量之间的相关性来定位目标数据。例如，油耗与发动机负荷正相关，通过采集已知的发动机负荷数据和未知的 CAN 帧数据，分析两者的相关性，可以推断出哪条 CAN ID 承载油耗数据、以及在 payload 中的字节位置。
java
public class CustomCanDecoder {
/**
* 通过相关性分析识别自定义CAN帧中的油耗数据
* 核心思路：油耗与发动机负荷正相关
*/
public CanField locateFuelRate(List<CanFrame> frames,
List<Double> engineLoadHistory) {
for (CanFrame frame : frames) {
// 对每个候选字节位置，计算与发动机负荷的相关系数
for (int byteOffset = 0; byteOffset < frame.getPayload().length - 1; byteOffset++) {
List<Double> candidateValues = extractValues(frames,
frame.getId(), byteOffset);
double correlation = pearsonCorrelation(
candidateValues, engineLoadHistory);
if (correlation > 0.85) { // 强正相关
return new CanField(frame.getId(), byteOffset,
ScaleFactor.autoDetect(candidateValues));
}
}
}
return null; // 未找到
}
}工程约束 ：相关性分析需要足够的样本量（通常数百帧以上），且必须在车辆处于稳定工况时采集，避免急加速/急减速的瞬态干扰。
三、冷链场景：温度数据的采集与告警
冷链物流的快递系统 对温度有硬性要求。冷机车厢温度通常由独立的温度传感器采集，通过 CAN 总线或 RS485 上传。采集频率不需要像发动机数据那么高，每 30 秒到 1 分钟一次即可满足监控需求。
关键设计是温度告警的分级。德邦的三级告警模型可以参照：一级告警（红色）对应立即需要干预的异常，如超速或急刹车；二级（橙色）对应需要关注但可稍后处理的，如发动机高温。冷链温度告警同理：车厢温度偏离设定值超过 2°C 持续 10 分钟 → 二级告警；超过 5°C → 一级告警，立即通知司机和调度。
四、边缘缓存与断网补传：跨境场景的刚需
跨境物流快递系统的车辆经常行驶在信号盲区（山区、隧道、边境地带）。如果数据只在联网时采集和上传，断网期间的数据会永久丢失。
工程方案是边缘缓存 + 断网补传：车载终端内置本地存储（如 eMMC 或 SD 卡），采集到的数据先写入本地环形缓冲区，联网时按时间顺序批量上传，上传成功后标记已同步。缓冲区大小按"最长断网时间 × 采集频率"估算，通常保留 24--72 小时的数据。
java
public class EdgeBuffer {
private final RingBuffer<VehicleData> buffer; // 环形缓冲区
private static final int MAX_SIZE = 72 * 3600 / 2; // 72小时，每2秒一条
public void onDataCollected(VehicleData data) {
buffer.write(data); // 先写本地
if (isNetworkAvailable()) {
flushToCloud(); // 联网时异步上传
}
}
private void flushToCloud() {
while (!buffer.isEmpty()) {
VehicleData data = buffer.peek();
if (upload(data)) {
buffer.poll(); // 上传成功才移除
} else {
break; // 上传失败，保留在缓冲区
}
}
}
}五、避坑指南
坑1：只读标准 OBD-II PID，不解析厂商自定义 CAN 帧。 油耗、冷机温度等关键数据往往在自定义帧里。相关性分析是定位自定义数据的可行路径。
坑2：CAN 总线数据直接透传到云端。 每 2 秒一条、每辆车数十个参数，2 万辆车的数据量是每秒百万级。必须在边缘做聚合和降频，只上传关键指标和告警事件。
坑3：断网期间数据不缓存。 跨境场景信号盲区多，断网数据丢失等于监控空白。边缘环形缓冲区是必备能力。
坑4：温度告警阈值一刀切。 不同货物（冷冻、冷藏、恒温）的温度要求不同。阈值必须按货物类型配置，而不是全局固定值。
六、总结
车载 OBD 与 CAN 总线采集的核心是协议解析 + 边缘缓存 + 分级告警 。标准 OBD-II PID 覆盖基础参数，厂商自定义 CAN 帧需要相关性分析来定位；冷链温度按货物类型配置分级阈值；跨境场景的断网补传靠边缘环形缓冲区兜底。德邦 2 万辆车、每秒 10 万条数据的规模说明，这套方案在物流系统的工程实践中是可行的。
下一篇预告：车辆数据采集解决了"车怎么样"，但跨境物流的资金流还有另一层复杂度------多币种、多时区、多监管。明天聊海外多币种资金池设计。
> 本文作者：深圳＋Eyf•半字节科技▪技术产品团队
> 物流、快运、快递管理系统，让每一票，都清晰可控。从任务分配到签收回传，一站式管理每个作业环节。