功能安全标准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.1 allocation：分配；将需求分配给架构级元件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注1：配置数据不能包括可执行代码或可判断代码；

注2：配置数据控制软件的build（构建）。只有配置数据选择的代码或数据能包括到可执行代码中。

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

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

注1：ISO26262-2中会给出完整的评审清单；

注2：审查的目的是为了保证评审项对于ISO26262的合规性。

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

注1：所谓的相关人员，包括驾驶员、乘客或靠近车辆的外部人员；

注2：危害分析和风险评估（HARA）中的参数C，代表了可控性的潜力。

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

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

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

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

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

注1：当 A和B两个失效同时发生的概率PAB ≠PA×PB时，A和B两个失效算做关联失效。其中PAB指A和B两个失效同时发生的概率；PA指A发生失效的概率；PB指B发生失效的概率。

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

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

例：检出故障可由功能安全概念中定义的专用安全机制来检测。这种安全机制包括：检测出错误后，通过仪表板上的报警装置通知驾驶员。

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

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

注1：诊断覆盖率可以根据残余故障或硬件元器件中可能出现的潜在多点故障来评估；

注2：定义见ISO26262-5给出的方程表示；

注3：可考虑在架构的不同层级实现安全机制。

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

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

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

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

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

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

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

注1：双点故障是二阶多点故障；

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

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

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

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

注2：见多点故障。

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

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

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

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

注：处理元件一般是一个MCU、FPGA或ASIC，但也可能是一个更复杂的零部件或子系统。（PS：比如SOC片上系统？）

1.34 emergency operation：应急操作；就是降级的功能，从故障发生时的状态开始，转变到预警和降级概念的安全状态。

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

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

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

注1：错误的发生，可能是由于不可预见的操作条件，或由于系统、子系统或零部件的故障导致的；

注2：元件中的某个故障能够以错误的方式暴露出来，而错误也可最终导致故障的发生。

1.37 exposure：暴露度；处在有危害（与分析的失效模式一致）的运行条件的状态。

1.38 external measure：外部措施，与某个相关项不同，但是又可以降低或减轻该相关项风险的措施。

1.39 failure：失效；指元件根据需要执行某个功能的能力被终结了。（PS：换句不绕口的话说，当一个系统不能执行所要求的功能时，就是失效）

注：不正确的规范是失效的根源。

1.40 failure mode：失效模式；元件或相关项失效的方式。

1.41 failure rate：失效率；失效概率密度除以硬件元件的幸存概率的值。

注：失效率假定为常数，通常表示为λ。

1.42 fault：故障；可能导致系统或功能失效的异常条件。

注1：一般考虑永久性故障、间歇性故障和瞬态故障（尤其是软错误）；

注2：间歇性故障会时不时发生，然后消失。当某个部件处于故障边缘时（比如有开关的小差错），可能会发生这种类型的故障；某些系统性故障（时刻边缘）也可能会导致间歇性故障。

1.43 fault model：故障模式；故障引起的失效模式的表征方式。

注：故障模式通常基于现场经验或可靠性手册来定义。

1.44 fault reaction time：故障响应时间；从检测出故障到安全状态的时间跨度。

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

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

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

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

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

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

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

例1：若元件2任何失效都不能导致元件1失效，则元件1与元件2没有干涉；

例2：若元件3中存在某个失效会导致元件4失效，则元件3与元件4发生干涉。

1.50 functional concept：功能概念；为实现所需行为所必需的预期功能性及其交互的规范。

注：功能概念是在概念阶段开发的。

1.51 functional safety：功能安全；不存在因电子电气系统故障引起的危害，而导致的不合理风险。

1.52 functional safety concept：功能安全概念；指功能安全需求相关的规范，包括相关信息、架构元件分配以及它们之间为了实现安全目标所进行的一些相互作用。

1.53 functional safety requirement：功能安全需求；实施独立的安全行为规范，或实施独立的安全措施（包括安全相关属性）。

注1：功能安全需求可以是安全相关E/E系统或其他技术的安全相关系统实现的安全需求，并考虑到确定的危害事件，来实现或维持相关项的安全状态；

注2：功能安全需求可以独立于产品开发概念阶段。

注3：安全相关属性包括ASIL等信息。

1.54 hardware architectural metrics：硬件架构度量；评估硬件架构安全有效性的指标。

注：单点故障度量和潜在故障度量是两种硬件架构度量方法。

1.55 hardware part：硬件部件；不能再细分的硬件元件。

1.56 harm：伤害；对人体健康产生损害的物理损伤。

1.57 hazard：危害；相关项故障行为造成的潜在伤害根源。

注：该定义仅限于ISO26262标准；更加一般化的定义是指潜在的伤害根源。

1.58 hazard analysis and risk assessment：危害分析与风险评估；用来对相关项危害事件进行识别和分类的方法，规定了安全目标和ASIL等级（预防或减轻相关危害），以避免不合理风险。

1.59 hazardous event：危害事件；危害与操作状况的综合体。

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

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

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

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

