CN113691623B - 车载Tbox的软件配置方法、装置及云端平台 - Google Patents

Abstract

本申请涉及新能源汽车技术领域，特别涉及一种车载Tbox的软件配置方法、装置及云端平台，其中，方法包括：获取当前车辆的整车配置信息，并发送整车配置信息至当前车辆的车载Tbox，使得基于整车配置信息对当前车辆进行配置；在配置完成后，发送当前车辆对应的远程指令，以使车载Tbox将远程指令中的CAN报文信息上传至当前车辆的CAN网络；获取车载Tbox从CAN网络中采集与远程指令对应的执行信息，并根据执行信息得到远程指令的执行结果。由此，解决了相关技术中不同车型的Tbox软件需要不同厂家独立开发，导致开发成本以及售后维护较高，容易出现人工操作失误等问题。

Description

车载Tbox的软件配置方法、装置及云端平台

技术领域

本申请涉及新能源汽车技术领域，特别涉及一种车载Tbox的软件配置方法、装置及云端平台。

背景技术

随着新能源汽车行业的发展，车企新车型开发速度不断加快，Tbox(Telematicsbox，远程信息处理控制器)作为车与监控后台的桥梁，会随着整车采集信号的变更、车控需求的扩展不断新开发，以满足企业监控及用户远程监控的需求。

然而，目前不同车型Tbox接收整车CAN网络数据不完全相同，Tbox需要执行的远程控制命令也不完全相同。随着大数据的发展趋势，要求后台监控数据不断扩展，必然引发终端Tbox软件不断变更及后台TSP(Telematics Service Provider，汽车远程服务提供商)的适配开发，大大增加了开发费用；且零件号、软件版本不断增多，也会加大售后维护成本，一定程度上增大操作出错的概率。

申请内容

本申请提供一种车载Tbox的软件配置方法、装置及云端平台，以解决相关技术中不同车型的Tbox软件需要不同厂家独立开发，导致开发成本以及售后维护较高，容易出现人工操作失误等问题。

本申请第一方面实施例提供一种车载Tbox的软件配置方法，包括以下步骤：获取当前车辆的整车配置信息，并发送所述整车配置信息至所述当前车辆的车载Tbox，使得基于所述整车配置信息对所述当前车辆进行配置；在配置完成后，发送所述当前车辆对应的远程指令，以使所述车载Tbox将所述远程指令中的CAN报文信息上传至所述当前车辆的CAN网络；获取所述车载Tbox从所述CAN网络中采集与所述远程指令对应的执行信息，并根据所述执行信息得到所述远程指令的执行结果。

进一步地，所述获取当前车辆的整车配置信息，包括：获取所述当前车辆的身份标识；根据车辆静态信息表生成与所述身份标识对应的整车配置信息。

进一步地，所述发送所述整车配置信息至所述当前车辆的车载Tbox，包括：将所述整车配置信息转化为预设格式的远程配置码；发送所述远程配置码至所述车载Tbox。

进一步地，在获取当前车辆的整车配置信息之前，还包括：接收所述车载Tbox的注册请求；根据所述注册请求判断所述车载Tbox是否满足注册条件；如果所述车载Tbox满足所述注册条件，则接收所述当前车辆的配置请求。

进一步地，还包括：若预设时长内未收到所述车载Tbox发送的配置成功信号，则重新发送所述整车配置信息至所述车载Tbox，并检测失败次数；若所述失败次数大于预设阈值，则发送配置失败信号至预设终端。

本申请第二方面实施例提供一种车载Tbox的软件配置装置，包括：配置模块，用于获取当前车辆的整车配置信息，并发送所述整车配置信息至所述当前车辆的车载Tbox，使得基于所述整车配置信息对所述当前车辆进行配置；第一发送模块，用于在配置完成后，发送所述当前车辆对应的远程指令，以使所述车载Tbox将所述远程指令中的CAN报文信息上传至所述当前车辆的CAN网络；获取模块，用于获取所述车载Tbox从所述CAN网络中采集与所述远程指令对应的执行信息，并根据所述执行信息得到所述远程指令的执行结果。

