毫米波雷达遮挡检测：从信号衰减到工程落地的完整指南

1. 为什么“雷达遮挡”会成为躲不开的工程问题

先聊一个很多做感知的朋友都绕不开的场景：一辆带辅助驾驶的车在雨天跑高速，ACC自适应巡航原本稳得很，结果开了两个小时，系统突然提示“前雷达传感器被遮挡，功能受限”，紧接着车道保持、自动紧急制动全部退出。车上的人一脸懵，明明路上没什么脏东西，怎么一进服务区擦了一下雷达罩就恢复正常了。

这事在智能驾驶、安防监控、交通流量检测这些领域几乎天天发生。雷达装在车头格栅后面、装在路侧杆子上、装在机器人底盘上，时间一长必然会沾上泥、盖住雪、贴上广告贴纸，甚至被撞歪。但问题是，雷达不像摄像头，镜头脏了驾驶员一眼就能看出来；毫米波雷达的天线罩看起来干干净净，内部到底有没有被脏污衰减信号，肉眼根本判断不了。

更麻烦的是另外一个层面：雷达被遮挡之后，系统并不会立刻“瞎掉”。它的表现是信噪比变差、最远探测距离缩水、小目标漏检率上升，如果软件没有遮挡检测机制，ECU还会拿这组“带病数据”去做融合决策。在自适应巡航场景下，这意味着前车距离可能从150米突然缩短到30米才被感知到，给紧急制动留下的时间窗口几乎为零。所以行业里有个共识：雷达遮挡检测不是“锦上添花”的高级功能，而是直接挂钩功能安全和预期功能安全的基础需求。

这篇文章就把雷达遮挡检测这事从头到尾捋一遍，包括它为什么会发生、工程上怎么检测、不同方案有哪些坑、以及现在比较前沿的做法是什么。内容主要面向做智能驾驶感知、毫米波雷达应用开发、以及安防雷达集成的工程师，也适合刚入门雷达信号处理、想理解“工程落地视角”的学生。我会尽量把原理讲透，但也不会扯一堆公式就不管了，毕竟真正干活的时候，一个阈值设不好，什么花哨算法都白搭。

2. 遮挡如何影响雷达信号：从雷达方程到CFAR消失

2.1 雷达距离方程里的“隐形衰减项”

理解遮挡检测之前，得先搞清楚遮挡到底是怎么让雷达“变瞎”的。教科书里最常见的雷达距离方程长这样：

Pr = Pt × Gt × Gr × λ² × σ / ((4π)³ × R⁴ × L)

其中Pt是发射功率，Gt和Gr是收发天线增益，λ是波长，σ是目标雷达截面积，R是目标距离，L是系统损耗。对于车载毫米波雷达来说，这个公式的关键在于接收功率Pr和距离R的四次方成反比——也就是说，目标距离变远一倍，回波功率掉到原来的十六分之一。

遮挡物在这里扮演的角色，是在系统损耗L这一项里“塞进”一个额外衰减因子。比如一块湿泥巴盖在天线罩上，电磁波穿过泥巴时会产生吸收损耗和散射损耗，这部分能量既没有到达目标，也没有回到接收天线，等效于L增大了。具体增大多大，取决于遮挡物的介电常数、厚度、含水量，还有雷达工作频率。

举个例子：77GHz毫米波雷达的波长只有大约3.9毫米，这个频段对介电常数变化非常敏感。干燥的塑料膜可能只带来0.5dB到1dB的损耗，但一片浸透雨水的树叶盖上去，损耗可能直接飙到6dB到10dB。6dB的衰减是什么概念？它意味着回波功率变成原来的四分之一，等效到距离上，最大探测距离直接缩水到原来的约70%；10dB衰减就更夸张，探测距离掉到只有原来的56%。也就是说，遮挡不只是“灵敏度低了一点”，而是直接把感知范围砍掉了一半。

2.2 遮挡之后，距离-多普勒图上发生了什么

雷达信号处理的一般流程，是把回波做距离维FFT和多普勒维FFT，得到一张距离-多普勒图（Range-Doppler Map，简称RD图）。在RD图上，正常目标是孤立的亮点，静止目标多普勒频率为零，运动目标会出现在对应的多普勒单元上。背景则是均匀的噪声底，噪声功率的大小由接收机热噪声决定。

遮挡发生之后，RD图会出现两种典型变化。

