车载软件管理方法、装置、电子设备及车辆

技术领域

本申请涉及车辆技术领域，尤其涉及一种车载软件管理方法、装置、电子设备及车辆。

背景技术

目前，车载系统中，不同的域控制器对应不同的开发环境，不同域控制器内对软件数据的管理，包括软件安装、升级等流程，通常基于开发环境进行适应性确定。例如，针对自动驾驶模块的程序升级，通常通过对自动驾驶模块的完整固件镜像进行更新或修补来实现，但针对安卓系统下的应用程序，则通常使用差分升级的方式来实现。这使得整车域控制器的软件数据的管理效果较差。

发明内容

本申请提供了一种车载软件管理方法、装置、电子设备及车辆。

根据本申请的第一方面，提供了一种车载软件管理方法，包括：

确定车载系统目标域控制器中软件包的类型，一个所述软件包封装有一个软件数据模块对应的可执行程序或插件程序，一个所述软件数据模块包括至少一项车载服务的软件数据；

基于所述软件包的类型，对所述目标域控制器进行软件数据管理。

根据本申请的第二方面，提供了一种车载软件管理装置，包括：

确定模块，用于确定车载系统目标域控制器中软件包的类型，一个所述软件包封装有一个软件数据模块对应的可执行程序或插件程序，一个所述软件数据模块包括至少一项车载服务的软件数据；

管理模块，用于基于所述软件包的类型，对所述目标域控制器进行软件数据管理。

根据本申请的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请的第一方面所述的方法。

根据本申请的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行本申请的第一方面所述的方法。

根据本申请的第五方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现本申请的第一方面所述的方法。

根据本申请的第六方面，提供了一种车辆，被配置为执行本申请的第一方面所述的方法。

本申请实施例中，相比基于不同域控制器的开发环境或属性，对不同域控制器执行不同机制的软件数据管理，通过封装有可执行程序或插件程序的软件包，可以对整车域控制器软件包进行统一管理，简化了车辆软件系统的开发和管理，减少了开发人员的工作量，提高了车辆软件系统开发和管理的灵活性。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是本申请实施例提供的一种车载软件管理方法的流程示意图；

图2a是本申请实施例提供的一种软件包的内容示意图之一；

图2b是本申请实施例提供的一种软件包的内容示意图之二；

图3是本申请实施例提供的一种软件包的内容示意图之三；

图4是本申请实施例提供的一种软件包的封装流程示意图；

图5是本申请实施例提供的一种软件包的安装原理示意图；

图6是本申请实施例提供的一种软件包的安装/升级的交互示意图；

图7是本申请实施例提供的一种软件包的启动的交互示意图；

图8是本申请实施例提供的一种车载软件管理装置的结构框图；

图9是本申请实施例提供的一种电子设备的结构框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为方便理解，先对本申请涉及的一些内容进行说明：

域控制器：相关技术中，车辆的电子电器架构可以划分为多个域(Domain)。具体的，可以依据功能划分为多个功能域，并对应设置功能域控制器。功能域控制器可以分为两类：一类是对算力要求高的座舱域和自动驾驶域，另一类是对算力较低的动力总成域、底盘域、车身域等。或者，也可以依据物理区域位置划分为多个位置域，并对应设置位置域控制器。本申请实施例涉及的车载系统的域控制器可以是上述功能域控制器，也可以是上述位置域控制器，具体可根据实际情况决定，在此不作具体限定。

软件在线升级(Software over the air，SOTA)：也可以称为软件空中升级，在本申请实施例中，简称为SOTA升级。SOTA升级通常是指面向车载系统的应用软件升级，或者通过窄带物联网(Narrow Band Internet of Things，NB-IoT)模组给微控制单元(Microcontroller Unit，MCU)升级。

请参见图1，图1是本申请实施例提供的一种车载软件管理方法的流程图。上述车载软件管理可以由车载系统执行。需要说明的是，本申请实施例中，不对车载系统运行的操作系统进行限定，也不对车载系统运行的智能化架构进行限定。

