功能安全与SOTIF融合实施设计方案

　　智能驾驶真能替代“老司机”吗？
　　研究数据表明，近94%的致命车祸与驾驶员直接相关，例如疲劳、超速或其他违法行为，智能驾驶被视为可以显著降低事故率。
　　
　　随着系统复杂性的不断提升，新技术将会引入新的安全风险，Uber自动驾驶汽车2018年3月在美国意外撞击致死一名行人，2016-2020四年间特斯拉三次因摄像头识别局限性撞向白色卡车，2020年3月沃尔沃向全球市场发出大规模召回通告，数量达70万辆，涉及9款在售车型，召回的原因是此前沃尔沃在丹麦进行的一项关于XC60的安全测试中，发现自动紧急制动系统（Autonomous Emergency Braking， AEB）没有按预期在发生碰撞时及时刹停车辆。无论是关于消费者购买自动驾驶车辆的决定因素调查，还是各国发布的自动驾驶车辆标准，“安全”始终是最受关注的焦点。
　　
　　智能驾驶带来的安全问题越来越多，不管是交通事故还是召回事件，究其原因也不全是由于E/E系统故障失效而导致的；在自动驾驶系统中即使系统不发生故障，也可能因为复杂智能算法的不确定性导致功能的偏离、传感器或系统性能限制、驾驶员对车辆功能的误用，造成交通伤害。智能驾驶事故频发，公众的信心下降，对于智能驾驶的未来我们不禁会有这样的疑问：我还有机会吗？
　　

　　智能驾驶的“安全带”—SOTIF
　　我们知道ISO26262 功能安全旨在避免由E/E系统功能失效导致的不可接受的风险，主要是针对系统性失效/随机硬件失效导致的风险的进行分析和控制，然而传感器和感知算法（e.g. machine learning， neural networks），在没有出现电子电器系统失效时，由于设计的局限性也会导致风险，但此部分并不属于ISO 26262的范畴。为了弥补ISO 26262的局限，预期功能安全（Safety of the intended functionality，SOTIF）应运而生。
　　2019年1月，ISO/PAS 21448:2019 Road vehicles — Safety of the intended functionality发布，同年5月ISO 21448工作组草案（WD）中已将该国际标准的范围拓展至L1-L5自动驾驶车辆系统。
　　SOTIF定义为不存在不可接受的由功能设计不足或者可预见的驾驶员误操作风险，主要为了消除以下两类风险：
　　 Performance limitation 例如：恶劣环境条件下，传感器无法探测到物体
　　 Misuse 例如：人机界面设计差，导致驾驶员误用自动驾驶功能
　　智能网联车辆对于不同的危害事件原因，会有相应标准覆盖。
　　
　　SOTIF从已知性和安全性两个维度将场景分为4类：
　　
　　SOTIF的目的就是评估Area 2和Area 3，通过一系列技术措施将两区域减小，并同时提供证据证明这两个域已经足够小，剩余的残余危害是可接受的。在此过程中Area 1通常是增加的。
　　
　

　ISO 26262与ISO 21448 核心环节对比
　　尽管ISO 26262和ISO 21448处理的是安全的不同方面，但这两个过程都需要用于实现预期功能的可靠安全性论证。两个标准之间活动的一致性有助于在系统设计的早期发现问题并进行修改，同时各活动之间是交互进行的，产品开发阶段通常需要多次迭代，以生成最终的功能和系统规范。
　　
　　Part5 系统规范和设计与 Item Definition 并行
　　 Part6 危害识别和风险评估与 HARA 并行
　　 Part7 触发条件识别和评估与 FSC/TSC 并行
　　 验证和确认与 ISO 26262的 V模型右半边并行
　　 SOTIF的发布与功能安全评估并行

　　功能安全与SOTIF融合实施
　　ISO 21448中定义了SOTIF的工作流，下面融合ISO 26262开发过程，针对Part5-Part8详细描述个阶段工作内容。
　　
　　 Part 5 功能规范与系统设计方案
　　功能规范 Functional description
　　整车层面的描述，包括预期功能和子功能目的、需要达到的性能指标、预期功能的启动，退出条件（运行设计域operational design domain， ODD描述）、车辆自动化的Level等级等。
　　
　　方案设计 system design and architecture
　　方案设计中搭建系统架构，明确各子系统间的依赖交互关系，定义系统功能和相关故障。
　　
　　Part 6 识别与评估危害事件
　　与ISO26262不同，SOTIF的危险不是由故障引起的，而是由于来自外部的触发条件会触发系统的局限性或弱点（都不是故障）。SOTIF最初的HARA可以与ISO 26262中的相同，但是会不断演变最终会包含更多的故障，新的系统性危害以及更多情况（包括触发条件）。Part 6 识别与评估危害事件
　　
　　 Part 7 触发条件的识别和评估
　　通过参考相同的项目或者相同领域的经验，系统性的分析触发条件。识别系统的缺陷或者场景主要分析内容：
　　已知的系统组件约束
　　 环境条件和可预见的误操作
　　通过这些分析可以提高对系统局限性的理解，同时将会改善未知触发条件的识别。基于整车级别危害可通过故障树同时分析功能安全原因和预期功能安全原因，预期功能的故障行为下包含触发条件和相应的弱点和限制。
　　
　　针对不同模块（例如传感器）创建局限性库进行限制和弱点分析，将传感器/功能特征与潜在场景的特征/特性联系起来，确定的触发条件可以保存为情景库，以供在新项目中进一步使用。另外附加一个SysML模型，用于描述它们随时间的变化（活动图）
　　
　　
　　Part 8 功能改进（Architecture）
　　首先从安全目标得出功能要求，然后从已识别的故障得出较低级别的功能要求。随后在单独的安全概念（TSC /SOTIF概念）中细化为技术要求（TSR）和性能要求（SOTIF）。添加额外SOTIF安全机制对架构进行改进，例如：提高传感器性能/精度、传感器算法改进、选用合适的传感器技术、改变传感器位置、传感器干扰检测，并触发报警和降级策略、运行设计域（ODD）退出的检测等。
　　
　　 Part9-Part10为SOTIF验证阶段，需要定义验证和确认策略，以提供实现目标的证据，并说明如何实现目标。随着功能的改进，对系统进行分析，以确定在验证和确认期间是否重新测试了其他功能。这些相关功能通过回归测试得到验证。这确保了已知的或新的触发事件不会在未更改的功能中导致潜在的危险行为。在验证和确认活动中发现的触发事件（其中存在潜在的危险行为）在每次发布时都要重新测试。对于Area 2可以通过很明确的方法进行验证，可参考ISO21448 Clause 10中给出了的系统和组件（传感器、算法和执行器）和集成的推荐验证方法。对于Area 3这类情景只能靠企业的实践或其他方法（如设计度量、系统分析或专用实验）进行评估。