FS-05 功能安全ISO26262之安全目标与功能安全概念深度解析

FS-05 安全目标与功能安全概念：从HARA到系统架构的桥梁

**来源依据：**ISO 26262-3:2018 Clause 7.4.2、Clause 8、Clause 9

系列： FS系列（Functional Safety）| **篇目：**FS-05/20

FS-05 安全目标与功能安全概念：从HARA到系统架构的桥梁

一、引言：从HARA到安全架构的必经之路

在ISO 26262功能安全标准体系中，危害分析与风险评估（HARA） 完成了对系统潜在危害的识别与风险量化，而安全目标与功能安全概念则是将这些分析结果转化为具体技术要求的桥梁。这一环节决定了系统将如何"设计"其安全性------从抽象的"不能造成人员伤害"到具体的"检测到转向助力失效后200ms内进入跛行回家模式"。

本文将深度解析ISO 26262-3:2018 Clause 7.4.2规定的安全目标定义，以及Clause 9规定的功能安全概念（Functional Safety Concept, FSC）开发过程，为工程师提供从HARA到系统架构的完整技术路径。

来源依据： ISO 26262-3:2018 Clause 7.4.2、Clause 8、Clause 9

二、Safety Goal（安全目标）：顶层安全需求

2.1 Safety Goal的定义与定位

Safety Goal是功能安全生命周期的最高层级安全要求，直接继承自HARA输出的危害事件（hazard event）和ASIL等级。根据ISO 26262-3:2018 Clause 7.4.2.1：

> "Safety Goal是为避免不合理风险而制定的顶层安全要求，从HARA中导出的每个危害事件至少对应一个Safety Goal。"

Safety Goal具有以下核心特征：

| 特征 | 说明 |
| 顶层性 | 最高层级的功能安全需求，不从其他需求派生 |
| 继承性 | 直接来自HARA的危害事件和ASIL等级 |
| 目标性 | 描述期望达到的安全状态，而非具体实现方式 |
| 可追溯性 | 必须能够追溯到具体的危害事件 |

可测试性	Safety Goal必须是可验证的

2.2 Safety Goal的编写规范

根据工程实践经验，Safety Goal应遵循SMART原则：

Specific（具体）：明确具体的安全功能要求

Measurable（可测量）：有明确的量化指标
Achievable（可实现）：在现有技术条件下可行
Relevant（相关）：直接关联到危害事件
T ime-bound（有时限）：有明确的响应时间要求

示例对比：

❌ 不好的Safety Goal： > "EPS系统应该安全"

✅ 符合SMART原则的Safety Goal： > "当车速>10km/h且检测到转向助力电机失效时，系统应在200ms内进入跛行回家模式，维持最小转向助力（正常助力的20%）直至车速降至0或驾驶员关闭电源"

2.3 Safety Goal的数量控制

一个Item（相关项）通常会有多个Safety Goal，数量取决于HARA分析识别出的危害事件数量。但需要注意：

避免过度细化 ：如果一个Safety Goal可以通过更简单的系统设计来满足，则不需要将其拆分为多个 2. 避免过度抽象 ：如果多个危害事件有共同的根因，可以共享一个Safety Goal 3. ASIL合并：来自同一危害事件的多个Safety Goal应具有相同的ASIL等级

实际工程建议：

简单系统：3-8个Safety Goal
复杂系统（如自动驾驶控制器）：10-30个Safety Goal
Safety Goal过多可能意味着HARA分析过于细碎或系统边界定义不当

2.4 Safety Goal与Safety Requirement的关系

Safety Goal是顶层需求，其下会分解为多层安全需求：

复制代码

Safety Goal (顶层)
    ↓
Functional Safety Requirements (功能安全需求)
    ↓
Technical Safety Requirements (技术安全需求)
    ↓
Hardware/Software Requirements (硬件/软件需求)

这种分解关系必须通过追溯矩阵（Traceability Matrix）进行管理，确保每个Safety Goal的满足都能得到验证。

来源依据： ISO 26262-3:2018 Clause 7.4.2.2, Clause 7.4.2.3

三、FTTI（故障容错时间间隔）：时间维度的安全约束

3.1 FTTI的定义

Fault Tolerant Time Interval (FTTI) 是ISO 26262中最关键的时间参数之一。根据ISO 26262-3:2018 Clause 7.4.2.2：

> "FTTI是从系统内故障发生到危害事件可能发生之间的时间间隔。在FTTI内，系统必须检测到故障并进入安全状态，以防止危害事件发生。"

