ISO26262功能安全——安全测试

- [验证 vs. 确认：你造对了东西，还是造了不对的东西？](#验证 vs. 确认：你造对了东西，还是造了不对的东西？)
- 故障注入测试（FIT）：有计划地"搞破坏"
- - [1. 硬件故障注入](#1. 硬件故障注入)
  - [2. 软件故障注入](#2. 软件故障注入)
  - [3. 总线故障注入](#3. 总线故障注入)
- 基于故障注入的覆盖率：诊断覆盖率怎么来的？
- HIL与轨基测试：让虚拟车辆"犯错误"
- 软件测试的"覆盖率炼狱"：MC/DC
- [故障注入与覆盖率的闭环：安全案例（Safety Case）](#故障注入与覆盖率的闭环：安全案例（Safety Case）)
- 结语：炼狱不是折磨，是最后的尊严

前面八讲，我们从全知视角搭起了一座功能安全的摩天大楼：HARA定了安全目标，系统架构画了冗余与监控，硬件FMEDA算了失效率，软件实现了程序流与E2E，SafeOS管住了任务逃逸，连自动驾驶的Fail‑Operational都布置好了。图纸美轮美奂，代码行云流水------然后呢？
你怎么证明这栋大楼真的不会塌？

在功能安全领域，这个"证明"不是靠拍胸脯，也不是靠开一个月路试没问题。它需要一套近乎变态的、有组织有预谋的、专门针对"搞坏系统"的测试体系。这就是安全测试的炼狱。

验证 vs. 确认：你造对了东西，还是造了不对的东西？

ISO 26262将"证明安全"分为两个动作：

验证（Verification） ：我们是否正确地实现了需求？------检查设计、代码走查、单元测试、集成测试......回答"有没有跑偏"。
确认（Validation） ：我们是否实现了正确的需求？------整车级别的安全确认、在真实或模拟场景中检查安全目标是否真的被满足。回答"有没有漏掉真正的危险"。

打个比方：你要造一把不会走火的枪。验证是检查扳机弹簧符合图纸、保险机构能正常卡住；确认是把枪装满了实弹，在不同姿态下摔、砸、淋雨，看看它会不会意外击发。

在安全测试中，验证决定了你能不能拿到TÜV的报告，确认决定了会不会有人死在车里。

故障注入测试（FIT）：有计划地"搞破坏"

在所有安全测试手段中，最核心、最能体现功能安全特色的当属故障注入测试（Fault Injection Testing, FIT） 。它的逻辑很简单：主动制造故障，观察系统的反应是否符合预期。

FIT可以按层级分为三类：

1. 硬件故障注入

直接在硬件上制造物理故障，检查安全机制是否探测到并正确响应。方法包括：

引脚短路/开路：用继电或手动短路MCU两个引脚、断开CAN收发器的电源。
电压扰动：用电源扰动器在供电线上叠加纹波或瞬时跌落，看电压监控芯片能否触发复位。
辐射/激光（高精尖）：用聚焦离子束或激光照射芯片特定区域，模拟单粒子翻转。这项成本极高，一般只用于安全MCU的认证测试。

实战中，多数项目采用故障注入板卡（如dSPACE的Failure Insertion Unit）自动化执行。例如，在制动控制器的电源输入上注入一个100ms的电压跌落到4V（12V系统），检查：欠压检测是否在1ms内触发？MCU是否进入安全状态？故障码是否被记录？

2. 软件故障注入

不碰硬件，而是通过调试接口或插桩代码，篡改软件运行时的数据。常见方式：

内存数据篡改 ：在某个安全关键变量（如brake_pressure_target）被使用前，强行改为异常值。
程序计数器跳转：强制跳过安全检查函数，或直接跳转到非法地址。
堆栈溢出：不断往栈里压数据直到溢出，检查MPU或栈监控能否捕获。

例如，在EPS应用中注入一个故障：让转角传感器读取值从0x1000突变为0xE000。观察E2E校验是否立即该帧丢弃？安全岛是否切换至备用传感器？

3. 总线故障注入

通过CANoe、Vehicle Spy等工具直接往总线上发送异常帧：

位翻转：将目标信号帧中的一位取反，重新计算CRC（攻击E2E）。
丢帧/延迟：在网关上人为丢弃某几帧安全关键消息，或将其延迟200ms。
帧欺骗：以一个不存在的源地址发送高优先级的安全消息，测试接收端能否识别身份非法。

总线故障注入也用于验证E2E保护和网络安全机制（SecOC）的有效性。

基于故障注入的覆盖率：诊断覆盖率怎么来的？

还记得第4讲硬件FMEDA中的诊断覆盖率（Diagnostic Coverage, DC） 吗？那个百分比不是拍脑袋的，正是通过故障注入测试定量评估出来的。

对于硬件安全机制（如看门狗、电压监控、ECC），ISO 26262-5附录D给出了三类覆盖率经验值：

低（60%） ：简单的通用机制
中（90%） ：针对性较强的机制
高（99%） ：高诊断覆盖率

但要申报某个具体设计达到"中"或"高"，必须通过故障注入实验来证明。例如，针对MCU内部寄存器的单粒子翻转，你注入1000次随机位翻转，检查锁步核或ECC能否探测到------探测到980次，DC=98%，达标中覆盖。

安全测试的残酷就在这里：你必须设计成千上万个故障注入用例，每一个用例都必须有明确的预期结果；但凡有一个用例系统反应不符合预期，就要打回设计整改。

HIL与轨基测试：让虚拟车辆"犯错误"

故障注入大多针对单一部件；系统级验证需要把ECU放在硬件在环（HIL, Hardware-in-the-Loop） 台架上，连接真实的执行器（或负载模拟器）和总线，运行整车模型。

HIL测试的功能安全专项包括：

残余故障的随机注入：在一个长场景（如高速公路变道）中随机注入硬件故障，观察系统是否最终进入安全状态且不发生碰撞。通常跑数万次回归。
最坏情况时序测试：人为在总线上注入高负载（例如CAN总线占用率达到100%、以太网风暴），看安全关键消息的延迟是否仍在FTTI之内。
故障叠加测试：先注入一个故障（例如主电源跌落），系统进入降级模式后，再注入第二个故障（例如备用传感器失效），检查系统是否仍能完成最小风险机动（Fail‑Operational要求）。

等你把这些都跑通了，才可以进入轨基测试（Proving Ground） ------在试车场上用真实车辆做同样的故障注入。例如，通过信号发生器强行给制动控制器一个错误的目标压力，看AEB会不会误触发；或者人为断开EPS的扭矩传感器一路信号，看方向盘助力是否平滑过渡到备选传感器。

软件测试的"覆盖率炼狱"：MC/DC

对于软件，除了故障注入，还有一个硬性指标：代码覆盖率。ISO 26262-6根据ASIL等级，要求不同层级的覆盖率：

覆盖率层级	ASIL A	ASIL B	ASIL C	ASIL D
语句覆盖	推荐	推荐	强制	强制
分支覆盖	推荐	强制	强制	强制
MC/DC	---	---	推荐	强制

MC/DC（修正条件/判定覆盖） 是最严苛的覆盖率指标。它要求：对于每个布尔判定（如if( A && B || C )），每个条件（A、B、C）必须独立地展示其能够独立影响判定的结果。

举个例子：判定 (A && B) || C 。要达到MC/DC，你需要设计测试用例，使得：

A 从真变假而 B、C 不变时，判定结果改变；
B 从真变假而 A、C 不变时，判定结果改变；
C 从假变真而 A、B 不变时，判定结果改变。

这意味着，即使你的代码覆盖了所有分支和语句，仍可能遗漏某些条件组合的耦合效应。MC/DC专门用来捕捉这种"隐藏的假阴性"。为达到ASIL D要求的100% MC/DC，安全软件的单元测试用例数量往往是普通代码的5-10倍。

故障注入与覆盖率的闭环：安全案例（Safety Case）

所有测试做完后，你需要将所有证据组织成一个安全案例（Safety Case）------一份面向审核员的说理文档，证明"系统在定义的运行条件下是安全的"。

安全案例通常采用目标结构符号（GSN, Goal Structuring Notation），自上而下地展开：

顶层目标：系统不会发生因功能安全导致的不可接受风险。
下层论证：通过HARA确定了所有危害，并为每个危害分配了ASIL等级和安全目标。
证据层：安全目标被分解为功能安全需求，每条需求都对应了设计、实现、验证的证据（测试报告、代码审查记录、故障注入日志等）。
关联：用追溯矩阵显示每条安全需求→测试用例→测试结果之间的闭环。

审核员会逐条检查：你说的"诊断覆盖率99%"有没有对应的故障注入报告证明？说的"MC/DC 100%"有没有工具生成的报告？如果没有，对不起，退回重做。

结语：炼狱不是折磨，是最后的尊严

安全测试之所以被称为"炼狱"，是因为它极尽枯燥、繁琐、不近人情。一个简单的应用层逻辑，为了达到MC/DC，可能要写上百个单元测试；一个ASIL D的系统，故障注入用例往往以万为单位。

但正是这种"变态"，给了我们最后的安心：当数百万行代码的自动驾驶汽车以120km/h行驶在高速上时，我们敢打包票说，在单一故障下，它依然不会杀人。

下一篇预告：所有技术都讲完了，最后一篇我们将回首来路，从方法论的高度总结功能安全的实践哲学，并给出给工程师与管理者的实用建议。第10篇《安全档案与终极突围 ------ 安全案例与ASIL分解》------如何用ASIL分解降成本？安全文化如何落地？敬请期待。

思考题：在你的EPS转向项目中，软件中的一个安全关键判定是 if( sensorA_valid && (sensorB_valid || backup_valid) )。请设计最少几个测试用例，使得该判定的MC/DC覆盖率达到100%？列出每个用例中各条件的取值。