📚 课程目录第3章 ISO 26262标准概览

3、ISO 26262标准概览：标准各部分（Part 1-12）的职责、适用范围、与IEC 61508的关系

ISO 26262《道路车辆——功能安全》是汽车电子电气系统功能安全的国际标准，其前身是IEC 61508（电气/电子/可编程电子安全相关系统的功能安全）。ISO 26262并非对IEC 61508的简单复制，而是针对汽车行业“大批量生产、多供应商协同、产品生命周期长、现场不可轻易修改”等特点进行了深度定制。理解ISO 26262的12个部分（Part 1-12）的职责边界与内在逻辑，是开展ASIL等级评估、安全需求分解、安全确认等一切工作的前提。本章将系统梳理各部分的职责、适用范围，并厘清其与IEC 61508的继承与差异关系。

上图展示了ISO 26262的整体架构。从图中可以看出，标准并非单一线性流程，而是由“管理框架”“产品开发”“半导体专项”三大支柱构成，并由Part 1词汇表作为共同语言基础。下面我们将逐一解析各部分的职责与适用范围。

3.1 标准各部分（Part 1-12）的职责与适用范围

3.1.1 Part 1：词汇表（Vocabulary）

核心原理：Part 1定义了整个标准体系中的统一术语，包括ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）、安全目标（Safety Goal）、安全状态（Safe State）、残余风险（Residual Risk）、安全机制（Safety Mechanism）等关键概念。没有统一的词汇，跨团队、跨供应商的沟通将出现歧义。

适用范围：所有其他Part的引用基础。任何安全文档、评审报告、供应商技术协议中使用的术语，均须以Part 1为准。

实战提示：在项目启动时，建议由功能安全经理组织一次“术语对齐会”，特别是与电子、软件、机械背景的工程师共同确认“故障（Fault）”“错误（Error）”“失效（Failure）”的区别——这三者在ISO 26262中有着严格的定义边界，混用会导致FMEA（失效模式与影响分析）和FMEDA（失效模式影响与诊断分析）结果失真。

3.1.2 Part 2：安全管理（Management of Functional Safety）

核心原理：Part 2规定了组织层面的安全文化、项目独立性和安全计划。它要求建立安全生命周期，明确每个阶段的职责、输入输出、评审节点。安全经理的角色、安全案例（Safety Case）的编制与维护也在此部分定义。

操作流程：

制定安全计划（Safety Plan），明确项目范围、时间表、交付物。
定义安全活动（如危害分析、验证、确认）的负责人与独立性要求。
建立安全档案（Safety Case），持续收集证据，证明系统满足安全目标。
进行安全评审（Safety Review），在关键里程碑（如概念冻结、设计冻结）进行独立评估。

  案例拆解：某Tier 1供应商为整车厂开发电动助力转向（EPS）控制器。项目启动时，安全经理依据Part 2要求，定义了“独立评审员”角色——该评审员不参与具体设计，仅负责审核FMEA、安全需求规格和验证报告。在评审中，发现硬件失效率计算中忽略了“电源电压骤降”这一运行模式，导致ASIL D的失效率目标可能无法满足。通过独立评审机制，问题在SOP（量产）前6个月被拦截，避免了召回风险。

3.1.3 Part 3：概念阶段（Concept Phase）

核心原理：Part 3是功能安全的起点，核心活动包括：项目定义（Item Definition）、危害分析与风险评估（HARA）、安全目标定义、ASIL等级确定、功能安全概念（Functional Safety Concept）开发。

判断方法：HARA中，根据“驾驶场景（如高速、低速、停车）”“操作模式（如正常、故障、维护）”“可控制性（C）”“暴露概率（E）”“严重度（S）”三个参数，查表确定ASIL等级（A/B/C/D或QM）。

参数	说明	示例（EPS系统）
S（Severity）	对乘员或行人的伤害程度	S3：可能危及生命
E（Exposure）	场景发生的概率	E4：每次驾驶都会遇到
C（Controllability）	驾驶员或其他人员避免伤害的能力	C3：难以控制或无法控制

查表可得：S3+E4+C3 → ASIL D（最高等级）。

常见误区：很多团队将ASIL等级直接分配给某个ECU或软件模块，而忽略了ASIL是“针对安全目标”的。例如，EPS的“防止非预期转向”是ASIL D，但“提供助力”可能只是QM（Quality Management，质量管理）。必须逐条安全目标分别定级，再通过安全需求分解到系统、硬件、软件。

3.1.4 Part 4：系统级产品开发（Product Development at the System Level）

