如果你翻过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的价值：“在无线更新过程中提供一种灵活方便的方法来实现修改，进而达到在运行阶段及时解决已发现的功能缺陷的目的。”
现场监控与OTA：SOTIF的“永动机”
现场监控和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 5：OTA部署
通过OTA将修复补丁推送到所有受影响车辆。
✅ Step 6：验证确认
在VaHIL台架上复现该场景 → ✅ 通过
继续现场监控 → ✅ 确认问题已解决
⚠️ 运行阶段活动中容易踩的“坑”
坑1：车卖了就不管了
❌ “SOTIF发布完了，项目结束了”
✅第13章明确要求：运行阶段必须建立现场监控过程
坑2：只监控“事故”，不监控“差点出事”
❌ “没撞上就不算问题”
✅标准要求监控：“功能已造成或可能造成伤害的事件”——差点出事的也要记录
坑3：发现问题后“慢慢修”
❌ “等下一个版本一起修”
✅如果风险不可接受，必须立即响应——先临时措施“止血”，再永久修复
坑4：现场监控和开发团队“两张皮”
❌ “监控是售后的事，开发不管”
✅标准要求：“将相关数据转发给开发部门”——开发团队必须参与分析和修复
🔗 第13章与第8章（持续网络安全活动）的异同
如果你学过ISO 21434，会记得第8章也有“持续的网络安全活动”。两个标准的“持续活动”有什么区别？
对比维度 | 🔒ISO 21434 第8章 | 🧠ISO 21448 第13章 |
|---|---|---|
🎯管什么 | 网络安全威胁（黑客攻击） | 功能不足（系统“不行”） |
🔍监控对象 | 网络攻击、漏洞、恶意行为 | 功能表现异常、新触发条件 |
🛠️响应方式 | 安全补丁、事件响应 | 功能改进、OTA升级 |
🔗共同点 | 都要求持续监控、持续改进 | 都要求持续监控、持续改进 |
💡两个标准都强调“持续”——安全不是“做完就完事”的，它是一个永不停止的闭环
