—— 汽车产业链供需平台 ——
首页 > 资讯 > 供应链 > 自动驾驶安全实践挑战及思考

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

盖世直播 2022-09-23 14:13:43

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

上海磐时信息技术有限公司创始人边俊以《自动驾驶安全实践挑战及思考》为主题,从如何设计可靠冗余,如何让Linux满足功能安全,如何覆盖感知系统的各种失效模式,如何正确判断自动驾驶设计的ODD,如何定义自动驾驶的安全可接受准则,如何解决自动驾驶仿真环境和真实世界的差异性这几个方面展开,以下是演讲内容整理:

1.jpg

上海磐时信息技术有限公司创始人边俊

如何设计可靠冗余

首先做个简单的自我介绍,我在2009年开始接触功能安全,当时普遍使用的标准还是应用于工业领域的IEC 61508,到如今已经从事了十几年安全相关的开发、审核等工作。首先说一下创立上海磐时信息技术公司的初心,从业十几年来,我看到国内安全领域和国外还是有一定差距,主要体现在自动驾驶、芯片、软件质量等领域,特别在自动驾驶领域,安全作为从L2向L3演进的最关键、也最基本的点,这一环节的完成度会影响到中国整个自动驾驶行业的落地。

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

第一,如何设计可靠的冗余系统,自动驾驶从L1向L4演进,安全冗余的设置也会越来越多,从L3-TJP交通拥堵辅助、L3-HWP高速公路引导等功能开始,在转向、机动、定位等方面都会有冗余要求。到L3以上,安全冗余会有一个全方位的要求,涉及感知、域控、电控等基础操作层面。

从2018年到如今,国内已经形成了自己的系统解决方案,但是有方案不代表这一领域真正实现了量产落地,其中仍然有很多技术问题没有得到解决。首先,系统需要具备有效且及时的失效检测机制,“有效”强调安全冗余机制的性能问题,国内的安全冗余设计往往是多种安全机制相互校验,如果有一个安全机制失效了,还要关注另外一个安全机制的性能能否达到要求。比如路征匹配和绝对定位一起构成了道路级定位的冗余设计,一旦绝对定位失效,路征匹配方案是不是还具备足够高的准确性,能够支撑车辆运行,这是需要考虑的问题。

“及时”强调冗余机制的切换时间,需要系统在较短的时间内检测到失效点,并迅速切换到备用机制,才能保证系统的正常运行。比如将摄像头和激光雷达融合,作为车道线识别的冗余设计,一旦激光雷达出现故障,实际运行车道线就会逐渐偏离摄像头车道线,这就需要激光雷达自身的安全机制可以及时探测到故障,系统进而及时切换到基于摄像头输出的横向控制。如果不能及时检测故障,实际行驶车道线和摄像头车道线偏差过大,系统就无法确认故障点,那么就必须采取紧急制动。

难点二,就是复杂的系统设计增加了冗余设计独立性的难度。工作人员需要考虑各种共因失效和级联失效,尤其是用到传感器融合的一些设计,需要考虑传感器的时间戳、自身运动状态等共因。除了电子电器故障之外,外在环境因素也会导致冗余设计的失效,比如降雨可能同时导致摄像头和激光雷达的性能下降。

做冗余设计的时候要从五个方面考虑。第一,要做充分的安全分析,如FTA,要把冗余机制由于性能局限导致失效的概率考虑在内。第二,在开发阶段早期做DFA的分析,避免潜在的公因失效和级联失效。第三,要有时间规划,需要缩短自我诊断和相互校验的时间。第四,增加系统工程的投入。第五,进行双重考虑,冗余设计既要实现ASIL等级分解,也要考虑fail-operational,为了故障降低的顺利进行,感知系统至少需要三个独立的功能/机制,通过3选2的策略,快速甄别故障。

如何让Linux满足功能安全

相比于其他系统,Linux有很多优势,一方面免费开源,拥有丰富的软件库,开发成本较低。另一方面综合性能强,反应时间、响应速度更快,可以更有效地运行软件任务,而且支持多核运行,适配于不同硬件。同时,Linux也有一定的劣势,比如说整个开发过程没有办法达成功能安全相关的标准,以下对Linux满足功能安全的几大挑战做了概括:

第一是缺文档,开发过程无法追溯。针对这一点,可以采用软件FMEA分析的方式,将软件模块白盒化,识别失效模式和影响,也可以对软件模块做ASIL安全等级分解,从不同层级进行监控,但如果采取软件监控,就需要额外去考虑其独立性。

第二是硬实时性难以保证,针对这一点,常用策略是增加实时内核,采用双内核运行,但这个解决方案也有很多问题,比如实时内核无法拥有Linux内核的优越性,而Linux内核无法满足安全性,为了保证硬实时性采取双核,可能会产生代码移植的问题。

第三是代码和单元测试的工作量巨大,这就需要针对安全做裁剪,重编不符合ISO26262编码规范的代码。第四是经过安全性改造之后,Linux的优越性消失。业内有一个假设,也许将来不会存在缩水打包的Linux软件包,这种软件包可以应用于对安全性要求很高的应用程序上,但是在硬件的通用性上可能会打折扣。

从行业进展看,目前国内外组织都在致力于提升Linux系统的安全性。因此,长远来说,Linux可能是一个更开放的平台,未来还是有蛮大概率被会用于安全的产品上。

如何覆盖感知系统的各种失效模式

目前来说整个自动驾驶的难点其实在感知,比如说L1和L2级别自动驾驶的主要目标是防止非预期的AEB导致与后车相撞,过渡到L3级别之后还会增加很多额外的安全目标,比如要正确地识别道路边缘信息;正确地识别前方障碍物以防止错误地前碰和后碰;正确地识别表征ODD的信息以防止系统进入不可知的危险状态。

当前感知上的安全目标还是主要针对L1、L2级别进行定义,一旦要用于L3级别系统,如何考虑这些偏差会成为行业的一个难点。设想一个场景,早高峰阴转中雨,你开车行驶在某道路路口,突然摄像头故障,那么你会看到以下场景:行地址失效,列地址失效,控制寄存器失效,像素数据管道失效,内存/寄存器寻址失效,图像数据管道失效。

2.png

图片来源:上海磐时信息技术有限公司

在L3级别自动驾驶中,需要保证目标物识别正确,ODD识别正确的同时,考虑到各种失效对它的影响,这其实有非常大的工程量。我之前也见过国外的一些芯片,他们在做这块分析时可能列到几千个场景,针对每个场景去考虑有什么影响,如何去解决。

针对以上难点,行业内也提出了几类针对摄像头的安全机制,一类是象素级别的模拟测试,主要是针对象素点,常用的方法比如模拟信号范围筛查,ADC的测试方案,行/列存储数据通路的测试方案,最后就是冗余。像素模拟测试可以用来解决像素颜色、强度、对比度的问题,也能发现大于一定域值的噪声,但是没有办法解决象素的时间、空间的表达,也没有办法解决图象传输中发生的问题。

针对图象的测试,这也是目前行业内应用比较多的方式,典型方式就是给一个参考图象,然后知道参考图象应该输出什么目标物。这种方式的优势是能够针对象素的时间、空间表达去测试,但是也具备一定劣势,其诊断覆盖率很难达到一定要求,难以遍历巨量的失效模式。

第三就是对组成元件的测试,这种方式覆盖像素颜色、强度、对比度;像素时间、空间表达;图像传输;也可以发现大于阈值的噪音,相当于白核测试,采用关键数据写入保护;CRC寄存器;温度、电压检测;时钟检查等等方法进行。

3.png

图片来源:上海磐时信息技术有限公司

以上这几种方式,我认为未来肯定是都是要结合在一起的,但是如何设计一个高诊断覆盖率,针对不同安全目标都可以适用的方案,我相信是所有摄像头厂商和后端芯片厂商的难题。

如何正确判断自动驾驶设计的ODD运行设计域

其实在自动驾驶早期的时候,大家都更倾向于用静态ODD约束和地理围栏。发展到现在,纯静态运行设计域约束不再适用,系统需要具备有效且及时反映环境条件的动态检测机制,保证系统始终在可接受风险下运行。

这里举了两个例子,左图是对于单一因子影响的评估:比如阳光直射导致摄像头反光,系统如何判断怎样的反光程度会对驾驶员产生影响,何时应该退出,这是当前行业的难点。右图是多影响因子耦合:大雾的夜晚,迎面远光灯,系统如何评估这个时候是退出还是继续运行。