如图1所示，上述车载软件管理方法包括以下步骤：

步骤101、确定车载系统目标域控制器中软件包的类型。

其中，一个所述软件包封装有一个软件数据模块对应的可执行程序或插件程序，一个所述软件数据模块包括至少一项车载服务的软件数据。

本申请实施例中，开发端可以预先定义一种通用的软件包。之后，基于车载系统上多项车载服务的功能、类型的区别，可以将相关联的一项或者多项车载服务的软件数据确定为一个软件数据模块，并将一个软件数据模块对应的程序封装进上述软件包中。上述软件包在不同域控制器中的格式相同，因此可以对车载系统的所有域控制器软件包进行统一管理。例如，当软件包被启动时，软件数据模块对应的程序可以被执行，以实现一个或者多个相关联的车载服务。

进一步的，可以以域控制器为单位，对每一域控制器中的软件数据进行模块划分、软件包封装等。目标域控制器是指车载系统上任一域控制器，本申请实施例以目标域控制器中软件数据的管理为例进行说明。

根据目标域控制器内不同车载服务的不同属性，可以开发得到可执行程序或插件程序，插件程序不可单独执行。上述软件包既可以封装可执行程序，也可以封装插件程序，封装有不同程序的软件包类型不同，但格式相同。

具体实现时，车载系统可以基于软件包内封装的程序类型，先确定软件包的类型，之后继续执行步骤102。

步骤102、基于所述软件包的类型，对所述目标域控制器进行软件数据管理。

本步骤中，当软件包封装有可执行程序时，车载系统可以基于可执行程序的性质，对目标域控制器进行软件数据管理；当软件包封装有插件程序时，车载系统可以基于插件程序的性质，对目标域控制器进行软件数据管理。

可选地，上述软件数据管理可以包括但不限于：1)控制目标域控制器中车载服务的实现，具体实现时，车载系统可以通过控制软件包的下载、安装、加载、解析、启动等，来控制目标域控制器中车载服务的实现；2)控制目标域控制器中车载服务的升级，具体实现时，车载系统可以通过控制软件包的升级，来控制目标域控制器中车载服务的升级；3)控制目标域控制器中车载服务的移除，具体实现时，车载系统可以通过控制软件包的停止、卸载等，来控制目标域控制器中车载服务的移除。

可以理解的是，本申请实施例中，车载系统对目标域控制器进行软件数据管理的方式是基于具有统一格式的软件包进行的，因此可以在车辆的不同域控制器中复用相同的软件数据管理机制。相比基于不同域控制器的开发环境或属性，对不同域控制器执行不同机制的软件数据管理，本申请实施例，不同域控制器中的软件包格式相同，因此可以对整车域控制器软件包进行统一管理，从而可以兼容车载系统中所有车载服务的软件数据，不仅可以消除车辆中不同域控制器因开发环境造成的软件数据管理壁垒，还可以消除不同车载服务因服务特性造成的软件数据管理壁垒，简化了车辆软件系统的开发和管理，减少了开发人员的工作量，提高了车辆软件系统开发和管理的灵活性。

下面对本申请实施例中的软件包进行说明：

本申请实施例中，软件包的类型至少包括两种：封装有可执行程序的软件包，或者，封装有插件程序的软件包。软件包的类型不同，安装、启动、卸载、升级等机制也会存在区别。

软件包至少封装有可执行程序或者插件程序。针对可执行程序，可以包括一个程序，也可以包括一组程序。可选地，在确定软件数据模块的软件数据后，可以将所述软件数据模块的软件数据编译成动态库，再对所述动态库进行编译链接，得到可执行程序。针对插件程序，可以包括一个程序，也可以包括一组程序。可选地，在确定软件数据模块的软件数据后，可以将所述软件数据模块的软件数据编译成动态库，得到插件程序。

