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

2021-08-28 09:16:15来源：盖世汽车

8月26日，由盖世汽车主办的“2021行业首届智能汽车域控制器创新峰会”于上海汽车城瑞立酒店隆重召开。本次会议持续两天，将围绕智能汽车、智能驾驶域控制器、智能座舱域控制器、底盘及车身域控制器、智能驾驶计算平台、电子电气架构、软件定义汽车、车规芯片等行业焦点话题展开。会议期间，沃尔沃研发中心软件与电子高级总监谢保军发表了《沃尔沃汽车电子电气架构及中央计算介绍》的主题演讲。

沃尔沃

以下为演讲实录：

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

在讲电子电气架构之前特别说明一下，我们有整个大的数字系统架构概念，将车、云、网络、企业数字平台包括企业级数据中台、用户账号体系打通等，这是一个整体的概念。当然车的电子电气架构和基础软件平台是其中非常关键的一环。

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

再来回顾一下沃尔沃电子电气架构变革的过程，横轴是时间，纵轴是ECU数目。从90年代S80十几个ECU，到2015年我们推出XC90100多个ECU，随着功能增加，ECU数量也在飞速的增长。

这是我们现在车上使用的SPA1架构，2015年推出，非常典型的域控制器架构。什么是域呢？简单来讲就是把相近的，相关的功能整合在一起。这一代有4个域，4个域控制器，分别是信息娱乐、主动安全、底盘+发动机、车身，主干网是FlexRay，同时用了CAN、MOST、LIN以及100+ECU。

现有架构的系统复杂性。大家请看一下右图，方框是ECU，线是ECU与ECU之间的通讯，非常复杂。随着功能的增加，ECU数目的增长，这样的整体研发效率很难持续下去，我们需要作出变革。

快速看一下左边的总结，网络结构复杂，容易形成信息和数据的孤岛。为了实现功能迭代，持续增加ECU，我们国内团队在近两年这个架构上增加了3个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主要有3个重要组成, 分别是：Service, HAL,Device proxy.

我们可以对照着右边的系统架构图，简要说明一下：最上面是中央计算，以太网的主干网，VIU是网关，连接到ECU或直接连到传感器和执行器。

在中央计算中的软件分层是这样的，最上面是应用，实现车辆功能和用户功能，是通过调用service来实现。再下面就是HAL层和Device Proxy.

这样做的好处主要有两个：

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

2，支持硬件的快速升级迭代，换硬件就只要修改HAL层和Device Proxy，Application可以保持不变。

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

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

设计过程是这样的：

先看下面的灰色框图，从左往右看，涉及到的3个执行端分别是发动机，刹车和智能配电，通过VIU网关，然后是以太网。

接下来来看黄色部分，中央计算平台里的软件的设计框架，从下往上看：Device Proxy, HAL层，services, 最上面的是application, 通过读取车速，刹车和智能配电的状态，进行逻辑判断，调用engine service实现发动机的启停功能。代码实现是这样的： C++，总共6000左右行代码。应用层大概在两三百行。

我们自己的总结是：集中化的电子电气架构，中央计算平台和良好设计的基本软件平台是实现软件定义汽车的关键。能极大的提升软件开发效率。

之前一个功能往往分散在不同ECU, ECU内部的软件也是垂直打穿式的开发，变更要从Application到变到底层，大部分还会涉及到信号的变更，又会影响到其他应用。效率是很难提高的。

做OTA升级也是一样的，之前为了实现一个功能迭代，要同时升级几个ECU, 而且往往升级整个ECU软件。效率也是不高的。

接下来内容非常有趣，我们在实际开发过程中遇到的坑，也有可能是大家遇到共性的挑战，进行分享，共同启发。

App做的很厚，Service和HAL层被跳过。

左边是应该的状态，右边是就是实际遇到的一种典型的坑，app做的很厚，原本应该在service中实现的通用逻辑在多个APP中重复实现。算力浪费，无法高效的进行新功能开发，遇到硬件或信号的变化，app就需要重新写。

第二个，假的Serviec。Service并不真正提供服务，而是又绕到了APP里面进行处理。带来的问题就是APP之间间接相互依赖，功能层次混乱，数据流混乱难以理解和调试，同时这样的做法往往会造成循环依赖。

简单回顾这两个挑战，这两个典型的假SOA的做法，不难理解主要来源于我们之前开发软件的一般做法。

当然SOA架构的设计，比如怎么搭建良好的service层，非常重要，同时内部开发工具链和流程的支持也很关键。

第三个，整车级控制仍然在ECU中实现。这里举例是动力转向控制，打勾是应该的状态，动力转向控制应该在中央计算软件中实现，现实遇到的挑战还是回到了传统的做法，动力转向控制算法还是在专门的ECU中去实现，中央计算降级成了信号转发，这反映了今天大多数情况下车厂传统的合作模式。这块改善需要聚焦在整体研发效率提升，需要新的合作方式、新的商务模式。

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

这块做法是需要在搭建架构的时候就要做好功能和软件分布的设计，在这样的架构里面往往软件的分布极大程度上限定了端到端的延迟。例如分布在执行端延迟大概会在5毫秒以内，分布在区控制器延迟大概会在10毫秒以内。

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

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

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

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

我们从2012年在国内开始建立coding团队，，2018年进行大规模的Linux/C++开发。今天所有团队当中软件开发占比30-40%左右，目前来看平衡状态应该是40-50%左右。

这就是我今天分的主要内容，谢谢大家。

现场问答

周晓莺：谢总，请留步，我看还有一点点时间，看看现场有没有同学有什么问题需要请教的。

提问：谢总，您好，我是伟创力的。刚才我看PPT上面VCU已经是水冷的，请问一下这个VCU大概是什么样的架构呢？

谢保军：VCU里面有多个SOC,多个操作系统，我们第一步先把车辆相关的包括ADAS放在里面，第二步是把AD计算相关的放在里面。