功能安全 Functional Safety ISO26262-1

ISO 26262-1 词汇表
ISO26262是基于IEC61508标准演化而来的一项标准，旨在满足道路车辆电子电气系统领域的特定需求。

这种改编适用于由电子电气元件和软件组件组成的安全系统的整个生命周期内的所有活动。

安全是未来汽车发展的关键问题之一。

一些新的功能，在驾驶员辅助、动力、车内动态控制和主动&被动安全系统等方面日益牵涉到越来越多的系统安全工程。

这些功能的开发和集成会增加对安全系统开发流程、并证明所有合理的系统安全目标都得到满足的证据的需求程度。

随着技术复杂度、软件内容和机电一体化程度的不断提高，系统失效和随机硬件失效的风险也越来越大。

ISO 26262会提供适当的要求和流程来避免这些风险。

系统安全是通过一系列安全措施来实现的，通过应用各种技术（例如机械、液压、气动、电气、电子、可编程电子），并在开发过程的各个层面上应用。

尽管ISO26262涉及到电子电气系统的功能安全，但是它也会提供其他系统常用安全技术的框架。

ISO26262可以：
a)提供车辆安全生命周期的支持（管理、开发、生产、操作、服务、报废）；
b)提供车辆专用的风险评估方法（ASIL，Automotive Safety Integrity Levels，汽车安全完
整性等级）；
c)使用ASIL评级提出可实施的功能安全需求，来避免不合理的剩余风险；
d)向供应商提供功能安全需求。

功能安全受到开发流程（需求规范、设计、实现、集成、验证、确认和配置）、生产和服务流程、管理流程的影响。

安全问题与以功能为导向、以质量为导向的开发活动和工作产品交织在一起。

ISO 26262阐述了开发活动和工作产品等安全相关的内容。

1 名称解释：
1.1allocation：分配；将需求分配给架构级元件。

1.2anomaly：异常；指偏离期望的一些条件，这些条件包括需求、说明书、设计文档、用户
文档、标准或者经验。

1.3architecture：架构；代表相关项/功能/系统/元件的构造块及构造块的边界和接口，且相
关的功能已经分配给了硬件/软件元件。

1.4assessment：评估；是指对相关项/元件特征的考察。

1.5audit：审计；是实施过程的考察。

1.6ASIL：车辆安全完整性等级，Automotive Safety Integrity Level；是指ABCD四个等级中
的一个等级，规定了相关项或元件的ISO26262需求和安全测量措施，来避免不合理剩余风险；其中，D代表最严格等级，A代表最不严格等级。

1.7ASIL decomposition：ASIL分解；指将安全需求冗余地分摊给那些足够独立的元件，目
的是降低这些独立元件的冗余安全需求的ASIL等级。

1.8availability：有效性；假设所需的外部资源可用的条件下，在特定条件、特定时间或时期
内，产品处于正在执行所需功能的状态的能力。

1.9baseline：基线；是指正处于配置管理中的某个或多个工作产品/相关项/元件的一个版
本，并作为变更管理流程的一个基础用于进一步开发。

1.10branch coverage：分支覆盖；指控制流分支中，已被执行的百分比。

注1：100%的分支覆盖率意味着100%的软件已执行语句覆盖率（statement coverage）。

注2：if语句总有两个分支：条件true和条件false，因此这里的所谓“分支”并不是指if … else中的else这个语句。

1.11calibration data：标定数据；指软件开发过程中，在软件build之后需要匹配的数据或
参数。

例：参数（parameter，例如低怠速值、发动机特性图）；车辆特定参数（vehicle specific parameters，一般是一种自适应值，通过自动标定算法实现，例如节气门限位器）；变体编码（variant coding，例如国家/地区代码、左舵/右舵）。

1.12candidate：候选项；指项目或元件的定义和使用条件与已发布的某个项目或元件一样或
高度相似。

注：此定义适用于在经使用验证的背景中候选项的使用情况。

1.13cascading failure：级联失效；元件/相关项的失效导致其他元件或相同相关项的其他元
件失效。

注：级联失效是一种非共因失效的相关失效。

1.14common cause failure：共因失效CCF；指某个单独特定的事件或根本原因导致的相关
项的两个或多个元件失效。

注：CCF是一种非级联失效的相关失效。

1.15component：组件/零部件；指非系统级的元件，这些元件一般是因为在逻辑和技术可
以从系统中分割出来，并由多个硬件或多个软件单元组成。

注：一个组件是一个系统的一部分。

1.16configuration data：配置数据；在软件build期间，分配并控制软件build过程的数据。