所述软件包还封装有目标信息，所述目标信息包括描述软件包的各项信息。具体实现时，所述目标信息可以由封装在软件包中的各种文件承载，车载系统在安装软件包后，软件包中封装的文件可以被解压到目标目录中，车载系统可以在目标目录中的文件中获取目标信息。

为了使车载系统在安装软件包后，可以快速获取软件包的类型，可选地，所述目标信息包括用于表征所述软件包的类型的第一类型信息或第二类型信息，所述第一类型信息用于表征所述软件包封装有可执行程序，所述第二类型信息用于表征所述软件包封装有插件程序。车载系统在安装软件包后，可以在目标目录中的文件中获取上述第一类型信息或第二类型信息，从而确定软件包的类型，进而确定对软件包的加载方式、解析方式、启动方式、停止方式、卸载方式等。

在一可选实施方式中，软件包中封装的文件中包括一描述文件，该描述文件中存储有软件包的基本信息，其中就可以包括上述第一类型信息或第二类型信息。进一步的，软件包的基本信息还可以包括但不限于以下至少一项：软件包的名称标识，例如软件数据模块对应的车载服务的名称、域控制器的名称等；软件包的版本标识，例如软件包版本号；软件包的体系架构；软件包的作者；软件包的大小；软件包依赖的其他软件包；与软件包存在冲突的其他软件包；软件包的提供商。

在服务开发过程中，开发人员可以预先配置不同类型的软件包对应的启动信息，上述启动信息包括启动参数和/或启动方式。可选地，上述目标信息还包括配置信息，配置信息包括软件包的启动信息。车载系统在安装软件包后，可以在目标目录中的文件中获取配置信息，并对配置信息进行解析，以获取软件包的启动信息，并根据启动信息，将软件包添加到域控制器的启动列表中，以对软件包进行启动。可选地是，在启动信息不包括启动方式，即开发人员未配置启动方式的情况下，车载系统可以基于系统默认的软件包的启动方式，对软件包进行启动。

在一可选实施方式中，软件包中封装的文件中包括一配置文件，该配置文件中存储有软件包的配置信息。进一步的，配置信息除了包括软件包的启动信息之外，还可以包括软件数据模块对应的车载服务的端口号、方法(method)、域(field)列表等。

在一可选实施方式中，在所述软件包封装有可执行程序的情况下，可执行程序的启动方式为：通过第一函数集启动所述软件包，所述第一函数集包括第一函数和第二函数。其中，所述第一函数为用于将程序分成至少两个相同的进程的函数，例如fork函数；所述第二函数为用于执行可执行程序的函数，例如exec函数族。

和/或，插件程序的启动方式为：通过第二函数集启动所述软件包，所述第二函数集包括所述第一函数、第三函数和第四函数。其中，所述第一函数为用于将程序分成至少两个相同的进程的函数，例如fork函数；第三函数为用于打开动态库的函数，例如dlopen函数，所述第四函数为用于加载动态库的函数，例如onStart函数。

在一可选实施方式中，在将上述信息封装成软件包后，可以对软件包进行签名，并将签名信息对应的签名文件也封装进软件包中。换言之，上述目标信息中还包括签名信息。签名信息可以保证软件包中内容的完整性和真实性，以及保证软件包不被篡改，提高软件包使用的安全性。

在一具体示例中，当软件包封装有可执行程序时，软件包中的内容可以如图2a所示，当软件包封装有插件程序时，软件包中的内容可以如图2b所示。

下面对本申请实施例中基于软件包，对目标域控制器的软件数据管理的方式进行说明。

本申请实施例中，可选地，上述软件数据管理可以包括但不限于：

1)控制目标域控制器中车载服务的实现。

具体实现时，车载系统可以通过控制软件包的下载、安装、加载、解析、启动等，来控制目标域控制器中车载服务的实现。在一具体示例中，车载系统在接收到某一车载服务的下载请求时，可以向服务端请求该车载服务对应的软件数据，服务端可以将封装有软件数据的软件包发送至车载系统。车载系统在获取软件包后，可以对软件包进行解压，将软件包中封装的文件解压到目标目录中。车载系统可以从解压得到的文件中确定软件包的类型，以及软件包的启动信息等。之后，车载系统可以根据软件包的类型和软件包的启动信息，对软件包进行启动。

