2022汽车论坛华为虞晓：打造智能汽车数字底座，践行软件定义汽车

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

尊敬的各位领导、行业专家、女士们、先生们:

大家早上好！

我是华为智能车辆解决方案BU智能车辆控制的萧玉。我今天分享的主题是“构建智能汽车的数字化基础，实践软件定义汽车”。本文主要介绍一年多来智能数字基地发展中遇到的问题、挑战和我们的思考。

正如昨天王先生在大会演讲中提到的，智能电动车时代，电动化是上半场，智能化是上半场。硬件决定了智能汽车体验的下限，软件水平也体现了智能汽车体验的上限。随着技术的发展、竞争的激烈、监管法规的要求、终端用户需求的变化，智能汽车软件的复杂度显著提高，使得智能汽车不得不在软件定义的汽车模型基础上不断迭代优化。

传统汽车主要是硬件，要考虑上万个部件的集成。智能汽车必须在此基础上考虑数万行代码的整合和优化。传统汽车可以离散地专注于一些单个部件竞争力的体现，通过材料的堆砌来提高竞争力。但智能汽车必须考虑多样智能部件的配合，形成综合解决方案的竞争力。传统的汽车用户体验可能侧重于出行带来的操控体验和驾驶体验。随着自动驾驶和辅助驾驶的广泛应用，智能汽车需要考虑基于第三生活空间的各种用户体验的不断变化和完善，这离不开软件定义汽车的不断迭代和优化。

汽车的软件定义需要一个智能汽车数据库的软件平台。它是一个开放、可靠、安全、高效的SDV软件开发平台，需要引入高速以太网通信网络，实现基于抽象的软硬件解耦。采用SOA服务的理念，通过基础操作系统、原子服务和组合服务，支持上层应用app灵活多样需求的快速开发和迭代。通过这个数字化基础软件平台，APP应用开发可以通过调用标准化接口屏蔽不同厂商硬件设备的差异，更多同类型的执行器可以快速便捷地接入平台。对于华为在设计和开发智能数字基础平台软件过程中遇到的各种问题，我们初步总结为以下三个挑战:

首先，数字基础软件平台的基本性能挑战。如何构建开放、稳定、灵活的通用架构，如何保证通信网络的高带宽、低延迟，如何平衡各处理单元的高效处理能力。

其次，面向软件共同开发、多方协作、协同集成。如何在面对多方协同集成时保证协同开发的效率，如何保证各方开发者的知识产权和正常的信息共享，如何面对多方集成的端到端建模仿真验证。

再次，面对OEM加速多车快速迭代的目标，如何保证架构、结构的标准化和高效迭代优化。

下面我从三个方面详细介绍一下:

第一，传统的面向信号的处理系统，可以在一个CAN报文中封装多个不相关的信息，周期性的广播发送，报文的耦合度比较高。但是在SOA框架下，基于高内聚低耦合的原则，CAN消息需要分成几个独立的以太网服务消息，在不同的事件和状态下发送。如果仍然采用传统的CAN周期性发送机制，必然会引发一场发送服务信令的风暴。

另一方面，如果大量的小控制信息以服务包的形式逐个发送，处理开销也非常大。因此，基于华为长期以来优秀的ICT实践，我们建议采用Update on Change方法，而不是周期事件方法，有效减少90%的消息数量。此外，我们采用nPDU机制来聚合非延迟敏感包，有效地减少了60%的通信包数量和CPU开销。

面向服务的SOA，跨ECU调用主要是服务调用。如果采用传统的同步RR调用方式，客户端任务很容易因为在调用过程中需要等待调用反馈响应而被阻塞，导致任务调用不稳定或者延迟过大。所以在这里，我们建议使用异步RR调用方法来处理服务调用并得到结果反馈，这样可以有效降低80%的处理延迟。

其次，集中控制下的高性能MCU往往需要融合多个传统ECU的功能，这也会带来一系列挑战，比如单个MCU的任务激增、混合应用调度与相关性能测量之间的相互隔离等。这就要求我们的域控ECU的底层OS要有更高的性能，要求低CPU噪底，低内存噪底，低延迟和调度的确定性，以及更好的整体易调易测能力。华为的VOS操作系统通过自主研发的轻量级协议栈、BSW多核部署机制、静态内存确定性调度设计、信息安全等技术，确保了我们数字基础基础操作系统性能的持续优化和迭代提升。

