企业官网建设流程全解析

简介：这份资源是《道路车辆功能安全——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 的边界，否则很容易把系统层的安全需求写到软件层去，或者把支持过程当成开发过程。

这张表的价值在于：当你接到“把这个功能做到 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 12

ISO 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：

暴露率 E：

可控性 C：

打分时最容易出问题的是 C。很多团队把 C 打成 C1，理由是“驾驶员应该能反应过来”，但标准要求的是“一般驾驶员在典型场景下”的可控性，不是“专业驾驶员在理想条件下”。如果场景是高速上突然失去助力，C 通常至少是 C2 甚至 C3。

3.2 从危害事件到安全目标的转换

打完分后，查 ASIL 表得到等级。比如 S3 + E4 + C3 = ASIL D，S2 + E3 + C2 = ASIL B，S1 + E2 + C1 = QM。得到 ASIL 后，要把它写成安全目标。安全目标不是“防止失效”，而是“防止危害事件发生”。

举个例子：某电子助力转向系统，危害事件是“车辆在高速行驶时突然失去转向助力”。S3、E4、C3，ASIL 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 硬件层检查项

• 是否做了 FMEDA，SPFM 和 LFM 是否满足目标 ASIL。
• 诊断覆盖率是否有依据，是否覆盖了所有安全相关元件。
• 是否考虑了共因失效，比如电源、时钟、温度。
• 是否定义了硬件安全机制的自检和周期。
• 是否按芯片 Safety Manual 使用了推荐的诊断。

6.4 软件层检查项

• 软件安全需求是否从系统安全需求推导，是否有追溯。
• 编码规范是否按目标 ASIL 裁剪，圈复杂度是否受控。
• 测试覆盖率是否满足目标 ASIL，是否做了 MC/DC。
• 是否做了软件 FMEA 或依赖分析。
• 工具链是否做了鉴定或输出验证。

6.5 支持过程检查项

• 配置管理是否覆盖了安全相关的工作产品。
• 变更管理是否评估了变更对功能安全的影响。
• 文档管理是否保证了版本一致性和可追溯性。
• 是否定义了安全案例的结构和证据清单。
• 是否做了功能安全审核，审核发现是否闭环。

这套清单不能替代标准原文，但能帮你在项目里快速定位“现在该做什么、做完没有、证据在哪”。标准中文版读起来枯燥，但把它拆成检查项之后，就变成了一张可执行的地图。

6.6 一个具体技巧：用追溯矩阵反向验证

最后分享一个我常用的技巧：不要只从安全目标往下推，也要从测试用例往上反查。具体做法是，把测试用例列表拿出来，逐条问“这条用例验证的是哪条安全需求？这条安全需求又来自哪个安全目标？”如果有一条测试用例找不到对应的安全需求，要么是需求漏了，要么是测试多余了。如果有一条安全需求找不到对应的测试用例，那就是验证覆盖不全。

这个反向验证通常能在审核前发现不少问题，尤其是那些“写了但没测”的安全需求。我一般会在项目中期做一次，审核前再做一次，两次结果对比，能看出追溯链有没有在后期被改乱。希望帮到你。

本文还有配套的精品资源，点击获取