2、功能安全基础:IEC 61508、ISO 26262等标准中的安全生命周期、安全完整性等级(SIL/ASIL)概念

功能安全的核心思想并非“产品不出故障”,而是“当故障发生时,系统仍能维持安全状态或将风险降低到可接受水平”。IEC 61508作为通用功能安全基础标准,首次系统性地提出了安全生命周期(Safety Lifecycle)与安全完整性等级(Safety Integrity Level, SIL)的概念;而ISO 26262则是在此基础上针对道路车辆电子电气系统的行业化落地,将SIL映射为汽车安全完整性等级(ASIL)。理解这两个标准中的生命周期模型与完整性等级划分,是开展FMEDA(失效模式、影响与诊断分析)的前提——因为FMEDA的量化目标(如PMHF、SPFM、LFM)正是依据SIL/ASIL等级来设定的。本章将围绕安全生命周期的阶段划分、SIL/ASIL的确定方法及其与FMEDA的衔接关系展开。

IEC 61508 / ISO 26262 安全生命周期与完整性等级映射 IEC 61508 安全生命周期(E/E/PE) 1. 概念定义(风险分析) 2. 安全要求分配(SIL确定) 3. 系统/硬件/软件设计 4. 集成测试与验证 5. 运行、维护与退役 ISO 26262 安全生命周期(车辆) 1. 相关项定义(Item) 2. 危害分析与风险评估(HARA) 3. 功能安全概念(FSI) 4. 技术安全概念(TSI) 5. 硬件/软件级开发与验证 SIL ↔ ASIL 映射关系 SIL 1→ASIL B | SIL 2→ASIL C | SIL 3→ASIL D FMEDA 量化目标输入 PMHF / SPFM / LFM / 诊断覆盖率(DC) 安全生命周期是FMEDA分析的时间轴框架 SIL/ASIL等级决定量化指标阈值 IEC 61508 ISO 26262 映射关系 FMEDA输入

2.1 安全生命周期的核心原理与阶段划分

核心原理:安全生命周期(Safety Lifecycle)是从系统概念设计到退役的全过程管理框架,其根本目的是确保每一项安全功能在整个生命周期内都保持可验证、可追溯、可维护的完整性。IEC 61508将生命周期划分为16个阶段,从“概念”到“退役”,每个阶段都有明确的输入、输出、验证活动和评审节点。ISO 26262则针对汽车行业的特点,将生命周期划分为管理、开发、生产、运行、退役等大阶段,并细分为相关项定义、HARA、功能安全概念、技术安全概念、硬件/软件设计、集成测试、安全确认等子阶段。

判断方法:在实际项目中,判断一个组织是否真正落实了安全生命周期,可以从以下三个维度考察:

  • 阶段完整性:是否覆盖从概念到退役的全部阶段,是否存在跳过或合并关键阶段(如跳过HARA直接进行硬件设计)的情况。
  • 可追溯性:每个阶段的安全需求是否能够向上追溯到上一阶段的输出,向下追溯到下一阶段的实现与验证。
  • 验证闭环:每个阶段是否有独立的验证活动,验证结果是否反馈到设计输入中形成闭环。

案例拆解:以某汽车BMS(电池管理系统)项目为例,其安全生命周期实施如下:

生命周期阶段关键活动输出物FMEDA关联
相关项定义定义BMS边界、功能列表、运行场景Item Definition确定分析范围
HARA分析过压、过流、过温等危害事件HARA报告、ASIL等级确定量化目标
功能安全概念定义安全目标、安全状态、安全机制FSI识别安全机制
技术安全概念将FSI分配到硬件/软件架构TSI定义硬件架构
硬件设计选择MCU、AFE、隔离器件等硬件设计文档FMEDA基础数据
硬件集成测试故障注入、诊断覆盖率验证测试报告验证DC假设
经验提醒:在FMEDA分析中,安全生命周期阶段决定了分析的时间基准。例如,在概念阶段进行FMEDA时,只能基于假设的架构;而在详细设计阶段,FMEDA应基于实际的原理图和BOM。因此,FMEDA的版本必须与生命周期阶段对应,避免使用过时的分析结果支持当前的设计决策。

2.2 SIL与ASIL的确定方法及量化指标

核心原理:SIL(Safety Integrity Level)是IEC 61508中定义的安全完整性等级,分为SIL 1至SIL 4,等级越高,要求的安全完整性越高。ASIL(Automotive Safety Integrity Level)是ISO 26262中的等级,分为A、B、C、D四级,其中ASIL D要求最高。SIL/ASIL的确定基于三个参数:严重度(Severity, S)、暴露概率(Exposure, E)和可控性(Controllability, C)。在IEC 61508中,还考虑需求频率(Demand Rate)来区分低需求模式和高需求模式。

判断方法:ISO 26262中ASIL等级的确定遵循以下步骤:

  1. 识别危害事件(如车辆意外加速、电池过充)。
  2. 评估严重度S(S0无伤害、S1轻伤、S2重伤、S3致命)。
  3. 评估暴露概率E(E1极低、E2低、E3中、E4高)。
  4. 评估可控性C(C1可控制、C2一般可控、C3难以控制)。
  5. 查表确定ASIL等级(如S3+E4+C3 → ASIL D)。

