“舱驾融合”技术发展趋势分析（下）

最新推荐文章于 2024-07-04 09:46:36 发布

SOA开发者

最新推荐文章于 2024-07-04 09:46:36 发布

阅读量997

点赞数 3

文章标签：舱驾融合智能座舱单SoC芯片

原文链接：https://mp.weixin.qq.com/s/-K568fn3h5ToHJs2enyT3A

版权

作者：陈康成内容来源：九章智驾

4 . 单SoC芯片的舱驾融合方案

特斯拉目前采用的方案属于舱驾融合的一个初期探索，只是把座舱和智驾的域控制器合二为一集成在一个盒子里面。以后，如果能够实现真正的舱驾融合——把座舱和智驾的功能完全集成在一颗SoC里面来实现。这样的方案又会带来哪些好处？同时，实现这样的方案又将面临怎样的挑战？

4.1 单SoC芯片方案带来的好处

1）成本可以做得更低

芯片的集成化程度更高，物料用的更少，相比于之前用多个芯片方案的成本，可以有一定程度的降低。
部分底层软件可以共用，可以节约一部分底层软件的开发成本或购买成本。

2）通讯时延更短

相比于之前通过网络总线传输的方式或两个板子件通过Switch通讯，现在可以使用内存共享的方式，通讯时延会更短。

3）OTA升级空间更大

某主机厂自动驾驶系统架构专家认为：“舱驾融合后，数据信息可以共享，两者之间的交互可以做得更多，软件迭代的想象空间会更大。如果两个域还是完全独立，接口基本上是固定的，接口变，双方软件就要跟着变，比如在后期，一些主机厂会要求增加一个新功能，就需要订阅一些服务，会发现订阅不了，因为之前的接口是定义“死”的，除非在开始的时候就能够把接口定义得特别丰富，否则，一旦后期需要做变更，就需要跨部门提变更需求，再次跨部门进行协作，沟通成本很高。如果两者融合了，再增加新的功能，一般只需要对软件模块做一些变更，不再需要变更硬件接口，便于在后期做一些系统上的OTA升级。”

“座舱域控制器和智能驾驶域控制器相互独立的时候，他们之间可互通的信息比较少，也很难及时获取对方的数据信息，但舱驾融合以后，两者的传感器数据便可以更充分、更及时地被复用。相当于在功能层面留下更多的想象空间 —— 基于座舱和智驾的这些传感器数据，可以融合出一些比较新的、有想象力的应用。” 杨曾说道。

4.2 单SoC芯片方案面临的挑战

4.2.1 硬件层面的挑战

1）芯片本身的设计

实现真正的舱驾一体融合方案，SoC芯片设计本身就是个很大的难题 —— 要把很多的系统和功能融合在一起，芯片的设计方案会很复杂。同时，单SoC芯片不仅要实现上千TOPS的算力，还要把功耗控制在可接受的程度内，这对芯片的制程要求非常高。现在的车载AI芯片已经下探到5nm了，不仅成本高，而且掌握这种先进工艺的企业也寥寥无几。

有业内人士提到了使用Chiplet来设计这样的SoC芯片，它的优势在于各家芯片厂商可以专注自己的芯粒和IP，不用为多余的IP买单，并且小芯粒的流片良率更高，有坏点的部分扔掉，剩下的还能用。因此，采用小芯粒技术进行SoC芯片的迭代设计会更加方便。但是，目前也存在一些问题 ——

Chiplet技术，又被称为小芯粒技术，即把不同制程的芯粒经过选型直接封装在一个SOC里面。目前业内已有一些成功的应用案例，并且整个行业也在推动。曹晶告诉九章智驾：“基于Chiplet技术实现舱驾融合的SoC芯片不难被设计出来，只要产业链端能够提供足够多满足智驾和智舱的芯粒就可以。我觉得使用芯粒技术最大的挑战不在单个芯粒内部的这些设计和实现，反倒是高速带宽部分，毕竟芯粒之间也是需要进行大通道数据的输入输出。

“同样，Chiplet技术不仅面整个产业链成熟的问题，而且在SoC芯片上面实现智舱和智驾这些复杂功能也会涉及到很多工程化的问题，这些问题可能会比把芯片设计出来所花的时间还要长。整个行业讨论这种技术方案比较多，在实践上也有企业在向这个方向发展，但是我觉得离真正在车上量产应用尚且需要一段时间，不过至少这个方向的国产自主化趋势是窥见一斑了。”

2）硬件资源分配