进一步地，所述配置模块包括：获取单元，用于获取所述当前车辆的身份标识，根据车辆静态信息表生成与所述身份标识对应的整车配置信息；发送单元，用于将所述整车配置信息转化为预设格式的远程配置码，发送所述远程配置码至所述车载Tbox。

进一步地，还包括：第一接收模块，用于在获取当前车辆的整车配置信息之前，接收所述车载Tbox的注册请求；判断模块，用于根据所述注册请求判断所述车载Tbox是否满足注册条件；第二接收模块，用于在所述车载Tbox满足所述注册条件时，接收所述当前车辆的配置请求。

进一步地，还包括：检测模块，用于在预设时长内未收到所述车载Tbox发送的配置成功信号时，重新发送所述整车配置信息至所述车载Tbox，并检测失败次数；第二发送模块，用于在所述失败次数大于预设阈值时，发送配置失败信号至预设终端。

本申请第三方面实施例提供一种云端平台，包括如上述实施例所述的车载Tbox的软件配置装置。

由此，本申请至少具有如下有益效果：

基于云端远程实现车载Tbox的软件的通用化配置，通用化Tbox软件可以兼容不同车型不同需求，并通过云端信息维护代替厂家软件开发，降低开发成本、缩短开发周期，同时也可以降低售后维护成本、减少操作失败带来的数据问题。由此，解决了相关技术中不同车型的Tbox软件需要不同厂家独立开发，导致开发成本以及售后维护较高，容易出现人工操作失误等技术问题。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请实施例提供的车载Tbox的软件配置方法的流程示意图；

图2为根据本申请一个实施例提供的车载Tbox的软件配置方法的流程示意图；

图3为根据本申请实施例提供的车载Tbox的软件配置装置的示例图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

目前新能源车辆的远程监控模块Tbox主要功能，采集整车网络数据(整车网络定义一个信号需要多个变量：采集ID、周期、起始位、长度、精度、偏移量)，按照固定格式打包上传云端TSP，满足数据监控目的；另一方面，通讯终端接收后台下发的远程控制指令，传递至整车网络，实现车控目的。

然而，目前不同车型Tbox接收整车CAN网络数据不完全相同，Tbox需要执行的远程控制命令亦不完全相同。随着大数据的发展趋势，要求后台监控数据不断扩展，必然引发终端Tbox软件不断变更及后台TSP的适配开发，增加了开发费用。且零件号、软件版本也不断增多，加大了售后维护成本，一定程度上增大操作出错的概率。

为此，本申请实施例充分利用Tbox远程通讯能力，提出一种基于云端远程配置的通用化终端软件设计方案，解决不同车型、Tbox软件不断新开发的问题，通用化的软件，减低了开发、售后的维护成本、也减少了人工操作失误引发的错误。

下面参考附图描述本申请实施例的车载Tbox的软件配置方法、装置及云端平台。针对上述背景技术中心提到的相关技术中不同车型的Tbox软件需要不同厂家独立开发，导致开发成本以及售后维护较高，容易出现人工操作失误的问题，本申请提供了一种车载Tbox的软件配置方法，在该方法中，基于云端远程实现车载Tbox的软件的通用化配置，通用化Tbox软件可以兼容不同车型不同需求，并通过云端信息维护代替厂家软件开发，降低开发成本、缩短开发周期，同时也可以降低售后维护成本、减少操作失败带来的数据问题。由此，解决了相关技术中不同车型的Tbox软件需要不同厂家独立开发，导致开发成本以及售后维护较高，容易出现人工操作失误等技术问题。

具体而言，图1为本申请实施例所提供的一种车载Tbox的软件配置方法的流程示意图。

如图1所示，该车载Tbox的软件配置方法包括以下步骤：

在步骤S101中，获取当前车辆的整车配置信息，并发送整车配置信息至当前车辆的车载Tbox，使得基于整车配置信息对当前车辆进行配置。

