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

【引言】复杂

一个座舱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算力，硬件隔离，系统冗余等。这也是复杂变简单的方法之一。

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