座舱域控制器:简单与复杂

发布于 2023-3-7 11:54
浏览
0收藏

【引言】复杂

一个座舱DCU控制器中,到底软件有多复杂?为了对此有个概念,我们看看下面这张图:

座舱域控制器:简单与复杂-汽车开发者社区

以上是DCU座舱域控制器高视角的软件知识脑图,大体上可分为三类:基础软件,框架软件,应用软件。


全部展开是这样的:

座舱域控制器:简单与复杂-汽车开发者社区

如此多的软件模块(实际上还要多),要开发符合汽车质量标准的软件,对于一个公司而言极具挑战性。


在解决软件复杂性的问题上,猴哥觉得有以下几个思路可以一起聊聊。

【1】标准化

一流企业定标准、二流企业做品牌、三流企业做产品,一句话揭示高科技行业的真谛。


软件定义汽车的大趋势下,传统的车厂都在努力向高科技企业转型。大多数车厂试图制定标准,期望一个平台覆盖所有产品。


相关的汽车软件标准组织,比如:

座舱域控制器:简单与复杂-汽车开发者社区

以上,看到比较大的标准组织,基本上都有车厂影子,很多标准组织车厂本身就是发起者。


欧洲车厂尤为注重汽车软件标准制定,主导话语权。


举个例子:


RAMSES曾经是宝马主导的多屏数字座舱解决方案,实现了汽车座舱里不同操作系统之间的多屏互动

座舱域控制器:简单与复杂-汽车开发者社区

一般的做法是用一颗高性能的SoC芯片来推动车内座舱所有屏幕的渲染和内容互动。


但是这导致对SoC的硬件性能要求很高;同时软件设计也很复杂。比如要在一颗SoC上运用Hypervisor+多OS的技术;这对Tier1的技术能力要求非常高,通常一家Tier1无法完成从仪表-->中控-->HUD-->门控制-->后座等各个域的跨界设计。


RAMSES分布式的设计 目的是把座舱系统的所有显示屏连接起来,让所有的屏幕内容可以互相分发。RAMSES框架,以一种服务定制(SOA)的方式,用RAMSES进行基于场景的分发:


• 整个车载座舱可以达到良好的负载均衡


• 实现高效/高性能的渲染(传递)


• 占用较低的网络带宽


• 与平台无关,系统极易扩展


这样完美解决了传统方案的软件复杂度高的问题,让Tier1专注其擅长领域,让车厂灵活的选择多个Tier1帮助完成整车多屏的部署。


这就是一个典型化繁为简的解决方案,这种方案已经实装在宝马3系,8系,X5,Z4等相关车型里。目前RAMSES成为Genivi标准之一,并且开源给所有的Genivi生态伙伴。


使用已经验证过的软件模块,对于用户而言没有质量上的顾虑,也更加容易移植。


利用联盟组织,借助生态伙伴,凭借细致的分工,就可以做到站在巨人的肩膀上,事半功倍

【2】模型化

标准化带来的就是对模型化开发的推崇。


所谓模型化开发,就是定义一种方法论(Methodology),开发出相应的软件工具,生成各种软件模型,接口等,开发者根据这些模型和接口实施二次开发。


  • 方法论(Methodology):


以Genivi 为例 ,通过开发工具Franca自动产生代码,定制接口,定制SOA服务。

座舱域控制器:简单与复杂-汽车开发者社区

  • 标准化接口,抽象物理层


以Autosar 为例,标准化后,只要符合autosar标准的App,在不同autosar供应商提供的环境下都能运行。


比如在Mentor公司的classic Autosar环境下写好的App, 不用修改直接就能放到Vector公司的classic Autosar环境下编译运行。

座舱域控制器:简单与复杂-汽车开发者社区

显而易见,模型化开发的方法对软件质量起到了相当好的控制目的,丰富了生态圈,极大推动了汽车软件工业的发展,特别是降低了应用软件开发的难度

【3】开源社区

特斯拉给我们展示了另外一种方式。


特斯拉抛开了模型化和各种标准,直接利用各种开源资源,招聘优秀的软件工程师对其进行深度优化。


特斯拉别于传统车厂成功的重要因素,个人愚见不是特斯拉软件架构有多优秀(如下图),而是由于软件在特斯拉公司内部的极高的地位。

座舱域控制器:简单与复杂-汽车开发者社区

如果一个车厂高层不从基因里重视软件开发,不重视软件人才,不重视软件开发者的地位,转型高科技公司只怕是空中楼阁。


反过来,能以互联网公司的高薪招聘到高质量的软件人才,那么对于拥有一支高质量软件团队的公司而言,任何软件标准和模型都是束缚,他们可以灵活地创造最有效率的架构和模型。并且,由于不依赖外部软件供应商,从而可以实现高效的敏捷开发,迅速的迭代。


特斯拉在系统层面还做了很多工作,来降低软件复杂度,比如增加SoC算力,硬件隔离,系统冗余等。这也是复杂变简单的方法之一。


文章转载自公众号:智能汽车开发者平台

收藏
回复
举报
回复
相关推荐