2. 车联网通信基础
车联网不是“把车连上网”这么简单，它是一套由车、路、云、人、平台共同参与的分层通信系统。理解车联网通信，先要看清体系架构，再理解 V2X 的典型场景，最后才能谈协议分类与选型。否则很容易陷入“所有数据都上云”“所有通信都用 MQTT”这类工程误区。
一、车联网体系架构：端、管、云三层协同
从通信工程视角看，车联网通常划分为三层：端侧（感知与执行层）、管侧（网络与传输层）、云侧（平台与应用层）。端侧包括车载 T-Box、OBU、摄像头、雷达、ECU、手机 App 等；管侧包括蜂窝网络（4G/5G）、C-V2X 直连、Wi-Fi、以太网、CAN 总线等；云侧包括车联网平台、TSP、OTA 服务、高精地图、交通调度与数据分析系统。
三层之间并非简单串联，而是存在多路径协同。例如，紧急制动预警既可以通过 PC5 直连广播给周边车辆，也可以经 5G 上行到边缘云再下发；车辆状态数据则通常经 MQTT 上报至云平台。架构决定了“哪些数据走哪条路”，也决定了时延、可靠性和成本边界。
二、V2X 通信场景：从安全到效率再到服务
V2X（Vehicle to Everything）是车联网通信场景的总称，按对象可分为 V2V（车-车）、V2I（车-基础设施）、V2P（车-行人）、V2N（车-网络）。不同场景对通信指标的要求差异极大，这是协议选型的根本依据。
- 安全类场景：前向碰撞预警、盲区预警、紧急制动提醒。要求时延 10～50 ms、可靠性 99.999%，通常采用 C-V2X PC5 直连广播。
- 效率类场景：绿波车速引导、路口排队提醒、动态路径规划。时延 100～500 ms 可接受，多经蜂窝网络与云平台交互。
- 服务类场景：OTA 升级、远程控车、车辆状态上报、影音娱乐。对时延不敏感，但数据量大、并发高，适合 MQTT/HTTPS 承载。
三、通信协议分类：按“距离、时延、可靠性”划分
车联网涉及的协议栈非常宽，从物理层到应用层都有专用技术。工程上可按通信范围与用途分为四类：
| 协议/技术 | 典型范围 | 时延量级 | 典型用途 | 是否经公网 |
|---|---|---|---|---|
| CAN / LIN | 车内总线 | < 10 ms | ECU 控制、状态采集 | 否 |
| C-V2X PC5 | 车-车/车-路 数百米 | 10～50 ms | 碰撞预警、协同驾驶 | 否 |
| MQTT | 车-云 广域 | 100 ms～秒级 | 状态上报、指令下发 | 是 |
| HTTPS | 车-云 广域 | 秒级 | OTA、文件、鉴权 | 是 |
| UDP / RTP | 车-云/车-车 | 低 | 音视频流、实时媒体 | 视场景 |
四、选型原则：先定指标，再定协议
协议选型不是“哪个流行用哪个”，而是从业务指标反推。建议按以下顺序决策：
- 确定通信对象与范围：车内、车-车、车-路、车-云，范围决定候选协议集合。
- 确定时延与可靠性要求：安全类必须直连；非安全类可走公网。
- 确定数据方向与频率：高频小报文适合 MQTT 发布/订阅；低频大文件适合 HTTPS。
- 确定网络条件与成本：是否有 5G 覆盖、是否允许公网、流量成本如何。
- 确定安全与合规要求：是否需要双向证书、国密、数据出境限制。
五、案例与误区复盘
某商用车队项目最初把“碰撞预警”也做成 MQTT 上报到云平台再下发，结果端到端时延超过 800 ms，预警基本失效。复盘后发现：安全类场景必须用 PC5 直连广播，云平台只做事件记录与统计分析。调整后，预警时延降到 30 ms 以内，同时云端仍保留完整日志。
另一个常见误区是“所有数据都上云”。实际上，车内 CAN 数据量极大，全部上云既昂贵又无必要。正确做法是：本地域控先做过滤、聚合与事件提取，只把关键状态、故障码和统计结果通过 MQTT 上报。这样既降低带宽成本，也减少云端存储压力。
# 典型车云通信主题设计（MQTT）
vehicle/{vin}/status/report # 车辆状态上报，QoS 1
vehicle/{vin}/command/down # 云端指令下发，QoS 1
vehicle/{vin}/event/alert # 安全事件通知，QoS 1
vehicle/{vin}/ota/progress # OTA 进度，QoS 0
理解体系架构、V2X 场景、协议分类与选型原则，是后续学习 MQTT 与 HTTPS 工程实现的基础。只有先明确“数据从哪来、到哪去、要求多快多稳”，才能在具体协议配置中做出正确取舍。