4.png

图片来源:上海磐时信息技术有限公司

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

5.png

图片来源:上海磐时信息技术有限公司

如何定义自动驾驶的安全可接受准则

针对如何定义自动驾驶的安全可接受准则,首先来解决两个问题:已知不安全场景怎么样算是可接受的?未知不安全场景的解决思路是什么?

针对已知不安全场景,一方面要去量化系统安全性能需求,建立测试评价体系,同时要解决仿真和实测上的技术难点,复现不安全场景,以仿真测试结果判断是不是符合安全的要求。针对未知不安全的场景,也有两个问题需要考虑:一是如何去定义自动驾驶释放的安全准则,多大概率的碰撞是可接受的;二是如何去构建一个场景库,解决算法的安全问题,而不是一直进行实车测试,缩减测试周期。

具体而言,针对已知不安全场景,预期安全标准罗列了对于传感器、执行器、算法及集成系统的不同测试方法,但目前并没有给出量化KPI的方法。对于行业实践来说,很多指标都是需要去具体量化定义的,除了感知类的,其实还有控制类、决策类的指标。每个指标怎么去分配、定义,目前对于整个行业都是一个难题。

针对这一难题,可以去对感知系统的安全KPI进行量化:第一层通过RSS或者TTC去评估安全距离是不是合适。第二层是通过碰撞检查,去评估肇事者是否可控?缓解策略的有效性多高?总体通过这两条路线去评价决策系统是不是足够安全。

6.png

图片来源:上海磐时信息技术有限公司

如何解决未知的场景安全问题,就需要去定义整车安全准则:这辆车开了多久,碰撞概率多大。这是一个相对安全的概念。是对于安全性和可用性的平衡,那么一定需要考虑定义可接受风险,什么是可接受风险?目前有几种思路。

第一,通过交通道路数据看在不同场景下的风险准则。第二,参考功能安全ASIL A-D的等级标准进行定义。在定义了风险准则之后,还有一个问题就是如何去实测,曾经有人估计过,如果要证明自动驾驶的算法是安全的,要测140亿公里。这直观反映了自动驾驶系统实测的工作量之大。因此,我认为仿真一定是未来的主流方向,虽然现在仿真有各种各样的不足,但随着数字化软硬件技术的发展,这些问题都会逐渐得到解决。

如何解决自动驾驶仿真环境和真实世界的差异性

现在整个仿真和现实世界还是存在比较大的差异性,首先就是因为传感器仿真模型的局限性。现在常用的仿真软件已经可以做大部分传感器的仿真模型,但是针对传感器出现污渍、直面强光等场景,仿真中很难做出定量的判断,只能定性处理,因此很难通过仿真找到算法的边界问题。

更大的难点在于要建立一个和现实世界相似的场景模型,场景仿真的计算量非常大,如何支撑其物理仿真的工作。目前是尽可能拆解到若干有关功能安全的小型场景模块,这是未来可能发展的一个方向。

总的来说,为解决自动驾驶仿真环境和真实世界的差异性,可以采取场景库的模式:针对决策系统,通过足够逼近真实世界的场景库进行仿真,识别决策算法缺陷。也可以采取随机交通流的方法:通过具有自主行驶能力的智能体或智能体集群形成的动态背景车与被测对象发生交互,产生场景,在随机交通流中进行决策仿真。

(以上内容来自上海磐时信息技术有限公司创始人边俊于2022年8月26日由盖世汽车主办的2022中国汽车信息安全与功能安全大会发表的《自动驾驶安全实践挑战及思考》主题演讲。)

关注我们更多服务平台

添加社区公众号、小程序, APP, 随时随地云办公尽在掌握

联系我们
盖世汽车社区 盖世汽车中文资讯 盖世汽车会议 盖世汽车研究院 盖世大学堂-公开课 Automotive News Global Auto Sources 友情链接 Copyright@2007-2022 All Right Reserved.盖世汽车版权所有
增值电信业务经营许可证 沪B2-2007118 沪ICP备07023350号 沪公网安备 31011402009699号 未经授权禁止复制或建立影像,否则将追究法律责任。