CN102955708B - 软件更新的方法和装置 - Google Patents

Abstract

本发明公开了一种用于软件更新的方法的方法，包括接收恢复指令以恢复车辆计算机系统(VCS)的系统状态。该方法还包括恢复基础系统状态至已知的、运转的状态并且获取先前在该VCS上安装的应用程序的清单。该方法还包括针对先前在该VCS上安装的每个应用程序，搜索与该恢复的基础系统状态兼容的应用程序的版本。此外，该方法包括安装与该恢复的基础系统状态兼容的每个应用程序的版本。

Description

软件更新的方法和装置

技术领域

本发明中的说明性实施例总体上涉及用于软件更新的方法和装置。

背景技术

随着计算机技术的进步不断出现新的机会，经常需要更新操作系统。形成平台的主干的操作系统使计算机系统的所有组件一起进入运转基础(functioning base)，可从该运转基础运行多个软件应用程序。

PC操作系统经常有很多更新可用。为了更好地使用现有资源或为了最佳地使用新的可用的技术，操作系统更新能提供不断改进的基础，能在该基础上建立终端用户体验。无论是全新的操作系统还是对现有系统的版本更新，用户有很多原因可能希望在PC上更新操作系统。

在计算机平台的PC-模型中，一旦购买了PC，通常由用户决定更新操作系统。由于一旦作出首次购买之后制造商通常与PC很少或没有联系，用户必须依赖他们自己的需要和行动提供对系统的更新。一些操作系统可能自动下载为其提供的新补丁及更新，可是同样通常是用户发起此自动更新处理并且用户负责确保现有软件产品将与新的操作系统兼容。

然而，现在存在另一个模型，即移动计算机。设备(例如PDA、智能手机甚至车辆)可能在其中携带移动计算机系统，并且在很多情况下这些设备的提供者将还有既得利益来确保该设备的后续功能。

例如，智能手机不仅作为便携式计算机设备，而且它还作为可作出蜂窝电话呼叫的平台。由于通常存在与设备相关联的服务协议(通常用于无线通讯(cellular)和数据传输服务两者)，为了服务提供者的最好利益应当确保在设备上按需要执行操作系统更新。

同时，与个人计算机一样，软件开发者不断地开发在移动计算设备上使用的应用程序。由于很多这些设备可能在为装置开发的特定应用程序的特性和细节上仅具有有限的约束，设备的制造商/提供者可能难以确保所有的应用程序与新操作系统或操作系统版本兼容。所以，改变操作系统可能导致应用程序的功能不同或者完全失去功能性。

因此，当更新操作系统时用户通常有责任确保下载并安装特定应用程序的新版本。类似地，开发者必须确定应用程序保持最新以便于在操作系统软件/固件的新版本上起作用。

然而，不同于PC领域，因为移动计算机领域的设备提供者通常与使用他们产品的消费者保持更密切的关系，如果操作系统更新使一个或多个安装在移动计算机装置上的应用程序失效或使其不可使用时，消费者们倾向于误以为是系统提供者的问题。

发明内容

在第一个说明性实施例中，计算机可执行的方法包括接收恢复指令以恢复车辆计算机系统(VCS)的系统状态。该说明性方法还包括将基础系统状态恢复为已知的、运转的状态并且获取先前在该VCS上安装的应用程序的清单。

在此实施例中，该说明性方法还包括针对先前在该VCS上安装的每个应用程序，搜索与该恢复的基础系统状态兼容的应用程序的版本。此外，该说明性方法包括安装与该恢复的基础系统状态兼容的每个应用程序的版本。

在第二说明性实施例中，机器可读的存储介质存储有当执行时使VCS的处理器执行下述方法的指令，该方法包括接收恢复指令以恢复VCS系统状态。该方法还包括将基础系统状态恢复为已知的、运转的状态并且获取先前在该VCS上安装的应用程序的清单。

在此实施例中，该方法还包括针对先前在该VCS上安装的每个应用程序，找到与该恢复的基础系统状态兼容的该应用程序的版本。该方法还包括安装与该恢复的基础系统状态兼容的每个应用程序的该版本。

在第三说明性实施例中，系统包括VCS、诊断服务工具(DST)以及远程全局车内信息系统(GIVIS)。在此实施例中，DST操作用于产生恢复指令至GIVIS。

