ISO 21448第8章的核心任务针对识别出的功能不足FI和触发条件TC设计并实施改进措施把“已知危险场景”变成“已知安全场景”。第8章在讲什么一张图看懂ISO 21448第8章“功能修订以减少SOTIF相关风险”是整个SOTIF流程中从“分析”到“行动”的关键一步。由四个小节组成小节内容大白话8.1 目标本章要达成的目的“我们要交什么活”8.2 概述本章的总体原则“整体思路是什么”8.3 改进SOTIF的措施核心中的核心“具体怎么改”8.4 更新系统规范把改进写回文档“改完了要记录下来”第8章的目标确定和分配措施以避免、减少或减轻与SOTIF相关的风险同时估计这些措施对预期功能的影响。️ 四大改进策略SOTIF的“工具箱”ISO 21448第8.3节详细列出了四大类改进措施策略一系统改进 ——“升级硬件、优化算法”这是最直接的改进方式——修改系统本身让它的能力变得更强。从三个层面入手1. 传感器层面——“让眼睛更亮”改进措施大白话实战例子改进传感器算法“让摄像头‘看’得更聪明”优化图像处理算法提升低照度下的识别率采用更好的传感器技术“换一副更好的‘眼镜’”从普通摄像头升级到高动态范围HDR摄像头修改传感器位置“把‘眼睛’挪到更合适的位置”调整雷达安装角度减少视野盲区传感器扰动检测“当‘眼睛’被遮住时能自己发现”检测到摄像头被泥巴遮挡时触发报警和降级策略2. 执行器层面——“让手脚更稳”改进措施大白话实战例子⚡适当的执行器技术“选更精准的‘手’”提高转向精度、扩大输出范围、缩短响应时间3. 算法层面——“让脑子更聪明”改进措施大白话实战例子算法改进“让AI‘学’得更好”改进目标检测算法减少误识别识别不支持的环境条件“知道自己‘不行’的时候及时认怂”系统识别到强逆光时自动切换到更保守的驾驶策略缓解功能冲突“避免左右手互搏”解决车道保持与自动换道之间的指令冲突行业实践中的“系统改进”针对感知系统的性能局限可以通过传感器冗余设计、融合算法优化等方式来改进。例如在AEB系统中增加毫米波雷达与摄像头融合就是典型的传感器层面改进。策略二功能限制 ⛔——“不行的时候就不干”不是所有功能不足都能通过“升级”来解决——有些是物理极限根本做不到。这时候就要限制功能。功能限制的核心逻辑“既然在这个场景下我容易犯错那我干脆就不在这个场景下工作。”ISO 21448列出了三种功能限制方式限制方式大白话实战例子限制特定用例的功能“在某些场景下‘出工不出力’”车道检测不清时减少车道保持辅助的干预力度⛔限制特定用例的权限“在某些场景下‘不让它干’”午后阳光致盲摄像头时限制视觉传感器的使用权限限制总体权限“在极端场景下‘直接撂挑子’”暴风雪致盲所有传感器时请求驾驶员接管一个生动的例子一个车道保持系统在车道线清晰时表现良好区域1。但在大雪覆盖车道线的场景下系统“看不清”车道触发条件可能会乱打方向盘功能不足导致的危险行为。功能限制方案当系统检测到“车道线不可见”时自动降低车道保持的干预力度只保留轻微的方向修正而不是试图“硬撑”着居中行驶。策略三权限移交 ——“我不行了你来”当系统遇到自己“搞不定”的场景时把控制权交还给驾驶员。权限移交的核心逻辑“这个场景我处理不了你来开吧。”ISO 21448要求要求大白话️改进人机界面HMI“让提示更清晰、更易懂”⚠️改进预警和降级策略“提前告诉驾驶员‘我要不行了’”️从其他来源获得指导“实在不行导航或云端也能帮忙”关键点权限移交本身必须是可控的不能给驾驶员带来额外风险。实战例子L3级自动驾驶系统在高速上行驶突然遇到暴风雪——所有感知传感器都被“致盲”了。权限移交流程系统检测到“所有传感器失效” → 触发降级策略通过HMI发出接管请求TOR声音视觉触觉提醒给驾驶员足够的时间比如10秒来接管如果驾驶员接管了 → 权限移交完成 ✅如果驾驶员没接管 → 系统执行最小风险策略MRM自动靠边停车 ️策略四改进误用 ——“让用户别用错”SOTIF不仅关注系统本身的问题还关注驾驶员可能用错的情况。ISO 21448要求要求大白话改进提供给驾驶员的信息“说明书写得再清楚一点”️改进人机界面HMI“让提示更直观避免误解”实施监测和预警系统“发现驾驶员用错了就提醒”实战例子一个ACC系统在城市道路上表现不佳容易误判但说明书里写的是“适用于高速公路和城市快速路”。改进误用方案在仪表盘上增加明确的提示“当前道路不适合使用ACC”当检测到驾驶员在非适用道路上激活ACC时自动提醒并建议关闭 一张表看懂四种策略怎么选策略什么时候用怎么做效果系统改进功能不足可以通过技术升级来解决升级传感器、优化算法、改进执行器消除功能不足⛔功能限制功能不足是物理极限无法消除限制ODD、限制功能权限、限制干预力度避免触发条件权限移交系统“不行”时人可以处理改进HMI、改进预警策略、MRM转移控制权改进误用问题是人用错了不是系统不行改进说明书、改进HMI、增加监测减少误用 实战AEB系统的功能改进方案把前几期AEB系统分析出的FI和TC用四种策略逐一“开药方”。 回顾识别出的FI和TCFI ID功能不足触发条件FI-01摄像头低照度识别不足夜间 白色货车FI-02雷达对非金属不敏感非金属货箱FI-03静止障碍物处理策略缺失前方静止车辆️ 改进方案针对FI-01摄像头低照度识别不足 TC夜间白色货车策略方案效果系统改进增加毫米波雷达摄像头融合雷达不受光照影响夜间也能检测到货车⛔功能限制限制AEB在夜间无路灯场景下的车速降低碰撞能量针对FI-02雷达对非金属不敏感 TC非金属货箱策略方案效果系统改进采用异构传感器摄像头雷达激光雷达多传感器交叉验证减少单一传感器的盲区⛔功能限制增加非金属物体检测算法降低对雷达的依赖在雷达“看不见”时依靠摄像头补充识别针对FI-03静止障碍物处理策略缺失 TC前方静止车辆策略方案效果系统改进在规范中明确定义静止障碍物的处理策略从“不知道怎么办”变成“知道怎么办”权限移交当检测到“可能撞上静止障碍物”时提前1.5秒发出接管请求给驾驶员足够时间反应 改进前后对比8.4 更新系统规范——改完了要写下来这是SOTIF和传统开发最重要的区别之一。ISO 21448第8.4节的核心要求每次功能改进之后都必须更新第5章的功能和系统规范。为什么这么重要因为SOTIF是迭代的。如果你只改了代码没更新规范下一轮迭代的时候你可能会“忘记”自己改了什么或者新加入的工程师不知道系统为什么这么设计。更新的内容更新项大白话新增安全措施“加了雷达融合要写进规范里”修改功能行为“夜间场景下限制了车速要写进规范里”更新设计约束“增加了ODD限制要写进规范里”更新验证用例“新增了测试场景要写进测试计划里”规范的更新状态反映了当前的设计状态。在SOTIF的迭代过程中每一次改进后功能和系统规范都要用确定的措施更新升级。⚠️ 功能改进中容易踩的“坑”坑1只改代码不更新规范❌ “加了个雷达融合代码改了就行”——但规范里没写下一轮迭代就忘了✅8.4要求每次功能改进后必须更新第5章的功能和系统规范坑2只做“系统改进”不用“功能限制”❌ “升级传感器就能解决所有问题”——但有些是物理极限根本做不到✅四种策略组合使用系统改进功能限制权限移交改进误用坑3忘了考虑“改进措施之间的冲突”❌ “加了雷达融合又加了功能限制”——两个措施可能互相矛盾✅改进措施之间需要协调比如功能限制不能影响系统改进后的正常功能坑4功能限制“一刀切”❌ “夜间场景不安全直接禁用AEB”——晚上完全没保护了✅精细化的功能限制不是“禁用”是“降低车速”或“增加警告” 本期重点回顾核心要点一句话总结系统改进“升级硬件、优化算法”——让系统变强⛔功能限制“不行的时候就不干”——让系统认怂权限移交“我不行了你来”——让驾驶员接管改进误用“让用户别用错”——让驾驶员用对更新规范“改完了要写下来”——让改进可追溯