i-VISTA|上海智能新能源汽车科创功能平台有限公司陈君毅：基于场景测试预期功能安全量化评价方法

2020年12月3日，由中国汽车工程研究院主办的第五届i-VISTA智能网联汽车国际研讨会隆重召开， 在中国智能网联汽车产业创新联盟CAICV-SOTIF工作组会议环节，同济大学智能汽车研究所测试与评价研究室负责人，上海智能新能源汽车科创功能平台有限公司智能网联汽车事业部副部长陈君毅发表了“基于场景测试预期功能安全量化评价方法”的主旨演讲。

同济大学智能汽车研究所测试与评价研究室负责人陈君毅

以下为演讲实录：

感谢王总，非常感谢工作组，包括王红老师又给我一个机会，再来跟大家分享一下我们的想法。这个是第二块是讲量化评估方法的，我主要是今天纯粹属于抛砖引玉，这个背景的东西前面很多同学的同事都讲过了，我就不再赘述了，主要是因为用的安全它的来源非常的广泛，就是环境当中的这些突发的条件非常多，包括自动驾驶本身在各个环节上面都有相应的性能体现，会产生提供的安全问题。

这里面如果回到实际的事故当中，大家其实也提到过，我们看一下你如果把每一个事故切分开来其实都会发现它有一定的外部的原因，就是我们讲的环境的要素和这个车本身它里面某一个系统的性能曲线组成。举一个就是最常举的例子，我们看一下比如说客家的事故，这个情况本身外部的环境是强烈的日报，包括白色的卡车的车身，这两个条件存在在一起，形成了一个突发事件，然后导致了一个未识别卡车的这样一个情况，这里面就想说的这个事情是说事故本身当然有很多，然后都是大部分现在我们看到的都是消费者相关的这样一些状态，索取的事故它的特殊性其实主要是体现在需要一个触发条件，这个是我们谈了很多，但是可能需要一些方法把它跟我们的测试场景怎么样有机的又结合我们这样一个点上，就是触发条件是我们这里的关键。

我们这个版本可能一定有一些问题大家将就看一下，我先从左边的这边开始讲，就是我的理解关于这件事情，如果是要做一个量化评估的话，他首要的目的是什么？我觉得这个目的一个是去构建一个比较公共的就是整个行业或者是整个市场上面的一个公共的安全底线。

第二个当然是面向产品开发来讲，能够去引导产品的开发和设计，这都是比较正向的一个目的。我们本来这里是差表达出来变成了一个圈，就是叉叉表达的是说它干什么，前面说的是它干什么，它干的是构建一个安全底线和指导设计和开发。

我觉得这个事情不能干的事情都是对特定的被测对象进行一个安全论证，也就是说安全论证的角色应该还是企业和其他的第三方去完成，从这样一个量化评估的这个动作上面来讲，我觉得他是不能够完成针对特定对象的安全论证的，这是我个人的一个观点，那原则很显然希望他跟所有的这种评价来讲都是类似的，公开、公正、公平这个原则落到实处的话，就是落到了理论上方法上和信息上面，肯定是希望支撑它的理论是比较系统和正确的，方法是客观和科学，这也是我们整个工作组在做的这些工作的主要的目的，能够去把中间比较共性的理论和方法能够大家形成比较好的共识，也能够最接近争执或者是客观的情况。

第三个点是信息的方面，是希望他给大家传递的信息是比较透明的，然后是比较直接的，我发挥到他真正该发挥的作用。往下走，这边是要去兼顾什么？因为如果做所有的测试，它其实都要兼顾这个点，因为测试是有成本的，但要考虑一下分析的分析的效率，测试评估的效率都是事实上客观存在的需要兼顾的一个点。

最后最重要的部分其实是挑战，就是这个问题跟我们现在比如说已有的法规也好，或者说我现在已有的n看和测试也好，它最大的区别在什么地方？

大家其实前面每个人心里也很清楚，然后谈论的也非常多，预气功能安全它的主要的影响因素非常多，然后触发条件的种类也非常多。

那么像跟我们传统的比如说安排里面在做的一些非常安全的相关的测试相比，包括跟现在ed的测试相比，它的差别是非常根本性的，你如果谈论的是一个碰撞实验碰撞实验里面的主导的要素，从动能当中就决定了你的质量，你的速度、你的方向、你的碰撞对象的刚度，就这些决定了你的最后的这个效果是怎么样。