此外，在此实施例中，当接收到该恢复指令时，该GIVIS可操作用于下载并在该VCS上安装已知的、运转的VCS操作系统。安装该操作系统之后，该VCS进一步操作用于与该GIVIS通信以针对先前在该VCS上安装的每个应用程序接收与安装的操作系统兼容的该应用程序的最新版本。此外，该GIVIS可操作用于指示安装与在该VCS上安装的操作系统兼容的每个应用程序的最新版本。

附图说明

图1显示了车辆计算机系统的说明性示例；

图2显示了软件维护生态系统(ecosystem)的说明性示例；

图3显示了软件维护模型的说明性示例；

图4显示了软件更新处理的说明性示例；

图5显示了第二软件更新处理的说明性示例；

图6显示了恢复处理的说明性示例；

图7显示了操作系统更新处理的说明性示例。

具体实施方式

根据需要，本说明书中公开了本发明具体的实施例；但是，应理解公开的实施例仅为本发明的示例，其可以多种替代形式实施。附图无需按比例绘制；可放大或缩小一些特征以显示特定部件的细节。所以，此处所公开的具体结构和功能资料不应解释为限定，而仅为教导本领域技术人员以多种形式实施本发明的代表性基础。

图1说明了用于车辆31的基于车辆的计算机系统的示例框式拓扑图。这样的基于车辆的计算机系统1的示例是由福特汽车公司制造的SYNC系统。设有基于车辆的计算机系统的车辆可包括位于车辆里的可视前端界面4。如果设有可视前端界面，则用户可和所述界面(例如触摸屏)交互。在另一说明性实施例中，可通过按压按钮、可听语言和语音合成进行交互。

在图1所示的说明性实施例中，处理器3至少控制基于车辆的计算机系统的操作的一部分。设于车内的处理器允许车载地处理指令和程序。进一步地，所述处理器连接到非持久存储器5和持久存储器7。在这个说明性实施例中，所述非持久储存器是随机存取存储器(RAM)并且所述持久存储器是硬盘驱动器(HDD)或闪存。

所述处理器还设有允许用户和所述处理器交互的许多不同的输入。在这个说明性实施例中，提供了话筒29、辅助输入25(用于输入33)、USB输入23、GPS输入24和蓝牙输入15中的全部。也提供了输入选择器51，以允许用户在多种输入之间切换。话筒和辅助连接器两者的输入在传给处理器之前通过转换器27从模拟信号转换为数字信号。虽然未示出，与VCS通信的多个车辆部件和辅助部件可使用车辆网络(比如，但不限于CAN总线)向VCS(或者它的部件)传输数据或从其传输数据。

系统的输出可包括但不限于，视觉显示器4和扬声器13或立体声系统的输出。扬声器和放大器11相连并且通过数字模拟转换器9从处理器3接收其信号。输出也可沿分别如19、21处所示的双向数据流向远程蓝牙装置(比如PND54)或USB装置(比如车辆导航装置60)进行输出。

在一个说明性实施例中，系统1使用蓝牙收发器15和用户的漫游设备53(例如蜂窝电话、智能手机、PDA或具有无线远程连接的任何其它装置)通信17。漫游设备随后可用于通过与例如蜂窝塔57的通信55来与车辆31外部的网络61通信59。在一些实施例中，塔57可为WiFi接入点。

在漫游设备和蓝牙收发器之间的示例性通信可通过信号14表示。

可通过按钮或相似的输入指示漫游设备53和蓝牙收发器15的配对52。这样，指示CPU车载的蓝牙收发器将与漫游设备里的蓝牙收发器配对。

可利用例如与漫游设备53关联的数据计划(data-plan)、声载数据或双音多频(DTMF)音调在CPU3和网络61之间通信数据。可替代地，可希望包括具有天线18的车载调制解调器63以在CPU3和网络61之间通过声音频带传送16数据。漫游设备53随后可用于通过和例如蜂窝塔57的通信55来和车辆31外部的网络61通信59。在一些实施例中，调制解调器63可建立和塔57的通信20用于和网络61通信。作为非限制性的示例，调制解调器63可以是USB蜂窝式调制解调器并且通信20可以是蜂窝无线通信。

在一个说明性实施例中，处理器设有包括与调制解调器应用软件通信的API的操作系统。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件以完成和远程蓝牙收发器(比如设在漫游设备里的)的无线通信。蓝牙是IEEE 802 PAN(个人局域网)协议的子集。IEEE 802 LAN(局域网)协议包括WiFi并且与IEEE 802 PAN有相当多的交叉功能。两者都适合用于车辆中的无线通信。在此范围中可使用的另一个通信方法是自由空间光通信(例如红外数据组织(IrDA))和非标准的消费者IR(红外)协议。