第一种变化是整体噪声底抬高。遮挡物本身就在天线近场范围内，它反射的强能量会直接进入接收机，形成宽带干扰。反映在RD图上，就是某些近距离距离门的噪声电平整体抬升，目标峰值和噪声底之间的信噪比差距急剧缩小。原本一个信噪比18dB的行人目标，噪声底抬高6dB之后，信噪比就剩12dB了。如果本来目标就弱，比如远距离的摩托车，那它直接淹没在噪声里，CFAR检测器根本点不出来。

第二种变化是近距离出现“一堵墙”式的强反射。泥、雪、金属贴纸这类遮挡物，本质上就是贴在雷达脸上的一块大目标。它的回波极其强烈，而且在距离维上占据连续的门。反映在RD图上就是从第几个距离门开始，一整片区域全是高能量。这其实是一个很好的检测信号，但它同时也是一个严重的干扰源。如果CFAR检测器的参考窗刚好覆盖这片高能量区域，那参考电平会被拉高，反而导致原本能检测到的目标被判为噪声丢掉，形成“目标被遮挡物压住”的现象。

2.3 为什么CFAR会在遮挡场景下“翻车”

恒虚警检测（CFAR）是雷达检测目标的核心手段，它的原理是在被检测单元周围取一个参考窗，统计参考窗内的噪声/杂波电平，然后根据设定好的虚警概率计算一个检测门限。如果被检测单元的能量超过这个门限，就判定为目标。

问题恰恰出在“参考窗统计噪声电平”这一步。正常场景下，RD图的噪声底是平稳的，参考窗能给出一个稳定的估计。可一旦雷达被遮挡，近距强反射区域进入参考窗，噪声统计就失真了。参考窗电平被抬高，检测门限跟着抬高，真实目标反而过不了门限；反过来，如果遮挡物刚好落在保护单元附近，又可能因为保护单元没挡住强泄漏而产生一串虚警。

很多刚入门的朋友会问：那我把CFAR的门限设低一点不就完了？不行。门限设低了，虚警率立刻飙上去，系统天天报假目标，比漏检还让人崩溃。这个矛盾是CFAR固有的，也是为什么遮挡检测不能单纯依靠“调CFAR参数”来解决的底层原因——遮挡场景下，整张RD图的噪声分布已经不符合CFAR的平稳性假设了。

3. 工程上主流的遮挡检测实现思路

3.1 方法一：基于接收噪声底噪的检测

这是最简单、也最常用的一类方法。思路非常直白：雷达没有被遮挡时，接收机输出的底噪功率是相对稳定的；遮挡发生后，底噪会明显变化（通常是抬高）。所以只要持续统计RD图中无目标区域的噪声功率，跟雷达出厂标定的基准值做比较，差值超过阈值就判定为遮挡。

这个方案的关键在于“无目标区域”怎么选择。选得太远，可能超出雷达有效探测范围，统计的是纯噪声没错，但遮挡物对远距离底噪的影响很弱；选得太近，又可能把自身泄漏或天线罩反射统计进去。我在实际项目中一般会在中远距离段取若干个距离门，比如40米到80米之间，对这些距离门上的功率做排序，取中位数或低分位数作为底噪估计值，这样比取均值更抗异常点。

另外一个容易踩坑的地方是温度。毫米波雷达的噪声系数受温度影响很明显，夏天暴晒和冬天零下二十度，底噪可能差好几个dB。所以阈值不能做成固定值，必须用雷达内部的温度传感器做补偿，或者在上电之后做一段自适应基线校准。否则冬天一到，系统隔三差五报“遮挡”，用户投诉能把售后电话打爆。

3.2 方法二：基于近距离强反射的检测

遮挡物就在雷达天线罩外面，距离近、截面积大、回波强。利用这个特点，可以直接在近距离距离门看是否有异常强反射。具体做法是设置一个较低的检测门限，只在0.3米到1米范围内的近距离门上找连续高能量区域，同时统计这些区域的宽度和稳定度。

这里有个很重要的区别：正常目标也会在近距离出现，例如车头正前方蹲个人、或者旁边车道的车头切进来。怎么区分正常近距目标和遮挡物？经验是两个维度——时间稳定性和空间连续性。正常目标不会一直停在那里，它的距离、速度、位置会随时间变化；遮挡物则是不动的，连续几十帧、几百帧都在同样的距离范围出现同样形态的强回波。空间连续性则是指遮挡物在RD图上往往占据多个连续的距离门，而且能量分布比较均匀，不像行人那样存在明显的闪烁起伏。