2)控制目标域控制器中车载服务的升级。

可选地，车载系统可以控制目标域控制器中的车载服务进行SOTA升级。SOTA升级的颗粒度更小，可以实现仅针对目标域控制器中的某一软件包进行整体升级或迭代升级。相比对域控制器执行固件在线升级(Firmware over the air，FOTA)，SOTA升级更加适合敏捷开发，灵活度更高，且每次升级数据较少，车载系统所需的计算资源，以及网络传输所需的资源更少，效率更高，能够实现车载系统软件数据的快速迭代。示例性的，基于本申请实施例提供的软件包，车载系统中的自动驾驶域控制器(Automated-driving Control Unit，ACU)、通信互联域控制器(Telematics and Connectivity Antenna Modul,TCAM)等均可实现SOTA升级。

需要说明的是，基于软件包进行SOTA升级的具体实施方式可以参照相关技术中已有的软件包进行SOTA升级的流程，例如Android应用程序包(Android ApplicationPackage，APK)进行SOTA升级的流程，基于软件包进行SOTA升级的机制可以复用车载系统已有的SOTA升级机制，在此不赘述。

3)控制目标域控制器中车载服务的移除。

具体实现时，车载系统可以通过控制软件包的停止、卸载等，来控制目标域控制器中车载服务的移除。

下面介绍本申请实施例一种具体示例：

本示例中，开发端可以预先定义一通用软件包，并基于该软件包开发一套通用工具，包括但不限于软件包的封装工具、软件包的解析启动工具、软件包的安装卸载工具。这套工具可以提供给车辆制造商的开发人员，也可以提供给单个域控制器的硬件和/或软件供应商的开发人员。基于上述通用工具可以兼容不同的操作系统，以使本申请实施例提供的软件包可以在不同操作系统中运行，例如Windows系统、Linux系统、Qnx系统、Android系统等，实现对车载系统软件数据的统一管理。

本示例中，软件包的名称定义为Jet软件包(Jet Software Package)，格式为.jet，具体包括两种类型，分别为Jet可执行程序软件包(Jet Executable)，表示封装有可执行程序的软件包，以及Jet插件程序软件包(Jet Component)，表示封装有插件程序的软件包。其中，Jet Executable软件包中的内容如图2a所示，在一具体示例中，JetExecutable软件包中的内容如图3所示，分别说明如下：

bin:表示可执行程序文件目录，其中存储有一个或者一组可执行程序。

lib：表示动态库文件目录，其中存储有一个或者多个动态库文件，一个或者多个动态库可以对应一项车载服务。动态库文件的后缀可以显示服务的版本信息，例如libwindow_service.so.1.0.1。

etc:表示软件包运行时依赖的配置文件，配置文件中存储有配置信息，配置信息包括软件数据模块对应的车载服务的端口号、方法(method)、域(field)列表等，还包括软件包的启动参数和启动方式。

data：表示软件包的数据文件，存储有软件包所需的数据。

manifest.json：表示软件包的描述文件，存储有描述软件包的基本信息，可以包括但不限于：软件包的名称标识；软件包的版本标识；软件包的体系架构；软件包的作者；软件包的大小；软件包依赖的其他软件包；与软件包存在冲突的其他软件包；软件包的提供商。示例性地，为了区分不同域控制器上同名的软件包，可以将“域控制器名称+软件包名称”作为软件包的唯一标识信息。需要说明的是，Jet Executable软件包和Jet Component软件包的后缀均为.jet，可以通过manifest.json中的类型(type)字段进行区分。

sign：表示软件包的签名文件，其中的签名信息通过对上述lib、bin、etc、manifest.json中的内容进行签名得到。

以Jet Executable软件包为例，软件包的封装过程可以如图4所示，具体说明如下：

