ISO 26262道路车辆功能安全标准深度解析：硬件开发（Part 5）合规指南

ROADVEHICLES·FUNCTIONALSAFETY·ISO26262-5道路车辆功能安全标准深度解析ISO26262硬件开发（Part5）从硬件安全需求到指标评估与测试验证——功能安全硬件开发的完整闭环ISO26262系列标准·第二版（2018）·汽车电子功能安全CONTENTS目录：沿硬件开发五阶段展开01ISO26262与硬件开发概览标准定位·ASIL·Part5角色·定量评估机制02硬件安全需求规范需求分解·HSI接口·五类属性要点03硬件设计架构设计·详细设计·稳健原则04安全分析与故障单点/残留/多点·FMEA·FTA05指标评估与测试验证SPFM·LFM·PMHF·测试闭环02CHAPTERONE01第一章ISO26262与硬件开发概览标准定位·ASIL等级·Part5角色·定量评估机制第一章·标准定位ISO26262：面向道路车辆E/E系统的功能安全国际标准标准定位ISO26262是面向道路车辆电气/电子（E/E）系统的功能安全标准，起源于IEC61508的汽车行业适配。它以风险导向方法确定安全完整性等级（ASIL），并据此规定各项安全活动的严苛程度，目标是把残余风险控制在合理可接受的范围。覆盖功能安全管理、设计、实现、验证、确认与发布活动，以及客户与供应商的协作关系。版本沿革2011第一版确立ASIL分级与安全生命周期框架。2018第二版扩展至12部分，新增半导体、摩托车等。判断：ISO26262把"安全"从经验判断升级为可分级、可追溯、可验证的工程体系——每一档ASIL都对应明确的方法要求与定量指标。来源：ISO26262-1:2018标准公开摘要（）04第一章·ASILASIL安全完整性等级：由HARA风险分析导出，决定开发严苛度HARA三参数危害分析与风险评估（HARA）通过三个参数确定每个危险事件的ASIL：S（Severity）严重度·E（Exposure）暴露率·C（Controllability）可控性三参数组合映射到QM至ASILD五个档位。五档等级QM仅质量管理要求；ASILA最低安全等级；ASILB/C中等等级；ASILD最高等级，要求最严苛，例如自动紧急制动系统。与硬件的关系：本讲硬件开发安全分析（单点/残留/多点故障）适用于ASIL（B）、C、D——高安全等级下，硬件故障的定量证据成为强制要求。来源：ISO26262-1:2018公开摘要；HARA与ASIL分级（iso26262.academy）05第一章·Part5角色ISO26262-5：硬件级产品开发在安全生命周期中的枢纽地位概念阶段危害分析功能安全概念安全目标系统层面技术安全概念软硬件接口系统集成验证硬件层面（Part5）硬件安全需求·硬件设计安全分析·指标评估·测试定位：硬件开发上承技术安全概念，下接软件与系统集成，是安全目标在物理层真正落地的关键环节。Part5一方面承接系统层面的技术安全需求，另一方面为整机失效率指标（如PMHF）提供硬件侧的全部支撑数据。与软件协调：硬件安全需求需明确软硬件接口（HSI），并在开发全程与软件子阶段保持同步。06第一章·硬件层面活动硬件层面三大必要活动：实现、分析、协调缺一不可1技术安全概念的硬件实现把系统层面的技术安全概念翻译为具体的硬件安全需求、架构与电路实现，是硬件开发的第一步。2潜在硬件故障及影响分析通过安全分析识别单点、残留、多点等故障模式及其对安全目标的影响，为设计改进提供依据。3与软件开发的协调硬件与软件通过软硬件接口（HSI）协同开发：安全机制的触发、诊断覆盖、容错时间间隔等参数必须在两侧保持一致，任一方的偏差都会破坏整体安全论证。三项活动共同构成硬件开发的完整输入面，任何一项缺失都会导致安全论证链条断裂。07第一章·定量评估机制第8、9条：用定量指标回答"硬件够不够安全"第8条·硬件架构指标通过两个指标评估硬件架构与安全机制的有效性，面向随机硬件故障：·单点故障度量SPFM·潜伏故障度量LFM这两个指标量化"安全机制覆盖了多少故障"。第9条·残余风险评估作为第8条的补充，评估违反安全目标行为的残余风险是否足够低：·全局性概率方法（整体量化）·割集分析（逐元件故障影响）对应随机硬件失效概率度量PMHF。机制：第8、9条共同构成硬件定量评估的"双保险"——先用架构指标看覆盖，再用失效概率看残余。评估结论以失效率数据、指标计算与安全分析报告的形式留痕。来源：ISO26262-5:2018第8、9条（硬件架构指标与残余风险评估）08CHAPTERTWO02第二章硬件安全需求规范需求分解·HSI软硬件接口·五类属性要点第二章·需求来源硬件安全需求：从系统技术安全需求分解而来，并承载HSI接口系统技术安全需求（功能级）硬件安全需求（实现级）硬件架构/电路实现（最低层/最小模块）分解关联：硬件安全需求应从系统技术安全需求分解关联而来，并详细描述软硬件接口规范（HSI）。可追溯性：硬件安全要求与实现之间的可追溯性应保存到硬件单元的最低层或最小功能模块——这是ISO26262与ASPICE流程共同强调的底层逻辑。每条硬件安全需求都应能追溯到系统层需求与安全目标，反向亦然，形成双向可追溯链。HSI的作用：软硬件接口规范是硬件与软件协同开发的中枢——安全机制由谁触发、诊断信号如何传递、接口时序如何约束，都通过HSI固化下来，避免两侧理解偏差。10第二章·需求要点1-2需求属性（一）：控制内部失效，同时承受外部失效1控制硬件单元的内部失效硬件安全需求及相关安全机制的属性应能控制硬件单元的内部失效，包括内部安全机制覆盖瞬态故障的能力。相关属性可以包括定时器与看门狗检测——用于捕捉程序跑飞、时钟异常等内部故障。2承受外部单元的失效硬件安全需求及相关安全机制的属性应能承受外部单元的失效。典型场景：ECU外部失效时，对ECU输入的开路（如KL30断路/短路）不导致安全目标被违反。这要求硬件对外部电气异常具备检测或容忍能力。内部失效靠机制覆盖，外部失效靠承受能力——两条属性分别对应不同的失效来源与防护策略。11第二章·需求要点3-5需求属性（二）：匹配、检测指示与验证标准边界3匹配其他单元的安全需求硬件单元与其他单元协同工作时，安全属性需相互匹配，避免一方安全机制被另一方破坏。4检测和指示内部与外部故障应具备故障检测与指示能力，例如pin开路、短地、短电源等，便于及时进入安全状态或提示驾驶员。5不指定设计验证标准（边界）硬件安全需求不规定安全机制产品硬件的设计验证标准，但需明确环境条件（温度、振动、电磁干扰）、操作环境（电源电压、任务历程）与特定组件要求。判断：五类属性共同界定了硬件安全需求的"边界"——既要覆盖内部与外部故障、协同与检测，又要明确"不做什么"（验证标准另立），保证需求清晰、可测、可追溯。12第二章·分解链从安全目标到硬件需求：一条完整的需求分解链安全目标（ASIL绑定）功能安全需求（系统层）技术安全需求（含HSI）硬件安全需求（Part5承接）软件安全需求（Part6）（与硬件并行）分解原则：需求逐级细化、属性逐步落地；硬件与软件需求在HSI处汇合，确保安全机制两侧一致。追溯要求：每一条硬件需求都能向上追溯到技术安全需求与安全目标，向下追溯到具体硬件单元实现，形成贯穿全生命周期的双向追溯链。需求分解的完整性直接影响后续安全分析、指标计算与测试验证的可信度。13CHAPTERTHREE03第三章硬件设计架构设计·详细设计·稳健原则·非功能要求第三章·两阶段硬件设计的两阶段：架构定结构，详细定实现硬件架构设计（表示所有硬件单元及彼此关系）硬件详细设计（电路原理图上的具体实现）架构设计：应实现硬件的安全要求，每个硬件单元应根据硬件安全要求实现最高的ASIL；表示出所有硬件单元及彼此间的关系，为安全分析提供结构基础。详细设计：指在电路原理图上的设计，关注具体器件选型、参数、连接与保护电路，是架构要求落实到物理实现的一步。衔接：架构设计为详细设计划定边界，详细设计反哺架构验证——两者互为输入输出，共同支撑后续安全分析。判断：两阶段设计都以"安全要求的可追溯落地"为纲——架构层明确安全机制布局，详细层确保每个安全机制在电路上真实可工作。15第三章·架构设计硬件架构设计：ASIL继承+最低层可追溯ASIL继承规则每个硬件单元应根据硬件安全要求实现最高的ASIL。当多个安全要求汇聚到同一硬件单元时，按最高等级执行开发方法、分析与验证要求。安全机制本身也需按相应ASIL设计与评估。可追溯性要求硬件安全要求和实现之间的可追溯性应保存到硬件单元的最低层或最小功能模块。这是所有ISO26262与ASPICE流程最强调的底层逻辑——从系统需求到最小模块，链路清晰、逐级可查。图示：ECU硬件架构将安全要求分配到各硬件单元与最小功能模块，并通过数据流互联实现安全机制协同。16第三章·复杂性控制降低复杂性的三原则：模块化、粒度适当、简易性模块化按功能边界划分硬件单元，接口清晰、职责单一，故障影响局部化。粒度适当分解粒度既不过粗导致难以分析，也不过细导致维护爆炸，与分析、验证成本相平衡。简易性优先简单的设计——更少的元件、更清晰的路径，意味着更少的失效模式与更可控的安全论证。为什么重要：高复杂性是系统性故障的温床——元件越多、路径越绕，越难做到全面分析与验证。三条原则共同抑制复杂性风险。落地：架构评审时逐项对照三原则；模块接口以HSI为锚点；简化决策记录为设计依据。17第三章·非功能要求非功能性要求与DVP：故障不只在电路内部考虑的因素对于安全相关的硬件组件故障，硬件设计过程中的非功能性条款应考虑：·温度·振动·湿度·灰尘·电磁干扰既包括硬件结构的组件自身，也包括其他环境串扰源。DVP测试大纲这些影响因素最终体现为设计验证计划（DVP）的测试大纲内容：·EMC电磁兼容测试·电气测试·环境与寿命测试确保硬件在真实使用环境下依然满足安全要求。判断：功能安全不只看"电路逻辑是否正确"，更要看"在恶劣环境与外部干扰下是否依然安全"。非功能因素必须从设计阶段就纳入考虑，并通过DVP系统验证。18第三章·详细设计硬件详细设计四要点：安全文化到操作边界1遵循组织安全文化为避免设计缺陷，相关经验教训应遵循组织的安全文化（2-5.4.7）。2考虑非功能性原因与安全相关的硬件部分失效时，应考虑详细设计中的EMC、电气、环境等验证因素。3满足操作条件限制硬件部分的操作条件应满足其环境和操作限制的规范，不得超限使用。4应用稳健设计原则可利用基于QM方法清单，如保守组件规范、降额设计与WCCA计算等科学思想。判断：详细设计是把"安全意图"变成"可靠电路"的关键一跳——经验、环境、边界、稳健四要素齐备，硬件才谈得上真正符合安全要求。19第三章·稳健设计稳健设计方法：让电路在参数漂移下依然安全保守组件规范选用额定值留有裕量的器件，避免在极限工作点附近运行，降低器件个体差异带来的风险。降额设计按额定值的比例降额使用（电压、电流、功率、温度），显著提升器件可靠性并降低失效率。WCCA计算最坏情况电路分析：遍历参数公差与温度范围，验证电路在最坏组合下仍满足功能与安全边界。思想本质：稳健设计不追求"理想参数下的正确"，而追求"参数漂移与环境变化下的依然正确"——这是随机硬件故障防护的第一道防线。基于QM方法清单即可应用，与安全等级无关，适合所有硬件设计场景。20CHAPTERFOUR04第四章安全分析与故障安全分析依据·单点/残留/多点·双点逻辑·FMEA/FTA第四章·分析依据安全分析：支撑设计规范，再用于设计验证分析依据在硬件设计上找出故障原因和故障影响的安全性分析，依据表2和ISO26262-9:2011条款8。安全分析的最初目的是支持硬件设计规范。随后，安全分析可用于硬件设计验证（见7.4.4）。适用范围本要求适用于安全目标ASIL（B）、C、D的安全相关硬件部件或零件。在确定的安全目标下，安全分析应考虑故障的类别与影响，为设计改进提供方向。判断：安全分析不是"事后验尸"，而是贯穿设计始终的工程工具——设计前用分析找方向，设计后用分析证实现，一鱼两吃。22第四章·分析因素安全分析考虑的因素：安全故障、单点与多点故障A安全故障故障发生后不会导致违反安全目标，甚至可能导向安全状态，无需安全机制覆盖。B单点/残留故障单点故障未被安全机制覆盖且直接违反安全目标；残留故障是安全机制存在但未覆盖到的那部分。C多点故障两个及以上故障组合（感知、检测或潜在），需评估其组合效应与安全机制的感知能力。分析策略：在大多数情况下，可以将分析限于双点故障。但多点故障（两个以上）在某些场景可以显示更高的技术安全概念，例如当实现冗余安全机制时。故障分类直接决定安全机制的覆盖目标与指标计算的输入。23第四章·双点故障双点故障分析：聚焦安全技术概念考虑到的组合识别目的双点故障识别的目的，是不需要对每一个可能的两个硬件组合的故障进行系统分析。但是，至少应从安全技术概念考虑到组合。例如：两个故障共同达到或维持一个安全状态；一个故障影响安全相关元素、另一故障影响相应安全机制。典型组合场景·功能故障+诊断故障：功能单元失效，同时诊断机制失效。·感知/检测/潜在：多点故障按安全机制是否感知、何时检测分类。·冗余实现：当实现冗余安全机制时，可考虑超过双点的组合。判断：双点分析是"重点穷举、其余从简"的务实策略——把分析资源投入到安全技术概念真正关心的组合上，兼顾完备性与工程效率。24第四章·单点故障单点故障：未被覆盖且直接违反安全目标的硬件故障定义与适用单点故障是在一个单元中，未被安全机制覆盖且直接会导致违反安全目标的硬件故障。这项规定适用于安全目标ASIL（B）、C和D。有效安全机制的证据A）保持安全状态：提供保持安全状态或安全切换到安全状态的能力，特别是恰当缓解故障的容错时间间隔内的能力。B）评估诊断覆盖率：评估关于残余故障的诊断覆盖率。注意：如果诊断测试间隔加上安全机制故障响应时间超过容错时间间隔，故障就不能被认为有效覆盖（例如不仅在上电时）。若故障仅发生在上电时刻，可对上电后执行测试。分析方法可采用FMEA或FTA组成基本原理。25第四章·潜在故障潜在故障：检测不到、驾驶员也识别不出的多点故障定义与适用潜在故障是在多点故障检测时间间隔内，不能被安全机制检测出来、也不能被驾驶员识别的多点故障。这项规定适用于安全目标ASIL（B）、C和D。有效安全机制的证据A）检测并通知驾驶员：在可接受的多点故障检测时间间隔内，确定哪些故障潜伏、哪些不能潜伏。B）评价诊断覆盖率：对潜在故障的诊断覆盖率进行评价。注意：如果诊断测试间隔加上安全机构故障响应时间比潜在故障相关的多点故障检测时间间隔长，则该故障不能被覆盖。采用诸如FMEA或FTA的分析方法组成基本原理。26第四章·FMEA与FTAFMEA与FTA：一升一降，构成安全分析的完整骨架FMEA（失效模式与影响分析）自下而上：从单个元件失效模式出发，向上追踪对系统与安全目标的影响。适合系统性遍历硬件单元的全部失效模式，支撑SPFM/LFM指标计算。输出：失效模式清单、安全机制覆盖矩阵、诊断覆盖率。FTA（故障树分析）自上而下：从项级事件（违反安全目标）向下分解，找出所有故障组合与割集。适合评估残余风险与PMHF的割集分析。输出：最小割集、项级失效概率、主导失效路径。图示：故障树自顶向下分解到各失效模式节点，识别最小割集；与自下而上的FMEA交叉验证。27CHAPTERFIVE05第五章指标评估与测试验证失效率来源·SPFM/LFM/PMHF·FMEDA·测试闭环第五章·指标评估逻辑硬件体系指标评估：用数据说话，把安全机制覆盖面量化评估目的通过随机硬件故障这类安全相关元素，包括单点、剩余和潜在故障的分析统计，从客观指标上支持判断是否通过标准。同时通过这些指标解释安全机制的覆盖面，降低硬件故障率不确定的安全风险，提高鲁棒性。评估输入·元件失效率数据（工业数据库/现场数据/专家判断）·安全机制与诊断覆盖率分析·故障分类（单点/残留/多点）与失效模式分布·架构与冗余设计参数判断：指标评估把"安全"从定性描述推向定量证据——计算出的指标直接对标ASIL目标值，形成客观、可复核的通过依据。29第五章·失效率来源失效率三大来源：工业数据库、现场数据与专家判断a工业界认可的硬件故障率数据源包括IEC/TR62380、IEC61709、MIL-HDBK-217F、RIACHDBK217、UTEC80-811、NPRD95、EN50129、IEC62061、RIACFMD97、MIL-HDBK-338等；当前业界参考SN29500标准较为常见。b现场返回或测试数据基于实际使用与测试统计的失效率，此时失效率必须有足够的置信水平。c工程专家判断基于定量和定性参数的专家判断方法，应按照结构化标准行使判断依据，估算适用于ASIL（B）、C、D的故障率。30第五章·三大指标三大硬件指标：SPFM、LFM、PMHF各司其职SPFM单点故障度量衡量安全机制覆盖单点故障的能力。SPFM=1-(单点+残余失效率)/总失效率值越高，单点故障越少漏网。LFM潜伏故障度量衡量对潜伏（未检测）多点故障的覆盖。LFM=1-潜伏失效率/多点总失效率值越高，潜伏故障越早暴露。PMHF随机硬件失效概率估算违反安全目标的发生率。单位：失效次数/小时（FIT）越低越安全，与ASIL目标值对标。对应关系：SPFM与LFM属第8条硬件架构指标（无量纲百分比）；PMHF属第9条残余风险评估（有量纲概率）。三者共同构成硬件安全"成绩单"。指标数据由FMEDA分析工具系统计算得出。来源：ISO26262-5:2018第8、9条；硬件指标定义与计算（技术栈/MUNIK/Motodemy）31第五章·指标目标值指标目标值随ASIL逐级收紧：等级越高，达标越难典型目标值（参考）ASIL-D：SPFM≥99%，LFM≥90%，PMHF<10FIT（10^-8/小时）ASIL-C：SPFM≥97%，LFM≥80%，PMHF<100FITASIL-B：SPFM≥90%，LFM≥60%，PMHF阈值相应放宽（不同来源取值略有差异，以最新标准正文为准）工程含义等级越高，对安全机制的覆盖要求越苛刻，诊断覆盖率、冗余程度与验证成本同步上升。指标不达标时，需通过增加安全机制、提高诊断覆盖或改进架构来迭代。图示：硬件安全指标以仪表盘方式呈现，指针须落在安全阈值区间内，直观反映达标状态。32第五章·FMEDAFMEDA：把失效模式、影响与诊断分析算成指标FMEDA是什么失效模式、影响与诊断分析（FMEDA）是硬件指标计算的系统化工具。它逐元件建立失效模式、失效率、诊断覆盖率与安全机制映射，最终汇总出SPFM、LFM与PMHF三项指标。是FMEA的定量延伸，可直接支撑第8、9条评估。计算流程1.建立硬件分解与元件清单2.为每个失效模式分配失效率3.标注安全机制与诊断覆盖率4.汇总单点/残留/潜伏失效率5.计算SPFM、LFM、PMHF并对照目标判断：FMEDA是硬件定量评估的"算账工具"——指标是否达标、差在哪、改哪里，都可通过FMEDA工作簿追溯到具体元件与失效模式。33第五章·测试验证硬件测试验证：发现并改善遗漏问题的闭环关键定位这是硬件开发非常重要的闭环阶段，用于发现和改善遗漏的问题。主要目的：验证硬件符合适当的ASIL硬件安全要求。测试结果反哺设计，驱动迭代优化。测试用例来源测试用例的制定应来源于