这套方法对泥浆、积雪、贴纸这类“贴在脸上”的遮挡非常灵敏，但对一种特殊情况会漏检：如果遮挡物是湿润的薄冰层或者某些特殊塑料，它的介电常数匹配得“恰到好处”，电磁波几乎无反射地穿透过去，或者被吸收掉，近距离反而看不到强反射。这种“无反射遮挡”是最棘手的，因为它既不给底噪信号，也不给强反射信号，几乎只能靠目标级表现来反推。

3.3 方法三：基于业务目标统计的健康度判断

这个思路不关心物理信号，只看雷达输出的目标级数据的“质量”。雷达正常工作时，一帧RD图里检测出的目标数量、目标距离分布、目标信噪比分布，是有一定统计规律的。拿高速公路场景来说，空旷路段目标少但远距离目标多，城市道路目标多且分布集中。遮挡发生后，最典型的特征是：远距离目标突然消失，目标平均信噪比下降，目标数量在某些距离区间出现断层。

工程实现上就是做一个滑动窗口统计器，比如统计过去10秒内目标数量均值、最远稳定目标距离、超过一定信噪比阈值的目标占比。如果最远稳定目标距离明显小于正常水平，且低信噪比目标占比升高，就给出遮挡置信度。这个方法实现成本低，不需要改动底层雷达信号处理链路，很多时候直接在融合模块里加个逻辑就能用。

缺点也很明显：它对场景的依赖太强。隧道里、极端暴雨中、复杂城市峡谷环境，即使雷达完全没被遮挡，目标统计特征也可能和“被遮挡”非常相似。所以这种方案一般只作为辅助判据，用来交叉验证前两种方法的结果。

3.4 方法四：雷达自检与天线罩状态监测

有些雷达芯片会提供内建自检功能，比如通过耦合通道在发射和接收之间注入一个小幅度的已知信号，检测整个收发链路的增益是否正常。如果接收通道增益掉得厉害，说明前端可能有问题。这个方案对“雷达内部故障”的检测非常有效，但对“天线罩外部被泥糊住”这种纯外部因素，只能间接反映。

另外，部分高端雷达开始尝试在雷达罩上集成专用传感器，比如在靠近天线罩的位置布置电容式或光学传感器，直接测天线罩表面有没有附着物。这个方法在实验室里效果很好，但量产阶段面临耐候性、成本、一致性等一系列问题，目前还没有成为主流。

下表把这几种方法的优劣势汇总了一下：

4. 遮挡检测系统的完整落地流程

4.1 数据采集：遮挡样本比你想的更难得

做遮挡检测算法，最大的困惑不是算法本身，而是数据。雷达正常工作的数据满地都是，但被泥糊住、被雪盖住、被贴纸贴住的“真实遮挡数据”，量产之前根本攒不够。所以我们的经验是：在项目启动阶段就要专门设计遮挡数据采集方案。

比较实用的做法是准备一套可替换的遮挡模拟件，包括不同厚度的湿润海绵、塑料板、金属网格、泥沙混合物等，分别贴在雷达天线罩上进行整车道路采集。注意每种遮挡物都要覆盖不同车速、不同场景（高速、城区、隧道、雨天），至少采集几十分钟以上连续数据，确保覆盖目标出现、消失、超车等各种情况。这样才能在RD图层面积累足够多样的遮挡形态。

另外一定要记录真值。遮挡检测的真值不像目标检测那么好标——雷达模块要输出“当前是否遮挡”的状态，这个状态在数据回放阶段很难人工判定。我们习惯的做法是：在采集时用一个外部设备记录遮挡动作时间戳，比如用一个按钮盒手动标记“开始遮挡”“解除遮挡”，后期用这个时间戳自动生成标注，比人工逐帧看RD图靠谱得多。

4.2 离线分析：找准特征再做算法

拿到数据之后，不要在算法上急着动手。先把样本里的RD图逐帧看一遍，统计遮挡前后的底噪曲线、近距能量曲线、目标信噪比分布曲线。这一步做得越细，后面算法选型越省事。比如有的雷达型号遮挡后底噪抬高非常明显，那直接用底噪阈值方案就够了；有的雷达天线罩设计得比较讲究，近距反射却很弱，那就得靠目标统计来兜底。

