融合框架核心参考方案

一、产品概述

融合框架核心参考方案的目标，是把毫米波、相机、激光、超声四类传感器统一到同一个目标列表与同一个时空基准上，让下游规划控制拿到的是一条条稳定的航迹，而不是四份各说各话的列表。它支持前融合、特征融合与后融合三种架构的切换，团队可以依据算力与时延预算选最合适的一档，而不是被单一架构绑死。

这套方案的关键在于"基准"二字：时间同步负责让四路传感器在同一时刻说话，外参标定负责让它们在同一坐标系说话，置信度加权负责决定某一工况下谁更可信。三类能力齐备，融合才有意义；缺任何一项，融合都会退化成简单的拼接。

二、应用场景

• L2+ 域控感知：作为行车与泊车域的共同底座，向规划控制输出统一目标列表，避免跨域重复建图。
• 城市 NOA 多传感器融合：在目标密集、穿插频繁的城市道路，靠特征级对齐与航迹管理抑制遮挡带来的跳变。
• 行车与泊车统一底座：近场用超声与视觉、远距用毫米波与激光，分层处理后再融合，覆盖从泊车到高速的全速域。

三、选型建议

架构选择先回答三个问题：是否强调全天候直接测距测速、是否必须保留最完整原始信息、算力与时延预算是否紧张。算力富余且追求上限选前融合，预算紧张追求可量产选后融合，主流 L2+ 域控选特征融合。框架本身不承诺单算法全工况零误报，验收以检出率、漏检、虚警、测距测速精度与端到端延迟为参考线。

四、服务流程与配合事项

第一步是需求对齐：我们会先了解您的传感器组合、目标类型、速度区间、天气与场景，以及期望的验收指标，再据此建议架构档位。第二步是样机配套与接口确认，重点核对时间戳语义、坐标系与 ISO 23150 风格目标列表的一致性，这一步直接决定融合能否正确对齐。第三步是标定与时间同步的基准搭建，外参标定精度与同步裕度要在实车上量过，而不是只在文档里写指标。第四步是验收与数据回灌，我们把典型工况与边界场景做成可回归的用例，确认指标稳定后再交付。

需要强调的是，融合框架的落地不是把模型跑通就结束，而是要在千变万化的实车数据上保持一致。我们会在交付后保留场景库的维护和回归支持，确保后续模型迭代不引入新的虚警或漏检。涉及具体型号与器件的选型，建议结合实测与送检测确认。

五、与功能逻辑的关系

融合框架输出的是统一目标列表，是 AEB、ACC、BSD 等功能逻辑的直接输入。功能逻辑要不要刹、怎么刹，依据的正是这条列表里的目标与航迹。因此框架的稳定性直接决定功能逻辑的安全表现——上游航迹跳 ID 或闪现，下游再怎么调阈值也压不住误刹漏刹。两者要当成一套系统一起验收，而不是各验各的。

六、集成中的常见坑

集成时最常见的坑，是时间戳语义不一致：雷达报的速度是径向还是全速、时间戳是采样还是输出，文档不写清，融合就各说各话。其次是标定版本没绑定，上线后漂移无人知晓。还有是同步裕度留太小，偶发超时直接引发关联错乱。这些坑都出在基线不稳，而非框架本身。

七、性能表现的可验收区间

框架的交付要附上在您工况下的可验收区间，而不是一句"支持融合"。我们通常会给出端到端时延、最大目标数、以及在不同天气下的航迹连续性指标。把区间写清，您才能在验收时判断到底达没达标，而不是被"先进融合"四个字带过，事后才发现能力缺口。

八、后续维护的说明

融合框架上线不是结束，车型生命周期里会有多次模型与标定迭代。我们交付时会说明版本绑定与回归方式，确保每次迭代都能快速确认融合表现没有回弹。把维护方式提前讲清，后续合作才不会在每次升级时手忙脚乱，也便于您内部团队接手。

九、交付前的联合验收建议

融合框架上线前，建议做一次联合验收，把框架、关联、跟踪、功能逻辑串起来跑真实与仿真场景，而不是各模块单独过。联合验收能暴露模块间的接口与边界问题，比如时间戳语义不一致、航迹 ID 在跨模块跳变、降级策略相互冲突。很多问题单独验模块发现不了，只有在整链路里才暴露。把联合验收作为交付门槛，比事后在车上排查省太多，也能让各方责任清晰，不至于出问题互相推诿。此外，联合验收还要覆盖失效模式：当某路传感器短时失效，框架是否优雅降级而非整体失稳；当同步偶发超时，关联是否还能续上。这些才是真实道路最常见、也最易被单模块验收漏掉的工况。我们通常在交付时提供联合验收的用例清单与判定口径，确保您能照着复现，而不是凭感觉判断过没过。框架的可交付性，最终不取决于能跑通 demo，而取决于它在您的整链路真实工况下稳不稳。

相关产品

• 目标关联能力 — 跨模态目标如何对齐
• 目标跟踪能力 — 航迹生命周期与重识别
• 标定与时间同步基线 — 让四路传感器同一时刻同一坐标说话