在另一实施例中，漫游设备53包括用于声音频带或宽带数据通信的调制解调器。在声载数据的实施例中，可执行已知的频分复用技术，此时漫游设备的所有者可在正在传输数据时通过所述装置通话。在其它时间，当所有者没有使用所述装置时，数据传输可使用所有的带宽(在一个示例中是300Hz到3.4kHz)。尽管频分复用对于车辆和互联网之间的模拟蜂窝通信很普遍并且仍然在使用，但它已经主要被用于数字蜂窝通信的码域多址(CDMA)、时域多址(TDMA)和空域多址(SDMA)的混合所取代。这些均是遵从ITU IMT-200(国际电信联盟国际移动通信-2000)(3G)的标准，并且对于静止或步行的用户提供高达2mbs的数据速率，对于移动的车辆中的用户提供高达385kbs的数据速率。3G标准现在正在被对车辆中的用户提供100mbs并对静止的用户为1gbs的IMT-Advanced(4G)取代。如果用户有和漫游设备关联的数据计划，则数据计划可允许宽带传输并且所述系统可使用宽得多的带宽(加速数据传输)。在另外一个实施例中，用安装在车辆31上的蜂窝通信装置(未示出)代替漫游设备53。在另一个实施例中，漫游设备(ND)53可以是能通过例如(但不限于)802.11g网络(即WiFi)或WiMax网络通信的无线局域网(LAN)装置。

在一个实施例中，接收到的数据可通过声载数据或数据计划穿过漫游设备，穿过车载蓝牙收发器并且流入车辆的内部处理器3。作为示例，在某些临时数据的情况下，数据能存储在HDD或其它存储媒体7上直到不再需要所述数据。

其它可和车辆交互的源包括具有例如USB连接56和/或天线58的个人导航装置54；或者具有USB62或其它连接的车辆导航装置60，车载GPS装置24或和连接至网络61的远程导航系统(未示出)。USB是串行网络协议的分类的一个。IEEE 1394(火线)、EIA(电子工业协会)串行协议、IEEE 1284(并行端口)、S/PDIF(索尼/飞利浦数字互相连接格式)和USB-IF(USB制订人论坛)形成装置与装置(device-device)串行标准的主要部分。针对电子或光通信可执行所述大多数协议。

此外，CPU能和各种其它的辅助装置65通信。这些装置可通过无线连接67或有线连接69来连接。辅助装置65可包括，但不限于，个人媒体播放机、无线健康装置、便携式计算机等。

额外或可替代地，CPU可基于无线路由器73使用例如WiFi71收发器和车辆连接。这可允许CPU连接到本地路由器73的范围内的车辆。

除了具有通过位于车内的车辆计算机系统执行的示例性处理，在特定实施例中，示例性处理可通过和车辆计算机系统通信的计算机系统执行。这种系统可包括但不限于无线装置(例如但不限于移动电话)或者通过无线装置连接的远程计算机系统(例如但不限于服务器)。共同地，这种系统可被称为车辆关联计算机系统(VACS)。在某些实施例中，根据系统的特定实施，VACS的特定组件可执行处理的特定部分。通过示例但不限制的方式，如果处理具有与配对的无线装置发送或接收信息的步骤，那么无线装置有可能不执行处理，因为无线装置不能与自己发送和接收信息。本技术领域内的普通技术人员应理解何时不适合将特定的VACS应用于给定的解决方案。所有的解决方案中，可预想至少位于车内的VCS自身能执行示例处理。

图2显示了软件维护有机系统的说明性示例。此说明性实施例显示了VCS、消费者设备、经销商/服务中心、OEM装配以及模块供应商之间关系的一个非限制性示例。

在此示例中，移动计算机平台的核心是VCS模块299。此模块代表安装在VCS上的操作系统的当前版本以及任何也安装在该系统中的应用程序和应用程序版本。此模块(特别是操作系统)的更新应该尝试保持尽可能大的兼容性，以便于应用程序以用户期望的方式运转并且避免不能使用。

此模块的初始配置的一个点可以是OEM装配工厂260。在车辆装配期间的某个点，可通过例如无线访问点265将多个软件应用程序安装在VCS模块299上。无线访问点能从新的工厂底层系统(PFS)263接收要安装的特定软件“部件”。PFS可接收来自车内软件(IVS)系统240的模块软件部件，该IVS系统也能向GIVIS(全局车内信息系统)系统220发送这些部件(或至少这些部件的记录)。

