功能安全与SOTIF如何融合实施.docVIP

功能安全与SOTIF如何融合实施？ 随着系统复杂性的不断提升，新技术将会引入新的安全风险，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详细描述各阶段工作内容。 ?? Part5 功能规范与系统设计方案 功能规范? Functional description 整车层面的描述，包括预期功能和子功能目的、需要达到的性能指标、预期功能的启动，退出条件（运行设计域operational design domain, ODD描述）、车辆自动化的Level等级等。 方案设计? system design and architecture 方案设计中搭建系统架构，明确各子系统间的依赖交互关系，定义系统功能和相关故障。 ?? Part 6 识别和评估危害事件 与ISO26262不同，SOTIF的危险不是由故障引起的，而是由于来自外部的触发条件会触发系统的局限性或弱点（都不是故障）。SOTIF最初的HARA可以与ISO 26262中的相同，但是会不断演变最终会包含更多的故障，新的系统性危害以及更多情况（包括触发条件）。 ?? Part 7 触发条件的识别和评估 通过参考相同的项目或者相同领域的经验，系统性的分析触发条件。识别系统的缺陷或者场景主要分析内容：