软件定义智能汽车带来了体验的提升，复杂度的提升，同时迭代速度也越来越快。在此背景下，2024年3月14日，在2024第五届软件定义汽车论坛暨AUTOSAR中国日上，华为智能汽车解决方案BU平台软件技术规划专家徐艳琴坦言，推动车型的平台化和软件架构的服务化是未来智能化、数字化、软件定义的基础。但落地过程中，首先需要统一的服务化软件架构；其次架构要更解耦、更灵活，有利于行业分工合作，实现高效工作。最终目的是实现多车型的高效发布，做到车型平台化。

徐艳琴分享了华为对各环节的不同需求并分别提出了解决方案。同时她表示，作为特级合作伙伴，华为积极参与AUTOSAR标准工作，而AUTOSAR作为SDV生态一环，还要加强与产业组织、区域组织的协同，共同推进智能网联汽车产业的发展，推动整车服务化生态。

华为智能汽车解决方案BU平台软件技术规划专家

以下为演讲内容整理:

服务化架构趋势

随着智能汽车时代的到来，用户对汽车使用体验的需求不断提升，从单一的驾驶体验逐渐转变为第三生活空间体验。这一空间不仅包括了娱乐体验，还涵盖了诸如午休模式、露营模式甚至私人影院等个性化需求。这意味着汽车发布周期和迭代速度需要不断加快，以满足消费者不断变化的期待。

与传统燃油车时代相比，智能汽车时代的车型发布周期已经大大缩短，从原来的一两年缩短到更短的周期。这对车辆的软硬件架构和平台化提出了巨大挑战。如何确保服务体验的持续升级以及软件迭代的安全可靠性成为我们长期需要解决的关键问题。

我们正在经历着电子EEA架构的演进，从以前的全分布式独立ECU架构逐步转变为部分功能升级至更高算力的域控制器。随着车型平台化的实现，我们迫切需要底层区域接入，以实现底层硬件IO与计算中心或域控制器上的计算解耦，这一需求推动着架构的不断演进。

图源:演讲嘉宾素材

随着上层集中的域控制器算力不断增强，甚至可能演变为中央计算，我们需要确保新特性和应用能够更好地独立开发和升级，更加灵活地应对变化。因此，大家普遍认为，将软件架构服务化是必然的趋势。

在推动车型平台化和软件架构服务化的过程中，我们的思路是首先达成统一的服务化软件架构，希望在业界形成共识。我们需要将底层与计算解耦的设备抽象化，并在区域接入控制中实现IO设备和原子服务的抽象化，逐步实现接口标准化。

这样一来，底层车型便能够与硬件解耦，而上层则能够利用服务化架构，实现与平台以及上层应用和特性升级的解耦。服务化和标准化的目标是应当前新的分工合作模式，满足不同供应商和OEM之间的合作需求和分工合作模式的差异，使架构更加解耦、灵活，从而提高各方的合作效率。最终目标是实现多车型快速迭代的高效发布，从几年的周期缩短至月级甚至周级发布基础软件。整体目标是实现车型的平台化。

尽管在过去几年中服务化架构一直备受关注，但在实际落地过程中，我们发现不同项目可能会采取不同的方式。这是因为车载软件已经拥有相对成熟完善的功能，对安全可靠性有所保证。因此，针对底层IO与计算解耦的服务化落地，会根据不同项目或不同阶段采用多种方式。

进一步而言，我们的目标是实现全服务化的架构，将底层与车型或硬件解耦的原子服务和抽象服务进行整体服务化。希望上层应用开发方也能与基础软件解耦，能够独立开发和升级，使服务化更加彻底。

AUTOSAR服务化落地

在我们全副武装的落地过程中，我们面临了几个挑战。我们提出了分层解耦的思路，因为我们已经积累了几年的量产经验，多车型适配和快速配置是强烈的需求。我们希望在这个过程中，仅需要配置底层车型的差异，而中间的原子服务和IO设备抽象能够接口标准化和统一，可以复用到多个车型。上层体验和跨域应用的开发不需要关注底层平台或硬件是哪种车型，只需根据原子服务需求进行灵活组装。在做多车型适配时，我们希望实现“两个不变一个变”的目标。

图源:演讲嘉宾素材

具体到落地过程中和软件架构设计的思路和方法论，我们与以往不同。以前的软件设计是自上而下的，从整车功能开始定义设计，然后逐步分解到独立的ECU，再逐步开发应用和基础软件集成。然而，对于智能车而言，对新功能和新体验的跨域服务定义最初并不是固定的，在过程中会逐步迭代，功能体验的定义贯穿整个项目过程或后续车型生命周期。

