4、预期功能安全关键术语：预期功能、功能不足、触发条件、场景、危害事件、风险、安全目标

预期功能安全（SOTIF，Safety Of The Intended Functionality）的核心挑战在于：系统本身没有故障，但依然可能因为性能局限、环境干扰或用户误用而产生危害。要准确开展SOTIF分析与开发，首先必须建立一套精确的术语体系。ISO 26262与ISO 21448（SOTIF标准）共同定义了七个关键术语——预期功能、功能不足、触发条件、场景、危害事件、风险、安全目标。这些术语并非孤立的概念，而是构成了一条从“功能定义”到“安全验证”的逻辑链。本章将逐一拆解每个术语的内涵、判定方法、相互关系及工程应用要点，帮助学员在后续的HARA（危害分析与风险评估）和SOTIF释放工作中建立统一的沟通语言。

4.1 预期功能与功能不足：定义与边界

4.1.1 核心原理

预期功能（Intended Functionality）是指系统设计时被期望实现的功能行为，包括功能规范、性能指标、使用场景假设以及合理的用户操作预期。它不等同于“功能安全”中的安全机制，而是指系统在无故障条件下应表现出的行为。例如，自适应巡航控制（ACC）的预期功能包括：在干燥路面、良好能见度下，按设定速度跟车并保持安全距离。

功能不足（Functional Insufficiency）是指预期功能在特定条件下无法达到设计意图的性能局限或规范缺陷。它分为两类：性能局限（如传感器探测距离不足、算法在弯道中误判）和规范不足（如未定义雨天场景下的降级策略）。功能不足是SOTIF分析的核心对象，它不源于硬件随机故障或软件系统故障，而是源于“设计本身对某些场景考虑不周”。

4.1.2 判断方法

识别功能不足需要系统化的方法，推荐以下三步流程：

1. 功能规范拆解：将预期功能分解为感知、决策、执行三个层面，列出每个层面的性能边界（如最大探测距离、最小识别置信度、最大制动减速度）。
2. 场景覆盖分析：对照真实世界场景库（如Euro NCAP场景、自然驾驶数据库），找出功能规范中未覆盖或覆盖不足的场景参数组合。
3. 触发条件假设：针对每个未覆盖场景，假设可能引发功能不足的触发条件（如逆光、雨雾、路面标线磨损），形成“功能不足-触发条件”候选清单。

4.1.3 案例拆解：AEB（自动紧急制动）的功能不足识别

某OEM开发AEB系统，目标是在车速30-80km/h时避免与前方静止车辆碰撞。在实车测试中发现：当目标车辆为白色且背景为强逆光时，AEB系统未触发制动。分析过程如下：

• 初始现象：测试车以50km/h接近白色静止卡车，逆光条件下系统无报警无制动。
• 关键数据：摄像头传感器在逆光下的信噪比下降约40%，目标检测置信度从0.95降至0.62（低于0.7的触发阈值）。
• 分析判断：功能不足在于“视觉感知模块对高动态范围场景的适应能力不足”，属于性能局限；同时功能规范中未定义“逆光+白色目标”的降级策略，属于规范不足。
• 改进措施：增加HDR（高动态范围）图像处理算法，并将置信度阈值调整为动态阈值（根据环境光照自动调整）。
• 复盘经验：功能不足的识别不能仅依赖测试，必须在开发早期进行场景参数扫描，尤其是光照、天气、目标类型等边界条件。

4.2 触发条件与场景：从抽象到具象

4.2.1 核心原理

触发条件（Triggering Condition）是导致功能不足被激活的特定条件组合，包括环境条件（光照、天气、道路）、交通条件（其他车辆行为、行人密度）、以及系统自身状态（车速、传感器配置）。触发条件本身不直接造成危害，而是“点燃”功能不足的导火索。

场景（Scenario）是描述系统运行环境的完整快照，包含静态要素（道路几何、交通标志）、动态要素（其他交通参与者的运动状态）、环境要素（天气、光照）以及自车状态（车速、转向角）。场景是SOTIF分析的基本单元，通常用参数化语言描述（如“雨天夜间，自车以60km/h行驶在双向两车道，对向车辆开启远光灯”）。

4.2.2 场景分类与参数化

4.2.3 实战场景：触发条件组合的识别方法

在L3级高速公路领航辅助（HWP）开发中，团队需要识别“车道线丢失”场景下的触发条件。通过自然驾驶数据采集，发现以下触发条件组合：

• 环境条件：强光直射（太阳高度角低于15°）、路面反光、车道线磨损率超过30%。
• 交通条件：前方大型车辆遮挡车道线、相邻车道车辆并行导致摄像头视野受限。
• 系统状态：自车处于弯道（曲率半径小于250m）且车速高于100km/h。