核心原理：Part 4是技术安全概念（Technical Safety Concept）的诞生地。它将功能安全概念（Part 3的输出）细化为系统级技术需求，包括系统架构设计、硬件-软件接口（HSI）定义、安全机制（如故障检测、冗余、降级策略）的分配，以及系统集成与验证。

关键交付物：技术安全需求规格、系统架构设计、安全机制规格、集成测试计划、安全验证报告。

案例拆解：以自动紧急制动（AEB）系统为例。功能安全概念要求“在传感器故障时，系统应进入安全状态”。Part 4阶段，系统架构师将这一需求分解为：① 雷达与摄像头信号交叉校验（冗余）；② 若校验不一致，则禁用AEB功能并点亮警告灯（降级）；③ 警告灯点亮逻辑需满足ASIL B，而AEB执行器控制需满足ASIL D。通过ASIL分解（详见Part 9），ASIL D的需求可分解为ASIL C(D)+ASIL A(D)的组合，从而降低部分模块的开发成本。

3.1.5 Part 5：硬件级产品开发（Product Development at the Hardware Level）

核心原理：Part 5关注硬件电路、电子元器件、FPGA、ASIC的设计与验证。核心活动包括：硬件安全需求规格、硬件设计（原理图/PCB）、硬件失效模式与影响分析（硬件FMEDA）、失效率计算（基于IEC 62380或SN 29500等标准）、硬件集成测试。

关键指标：硬件架构指标（SPFM，单点故障指标；LFM，潜伏故障指标）和随机硬件失效概率目标（PMHF，Probabilistic Metric for Random Hardware Failures）。

ASIL等级	SPFM	LFM	PMHF（每小时失效概率）
ASIL B	≥90%	≥60%	<10⁻⁷
ASIL C	≥97%	≥80%	<10⁻⁷
ASIL D	≥99%	≥90%	<10⁻⁸

  实战场景：某域控制器中，电源管理芯片（PMIC）的“看门狗”功能被分配为ASIL D。硬件工程师在FMEDA分析中发现，看门狗定时器使用的时钟源（内部RC振荡器）漂移过大，可能导致误触发复位。解决方案：① 改用外部晶振（精度更高）；② 增加时钟监控电路，若频率偏差超过±5%则进入安全状态。通过该设计变更，SPFM从96.2%提升至99.3%，满足ASIL D要求。

3.1.6 Part 6：软件级产品开发（Product Development at the Software Level）

核心原理：Part 6是软件工程的功能安全化，基于V模型。左侧包括软件安全需求规格、软件架构设计（如AUTOSAR分层）、软件单元设计与实现；右侧包括单元测试、集成测试、软件安全验证。关键要求包括：编码规范（如MISRA C）、静态分析、覆盖率（语句/分支/MC/DC）等。

操作流程：

软件安全需求规格：从技术安全需求中提取软件相关部分，并分配ASIL。
软件架构设计：定义软件组件、接口、调度机制，避免“共享资源冲突”。
单元测试：使用工具（如VectorCAST、Polyspace）验证每个函数的行为。
覆盖率分析：ASIL D要求修改条件/判定覆盖（MC/DC）达到100%。

常见误区：很多团队认为“只要代码通过了MISRA检查，就满足功能安全”。实际上，MISRA只是编码规范，它减少了C语言的未定义行为，但无法保证逻辑正确性。必须结合需求追踪矩阵（从安全需求到代码的映射）和动态测试，才能证明软件满足安全目标。

3.1.7 Part 7：生产、运行、服务和报废（Production, Operation, Service and Decommissioning）

核心原理：Part 7关注产品量产后的功能安全。它要求生产过程中的质量控制（如焊接工艺、装配防错）、售后维修中的安全信息传递（如维修手册中的安全注意事项）、以及软件更新（OTA）时的安全验证。

关键点：生产阶段的“安全相关特性”必须被识别并纳入生产控制计划。例如，安全气囊ECU的焊接温度曲线、扭矩要求等，若偏离规格，可能导致焊点失效，进而引发安全目标违背。

3.1.8 Part 8：支持过程（Supporting Processes）

核心原理：Part 8是“流程的流程”，定义了分布式开发接口（DIA）、安全需求管理、配置管理、变更管理、验证、文档化、工具可信度（Tool Confidence Level，TCL）等支持性活动。这些过程不直接产生安全需求，但为安全活动提供质量保障。

工具可信度（TCL）说明：如果使用软件工具（如编译器、静态分析工具）生成或验证安全需求，必须评估该工具是否可能引入错误。工具分为TCL1（高可信）、TCL2（中可信）、TCL3（低可信）。例如，使用未经验证的编译器编译ASIL D代码，需要额外增加“工具验证”活动（如对比编译前后汇编代码）。

