8月26日，由盖世汽车主办的“2021行业首届智能汽车域控制器创新峰会”于上海汽车城瑞立酒店隆重召开。本次会议持续两天，将围绕智能汽车、智能驾驶域控制器、智能座舱域控制器、底盘及车身域控制器、智能驾驶计算平台、电子电器架构、软件定义汽车、车规芯片等行业焦点话题展开。会议期间，上汽零束软件分公司基础软件平台专家曾杰男发表了《云管端一体化中央计算平台解决方案》的主题演讲。

零束,域控制器

以下为演讲实录：

大家好，我来自上汽零束，今天大会主题是域控制器，这个话题本身其实并不局限在域控制器，我们也从智能汽车的角度跟大家做一个分享，抛砖引玉，分享一些我们的看法和想法，希望大家一起探讨，共同进步。

软件定义汽车已经是行业共识，在软件定义汽车场景下，关键之一是要做数字化转型，对于智能汽车而言，数字化转型有三个方面的需求：

一、满足千人千面的用户需求。当今社会有一句话“个性当道，品质为王”，“个性当道”其实就是千人千面的需求，在当今这个社会如果你的产品一成不变，产品高度雷同，类比手机，如果只是完全一样的功能堆砌，用户其实是不会买单的，也不符合用户对于智能汽车智能的想象。

二、用户体验持续进化。这是从“品质为王”角度来谈的，我们认为智能汽车已经不一样了，它的品质不再局限于狭义的质量，以前一辆车开不坏，没什么小毛病，我们说质量很好，但现在一辆智能汽车达到这个程度，能说品质很好吗？其实不能的。打个比方，中控操作逻辑比较奇葩，语音体验比较差，这个情况下可能硬件质量很好，但是不能说它的品质很好。

三、车辆主动感知，主动决策。零束愿景就是让车成为有生命力的人类伙伴，既然是伙伴，那自然不是工具，只有工具才是被我们被动的使用，伙伴是需要有主动感知和主动决策的能力。

对于传统汽车来说，这三点需求能够实现吗？答案是不能的。因为我们现在最大瓶颈在于现在电子电气架构是孤岛式的电子电气架构，这种架构里面基本上每个控制器功能都是固定的，你想要一个车在不同的用户那儿呈现不同的功能状态是很难的。

其次说用户体验的持续迭代更新，即便说可以做到OTA，做到整车更新，但如果说用户需求来了，你相应的更改是需要在各个域上的多个控制器上去修改，各个控制器可能来自于不同的供应商，这个时候整个软件研发，测试，部署的周期可能会超过20个月，就难以满足用户体验持续进化的需求。

另外说主动感知和决策，主动的前提是什么？主动的前提是能够收集用户数据进行分析，进行自我学习，一个很重要的背景是联合云端一起做这个事，因为车端算力是有限的，车端存储也是有限的，传统架构和车外生态之间的壁垒限制了它的实现。

要解决刚刚三个需求需要达到什么样状态？我们认为，第一、在硬件层面上，分布式到中央集中式的转变，有一个中央集中式计算平台提供算力基础。第二、云管端一体化SOA软件平台实现软硬解耦，快速迭代，数据平台实现数据闭环和自我分析自我进化。第三、端到端用户体验，必须建立一个生态，去实现端到端的用户体验，才能对用户体验进行持续的进化和持续的改进。

零束提供的解决方案是全栈，目前处在全栈1.0阶段，在今年年底我们会进行量产，主要是做域集中和部分域融合，在2023年会量产全栈3.0方案，在这个方案里面就会走到整车计算中心再加区域控制器。

具体看一下3.0架构的相关信息，首先硬件平台方面，我们的方案是2个高性能计算单元HPC1和HPC2，再加4个区域控制器，HPC里面实现智能驾驶、智能座舱、智能计算、智能驾驶备份等功能，4个区域控制器中去实现各自不同区域的相关功能。这个硬件架构是比1.0更加集中的硬件方案，当然这个方案对于芯片算力会有更高的要求。

这是硬件部分，但光有硬件还是不够的，硬件算力再高，如果软件不支持快速迭代，不支持云端打通，用户体验的持续更新也是不可能实现的，所以软件方面的解决方案是云管端SOA一体化软件平台，我们的软件平台能够实现和硬件芯片和操作系统，也就是和我们架构之间的解耦。1.0平台芯片和3.0平台芯片不一样，上面操作系统也会不一样，这个时候软件平台是能够直接平移过来使用，也就是我们做到了让应用开发人员开发出来的应用，不管你这个车是1.0架构、3.0架构或者1.0架构之间不同车型都能够直接使用。

