ISO26262 Road vehicles Functionalsafety，发布于2011年，2018年更新第二版，内容有所增加。ISO26262对应的中文版国标是GB/T34590，中文名叫道路车辆功能安全，发布于2017年，几乎就是 ISO26262的翻译。
文末有下载链接。
ISO26262应用对象
to be applied to safety-related systems that includeone or more electrical and/or electronic (E/E) systems
passenger cars with a maximum gross vehicle mass up to3500kg
ISO26262 addresses possible hazards causedby malfunctioning behaviour of E/E safety-relatedsystems
可以看出来ISO26262的适用范围主要是乘用车上安全相关的电子电气系统
如：Airbag/EMS(发动机管理系统)/BMS(电池管理系统)/ABS(汽车防抱死系统)/ESP(车身稳定系统)/TPMS(胎压监控系统)等
ISO26262流程图
产品安全生命周期模型
ISO26262涵盖了整个产品设计的各个方面，包括系统设计、软件设计、硬件设计等，并贯穿于整个产品的生命周期，从产品概念阶段一直到产品报废。
Vocabulary
functional safety功能安全
不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险
HARA(hazard analysis and risk assessment)危险分析和风险评估
method to identify and categorize hazardous events of items andto specify safety goals and ASILs related to the prevention ormitigation of the associated hazards in order to avoid unreasonablerisk
为了避免不合理的风险，对相关项的危害事件进行识别和归类的方法以及定义防止和减轻相关危害的安全目标和ASIL等级的方法。
HARA流程
危害分析和风险评估 >> 安全目标和ASIL等级 >> 具体功能安全要求 >>具体技术安全要求 >> 具体硬件安全要求 和 具体软件安全要求
通过HARA分析，评估事件可能造成的伤害程度，依据判断结果，我们可以：设定项目的 safetygoal 和确定 ASIL等级
safety goal
top-level safety re as a result of the hazard analysisand risk assessment at the vehicle level.
安全目标是Zui高层面的安全要求，是危害分析和风险评估的结果。
ASIL (Automotive Safety Integrity Level)车辆安全完整性等级
26262根据安全风险程度，对系统或系统部件确定划分为 ASIL D 到QM的安全等级，其中ASILD为Zui高，QM为Zui低
英文叫 integrity levels，字面意思是完整等级(有honest 和 whole两个意思)，但是中文叫安全等级。
ASIL由三部分构成 严重度 暴露度 可控性
functional safety concept
功能安全概念 指为了实现安全目标，定义功能安全要求及相关信息，并将要求分配到架构要素上，以及定义要素之间的必要交互。如：
能够进行故障检测，降低失效的可能性
使潜在危险状态过渡到安全状态
故障容错机制（不违背安全目标，使车辆在一个安全状态下）
故障检测报警
安全气囊系统：在正常驾驶车辆过程中，安全气囊意外弹出，会造成车辆失控。（由危害分析及风险评估得出：车辆安全完整性等级为 ASILD）
安全目标：除非车辆发生碰撞，否则在任何情况下，安全气囊不能意外弹出。
功能安全概念：设计一个冗余功能，用来检测车辆是否发生碰撞。
技术安全概念：设定2个不同轴向的独立加速度传感器和2个对应的独立的点火信号。如果发生碰撞，2个点火电路同时闭合，引爆内部雷管，使安全气囊弹出。
Fault, Errors and Failures Definitions
Fault（故障）：可引起要素或相关项失效的异常情况
Errors (错误)：计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异
Failure（失效）：要素按要求执行功能的能力的终止
随机失效 (Random faults)
只出现在硬件失效中。
定量指标 ：单点故障指标SPFM 和 潜在故障指标 LFM
系统性失效 (Systematic faults)
主要指由于人的失误，残留在软件内的bug。
存在于整个生命周期。
不可完全消除，可通过流程管理尽量避免。
针对系统性失效的阶段手段 “分解” ASIL decomposition
decomposition 分解
将安全要求冗余地分配给充分独立的要素，目的是降低分配给相关要素的冗余安全要求的ASIL等级。
功能安全需求分解是为了提高可操作性
ASIL分解不能影响随机硬件失效的故障指标，不能违背设定的安全目标
分解后执行设计功能应保持充分的独立性