本文来自功能安全工程师认证学习内部资料,内容主要包括ISO 26262词汇解析以及缩略词汇解释,会对功能安全认证学习以及汽车行业工程师有所帮助。
ISO 26262 词汇表
ISO和IEC对负责维护专业词汇的定义,词汇表如下:
|
词汇 |
词汇解释 |
|
architecture |
表示所有元素的结构,由区块、边界、接口等这些区块相关的事物组成。 |
|
ASIL |
Automotive safety intergrity level,汽车功能安全级别。一共有四个级别,代表了该元素对安全的需求。D是最高级别。 |
|
ASIL capability |
满足特定ASIL级别安全需求的能力。是硬件功能安全的一部分,包含分配给某元素的故障指标。 |
|
ASIL decomposition |
ASIL分解是一种裁剪方法,它将安全荣誉分配给元素,每个元素要具有独立性,共同达到安全目标。 |
|
assessment |
评估一个元素是否达到了ISO 26262的目标 |
|
audit |
审计,即检查有关目标的已实施过程是否符合规范 |
|
availability |
产品在给定的条件下,全生命周期正常运转的能力 |
|
BFR |
Base failure rate,在给定的条件下,硬件故障率 |
|
Base vehicle |
一个基本汽车配置的标准 |
|
baseline |
基线:一个变更下的基本版本,一般用于配置管理,在其中作为下一步开发的基础 |
|
BB |
Body builder,主机厂。 |
|
Body builder equipment |
安装在base vehicle上的设备 |
|
Branch coverage |
分支覆盖率。软件测试包含所有控制分支的比率。100%的分支覆盖率代表100%的代码覆盖率。 |
|
bus |
9座以上汽车 |
|
Calibration data |
软件完成后,其中使用的参数。例如国家代码,节流阀极限值。不包含代码。 |
|
candidate |
具有共性的元素 |
|
Cascading failure |
级联故障。元素失效导致其他元素连锁失效。 |
|
CCF |
Common cause failure,常见故障 |
|
CMF |
Common mode failure,多个元素以相同的方式失效 |
|
Complete vehicle |
全装车辆加制造设备 |
|
component |
是系统的一部分(但不是系统),例如一个软件单元或一个微控制器。 |
|
Configuration data |
配置数据,在构建元素(生产)过程中产生的数据。 |
|
Confirmation measure |
衡量功能安全项 |
|
Confirmation review |
确认一项工作能够提供足够的证据,证明其符合功能安全相关的需求 |
|
controllability |
通过人为操控避免特定损害的能力 |
|
Coupling factors |
耦合因子,导致元素失效的共同特性 |
|
Dedicated measure |
度量违反了安全目标导致失效的几率 |
|
degradation |
功能降级 |
|
Dependent failures |
关联的失效,即将所有失效概率独立计算后,与实际概率不一致 |
|
DFI |
Dependent failure initiator,独立的根因通过耦合因子导致多个元素失效 |
|
Detected fault |
安全机制在规定时间内检测到的故障 |
|
DIA |
Development interface agreement,开发协议。供应商和客户之间的协议,包含了扮演的角色,产品,验证证据等。DIA代表了开发阶段的协议,supply areement代表了生产阶段的协议。 |
|
DC |
Diagnostic coverage,诊断覆盖率。硬件元素失效被安全机制探测到的比率。 |
|
Diagnostic points |
诊断点。当探测到失效时,发出的信号。 |
|
Diagnostic test time interval |
诊断间隔。某个安全机制执行的间隔时间。 |
|
Distributed development |
将一个元素开发过程分解到多个客户或供应商 |
|
diversity |
相同需求的不同解决方案。为了实现冗余,或者独立,可以解决common cause failures。 |
|
Dual-point failure |
两个独立的硬件失效导致的失败,直接违反了安全目标 |
|
Dual-point fault |
独立的错误,和其他错误一起导致dual-point failure。 |
|
E/E System |
Electrical and electronic system。电子电气系统。 |
|
element |
元素。例如系统、组件、硬件部分、软件单元等。 |
|
Embedded software |
嵌入式软件,可以完全植入一个处理单元。 |
|
Emergency operation |
紧急操作。应对一个错误的操作模式,直到达到安全状态。当安全状态不能直接达到时,安全机制可以要求此元素进入emergency operation直到达到安全状态。例如Degradation。 |
|
EOTI |
Emergency operation time interval。维持emergency operation的时间, |
|
EOTTI |
Emergency operation tollerance time interval。EOTI的最大值。
|
|
error |
和定义的正确情况不一致 |
|
Expert rider |
骑术高手(测试员)。测试摩托车的可操控性的角色。 |
|
exposure |
经过分析在某种状态下可能会有危险 |
|
External measure |
外部测量。使用不同的方式进行风险的测量。 |
|
failure |
由错误引起的失效。 |
|
Failure mode |
失效模式。某个元素不能提供期望的行为时的模式。 |
|
FMC |
Failure mode coverage。失效模式覆盖率。安全机制能够探测控制的失效模式的覆盖率。 |
|
Failure rate |
失效的可能性。 |
|
fault |
非正常的状态,可能导致元素失败 |
|
FDTI |
Fault detection time interval。错误发生到探测到此错误的时间。 |
|
FHTI |
Fault handling time interval。错误探测时间和响应时间之和。 |
|
Fault injection |
错误注入。为了评估错误的影响,人为注入一个错误以观察反应。 |
|
Fault model |
错误模型 |
|
FRTI |
Fault reaction time interval。从错误发现,到进入安全状态之间的时间。 |
|
Fault tolerance |
在特定的一个或多个错误下仍然能实现功能的能力 |
|
FTTI |
Fault tolerant time interval。在安全机制没启动的情况下,从错误发生到危险发生最小的时间。
|
|
Field data |
在某元素工作中持续积累的数据 |
|
Formal notation |
正式定义的信息 |
|
Formal verification |
正式的验证方法,根据已定义的属性证明元素是正确的 |
|
Freedom from interference |
不受干扰的特性 |
|
Functional concept |
定义功能和交互以实现期望的行为。functional concept在概念阶段确定。 |
|
Functional safety |
不存在不合理的风险 |
|
Functional safety concept |
定义安全需求和相关信息 |
|
Functional safety requirement |
定义独立实施的安全行为和安全检测包含所有安全属性 |
|
Hardware architectural metrics |
硬件架构度量。度量硬件安全架构的效率。 |
|
Hardware part |
第一层硬件架构分解的硬件组件 |
|
Hardware elementary subpart |
在安全分析中最小硬件子部件 |
|
Hardware subpart |
硬件子部件 |
|
harm |
对人体造成物理伤害 |
|
hazard |
潜在可能发生的物理伤害 |
|
HARA |
hazard analysis and risk assessment,危险分析和风险评估。针对ASIL安全目标分类危害的方法,目的是避免不合理的风险。 |
|
Hazardous event |
可操作的危险场景 |
|
independence |
独立的。非多个因素作用导致违反安全需求的。 |
|
Independent failures |
独立的失败,总概率可以简单表示为多个失败概率的乘积 |
|
Informal notation |
非正式的定义 |
|
inheritance |
在开发过程中在下一个级别使用和本级别相同的风格 |
|
inspection |
使用正式流程检查工作产出,目的是发现安全问题 |
|
Intended functionality |
预期功能。为某个事物定义的行为,包含安全机制 |
|
item |
系统或系统集成,应用ISO26262的主体 |
|
Latent fault |
潜在错误。未被探测到的多点失效或在FDTI内未被感知到的错误。 |
|
lifecycle |
生命周期 |
|
Management system |
组织为了达到目标所采用的政策过程流程体系。 |
|
Malfunctioning behaviour |
失灵行为。错误或未预期的行为。 |
|
Maximum time to repair time interval |
安全状态保持时间。 |
|
MBD |
Model-based development。面向模型开发。 |
|
modification |
从存在的项里创建一个新项 |
|
MC/DC |
Modified condition / decision coverage。条件/判定覆盖。独立影响输出的控制流被检验过的覆盖率。 |
|
motorcycle |
摩托车,两轮 |
|
MSIL |
Motorcycle safety integrity levle。摩托车的ASIL。 |
|
multi-core |
多核,硬件 |
|
Multiple-point failure |
多个独立的硬件错误导致违反了安全目标 |
|
Multiple-point fault detection time interval |
检测到多点错误的时间 |
|
New development |
创建一个新的之前未有的功能,或用新方法重新实现 |
|
Non-functional hazard |
不是由于制造商导致的危害 |
|
Observation points |
观察点。元素在可能出错误的地方输出信号用于观察。 |
|
Operating mode |
行为模式,例如开关 |
|
Operating time |
行为时间。 |
|
Operational situation |
行为情况。汽车在生命周期内可能遇到的场景。 |
|
Other technology |
非E/E相关的技术 |
|
partitioning |
为了达到目标进行元素分离 |
|
Passenger car |
小客车 |
|
Perceived fault |
可以间接感知的错误 |
|
Permanent fault |
永久错误。发生之后一直存在除非被修复。 |
|
phase |
阶段。 |
|
POF |
Physics of failure。物理错误。科研角度的错误。 |
|
PTO |
Power take-off 上电按钮(接口) |
|
PE |
Processing element 处理器。 |
|
PLD |
Programmable logic device。可编程逻辑设备。硬件 |
|
Proven in use credit |
使用中的得到的证明 |
|
QM |
Quality management 质量管理 |
|
Random hardware failure |
不可预测的、符合概率分布的硬件失效 |
|
Random hardware fault |
符合概率分布的硬件错误 |
|
Reasonably foreseeable |
合理可预见。可测量的技术概率 |
|
rebuilding |
调整配置以实现另一个不同的任务 |
|
redundancy |
冗余 |
|
Regression strategy |
回归策略。检验变更是否起作用的策略。 |
|
remanufacturing |
再制造。用新部件分解翻新旧汽车。 |
|
Residual fault |
部分随机硬件故障,不受安全措施控制。 |
|
Residual risk |
当部署安全措施之后残余的风险 |
|
review |
检查工作成果 |
|
risk |
风险。发生伤害的可能性 |
|
Robust design |
健壮性设计。可以接受错误输入和承受系统压力的设计。对软件来说,可以接收错误输入和环境但不引起错误。对硬件来说,可以容忍恶劣的环境。 |
|
Safe fault |
安全错误。是一个错误但是不会明显提升安全问题概率。 |
|
Safe state |
安全状态。可操作的模式,不会有不合理的风险。正常操作即为安全,例如人正常操作汽车的状态。 |
|
safety |
安全。没有不合理的风险。 |
|
Safety activity |
安全活动。在安全生命周期中的一个或多个时期中的某项活动。 |
|
Safety anomaly |
安全偏离。工况偏离预期,可能会导致损害。 |
|
Safety architecture |
安全架构。元素组和它们之间的交互,以实现安全需求 |
|
Safety case |
安全用例。论述符合安全要求的实例。 |
|
Safety culture |
安全文化。企业在安全目标上的价值、态度、动机、知识,体现在决定和行动上。 |
|
SEooC |
Safety element out of context 无背景安全因素。这个安全元素不需要背景,在任何情况下是通用的。 |
|
Safety goal |
最顶层的安全需求。汽车级别的安全目标。 |
|
Safety manager |
安全经理。负责整体执行必要的安全活动的人或组织。 |
|
Safety measure |
安全措施。安全相关的活动或技术方案,例如探测失败、损害迁移 |
|
Safety mechanism |
安全机制。技术解决方案,可以探测、容忍、避免错误。 |
|
Safety plan |
管理和执行安全活动的计划,包括时间、里程碑、任务、交付物、责任和资源等 |
|
safety-related elenment |
安全相关的元素。 |
|
safety-related function |
安全相关的功能。 |
|
Safety-related incident |
安全相关的故障。 |
|
Safety-related special characteristic |
项目、元素或生产过程中产生的安全特征。 |
|
Safety validation |
安全验证。基于检查和测试,保证安全目标达到了特定的ASIL级别 |
|
Semi-formal notation |
半正式定义。不完整的描述。 |
|
Semi-formal verification |
半正式验证。 |
|
semi-trailer |
半挂车 |
|
Series production road vehicle |
量产车辆。非原型。 |
|
Service note |
服务文档 |
|
severity |
潜在危险事件中可能发生的对一个或多个人伤害程度 |
|
Single-point failure |
单点失效 |
|
Single-point fault |
点点错误 |
|
Software component |
一个或多个软件单元 |
|
Software tool |
用来开发的电脑程序 |
|
Software unit |
软件单元,可以拆分到单元测试的软件部分 |
|
Statement coverage |
软件中能够运行的部分比率 |
|
sub-phase |
安全生命周期中的一个子时期 |
|
Supply agreement |
供应协议 |
|
system |
系统 |
|
Systematic failure |
系统性失败。由确定原因导致的失败,只能通过改变设计、生成工艺等来消除。 |
|
Systematic fault |
系统性错误。 |
|
Target environment |
目标环境。软件指定的期望的运行环境。 |
|
Technical safety concept |
技术安全要求。包含了每一个系统元素的安全需求。 |
|
Technical safety requirement |
技术安全需求。从功能安全需求衍生出的技术上的需求。 |
|
testing |
测试 |
|
tractor |
拖拉机 |
|
trailer |
拖车 |
|
transducer |
变换器 |
|
Transient fault |
临时错误。发生一次随后消失的错误。 |
|
truck |
卡车 |
|
T&B vehicle configuration |
基础车辆配置 |
|
Unreasonable risk |
不合理风险,社会伦理道德不能接受的风险。 |
|
Variance in T&B vehicle operation |
车辆操作差异 |
|
Vehicle function |
车辆功能 |
|
Vehicle operating state |
操作状态。操作模式的集合 |
|
verification |
验证,决定检查结果是不是符合需求 |
|
Verification review |
验证评审 |
|
walk-through |
过一遍,系统检查产品,为了发现不正常的安全情况。 |
|
Warning and degradation starategy |
通过警告和降级的方式减少功能,达到安全状态 |
|
well-trusted |
可信的。以前用过没发现不安全情况。 |
|
Work product |
ISO 26262相关工作文档 |


1622

被折叠的 条评论
为什么被折叠?



