智能汽车软硬分离背景下的行业痛点

智能汽车趋势与挑战

智能汽车高速发展的同时为汽车行业带来一些趋势和挑战，第一是OEM从设备制造商向科技公司转型；第二大是软件定义汽车的概念在汽车在智能化领域影响力价值也越来越高；第三软硬分离，也是下文重点要讲的内容。 软硬分离也是行业内常见的一个热题，不仅是OEM，整个汽车产业链也在软硬分离的大背景下也发生了一些变化。在这个背景下，怿星科技把自己这些在智能座舱软件开发的一些平台化的技术和经验给大家做一个分享。  

软硬分离背景下的行业痛点

各种HMI工具，Kanzi，Unity，QT，Unreal如何取舍？

市面上可供选择的工具众多，对于OEM来说，在进行工具选择的时候可能面临诸多困扰：每个工具的优劣不同，孰优孰劣如何取舍？如果OEM被某个工具绑架，后续切换的成本比较大；如果工具选择的不合适，则有可能造成不必要的的资源浪费。

如何一套代码兼容不通车型，不同分辨率，不同电子架构？

每个OEM都会有若干车型系列，车型不同，配置也随之有差异，比如不同的分辨率，不同的电子架构，还有油车、电车。如何在不重复造轮子的情况下，用一套代码去兼容不同的车型，不同的分辨率和不同的电子架构。

如何一套代码兼容不同的Tier1的底层平台？

在为OEM做软件开发可能会遇到很多问题，仓库一堆，重复代码一堆，修Bug的时候，这个Bug可能在不同车型里面很难进行同步。而且OEM通常会有很多Tier1，不同的Tier1有不同的软硬件平台，底层的一些基础的API、接口都不一样。OEM跟Tier1合作的情况下，在软硬分离的情况下，如何用一套代码兼容不同Tier1底层的平台，实现大范围的互用。  

智能座舱系统架构概览

图片来源：怿星科技

上图是智能座舱的系统的架构的整体的图，从下往上看，下面是典型的基于高通8155芯片，然后是Hypervisor，再往上是系统的, QNX、安卓，在这一层我们通常叫软硬分离。软硬分离中的硬和软到底什么意思？硬一般指系统平台，包括硬件、操作系统，还有它的一些技术软件，驱动等等；软一般指上层应用层软件或者中间件这一层。在座舱域控制器里软件部分包含仪表、HUD，还有中控，包括上面一些应用的、HMI的，还有底下中间的一些framework的层面的内容。

HMI应用三层架构

图片来源：怿星科技 在怿星科技的架构里面，应用层软件通常被分为三层，HMI框架包含两层——静态界面层以及UI交互逻辑层，下面业务框架完全是业务逻辑。

为什么会把HMI中的静态界面和交互逻辑分成两层，原因在于两者具有不同的特点：对于完全纯静态的界面，通常都是完全使用工具软件完成，这样操作起来效率高，修改起来的效率也比较高，常见的工具软件有Kanzi，QT或者Unity，也包括Unreal等一些工具；交互逻辑层聚焦于页面跳转的逻辑，这些逻辑通常是跟底层的数据状态有关，这一部分在量产的过程中，建议用代码实现，避免在工具里面做交互逻辑，做Demo的时候觉得非常合适，等到量产的发现实际的信号和Demo里面不匹配的情况，这样导致后续修改的成本非常高。

这样把应用层软件分为三层，上面一层用工具实现，下面两层用代码实现，这样可以彻底解耦UI界面，UE逻辑，业务逻辑三者，易于分工、易于开发，更易于维护。  

高效的MVVM设计模式

图片来源：怿星科技 MVVM模式特点：

ViewModel与View彻底分离，UE逻辑与界面彻底分离

View与ViewModel通过消息通信，在工具中完成

View和ViewModel实现可视化数据绑定，在工具中完成

View的改变不会引起ViewModel，Model的任何变化

OEM可以随意订制HMI

MVVM设计模式把View和交互逻辑做了进一步的解耦，所以在MVVM的模式下，View对应的界面完全用工具来实现，ViewModel对应的逻辑可以直接把数据处理的结果和界面进行双向的绑定， Model则完全属于业务逻辑数据这个层面。 由于ViewModel和View彻底的分离，在MVVM模式种有很多新的工具，包括微软的WPF，还有Kanzi等等都会支持MVVM。