与此同时，我们在底层平台或者平台供应商方面仍在思考如何将底层从下至上完善为一个完整的平台化中间件层。在这个过程中，我们会继续完善例如从上到下的功能定义、服务设计以及从上到下的平台服务开发定义等方面。

华为与SDV标准委员会合作推进了中间服务API接口的标准化，目前已发布了第四版，在多家OEM和合作伙伴中已经有量产应用。

面向智能车和软件定义以及应对车型快速发布的需求，我们希望架构能够实现车型平台化和软件架构服务化。我们在落地过程中发现了四个现象。

第一，由于MCU侧域的集中，MCU算力越来越强，上面的应用由多家厂家开发，在开发过程中面临与基础软件以及平台供应商的交互。

第二，多车型中一些功能保持不变的软件是否可以复用，这样平台软件团队就可以快速将其复制到多个车型中。这也是华为BU平台致力于解决的问题，因为我们没有足够的能力为每个车型定制开发软件。

第三，我们现在在服务化方面取得了进展，MPU侧的服务也越来越多，AP服务化通信配置项目增多。

第四，设计开发工具涉及多个厂家，强调多人协作。

提升方案

首先，我们需要理解配置项之间的差异很大，而且这么多的配置项实际上是相当复杂的。在这个过程中，一方面，我们需要进一步优化AP工具，尽量多地结合场景或项目，优先生成自动化的配置，并考虑前端工具与开发方式的兼容性，自动地导入到模型化的项目工程中，这也是另一个兼容性方面的思路。我们也在不断扩大Autosar的培训或生态系统，这实际上也是解决问题的一种方法。同时，我们也希望在这个过程中逐步优化，并考虑在整车服务化过程中如何精简AP，包括简化开发验证流程时面对不同角色的服务开发角色定义。

最后分享我们对于AUTOSAR的设计开发工具的经验。之前AUTOSAR的模型化工具链，从整车网络设计、服务化设计到软件架构设计，还有OS基础配置工具和行为建模工具，都是从零开始构建的，在服务化项目落地过程中，当服务设计发生变更时，我们通常通过人工同步或文件同步来通知下游和其他方进行相关变更的同步。这种效率非常低，很难保证变更的一致性和可追溯性。

我们的工具团队也在努力打通从上到下的数据流，针对服务化开发，数据能够自动同步，变更能够自动推送。这涉及到纵向断裂，即工具链之间的断裂。横向方面，我们在底层平台服务的开发过程中，也有多个团队协同合作。然而，在MCU侧，这些团队之间为了进行变更，目前还无法像平时编写代码那样自动提交，只能商议后再进行提交，这显然效率非常低。因此，我们提出了协同机制，希望实现像代码提交一样的功能，从而完善AUTOSAR工具的工作流程。

在华为的服务化项目中，我们已经实现了端到端的流和平台的打通。当然面对与第三方、OEM和其他合作方协同开发应用和服务时，我们需要进一步提高协作效率，解决工作流程的打通问题。

自2018年起，华为开始加入AUTOSAR组织并投入相关方向。早在2003年和2004年AUTOSAR成立之初，华为就已经参与其中，重点关注智能车和智能化部件。我们最初关注的是AP的第一个版本，并积极参与了标准的制定。我们的贡献和关注方向主要集中在两个方面:一是互联互通，作为部件和解决方案供应商，我们注重与第三方的协同合作。另一个方面是系统资源的确定性和安全架构，考虑到我们自研的操作系统和基础软件。

图源:演讲嘉宾素材

在参与项目中，我们发现虽然AUTOSAR社区在2018年已经引入了DDS的标准，我们的首个AP版本也支持自研和DDS，然而当我们要与CP进行互通时，发现CP没有DDS的生态。我们希望能够复用DDS的能力，但自己无法将其集成到CP中。如果整个生态还不成熟，DDS的互通生态就无法推广。因此，我们考虑推动该标准的落地，并在2022年的标准版本中实现了这一目标。

针对未来的智能驾驶与互联生态，AUTOSAR目前仅关注了车内的一部分，但其态度非常开放。我们注意到AUTOSAR周边的开源组织，它们提供了一些信号服务和服务接口的定义。此外，我们也希望探索未来云原生车辆和云对等架构的验证，以推动智能驾驶车辆的生态发展。我们持续关注这些领域，并希望借助华为在IT或ICT领域的技术，将其应用到车载场景中，从而推动智能驾驶生态的进一步发展。