再次，在SOA软件服务的条件下，软件分为多个层次，软件模块之间的关系更加灵活复杂。除了设备抽象，我们一般考虑就近部署，其他服务模块可以灵活部署在不同ECU中的MCU上。在这里，我们需要考虑如何平衡资源效率。这里要考虑的问题很多，包括模块之间的通信频率、服务的调用关系、资源占用、功能安全的要求、CPU的负载等等。因此，软件部署是一个系统工程，需要综合考虑以上因素进行综合分析和评估，从而获得最佳的部署策略。

这里有一个例子。左图使用了简单的就近部署策略，所有软件模块都部署在四个MCU上。四个MCU的CPU利用率很不均衡，高的达到60%，低的只有22%。经过相应的部署优化，我们可以将四个MCU的CPU份额均衡在30%到40%之间。同时，部署优化后，整体通信负载也降低了14%，可以更好地提升整个平台的性能。

此外，软件分层解耦也给多个软件模块开发者之间的协作集成带来了复杂的挑战。首先，作为集成商，我们认为还是需要一个贯穿整车开发过程的端到端的工具链。在车辆设计、开发、验证过程中，行业内有很多优秀的工具，但目前各个工具链相对独立，未能有效贯穿，没有形成真正的生产力。最重要的是，上一个工具的输出可以直接做成下一个工具的输入，不需要格式修改，不需要额外的检查比较等工作量，还要考虑如何提高开发效率。

另一方面，在多方集成的过程中，各方开发代码的知识产权保护与调试过程中的共享集成之间总是存在矛盾，有时会阻碍合作开发进程。这就需要一套保护机制来限制合作者的工作和范围。最终的代码集成可以在后端或云服务器完成，使各方客户端相对独立，从而开启了基于知识产权保护的共享合作和调试集成。

最后，传统的V-model要求每一个设计变更都需要一个完整的设计、开发和验证的V-model流程。对于SOA分层解耦的软件开发，需要构建一个可分离、可分离的运行仿真模拟器的工具，可以独立开发、验证、调试各个软件模块，组合起来进行全业务、全卷软件的端到端仿真验证，做到真正的设计正确。

作为数字基础软件平台，软件版本的性能必须不断优化和迭代。OneTrack的版本是保证软件高效迭代和性能提升的必要途径，是帮助主机厂实现多车、跨车高效开发的有效保障。在实践过程中，我们也发现由于合作方式的不同，存在很多问题。比如上层的应用，有一部分是独立开发或者委托第三方开发，在开发过程中可能经常违反调用关系，直接调用下面的设备抽象，这样被认为更高效、更方便、更快捷。也适用于基于不同标准化的不同机型，因为不同厂商认为这种相互合作更快，导致了重复定制自己私有化接口的现象。如果是这样，必然无法保证数字基地平台软件OneTrack的规划、平台性能的持续优化迭代、问题的快速定位。

所以我们还是建议保持原子服务和设备抽象接口的标准化，可以在不同车型的开发过程中拔出分支，扩展相应的接口，进行开发验证。经过验证，我们需要以统一的方式合并回主干版本，形成主干OneTrack，以确保不同车型的版本匹配，以及我的数字基础软件平台的性能优化可能带来的统一升级和迭代优化的价值。

最后，综上所述，智能汽车数字基础软件平台的目标是高效、协作和开放。高效是指提供一个可扩展的、确定性的、低延迟的高速通信网络，提供一个优化以太网处理性能、匹配SOA面向服务的软件调度机制的、基于综合延迟和资源开销的、灵活部署的软件平台，以保证整个软件平台的高性能持续迭代优化。协同是将分散在设计、开发、验证工作流程中的独立工具打散，使之成为统一的端到端工具链，在尊重知识产权保护的基础上，支持高安全性CP/AP的集成。与多方合作构建可信建模验证，构建模块化、系统级仿真模型工具。开放意味着坚持标准化的接口定义，实现更多合作伙伴的共同开发。在繁荣生态的同时，搭建统一的骨干版本OneTrack，一个数字化的基础软件平台，可以帮助OEM厂商快速迭代发展。

最后，我们还是主张各行业组织加强合作，联系上下游企业共同定义、统一发布，在中汽协软件分会的领导下，发布一套最有用、最易用的软件定义的汽车级各层次API的接口标准和规范。同时，围绕分层架构和统一API接口，实现不同厂商之间的互联互通，探讨面向2C场景应用的联合创新模式，繁荣第三方生态。结合各自优势，分工协作，减少重复劳动，开放共赢，落地实践，保证质量，提升性能，共同做大智能汽车产业的蛋糕。

谢谢大家！