随着自动驾驶技术的发展，人们发现车辆安全问题并非都源于系统错误和失效。很多时候，在复杂的系统以及场景中，问题时常源于环境影响带来的非预期性安全问题。而车辆的安全性指标除了满足信息安全和功能安全之外，还应满足预期功能安全。

为了避免相关的安全风险，国际标准ISO21448计划于2021年底前发布。那么，新法规中包括哪些重点内容？预期功能安全面临哪些挑战性问题？同时又适用于哪些具体场景呢？

刘博士针对预期功能安全的内容介绍一下国际上的相关标准，以及围绕着预期功能安全出现的典型场景。

说到预期功能安全，就不得不提ISO26262，做汽车电子开发。就一定会接触到和功能安全相关的一些标准。在汽车电子的开发过程中，一定要遵循的一些设计上的要求。那么这个要求被称为功能安全。在功能安全的设计的时候，重点针对的是电子电气架构可能存在的一些功能上的异常。在它的定义中，有个关键词就是面向电子电气架构的，功能异常表现。

而说到预期功能安全，也有一个非常著名的标准就是ISO21448。早在2019年的时候，官方发布了针对预期功能安全的这个要求，在功能安全的基础之上的，通过一系列的手段，包括验证、测试、确认等等来发现，在我们自动驾驶的这个场景当中，一起去探讨，发现由于传感器的不足、辅助的决策和逻辑的推演，以及在整个功能设计方面，是否存在一些不足。通过这些不足来加强功能设计的开发。

为什么被称为预期功能安全？这是因为它和传统的功能安全是不一样的。针对预期功能安全的官方定义，有两个非常重要的关键词：首先它是一种功能上的不足，而这种功能上的不足，并不是因为故障。如果按照字面意思进行翻译的话，是不存在因为预期功能不足或者是由于合理预见的人员的误操作造成的危险。

如果由于故障的不足造成的危险，我们可以把它归为功能安全的范畴。那么在这里是由于在非故障情况下可能造成的一些功能的不足，我们称为预期功能安全。

图片来源：上海控安

我们其实可以发现。其实预期功能安全天然就是为我们整个自动驾驶的这个场景而设计的。

讲到了功能安全/预期功能安全。其实还有一个非常值得关注的标准。也是面向于我们整个汽车电子的，那就是面向信息安全，那么包括SAE也发布了类似于3061等。那么ISO也有类似的ISO21434标准.功能安全也好，信息安全也好，其实它是站在整个汽车的角度以不同的视角来看我们的安全问题的。

这里同样列举了ISO21434中针对信息安全的一段描述，信息安全就是指它是不是足够的能够应对来自外界的攻击，能够抵御这种非授权的访问等等。如果站在一个车的视角当中，功能安全就是自身的可靠。而信息安全就是能够有足够的能力，抵抗来自外界的一些攻击。而预期功能安全是与功能安全和信息安全紧密相关的一个新的概念。

这张表简单的总结了关于功能安全、信息安全和预期功能安全的适用场景。在这个场景当中，我们把围绕着自动驾驶的安全挑战，划分了三个因素，包括车辆的因素，人员的因素和环境的因素。围绕着电子电气自身的故障，就属于功能安全。

图片来源：上海控安

由于这个各方面的原因，导致的功能的局限性，以及人员的误操作和整个自动驾驶场景当中，环境的复杂性，以及其他的相关干扰，都可以把它归为预期功能安全的范畴。

在这样的一个分类当中，那么其中有一点，我们被称为环境的干扰。其实对于自动驾驶来讲是非常重要的因素。因为在整个车辆设计的时候，作为零部件厂商，有足够的权利去选择芯片和我所开发的软件，但是车辆所运行的环境，这个时候是在实验室的条件下，很难完全复刻的。所以我们将环境的干扰因素引入到预期功能安全的设计过程中。环境干扰因素有道路条件、天气条件及周边条件。围绕着车辆、人员和环境，这三个因素都是预期功能安全重点需要考虑的范畴。

围绕着功能安全、信息安全和预期功能安全，我们来看一下它们从不同的角度来围绕着汽车电子电气整个生命周期的开发。是否有一些共性的要素呢？

如果大家仔细研读过相关的标准的话，无论是功能安全的ISO26262，还是SAE类似相关的信息安全标准。其实都将整个汽车开发的全生命周期融入到设计中，应该说这三个安全是贯穿车辆系统开发的全流程的。他们都有一个共性，都是从风险分析开始,到中间的设计开发实现，最后测试评估发布作为终止的。那么在这样的一个全生命周期的设计过程中，从需求建模研发到整个测试验证评估的一整套体系中，都会融入到功能安全、信息安全以及预期功能安全的设计。

那预期功能安全（SOTIF）主要的用途是什么呢？

如果说用三个词作为一个标志的话，我们可以用设计、验证、确认这三个词。它是另外一个面向自动驾驶领域，指导着功能设计验证和确认工作的一套方法论和标准体系。

设计的话，大家都很清晰。回到自动驾驶领域，如何去保证传感器的性能，功能如何能够满足复杂的路况要求。

