CN105549416A - 子系统、机动车辆和将软件更新传输给机动车辆的系统 - Google Patents

Abstract

本发明涉及子系统、机动车辆和将软件更新传输给机动车辆的系统。本发明提供一种用于机动车辆的系统，其具有如下特征：无线地与后端（28）连接的车辆更新器（14），用于从后端（28）接收软件更新；运行时环境（18），用于解释软件更新并将软件更新从车辆更新器（14）传送给机动车辆（32）的控制设备，其中所述控制设备能够经由机动车辆（32）的通信总线被起动；以及虚拟车辆通信接口（26），用于将运行时环境（18）与机动车辆（32）的通信总线连接。本发明此外提供一种相应的机动车辆以及一种相应的用于将软件更新传输给机动车辆的系统。

Description

子系统、机动车辆和将软件更新传输给机动车辆的系统

技术领域

本发明涉及一种用于机动车辆的子系统。除此之外，本发明涉及一种相应的机动车辆以及一种相应的用于将软件更新传输给机动车辆的系统。

背景技术

在无线电技术中，数据借助于电磁波、即显然通过介质空气（空中（overtheair），OTA）的传输有时被称为空中接口。这样的“空中接口”的特征尤其在于，不使用诸如铜电缆或光纤电缆之类的固体传输介质，这针对后续实施的目的未排除真空中的传输。利用这样的传输的电信技术方案譬如作为空中编程（Over-the-Air，OTA）、空中服务提供（Over-the-AirServiceProvisioning，OTASP）、空中提供（Over-the-AirProvisioning，OTAP）或者空中参数管理（Over-the-AirParameterAdministration，OTAPA）已知。

所提到的技术对于更新所谓的固件、即嵌入到电子设备中的软件是特别重要的。上面提到的OTA技术的根据固件被适配的修改方案在电信中以上位概念“固件空中编程（Firmware-Over-the-Air，FOTA）”被概括。

DE10105454A1提出一种用于经由空中接口自动补充软件的方法，该方法用于用新软件模块对在系统上运行的软件进行补充，其中这些软件模块首先被测试并且然后从这些软件模块中导出应用模块。

发明内容

本发明提供根据独立权利要求的用于机动车辆的子系统、相应的机动车辆、以及相应的用于将软件更新传输给机动车辆的系统。

该解决方案的优越性在于其可以与现有车间解决方案共存，所述现有车间解决方案通常基于也被用作诊断测试器的所谓的车辆通信接口（vehiclecommunicationinterface，VCI），所述车辆通信接口的硬件设计要求例如由国际标准ISO22900-1:2008来定义。根据本发明，为此在车辆自身的子系统中仿真这样的接口，这仅仅需要将本身已知的运行时环境迁移到车辆中可用的硬件上。在此，软件更新自身由子系统的所谓的车辆更新器无线地得到。因此所导致的车辆通信接口的“虚拟化”允许在车辆的所涉及的控制设备上基本上不加改变地保留软件更新的打包及其最终的安装。其因此有利于所提出的技术的高认可度、短期引入和市场实施。

本发明的另外的有利的构型在从属权利要求中予以说明。这样，譬如车辆更新器和运行时环境可以在机动车辆的极其不同的控制设备之内实现，包括该机动车辆的中央网关、连通性控制设备、域控制设备、头部单元或者车载计算机，其中中央网关被证明是车辆更新器的特别有利的硬件平台。子系统的分布在多个控制设备上的实现也是完全可设想的。因此，所提出的方案可以被转用于多种具有极其不同的控制设备配置的车辆模型。

特别有利的是，在硬件上有管理程序可用。在这种情况下，车辆更新器和运行时环境可以被构成为虚像，并且因此在正常行驶运行中保持去激活。只有当需要该功能时，该功能才被加载并且在虚拟环境中被实施。该方案关于运行安全性和数据保护也具有积极的方面。

所述子系统合理地包括与车辆更新器连接的用于暂存软件更新的数据缓冲器。这样，所涉及的控制设备的软件下载和实际更新的过程步骤也可以在时间上尽可能去耦合，这提高鲁棒性并且即使在空中接口中断的情况下也使得能够执行软件更新。

当运行时环境对应于ISO-22900并且子系统包括用于起动（Ansprechen）车辆通信接口的协议数据单元编程接口、以及用于借助协议数据单元编程接口来操作车辆通信接口的可由车辆更新器经由运行时环境来起动的模块化车辆通信接口服务器时，可以实现符合标准性。用于起动车辆通信接口的遵循国际标准SAEJ2534/1的推荐的PassThru编程接口附加地扩展子系统的硬件兼容性。

关于运行时环境的运行，Linux的利用被证明是特别合理的变型方案，因为这些运行时环境的几个制造商同样提供兼容Linux的实现。