例：预处理器指令；软件build脚本（例如XML配置文件等构建脚本）。

注1：配置数据不能包括可执行代码或可判断代码；
注2：配置数据控制软件的build（构建）。

只有配置数据选择的代码或数据能包括到可执行代码中。

1.17confirmation measure：确认措施；指对功能安全相关的确认审查（confirmation review）、
审计（audit）、评估（assessment）。

1.18confirmation review：确认评审；确认工作产品符合ISO26262的要求，且参与的评审员
具备所要求的独立性。

注1：ISO26262-2中会给出完整的评审清单；
注2：审查的目的是为了保证评审项对于ISO26262的合规性。

1.19controllability：可控性；指通过相关人员的及时反应，来避免特定伤害/损害的能力；该
能力可能需要外部措施的支持。

注1：所谓的相关人员，包括驾驶员、乘客或靠近车辆的外部人员；
注2：危害分析和风险评估（HARA）中的参数C，代表了可控性的潜力。

1.20dedicated measure：专用措施；指确保违反安全目标的估计概率在声称的失效率范围内
的措施。

例：设计功能点，如硬件的过度设计（额定电功率或额定热应力）和物理分离（例如印刷电路板上触点的间距）；对来料进行特殊抽样试验，降低因违反安全目标的失效模式的发生风险；老化测试；专用控制计划。

1.21degradation：退化；指失效发生后的安全设计策略。

注：退化可以是功能性的减少、性能的较少或功能性和性能的双重减少。

1.22dependent failures：相关失效；是指有一种失效，其同时或连续发生失效的概率不能表
示为各自无条件概率的简单乘积。

注1：当A和B两个失效同时发生的概率P AB≠P A×P B时，A和B两个失效算做相关失效。

其中P AB指A和B两个失效同时发生的概率；P A指A发生失效的概率；P B指B发生失效的概率。

注2：相关失效包括共因失效和级联失效。

1.23detected fault：检出故障；在规定时间内，由防止潜伏故障发生的安全机制检测到的故
障，叫做检出故障。

例：检出故障可由功能安全概念中定义的专用安全机制来检测。

这种安全机制包括：检测出错误后，通过仪表板上的报警装置通知驾驶员。

1.24development interface agreement：开发接口协议；表示客户和供应商之间的协议，规
定了各方交换活动、证据或工作产品的责任。

1.25diagnostic coverage：诊断覆盖率；指安全机制所检测或控制的硬件元器件失效的比例。

注1：诊断覆盖率可以根据残余故障或硬件元器件中可能出现的潜在多点故障来评估；
注2：定义见ISO26262-5给出的方程表示；
注3：可考虑在架构的不同层级实现安全机制。

1.26diagnostic test interval：诊断测试间隔；安全机制执行在线诊断测试的时间间隔。

1.27distributed development：分布式开发；在客户和供应商之间为整个相关项或元件或子
系统划分开发责任，来进行相关项或元件的开发工作。

注：客户和供应商是合作方的角色。

1.28diversity：多样性；指以独立性为目标，满足相同需求的不同解决方案。

例：多样的程序设计；多样化的硬件。

注：多样性并不能保证独立性，但可以解决某些类型的共因失效。

1.29dual-point failure：双点失效；两个独立故障共同导致违反安全目标的故障的发生。

注1：双点故障是二阶多点故障；
注2：ISO26262中所述的双点失效包括一个影响安全相关元件的故障，一个影响相应的安全机制以达到或保持安全状态的故障。

注3：对于直接违反安全目标的双点失效，需要两个独立故障的存在，例如，因残余故障与安全故障的组合而违反安全目标的故障就不属于双点故障，因为残余故障不算第二个独立故障，无论该故障是否导致了违反安全目标的情况发生。

1.30dual-point fault：双点故障；两个独立的单个故障共同导致的故障，叫做双点故障。

注1：只有识别出双点失效后，才能识别出双点故障，例如故障树中的割集分析；
注2：见多点故障。

1.31electrical and/or electronic system，电子电气系统，E/E system；即由电子和/或电气元
件组成的系统，包括可编程电子元件。

例：电源；传感器或其他输入设备；通信路径；执行器或其他输出设备。

1.32element：元件；系统或系统的一些组成部件，包括组件、硬件、软件、硬件部件和软
件单元。

1.33embedded software：嵌入式软件；在处理元件中执行的完全集成的软件。

注：处理元件一般是一个MCU、FPGA或ASIC，但也可能是一个更复杂的零部件或子系统。

（PS：比如SOC片上系统？）
1.34emergency operation：应急操作；就是降级的功能，从故障发生时的状态开始，转变到
预警和降级概念的安全状态。