所以MVVM模式最大的优势之在于它把应用层软件三层彻底解耦，中间该工具化的完全工具化，模块化的模块化。 前文提到平台化里面有三个痛点，第一个是上层怎么兼容不同的工具，像Kanzi，Unity、QT这样的工具，第二就是在下层怎么兼容不同的Tier1，不同Tier1的平台，第三是中间怎么适配不同的车型，用一套代码支持不同的车型，不同的分辨率，不同的电子架构。

怿星的架构重点在于首先是要进行分层，分层之后把这个相关的三层完全解耦，进而在每一层里面实现一些标准化模块，比如说UI的模块，UE的交互模块，以及业务逻辑模块， DataParser模块。

怿星根据多年来为OEM提供HMI软件的经验，在这里面把整个应用层上下分成了大概五层，最上层的UI完全用工具来做，做的是一个模块一个模块；第二层是UE的交互逻辑，第三层业务逻辑，第四层Parser也就是数据解析层，第五层是Adapter，Adapter是专门用来跟平台进行适配，底下有不同的平台采用不同的接口，比如说有的平台用PPS通信，有的平台是用FDBAS通信等等ODI通信，不同的通信通过不同的Adapter去适配不同的Tier1平台，通过Adapter的Parser层对数据进行解析，解析完之后这个数据成为标准化的数据。

所以从Parser层之上，所有的数据和所有的Tier1的平台都是解耦的。Adapter主要是用来跟Tier1平台的数据结构、解析进行关联，通过这一层可以实现，下面可以兼容不同的Tier1，上面又针对不同工具进行适配，以及在中间的业务逻辑层、交互逻辑层、Parser层整体的接口完全是用C++，而且对它实现了标准化、模块化。 怿星有一个Base Project，这个Base Project可以理解为对同一个车厂里不同车型共用的模块进行标准化开发，所以共用的模块都是用Base来进行实现。

不同车型又有差异化，不同的分辨率有差异化，不同的电子架构有差异化， 怿星把差异化的东西作为一个单独的相当于是插件的方式加进来，作为动态库的方式集成进来，最终可以提供用Cmke体编译，通过编译设置配置选项，来实现最终能够根据不同的配置选项生成对应的不同的电子架构，不同的车型，不同的分辨率所对应的可执行文件。

可执行文件只会包含这个车型，这个分辨率，这个电子架构所需要的最小的代码，以及它的源文件。这个是一个目前来说怿星在实践过程中发现最优的一个方案。

怿星HMI软件平台化架构及工具链方案最上层是用工具，最下层是兼容不同的Tier1，中间这部分的属性数据是跟所有的Tier1或者所有的底层数据是没有关系的，它是标准化数据。比如速度数据，速度可能是从底下CAN信号过来，或者从FDBAS过来，它的数据结构都是不一样的，但是到了中间业务逻辑层，就会给速度数据一个标准化数据格式，这样能达到中间层整个应用层的业务逻辑到交互逻辑这一块是完全标准化的。

这样我后续在适配不同的Tier1的时候、在切换Tier1的时候，只要把Adapter重新换一个，然后把Tier1的数据格式转化成自己的标准化的数据格式，以及在增加车型的时候，只要以动态库的形式集成进来一个差异化的一个模块。 这样能够真正实现用一套代码来兼容不同的车型，兼容不同的Tier1，同时因为从UI层之下，所有层都是C++的接口。

这个C++的接口本身跟上面的工具脱离，在C++代码层是见不到任何的有Kanzi的API，QT的API，所有的工具的API全部都在上层，以及通过相应的适配器把它封装好了。这样以来，所有的HMI的开发的时候，业务逻辑和UE的逻辑都是C++的方式，跟所用的工具没关系，比如说现在用Kanzi的工具，未来我要切换到新的工具的时候，除了这个工具界面里面做的静态界面里面需要用新的工具重新做一遍之外，底下所有的代码不需要做任何的迁移。

这一套方案就可以实现车厂不会被任何的一款工具给绑定，可以根据自己的需要，后续选择相应的工具，这个迁移的成本非常低。

审核编辑：刘清