智舱和智驾功能融合在一个单SoC芯片里面，芯片内部的GPU和CPU等资源可以共享，但是资源该如何分配？哪一块GPU/CPU资源供智能驾驶使用，哪一块GPU/CPU资源供座舱使用，怎样实现资源的动态调节？并且，智舱和智驾都处于不断地迭代发展中，如果智能驾驶发展两年，技术迭代升级了，对硬件的需求变了，之前硬件资源分配方案可能就不行了，还需要重新做资源分配。

同时，对于单SoC芯片的舱驾融合方案，很有可能要做内存共享，这样数据才会读得更快，信息传输延迟会更小。但是，DDR分配也会面临很多问题 —— 比如，智驾的内存需求发生变更，另外一个也要跟着变更；在座舱开发的时候，内存损坏，也会影响到自动驾驶的开发。

某主机厂自动驾驶系统架构专家告诉九章智驾：“当前，座舱和智驾尚未达到一个终极形态，硬件资源也没有足够强。两者在硬件资源需求上的变动很可能会影响到整个软件架构，以及后续硬件资源的分配。比如，对于CPU资源，有些ARM核用于支持座舱相关应用，有些ARM核用于支持智能驾驶相关应用；对于GPU资源，可能会通过制定一个优先级进行资源使用或者直接把GPU隔离成不同部分，座舱用一部分、智驾用另外一部分；但问题的关键是 - 对于这种架构设计，大家都没有太多经验可以借鉴，比如，硬件资源怎么去分配，分配是否合理？后期面临需求变更的时候，会不会没办法实现？这些问题都会存在很大的不确定性。”

“智能座舱和智能驾驶功能集成在单颗SoC芯片上的时候，因为两个域的需求完全不同，在做硬件资源分配的时候，既要定义这些应用的优先级，又要确保这些应用有足够资源可以用 —— 能够保证互相不打架，也不能出现一个应用锁死另外一个应用的现象。”汪浩伟表示。

4.2.2 软件层面的挑战

1）OTA升级策略

智能座舱和智能驾驶两者的OTA软件模块、升级模块的数据量、数据包的大小可能都不太一样，在这样的情况下，做好OTA的升级策略也存在一定的挑战。

赵建洪认为，舱驾融合后，座舱发布的数据包和智驾发布的数据包需要要整合在一起才能升级。因为涉及很多的功能，如何更好地整合在一起会有一定的难度。同时，两者有各自的功能升级策略，有的升级频率是三个月，有的升级频率为半年。并且，座舱升级频率比较高，并且座舱还经常容易出问题，出问题就要升级，临时更新内容也需要马上升级。

2）软件上的安全隔离

SoC上面需要隔离出不同区域，并且适配好不同的操作系统。A核上面一般会跑 Linux或QNX系统；内置MCU、M核或R核上会跑AUTOSAR CP。

汪浩伟讲到：“对于舱驾融合方案，在软件上进行整合，并做好安全隔离，确保不同应用的功能安全和信息安全。如此一来，座舱便不会影响自动驾驶，自动驾驶也不会影响到座舱。隔离是系统设计的问题，要从系统设计出发去考虑怎么去做隔离方案。随着芯片的集成化程度越来越高，方案会越来越统一，直到有一天大家都用一种或少数几种芯片、一种操作系统，并且应用程序也非常固定的时候，功能安全方案才会固定下来。不然，功能安全方案永远是跟着项目走，一个项目可能就需要采用一种功能安全方案。

“安全级别不一样的软件放在一起如何共存？既要保证安全件的绝对安全性，又要保证非安全件的“人权”，—— 他们不是“奴隶”，也需要获取一部分资源。可以在操作系统上面再嵌套操作系统，虚拟机是一种，也可以采用Container的方式去做。通过这些方式都可以在软件层面上把不同的应用隔离出来，但更大的问题在于隔离完以后该怎么办？—— 通讯怎么解决、调度怎么解决、资源怎么保证，这些问题才是更主要的。”

目前座舱和智驾中相关模块对功能安全的要求：座舱的中控娱乐模块需要达到ASIL A等级，仪表模块需要达到ASILB等级；智驾的泊车模块至少需要达到ASILB等级，行车模块需要达到ASILD等级。那么芯片底层的加速器资源针对这些不同功能安全等级的应用如何进行有效隔离也是一个比较大的挑战。

杨曾举例说：“以GPU为例，既可以用于做深度学习，又可以用于图像渲染，但是在系统设计的时候，到底留多少给座舱做图形渲染，又留多少给智驾做AI计算？GPU资源的划分既要满足不同功能域的需求，又要支持不同域功能安全的隔离，同时还要保证不同域的数据流能够互相访问复用，这不仅对芯片底层设计，甚至对整个系统软件的设计，都提出了比较高的要求。”