团队将这些触发条件组合成逻辑场景，并在仿真中进行了2000组参数扫描，最终识别出12个高风险场景，其中3个场景会导致系统退出HWP且未发出足够早的接管请求。这一分析直接推动了“车道线丢失降级策略”的规范更新。

4.3 危害事件与风险：从场景到量化评估

4.3.1 核心原理

危害事件（Harm Event）是指由预期功能的行为（或缺失行为）导致的伤害事件，它包含两个要素：危害（对人员或财产的物理伤害）和可预见操作场景（危害发生的具体场景）。例如，“在高速公路上，ACC系统未识别前方静止车辆导致追尾，造成乘员受伤”是一个危害事件。

风险（Risk）是危害事件发生的概率与严重度的组合度量。在ISO 26262中，风险通过三个参数评估：S（Severity，严重度）、E（Exposure，暴露概率）、C（Controllability，可控性）。风险等级（ASIL）由S、E、C组合决定，从ASIL A（最低）到ASIL D（最高），QM（Quality Management）表示无安全等级要求。

4.3.2 风险评估流程

1. 危害识别：从功能不足和触发条件出发，推导可能的危害事件。使用“危害-场景”矩阵，确保每个危害事件都关联到具体的场景描述。
2. 参数评估：对每个危害事件，分别评估S（0-3级）、E（0-4级）、C（0-3级）。评估依据包括统计数据、仿真结果、专家判断。
3. ASIL等级确定：根据ISO 26262-3:2018中的ASIL等级表，由S、E、C组合确定ASIL等级。
4. 风险接受准则：对于SOTIF，还需考虑“残余风险”是否可接受。通常参考GAMAB（Globalement Au Moins Aussi Bon，全球至少同样好）原则或ALARP（As Low As Reasonably Practicable，合理可行尽量低）原则。

4.3.3 案例拆解：泊车辅助系统的风险评估

某APA（自动泊车辅助）系统在垂直泊车场景中，可能因超声波传感器探测盲区导致与后方矮墙碰撞。评估过程如下：

• 危害事件：车辆在倒车过程中，APA系统未识别高度低于30cm的矮墙，导致车辆后保险杠损坏，无人员受伤。
• S评估：S=1（轻度伤害，仅财产损失）。
• E评估：E=3（中等暴露，垂直泊车场景在城市中常见，但矮墙出现概率较低）。
• C评估：C=2（可控性有限，驾驶员可能来不及干预）。
• ASIL等级：查表得ASIL A。
• 安全目标：要求APA系统在探测到高度低于30cm的障碍物时，必须发出声光报警并限制倒车速度不超过5km/h。

4.4 安全目标：从风险到安全要求

4.4.1 核心原理

安全目标（Safety Goal）是针对每个危害事件制定的顶层安全要求，用于消除或减轻风险。安全目标必须包含：危害事件的引用、安全行为描述、ASIL等级、验证与确认准则。安全目标是连接SOTIF分析与功能安全开发的桥梁，它会被分解为功能安全需求（FSR）和技术安全需求（TSR）。

4.4.2 安全目标编写规范

4.4.3 实战场景：安全目标的分解与验证

以L2级车道保持辅助（LKA）为例，识别到危害事件“在雨天标线不清时，LKA系统错误退出导致车辆偏离车道”。制定安全目标如下：

• 安全目标SG-01：在车道线可见度低于阈值时，LKA系统必须在200ms内发出接管请求，并保持车道居中控制至少3秒。
• ASIL等级：ASIL B（因为偏离车道可能导致对向碰撞，S=2，E=3，C=2）。
• 分解需求：感知模块需在雨天场景下达到最小识别置信度0.8；决策模块需在置信度低于阈值时触发降级策略；执行模块需在3秒内维持横向控制。
• 验证方法：在仿真环境中构建200个雨天场景，覆盖不同雨量、不同标线磨损程度，验证系统响应时间与保持时间。

4.5 术语关系总结与工程应用

七个术语构成了SOTIF开发的完整逻辑链：预期功能定义了“系统应该做什么”，功能不足揭示了“系统在哪些条件下做不好”，触发条件描述了“什么情况下会暴露不足”，场景提供了“分析不足的上下文”，危害事件明确了“不足导致的后果”，风险量化了“后果的严重程度”，安全目标则给出了“必须达到的安全底线”。

在工程实践中，建议团队建立术语管理表，确保每个术语在文档、评审、测试中保持一致的定义。例如，在SOTIF测试用例编写时，每个测试用例应明确标注其覆盖的“场景-触发条件-功能不足-危害事件”链路，这样当测试失败时，可以快速追溯到具体的功能不足和风险等级。