FTTI是HARA分析的时间维度延伸------S/E/C三因子回答了"风险有多严重"，而FTTI回答了"系统必须多快响应"。

3.2 FTTI的组成结构

FTTI可以分解为多个子阶段：

| 阶段 | 描述 | 典型时间占比 |
| 故障检测时间 | 从故障发生到系统检测到故障 | 10-30% |
| 诊断时间 | 确认故障性质、排除误报 | 20-40% |
| 安全机制响应时间 | 执行安全动作、进入安全状态 | 30-50% |

驾驶员反应时间	可控性评估（可选，C0/C1场景可忽略）	-

计算公式：

复制代码

FTTI = t_fault_detection + t_diagnosis + t_safe_state_transition
       （+ t_driver_reaction，如果考虑可控性）

3.3 FTTI的确定方法

FTTI的确定需要综合考虑以下因素：

3.3.1 基于驾驶员行为学数据

对于涉及驾驶员反应的场景，FTTI应考虑：

驾驶员平均反应时间：约700ms（复杂场景可达1500ms）
专业驾驶员反应时间：约400-500ms
紧急情况下的最短反应时间：约300ms

3.3.2 基于危害事件动力学

某些危害事件的发生需要特定条件：

车辆减速度累积到危险水平所需时间
方向盘转角偏差累积到危险程度所需时间
电池过温导致热失控的传播时间

3.3.3 基于系统架构约束

硬件处理周期、软件任务调度周期都会影响FTTI的下限：

硬件看门狗响应周期：通常10-50ms
软件任务周期：通常5-100ms
传感器采样周期：通常1-20ms

3.4 FTTI典型数值参考

电池管理系统	500ms-2s	热失控传播相对较慢

来源依据： ISO 26262-3:2018 Clause 7.4.2.2, ISO 26262-9:2018 Clause 4

四、Safe State（安全状态）：系统故障后的归宿

4.1 Safe State的定义

根据ISO 26262-1:2018 Clause 3.133：

> "Safe State是指系统在故障后能够达到的、不存在不合理风险的状态。"

Safe State的核心要求是： 1. 无危害 ：在该状态下，危害事件不会发生 2. 可维持 ：系统能够在该状态下持续运行或安全停机 3. 可转换：系统能够从故障状态转换到Safe State

4.2 Safe State的分类

根据系统的具体特点，Safe State可以分为三种主要类型：

4.2.1 跛行回家模式（Limp Home Mode）

适用场景：系统部分功能丧失，但核心功能仍可维持

特征：

功能降级运行
性能受限但可用
允许驾驶员将车辆驾驶到安全地点

EPS系统示例：

关闭电子助力，保留机械转向连接
提供有限的被动助力（依赖车速的液压助力）
限制最大转向速度

4.2.2 降级运行模式（Degraded Mode）

适用场景：系统检测到潜在故障但尚未完全失效

特征：

部分冗余通道失效
提高监控频率
限制功率或性能

BMS系统示例：

单体电池过压时限制充放电功率
降低充电电流上限
禁用快充功能

4.2.3 功能关闭模式（Function Shutdown）

适用场景：故障无法通过降级运行来控制风险

特征：

完全关闭危险功能
可能影响车辆正常运行
优先保障人员安全

制动系统示例：

检测到ABS泵电机故障时，关闭ABS功能
保持基础制动能力
点亮故障灯提醒驾驶员

4.3 Safe State Transition（安全状态转换）

安全状态转换是FSC的核心内容之一，需要明确定义：

恢复条件	何时可以恢复到正常状态

设计要点： 1. Safe State Transition必须在FTTI内完成 2. 转换过程本身不能产生新的危害 3. 需要考虑转换过程中的瞬态行为

来源依据： ISO 26262-3:2018 Clause 7.4.2.1, ISO 26262-4:2018 Clause 6

五、Functional Safety Concept（功能安全概念）

5.1 FSC的定义与范围

根据ISO 26262-3:2018 Clause 9.1：

> "功能安全概念定义了实现Safety Goal所需的安全机制，并将这些机制分配到初步的系统架构中。"

FSC是连接"需要达到什么安全目标"与"如何实现这些目标"的关键环节。

5.2 FSC的开发输入

FSC开发需要以下输入：

Safe State定义	FSC确定	目标状态

5.3 FSC的核心内容

5.3.1 安全机制定义

安全机制（Safety Mechanism）是FSC的主体内容，包括：

