沃尔沃谢保军：沃尔沃汽车电子电气架构及中央计算介绍

8月26日，由Gaspar主办的“2021行业首届智能汽车域控制器创新峰会”在上海汽车城瑞丽酒店举行。为期两天的会议将重点讨论智能汽车、智能驾驶域控制器、智能驾驶舱域控制器、底盘和车身域控制器、智能驾驶计算平台、电子和电气架构、软件定义的汽车和汽车仪表芯片。会议期间，沃尔沃R&D中心软件与电子高级总监谢宝军发表了题为“沃尔沃汽车电子电气架构与中央计算简介”的主题演讲。

以下为演讲实录:

大家好，我这次分享的内容主要包括三个方面:电子电气架构、中央计算平台和中央计算平台上的软件开发。架构和中央计算平台是去年共享的，所以这次我们将稍微关注一下软件开发的角度。

在讲电子电气架构之前，我们有了数字系统架构的整体概念，它连接了汽车、云、网络和企业的数字平台，包括企业数据中心和用户账户系统。这是一个整体概念。当然，汽车的电子电气架构和基础软件平台是一个非常关键的环节。

快速回顾电子电气架构趋势，集中化，集中化。软件定义汽车和SOA被提到了很多。要实现软件定义汽车，做好SOA，一个集中式的电子电气架构，一个中央计算平台，一个设计良好的基础软件平台是根本。

我们来回顾一下沃尔沃电子电气架构改革的过程。横轴是时间，纵轴是ECU的数量。从90年代的S80十几ECU到2015年的XC90 100 ecus，随着功能的增加，ECU的数量也在快速增加。

这是我们现在在车上用的SPA 1架构，是2015年推出的，是非常典型的域控制器架构。什么是域？简单来说，就是把相似且相关的功能整合在一起。这一代有四个域和四个域控制器，分别是信息娱乐、主动安全、底盘+发动机和车身。骨干网是FlexRay，也用CAN，MOST，LIN，100+ECU。

现有架构的系统复杂性。请看右图。盒子是ECU，线是ECU之间的通信，很复杂。随着功能和ECU数量的增加，R&D的整体效率很难持续，我们需要做出改变。

快速浏览一下左边的摘要。网络结构复杂，容易形成信息和数据孤岛。为了实现功能迭代，不断增加ECU，我们国内团队这两年在这个架构上增加了三个ECU。大多数情况下是由不同的供应商开发，框架和软件不能协同复用，很难统一OTA。在大多数情况下，一个用户的功能分布在几个不同的ECU中，因此经常需要协调多个ECU/供应商来更改/升级一个功能，有时不支持总线信息。ECU基本上是个黑匣子，很难支持快速的硬件迭代。

下一步做什么？我们应该做出改变，做一个新的架构，整合ECU，做中央计算。ECU集成的好处是降低成本，减轻重量，提高车辆能效，提高开发效率等等。我们自己实践中的一些有趣的发现，比如提到降低成本，很容易理解。我们可以通过简化ECU，减少线束来优化成本。同时，通过在实际中组合几个ECU，也可以在物流和装配方面带来可观的成本节约。

这是我们正在开发的SPA2架构。骨干网是以太网，核心是中央计算平台。更具体地说，我们分两步走。第一步是把域控制器和其他需要大量计算的ECU集中到中央计算。快速看一下这张图:骨干网是以太网，使用的是千兆\百兆。VIU三大网关模块的核心是简化骨干网，简化ECU，集中大量复杂的计算、用户功能和车辆……中央计算平台上的功能，以便仅通过更新中央计算平台中的软件来更新用户功能。

第二步，将网关、配电、机电控制ECU集成到区域控制器中，大大减少了ECU的数量。与第一步相比，主要有两个变化。第一个变化是将AD计算单元并入中央计算平台，第二个变化是将网关、配电、机电控制ECU集中在区控制器。什么是区域控制器？简单来说，与域控制器相比，它集成了你要关闭的功能区域，域控制器直接体现在位置上，根据位置进行配置。它主要集成了网关、配电和I/O控制。

本文简要回顾了我们的电子电气架构，然后简单介绍了核心的“中央计算平台”。

这是我们的样品B当时在实验室拍的照片，水冷散热。典型功耗60-70瓦，样本C今天的状态在右下角。

