“上汽零束曾杰男：云管端一体化中央计算平台处理方案​”

8月26日，由爱因斯坦汽车主办的“2021领域首届智能卡主控制器创新峰会”在上海汽车城瑞立酒店隆重举行。 这次会议持续了两天，包括智能汽车、智能驾驶域控制器、智能座舱域控制器、机箱和车身域控制器、智能驾驶计算平台、电子电气体系结构、软件 会议期间，上汽零捆绑软件由企业基础软件平台专家曾杰男提出《云管端一体化中央计算平台处理方案[

以下是演讲的实录。

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

软件定义汽车已经是领域的共识，在软件定义汽车的场合，重要的一点是进行数字化的变革。 对智能汽车来说，、、数字化的变革有三个方面。 / S2// S2 /

一、满足千人千面客户的诉求。 当今社会有“个性为道，质量为王”的说法。 “个性就是道”，实际上是千人千人所追求的。 在当今社会，如果你们公司的产品不变的话，产品是非常相同的，只是模拟手机，完全相同的功能堆积在一起，客户是买不到的。 另外，也不符合客户对智能车智能的想象。

尼，顾客体验持续发展。 这是从“质量为王”的立场出发的话。 我认为智能车已经不同了。 其质量不再局限于狭义的质量。 以前一辆车没坏，没什么毛病。 我们都说质量好，但现在一辆智能车达到了这个程度，可以说质量好吗？ 其实不能。 例如，如果中央控制的操作逻辑很奇怪，语音体验很差，硬件的质量可能很好，但质量并不好。

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

对于以前流传下来的汽车来说，这三种诉求能实现吗？ 我不能回答。 我们最大的瓶颈是现在电子电气架构是孤岛式的电子电气架构。 由于该体系结构中各控制器的功能基本上是固定的，所以一辆车在不同的顾客处表现出不同的功能状态并不容易。

其次，客户体验的持续反复更新，虽然说可以更新ota、整车，但是如果客户投诉，就需要相应地对每个域进行多个控制器的变更。 每个控制器可能来自不同的供应商。 此时，软件开发、测试、部署的周期可能会超过20个月，难以满足客户体验的持续进化诉求。

又说主动感知和决定，主动的前提是什么？ 能动的前提是收集和分解顾客数据，进行自我学习。 一个非常重要的背景是与云合作做这件事。 由于车侧的计算能力有限，车侧的存储也有限，以前流传下来的体系结构和车外生态的墙壁限制了其实现。

处理刚才的三项指控需要处于什么样的状态？ / S2// S2 /，/ S2// S2 /第一，/ S2 /在硬件级别上，/ S2 /，/ S2 / 第三，端到端的客户体验是，/ S2/] [/S2// ]

零光束提供的处理方案为全栈，目前处于全栈1.0阶段，将于今年年底批量生产。 第一是进行域集中和部分域融合，2023年批量生产全栈3.0方案，在这个方案中去整车计算

[/S2/让我们具体看看3.0体系结构的相关情况，首先就硬件平台而言，的计划是 [/S2// ] ]区域添加控制器，在hpc中智能运行，/ s2/ ]智能空腔 实现智能计算 该硬件体系结构是比1.0更集中的硬件方案，当然这里

这是硬件的一部分，但只有硬件还不够。 无论硬件计算能力有多高，如果软件不支持高速迭代，不支持云服务，也无法实现顾客体验的持续更新。 因此，软件端的处理方案是与云管端soa一体化软件 1.0平台芯片和3.0平台 此时，软件平台可以直接平行移动采用。 也就是说，我们实现了APP开发者开发的APP应用。 即使你的车是1.0体系结构、、3.0体系结构或1.0体系结构之间的不同车型，也可以直接采用

为了实现这些，需要将软件分层。 底部是硬件芯片，上面是虚拟机管理程序虚拟化。 虚拟化的首要任务是在一个芯片上实现硬件隔离和资源共享，在虚拟化之上有各种各样的异构操作系统。 目前，异构操作系统被认为还在很长一段时间内被选中。 在异构操作系统之上有中间件层和soa服务层。 操作系统是用来隔离芯片和软件的，通过操作系统，我们的软件开发可以不用在意采用的芯片是什么。 但是，面板驱动和车内的各种信号，这些东西依然没有标准化。 例如，假设一个APP使用一个信号。 这个信号可能会根据车型而改变。 我不能采用你的APP。 这是以前流传的情况下APP不能复用的一大原因。

这就是中间件和soa原子服务这两层要做的事情，目的是向上方提供统一的标准api接口。 当然原子化服务可以提供任意组合的利益，组合你想要的功能，从而实现应用功能的千变万化。

再往上是APP应用层，实现在不同场景的应用。 这个APP的开发仅靠oem一家是不够的，如果只靠自己进行的话，oem的人才有限，能做的APP也有限。 因此，通过在标准api中加入软件平台sdk，oem、供应商、第三方开发者和顾客希望参与到APP开发的中间，共享APP的生态。 不同的开发者提供的工具不同。 与最普通的顾客或极客相比，他们的软件开发能力有限。 我们提供了z-one maker图形界面，只要简单地拖动就可以实现场景APP应用的开发。 向具有一定软件能力的第三方开发者提供z-one studio lite，可以通过简单的编程和图形调试的方法迅速开发轻量级的APP。 对oem和供应商来说，提供的是z-one studio lite

整个软件平台有两个优点，第一个是高速，t+0+1+7， / S2// S2/z-onemaker 开发的场景[/S2// S2/] z-onestudioli [/S2// ] z-on estudi o 开发的服务和应用[/S2// S2/] S2// S2/] t +7 的[/S2/S2/]再利用APP开发的方法结合原子化服务，实现了千变万化不同的对应 [/S2// ] [/s2/]

以上，首先对硬件、第二个软件平台进行了说明。 硬件为我们提供了计算能力的基础，我们可以制作越来越多的算法，也可以制作越来越多的功能。 在软件平台上，可以通过软件与底层硬件平台的解耦来实现APP应用的重用，可以插件化，越来越多的开发者可以共同创建这个生态。

我们认为，光靠这一点是无法实现智能车所需的三项指控的。 为什么呢？ 为了最终实现基于硬件软件的生态环境，客户可以通过此生态环境体验跨域、融合和多维度。

如果你没有建立手机到客舱的无缝连接，没有建立以客户为中心的生态系统，没有以工厂内的网络生态系统为中心，你开发的功能和APP真的能够重复吗？ 我觉得我们不可能。 例如，在我们以前流传的照相机时代，照相机的拍摄质量一般超过手机，但为什么大家最终放弃了照相机用手机拍照？ 虽然导出照相机拍的照片发给WeChat的力矩展示很麻烦，但是因为手机在拍照后马上发给WeChat的力矩，可以从WeChat的力矩中得到反馈，获得满足感。 同样，汽车开发的许多APP和功能实际上客户一开始可能有点意思，但两三天后可能就没意思了。 因为在招聘上得不到越来越多的反馈。 请客户采用这个功能，通过这个功能访问网络生态系统，例如WeChat的力矩，从中间得到反馈，得到反馈，才能得到满足感，促进采用，具有粘性。 随着越来越多的顾客有顾客粘性，开发者开发出越来越多的APP通讯，形成正循环，因此这里面的生态很重要。

我刚才提到的车的第三个诉求是自我进化，但其中非常重要的是从客户的成本习惯、招聘习惯中获取数据，促进自我进化。 但是，我们每天在车内的时间相对来说非常短。 通常是上班下班。 差不多两个小时都在里面。 无论我们要融合多么深刻的场景，我们都做了很多这样的努力。 实际上，你的想象空之间非常有限。 因为可用的素材太少了，所以最终必须实现从智能车的应用到家庭智能的扩展，也就是车与另一个场景的融合。

总而言之，我认为实现智能车的核心关键首先有三个方面。 一、支撑硬件的计算能力基础； 二、支持APP开发的软件平台，必须能够快速迭代，具有很高的重用性； 三、利用硬件和软件平台，最终形成与网络和整个生态系统合作的大生态系统。 这样，客户在购车过程中可以得到整个生态系统的正向反馈，从而实现正向循环。

最后，让车成为有生命力的人类伙伴。 谢谢你。