3. 功能安全基础与ISO 26262框架

ISO 26262 是道路车辆功能安全的国际标准，它把“安全”从一句口号变成了一套可执行、可验证、可追溯的工程体系。理解这套体系，关键要抓住五个相互咬合的概念：安全生命周期、ASIL 等级、安全目标、功能安全概念，以及系统开发要求。它们不是并列的五个名词，而是一条从“风险有多大”推导到“具体怎么做”的完整逻辑链。

安全生命周期：把安全贯穿到产品全寿命

安全生命周期是 ISO 26262 的骨架。它从概念阶段开始，经过系统开发、硬件开发、软件开发、生产与运行，直到退役，每个阶段都有明确的输入、活动和输出。概念阶段的核心产物是相关项定义、危害分析与风险评估（HARA）和安全目标；开发阶段则把安全目标逐层分解为功能安全概念、技术安全概念，最终落到具体的硬件和软件安全机制上。

对线控底盘而言，安全生命周期尤其强调“追溯”。例如线控制动的安全目标必须能追溯到 HARA 中的危害事件，而每一个安全机制又要能追溯到它所支撑的安全目标。缺少这条追溯链，功能安全就只是文档堆砌。

ASIL 等级：用三个参数决定严格程度

ASIL（汽车安全完整性等级）由 HARA 得出，分为 A、B、C、D 四个等级，D 最严格，QM 表示只需常规质量管理。它由三个参数共同决定：

• 严重度 S：S0 无伤害，S1 轻中度伤害，S2 重度伤害，S3 危及生命。
• 暴露率 E：E0 极低概率，E1 低概率，E2 中等概率，E3 高概率，E4 极高概率。
• 可控性 C：C0 一般可控，C1 简单可控，C2 通常可控，C3 难以控制或无法控制。

三者组合后查表得到 ASIL。以线控制动为例：若车辆在高速行驶中制动失效，严重度通常为 S3；该场景暴露率可能为 E4；驾驶员对突然失去制动的可控性为 C3，则组合结果为 ASIL D。若同样的失效只发生在低速泊车场景，严重度可能降为 S1、可控性为 C2，ASIL 等级会明显降低。这说明 ASIL 不是对“部件”的评级，而是对“危害事件”的评级。

安全目标：从危害到可验证的陈述

安全目标是针对每个危害事件给出的顶层安全要求，通常表述为“防止……发生”或“在……情况下将……限制在……”。它必须满足几个条件：与危害事件一一对应、可验证、不依赖具体技术方案、并带有对应的 ASIL 等级和安全状态。

例如线控转向系统的一个安全目标可以写成：“防止车辆在行驶过程中出现非预期的转向力矩，ASIL D，安全状态为助力降级并点亮故障灯。”这里“非预期转向力矩”是危害，“助力降级”是安全状态，ASIL D 决定了后续开发必须满足的严格度。安全目标一旦确定，就成为整个开发过程的“宪法”。

功能安全概念与系统开发要求

功能安全概念是把安全目标转化为功能层面的安全要求，并分配给架构元素。它回答“系统应该做什么来保证安全”，例如“当检测到转向传感器信号不一致时，系统应在 20 ms 内进入降级模式”。技术安全概念则进一步回答“用什么技术实现”，例如双通道传感器、独立监控芯片、看门狗、冗余供电等。

系统开发要求则把技术安全概念落到具体设计约束上，包括：安全机制的设计与验证、故障容错时间间隔（FTTI）的分配、硬件随机失效的量化指标（如 SPFM、LFM）、软件架构的分区与监控、以及集成测试和确认测试的要求。对线控底盘来说，FTTI 是特别关键的参数：从故障发生到必须进入安全状态的时间窗口，必须大于“故障检测时间 + 故障响应时间”，否则安全目标无法达成。

把这条链走通，线控底盘的功能安全才真正落地。HARA 决定 ASIL，ASIL 决定安全目标的严格度，安全目标驱动功能安全概念，功能安全概念再细化为技术安全概念和系统开发要求。每一步都必须有输入、有输出、有验证、有追溯。对工程师而言，最实用的检查方法是：拿到一个安全目标，能否沿着这条链一路向下找到对应的安全机制和测试用例；反过来，任何一个安全机制，能否向上追溯到它支撑的安全目标和危害事件。能双向走通，说明功能安全体系是完整的；走不通，就说明某个环节存在缺口，需要补齐。