例如但不限于，如果在车辆中检测到导航系统，则VCS模块将会知道它需要一个或多个对应于导航系统的软件部件。该模块然后能从PFS请求需要的部件。

一旦安装了所有的软件部件，VCS模块能将模块资料传送回至终端线路(endline)系统267，该终端线路系统将那些资料中继至EOLX(线路终端X)261。这也能作为成功安装所有软件部件的确认。可将该信息从EOLX发送至GIVIS系统220，以便于能具有模块资料的全面记录。

当正在进行初始安装时，模块供应商280可提供模块(包括特定模块使用的安全密码)以和VCS模块一起使用。模块供应商制造(MSM)系统281可这些模块以未预分配(unprovisioned)状态发送至VCS模块。此外，该系统281可将改善的供应商供给发送至全局电子商务中心(GEC Hub)270，并且来自该中心的数据可存储在GIVIS系统中以维护用于与VCS模块一起使用而安装的模块/安全密码的记录。

除了存储从EOLX中继的模块资料，GIVIS能中继模块属性(例如安全密码)至车内安全系统230。系统230能为穿过GIVIS的信息提供加密/解密的功能，并且通过作为从GIVIS去除的一个级别而提供额外的安全层。

经销商250可在车辆装配和模块初始化之后的某个点具有为其提供的诊断工具系统251。此系统可向USB驱动器255提供用于应用程序安装的指令(以及应用程序数据)，经销商处的技术人员可使用该驱动器来在VCS模块上安装应用程序和其它软件。

可通过OBD(车载诊断)-II接口253发送安装记录以维护安装的应用程序和/或应用程序版本的日志。此外，技术人员可使用OBD-II接口来恢复VCS模块至未预分配状态，并且例如在恢复后进一步分配该模块。用于恢复该模块并分配该模块的软件和/或指令可来自诊断系统，该诊断系统也可接收从OBD-II接口中继至GIVIS的安装日志的备份。一旦安装了所有的应用程序并且分配了该模块，可将模块/应用程序状态从车辆中继至GIVIS。

消费者设备200(在此示例中也就是从消费者PC201接收数据的USB驱动器203)也可与VCS模块交互。消费者PC可能具有在模块上可使用/可安装的软件更新，并且此数据可发送至USB驱动器以安装进该模块中。

消费者PC可从网络门户(web portal)系统210接收此软件数据，网络门户(webportal)系统210可被告知来自GIVIS系统的更新，GIVIS系统应当至少通过追踪日志和存储模块资料知道特定VCS模块的当前状态。

一旦从USB驱动器将数据安装在VCS模块中，可将安装日志从VCS模块发送至USB驱动器，中继至家用PC并且从家用PC发送至网络门户系统。然后网络门户系统可将该信息中继至GIVIS系统以维护在VCS模块上安装的软件的当前记录。

图3显示了软件维护模型的说明性示例。在此说明性实施例中，GIVIS系统301可访问SMR(SyncMyRide)/ENGINE(引擎)/APA(亚太地区)系统305以确定关于VCS模块可安装的应用程序的可用版本308。

GIVIS系统还可与集成诊断软件(IDS)/职业技师社团(PTS)/电子技术信息系统(ETIS)/技术服务信息(TSI)系统303交互以提供可安装于VCS模块的可用应用程序306(例如，不限于免费的和先前购买的应用程序的版本)。与系统303的通信还可包括获取最新通信304。

在获取最新通信中，系统确定带有用于模块最新状态的软件包的最近(例如但不限于最新的)版本的安装包。

在至少一个示例中，可安装具有第一组特点的软件的“免费”版本。这将是软件谱系(lineage)的分支A。在此版本中可向软件提供更新以保持兼容，并且只要用户选择保持软件的第一版本则不会产生费用。

此外，在某个点也可使用软件的第二“付费”版本，第二“付费”版本具有另一组特点或第一组特点的增强版本。这将是软件谱系的分支B。

如果用户选择保持使用免费版本，那么“获取最新”指令可前进至分支A谱系的末尾处，保存软件版本的免费状态，同时跳过间歇的更新以安装该分支的最新版本。

另一方面，如果用户在某个点分支到分支B，则安装软件的付费版本，“获取最新”可检索那个分支的最新版本。

作为替代，如果执行“获取可用(get available)”指令，则可向用户显示保持软件的免费版本或改变为软件的付费版本的选项(如果选项都可用并且与VCS模块的当前状态兼容)。