例：图表中的描述；

注：语法定义不完整，意味着语义也没有完全定义。

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

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

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

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

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

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

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

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

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

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

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

1.72 lifecycle：生命周期，从概念到报废的整个阶段。

1.73 malfunctioning behaviour：，故障行为；指关于相关项设计意图方面的故障或意外行为。

1.74 model-based development：基于模型的开发；指使用模型描述待开发元件功能行为的开发工作。

注：根据用于此类模型的抽象级别，该模型可用于模拟或代码生成，或两者兼有。

1.75 modification：修改；指相关项的授权更改。

注1：在ISO26262中，修改用于重用生命周期裁剪。

注2：更改（change）是某个相关项生命周期内来实现，而修改（modification）是在原有一个相关项的基础上创建出一个新的相关项来实现。

1.76 multiple-point failure：多点失效；由多个独立故障共同造成的失效，且该失效的发生直接导致违反安全目标。

注：对于直接违反安全目标的多点失效，必须是所有的独立故障同时出现才行。例如，如果是由于某个残余故障和其他独立故障一同造成了安全目标的违反，不视为多点故障。

1.77 multiple-point fault：多点故障；指某个单独的错误与其他独立错误一起发生，导致一个多点失效的发生。

注：只有在识别出多点失效后，才能识别出多点故障，例如利用故障树的割集分析来识别。

1.78 multiple-point fault detection interval：多点故障检测间隔；指在可能导致多点失效之前检测多点故障的时间跨度。

1.79 new development：新开发；指创造先前没有指定功能的相关项、或者现有功能的全新实现、抑或两者皆有的实现过程。

1.80 non-functional hazard：非功能性危害；指除了E/E系统或其他技术/外部措施的安全系统的错误运行所导致的的危害发生。

1.81 operating mode：操作模式；指相关项/元件的可感知功能状态。

例：系统关闭；系统激活；系统抑制；降级操作；紧急操作。

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

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

例：驾驶；停车；维修。

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

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

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

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

注：分区可用于故障遏制，来避免级联故障的发生。为了避免分区设计元件之间干涉现象的发生，可引入附加的非功能需求来满足设计要求。

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

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

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

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

注：直流故障是永久性故障，例如固定型故障（stuck at fault）和桥接故障（bridging fault）。系统性故障主要表现为永久性故障。

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

注：ISO26262中的安全生命周期阶段在ISO26262的其他章节有详细定义，这几个阶段分别是：

概念阶段；

产品系统开发阶段；

产品硬件开发阶段；

产品软件开发阶段；

生产经营阶段。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注：鲁棒性可通过以下几条描述来理解：

a) 对于软件来说，鲁棒性是指对不正常输入和条件进行正确响应的能力；

b) 对于硬件来说，鲁棒性是指免疫环境胁迫的能力，以及在设计寿命范围内保持稳定的能力；

c) 在整个ISO26262标准中，鲁棒性是指在边界条件下能够提供安全行为的能力。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注2：安全措施包括安全机制。

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

注1：相关项实现安全机制，可防止故障导致的单点失效，或者降低剩余失效，防止潜在故障；

注2：定义在功能安全概念中的安全机制能够：

1) 将相关项转移到或保持到一个安全状态，或

2) 警告驾驶员，期望驾驶员控制失效影响。

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

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

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

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

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

注1：术语特性在ISO/TS16949中有定义；

注2：安全相关的特性是在相关项/元件开发阶段衍生出来的。

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

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

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

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

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

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

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

例：安全相关特性；需要的安全操作；

1.120 severity：严重度；预估潜在危害对个人或多人造成的伤害程度。

注：危害分析与风险评估中的参数“S”表征伤害的潜在严重度等级。

1.121 single-point failure：单点失效；单点故障引起的、直接导致违反安全目标的失效。

注1：单点失效相当于具有0%故障诊断率的元件的剩余失效；

注2：若某个硬件元件定义了至少一个安全机制（例如MCU的看门狗），则该硬件元件的任何故障都不再可能是单点故障了。

1.122 single-point fault：单点故障；指那种没有被安全机制覆盖并直接导致违反安全目标的元器件故障。

注：见单点失效。

1.123 software component：软件组件；一个或更多的软件单元。

1.124 software tool：软件工具；用于相关项或元器件开发的计算机程序。

1.125 software unit：软件架构中的原子级软件组件（即不可再细分的组件），该组件能够独立进行测试。

1.126 special-purpose vehicle：特殊目的车辆；指一些需要特殊车身布置和（或）设备来执行功能的车辆。

例：居旅车；装甲车；救护车；灵车；拖挂车；起重机；

注：ECE TRANS/WP.29/78/Rev.1/Amend.2中有专用车辆的相关定义。

1.127 statement coverage：语句覆盖；软件中已执行语句的百分比。

1.128 subphase：安全生命周期子阶段；指ISO26262中明确规定的细分安全生命周期阶段。

例：危害分析与风险评估（HARA）是ISO26262-3中定义的安全生命周期子阶段。

