简介这份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 到 S3E 分 E0 到 E4C 分 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架构团队技术安全概念FSCTSC系统/软硬件团队硬件安全需求TSCHSR硬件团队软件安全需求TSCSSR软件团队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(fSPFM: {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 过一遍安全自查清单再开始画框图和写需求。这个习惯帮我省了不少返工时间也让我在评审时心里有底。希望帮到你。本文还有配套的精品资源点击获取
简介这份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 到 S3E 分 E0 到 E4C 分 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架构团队技术安全概念FSCTSC系统/软硬件团队硬件安全需求TSCHSR硬件团队软件安全需求TSCSSR软件团队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(fSPFM: {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 过一遍安全自查清单再开始画框图和写需求。这个习惯帮我省了不少返工时间也让我在评审时心里有底。希望帮到你。本文还有配套的精品资源点击获取
