一文解读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

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

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

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

相关推荐
jimmyleeee1 小时前
大模型安全之二十二:AI 安全实践:真实案例研究与经验教训
人工智能·安全
咖啡星人k1 小时前
给 AI 接工具的权限设计:账号、Key、参数三层
安全·mcp·权限设计
jimmyleeee3 小时前
大模型安全之二十八:Agent 权限与策略控制:从最小权限到多层监督
人工智能·安全
hasty3 小时前
一封邮件如何跨越三层边界拿到 root?Cisco Secure Email Gateway CVE-2026-76461 深度解析
安全·安全威胁分析·代码复审
是隼人3 小时前
buuctf-pwn ciscn_2019_sw_1(32位只有一次格式化机会)题解(学习过程持续更新)
c语言·学习·安全·pwn入门·ctf入门
三8444 小时前
云安全 · 06 · 云凭证 AK/SK 与元数据服务
安全·云安全·docker逃逸·ak/sk
xixiaoyunya6 小时前
制造业生产数据备份:在“不停产“前提下的自动化实践
网络·安全
jimmyleeee6 小时前
大模型安全之二十五:Agent AI 威胁全景
人工智能·安全
kali-Myon6 小时前
分享一个网络安全 AI 工具导航项目 SecSkills
安全·ai·github·ctf
EasyGBS18 小时前
终结训推割裂!EasyGBS×EasyAIS×DLTM,实现AI算法训推一体闭环落地!
服务器·深度学习·安全