2024年7月11-13日，2024中国汽车论坛在上海嘉定举办。本届论坛以“引领新变革，共赢新未来”为主题，由“闭门峰会、大会论坛、10多场主题论坛、9场重磅发布、主题参观活动”等多场会议和若干配套活动构成，各场会议围绕汽车行业热点重点话题，探索方向，引领未来。其中，在7月12日下午举办的“主题论坛四：数据链动汽车，智能驶向未来”上，易特驰汽车技术有限公司软件开发解决方案总监吴正发表精彩演讲。以下内容为现场演讲实录：

  各位领导、各位同仁下午好，我是来自于易特驰的吴正，今天下午我会把汽车行业软件开发面临的挑战和博世集团以及易特驰公司针对这个挑战的一些想法和大家分享。

  主要由于自动驾驶和智能座舱这两个域的软件开发驱动，给新的软件开发工程师带来了新的挑战，主要集中在三部分：

  1.部署频率。

  2.新功能的开发速度。

  3.当我们SOP以后，如果我们的软件有BUG，是不是能在以小时为计的时间之内发现这个BUG，同时把BUG迭代掉。

  这三个指标针对于之前传统的V-cycle的开发模式无论如何达不到的，这是我们现在必须面对的挑战，必须找到相应的解决方案。

  站在主机厂的角度，现在软件的集成度越来越高，电子电气架构从传统的分布式一直往SOA的架构上迭代，就意味着有越来越多的功能从传统控制器拆出来、解耦出来，往你的主机电脑上不停地集中、不停地迭代，就意味着单个车载电脑软件的复杂程度越来越大，就意味着集成过程中参与方越来越多，从操作系统、基础软件、中间件、算法、应用层，越来越多的玩家集中在一个控制器的开发中。

  作为主机厂，我负责最后的集中交付，我面临的问题是当我拿到这些软件集中的时候，已经在整个开发流程的中后期，如果这个阶段发现问题的话，时间压力、成本压力、沟通压力非常大。现在大家都比拼时间和速度，如果没有很好的办法把问题提前发现，一定要把问题集中在最后的集成阶段才能发现的话，面临的挑战就非常大，团队和交付期面临不可控的因素也会越来越多。

  所有主机厂都在想，我们挑战已经在面前了，用什么样的方法解决这个问题?绝大多数主机厂的软件工程师都建立了很大的团队，500人、1000人团队，他们做的事情就是从传统的V-cycle向DevOps开发流程持续集成、持续交付的方式实现。通过ETAS跟欧洲和美国的主机厂，和国内主机厂的伙伴，发现大家做DevOps的时候通常会有三个级别：第一是实现了单个软件模块的自动化流水线，软件模块本身已经可以自动化实现开发和测试，依然无法避免最后阶段的集成，这个就是集成的地域模式无法避免。做得好一点，我们可以把功能相近的软件模块或者地理上相近的，或者组织结构相近的一些模块或者功能可以进行预编译、预集成，极大减少了最后阶段的集成，可以实现部分的改善。

  如果要想彻底解决这个问题，我们现在提出了“软件工厂”的概念，所有软件的参与方是基于合作的平台，当然是有权限的限制来共同开发，他的想法是只要有一版软件的提交，这版软件就会自动在平台上把所有该做的软件事情通过流水线的方式自动化实现，包括现在说的模块测试、集成测试甚至以后的回归测试，所有这些东西都可以在软件触发之后自动触发，作为软件的开发工程师可以第一时间拿到测试报告，可以在很快的闭环之内不停地迭代软件，不用等到最后的集成。

  这是针对最下面这一层实现一个软件模块或者软件端功能自动化流水线的实例，这是去年底我们跟亚马逊合作，在亚马逊Re Invent的技术日上联合展出。我们的目的，现在很多主机厂做软件的时候还有一个问题，大家每个软件开发者用自己的电脑装了一个软件开发环境进行代码开发、代码提交，现在很大的问题就是开发环节和验证环节、部署环节如果不一致的话，用的公域版本不一致、库的版本不一致，工程师本身在电脑上开发没有问题，但一旦真正部署到实际环境上，这些问题无法提前发现，这就是为什么我们有一个Washing Workbench的概念，我们把所有的开发环境以镜像的方式提前在云上部署好。作为任何一个软件工程师，只要根据我编的项目平台进行登录，还会自动在云端建立起来我要使用的软件开发环境，就可以针对这个环境开发软件，进行软件提交，当我推出以后，所有这些资源会自动被释放。这是一个软件开发虚拟集成环境的概念。

  一旦软件被提交到了代码仓库里，所有刚才我说的集成测试，甚至当你的软件编译过程中，相应的需求文档也会自动被触发生成，之前ASPACE要求的追溯性可以通过这个平台进行保证。接下来虚拟控制器的生成，虚拟控制器和多样模型的闭环搭建，和我们测试用例的自动拉取，基于测试用例在云端自动测试的执行，所有这些东西都是在云端自动实现的，作为软件开发工程师可以拿到自动的软件开发报告，来验证我刚才提交的那版软件是不是有问题，如果有问题的话可以立刻迭代掉。

  这是当时我们跟亚马逊联合发布的一个例子，这个例子是跟我有关，技术控搞得比较复杂一点。这个例子本身就把刚才PPT上说的几个步骤全部实现，怎么通过虚拟的软件开发环境，我在云端进行代码的编写或者建模，模型建完以后怎么提交到代码仓库，提交代码仓库以后就会自动触发所有软件接下来编译和测试的工作。

  这边是三个层次当中的第三个层次，现在博世内部也有一个软件工厂的开发平台，这个平台举两个例子。基于平台，我们首先开发了一个ADAS中间件，另外是AUTOSAR AP。基于这两个平台，我们跟合作伙伴联合开发，这个平台本身是跨公司、跨国家的一个合作平台，这个平台大家可以看到每天有将近600个工程师在上面进行开发和迭代，最多的时候需要同时在云上起180个虚拟机支持所有流水线的执行，每天会有超过100GB data的同步，无论你是下载还是代码的推送、验证都会基于这个平台进行，这是我们博世内部基于软件工厂概念的实践。

  这是平台简要的介绍，我们有很多成熟的组件已经在里面了，可以根据客户需求定制化开发，还有资源的监控，所有资源都可以搭建和动态释放，完全取决于你现在有多少人在做工作，做了哪些工作，所有这些都可以动态监控。这里可以看到实时在跑的流水线是哪些，这些流水线是做什么的，下面你要点进去，每个流水线的细节都可以看到，整个平台会支撑跨公司、跨域的合作。这是我们面对软件新挑战的解决方案。

  这个方案最核心的解决方案就是虚拟化测试(软件在环测试)，传统控制器的开发强烈依赖于软件开发完以后，做完软件必要测试以后一定要上HiL上Bench或者上整车才能交付release。现在电子电气架构逐渐集中，逐渐和强实时real time的操作系统进行解耦，你会把很多功能放在非安全域的控制上执行。这些功能本身就和实时系统解耦了，如果解耦这些功能完全可以用虚拟化的方式测试掉，这是我们的方案。要做这个事情本身大概分为几步，首先针对于基于控制器的代码，必须要有办法生成虚拟控制器，把以前跑在控制器ECU上的程序可以让它跑在PC端、云端。

  另外我们要把市面上比较主流的多样模型集中在一起，因为所有按功能划分的部门，无底盘、PT、自动驾驶、座舱他们都有用得非常习惯的第三方主流的模型，发动机模型、变速箱模型或者车辆动力学模型、道路模型，所有这些模型我们必须找到一个平台，把它和虚拟控制器可以通过虚拟总线的方式联系在一起，我们这个平台叫call simulation，我们可以把市面上所有主流的对象模型和生成的虚拟控制器进行闭环搭建。基于这个，搭建起来一个闭环的环境以后，基于这个环境可以做测试甚至做虚拟标定，因为我在很多主机厂，他们最大的问题是现在的车，单车型销售越来越少，但变种越来越多，这种情况下以前这么投入造很多样车跑实验、做耐久是无法负担的，这个地方需要有虚拟环境，把绝大多数的测试甚至成熟度不高的预标定做完，现在我们有一些客户是基于这个平台做预标定的事情。最后我们可以把整个环境进行到云端部署，跨部门合作就不成问题了。

  接下来有一个视频，我们基于简单纯电的平台建立了纯电的虚拟环境，如果大家对测量标定比较熟悉的话这是主流的测量标定工具INCA，也是我们公司的。基于这个虚拟平台，标定工程师和测试工程师跟他上实车，跟他上HiL、跟他上Bench用的工具一样，依然通过这个工具进行通讯，采集控制器里面的数据，甚至在这个例子里我们进行了预标定自动标定的过程，之前的稳态扭矩输出和实现目标的扭矩输出有一个明显的GAP，他用一个定点补偿的方式进行优化，优化完以后自动把标定再刷回去，之前和之后两个情况进行对比。标定工程师基于虚拟平台做的事情，和你在HiL上整车市场是一样的，甚至测试用例、测试工具都不需要改变。

  这是另外一个例子，这个上面有6个虚拟控制器，这是针对于VCU百公里加速的标定，首先模拟一个上电的过程，挂到D档，把油门踏板上到50%的开度。之前的标定百公里加速需要15秒，我们需要改，把标定数据优化以后可以缩短百公里加速的时间。基于这个技术，我们有些主机厂基于这个技术可以实现预标定的原因，完全可以把车上用的标定流程或者环境直接移植到现在的虚拟平台上，是无缝对接的。

  最后一个问题，这个虚拟测试或者虚拟标定的概念非常好，但它有瓶颈，瓶颈在什么地方?如果我们想定性测一些功能没有问题，但如果我想在一个虚拟环境下想定量做一些事情，他绝大多数很强烈地依赖于被控对象模型的精度。假如发动机模型精度本身并不是那么高的话，上面能做的事情其实有限，比如我可以实现50%的标定成熟度，再往后要上实车要真正上Bench去做。

  这里有一个对比，博世的气囊部门用了虚拟化进行了测试，他有一些数据对比。首先是气囊部门完整测试有7万条测试用例，正常发布周期要三个月，是以季度来算的，为什么?基于HiL要测完7万条用例需要4个多月，最大的瓶颈在这边。当我们把Full test用虚拟化的方式实现，大家可以看到95%测试用例可以用虚拟化实现，有5%是无法用虚拟化替代。但是基于这样的比例，极大提高了整个测试的覆盖度，以前要四个半月，现在七天就能测完。哪5%是无法用虚拟化替代的?就是这边，主要是跟电磁干扰、雷雨环境、振动这些有关系，这个很难用纯软件的方式解决掉，但也可以，但代价和产出不成正比。

  所以说软件在环测试不是为了替代硬件测试，一定是把更多的以前强依赖于硬件测试往前移，尽量缩短整个开发周期，这是我们的目的。而且针对于这个解决方案，以虚拟化测试为中心，向前向后延伸我们做了很多实践，流水线可以大大缩短整个开发周期。

  这是我今天的分享，谢谢!