​ID3里面的软件智能化，ICAS1和 ICAS2的问题

01 三个视频折射的东西

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

2） 座舱的显示：以中控屏为核心（虽然这个屏不是很大），是大众 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 从信号到服务，我们要刷新认知 

02 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 的汽车软件工程师，想要转换到基于车载计算平台的软件开发有点困难。

编辑：hfy