2. 功能安全基础

功能安全(Functional Safety)的核心命题是:当电子电气系统发生随机硬件失效或系统性失效时,系统能否把风险控制在可接受范围内。ISO 26262 给出的答案不是“让系统永不出错”,而是通过一套可追溯、可验证、可审核的工程活动,把安全责任从“事后补救”前移到“设计约束”。理解本章的四个基础概念——功能安全、安全生命周期、ASIL 等级、相关项与安全目标——是后续所有确认与审核工作的逻辑起点。

一、功能安全的基本概念

功能安全指“不存在由电子电气系统的功能异常表现引起的不可接受风险”。这里有两个关键词:功能异常表现与不可接受风险。前者包括失效、故障、误动作、非预期行为;后者由危害事件的发生概率与严重程度共同决定。功能安全不是产品功能本身,而是附加在功能之上的“安全机制”,例如监控、冗余、限值、降级、故障响应。

与之容易混淆的是“预期功能安全(SOTIF)”。功能安全处理的是系统失效导致的风险,而 SOTIF 处理的是“系统没有失效,但功能在特定场景下表现不足”导致的风险。审核中若把两者混为一谈,会导致安全目标与验证方法错配。

功能安全的三层逻辑:危害 → 安全目标 → 安全需求。危害是起点,安全目标是顶层约束,安全需求是落到系统、硬件、软件上的可执行条款。

二、安全生命周期:从概念到退役的闭环

ISO 26262 的安全生命周期覆盖“概念阶段—开发阶段—生产运行—退役”。它不是一条单向流水线,而是一个带反馈的闭环:验证与确认结果会反向修正安全目标与安全需求。生命周期中的关键节点包括:相关项定义、危害分析与风险评估、安全目标制定、功能安全概念、技术安全概念、系统/硬件/软件开发、集成与测试、安全确认、生产与运行、退役。

审核视角下,生命周期最重要的不是“做了哪些活动”,而是活动之间的追溯性:每个安全目标能否追溯到危害事件?每条安全需求能否追溯到安全目标?每个测试用例能否追溯到安全需求?追溯链断裂,就是审核中的典型不符合项。

ISO 26262 安全生命周期闭环与追溯关系 概念阶段 相关项定义 HARA / 安全目标 开发阶段 功能安全概念 技术安全概念 实现阶段 系统 / 硬件 / 软件 集成与测试 确认与运行 安全确认 生产 / 运行 / 退役 追溯链(审核核心检查项) 危害事件 Hazard 安全目标 Safety Goal 安全需求 Safety Requirement 测试用例 Test Case 验证与确认反馈,修正安全目标与需求 ASIL 等级:由 S、E、C 三维参数决定 S 严重度 S0 ~ S3 E 暴露率 E0 ~ E4 C 可控性 C0 ~ C3 输出:QM / A / B / C / D D 为最高完整性等级

三、ASIL 等级:风险分级的工程语言

ASIL(Automotive Safety Integrity Level)由三个参数共同决定:S(Severity,严重度)、E(Exposure,暴露率)、C(Controllability,可控性)。S 描述伤害的严重程度,E 描述运行场景出现的概率,C 描述驾驶员或其他人员能否及时控制危害。三者组合后映射为 QM、ASIL A、B、C、D 五个等级,D 最高。

ASIL 等级直接决定开发过程的严格度:需求分析深度、验证方法、硬件失效率目标、软件架构约束、工具置信度、审核证据要求都会随等级提升而加严。例如 ASIL D 通常要求更高的诊断覆盖率、更严格的独立性评审和更完整的追溯证据。

ASIL 等级 典型风险特征 开发约束强度 审核关注重点
QM 无安全目标,按质量管理 常规质量流程 流程符合性
ASIL A 低严重度、低暴露、易控制 基础安全活动 安全需求完整性
ASIL B 中等风险,需一定安全机制 中等验证深度 测试覆盖率与追溯
ASIL C 较高严重度或较难控制 较高诊断覆盖率 硬件失效率与独立性
ASIL D 高严重度、高暴露、难控制 最高完整性要求 全链条证据与确认评审

四、相关项定义与安全目标

相关项(Item)是功能安全分析的基本对象,可以是一个系统、一个功能或一个组件。相关项定义要明确边界:它包含什么、不包含什么、与外部环境如何交互、依赖哪些输入输出。边界不清,HARA 就会失焦,安全目标也会失去约束力。

安全目标(Safety Goal)是相关项层面的顶层安全需求,通常表述为“避免某类危害事件发生”或“将某类风险限制在可接受水平”。安全目标必须可分配、可验证、可追溯。例如:“避免车辆在行驶中非预期加速”是一个安全目标;而“MCU 应在 10ms 内检测到扭矩信号异常并进入安全状态”则是从它派生出的功能安全需求。

审核实操中,检查安全目标是否合格,可以问三个问题:它是否对应明确的危害事件?它是否可被分配至系统/硬件/软件?它是否有对应的验证与确认证据?三问缺一,安全目标就只是口号。

五、案例与常见误区

以电子驻车制动(EPB)为例。相关项可定义为“EPB 控制单元及其执行机构”。HARA 识别出“行驶中 EPB 意外施加”这一危害事件,评估 S3、E4、C3,得出 ASIL D。安全目标可写为“避免行驶中非预期驻车制动”。由此派生功能安全需求:车速高于阈值时禁止 EPB 动作;再派生技术安全需求:车速信号需冗余校验,MCU 需具备看门狗与安全状态切换。

常见误区有三类:其一,把“功能安全”等同于“产品可靠性”,忽视安全目标与危害的对应关系;其二,ASIL 等级拍脑袋决定,缺少 S/E/C 的评估记录;其三,相关项边界随意扩大或缩小,导致 HARA 覆盖不全或重复分析。复盘时应重点检查:危害清单是否完整、S/E/C 评分是否有依据、安全目标是否可追溯、需求分解是否闭环。

审核追溯检查示例(伪记录):
Hazard: H-012 行驶中EPB意外施加
  -> Safety Goal: SG-003 避免行驶中非预期驻车制动 (ASIL D)
    -> FSR: FSR-021 车速 > 5km/h 时禁止EPB动作
      -> TSR: TSR-045 车速信号双通道校验,偏差 > 2km/h 进入安全状态
        -> Test: TC-118 注入车速信号偏差,验证 10ms 内进入安全状态

掌握以上四个基础概念后,后续的安全确认与审核才有共同的判断尺度:功能安全定义“防什么”,安全生命周期定义“何时做、谁做、如何闭环”,ASIL 定义“做到多严”,相关项与安全目标定义“对谁做、做到什么程度”。这四者共同构成 ISO 26262 工程实践的底层坐标系。