最后，为了将运行时环境与通信总线连接所需要的配置数据（哪个控制设备可以经由哪个总线被起动、协议等等）有利地从运行时环境的数据中获取。因此，取消易错的单独的数据保持。

附图说明

本发明的实施例在附图中予以示出并且在下面予以进一步描述。

唯一的图示出根据本发明的一种实施方式的用于将软件更新传输给机动车辆的系统的框图。

具体实施方式

图1借助简化框图图解所提出的用于将软件更新传输给机动车辆32的系统30的示意性构造。根据所示出的实施方式的系统30被划分成两个位置上分离的子系统：无线地与机动车辆32连接的用于分发软件更新的后端28、以及在机动车辆32自身之内实现的用于借助于所述软件更新来更新机动车辆32的（本身未以绘画方式示出的）控制设备的子系统10。在此，控制设备经由至少一个通信总线互相连接，并且可以经由该总线分别有针对性地被起动。

车辆内部的子系统10当前被实现在控制设备下的中央网关之内，并且经由连通性控制设备12无线地与后端28连接。在此，子系统10的中央车辆更新器14用于从后端28接收软件更新，该中央车辆更新器将所接收的更新暂存在所连接的数据缓冲器16中以用于进一步使用。为此，网关包括管理程序，该管理程序为了按需要实施车辆更新器14而提供Linux来宾系统下的运行时环境18。

一旦实际的更新被导入，则同样被子系统10包括的符合ISO-22900的运行时环境18就将软件更新从车辆更新器14传送给要更新的控制设备，该控制设备利用其通信总线经由虚拟车辆通信接口26被连接。为此，该虚拟车辆通信接口根据所述标准通过模块化车辆通信接口服务器（MVCI）20经由协议数据单元编程接口（PDU-API）22被起动。车辆通信接口26直接从运行时环境18中得到为此需要的配置数据，使得根据所涉及的控制设备而不是协议数据单元编程接口22，可以按需要使用替代的与标准SAEJ2534/1相对应的PassThru编程接口24。

Claims (10)

1.用于机动车辆（32）的系统（10），

其特征在于如下特征：

-无线地与后端（28）连接的车辆更新器（14），用于从所述后端（28）接收软件更新，

-运行时环境（18），用于解释所述软件更新并将所述软件更新从所述车辆更新器（14）传送给所述机动车辆（32）的至少一个控制设备，其中所述控制设备能够经由所述机动车辆（32）的至少一个通信总线被起动，以及

-虚拟车辆通信接口（26），用于将所述运行时环境（18）与所述机动车辆（32）的通信总线连接。

2.根据权利要求1所述的子系统（10），

其特征在于，

所述车辆更新器（14）或者所述运行时环境（18）在所述机动车辆（32）的如下的另外的控制设备之一之内实现：

-中央网关，

-连通性控制设备（12），

-域控制设备，

-头部单元，或者

-车载计算机。

3.根据权利要求2所述的子系统（10），

其特征在于，

所述另外的控制设备具有用于按需要实施所述车辆更新器（14）的管理程序。

4.根据权利要求1至3之一所述的子系统（10），

其特征在于，

所述子系统（10）包括与所述车辆更新器（14）连接的用于暂存所述软件更新的数据缓冲器（16）。

5.根据权利要求1至4之一所述的子系统（10），

其特征在于，

所述运行时环境（18）对应于ISO-22900，并且所述子系统（10）包括如下特征：

-协议数据单元编程接口（22），用于起动所述车辆通信接口（26），以及

-能够由所述车辆更新器（14）经由所述运行时环境（18）起动的模块化车辆通信接口服务器（20），用于借助于所述协议数据单元编程接口（22）操作所述车辆通信接口（26）。

6.根据权利要求5所述的子系统（10），

其特征在于，

所述子系统（10）此外包括与SAEJ2534/1相对应的用于起动所述车辆通信接口（26）的PassThru编程接口（24）。

7.根据权利要求5或6之一所述的子系统（10），

其特征在于，

所述子系统（10）包括用于运行所述运行时环境（18）的Linux操作系统。

8.根据权利要求1至7之一所述的子系统（10），

其特征在于，

所述子系统（10）被配置，使得所述车辆通信接口（26）从所述车辆更新器（14）得到为了将所述运行时环境（18）与所述通信总线连接所需要的配置数据。

9.机动车辆（32），

其特征在于如下特征：

-多个控制设备；

-至少一个将所述控制设备连接的通信总线，用于起动所述控制设备，以及

-根据权利要求1至8之一所述的子系统（10），用于借助于软件更新来更新所述控制设备。

10.用于将软件更新传输给机动车辆（32）的系统（30），

其特征在于如下特征：

-无线地与所述机动车辆（32）连接的后端（28），用于分发所述软件更新，以及

-在所述机动车辆（32）之内实现的根据权利要求1至8之一所述的子系统（10），用于借助于所述软件更新来更新所述机动车辆（32）的控制设备。