对于我们的预期工作安全的话题来说差别就非常大了，一个是来源非常广泛，然后它反映出来的触发的机制也非常的多，最后显现出来的就是我们为什么写出一本这样子的报告，行为里面东西实在是太多，必须为一个报告来写。如果写碰撞安全可能就列一个公式，基本上把里面的主要的要素都涵盖了，他们的影响和他们的要素都已经表达出来了。

另外一个条件挑战是存在在它的因果关系是不单调的，也就说并不是前面的影响因素怎样，然后我们的输出一定会怎样，它不是一个单调的变化，而它的单调的变化决定了你不能做一个测试，来推导到所有的结果，也就是说你不是划定一个一直说白色的卡车车身会产生什么样的触发效果，是没有办法来推导的。

这个飞单票的作用是一个非常重要的点，它决定了我们的就是推导额外推进是不存在的。

没有办法，他如果关系不单调，没有办法外推，就这个事情就要想一想到底怎么来测了，他不是测一个工况就能解决的，所以我们想象的方法可能是要稍微复杂一点点，大体上分成4个步骤，第一个是要去见1个危害场景的场景，其实同事们谈论的非常多了，可能我的想法略有一点点不同，等一下跟大家分享一下。

主要可能是有两个部分构成，一个是场景库本身，就是我们每个人每天在打的 Scenario的场景库，第二个部分结果看，第二个部分是触发条件的规则。

也就是说当我们把这些触发条件里面所包含的要素也好，它的出发机制也好，都融合到前面那个场景库里的时候，会发现好像有点造成了一波皱的感觉，反正我个人是这个感觉，大家可以想象一下，我们是不是能够把它试着分离出来，就是场景库从场景库，场景库归场景，然后规出发条件规则，可能跟前面华为的同事讲的事情有一点点像的地方，是在产品库的本质，其实更多的会从功能入手，是从功能到功能场景，到后面我们所知的所有的场景。

而这个出发条件，所以它其实可以叠加在任何场景下，在叠加在任何场景下，他们一定程度上可以是这样的个人的想法，后面会有一些具体的展示。

第二个步骤是做这个产品的风险评估，也就是说我前面讲了我们有效率的问题，所以会要像在里面去挑相对来说比较有价值的场景去测试，就是效率优先的这个地方，所以会有一个想象的评估的框架去定义场景，有多么被值得测试。

然后会有一个分析的方法，分析之后的结果其实决定了我们所有测试的优先级。当我们不是做安全论证这件事情的话，我们其实是有条件从高的风险做到低的风险，这样子有选择性的来做测试。

第三个部分是测试场景型的，它有一些生成的原则，希望它在符合一定原则的基础上去生成有对应性的有针对性的测试场景，然后来完成测试。最后一部分就是评估了评估的部分，包括在前面挑选出来的单个场景里的评估，包括说结合了他可能肯定不是测一个场景，肯定是要测一群场景，在测很多场景的基础上有一些结果，最后综合起来形成一个对于a测对象的整体的安全性的一个表达。

我们先看一下第一个部分就是测试产品库的部分，我们前面还是回到那个例子上面，这个例子上面按我刚刚讲的，它如果分成两个部分，一个部分是它的测试场景，一部分是它的出发条件，测试场景是这个车两个车，然后在一个路口，然后一个车左转一个车子，所以这个场景是一个非常普通的场景，它可以从功能分析的角度来推导到，如果这个车它是比如说是XP或者是TCP，它可能不会遇到这个场景，这个场景对它来说是一个无效的场景，不需要被测试的场景。

它如果是一个城市的logo text，它可能会遇到类似的场景，这个场景是有价值的场景。

左边那边看到的是它的触发条件，刚才刚我讲的一个是外部的环境条件，就是l5的那一层，然后还有被测对象本身的不是被测对象，就是它的交互对象，它的声音，车身上面的一些属性。如果大家可以试想一想，我们把这两个事情只要有可能就变成了两样东西，右边的这样东西是大家比较熟悉的，也是我刚刚说可以从功能上面去往下导出的。

功能就是一个整体的功能，比如说打包的也好，问题也好，打包的功能它可以被拆解成很多的子功能，每一个子功能可以去做，再往下也可以去变成它的功能场地，我们还是可以变的，我知道这个大概左边这个部分就是咱们触发条件的规则，其实里面我的解释，它应该包含了两大部分的内容，一部分的内容是针对特定要素的一个特定的属性，回到这个例子上面来讲的话，它其实是属性，对于这个车来说属性就是颜色，颜色，特别是它的白色，这是一种可能性。

