自动驾驶安全实践挑战及思考

上海盘石是一家专业从事汽车功能安全，预期功能安全，信息安全相关的培训，流程咨询，产品咨询，工程服务的专业公司。

上海盘石信息技术有限公司创始人边军以自动驾驶安全的现实挑战与思考为主题，从如何设计可靠冗余，如何让Linux满足功能安全，如何覆盖感知系统的各种故障模式，如何正确判断自动驾驶设计的ODD，如何定义自动驾驶的安全验收标准，如何解决自动驾驶仿真环境与现实世界的差异等几个方面入手。以下是演讲内容:

上海盘石信息技术有限公司创始人边军。

如何设计可靠的冗余

首先，我简单介绍一下自己我从2009年开始接触功能安全当时常用的标准是IEC 61508，应用于工业领域到现在为止，我从事安全相关的开发和审计已经十几年了首先说一下创办上海盘石信息技术公司的初心从业十几年，看到国内安防领域和国外还有一定差距，主要体现在自动驾驶，芯片，软件质量等领域，尤其是在自动驾驶领域安全是L2向L3演进过程中最关键，最基本的一点，这个环节的完成将影响中国整个自动驾驶产业的落地

自动驾驶安全需要集合国家和社会的财力和知识资源，建立产业连接，才能真正解决其在安全方面的共性问题，最终助力中国自动驾驶落地我今天带来的内容主要分为六个方面，主要是我在整个自动驾驶发展过程中遇到的问题和挑战，需要大家共同探讨和完成

一，如何设计一个可靠的冗余系统伴随着自动驾驶从L1进化到L4，安全冗余设置会越来越多从L3—TJP交通拥堵辅助，L3—HWP高速公路诱导等功能开始，在转向，机动，定位等方面会有冗余要求到L3，会对安全冗余有全方位的要求，涉及感知，域控制，电子控制等基本操作层面

从2018年到现在，中国已经形成了自己的系统解决方案但是，有了解决方案并不代表这个领域真的实现了量产，还有很多技术问题没有解决首先，系统需要有有效及时的故障检测机制，有效性强调的是安全冗余机制的性能国内的安全冗余设计往往是多种安全机制的相互验证如果一个安全机制失效了，还要注意另一个安全机制的性能是否能满足要求例如，郑路匹配和绝对定位一起构成了道路级定位的冗余设计一旦绝对定位失败，郑路匹配方案是否足够精确以支持车辆运行是一个需要考虑的问题

及时强调冗余机制的切换时间，要求系统在短时间内检测出故障点，并迅速切换到备用机制，保证系统的正常运行例如，将相机与激光雷达相结合被用作车道识别的冗余设计一旦激光雷达出现故障，实际行驶车道会逐渐偏离摄像头车道，这就需要激光雷达自身的安全机制及时检测到故障，然后系统会及时切换到基于摄像头输出的侧向控制如果不能及时发现故障，实际行驶车道线与摄像头车道线偏差过大，系统无法确认故障点，必须采取紧急制动

第二个困难是复杂的系统设计增加了冗余设计独立性的难度工作人员需要考虑各种共因故障和连锁故障，尤其是一些采用传感器融合的设计，需要考虑传感器的时间戳和自身的运动状态等共因除了电子电气故障，外部环境因素也会导致冗余设计失效，比如降雨，也可能导致相机和激光雷达的性能下降

设计冗余时，需要考虑五个方面首先要做充分的安全性分析，比如FTA，考虑冗余机制由于性能限制失效的概率第二，在开发初期做DFA分析，避免潜在原因失效和级联失效第三，要有时间规划，要缩短自我诊断和相互验证的时间第四，增加系统工程的投入第五，应该给予双重考虑冗余设计不仅要实现ASIL层次分解，还要考虑失效操作为了故障减少的顺利进行，传感系统需要至少三个独立的功能/机制，并且可以通过3选2的策略快速识别故障

如何让Linux满足功能安全性

与其他系统相比，Linux有很多优点一方面是免费开源，软件库丰富，开发成本低另一方面综合性能强，响应时间和响应速度更快，能更有效地运行软件任务它还支持多核操作，适用于不同的硬件同时，Linux也有一定的劣势比如在整个开发过程中，没有办法达到功能安全相关的标准

首先是缺少文档，开发过程无法追溯鉴于此，软件FMEA分析可用于白盒软件模块，识别故障模式和影响，或者ASIL安全级别分解可用于从不同级别监控软件模块但如果采用软件监控，则需要额外考虑其独立性

其次，硬实时性能难以保证解决这个问题，常用的策略是增加实时内核，用双核运行但是这种解决方案也存在很多问题，比如实时内核无法具备Linux内核的优势，Linux内核无法满足安全需求为了保证硬实时性能，可能会采用双核，这可能会导致代码迁移的问题

第三，代码和单元测试的工作量巨大，为了安全需要删减代码，重写不符合ISO26262编码标准的代码第四，安全改造后，Linux的优越性消失业内有一种假设，未来可能不会有收缩包装的Linux软件包这种软件包可以应用于具有高安全要求的应用，但是硬件的通用性可能会受到损害

从行业进展来看，国内外的组织都在致力于提高Linux系统的安全性所以从长远来看，Linux可能是一个更开放的平台，未来还是有很大概率用在安全产品上

如何覆盖感知系统的各种故障模式。

目前整个自动驾驶的难点其实是感知例如，L1和L2自动驾驶的主要目标是防止意想不到的AEB与后车相撞过渡到L3后，会增加很多额外的安全目标，比如正确识别道路边缘信息，正确识别前方障碍物，防止假前后碰撞，正确识别代表ODD的信息，防止系统进入未知的危险状态