在中央计算平台的软件开发中，我们采用了面向服务的架构(SOA)。总结SOA的优势，我们可以把设备集成抽象成各种服务，使App能够创新迭代，用三个重要组件实现SOA，即服务、HAL、设备代理。

我们可以通过对比右图的系统架构图来简单说明一下:最上面是中央计算，是以太网的主干，VIU是网关，连接ECU或者直接连接传感器和执行器。

在中央计算中，软件是这样分层的。最上层是应用，通过调用服务实现车辆功能和用户功能。下面是HAL层和设备代理。

有两个主要好处:

1，做一个用户功能的快速迭代，更新这个应用就行了，其实这也是做好OTA的关键，只是OTA这个应用。

2.支持硬件的快速升级迭代。更换硬件时，只需修改HAL层和设备代理，应用程序可以保持不变。

SOA的本质是分层，抽象与解耦，软件与硬件的解耦，信号与功能的解耦，逻辑与控制的解耦。接下来我们通过一个自动启停功能开发的例子来做进一步的演示。

自动启停这是我们内训经常用到的“Hello World”。用户场景非常简单。如何在车辆临时停车节油时踩下制动踏板关闭发动机，松开制动踏板后重新启动发动机。当12V电池断电时，当车辆临时停车给电池充电时，发动机不会关闭。

设计过程如下:

先看下面的灰色框图。从左至右，涉及的三个执行终端是发动机、制动和智能配电，通过VIU网关，然后是以太网。

接下来看黄色部分，软件在中央计算平台的设计框架，自下而上:设备代理、HAL层、服务，最上面是应用，读取车速、制动、智能动力分配的状态，进行逻辑判断，调用引擎服务实现引擎启停功能。代码实现如下:C++，共约6000行代码。应用层大概两三百行。

我们自己的结论是，集中式的电子电气架构、中央计算平台和设计良好的基础软件平台是实现软件定义汽车的关键。它可以大大提高软件开发的效率。

之前的功能往往分散在不同的ECU中，ECU内部的软件也是垂直开发的。变化会从应用到底层，大部分也会涉及到信号的变化，也会影响到其他应用。效率很难提高。

OTA升级也是如此。之前为了实现一次功能迭代，要同时升级几个ECU，往往要升级整个ECU软件。效率也不高。

下面的内容很有意思。我们在实际开发过程中遇到的坑，也可能是大家遇到的共同挑战，一起分享，一起启发。

App很厚，跳过了服务和HAL层。

左边是国家…应该是，右边是实际遇到的典型坑。app很厚，本该在服务中实现的通用逻辑在多个app中重复实现。计算能力浪费，无法高效开发新功能。当硬件或信号发生变化时，需要重写app。

第二个，假服务。Service并不是真的提供服务，而是绕到APP上进行处理。带来的问题是app之间的间接相互依赖，混乱的功能层次，混乱的数据流，难以理解和调试。同时，这种方法经常导致循环依赖。

回顾这两个挑战，这两个典型的伪SOA实践，就不难理解它们主要来源于我们之前开发软件的一般实践。

当然，SOA架构的设计，比如如何搭建一个好的服务层很重要，内部开发工具链和流程的支持也很关键。

第三，整车级控制仍然在ECU中实现。这里的例子是动力转向控制。打勾才是正确的状态。动力转向控制应在中央计算软件中实现。现实中的挑战是回到传统的做法。动力转向控制算法仍然在一个专门的ECU中实现，中央计算退化为信号转发，体现了当今大多数情况下工厂的传统合作模式。这种改善需要着眼于提高整体R&D效率，需要新的合作方式和新的商业模式。

第四，特殊的低延迟要求。这里有一个ABS控制的例子。为了满足用户体验，避免振荡，需要将端到端延迟控制在10毫秒以内。按照右图典型的中央计算实现方式，端到端链路比较长，软件放在中央计算平台上实现控制算法，很难保证或者基本实现10毫秒以内的延迟。

这种方法需要在构建架构时设计功能和软件分布。在这样的体系结构中，端到端延迟通常受到软件分布的限制。例如，分布在执行端的延迟将在5毫秒内，分布在区域控制器的延迟将在10毫秒内。

简单总结一下，我们一路走来遇到了很多挑战，包括技术实现、组织架构、与供应商和合作伙伴的合作商业模式，一路走来还有很多挑战。