另外一种可能性是定义要素的，要素之间的关系，这个关系，当然也有很多的维度可以去想象，比如说位置上的关系，就是我们常说的这种遮挡，但也可能是其他的，比如说纹理上面的关系或者颜色上面的关系，还有很多可以展开的想象。对于要素的特定的属性，我下面也是简单举个两个例子，大家也应该脑子里可以想象出很多东西，一个是比如说对于非实体要素的这种属性的定义，有些是对于实体要素的属性的定义，一直应该非常知名的，我就不解释了。

然后要素的关系就是我刚刚提的这个关系，比如说我们常见的遮挡就是像看头的这种case，它其实描述的是要素和要素之间的位置和利用关系的。

目前你们模式其实有一个图，图上面好多场景就是画了很多线给大家联系起来了，所以这个也是我们想象，你所有东西其实在一起的时候，它必然会形成这样一个非常复杂的技术结构，因为谁和谁都有关系。

在这个情况下，可能的解决方案，包括现在可能也有很多大家在尝试的方式，你把所有的要素，是给你要素的特定的属性的这种态度形式给它标注在里面，而不是去直接定义你的场景库里面这个场景和那个场景之间的关系，可能是稍微更容易实现的一些方式，就是举个例子。

第二个步骤是去做风险评估，场景的风险评估，而不是说那个车在场景里面表现下来的风险，稍微有一点点区别。这个评估的框架其实跟所有安全评估或者是风险评估的框架没有太本质的区别。那一部分描述的是它的可能性，就是这样一个危险事件和危害事件发生的可能性。另外一部分实际上发生之后可能的后果是什么？可能性其实我在上次报告里面给你讲过一次，我不知道大家能够接受到多少。左边的部分可能性其实两类，一类是大家比较熟悉的风险的部分，就是场景的暴露率，跟所有的比如说公共安全里面谈的概念还是非常相似的。

第二个部分是触发条件的转化率，也就是说并不是场景发生都一定会产生什么样的后果，也就是说触发条件本身它有多大，可能把这样一个触发的条件结合上一个直线性，产生一个相应的结果，就是它可能有一些转化率的问题。比如说特别大的洞或者特别大的，它转化率很高，它发生率可以很低，但它转化率会很高，就是我想表达的是这个意思。

这两部分的数据，当然第二第一部分的数据大家非常了解，可能从哪里来，第二部分的数据可能要更多的是依赖就是比较公共的，大家做的一些实验仿真也好，场地的实验也好，通过实验通过右边的后果其实也跟原来差不多，就是一个是后果本身的严重度，但基于比如说碰撞的事故的这一些数据，其实大家有很多的公共支持在里面，基于事故数据建的预算模型也是为了简化的去获得后果的，用户这部分是比较有现成的信息的，中间也简单化了一下，但其实应该有很多这样相关的研究。

我要提的是说我后面加了一个关于责任敏感性的问题，因为最后我是觉得这个事故可能是会要发生的，然后发生我们其实不光光担任了事故后果，这部分的责任的承担，那一部分你要考虑说在因为最后开发的那个车，也就说事故不由驾驶员负责，那个事故是由车引起来，由那个车来负责，无论说这个责任之后是由保险去承担还是由谁承担，但这部分责任肯定是存在的，所以我的理解是这个场景里面可能会存在，是这个场景有多对责任来说有多敏感，就是一个可能需要度量的东西。

我这边分成了两大类，一部分是动态的，一部分是静态的，大家可以简单看一下这个例子来描述一下。

动态的部分，更多的讲的是说，因为当我是在自己有行使路权的情况下，其实我的责任无论发生什么事情，我的责任都会比较小。

当我没有路权的时候，我其实无论如何责任都会比较大，这个路权的转换对我来说是一个把它归为动态的属性，这个动态的属性里面，当我是要去在行驶过程当中，在动态场景里，我是要去抢占别人的物权的，或者是我当行驶在一个没有路权的情况下的时候，我可能这个场景是一个比较对事故来讲比较敏感的场景，这是一个部分。

另外一部分是静态的要素，上面有个图就是比如说我们行驶到我们地上有菱形的框，做前面接近横道线，一旦是这样子的一个场景，如果一旦发生了这种碰撞类似的风景，你这个车是绝对是要担责任的，担比较主要的责任，所以就是在画的减速菱形框和画的横道线的区域附近的时候，那场景其实就是一个对我来说的责任敏感的场景，这个场景里面是如果一旦发生了碰撞，这个车辆是要承担比较主要的责任，我们需要再把这个场景区分出来，做跟其他场景做一个区分，最后可能按照这个可能性和后果的程度做一个两维的这样一个分布，就跟所有的安全分析的角度是一样的。

