一文秒懂预期功能安全SOTIF-MUNIK知识普及课堂
SOTIF定义：
标准定义：预期功能安全的定义为不存在由于预期功能不足或人为的合理可预见的误用所引起的危害而由此危害造成的不合理风险。
预期功能安全（SOTIF）是除功能失效以外，由于系统功能不足或驾驶人员的误用（misuse）所导致的危害和风险事件，为避免此类情况产生所建立的标准。
例如：自动辅助驾驶系统由于环境光线强度不足，无法识别出最优的行驶路线（传感器性能不足或芯片算力不足导致）；再比如驾驶员不规范的语音指令，导致车机系统造成误判引起风险等。
功能不足：功能不足包括整车层面或系统中电气/电子要素层面的规范定义不足或性能局限
误用（misuse）：以制造商或服务提供商不期望的方式使用，误用可能来源于对系统性能的过度信心。
预期功能安全与功能安全的映射
预期功能安全标准的主体内容部分是第五章节到第十三章节，下面是各章节的对应标题
ISO21448.5：functional and System specification
规范定义和设计中包含了那些在后续SOTIF活动和周期开始前就已知的功能不足。SOTIF活动的迭代可能会导致规范定义和设计的更新，以及先前未发现的功能不足。SOTIF活动的每次迭代开始于规范定义和设计，目的在于将规范定义和设计更新到最新状态。
ISO21448.6：SOTIF related hazard identification and evaluation
对已识别出的危害事件进行风险评估，并定义相应的风险接受准则。如果证明危害事件不会导致不合理的风险，则不需要应用额外的设计措施。第6章不考虑预期功能的危害行为的原因，而仅考虑其对安全的影响。因此，重点是评估可能由危害行为引起的危害事件，并定义所需满足的接受准则。
ISO21448.7：identification and evaluation of triggering events
第7章旨在识别可能导致预期功能危害行为的根本原因，并评估由所识别出的潜在功能不足和触发条件引起的风险是否合理
ISO21448.8：functional modifications to reduce SOTIF risks
第8章旨在对功能进行修改，以改进SOTIF
ISO21448.9：definition of the verification and validation
第9章旨在制定验证和确认策略，以提供证据来证明：与SOTIF相关的整车层面残余风险符合可接受的水平，要素满足其功能要求，对ODD（设计运行范围）的覆盖是充足的。
ISO21448.10：verification of the SOTIF: evaluate known scenarios
第10章关于已知场景导出相应验证和确认的测试用例，且测试用例对ODD的覆盖度足够高。
ISO21448.11：validation of the SOTIF: evaluate unknown scenarios
第11章关于未知场景导出相应验证和确认的测试用例，且测试用例对ODD的覆盖度足够高。
ISO21448.12：methodology and criteria for SOTIF release
第12章旨在评估SOTIF活动的结果是否充分，足以论证实现了SOTIF。
其中5、6、7章节可以映射ISO 26262 Part3中的内容；
注：SOTIF第5章节“规范的定义与设计”和ISO 26262中Part 3“相关项定义活动”的内容重合度是比较高的，均体现了整车层面对于功能、运行环境、相关项及要素的依赖关系等；6、7章节则对应功能安全中的HARA活动，具体描述在下节内容详细展开。
第8章节则对应的ISO 26262中有关开发阶段安全概念、安全分析及安全措施的内容；
注：本章内容是为了实现预期功能安全所惨取得各项措施，涉及到相关项及系统层面的活动，与ISO 26262中的功能安全概念、技术安全概念以及各种安全措施内容类似，还涉及到部分分析活动。
第9、10、11章节则映射ISO 26262中系统及相关项的验证、安全确认的内容；
注：第9章定义了V&V的策略，第10、11章讨论已知、未知场景下验证与确认的执行和结果，与功能安全活动中系统的验证与安全确认活动所覆盖的范围相近。
最后12章节映射了ISO 26262中的认可措施，确保相关成果符合预期功能安全的要求所执行的评估活动。
危害的识别与评估
在功能安全体系中，危害识别与评估活动是需要对危害事件从严重度（S）、暴露概率（E）、和可控性（C）三个方面评估定级（ASIL等级）。预期功能安全体系中对于危害事件则没有明确的等级划分，而是通过对于风险的评估来定义危害事件的接受准则。且暴露概率（E）在预期功能安全中不作为考虑因素，这是因为在SOTIF中参与评估分析的风险，它们的暴露一定是与SOTIF相关的，否则不会参与分析。
预期功能安全的接受准则有两层，通过可测量的各项参数来判断危害行为是否可控（可控C=0，不可控C>0）及危害行为严重度是否为“无伤害”（无伤害S=0，有伤害S>0），这就是第一层接受准则“危害行为接受准则”；当危害行为判定为有伤害且不可控事件时（S>0，C>0），需要为这些危害行为定义“残余风险接受准则”也就是第二层接受准则。
危害事件的评估示例：
危害行为：在高速行驶中AEB非预期的激活，导致产生较大的减速度
潜在结果：与后车发生追尾
是否属于不合理的风险：是
严重度：S>0； 可控性：C>0.
潜在功能不足与触发条件的识别与评估
对于不满足接受准则的危害行为而言，我们要了解是什么原因引起的这些危害行为的发生，这样才能在后续活动中作出针对性的优化。
潜在功能不足与触发条件的分析可以从以下两方面考虑
l 基于已知的潜在规范定义不足和性能局限，确定导致已识别出的危害行为的场景（包含触发条件）。
示例：路面上的3D图案被误识别为障碍物从而引起AEB的介入（传感器性能局限导致的减速），触发条件可能是弱光条件与大于限定行驶速度的车速。
l 基于已识别出的环境条件和可合理预见的误用，确定潜在的规范定义不足和性能局限。
示例：环境条件是不清晰的车道线导致ACC偏离指定车道行驶，驾驶员由于未看到车道线所以并没有立即接管车辆控制权。
预期功能安全车辆运行场景
明确识别出现有的潜在功能不足与触发条件时，需要考虑采取何种SOTIF措施来优化目前遇到的问题，并更新规范定义与设计，从而完善系统。
常见SOTIF措施可分为四类：
l 系统修改
示例：例如当前算法的性能与精度不满足预期功能安全要求时，可以考虑改进算法来提升安全可靠性。
l 功能限制
示例：例如当出现车道识别不明确时，限制转向辅助介入驾驶控制。
l 权限移交
示例：例如当环境识别能见度过低或无法识别时，HMI（人机交互）将驾驶权限移交给驾驶员并发出提醒。
l 解决可合理预见的误用
示例：例如驾驶员双手离开方向盘时，座椅震动与语音播报同时提醒驾驶员不要违规操作，直至驾驶员恢复常规驾驶行为。
验证和确认策略
验证与确认活动是为了证明预期功能安全在各个层面的实现。
制定不同的验证与确认策略以应对不同环境条件下危害行为的评估活动，确保SOTIF措施在组件与整车层面均能有效地处理各种情况下发生的危害事件。
预期功能安全车辆运行场景
如图所示，预期功能安全中将车辆运行场景划分为四类，分别是已知安全场景、已知不安全场景、未知不安全场景以及未知安全场景。通过各种预期功能安全措施尽可能缩小已知、未知的不安全场景的占比，是预期功能安全的首要目的。
示例：驾驶员使用手册中对可能发生的误用事件进行列举，并告知驾驶员避免不正确的驾驶行为。
预期功能安全的必要性
近年来辅助驾驶与自动驾驶的受关注度高居不下，各大车企都对这个领域投入巨额的资本与精力，自动驾驶的舞台相当广袤。这样百舸争流的大环境下，稳定的根基才是成功的必经之路，安全永远是第一要义。自动驾驶的核心就是人与机器的配合实现更安全、更高效、更舒适的驾驶体验。想要实现这个目的，那这样就绕不开预期功能安全。今天简单分享预期功能安全的部分内容，想了解更多信息可以持续关注！
