如果你翻过ISO 21448:2022的版本历史会发现一个有意思的事实第13章是2022年正式版新增的。在2019年的试行版ISO/PAS 21448:2019中根本没有运行阶段活动这一章。为什么正式版要特意加上因为行业发现了一个残酷的现实SOTIF在开发阶段做得再好也无法穷尽真实世界的所有场景。区域3未知危险永远存在。你不可能在开发阶段发现所有“未知的未知”。车一旦上路每天都在遇到新的场景、新的路况、新的天气组合、新的交通参与者行为。第13章的存在承认了一个事实SOTIF不是“做完就完事”的它是一个持续演进的过程。标准明确规定产品发布的目的是将风险降低到可以接受的范围内。但是在以下情况下需要重新考虑风险评估在功能运行期间现场发现了之前没有识别的功能不足或触发条件在功能开发过程中假设的环境条件或交通规则发生了变化第13章的价值它把SOTIF从“一次性工程”升级为“全生命周期管理”——从概念设计到车辆报废全程都要管。️ 第13章在讲什么一张图看懂ISO 21448第13章“运行阶段活动Operational phase activities”由五个小节组成小节内容大白话13.1 目标本章要达成的目的“我们要交什么活”13.2 总则本章的总体原则“整体思路是什么”13.3 观察主题要监控什么“盯着哪些东西看”13.4 SOTIF问题评估与解决流程发现问题后怎么处理“出事了怎么修”13.5 工作产物要输出的文档“交什么活”第13章在SOTIF全流程中的位置第13章把SOTIF变成了一个闭环第5-11章是“做安全” → 第12章是“证明安全” → 第13章是“保持安全” → 发现新问题后回到第5-8章“再改进”→ 再验证 → 再发布 → 再监控……这是一个永不停止的循环。 13.2 总则运行阶段要做什么ISO 21448第13.2节规定运行阶段活动的目的是确保SOTIF在车辆全生命周期内得到维持。运行阶段活动需要基于以下输入输入来源内容第5章功能规范和设计第7章潜在的功能不足、性能局限和触发条件第10章验证活动的结果第11章确认活动和剩余风险评估的结果核心逻辑第13章不是“凭空”做监控——它的监控目标和重点来自于前12章的分析结果。你之前识别的所有功能不足和触发条件都是运行阶段需要重点监控的对象。 13.3 观察主题现场监控“盯什么”第13.3节定义了现场监控Field Monitoring的核心任务。ISO 21448对现场监控的官方要求是应定义并启动现场监测过程以确保运行期间的SOTIF。观察主题包括但不限于观察类别具体内容大白话已发生或可能发生的伤害事件功能已造成或可能造成伤害的事件“有没有出过事差点出事的也算”超出定义值的情况在不同情况下功能超过定义值可能导致伤害的事件“系统有没有‘超常发挥’——比如刹车力度超过设计上限”知识状态的变化对系统能力认知的变化“我们‘知道’的东西变了吗”新情况可能影响SOTIF并可能导致重新考虑SOTIF发布结论的新的情况“有没有出现之前没想到的新场景”现场监控的最终目标发现开发阶段没有识别出的“未知危险场景”区域3。行业实践现场监控通常通过两种方式实现方式大白话车载监控系统“在车上装一个‘黑匣子’实时记录系统行为和环境数据”☁️云端数据分析“数据传回云端用大数据分析发现异常模式”现场监控和运行时监控的关系我们在第21期讲过的安全监督器Safety Supervisor是车端的实时监控——毫秒级响应发现风险立即干预。现场监控Field Monitoring是车端云端的长期监控——把数据传回云端分析发现那些“单辆车看不出来、但大数据能看出来的”模式。️ 13.4 SOTIF问题评估与解决流程发现问题后怎么办第13.4节定义了发现问题后的处理流程。Step 1数据收集与转发 “将相关数据转发给开发部门”现场监控收集到的数据需要及时传递给开发团队进行分析。这要求建立完整的数据回传通道——车端数据 → 云端 → 开发团队。Step 2风险评估 “对收集到的数据进行评估判断风险是否依旧合理”不是所有异常都需要立即响应。开发团队需要判断这个异常是否真的构成了不合理风险评估结果处理方式风险仍可接受记录归档继续监控风险边界但可控制定改进计划排期修复风险不可接受立即响应Step 3立即响应 “根据运行中发现的SOTIF问题可能需要立即作出反应以减轻不合理的风险”如果评估发现风险不可接受必须立即采取措施减轻风险——即使“终极修复”还没完成。立即响应的措施措施大白话⚠️临时功能限制“先把这个功能关了等修好了再开”临时降级“把功能降级到更安全的模式”用户通知“告诉用户‘这个功能暂时别用’”关键原则先“止血”再“治病”。不要等到完美修复方案出来再行动——在最终修复可用之前可能需要采取不需要额外SOTIF活动的临时措施。Step 4根因分析与修复 找到临时方案后开发团队需要深入分析根因制定永久修复方案。修复的两种方式方式大白话适用场景OTA更新“通过无线推送新软件”最常见、最高效召回维修“把车召回4S店修”OTA无法覆盖的硬件问题标准特别提到了OTA的价值“在无线更新过程中提供一种灵活方便的方法来实现修改进而达到在运行阶段及时解决已发现的功能缺陷的目的。”现场监控与OTASOTIF的“永动机”现场监控和OTA是SOTIF运行阶段的两大核心支柱它们共同构成了一个自我进化的安全闭环第13章虽然没有直接提到“OTA”这个词但它的逻辑天然指向OTA。清华大学李骏院士团队的研究成果明确指出运行阶段SOTIF保障的关键技术包括关键技术大白话关键数据发现与记录“从海量数据中找出‘异常’”增量式学习成长平台“让系统持续学习新的场景”OTA升级“通过无线推送修复和改进”OTA是SOTIF运行阶段的“执行器”现场监控是“眼睛”——发现问题 数据分析是“大脑”——判断问题 OTA是“手”——执行修复 ✋ 实战一个完整的SOTIF运行阶段闭环 场景某车型的AEB系统在开发阶段通过了SOTIF发布第12章正式上市销售。 Step 1现场监控13.3车载监控系统记录了一条异常数据在某城市特定路口多辆同款车型在黄昏逆光条件下AEB系统出现了轻微制动延迟——虽然没有造成事故但制动力度比设计值偏小。 Step 2数据评估13.4开发团队收到数据后评估评估项结论是否造成伤害❌ 没有轻微延迟但未碰撞是否可能造成伤害⚠️可能——如果车速更快或跟车距离更近可能追尾风险是否可接受❌不可接受——这是一个新的触发条件 Step 3立即响应13.4在永久修复完成前团队采取临时措施 通过车机推送通知“在黄昏逆光场景下请保持更大的跟车距离”⚠️ 临时降低AEB在该场景下的激活阈值更早触发 Step 4根因分析与修复13.4深入分析发现这是一个新的触发条件——“黄昏 逆光 特定城市路口的高楼反射光组合”在开发阶段的场景库中没有被覆盖。修复方案优化摄像头在逆光条件下的图像处理算法增加雷达在低置信度场景下的权重将该场景补充到场景库中区域3 → 区域2 Step 5OTA部署通过OTA将修复补丁推送到所有受影响车辆。✅ Step 6验证确认在VaHIL台架上复现该场景 → ✅ 通过继续现场监控 → ✅ 确认问题已解决⚠️ 运行阶段活动中容易踩的“坑”坑1车卖了就不管了❌ “SOTIF发布完了项目结束了”✅第13章明确要求运行阶段必须建立现场监控过程坑2只监控“事故”不监控“差点出事”❌ “没撞上就不算问题”✅标准要求监控“功能已造成或可能造成伤害的事件”——差点出事的也要记录坑3发现问题后“慢慢修”❌ “等下一个版本一起修”✅如果风险不可接受必须立即响应——先临时措施“止血”再永久修复坑4现场监控和开发团队“两张皮”❌ “监控是售后的事开发不管”✅标准要求“将相关数据转发给开发部门”——开发团队必须参与分析和修复 第13章与第8章持续网络安全活动的异同如果你学过ISO 21434会记得第8章也有“持续的网络安全活动”。两个标准的“持续活动”有什么区别对比维度ISO 21434 第8章ISO 21448 第13章管什么网络安全威胁黑客攻击功能不足系统“不行”监控对象网络攻击、漏洞、恶意行为功能表现异常、新触发条件️响应方式安全补丁、事件响应功能改进、OTA升级共同点都要求持续监控、持续改进都要求持续监控、持续改进两个标准都强调“持续”——安全不是“做完就完事”的它是一个永不停止的闭环