1.129 system：系统；至少与传感器、控制器和执行器相互关联的一组元器件。

注1：相关传感器或执行器既可以包括在系统中，也可以在系统外部；

注2：一个系统的元件，可能是另一个完整的系统。

1.130 systematic failure：系统性失效；某种原因导致失效以确定的方式发生，且该失效只能通过改变设计或制造工艺、操作程序、文件或其他相关因素来消除。

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

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

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

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

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

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

注：电磁干扰会导致位翻转，使瞬时故障发生。单粒子翻转（SEU）和单粒子瞬态（SET）等软错误都属于瞬态故障。

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

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

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

注1：验证评审的单个具体要求，见ISO26262某个部分的具体条款；

注2：验证评审的目的是保证相关项或元器件在用例和失效模式中的技术正确性和完整性。

例：技术评审；穿行测试（走查）；检测。

1.139 walk-through：穿行测试；为检测异常而对工作产品进行的系统性检查。

注1：穿行测试是一种验证方法；

注2：穿行测试不同于普通测试，它通常不涉及相关项或元器件的操作；

注3：检测到的任何异常通常通过返工来解决，然后要对返工工作产品进行穿行测试；

例：在穿行测试过程中，开发人员将逐个向评估人员解释工作产品。目的是建立对工作产品的共同理解，并识别工作产品的任何异常。检测（inspection）和穿行测试（walk-through）都属于同行评审（peer review），其中穿行测试是一种比检测更加不严格的同行评审方式。

1.140 warning and degradation concept：预警及降级概念；指如何提醒驾驶员潜在的功能降级以及如何提供这种降级的功能，来确保系统达到安全状态的一种说明。

1.141 well-trusted：值得信赖的；曾使用过的没有已知安全异常的形容词。

例：值得信赖的设计原则；值得信赖的工具；值得信赖的硬件组件。

1.142 work product：工作产品；ISO26262标准中一个或多个相关需求的结果。

注：引用（Reference）既可以是包含工作产品完整信息的独立文档，也可以是对工作产品完整信息的引用列表。

2 缩写术语：

ACC：自适应巡航；

AEC：汽车电子委员会；

AIS：简略创伤量表；

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）.

功能安全标准ISO26262-1翻译相关推荐

汽车电子功能安全标准ISO26262解析（一）——总述部分
写在前面:本文旨在对汽车电子功能安全标准ISO26262进行解析,提炼出对设计有强指导意义的关键点.文中包括ISO26262原文的翻译及结合自己工作经验的理解. 0. ISO26262应用对象: IS ...
SOTIF 预期功能安全ISO21448介绍、功能安全标准ISO26262 与若干安全标准的适用范围和开发流程映射
SOTIF 预期功能安全ISO21448介绍.功能安全标准ISO26262 与若干安全标准的适用范围和开发流程映射 ISO 21448 中规定了预期功能安全的设计开发流程图, 如下图所示.首先从第 ...
汽车电子功能安全标准ISO26262解析（四）——FMEDA
Evaluation of the hardware architectural metrics. FMEDA是硬件架构度量的一种验证方法. The objective of this clause ...
汽车电子功能安全标准ISO26262解析（五）——FTA
Evaluation of safety goal violations due to random hardware failures. FTA是用来验证随机硬件失效导致的违背安全目标. The o ...
汽车电子功能安全标准ISO26262解析（十二）——HARA分析
ISO 26262-3: Clause 7 (HARA) Hazard analysis and risk assessment 危害分析和风险评估 1. Objectives 目的 The obje ...
汽车电子功能安全标准ISO26262解析（十一）——安全机制
ISO 26262-4: 6.4.7 1. The safety mechanisms shall be specified by technical safety requirements incl ...
汽车电子功能安全标准ISO26262解析（十）——HSI
Hardware software interface specification (HSI) ISO 26262-4:7.4.6.1 The HSI shall be specified duri ...
matlabrvctools主要功能及实际应用_【从业必备 | 收藏】ISO26262功能安全标准白皮书：关键组成、软硬件认证、测试过程、合规认证工具...
ISO26262功能安全标准白皮书: 关键组成.软硬件认证.测试过程,合规的认证工具目录背景 ISO 26262的关键部分硬件组件认证软件组件认证 "在实践中证 ...
ISO 26262功能安全标准体系解读（下）
ISO 26262功能安全标准体系解读(上)中,我们为大家介绍了:什么是功能安全?功能安全的制定经历了什么样的历程?什么是ISO 26262?如何评估ASIL? 通过危害分析和风险评估,我们得出系统或 ...
ISO 26262功能安全标准体系解读（上）
汽车功能安全标准于2011年作为ISO标准正式颁布,此后,汽车业界开始采纳应用该标准. 虽然标准的采纳是自愿的,但在这样的背景和趋势之下,无论是汽车厂商还是零部件供应商,为了满足ISO 26262的要 ...

功能安全标准ISO26262-1翻译

功能安全标准ISO26262-1翻译相关推荐

最新文章

热门文章