1)基于Windows服务(Windows Service)接口定义语言(Interface DescriptionLanguage，IDL)和Windows服务框架(Windows Service Skeleton)进行车载服务开发，将相关联的一项或多项车载服务的软件数据开发成一个软件数据模块。

2)一项服务可以编译得到一个动态库，一个软件数据模块中的一项或多项服务的软件数据可以编译得到一个或多个动态库，以动态库文件的形式存储在lib目录下。

3)将一个或多个动态库文件进行编译链接可以得到一个或一组可执行程序，存储在bin目录下。需要说明的是，针对Jet Component软件包，将服务的软件数据编译得到动态库即可，因此Jet Component软件包中可以没有bin目录。

4)开发人员可以手动配置软件包的配置信息和描述信息，分别生成配置文件和描述文件。Jet Executable软件包的配置文件可以存储在etc目录下预设的目录中，例如etc/exec.json目录中。Jet Executable软件包的启动信息可以包括：通过车载系统的init进程或者systemd进程加载和解析json文件，再通过fork函数和exec函数族启动软件包。此外，可以将“域控制器名称+软件包名称”作为软件包的唯一标识。

需要说明的是，Jet Component软件包的配置文件可以存储在etc目录下预设的目录中，例如etc/component.json目录中。Jet Component软件包的启动信息可以包括：先通过fork函数复刻出子进程，再通过dlopen函数打开json文件中指定的入口动态库，再通过onStart函数启动软件包。

5)软件包实质可以是一个压缩包，例如zip格式的压缩包，封装的过程就是把lib，bin、etc、manifest.json中的内容压缩成一个zip包。

6)对lib、bin、etc、manifest.json内的内容整体进行签名得到签名信息，并将签名信息对应的签名文件添加到zip包里面，得到软件包。

当软件包下载至域控制器内时，由域控制器根据实际需要对其进行安装、启动、停止、卸载等步骤。本示例中，如图5所示，域控制器中可以通过主板(Main Board)和软件包管理器(Package Manager)对软件包进行管理。需要说明的是，由于本申请实施例涉及的软件包为新定义的一种软件包格式，因此Main Board和Package Manager可以适应新的软件包格式进行底层开发，在此不赘述。

当域控制器接收到软件包的安装请求时，Package Manager可以对软件包进行安装，例如通过jet–install xxx命令安装名称为xxx的软件包。Package Manager可以根据需要维护一份域控制器内已经安装完成的软件包清单，用于整车软件管理时，尤其是SOTA升级时进行软件包版本收集和管理。软件包安装的根目录可以由域控制器自行确定。

在软件包安装完成后，当域控制器接收到软件包的启动请求时，Main Board可以根据软件包的启动信息对软件包进行启动。当域控制器接收到软件包的卸载请求时，MainBoard可以根据软件包的启动信息先将运行的软件包停止，再由Package Manager对软件包进行卸载，例如通过jet–uninstall xxx命令卸载名称为xxx的软件包。之后，PackageManager将根目录中的软件包对应的目录删除。

软件包的SOTA升级流程可以如图6所示，具体说明如下：

1)域控制器的SOTA从节点(SOTA Slave)安装新软件包或升级软件包。PackageManager进行安装/升级前的检查，包括但不限于：基于软件包中的签名信息验证软件包的合法性和完整性，以及检查域控制器当前的剩余空间以确定是否足够安装软件包。

2)在进行SOTA升级时，Package Manager还需要将已经安装的软件包的分区切换为可读可写，以便于对软件包数据进行更新。此外，Package Manager还需要停止正在运行的同名软件包。

3)在完成安装/升级前检查后，Package Manager可以将新的软件包或升级软件包安装到预设的目标目录中。

4)在安装/升级完成后，Package Manager可以恢复对应的分区为只读，并更新本地软件包安装列表。

软件包的启动流程可以如图7所示，具体说明如下：

软件包安装后，软件包中的配置文件和描述文件可以解压至预设的目录中，启动时，Main Board可以在预设的目录中获取配置文件和描述文件，并对其进行解析获取启动信息。之后，Main Board可以根据启动信息启动软件包。

