做车联网这行三年多，接触过不少无人车项目。要说车上哪个设备组合最容易出幻影故障，车载通信网关和摄像头系统绝对排得上号。

为什么这么说？因为摄像头拍的视频要实时传到云端，对带宽、延迟、稳定性的要求都很苛刻。稍微有点闪失，要么画面卡成PPT，要么干脆黑屏。

今天就聊聊这两个设备怎么配合干活，以及实际应用中需要注意什么。

摄像头在无人车上到底干什么

先说摄像头的活儿。一台L4级无人车上通常会装8到12个摄像头，覆盖车辆周围360度视野。这些摄像头分几类：

前视摄像头最重要，一般会装2-3个，分别负责远距离、中距离和近距离的视野。远距离那个用来看红绿灯和前方路况，视角窄但看得远，能到150米。中距离的负责看车道线和前车，近距离的主要用于路口和低速场景。

侧视和后视摄像头用来盲区监控和变道判断。尤其是B柱位置的盲区，激光雷达扫不太到的地方，就得靠摄像头补盲。

环视摄像头通常是4个鱼眼镜头，装在车辆四角，主要用于自动泊车和低速避障。鱼眼畸变很严重，需要软件矫正。

这些摄像头产生的数据量有多大？一个1080P的摄像头，30帧每秒，未压缩的原始数据流大概是100-150Mbps。车上10个摄像头，理论峰值就是1-1.5Gbps。当然实际会做压缩，但即便压缩到十分之一，总带宽也要上百兆。

为什么必须配车载网关

有人可能问，摄像头数据不是给车上的计算平台用吗，为什么还要通过网关传到云端？

这里有几个实际需求：

远程监控需求。运营无人车的公司，需要在远程监控中心实时看到车辆视野。万一车遇到处理不了的情况，人工可以远程接管。这就需要至少把前视摄像头的画面实时传回去，延迟要控制在200毫秒以内。

数据标注需求。训练自动驾驶AI模型需要海量的真实道路数据。摄像头拍到的各种corner case场景，都要传回云端做标注。这个倒不需要实时，但数据量很大。

车队管理需求。商用无人车跑运营，车队管理平台需要知道每辆车的位置、状态、是否出现异常。摄像头画面是很重要的判断依据。

法规要求。一些地区的自动驾驶法规要求，测试车必须配备黑匣子和远程监控能力。摄像头数据要能随时调取。

所以车载网关在这里充当的角色，就是把车内局域网的视频数据，通过4G或5G网络传到云端服务器。听起来简单，实际做起来讲究很多。

这俩设备怎么连起来的

车上的网络拓扑通常是这样：摄像头通过GMSL或者车载以太网连接到域控制器，域控制器再通过以太网连到车载网关，网关负责对外的4G/5G通信。

为什么不让摄像头直接连网关？因为摄像头拍的原始数据要先给计算平台做实时处理，用于自动驾驶决策。处理完之后，才选择性地通过网关上传云端。

这里有个关键点：什么数据要上传，什么数据不上传，谁来决定？

通常有两种模式。第一种是域控制器来决定，它分析完数据后，把需要上传的视频片段发给网关。第二种是网关自己做边缘计算，接收所有视频流，但只把重要片段上传。

第一种模式比较常见，因为域控制器算力强，判断更准确。但缺点是域控制器要同时干太多活，负载高的时候可能顾不过来。

第二种模式对网关的要求就高了，不仅要能跑Linux系统，还得有一定的AI推理能力。现在有些车载网关会集成NPU芯片，专门用来做边缘AI推理。

带宽是最大的瓶颈

理论上5G网络上行能到几百Mbps，但实际测试中，车辆在高速移动状态下，5G网络的实际上行带宽经常只有50-100Mbps，而且抖动很大。在隧道、高架桥下、密集城区这些场景，信号更差。

10个摄像头的原始数据流是上百兆，就算压缩十倍也要十几兆。怎么在50Mbps的带宽下传输？这就是核心问题。

第一个办法是选择性传输。正常行驶时，只传前视摄像头的画面，而且可以降到720P或者540P。其他摄像头的数据只在本地存储。只有在发生异常事件时，比如急刹车、人工接管、系统报警，才把所有摄像头的数据上传。

第二个办法是分层编码。视频流编码成基础层和增强层。基础层保证基本画面质量，增强层提供更清晰的细节。网络好的时候传两层，网络差的时候只传基础层。H.265编码标准就支持这个特性。

第三个办法是动态码率调整。根据网络状况实时调整视频码率。这个技术在直播行业已经很成熟了，车载场景也可以借鉴。网关要能实时监测上行带宽和丢包率，然后通知域控制器调整编码参数。

