简介这份资源是《道路车辆功能安全——ISO26262标准解析》中文版PDF面向汽车电子、电气系统研发工程师、功能安全管理人员及高校相关专业学习者帮助系统理解ISO26262:2018标准框架与落地方法。压缩包内仅1个PDF文件约18.31MB内容完整覆盖标准适用范围与主要内容、功能安全管理、概念阶段、系统级产品开发、硬件级产品开发等章节并延伸至软件开发、生产服务、产品一致性及事故后分析改进等后续环节。目录结构清晰从项目定义、安全生命周期、危险分析与风险评估到技术安全需求制定、系统设计、集成测试、安全确认与功能安全评估逐层展开便于按模块查阅与对照实践。目前已有2163人学习下载适合需要建立功能安全知识体系、准备项目合规审查或开展安全设计参考的读者使用。1. 道路车辆功能安全 ISO 26262从标准中文版到可落地执行做汽车电子的人几乎都经历过这样的场景项目评审会上客户或审核方突然问一句“这个 ECU 的 ASIL 等级怎么定的安全目标覆盖了哪些失效模式”如果平时只把 ISO 26262 当成一份“要交的文档”这时候大概率会卡壳。ISO 26262 是道路车辆功能安全的国际标准中文版通常指 GB/T 34590 系列它把整车到芯片的整条链路拆成了概念、系统、硬件、软件、支持过程、ASIL 导向分析等部分。它解决的不是“怎么让零件不坏”而是“坏了之后车不能出人命”这套逻辑怎么被证明。适合谁看做域控制器、BMS、EPS、ADAS 的软硬件工程师以及需要写安全计划、做安全分析、应对审核的功能安全工程师。这篇笔记不空谈条款而是把标准中文版里最常被用到的部分拆成能直接抄的流程、参数和排查清单。2. 先分清 ISO 26262 的 Part 与 GB/T 34590 的对应关系很多人一上来就翻“中文版”结果发现目录对不上越看越乱。原因很简单ISO 26262 是国际标准国内等同转化后是 GB/T 34590 系列两者章节结构基本一致但编号和措辞有差异。如果你手里拿的是 ISO 26262 的英文版却按 GB/T 34590 的条款号去引用评审时就会被挑出“引用不一致”的问题。所以第一步不是背条款而是先把“你要用哪一版、哪一部分”锁死。2.1 标准十二个 Part 各自管什么ISO 26262 目前常见的是 2018 版分为 12 个 Part。做落地时不需要全部精读但必须知道每个 Part 的边界否则很容易把系统层的安全需求写到软件层去或者把支持过程当成开发过程。Part中文版对应主要管什么谁最该看Part 1GB/T 34590.1术语、词汇所有人Part 2GB/T 34590.2功能安全管理功能安全经理、项目经理Part 3GB/T 34590.3概念阶段、HARA系统工程师、安全工程师Part 4GB/T 34590.4系统层开发系统架构师Part 5GB/T 34590.5硬件层开发硬件工程师Part 6GB/T 34590.6软件层开发嵌入式软件工程师Part 7GB/T 34590.7生产、运行、服务制造与售后Part 8GB/T 34590.8支持过程配置管理、变更管理Part 9GB/T 34590.9ASIL 导向与安全分析安全分析人员Part 10GB/T 34590.10指南新手入门Part 11GB/T 34590.11半导体应用指南芯片与底层驱动Part 12GB/T 34590.12摩托车两轮车相关这张表的价值在于当你接到“把这个功能做到 ASIL D”的需求时能立刻判断出该翻 Part 3 定目标、Part 4 拆系统、Part 5 和 Part 6 分别约束硬件和软件而不是抱着一本合订本从头翻到尾。2.2 中文版和英文版混用时最容易踩的引用坑常见做法是公司内部模板用 GB/T 34590 的条款号但供应商给的 Safety Manual 引用的是 ISO 26262 的 Part 号。这时候如果直接复制粘贴就会出现“GB/T 34590.5-2022 的 7.4.3”和“ISO 26262-5:2018 Clause 7.4.3”混在一份文档里。审核方不一定判你不符合但会要求你解释对应关系平白增加工作量。我一般会建议团队在安全计划里加一张“引用映射表”把项目里用到的每一条标准要求同时标出 ISO 和 GB/T 的编号。这样无论审核方习惯看哪一版都能对上。映射表不需要覆盖全部条款只覆盖项目实际裁剪后保留的部分即可通常几十行就够。2.3 裁剪不是所有项目都要从 Part 1 做到 Part 12ISO 26262 允许裁剪但裁剪必须有理由。比如一个纯软件组件如果它不直接控制执行器也不涉及安全目标那 Part 5 硬件层的要求可能就不适用。但“不适用”不等于“不写”而是要在安全计划里写清楚为什么裁剪、裁剪后如何保证安全目标仍然被覆盖。常见做法是先根据 HARA 定出 ASIL 等级再按 ASIL 等级查 Part 4、Part 5、Part 6 里对应的要求表。ASIL A 和 ASIL D 在测试覆盖率、方法推荐度上的要求差别很大。如果一上来就按 ASIL D 全量做时间和成本会失控如果该做 ASIL D 却按 QM 做审核又过不了。所以裁剪的前提是 HARA 做扎实。3. 用 HARA 把安全目标定出来S、E、C 三个参数怎么打分HARA危害分析与风险评估是整条链路的起点。如果 HARA 做错了后面所有安全需求、安全机制、测试用例都是空中楼阁。很多团队 HARA 做得敷衍结果到系统层发现安全目标根本没法拆只能回头重做血泪经验就是HARA 阶段多花两天后面省两周。3.1 S、E、C 的定义与打分表HARA 的核心是对每个危害事件打三个分严重度 S、暴露率 E、可控性 C。三个分确定后查表得到 ASIL 等级。严重度 S等级描述典型后果S0无伤害仅财产损失S1轻中度伤害轻微擦伤、低速碰撞S2重度伤害骨折、危及生命的伤害但通常可存活S3致命伤害可能致死暴露率 E等级描述典型场景E0极低概率几乎不可能发生E1低概率一年几次E2中等概率一月几次E3高概率几乎每天E4极高概率每次驾驶都发生可控性 C等级描述驾驶员能否避免伤害C0完全可控一般驾驶员都能控制C1简单可控稍微操作就能避免C2一般可控需要一定反应和操作C3难以控制大多数驾驶员无法避免打分时最容易出问题的是 C。很多团队把 C 打成 C1理由是“驾驶员应该能反应过来”但标准要求的是“一般驾驶员在典型场景下”的可控性不是“专业驾驶员在理想条件下”。如果场景是高速上突然失去助力C 通常至少是 C2 甚至 C3。3.2 从危害事件到安全目标的转换打完分后查 ASIL 表得到等级。比如 S3 E4 C3 ASIL DS2 E3 C2 ASIL BS1 E2 C1 QM。得到 ASIL 后要把它写成安全目标。安全目标不是“防止失效”而是“防止危害事件发生”。举个例子某电子助力转向系统危害事件是“车辆在高速行驶时突然失去转向助力”。S3、E4、C3ASIL D。安全目标可以写成“防止在车辆行驶过程中非预期地失去转向助力ASIL D。”注意这里没有写“助力电机不能坏”因为电机坏不一定导致失去助力可能只是助力下降。安全目标要对应危害事件而不是对应零部件。3.3 一个可复用的 HARA 表格模板下面这个表格结构可以直接拿去用列名和顺序按常见审核习惯排危害事件编号 | 整车功能 | 危害事件描述 | 运行场景 | S | E | C | ASIL | 安全目标 | 安全状态 | 故障容错时间其中“故障容错时间”是很多团队会漏掉的一列。它指的是从故障发生到危害事件发生之间允许的时间窗口。这个时间直接决定系统层要不要做冗余、软件层要不要做快速检测。比如故障容错时间 100ms那软件检测周期就不能是 200ms否则还没检测到就已经出事了。4. 系统层与软硬件层怎么拆安全需求、安全机制与 ASIL 分解HARA 定完安全目标后下一步是把它拆成系统层安全需求再拆到硬件和软件。这一步最容易出现“需求写得太虚”的问题比如“系统应保证安全”这种话写了等于没写。可执行的安全需求必须能对应到具体的检测机制、响应动作和验证方法。4.1 安全需求从安全目标推导的写法安全目标“防止非预期失去转向助力”可以拆成几条系统层安全需求系统应在检测到助力电机驱动故障后 20ms 内进入安全状态。系统应能检测助力扭矩传感器信号丢失或超出合理范围。系统应在检测到供电电压异常时限制助力输出并点亮警告灯。每条需求都要有 ASIL 等级、验证方法和来源追溯。来源追溯就是指向对应的安全目标这样审核时能看出需求不是拍脑袋写的。4.2 硬件层FMEDA 与诊断覆盖率硬件层最常被问到的是 FMEDA失效模式、影响与诊断分析。它的作用是计算硬件的单点故障指标 SPFM 和潜伏故障指标 LFM。ASIL D 要求 SPFM ≥ 99%LFM ≥ 90%ASIL C 要求 SPFM ≥ 97%LFM ≥ 80%ASIL B 要求 SPFM ≥ 90%LFM ≥ 60%。做 FMEDA 时每个硬件元件都要列出失效模式、失效率、诊断覆盖率和是否安全相关。诊断覆盖率 DC 的取值不是随便填的通常参考芯片 Safety Manual 或标准里的推荐值。如果芯片厂商没给就要自己根据诊断机制估算比如看门狗对 CPU 的 DC 可能是 60%而双核锁步可能是 99%。4.3 软件层ASIL 等级对编码和测试的约束软件层的 ASIL 等级会影响编码规范、测试覆盖率和工具链。比如 ASIL D 通常要求语句覆盖、分支覆盖和 MC/DC 覆盖而 ASIL A 可能只要求语句覆盖和分支覆盖。工具链方面如果用了自动代码生成工具本身需要做鉴定或者对生成代码做额外验证。一个常见的翻车点是软件团队按 ASIL D 写了代码但测试只做了功能测试没有做 MC/DC。审核时被要求补测试用例结果发现代码结构太复杂MC/DC 用例数量爆炸。所以如果项目定了 ASIL D编码阶段就要控制圈复杂度避免深层嵌套和复杂条件表达式。4.4 ASIL 分解什么时候可以拆什么时候不能拆ASIL 分解允许把一个高等级需求拆成两个低等级需求比如 ASIL D 拆成 ASIL B(D) ASIL B(D)。但分解有条件两个独立通道必须充分独立不能共因失效。如果两个通道共用一个电源、一个时钟、一个芯片那分解就不成立。我一般会建议如果系统架构本身没有冗余就不要强行做 ASIL 分解老老实实按高等级做。分解看起来省成本但独立性论证的工作量往往比直接做还大而且审核方会重点盯共因失效分析。5. 避坑与排查ISO 26262 落地时最常见的五个问题这一章不按标准条款讲而是按实际项目里最常被卡住的五个点来写。每个点按“现象 → 原因 → 解决”展开方便直接对照排查。5.1 安全目标写成了功能描述现象安全目标写成“系统应提供转向助力”审核方直接判不符合。原因把“功能”和“安全目标”混为一谈。功能是系统本来就要做的事安全目标是防止危害事件发生。解决安全目标必须对应 HARA 里的危害事件写成“防止非预期失去助力”或“防止非预期助力过大”。写完后对照危害事件表看能不能一一对应。5.2 诊断覆盖率拍脑袋填现象FMEDA 里诊断覆盖率填了 99%但拿不出任何依据。原因芯片 Safety Manual 没看或者看了但没按实际使用的诊断机制取值。解决每个诊断覆盖率都要有来源。优先用芯片厂商给的推荐值如果没有就按标准里的方法估算并在文档里写清楚估算依据。审核方不一定要求你做到 99%但要求你能解释为什么是 90% 而不是 99%。5.3 安全需求没有追溯链现象审核时被问“这条软件需求对应哪个安全目标”答不上来。原因需求管理工具里没有建立追溯关系或者追溯关系是后补的对不上。解决从 HARA 开始就用需求管理工具建立追溯安全目标 → 系统安全需求 → 硬件/软件安全需求 → 测试用例一条链拉通。如果项目中期才发现没做至少要把已有关键需求补上追溯不要等审核前才补。5.4 共因失效分析被忽略现象做了冗余设计但两个通道共用一个电源审核不认。原因只关注了独立失效没做共因失效分析。解决冗余设计必须做共因失效分析常见方法包括 FTA、DFA 和依赖分析。如果两个通道无法做到充分独立就要在安全分析里说明并采取额外措施比如增加监控通道或降低 ASIL 分解的依赖。5.5 工具链鉴定被漏掉现象用了自动代码生成工具但没做工具鉴定审核要求补。原因以为工具只是辅助不需要鉴定。解决先判断工具是否影响安全相关代码。如果影响就要做工具鉴定或者对工具输出做独立验证。工具鉴定不是必须买认证证书也可以通过使用历史、测试和验证来论证。关键是文档里要有论证过程。6. 把标准中文版用起来一个可复现的落地检查清单标准中文版最大的价值不是读一遍而是变成项目里的检查清单。下面这套清单是我在多个项目里反复用过的按阶段排列每个阶段只列最关键的检查项。你可以直接拿去改也可以按项目裁剪。6.1 概念阶段检查项HARA 是否覆盖了所有整车功能和相关运行场景。S、E、C 打分是否有依据是否经过评审。安全目标是否对应危害事件是否分配了 ASIL 等级。是否定义了安全状态和故障容错时间。是否识别了功能安全与其它学科的接口比如网络安全、可靠性。6.2 系统层检查项系统安全需求是否从安全目标推导是否有追溯。是否定义了系统架构的安全机制比如冗余、监控、降级。是否做了系统层 FMEA 或 FTA。是否定义了安全验证计划包括测试方法和通过准则。是否识别了安全相关的外部接口比如传感器、执行器、通信。6.3 硬件层检查项是否做了 FMEDASPFM 和 LFM 是否满足目标 ASIL。诊断覆盖率是否有依据是否覆盖了所有安全相关元件。是否考虑了共因失效比如电源、时钟、温度。是否定义了硬件安全机制的自检和周期。是否按芯片 Safety Manual 使用了推荐的诊断。6.4 软件层检查项软件安全需求是否从系统安全需求推导是否有追溯。编码规范是否按目标 ASIL 裁剪圈复杂度是否受控。测试覆盖率是否满足目标 ASIL是否做了 MC/DC。是否做了软件 FMEA 或依赖分析。工具链是否做了鉴定或输出验证。6.5 支持过程检查项配置管理是否覆盖了安全相关的工作产品。变更管理是否评估了变更对功能安全的影响。文档管理是否保证了版本一致性和可追溯性。是否定义了安全案例的结构和证据清单。是否做了功能安全审核审核发现是否闭环。这套清单不能替代标准原文但能帮你在项目里快速定位“现在该做什么、做完没有、证据在哪”。标准中文版读起来枯燥但把它拆成检查项之后就变成了一张可执行的地图。6.6 一个具体技巧用追溯矩阵反向验证最后分享一个我常用的技巧不要只从安全目标往下推也要从测试用例往上反查。具体做法是把测试用例列表拿出来逐条问“这条用例验证的是哪条安全需求这条安全需求又来自哪个安全目标”如果有一条测试用例找不到对应的安全需求要么是需求漏了要么是测试多余了。如果有一条安全需求找不到对应的测试用例那就是验证覆盖不全。这个反向验证通常能在审核前发现不少问题尤其是那些“写了但没测”的安全需求。我一般会在项目中期做一次审核前再做一次两次结果对比能看出追溯链有没有在后期被改乱。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 11:04:55 · 阅读 1.2k ISO 26262 功能安全落地实战：从标准中文版到可执行检查清单
简介这份资源是《道路车辆功能安全——ISO26262标准解析》中文版PDF面向汽车电子、电气系统研发工程师、功能安全管理人员及高校相关专业学习者帮助系统理解ISO26262:2018标准框架与落地方法。压缩包内仅1个PDF文件约18.31MB内容完整覆盖标准适用范围与主要内容、功能安全管理、概念阶段、系统级产品开发、硬件级产品开发等章节并延伸至软件开发、生产服务、产品一致性及事故后分析改进等后续环节。目录结构清晰从项目定义、安全生命周期、危险分析与风险评估到技术安全需求制定、系统设计、集成测试、安全确认与功能安全评估逐层展开便于按模块查阅与对照实践。目前已有2163人学习下载适合需要建立功能安全知识体系、准备项目合规审查或开展安全设计参考的读者使用。1. 道路车辆功能安全 ISO 26262从标准中文版到可落地执行做汽车电子的人几乎都经历过这样的场景项目评审会上客户或审核方突然问一句“这个 ECU 的 ASIL 等级怎么定的安全目标覆盖了哪些失效模式”如果平时只把 ISO 26262 当成一份“要交的文档”这时候大概率会卡壳。ISO 26262 是道路车辆功能安全的国际标准中文版通常指 GB/T 34590 系列它把整车到芯片的整条链路拆成了概念、系统、硬件、软件、支持过程、ASIL 导向分析等部分。它解决的不是“怎么让零件不坏”而是“坏了之后车不能出人命”这套逻辑怎么被证明。适合谁看做域控制器、BMS、EPS、ADAS 的软硬件工程师以及需要写安全计划、做安全分析、应对审核的功能安全工程师。这篇笔记不空谈条款而是把标准中文版里最常被用到的部分拆成能直接抄的流程、参数和排查清单。2. 先分清 ISO 26262 的 Part 与 GB/T 34590 的对应关系很多人一上来就翻“中文版”结果发现目录对不上越看越乱。原因很简单ISO 26262 是国际标准国内等同转化后是 GB/T 34590 系列两者章节结构基本一致但编号和措辞有差异。如果你手里拿的是 ISO 26262 的英文版却按 GB/T 34590 的条款号去引用评审时就会被挑出“引用不一致”的问题。所以第一步不是背条款而是先把“你要用哪一版、哪一部分”锁死。2.1 标准十二个 Part 各自管什么ISO 26262 目前常见的是 2018 版分为 12 个 Part。做落地时不需要全部精读但必须知道每个 Part 的边界否则很容易把系统层的安全需求写到软件层去或者把支持过程当成开发过程。Part中文版对应主要管什么谁最该看Part 1GB/T 34590.1术语、词汇所有人Part 2GB/T 34590.2功能安全管理功能安全经理、项目经理Part 3GB/T 34590.3概念阶段、HARA系统工程师、安全工程师Part 4GB/T 34590.4系统层开发系统架构师Part 5GB/T 34590.5硬件层开发硬件工程师Part 6GB/T 34590.6软件层开发嵌入式软件工程师Part 7GB/T 34590.7生产、运行、服务制造与售后Part 8GB/T 34590.8支持过程配置管理、变更管理Part 9GB/T 34590.9ASIL 导向与安全分析安全分析人员Part 10GB/T 34590.10指南新手入门Part 11GB/T 34590.11半导体应用指南芯片与底层驱动Part 12GB/T 34590.12摩托车两轮车相关这张表的价值在于当你接到“把这个功能做到 ASIL D”的需求时能立刻判断出该翻 Part 3 定目标、Part 4 拆系统、Part 5 和 Part 6 分别约束硬件和软件而不是抱着一本合订本从头翻到尾。2.2 中文版和英文版混用时最容易踩的引用坑常见做法是公司内部模板用 GB/T 34590 的条款号但供应商给的 Safety Manual 引用的是 ISO 26262 的 Part 号。这时候如果直接复制粘贴就会出现“GB/T 34590.5-2022 的 7.4.3”和“ISO 26262-5:2018 Clause 7.4.3”混在一份文档里。审核方不一定判你不符合但会要求你解释对应关系平白增加工作量。我一般会建议团队在安全计划里加一张“引用映射表”把项目里用到的每一条标准要求同时标出 ISO 和 GB/T 的编号。这样无论审核方习惯看哪一版都能对上。映射表不需要覆盖全部条款只覆盖项目实际裁剪后保留的部分即可通常几十行就够。2.3 裁剪不是所有项目都要从 Part 1 做到 Part 12ISO 26262 允许裁剪但裁剪必须有理由。比如一个纯软件组件如果它不直接控制执行器也不涉及安全目标那 Part 5 硬件层的要求可能就不适用。但“不适用”不等于“不写”而是要在安全计划里写清楚为什么裁剪、裁剪后如何保证安全目标仍然被覆盖。常见做法是先根据 HARA 定出 ASIL 等级再按 ASIL 等级查 Part 4、Part 5、Part 6 里对应的要求表。ASIL A 和 ASIL D 在测试覆盖率、方法推荐度上的要求差别很大。如果一上来就按 ASIL D 全量做时间和成本会失控如果该做 ASIL D 却按 QM 做审核又过不了。所以裁剪的前提是 HARA 做扎实。3. 用 HARA 把安全目标定出来S、E、C 三个参数怎么打分HARA危害分析与风险评估是整条链路的起点。如果 HARA 做错了后面所有安全需求、安全机制、测试用例都是空中楼阁。很多团队 HARA 做得敷衍结果到系统层发现安全目标根本没法拆只能回头重做血泪经验就是HARA 阶段多花两天后面省两周。3.1 S、E、C 的定义与打分表HARA 的核心是对每个危害事件打三个分严重度 S、暴露率 E、可控性 C。三个分确定后查表得到 ASIL 等级。严重度 S等级描述典型后果S0无伤害仅财产损失S1轻中度伤害轻微擦伤、低速碰撞S2重度伤害骨折、危及生命的伤害但通常可存活S3致命伤害可能致死暴露率 E等级描述典型场景E0极低概率几乎不可能发生E1低概率一年几次E2中等概率一月几次E3高概率几乎每天E4极高概率每次驾驶都发生可控性 C等级描述驾驶员能否避免伤害C0完全可控一般驾驶员都能控制C1简单可控稍微操作就能避免C2一般可控需要一定反应和操作C3难以控制大多数驾驶员无法避免打分时最容易出问题的是 C。很多团队把 C 打成 C1理由是“驾驶员应该能反应过来”但标准要求的是“一般驾驶员在典型场景下”的可控性不是“专业驾驶员在理想条件下”。如果场景是高速上突然失去助力C 通常至少是 C2 甚至 C3。3.2 从危害事件到安全目标的转换打完分后查 ASIL 表得到等级。比如 S3 E4 C3 ASIL DS2 E3 C2 ASIL BS1 E2 C1 QM。得到 ASIL 后要把它写成安全目标。安全目标不是“防止失效”而是“防止危害事件发生”。举个例子某电子助力转向系统危害事件是“车辆在高速行驶时突然失去转向助力”。S3、E4、C3ASIL D。安全目标可以写成“防止在车辆行驶过程中非预期地失去转向助力ASIL D。”注意这里没有写“助力电机不能坏”因为电机坏不一定导致失去助力可能只是助力下降。安全目标要对应危害事件而不是对应零部件。3.3 一个可复用的 HARA 表格模板下面这个表格结构可以直接拿去用列名和顺序按常见审核习惯排危害事件编号 | 整车功能 | 危害事件描述 | 运行场景 | S | E | C | ASIL | 安全目标 | 安全状态 | 故障容错时间其中“故障容错时间”是很多团队会漏掉的一列。它指的是从故障发生到危害事件发生之间允许的时间窗口。这个时间直接决定系统层要不要做冗余、软件层要不要做快速检测。比如故障容错时间 100ms那软件检测周期就不能是 200ms否则还没检测到就已经出事了。4. 系统层与软硬件层怎么拆安全需求、安全机制与 ASIL 分解HARA 定完安全目标后下一步是把它拆成系统层安全需求再拆到硬件和软件。这一步最容易出现“需求写得太虚”的问题比如“系统应保证安全”这种话写了等于没写。可执行的安全需求必须能对应到具体的检测机制、响应动作和验证方法。4.1 安全需求从安全目标推导的写法安全目标“防止非预期失去转向助力”可以拆成几条系统层安全需求系统应在检测到助力电机驱动故障后 20ms 内进入安全状态。系统应能检测助力扭矩传感器信号丢失或超出合理范围。系统应在检测到供电电压异常时限制助力输出并点亮警告灯。每条需求都要有 ASIL 等级、验证方法和来源追溯。来源追溯就是指向对应的安全目标这样审核时能看出需求不是拍脑袋写的。4.2 硬件层FMEDA 与诊断覆盖率硬件层最常被问到的是 FMEDA失效模式、影响与诊断分析。它的作用是计算硬件的单点故障指标 SPFM 和潜伏故障指标 LFM。ASIL D 要求 SPFM ≥ 99%LFM ≥ 90%ASIL C 要求 SPFM ≥ 97%LFM ≥ 80%ASIL B 要求 SPFM ≥ 90%LFM ≥ 60%。做 FMEDA 时每个硬件元件都要列出失效模式、失效率、诊断覆盖率和是否安全相关。诊断覆盖率 DC 的取值不是随便填的通常参考芯片 Safety Manual 或标准里的推荐值。如果芯片厂商没给就要自己根据诊断机制估算比如看门狗对 CPU 的 DC 可能是 60%而双核锁步可能是 99%。4.3 软件层ASIL 等级对编码和测试的约束软件层的 ASIL 等级会影响编码规范、测试覆盖率和工具链。比如 ASIL D 通常要求语句覆盖、分支覆盖和 MC/DC 覆盖而 ASIL A 可能只要求语句覆盖和分支覆盖。工具链方面如果用了自动代码生成工具本身需要做鉴定或者对生成代码做额外验证。一个常见的翻车点是软件团队按 ASIL D 写了代码但测试只做了功能测试没有做 MC/DC。审核时被要求补测试用例结果发现代码结构太复杂MC/DC 用例数量爆炸。所以如果项目定了 ASIL D编码阶段就要控制圈复杂度避免深层嵌套和复杂条件表达式。4.4 ASIL 分解什么时候可以拆什么时候不能拆ASIL 分解允许把一个高等级需求拆成两个低等级需求比如 ASIL D 拆成 ASIL B(D) ASIL B(D)。但分解有条件两个独立通道必须充分独立不能共因失效。如果两个通道共用一个电源、一个时钟、一个芯片那分解就不成立。我一般会建议如果系统架构本身没有冗余就不要强行做 ASIL 分解老老实实按高等级做。分解看起来省成本但独立性论证的工作量往往比直接做还大而且审核方会重点盯共因失效分析。5. 避坑与排查ISO 26262 落地时最常见的五个问题这一章不按标准条款讲而是按实际项目里最常被卡住的五个点来写。每个点按“现象 → 原因 → 解决”展开方便直接对照排查。5.1 安全目标写成了功能描述现象安全目标写成“系统应提供转向助力”审核方直接判不符合。原因把“功能”和“安全目标”混为一谈。功能是系统本来就要做的事安全目标是防止危害事件发生。解决安全目标必须对应 HARA 里的危害事件写成“防止非预期失去助力”或“防止非预期助力过大”。写完后对照危害事件表看能不能一一对应。5.2 诊断覆盖率拍脑袋填现象FMEDA 里诊断覆盖率填了 99%但拿不出任何依据。原因芯片 Safety Manual 没看或者看了但没按实际使用的诊断机制取值。解决每个诊断覆盖率都要有来源。优先用芯片厂商给的推荐值如果没有就按标准里的方法估算并在文档里写清楚估算依据。审核方不一定要求你做到 99%但要求你能解释为什么是 90% 而不是 99%。5.3 安全需求没有追溯链现象审核时被问“这条软件需求对应哪个安全目标”答不上来。原因需求管理工具里没有建立追溯关系或者追溯关系是后补的对不上。解决从 HARA 开始就用需求管理工具建立追溯安全目标 → 系统安全需求 → 硬件/软件安全需求 → 测试用例一条链拉通。如果项目中期才发现没做至少要把已有关键需求补上追溯不要等审核前才补。5.4 共因失效分析被忽略现象做了冗余设计但两个通道共用一个电源审核不认。原因只关注了独立失效没做共因失效分析。解决冗余设计必须做共因失效分析常见方法包括 FTA、DFA 和依赖分析。如果两个通道无法做到充分独立就要在安全分析里说明并采取额外措施比如增加监控通道或降低 ASIL 分解的依赖。5.5 工具链鉴定被漏掉现象用了自动代码生成工具但没做工具鉴定审核要求补。原因以为工具只是辅助不需要鉴定。解决先判断工具是否影响安全相关代码。如果影响就要做工具鉴定或者对工具输出做独立验证。工具鉴定不是必须买认证证书也可以通过使用历史、测试和验证来论证。关键是文档里要有论证过程。6. 把标准中文版用起来一个可复现的落地检查清单标准中文版最大的价值不是读一遍而是变成项目里的检查清单。下面这套清单是我在多个项目里反复用过的按阶段排列每个阶段只列最关键的检查项。你可以直接拿去改也可以按项目裁剪。6.1 概念阶段检查项HARA 是否覆盖了所有整车功能和相关运行场景。S、E、C 打分是否有依据是否经过评审。安全目标是否对应危害事件是否分配了 ASIL 等级。是否定义了安全状态和故障容错时间。是否识别了功能安全与其它学科的接口比如网络安全、可靠性。6.2 系统层检查项系统安全需求是否从安全目标推导是否有追溯。是否定义了系统架构的安全机制比如冗余、监控、降级。是否做了系统层 FMEA 或 FTA。是否定义了安全验证计划包括测试方法和通过准则。是否识别了安全相关的外部接口比如传感器、执行器、通信。6.3 硬件层检查项是否做了 FMEDASPFM 和 LFM 是否满足目标 ASIL。诊断覆盖率是否有依据是否覆盖了所有安全相关元件。是否考虑了共因失效比如电源、时钟、温度。是否定义了硬件安全机制的自检和周期。是否按芯片 Safety Manual 使用了推荐的诊断。6.4 软件层检查项软件安全需求是否从系统安全需求推导是否有追溯。编码规范是否按目标 ASIL 裁剪圈复杂度是否受控。测试覆盖率是否满足目标 ASIL是否做了 MC/DC。是否做了软件 FMEA 或依赖分析。工具链是否做了鉴定或输出验证。6.5 支持过程检查项配置管理是否覆盖了安全相关的工作产品。变更管理是否评估了变更对功能安全的影响。文档管理是否保证了版本一致性和可追溯性。是否定义了安全案例的结构和证据清单。是否做了功能安全审核审核发现是否闭环。这套清单不能替代标准原文但能帮你在项目里快速定位“现在该做什么、做完没有、证据在哪”。标准中文版读起来枯燥但把它拆成检查项之后就变成了一张可执行的地图。6.6 一个具体技巧用追溯矩阵反向验证最后分享一个我常用的技巧不要只从安全目标往下推也要从测试用例往上反查。具体做法是把测试用例列表拿出来逐条问“这条用例验证的是哪条安全需求这条安全需求又来自哪个安全目标”如果有一条测试用例找不到对应的安全需求要么是需求漏了要么是测试多余了。如果有一条安全需求找不到对应的测试用例那就是验证覆盖不全。这个反向验证通常能在审核前发现不少问题尤其是那些“写了但没测”的安全需求。我一般会在项目中期做一次审核前再做一次两次结果对比能看出追溯链有没有在后期被改乱。希望帮到你。本文还有配套的精品资源点击获取