Main Board可以基于第一启动命令启动Jet Executable软件包。具体示例中，Main Board可以通过init进程或者systemd进程加载和解析配置文件，例如json文件，再通过fork函数和exec函数族启动软件包。

Main Board可以基于第二启动命令启动Jet Component软件包。具体示例中，MainBoard可以先通过fork函数复刻出子进程，再通过dlopen函数打开配置文件，例如json文件中指定的入口动态库，再通过onStart函数启动软件包。

参见图8，图8是本申请实施例提供的媒体内容推荐装置的结构图。

如图8所示，车载软件管理装置800包括：

确定模块801，用于确定车载系统目标域控制器中软件包的类型，一个所述软件包封装有一个软件数据模块对应的可执行程序或插件程序，一个所述软件数据模块包括至少一项车载服务的软件数据；

管理模块802，用于基于所述软件包的类型，对所述目标域控制器进行软件数据管理。

可选地，所述管理模块包括：

升级单元，用于基于所述软件包的类型，对所述目标域控制器的软件数据进行软件在线升级SOTA。

可选地，所述软件数据模块对应的插件程序通过将所述软件数据模块的软件数据编译成动态库得到；

或者，

所述软件数据模块对应的可执行程序通过将所述软件数据模块的软件数据编译成动态库，再对所述动态库进行编译链接得到。

可选地，所述软件包还封装有目标信息，所述目标信息包括用于表征所述软件包的类型的第一类型信息或第二类型信息，所述第一类型信息用于表征所述软件包封装有可执行程序，所述第二类型信息用于表征所述软件包封装有插件程序。

可选地，所述目标信息还包括配置信息，所述配置信息包括所述软件包的启动信息；

所述管理模块包括：

解析单元，用于基于所述软件包的类型，获取所述配置信息，并对所述配置信息进行解析，得到所述启动信息；

启动单元，用于根据所述启动信息，对所述软件包进行启动。

可选地，所述启动单元包括：

第一启动子单元，用于在所述软件包封装有可执行程序的情况下，通过第一函数集启动所述软件包，所述第一函数集包括第一函数和第二函数；

或者，

第二启动子单元，用于在所述软件包封装有插件程序的情况下，通过第二函数集启动所述软件包，所述第二函数集包括所述第一函数、第三函数和第四函数；

其中，所述第一函数为用于将程序分成至少两个相同的进程的函数，所述第二函数为用于执行可执行程序的函数，所述第三函数为用于打开动态库的函数，所述第四函数为用于加载动态库的函数。

车载软件管理装置800能够实现如图1对应的方法实施例的各个过程，以及达到相同的有益效果，为避免重复，这里不再赘述。

根据本申请的实施例，本申请还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图9示出了可以用来实施本申请的实施例的示例电子设备900的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图9所示，设备900包括计算单元901，其可以根据存储在只读存储器(ROM)902中的计算机程序或者从存储单元908加载到随机访问存储器(RAM)903中的计算机程序，来执行各种适当的动作和处理。在RAM 903中，还可存储设备900操作所需的各种程序和数据。计算单元901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

设备900中的多个部件连接至I/O接口905，包括：输入单元906，例如键盘、鼠标等；输出单元907，例如各种类型的显示器、扬声器等；存储单元908，例如磁盘、光盘等；以及通信单元909，例如网卡、调制解调器、无线通信收发机等。通信单元909允许设备900通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元901可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元901的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元901执行上文所描述的各个方法和处理，例如车载软件管理方法。例如，在一些实施例中，车载软件管理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元908。在一些实施例中，计算机程序的部分或者全部可以经由ROM 902和/或通信单元909而被载入和/或安装到设备900上。当计算机程序加载到RAM 903并由计算单元901执行时，可以执行上文描述的车载软件管理方法的一个或多个步骤。备选地，在其他实施例中，计算单元901可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行车载软件管理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本申请的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。