我踩过的坑是：只看了一个雷达型号的数据就定了方案，结果换一个供应商的雷达之后，底噪特性完全不一样，算法参数全部重新标定。所以如果你的项目里有多家雷达供应商，最好在方案设计时就考虑“通用特征”，优先选择那些在物理原理上对所有雷达都成立的特征，而不是针对某个特定型号的RD图形态过拟合。

4.3 阈值标定与状态机设计

特征定好之后，就需要设计判定逻辑。工业界用得比较成熟的做法是输出连续遮挡置信度，而不是直接输出一个二值状态。典型流程是：每个雷达帧（比如50ms一帧）计算一次基础特征，包括底噪偏差、近距能量指标、目标统计指标；然后把这些特征做时间平滑，形成三个置信度分量；最后加权融合成一个遮挡置信度。

状态机需要至少设计四个状态：正常、疑似遮挡、遮挡确认、遮挡恢复。从正常到疑似遮挡，置信度需要超过一个较低门限并维持一段时间，比如0.5秒；从疑似到确认，需要更高门限并维持更长时间，比如2秒。这个延迟设计非常重要——如果响应太快，车辆经过一片水花时雷达会频繁误报；如果响应太慢，实际遮挡后系统还一直报“功能可用”，又违背了功能安全要求。

阈值怎么定？我个人的习惯是先拿采集的遮挡数据跑一遍离线仿真，画出特征分布的直方图，找一个尽可能把遮挡和正常样本分开的初始阈值，再在实车上做几轮迭代微调。注意阈值不能只让算法在遮挡样本上效果好，还要在正常场景下保证极低的误报率。因为雷达遮挡误报对用户体验的伤害，很多时候比漏报还要大。

4.4 与下游系统联动：检测出来之后怎么办

遮挡检测的最终输出，要接入到整车的功能安全策略里。ISO 26262和ISO 21448这两份标准都强调：如果感知传感器处于降级状态，系统必须通过人机交互明确告知驾驶员，并限制相关功能的运行权限。

实际工程上，遮挡状态一般分为几个等级。轻度遮挡：底噪略有抬高，功能还能用但性能下降，此时在仪表盘上提示“传感器脏污，请清洁”；中度遮挡：探测距离明显缩短，禁止激活ACC和AEB，已经激活的逐步降级退出；严重遮挡：雷达完全失效，系统直接显示故障码，并告知驾驶员需要进店检修。

这里有一个细节值得单独说：雷达在“遮挡确认”之后，如果几分钟后遮挡物被雨水冲掉了，系统需要能够自动恢复正常。所以遮挡置信度不能只升不降，要设计恢复机制，比如持续检测到远距离目标恢复、底噪回落，就逐步降低置信度，回到正常状态。这个“自动恢复”功能做得好不好，直接决定了用户的售后评价。

5. 工程实战中的典型问题与排查技巧

5.1 雨天误报：“我感觉雷达没脏，但系统一直报遮挡”

这个问题在量产车上出现频率相当高。排查思路不要一上来就怀疑算法，先从信号源头看。雨天环境下，前车卷起的水雾、路面溅起的泥水、以及直接打在雷达天线罩上的雨滴，都会让近距反射信号短时增强。如果阈值设得比较激进，一片水雾飘过就可能触发遮挡置信度飙升。

解决办法有两层。第一层是算法层面，把遮挡置信度的时间平滑系数加大，单帧或者短时几帧的尖峰不会立刻把置信度推到确认门限以上。第二层是特征层面，雨雾的反射特性和固态遮挡物不一样——雨雾是不断流动变化的，在RD图上的近距能量会出现明显的帧间起伏，而泥块、雪、贴纸这类固态遮挡物，近距能量是高度稳定的。所以加一个“时间稳定性”特征，能有效区分雨天误报和真实遮挡。

5.2 低温环境下底噪异常

冬天户外停车一晚，第二天上车发现雷达报遮挡，这个问题我以前排查了很久。最后定位到是低温导致接收机增益变化，底噪基线整体漂移了。当时用的固定阈值，没有做温度补偿，低温下底噪一降，和基线的偏差就超了门限。

解决办法是给雷达内部的底噪统计加一个温度查表补偿。标定的方法是：把雷达放在温箱里，从-40℃到85℃每5℃测一次底噪值，拟合出一条温度-底噪曲线，然后在算法里实时根据雷达上报的温度做修正。这一步虽然枯燥，但非常重要。我建议所有做雷达算法的人，前期标定阶段一定要拿到雷达的温度特性数据。

