02_汽车行业的功能安全标准: ISO 26262
- 一、ISO 26262的诞生背景与版本演进
- 二、标准结构全景图：10+1部分框架与产业角色映射
- 三、ISO 26262:2018 各章节解读
- Part 1：术语（Vocabulary）
- Part 2：功能安全管理（Management of Functional Safety）
- Part 3：概念阶段（Concept Phase）
- Part 4：系统级开发（Product Development at System Level）
- Part 5：硬件级开发（Product Development at Hardware Level）
- Part 6：软件级开发（Product Development at Software Level）
- Part 7：生产与运行（Production and Operation）
- Part 8：支持过程（Supporting Processes）
- Part 9：面向ASIL的分析（ASIL-Oriented and Safety-Oriented Analysis）
- Part 10：指南（Guideline）
- Part 11：半导体指南（新增于2018版）
- 四、总结：标准的核心价值与行业应用建议
一、ISO 26262的诞生背景与版本演进
在现代密切分工的工业体系下，大家共同遵循的指导标准更有利于大型设备产品的开发和维护,在实现功能安全方面上，我们需要一套统一的标准或者体系，这个标准应被行业广泛认可,汽车领域的ISO 26262由此诞生。
1. 诞生背景
功能安全方法论起源于IEC 61508通用标准，它是由国际电工委员会发布的一项国际标准，包含如何应用、设计、部署和维护安全相关系统或自动保护系统的方法。基于该标准，其他细分行业的标准都是在此基础上的衍生或者再规范。其中，国际标准ISO 26262是汽车行业的工程师必关注的一个。
- 技术驱动：2000年后汽车电子渗透率激增（如ABS/ESP系统），但E/E系统失效引发的召回事件频发（如制动失控、转向故障），暴露了电子系统可靠性缺陷。
- 标准空白：通用工业安全标准IEC 61508缺乏汽车场景适配性，无法覆盖车辆动态环境、驾驶员交互等特有风险。
- 行业共识：2005年由ISO/TC22 SC3 WG16工作组联合30余家车企启动制定，2011年正式发布首版，成为全球首个针对量产乘用车E/E系统的功能安全标准。
2. 核心版本差异
| 维度 | ISO 26262:2011 | ISO 26262:2018 |
|---|---|---|
| 适用范围 | 仅限乘用车（≤3.5吨） | 扩展至摩托车、卡车、巴士 |
| 新增内容 | 基础框架（10部分） | 增补半导体指南（Part 11）、强化软件安全分析、相关失效分析（DFA） |
| 关键深化 | ASIL分级（S/E/C参数） | 细化ASIL分解规则、明确软硬件接口（HSI）要求 |
| 自动驾驶适配 | 未考虑无人驾驶场景 | 新增L3级自动驾驶系统安全分析导则 |
二、标准结构全景图：10+1部分框架与产业角色映射
核心适用对象与阶段定位
| 角色 | 重点章节 | 核心责任 |
|---|---|---|
| 整车厂（OEM） | Part 3（概念）、Part 9（分析） | 主导HARA分析、定义安全目标（ASIL D级决策） |
| Tier 1供应商 | Part 4~6（系统/软硬件） | 实现技术安全需求（TSR）、设计安全机制 |
| 半导体厂商 | Part 5（硬件）、Part 11 | 提供ASIL B/D Ready IP、硬件失效率数据 |
| 工具链认证机构 | Part 8（支持过程） | 评估开发工具置信度（TCL） |
三、ISO 26262:2018 各章节解读
ISO26262的重点内容为第4到第6部分，这部分对应了研发流程，从系统级、硬件和软件级三个部分，对功能安全的研发给出了明确指导。
在汽车工业体系下，OEM厂商统筹分析风险源、风险项，并分配安全等级要求到各个下级零部件开发商，下游零部件开发商始终围绕着第4到第6部分进行开发维护工作，并接受OEM的过程评审。
安全等级是ISO26262中的重要概念，其分配由产品设计商分配，在汽车行业，唯一设计商只有OEM，他对车辆整体负责，而零部件厂商往往不关注安全等级的分配工作，但零部件厂商需要按照OEM要求输出过程产物及能够证明零部件可以达到预定安全等级的测评报告。
以下按标准10个主干部分+新增Part 11展开，每部分按以下维度解析：
Part 1：术语（Vocabulary）
| 要素 | 说明 |
|---|---|
| 核心目的 | 统一功能安全术语体系，避免跨企业协作歧义（如Fault vs. Failure） |
| 内容概述 | 定义158个关键术语，如： - 危害（Harm）：人身伤害/财产损失 - 安全状态（Safe State）：故障后可控退化模式 |
| 主要适用对象 | 全产业链（OEM、供应商、认证机构） |
| 主要适用部门 | 系统工程、安全管理部门 |
| 主要适用阶段 | 全生命周期（始于概念阶段需求定义） |
Part 2：功能安全管理（Management of Functional Safety）
| 要素 | 说明 |
|---|---|
| 核心目的 | 建立安全文化框架，明确角色职责（安全经理 vs. 项目经理） |
| 内容概述 | - 安全计划（Safety Plan）制定与追踪 - 安全审核与评估（Confirmation Measures） - 安全档案（Safety Case）构建 |
| 主要适用对象 | OEM（顶层流程）、Tier 1（执行流程） |
| 主要适用部门 | 项目管理办公室（PMO）、质量保障部（QA） |
| 主要适用阶段 | 从项目启动到量产发布（持续管理） |
Part 3：概念阶段（Concept Phase）
| 要素 | 说明 |
|---|---|
| 核心目的 | 识别危害事件，推导安全目标（Safety Goals）及ASIL等级 |
| 内容概述 | - HARA分析：量化暴露率（E）、严重度（S）、可控度（C）→ 输出ASIL等级 - 功能安全概念（FSC）：定义安全机制（如冗余制动） |
| 主要适用对象 | 整车厂（OEM主导）、Tier 1参与 |
| 主要适用部门 | 系统架构部、安全分析部 |
| 主要适用阶段 | 产品定义早期（预研阶段） |
Part 4：系统级开发（Product Development at System Level）
| 要素 | 说明 |
|---|---|
| 核心目的 | 将安全目标分解为技术安全需求（TSR），设计系统架构 |
| 内容概述 | - 系统架构设计（含软硬件接口HSI） - FTA/FMEA分析（顶事件=安全目标违反） - 定义安全机制（如监控芯片+执行器冗余） |
| 主要适用对象 | Tier 1（系统集成商）、OEM（架构评审） |
| 主要适用部门 | 系统设计部、安全工程部 |
| 主要适用阶段 | 系统需求分解及原型设计 |
Part 5：硬件级开发（Product Development at Hardware Level）
| 要素 | 说明 |
|---|---|
| 核心目的 | 确保硬件随机失效率满足ASIL目标（如ASIL D要求SPFM≥99%） |
| 内容概述 | - 硬件架构度量：单点故障度量（SPFM）、潜伏故障度量（LFM） - FMEDA分析：计算故障覆盖率/诊断覆盖率 - 冗余设计（如双MCU锁步） |
| 主要适用对象 | 芯片厂商（IP设计）、Tier 1（硬件选型） |
| 主要适用部门 | 硬件设计部、测试验证部 |
| 主要适用阶段 | 原理图设计→PCB布局→样机测试 |
Part 6：软件级开发（Product Development at Software Level）
| 要素 | 说明 |
|---|---|
| 核心目的 | 通过防御性编码及测试，预防系统性软件失效 |
| 内容概述 | - 符合MISRA-C等安全编码规范 - 分层测试：单元测试（MC/DC覆盖）→集成测试→HIL测试 - SW-FMEA分析（如时序错误、内存溢出） |
| 主要适用对象 | 软件供应商、Tier 1（软件集成） |
| 主要适用部门 | 软件开发部、测试部 |
| 主要适用阶段 | 软件编码→模块集成→整车标定 |
Part 7：生产与运行（Production and Operation）
| 要素 | 说明 |
|---|---|
| 核心目的 | 确保制造过程及售后维护不引入安全风险 |
| 内容概述 | - 生产控制计划（如ESD防护、FCT测试覆盖率） - 用户手册定义安全操作边界（如自动驾驶ODD） - OTA更新的安全校验机制 |
| 主要适用对象 | 制造工厂、售后服务商 |
| 主要适用部门 | 生产制造部、售后服务部 |
| 主要适用阶段 | 量产爬坡→用户交付→后期维护 |
Part 8：支持过程（Supporting Processes）
| 要素 | 说明 |
|---|---|
| 核心目的 | 规范工具链认证、供应链协作等支撑体系 |
| 内容概述 | - 工具置信度（TCL）：评估仿真/测试工具可靠性 - 组件认证：脱离上下文（SEooC）认证流程 - 需求追踪工具（如DOORS）合规性 |
| 主要适用对象 | 工具供应商（EDA/IDE）、第三方认证机构 |
| 主要适用部门 | 质量流程部、采购部 |
| 主要适用阶段 | 全生命周期（持续支撑） |
Part 9：面向ASIL的分析（ASIL-Oriented and Safety-Oriented Analysis）
| 要素 | 说明 |
|---|---|
| 核心目的 | 针对高ASIL等级（C/D）系统进行深度失效防护分析 |
| 内容概述 | - 相关失效分析（DFA）：识别共因失效（如电源浪涌） - 级联失效分析：预防故障扩散路径（如MCU故障波及通信模块） |
| 主要适用对象 | Tier 1（安全关键系统设计）、OEM（安全评估） |
| 主要适用部门 | 可靠性工程部、安全分析部 |
| 主要适用阶段 | 系统设计→硬件设计→软件设计（迭代分析） |
Part 10：指南（Guideline）
| 要素 | 说明 |
|---|---|
| 核心目的 | 提供标准实施的实践参考（非强制要求） |
| 内容概述 | - HARA分析案例（如ACC系统误加速场景） - 安全机制设计示例（ECC纠错码实现） - ASIL分解方法（冗余组件降级设计） |
| 主要适用对象 | 全产业链（教育/培训/工程参考） |
| 主要适用部门 | 培训部、标准研究部 |
| 主要适用阶段 | 企业标准落地初期 |
Part 11：半导体指南（新增于2018版）
| 要素 | 说明 |
|---|---|
| 核心目的 | 解决车规芯片特有挑战（如纳米级工艺的软错误率） |
| 内容概述 | - 半导体故障模型（SEU/MBU） - 安全机制设计（TMR/ECC/内存BIST） - 硬件可靠性验证（FIT率计算） |
| 主要适用对象 | 半导体厂商（英飞凌/NXP等）、Tier 1（芯片选型） |
| 主要适用部门 | 芯片设计部、车规验证实验室 |
| 主要适用阶段 | 芯片架构设计→流片→AEC-Q100认证 |
四、总结：标准的核心价值与行业应用建议
- 安全左移：
- 从事后纠错转向事前预防，通过HARA分析前置风险识别（Part 3），降低量产后的召回成本。
- 跨界协同：
- 明确OEM、Tier 1、芯片商的分工（如OEM定义ASIL，Tier 1实现TSR，芯片商提供FMEDA数据），避免责任模糊。
- 技术闭环：
- 硬件（SPFM≥99%）+ 软件（MC/DC≥100%） + 生产（FCT覆盖率）三重保障，构建完整证据链（Safety Case）。
对企业的核心建议：
- OEM：主导HARA分析并严格评审供应商安全档案（Safety Case）；
- Tier 1：投资硬件FMEDA工具链（如ANSYS Medini）及软件测试自动化（CI/CD集成）；
- 芯片商：布局ASIL D Ready IP（如锁步核+ECC内存），抢占智能驾驶芯片市场。
后面详细总结各种失效、风险等概念
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