3）虚拟机技术带来额外的硬件开销

舱驾融合需要在操作系统层面做虚拟化技术，但虚拟化技术并非解决问题的完美方案。因为采用虚拟机将会占用一定的硬件资源。据业内相关人士透露，采用虚拟机将会导致额外增加10%以上的CPU开销，同时在商业层面，虚拟化也会带来更多的授权许可成本。

“虽然虚拟化对整体资源会有一定的消耗，但是它也带来了额外的好处 —— 实现了对客户机资源静态的划分及分配。客户机应用之间不互相干扰、信息不会互相串访，保证了功能与信息安全性，简化了上层软件的开发，所以这些资源的耗费也是值得的。”杨曾解释道。

4.2.3 工程化层面的挑战

1）测试验证层面

某主机厂自动驾驶系统架构专家认为：智能驾驶本身在进行底层软件以及应用软件集成的时候就面临很多问题，现在还要和座舱的相关功能一起去进行集成测试和回归测试，不仅工作量很大，并且也很难保证整个产品的可靠性。

2）开发体系不同

“智驾系统和座舱系统本来是两套独立的体系，都有自己的开发节点和发展路线。特别是智驾系统，现在发展还不是特别成熟，比如Orin芯片，虽然现在蔚小理等很多家都在用，但是它的功能尚未被完全开发出来，至少需要2~3年后才能够发挥出来。如果把两者放在一个时间节点上去开发，问题会很多，不仅达不到1+1大于2的效果，甚至可能还会相互拖后腿，没有必要过早的就交叉融合在一起。当两者的技术达到一定成熟度的时候，自然会有一些整车厂愿意去尝试。”赵建洪表示。

4.2.4 跨部门协作难

舱驾融合还面临另外一个难题，就是“部门墙”的问题。业内相关专家大都认为，如果要把座舱和智驾的功能集成到一个SOC芯片上来，确实对主机厂的组织架构存在挑战，根本原因在于谁来做、谁承担责任的问题。最终整合的话，相当于把这些研发资源都打通了，一起来管理。如果还是现在这种跨部门协作，肯定多少会存在扯皮、懈怠的问题，难以保证开发效率和质量。

4.2.5 缺乏统一的行业标准

汪浩伟谈到：“实现真正的舱驾融合，首先要让座舱和智驾把自己的整个架构打开，打开以后把各自的服务做好。SOA实现路径中间必经的一步就是要把原来单体的软硬件架构打碎，变成一个个微服务。这一步做完之后，再谈如何去做融合，不仅智舱和智驾两个部门协作的难度会降低不少，而且后期在资源和时间上的投入也会少很多。

“但是这个事情，需要行业标准的推动，甚至需要强迫一些厂商逐渐把它的软件架构打开。制定行业标准的目的就是把大家的利益统一起来，谁不跟着行业标准走，谁就会吃亏、掉队，甚至面临淘汰，这样才能逐渐推动整个行业的发展和进步。”

5. 舱驾融合对开发模式和产业链格局的影响

5.1 对开发模式的影响

从开发模式上来说，在舱驾融合之前，造车新势力也好、传统主机厂也罢，他们的智能座舱和智能驾驶，是分别开发、再拉通的模式，基本上是智舱部门承接智驾部门的需求，把智驾相关的显示、操控需求，简单地加入到座舱开发中，可以想象得到，其融合程度一定是很低的。

而秉承舱驾融合的理念，智舱与智驾的开发需要同步进行，从一开始两者就紧密相连，智驾部门会将座舱、人机交互等内容，也作为智能驾驶的一部分来考虑；智舱部门也会将智驾功能在车内的表现，作为重中之重来考虑。

那么未来会主机厂的智舱和智驾部门的组织架构又将会是怎样的一种形态，谁又会去融合谁？

当前，在主机厂的研发部门，智驾和座舱是两个独立的部门。智驾内部又分行车和泊车两个不同的团队，再往下可能会分多个不同专业——感知、规控、定位等专业小组；座舱部门会分为HUD、仪表和中控等不同团队。另外，还有专门负责车型的部门，车型部门会围绕车型的EE架构以及系统的一些技术，包括需求定义等开展工作。当车型的功能定义好之后，车型部门相关负责人会找具体的部门来协作。整体来说，一般是由车型部门的项目经理或项目总监来整合这两部分的需求，这是目前智舱和智驾两个部门比较常见的一种开发合作模式。

