别嘲笑大众“弱鸡”！解析ID.3的软件智能化

ID.3这款大众MEB平台的车还没上市，就遭到德国媒体爆料有诸多的软件问题，而大众官方也没有出来辟谣。最近大众在英国发布了一些预告片，主要渲染这车的虚拟座舱、HUD和智能灯光控制，今天我们结合它的架构来探讨一下这些智能化软件组合的得失。我特别不喜欢某位仁兄写的有关唱衰它的文章，MEB这个平台虽然从三电系统上来看我们都能跟得上，但是在电子电气架构方面，很多的时候我们真的只能集中资源去尝试和摸索。

大众软件智能化水平

1） HUD视频：

视频正在加载中...

这条视频折射出的是大众的HUD特性，显示的信息很多，把大量有关ADAS交互的信息配合着内部的灯光一起，作为和车主的交互。

2） 座舱的显示：

以中控屏为核心（虽然ID.3上这块屏不是很大），是大众VW.OS的核心，它承载着整个车主和车辆的交互，同时也是和后台进行交互的关键。

目前已经可以找到一些车载应用服务器ICAS3的结构照片以及它的功能定义，这个LG Electronics提供了一些基础的软件功能，大部分大众自主开发的OS和交互软件都是以此为基础来做的。从目前来看，这有点类似第一代iPhone软件系统的OS，还需要对很多地方进行完善。

我个人理解它的问题包括——

大众把大量的车载计算平台的交互，以SOA面向服务的形式开发，原来大量的Use Case、Feature转化为Requirement，甚至做成功能逻辑都不难，但是具体到软件架构中的服务和服务接口，再转化成通信设计（以太网的参数和底层的CAN FD）在域控制器和传统ECU之间进行执行的时候，由于之前没有做过，就很难估计其复杂度。

图1 ICAS3的核心

备注：在德国媒体的爆料中，这套软件系统“道路测试每天都会上报新的问题，有数百名司机同时驾驶车辆进行路试，平均每天上报300个Bug”。有大约10000名工程技术人员在参加技术攻坚。而ID.3的硬件生产并没有受到影响，都是缺乏可用的软件系统。参加这一项目的人都认为。原定的夏季发布这款车的计划并不可行，可能会延期3~12个月，但大老板依然坚持要按原计划发布。某种意义上，大众在跨越一道鸿沟，之前大量的开发经验，特别是在ICAS1-ICAS3这三个核心的计算平台之间的软件交互，大部分Tie1旧有的经验用不上，从车企到支持的软件供应商都要一点点“打怪”，慢慢积累经验。

图2 从信号到服务，我们要刷新认知

ICAS1和ICAS2的问题

大众试图在MEB平台把车辆和人的距离拉近，不仅仅是依靠原有的PEPS这类的检测，而是可以通过用户的手机=>后台=>车，交互的内容是车辆里面大部分的服务，所以虽然ICAS1是一个车身+网关兼容的计算平台，但是里面的功能也非常多。

1） 从求全的角度考虑，以目前大众把ICAS1中设计的网关/车辆管理功能，涵盖高压电源管理、低电压能量管理、历史数据记录、疲劳识别、驾驶配置文件、剩余有效里程、实时监控等等，在权限、访问和个性化、在线个性化等等（包括车内灯光、空调和车外灯光），大众在软件服务定义的角度已经做得非常细致，但是实际在实现过程中，这套基于E2E的架构需要耗费很多的时间和精力，特别是ICAS1也有独立的网络连接功能。这些把传统车辆的功能以服务的形式和ICAS3进行交互，很大一部分是我们之前也没有经历过的。

图3 End to End架构E3

2） 有zFAS在前，在ICAS2中比之前更少的定义，说明这套ADAS其实是轻车熟路的，更多的还是在一个算力更强的平台里面实现L1和L2的各项功能，集成各种软件，我觉得这部分不会是MEB的瓶颈。

图4 zFAS的框图

小结：

我觉得我们现在不应该嘲笑大众“弱鸡”，目前我们就单个的车载计算平台的开发，也都是一点点尝试，等到我们把这些控制器组合起来，需要实现那么多的新Use Case，而所有的新客户都适应这些新的功能作为标配的时候，就轮到我们弱鸡了。

我觉得这也是当下车企在软件领域成立独立的子公司并开始进行摸爬滚打的关键阶段。有时候看这些架构、软件和基于计算平台的发展，为自己将来干什么深深忧虑，不过总是要跟着学习和进步才能跟上时代步伐。不过我确定的是对于系统工程师来说，还是可以找到自己的位置，虽然很多传统开发ECU的汽车软件工程师，想要转换到基于车载计算平台的软件开发有点困难。

作者简介：朱玉龙，资深电动汽车三电系统和汽车电子工程师，著有《汽车电子硬件设计》。

图｜朱玉龙 网络及相关截图