1.35emergency operation interval：应急操作间隔；指需要应急操作来支持预警和降级概念
的时间跨度。

注：应急操作是预警和降级概念的一部分。

1.36error：错误；计算、观察或测量的值或条件，与真实、规定或理论上正确的值或条件之
间的差异。

注1：错误的发生，可能是由于不可预见的操作条件，或由于系统、子系统或零部件的1.44fault reaction time：故障响应时间；从检测出故障到安全状态的时间跨度。

1.45fault tolerant time interval：容错时间间隔；发生危害事件之前，系统可能存在一个或多
个故障的时间跨度。

1.46field data：现场数据；指从相关项或元件使用过程中获得的数据，包括累计运行时间、
所有的失效记录以及运行中的运行情况记录。

注：现场数据通常来自客户使用过程。

1.47formal notation：正式符号；完全定义了的语法和语义描述技术。

例：Z符号（Z）；符号模型检查器（NUSMV）；原型验证系统（PVS）；维也纳开发法（VDM）。

1.48formal verification：正式验证；证明系统的行为符合所需行为的形式标注规范的方法。

1.49freedom from interference：不受干扰；指两个或多个元件之间不存在可能导致违反安
全要求的级联故障。

：同构冗余；需求的多个但相同的实现。

1.61independence：独立性；两个或两个以上要素之间，不存在可能导致违反安全要求的相
关失效，或不存在违反行动当事人组织分离原则的相关失效。

1.62independence failures：独立失效；（失效）同时或连续发生的概率，可以表示为其无条
件概率的简单乘积的失效。

1.63informal notation：非正式符号；没有完全定义的语法描述技术。

例：图表中的描述；
注：语法定义不完整，意味着语义也没有完全定义。

1.64informal verification：非正式验证；那些不被视为半正式或正式验证技术的验证方法。

例：设计评审；模式评审。

1.65inheritance：继承性；在开发过程中，以不变的方式将需求传递到下一个更细化的层级。

1.66initial ASIL：初始ASIL；指由危害分析产生的ASIL，或由之前ASIL分解产生的ASIL。

注：初始ASIL是当前或者下一步ASIL分解的起始点。

1.67inspection：检测；按照正式程序检查工作产品，检查异常情况。

注1：检测是一种验证（verification）手段。

1.68intended functionality：预期功能；指相关项/系统/元件（不包括安全机制）的指定行为。

1.69item：相关项；指那些适用于ISO2626的、实现整车级功能的系统或系统阵列。

1.70item development：相关项开发；指实现相关项的完整过程。

1.71latent fault：潜在故障；指不易被安全机制检测到的多点故障，或者在多点故障检测间
隔期间不易被驾驶员察觉到的多点故障。

1.82operating time：操作时间；指相关项/元件保持运行的累积时间。

1.83operational situation：运行情况，车辆整个生命周期中会发生的各种情景。

例：驾驶；停车；维修。

1.84other technology：其他技术；本标准特指那种不同于ISO26262标准中涉及到的电子电
气技术的其他技术。

例：机械技术；液压技术。

注：在安全需求分配时，其他技术也可以作为一种外部措施，用于功能安全概念规范的考虑范围中。

1.85partitioning：分区；即分割一些功能或元件来满足设计需要。

注：分区可用于故障遏制，来避免级联故障的发生。

为了避免分区设计元件之间干涉现象的发生，可引入附加的非功能需求来满足设计要求。

1.86passenger car：乘用车；指那种设计制造出来，用于运载乘客及行李、货物的车辆；该
车除了驾驶员外，座位数不超过8个，且车内没有乘客站立的空间。

1.87perceived fault：感知（到的）故障；指驾驶员在规定时间段内，能推断并发现的故障。

例：通过显眼的系统行为或明显的性能限制，让驾驶员可以直接感受到故障（已经发生了）。

1.88permanent fault：永久性故障；指在拆解或修复之前会一直保持的故障。

注：直流故障是永久性故障，例如固定型故障（stuck at fault）和桥接故障（bridging fault）。

系统性故障主要表现为永久性故障。

1.89phase：阶段；指ISO26262中明确规定的安全生命周期阶段。

注：ISO26262中的安全生命周期阶段在ISO26262的其他章节有详细定义，这几个阶段分别是：
•概念阶段；
•产品系统开发阶段；
•产品硬件开发阶段；
•产品软件开发阶段；
•生产经营阶段。

1.90proven in use argument：经使用验证的参数；通过对候选项使用过程中产生的现场数
据进行分析，有证据表明该候选项的任何可能损害安全目标的失效概率满足对应的ASIL 等级要求。