需要说明的是，本申请实施例的方法可以应用于云端平台，比如TSP平台等。

其中，整车配置信息可以包括电池配置信息、电机参数配置信息、远程功能项配置信息、Tbox需要接收CAN网络数据配置信息等。

在本实施例中，获取当前车辆的整车配置信息，包括：获取当前车辆的身份标识；根据车辆静态信息表生成与身份标识对应的整车配置信息。

其中，身份标识可以为车辆的VIN(Vehicle Identification Number，车辆识别号码)。车辆静态信息表中的信息可以包括整车、电池、电机参数、远程功能项、Tbox需要接收CAN网络数据等信息。

可以理解的是，本申请实施例可以在云端平台维护不同车型车辆静态信息表，不同车型及高中低配差异可以通过整车物料号识别，车辆在出厂前在云端平台中自动建立物料与车辆VIN的对应关系。

在本实施例中，发送整车配置信息至当前车辆的车载Tbox，包括：将整车配置信息转化为预设格式的远程配置码；发送远程配置码至车载Tbox。

其中，预设格式可以根据远程配置码具体设置，不做具体限定。

可以理解的是，云端平台可以自动为每台车辆的VIN生成了一段固定格式的远程配置码，并将固定格式的远程配置码发送至车载Tbox。

在本实施例中，在获取当前车辆的整车配置信息之前，还包括：接收车载Tbox的注册请求；根据注册请求判断车载Tbox是否满足注册条件；如果车载Tbox满足注册条件，则接收当前车辆的配置请求。

其中，注册条件是指车辆上电后整车物料号、车辆VIN、终端Tbox身份的信息是否与云端平台存储的信息一一对应。

可以理解的是，当该车注册云端平台后，平台下发该车的远程配置码，Tbox接收到配置码后，存储、校验、解析、实现软件参数匹配。

在步骤S102中，在配置完成后，发送当前车辆对应的远程指令，以使车载Tbox将远程指令中的CAN报文信息上传至当前车辆的CAN网络。

可以理解的是，在配置完成后，Tbox可以根据配置内容采集CAN数据，并上报云端平台。

具体地，本申请实施例可以通过远程指令下发不同的远程功能，并通过在云端平台建立默认的通讯协议下发远程指令，下发的信息包含了Tbox需要向整车CAN网络下发的信息，Tbox可以直接转发云端平台的指令给整车，降低Tbox的数据处理压力。由此解决了相关技术中需要Tbox解析指令内容，再根据软件中定义内容判断发送哪些信息给整车其它模块，导致Tbox数据处理压力较大的问题。

在步骤S103中，获取车载Tbox从CAN网络中采集与远程指令对应的执行信息，并根据执行信息得到远程指令的执行结果。

可以理解的是，整车执行结果由云端平台根据终端Tbox上报的实时数据信息判定。

在一些实施例中，还包括：若预设时长内未收到车载Tbox发送的配置成功信号，则重新发送整车配置信息至车载Tbox，并检测失败次数；若失败次数大于预设阈值，则发送配置失败信号至预设终端。

其中，预设时长及预设阈值均可以根据实际情况进行设置，对此不作具体限定。预设终端可以至用户的移动终端或者计算机等设备。

可以理解的是，如果Tbox未接收到云端平台的远程配置码，则无法采集整车数据，可以上报给云端平台，云端平台重新发送远程配置码；并在失败次数超过一定次数时，进行配置失败提醒。

综上，本申请实施例可以充分利用终端Tbox远程通讯能力，通过云端平台来维护不同车型的信息，并将终端需要接收的整车CAN网络信息以固定的格式远程下发，Tbox接受远程配置信息后进行解析，以此过程替代终端Tbox软件的开发。

下面将结合具体实施例对车载Tbox的软件配置方法进行阐述，如图2所示，包括以下步骤：

1、整车配置信息远程下发：

