去年给一家物流公司做车队管理项目的时候，客户提出一个需求：要实时监控每辆货车的油耗、发动机转速、水温这些数据。这些数据不能只是存在车上，必须实时传到云端平台，方便调度员监控车辆状态。

听起来很简单，但实际做起来才发现，从车辆内部读取这些数据，远比想象中复杂。车辆的各种信息都在CAN总线上传输，但不同车型的CAN报文格式完全不一样。同样是读发动机转速，解放的卡车和东风的卡车，CAN报文的ID、数据位置、换算系数都不同。

最后我们用了双5G车载网关来解决这个问题，网关通过CAN接口连接车辆总线，解析各种报文，然后通过5G网络上传到云端。整个项目下来，对车载网关和CAN总线的配合有了很深的理解。

CAN总线在车辆上的作用

先说说CAN总线是什么。CAN是Controller Area Network的缩写，控制器局域网。这是博世在1980年代为汽车设计的一种通信总线。

为什么需要CAN总线？因为现代车辆上有几十个甚至上百个电子控制单元（ECU）。发动机ECU、变速箱ECU、ABS ECU、仪表ECU、车身控制ECU等等。这些ECU之间需要通信，如果每两个ECU之间都拉一根线，布线会非常复杂。

CAN总线就是把所有ECU连到一条总线上。就像一条公交线路，所有站点都在这条线上。任何ECU发送的消息，其他ECU都能收到。每个ECU根据自己的需要，选择性地接收和处理相关消息。

一辆商用车通常有2-3条CAN总线。动力CAN总线连接发动机、变速箱、ABS这些动力系统ECU，通信速率通常是500kbps或者250kbps。车身CAN总线连接车灯、门锁、空调这些舒适系统ECU，速率通常是125kbps。还可能有专门的诊断CAN总线。

车载网关要读取车辆数据，就得接入这些CAN总线。以SV910为例，它配备了3路CAN接口，可以同时连接车辆的多条CAN总线。

从CAN总线读取数据的过程

具体怎么读取数据？以发动机转速为例，完整流程是这样的。

第一步，物理连接。把网关的CAN接口连接到车辆的OBD诊断口或者直接接到CAN总线上。商用车一般都有标准的OBD接口，位置通常在驾驶室的仪表台下方或者座椅旁边。接口是一个梯形的插座，有16个针脚。

CAN总线用的是差分信号，两根线：CAN_H和CAN_L。OBD接口的6号针脚是CAN_H，14号针脚是CAN_L。网关的CAN接口也有对应的两根线，接上就行。要注意的是，CAN总线的两端需要加120欧姆的终端电阻，避免信号反射。有些网关内部已经集成了终端电阻，可以通过软件配置开启或关闭。

第二步，配置波特率。CAN总线的通信速率必须匹配，不然收不到任何数据。商用车的动力CAN通常是250kbps或者500kbps，需要先确认。可以查车辆的维修手册，或者用专业的CAN分析仪测试。

网关的CAN接口要配置成相同的波特率。SV910这种网关通常支持多种波特率，通过配置文件或者管理界面设置。

第三步，监听和解析CAN报文。CAN总线上的数据是以报文（Frame）的形式传输的。每个报文包含几个部分：报文ID、数据长度、数据内容、校验码。

报文ID是识别这条消息的关键。比如发动机转速的报文ID，在国标GB/T 27930和SAE J1939标准里有定义。J1939标准是商用车常用的，发动机转速的ID是0x0CF00400，数据位置在第4和第5字节。

网关要做的是，持续监听CAN总线，抓取特定ID的报文，然后从数据字节里提取出转速值。提取出来的是原始数字，还要根据换算公式转换成实际的转速。J1939标准里，发动机转速的分辨率是0.125rpm/bit，就是说原始值要乘以0.125才是真实转速。

