2024年全国两会
确定

网站 > 2023中国汽车论坛

苏州智行众维智能科技安宏伟:基于X-in-Loop技术体系的功能安全软件测试


2023年7月5日-7日,由中国汽车工业协会主办的第13届中国汽车论坛在上海嘉定举办。本届论坛以“新时代 新使命 新动能——助力建设现代化产业体系”为主题,设置“1场闭门峰会+1个大会论坛+16个主题论坛+N场发布”共18场会议及若干发布、展示、推广等活动,旨在凝聚各方力量,形成发展共识,为建设现代化产业体系贡献汽车行业的智慧和力量。其中,在7月7日下午举办的“主题论坛十三:聚能共创,加速构建软件定义汽车新生态”上,苏州智行众维智能科技有限公司CEO安宏伟发表精彩演讲。以下内容为现场演讲实录:

 

 

 

大家好!非常感谢协会的安排,还有各位专家、各位嘉宾耐心等到现在,作为今天演讲的最后一个主题,我将尽快把这个工作完成,尽量把我们损失的时间找补回来。今天给大家汇报的主题是基于X-in-Loop仿真测试技术体系的功能安全软件测试。

 

刚才韩昭总监已经介绍过,我是苏州智行众维的安宏伟,今天演讲分三部分:

 

1.给大家简要介绍下公司的情况。

 

2.针对我们围绕安全测试,包括功能安全、预期功能安全领域我们在应用层开展的工作,我们的技术体系,实际服务于行业、产业所开展的工作做介绍。

 

3.我们最近两年探索的,如何把功能安全软件测试和基于场景的应用层测试融合在一起,将所做的探索和工作给大家做汇报。

 

首先给大家简要介绍下公司的情况。IAE总部在苏州,同时在上海、杭州、重庆、武汉、合肥各个地区也有相应的部署,期待大家在各地都能够和我们多多交流和互动。

 

我们所从事的领域主要是围绕自动驾驶或者说智能网联汽车的安全,从仿真测试方面开展工作,包括进行相关工具链的研发、技术服务以及提供行业所需的仿真场景数据平台,并在数据驱动和法规驱动方向开展一些相应工作。

 

自动驾驶发展到现在,安全始终是我们无法逾越的一关。安全问题和我们的算法、和整个系统开发相关,归根结底体现在软件安全性上,既有应用层、功能层面的安全,同时也包括软件本身架构、代码,自身在安全性上的表现。

 

我们愿景是通过大家的努力、通过科学有效的仿真测试手段,来加速自动驾驶产业安全落地的进程,通过建设企业技术层面的自信,以及社会层面对我们自动驾驶技术的公信来推进这一进程。也是为了服务这一愿景,我们构建了称之为X-in-Loop的仿真测试技术体系,这一技术体系是以场景测试、场景覆盖为导向,以数据为驱动的。

 

基于这个体系,从代码、软件到处理器,到控制器,到子系统再到整车是一个完整的闭环测试流程。我们所做的工作,是在应用层,围绕算法、围绕我们的软件在整个开发不同阶段的安全表现进行测试。后面大家也会看到,我们把功能安全软件测试也嵌入到X-in-Loop这个流程体系里,来更好服务和加速安全落地的进程。

 

第二部分介绍一下我们在应用层所开展的工作。这里简要给大家介绍一下我们的技术、产品以及做的一些具体工作。首先我们针对算法、代码和软件,在完全虚拟环境下,构建了云算力海量仿真平台,目的是为了实现安全测试所需要的加速能力。自动驾驶的测试是基于场景的,并且是海量的场景,只有通过云算力、通过并行仿真的方式才能够实现百台、千台甚至万台虚拟车辆的并行测试,快速完成海量有效场景的测试和筛选,针对筛选出来的场景,进一步我们再通过硬件在环等技术手段完成后续的测试评价。

 