1.1、在新车型车辆生产前，在系统维护该车型的相关静态信息-固定格式的表格或其他形式；

1.2、车辆在生产时产线将整车物料号、车辆VIN、终端Tbox身份的信息一一对应关系信息实时同步至云端平台；

1.3、整车上电后，终端Tbox在云端平台进行注册，身份校验通过后，向云端平台请求车辆配置码，云端平台判定该车是否需要重新下发配置，决定是否下发配置信息；其中，如果上次配置成功、终端身份信息无变更、后台该车型的配置码无变更，则不需要重新下发；如果无配置记录、配置失败、配置码变更或Box身份变更，则需要重新下发；

1.4、Tbox接收配置码信息后，进行相关存储、解析，完成软件的初始化，反馈云端平台配置结果；

1.5、配置成功后，Tbox进入常规的整车实时数据采集、上报。

2、远程指令下发：

2.1、在云端平台维护不同车型不同的远程指令对应的Tbox需要发送的CAN报文；

2.2、Tbox接收到云端平台远程指令后，转发指令中CAN报文信息至整车CAN网络；

2.3、并采集整车CAN上信息上报云端平台；

2.4、云端平台解析Tbox上报内容，判断执行结果。

综上，本申请至少具有如下有益效果：

(1)通用化的开发思路，通用化Tbox软件可兼容不同车型不同需求；

(2)在平台建立并维护车辆的静态信息，方便查询；

(3)通过平台信息维护代替厂家软件开发，降低开发成本、缩短开发周期；

(4)降低Tbox的售后维护成本、减少操作失败带来的数据问题。

根据本申请实施例提出的车载Tbox的软件配置方法，基于云端远程实现车载Tbox的软件的通用化配置，通用化Tbox软件可以兼容不同车型不同需求，并通过云端信息维护代替厂家软件开发，降低开发成本、缩短开发周期，同时也可以降低售后维护成本、减少操作失败带来的数据问题。

其次参照附图描述根据本申请实施例提出的车载Tbox的软件配置装置。

图3是本申请实施例的车载Tbox的软件配置装置的方框示意图。

如图3所示，该车载Tbox的软件配置装置10包括：配置模块100、第一发送模块200和获取模块300。

其中，配置模块100用于获取当前车辆的整车配置信息，并发送整车配置信息至当前车辆的车载Tbox，使得基于整车配置信息对当前车辆进行配置；第一发送模块200用于在配置完成后，发送当前车辆对应的远程指令，以使车载Tbox将远程指令中的CAN报文信息上传至当前车辆的CAN网络；获取模块300用于获取车载Tbox从CAN网络中采集与远程指令对应的执行信息，并根据执行信息得到远程指令的执行结果。

进一步地，配置模块100包括：获取单元和发送单元。其中，获取单元，用于获取当前车辆的身份标识，根据车辆静态信息表生成与身份标识对应的整车配置信息；发送单元，用于将整车配置信息转化为预设格式的远程配置码，发送远程配置码至车载Tbox。

进一步地，本申请实施例的装置10还包括：第一接收模块、判断模块和第二接收模块。其中，第一接收模块，用于在获取当前车辆的整车配置信息之前，接收车载Tbox的注册请求；判断模块，用于根据注册请求判断车载Tbox是否满足注册条件；第二接收模块，用于在车载Tbox满足注册条件时，接收当前车辆的配置请求。

进一步地，本申请实施例的装置10还包括：检测模块和第二发送模块。其中，检测模块，用于在预设时长内未收到车载Tbox发送的配置成功信号时，重新发送整车配置信息至车载Tbox，并检测失败次数；第二发送模块，用于在失败次数大于预设阈值时，发送配置失败信号至预设终端。

需要说明的是，前述对车载Tbox的软件配置方法实施例的解释说明也适用于该实施例的车载Tbox的软件配置装置，此处不再赘述。