检测类机制：

故障检测（Fault Detection）：识别系统中存在的故障
故障诊断（Fault Diagnosis）：确定故障的性质和位置
故障预测（Fault Prediction）：识别即将发生的故障（高级功能）

响应类机制：

故障处理（Fault Handling）：检测到故障后的处理逻辑
安全状态转换（Safe State Transition）：进入安全状态的路径
冗余切换（Redundancy Switching）：从主通道切换到备份通道

防止类机制：

故障预防（Fault Prevention）：通过设计避免故障发生
故障避免（Fault Avoidance）：通过质量管理避免系统性故障

5.3.2 安全机制选型决策

安全机制的选型需要综合考虑以下因素：

复制代码

安全机制选型 = f(ASIL, 故障类型, FTTI, 系统复杂度, 成本)

基于ASIL的选型指导：

ASIL D	2oo3/2oo2投票、异构冗余、硬件监控、故障注入测试

5.3.3 架构元素分配

FSC需要将安全机制分配到初步的系统架构元素：

分配到ECU：哪个ECU负责执行哪个安全机制

分配到传感器：哪些传感器用于故障检测
分配到执行器：哪些执行器用于安全响应
分配到通信 ：安全相关的通信路径

5.4 FSC的工作产品

根据ISO 26262-3:2018 Clause 9.5，FSC的主要工作产品包括：

FTTI分配	各子阶段的时间分配

来源依据： ISO 26262-3:2018 Clause 9, Clause 10

六、工程实践：以EPS系统为例

6.1 系统背景

电动助力转向系统（Electric Power Steering, EPS）是典型的安全关键系统：

ASIL等级：通常ASIL C或更高
功能：辅助驾驶员实现转向
危害：助力失效可能导致转向困难或失控

6.2 HARA输出示例

| 危害事件 | S | E | C | ASIL |
| 助力突然失效导致转向困难 | S2 | E4 | C2 | ASIL C |
| 助力过大导致过度转向 | S3 | E4 | C2 | ASIL C |

助力失控导致车辆突然转向	S3	E3	C3	ASIL D

6.3 Safety Goal定义

基于HARA，定义以下Safety Goal：

SG-01： > "当车速在10-80km/h范围内时，如果检测到助力电机失效，系统应在200ms内进入跛行回家模式，提供最小助力（正常助力的20%）直至车速降为0"

ASIL：D（从最严重危害事件继承）
FTTI：200ms

SG-02： > "系统应防止任何导致非驾驶员意图的转向力输出"

ASIL：D
FTTI：50ms（更严格的响应要求）

6.4 Safe State定义

SG-02	Function Shutdown	完全关闭电机输出

6.5 功能安全概念设计

6.5.1 故障检测机制

电源电压异常	电压监控	1ms

6.5.2 安全机制架构

复制代码

┌─────────────────────────────────────────────────┐
│                  EPS Controller                  │
├─────────────────────────────────────────────────┤
│  ┌──────────────┐    ┌──────────────┐          │
│  │ Main Channel │◄──►│ Monitor MCU  │          │
│  │  (ASIL C)   │    │  (ASIL C)    │          │
│  └──────┬───────┘    └──────┬───────┘          │
│         │                    │                   │
│         └────────┬─────────┘                   │
│                  │ Cross-Check                  │
│         ┌────────▼─────────┐                    │
│         │  Safety Relay   │                    │
│         │  (双路切断)      │                    │
│         └────────┬─────────┘                    │
│                  │                              │
│         ┌────────▼─────────┐                    │
│         │   Motor Driver  │                    │
│         └────────┬─────────┘                    │
└─────────────────┼───────────────────────────────┘
                  │
          ┌───────▼───────┐
          │   DC Motor    │
          │  (助力电机)    │
          └───────────────┘

6.6 TSR初步分配

TSR-004	电机电流每秒采样不少于1000次	Current Sensor	C

来源依据： ISO 26262-3:2018 Clause 9, ISO 26262-4:2018 Clause 5-6

七、常见陷阱与避坑指南

7.1 Safety Goal编写常见问题

问题1：Safety Goal过于抽象

❌ 错误示例： > "EPS系统应保证转向安全"

✅ 正确做法： > "当车速>10km/h时，如果助力电机电流超过额定值150%且持续超过50ms，系统应在100ms内进入跛行回家模式"

问题2：Safety Goal与系统需求混淆

❌ 错误示例： > "系统应使用双CAN通道冗余通信"

