2、远程监控系统架构：端-边-云协同架构、数据流走向、关键组件与通信协议概览
无人车的远程监控并非简单地将车载摄像头画面推送到监控大屏，而是一套覆盖“车端采集—边缘处理—云端汇聚—终端呈现”的完整系统工程。由于无人车运行环境复杂、网络条件波动、数据种类繁多（视频流、高频状态数据、告警事件），传统“车端直连云端”的集中式架构在带宽、时延和可靠性上均无法满足要求。因此，业界普遍采用端-边-云三层协同架构，将计算与存储压力分层卸载，实现数据的分级处理与按需回传。本章将围绕该架构的组件划分、数据流走向、关键通信协议选型及工程落地要点展开深度解析。
上图展示了端-边-云三层架构的核心组件与数据流走向。端侧负责原始数据采集与轻量预处理，边侧承担区域级数据汇聚与实时响应，云侧则完成全局存储、分析、展示与决策。三层之间通过异构网络连接，形成“车端产生数据—边缘过滤清洗—云端深度处理”的流水线。下面从各层职责、数据流细节、通信协议选型三个维度展开。
2.1 端侧（车端）组件与数据采集
核心原理：端侧是数据的源头，其核心职责是多源异构数据的同步采集与初步编码。无人车通常搭载6-12路摄像头（前视、环视、后视）、1-3颗激光雷达、组合导航系统（GPS/IMU）以及车辆CAN总线接口。这些传感器产生的数据格式、频率和量级差异巨大：视频流单路1080P@30fps约需4-8Mbps码率，激光雷达点云每秒可达数十万点（约10-50Mbps），而CAN总线数据仅为每秒几十KB。端侧计算单元（通常为高算力工控机或域控制器）需要对这些数据进行时间同步（PTP或GPS授时），并完成视频的H.264/H.265硬编码、点云降采样、状态数据打包等预处理。
操作流程：端侧数据采集与处理遵循以下步骤：
- 传感器驱动与时钟同步：各传感器通过PPS（秒脉冲）信号或IEEE 1588协议对齐时间戳，确保后续融合分析时数据时间轴一致。
- 视频编码与ROI标注：车载摄像头输出原始YUV数据，经GPU/NPU硬件编码为H.264/H.265流，同时根据业务需求标注感兴趣区域（ROI），如车辆前方50米区域。
- 状态数据打包：将车辆速度、转向角、电池电量、定位坐标、自动驾驶模式（手动/自动驾驶/远程遥控）等CAN信号按固定频率（通常10-50Hz）封装为JSON或Protobuf消息。
- 本地缓存与断网保护：在车端配置SSD环形缓冲区（如存储最近30分钟视频），当网络中断时自动缓存，恢复后按时间戳续传。
2.2 边侧（边缘节点）的汇聚与实时响应
核心原理：边缘层是端-云之间的“缓冲带”和“加速器”。其部署位置通常在无人车运营园区、矿区、港口或城市道路旁的边缘机房。边缘节点承担三大职责：协议转换与数据汇聚、实时告警触发、带宽削峰填谷。由于车端网络信号不稳定，若所有数据直接上云，会造成云端接入压力大、链路拥塞、费用高昂。边缘节点通过有线网络（光纤/工业以太网）同时接入多辆无人车，将车端上传的RTSP视频流转为云端所需的GB28181或HLS流，将MQTT状态数据转为Kafka消息，实现协议归一化。
关键组件与功能：
| 边缘组件 | 核心功能 | 典型实现 |
|---|---|---|
| 视频接入网关 | 接收多路RTSP流，转码、封装、分发 | NVIDIA Jetson AGX Orin + FFmpeg |
| AI推理盒子 | 对视频流做抽帧分析，识别行人、车辆、障碍物、车道线偏离等事件 | 地平线旭日X3、华为Atlas 500 |
| 数据汇聚网关 | 接收车端MQTT/CoAP消息，解析、清洗、格式转换后上云 | EMQX边缘版、Node-RED |
| 存储与缓存 | 存储最近1-2小时视频片段，缓存告警图片/短视频 | NVMe SSD阵列、Redis |
案例拆解：在某港口无人集卡项目中，30辆无人车同时作业，每辆车回传4路1080P视频（总码率约48Mbps）和50Hz状态数据。若全部直连云端，需占用1.5Gbps上行带宽，且云端流媒体服务器需处理120路并发拉流，成本极高。部署边缘节点后，每5辆车接入一个边缘网关，边缘AI盒子对视频进行ROI裁剪（仅保留车辆前后方区域），将码率压缩至原流的40%，同时将告警事件（如行人闯入、车辆急停）以截图+短视频形式实时上传，普通视频仅存储30秒循环片段。最终云端仅需处理约600Mbps视频流和低频告警事件，带宽成本降低60%，告警响应时延从原来的2秒降至300毫秒。
2.3 云侧平台与数据流终点
核心原理：云侧是远程监控的“大脑”和“数据仓库”。它接收来自多个边缘节点的数据流，完成全局存储、深度分析、可视化呈现和远程控制指令下发。云侧架构通常分为四层：接入层、处理层、存储层、应用层。接入层负责与边缘节点建立长连接（如WebSocket、Kafka Consumer），处理层进行数据清洗、告警规则引擎匹配、AI二次分析（如跨摄像头轨迹追踪），存储层采用混合存储策略（热数据用时序数据库，冷数据用对象存储），应用层则面向监控人员提供Web端大屏、手机APP和API接口。
数据流走向详解：
- 视频流路径：边缘节点将转码后的HLS/HTTP-FLV流推送到云侧流媒体服务器（如SRS、ZLMediaKit），监控端通过Web浏览器或客户端拉流观看。对于需要长期保存的视频，云侧按时间切片存储至对象存储（如MinIO、阿里云OSS），保存周期通常为7-30天。
- 状态数据路径：边缘节点将清洗后的车辆状态消息发布至Kafka Topic（如
vehicle_status），云侧消费者服务订阅该Topic，将数据写入时序数据库（如TDengine），用于车速曲线、电池衰减、轨迹回放等分析。 - 告警事件路径：边缘AI盒子识别到异常后，生成告警事件（包含事件类型、时间、车辆ID、抓拍图片、短视频片段），通过MQTT/HTTP POST上报至云侧告警服务。告警服务将事件写入Elasticsearch用于检索，同时推送至监控大屏和值班人员手机。
// 云侧告警事件消息示例（JSON格式）
{
"event_id": "evt_20240511_001234",
"vehicle_id": "AGV-07",
"event_type": "PEDESTRIAN_INTRUSION",
"timestamp": "2025-05-11T10:23:45+08:00",
"location": {"lat": 31.2304, "lon": 121.4737},
"video_url": "https://cloud.example.com/record/2025/05/11/AGV-07_102345.mp4",
"snapshot_url": "https://cloud.example.com/snap/AGV-07_102345.jpg",
"severity": "HIGH",
"edge_node_id": "edge-shanghai-01"
}通信协议选型对比：
| 数据类别 | 推荐协议 | 优势 | 劣势 |
|---|---|---|---|
| 视频流（实时） | RTSP（车端→边缘）、GB28181（边缘→云）、HLS/WebRTC（云→浏览器） | RTSP低时延；GB28181国标兼容；HLS穿透防火墙 | RTSP不适合公网；HLS时延3-5秒 |
| 状态数据（高频） | MQTT over TLS（车端→边缘）、Kafka（边缘→云） | MQTT轻量、支持QoS；Kafka高吞吐、可回溯 | MQTT不适合海量历史数据；Kafka运维复杂 |
| 告警事件（低频） | HTTP RESTful / MQTT | 简单通用，易于集成第三方 | HTTP需处理连接建立开销 |
| 远程控制指令 | WebSocket（云→边缘→车端） | 全双工、低时延，支持下行指令 | 需处理心跳保活 |
2.4 常见误区与设计复盘
误区一：所有数据都上云。这是最常见的错误。将全部视频和点云数据实时上传，不仅浪费带宽，还会导致云端存储成本失控。正确做法是“边缘过滤+云上精选”：普通数据仅上传特征值或缩略图，只有告警事件和人工调阅时才上传完整数据。
误区二：忽略网络抖动对视频的影响。无人车在移动中会频繁切换基站，导致网络丢包和时延抖动。若视频传输使用TCP，丢包重传会造成画面卡顿；若使用UDP，则可能花屏。建议在车端与边缘之间使用SRT（Secure Reliable Transport）协议，它基于UDP但具备丢包重传和自适应码率功能，能有效对抗网络抖动。
误区三：边缘节点与云端数据不一致。当边缘节点缓存的数据因网络中断未能及时上云时，云端查询到的状态可能滞后。需设计数据补偿机制：边缘节点记录数据序列号（SeqNo），云端检测到序列号不连续时，主动向边缘拉取缺失数据。
总结复盘：端-边-云架构的核心设计原则是“数据分级、按需回传、实时优先”。在实际项目中，建议先明确监控业务需求（如需要多高实时性、需要保存多久数据、需要识别哪些事件），再反推各层组件的算力、存储和带宽需求。下表总结了不同场景下的架构选型建议：
| 应用场景 | 端侧要求 | 边缘节点 | 云侧重点 |
|---|---|---|---|
| 封闭园区物流车 | 4路720P视频，10Hz状态 | 单园区部署1个边缘节点 | 实时监控+轨迹回放 |
| 城市开放道路Robotaxi | 12路1080P视频，50Hz状态 | 按区域部署，需支持车辆跨区切换 | 高并发接入+AI事件分析 |
| 矿区/港口无人驾驶 | 多传感器融合，高精度定位 | 强震动、高温环境，需工业级硬件 | 远程遥控接管+数据长期归档 |
最后需要强调的是，远程监控系统的可靠性不仅取决于架构设计，还依赖于完善的运维监控体系。建议对端-边-云全链路实施链路质量监测（如ping时延、丢包率、视频帧率、消息积压数），并设置告警阈值，确保在系统出现异常时能快速定位问题节点。