前言为什么第5章如此重要在SOTIF的V模型开发流程中第5章功能与系统规范位于V模型的左上角——它是整个SOTIF活动的起点也是决定后续所有分析质量的源头。一个常见的误区是“功能规范不就是写个功能需求文档吗有什么难的”但SOTIF视角下的功能规范与传统需求文档有一个根本差异传统需求文档回答系统应该做什么SOTIF功能规范还必须回答系统在什么条件下能做到什么程度。多出来的这后半句恰恰是SOTIF的核心关切——如果连系统能力边界在哪里都没定义清楚你怎么知道它在边界外会发生什么一、功能规范的四大核心要素ISO 21448第5章要求SOTIF功能规范必须包含以下四大核心要素图1SOTIF功能规范的四大核心要素1.1 功能定义Function Definition功能定义是最基础的层级需要明确描述功能目标系统要实现什么安全目标比如AEB的目标是在检测到前方碰撞风险时自动制动以减轻或避免碰撞。系统边界功能的作用范围和限制条件。比如AEB只在车速10-60km/h范围内激活不对对面来车响应。预期行为描述在各种输入条件下系统应该输出什么行为。需要覆盖正常行为和降级行为。系统交互关系功能与其他系统之间的依赖和影响关系。比如AEB依赖感知模块的目标识别结果依赖底盘模块的制动执行。实践要点功能定义不是写系统应该能刹车而是要写清楚在什么感知输入条件下、在什么速度范围内、以什么减速度上限、对什么类型的目标物、执行制动行为。1.2 ODD定义Operational Design DomainODD是SOTIF功能规范中最有特色也最重要的部分。后续的所有危害分析、触发条件识别都围绕ODD展开。ODD定义了系统被设计为能够安全运行的所有条件包括但不限于图2ODD设计运行范围的五大维度ODD的每个维度都需要给出具体的、可量化的参数值而不是模糊的描述。对比如下维度模糊定义不合规量化定义合规道路类型“适用于主要道路”“高速公路、城市快速路不含匝道”速度范围“中低速”“10-60 km/h”天气条件“良好天气”“能见度100m无积雪/积水路面”光照条件“白天”“照度500 lux无直射逆光”关键提醒ODD之外的场景不属于系统预期使用范围。但SOTIF要求即使场景在ODD之外也需要评估合理可预见的越界使用——驾驶员会不会误以为系统在ODD外也能工作1.3 系统架构System Architecture功能规范还需要定义实现预期功能的系统架构包括传感器配置使用了哪些传感器摄像头、毫米波雷达、激光雷达等各自的安装位置、视场角、探测范围算法模块划分感知、规划、控制的模块边界和接口定义执行器接口系统如何与底盘执行器制动、转向、油门交互冗余设计是否有传感器冗余、算法冗余从SOTIF角度看系统架构描述的目的不是指导硬件设计而是为后续的性能局限分析和触发条件识别提供基础——你需要知道系统由哪些传感器和算法组成才能分析它们在什么条件下会不够好。1.4 人机交互规范HMI Specification人机交互规范在SOTIF中有特殊重要性因为合理可预见的误用很大程度上与HMI设计相关功能状态提示系统当前是否激活是否在正常工作驾驶员能否清晰感知接管请求设计当系统能力达到边界时如何提醒驾驶员接管提醒方式声光触觉、时机、强度误用预防策略如何通过设计降低驾驶员过度信任的风险如脱手检测、注意力监控等实践要点HMI规范不能只写提醒驾驶员要写清楚在什么条件下、以什么方式、在多长时间内、以什么强度提醒、驾驶员未响应时系统的降级策略是什么。二、与ISO 26262相关项定义的区别初学者常问“ISO 26262也有相关项定义Item DefinitionSOTIF的功能规范和它有什么区别”图3SOTIF功能规范与ISO 26262相关项定义的对比两者的核心差异可以用一句话概括ISO 26262定义系统做什么SOTIF定义系统在什么条件下能做好。对比维度ISO 26262 相关项定义ISO 21448 功能规范关注焦点电子电气系统的功能描述预期功能的能力边界与限制ODD提及但不深入核心要素需详细量化定义传感器规格一般不涉及必须详细描述性能参数算法能力假设一般不涉及必须明确算法的能力假设误用预防不重点关注核心要素之一后续分析为HARA提供输入为危害分析触发条件识别提供输入实际项目中的做法通常将两者合并为一份统一的功能规范文档既满足26262的要求也覆盖21448的需求。但内部需要清晰区分哪些内容服务于哪个标准。三、实践案例以AEB功能为例让我们用AEB自动紧急制动功能为例看看一份合格的SOTIF功能规范应该长什么样。3.1 功能定义示例功能名称自动紧急制动AEB 功能目标在检测到前方碰撞风险且驾驶员未及时反应时 自动执行制动以减轻碰撞严重程度或避免碰撞 系统边界 - 激活速度范围5-60 km/h - 目标类型前方同车道车辆、行人、自行车 - 不响应场景对面来车、横穿目标速度差30km/h时 预期行为 - 正常行为检测到碰撞风险TTC2s时分阶段制动 第一阶段50%制动减速度0.3g 第二阶段100%制动减速度0.6g - 降级行为传感器置信度低于阈值时仅执行第一阶段制动 并通过HMI提醒驾驶员接管 系统交互 - 依赖前向摄像头提供目标识别、前向毫米波雷达提供距离 - 输出制动压力请求至ESP系统 - 反馈制动状态至仪表和HMI3.2 ODD定义示例ODD维度具体定义道路类型铺装路面车道线清晰纵坡8%速度范围本车5-60 km/h目标速度0-60 km/h天气条件无雨雪雾能见度200m光照条件自然光照度500 lux无直射逆光目标类型车辆宽1.2m、行人高1.0m、自行车车道宽度2.75-4.0m3.3 关键的能力假设SOTIF功能规范与普通需求文档最大的不同是需要明确系统能力假设——即假设系统能做到什么程度传感器能力假设 - 摄像头白天晴天下对车辆有效识别距离≥80m 对行人有效识别距离≥40m - 毫米波雷达对车辆有效探测距离≥120m 对行人/自行车探测距离≥30m 算法能力假设 - 目标识别准确率≥99%ODD范围内 - 误报率≤0.01次/100km - 响应延迟≤200ms 执行器能力假设 - ESP制动系统建压时间≤150ms - 最大制动减速度0.6g这些能力假设是后续触发条件识别的基础——如果实际性能低于假设值就构成了性能局限可能引发危害行为。四、写好SOTIF功能规范的五条经验经验一量化优先于定性系统在良好天气下工作是不合格的描述。系统在能见度200m、照度500lux、无积雪路面条件下工作才是合格的。SOTIF要求所有条件可量化、可测试、可验证。经验二边界比正常路径更重要传统需求文档热衷于描述系统正常工作时的行为但SOTIF更关注系统在边界条件下的行为。哪些边界ODD边界接近ODD限制时系统如何过渡性能边界传感器接近探测极限时如何降级接口边界依赖模块异常时如何兜底经验三误用场景要合理可预见不要写驾驶员不应在驾驶时看手机——这是道德说教不是工程规范。要写当驾驶员连续脱手15秒时系统执行分级提醒3秒声光提醒 → 5秒安全降速 → 紧急停车。合理可预见的判断标准正常人可能做、且可以合理预料到的行为。经验四能力假设要留有余量定义传感器能力假设时不要按实验室最优条件写。要考虑实际道路上的退化因素镜头脏污、安装偏差、老化等。建议在实验室数据基础上留10-20%的余量。经验五与功能安全协同功能规范应该同时满足ISO 26262和ISO 21448的要求。建议在文档中用标签标注每部分服务于哪个标准如[FuSa]和[SOTIF]方便追溯。五、小结本篇我们详细拆解了ISO 21448第5章——功能规范定义的核心内容。要点总结功能规范定位SOTIF的起点决定后续所有分析的质量四大要素功能定义 ODD 系统架构 HMIODD核心性ODD是SOTIF最有特色的要素必须量化与26262区别26262定义做什么SOTIF定义能做到什么程度能力假设必须明确传感器和算法的能力假设留有余量误用预防HMI规范中必须包含合理的误用预防策略