1.91proven in use credit：经使用验证的信用；通过已验证的使用参数用相应的工作产品替
换一组给定的生命周期子阶段。

1.92random hardware failure：随机硬件失效；指硬件元件在生命周期内会发生不可预测
的、符合概率分布的失效。

注：随机硬件失效率可以进行合理精度下的预测。

1.93reasonably foreseeable event：可合理预见的事件；指技术上可能发生的、并具有可信
/可测量发生概率的事件。

1.94redundancy：冗余；某个元件拥有足够手段来执行所需功能或表示信息之外，拥有附加
的手段来实现同样的功能和表示信息。

注：在ISO26262中，冗余用于实现安全目标或规定的安全需求，也用于表示安全相关信息。

例1：冗余的一个实例是采用重复的功能组件，可以提高可用性或用来故障检测。

例2：在安全相关的信息数据中添加奇偶校验位，来提供故障检测功能，也是一种冗余。

1.95regression strategy：回归策略；某个相关项或元件的验证更改实施策略不会影响到那些
不更改的/现存的/验证过的部分或属性。

1.96residual fault：剩余故障；故障的一部分，且该部分故障没有被安全机制覆盖；恰恰是
这部分故障导致硬件元器件违反安全目标。

注：假设硬件元件只对部分故障有安全机制覆盖。

例：如果一个失效模式有60%的覆盖率，那么该失效模式剩下的40%就叫做剩余故障。

1.97residual risk：剩余风险；实施了安全措施后仍旧剩余的风险。

1.98review：评审；指根据审查的目的对工作产品进行审查，使其达到预期的工作产品目标。

注：清单（checklists）可以支持评审工作。

1.99risk：风险；即危害发生概率与危害严重程度的结合。

1.100robust design：鲁棒性设计；能够在有无效输入干扰或压力环境条件下保持正常工作
的设计，叫做鲁棒性设计。

注：鲁棒性可通过以下几条描述来理解：
a)对于软件来说，鲁棒性是指对不正常输入和条件进行正确响应的能力；
b)对于硬件来说，鲁棒性是指免疫环境胁迫的能力，以及在设计寿命范围内保持稳定
的能力；
c)在整个ISO26262标准中，鲁棒性是指在边界条件下能够提供安全行为的能力。

1.101safe fault：安全故障；即发生后不会显著增加违反安全目标概率的故障。

注1：不管是非安全相关的元件，还是安全相关的元件，都有安全故障。

注2：单点故障、剩余故障和双点故障，不构成安全故障。

注3：除非安全概念中特殊说明，否则大于2点的多点故障可以认为是安全故障。

1.102safe state：安全状态；没有不合理风险水平的相关项的操作模式。

例：预期工作模式；降级工作模式；关闭模式。

1.103safety：安全；没有不合理风险。

1.104safety activity：安全活动；在安全生命周期中的一个或多个子阶段运行的活动。

1.105safety architecture：安全架构；满足安全需求的一组元件及其相互关系的合集。

1.106safety case：安全案例；开发期间从安全活动的工作产品中收集到的证据，证明相关
项的安全要求是完备的和满足要求的。

注：安全案例可以扩展至超出ISO26262范围的安全问题。

1.107safety culture：安全文化；组织内用于支持安全相关系统的开发、生产及运营的政策
和策略，叫做安全文化。

1.108safety goal：安全目标；即经过危险分析和风险评估得出的顶级安全需求。

注：一个安全目标可以与多个危害相关，多个安全目标也可以与单个危害相关。

1.109safety manager：安全经理；项目开发期间负责功能安全管理角色的人员。

1.110safety measure：安全措施；指避免或尽量控制系统性失效、检测或尽量控制随机硬件
失效、或减轻不良影响的活动或技术解决方案。

注1：安全措施包括FMEA及不使用全局变量的软件；
注2：安全措施包括安全机制。

1.111safety mechanism：安全机制；由电子电气功能、元件或其他技术实现的技术解决方
案，用于故障检测和失效控制，以达到（或保持）安全状态。

注1：相关项实现安全机制，可防止故障导致的单点失效，或者降低剩余失效，防止潜在故障；
注2：定义在功能安全概念中的安全机制能够：
1)将相关项转移到或保持到一个安全状态，或
2)警告驾驶员，期望驾驶员控制失效影响。

1.112safety plan：安全计划；计划管理和指导项目安全活动的执行，包括日期、里程碑、任
务、可交付成果、责任和资源。

1.113safety-related element：安全相关元件；可能导致违反（或实现）安全目标的因素。