如果简单粗略的划分一下的话，都可以走高中低一点，比如说划成三档，最后肯定会有一些 Top priority的那些最关注的场景和相对次要一些的场景，这个我觉得后面应该如果是作为一个非安全论证的测试来讲，可以去提高工作效率的一个手段，我可以从往前做到后面，而且是有理有据的往这个方向去做。

我们第三个部分就是去形成这个产品，就是刚刚讲的是解耦开来，就是把这个场景为场景，触发场景为触发场景。在最后当你面向一个特定对象去做测试的时候，你就还得再给他联系起来。联系起来的依据当中的内容是什么？就是一个是它被测对象肯定要plan自己的 O定是什么，这是你所有要去做的工作的起点，就是这点点的匹配的依据。

当你有了被测对象的odd然后有了它自己标称的自己要去完成的功能或者是功能的组合的时候，我们就是依据信息往下做，做的过程当中，我现在只能想到这个层面，我也没有太具体的东西。

我就是想说在做的过程当中，要去遵循一定的去组合和生成场景的时候要想遵循的原则。

这原则分成叫三个部分，一个是符合性，也就是说我提的场景肯定是要是人家提出来的 Ott和功能组合范围内的，我也不能让他测一个范围外的场景对吧？所以这个场景必须是存在它的必要性的，就是有一个符合性符合竞争体现在刚刚讲的这两方面。

第二个是负感情(音)，这个非常重要，是说因为我们其实你说它 Ott范围也可能很大，功能可能也很大，如果说我就是挑了其中非常随意的挑了几个场景，其实很难有说服力，我觉得在这个部分要做的工作是论证他的充分性，就是说我哪怕只是做了非常有限数量的测试，但是我也要能够陈述我们这个测试是有足够的覆盖性，也是体现在这两个方面，一个是刚刚提的触发条件，就是触发条件的类型，它有足够的覆盖性，就是你这个对象它比如说用了视觉传感器，我针对视觉传感器所要产生的这些触发条件，我肯定要给它测到对吧？

我不能说测其中的一个两个，这样就不太好论证覆盖性。

另外就是场景刚刚讲的，但他如果讲自己是一个 APP，就是说你起码在APP里面往下一层往下一层要去落的功能场景肯定是要能够去覆盖的，你可能一个功能场景下，你不可能把整个逻辑调整空间都抛出来，这是不可能的，但是你起码面上的功能场景我觉得是要房产的，这是我觉得两个维度上面要去论证的，你提出一个测试场景，你要去满足这两个问题。

第三个原则其实就刚刚分级主要做的目的，也就是说你能够说出来我们这个测试是有优先性的，我优先测了哪些，而不是说抓了这个事情的细枝末节，而是肯定是先去聚焦这个问题的最核心的方面去做，所以这是我们想到的真正原则，可能还是有待于进一步的优化。

第4个方面相对来说也挺难做的，要做评估，其实上面包括比如说拍照设计里面，我上次也有稍微讲一下，它有一个自己的安全评价的一个基本的逻辑，依着依照这个逻辑或者说参考这个逻辑，包括去参考一个正常的cim它可能发生的一个过程的话，我这边能够建议出来的一些想法是这样子的，可能也不是特别的完善。

一个是行为的安全度其实是最直接的一个东西，是大家心里面最重要的部分评价的部分，总体上会要么直接一点评价他撞一撞对吧？也可以稍微再往后退一点，能够有一定的安全运动的这样一个评价，不光是你有没有撞，而且你不要停在我面前，使命你可能已经是我一个不能接受的安全运作的法人下到也不是很好，主要是安全行为安全的角色。

第二个部分其实我们也是最近在思考的一个部分，就是行为保守，大家可能在听觉得这个跟跟安全不太搭嘎，安全不就是要保守一点，但是我们想象一下，如果我们最后自动驾驶车是要放在一个场景里面跑，放在一个自然交通流里面去跑，过于保守的行为或者说高度不私人的这种行为，他可能会引发二次风险，你会使得别的车进入更加有风险的情况，可能不在被测对象本身的角色上，在一个稍微更宏观一点的角色上面。