5.3 遮挡检测功能在隧道路段误触发

隧道场景下误报的根源和前两类不同。隧道壁是连续金属反射面，雷达在隧道里RD图会被大量强杂波填充，底噪估计和目标统计都会失真。如果遮挡检测算法用了目标统计特征，隧道场景很容易被误判成“远距离目标消失、目标数量下降”，从而把隧道误判成遮挡。

排查时可以先做个简单的区分逻辑：如果雷达同时检测到大量近距离目标（比如两侧隧道壁），而且这些目标的距离随着本车移动保持相对稳定，那就应该判定为“场景异常”而不是“传感器遮挡”。更稳妥的方案是在遮挡判定逻辑里加一个场景置信度开关，当检测到类似隧道的高杂波场景时，适当调高遮挡确认的门限，用更长的确认时间来过滤误报。

6. 遮挡检测的当下趋势与扩展方向

6.1 4D毫米波雷达带来的变化

4D毫米波雷达在距离、速度、水平角之外新增了俯仰角维度，输出的是完整的点云数据。这让遮挡检测有了新的玩法：4D雷达不仅能看RD图，还能从点云的空间分布上判断遮挡。如果天线罩表面附着泥块，点云会在近距离区域形成一片“贴脸”点簇，且点簇的形状和位置长时间不变；而正常的近距离目标（比如路沿、护栏）会随车辆运动发生相对运动。

另外，4D雷达的高角度分辨率也让“部分遮挡”检测成为可能。传统3D雷达只能判断“整个雷达是否被遮挡”，4D雷达可以把视场角划分成多个子区域，单独检测每个子区域的遮挡状态。比如天线罩左下角被泥糊了一块，系统能定位到是哪个方位角范围的探测性能下降了，这对于远距离目标的置信度降权很有价值。

6.2 基于学习的遮挡状态估计

传统方法依赖人工设计特征和阈值，通用性有限。近几年业界开始尝试用深度学习方法直接在RD图或点云数据上做遮挡状态分类。具体形式可以是一个轻量化CNN，输入为多帧RD图序列，输入出为遮挡概率；也可以是一个时序模型，直接把一帧帧的特征序列做分类。

这类方案的优势在于，它不需要人工去定义“底噪偏移多少算遮挡”“连续性多强算遮挡”，模型可以从数据里自动学到不同遮挡物、不同场景下的复杂特征。坦白说，在测试集上效果确实比传统方法好不少，尤其对吸收型遮挡这种“无声无息”的情况，学习法表现得比传统特征法更灵敏。

但落地时要面对两个现实问题。一是数据，RD图级别的标注比目标级标注还痛苦，需要大量人工筛选和半自动标注工具辅助。二是可解释性，功能安全评审时，你能说清楚一个阈值对应什么物理含义，但很难讲清楚CNN的某个权重为什么是这样。所以在实际操作中，我倾向于把学习法当成一个辅助置信度来源，和传统特征法做融合，而不是完全替代。融合策略可以简单做加权平均，也可以用逻辑回归学一个“二分类器套分类器”的组合权重。

6.3 遮挡检测与传感器融合的联动

再往上一层看，遮挡检测的结果不应该只是用来报个警。理想的架构是：感知融合模块实时获取每个雷达传感器的健康状态，然后根据这个状态动态调整传感器在融合输出中的权重。例如左前雷达报“部分遮挡”，那么融合模块在生成目标车辆状态时，对来自这个雷达的目标点的置信度进行降权，更多依赖毫米波雷达其他区域和其他传感器（比如摄像头）的数据。

这个方向目前还在落地过程中，但它代表了一个趋势：传感器健康管理从“故障后告警”走向“感知全生命周期健康监控”。雷达不只是一个采集数据的硬件，它本身也是一个有状态、会损耗、需要持续监控的子系统。

最后再分享一点我的个人体会。遮挡检测这个功能，论文里经常被一两句话带过，但真正做量产之后你会发现，它是感知系统里跟用户体验、功能安全、售后成本关联最紧密的一环之一。算法本身并不复杂，真正的复杂度来自场景的无限多样性和工程细节的无数坑。谁能把这些坑提前填平，谁的感知系统就能在恶劣环境里比别人多稳住一秒钟——在自动驾驶这件事上，一秒钟往往就是天壤之别。