这几年一直泡在自动驾驶相关项目里圈子里的共识慢慢收敛到一件事上单车智能做得再极致车还是看不见墙后面的东西。边缘计算下沉到路边说白了就是想办法让路本身变成车的“眼睛”和“大脑”把实时决策的时延压缩到人的反应速度以下。这篇分享聚焦无人驾驶中的边缘计算与实时决策这条从云端下沉到路边智能的技术路线聊聊它到底解决什么问题、怎么落地、部署中会踩哪些坑。适合正在做车路协同、智能路口、自动驾驶量产项目的工程师也适合想搞明白“为什么车不能自己算完所有事情”的产品和技术管理者。1. 先看清一个本质问题无人驾驶为什么不能只靠车自己算1.1 单车智能的天花板传感器盲区与视距限制很多不在一线做系统的人对自动驾驶有个误解觉得只要算法够强、算力够大车的感知就能无限接近人类甚至超过人类。真实情况是车辆自身的传感器布局天然受限车顶激光雷达看得再远也绕不开物理遮挡。一个典型的十字路口左侧驶来的车辆被路边建筑和绿化带挡住直到距离路口不到三十米才进入自车传感器视野。这个距离下两车相对速度加起来可能超过80km/h留给系统的反应时间只有一两秒。更麻烦的是大车遮挡一辆长挂车在相邻车道等红灯它后面突然窜出一辆电动车自车摄像头和毫米波雷达根本看不见等大车起步、电动车露头的时候自车制动距离往往已经不够了。这不是算法能解决的问题这是信息获取方式的结构性缺陷。车坐在地上地面视角决定了它只能看到“锥形视野”里的东西。想要提前知道路口侧向有没有来车、想要穿透前车看到更远处的异常事件唯一的办法是让感知位置变高、让感知视角变广。路边智能的核心价值就在于把传感器架到杆件上、龙门架上以俯视视角覆盖路口全貌再把处理结果低时延地送给车。以前这些信息靠人去判断、靠经验去猜现在靠路侧边缘计算变成结构化数据算完直接发给车。1.2 时延账本100毫秒里车已经跑了多远做实时决策系统先得把“快”这件事量化。车速60km/h的时候是16.7米每秒100毫秒就是1.67米200毫秒是3.34米。听着不多但紧急制动场景下这多出来的两米可能就是撞上与擦肩而过的区别。再看L4级自动驾驶对全链路时延的工程基线从传感器捕捉到目标到感知融合、决策规划、执行器响应业内一般按200毫秒到300毫秒来压。人眼的反应时间约200毫秒经验丰富的驾驶员实际完成制动操作往往需要500毫秒以上机器的优势就在于可以把这个时间稳定压缩到几百毫秒以内。但这里有个矛盾如果所有计算都依赖云端数据从路侧上传到云中心、云中心算完再下发一个回合至少几百毫秒碰上网络波动直接超过一秒。这种时延只能做全局调度和离线分析根本支撑不了实时决策。所以边缘计算下沉不是“锦上添花”而是整个决策链路的刚性约束。原来喊“所有计算上云”那套思路在自动驾驶场景里必须修正为“能本地算的绝不上传非得上传的只传结果”。2. 边缘计算在车路协同里到底扮演什么角色2.1 云边端三级架构不是替代关系是接力关系现在做车路云一体化行业内普遍接受的是云、边、端三级架构。云中心管的是长周期、全局性的事情比如高精地图更新、跨路口的路径规划、模型训练、故障统计它对时延不敏感强调的是计算能力和存储能力。边缘节点部署在路口、隧道、匝道这些关键位置管的是短周期、局部性的实时感知和决策强调的是确定性时延和数据本地化。端就是车本身负责执行、本车感知和车内决策。这三层不是替代关系是接力关系。车端算力再强也没有路侧的上帝视角云中心算力再大也够不着毫秒级的响应要求。边缘节点夹在中间把云端的模型能力、路侧的全景感知、车端的实时执行串成一条低时延链路。我见过不少项目一上来就追求“全上云”结果路口协同预警业务延迟飘到800毫秒体验极差。反过来把所有逻辑都堆在车端又回到单车智能的盲区问题。三级架构听起来朴素但它同时解决了视野、算力、时延三个维度的约束。2.2 边缘下沉解决的三件事时延、带宽、可用性边缘计算下沉到路边第一个价值就是时延可控。路侧设备和信号机、边缘计算节点之间的交互走有线或短距离直连通信单跳时延可以做到个位数毫秒。第二个价值是带宽压力骤减。一个路口十六路摄像头加上多套毫米波雷达原始码流全部回传中心百兆带宽根本扛不住。边缘节点把原始数据消化成本地结构化目标信息只把目标类型、位置、速度、轨迹片段上传带宽需求直接下降两三个数量级。第三个价值是可用性。自动驾驶不能赌网络永远顺畅边缘节点在断网、拥塞时依然能独立完成路口感知和预警发布中心掉线只是影响统计和全局优化不影响单点安全功能。这三个价值放在一起就是“把计算搬到数据产生的地方”。云端的角色没有消失而是退到了更合适的位置它负责给边缘下发模型、汇聚边缘上报的脱敏统计信息、做跨区域调度。真正的毫秒级业务闭环全部留在路边。理解了这个分工后续选型、部署、运维才不会跑偏。3. 路边智能的落地形态路侧单元与感知计算3.1 路侧单元的一般构成与部署位置路侧智能的物理载体是路侧单元业内一般叫RSURoad Side Unit但这个名字在不同项目里指的东西差别很大。有的地方RSU只指通信盒子有的地方把整个路侧感知计算一体化设备都叫RSU。我这里说的路侧单元是完整形态感知模块加上计算模块加上通信模块。感知模块通常包含路侧摄像头、毫米波雷达复杂路口会加装激光雷达。摄像头负责识别类型、颜色、车牌、信号灯状态毫米波雷达负责全天候测距测速激光雷达提供高精度三维轮廓和轨迹。计算模块承担融合、跟踪、预测和事件检测硬件上常见的是工业级工控机配合GPU或NPU加速卡。通信模块分两部分一部分走C-V2X PC5直连通信把结果发给周围车辆另一部分走蜂窝网或光纤把统计数据和异常事件回传中心。部署位置上十字路口是最常见的场景设备一般装在信号灯横臂杆或专用杆件上。杆件高度六米到八米比较合适太高了俯视角度太平太低了容易被大车遮挡。隧道和匝道是事故高发区也是部署重点但环境更苛刻要考虑低照度、通风和有限空间。真正决定部署位置的不是“哪里看着顺眼”而是“哪里存在单车感知盲区”和“哪里需要提前预警”。3.2 感知融合摄像头、毫米波雷达、激光雷达怎么配合多传感器融合听起来高级实际做下来就是“各取所长互相兜底”。摄像头对颜色和纹理敏感能分清红灯绿灯、轿车还是卡车但在强逆光、夜间弱光环境下可靠性明显下降。毫米波雷达不受光照和雨雾影响对运动目标的速度测量特别准缺点是点云稀疏对静止目标区分能力弱对行人的反射特征不稳定。激光雷达精度最高能给出目标的三维轮廓但价格贵、对雨雾和灰尘敏感。雷视融合是目前路侧感知的主流方案。具体流程是先做传感器标定把毫米波雷达和摄像头统一到同一个世界坐标系下然后由毫米波雷达给出候选目标位置作为“注意力提示”接着视觉在对应区域做目标分类和尺寸估计最后用卡尔曼滤波或更现代的多目标跟踪方法把时间序列上的检测结果关联成轨迹。雷视融合的价值体现在互相校验一个传感器掉线或者给出错误数据时另一个还能顶住不会出现整个感知系统瞬间失效的情况。加了激光雷达之后融合复杂度会明显上升但换回来的是对静止障碍物和路沿的三维精细建模。典型场景是路侧停车、施工区域检测纯摄像头的测距精度不够毫米波雷达对静止目标又容易漏检这时候激光雷达的优势就体现出来了。我的经验是能不加激光雷达就先不加它的维护成本和标定成本比很多人想象得高先用雷视融合把90%的场景跑稳再根据实际漏检数据决定是否加钱加设备。3.3 边缘计算设备的关键参数选型路侧边缘计算的硬件选型有几个参数必须抠死。第一个是算力。一个标准十字路口四方向感知目标规模从几十到上百个如果只做目标级融合与规则决策几十TOPS的算力就够用如果要在路边跑大模型做结构化场景理解、做多目标轨迹预测就需要上百TOPS的GPU或NPU。第二个是功耗和散热。杆件上取电有限不少现场只能拉220V市电设备功耗普遍希望控制在150瓦以内再高就得考虑散热和供电改造。第三个是工作温度范围。户外设备至少要扛住-40到70摄氏度的宽温要求工业级SSD和宽温内存是标配商业级组件在夏天暴晒下很容易触发降频。接口时延同样容易被忽视。边缘计算节点和路侧传感器之间走千兆以太网还是走工业相机专用接口直接影响数据采集时延。不要只看CPU和GPU型号整机从收到数据到吐出决策结果的总时延才是关键指标正规一点的设备厂商会把这个指标直接写进规格书。实操中我建议在选型阶段就让厂商提供同形态设备在满负载下的时延压测报告而不是只看浮点算力数字。4. 从边缘决策到车实时性是怎么保证的4.1 毫秒级通信链路PC5与Uu口的配合路侧计算的结果要送进车内靠的是车路通信。目前主流的C-V2X蜂窝车联网体系里两条链路配合使用PC5直连通信和Uu蜂窝通信。PC5工作在5.9GHz频段车和路之间直接通信不经过基站端到端时延能做到20毫秒以内这是实时决策的主通道。Uu口走蜂窝网络时延通常几十毫秒起步、且受网络负载影响适合用来做红绿灯配时方案的批量下发、区域交通事件推送这些非实时业务。实际工程里PC5链路的问题是覆盖范围有限几百米外基本就断连了而且容易受建筑物遮挡。所以路侧决策不是“广播出去就完事”还要配合车载终端的接收状态做可靠性设计重要预警消息采用周期性重复发送像盲区来车预警这类安全消息一般要求消息发送频率不低于10Hz也就是每100毫秒发一次连续收到多次才会触发车内提示或制动干预避免单次丢包导致的漏报。通信时延预算也要提前分配。路侧感知处理占50毫秒边缘决策占30毫秒PC5发送加车端接收处理占20毫秒车内决策执行占100毫秒以内全链路加起来可以压在200毫秒到300毫秒之间。这条预算链路上每一环都不能超所以做路侧系统的人必须关心通信模块的发送频率和缓冲策略而做车端系统的人必须关心消息过滤和降级逻辑。两边经常因为“消息到了但车内处理太久”吵得不可开交实际上问题往往出在车端把路侧消息排在了视觉感知任务后面。4.2 时间同步与ID关联数据对得上才是关键多传感器融合有个绕不过去的基础问题时间同步。路侧摄像头、雷达各发各的时间戳如果没对齐一辆以20米每秒速度行驶的车辆100毫秒的时间误差就对应2米的位置偏差融合出来的轨迹基本没法用。行业标准做法是GNSS授时加PTP精确时间协议把路侧所有传感器和边缘计算节点的时钟统一到几十微秒量级。这里有个工程细节雷视融合时图像帧和雷达数据包的时间戳必须在边缘计算节点里做插值对齐不能只看“到达时间”因为不同传感器链路内的缓存延迟完全不同。比时间同步更头疼的是ID关联。路侧系统给每个目标分配一个跟踪ID车端系统自己也有一个目标列表双方对“这是同一个目标”的判定必须一致。常见做法是以全局位置作为关联依据路侧把目标的经纬度、速度、航向角按统一坐标系发出来车端把自车感知到的同类目标映射到同一坐标系距离和航向接近的分到同一个“语义身份”下。这个逻辑在目标少时很稳在密集车流里就很容易错配所以我更推荐在路侧和车端之间建立一套轻量级的身份协商机制车端在进入路口覆盖范围时向路侧注册本车ID路侧在后续消息里带着这个ID发布相关信息相当于双方先握手再协作而不是事后猜同一性。4.3 决策结果怎么变成车辆行动路边算出来的决策结果不是直接控车而是以信息的形式辅助车端决策。最基础的一类是状态推送比如信号灯剩余时间、前方拥堵情况、下一路口建议速度。这类信息车端接收后可以平滑调整车速实现绿波通行。第二类是危险预警比如侧向来车冲突、行人闯入、前方异常停车路侧通过PC5把事件位置和类型发给车车端根据自车状态判断是否触发减速或转向避让。第三类是协同控制建议比如交叉口车辆通行次序建议车端在L4模式下可以纳入规划层做决策参考。车端接到消息后不是无条件执行而是做“可信度评估”。消息来源是否可靠目标位置和自车传感器检测结果是否冲突如果车端视觉明明看到目标还在三十米外路侧却报正碰撞预警中间肯定有一方错了。常见做法是设置证据融合窗口连续N条路侧消息与自车感知一致才采信否则先降级为提示级别。这个机制非常重要路侧设备故障、标定漂移、时间同步失效都会导致误报误报多了一次车端就会“狼来了”后续真实预警反而被忽略。做实时决策系统安全的关键不只是“快”还有“可信”。5. 实操部署中的典型问题与排查记录5.1 路侧感知设备振动导致数据对不齐路侧摄像头和激光雷达装在杆件上汽车驶过、大风天气、甚至施工振动都会让设备外参发生微小偏移。刚标定完的时候激光点云投影到图像上严丝合缝过一个月再看点云边缘和目标框已经错位几十像素了。对不齐的直接后果是雷视融合置信度下降目标位置输出抖动严重时会把静止的灯杆误检成移动障碍物。这个问题靠定期人工标定根本扛不住尤其是一条路几十个路口标一遍要耗掉很多人力。后来我们改成在线校验方案利用路口固定的标志物比如停止线、路沿、灯杆作为参照定期自动评估点云和图像的投影误差误差超过阈值就告警提示重新标定。同时优先选择固态激光雷达它没有机械旋转结构抗振动能力比机械式好得多。放在杆件上的设备安装支架也要选减震型别用普通角钢硬连接。5.2 雷视融合结果抖动怎么办融合结果抖动的典型表现是一个静止目标在路侧输出的轨迹上位置漂移一会儿在车道内一会儿在车道外或者目标速度偶尔跳变到不合理的数值。排查的时候先别急着调算法参数按顺序查三个地方第一检查时间同步状态看看雷达和摄像头的时间戳偏差是不是超过阈值第二检查标定是否漂移重新投影验证第三检查雷达配置部分毫米波雷达在静止目标识别上默认滤除静止点云导致融合算法只能依赖视觉性能自然下降。在算法层也有一个很实用的工程技巧给每个传感器输出加置信度权重而不是等权融合。视觉在白天置信度高夜间调低雷达在雨雾天置信度高在金属护栏密集区调低。权重可以根据历史误差在线学习也可以在标定现场手动设初值。权重机制加完之后单个传感器偶发误检对最终输出的影响会小很多。5.3 多边缘节点切换引发的ID跳变一条连续主干道上每隔几百米就有一个边缘节点车辆从节点A覆盖区驶向节点B覆盖区在重叠区域两个节点会同时感知同一个目标。如果两边各自管理跟踪ID车辆端会看到同一条轨迹突然从ID 523跳成ID 108车端决策逻辑里那些“基于历史轨迹判断意图”的模块就会乱掉。标准解法是目标交接协议。在覆盖区边界设置交接线目标还没到交接线之前节点A就把目标属性尺寸、类型、速度、预测轨迹传给节点B节点B提前建立匹配假设等目标真正进入自身强覆盖区时直接沿用A分配的全局ID。这项功能要求边缘节点之间存在可靠的节点间通信链路简单场景可以用局域网直连大范围部署就要依赖区域级边缘汇聚节点做ID注册和仲裁。ID跳变在测试阶段特别容易被忽略等真实车辆跑起来才暴露一暴露往往是整个系统稳定性最明显的问题。5.4 设备运维与升级的工程经验路侧设备数量上来之后运维压力很快超过开发压力。几十个路口的设备分散在城市各角落每一台都是潜在故障点。电断了、网断了、设备过热重启、SD卡写满、时间戳跑偏这些看起来很小的问题在无人驾驶场景里都会直接转化为安全风险。所以运维体系不能靠事后救火要有主动监控设备心跳、传感器自检、输出数据新鲜度检查全部接到统一运维平台异常自动派单。升级策略也要格外小心。路侧设备的OTA升级和手机不一样不能“发了就完事”。我们内部的铁律是灰度发布先在一台设备上升级观察48小时系统时延、目标检测率和告警误报率确认没有回归再逐步扩大到整个路口、整条线路。因为路侧设备直接影响正在行驶的自动驾驶车辆一次回归就可能造成大规模异常。断电恢复逻辑同样重要设备重启后要能自动恢复标定参数、重新建立时间同步、重新注册所有通信连接人工配合越少越好。如果一项功能需要频繁到现场处理这个设计就是失败的。最后分享几条实战里攒下来的体会做过的几个试点项目里印象最深的往往不是算法指标提升了多少而是把边缘设备稳定跑在路口这件事本身有多难。环境温度、振动、供电质量、通信干扰这些在机房和实验室里根本遇不到的问题到现场会一起扑过来。所以我给团队的规矩一直是室内把时间同步、标定校验、断网降级这三件事提前做好比什么都重要。另外别把边缘计算当成万能药。路侧设备再多也不可能覆盖每一寸道路车端的备份决策能力必须保留。真正成熟的设计是车先默认“路测不在”来规划安全策略收到高可信度路侧信息后再优化行驶表现。这套“无路侧也能安全有路侧更加高效”的基线思想比任何单项技术都更值得贯穿到整个系统里。