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