最后，介绍一下我们在中国的平台核心开发团队。做这个需要非常强的内部能力，内部软件开发和内部硬件参考设计能力。

一个新的工具链，一个新的流程，一种新的工作方式/就是向我们经常提到的高科技公司和“软件公司”转型。

做软件开发往往靠人数很难实现。这就像跳高，其中架构是关键，敏捷的工作方法非常重要。其中，我们特别提到持续集成和自动化测试的能力。

2012年开始在国内组建编码团队，2018年将进行大规模的Linux/C++开发。今天，软件开发约占所有团队的30-40%。目前余额应该在40-50%左右。

这是我今天要点的主要内容，谢谢。

现场问答

周晓颖:谢先生，请留步。我觉得还有一点时间，看看现场有没有同学需要提问。

问题:谢先生您好，我是伟创力的。刚才我看到PPT上的VCU已经水冷了。这个VCU是什么样的建筑？

谢宝俊:VCU有多个SOC和多个操作系统。第一步是把车辆相关的ADAS放进去，第二步是把AD计算相关的放进去。

问题:我是比亚迪的。刚才PPT提到了延迟。延迟解决方案是什么样的？

谢宝俊:不同的场景其实有不同的解决方案。例如，有几种ABS控制算法。你可以把控制算法放在执行端或区域控制器中。这是惯例，这个可以控制在5毫秒内。

问题:我想问一下，在这个设计过程中，如何平衡偏执端的区域控制器、马达灯等执行机构功能，比如哪些执行环节放在t……区域控制器和哪些留在底部？

谢宝俊:2018年我们做这个规划的时候，是比较理想的。科学和工程人员都想把它放在一起，但经过这么多坑，我们发现我们仍然必须考虑R&D效率和新的商业模式。刚才说的转向算法和刹车算法都是在执行端考虑的。

问题:我问一下，以前供应商做的汽车里面有很多控制量和测试算法。想自己做还需要从头开发这个算法吗？

谢宝俊:其实自己做没什么意义。比如你可以自己做刹车算法，但是做整体的R&D效率和业务逻辑没有意义，所以更多的是合作和整合。

问题:这个过程还是需要供应商的配合，对吧？

谢宝俊:对，这一块主要考虑商业模式和合作模式。8月26日，由Gaspar主办的“2021行业首届智能汽车域控制器创新峰会”在上海汽车城瑞丽酒店举行。为期两天的会议将重点讨论智能汽车、智能驾驶域控制器、智能驾驶舱域控制器、底盘和车身域控制器、智能驾驶计算平台、电子和电气架构、软件定义的汽车和汽车仪表芯片。会议期间，沃尔沃R&D中心软件与电子高级总监谢宝军发表了题为“沃尔沃汽车电子电气架构与中央计算简介”的主题演讲。

以下为演讲实录:

大家好，我这次分享的内容主要包括三个方面:电子电气架构、中央计算平台和中央计算平台上的软件开发。架构和中央计算平台是去年共享的，所以这次我们将稍微关注一下软件开发的角度。

在讲电子电气架构之前，我们有了数字系统架构的整体概念，它连接了汽车、云、网络和企业的数字平台，包括企业数据中心和用户账户系统。这是一个整体概念。当然，汽车的电子电气架构和基础软件平台是一个非常关键的环节。

快速回顾电子电气架构趋势，集中化，集中化。软件定义汽车和SOA被提到了很多。要实现软件定义汽车，做好SOA，一个集中式的电子电气架构，一个中央计算平台，一个设计良好的基础软件平台是根本。

我们来回顾一下沃尔沃电子电气架构改革的过程。横轴是时间，纵轴是ECU的数量。从90年代的S80十几ECU到2015年的XC90 100 ecus，随着功能的增加，ECU的数量也在快速增加。

这是我们现在在车上用的SPA 1架构，是2015年推出的，是非常典型的域控制器架构。什么是域？简单来说，就是把相似且相关的功能整合在一起。这一代有四个域和四个域控制器，分别是信息娱乐、主动安全、底盘+发动机和车身。骨干网是FlexRay，也用CAN，MOST，LIN，100+ECU。

现有架构的系统复杂性。请看右图。盒子是ECU，线是ECU之间的通信，很复杂。随着功能和ECU数量的增加，R&D的整体效率很难持续，我们需要做出改变。