对于自动驾驶尤其是高阶自动驾驶来说,硬件在环测试依然重要,但是从场景覆盖效率、从效率和真实度来讲,我们还需要构建更加高效、更接近真实的方法,这也是和传统E/E测试的不同。这就需要车辆在环技术。我们在实验室里,基于安全可控的道路负载模拟进行实车在环测试,甚至我们在实验室里构建虚拟的试验场,模拟不同天气尤其是恶劣天气影响,来加速测试验证进程,在充分保证安全的情况下,对危险场景进行验证。

 

对于高阶自动驾驶而言,云算力的海量场景仿真可以极大提升我们测试效率,而车辆在环仿真,尤其是在实验室内、基于道路负载模拟的实车在环可以让我们的测试无限逼近于我们在真实道路上的场景,在实现危险场景测试和加速测试的同时保证我们的安全性。再比如,像前些年特斯拉遇到的制动失效等情况,这类场景不是自动驾驶功能,但可能和功能安全,或者和预期功能安全相关的场景,都需要有新的技术方法进行有效测试。

 

这里有一个很有意思的例子,今年年初上海电视台曾经对上汽(车辆在环实验室)有过一个专访。上汽去年实现了双百万的成绩,新能源车过百万,出口也是过百万。我们为上汽搭建了高级整车在环实验室,去年在疫情情况下,针对要出口的目的地的使用场景,在国内、实验室的环境下,针对ADAS等功能提前做落地前的验证,加速出口销售的进程。

 

在虚拟仿真和实验室混合仿真之后,最后还需要场地和道路上的验证,也是基于这样的体系,我们提出了称之为“新三支柱法”自动驾驶仿真测试和评价体系。我们通过云算力仿真完成场景覆盖形成一个漏斗,筛选极限场景和危险场景,再通过我们刚才看到的车辆在环体系,以无限逼近于实车测试的环境,同时又保证它的安全性、一致性和可重复性,进行可能的极限场景、危险场景的验证,来帮助我们最后进行强化测试。这和人工智能的深度学习和强化学习路径有相似之处。第三个支点我们把工况场景在场地道路上进行标定、测试和验证,来提升我们虚拟仿真的精度和置信度,完成技术上和数据上的闭环。

 

第三部分我们从功能安全角度来看一下软件测试。我们不仅在应用层进行功能测试评价,同时我们要考虑,如何服务于自动驾驶算法软件的整个开发流程。

 

我们从2年之前开始研究功能安全包括预期功能安全,从基础软件层面如何和应用层的测试打通,在基础层和应用层之间形成链接,甚至是形成协同。

 

对于软件测试,我们有静态代码检查、动态代码检查、故障注入测试、资源占用及时序监测等一系列环节,今天时间有限,就只针对故障注入和资源占用监测这两块和X-in-Loop技术闭环体系的结合给大家介绍一下我们的探索。

 

大家从事软件开发,尤其是汽车软件开发,对于ISO26262标准应该都很熟悉,这是我们的基础。从ISO26262来讲,V流程是一个必要的要求,但是对自动驾驶开发包括智能座舱来说,我们要强调敏捷开发和快速迭代。这两点从我们仿真测试、从验证体系的角度来说,不一定是非左即右,这两点是可以完全融合在一起的。

 

在技术闭环体系里,在开发全过程中,各个环节都需要考虑在环测试。而针对故障注入还有资源占用监测,我们要从单件,从部件到子系统、再到系统这些环节看,如何和X-in-Loop、和我们在环测试结合在一起。

 

首先,我们简要介绍一下FIT,就是故障注入测试,故障注入测试大家都很熟悉了,在这个领域有一个最经典的例子,当年丰田的电子节气门控制这块出现了故障,导致了900万台车的召回,被罚款12亿美元,后面还导致了丰田二手车估值的断崖式下跌。

 

从故障分析调查结果来看,是它的源代码错误,包括缺乏充分的fail-safe这样的机制保障,这也是为什么我们说在ISO26262里面,现在对于ASIL C和ASIL D,故障注入测试这一块是强制性要求,具体的技术细节不再跟大家赘述,大家如果感兴趣的话后面可以专门再做详细交流和沟通。

 

