2022年11月8日-10日，由中国汽车工业协会主办的第12届中国汽车论坛在上海嘉定举办。作为党的“二十大”召开后的汽车行业首场盛会，本届论坛以“聚力行稳蓄势新程”为主题，共设置“1场闭门峰会+1个大会论坛+16个主题论坛”，以汽车产业的高质量发展为主线，与行业精英一起贯彻新精神，研判新形势，共商新举措。其中，在11月10日上午举办的“主题论坛10：开放、协同，软件定义汽车生态圈的新常态”上，华为智能汽车解决方案BU智能车控领域总经理虞晓发表精彩演讲。以下内容为现场演讲实录：

　　尊敬的各位领导、行业专家，女士们、先生们：
　　大家上午好！
　　我是华为智能汽车解决方案BU，智能车控的虞晓。感谢中汽协的邀请和韩昭主任的介绍，我今天分享的主题是《打造智能汽车数字底座，践行软件定义汽车》。主要介绍一下我们过去一年多践行智能数字底座开发过程中遇到的问题和挑战，以及我们的思考。
　　首先如同昨天大会主题演讲中王军先生提到的，智能电动汽车的变革时代，电动化是上半场，智能化是下半场。硬件能力决定了智能汽车体验的下限，而软件水平体现了智能汽车智能化体验的上限。智能汽车软件的复杂度随着技术的发展、竞争态势的激烈、监管和法规的要求，以及最终用户的需求变化而显著提升，使得智能汽车必须基于软件定义汽车的模式持续迭代优化。
　　传统汽车以硬件为主，需要考虑上万个零部件的集成，智能汽车必须在此基础上需要考虑上万行代码的集成优化。传统汽车可以离散地聚焦于一些单部件的竞争力和通过堆料方式实现提升竞争力。智能汽车必须考虑多样化智能部件的相互协同，构成综合解决方案竞争力。传统汽车注重汽车功能的结果安全，智能汽车必须考虑软件代码引入后各种ConerCase的过程安全。传统汽车的用户体验集中于行车中的驾驶性能和操控体验，智能汽车在辅助驾驶和自动驾驶的应用下更需要考虑做为第三生活空间中的个体各式各样的多样化的用户体验要求，这都离不开软件定义汽车的持续迭代和优化。
　　软件定义汽车需要一个智能汽车数字底座，一个开放、可靠、安全、高效的SDV软件开发平台。它需要引入高速以太通信网络，在基于I/O抽象基础上实现软硬件解耦，采用SOA服务化的理念，通过基础操作系统OS、原子服务、组合服务来支撑上层应用APP的灵活多样需求的开发和迭代。通过这个数字底座软件平台，APP应用开发可以通过调用北向标准服务化接口屏蔽不同厂家的硬件设备差异，而南向设备I/O抽象的接口标准化，使更多同类型的执行器能够快速方便地接入到平台上来。华为在设计开发智能数字底座软件平台的实践过程中，也遇到了各种各样的问题，这里我们初步归纳了如下三大挑战：
　　第一方面，数字底座软件平台的基础性能挑战。如何构建一个开放稳定，可灵活扩展的架构；如何保障通信网络的高带宽、低时延；如何均衡各个处理单元处理器的高效处理能力。
　　第二方面，面对软件共同开发中多方协同集成，如何保障协同开发的高效；如何保障各方开发的知识产权和正常的信息共享；如何面向多方集成下端到端的模型化仿真验证。
　　第三方面，面对OEM主机厂希望加快多车型快速迭代的目标，如何保障架构的标准化、接口标准化和软件平台版本的OneTrack高效迭代。
　　传统面向信号的处理系统，是可以将多个内容无关的信息打包在一个CAN报文中周期性的广播发送，报文的耦合度比较高。SOA软件服务化机制下，基于高内聚低耦合的原则，需要把CAN报文分拆成若干个独立的以太服务报文，以不相干的事件和状态发送，如仍采用CAN的周期性发送机制，必然会导致信令风暴。而且大量小的控制信息如果都要逐一用以太服务包发送，处理开销也很大。这里建议引入传统ICT的优秀实践，采用了Update on Change的事件触发机制替代周期性的Event的方式，能有效减少90%报文。采用nPDU机制将非时延敏感包聚合发送，能有效减少通信包的数量，可使CPU开销有效降低60%。
　　另外，SOA服务化后跨ECU间的交互以服务调用为主，如采用传统的同步RR调用方式，容易出现客户端软件任务Task因需要等待调用Result响应而产生阻塞，从而导致时延不稳定或者过大。这里建议采用异步RR调用机制，把服务调用和调用结果获取独立开来，能有效降低80%处理时延。
　　集中控制下的高性能ECU往往需要收编多个传统ECU的功能，必将带来单MCU上应用任务数量的激增、混合应用调度的相互隔离、性能、维测等一系列挑战。这就需要域控ECU的底层OS有更高的性能，包括低CPU底噪、低内存底噪、调度的低时延和确定性，更好的易调优维测的能力。华为VOS的操作系统通过自研轻量级协议栈、BSW多核部署、静态内存、确定性调度设计、服务化设计、网络安全、信息安全等技术来保障数字底座基础操作系统性能的不断优化和提升。
　　SOA服务化下软件分成应用、组合服务、原子服务、I/O设备抽象等多个层次，软件模块更多关系，更灵活，更复杂。除了设备抽象一般考虑就近部署之外，其他SOA软件服务模块可以灵活部署在不同的ECU上，这里需要考虑的因素有很多，包括模块间的通信频度、调用关系、资源占用、功能安全要求、CPU负载等等，部署是一个系统工程，需要综合考虑如上因素，综合分析评估以获取得最佳的部署策略。例如如图所示，优化前采用简单的就近部署策略，发现4个VIU的MCU负载表现不平衡，高的可以到60%，低的只有22%。经过相应的部署调优之后，我们能够把4个MCU的CPU占有率均衡在30%-40%之间，通信负载的整体也降低了14%，能够更好提高整个平台的性能。
　　再者，软件分层解耦也带来了多个软件模块开发商之间协同集成的复杂性挑战。首先作为集成方需要有一个贯穿整车开发流程的端到端的工具链。整车在设计、开发、验证过程中业界有很多优秀的工具，但是各个工具目前是相对独立的，并未能有效贯穿，没有形成真正的生产力。最重要的是上一个工具的输出要能够直接做成下一个工具的输入，而不需要进行格式转变，核查比对等额外的操作，提高开发效率。
　　另一点，在多方集成过程中，各方开发代码的知识产权保护和共享集成矛盾突出，有时会阻碍合作开发进程。这需要一套工具和保护机制，限定合作各方的工作和取阅范围，最终代码的集成可以在后端或云端服务器完成，与各方客户端相对独立，从而达到知识产权保护基础上的充分共享合作和调试集成。
　　最后一点，传统V模型要求每次设计变化都需要通过完整的设计、开发、验证，针对SOA分层解耦的软件开发，需要打造一个可分可合的运行仿真模拟器的工具，分开时，可以对每一个软件模块进行独立的开发、验证、调试，组合起来则可以对全业务、全量软件进行端到端的模拟验证，真正做到“设计即正确”。
　　做为数字底座软件平台，版本的OneTrack是保证软件高效迭代，性能提升的必要方式，是帮助OEM主机厂进行多车型、跨车型快速开发的有效保障。在实践过程当中我们也发现很多因为合作方式差异引发各种各样的问题出现。比如说上层应用，有一些是主机厂自主开的发，或者委托第三方开发的，在开发过程中经常违反调用关系，直接去调用下面设备抽象，认为这样更高效、更方便、更快捷。也有基于不同的接口应用在不同的车型，因为有不同的厂商认为这种互相合作比较快捷，导致出现重复自定义自己私有化接口的现象。如果是这样，必然会无法保障数字底座平台软件OneTrack归一化，也无法保障平台性能的迭代优化和问题的快速定位。
　　所以我们这里仍然建议要保持原子服务和设备抽象接口的标准化，可以在不同车型开发过程中拉出分支，版本进行扩展开发验证，完成后需要统一合入回主干版本，形成主干的OneTrack开发迭代，这样才能保障不同车型的版本配套，和可能因为我的数字底座软件平台的性能优化而带来的统一的升级迭代优化的价值。
　　最后总结一下，智能汽车数字底座软件平台的目标是高效、协同、开放。
　　高效就是要提供一张可扩展，具备确定性、低时延的高速通信网，提供优化以太处理性能和匹配SOA服务化软件的调度机制的，并基于时延和资源开销等综合最优的服务灵活部署策略，来保障整个软件平台的高性能。
　　协同就是把分散在设计、开发、验证工作流中的独立工具化零为整，贯穿成为统一的端到端的工具链，并支持在尊重知识产权保护基础上的高安全CP/AP的集成。多方合作构建可信模型化验证，打造模块化和系统级仿真模型工具支撑实现“设计即正确”。开放就是坚持遵循标准化接口定义，实现更多的合作伙伴的共同开发，在繁荣生态的同时，构建数字底座软件平台OneTrack主干版本的归一机制，助力OEM主机厂多车型快速迭代开发。
　　最后，我们还是倡议各个行业组织加强协作，联系上下游各企业共同定义、统一发布，在中汽协软件分会的领导下，发布一套最好用、最易用的软件定义汽车的整车层面各层API的接口标准规范。同时，围绕分层架构和统一API接口，实现不同厂家之间的互联互通，针对2C场景化应用探讨联合创新的模式，繁荣第三方生态。结合各自优势，分工协作，减少重复工作，开放共赢、落地实践、保障质量、提升性能，共同做大智能汽车产业的蛋糕。
　　谢谢大家！
　　（注：本文根据现场速记整理，未经演讲嘉宾审阅）