第四步，数据打包上传。解析出转速值之后，网关要把数据打包成合适的格式，通过5G网络上传到云端。常见的格式有JSON、Protobuf、MQTT消息等。

上传频率根据需求定。实时监控可能需要1秒钟传一次，普通的车队管理10秒或者30秒传一次就够了。频率高了流量费用也高。

不同车型的适配挑战

理论上听起来简单，实际操作中最头疼的是不同车型的适配。

国标GB/T 32960定义了新能源车的数据格式，但只覆盖了新能源车。传统燃油商用车大多遵循SAE J1939标准，但具体实现还是有差异。

更麻烦的是，很多车企在标准之外，还有自己的私有CAN报文。比如某些品牌会把故障码、保养提醒这些信息放在私有报文里，格式不公开。如果要读取这些数据，只能通过逆向工程或者找车企要技术资料。

我们做项目的时候，针对每个车型都要做适配工作。首先收集这个车型的CAN协议文档，如果拿不到文档，就用CAN分析仪录一段总线数据，人工分析报文格式。然后在网关里配置对应的解析规则。

SV910这种网关通常支持灵活的配置。可以自定义解析规则，指定哪个报文ID的哪几个字节代表什么含义，换算公式是什么。这样不同车型只需要修改配置文件，不用改代码。

我们建立了一个车型数据库，存储不同品牌不同型号的CAN协议配置。新项目来了，先查数据库有没有现成的配置。如果没有，就做一次适配，然后加到数据库里。现在库里已经有四五十种车型的配置了。

实时性和数据准确性的保障

车载网关读取CAN数据，实时性很重要。特别是在自动驾驶或者ADAS辅助驾驶场景，数据延迟可能影响安全。

CAN总线本身的延迟很低，微秒级。但网关处理数据、打包、上传，会引入额外延迟。如何控制这个延迟？

首先是减少处理环节。网关接收到CAN报文后，直接在中断处理函数或者高优先级任务里解析，不要排队等待。解析完立刻放到发送缓冲区，通过5G网络发出去。

其次是用硬件加速。一些高端的车载网关，CAN控制器集成了硬件过滤功能。可以在硬件层面配置过滤规则，只接收关心的报文ID，其他报文直接丢弃。这样减少了CPU的负担，提高了处理速度。

第三是时间戳管理。每条CAN报文在网关接收到的时候，要立刻打上时间戳。这个时间戳要足够精确，最好是微秒级。上传到云端的数据要带上这个时间戳，让云端知道数据是什么时候采集的。

SV910支持PTP/GPTP时间同步协议，可以保证网关的时钟和其他设备高精度同步。这对于需要多设备协同的场景很重要。

数据准确性也必须保证。CAN总线虽然有校验机制，但偶尔还是会出现错误数据。网关要做二次校验。比如发动机转速，正常情况下不可能突然从1000rpm跳到5000rpm再跳回来。如果出现这种异常数据，要标记为可疑数据，不直接使用。

还要处理总线静默的情况。如果长时间收不到某个报文，可能是对应的ECU故障了，或者总线断了。网关要能检测到这种情况，并上报异常。

双5G架构的优势

SV910是双5G架构，配了两个5G模组。为什么要双5G？

第一是冗余备份。商用车长途运输，可能经过信号不好的区域。单5G的话，信号断了数据就传不出去。双5G用两张不同运营商的SIM卡，电信和联通，或者移动和联通。一个信号差了，切换到另一个。

切换可以是自动的。网关实时监测两个5G链路的信号强度和延迟，选择质量好的那个用。或者两个链路同时用，做链路聚合，带宽翻倍。

第二是分流。车载应用通常有多种数据流。CAN总线数据、摄像头视频、定位数据、V2X通信数据。这些数据的特点不一样，对带宽和延迟的要求也不同。

可以把关键的控制数据走一条5G链路，大流量的视频数据走另一条。这样互不干扰，保证关键数据的实时性。