注：若故障安全元件（fail-safe）能够实现至少一个安全目标，那么就可以将其视为安全相关元件。

1.114safety-related function：安全相关功能；可能导致违反安全目标的功能。

1.115safety-related special characteristic：安全相关特性；相关项/元件或其生产过程的特征，
且该特征能够合理预见的偏差可能影响、促成或削弱功能安全。

注1：术语特性在ISO/TS16949中有定义；
注2：安全相关的特性是在相关项/元件开发阶段衍生出来的。

例：温度区间；失效日期；紧固扭矩；生产公差；配置。

1.116safety validation：安全确认；在检查和测试的基础上，确保安全目标是足够的，且安
全目标已经实现。

1.117semi-formal notation：半正式符号；一种描述技术，其语法已经完全定义，但是语义
可能不完整。

例：系统分析和设计技术（SADT）；统一建模语言（UML）。

1.118semi-formal verification：半正式验证；基于半正式符号描述的验证方法。

例：使用半正式模型生成的测试向量来测试系统行为是否与模型匹配。

1.119service note：服务说明；执行项目维护程序时，要考虑的安全信息文件。

通过改变设计或制造工艺、操作程序、文件或其他相关因素来消除。

1.131systematic fault：系统性故障；以确定性方式表现出失效的故障，且该故障只能通过
匹配流程或设计措施加以预防。

1.132technical safety concept：技术安全概念；指技术安全需求规范及其系统元素的分配
（供系统设计的实施）。

1.133technical safety requirement：技术安全需求；执行相关功能安全需求的需求。

注：衍生需求包括缓解需求。

1.134testing：测试；计划、准备、操作或执行一个相关项或元器件的某个流程，且该流程
主要目的是为了验证相关项/元器件是否满足规定的要求、检测异常、并对相关项/元
器件的行为建立信心。

1.135transient fault：瞬时故障；出现一次后立刻消失的故障。

注：电磁干扰会导致位翻转，使瞬时故障发生。

单粒子翻转（SEU）和单粒子瞬态（SET）等软错误都属于瞬态故障。

1.136unreasonable risk：不合理风险；根据有效的社会道德概念，在特定环境下被判定为不
可接受的风险，叫做不合理风险。

1.137verification：验证；测定需求在一个阶段或子阶段的完整性和规范或实现的正确性。

1.138verification review：验证评审；用以确保开发活动的结果是满足项目要求和（或）技
术要求的一种验证活动。

注1：验证评审的单个具体要求，见ISO26262某个部分的具体条款；
2
ASIC：专用集成电路；
ASIL：汽车完整性等级；
BIST：内置自检功能；
CAN：控制器区域网络；
CCF：共因失效；
COTS：商用现货；
CPU：中央处理单元；
CRC：循环冗余检查；
DC：诊断覆盖率；
d.c.：直流电；
DIA：开发接口协议；
DSC：动态稳定控制；
ECU：电子控制单元；
EDC：误差检测与校正；
E/E system：电子电气系统；
EMC：电磁兼容；
EMI：电磁干扰；
ESD：静电放电；
ESC：电子稳定控制；
ETA：事件数分析；
FPGA：现场可编程门阵列；
FIT：故障率单位，用来衡量正常工作的产品在规定时间t 之后，产品中丧失其规定的功能的产品所占比例；
FMEA：失效模式与影响分析；
FTA：故障树分析；
HAZOP：危害和可操作性分析；
HIS：软硬件接口；
HW：硬件；
H&R：危害分析与风险评估；
IC：集成电路；
I/O：输入输出；
MC/DC：修正条件/判定覆盖（软件测试方法之一）；
MMU：内存管理单元；
MPU：存储器保护单元；
MUX：多路复用器，多工器；
OS：操作系统；
PLD：可编程逻辑器件；
PMHF：随机硬件失效的概率度量
QM：质量管理；
RAM：随机存取存储器；
ROM：只读存储器；
RFQ：询价单；
SIL：安全完整性等级；
SOP：开始生产；
SRS：系统需求规范；
SW：软件；
UML：统一建模语言；
V&V：验证与确认；
XML：可扩展标记语言。

附录：
关于failure/fault/error的对比：
三者之间覆盖所有现实中的失效场景关系：包含递进关系，即故障（fault）发生了，会导致错误（error），错误有可能造成系统功能失效（failure）。

例：病人告诉医生自己的各种症状，身体没有健康的工作–失效（failure）；
医生检查病人身体状态，测量出异常，如血压高、心律不齐等–错误（error）；
医生找到了疾病的根源，如病毒–故障（fault）；。