第四个办法是边缘存储加延迟上传。车上配个大容量SSD，把视频先存在本地。等车回到停车场接上WiFi，或者5G信号好的时候，再批量上传。这个方案适合训练数据采集，但不适合需要实时监控的场景。

延迟问题同样要命

远程监控和接管对延迟要求很高。从摄像头采集画面，到云端监控人员看到，整个链路的延迟要控制在300毫秒以内，理想情况是200毫秒。

这300毫秒怎么分配？摄像头采集和编码大概30-50毫秒，网关打包发送10-20毫秒，4G/5G网络传输100-150毫秒，云端解码和渲染30-50毫秒。最大的不确定因素在网络传输。

为了降低延迟，有几个常用手段：

用UDP而不是TCP传输视频流。TCP有重传机制，丢包了会等重传，延迟会飙升。UDP虽然不可靠，但实时性好。丢几个视频帧问题不大，但延迟高了人就反应不过来。

用专门的低延迟编码器。普通的H.264/H.265编码器为了压缩率会牺牲延迟。现在有专门优化低延迟的编码器，比如x264的zerolatency preset，可以把编码延迟控制在20毫秒以内。

用边缘计算节点做中转。不直接把视频传到远程数据中心，而是先传到附近的边缘节点。边缘节点做初步处理和判断，只有必要时才转发到远程。这样能省掉几十毫秒的广域网传输时间。

优化4G/5G网络的QoS配置。跟运营商申请专用APN，给视频流分配更高的优先级。虽然不是所有地方都能申请到，但商用无人车一般可以跟运营商谈。

稳定性才是长期挑战

带宽和延迟问题技术上还好解决，最头疼的是稳定性。无人车要在各种复杂环境下工作，网络状况千变万化。

地下车库里5G信号直接没了，只能靠4G。高速公路上车速120公里每小时，基站切换频繁，经常掉线重连。城市隧道里信号断断续续。这些场景下，怎么保证视频传输不中断？

最基本的做法是多链路冗余。车载网关配两张SIM卡，一张电信一张联通，用不同运营商的网络。哪个信号好用哪个，或者两个同时用做链路聚合。

第二是本地缓存机制。网关内置缓存，网络断了之后视频先存本地，等网络恢复了再补传。缓存大小一般配几个GB，能顶几分钟。

第三是快速重连机制。传统的TCP连接断了重连要好几秒，用UDP加上应用层的快速重连协议，可以把重连时间压到500毫秒以内。

第四是降级策略。网络实在不行了，就只传最低分辨率的画面，或者只传关键帧。保证至少能看到车的状态，总比完全黑屏强。

功耗和散热也得考虑

车载网关持续用4G/5G传输高清视频，功耗能到20-30瓦。夏天车顶暴晒，设备温度能飙到70-80度。很多消费级的通信模组在这个温度下就不稳定了，要么降频要么重启。

所以车规级的网关都会做散热设计，金属外壳加导热片，有的还会接到车辆的液冷系统。成本会高不少，但稳定性有保障。

还有就是功耗管理。车停着的时候，网关要能进入低功耗模式，不然12V电瓶撑不了多久。但又要能够随时唤醒，响应远程监控指令。这个需要网关支持深度睡眠模式，功耗能降到1瓦以下。

安全问题不能忽视

视频数据传到云端，必须加密。车上摄像头拍的画面涉及隐私，如果被劫持了后果很严重。

通常的做法是用TLS或者DTLS加密传输通道。网关和云端服务器之间建立加密连接，所有视频数据都在加密通道里传。

但加密会增加延迟和CPU负担。为了平衡性能和安全，可以只加密控制信令，视频流本身用轻量级的加密。或者在硬件层做加密加速，用专门的加密芯片。

另外还要防止网关本身被攻击。车载网关跑的是Linux系统，理论上可能被入侵。所以要做安全加固，关掉不必要的端口和服务，定期更新固件补丁，配置防火墙规则。

一些实际的取舍

说了这么多技术细节，实际项目中还是要根据场景做取舍。

如果是robotaxi这种载人服务，远程监控的实时性最重要，那就得牺牲一些画质和数据完整性，优先保证低延迟。

如果是无人配送车或者扫地车，速度慢也不载人，那可以降低实时性要求，多做本地存储，回到停车点再批量上传。

如果是矿区、港口这些封闭场景，可以部署私有5G网络，带宽和延迟都可控，系统设计就简单很多。

总之车载网关和摄像头的配合，核心就是在有限的带宽和不稳定的网络条件下，尽可能高效可靠地传输视频数据。技术方案很多，但没有银弹，得根据具体需求来选。

现在这个领域还在快速发展中，5G的普及、边缘计算的成熟、编解码技术的进步，都会带来新的可能性。做这行得持续跟进新技术，同时把基础打牢。