功能安全监控与诊断模块

一、产品概述

功能安全监控与诊断模块对感知链路的输出做独立校验：它不参与主感知计算，而是从旁观察传感器输出与融合航迹，检查是否存在失效、不合理或超出预期的情况，并在判定异常时触发安全状态。

这类模块的存在理由是「主链路不能自己证明自己正确」。主感知算法可能因为缺陷、标定错误或输入异常而输出错误结果，且自身不会报错；独立的监控层用不同的判据（异构校验、合理性检查、范围检查）来发现这类问题。

需要区分的是：它处理的是随机硬件失效与系统性失效的检测与响应，而传感器在已知场景下的性能局限属于预期功能安全范畴，两者的工作方式与验证手段不同，不能混为一谈。

二、技术参数

取值需按实际系统配置与安全论证确认；覆盖率由失效模式分布加权计算。

三、应用场景

• 高阶辅助驾驶安全监控：在感知输出参与车辆控制前做独立校验，本模块可作为安全机制的一部分支撑等级论证。
• 感知失效检测与降级：检测到传感器异常后触发降级策略，本模块负责判定与状态管理，保证失效不是静默的。
• 功能安全等级论证支撑：提供诊断覆盖率与安全状态响应时间的证据，本模块的诊断项清单可直接用于安全文档。
• 售后故障定位：记录失效事件与上下文，本模块的诊断记录可用于售后分析，缩短定位周期。

四、选型建议

选择监控模块的前提是功能确实需要独立的安全机制。若功能等级较低或已有充分的异构冗余，额外的监控层可能是不必要的成本。

搭配上，本模块应与融合模块或域控协同部署，监控对象应覆盖传感器输出与融合结果两层。只监控传感器而放过融合环节，会留下覆盖空白。

一条需要守住的边界是独立性：监控逻辑不能与主感知共用同一套代码路径或同一份输入处理，否则共因失效会让监控形同虚设。独立性是这类模块价值的前提。

五、安装与标定

本模块以软件形式部署在域控或独立的安全核中，硬件上需保证供电与通信的独立性。若部署在同一域控内，应通过分区或独立核保证与主感知的隔离。

标定的重点是监控阈值：阈值过松会漏掉真实失效，过紧会产生误触发导致功能频繁退出。阈值应基于大量正常工况数据统计确定，并留出覆盖边界的余量。

装车后应做故障注入验证：人为注入传感器失效、通信中断、数值异常，确认模块能按设计进入安全状态且响应时间满足要求。缺少这一项，安全论证通常无法通过评审。

六、维护与复检

维护重点是诊断记录的分析。误触发增多通常说明阈值需要重新标定或传感器状态发生了变化，应结合记录定位根因而不是简单放宽阈值。

复检项目建议包括：故障注入测试通过率、安全状态响应时间、以及误触发频次。这三项分别对应检测能力、响应及时性与可用性，需同时满足。

软件升级后必须重新执行故障注入验证。监控逻辑的变更可能改变覆盖率与响应时间，沿用旧的验证结论会留下安全论证缺口。

七、供货与配合事项

交付前需确认四项条件：目标功能安全等级与监控范围是否明确、监控对象的数据接口是否可获取、独立部署条件是否满足、以及安全状态的定义是否被整车接受。

配合事项上，集成方应提供完整的失效模式分析与诊断项清单，以便确定监控判据；同时需明确安全状态下的整车行为（提示、降级或接管），这决定了响应时间的分配。

建议在定点前完成一轮故障注入联合验证，确认检测覆盖率与响应时间满足安全目标，而不是仅依据设计文档评审。

八、搭配边界与常见误区

第一个误区是让监控模块与主感知共用实现。共因失效会让监控失去意义，独立性必须体现在代码、输入与执行环境上。

第二个误区是把性能局限当作失效来监控。传感器在已知场景下的能力边界属于预期功能安全，靠监控模块无法解决，应通过场景库与触发条件识别处理。

第三条边界是误触发成本：监控过于敏感会导致功能频繁退出，用户最终可能关闭功能，反而降低整体安全收益。阈值应在检测能力与可用性之间取平衡。

九、与整车功能的配合

安全监控模块必须与整车的降级策略绑定才有意义：检测到异常后是提示、降级还是请求接管，需要在整车层面定义清楚。缺少降级定义的监控只会让功能突然退出，体验与安全收益都不理想。

相关产品

• 目标级多传感器融合模块 — 被监控的主感知环节之一
• 特征级前融合处理单元 — 集中式架构下的监控对象