接下来我们介绍一下,针对故障注入测试,我们如何和X-in-Loop体系融合,我们可以和软件在环、芯片处理器在环、硬件在环、车辆在环测试环节结合在一起。这是针对新能源车ECU的一个测试案例,从功能安全软件开发测试角度来说,在控制器、软件代码、模拟故障这些环节都需要涵盖,在实际测试过程中,还有一个环节,是在实车、道路上大家也要做FIT的测试。

 

FIT是软件故障注入,在内存寄存器,任务,函数里来实现执行阻塞、死锁、活锁、执行时间的不正确分配、内容损坏及溢出等故障的注入模拟,在实际道路上开车时做这个测试,还是非常危险的。很难保证不会发生类似当年丰田这样的事故。

 

但是从我们整车的开发,从软件功能安全测试角度来说,这又是必要环节,因为在实车状态下,和在虚拟仿真测试状态下,整个控制器的边界条件包括各个控制器之间的互相影响和干扰都是完全不一样的。

 

我们通过将硬件在环和车辆在环模拟测试,和FIT结合,我们可以保证它在足够安全的情况下,进行不安全场景的测试。从功能安全软件测试来说,这是一个切入点,我们要做的工作就是如何用安全的手段测试不安全的场景,让安全更加安全。

 

基于X-in-Loop,第二个功能安全软件测试的应用,就是资源占用监测,从软件开发和ISO26262标准来说,和刚才介绍的FIT又有不同,FIT只是对特定安全等级有要求,但是对于资源占用测试,在ISO26262里定义的所有安全等级的部件都要求进行测试,因为这实际上是我们对于软件最基础的要求。那么资源监测要测试什么?我们的CPU和内存,我们对于手机、电脑都很熟悉,CPU资源不够、内存不够、我们文件无法保存、系统可能会死机,而对于汽车来说如果资源不足,我们的目标指令无法执行,那么车的安全、各方面都可能会发生很严重的事故,甚至是车毁人亡。

 

我们在软件阶段、控制器系统阶段都要进行资源监测测试,我们目前和一些主机厂伙伴也在合作,在探讨在硬件在环或者车辆在环阶段,把这块测试能力给添加进来,在保障它的安全情况下,我们完成软件测试,这里就是我们一个PROV资源监测和半实物仿真结合的例子。

 

上面的所有测试都会自动生成测试报告,自动化测试是提升我们研发验证效率的必要手段。

 

这里我们做了简单的汇总,针对故障注入和资源占用监测,我们在测试时候可以针对单件控制器,也可以针对我们的子系统、针对实车测试,针对不同的使用需求、不同的应用场景和验证场景,我们可以选用合适的方法。

 

它们之间的对比这里我不再赘述,大家有兴趣的话可以再具体交流。但是我们的目标就像刚才提到,能够让安全更加安全。我们面向应用层、基于场景测试的例子就不再列举了,这里可以介绍一下我们最近给华人运通做的工作,针对英飞凌还有恩智浦两款芯片,在AUTOSAR架构下,我们针对它的控制器,使用FIT和资源监测工具,基于我们的专家团队的丰富经验,来实现故障注入测试和资源占用监测。

 

同时在这个过程中,我们也从控制器硬件在环测试入手,将软测工具融入台架测试阶段,下一步我们可能在实车,在实验室,在台架上也会完成进一步的工作。

 

最后,从功能安全软件测试角度来讲,和场景测试、面向应用层的测试不太一样,功能安全软件测试对于使用的工具本身是有功能安全认证要求的,这里我们和SGS和TUV莱茵合作,有相应认证支持,后面也是希望在软件定义汽车的时代,我们能够更多参与到整个汽车软件的开发、验证过程中,并加速整个进程,让未来加速到来!

 

也希望和产业、和协会包括软件分会还有在座的各位嘉宾朋友一起,我们能够在新的方法体系、技术路线和新的手段上去做更多的探讨和共同的研究。

 

非常感谢大家的参与,谢谢!

 

(注:本文根据现场速记整理,未经演讲嘉宾审阅)

所转载稿件如有侵权,请与我方联系删除;邮箱:daogecaijing@126.com

评论

暂无评论
已全部加载