作者 | Aimee
出品 | 焉知
传统电子电气领域问题，可通过功能安全解决。但随着自动驾驶技术的发展，加入了包括算法、图像识别等内容，仅保证自身无故障已经不足以满足自动驾驶对于安全的需求。由于自动驾驶系统本身的高度复杂性，导致了我们设计的功能本身就有局限性或缺陷，从而进一步导致安全事故的发生，预期功能安全试图解决的就是这些问题。
行业内预期功能安全的标准为ISO21448，这份标准主要为了应对驾驶辅助/自动驾驶领域越来越复杂的系统和工况。与功能安全不同，在判断功能失效的情况及原因时，如果功能错误/失效是由于相关EE架构失效或硬件失效等引起的，就是功能安全的范畴(ISO 26262)，如果是由于一些系统的设计局限，比如传感器的误识别或是驾驶员的误操作等原因导致对一些场景的错误解读而引起的话，就是SOTIF的范畴(ISO/PAS 21448)。
本系列文章将分别介绍预期功能（SOTIF），功能安全和网络安全这三个可靠性域如何协同工作，以及如何将它们组合在一起以创建一个可靠的系统。
本文首先介绍每个领域，并从安全性前提下衍生出可靠的自动驾驶功能。然后，提供可以实现这些预期功能安全设计的元素。最后，通过引入通用的逻辑体系结构来组合所有元素确保预期功能安全设计的完备性。
一、自动驾驶汽车的法律框架
中华人民共和国工业和信息化部于2018年发布了《国家汽车工业互联网标准体系（智能互联汽车）建设指南》，以全面加强顶层设计，加强自动驾驶汽车的智能化及网联化过程研发。功能安全通用标准ISO 26262的第二版已经成熟，其中的变化包括设计更严格的整车结构和功能架构，以支持更复杂的汽车电子系统。最新发布的ISO / PAS 21448标准指定了用于分析，验证和确认非故障场景和系统用例的开发过程，我们通常称之为预期功能安全开发设计过程。但是，ISO / PAS 21448几乎都偏重于关注L1和L2辅助驾驶系统。实际应用过程中需要将该标准外推至L3甚至L4的应用。
实施安全标准ISO / PAS 21448，ISO 26262和ISO / SAE 21434允许将其程序和方法结合在一起。ISO / PAS 21448的开发旨在解决由预期功能（包括可预见的滥用）引起的风险和危害等级。系统的E / E故障引起的危险通过使用全球建立的ISO 26262标准的功能安全性来解决，而故意操纵导致的危险则从ISO / SAE 21434安全性角度进行评估。以上标准互为补充，可主要用于定义自动驾驶系统的设计风险，使工程团队具备设计安全机制的能力，并增强自动驾驶系统的预期功能以减轻已识别的风险。根据开发组织的需求，有可能独立制定必要的标准内容，并在此过程中考虑该类标准之间的依赖性。
现有标准并未提供针对自动驾驶系统中一些最有问题的主题的解决方案，例如人工智能的安全保证（最相关的算法源自机器学习和神经网络领域），人为因素和心理，以及用作自动驾驶系统输入的传感设备的技术能力。但是，应用分析与安全相关的用例，可以确保必要的安全级别。这些分析可以系统地评估功能说明中因预期用途和可预见的滥用引起的潜在危害。除了安全的设计和开发过程外，还确保测试到验证以迭代的方式进行。过程中需要涵盖专家评估，安全性分析和阶段性测试。根据它们的范围，采用不同的标准支持此过程。
二、自动驾驶的预期功能安全设计原则
开启自动驾驶车辆功能时，应评估基于功能和系统边界的风险。性能限制（例如基于传感器的限制）可能会导致故障行为，从而可能导致危险情况的发生。开发标准将帮助开发人员管理系统的复杂性，估计可能的风险并采取适当的措施。最后，利用可用的标准来实现系统的安全性和可用性之间的充分关联。
对于大多数应用程序，将ISO 26262用于可用性方面都有其局限性。设计一个安全的系统是在风险和应用程序可用性之间取得平衡的过程行为，当风险太大会导致系统设计得过于保守，其系统可用性就会变得极低（达到足够完整性的安全机制可能会危害可用性目标），这样将无法提供更安全，更舒适的客户体验。相反，如果系统安全性设计指标过于宽松，则会导致系统的安全性不够，但可以确保系统持续具备可用性。
如下图所示：
因此，从分析的角度解决问题，通过设计基于场景的系统行为来解决系统的安全问题以及通过分析用例和场景，来设计强大而安全的系统，从而提升技术能力将变得越来越重要。
可用性主要受到ODD限制的影响，还会导致过度保守，过于复杂或有缺陷的安全设计机制及有缺陷的系统设计。关于模式和冗余的传感器，其多样性可能不足。而由于环境因素，人机界面设计不良而引起的人为模式混乱或自动化成都影响（车辆之间的相互依赖性）也可能会损害安全性。最终，这演变成一个安全概念，定义了支持安全目标的安全机制。
从安全分析域推导自动驾驶能力
从可靠性域衍生功能首先要概述自动驾驶汽车的不同国际法律框架，以识别除十二项原则外功能还应涵盖的要求。这些功能涵盖了处理人为因素的SOTIF和功能安全性。安全工作在逻辑和技术架构上，并为这两者提供输入要求。由于当前尚无有关汽车网络安全的已批准法律或国际标准化，因此本节提供有关安全方法和措施的建议。
三、预期功能安全设计要素
预期功能（SOTIF）方法安全性的基本概念是引入一个迭代功能开发和设计过程，该过程包括测试和验证，其结果是可以声明为安全的预期功能。可以基于一种方法论证得出一些活动，相关的论据证明这些活动足以开发安全的自动驾驶功能。
该方法假定存在一个已知场景的区域，该区域具有安全的系统行为，而一个未知场景的区域则具有潜在的危害。实际上，这些区域划分中都是重叠的，如下图所示。图中描述的区域定义如下：
根据定义，其余白色区域是安全的并且是未知区域。
四、预期功能开发目标
汽车开发的目标是将已知的潜在意外行为和未知的潜在行为降低到可接受的残留风险水平。使用上述模型，可以得出以下开发目标：
白色区域是假设的安全区域，其表示与本文讨论的论点无关。无论如何，也可以通过减少区域3或扩大区域1的措施来减少白色区域。图5通过描述开发目标来可视化结果：
以下措施有助于使用此概念实现开发目标。且这些措施将促进持续的迭代更新和过程改进。由于可以通过实验测试和验证活动来提供主要证据，足以证明该系统对客户是足够安全的。
1、区域1（策略）：
- 通过分析确定潜在风险
- 通过发现系统缺陷并进行重新定义
首先，需要明确定义要开发的功能，将使用与ISO 26262相似（但不完全相同）的风险分析方法来分析功能和技术规范。如果发现弱点，则会改进功能或系统。
2、区域2（策略）：
测试功能系统，包括其系统组件实现如下：
- 模拟功能，包括其场景
- 测试系统组件和整个系统
- 确定在存在弱点的情况下可以对功能或系统进行改进的地方
- 确定接受剩余风险的依据
3、区域3（策略）：
验证功能系统：
将区域3减少到可接受的水平，例如通过耐力测试，驾驶测试，仿真测试；
五、预期功能测试验证
全面的系统安全验证不仅需要测试，还需要诸如开发过程的质量审核或通过分析技术实施可靠的系统设计之类的工作，这些共同构成了自动驾驶系统的安全论据。预期功能安全在车对车方面的假设分析与L0–L2系统大致相同（参见ISO 26262），但是复杂性却增加了。
首先验证通过设计策略通过安全性得出的所有要求都得到满足。此步骤可确保覆盖已知方案，并确保系统按预期有效的运行。因此，验证的重点是易于测试的需求，并且可以通过设计流程对已经集成到生产车辆中数十年的系统进行完善的安全性检查。例如，线控油门系统通过一套可验证的措施（例如冗余油门踏板位置传感器和运行冗余软件的冗余微处理器）来防止车轮处产生不必要的正扭矩。为了符合设计原则和可验证要求的安全性，现代自动驾驶系统需要进行有效的设计和测试措施，以确保系统能安全输出。
如上图所示，阶段性测试可能会促使对功能设计的改进，从而产生新的验证需求。通过解决已知的不安全情况，此迭代过程可提高对安全性的信心，从而缩小其面积。
总结
本文主要讲了与自动驾驶功能相关的恶预期功能安全策略，从基本的概念、目标、架构、标准及测试范围着手进行了全面的分析，旨在为下一节自动驾驶准入过程中的难点分析铺垫。使读者能够在深入浅出的了解到预期功能安全的重难点，从而后续为自动驾驶的设计过程提供的必要的支撑，支撑产品顺利通过准入。
本文转自： 焉知自动驾驶，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
