如何理解预期功能安全（三）

在系统开发V模型中的上升阶段，什么时候意味着开发可以收口，系统达到了发布的条件，从风险管理的角度，就是说具备什么条件，意味着系统残余的风险可以接受，在预期功能安全中，可以总结为两句话：

一：所有已知的风险已有对应措施进行了控制（区域2）——ISO21448第10节

二：所有未知的风险在实际运行中已经足够小（区域3）——ISO21448第11节

下面对这两个方面展开谈谈

第一句是对已知的不安全情况（区域2）进行评估，确保在采取SOTIF缓解措施的情况下，已知情况下导致危害事件，不存在不合理的风险了。缓解措施可能包括限制系统应用范围ODD，进行传感器和算法的冗余设计。风险接受的重点在于是否根据已知的缓解措施对传感器、算法、执行器和集成后的系统进行有针对性的测试。ISO21448提供了一系列测试方法的组合，包括分析、模拟仿真和实车测试，用于对区域2的各种场景进行全面的测试。

验证技术的运用不那么简单，寥寥数语，实际做起来非常考验安全和验证人员的能力。举个例子，对于第一点，已知不安全情况的风险评估，在采用了冗余的系统架构时，不同计算通道的独立性是需要验证的。而独立性要从系统失效的独立性（软件和硬件）和随机失效的独立性（硬件）两个方面进行验证，例如软件系统性失效方面如使用了两个不同类型算法的分类器，但采用了相同的数据集进行训练，容易对相同的样本产生同一错误的输出，因此建议采用有区分度的数据集进行训练，硬件系统性失效，如主计算通道和辅计算通道采用了不同的硬件平台进行冗余计算，但存在采用了同一电源，在同一个电路板上，存在由于电源波动和EMI干扰，导致多样化硬件同时失效的情况，这些都是系统保证独立性需要考虑的因素。

比如在基于触发事件进行场景测试时，要求单个触发事件有明确的场景条件，基于场景可以去构建测试案例，如果危害分析中的触发事件比较笼统，则需要进行额外的分析，以建立基于场景的测试案例。以车道保持系统触发事件——车道线被覆盖导致相机无法检测到，需要考虑的场景变量就有很多种：

车辆行驶的地点有：出入高速口、车道并窄、分叉口、弯道左转、弯道右转、施工维修路障；

覆盖物类型有：水完全淹没、雪、沙、雨水淋、泥浆、淤泥、标线模糊、跌落异物。

ODD不同场景的延展 （取自网络）

第二句是对未知的不安全情况（区域3）进行评估，这是非常具有挑战性的，仅靠测试里程的不断累积显然无法达到目标，需要综合运用结构化的分析技术（如引导词头脑风暴HAZOP）和道路测试，暴露未知不安全的场景。在SOTIF过程中，识别未知不安全场景所需的测试范围仍然是一个尚未解决的问题，测试范围与场景的类别和分布相关联，能够覆盖ODD的所有要素，并考虑到以前的经验成果、司机的可控性和其它因素。

ISO21448附录C提供了一种方法，先设定一个里程目标值，在测试范围中识别出了新的未知不安全场景，就需要补充新的类型的测试，以针对设计更改的范围。

总结以上，在ISO21448中对于区域2和区域3给出的指导性原则方法，在实际项目中进行延展，构建一套完整的结构化分析方法和测试场景库。

那么，什么是预期功能安全最终的衡量标准，可以考虑的方法有：

1. 与现有的交通数据（如碰撞事故统计、数据分析）比较；
   

2. 现行行业中类似功能预先存在的目标；

3. 与人类驾驶员行为的对比
   

4. 其它的风险接受准则（GAMAB、ALARP等）。
   

对于L2和L3级系统，由于存在着自动驾驶系统与人之间的权限过渡，如果系统不能实现驾驶任务，但是能安全地让司机接管，也会避免事故的发生，因此需要考虑司机接管成功的概率。

没有足够的交通数据的情况，选择其它的风险评价原则，GAMAB和ALARP是法国和英国铁路领域应用的风险评价原则，

GAMAB（全局至少一样好），增加系统带来的风险不高于用于比较的现有系统的风险。这个概念是基于风险和危害之间的权衡。

ALARP，合理可行的范围内减少风险，同时考虑减少风险的成本，取得风险降低和成本之间的权衡。

以上四种风险接受方法可以结合使用，先将系统性能与交通数据或人类驾驶行为进行比较，取决于数据是否可用，如果系统允许司机接管，则评估司机安全接管的概率，不断验证和迭代系统开发，直到系统满足选定的指标。最后，如果存在具有成本效益的措施可以进一步降低风险，满足ALARP原则，也将这些措施考虑到系统设计中。

原文始发于微信公众号（薄说安全）：如何理解预期功能安全（三）