ISO 21448第5章详解：功能规范定义——SOTIF的基石

前言：为什么第5章如此重要？

在SOTIF的V模型开发流程中，第5章"功能与系统规范"位于V模型的左上角——它是整个SOTIF活动的起点，也是决定后续所有分析质量的源头。

一个常见的误区是：“功能规范不就是写个功能需求文档吗？有什么难的？”

但SOTIF视角下的功能规范与传统需求文档有一个根本差异：

传统需求文档回答"系统应该做什么"，SOTIF功能规范还必须回答"系统在什么条件下能做到什么程度"。

多出来的这后半句，恰恰是SOTIF的核心关切——如果连"系统能力边界在哪里"都没定义清楚，你怎么知道它在边界外会发生什么？

一、功能规范的四大核心要素

ISO 21448第5章要求，SOTIF功能规范必须包含以下四大核心要素：

图1：SOTIF功能规范的四大核心要素

1.1 功能定义（Function Definition）

功能定义是最基础的层级，需要明确描述：

• 功能目标：系统要实现什么安全目标？比如AEB的目标是"在检测到前方碰撞风险时自动制动以减轻或避免碰撞"。
• 系统边界：功能的作用范围和限制条件。比如AEB只在车速10-60km/h范围内激活，不对对面来车响应。
• 预期行为描述：在各种输入条件下，系统应该输出什么行为。需要覆盖正常行为和降级行为。
• 系统交互关系：功能与其他系统之间的依赖和影响关系。比如AEB依赖感知模块的目标识别结果，依赖底盘模块的制动执行。

实践要点：功能定义不是写"系统应该能刹车"，而是要写清楚"在什么感知输入条件下、在什么速度范围内、以什么减速度上限、对什么类型的目标物、执行制动行为"。

1.2 ODD定义（Operational Design Domain）

ODD是SOTIF功能规范中最有特色也最重要的部分。后续的所有危害分析、触发条件识别都围绕ODD展开。

ODD定义了系统"被设计为能够安全运行的所有条件"，包括但不限于：

图2：ODD设计运行范围的五大维度

ODD的每个维度都需要给出具体的、可量化的参数值，而不是模糊的描述。对比如下：

关键提醒：ODD之外的场景不属于系统预期使用范围。但SOTIF要求，即使场景在ODD之外，也需要评估"合理可预见的越界使用"——驾驶员会不会误以为系统在ODD外也能工作？

1.3 系统架构（System Architecture）

功能规范还需要定义实现预期功能的系统架构，包括：

• 传感器配置：使用了哪些传感器（摄像头、毫米波雷达、激光雷达等），各自的安装位置、视场角、探测范围
• 算法模块划分：感知、规划、控制的模块边界和接口定义
• 执行器接口：系统如何与底盘执行器（制动、转向、油门）交互
• 冗余设计：是否有传感器冗余、算法冗余

从SOTIF角度看，系统架构描述的目的不是指导硬件设计，而是为后续的性能局限分析和触发条件识别提供基础——你需要知道系统由哪些传感器和算法组成，才能分析它们在什么条件下会"不够好"。

1.4 人机交互规范（HMI Specification）

人机交互规范在SOTIF中有特殊重要性，因为"合理可预见的误用"很大程度上与HMI设计相关：

• 功能状态提示：系统当前是否激活？是否在正常工作？驾驶员能否清晰感知？
• 接管请求设计：当系统能力达到边界时，如何提醒驾驶员接管？提醒方式（声光触觉）、时机、强度
• 误用预防策略：如何通过设计降低驾驶员过度信任的风险？如脱手检测、注意力监控等

实践要点：HMI规范不能只写"提醒驾驶员"，要写清楚"在什么条件下、以什么方式、在多长时间内、以什么强度提醒、驾驶员未响应时系统的降级策略是什么"。

二、与ISO 26262相关项定义的区别

初学者常问：“ISO 26262也有相关项定义（Item Definition），SOTIF的功能规范和它有什么区别？”

图3：SOTIF功能规范与ISO 26262相关项定义的对比

两者的核心差异可以用一句话概括：

ISO 26262定义"系统做什么"，SOTIF定义"系统在什么条件下能做好"。

实际项目中的做法：通常将两者合并为一份统一的功能规范文档，既满足26262的要求，也覆盖21448的需求。但内部需要清晰区分哪些内容服务于哪个标准。

三、实践案例：以AEB功能为例

让我们用AEB（自动紧急制动）功能为例，看看一份合格的SOTIF功能规范应该长什么样。

3.1 功能定义示例

功能名称：自动紧急制动（AEB） 功能目标：在检测到前方碰撞风险且驾驶员未及时反应时， 自动执行制动以减轻碰撞严重程度或避免碰撞 系统边界： - 激活速度范围：5-60 km/h - 目标类型：前方同车道车辆、行人、自行车 - 不响应场景：对面来车、横穿目标（速度差>30km/h时） 预期行为： - 正常行为：检测到碰撞风险TTC<2s时，分阶段制动 第一阶段：50%制动减速度（0.3g） 第二阶段：100%制动减速度（0.6g） - 降级行为：传感器置信度低于阈值时，仅执行第一阶段制动 并通过HMI提醒驾驶员接管 系统交互： - 依赖：前向摄像头提供目标识别、前向毫米波雷达提供距离 - 输出：制动压力请求至ESP系统 - 反馈：制动状态至仪表和HMI

3.2 ODD定义示例

3.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章——功能规范定义的核心内容。