根据本申请实施例提出的车载Tbox的软件配置装置，基于云端远程实现车载Tbox的软件的通用化配置，通用化Tbox软件可以兼容不同车型不同需求，并通过云端信息维护代替厂家软件开发，降低开发成本、缩短开发周期，同时也可以降低售后维护成本、减少操作失败带来的数据问题。

此外，本申请实施例还提供一种云端平台，包括如上述实施例的车载Tbox的软件配置装置。该平台基于云端远程实现车载Tbox的软件的通用化配置，通用化Tbox软件可以兼容不同车型不同需求，并通过云端信息维护代替厂家软件开发，降低开发成本、缩短开发周期，同时也可以降低售后维护成本、减少操作失败带来的数据问题。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或N个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“N个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更N个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，N个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

Claims (7)

1.一种车载Tbox的软件配置方法，其特征在于，包括以下步骤：

获取当前车辆的整车配置信息，并发送所述整车配置信息至所述当前车辆的车载Tbox，使得基于所述整车配置信息对所述当前车辆进行配置；

在配置完成后，发送所述当前车辆对应的远程指令，以使所述车载Tbox将所述远程指令中的CAN报文信息上传至所述当前车辆的CAN网络；以及

获取所述车载Tbox从所述CAN网络中采集与所述远程指令对应的执行信息，并根据所述执行信息得到所述远程指令的执行结果；

其中，所述获取当前车辆的整车配置信息，包括：获取所述当前车辆的身份标识；根据车辆静态信息表生成与所述身份标识对应的整车配置信息；所述发送所述整车配置信息至所述当前车辆的车载Tbox，包括：将所述整车配置信息转化为预设格式的远程配置码；发送所述远程配置码至所述车载Tbox。

2.根据权利要求1所述的方法，其特征在于，在获取当前车辆的整车配置信息之前，还包括：

接收所述车载Tbox的注册请求；

根据所述注册请求判断所述车载Tbox是否满足注册条件；

如果所述车载Tbox满足所述注册条件，则接收所述当前车辆的配置请求。

3.根据权利要求1所述的方法，其特征在于，还包括：

若预设时长内未收到所述车载Tbox发送的配置成功信号，则重新发送所述整车配置信息至所述车载Tbox，并检测失败次数；

若所述失败次数大于预设阈值，则发送配置失败信号至预设终端。

4.一种车载Tbox的软件配置装置，其特征在于，包括：

配置模块，用于获取当前车辆的整车配置信息，并发送所述整车配置信息至所述当前车辆的车载Tbox，使得基于所述整车配置信息对所述当前车辆进行配置；

第一发送模块，用于在配置完成后，发送所述当前车辆对应的远程指令，以使所述车载Tbox将所述远程指令中的CAN报文信息上传至所述当前车辆的CAN网络；以及

获取模块，用于获取所述车载Tbox从所述CAN网络中采集与所述远程指令对应的执行信息，并根据所述执行信息得到所述远程指令的执行结果；

其中，所述配置模块包括：获取单元，用于获取所述当前车辆的身份标识，根据车辆静态信息表生成与所述身份标识对应的整车配置信息；发送单元，用于将所述整车配置信息转化为预设格式的远程配置码，发送所述远程配置码至所述车载Tbox。

5.根据权利要求4所述的装置，其特征在于，还包括：

第一接收模块，用于在获取当前车辆的整车配置信息之前，接收所述车载Tbox的注册请求；

判断模块，用于根据所述注册请求判断所述车载Tbox是否满足注册条件；

第二接收模块，用于在所述车载Tbox满足所述注册条件时，接收所述当前车辆的配置请求。

6.根据权利要求4所述的装置，其特征在于，还包括：

检测模块，用于在预设时长内未收到所述车载Tbox发送的配置成功信号时，重新发送所述整车配置信息至所述车载Tbox，并检测失败次数；

第二发送模块，用于在所述失败次数大于预设阈值时，发送配置失败信号至预设终端。

7.一种云端平台，其特征在于，包括如权利要求4-6任意一项所述的车载Tbox的软件配置装置。