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：容错时间间隔；发生危害事件之前，系统可能存在一个或多