验证就是保证做正确的事情。举个例子，产品经理在整个产品设计开发的时候定义了abcd等设计要求。工程师按照这样的一个需求设计文档进行功能的开发，等到开发完了之后，来验证是不是全部符合功能点。如果是的话，我们认为工程师做的正确。它能够符合整个功能，产品设计上的验证是面向一个侧重于过程的定义。

确认是回到了我做的东西是正确的，比如说产品经理设计了abc这样的需求。但是等到工程师开发完了之后，发现这个产品是不符合客户要求的。无法在市场上能够有效的去满足客户需求，我们认为他并没有完成所谓的这样的一个确认的功能。

站在这样的一个视角，一个面向过程，一个面向结果。那么这两个维度共同的作用也依然是SOTIF预期功能安全需要重点考虑的。

整个自动驾驶SOTIF的场景。以设计、验证和确认三个环节，作为相互支撑，来开展相关的工作。这套标准其实也是有自己的一个适用范围的。

在这个标准中列出了两个不适用项：

1.不适用于ISO26262当中考虑的因为系统故障导致的危害。这部分问题属于公共安全的范畴。

2.不适用于现有的系统的功能。这些系统在发布的时候已经有完善可靠的设计了。也不作为我们考虑的范畴。

它其实是围绕着辅助驾驶，L1和L2级的，以及L3更高级别的自动驾驶的场景。

在整个ISO21448标准中涉及到12个典型的章节。前面四个章节，主要是一些概述性的内容。从第五章开始，它会有一些功能和规范性的定义。第六七八章节围绕着预期功能安全存在的一些危险事件，来确定对应的目标。第七章从整个事件原因的角度进行了解读。第八章是围绕着对功能完善和用力限制的角度来避免和降低SOTIF带来的风险。第五章是站在测试的角度，如何去提高系统安全性。第十和第十一章围绕着已知和未知的危险场景分别对整个SOTIF进行验证，提供了相应的指导。第十二章围绕着所有的闭环之后，那么是不是存在一些残余的风险，而这些风险是不是能够被接受。

图片来源：上海控安

这里用一张图来总结后面的5到12个章节的切入点。大V模型其实无论是公共安全还是信息安全，都是非常熟悉的，那么其中五和八是面向整个设计到开发环节的，第六章和第七章是围绕着定义之后的具体危害的分析、功能性和性能性的设计来完成的。第十章和第十一章围绕着认证和测试的阶段，针对验证和确认的需求来完成的。最后12是围绕着剩余风险进行有效评估。

在标准的解读之下，它面临的场景和测试验证方面是不是有相关的支撑技术？

这里就简单的来介绍一下自动驾驶的场景，自动驾驶用三个词来概括，就是感知、决策和执行。这个跟所有的物联网场景是一致的。

感知，现阶段传感器的数据是不是被有效的感知上来？是不是有不可信的、不可靠的、被伪造的和欺骗的数据，这个不完全在SOTIF的考虑范畴内。它重点会围绕着由于各方面的不完善，比如系统是不是能够做出更正确的一个响应的等。

那么在自动驾驶的场景当中，其实自动驾驶本身就存在一定的安全性挑战。由于环境的复杂，导致会存在有一些功能、设计上的和环境适配的问题。算法不可能完全做到100%的完美，特别是引入了人工智能的机器学习算法，它甚至是一种概率上的判断。我们在整个AUTOSAR的架构之下，软件定义汽车的这种模式中，软件自身的问题，会不会进一步的影响到它的预期功能安全也是需要我们共同去考虑的。

图片来源：上海控安

在自动驾驶的驱动下，针对危害分析和风险评估，在预期功能安全中也依然需要考虑。

如果说用功能安全和预期功能安全进行对比的话，其实它的危害是非常相似的。它们可以用类似的一个量表，来对SOTIF造成的危害进行辅助的判断。但是它会有一个问题，就是在整个安全级别进行定级的时候，在功能安全和预期功能安全当中，都会反复提到一个可接受的风险。某种场景下它是可接受的，依然可以融入到我们的设计当中。

在这样的一个预期功能安全背景之下围绕着我们的威胁评估，它会面临到一些新的挑战。这些挑战来自于车辆的操作状态、驾驶人员的行为习惯以及路况，又是围绕着车人和环境息息相关的。在这样的一个危害评估的时候，要重点考虑的就是我们所承载的自动驾驶的相关程序，自身是不是有一些在整个算法优化的过程中，参数的设计是不是能够有效地来适应各种各样的场景？甚至是有些参数是不是在特定的场景下是不需要使用的？都是我们整个预期工作安全需要考虑的问题。

最后想介绍一下在预期工作安全领域，面临的一些挑战。这些挑战性问题就是围绕着它的适用场景，更多的是来自于环境和人员以及车辆自身。甚至是大部分或者说相当一部分的缺陷，是跟场景的复杂性相关。所以说对应的路测非常重要。但是承载路测的相关技术手段和支撑技术，也是需要我们整个业界共同去完成的。