AEB/ACC/BSD 功能逻辑参考

一、产品概述

AEB/ACC/BSD 功能逻辑参考，把上游融合与跟踪输出的稳定航迹，转换成可执行的制动、跟车与盲区告警决策。它覆盖触发条件（TTC、相对速度、横向位置）、纵向控制（分级制动减速度曲线）、横向控制（转向避让或仅报警）、接管与降级策略，并配套一套可回归的验证场景库。逻辑层不承诺单算法全工况零误报，而是把误刹与漏刹控制在可验收的区间。

功能逻辑是感知链路里离安全最近的一环，也因此受 ISO 26262、ISO 21448 SOTIF 与 UN-R152 的硬约束最多。逻辑设计必须把"该刹要刹、不该刹别刹"同时做到，任何一侧失衡都会变成投诉或事故。

二、应用场景

• AEB 误刹漏刹归因：把误刹归因为虚警、漏刹归因为漏检，结合标定与时间同步定位成因。
• ACC 目标筛选：在密集车流里从多目标中筛出本车道前车，输出平稳的跟车曲线。
• 商用车盲区告警：转弯与变道时对盲区目标给出行为预测与告警，降低右侧与尾部风险。

三、选型建议

功能逻辑的触发阈值要分场景标定，不能全球一个值。高速与城市、晴天与雨雾、本车道与前车，TTC 与减速度分级都应不同。降级策略必须提前定义：当某传感器失效或置信度不足时，系统是保守告警还是直接退出，要在设计阶段写清，而不是出事再补。逻辑参数同样要附工况区间，单独一个 TTC 阈值没有意义。

四、服务流程与配合事项

第一步是功能边界对齐：明确您要做 AEB、ACC 还是 BSD，以及各自的责任边界与法规对照（GB/T 40429、UN-R152）。第二步是逻辑建模：在您的触发条件与降级策略上搭出可仿真验证逻辑，并跑通与上游目标列表的对接。第三步是场景验证：用覆盖法规与典型工况的场景库做回归，重点看误刹与漏刹的分布与成因。第四步是交付与维护：把逻辑版本与场景库绑定，后续每次上游模型迭代都自动回归，避免引入新的触发失衡。

我们会交付功能逻辑说明与验证报告，明确在您工况下误刹与漏刹的可验收区间。需要强调的是，功能逻辑的安全表现强依赖上游融合、跟踪与标定质量——上游误报多，逻辑层再怎么调也压不住虚警，因此我们建议把整链路当成一套系统来验证。

五、与融合跟踪的耦合

功能逻辑消费的是融合与跟踪输出的目标列表，它的安全表现强依赖上游质量。上游虚警多，逻辑层再怎么调也压不住误刹；上游漏检多，漏刹也压不住。因此我们建议把逻辑与上游整链路一起验收，而不是只验逻辑本身，否则问题会被错误归因到逻辑层，越调越乱。

六、集成中的常见坑

坑一是触发阈值全球一个值，不分高速城市、不分晴雨；坑二是降级策略没写清，传感器失效时系统行为不确定；坑三是只验自定用例不验法规场景。逻辑离安全最近，这些坑每一个都可能变成真实事故或投诉，必须在设计阶段堵上，而不是出事再补。

七、性能的可验收区间

功能逻辑交付要给出在您工况下误刹与漏刹的可验收区间，并对照 GB/T 40429 与 UN-R152 的责任边界。我们强调分成因、分场景看，而不是给一个总触发率。安全相关的指标必须透明，才能过得了验收与审计，也才能在出问题时有据可查。

八、后续维护的说明

逻辑参数会随上游模型迭代调整，触发阈值、降级策略都可能需要再校验。我们交付时会说明版本绑定与回归方式，确保每次上游改动后逻辑表现不回弹。安全功能的维护不能含糊，必须有可审计的变更记录，这是车规的基本要求。

九、逻辑验收要覆盖失效模式

功能逻辑验收，最该覆盖的是失效模式，而不只是常规触发。要验当某传感器失效、置信度不足、或目标列表异常时，逻辑是否按既定降级策略行为可预测；要验在雨夜、逆光、团雾下误刹漏刹是否仍在可验收区间。这些才是安全攸关、也最易被忽略的工况。我们建议在交付时把逻辑与上游整链路一起跑失效模式用例，并对照 GB/T 40429 与 UN-R152 的责任边界。此外，逻辑参数（触发阈值、降级策略）要固化并纳入回归。我们交付时会给出判定口径与用例清单，确保后续迭代不引入新的触发失衡。逻辑离安全最近，验收必须较真，不能拿几个轻松用例交差。

十、给安全团队的一句提醒

功能逻辑离安全最近，验收必须较真。把失效模式与恶劣天气作为必验项，对照 GB/T 40429 与 UN-R152 的责任边界逐条过，而不是拿几个轻松用例交差。逻辑参数固化进配置并纳入回归，才能确保后续迭代不引入新的触发失衡。我们建议把逻辑的每次改动都走变更评审，明确改了什么、影响哪些场景、回归是否通过。安全功能的变更必须有据可查，这是车规的基本要求，也是事故复盘时最关键的护身符。

相关产品

• 目标跟踪参考能力 — 功能逻辑的消费对象
• 误报漏报分析能力 — 误刹漏刹的成因闭环
• 标定与时间同步基线 — 逻辑稳定的基准前提