目前，感知的安全目标主要是为L1和L2级别定义的一旦用于L3级系统，如何考虑这些偏差将成为行业难点想象一下早高峰多云转阴雨的场景你在十字路口开车，突然摄像头失灵了然后你会看到以下场景:行地址故障，列地址故障，控制寄存器故障，像素数据流水线故障，存储器/寄存器寻址故障，图像数据流水线故障

在L3级别的自动驾驶中，既要保证目标和奇的正确识别，同时还要考虑各种故障对它的影响，这其实工作量非常大之前见过一些国外的芯片当他们进行这种分析时，他们可能会列出成千上万个场景对于每个场景，考虑它有什么影响以及如何解决它

鉴于上述困难，业界也提出了几种摄像机的安全机制一种是像素级模拟测试，主要针对像素常用的方法如模拟信号范围筛选，ADC测试方案，行/列存储数据通路测试方案，最后是冗余像素模拟测试可以用来解决像素的颜色，强度，对比度等问题，也可以发现大于一定阈值的噪声但是没有办法解决像素的时空表达，也没有办法解决图像传输中的问题

对于图像测试，这也是目前业内普遍采用的方式典型的做法是给一个参考图像，然后知道参考图像应该输出什么目标这种方法的优点是可以测试像素的时空表达，但也有一些缺点，其诊断覆盖率难以满足一定的要求，难以遍历数量巨大的失效模式

第三是组件的测试，包括像素的颜色，强度和对比度时空表达，图像传输，还可以找到大于阈值的噪声，相当于白芯测试，采用关键数据写保护，CRC寄存器，温度和电压检测，检查时钟等等

以上方法我觉得以后肯定会结合起来，但是如何设计一个诊断覆盖率高，可以适用于不同安全目标的解决方案，是所有相机厂商和后端芯片厂商的难题。

如何正确判断自动驾驶设计的奇数操作设计域

事实上，在自动驾驶早期，大家更倾向于使用静态奇数约束和地理围栏到目前为止，纯粹的静态运行设计域约束已经不再适用，系统需要有一个有效及时的动态检测机制来反映环境条件，以保证系统始终在可接受的风险下运行

这里有两个例子左图是对单一因素影响的评估:比如阳光直射导致相机反光系统如何判断什么程度的反思会影响到司机，什么时候应该退出这是当前行业的难点右图是多重影响因素的耦合:雾夜，迎面远光灯，此时系统如何评估是退出还是继续跑

以下是基于传感器原理方法的环境触发条件识别案例:车辆行驶在金属护栏道路边缘，雷达反射导致虚拟场景，系统误认为前方有车辆，导致误制动。

如何定义自动驾驶的安全验收标准

为了定义自动驾驶的安全可接受标准，首先要解决两个问题:已知的不安全场景如何被接受未知不安全场景的解决方案是什么

针对已知的不安全场景，一方面需要量化系统安全性能的要求，建立测试评估体系，同时需要解决模拟和测量中的技术难点，再现不安全场景，通过模拟测试结果判断是否满足安全要求对于未知和不安全的场景也有两个问题需要考虑:一是如何定义自动驾驶放行的安全标准，什么样的碰撞概率是可以接受的，二是如何建立场景库，解决算法的安全问题，而不是总是测试实车，缩短测试周期

具体来说，对于已知的不安全场景，期望安全标准列出了传感器，执行器，算法和集成系统的不同测试方法，但目前没有量化KPI的方法就行业实践而言，很多指标需要量化定义除了感知，其实还有控制和决策指标如何分配和定义每个指标是目前整个行业的难题

要解决这个问题，可以量化感知系统的安全KPI:第一层通过RSS或TTC评估安全距离是否合适第二个层次是通过碰撞检查评估肇事者是否可控缓解策略的效果如何总的来说，这两条路线是用来评估决策系统是否足够安全的

如何解决未知场景安全问题，需要定义整车安全准则:汽车行驶了多长时间，发生碰撞的概率这是一个相对安全的概念为了在安全性和可用性之间取得平衡，我们必须考虑定义可接受的风险什么是可接受的风险目前有几种想法

首先，通过交通道路数据看不同场景下的风险标准其次，参照A—D ASIL功能安全等级标准进行定义..在定义了风险标准之后，还有一个如何衡量的问题有人估计，如果要证明自动驾驶的算法是安全的，需要140亿公里来测量这直观地反映了自动驾驶系统测量的工作量所以我觉得模拟一定是未来的主流方向虽然现在仿真存在各种缺点，但是伴随着数字硬件和软件技术的发展，这些问题会逐步得到解决

如何解决自动驾驶模拟环境与真实世界的差异。

整个模拟和真实世界还是有很大差别的首先是因为传感器仿真模型的局限性现在常用的仿真软件可以制作传感器的大部分仿真模型但是在仿真中很难做出定量的判断，只能进行定性的处理，所以很难通过仿真发现算法的边界问题

更难的一点是建立与真实世界相似的场景模型场景模拟的计算量很大，如何支持其物理模拟目前是尽可能多地拆解功能安全相关的小场景模块，这是未来一个可能的发展方向

一般来说，为了解决自动驾驶仿真环境与现实世界的差异，可以采用场景库的模式:针对决策系统，通过与现实世界足够接近的场景库进行模拟，以识别决策算法的缺陷也可以采用随机交通流的方法:由具有自主驾驶能力的智能体或智能体集群组成的动态背景车辆与被测对象交互生成场景，在随机交通流中进行决策仿真