从硬件到体验，舱驾一体的机会与挑战 |GAIR Live

随着智能汽车在智能驾驶和智能座舱的进一步升级，舱驾融合成为业内希望进一步挑战的高峰，越来越多的企业开始思考，舱驾一体对于现有的业务、产品会带来怎样的冲击与技术挑战。

为了更深入地了解舱驾一体的行业发展现状和技术动向，4月13日，雷峰网新智驾频道联合国产3D引擎Cocos 策划了主题为“从硬件到体验，舱驾一体的机会与挑战”的线上直播分享活动，活动邀请了来自Tier1 博世中国、3D 渲染引擎技术提供商Cocos、HUD 产品公司泽景科技以及芯片公司芯擎科技等4位企业嘉宾，就驾舱一体的话题进行分享，大家就当前的业务产品以及驾舱一体所带来的未来挑战进行了深度的探讨。(新智驾正在策划有关智能座舱方向的内容选题和线上直播分享，欢迎添加作者微信ID：zhangxian2021，进行交流）

以下为本次分享的主要内容，雷峰网新智驾进行了不改变原意的整理。

分享嘉宾

梁融韬（Cocos 车载业务产品总监）

万昕（博世中国首席客户解决方案专家）

李贝尔（泽景HUD 产品总监）

蒋汉平博士（芯擎科技副总裁兼产品规划部总经理）

Q: 各家与舱驾一体的相关产品是如何布局的，目前业务进展情况如何？

Cocos：Cocos 主要提供3D 引擎技术方案，已经为全球160 多万开发者持续提供游戏引擎方面平台，和技术支持服务。除了游戏方向外，Cocos 在智能座舱方向也有业务布局，目前主要面向智能座舱的HMI 交互、元宇宙和XR 的技术方案开发。

业务方面，Cocos 与主机厂、Tier 1的合作主要集中在智能座舱的 3D 的主launcher，包括语音助手、行泊一体的交互体验，以及在智能驾驶模式下的环境感知信息的全面 3D 化。 

泽景HUD：泽景主要致力于HUD 车载视觉产品。业务方面，泽景与国内主流的主机厂都有合作与联系，产品已经上车了三四十款车型。泽景的产品主要分WHUD和ARHUD，ARHUD 已经实现量产，预计今年将会有5款车型上线ARHUD 产品。

博世中国：博世智能驾驶与控制事业部（XC）成立于2021年，业务主要覆盖智能驾驶、智能座舱、智能网联3大方向。

业务方面，博世在智能泊车、自动驾驶方面有长期的产品规划，并且已经实现了量产。目前，博世已推出跨域舱泊融合的解决方案，将泊车集成在智能座舱的域控制器里面，是一套非常有性价比的方案。这套舱泊融合的 demo 去年 11 月份就已经公开发布了，整套域控制器集成了环视摄像头加12 个超声波传感器，同时在SOC 上集成了泊车算法，在MCU 上实现功能安全控制，从而实现舱泊融合的功能。

芯擎科技：芯擎科技主要从事车规级低功耗及高复杂度的芯片设计，目前产品线包括高性能智能座舱芯片、自动驾驶芯片和MCU 等。产品方面，芯擎在2021年发布了7纳米的座舱芯片龍鹰一号，目前已经实现量产，并将搭载相关车型对外发布。 

Q：对于舱驾一体的路径选择上，智驾兼容泊车和座舱兼容泊车，哪条路径会更合理一些？

芯擎科技：无论是智驾兼容泊车，还是座舱兼容泊车，首先都要靠感知系统，感知系统被重用才是最佳的融合方案；一般泊车配备4 个环视摄像头，AVM环视天生就是座舱域要干的事情。对于泊车来说，在不增加任何成本的情况下，只要座舱域能给给泊车提供算力空间，那么泊车就是很自然的一个过程。

与之不同的是智驾域，智驾域以前视为主、环视为辅，然后加雷达，这种情况下它经常会缺失部分算力，比如缺失GPU。所以如果要实现环境拼图等功能的话，还是需要回到座舱域。

从我们的理解来说，座舱域+泊车，比如说做APA 可能只增加超声波雷达（USS）, 由于车身本来就有ECU 单元，那么就自然完成了功能实现。因此，基于座舱域来做泊车，在成本上几乎是接近于零负荷。

当然以上说法与SOC 的性能还是有很大关系的，需要具备有预埋算力的能力，那么从座舱域到泊车就是一个极低成本的方案。以龍鹰1 号为例，单颗芯片能涵盖座舱域的DMS、OMS，同时加上泊车环视等功能。

因为泊车也涉及到控制部分，只要功能安全ASILD 计算核的算力有2K以上，就可以同时处理好仪表盘的功能安全和泊车的规模算法。

以上这些部分，是芯擎与很多车厂形成的最终共识，我们认为座舱兼顾泊车会是一个非常低成本快速导入的方案。

Q：舱驾一体的趋势下，行业内的协作趋同于集中化。舱驾一体的大背景下，对Tier 1公司在上下游合作方面会带来怎样的改变？ 

博世中国：传统Tier1 的合作模式是Tier 1来做全栈开发，给主机厂提供交钥匙的方案。博世有全栈开发的能力，在合作模式上可以非常灵活，既可以提供交钥匙的方案，也可以分模块地给主机厂做交付。合作模式是基于主机厂在实际开发过程中可能需要更多发包的情况而设计的。

在整体的产品规划当中，博世也在引入更多的合作伙伴。在上海车展现场发布的全新软件平台中，博世引入了Cocos、泽景等一系列合作伙伴。所以，在当前汽车市场的大背景下，上下游之间能够灵活开放合作是博世现在最关注的方面。

Q：近来，业内有“ Tier 1 需要往 Tier 0.5 进行转变的一个趋势”的说法，意味着Tier 1 企业需要在现有的角色上与主机厂走得更近。那么，博世是如何更深度地支持主机厂来打造差异化竞争力的？ 

博世中国：对于博世 XC 事业部来说，我们更注重的是软件能力，借助软件来支持主机厂去打造差异化的体验。我们目前在开发一个通用的跨域软件平台，它包含整套工具链，能够支持智能座舱、智能驾驶等上层应用的开发，也支持跨系统跨域的高速通信。近期，软件平台将于上海车展正式发布，欢迎大家关注。

这套软件平台主要提供三层软件能力的服务，包含基础服务、跨域服务，以及与合作伙伴一起提供的生态原子化服务，我们称之为“1+3”。一个软件平台+三层软件服务的灵活方案。客户可以基于整套方案做自由的排列组合，与客户一同共创，实现更丰富的跨域融合场景，也能够支持客户去打造一些差异化的用户体验，这是博世XC 事业部的主要目标。

Q：舱内交互是一个很重要的话题。李总刚才有介绍泽景在HUD 方面的布局，作为国内HUD 市场的领先企业，能否介绍下泽景在AR HUD 方面的研发过程。

泽景HUD：泽景一开始做的是C-HUD和W-HUD，我们负责产品的稳定性、可靠性，然后将硬件产品交付给主机厂即可。随着对产品体验要求的提升，我们开始涉足虚实结合的AR-HUD 产品研发。HUD 是一套涉及光学、机械、电子和软件的软硬件设备，在研发过程中遇到了许多问题。

相比W-HUD，AR-HUD 的屏幕尺寸更大，但屏幕做大以后，不能够像W-HUD 一样，将所有信息全部显示上去，需要将显示信息有选择地显示，这就带来了一个挑战。同时AR-HUD 呈现的是虚实融合的效果，这就需要结合实景的变化、驾驶场景的变化、来调整实时信号内容的生成，这部分我们称之为 AR 引擎，这是一套升级版的软件。

软件硬件的问题都解决之后，我们发现光把这两部分做好还是没办法把显示做好，这关系到显示策略的问题，还需要基于驾驶员的驾驶行为去优化显示效果，比如什么时候需要出现报警标注、航迹线、转弯箭头等等信息，而且这些型号还可能会同时出现，因此需要深度了解驾驶习惯来进行显示策略调整。 因此，就需要引入人机模型，驾驶员、AI 本身和所有驾驶场景，了解驾驶员的痛点和驾驶期望值，以及不同场景下对应做怎样的显示并制定场景显示策略。

基于不同的具体场景做了显示策略的优化之后，我们把产品交付给车企和用户之后，发现还是会存在褒贬不一的问题，这里就需要建立一套体验评价体系，用以判断到底什么样是一个好产品，这里就涉及心理学等各个评价维度。总而言之，基于舱驾融合之后的AR-HUD 研发过程对产品研发公司的综合要求还是非常高的。

Q：业内有关于AR-HUD 和中控屏互相融合的话题讨论，您对这一话题怎么看？

泽景HUD：刚才提到了显示策略的问题。车辆上有多块屏，中控屏、仪表屏、甚至副驾屏、抬头显示屏。以中控屏和抬头显示屏为例，它们的特性是蛮不一样的。 

所以这几个差异点，决定了这两块屏更多的是互相补充的关系来提升驾驶体验。

Q: 座舱是移动的第三空间，作为 3D 渲染引擎技术提供商，Cocos 是如何去从产品端去理解座舱娱乐化升级的？

Cocos：3D 引擎带来的用户交互体验的升级具体有4个方面：

智能座舱交互体验的提升；

智能座舱沉浸感的提升；

智能座舱个性化体验方面的全新感受；

用游戏化的理念来增强智能座舱的整体交互，比如用一些好的体验故事线来串联整个智能座舱的体验，包括通过视觉、用户交互等方式来增强用户的在使用智能座舱和智驾功能的趣味性。

Q：舱驾一体的升级，对各家公司现有的产品布局会带来怎样的技术挑战？

Cocos：技术挑战还是蛮大的。Cocos 最初是游戏引擎，在移动游戏、IoT 设备、以及穿戴式设备XR 眼镜、AR 眼镜、VR 眼镜上面都有很多的应用。进入智能座舱领域，对于引擎的要求有了更深入、更差异化的提升。因为舱内的3D 应用和 3D 场景是基于系统级别的，而不是只是一个独立的应用级别。

另外，很多客户需要让我们把3D 引擎在AR-HUD 上运行，甚至智能材料、全息投影等介质上。这对引擎架构以及平台都提出了更高的要求。

Cocos 要做的是：

第一点：全面拥抱变化，实现引擎跨平台的能力，实现智能座舱硬件以及系统级的融合；

第二点：提升引擎集成度。原来我们的产品只需要有标准的安卓、智能设备接口，就可以让引擎 run 起来。现在，智能座舱上面除了有传统系统的信息数据和接口以外，还有就是智驾域、座舱域的控制信息如何去跟我们的引擎对接。所以，上层的开发者需要对接好的这些数据，然后在我们的 3D 场景内做出更加有创意的交互和体验来。

第三点：要跟智驾域、座舱域整体的算力规划安全性。刚才泽景的李总提到的包括驾驶的安全、数据的安全、整车的安全以及我们的应用场景，综合考虑 3D 引擎在刚才提到的体验上面会有很强的冲击力，需要我们充分考虑算力的平衡、整车安全性以及用户交互等问题。

泽景HUD：舱驾融合能够为HUD 产品提供更好的应用场景。

在舱驾域还没有融合的情况下，如果驾驶员要获得驾驶相关的信息，工程方面需要经过驾驶域，然后通过以太网总线传送到智驾域、座舱域，然后从座舱域的域控中得到HUD 引擎所需要的工程的信号，这是一个间接的过程。

不融合的情况下，需要分别和座舱域、驾驶域打交道，流程比较复杂。舱驾融合之后，工程开发更便利。

第二个是算力方面。舱驾融合之后算力平台能够分配更多的算力给到HUD 产品，HUD 可以支持更多的驾驶场景信息显示。以前，HUD 主要显示的是ADAS、导航等信息，舱驾融合之后，就可以展示行泊一体、APA 等驾驶场景信息，这对驾驶体验会有很大的提升。

第三方面：HUD 公司之前更多是在做硬件、算法、光学技术的研究，忽视了视觉交互效果的设计。舱驾融合能够提升HUD 在整车的重要性，这对我们的视觉效果设计、HMI 设计提出了更高的要求。

博世中国：挑战在于软硬解耦的软件平台、芯片解耦的算法能力以及AI 的安全性问题。

1、软硬解耦的软件平台。软件平台比拼的就是效率，如何高效地把座舱的软件和智驾软件集合在一起。尤其是现在的芯片比较多样化，算力功能安全，芯片供应的不确定性，所以就需要用通用的软件平台来应对各种不确定性，这就是我说的软硬解耦的软件平台。

2、芯片解耦的算法能力。博世在泊车的领域，已经能够做到算法的芯片解耦，已经得到了验证，目前我们想把这一部分复制到舱驾融合方向。

3、AI 的安全问题。因为 AI 技术的不确定性是没办法用功能安全等级ASIL 去衡量的。所以我们正在尝试用预期功能安全的方案去解决这样的问题，比如说通过训练数据集的覆盖度来衡量训练后算法的安全性，包括我们为 AI 软件的安全验证建立了相应的数据工程的模型，然后对 AI 的不确定性、鲁棒性去针对性的优化，以及我们在部署到嵌入式环境里边的这种一致性的验证。这些其实是当前行业的普遍难题。

芯擎科技：对芯片公司最大的挑战还是如何约束算力的膨胀。

1、行业内都会谈算力预埋，实际上算力的使用是有一定天花板的，因为芯片有工艺制程、功耗和成本等条件的限制，所以如何尽可能地发挥出芯片的算力，是对芯片公司的主要挑战。 

2、另一个挑战来自于：软件的成熟度。不管是上层应用，包括智驾应用算法、功能安全、信息安全，如何把芯片的各个计算单元算力来有机融合，加速整个系统的上市时间周期，是芯片公司主要在思考的问题。

3、还有就是架构，汽车整体的电子架构会影响芯片的架构设计，芯片架构如何做到最优、效率最高，以及易于开发、维护、升级，提升芯片的易用性和高效率，对于芯片设计能力的挑战也不小。

提问环节

Q：舱驾一体化的高算力芯片在量产方面是否会存在卡脖子的问题？ 

芯擎科技：目前车规级芯片最好的工艺制程就是 7 纳米，因此并没有在3 纳米、5 纳米芯片上做文章，可以规避掉一些风险。从工艺制程的角度来说，车规级市场还是相对的安全区。

另外，中国拥有全球最大的手机市场，未来的汽车市场中国也会非常领先的，这方面大家要对国家和中国市场有信心。

Q：行泊分离架构下，行车和泊车对应的技术人员和方案开发是如何进行的？是在一个部门还是两个部门？ 

博世中国：博世内部是由系统供应商整体开发完成整套方案的。团队协作方面，行泊分离的方案是在同一个部门，但是两个不同的团队在负责。 Q：行泊一体架构，车企的组织架构是否也要做相应的调整？ 博世中国：需要根据车企的组织架构规划来判断。目前，博世所接触的车企，舱、行、泊都是在一个部门，也有这样的车企。

未来电子电气架构是往越来越融合的方向去发展，在行泊一体的架构下，车企都会有一些调整。目前的话，主要会是软硬分离的工作方式。 

Q：智能座舱的娱乐化是直接接入游戏主机比较好，还是针对于座舱内部环境量身打造游戏比较好？ 

Cocos ：我相信这两种形态在一段时间甚至长时间会共存。现阶段，很多主机厂会考虑到车主是主机游戏大作玩家的需求，来引入投屏或者说映射的游戏方式。另一方面，随着舱驾融合程度的进一步提高，我相信游戏开发商、游戏开发者会更深度地基于座舱环境来开发游戏，创造一个全新的游戏品类。 

Q：舱驾一体化的核心是指域控制器一体化还是SOC层的一体化？

芯擎科技：融合是有一些基本的原则，比如功能安全级别接近或可靠性接近，才能进行融合。我们理解的舱驾融合，目前来看实现SOC 层的融合还是需要时间的，目前主要还是系统侧做融合。从目前逐渐转向中央计算的趋势来看，最终会从系统层过渡到SOC 层。 

博世中国：我们觉得最终的一体化会是在SOC 层面的。

因为，现阶段芯片还存在算力问题，以及功能安全的问题，没办法用一颗SOC 把舱、驾、泊，并且是高阶的驾驶功能全部支持。所以我们内部的路线规划是先舱泊，然后再舱驾。而且，舱驾会先支持到低阶的L2，然后再转向高阶。

为什么说一体化应该是SOC 层面的呢？因为一体化最主要的目标是能够简化设计，然后能够降低成本，同时做到芯片的算力共享。所以从角度来说，真正实现SOC 层面的一体化才是真正的一体化。（完）