[PDF] GB/T 34590.1-2017 - 自动发货. 英文版
| 标准号码 | 美元 | 购买PDF | 工期 | 标准名称(英文版) |
| GB/T 34590.1-2017 | 145 | GB/T 34590.1-2017 | 9秒内发货PDF | 道路车辆 功能安全 第1部分：术语 |
| 基本信息 | |
|---|---|
| 标准编号 | GB/T 34590.1-2017 (GB/T34590.1-2017) |
| 中文名称 | 道路车辆 功能安全 第1部分：术语 |
| 英文名称 | Road vehicles -- Functional safety -- Part 1: Vocabulary |
| 行业 | 国家标准 (推荐) |
| 中标分类 | T35 |
| 国际标准分类 | 43.040 |
| 字数估计 | 30,392 |
| 发布日期 | 2017-10-14 |
| 实施日期 | 2018-05-01 |
| 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 |
GB/T 34590.1-2017
道路车辆 功能安全 第1部分：术语
Road vehicles -- Functional safety -- Part 1: Vocabulary
1 范围
GB/T 34590的本部分规定了本标准所有部分所应用的术语和定义,以及缩略语。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统,例如,为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。
对于在本标准发布
前完成生产发布
的系统及其组件进行进一步的开发或变更时,仅修改的部分需要按
照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害,包括这些系统相互作用而
引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能,即使这些系统(例如,主动和被动安全系统、制动系统、自
适应巡航控制系统)有专用的功能性能标准。
2 术语和定义
2.1
分配
将要求指定给架构要素(2.32)。
注:目的不是将一个不可分割的要求分割成多个要求。从一个不可分割的系统(2.129)层面的要求到多个较低层面的不可分割的要求的追溯是允许的。
2.2
异常
与预期(例如,基于要求、规范、设计文档、用户文档、标准或者经验的预期)偏离的情况。
注:异常可在除评审(2.98)、测试(2.134)、分析、编译、组件(2.15)的使用、或适用文档的使用等过程中被发现,也可在过程中被发现。
2.3
架构
相关项(2.69)、功能、系统(2.129)或要素(2.32)的结构的表征,用于识别结构模块及其边界和接口,
并包括硬件和软件要素的要求分配(2.1)。
2.4
评估
对相关项(2.69)或要素(2.32)的特性的检查。
注:执行评估的一方或多方的独立性(2.61)水平与每一次评估相关。
2.5
审核
对已实施流程的检查。
2.6
汽车安全完整性等级
四个等级中的每一个等级定义了GB/T 34590中相关项(2.69)或要素(2.32)的必要的要求和安全
措施(2.110),以避免不合理的残余风险(2.97),D代表最高严格等级,A代表最低严格等级。
2.7
ASIL分解
将安全要求冗余地分配给充分独立的要素(2.32),目的是降低分配给相关要素的冗余安全要求的
ASIL(2.6)等级。
2.8
可用性
在特定时间或给定的期间内,假设所需的外部资源是可用的,在给定条件下,产品处于执行所需功
能的状态的能力。
2.9
基线
在配置管理下,通过变更管理流程,作为进一步开发的基础的一组单一或多个工作成果、相关项
(2.69)或要素(2.32)的版本。
注:参见GB/T 34590.8-2017第8章。
2.10
分支覆盖率
已执行的控制流分支所占的比率。
注1:100%分支覆盖率意味着100%语句覆盖率(2.127)。
注2:一个if语句总有两个分支即条件真和条件假,其独立于一个else语句。
2.11
标定数据
在开发过程中,软件编译后将要应用的数据。
示例:参数(例如,低怠速值、发动机特性曲线图);车辆特定参数(适应值)(例如,节气门极限停止);变量编码(例如,国家代码、左舵/右舵)。
注:标定数据不包含可执行代码或注释代码。
2.12
候选项
与已经发布并在运行的相关项或要素的定义和使用条件相同、或具有高度通用性的相关项(2.69)
或要素(2.32)。
注:该定义适用于在用证明(2.90)中使用的候选项。
2.13
级联失效
同一个相关项(2.69)中,一个要素(2.32)的失效(2.39)引起另一个或多个要素的失效。
注:级联失效是非共因失效(2.14)的相关失效(2.22),见图2,失效A。
2.14
共因失效
一个相关项(2.69)中,由一个单一特定事件或根本原因引起的两个或多个要素(2.32)的失效
(2.39)。
注:共因失效是非级联失效(2.13)的相关失效(2.22)。
2.15
组件
逻辑上和技术上可分的非系统(2.129)层面的要素(2.32),由一个以上硬件元器件(2.55)或一个到
多个软件单元(2.125)组成。
注:组件是系统的一部分。
2.16
配置数据
在软件构建过程中分配的、控制软件构建过程的数据。
示例:预处理器配置指令;软件构建脚本(例如,XML配置文件)。
注1:配置数据不可包含执行代码或注释代码。
注2:配置数据控制软件的构建,仅由配置数据选择的代码或数据可以包含在执行代码中。
2.17
认可措施
与功能安全(2.51)相关的认可评审(2.18)、审核(2.5)或评估(2.4)。
2.18
认可评审
由具备所需独立性(2.61)级别的评审员,对满足GB/T 34590要求的工作成果的确认。
注1:GB/T 34590.2-2017提供了一个完整的认可评审清单。
注2:认可评审的目的是确保符合GB/T 34590。
2.19
可控性
通过所涉及人员的及时反应,也可能通过外部措施(2.38)的支持,避免特定的伤害(2.56)或损伤的能力。
注1:所涉及人员可包括驾驶员、乘客或车辆外部的邻近人员。
注2:危害分析和风险评估(2.58)中的参数C表示可控性的可能性。
2.20
专用措施
在评估违背安全目标(2.108)的可能性的过程中,用于确保所声明的失效率(2.41)的措施。
示例:设计特性,诸如硬件元器件(2.55)过度设计(例如,电应力或热应力分级)或者物理分隔 (例如,印刷电路板上的触点间隔);对来料进行专门的抽样测试,以降低与违背安全目标有关的失效模式(2.40)的发生风险(2.99);老化测试;
专用的控制计划。
2.21
降级
通过设计提供失效(2.39)发生后的安全(2.103)的策略。
注:降级可包含功能缩减,性能降低,或两者均降低。
2.22
相关失效
失效(2.39)同时或相继发生的概率不能表示为每个失效无条件发生概率的简单乘积的失效。
注1:当PAB≠PA×PB,失效A和失效B可被定义为相关失效。
式中:
PAB---失效A和失效B同时发生的概率;
PA ---失效A发生的概率;
PB ---失效B发生的概率。
注2:相关失效包含共因失效(2.14)和级联失效(2.13)。
2.23
可探测的故障
在规定的时间内,可通过防止故障(2.42)变成潜伏故障的安全机制(2.111)探测到的故障。
示例:可被功能安全概念(2.52)中定义的专门安全机制(2.111)[例如,探测到错误(2.36)并通过仪表盘上的报警装置通知驾驶员]探测到的故障。
2.24
开发接口协议
客户与供应商之间的协议,该协议规定了双方在相关活动中各自承担的责任、应提供给对方的证据
或工作成果。
2.25
诊断覆盖率
硬件要素(2.32)失效率(2.41)中,由实施的安全机制(2.111)探测或控制的失效率所占的比例。
注1:诊断覆盖率可通过在硬件要素中可能发生的残余故障(2.96)或潜伏的多点故障(2.77)进行评估。
注2:该定义可按照GB/T 34590.5-2017中给出的等式表述。
注3:可考虑在架构(2.3)中的不同层面所实施的安全机制。
2.26
诊断测试时间间隔
通过安全机制(2.111)执行在线诊断测试的时间间隔。
2.27
分布式开发
在客户和供应商之间分配整个相关项(2.69)、要素(2.32)或子系统开发责任的相关项或要素的
开发。
注:客户和供应商是合作方中的角色。
2.28
多样性
以独立性(2.61)为目标,满足相同要求的不同解决方案。
示例:多样的程序;多样的硬件。
注:多样性不保证独立性,但是可避免特定类型的共因失效(2.14)。
2.29
双点失效
由两个独立故障(2.42)的组合引起,且直接导致违背安全目标(2.108)的失效(2.39)。
注1:双点失效是2阶的多点失效(2.76)。
注2:GB/T 34590中提到的双点失效包括这些失效,即:有一个故障影响到安全相关要素(2.113),而另一个故障影
响到相关的达到或保持安全状态(2.102)的安全机制(2.111)而导致的失效。
注3:对于直接违背安全目标的双点失效,两个独立故障的发生是必要的,即不认为导致违背安全目标的残余故障(2.96)和安全故障(2.101)的组合为双点失效,因为残余故障可以直接导致违背安全目标,与第二个独立故障是否发生没有关系。
2.30
双点故障
与另一个独立故障组合而导致双点失效(2.29)的一个故障(2.42)。
注1:只有在明确双点失效后才能识别出一个双点故障,例如,通过故障树的割集分析。
注2:参见多点故障(2.77)。
2.31
电子电气系统
电子/电气要素(2.32)构成的系统(2.129),包括可编程电子要素。
示例:电源;传感器或其他输入装置;通讯路径;执行器或其他输出装置。
2.32
要素
系统(2.129)、组件(2.15)(硬件、软件)、硬件元器件(2.55)或软件单元(2.125)。
2.33
嵌入式软件
在一个处理要素(2.32)上运行的充分集成的软件。
注:该处理要素通常是一个微控制器、一个现场可编程门阵列(FPGA)或者专用集成电路(ASIC),但是它也可以是一个更复杂的组件(2.15)或子系统。
2.34
紧急运行
按报警和降级概念(2.140)中所定义的,实现由故障(2.42)状态过渡到安全状态(2.102)的降级功能。
2.35
紧急运行时间间隔
用于支持报警和降级概念(2.140)所需要的紧急运行(2.34)的特定时间间隔。
注:紧急运行是报警和降级概念(2.140)的一部分。
2.36
错误
计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。
注1:错误可由未预见的工作条件引起或由所考虑的系统(2.129)、子系统或组件(2.15)的内部故障(2.42)引起。
注2:故障可表现为所考虑要素(2.32)内的错误,该错误可最终导致失效(2.39)。
2.37
暴露
处于某运行场景(2.83)的状态,在该运行场景下,如果发生所分析的失效模式(2.40),可能导致危害。
2.38
外部措施
独立于且不同于相关项(2.69)的措施,以减少或减轻由相关项导致的风险(2.99)。
2.39
失效
要素(2.32)按要求执行功能的能力的终止。
注:不正确的规范是失效的来源。
2.40
失效模式
要素(2.32)或相关项(2.69)失效的方式。
2.41
失效率
硬件要素(2.32)的失效(2.39)概率密度除以幸存概率。
注:失效率被假设为常数且通常用“λ”表示。
2.42
故障 fault
可引起要素(2.32)或相关项(2.69)失效的异常情况。
注1:考虑永久性故障(2.88)、间歇性故障和瞬态故障(2.135)(尤其软错误)。
注2:间歇性故障一再发生,然后消失。当一个组件(2.15)处于损坏的边缘时,或者例如由于开关的问题,间歇性故障可能会发生。某些系统性故障(2.131)(例如时序裕度不足)也可能导致间歇性故障。
2.43
故障模型
由故障(2.42)导致的失效模式(2.40)的表现。
注:故障模型一般基于现场经验或可靠性手册。
2.44
故障响应时间
从故障(2.42)探测到进入安全状态(2.102)的时间间隔。
2.45
故障容错时间间隔
在危害事件(2.59)发生前,系统(2.129)中一个或多个故障(2.42)可存在的时间间隔。
2.46
现场数据
从相关项(2.69)或要素(2.32)的使用中获得的数据,包含累加的运行时间、所有的失效(2.39)和服
务中的异常。
注:现场数据通常来自客户的使用。
2.47
形式记法
语法和语义上完整定义的描述方法。
示例:Z记法(Zed);符号模型检查(NuSMV);工程样机验证系统(PVS);Vienna开发方法(VDM)。
2.48
形式验证
基于以形式记法(2.47)定义的系统(2.129)所要求的行为,验证系统正确性的方法。
2.49
免于干扰
两个或两个以上的要素(2.32)之间,不存在可能导致违背安全要求的级联失效(2.13)。
示例1:如果要素2的失效(2.39)不会导致要素1失效,则要素1免于要素2的干扰。
示例2:如果要素3的失效导致要素4失效,则要素3干扰要素4。
2.50
功能概念
为了实现预期的表现,对所需的各预期功能及其交互的定义。
注:功能概念是在概念阶段(2.89)开发的。
2.51
功能安全
不存在由电子电气系统(2.31)的功能异常表现(2.73)引起的危害(2.57)而导致不合理的风险
(2.136)。
2.52
功能安全概念
为了实现安全目标(2.108),定义功能安全要求(2.53)及相关信息,并将要求分配(2.1)到架构要素
(2.32)上,以及定义要素之间的必要交互。
2.53
功能安全要求
定义了独立于具体实现方式的安全(2.103)行为,或独立于具体实现方式的安全措施(2.110),包括
安全相关的属性。
注1:功能安全要求可以是由安全相关的电子电气系统(2.31)或基于其他技术(2.84)的安全相关系统(2.129)所执
行的安全要求,目的是通过考虑确定的危害事件(2.59),使相关项(2.69)达到或保持在安全状态(2.102)。
注2:功能安全要求的定义可独立于产品开发概念阶段(2.89)中使用的技术。
注3:安全相关的属性包括ASIL等级(2.6)信息。
2.54
硬件架构度量
用于评估(2.4)硬件架构(2.3)安全(2.103)有效性的度量。
注:单点故障(2.122)度量和潜伏故障(2.71)度量都是硬件架构度量。
2.55
硬件元器件
硬件组件(2.15)的一部分。
示例:微控制器的CPU、电阻、电容。
2.56
伤害
对人身健康的物理损害或破坏。
2.57
危害
由相关项(2.69)的功能异常表现(2.73)而导致的伤害(2.56)的潜在来源。
注:该定义仅限于GB/T 34590;危害的一个更通常定义是伤害的潜在来源。
2.58
危害分析和风险评估
为了避免不合理的风险(2.136),对相关项(2.69)的危害事件(2.59)进行识别和归类的方法以及定
义防止和减轻相关危害的安全目标(2.108)和ASIL等级(2.6)的方法。
2.59
危害事件
危害(2.57)和运行场景(2.83)的组合。
2.60
同构冗余
对一个要求的多个完全相同的实现。
2.61
独立性
不存在会导致违安全要求的两个或多个要素(2.32)间的相关失效(2.22),或从组织上分隔执行活
动的各方。
注:根据定义,ASIL分解(2.7)或认可措施(2.17)包括独立性要求。
2.62
非相关失效
同时或相继失效的概率可表示为无条件失效概率的简单乘积的失效(2.39)。
2.63
非形式记法
非完整语法定义的描述方法。
示例:以图形或图表的方式描述。
注:不完整的语法定义指语义学也没有完整的定义。
2.64
非形式验证
不属于半形式或形式验证(2.48)的验证(2.137)方法。
示例:设计评审(2.98);建模评审。
2.65
继承
在开发过程中,某些要求的属性以一种未改变的方式传递到下一细节层面。
2.66
初始的ASIL等级
由危害分析和风险评估(2.58)得出的或由先前ASIL分解(2.7)得出的ASIL(2.6)等级。
注:初始的ASIL等级是ASIL分解(2.7)或ASIL等级进一步分解的起点。
2.67
检查
为发现异常而依据一个正式的流程对工作成果进行的考查。
注1:检查是验证(2.137)的一种方式。
注2:检查不同于测试(2.134),检查通常不包括对相关项(2.69)或要素(2.32)的操作。
注3:发现的异常经常通过重做予以解决,随后对重做的成果重新检查。
注4:一项正规的流程通常包括预先定义的步骤、检查列表、核对人员及对结果的评审(2.98)。
2.68
预期功能
为相关项(2.69)、系统(2.129)或要素(2.32)定义的不包含安全机制(2.111)的行为。
2.69
相关项 item
适用于GB/T 34590-2017,实现车辆层面功能或部分功能的系统(2.129)或系统组。
2.70
相关项开发
实现相关项(2.69)的完整过程。
2.71
潜伏故障
未被安全机制(2.111)探测到且在多点故障探测时间间隔(2.78)内未被驾驶员感知的多点故障(2.77)。
2.72
生命周期
相关项(2.69)从概念到报废的全部阶段(2.89)。
2.73
功能异常表现
失效(2.39)或与设计意图相悖的相关项(2.69)非预期表现。
2.74
基于模型的开发
一种使用模型描述要素(2.32)功能行为的开发。
注:根据模型使用的层次,该模型可用于仿真和代码生成。
2.75
修改
经过授权的相关项(2.69)的变更。
注1:在GB/T 34590中,为剪裁生命周期(2.72)对复用的部分使用“修改”。
注2:变更用于相关项(2.69)的生命周期过程中,而修改用于由已有的相关项生成新的相关项。
2.76
多点失效
由几个独立的故障(2.42)组合引发,直接导致违背安全目标(2.108)的失效(2.39)。
2.77
多点故障
与其他独立故障组合而导致一个多点失效(2.76)的单独故障(2.42)。
注:一个多点故障仅在识别出多点失效后才能被辨认出来,例如,通过故障树的割集分析。
2.78
多点故障探测时间间隔
在可导致一个多点失效(2.76)前,将多点故障(2.77)探测出来的时间间隔。
2.79
新开发
开发一个具有先前未定义功能的相关项(2.69)的过程,或开发一个对现有功能的新的实现方式的
相关项的过程,或两者都有。
2.80
非功能性危害
由电子电气系统(2.31)、基于其他技术(2.84)的安全相关系统(2.129)或外部措施(2.38)的不正确
功能之外的其他因素导致的危害(2.57)。
2.81
运行模式
相关项(2.69)或要素(2.32)的可感知的功能状态。
示例:系统(2.129)关闭;系统激活;系统非激活;降级运行;紧急运行(2.34)。
2.82
运行时间
相关项(2.69)或要素(2.32)工作的累积时间。
2.83
运行场景
在车辆生命周期中可发生的场景。
示例:行驶;驻车;维护。
2.84
其他技术
不同于GB/T 34590规定范围内的电子电气技术的技术。
示例:机械技术;液压技术。
注:其他技术可在安全要求(参见GB/T 34590.3-2017和GB/T 34590.4-2017)分配(2.1)过程中、
在功能安全概念(2.52)(参见GB/T 34590.3-2017第8章和图2)中定义,或作为外部措施(2.38)被考虑。
2.85
分区
为实现某种设计,而对功能或要素(2.32)的分隔。
注:分区可用于抑制故障(2.42)以避免级联失效(2.13)。为实现分区设计要素间的免于干扰(2.49),
可引入额外的非功能性要求。
2.86
乘用车
设计和制造上主要用于载运乘客及其随身行李和/或临时物品的汽车,包括驾驶人座位在内最多不
超过9个座位。它也可以牵引一辆中置轴挂车。
2.87
可感知的故障
在规定的时间间隔内由驾驶员推断出的故障(2.42)。
示例:故障可直接通过明显的系统(2.129)表现或性能的限制而感知。
2.88
永久性故障
发生并持续直到被移除或修复的故障(2.42)。
注:直流(DC)故障,例如卡滞故障和桥接故障是永久性故障。系统性故障(2.131)主要表现为永久性故障。
2.89
阶段
在GB/T 34590特定部分中定义的安全生命周期(2.72)的阶段。
注:GB/T 34590中的阶段在特定的部分中定义,例如:GB/T 34590.3-2017、GB/T 34590.4-2017、GB/T 34590.5-2017、GB/T 34590.6-2017和GB/T 34590.7-2017分别定义了阶段:
---概念;
---系统层面产品开发;
---硬件层面产品开发;
---软件层面产品开发;
---生产和运行。
2.90
在用证明
通过分析候选项(2.12)应用的现场数据(2.46),得出该候选项会影响相关项(2.69)安全目标
(2.108)的任何失效(2.39)的可能性满足适当ASIL(2.6)等级要求的证据。
2.91
在用证明置信度
通过在用证明(2.90)对一组给定的生命周期(2.72)子阶段(2.128)及相应工作成果的替代。
2.92
随机硬件失效
在硬件要素(2.32)的生命周期中,非预期发生并服从概率分布的失效(2.39)。
注:可在合理的精度内预测随机硬件失效率(2.41)。
2.93
合理可预见的事件
技术上可能并具有置信度或可测发生率的事件。
2.94
冗余
对要素(2.32)而言,存在除了足够实现其所需功能或表示信息的方法之外的方法。
注:GB/T 34590中的冗余用于实现安全目标(2.108)或特定安全要求,或者表示安全相关信息。
示例1:复制的功能组件(2.15)是冗余的一个实例,其目的是增加可用性(2.8)或允许故障(2.42)检测。
示例2:在表示安全相关信息的数据上增加奇偶校验位,是为允许故障检测提供了冗余。
2.95
回归策略
一种用于验证一个已实施的变更不会影响到相关项(2.69)或要素(2.32)中未变更的、已存在的和
先前验证过的部件或特性的策略。
2.96
残余故障
发生在硬件要素(2.32)中,能导致违背安全目标(2.108)且未被安全机制(2.111)覆盖的故障(2.42)
部分。
注:假设硬件要素的安全机制仅覆盖了该故障的一部分。
示例:如果对一个失效模式(2.40)声明了低覆盖率(60%),则该失效模式的其余40%就是残余故障。
2.97
残余风险
实施安全措施(2.110)后剩余的风险(2.100)。
2.98
评审
根据评审目的,为实现预期的工作成果目标而对工作成果进行的检查。
注:可用核对表支持评审。
2.99
风险
伤害(2.56)发生的概率及其严重度(2.120)的组合。
2.100
鲁棒性设计
在无效的输入或有压力的环境条件下,具有正确工作的能力的设计。
注:对鲁棒性可作如下理解:
---对于软件,鲁棒性是指应对异常输入和条件的能力;
---对于硬件,鲁棒性是指在设计范围和使用寿命内对环境压力的承受能力和稳定能力;
---在GB/T 34590上下文中,鲁棒性是在边界范围内提供安全行为的能力。
2.101
安全故障
不会显著增加违背安全目标(2.108)的概率的故障(2.42)。
注1:如GB/T 34590.5-2017附录B所示,非安全相关和安全相关要素(2.113)都可能有安全故障。
注2:单点故障(2.122)、残余故障(2.96)和双点故障不视为安全故障。
注3:除非在安全概念中表明具有相关性,否则,大于2阶的多点故障(2.77)可被认为是安全故障。
2.102
安全状态
没有不合理风险(2.99)的相关项(2.69)的运行模式(2.81)。
示例:预期运行模式;降级运行模式;关闭模式。
2.103
安全
没有不合理的风险(2.136)。
2.104
安全活动
在安全生命周期(2.72)的一个或多个子阶段(2.128)进行的活动。
2.105
安全架构
用于实现安全要求的一系列要素(2.32)以及它们之间的交互。
2.106
安全档案
将收集了开发过程中安全活动的工作成果作为证据,证明完整地实现了相关项(2.69)的安全要求。
注:安全档案可以扩展到包括GB/T 34590范围以外的安全(2.103)问题。
2.107
安全文化
组织内部用于支持安全相关系统(2.129)的开发、生产、运行、服务和报废的政策和策略。
注:参见 GB/T 34590.2-2017附录B。
2.108
安全目标
最高层面的安全要求,是危害分析和风险评估(2.58)的结果。
注:一个安全目标可能与几种危害(2.57)有关,几个安全目标可能与一种单一的危害有关。
2.109
安全经理
在相关项(2.69)的开发中,负责功能安全(2.51)管理的人员。
2.110
安全措施
用以避免或控制系统性失效(2.130)、探测随机硬件失效(2.92),控制随机硬件失效或减轻它们的
有害影响的活动或技术解决方案。
示例:FMEA和未使用全局变量的软件。
注:安全措施包括安全机制(2.111)。
2.111
安全机制 safetymechanism
为了达到或保持某种安全状态(2.102),由电子电气系统的功能或要素(2.32)或其他技术(2.84)来
实施的技术解决方案,以探测故障(2.42)、控制失效(2.39)。
注1:在相关项(2.69)中实施安全机制以避免故障导致单点失效(2.121)或减少残余失效,并防止故障潜伏。
注2:如同在功能安全概念(2.52)中定义的,安全机制也可是:
a) 能够使相关项过渡到或保持在安全状态;或
b) 能够向驾驶员发出提醒以控制失效(2.39)的影响。
2.112
安全计划
管理和指导开展项目安全活动(2.104)的计划,包括日期、节点、任务、可交付成果、职责和资源。
2.113
安全相关要素
潜在的有助于违背或实现安全目标(2.108)的要素(2.32)。
注:如果失效-安全要素可能违背至少一个安全目标,那么该失效-安全要素被认为是与安全相关的。
2.114
安全相关功能
潜在导致违背安全目标(2.108)的功能。
2.115
安全相关的特殊特性
相关项(2.69)、要素(2.32)或其生产过程的特性,这些特性的合理可预见偏差可能影响、促使或造
成任何潜在的功能安全(2.51)降低。
注1:GB/T 18305中定义了特殊特性的术语。
注2:安全相关的特殊特性在相关项或要素的开发阶段(2.89)中得出。
2.116
安全确认
基于检查和测试,确认充分实现了安全目标(2.108)。
注:GB/T 34590.4-2017提供了合适的确认方法。
2.117
半形式记法
语法定义是完整的,但语义定义可以是不完整的描述方法。
示例:结构化分析与设计技术(SADT);统一建模语言(UML)。
2.118
半形式验证
基于半形式记法(2.117)的验证(2.137)。
示例:使用由半形式模型生成的测试向量测试系统(2.129)表现与模型是否匹配。
2.119
服务说明
在执行相关项(2.69)的维护流程时所考虑的安全(2.103)信息文档。
示例:安全相关的特殊特性(2.115);所需的安全操作。
2.120
严重度
对可能发生在潜在危害场景中的一个或多个人员的伤害(2.56)程度的预估。
注:在危害分析和风险评估(2.58)中参数“S”代表潜在伤害的严重度。
2.121
单点失效
由单点故障(2.122)引起并直接导致违背安全目标(2.108)的失效(2.39)。
注1:单点失效等同于诊断覆盖率(2.25)为0%的要素(2.32)的残余失效。
注2:如果为一个硬件要素(例如,微控制器的看门狗)定义了至少一个安全机制(2.111),那么,所考虑
硬件要素的故障(2.42)都不是单点故障(2.122)。
2.122
单点故障
要素(2.32)中没有被安全机制(2.111)所覆盖,并且直接导致违背安全目标(2.108)的故障(2.42)。
注:参见单点失效(2.121)。
2.123
软件组件
一个或多个软件单元(2.125)。
2.124
软件工具
在开发相关项(2.69)或要素(2.32)中所用到的计算机程序。
2.125
软件单元
软件架构(2.3)中的最低层级且可被孤立测试(2.134)的软件组件(2.123)。
2.126
特殊用途车辆
由于执行一种专业的或娱乐的功能而需要特殊的车身布置和设备的车辆。
示例:旅居车、装甲车、救护车、殡仪车、拖挂房车、移动吊车。
2.127
语句覆盖率
软件中已执行语句所占的百分比。
2.128
子阶段
安全生命周期(2.72)中某个阶段的细分且其在GB/T 34590中有明确的章条描述。
示例:危害分析和风险评估(2.58)是安全生命周期的子阶段,在GB/T 34590.3-2017第7章中进行了描述。
2.129
系统
一组至少与一个传感器、一个控制器和一个执行器相关联的要素(2.32)。
注1:相关的传感器或执行器可包含在系统中,也可存在于系统之外。
注2:系统中的要素也可能是另一个系统。
2.130
系统性失效
以确定的方式与某个原因相关的失效(2.39),只有对设计或生产流程、操作规程、文档或其他相关
因素进行变更后才可能排除这种失效。
2.131
系统性故障
以确定的方式显现失效(2.39)的故障(2.42),只有通过使用流程或设计措施才有可能防止其发生。
2.132
技术安全概念
技术安全要求(2.133)的定义和为了能够通过系统设计实现功能而将技术安全要求向系统(2.129)
要素(2.32)的分配(2.1)。
2.133
技术安全要求
为实现相关的功能安全要求(2.53)而得出的要求。
注:得出的要求包括减轻失效所需的要求。
2.134
测试
通过计划、准备、运行或演练相关项(2.69)或要素(2.32),以验证其满足所定义的要求、探测其异常
(2.2)、对其行为建立信心的过程。
2.135
瞬态故障
发生一次且随后消失的故障(2.42)。
注:瞬态故障可由电磁干扰引起,其可导致位翻转。软错误,如单粒子翻转效应(SEU)和单粒子瞬态脉冲(SET),
均为瞬态故障。
2.136
不合理的风险
按照现行的安全观念,被判断为在某种环境下不可接受的风险(2.99)。
2.137
验证
确定某个阶段(2.89)或子阶段(2.128)的要求是否完整且正确的定义或实现。
2.138
验证评审
确保开发活动结果满足项目要求和/或技术要求的验证(2.137)活动。
注1:验证评审的单独要求在GB/T 34590的单独部分中的特定章条中给出。
注2:验证评审的目标是确认相关项(2.69)或要素(2.32)的技术正确性和完整性。
示例:技术评审(2.98)、走查(2.139)、检查(2.67)。
2.139
走查
为了发现异常,对工作成果(2.142)的系统性检查。
注1:走查是验证(2.137)的一种方法。
注2:走查与测试(2.134)的区别在于,走查通常不涉及相关项(2.69)或要素(2.32)的运行。
注3:被发现的任何异常通常通过重做来处......
英文网页: GB/T 34590.1-2017
相关标准: GB/T 34590.11|GB/T 34590.5|GB/T 34590.6|GB/T 34590.4|GB/T 34590.1-2017|GB/T 34590.1|