Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-5:2018 — 汽车功能安全硬件级产品开发
硬件设计、架构度量（SPFM/LFM）、PMHF评估与安全机制实现
ISO 26262-5:2018 硬件开发概述
ISO 26262-5:2018定义了汽车功能安全生命周期中硬件级产品开发的要求。该标准是抽象安全需求与物理实现的交汇点——规定了微控制器、传感器、执行器、ASIC、FPGA和电源等硬件组件如何设计、分析和验证以达到所需的汽车安全完整性等级（ASIL）。
硬件开发在功能安全中与软件开发的不同之处在于需要定量评估。ISO 26262-5引入了严格的数学度量来评估硬件架构检测和控制随机硬件故障的能力，使其成为整个标准系列中技术要求最高的部分之一。
对于刚接触功能安全的硬件工程师：需要理解的两个最重要度量是SPFM（单点故障度量）和LFM（潜在故障度量）。它们量化了您的硬件设计对危险故障的保护能力。
硬件安全需求与设计流程
第6章涉及硬件安全需求的规格说明，这些需求源自技术安全概念和系统架构设计。硬件安全需求必须指定以下属性：
- 每个硬件元件的诊断覆盖率和故障检测延迟
- 安全状态定义和故障反应时间
- 硬件特定约束（温度范围、电压容差、EMC抗扰度）
- 从HSI规格说明继承的需求
第7章涵盖硬件设计，分为两个子阶段：
- 硬件架构设计——定义高层硬件结构，划分为元件，并分配安全需求
- 硬件详细设计——详细规定每个硬件元件，包括原理图、物料清单和设计理由
设计过程必须包括硬件级安全分析（FMEA、FTA、DFA），以识别故障模式、其原因和影响，并定义适当的安全机制。
为ASIL C或D设计硬件时，通常需要冗余安全机制。例如，双核锁步CPU配独立看门狗监视器既提供故障检测（通过锁步比较）又提供故障反应（通过看门狗超时）。
硬件架构度量：SPFM与LFM
第8章规定使用两个关键定量指标进行硬件架构度量评估：
| 度量 | 全称 | 衡量内容 | ASIL B目标 | ASIL C目标 | ASIL D目标 |
|---|---|---|---|---|---|
| SPFM | 单点故障度量 | 对直接违反安全目标且未被检测到的故障的覆盖率 | ≥90% | ≥97% | ≥99% |
| LFM | 潜在故障度量 | 对与另一个独立故障组合时违反安全目标的未被检测故障的覆盖率 | ≥60% | ≥80% | ≥90% |
这些度量通过分析每个硬件元件、分类其故障模式（安全、检测到的单点、检测到的潜在等）并汇总所有元件的诊断覆盖率来计算。计算遵循标准附录C中的公式。
常见陷阱：仅通过分析达到SPFM/LFM目标是不够的。每个安全声明的诊断覆盖率必须得到证明——要么通过使用行业认可的失效率数据（如IEC TR 62380或SN 29500）进行定量FMEDA（故障模式、影响和诊断分析），要么通过现场数据或测试支持的定性论证。
PMHF评估与安全目标违反
第9章涉及随机硬件故障导致安全目标违反的评估，提供两种可选方法：
- 随机硬件故障概率度量（PMHF）——一种全局定量方法，计算车辆生命周期内（通常10-15年）违反安全目标的平均概率。ASIL D的目标是每小时内低于10-8次故障。
- 每个原因评估（EEC）——一种割集分析方法，检查每个可能违反安全目标的已识别故障或故障组合，并确保每个原因的残余风险可接受地低。
PMHF计算必须考虑：
- 所有硬件元件的故障率（来自行业可靠性数据的λ值）
- 每个安全机制的诊断覆盖率
- 潜在故障的暴露时间（通常为驾驶/诊断间隔）
- 故障处理时间和安全状态转换
PMHF预算分配是一项关键的设计活动。如果您提前了解硬件架构，请创建PMHF预算表，为每个子系统分配故障率目标。这可以防止在累积PMHF超过ASIL D目标时需要昂贵的重新设计而带来的后期意外。
硬件集成与验证
第10章要求采用结构化的硬件集成与验证方法，确保实现的硬件满足硬件安全需求。关键验证活动包括：
- 硬件集成测试（测试硬件元件之间的交互）
- 硬件验证测试（对照实现的设计测试每个需求）
- 环境测试（温度、振动、湿度、EMC）
- 故障注入测试（验证诊断覆盖率和故障反应）
验证深度取决于ASIL——更高的ASIL需要更严格的测试方法、更广泛的测试覆盖范围和更全面的文档。
常见问题解答
问：SPFM和LFM有什么区别？
答：SPFM处理单点故障——直接导致安全目标违反而无需第二个故障。LFM处理潜在故障——未被检测到且在与第二个独立故障结合时导致安全目标违反。例如，制动传感器中直接触发意外制动的卡滞零故障是单点故障，而阻止检测传感器故障的诊断电路中的故障是潜在故障。
答：SPFM处理单点故障——直接导致安全目标违反而无需第二个故障。LFM处理潜在故障——未被检测到且在与第二个独立故障结合时导致安全目标违反。例如，制动传感器中直接触发意外制动的卡滞零故障是单点故障，而阻止检测传感器故障的诊断电路中的故障是潜在故障。
问：如何获取硬件元件的故障率数据？
答：标准不强制要求特定的数据来源。常用的可靠性数据标准包括西门子SN 29500、IEC TR 62380 / IEC 61709和MIL-HDBK-217。对于半导体器件，可以使用供应商提供的数据或ISO 26262-11关于半导体故障模式的指南。关键要求是数据来源必须合理且一致应用。
答：标准不强制要求特定的数据来源。常用的可靠性数据标准包括西门子SN 29500、IEC TR 62380 / IEC 61709和MIL-HDBK-217。对于半导体器件，可以使用供应商提供的数据或ISO 26262-11关于半导体故障模式的指南。关键要求是数据来源必须合理且一致应用。
问：可以使用基于软件的诊断来改善硬件度量吗？
答：可以。基于软件的诊断（例如CPU自检、RAM测试库、通信校验和）可以贡献诊断覆盖率。硬件-软件接口（HSI）规格说明必须记录哪些诊断在软件中实现及其假设的覆盖率。但是，诊断测试间隔和故障反应时间仍必须满足硬件安全需求。
答：可以。基于软件的诊断（例如CPU自检、RAM测试库、通信校验和）可以贡献诊断覆盖率。硬件-软件接口（HSI）规格说明必须记录哪些诊断在软件中实现及其假设的覆盖率。但是，诊断测试间隔和故障反应时间仍必须满足硬件安全需求。
问：什么是FMEDA，它与ISO 26262-5有何关系？
答：FMEDA（故障模式、影响和诊断分析）是用于计算标准要求的SPFM、LFM和PMHF值的主要分析方法。FMEDA通过整合定量故障率数据和诊断覆盖率因素来扩展传统FMEA，以产生数值指标。大多数硬件功能安全认证工作都严重依赖FMEDA结果。
答：FMEDA（故障模式、影响和诊断分析）是用于计算标准要求的SPFM、LFM和PMHF值的主要分析方法。FMEDA通过整合定量故障率数据和诊断覆盖率因素来扩展传统FMEA，以产生数值指标。大多数硬件功能安全认证工作都严重依赖FMEDA结果。