3.1.9 Part 9：ASIL导向和安全导向的分析（ASIL-oriented and Safety-oriented Analyses）

核心原理：Part 9包含两个核心方法：ASIL分解（ASIL Decomposition）和冗余分析（如故障树分析FTA、可靠性框图）。ASIL分解允许将高ASIL需求分解到两个独立元素上，降低单个元素的开发难度。

ASIL分解规则：ASIL D可分解为ASIL C(D) + ASIL A(D)，或ASIL B(D) + ASIL B(D)。括号中的D表示原始ASIL等级，分解后的元素需满足各自的ASIL要求，且必须保证“独立性”（例如，两个元素不能共享相同的电源、时钟或软件变量）。

  案例拆解：制动系统要求ASIL D。方案一：使用一个ASIL D的ECU；方案二：使用两个ASIL B的ECU（主+冗余），通过交叉通信校验。方案二通过ASIL分解，使得每个ECU只需满足ASIL B，大幅降低了硬件失效率计算和软件开发的难度。但代价是增加了系统复杂度和成本。分解后，必须通过FTA验证“两个ECU同时失效”的概率是否满足ASIL D的PMHF目标。

3.1.10 Part 10：ISO 26262指南（Guidelines on ISO 26262）

核心原理：Part 10不是规范性要求，而是解释性指南。它提供了关于ASIL等级确定、安全案例编写、以及如何将ISO 26262应用于现有系统的非正式指导。对于初学者或跨行业者，Part 10是很好的入门读物。

3.1.11 Part 11：半导体应用指南（Guidelines on Application of ISO 26262 to Semiconductors）

核心原理：2018版新增的Part 11，专门针对半导体器件（如MCU、SoC、传感器、电源芯片）的功能安全。它定义了半导体器件的失效模式（如单粒子翻转、时钟抖动、漏电）、失效率计算的特殊方法（如基于晶圆工艺的FIT率）、以及安全机制（如ECC、BIST、时钟监控）在半导体内部的实现。

适用范围：半导体供应商（如NXP、Infineon、TI）和Tier 1（使用这些芯片的厂商）。Part 11解决了“芯片内部故障如何被检测”的问题，例如，MCU内部的RAM自检（LBIST）应何时运行、覆盖率需达到多少。

3.1.12 Part 12：摩托车适用性（Adaptation for Motorcycles）

核心原理：Part 12是ISO 26262对摩托车（L类车辆）的适配。由于摩托车的驾驶场景、电子电气架构与乘用车差异较大（如无车身稳定系统、驾驶员暴露度高），Part 12调整了HARA中的暴露概率和可控性评估方法，并简化了部分流程要求。

3.2 与IEC 61508的关系

继承关系：ISO 26262的核心框架（安全生命周期、V模型、安全完整性等级、安全案例）均源自IEC 61508。IEC 61508中的SIL（Safety Integrity Level，安全完整性等级）1-4级，在汽车领域被映射为ASIL A-D（ASIL D对应SIL 3的严格程度，但增加了汽车特有的“可控性”维度）。

主要差异：

维度	IEC 61508	ISO 26262
行业	通用（化工、核电、机械等）	道路车辆（乘用车、商用车、摩托车）
安全等级	SIL 1-4	ASIL A-D + QM
风险评估	基于风险矩阵（频率、严重度）	基于S/E/C三参数查表
生产阶段	较少涉及	Part 7专门规定生产、运行、维修
半导体专项	无	Part 11（2018版新增）
多供应商协同	强调功能安全管理	Part 8中的DIA（分布式开发接口）

实践中的关系处理：如果一家供应商同时为汽车和工业领域供货，建议建立两套流程：一套基于ISO 26262（汽车），一套基于IEC 61508（工业）。虽然两者在“安全生命周期”上相似，但在具体交付物（如HARA报告、FMEDA表格）和评审要求上差异显著，混用会导致评审失败。

经验总结：ISO 26262不是“纸上谈兵”的标准，而是需要嵌入到现有开发流程中的“安全操作系统”。建议企业按以下步骤落地：① 先建立Part 2要求的安全管理框架；② 选择一条产品线（如EPS或BMS）作为试点，完整走一遍Part 3-7；③ 在试点过程中，逐步完善Part 8要求的模板和工具链；④ 最后将经验横向推广到其他产品线。切忌“一步到位”推行所有Part，否则团队会因流程过重而抵触。