目前，自动驾驶一直是行业突破的重点之一，AI的发展为我们提供了很多新思路。那么，汽车与AI会碰撞出哪些新的突破呢？我们兴奋之余，更应该考虑的是AI本身的安全问题。通过系统架构师的操作？通过功能安全和关键芯片安全组件等方式来提高安全性？在机会与问题交织的背景下，SASETECH社区举办了这场以“AI安全”为主题的线下沙龙活动。
在活动中，大家基于自动驾驶领域的安全问题展开分析讨论，其中包括所涉及的模型选择、训练方法、硬件和软件的安全等级，从而延伸至AI算法在自动驾驶领域的应用。活动中，Steven老师对AI及8800标准进行了阐释和分析，我们觉得很有意义，因此将他的分享整理出来，供大家参考。
Steven
分享老师深耕行业十余年，专注功能安全，自动驾驶安全，结合8800标准和SOTIF有针对性的研究经验，分享内容围绕自驾展开。
在自动驾驶功能中的AI安全
自驾的AI安全，或者说泛AI系统的安全，这里面包含本身硬件的安全，也包括操作系统、底层软件和中间件，以及AI算法的安全，各自都有一些研究的痛点。
AI硬件安全
关于AI硬件的安全，在以前的说法是AI没法做功能安全，只能是QM，这种说法随着技术的发展被逐渐证伪。
但在这个过程中，AI芯片的设计和26262标准的要求存在实际冲突。比如高算力的SOC，如何评估它的安全或者说SOTIF的性能；比如两颗ASIL B的芯片要做cross check时，就不能做算力的叠加。
提升算力在提升SOTIF的性能上有很重要的作用。放弃了SOTIF的性能去做cross check的相互校验，并不是很有意义。硬件团队的核心要点是达到26262的要求，但不能认为软件出问题就是软件的事情，与硬件无关。从整体方案上考虑，还是要找到硬件和软件两者之间的平衡点。
ISO8926标准
传统上，对安全性要求高的公司，在车载产品上会采用QNX作为操作系统，但现实，市场上百分之九十的公司基于便利性，都会选择LINUX作为操作系统。然而LINUX本身没法符合26262，因此安全性能无法得到保证。
举例说明：伊莉莎项目，目的是用人海战术把LINUX重构一遍，项目失败后，项目组转型为ISO8926标准委员会，把26262 part8做hardware component evaluation的标准降低，相当于降低了26262的安全标准，再加入其他安全补丁方案，最终形成一套新的标准。
AI算法的安全
8800是目前比较火的标准。它从流程上、鲁棒性上考量了怎样把AI做得更安全，是基于目前业内的实践给出的标准。但目前8800中给定的一些标准尚无法落地。
基于确定性的监控
清华大学做过一个研究：通过算法来监控障碍物和行人的判定，获取位置、速度等信息，在判定的同时，给出这个判定有多少准确性的评估结果。并且通过采样对置信度进行标定。
随着AI技术的发展，技术上对算力的需求越来越大。因此8800标准的实施也离不开算力的支持，针对这方面8800给出了一个思路，当设计资源足够的时候，我们可以用这个方法去避免模型中一些系统性的问题。这个问题在26262的年代也会遇到，在26262标准刚出来时，大家发现如果按照标准实现，需要做很多冗余，做很多监控，要占用很多的资源。但是只要按照标准的要求来实施，就不会再有人质疑整个系统的安全性的问题。未来，8800标准的发展，也会像26262一样，把一些比较容易落地的标准，写成强制性的措施。
8800标准除了提出一些流程上的要求以外，最重要的两个点：一是增加系统本身的鲁棒性，通过fault tolerance来让系统更安全。当这个场景是训练场景没有cover的时候，将系统出错的可能性降低。二是增加系统监控的手段，虽然系统的鲁棒性没有提升，但是出现OOD的时候，能够监控到这个场景，进而使得系统进入安全状态。
8800标准里提出一个开发级的安全措施和一个架构级的安全措施。开发级的安全措施就是利用各种各样的模型选择和训练的方法，让模型提升OOD检测，也就是out of distribution的检测能力。架构级的安全措施则在架构层面给出了各种各样的做监控的方法，比如说可以用CV去监控，可以用多样性的AI去监控，以及像前面说的做OOD的监控，做Uncertainty的监控也就是不确定性监控，这都属于监控的范畴。
举例：Mobileye从2015-2016年就开始利用这种CV算法去监控它的DNN算法，然后它以此来去符合，也就是ISO20202的标准框架内的安全等级。也就是他们宣称的自己的AEB是ASIL B，那怎么实现ASIL B，它其实用了一个ASIL B的CV算法去监控它的这个AEB的DNN算法。
反思：要能够通过CV去监控DNN，首先要有一个比较好的方案针对safety margin安全边界的设计。其次就是设计团队本身要有一个非常强的CV算法积累。
我相信未来8800标准落地的时，不是说所有标准里提到的监控手段，设计产品中都要做到，如若此，将对那些没有CV能力的公司造成毁灭性打击。假设业内有80%的公司缺乏CV能力，而8800把这个东西写成强制落地，也并不利于8800的推广。
在智能座舱应用中的AI安全
智能座舱本身功能安全等级就低于自驾的等级，因为座舱主要是在一些人机交互的warning上，针对一些功能有ASILB的要求。站在AI的角度来说，AI算法其实有很多Cyber Security网络安全的漏洞。这些漏洞存在于AI算法本身。8800标准中也有提到，这种叫Adversary Attack的共计模式，用一些特定的图像的pattern就可以欺骗AI算法，让AI出现一些错误的判断，如果错误判断结果是黑客想要的话。这个东西就可以理解成一种Cyber Security的Attack。在座舱域，比如说让摄像头捕捉到一些会出错的image，就有可能被利用来通过人脸识别解锁车辆。这个就是我们说的Adversary Attack对抗性攻击。
再一个，如果是做舱驾一体方案的话，对座舱域的攻击会不会导致影响到自驾域？如果要做隔离，该怎么做隔离？是做硬隔离还是做软隔离？包括从功能层面的隔离，或者是Cyber Security层面的隔离。还有一点，座舱域的应用大量和SOTIF里面的misuse有关系，那当这种SOTIF的misuse被结合了我们说的Adversary Attack对抗性攻击措施，再加上硬隔离做的不好，就有可能会导致内存的错乱和溢出，这个也有可能影响到座舱域系统原本的功能安全的要求，或者是影响到自驾域的功能安全。
问题讨论
Q1：目前的自驾芯片常常宣称自己能够达到ASIL D的安全等级，实际是否能够达到？
A1：目前市面上的几款自驾芯片，一个是硬件上并不是全芯片都是ASILD安全等级，而是说里面的部分模块可以达到ASILD安全等级，其他模块可能只能到ASILB的安全等级。另一个是这个ASILD的安全等级并不包括软件的范围。
Q2：那这样在实际的使用当中，是不是会有风险？
A2：如果说等真正意义上的ASILD落地后再做产品，那么可能其他的车厂不等了，产品做出来上市了，那么（出于产品竞争的考量），该接受这个风险就接受。
作者：SASETECH
文章来源：sasetech
推荐阅读
更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