为了做到这一点需要对软件进行分层，最下面是硬件芯片，在它之上会有Hypervisor虚拟化，虚拟化主要是解决在一个芯片上实现硬件隔离和实现资源共享，在虚拟化之上会有各种异构操作系统，我们目前认为异构操作系统仍然是很长一段时间之内的一个选择。在异构操作系统之上就是中间件层和SOA服务层。操作系统是为了隔离芯片和软件，通过操作系统可以让我们的软件开发不用关心使用的芯片是什么。但是板上的驱动或者车内各种信号，这些东西仍然不会标准化。比如说一个应用要用到一个信号，这个信号可能在不同的车型上会发生变化，你这个应用就不能使用了，这是传统情况下应用没有办法复用的很大的原因。

这就是中间件和SOA原子服务这两层要做的，目的就是要向上提供统一的标准API接口。当然原子化服务还能提供任意组合的好处，组合出你自己想要的功能，这样可以实现应用功能的千变万化。

再上面是应用层，实现不同场景下的应用。这个应用开发光靠OEM一家自己来做是不够的，仅仅自己来做，OEM人力有限，能做的应用也有限，所以我们希望通过标准API加上软件平台SDK，让OEM、供应商、第三方开发者和用户都加入到应用开发中间来，共创应用生态。针对不同程度的开发者提供的工具会不一样。针对最普通的用户或者极客，他们软件开发能力是有限的，我们给它提供的是Z-ONE Maker图形化界面，简单拖拽就可以实现场景应用的开发，对于有一定软件能力的第三方开发者提供Z-ONE Studio Lite，可以通过简单编程加图形化调试的方式快速开发出轻型的应用，针对OEM和供应商而言提供的是Z-ONE Studio，它是一个完整的软件开发IDE。

整个软件平台有两个特点，第一个是快，T+0+1+7，Z-ONE Maker开发的场景T+0上线，Z-ONE Studio Lite开发的轻应用T+1上线，Z-ONE Studio开发的服务和应用T+7上线，真正可以实现快速迭代、快速进化，第二个是变，千人千面，对车上的传感器和硬件进行抽象，我们目标是把整车数字化，数字化之后形成原子化的SOA服务，再通过应用开发的方式把原子化服务组合起来，实现出千变万化不同的应用。

以上我们第一个说的是硬件，第二个说的是软件平台，硬件给我们提供了算力基础，让我们有可能在上面做更多的算法，去做更多的功能。软件平台方面，则可以让你通过软件和底下硬件平台的解耦实现应用的复用，可插可拔，可以吸引更多开发者共同创建这个生态。

如果仅仅只有这些我们认为仍然不能实现智能汽车所需要的三个需求。为什么呢？因为最终是要基于硬件软件实现生态，通过这个生态让用户能有跨域、融合和多维度的体验。

如果说你没有建立手机端到座舱无缝连接，没有打造以用户为中心的生态系统，没有围绕车间里互联网生态系统，那么你开发出来的功能和应用真的可以迭代吗？我们认为是不能的。比如说在我们传统的相机时代，相机的拍摄质量普遍是超过手机的，但为什么大家最终放弃相机，而用手机拍照？因为相机拍出来的照片要把它导出来再发到朋友圈展示，是很麻烦的，而手机可以拍完照后立即发到朋友圈，再从朋友圈得到反馈从而得到满足感。同样道理，在车上开发出来的很多应用和功能，实际上用户可能刚开始有点兴趣，可能两三天之后就没有兴趣了，因为在使用上得不到更多的反馈。只有让用户使用这个功能，通过这个功能进入到互联网生态，比如说朋友圈，从这个中间得到一个反馈，反馈进来之后才能够收获满足感促进他去更多的使用，有更多的黏性。只有当更多用户有了用户黏性之后开发者才会有动力开发更多的应用，形成正向循环，所以这里面生态是非常重要的。

刚才提到车的第三个需求是自我进化，这里面很重要一点是从用户的消费习惯、使用习惯中间获取数据，促进自我进化。但我们每天在车内待的时间相对来说非常短暂，一般来说就是上下班，差不多2个小时在里面，即使我们做再深度的场景融合，我们做过很多这样的努力，其实你的想象空间也是非常有限的，因为可用的素材太少了，所以最终一定要达到从智能车应用拓展到居家智能，也就是要把车和别的场景联系起来，做全场景的融合，才能得到更多用户消费习惯和用户使用的数据，从这中间才能够真正实现用户体验的持续更新。

总结下来，我们认为实现智能汽车的核心关键主要有三方面：一、支撑硬件的算力基础；二、支撑应用开发的软件平台，这个平台一定要能够进行快速迭代的，要有很高的复用性；三、利用硬件和软件平台最终形成和互联网和整个生态联合起来的大的生态，这样用户可以在使用车的过程中在整个生态中得到正向反馈，实现正向循环。

最后表达一下我们零束的愿景：让车成为有生命力的人类伙伴，谢谢大家。