2、功能安全基础：ISO 26262/IEC 61508中的安全生命周期、ASIL/SIL等级、安全目标与安全要求
功能安全并非一个抽象的质量口号，而是一套以“风险降低”为核心的工程方法论。无论是汽车电子领域的ISO 26262，还是涵盖工业、核电、医疗等更广泛领域的IEC 61508，其底层逻辑都是：识别系统可能导致的危害，评估风险等级，并通过系统化的开发流程与技术措施，将风险降低到可接受的水平。对于硬件工程师而言，理解安全生命周期、ASIL/SIL等级、安全目标与安全要求之间的递进关系，是开展FMEDA（故障模式、影响与诊断分析）的前提。如果脱离了安全目标和ASIL等级去谈失效率计算，FMEDA将失去评价基准，变成一堆无意义的数字。
上图展示了从标准框架到硬件FMEDA落地的核心映射关系。安全生命周期定义了“何时做”，ASIL/SIL定义了“做到多严”，安全目标定义了“做什么”，而硬件安全要求则是将上述抽象概念转化为可验证的硬件指标（如SPFM、LFM、PMHF）。下面我们逐一展开。
2.1 安全生命周期：从概念到运行的工程框架
核心原理：安全生命周期（Safety Lifecycle）是功能安全标准的骨架，它规定了从项目定义、危害分析、安全要求制定，到设计实现、验证确认、生产运行直至报废的全过程活动。ISO 26262将生命周期划分为概念阶段、产品开发阶段（系统、硬件、软件）以及生产运行阶段。IEC 61508则更通用，强调从整体安全生命周期（Overall SLC）到E/E/PE系统安全生命周期的层级分解。
判断方法/操作流程：在硬件开发中，我们最关注的是“硬件级开发”阶段。该阶段的核心输入是技术安全要求（TSR），输出则是硬件安全要求（HSR）。HSR必须包含：功能行为（该硬件在正常和故障模式下应如何表现）、ASIL等级属性（每个硬件安全要求都继承一个ASIL等级）、故障容错时间间隔（FTTI）、安全状态定义（例如，切断电源、输出固定电平）等。硬件工程师需要依据HSR进行硬件设计，并开展FMEDA来验证硬件架构是否满足量化指标。
| 生命周期阶段 | 关键活动 | 硬件工程师的主要交付物 |
|---|---|---|
| 概念阶段 | 相关项定义、HARA（危害分析与风险评估） | 提供硬件技术可行性输入、初步的架构约束 |
| 系统级开发 | 系统安全要求、系统设计 | 硬件-软件接口（HSI）定义、硬件模块划分 |
| 硬件级开发 | 硬件安全要求规范、硬件设计、FMEDA、硬件集成测试 | 硬件安全要求规格书、原理图、PCB、FMEDA报告、DFMEA |
| 生产与运行 | 生产计划、运行维护 | 硬件生产测试规范、现场故障反馈分析 |
2.2 ASIL与SIL等级：风险量化的尺度
核心原理：ASIL（汽车安全完整性等级）和SIL（安全完整性等级）是衡量安全要求严格程度的尺度。ISO 26262根据严重度（Severity）、暴露概率（Exposure）和可控性（Controllability）三个参数，将ASIL划分为A、B、C、D四个等级，其中D为最高等级。IEC 61508则根据风险频率和后果严重度，将SIL划分为1-4四个等级。等级越高，要求越严格，对硬件失效率的要求也越低。
判断方法/操作流程：对于硬件工程师而言，ASIL等级直接决定了硬件架构的冗余度、诊断覆盖率的要求以及失效率的预算。例如，ASIL D要求单点故障指标（SPFM）≥99%，潜在故障指标（LFM）≥90%，随机硬件失效率（PMHF）<10 FIT（1 FIT = 1次失效/10^9小时）。而ASIL B则要求SPFM≥90%，LFM≥60%，PMHF<100 FIT。这些量化指标是FMEDA计算的“及格线”。
2.3 安全目标与安全要求：从“做什么”到“怎么做”
核心原理：安全目标（Safety Goal）是顶层安全要求，它描述了“为了避免不合理的风险，系统必须做什么”。安全目标通常以“避免……发生”的句式表述，并带有ASIL等级和FTTI属性。安全要求则是对安全目标的细化和分解，分为功能安全要求（FSR）和技术安全要求（TSR）。硬件安全要求（HSR）是TSR在硬件层面的具体化。
判断方法/操作流程：在FMEDA中，我们首先需要明确每个硬件安全要求对应的安全目标。例如，对于“避免非预期加速”这一安全目标，其对应的硬件安全要求可能包括“加速踏板位置传感器信号必须冗余”、“信号处理电路必须能检测到传感器电源短路”等。FMEDA分析时，我们需要针对每个硬件安全要求，分析其硬件组成、故障模式、故障率、诊断机制和诊断覆盖率，最终计算出该安全要求是否满足其ASIL等级对应的量化指标。
2.4 案例拆解：安全目标如何驱动硬件FMEDA指标分配
案例背景：某新能源汽车的电池管理系统（BMS）需要满足ISO 26262 ASIL C等级。安全目标定义为“避免电池过充导致的热失控”。该安全目标具有以下属性：ASIL C，FTTI为100ms，安全状态为“断开高压接触器并禁止充电”。
关键输入数据：硬件架构采用“主控MCU + 独立监测IC”的双通道设计。主控MCU负责充电策略控制，独立监测IC负责监测单体电池电压。两个通道通过SPI通信。
分析判断过程：
- 分解安全要求：针对“避免过充”这一安全目标，分解出两个硬件安全要求：HSR-1（主控MCU必须在100ms内检测到过充电压并发出断开信号）；HSR-2（独立监测IC必须在100ms内检测到过充电压并直接驱动断开电路，不依赖MCU）。
- FMEDA分析：对HSR-1，分析MCU的ADC采样电路、电压比较器、SPI通信等模块。假设MCU的ADC采样电路失效率为50 FIT，诊断覆盖率（通过自检实现）为90%。则残余失效率为50 * (1-0.9) = 5 FIT。对HSR-2，分析独立监测IC的电压检测电路和驱动电路。假设其失效率为30 FIT，诊断覆盖率为99%（通过内部冗余比较器实现），则残余失效率为0.3 FIT。
- 指标计算：整个安全目标的残余失效率为5 + 0.3 = 5.3 FIT。该值远小于ASIL C要求的PMHF<100 FIT，满足要求。同时，SPFM计算需考虑所有单点故障，此处简化处理。
结果对比与复盘：通过FMEDA分析，我们发现MCU通道的残余失效率占主导。为了进一步降低风险，我们增加了MCU的ADC自检频率，将诊断覆盖率从90%提升至95%，使得残余失效率降至2.5 FIT。这一改动虽然增加了软件开销，但显著提升了整体安全性。复盘经验：FMEDA不是一次性的计算，而是指导硬件设计迭代的工具。当某个模块的残余失效率过高时，应优先考虑增加诊断机制，而非盲目增加冗余硬件。
2.5 常见误区与总结复盘
- 误区一：将ASIL等级与失效率直接划等号。ASIL等级是综合了严重度、暴露率和可控性的风险等级，而失效率是硬件本身的物理属性。ASIL等级决定了失效率的“目标值”，但失效率是否达标还取决于诊断覆盖率。
- 误区二：忽略安全状态和FTTI的定义。没有安全状态，FMEDA无法计算“故障发生后进入安全状态”的概率；没有FTTI，无法判断诊断机制是否足够快。
- 误区三：认为FMEDA只是硬件工程师的事。FMEDA的输入（安全目标、安全要求）来自系统工程师，输出（失效率、诊断覆盖率）又会影响软件诊断策略的设计。跨部门协作至关重要。
- 误区四：混淆SPFM与LFM。SPFM针对单点故障和残余故障，LFM针对潜在故障（即未被发现的潜伏故障）。两者计算方法和目标值均不同，需分别计算。