一、ISO 26262是什么
ISO 26262是一项针对道路车辆电子与电气（E/E）系统功能安全的国际标准。最新有效版本为 ISO 26262:2018，国内等同转化为强制性推荐国标 GB/T 34590《道路车辆 功能安全》。该标准脱胎于通用工业功能安全标准 IEC 61508，是汽车行业电子电气系统安全开发的纲领性框架，核心目标是通过覆盖产品全生命周期的流程管控，规避电子电气系统功能异常表现引发的危害，将车辆安全风险控制在可接受的合理范围内。
该标准覆盖了功能安全需求的规划、设计、实施、集成、验证、确认、配置等关键环节，旨在通过全面的开发流程来降低汽车电子电气系统失效的风险。
ISO 26262第一版于2011年发布，第二版于2018年12月正式发布。目前，第三版的制定工作正在进行，预计2027年正式发布。
针对行业核心的两类认证，此处仅作基础定义区分：
•流程认证（体系 / 能力认证）： 针对企业功能安全管理体系与开发能力的符合性认证，证明企业具备按照标准开展对应 ASIL 等级产品开发的组织能力；
•产品认证： 针对特定型号 / 版本的零部件 / 系统，对其全生命周期开发过程、设计方案、验证结果的专项符合性认证，证明该特定产品满足对应 ASIL 等级的功能安全要求。
二、为什么要做ISO 26262
2.1 主机厂（OEM）为什么要做
从主机厂的角度，做ISO 26262有以下几方面原因：
1.市场准入的硬性要求。 ISO 26262 虽为国际推荐性标准，但已通过全球主要汽车市场的法规转化为市场准入的强制要求。国内《新能源汽车生产企业及产品准入管理规则》明确要求企业建立电子电气系统功能安全管控体系，欧盟、北美等出口市场也已将功能安全要求纳入车辆型式核准的核心条款。
2.降低召回风险和品牌损失。 近年来，汽车软件相关的召回事件占比持续上升。功能安全的系统化落地有助于在产品开发早期发现和消除潜在危害，减少量产后的召回成本。
3.构建整车级安全体系。 随着车辆电子电气系统复杂度提升，主机厂需要建立覆盖整车功能安全概念开发、供应商管理和整车级验证的安全能力体系。没有完整的整车级功能安全管控能力，难以确保系统集成后的整体安全性。
4.法规合规与出海需求。 车辆出口欧洲等市场时，需满足ECE相关认证要求，功能安全合规是其中重要组成部分。
2.2 零部件供应商为什么要做
从零部件供应商的角度，功能安全合规的意义同样明确：
供应链准入门槛。 ISO 26262功能安全认证已成为电子零部件供应商进入汽车行业的先决条件。在2026年的行业环境下，该认证已从“加分项”变为进入全球主流OEM供应链的核心“入场券”。在招标时已将ISO 26262合规作为关键评估指标。对于以往未强调功能安全设计的模块级产品（如灯光控制器、HVAC模块、座椅调节模块等），如今也被要求提供安全设计证据才能融入整车安全架构。
提升开发质量和效率。遵循功能安全流程的产品开发，在需求追溯、设计验证和测试覆盖等方面更加系统化，有助于降低后期缺陷和设计变更的成本。
2.3 哪些零部件要做、做什么等级
功能安全的适用范围覆盖了广泛的车载电子电气产品。以下按典型零部件类型列出常见等级要求：
编辑
需要注意的是，实际等级需通过HARA分析确定，同一产品中不同功能也可能对应不同的ASIL等级。
具体如何确定等级请参考 汽车零部件功能安全ASIL等级确定方法（二）
三、供应商收到功能安全需求后必须与客户确认的核心事项
功能安全需求的确认是项目成功的关键起点。功能安全需求（FSR）必须由主机厂和供应商共同商讨定义——主机厂主导安全目标的提出，供应商提供技术可行性反馈，双方通过协商确保FSR合理、可实施，并在接口协议（DIA）中固化责任分工。
建议在项目启动阶段使用以下Checklist逐项与客户确认：
1. 项目周期与里程碑节点
- 项目整体时间计划（SOP时间点、样件节点、验证节点）
- 功能安全交付物在各阶段的提交时间要求
- 安全里程碑评审（Safety Milestone Review）的时间安排
- 功能安全评估报告的完成节点
2. 认证类型与范围确认
- 本项目是否需要认证：仅流程认证、仅产品认证、还是两者都需要
- 认证机构要求：是否有指定的第三方认证机构（如TÜV、DEKRA、UL等），还是客户接受供应商自选
- 认证交付物清单与验收标准
- 如需产品认证，明确认证范围覆盖的产品/功能边界,明确是完整产品全新开发，还是部分软件 / 硬件模块的开发，或是现有产品的功能安全适配；
- 确认产品生命周期阶段，是否涉及继承件、复用件的开发，以及复用件的安全评估要求与责任划分。
3. 责任范围与DIA签署
- 签署DIA（开发接口协议），明确双方在功能安全活动中的责任边界
- 明确哪些安全活动由主机厂完成，哪些由供应商完成
- 明确安全管理、安全分析、验证测试等工作的责任分配
- 明确接口协议中FSR分配、验收标准和验证责任
4. ASIL等级确认
- 产品/功能的目标ASIL等级（QM/A/B/C/D）
- 等级是否有进一步细分（如子功能不同等级）
- 等级是否有协商调整的空间（基于技术可行性或成本因素）
5. 安全目标与FSR确认
- 主机厂提供的安全目标清单（基于HARA分析）
- FSR的完整性与合理性评审
- FSR技术可行性评估与修改建议
- 安全机制的责任分工（哪些由主机厂负责，哪些由供应商实现）
- FSR的验证方法和验收标准
6. 交付物清单与格式要求
- 功能安全工作产品（Work Product）的完整清单
- 各交付物的模板格式要求
- 文档语言要求
- 评审与签批流程
7. 测试与验证要求
- 系统级集成测试要求
- HIL测试范围与用例数量
- 故障注入测试要求
- 整车级验证的参与范围
8. 评审与审核安排
- 功能安全评审会的时间与频次
- 功能安全审计的时间安排
- 供应商现场审核的计划
- 客户参与评审的人员要求
9. 变更管理流程
- FSR变更时的同步更新流程
- 设计变更对安全影响的评估流程
- 变更通知与审批机制
10. 安全档案与证据管理
- Safety Case的结构与内容要求
- 安全证据的保存方式与周期
- 需求追溯矩阵（RTM）的格式与维护方式
11. 预算与资源
- 功能安全专项预算的确认
- 是否需要额外的人力资源配置
- 认证费用的承担方
12. 第三方工具与软件
- 开发工具是否需要通过工具鉴定
- 使用的第三方软件组件是否需要符合功能安全要求
- 软件组件的鉴定方法和认证条件
四、ISO 26262如何落地
4.1 落地的核心步骤
ISO 26262的实施贯穿汽车安全全生命周期，覆盖管理、开发、生产、运行、服务及报废等关键阶段。主要实施步骤如下：
编辑
步骤一：差距分析（Gap Analysis）
评估企业现有研发流程与ISO 26262标准的差异，明确需要补充和改进的环节。这是整个功能安全实施的基础工作。
步骤二：体系建立
建立符合功能安全要求的管理手册、程序文件和模板，包括：
- 功能安全手册和组织架构定义
- 功能安全计划编制
- 人员能力管理和培训体系
- 供应商管理流程
- 配置管理和变更管理流程
- 文档管理规范
步骤三：概念阶段开发
- 相关项定义（Item Definition）
- 危害分析与风险评估（HARA）
- 确定安全目标（Safety Goals）
- 制定功能安全概念（FSC）
步骤四：系统阶段开发
系统阶段的核心任务是基于概念阶段输出的功能安全概念，进一步细化安全需求，设计技术安全方案，并通过集成测试验证方案的可行性。主要活动包括：
- 制定技术安全需求（TSR）
- 开发技术安全概念（TSC）
- 系统架构设计与安全分析（FMEA、FTA等）
- 系统集成与测试
- 整车级集成测试
步骤五：硬件开发
- 硬件安全需求制定
- 硬件架构设计与安全分析
- 硬件详细设计与实现
- 硬件架构度量和失效率评估（SPFM、LFM、PMHF）
- 硬件集成与测试
步骤六：软件开发
- 软件安全需求制定
- 软件架构设计
- 软件单元设计与实现
- 软件单元测试
- 软件集成与测试
- 软件安全需求验证
步骤七：安全确认
- 安全目标验证
- 安全确认评审
- Safety Case编制
步骤八：认证审核
- 选择认证机构（如TÜV、SGS、DEKRA、UL等）
- 提交安全档案
- 现场审核
- 整改与发证
4.2 责任范围确定
企业在实施功能安全流程时，需要明确自身产品需满足ISO 26262要求中的哪一部分。汽车制造商可能需要涵盖ISO 26262所有部分的流程，大型供应商可能需要大致相同的流程或从系统开发开始，而中小型供应商可能只负责子系统、硬件或软件部分。
对于中小供应商而言，由于人力和预算资源有限，应首先关注目前可以预测的产品和发展模式，实施能够应对这些情况的流程。
4.3 开发模式
ISO 26262采用V模型开发流程，左侧为需求分解与设计（从上到下），右侧为集成与验证（从下到上），两者并行推进。每个阶段都对应相应的验证活动，确保需求到实现的可追溯性。
4.4 周期一般是多久
功能安全落地的时间周期因企业起点和项目复杂度以及人员能力不同而存在较大差异：
编辑
流程体系建立周期： 对于从零开始建立功能安全开发流程体系的企业，完整建立一套覆盖ASIL D等级的流程体系,在条件具备的情况下，部分企业可在8个月左右完成流程体系搭建和认证。
编辑
产品项目开发周期： 功能安全活动需嵌入产品开发全过程，不会显著延长整体开发周期（通常与常规开发并行），但会增加以下环节的时间投入，：
- HARA分析和安全目标确定（约1至2个月）
- 功能安全概念和技术安全概念制定（约1至3个月）
- 安全分析（FMEA、FTA等，贯穿开发全过程）
- 安全验证与测试（增量时间因ASIL等级而异，ASIL D级可能需要增加30%至50%的测试工作量）
认证审核周期： 在流程体系或产品开发完成后，认证机构的审核通常需要1至3个月，包括文档评审、现场审核和整改闭环。
部分企业通过引入基于模型的设计等先进方法，可将开发和认证时间缩短约30%。
五、功能安全落地全流程常见问题及解答
以下整理了ISO 26262实施过程中供应商最常遇到的典型问题和实务解答：
Q1：供应商只有流程认证证书，客户要求做产品认证怎么办？
A：流程认证证明的是企业具备按照功能安全流程开发产品的能力，产品认证证明的是具体产品符合功能安全要求。两者范围不同，不能相互替代。当客户要求产品认证时，需要针对该具体产品按ISO 26262要求开展完整的开发活动并生成Safety Case，然后提交认证机构进行产品审核。需要注意的是，流程认证不能免除为支持客户需求而进行产品或工作产品变更的义务。
Q2：如何界定主机厂和供应商的功能安全责任边界？
A：责任边界通过DIA（开发接口协议）正式约定。ISO 26262第8部分第5节“分布式开发中的接口”规定了双方在产品开发前必须达成的各项要求，包括技术信息和管理要素（责任范围、流程和定制细节等）。建议在DIA中明确以下内容：安全目标的责任方、FSR的分配与验收标准、安全分析的责任分工、验证测试的责任分工、工作产品的交付范围等。
Q3：收到客户的FSR后发现技术不可行，怎么办？
A：应在收到FSR后尽快向客户反馈，提供技术分析报告说明不可行的原因（如硬件资源限制、响应时间无法满足、失效率要求过高等），并提出修改建议或替代方案。可能的解决路径包括：通过架构改进或冗余设计分散风险、调整安全目标（如放宽故障响应时间）、引入第三方技术支持等。所有讨论结果应记录在联合评审记录中。
Q4：中小供应商资源有限，如何高效落地功能安全？
A：建议分步实施：首先明确企业产品需满足ISO 26262的哪一部分要求，缩小目标范围。很多中小供应商只负责子系统、硬件或软件部分，不需要建立覆盖所有部分的完整流程。其次，可优先关注现有产品的功能安全升级需求，而不是试图一次性建立应对所有产品模式的完整体系。此外，对于中等复杂度的硬件组件和商用软件库，如果符合ISO 26262第8部分第12、13节的鉴定要求，可由采用方进行鉴定后集成使用，供应商自身无需建立完整的功能安全流程。
Q5：功能安全需求变更后，如何管理？
A：需要建立正式的变更管理流程，包括：变更影响分析（评估对安全目标、已实施安全机制和已有验证结果的影响）、变更评审与批准、相关文档和追溯矩阵的同步更新、验证活动的重新执行。ISO 26262第8部分对变更管理有明确要求，变更后的工作产品需保持完整的可追溯性。
Q6：国际认证机构的认证证书在国内是否被认可？
A：国际主流认证机构（如TÜV、SGS、DEKRA、UL等）颁发的ISO 26262证书在全球范围内被广泛接受。需要注意的是，不同主机厂可能对认证机构有不同偏好或指定要求，建议在项目启动阶段与客户确认是否有指定的认证机构要求。
Q7：Safety Case应该包含哪些内容？
A：Safety Case是证明产品满足功能安全目标的完整档案，通常包含：相关项定义、HARA报告和安全目标、功能安全概念和技术安全概念、硬件和软件安全需求及设计文档、安全分析报告（FMEA、FTA、DFA等）、验证和确认报告、测试报告、安全里程碑评审记录、功能安全评估报告等。Safety Case的结构和内容应根据ASIL等级和认证范围进行定制。
Q8：使用第三方开发工具需要做工具鉴定吗？
A：需要根据工具的置信度（Tool Confidence Level, TCL）来确定。ISO 26262第8部分第11节对软件工具的鉴定有详细要求。如果工具使用不当可能影响安全，同时工具本身无法对自身错误进行有效措施，则需要进行工具鉴定。工具鉴定的严格程度取决于ASIL等级和工具置信度水平（TCL1/TCL2/TCL3）。建议在功能安全计划中明确所使用的工具及其鉴定要求。
Q9：ISO 26262:2018版与2011版的主要差异是什么？是否必须按新版执行？
A：主要差异包括：新增Part 11“半导体开发指南”，适用范围扩展到卡车、客车和摩托车，修订了硬件鉴定术语，增加了功能安全、网络安全等相关组织之间“有效沟通渠道”的要求。目前行业普遍采用2018版，主机厂的采购要求也大多明确要求按2018版执行。建议新项目以2018版为标准，已按2011版开发的项目需与客户确认是否需要升级。
Q10：ISO 26262第三版即将发布，现在启动项目是否应该等待新版？
A：第三版预计2027年正式发布，当前启动的项目仍应以ISO 26262:2018版为准。新版标准预计将涵盖人工智能和机器学习、预测性维护、失效运行架构等内容，但与2018版的核心框架保持延续。届时可通过变更管理流程进行过渡升级，无需等待。
Q11：功能安全活动是否会显著增加项目成本？
A：功能安全的引入确实会增加一定的开发和认证成本，主要体现在：专职功能安全人员的人力成本、实现安全机制的技术成本、安全分析和测试的额外工作量、认证审核费用等。但功能安全流程也有助于在早期发现设计缺陷，减少后期的设计变更和召回成本。实际成本增加幅度因ASIL等级和项目复杂度而异，建议在项目立项阶段做好预算规划。
Q12：客户要求的功能安全等级过高，如何协商？
A：ASIL等级基于HARA分析得出，具有一定的客观依据，并非主观决定。如果供应商认为客户要求的等级与产品实际风险不匹配，可以建议双方共同对HARA进行复核，通过调整危害分析中的假设条件（如可控性评估、暴露率估算等）来重新评估等级。也可以通过引入外部安全机制或冗余设计来分散风险(ASIL等级分解)，从而降低对单个部件的ASIL要求。所有协商过程和结论应记录在案，并经双方确认。
以上内容基于ISO 26262:2018版标准要求和行业实践整理。由于不同项目和不同客户的具体要求可能存在差异，建议在实际项目中与客户和认证机构保持密切沟通，确保功能安全活动的顺利开展。
以上为本次技术分享，后续相关专题文章将持续更新，欢迎关注交流。