案例拆解:以电动助力转向(EPS)系统为例,其ASIL确定过程如下:

危害事件SECASILFMEDA量化目标
高速行驶中转向助力突然丧失S3(可能致命)E4(每次驾驶)C3(难以控制)ASIL DPMHF ≤ 10 FIT, SPFM ≥ 99%, LFM ≥ 90%
低速泊车时转向助力丧失S1(轻伤)E3(偶尔)C1(容易控制)ASIL APMHF ≤ 100 FIT, SPFM ≥ 90%
风险说明:ASIL等级并非越高越好。过高的ASIL等级会导致硬件成本急剧上升(如需要更复杂的诊断电路、更高性能的MCU),而过低的等级则可能带来不可接受的安全风险。FMEDA分析的价值之一,就是通过量化手段验证设计是否真正达到了目标ASIL等级的要求,避免“名义ASIL D、实际ASIL B”的情况。

2.3 SIL/ASIL与FMEDA量化指标的衔接

核心原理:FMEDA(失效模式、影响与诊断分析)是连接SIL/ASIL等级与硬件设计实现的桥梁。SIL/ASIL等级定义了量化目标,而FMEDA通过分析每个硬件元器件的失效模式、失效率、诊断覆盖率,计算出系统级的PMHF(Probabilistic Metric for random Hardware Failures)、SPFM(Single-Point Fault Metric)、LFM(Latent Fault Metric),并与目标值进行对比。

操作流程:FMEDA与SIL/ASIL衔接的标准流程如下:

  1. 根据HARA确定的ASIL等级,查表获取量化目标(PMHF、SPFM、LFM)。
  2. 建立硬件架构模型,列出所有元器件及其失效模式。
  3. 为每个失效模式分配失效率(基于SN 29500、IEC 62380等标准)。
  4. 分析安全机制(诊断覆盖、冗余、监控),计算诊断覆盖率DC。
  5. 汇总计算SPFM、LFM、PMHF,与目标值对比。
  6. 若未达标,则增加诊断措施或改进架构,迭代分析。

案例拆解:某汽车安全气囊控制器(ACU)项目,目标ASIL D。FMEDA分析发现,其加速度传感器(ACC)的SPFM贡献不足,导致整体SPFM为97.5%,低于ASIL D要求的99%。分析过程如下:

  • 初始现象:SPFM不达标,主要失分项为传感器信号链。
  • 关键数据:传感器失效率λ=50 FIT,其中“信号偏移”失效模式占60%,诊断覆盖率仅80%。
  • 分析判断:现有诊断机制(自检+范围检查)无法覆盖“渐进性偏移”失效。
  • 改进措施:增加“双传感器冗余+交叉校验”机制,将DC提升至99%。
  • 结果对比:SPFM提升至99.2%,满足ASIL D要求。
  • 代价评估:增加1颗传感器,BOM成本增加约$2.5,PCB面积增加约15mm²。
  • 经验提醒:FMEDA不是一次性的计算,而是贯穿硬件设计全过程的迭代活动。在概念设计阶段,可以使用估算的失效率进行初步分析;在详细设计阶段,应使用实际选型器件的精确数据;在量产阶段,还应结合现场失效数据对FMEDA模型进行校准。

    2.4 常见误区与总结复盘

    常见误区:

    • 误区一:将SIL/ASIL等级直接等同于“可靠性指标”。实际上,SIL/ASIL关注的是“安全完整性”,即系统在发生故障时维持安全状态的能力,而非无故障运行的概率。
    • 误区二:认为ASIL D就是“所有指标都要求最高”。实际上,ASIL D对PMHF、SPFM、LFM有不同的阈值,且不同安全目标可能对应不同的ASIL等级。
    • 误区三:忽略安全生命周期中“运行与维护”阶段。FMEDA分析通常聚焦于硬件设计,但现场失效率、维修策略、软件更新都会影响实际的安全完整性。
    • 误区四:将FMEDA的DC(诊断覆盖率)假设视为“设计保证”。DC必须通过故障注入测试或仿真进行验证,否则FMEDA结果不可信。

    总结复盘:本章的核心逻辑可以概括为:安全生命周期提供了“何时做”的框架,SIL/ASIL提供了“做到什么程度”的目标,而FMEDA提供了“如何证明做到了”的方法。在实际项目中,建议按照以下步骤推进:

    1. 在概念阶段完成HARA,确定每个安全目标的ASIL等级。
    2. 在系统设计阶段,将ASIL等级分解到硬件/软件组件。
    3. 在硬件设计阶段,同步开展FMEDA分析,确保量化指标达标。
    4. 在测试阶段,通过故障注入验证FMEDA中的DC假设。
    5. 在量产阶段,持续监控现场失效数据,更新FMEDA模型。
    风险说明:FMEDA分析中常见的“过度乐观”陷阱包括:使用理想化的失效率数据、高估诊断覆盖率、忽略共因失效(CCF)、未考虑安全机制本身的失效。这些都会导致分析结果偏离实际,最终在安全评审或事故调查中被质疑。建议在FMEDA报告中明确列出所有假设条件及其依据,并保留原始计算过程以备审查。