简介：这份PDF资料聚焦新能源智能汽车EE架构下的功能安全，系统梳理ISO 26262标准的核心理念与落地方法，面向汽车电子工程师、功能安全从业者及智能网联汽车方向的学习者，帮助建立从安全概念到安全生命周期的完整认知框架。内容涵盖功能安全概念、六阶段流程、安全设计中的容错与安全状态转换、测试验证、安全报告，以及SIL与ASIL等级划分、FIT率、MC/DC覆盖率、Safety Case等关键术语，并延伸至BMS、MCU、ECU、ABS、EPS等典型应用场景与EMC相关要求。资源包为1个PDF文件，大小约9.13MB，目录结构清晰，便于按章节查阅与对照学习。目前已有211人学习下载，适合需要系统理解ISO 26262、补齐功能安全知识体系或用于项目参考的读者。
1. 新能源EE架构下翻ISO26262：这份PDF为什么值得放在手边
做新能源智能汽车电子电气架构的同行大概都有体会：项目一旦进入功能安全评审阶段，最怕的不是找不到标准原文，而是标准原文太厚、太散，翻到关键条款时上下文全丢了。ISO 26262 正式版有十几个部分，从词汇、管理、概念阶段一直铺到生产运行，纯英文读下来对一线工程师并不友好。这份《新能源智能汽车EE架构—功能安全ISO26262》PDF 的价值在于，它把标准里跟 EE 架构强相关的部分做了中文梳理，尤其是域控制器、中央计算平台、区域控制器这些新架构形态下的安全活动怎么落地，讲得比纯标准原文更贴项目。适合谁看？做整车电子电气架构设计、域控软硬件开发、功能安全经理、以及正在准备 ASPICE 或功能安全审核的团队。如果你手上正跑着一个要过 ISO 26262 的域控项目，这份材料能当案头参考用。
2. 先搞清楚ISO26262在EE架构里管什么：从ASIL到安全目标
2.1 标准结构与本PDF的覆盖范围
ISO 26262 一共 12 个部分，第 1 到第 12 部分各有分工。第 3 部分概念阶段定危害分析和风险评估，第 4 部分系统层面定技术安全需求，第 5 部分硬件、第 6 部分软件，第 7 部分生产运行，第 8 部分支持过程，第 9 部分 ASIL 导向分析，第 10 部分指南，第 11 部分半导体应用指南，第 12 部分摩托车。新能源 EE 架构项目最常打交道的是第 3、4、5、6、8、9 这几部分。
这份 PDF 的编排逻辑不是照搬标准目录，而是按 EE 架构开发流程重新组织。它把概念阶段的 HARA 输出、系统阶段的技术安全概念、硬件阶段的诊断覆盖率、软件阶段的安全机制，串成一条线。好处是你在做域控设计时，能直接看到某个安全目标往下怎么分解到软硬件。
提示：读这份材料前，最好先确认你项目适用的标准版本。ISO 26262 有 2011 版和 2018 版，两者在部分术语和流程上有差异，PDF 里如果没明确标注版本，遇到关键条款要回查正式标准确认。
2.2 ASIL等级怎么定，为什么EE架构改动会牵动它
ASIL 由三个维度决定：严重度 S、暴露率 E、可控性 C。S 分 S0 到 S3，E 分 E0 到 E4，C 分 C0 到 C3。三者组合后查表得出 QM、A、B、C、D 五个等级，D 最高。
新能源 EE 架构从分布式 ECU 往域集中、中央计算演进时，一个明显变化是功能被重新分配。原来一个独立 ECU 管一个功能，现在可能几个功能跑在同一个域控上。功能合并后，失效模式变了，共因失效的风险上升，HARA 的结论可能跟着变。比如原来两个 QM 的功能合并到一个芯片上，如果它们共享电源和时钟，就可能需要重新评估可控性，ASIL 等级可能被拉高。
常见做法是，在架构设计早期就把安全目标按 ASIL 等级标出来，然后看哪些功能可以共存在同一颗芯片、哪些必须隔离。这份 PDF 里对 ASIL 分解有专门段落，讲得比较细，尤其是 ASIL 分解的几种方案和适用条件。
2.3 安全目标到技术安全需求的分解路径
安全目标是从 HARA 出来的，比如“防止车辆在行驶中非预期加速”，对应 ASIL D。安全目标不能直接拿去写代码，要往下分解成功能安全概念 FSC，再分解成技术安全概念 TSC，最后落到硬件安全需求和软件安全需求。
在 EE 架构层面，这个分解过程要回答几个问题：安全目标由哪个系统或域控承接？需要哪些安全机制？安全机制放在硬件还是软件？诊断覆盖率要求多少？这份 PDF 用表格形式给出了安全目标到 TSC 的映射示例，可以直接参考它的格式来写自己项目的安全需求文档。
| 层级 | 输入 | 输出 | 责任方 |
|---|---|---|---|
| 危害分析 | 整车功能清单 | 危害事件列表 | 系统安全团队 |
| 风险评估 | 危害事件 | ASIL 等级 | 系统安全团队 |
| 安全目标 | ASIL 等级 | 安全目标 | 系统安全团队 |
| 功能安全概念 | 安全目标 | FSC | 架构团队 |
| 技术安全概念 | FSC | TSC | 系统/软硬件团队 |
| 硬件安全需求 | TSC | HSR | 硬件团队 |
| 软件安全需求 | TSC | SSR | 软件团队 |
3. 把标准落到域控项目：安全机制选型与诊断覆盖率计算
3.1 硬件安全机制怎么选：看诊断覆盖率和ASIL
硬件层面常见的安全机制包括：看门狗、ECC、锁步核、CRC、电压监控、时钟监控、内存保护单元 MPU。选哪些、选到什么程度，取决于 ASIL 等级和诊断覆盖率目标。
ISO 26262 第 5 部分给出了单点故障度量 SPFM 和潜伏故障度量 LFM 的目标值。ASIL D 要求 SPFM ≥ 99%，LFM ≥ 90%；ASIL C 要求 SPFM ≥ 97%，LFM ≥ 80%；ASIL B 要求 SPFM ≥ 90%，LFM ≥ 60%。这些数字直接决定你选什么芯片、加什么诊断。
我一般会先列一个硬件模块清单，标出每个模块的失效模式，然后对照诊断覆盖率表看现有机制够不够。不够就加诊断，加完再算一遍 SPFM 和 LFM。这份 PDF 里有一节专门讲诊断覆盖率怎么估算，给了简化公式和示例，比翻标准原文快。
# 简化版 SPFM 计算示例 # 假设有 5 个硬件模块，每个模块有失效率 λ 和诊断覆盖率 DC modules = [ {"name": "CPU", "lambda": 100, "dc": 0.99}, {"name": "RAM", "lambda": 50, "dc": 0.98}, {"name": "Flash", "lambda": 30, "dc": 0.95}, {"name": "电源", "lambda": 20, "dc": 0.90}, {"name": "时钟", "lambda": 10, "dc": 0.85}, ] lambda_total = sum(m["lambda"] for m in modules) lambda_residual = sum(m["lambda"] * (1 - m["dc"]) for m in modules) spfm = 1 - lambda_residual / lambda_total print(f"总失效率: {lambda_total} FIT") print(f"残余失效率: {lambda_residual:.2f} FIT") print(f"SPFM: {spfm:.4f} ({spfm*100:.2f}%)") # 如果 SPFM 不达标，需要提高某些模块的 DC 或增加诊断这段代码的逻辑是：每个模块的残余失效率等于该模块失效率乘以（1 减诊断覆盖率），所有模块残余失效率之和除以总失效率，再用 1 减，得到 SPFM。参数说明：lambda 是模块失效率，单位 FIT，通常从芯片手册或可靠性报告拿；dc 是诊断覆盖率，0 到 1 之间，来自诊断机制的设计。如果算出来不达标，优先提高高失效率模块的 DC，因为它们的权重更大。
3.2 软件安全机制与EE架构的配合
软件层面的安全机制包括：程序流监控、内存保护、冗余计算、数据校验、安全状态切换。在域控架构下，软件安全机制还要考虑核间通信、Hypervisor 隔离、OTA 升级的安全。
举个例子，一个域控上跑着自动驾驶功能和座舱功能，两者 ASIL 等级不同。常见做法是用 Hypervisor 做隔离，把高 ASIL 功能放在独立分区，低 ASIL 功能放在另一个分区，分区之间通过受控通道通信。这样高 ASIL 功能的软件安全机制不会被低 ASIL 功能干扰。
这份 PDF 里对软件安全机制的描述比较务实，没有堆术语，而是按“什么场景用什么机制”来讲。比如程序流监控适合检测程序跑飞，内存保护适合检测非法访问，冗余计算适合高 ASIL 的关键算法。
3.3 用FMEA和FTA做安全分析的操作步骤
FMEA 和 FTA 是功能安全分析的两大工具。FMEA 自下而上，从失效模式推到影响；FTA 自上而下，从顶事件推到基本事件。在 EE 架构项目里，两者通常配合用。
操作步骤我一般这么走：
- 确定分析范围，比如一个域控的电源模块。
- 列出所有可能的失效模式，比如电压过高、电压过低、电压纹波过大。
- 对每个失效模式，分析局部影响、系统影响、整车影响。
- 评估严重度、频度、探测度，算 RPN 或按 ISO 26262 的 ASIL 逻辑定级。
- 对高风险的失效模式，提出改进措施，比如加电压监控、加滤波。
- 用 FTA 验证：把顶事件设为“域控非预期复位”，往下找所有可能原因，看 FMEA 有没有漏。
这份 PDF 给了 FMEA 表格模板和 FTA 符号说明，可以直接套用。注意 FMEA 的频度和探测度评估主观性较强，团队里最好有经验的人一起评审，不然容易拍脑袋。
4. 避坑与排查：ISO26262落地时最容易翻车的五个点
4.1 坑一：ASIL等级定完就不管了，架构一改全乱套
现象：项目初期定了 ASIL 等级，后来 EE 架构从分布式改成域集中，功能重新分配，但安全分析没更新，评审时被审核方挑出来。
原因：ASIL 等级跟功能分配和失效模式强相关，架构改动会改变共因失效路径和可控性评估，原来的 HARA 结论可能不再成立。
解决：架构每改一版，同步更新 HARA 和安全目标。把安全分析纳入架构变更流程，改架构必须触发安全评审。这份 PDF 里有一节讲变更管理对功能安全的影响，可以参考它的检查清单。
4.2 坑二：诊断覆盖率拍脑袋填，算出来SPFM虚高
现象：硬件安全分析时，诊断覆盖率直接填 99%，算出来 SPFM 很好看，但实际诊断机制根本没覆盖那么多失效模式。
原因：诊断覆盖率不是设计目标，是实际诊断机制能检测到的失效模式比例。填高了，安全论证站不住，审核时会被质疑。
解决：每个诊断机制对应哪些失效模式，要有依据。常见做法是查芯片手册里的诊断覆盖率数据，或者用故障注入测试实测。这份 PDF 里给了诊断覆盖率估算的保守方法，宁可填低一点，留余量。
4.3 坑三：安全需求和普通需求混在一起，追溯链断了
现象：安全需求写在普通需求文档里，没有单独标识，做追溯时找不到安全目标到安全需求的链路。
原因：ISO 26262 要求安全需求可追溯，从安全目标一路追到软硬件实现和测试用例。混在一起写，追溯链容易断。
解决：安全需求单独编号、单独管理，用需求管理工具建追溯矩阵。这份 PDF 里给了追溯矩阵的示例格式，安全需求用 ASR 前缀，普通需求用 REQ 前缀，区分清楚。
4.4 坑四：软件安全机制加了但没验证，测试用例覆盖不到
现象：软件里加了程序流监控和内存保护，但测试用例只测功能，没测安全机制本身，审核时拿不出验证证据。
原因：安全机制也是软件的一部分，需要专门的测试用例来验证它能不能正确检测失效、能不能正确进入安全状态。
解决：为每个安全机制写专门的测试用例，包括正常触发、误触发、不触发三种情况。常见做法是用故障注入，人为制造失效，看安全机制是否按预期动作。这份 PDF 里有一节讲安全机制验证方法，给了故障注入的几种手段。
4.5 坑五：把ISO26262当纯文档工作，开发和测试脱节
现象：功能安全文档写得很漂亮，但开发和测试按另一套流程走，安全需求没落到代码和测试用例里。
原因：功能安全不是文档工作，是贯穿开发全流程的活动。文档只是输出，真正的落地在需求、设计、编码、测试每个环节。
解决：把安全活动嵌入现有开发流程，安全需求进需求库，安全设计进设计文档，安全测试进测试计划。这份 PDF 里对开发流程的融合讲得比较清楚，尤其是怎么跟 ASPICE 流程对接。
5. 进阶用法：用这份PDF搭一套项目内的功能安全自查流程
这份 PDF 除了当参考书翻，还能当自查清单用。我一般会在项目几个关键节点拿它过一遍，下面是我自己用的自查流程。
第一个节点是概念阶段结束前。对照 PDF 里 HARA 那一章，检查危害分析有没有覆盖所有整车功能，ASIL 等级定得有没有依据，安全目标写得够不够具体。常见问题是安全目标写得太泛，比如“防止非预期加速”，这种没法往下分解，要改成“防止车辆在车速大于 10km/h 时非预期加速超过 0.5m/s²”。
第二个节点是系统设计评审前。对照 PDF 里技术安全概念那一章，检查安全目标到 TSC 的分解有没有断链，每个安全目标是不是都有对应的技术安全需求，每条技术安全需求是不是都有责任方和验证方法。我习惯用一张表来追，左边安全目标，中间 TSC，右边验证方法，空着的就是缺口。
第三个节点是硬件设计冻结前。对照 PDF 里硬件安全那一章，检查诊断覆盖率算得对不对，SPFM 和 LFM 达不达标，不达标的有没有改进计划。这里有个经验：SPFM 和 LFM 的计算最好用工具做，手算容易漏模块。如果项目里没有专用工具，用前面那段 Python 脚本也能凑合，但模块清单要列全。
第四个节点是软件提测前。对照 PDF 里软件安全那一章，检查安全机制有没有实现，测试用例有没有覆盖安全机制，故障注入测试做了没有。我见过不少项目，安全机制代码写了，但测试用例只测了正常路径，故障路径没测，审核时被开不符合项。
第五个节点是生产运行准备阶段。对照 PDF 里生产运行那一章，检查生产过程中的安全相关参数有没有定义，售后诊断和 OTA 升级的安全影响有没有评估。新能源车 OTA 频繁，每次升级都可能影响安全相关功能，这个环节容易被忽略。
| 节点 | 检查重点 | 常见缺口 |
|---|---|---|
| 概念阶段 | HARA 覆盖度、ASIL 依据、安全目标具体性 | 安全目标太泛、ASIL 无依据 |
| 系统设计 | TSC 分解链、责任方、验证方法 | 追溯链断裂、验证方法缺失 |
| 硬件冻结 | SPFM/LFM 达标、诊断覆盖率依据 | 覆盖率拍脑袋、计算漏模块 |
| 软件提测 | 安全机制实现、故障注入测试 | 只测正常路径、无故障注入 |
| 生产运行 | 生产参数、OTA 安全评估 | OTA 影响未评估 |
这套自查流程走下来，大概能覆盖 ISO 26262 对 EE 架构项目的主要要求。PDF 里有些章节讲得比较细，比如半导体应用指南那部分，做芯片选型时可以重点看。有些章节偏管理，比如支持过程，如果团队里有专职功能安全经理，可以让他重点看。
从那以后我每次拿到新的 EE 架构方案，都会先拿这份 PDF 过一遍安全自查清单，再开始画框图和写需求。这个习惯帮我省了不少返工时间，也让我在评审时心里有底。希望帮到你。
本文还有配套的精品资源，点击获取