✅ 正确做法： > "安全相关的控制指令必须具备冗余传输能力，任何单点故障不得导致指令丢失"

分析：第一条是系统实现方案，第二条才是Safety Goal------描述需要达到的安全特性，而非具体实现。

问题3：FTTI设定不合理

过短导致的问题：

系统架构无法满足硬件周期约束
成本急剧上升
可能需要引入更复杂的安全机制

过长导致的问题：

可能无法有效防止危害事件
与驾驶员可控性评估冲突
认证审核可能被质疑

建议：在满足安全要求的前提下，FTTI应尽可能宽松，以降低实现难度。

7.2 Safe State设计常见问题

问题1：Safe State不等于系统正常状态

某些工程师会错误地将"无故障状态"等同于"Safe State"。实际上：

Safe State是故障后的状态
正常状态是无故障的状态
两者需要分别定义

问题2：Safe State转换过程的风险

在设计Safe State Transition时，需要注意：

转换过程本身不能产生瞬态危害
降级过程应有平滑过渡
某些情况下，直接切断可能比降级更安全

问题3：多故障场景的Safe State

当系统同时发生多个故障时：

需要定义故障优先级
可能需要组合多种Safe State策略
应考虑"级联故障"的处理

7.3 FSC开发常见问题

问题1：安全机制与功能需求冲突

某些安全机制可能影响系统性能：

冗余检查增加响应延迟
看门狗复位导致功能中断
传感器交叉验证增加计算负载

解决方案：

在FTTI允许范围内优化实现
考虑软硬件分工
使用专用硬件加速安全检查

问题2：安全机制本身的失效

需要考虑的问题：

安全机制是否会失效？
安全机制失效后如何处理？
是否需要"安全的"安全机制？

这引出了深度防御 （Defense in Depth）理念和元余的监控（Monitoring of Monitors）概念。

来源依据： ISO 26262-3:2018 Clause 9.4, ISO 26262-4:2018 Annex B

八、总结与展望

8.1 核心要点回顾

FSC	安全机制定义与架构分配，连接目标与实现

8.2 与后续阶段的衔接

FSC完成后，将进入系统级产品开发（ISO 26262-4）阶段：

FSC输出的TSR将细化为Technical Safety Requirements
系统架构将精化为详细的硬件/软件架构
安全机制将具体化为硬件电路和软件模块

8.3 第三版标准趋势

根据ISO 26262第三版（WD草案，预计2027年发布）的讨论方向：

增强的SOTIF集成：FSC将与SOTIF危害分析更紧密地结合
软件定义安全：随着软件复杂度增加，FSC对软件架构的指导将更加具体
AI/ML组件 ：如何为基于AI的组件定义Safety Goal和FSC将成为新课题

8.4 实践建议

尽早介入 ：Safety Goal的确定应与HARA并行迭代，而非HARA完成后再开始 2. 多方参与 ：FSC开发需要安全专家、系统工程师、硬件工程师、软件工程师的协作 3. 持续评审 ：Safety Goal和FSC应经过多轮评审，确保完整性和一致性 4. 文档管理：所有安全相关的决策必须有明确的文档记录和追溯关系

附录：关键标准条款索引

Part 1 Clause 3.140	Safety Goal定义

本文标签： #功能安全 #ISO26262 #汽车电子 #SafetyGoal #FTTI #SafeState #FunctionalSafetyConcept #HARA #EPS #BMS #安全架构 #自动驾驶 #AUTOSAR #FS系列

下期预告： FS-06 功能安全管理体系（FSMS）：组织级安全治理的工程实践

本文基于ISO 26262:2018标准编写，所有技术内容可追溯到标准原文条款。

📚 FS系列文章导航

[FS-01 ISO 26262标准体系全景解析](#FS-01 ISO 26262标准体系全景解析)
[FS-02 功能安全核心术语精解](#FS-02 功能安全核心术语精解)
[FS-03 ASIL等级体系深度解读](#FS-03 ASIL等级体系深度解读)
[FS-04 危害分析与风险评估（HARA）工程实践](#FS-04 危害分析与风险评估（HARA）工程实践)
FS-05 安全目标与功能安全概念（本文）
FS-06 功能安全管理体系（预告）
标签：#功能安全 #ISO26262 #汽车电子 #SafetyGoal #FTTI #SafeState #FunctionalSafetyConcept #HARA #EPS #BMS

**下期预告：**FS-06 功能安全管理体系（FSMS）：组织级安全治理的工程实践