上汽大众何晓晓：车身域控制器开发实践

8月26日，由盖世汽车主办的“2021行业首届智能汽车域控制器创新峰会”于上海汽车城瑞立酒店隆重召开。本次会议持续两天，将围绕智能汽车、智能驾驶域控制器、智能座舱域控制器、底盘及车身域控制器、智能驾驶计算平台、电子电气架构、软件定义汽车、车规芯片等行业焦点话题展开。会议期间，上汽大众资深主管工程师何晓晓发表了《车身域控制器开发实践 》的主题演讲。

上汽大众资深主管工程师 何晓晓

各位好，今天我给大家带来的题目是《车身域控制器开发实践》。

目前上汽大众推出了ID.6X和ID.4X车型，本周成都车展也会全新亮相ID.3（参数丨图片）X。在新的平台上面我们有智选充电系统，通过智能手机和智能手表实时查看电量情况，同时上汽大众超级APP同时支持90%充电桩的便捷支付。

此外还有智趣出行系统，车机可以变成家电摇控器，远程控制智能家电，并且可以实现开闭功能。另外，我们还独创的Light可以实现智能光语和人机对话的双重反馈，增加了科技的氛围感。还有基于L2+驾驶辅助系统，大家有兴趣可以去4S店和体验店进行体验。

今天我会分五个方面进行讲解。

一、MEB架构的愿景：

按照传统的定义来说，我们一直认为汽车是一个交通工具，它的主要目的就是将我们从一个地方运送到另外一个地方，汽车跟我们数字生活是完全不相干的，就像十几年前，手机只是打电话的工具。但是到了新四化的今天，智能座舱和智能交互使用，汽车也越来越成为我们数字生活的一部分。

为了满足这个要求，对于新的架构来说希望能有四个方面的突破。1、功能多样性。2、私人化定制。3、个性化设置。4、可升级性。

功能多样性，简单理解就是在不同的配置车上面或者不同车型上面尽量开通更多的功能。

私人定制化简单来讲就是在硬件配置的情况下客户可以自由选择开通或者关闭某些功能，客户可以在手机APP上面自主选择某些功能。

个性化设置就是把可以选用的功能和驾驶员账户绑在一起，传统的比如说座椅位置，后视镜的位置，方向盘的位置和驾驶员的账户绑定，以后的香氛系统和智能氛围灯以及其他的设置偏好也会和驾驶员账户绑定在一起。

可升级性，大众提出了在全生命周期过程（DLCM）中软件会实时更新，做到新的功能可以在车上面进行升级，让用户更多体验到稳定的，功能越来越多的车身域控制。

二、基于Adaptvie Autosar 的SOA架构

MEB的电子电器架构平台为E3架构，目前为E3 1.1。所谓E3，即有三端：传感器/执行器端，主要基于CP开发，用于感知驾驶员的操作和环境变化，并相应ICAS端的控制指令对执行器进行操作；ICAS端，主要基于AP开发，由网关、基础服务和应用构成，ICAS目前主要提供了6种基础服务，比方说在线服务，能源管理，车辆基本信息等；云端就是执行云端的操作。

集中式功能架构，将应用软件与I/O功能解耦，降低了系统复杂性，传感器/执行器与ICAS之间没有功能依赖性，提供了添加新功能和功能更新的灵活性。

我们说SOA是域控制器实现的关键。软件层分为基础软件和软件框架，上面是应用层与服务，整个SOA架构本身有几个特点，1、面向服务的通讯方式。2、使用服务发现和发布/订阅的动态绑定。3、主要基于REST的数据表示方式，它是一种统一的接口，无状态，关注点分离等。4、接口的前后兼容性。

整个SOA架构主要实现新功能的即插即用，增强了系统的可更新性，可升级性，可重复性和可移植性。

AP是域控制器实现的途径，可以使客户功能/基础服务的开发独立于硬件和操作系统，和供应商之间有一支的开发方法论和交换格式，还有标准的升级和通讯协议。

这是ICAS软件架构图，CP部分主要处理实时性要求高，但计算量要求低的功能。AP部分主要处理实时性要求低，但计算量要求高的功能，比如说即插即充功能（PnC），在线服务功能。AP和CP之间通过ComServer传递信息，未来在E3 2.0的时候会加入VW OS或者IoT Edge功能。

刚才提到了它是面向服务的通讯。ICAS主要使用了两种协议：Viwi，RESTful微服务架构，使用JSON、HTTP、TLS，针对分布式服务的灵活协议，针对在node.js或其他Web服务容器或基于Html5的HMI元素中运行的应用。（烦请何总看下里面的英文词汇是否有误）

安全方面主要是TLS和DTLS。完成通讯认证和通讯加密的功能，另外SecOC的应用，保证了通讯的真实性。

使用VLAN技术使网络分成三个部分，外部可访问网络，主要是LTE、Wifi、BT、OBD等。另外还有两个内部网络，一般安全防护和高安全防护。

三、ICAS1介绍

前面讲了ICAS软件架构，我们看一下ICAS1，目前E3 1.1可以看到有两个控制器，ICAS1是车身域，ICAS3是娱乐域，ICAS2还在开发当中。

这是我们实际使用ICAS1零件，目前支持9路高速CAN，6路LAN，3路千兆和10路百兆以太网。

这是截止到欧洲ID3投产时的统计，一共有7万条需求，供应商投入800多开发人员，和ICAS1相关控制器68个，开发场所遍及欧洲13个地方，涉及软件公司19家，统计完之后的代码超过2000万条。

四、域控制器开发实践

这么庞大的系统如果基于传统的瀑布式开发是很难想象的，需求很难定义清楚，开发周期也没有办法保证，最后我们选择基于敏捷式的开发，基于增量式的交付迭代式的过程。

对于这么大的庞大系统来说有两个要求，一个是需要有强有力的开发工具链，第二是OEM和供应商合作需要到达新的水平。

这是供应商内部的框架，现在使用的是SAFe大规模敏捷框架，主要分三个部分：第一部分提供业务解决方案以及精细化系统。第二部分是项目，主要通过敏捷释放火车（Agile Relase Train，简称为ART）来完成，目前有三个部分：第一是基于传统CP ART。第二是AP RAT，第三是应用程的ART。第三部分是team，主要是完成团队的管理和技术敏捷性。这里主要针对的是应用的ART，目前分为8个敏捷开发团队，未来有可能会增加到15个敏捷的团队。

至于OEM和供应商之间怎么协作？针对敏捷开发来说，首先根据整车需求进行讨论，在10-12周里面定义优先级，选择优先级高的优先完成，整个冲刺时间差不多是10-12周，基本上现在以每两周一版迭代，每个周期仍以V模型的方式开发，最终供应商进行交付，总结和开展下一个周期的工作。

ICAS1还涉及到第三方软件协同，这里主要是开放了一个平台，这个平台里面有JIRA和其他软件，交付问题分享工具。具体来说对于Software module进行提交，Tierl-1持续的集成，测试和交付，交付完之后会提交软件和KPI报告，分发到这个平台上面，再通过这个平台把这些信息又传递给之前提交过软件的第三方。

五、总结：

总结一下，目前ICAS1目前还是以两周一版软件的速度在迭代，我们目前是希望在产品生命周期里面让客户能够体验到更稳定，功能更多的软件。车身域控制的开发需要OEM与供应商之间的协作，只有这样的合作到达一定的高度，我们才能作出更好的产品，谢谢大家。