你真的了解安全确认(Safety Validation)吗?

lidenghui

安全确认(Safety Validation)是功能安全开发必不可缺的环节，位于系统开发V模型右侧最上方，是对相关项功能安全开发结果的确认，为安全目标的实现提供保证。

本文围绕以下问题展开，旨在帮助朋友们进一步了解安全确认相关内容:

什么是安全确认？

什么是安全接受准则？
接受准则 vs. 安全确认目标安全确认的方法有哪些？

一、什么是安全确认?

相信朋友们对验证(Verification)和确认(Validation)这两个概念都不陌生，它们之间的区别也比较容易理解，在此不再赘述:

验证(Verification): 关注过程，提供客观证据，证明过程满足相关规定的要求。

确认(Validation): 关注结果，提供客观证据，证明产品最终满足客户预期的功能或要求。

但什么是功能安全确认？根据ISO 26262定义，所谓的安全确认是指:

a) 提供证据，证明集成到目标车辆的相关项实现了其安全目标，并满足安全接受准则。

b) 提供证据，证明功能安全概念和技术安全概念对于实现相关项的功能安全是合适的。

这个定义相对比较抽象，且不利于具体实施，根据确定(Validation)最基本的定义，安全确认无非就是证明最初的安全需求，即安全目标以及对应的安全属性，是否得到最终的满足，并通过一定的定量化的指标，即接受准则，进行量化评判。

当然，在概念开发阶段，安全目标导出过程中，可能存在一些针对外部措施的假设，这些假设会直接影响安全目标的ASIL等级，所以也必须对其有效性进行最终确认。

所以，总结来看，安全确认主要包括以下内容:

a) 安全目标及ASIL等级；b) 外部措施及假设的有效性；

二、什么是安全接受准则?

在安全确认内容中，我们提到了接受准则，它是安全确认的量化指标，那到底什么是接受准则，它包含了哪些内容？

所谓的接受准则，是不存在不合理风险水平的准则，主要包括两个层面:

1

危害行为事件的接受准则
危害行为事件的接受准则主要针对安全目标及对应ASIL等级，旨在描述相关项最终违反特定安全目标及其ASIL等级的可能性必须低于一定可接受的水平。

2
总体安全风险的接受准则用于衡量相关项整体安全，保证相关项针对任何类型危害的残余风险的足够低，旨在评估相关项所实施的不同的技术安全措施的有效性。

总体安全风险的接受准则和预期功能安全SOTIF第二层接受准则，即残余风险的接受准则，内容一致，都需要通过大量覆盖不同运行场景的车辆长期测试数据，从概率或统计学角度去定义并衡量危害或事故发生的频率，例如，规定公里或运行时间范围内，事故发生的概率等，例如，事故发生率小于10^-8/h。

但对于功能安全而言，由于不存在未知-不安全的运行区域，只要保证相关项违反安全目标的危害足够低，则可以认为整体安全也同样得到保证，整体残余风险达到要求，所以只需要定义并实施安全接受准则第一个层面，即针对安全目标对应危害行为的风险接受准则，即可。

而对于预期功能安全SOTIF而言，由于还存在未知-不安全运行区域，安全目标对应危害不一定能够涵盖所有危害场景，还必须定义接受准则第二层面的内容，即整体安全风险接受准则，这个也是预期功能安全确认工作的困难所在！

三、接受准则 vs. 安全确认目标

聊完了接受准则，那它和安全确认目标有什么区别？

实际上，在汽车功能安全ISO 26262中，并没有专门提出安全确认目标这一概念，在安全确认中，只要满足接受准则关于安全目标的要求即可。

安全确认目标源于预期功能安全SOTIF，和接受准则第二层面的整体安全风险相关，它是基于整体安全残余风险接受准则导出的，属于便于实践操作的指标。

这部分内容我在前面文章有过论述，二者主要区别在于:

理论上安全确认目标可以和残余风险接受准则保持一致，但实际操作中安全确认目标不一定直接等于残余风险接受准则，主要原因在于:

1

残余风险接受准则是理论上的风险接受准则，而安全确认目标是实操目标
残余风险接受准则在制定过程中并不需要考虑危害事件本身发生的概率，场景的暴露概率等影响因素，只关注事故最终发生的概率必须在极小范围内，而安全确认目标是车辆最终发布前实际上需要满足的确认目标，属于实际操作目标，一般都需要通过具体的车辆测试进行证明，而在实际操作中，基本上不可能对所有危害场景进行完整且满足残余风险接受准则要求的时间或距离的测试。

2
可考虑场景影响因素，基于残余风险接受准则，导出相对较低且可实施的安全确认目标
在实际操作中，一般会根据残余风险接受准则，考虑其场景暴露的概率，可控性影响等影响因素，或提供充分证据，对风险较高的场景进行测试，或者根据系统架构，减少冗余测试的内容，间接地降低安全确认的目标，以此减少确认的工作量。

四、怎么定义安全接受准则?

根据上面的论述，对于功能安全而言，由于不存在未知-不安全的运行区域，安全接受准则只需要针对安全目标对应的危害相关内容即可。

安全目标ASIL等级本身是在HARA过程通过严重性(S)，暴露度(E)，可控性(C)这三个参数确定，其中严重性和暴露度都可以通过定量或定性分析直接确定，而可控性(C)的确定相对较为困难，会直接影响危害是否最终产生，在概念开发阶段一般通过仿真或者其他辅助性数据对其进行确定，所以在针对安全目标及ASIL等级的安全确认(Validation)，最后演变为针对可控性(C)参数的确认，因此需要定义针对可控性(C)参数的接受准则，并进行整车测试和评估，最终完成对ASIL等级的确认。
例如，对于制动系统，在危害严重的车辆运行场景下，注入系统故障，在故障产生后特定时间内，可以将车辆前进的距离作为可控性接受准则要求，并且可以进一步对前进的距离进行分类，指定特定的可控性等级。

Q: 安全确认的方法有哪些？

一般来讲，安全确认的方法包括:
a) 基于特定测试用例的整车测试；b) HiL测试
c) 安全分析(例如，FMEA、FTA)及仿真；d) 长期测试；e) 实际使用条件下的操作用例、抽测或盲测、专家小组；f) 评审根据接受准则的定义，安全确认可以是基于特定安全目标/危害事件的确认，或基于整体安全的确认，所以根据接受准则内容的不同，安全确认方法也存在一定差异。

1

针对特定安全目标/危害事件的安全确认
主要是安全目标以及外部相关假设的确认，多采用基于特定测试用例进行HiL或整车测试，需要复现安全目标对应的车辆危害事件的运行场景，并注入相应的故障，判断是否满足所定义的测试用例要求或者接受准则要求，并在定义的故障容错时间间隔内，车辆进入安全状态。

2
针对整体安全的确认需要基于长期测试，并结合一定的安全分析，以此提供相关项整体安全的证据。

对于功能安全而言，实际操作中，大多只需要进行基于特定安全目标/危害事件的安全确认即可，基于整体安全的确认可根据实际需要，适当进行。

写在最后:

安全确认(Validation)相关的内容我们就聊完了

，希望能够给朋友们对其带来更多理解。



END