快速浏览一下左边的摘要。网络结构复杂，容易形成信息和数据孤岛。为了实现功能迭代，不断增加ECU，我们国内团队这两年在这个架构上增加了三个ECU。大多数情况下是由不同的供应商开发，框架和软件不能协同复用，很难统一OTA。在大多数情况下，一个用户的功能分布在几个不同的ECU中，因此经常需要协调多个ECU/供应商来更改/升级一个功能，有时不支持总线信息。ECU基本上是个黑匣子，很难支持快速的硬件迭代。

下一步做什么？我们应该做出改变，做一个新的架构，整合ECU，做中央计算。ECU集成的好处是降低成本、重量……减量、车辆能效提升、开发效率提升等等。我们自己实践中的一些有趣的发现，比如提到降低成本，很容易理解。我们可以通过简化ECU，减少线束来优化成本。同时，通过在实际中组合几个ECU，也可以在物流和装配方面带来可观的成本节约。

这是我们正在开发的SPA2架构。骨干网是以太网，核心是中央计算平台。更具体地说，我们分两步走。第一步是把域控制器和其他需要大量计算的ECU集中到中央计算。快速看一下这张图:骨干网是以太网，使用的是千兆\百兆。三大网关模块VIU的核心是简化骨干网络，简化ECU，将大量复杂的计算、用户功能、车辆功能集中到中央计算平台，只需更新中央计算平台中的软件即可更新用户功能。

第二步，将网关、配电、机电控制ECU集成到区域控制器中，大大减少了ECU的数量。与第一步相比，主要有两个变化。第一个变化是将AD计算单元并入中央计算平台，第二个变化是将网关、配电、机电控制ECU集中在区控制器。什么是区域控制器？简单来说，与域控制器相比，它集成了你要关闭的功能区域，域控制器直接体现在位置上，根据位置进行配置。它主要集成了网关、配电和I/O控制。

本文简要回顾了我们的电子电气架构，然后简单介绍了核心的“中央计算平台”。

这是我们的样品B当时在实验室拍的照片，水冷散热。典型功耗60-70瓦，样本C今天的状态在右下角。

在中央计算平台的软件开发中，我们采用了面向服务的架构(SOA)。总结SOA的优势，我们可以把设备集成抽象成各种服务，使App能够创新迭代，用三个重要组件实现SOA，即服务、HAL、设备代理。

我们可以通过对比右图的系统架构图来简单说明一下:最上面是中央计算，是以太网的主干，VIU是网关，连接ECU或者直接连接传感器和执行器。

在中央计算中，软件是这样分层的。最上层是应用，通过调用服务实现车辆功能和用户功能。下面是HAL层和设备代理。

有两个主要好处:

1，做一个用户功能的快速迭代，更新这个应用就行了，其实这也是做好OTA的关键，只是OTA这个应用。

2.支持硬件的快速升级迭代。更换硬件时，只需修改HAL层和设备代理，应用程序可以保持不变。

SOA的本质是分层，抽象与解耦，软件与硬件的解耦，信号与功能的解耦，逻辑与控制的解耦。接下来我们通过一个自动启停功能开发的例子来做进一步的演示。

自动启停这是我们内训经常用到的“Hello World”。用户场景非常简单。如何在车辆临时停车节油时踩下制动踏板关闭发动机，松开制动踏板后重新启动发动机。当12V电池断电时，当车辆临时停车给电池充电时，发动机不会关闭。

设计过程如下:

先看下面的灰色框图。从左至右，涉及的三个执行终端是发动机、制动和智能配电，通过VIU网关，然后是以太网。

接下来看黄色部分，软件在中央计算平台的设计框架，自下而上:设备代理、HAL层、服务，最上面是应用，读取车速、制动、智能动力分配的状态，进行逻辑判断，调用引擎服务实现引擎启停功能。代码实现如下:C++，共约6000行代码。应用层大概两三百行。

我们自己的结论是，集中式电子电气档案……cture、中央计算平台和设计良好的基础软件平台是实现软件定义汽车的关键。它可以大大提高软件开发的效率。

之前的功能往往分散在不同的ECU中，ECU内部的软件也是垂直开发的。变化会从应用到底层，大部分也会涉及到信号的变化，也会影响到其他应用。效率很难提高。

OTA升级也是如此。之前为了实现一次功能迭代，要同时升级几个ECU，往往要升级整个ECU软件。效率也不高。

