一文解读ISO26262安全标准:术语(二)

一文解读ISO26262安全标准:术语(二)

本文继续补充一些标准中的术语,方便后续文章内容的有效理解。

分支覆盖率 branch coverage

控制流分支覆盖的比率. 100%分支覆盖率意味着100%语句覆盖率,比如,一个if语句一定要有两个分支:条件真和条件假,这样才算100%分支覆盖率。

语句覆盖率 statement coverage

指软件中已执行语句所占的百分比。

标定数据 calibration data

软件编译后将要应用的数据。比如,应用参数(例如,低怠速值,发动机特性图)。

级联失效 cascading failure

同一个item中,一个要素(element)的失效(failure)引起另一个或多个要素的失效。

共因失效 common cause failure,CCF

同一个item中,由一个根本原因引起的两个或者多个要素(element)的失效(failure)。

专用措施 dedicated measure

对违背安全目标(safety goal)的评估中声明的失效率(failure rate,针对硬件要素的失效)进行防护的措施。

比如,对来料进行专门的抽样测试,以降低与违背安全目标有关的失效模式的发生风险。

可探测的故障 detected fault

在规定的时间内,通过设计的安全机制(safety mechanism) 所探测到的故障,该安全机制用以防止故障(fault)变成潜伏故障。

比如,功能安全概念(functional safety concept,FSC)中定义的专门安全机制。

诊断测试时间间隔 diagnostic test interval

指安全机制(safety mechanism)执行在线诊断测试的时间间隔。

现场数据 field data

从相关项(item)或要素(element)的使用过程中获得的数据,包含累加的运行时间、所有的失效(failure)和维护中的异常。

现场数据通常来自于客户。

双点失效 dual-point failure

指由两个独立故障(fault)共同引起的、直接导致违背了安全目标(safety goal)的失效(failure),引起失效的这两个独立的故障又被称为双点故障(dual-point fault)。

对于直接违背安全目标的双点失效,两个独立故障的发生是必要的,也就是说残余故障(residual fault)和安全故障(safe fault)的组合不是双点失效,因为残余故障可以直接导致违背安全目标,与第二个独立故障是否发生是没有关系的。

单点失效 single-point failure

由单点故障(single-point fault)引起并直接导致违背安全目标(safety goal)的失效(failure)。

单点失效等同于诊断覆盖率(2.25)为0%的要素(2.32)的残余失效(2.42)

比如,为微控制器的看门狗定义了至少一个安全机制,那么,这些被考虑到的故障都不是单点故障。

所以,单点故障不是残余故障。

故障响应时间 fault reaction time

从探测到故障(fault),到进入安全状态(safe state)的时间间隔。

故障容错时间间隔 = 诊断测试时间 + 故障响应时间 + 安全状态生效时间

故障保护的过程 : 正常运行 -> 发生故障 -> 故障探测 -> 故障响应 -> 进入安全状态

安全故障 safe fault

不会显著增加违背安全目标(safety goal)概率的故障(fault)。

单点故障(single-point fault)、残余故障(residual fault)和双点故障(dual-point fault)不会是安全故障。

除非在安全概念中显示具有相关性,否则大于2阶的多点故障(multiple-point fault)可被认为是安全故障。

瞬态故障 transient fault

发生一次且随后消失的故障。

瞬态故障可由电磁干扰引起,会导致位翻转的发生。

单粒子翻转效应(SEU)和单粒子瞬态脉冲(SET)引起的错误,都是瞬态故障。

残余故障 residual fault

违背安全目标的硬件要素发生了故障,该故障未被安全机制覆盖。

如果对一个失效模式(failure mode,指引起失效的方式)声明了低覆盖率(60%),则该失效模式的其余40%就是残余故障。

残余风险 residual risk

采用安全措施(safety measure,指避免系统性失效的技术解决方案)后剩余的风险(risk)。

风险 risk

伤害(harm,指对人身健康的伤害)发生的概率及其严重度(severity,指对人员造成伤害的严重程度)的组合。

鲁棒性设计 robust design

指在异常的情况下,系统能正确工作的设计。

对于软件,鲁棒性是指应对异常输入和条件的能力;

对于硬件,鲁棒性是指在设计范围和使用寿命内对环境压力的承受能力和稳定能力;

相关推荐
紫金桥软件32 分钟前
紫金桥RealSCADA:国产工业大脑,智造安全基石
安全·系统安全·软件工程
柑木39 分钟前
隐私计算-SecretFlow/SCQL-SCQL的两种部署模式
后端·安全·数据分析
峥嵘life1 小时前
Android 欧盟网络安全EN18031 要求对应的基本表格填写
android·安全·web安全
光爷不秃1 小时前
Go语言中安全停止Goroutine的三种方法及设计哲学
开发语言·安全·golang
挨踢攻城5 小时前
IT资讯 | VMware ESXi高危漏洞影响国内服务器
安全·web安全·网络安全·vmware·虚拟化技术·厦门微思网络·vmware esxi高危漏洞
厦门辰迈智慧科技有限公司5 小时前
白蚁监测仪是什么,其工作原理和应用领域
物联网·安全·自动化·监测
OpenAnolis小助手6 小时前
朗空量子与 Anolis OS 完成适配,龙蜥获得抗量子安全能力
安全·开源·操作系统·龙蜥社区·龙蜥生态
百里晴鸢8 小时前
小白也能懂的iptables核心逻辑!四张表+五条链如何守护你的网络安全?
linux·安全
wanhengidc9 小时前
云手机选哪个比较好用?
服务器·网络·安全·游戏·智能手机
思通数据14 小时前
AI视频监控:重构安防行业智能化新生态
人工智能·安全·目标检测·机器学习·计算机视觉·重构·数据挖掘