功能安全现场数据反馈闭环深度 — 量化再评估 / OTA 交付 / 召回触发

开发期签发的 安全案例 不是"证明系统安全",而是"在一组假设下论证残余风险可接受":

• FMEDA 用的失效率 λ(来自 SN29500/IEC 62380 手册或厂商数据)是预测值
• HARA 的 exposure 概率(某危险工况多常见)是估计值
• SOTIF 的已知场景集是当时能想到的

运营期是这些假设的真值检验场:实车失效率、真实工况频率、未预见的触发场景,会验证或推翻假设。闭环 = 让安全案例随场数据持续更新(living safety case),而非签发即封存。

场数据是海量且大部分非安全的,闭环第一关是管线 + triage:

• 数据源:DTC + freezeframe(故障码 + 冻结帧)、EDR(事件数据记录)、telematics 联网上传、warranty/PPM(质保/百万分故障)、投诉热线、法规事故通报、shadow-mode 场景捕获(量产车后台跑算法记录 corner case)
• 安全相关性 triage:绝大多数故障是质量/体验问题,不是安全。要先筛出触及 SG / 触发已知危险 / 暴露新 fault mode 的子集——靠故障码映射到 SG、近失(near-miss)模式匹配、统计异常检测
• 隐私/数据治理:telematics/EDR 涉个人数据,管线要合规(GDPR/国标)

triage 的产出:一批安全相关候选,进 §3 量化再评估。

Part 7 页 §4 说"PPM 超阈值就行动",但阈值哪来的?闭环的深层是把它锚到开发期假设:

• 实测 λ_field:从场失效数 / 装车量 / 运行小时算出实际失效率(带置信区间——早期样本少,CI 宽)
• 对账假设:实测 λ_field vs FMEDA 当初假设的 λ;实测 exposure vs HARA 假设
• 重算度量:λ 变了 → 重算 PMHF / SPFM / LFM → 还过不过 ASIL D 阈?
• 判定:
  • 实测 ≈ 假设 → 假设成立,安全案例保持
  • 实测 ≫ 假设 → 假设被推翻 → 安全案例失效 → 必须行动(§4)
  • 新 fault mode 不在 FMEDA → FMEDA 不完整 → 补 + 重评

把"PPM 超阈值"升级成"实测失效率推翻了 FMEDA 假设、PMHF 重算过不了 ASIL D"——这才是定量的再评估,阈值不再是拍脑袋。

量化骨架(别只喊"定量"):

• λ_field 与置信区间:λ_field = 场失效数 / 总运行小时;CI 用卡方分布(失效率区间估计的标准做法)
• 早期零失效别给点估计:用卡方单边上界(自由度 2,χ²(2,1−α)/(2T))给 λ 上限——运行小时 T 越少上界越松,这正是 §6"样本不足不能放过"的定量化
• 恒定 λ 只在随机失效期成立:进入磨损期(Weibull 形状参数 β>1,如 bond wire 老化)PMHF 的恒定失效率模型本身失效,要换 Weibull / B10 寿命建模——否则磨损型失效会被系统性误判成"还在假设内"
• leading 维度:除等失效(lagging),加 SPI(Safety Performance Indicator) 监控 precursor 信号(UL 4600 / SOTIF 运营期),别等炸了才动

再评估判定"要行动"后,选哪种行动按残余风险 + 法规时限:

• 召回(recall):残余风险高 / 已发生事故 → 法规强制(缺陷申报有时限,如 NHTSA 5 工作日、国标 GB 类似),代价最大
• OTA fix:可软件修复的 → 远程推送,代价小但OTA 本身是安全 + 信息安全相关
• 服务通报(service campaign):中度 → 4S 店进店修
• 下批改进:轻度 → 不召回,改设计/工艺下批生效

OTA 作为安全修复交付(易被低估):

• 按 ISO 24089(道路车辆软件更新工程) 做更新的安全工程
• 按 UNECE R156(SUMS,软件更新管理系统) 做型批准合规(R155 是 CSMS 网络安全)
• 关键:更新本身不能变砖(回滚 / A-B 分区 / 失败恢复)、更新 campaign 要有自己的安全案例(更新过程别引入新危险)、推送对象/版本可追溯

field feedback 不止 FuSa 一条 loop,三条并行、共享同一数据管线:

• 功能安全(26262-7):实测 λ → 再评估 FMEDA/PMHF → 召回/OTA(本页主线)
• SOTIF(21448 持续改进):场数据发现新触发场景 / 未知不安全(Area 3) → 加入 场景库 → 变"已知"(Area 3 → Area 2)→ 消解(→ Area 1)→ Area 3 缩小。这是 SOTIF 闭合"未知不安全"的唯一途径(Area 1 已知安全 / 2 已知不安全 / 3 未知不安全 / 4 未知安全)
• 网络安全(21434 / UNECE R155 CSMS):漏洞/攻击监控 → 评估 → 安全补丁(也走 OTA)

三条共享 DTC/telematics/EDR 管线,但评估准则不同(FuSa 看失效率、SOTIF 看触发场景、Cyber 看漏洞)。工程上常合一个 field-monitoring 平台喂三套评估。

现场反馈闭环翻车几乎都在"合规打卡不闭环"和"定性不定量":

• 签发即封存安全案例 — 不随场数据更新 = 不是 living safety case,假设被推翻也不知道
• PPM 阈值拍脑袋 — 不锚到 FMEDA 假设 λ,无法判断"是否推翻安全论证";要重算 PMHF
• 不做安全相关性 triage — 海量故障里淹没安全信号,或把质量问题当安全恐慌
• OTA 当普通软件升级 — 漏 ISO 24089/R156,变砖 / 引入新危险 / 不可回滚
• 三标准各搞各的管线 — 数据重复采集、漏交叉(一个场景同时是 SOTIF + Cyber 问题)
• 早期小样本下结论 — λ_field 置信区间宽,样本不足就召回/放过都可能错