在另一个示例中，当多个模块彼此交互时可出现分支以保持兼容性。与其它应用程序交互的某些软件应用程序的安装可能需要安装与该特定软件应用程序交互的应用程序的新版本。当接收到获取最新指令时，系统可获取这些应用程序中的与其它交互的应用程序保持兼容的任何应用程序的最新版本。当接收到获取可用指令时，系统可仅获取与其它安装的、交互的应用程序保持兼容的特定应用程序的可用版本。

可将应用程序和应用程序的新版本从生命周期系统(LCS)307提供至GIVIS系统。通过与LCS系统310通信，GIVIS系统可基于执行的是哪个指令(例如获取最新、获取可用、恢复等)确定适合呈现哪个应用程序以及应用程序的版本。IVS系统可将实际应用程序呈现至GIVIS系统。

系统303和GIVIS系统之间处理的恢复指令302将VCS模块的运转状态恢复为已知的工作状态或具体的版本。当然，这会导致与在VCS模块上安装的现有软件不兼容，所以获取最新指令通常与恢复指令一起处理。处理获取最新指令应该帮助确保随后获取所有现有软件的兼容版本，并在新的恢复VCS模块上安装所述兼容版本，并且应该保持关于恢复状态的功能。

图4显示了软件更新处理的说明性示例。在此说明性示例中，在401，作出对操作系统、应用程序、BIOS等的最新版本的请求。例如，软件应用程序经常具有与其关联的谱系。软件的版本号可确定特定版本在谱系中位于哪儿、初始软件是什么、已经作出什么配置或更新决定、以及什么未来版本或更新是可用的并与该版本兼容。在某些实例中，谱系基于配置和安装的部件分支，并且从那点向下的谱系可向下延续与先前安装的版本对应的特定分支。

在图4显示的处理中，响应于对最新版本的请求，在403，忽略现有软件向前的谱系。也就是，将既不安装软件的“下一”版本，也不会安装沿当前谱系位置和分支末尾之间的谱系的任何更新。相反，在405，处理前进至现有分支的末尾并且找到与模块兼容的软件的最新版本并安装这个版本。

图5显示了第二软件更新处理的说明性示例。在此说明性示例中，在501，作出对模块可用更新的请求。响应于该请求，在507，在503的所有免费的应用程序以及在505的先前购买的应用程序的清单被汇集并被提供给用户。然后，用户可细读该清单并且选择哪些应用程序及那些应用程序的哪些版本应该安装在模块上。

如之前讨论的，软件的不同版本可提供不同的选项和谱系。例如，用户可通过获取可用的指令选择软件的某些版本，并且然后进一步执行获取最新指令以确保选择的版本的最新的、兼容形式安装在移动计算机系统上。

图6显示了恢复处理的说明性示例。在601，当接收到恢复请求时，处理将首先在401、403、405处获取操作系统和/或BIOS的最新版本用于安装。

在VCS中安装最新兼容版本后，然后在501、503、505，处理将找到先前安装在VCS上的所有免费和购买的应用程序。然而，代替将这些作为选项向用户显示，可针对每个发现的与先前安装的应用程序对应的可用应用程序执行获取最新指令。从而，基于最近恢复的操作系统/BIOS状态，系统将安装所有先前安装的应用程序的最新的、兼容的版本。在603，可再次确认这些应用程序的兼容性，并且在这些应用程序与响应于恢复请求而安装的操作系统/BIOS兼容的情况下安装这些应用程序。

在之前安装的应用程序与新安装的操作系统之间存在任何不兼容的情况下，在605，系统将向用户报告不兼容以便于用户意识到那些应用程序在新系统上可能不运转。

图7显示了操作系统更新处理的说明性示例。在此说明性示例中，在701，检测到操作系统的更新。因为可能与安装的应用程序存在不兼容，在703，可确定是否有现有的应用程序安装在移动计算机平台上。

如果没有安装应用程序，或者如果所有安装的应用程序与新更新的操作系统兼容，则处理退出。这与常见的计算机环境不同，在常见计算机环境中用户必须通过手动检查一些或所有应用程序的持续兼容性来确保应用程序的现有的兼容性。

在703，如果存在至少一个未验证的应用程序，则在705，处理检查那个应用程序以在707确保兼容性。在至少一个示例中，此处理的提供者将知道应用程序的哪个版本与操作系统的哪个版本相兼容，并且应用程序版本号可用于确定那个应用程序的兼容性。