下面的内容很有意思。我们在实际开发过程中遇到的坑，也可能是大家遇到的共同挑战，一起分享，一起启发。

App很厚，跳过了服务和HAL层。

左边是应该的状态，右边是实际遇到的典型坑。app很厚，本该在服务中实现的通用逻辑在多个app中重复实现。计算能力浪费，无法高效开发新功能。当硬件或信号发生变化时，需要重写app。

第二个，假服务。Service并不是真的提供服务，而是绕到APP上进行处理。带来的问题是app之间的间接相互依赖，混乱的功能层次，混乱的数据流，难以理解和调试。同时，这种方法经常导致循环依赖。

回顾这两个挑战，这两个典型的伪SOA实践，就不难理解它们主要来源于我们之前开发软件的一般实践。

当然，SOA架构的设计，比如如何搭建一个好的服务层很重要，内部开发工具链和流程的支持也很关键。

第三，整车级控制仍然在ECU中实现。这里的例子是动力转向控制。打勾才是正确的状态。动力转向控制应在中央计算软件中实现。现实中的挑战是回到传统的做法。动力转向控制算法仍然在一个专门的ECU中实现，中央计算退化为信号转发，体现了当今大多数情况下工厂的传统合作模式。这种改善需要着眼于提高整体R&D效率，需要新的合作方式和新的商业模式。

第四，特殊的低延迟要求。这里有一个ABS控制的例子。为了满足用户体验，避免振荡，需要将端到端延迟控制在10毫秒以内。按照右图典型的中央计算实现方式，端到端链路比较长，软件放在中央计算平台上实现控制算法，很难保证或者基本实现10毫秒以内的延迟。

这种方法需要在构建架构时设计功能和软件分布。在这样的体系结构中，端到端延迟通常受到软件分布的限制。例如，分布在执行端的延迟将在5毫秒内，分布在区域控制器的延迟将在10毫秒内。

简单总结一下，我们一路走来遇到了很多挑战，包括技术实现、组织架构、与供应商和合作伙伴的合作商业模式，一路走来还有很多挑战。

最后，介绍一下我们在中国的平台核心开发团队。做这个需要非常强的内部能力，内部软件开发和内部硬件参考设计能力。

一个新的工具链，一个新的流程，一种新的工作方式/就是向我们经常提到的高科技公司和“软件公司”转型。

做软件开发往往靠人数很难实现。这就像跳高，其中架构是关键，敏捷的工作方法非常重要。其中，我们特别提到持续集成和自动化测试的能力。

2012年开始在国内组建编码团队，2018年将进行大规模的Linux/C++开发。今天，软件开发约占所有团队的30-40%。目前余额应该在40-50%左右。

这是我今天要点的主要内容，谢谢。

现场问答

周晓颖:谢先生，请留步。我想还有一点时间来看看是否有……e现场任何需要提问的同学。

问题:谢先生您好，我是伟创力的。刚才我看到PPT上的VCU已经水冷了。这个VCU是什么样的建筑？

谢宝俊:VCU有多个SOC和多个操作系统。第一步是把车辆相关的ADAS放进去，第二步是把AD计算相关的放进去。

问题:我是比亚迪的。刚才PPT提到了延迟。延迟解决方案是什么样的？

谢宝俊:不同的场景其实有不同的解决方案。例如，有几种ABS控制算法。你可以把控制算法放在执行端或区域控制器中。这是惯例，这个可以控制在5毫秒内。

问题:我想问一下，在这个设计过程中，你是如何平衡偏执端的区域控制器和马达灯等执行机构功能的，比如哪些执行环节放在区域控制器里，哪些留在底部？

谢宝俊:2018年我们做这个规划的时候，是比较理想的。科学和工程人员都想把它放在一起，但经过这么多坑，我们发现我们仍然必须考虑R&D效率和新的商业模式。刚才说的转向算法和刹车算法都是在执行端考虑的。

问题:我问一下，以前供应商做的汽车里面有很多控制量和测试算法。想自己做还需要从头开发这个算法吗？

谢宝俊:其实自己做没什么意义。比如你可以自己做刹车算法，但是做整体的R&D效率和业务逻辑没有意义，所以更多的是合作和整合。

问题:这个过程还是需要供应商的配合，对吧？

谢宝俊:对，这一块主要考虑商业模式和合作模式。

标签：沃尔沃发现比亚迪

汽车资讯热门资讯