📚 课程目录第2章功能安全基础

2. 功能安全基础

在AUTOSAR功能安全测试工程中，测试人员并不是从“写用例”开始，而是从理解ISO 26262的安全语言开始。只有把术语、等级、生命周期、安全目标与安全需求之间的关系梳理清楚，才能判断一条测试用例究竟在验证什么、覆盖到哪一层、是否足以支撑安全论证。本节围绕这五个核心概念展开，并给出它们在测试工作中的落地方式。

一、核心术语：从“危害”到“安全状态”

ISO 26262的术语体系是层层递进的。最上游是危害（Hazard），指可能造成伤害的潜在来源；危害在具体运行场景下被触发，形成危害事件（Hazardous Event）。对危害事件进行风险评估，得到ASIL等级。为把风险降到可接受水平，需要定义安全目标（Safety Goal），再逐层分解为功能安全需求（FSR）和技术安全需求（TSR）。当故障发生时，系统应进入安全状态（Safe State），例如降级输出、切断驱动或进入跛行模式。

测试人员需要特别关注两个术语：故障（Fault）、错误（Error）与失效（Failure）的因果链。故障是原因，错误是中间状态，失效是最终表现。功能安全测试的本质，就是在故障注入后观察系统是否产生错误、是否最终失效，以及是否按预期进入安全状态。

测试视角的术语映射：危害事件 → 测试场景；安全目标 → 测试目标；FSR/TSR → 测试需求；安全状态 → 预期结果；ASIL → 测试严格度与覆盖要求。

二、ASIL等级：风险决定测试强度

ASIL由三个参数共同决定：严重度（S）、暴露率（E）和可控性（C）。S评估伤害程度，E评估运行场景出现的概率，C评估驾驶员或其他人员能否及时控制。三者组合后映射为QM、ASIL A、B、C、D五个等级，D为最高。等级越高，对需求追溯、验证方法、故障覆盖和独立评审的要求越严格。

等级	典型风险特征	测试策略侧重
QM	常规质量管理即可	常规功能测试，无需专门安全论证
ASIL A	低严重度、低暴露、易控制	基本故障检测与需求覆盖
ASIL B	中等风险	增加边界、异常与故障注入测试
ASIL C	较高风险	强化故障注入、时序与冗余验证
ASIL D	高严重度、高暴露、难控制	最严格覆盖、独立验证与安全论证

需要强调的是，ASIL等级不是对“代码质量”的评级，而是对“风险降低需求”的评级。同一个ECU中不同功能可以有不同ASIL，测试计划必须按功能而非按项目统一处理。

三、安全生命周期：测试贯穿始终

ISO 26262的安全生命周期从概念阶段开始，经过系统开发、硬件开发、软件开发、生产运行，直到报废。测试活动并非只在“验证阶段”出现，而是分布在多个阶段：概念阶段确认安全目标可测试；系统阶段验证TSR；软件阶段验证单元与集成；运行阶段进行确认措施与现场监控。

图中下半部分展示了安全目标、FSR与TSR的分解关系。测试用例通常直接对应TSR，但测试报告必须能够向上追溯到FSR和安全目标，否则无法证明“测试覆盖了安全需求”。

四、安全目标与安全需求：测试用例的源头

安全目标描述的是“避免什么”，例如“避免车辆在行驶中非预期加速”。它不描述实现方式，只描述必须维持的安全状态。FSR把安全目标转化为功能行为，例如“当监测到扭矩请求异常时，应在100ms内切断动力输出”。TSR进一步落到技术细节，例如“监控模块应以10ms周期校验扭矩请求的合理性，并在连续3次校验失败后触发安全状态”。

在AUTOSAR项目中，TSR往往映射到具体的软件组件、Runnable、端口和诊断事件。测试人员应建立如下追溯链：

安全目标 SG-001：避免非预期加速（ASIL D）
  └─ FSR-001：异常扭矩请求时进入安全状态
       └─ TSR-001：监控模块10ms周期校验，3次失败触发
            ├─ SWC: TorqueMonitor
            ├─ Runnable: CheckTorqueRequest
            ├─ Port: TorqueRequest_In
            └─ 测试用例: TC-TSR-001-01 ~ 05

这条链是功能安全测试的“骨架”。如果测试用例只写了“验证扭矩监控功能”，却没有关联TSR编号和ASIL等级，就无法在安全评估中证明其充分性。

五、案例与常见误区

某制动控制项目在概念阶段将“避免制动失效”定为ASIL D安全目标，但测试团队只按常规功能测试执行，未进行故障注入，也未验证安全状态切换时间。审核时发现：TSR中要求的“双通道交叉校验”没有对应测试用例，安全目标无法追溯。复盘后，团队补充了故障注入用例，并建立了需求-用例-结果的双向追溯矩阵。

常见误区：把ASIL等级当作“代码复杂度”或“测试用例数量”的指标；只测正常功能，不测安全状态；安全目标与测试用例之间缺少追溯；把QM功能与ASIL功能混在同一测试计划中，导致严格度不足或过度测试。

实操建议：在测试计划中为每条TSR标注ASIL等级、安全状态、故障注入方法和通过准则；使用需求管理工具维护追溯矩阵；对ASIL C/D功能，优先设计故障注入、边界时序和冗余切换测试。

掌握这些基础概念后，后续的AUTOSAR安全机制测试、故障注入方法和安全论证，才有统一的语言和判断标准。测试人员应始终记住：功能安全测试不是“多测几个用例”，而是用可追溯的证据证明安全目标在故障条件下仍然成立。