在707，如果应用程序在当前版本中是不兼容的，则在709，处理确定应用程序的兼容版本是否可用。此版本可对应于应用程序的下一版本，或可以是从该安装的应用程序的当前版本起的谱系进一步向下的版本。

在711，可在此点下载兼容版本至平台。此版本可对应于应用程序的第一兼容版本，或者它可对应于超过第一兼容性的位置的应用程序的更加新的可用的版本。这样，不仅可向用户提供兼容版本，还可向他们提供最新版本的兼容的应用程序。然后在713，在平台上安装应用程序的新版本并且处理继续检查不兼容的应用程序。

如果在707应用程序不兼容并且在709不存在应用程序的兼容版本，则在715，可通知用户特定应用程序没有已知的兼容版本，并且将至少暂时停用。然后用户可检查未来兼容版本或是处理本身能够周期性地检查兼容版本。

额外地或可替代地，可远程存储系统配置，并且一旦开发出应用程序的兼容版本，可将新版本通知给所有先前停用该应用程序的系统，或者甚至在其上自动安装新版本。

尽管上文描述了典型的实施例，并非意味着这些实施例说明并描述了本发明的所有可能形式。相反，说明书中使用的词语为描述性词语而非限定，并且应理解在不脱离本发明的精神和范围的情况下可作出各种改变。另外，可组合各种执行实施例的特征以形成本发明进一步的实施例。

Claims (9)

1.一种用于软件更新的装置，包括：

车辆计算机系统(VCS)；

诊断服务工具(DST)；以及

远程全局车内信息系统(GIVIS)；

其中，所述诊断服务工具操作用于产生恢复指令至所述远程全局车内信息系统，

其中，当接收到所述恢复指令时，所述远程全局车内信息系统操作用于基于在车辆装配期间记录的软件部件安装记录和/或车辆的安装日志来下载并将已知的、运转的车辆计算机系统操作系统安装在所述车辆计算机系统上；

其中，在安装所述操作系统之后，所述车辆计算机系统还操作用于与所述远程全局车内信息系统通信以针对先前在所述车辆计算机系统上安装的每个应用程序接收与所述安装的操作系统兼容的所述应用程序的最新版本，并且通过车辆中的车载诊断接口(OBD-II)将安装后的安装日志发送至所述诊断服务工具，以由所述诊断服务工具将安装后的安装日志中继至所述远程全局车内信息系统以进行备份；

其中，所述远程全局车内信息系统操作用于指示在所述车辆计算机系统上安装与所述安装的操作系统兼容的每个所述应用程序的所述最新版本。

2.根据权利要求1所述的装置，其特征在于，所述远程全局车内信息系统还操作用于在所述应用程序中的一个或多个没有与所述安装的操作系统兼容的版本的情况下指示所述车辆计算机系统以通知用户。

3.根据权利要求1所述的装置，其特征在于，保存应用程序的谱系以使与所述安装的操作系统兼容的所述应用程序的所述最新版本来自于与先前安装的所述应用程序的版本相同的谱系。

4.根据权利要求1所述的装置，其特征在于，所述远程全局车内信息系统操作用于一旦已经安装所述应用程序的所述版本则记录系统配置，所述系统配置至少包括所有安装的应用程序的版本。

5.根据权利要求4所述的装置，其特征在于，所述远程全局车内信息系统操作用于为多个车辆中的每个车辆存储从所述车辆计算机系统报告的所述系统配置。

6.根据权利要求5所述的装置，其特征在于，针对车辆识别号码存储所述系统配置。

7.一种用于软件更新的方法，包括：

接收恢复指令以恢复车辆计算机系统(VCS)的系统状态；

基于在车辆装配期间记录的软件部件安装记录和/或车辆的安装日志来下载并将操作系统和/或BIOS恢复为已知的、运转的状态；

获取之前在车辆计算机系统上安装的应用程序的清单；

针对先前在车辆计算机系统上安装的每个应用程序搜索与响应于恢复指令而安装的操作系统和/或BIOS兼容的应用程序的版本；以及

安装与响应于恢复指令而安装的操作系统和/或BIOS兼容的每个应用程序的版本；

通过车辆中的车载诊断接口(OBD-II)获得安装后的安装日志以进行备份。

8.根据权利要求7所述的方法，其特征在于，应用程序包括免费应用程序。

9.根据权利要求7所述的方法，其特征在于，应用程序包括购买的应用程序。