2. 车云消息传输基础
车云消息可靠传输的第一步，是建立对“谁在发、发给谁、发什么、要求多可靠”的统一认知。车联网并非单一链路，而是由车内总线、车载网关、蜂窝网络、云端接入层与服务集群共同构成的多段通信系统。消息从车辆传感器产生，到云端业务消费，中间要跨越多个协议域与网络边界。理解这些边界，才能理解为什么断点续传、去重、顺序保证和幂等处理是工程必需，而不是可选项。
一、车云通信架构：四层分段模型
从工程视角看，车云通信可抽象为四层：车端感知与执行层、车载网关与T-Box层、移动网络与接入层、云端消息平台与业务层。车端通过CAN、LIN、以太网等总线采集信号；T-Box或车载网关负责协议转换、消息打包、缓存与重传；蜂窝网络（4G/5G）提供无线承载；云端接入网关完成鉴权、限流、协议解析，再交由消息队列或流处理平台分发给业务服务。
关键点在于：每一层都可能丢包、延迟或重复。车端到T-Box可能因总线负载丢帧；T-Box到云端可能因隧道切换、弱覆盖断连；云端接入层可能因扩容、重启导致连接中断。因此，可靠传输必须按“分段治理、端到端兜底”的原则设计。
二、消息类型：从遥测到控制
车云消息按业务语义可分为四类，每类对传输的要求差异显著：
- 遥测数据（Telemetry）：车速、电量、胎压、电机温度等周期性上报，频率高、单包小，允许少量丢失，通常使用QoS 0或QoS 1。
- 控制指令（Command）：远程解锁、空调预热、充电启停等下行指令，必须可靠到达且不能重复执行，通常使用QoS 1或QoS 2，并配合指令ID幂等。
- 告警事件（Event）：碰撞告警、故障码、电池热失控预警，突发性强、优先级高，需要QoS 1并保证云端去重。
- OTA与日志（Bulk）：固件包、诊断日志，数据量大、耗时长，必须支持断点续传与分片校验。
三、QoS等级：语义与代价
MQTT定义的QoS等级是车云传输最常用的语义基准：
| QoS等级 | 语义 | 交互次数 | 适用场景 | 风险 |
|---|---|---|---|---|
| QoS 0 | 至多一次 | 1 | 高频遥测、非关键指标 | 可能丢失 |
| QoS 1 | 至少一次 | 2 | 告警、控制指令、OTA分片 | 可能重复 |
| QoS 2 | 恰好一次 | 4 | 关键控制、计费相关 | 开销大、延迟高 |
四、典型应用场景与挑战
以“远程空调预热”为例：用户App下发指令，云端生成唯一指令ID，通过MQTT QoS 1下发至T-Box；T-Box执行后回传执行结果。若车辆处于地库弱网，指令可能超时；云端重发后，T-Box可能收到两条相同指令。此时必须依靠指令ID做幂等，避免重复启动。若车辆完全离线，指令需进入离线队列，待车辆重新上线后按序补发。
再以“电池热失控预警”为例：告警必须在秒级到达云端，且不能因网络抖动丢失。车端需将告警写入本地持久化队列，按优先级重传；云端接入层需支持QoS 1并做去重，业务层再触发短信、App推送与工单。
五、核心挑战清单
- 弱网与切换：隧道、地库、高速切换导致连接中断，需快速重连与消息缓存。
- 重复与乱序：QoS 1重传、多链路并发导致重复，需序列号与幂等键。
- 资源受限：T-Box存储与算力有限，缓存队列需设上限与淘汰策略。
- 安全与合规：指令需鉴权、签名、防重放，数据需满足隐私法规。
- 可观测性：端到端时延、丢失率、重传次数需可监控、可告警。
# 典型车云消息信封字段示例
{
"msgId": "01HZX9K2...", // 全局唯一，用于幂等
"vin": "LSV...", // 车辆标识
"type": "COMMAND", // TELEMETRY / COMMAND / EVENT / BULK
"qos": 1, // 0 / 1 / 2
"seq": 10245, // 车端单调递增序列号
"ts": 1735689600000, // 毫秒时间戳
"payload": { "action": "AC_ON", "temp": 26 }
}掌握上述架构、消息类型、QoS语义与挑战，是后续设计断点续传、去重、顺序保证与幂等机制的基础。只有先明确“消息长什么样、要求多可靠”，才能在工程上做出正确的取舍。