第三是安全隔离。有些车队管理平台出于安全考虑，要求车辆控制通道和数据采集通道物理隔离。双5G正好满足这个需求。控制指令走专用链路，采集数据走另一条，黑客即使攻破了数据通道，也没法篡改控制指令。

和车队管理平台的对接

车载网关采集到数据后，要上传到车队管理平台。平台通常是个云端服务，提供车辆监控、轨迹回放、报表统计、故障预警等功能。

数据上传的协议有几种选择。MQTT是最常见的。它是一种轻量级的消息队列协议，专为物联网设计。网关作为MQTT客户端，连接到云端的MQTT服务器，定期发布消息。

MQTT支持不同的QoS（服务质量）等级。QoS 0是最多一次，发了就不管，可能丢失。QoS 1是至少一次，保证送达但可能重复。QoS 2是恰好一次，既保证送达又不重复。根据数据的重要程度选择合适的QoS。

HTTP/HTTPS也常用。网关定期把采集的数据打包，通过HTTP POST请求上传到云端API。这种方式简单直接，兼容性好。缺点是HTTP的开销比MQTT大一些，不太适合高频次的小数据传输。

还有一些专用协议。比如JT/T 808是交通部制定的道路运输车辆卫星定位系统终端通信协议。很多商用车的车队管理平台用这个标准。网关要支持JT/T 808，需要实现完整的协议栈。

数据格式也要和平台约定好。常见的是JSON，可读性好，调试方便。但JSON比较占空间，如果流量费用敏感，可以用二进制格式，比如Protobuf或者自定义的紧凑格式。

故障诊断功能的实现

除了读取实时数据，车载网关还可以做故障诊断。

车辆ECU会产生故障码（DTC, Diagnostic Trouble Code）。比如发动机出问题了，会产生P0001、P0002这样的故障码。这些故障码存储在ECU里，可以通过CAN总线读取。

标准的诊断协议是ISO 14229（UDS, Unified Diagnostic Services）和SAE J1939-73。网关作为诊断客户端，向ECU发送诊断请求，ECU返回故障码和相关信息。

故障码读取出来后，要翻译成可读的故障描述。P0001代表什么意思？燃油体积调节器控制电路/开路。这个翻译过程需要故障码库。网关里可以内置常见故障码的描述，或者上传到云端后由云端翻译。

有了故障码，车队管理平台可以提前预警。比如发现某辆车产生了冷却液温度过高的故障码，立刻通知司机和维修部门，避免发动机过热损坏。

一些高级的应用还会做预测性维护。分析车辆的各种参数趋势，提前预判可能出现的故障。比如发现发动机机油压力逐渐下降，虽然还没触发故障码，但已经有苗头，可以提醒司机检查机油。

实际项目中的经验教训

做了这么多项目，踩过不少坑。

第一个教训是，一定要做好CAN总线的保护。车辆的CAN总线很重要，如果网关故障了，把CAN总线拉低或者发送错误报文，可能影响车辆正常运行。

所以网关的CAN接口要有电气隔离，防止故障蔓延。要有总线保护电路，过压、过流时能自动断开。软件上也要有保护机制，如果检测到异常就停止发送，避免干扰总线。

第二个教训是，车辆改装要合法合规。商用车加装车载网关，属于车辆改装。要符合国家和地方的法规要求，不能影响车辆的安全性能。有些地区要求改装后要去车管所备案。

第三个教训是，数据安全和隐私保护很重要。车辆行驶轨迹、驾驶行为这些数据涉及隐私。数据传输要加密，存储要脱敏。云端平台的访问要有权限控制，不能随便泄露给第三方。

总的来说，车载网关通过CAN总线读取车辆数据，是车联网应用的基础能力。技术本身不复杂，但要做好需要很多细节考虑。不同车型的适配、实时性保障、数据准确性、通信可靠性，每个环节都要打磨好，才能提供稳定可靠的服务。