所以我觉得在这个桥前提下，可能是要去度量一下它跟一般行使行为的差异，但是可能要避免走向另外一个极端，就是变成一个模块的测试，就是开电车开着很多项目，因为很多主机厂在开发的时候可能会考虑这个方面，但我理解在这个地方我们可能更多的做的是一个两元的态度，就是你觉得太不像人就行了，也没有说非常精细的去刻画他，像人的程度可能不是我们的本质。

但是为什么想到叫去讲这个行为保守度的事情，也是回到车辆开发的本源上面。车辆为什么那么难开发？其实就是因为我们的诉求特别多，我们有很多的价值加在一个车上，我们希望它开的快，然后希望它很舒适，然后希望它经济性也很好，就是这么多价值加在上面才去保证它的安全性，那是真正难的事情。

如果我啥也不干了，我就保证安全性，但你停在那你能保证安全性对吧？但是它不实现车辆本身的最根本的价值，我希望能够通过一个特定的维度能够让它去表达它的价值，然后也不让他走向丧失或者是丢失所有价值的情况下，去保证安全的这样一个不往下走向这个方向。这是我想说的第二个。

第三个点是减缓措施，其实在左上角的图上其实又讲到了，我们人在最后的一刻可能也会进行一些壁状的减缓，包括在拍摄4的完全是从拍摄4的想到的点，我觉得也是其实非常好，但其实在一些情况下，你其实都是无能为力的碰撞是必然要发生的。

在这个情况下，在最后的这段时间，你这个车有没有采取足够的这种避撞的措施，或者是减缓损失的措施，我觉得也是一个非常重要的安全上的努力，这是一个基本的出发点，努力可以是很多的方面，我没有办法去想的特别完整，但是想比如说我们有时候说停在那里两轮车，比如说要转过来的时候，你其实也无能为力，你也不能倒车，你也不能开到人家车道上去。

所以这个时候你可能能做的事情，你打灯也好，摁喇叭也好，哪怕看出头去叫一声也好，你会有很多的最后去减法结果的一些或者是减轻结果的一些努力和尝试了，我觉得对于自动驾驶车来说，他可能也要考虑这个方面，他哪怕有一些其他比如像真的是太critical了，然后无法避免碰撞，我觉得他如果进了他所有的减法的能力的话，我觉得也是要考量进去的一个维度。

最后一个方面当然是最后的具体的事故责任，就跟我前面讲的场景里面的责任感就会有点不一样，那个部分会比较粗颗粒，然后这部分会比较具体一些，因为事件已经返修了，对于一个特定的已经发生的事件，它总有一个结果，这个结果里面一定包含责任，就是这是一个其实是确定的，只是很难计算的一个东西。

他确定是确定在只要在路上发生任何一个事故，警察过来他总会给你一个结论，对吧？

可能上次还是应该有哪一位专家也应该提过类似的事情，其实也是我们很纠结的一个点，是因为现在的事故的责任判定其实是上海话叫老雅手的，他就是调解一下，他其实也没有非常100%的说你70% 70% 30%就没有这种话，所以更多的是看你更好被说服一点还是那个人比较好说服一点，然后在当中形成一个在人民内部没有矛盾的一个公共的大家能够形成共识的结果，他其实不是那么scientific的一个东西。但是如果你要判定一个自动驾驶车的责任，我相信你需要给他一些说法。

再说当然面向开发，其实他们也需要我不知道他们怎么处理，但是他们其实应该也需要，但是面向最后测试你肯定是需要的，你最后不能请一个老警察在那边，作者给你看一下每个测试场景，最后这个责任怎么判，你50他50你70他30，那就没有办法操作，所以这部分可能更多的是希望要去定义一个做一个事故责任判定的可以计算的方式，一个可以量化，可以计算一些哪怕不是完整的交通法规的复线板，它也是里面这对概要的一些内容的这样一个体现，能够帮你把每一个仿真测试也好，实测测试也好，测试下还是接口给到一个真正的客观的结果。

最后这部分就比较简单了，就是把所有的测试结果浓缩起来，变成一个针对对象的结果，我没有展开太多，因为我也不知道怎么做，我感觉怎么做，可能都是有很多类似的方法可以去借鉴，更多的是一些权重上面的讲法，遵循了我前面说的公开公平、公正，只要你自己言之有理，我相信第三方还是有足够的发生的层面去把这个话说通，就是我们没有做太多的展开，更多的就是把刚刚一个场景里面得到的结果做一个汇总，汇总的结果表示了被测对象的这样一个结果。

注：本文根据现场速记整理，未经演讲嘉宾审阅，仅作为参考资料，请勿转载！