智舱和智驾进行融合，到底哪个部门或者团队主导牵头去做这件事情，应该也是分阶段的。在现阶段，座舱和泊车进行融合，泊车功能比较成熟，座舱功能要比泊车功能复杂，并且座舱团队也比较庞大，这个时候适合座舱团队做主导。到后期，随着智驾技术发展成熟，以及智驾团队不断地发展壮大，多半是以智驾部门为主导去融合座舱，毕竟智驾的复杂度和对安全的重视程度要高于座舱。

未来舱驾融合之后，主机厂的组织架构会受到哪些影响？赵建洪认为：不管最终两个部门是否合并成一个部门，智舱和智驾始终都会是两个独立的团队，毕竟他们专业分工不同，两个部门都非常重要，把哪个部门做降级处理都不太现实。但是很有可能会出现一些主机厂把智驾和智舱合并成一个智能化部门 —— 我中有你，你中有我，从一开始就奠定了舱驾深度融合的基础。

5.2 对产业链格局的影响

整车EE架构从分布式向集中式域控架构转变的过程中，产业链从Tier2→Tier1→OEM这种线性关系，逐渐演变成以主机厂为中心的网状关系。那么到跨域融合的阶段，是否会对现在的产业链格局有更进一步的影响？

从集中式域控到跨域融合，产业链格局其实还是网状的。只不过这种格局需要主机厂的掌控力更强，对主机厂的要求更高。

杨曾谈到：“通常情况下，主机厂智驾域控的硬件和底层软件基本上会定一个供应商，功能模块可能会再找另外一家供应商，然后主机厂参与去做基础软件和整个域控系统的集成，这是一种在智驾场景下的合作方式，这种合作方式也会拓展到舱驾融合的控制器。

“如果主机厂做舱驾融合方案，首先会找一家做底层硬件和基础软件的Tier1供应商，它需要至少对一家主流芯片公司的芯片及其Roadmap比较熟悉。其次，再由主机厂牵头，去找一些中间件的模块，比如说智驾相关安全集成的中间件模块。再次，主机厂一般会找一些之前合作比较好或者能力比较强的智驾或座舱方面的公司，提供一些应用算法模块。最后，主机厂把所有功能进行集成，并统一牵头做系统验证和测试。”

对于域控供应商而言，之前所谓的Tier1和Tier2之间的分工和定位越来越模糊。

曹晶认为：“Tier1和Tier2的界限逐渐模糊，并且出现了Tier 0.5和Tier1.5。我们做域控设计的公司，对于轻量级的智驾域控，客户需要把所有功能都做一个整合，由于此类域控软件的代码量不高，我们自己就可以把这些功能全部完成。但是，对于比较复杂的的大算力域控，所有的软硬件模块都有一家Tier1来做也不太现实，如果市面上有一些已经量产的、比较好用的模块，比如感知模块，我们会直接去做集成，以提高研发周期降低自研成本。在这些情况下，我们基本就是在扮演一个Tier1的角色。

“在舱驾融合的阶段，主机厂大多会采用SOA的架构，要求软硬件做更好的解耦，因为软件是需要不断地OTA升级，从原来的买一个功能到后面就变成买一个服务，那个时候就会跟供应商绑定得比较深，需要供应商去维护这套软件框架，在未来几年的生命周期内也要不断地去迭代，这种情况下域控制器供应商就更像是一个Tier0.5的角色。”

智能汽车的产业链格局会随着整车架构的变化而变化，原先的产业格局属于垂直整合和横向分割，随着EE架构由分布式走向域集中式，产业链格局逐渐变成水平整合和垂直分割。

水平整合 —— 现在车上控制器越来越少，座舱和智驾甚至也要合并成一个舱驾一体域控制器，最后甚至还要把网关、BCM、VCM统统整合进来，集成为一个中央计算平台。

垂直分割 —— 硬件（包括芯片）、底层软件和应用层软件会由不同的公司分工去完成。每个公司专精于被垂直分割的一个垂直技术领域。

“舱驾一体作为中央计算平台发展的一个过渡形态，会推动整个汽车产业彻底走向软硬分离的方式。然后大家在垂直方向去寻找自己擅长的领域—— 有人专门设计芯片，有人专门设计底层软件，也有人专门设计应用层软件，甚至还有人专门做硬件代工。”汪浩伟解释道。

参考资料：

1.智能座舱的“质变”，域控+软件+多功能融合集成加速落地

https://mp.weixin.qq.com/s/-nkomCaEK-OJYUTpzLiQsg

2.智能座舱平台研究：智能座舱加速进入跨域融合，软件分层设计新时代

https://mp.weixin.qq.com/s/LW0THSTDR9NJegLbsJldgA

3.创时智驾：解码智能驾驶域控制器行业发展态势及软硬件内核

https://www.sohu.com/a/551498073_560178

4.特斯拉最新中央计算模块(CCM)解析