车载信息娱乐系统开发模式现状与未来趋势分析

2021-12-30朱芙蓉秦文贞

汽车电器 2021年12期

朱芙蓉，刘敏，秦文贞

（1.江西五十铃汽车有限公司，江西南昌 330104；2.南昌航空大学，江西南昌 330063）

车载信息娱乐系统（以下简称车机）是车辆的综合信息处理系统，承担着座舱娱乐、通信、车身控制、辅助驾驶、保证行车安全等重要功能。随着信息技术、车联网技术、5G技术、人工智能技术、自动驾驶技术的发展，车机开始向集成化和智能化发展［1］。车机的功能越来越趋于复杂，开发难度越来越大，也随着市场的培育，用户对车机系统的功能及交互要求也越来越高、对稳定性的要求也越来越高。因此，对于车机系统研发设计提出了更大的挑战。

本文通过分析目前车机开发的行业现状、存在的问题，调研目前原始设备制造商（OEM）、Tier1车机的开发模式偏好、OEM软硬件开发现状，并分析了车机的开发发展趋势。

1 车机的开发发展现状

系统软件方案商有一套基本的工程代码框架，此工程框架一般由平台芯片厂商提供，为了快速开发项目，项目都在此基本框架上建立软件分支副本，在此分支副本做增删改，在功能上做兼容，从此形成一个新的项目。也有的项目是在前期开发的类似项目上，建立副本分支，针对需求差异点，对新项目进行定制化开发。此为系统软件方案商进行新项目开发的基本模式。目前这种开发模式，存在以下不足。

1）开发到后期，代码功能越来越多，复杂度越来越高，代码容量越来越大，逻辑越来越杂乱，一套Android代码能达到60GB以上。如果测试不充分，就很容易导致经常出现很低级的软件bug流到OEM。

2）后期的开发人员初期都是参考以往同事的设计方式、逻辑、架构、或是在前人的基础上做些优化，导致软件设计、架构设计不清晰，风格不统一，特别是涉及到具体业务逻辑的应用层模块。对人员变动后，后续接手人员交接难度大，交接耗时，交接品质低。

3）方案公司一般进出人流量大，甚至除核心、骨干外，整个开发团队人员都会更新，这就加速了第二点的不足。且难以形成技术沉淀，对OS的定制开发能力、BSP的裁剪能力欠缺。

4）方案公司对核心板的软件管理，特别是对BSP，为了减少对不同的项目开发的移植难度，BSP功能大多采用兼容开发的模式，导致BSP庞大，OS运行卡顿、不流畅，软件效率低，硬件利用率低。

5）方案公司对APP应用的开发，为了提高项目的实现效率，往往是针对不同客户的差异化需求，在前期的工程上做修改，这样容易出现定制化开发不彻底，APP应用容易出现逻辑上的混乱。

2 车机开发模式偏好

为解决此前开发模式的不足，研究技术人员开展了大量的工作。经过调研，目前市场上，造车新势力比较偏好的车机开发模式。

1）车机硬件，由A供应商合作完成。其主要工作任务：硬件设计、硬件功能验证、硬件可靠性保证、硬件DVP实验、贴片生产、软件烧录、组装生产、整机功能测试、出货。

2）车机软件OS移植适配由B供应商完成或者也可由A供应商完成，OS移植需要根据需求适配硬件，对BSP进行定制开发，对OS进行深度裁剪，优化OS稳定性，删除无用的OS功能和模块，提升OS开机时间。此需要与A供应商紧密配合。

3）车机应用层软件，由C供应商完成，也可拆分委托多家合作完成。应用层分为各个模块或是各个APK，主要针对各个功能应用，例如AVM、APA、设置、电话、媒体、商城、自动驾驶、车联网车机端APP等，此需要与A、B供应商以及对手件紧密配合。

4）车联网部分由D供应商完成，目前此部分功能在车机中越来越重要，涉及到车机的智能化埋点，后台云TSP服务的稳定，以及后续AI算法的融入，考虑到后期连接数量越来越大，数据量越来越大，为减少切换供应商所带来的数据迁移和方案修改所带来的巨大成本，普遍趋于选一家技术稳定可靠的供应商长期合作。

车机开发模式包含硬件和软件，图1是硬件的模块开发组成和形式，图2是软件的分层模型［2-3］，图3是Android系统的架构分层模型。

图1 硬件的模块开发组成和形式

3 OEM车机软硬件研究发展

目前OEM车机软硬件主流开发方式有3种。

1）硬件电子开发模式是芯片平台的SOC+外围电路设计，此部分SOC为芯片原厂为方案公司提供基本一致的IC平台+软硬件基础包，此部分硬件电子由Tier1根据硬件电子基础包设计，并且添加OEM需求相关的外围电路设计。形成OEM的硬件电路方案形态。

2）软件开发模式：①Tier1的外包Tier2（如果有）方案商完成OS+driver的BSP移植工作，基本不做OS的深度裁剪，仅在基本框架方案上建立软件分支副本，在此分支副本做增删改，在功能上做兼容，从此形成OEM的OS，因为Tier2是系统软件方案商，考虑的是快速地完成项目开发，完成项目功能，且利于以后新项目的延续复用、移植和兼容，不会投入太多的人力完成系统稳定性的优化，和系统效率的提升。从而造成硬件利用率低、OS不稳定，卡、慢、死机等现象很难从根本上解决。②同时，Tier2也完成servises修改和移植，和APP的设计，与BSP的开发存在同样的现象和不足。③Tier1的CAN和MCU团队完成CAN的设计和MCU相关的设计。主要实现整车的CAN通信和诊断，电源管理相关的设计。

图2 软件的分层模型

图3 Android系统的架构分层模型

3）与车机相关的对手件APA、AVM、DVR设计成独立零件，通过数据线、信号线、CAN与车机通信。车机主要是应用层的APP做UI界面显示，APP通过车机MCU与独立零件通过CAN信号实现控制信号的交互，通过数据信号线与车机OS做视频传输，独立零件设计成本高、联调难度大。APA、AVM、DVR、人脸识别等功能与车机集成式的设计可以降低至少20%～30%的成本，但对软件开发能力要求更高，特别是BSP的开发能力［4］。

OEM车机及其相关对手件设计方式如图4所示。

越来越多的OEM车厂为了后期为提高软件品质和稳定性，提高硬件资源使用效率，节约硬件成本，加快车机以及智能座舱系统软件开发平台化进程，节约零部件成本，已经在慢慢放弃使用软件方案公司的开发模式，特别是造车新势力和处于头部的传统车厂，他们越来越倾向于前期加大软件开发的投入，做好前期规划的预研，陆续采取如图5的车机及其相关对手件的设计方式。具体合作模式参考图6。