数据传输装置、车辆的检验方法、车辆和计算机程序产品

摘要

本申请提供了一种数据传输装置、车辆的检验方法、车辆和计算机程序产品，该数据传输装置包括：第一接口单元，用于从第一服务器处获取目标车辆的第一软件版本数据，第一服务器位于第一网络域；第二接口单元，用于从第二服务器处获取目标车辆的第一硬件数据，第二服务器位于第二网络域；处理单元，用于基于第一软件版本数据以及第一硬件数据，生成目标车辆的车辆数据；发送单元，用于向诊断仪发送车辆数据，车辆数据用于诊断仪对目标车辆的第二状态进行检验；其中，第一网络域所在的网段与第二网络域所在的网段不同。如此，即使目标车辆的软件版本数据与硬件数据分离，也可以通过数据传输装置获取目标车辆的硬件数据。

权利要求

1.一种数据传输装置，其特征在于，包括：

第一接口单元，用于从第一服务器处获取目标车辆的第一软件版本数据，所述第一服务器位于第一网络域；

第二接口单元，用于从第二服务器处获取所述目标车辆的第一硬件数据，所述第二服务器位于第二网络域；

处理单元，用于基于所述第一软件版本数据以及所述第一硬件数据，生成所述目标车辆的车辆数据；

发送单元，用于向诊断仪发送所述车辆数据，所述车辆数据用于所述诊断仪对处于第二状态的所述目标车辆进行检验，其中，所述诊断仪位于所述第一网络域；

其中，所述数据传输装置位于所述第一网络域或所述第二网络域，所述第一网络域所在的网段与所述第二网络域所在的网段不同；

所述第二状态为所述目标车辆的部分或全部硬件组装完成，且针对所述组装完成的部分或全部硬件进行了软件刷写的车辆状态。

2.如权利要求1所述的数据传输装置，其特征在于，所述第一软件版本数据包括硬件号以及硬件版本信息，所述数据传输装置还包括第三接口单元，所述第三接口单元，还用于从第三服务器处获取第二硬件数据，所述第二硬件数据包括硬件号以及硬件版本信息，所述第三服务器位于所述第一网络域；

若所述第一硬件数据与所述第二硬件数据匹配，所述处理单元还用于基于所述第二硬件数据中的硬件号以及硬件版本信息与所述第一软件版本数据的硬件号以及硬件版本信息进行匹配，以确定所述第二硬件数据与所述第一软件版本数据是否匹配；

若所述第二硬件数据与所述第一软件版本数据匹配，所述处理单元还用于基于所述第一软件版本数据、所述第一硬件数据以及所述第二硬件数据，生成所述目标车辆的车辆数据。

3.如权利要求2所述的数据传输装置，其特征在于，所述第一硬件数据包括所述目标车辆的控制单元信息，所述第二硬件数据包括控制单元信息，所述处理单元，还用于基于所述第一硬件数据中包括的控制单元信息，以及所述第二硬件数据中包括的控制单元信息，确定所述第一硬件数据与所述第二硬件数据是否匹配，所述控制单元信息用于指示控制单元对应的控制功能。

4.如权利要求1所述的数据传输装置，其特征在于，所述处理单元还用于：从所述第一服务器处获取多个软件版本数据，所述多个软件版本数据包括所述第一软件版本数据；

基于预设规则，从所述多个软件版本数据中确定所述第一软件版本数据，所述第一软件版本数据与所述目标车辆相匹配。

5.如权利要求4所述的数据传输装置，其特征在于，所述预设规则用于指示所述目标车辆的车辆标识与软件版本数据的对应关系，所述处理单元，还用于基于所述预设规则，从所述多个软件版本数据中确定所述第一软件版本数据。

6.如权利要求4所述的数据传输装置，其特征在于，所述预设规则用于指示目标时间关联的车辆对应的软件版本数据，其中，所述目标时间关联的车辆包括在所述目标时间之后生产的车辆，所述处理单元，还用于基于所述预设规则，从所述多个软件版本中确定与所述目标时间对应的软件版本为目标软件版本，所述目标车辆的生产时间位于所述目标时间之后。

7.如权利要求6所述的数据传输装置，其特征在于，所述目标时间基于目标车辆标识确定，所述目标车辆标识中的目标字段用于指示所述目标时间。

8.如权利要求1所述的数据传输装置，其特征在于，所述车辆数据包括以下一种或多种：所述目标车辆的车辆总成信息；

所述目标车辆的车辆总成中包括的一个或多个硬件的硬件号；

所述目标车辆的车辆总成中包括的一个或多个硬件的硬件版本；

所述目标车辆的控制单元的信息，所述目标车辆的控制单元信息用于指示所述目标车辆中控制单元的功能。

9.一种车辆的检验方法，其特征在于，所述方法由数据传输装置执行，所述方法包括：从第一服务器处获取目标车辆的第一软件版本数据，所述第一服务器位于第一网络域；

从第二服务器处获取所述目标车辆的第一硬件数据，所述第二服务器位于第二网络域；

基于所述第一软件版本数据以及所述第一硬件数据，生成所述目标车辆的车辆数据；

向诊断仪发送所述车辆数据，所述车辆数据用于所述诊断仪对处于第二状态的所述目标车辆进行检验；

其中，所述数据传输装置位于所述第一网络域或所述第二网络域，所述第一网络域所在的网段与所述第二网络域所在的网段不同；

所述第二状态为所述目标车辆的部分或全部硬件组装完成，且针对所述组装完成的部分或全部硬件进行了软件刷写的车辆状态。

10.一种电子设备，其特征在于，包括输入/输出接口、处理器和存储器，所述处理器用于控制所述输入/输出接口收发数据，所述存储器用于存储计算机程序，所述处理器用于从所述存储器中调用并运行该计算机程序，使得所述电子设备执行权利要求9所述的方法。

11.一种计算机可读介质，其特征在于，所述可读介质存储有计算机程序/指令，当所述计算机程序/指令被处理器执行时用于实现如权利要求9所述的方法。

说明书

数据传输装置、车辆的检验方法、车辆和计算机程序产品

技术领域

[0001] 本申请涉及数据传输技术领域，具体涉及一种数据传输装置、车辆的检验方法、车辆和计算机程序产品。

背景技术

[0002] 目前，在对待检测车辆（又称“目标车辆”）的第二状态进行检验之前，需要获取目标车辆的硬件数据以及软件版本数据作为支撑，才能对目标车辆的第二状态进行检验。然而，在目标车辆的实际生产过程中，目标车辆的制造商（又称“委托方”）可能会委托其他制造商（又称“代工方”）制造目标车辆的某些硬件，此时，代工方制造的硬件对应的硬件数据会被存储在代工方的服务器（下文又称“第二服务器”）中，如此，委托方无法与第二服务器进行通信，以获取硬件数据，那么委托方便无法对目标车辆的第二状态进行检验。

发明内容

[0003] 本申请实施例致力于提供一种数据传输装置、车辆的检验方法、车辆以及计算机程序产品，下文从以下几个方面进行介绍。

[0004] 第一方面，提供了一种数据传输装置，包括：第一接口单元，用于从第一服务器处获取目标车辆的第一软件版本数据，所述第一服务器位于第一网络域；第二接口单元，还用于从第二服务器处获取所述目标车辆的第一硬件数据，所述第二服务器位于第二网络域；处理单元，用于基于所述第一软件版本数据以及所述第一硬件数据，生成所述目标车辆的车辆数据；发送单元，用于向所述第一网络域中的诊断仪发送所述车辆数据，所述车辆数据用于所述诊断仪对所述目标车辆的第二状态进行检验；其中，所述数据传输装置位于所述第一网络域或所述第二网络域，所述第一网络域所在的网段与所述第二网络域所在的网段不同。

[0005] 第二方面，提供了一种车辆的检验方法，所述方法由数据传输装置执行，所述方法包括：从第一服务器处获取目标车辆的第一软件版本数据，所述第一服务器位于第一网络域；从第二服务器处获取所述目标车辆的第一硬件数据，所述第二服务器位于第二网络域；基于所述第一软件版本数据以及所述第一硬件数据，生成所述目标车辆的车辆数据；向所述第一网络域中的诊断仪发送所述车辆数据，所述车辆数据用于所述诊断仪对所述目标车辆的功能进行检验；其中，所述数据传输装置位于所述第一网络域或所述第二网络域，所述第一网络域所在的网段与所述第二网络域所在的网段不同。

[0006] 第三方面，提供了一种电子设备，包括输入/输出接口、处理器和存储器，所述处理器用于控制所述输入/输出接口收发数据，所述存储器用于存储计算机程序，所述处理器用于从所述存储器中调用并运行该计算机程序，使得所述电子设备执行第二方面所述的方法。

[0007] 第四方面，提供了一种计算机程序产品，包括计算机程序/指令，当所述计算机程序/指令处理器被执行时实现如第二方面所述的方法。

[0008] 在一些实现方式中，上述计算机程序产品包括可以包括计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各方面所示的控制方法。

[0009] 在另一些实现方式中，计算机程序产品包括计算机可读介质，计算机可读介质存储有程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各方面所示的控制方法。

[0010] 本申请实施例提供了一种数据传输装置，该数据传输装置可以与第一服务器以及第二服务器通信，以从第二网络域中第二服务器处获取目标车辆的第一硬件数据，从第一网络域中获取目标车辆的第一软件版本数据，并基于第一硬件数据以及第一软件版本数据生成目标车辆的车辆数据，再将目标车辆的车辆数据传输到诊断仪，以对目标车辆的第二状态进行检测。如此，即使第一服务器所在的第一网络域以及第二服务器所在的第二网络域对应的网段不同，目标车辆的软件版本数据与硬件数据分离存储，也可以通过数据传输装置获取目标车辆的硬件数据。

附图说明

[0011] 图1是本申请实施例中的数据传输场景的示意图。

[0012] 图2是本申请实施例中的数据传输装置的示意图。

[0013] 图3介绍本申请实施例的数据匹配过程的示意性流程图。

[0014] 图4是本申请另一实施例的数据传输装置的示意图。

[0015] 图5是本申请另一实施例的数据传输装置的示意图。

[0016] 图6是本申请另一实施例的电子设备的示意性框图。

[0017] 图7是本申请实施例的车辆的检验方法的示意性流程图。

具体实施方式

[0018] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。

[0019] 随着汽车技术，特别是人工智能的快速发展，汽车已不简单是一台沙发加四个轮子的产品。一辆汽车从研发设计到量产出售给消费者是一个繁琐且漫长的过程。这当中包括市场调研、概念设计、工程设计、样车试验、量产5个主要阶段。而汽车的制造过程又主要分为：冲压、焊装、涂装、总装及检测等五个过程，亦即我们熟知的汽车四大工艺和检测。其中，检测又称“下线（End Of Line，EOL）检测”，该阶段是汽车电子产品下线前的功能检测，简单来讲EOL检测使用的是专用的EOL设备，（例如，注入EOL测试软件的设备），当汽车电子产品下线前可以将汽车电子产品连接到EOL设备上检测产品功能是否正常。为了便于理解，下文对EOL检测进行介绍。

[0020] 车辆下线检测是指汽车在生产制造过程中，检测零部件功能，控制整车质量的过程。换句话说，车辆的下线检测是针对处于第二状态的车辆进行检测，其中，第二状态可以理解为车辆的部分或全部硬件组装完成，且针对组装完成的部分或全部硬件进行了软件刷写的车辆状态。相应地，与第二状态对应的是目标车辆的第一状态。第一状态可以理解为车辆的部分或全部硬件组装完成，但是尚未刷写软件的车辆状态。

[0021] 常见的检测流程有尺寸匹配检查，静态功能检查，前束转毂测试，排放检测，雨淋和路试等，其中对整车电子电器质量的检测（又称“电检”）日趋复杂、重要。以电子控制单元（Electric Control Unit，ECU）为例，随着人们对车辆功能的要求的多样化，车辆上可以集成的ECU越来越多（例如，一些车辆中集成的ECU超过100个）。在这种情况下，对下线车辆的电子电器系统进行全面的检测变得十分重要。但如果依赖人工对车辆进行电检，将影响车辆生产的效率。

[0022] 假设一辆车有50个ECU，需要检查100个功能，单个功能手动检查要30秒，检查一辆车需要大约50分钟，这是对车辆进行批量生产的一个阻碍。因此，自动化检测系统（例如，下线诊断（End Off Line，EOL）系统应运而生，该系统类似于车辆数据的总装车间，将所有车辆需要的数据装入车辆，并对车辆的电器功能做全面的检查。

[0023] 通常，在车辆下线之前，需要根据车辆配置完成ECU编码（指ECU的数据写入），基础设定，测试等步骤，EOL系统就是基于诊断来完成以上工作，根据总装车间的工段分布，EOL系统通常会在不同工段设置电检工位：仪表板电器检测工位、车门电器检测工位、预检测工位、加液工位、整车电器功能检测工位、前束和四轮定位、转毂检测、尾气检测及整车电器终检。

[0024] EOL系统的高效工作也取决于高效的车辆生产信息系统，EOL系统需要从生产信息系统获取车辆订单，包括每辆车的生产识别代码、流水号、生产时间、车型、装备清单、控制器信息等，只有获取了这些信息，EOL系统才能够正确对车辆进行个性化配置（此时，车辆处于第二状态，即车辆的硬件组装，软件刷写完成后的车辆状态）；除此之外，VTS在进行车辆配置的过程中还需要将部分信息上传到生产信息系统，包括车辆各个工位的检测结果，ECU的序列号，重要螺栓的扭矩值，底盘调整值等。

[0025] 如前文介绍，EOL系统通常会在不同工段设置电检工位，下文以常见的几个电检工位为例进行介绍。

[0026] 1，预检测工位

[0027] 仪表板检测工位、车门检测工位都可以归入预检测，实际上部分整车厂已经取消了仪表板检测工位和车门检测工位。预检测工位常会安排在仪表板安装完成之后进行，此时网关，仪表，娱乐系统等控制器都已安装，由于此时算是车辆与EOL系统的首次通讯，通常需要在测试仪中输入车辆的订单。预检测工位会完成已安装ECU的初始化，所谓初始化是指对控制器进行编码，编码依据来源于产品开发部门，另外还有控制器在下线检测过程中需要执行的检测步骤，包括编码，基础设定，标定，测试等（特定控制器可能还需要进行软件刷新）。现在的车辆中，很多功能不是由一个控制器负责，因此需要参与该功能的所有控制器都完成了下线检测的步骤之后，该功能才可能正常运行。检测系统在和车辆上任何一个ECU通讯时，首先都会读取ECU的信息（零件号，软件版本，硬件版本等），然后将该信息与生产系统中该车应该安装的ECU的信息做比较，及时发现零件错装的问题。

[0028] 除了部分已装零件的初始化，对一些车型来说，还需要在此完成防盗申请，所谓防盗系统的匹配主要是指将涉及到的ECU的信息（会有唯一标识该ECU的序列号）以及该ECU将要安装到的具体车辆的信息（例如，车辆识别码Vehicle Identification Number，VIN）发送给委托方的服务器，完成ECU和车辆在服务器上的绑定，ECU还会收到服务器发送的密钥，需要将其写入ECU中，这样不合法的ECU装在车辆上时车辆就无法发动。

[0029] 2，加液工位

[0030] 加液工位负责完成车辆冷却液（冷却发动机，由水、防冻剂、添加剂组成），空调制冷剂是一种使用最广泛的中低温环保制冷剂），玻璃洗涤液和制动液（液压制动系统中传递制动压力的液态介质，常见的有：醇型，合成型，矿油型）的添加。其中制动液的添加涉及到与车身电子稳定系统（Electronic Stability Program，ESP）的通讯，加液设备有单独工作的，也有并入EOL系统中的，但是加液过程都是类似的，按照定义的操作步骤，执行ESP的相关例程，执行过程中需配合加液设备的动作。

[0031] 3，整车电器功能检测工位

[0032] 基本完成整车零部件安装之后，就需要为车辆首次发动做准备了，此时来到了整车电器功能检测工位，此工位会完成所有控制器的初始化和测试，即将所有ECU需要的数据都写入，并完成部分ECU的基础设定，还需要执行ECU的测试项，测试项包括自动测试和人工测试，该工位往往是所有电检工位中任务最重，问题最多的。

[0033] 初始化部分包括ECU数据写入、部分ECU的基础设定、车辆防盗匹配。此处会完成所有ECU的数据写入，即便在预检测时，部分ECU已经写入过数据，因为生产时要求即便预检测执行失败或者没有执行的时候，整车电器检测工位也需要能保证车辆完成所有电检（之前执行失败的原因已经解决），顺利下线。由于车辆ECU数量较多，实际操作过程中通常将ECU按所在总线区分，采用并行数据写入的方法。过程中数据写入量大，操作控制器数量多，易出现偶发的写入报错，具有跟踪记录困难，分析难度较大的特点，生产中会参考之前项目经验，对并行的设计进行优化。为减少写入过程中的总线负载，可以使用诊断服务控制部分ECU停止发送报文，完成数据写入之后再恢复ECU的功能。初始化部分的基础设定包括车窗的位置学习，天窗的位置学习，空调的风门匹配，因为控制器开发时不知道执行器安装之后的状态，所以在完成装配之后，控制器需要控制执行器动作，了解起止位置。在完成以上内容之后，需要删除所有ECU的故障码（DiagnosticTrouble Code，DTC），因为完成了数据写入、基础设定和防盗匹配之后，很多激活的DTC会变成被动的，可以被清除掉。

[0034] 测试部分包含自动测试和人工测试，自动测试项中诊断服务激活的是ECU开发时设计好的检查ECU及其输入输出功能的例程（比如BCM可能有依次测试车辆内部外部灯光的例程），以及对ECU特定输入输出的测试（比如外后视镜的加热功能的激活）。人工测试则是ECU无法独立完成的检测项，主要包括执行器和传感器的测试，例如车辆喇叭是否正常工作（执行器），座椅的乘客监测传感器是否正常工作（传感器）都需要操作人员的参与。

[0035] 4，前束工位

[0036] 前束工位（各主机厂工位、设备和检测项会存在不同）完成车辆的称重，四轮定位（调整车轮前束和外倾，使其符合开发部门的定义），大灯调整，控制器标定（自适应巡航控制系统（Adaptive Cruise Control，ACC）、多功能摄像头、变道辅助和抬头显示等）。与预检测和整车功能检测工位不同，前束工位、转毂工位和加液工位除了要完成EOL系统与车辆的信息通讯以外，还需要进行EOL系统与检测设备（加液设备，前束设备，转毂设备）的信息通讯。在ACC的标定时，测试仪会首先告诉前束设备将ACC标定目标板移动到车辆正前方，处于ACC的检测范围之内，然后测试仪会向ACC发送诊断指令，要求ACC开始标定，标定过程类似于数码相机的自动调焦，用户操作激活数码相机的自动调焦功能，调焦过程均由数码相机完成，ACC接收到测试仪的命令之后就会开启标定过程，如果一切正常，ACC就能成功标定。前束工位常常会将四轮定位、灯光调整和控制器标定设计为并行测试，节省工时，但是并行中也会有一定的先后逻辑关系，需要根据实际情况设计。

[0037] 上文介绍了本申请实施例适用的EOL系统，下文结合图1介绍本申请实施例适用的场景。图1所示的场景包括第一网络域110以及第二网络域120，第一网络域110可以位于目标车辆的委托方，第二网络域可以位于目标车辆的代工方，其中，第一网络域110以及第二网络域120位于不同的网段（network segment）。网段一般指一个计算机网络中使用同一物理层设备（例如，传输介质，中继器，集线器等）能够直接通讯的那一部分。相应地，第一网络域110以及第二网络域120由于位于不同的网段，那么第一网络域中的设备（例如，第一服务器）与第二网络域中的设备（例如，第二服务器）之间无法直接通信，或者说，第一网络域与第二网络域之间通信隔离。第一网络域110可以包括第一服务器、检测仪等。上述第一服务器111用于存储目标车辆的第一软件版本数据。

[0038] 第二网络域120可以包括第二服务器121，其中，第二服务器可以用于存储目标车辆的第一硬件数据。其中，第一硬件数据可以包括代工方制造的目标车辆中硬件的硬件数据。在一些实现方式中，第一硬件数据可以包括目标车辆的车辆总成信息，其中，车辆总成可以理解为是包括若干零件、部件、组合件或附件组合装配而成，并具有独立功能的车辆组成部分，例如，车辆总成可以包括发动机、变速器、转向器、前桥、后桥、车身、车架以及驾驶室中的一种或多种。

[0039] 在本申请实施例中，对第一硬件数据不作限定。在一些实现方式中，第一硬件数据还可以包括目标车辆的车辆识别号（Vehicle Identification Number，VIN）等。

[0040] 另外，基于上文的介绍的可知，上述第一服务器和/或第二服务器均可以理解为参与目标车辆的制造过程，也即是说，上述第一服务器和/或第二服务器可以位于生产目标车辆的产线上，因此，上述第一服务器和/或第二服务器又可以称为产线服务器。

[0041] 目前，在对待检测车辆（又称“目标车辆”）的第二状态进行检验之前，需要获取目标车辆的硬件数据以及软件版本数据作为支撑，才能对目标车辆的第二状态进行检验。然而，在目标车辆的实际生产过程中，目标车辆的制造商（又称“委托方”）可能会委托其他制造商（又称“代工方”）制造目标车辆的某些硬件，此时，代工方制造的硬件对应的硬件数据会被存储在代工方的服务器（下文又称“第二服务器”）中，如此，委托方无法与第二服务器进行通信，以获取硬件数据，那么委托方便无法基于硬件数据对目标车辆的第二状态进行检验。

[0042] 因此，针对上述问题，本申请实施例提供了一种数据传输装置，该数据传输装置可以与第一服务器以及第二服务器通信，以从第二网络域中第二服务器处获取目标车辆的第一硬件数据，从第一网络域中获取目标车辆的第一软件版本数据，并基于第一硬件数据以及第一软件版本数据生成目标车辆的车辆数据，再将目标车辆的车辆数据传输到诊断仪，以对目标车辆的第二状态进行检测。如此，即使第一服务器所在的第一网络域以及第二服务器所在的第二网络域对应的网段不同，即使目标车辆的软件版本数据与硬件数据分离存储，也可以通过数据传输装置获取目标车辆的硬件数据。

[0043] 为了便于理解，下文结合图2介绍本申请实施例的数据传输装置。图2是本申请实施例中的数据传输装置的示意图。图2所示的数据传输装置200可以包括第一接口单元210、第二接口单元220、处理单元230以及发送单元240。

[0044] 第一接口单元210，用于从第一服务器111处获取目标车辆的第一软件版本数据；

[0045] 第二接口单元220，还用于从第二服务器121处获取目标车辆的第一硬件数据；

[0046] 处理单元230，用于基于第一软件版本数据以及第一硬件数据，生成目标车辆的车辆数据；

[0047] 发送单元240，用于向诊断仪发送车辆数据，车辆数据用于诊断仪对目标车辆的第二状态进行检验。

[0048] 如前文介绍，第二状态可以理解为车辆的部分或全部硬件组装完成，且针对组装完成的部分或全部硬件进行了软件刷写的车辆状态。其中，硬件组装例如可以由第二网络域中的相关装置执行。软件刷写例如可以由第一网络域中的相关装置进行控制。

[0049] 在一些实现方式中，上述数据传输装置可以位于第二网络域，也即是说，数据传输装置可以位于车辆代工方的网络域中，这样，有助于提高第二服务器向数据传输装置发送第一硬件数据的可靠性。当然，在本申请实施例中，数据传输装置也可以位于第一网络域，有助于提高第一服务器发送第一软件版本数据的可靠性。

[0050] 上述第一软件版本数据可以用于指示软件相关的信息。在一些实现方式中，第一软件版本数据可以包括软件版本适用的控制单元（例如，ECU）的信息，软件版本适用的硬件的信息，以及软件信息中的一种或多种。其中，软件版本适用的硬件的信息例如可以为软件版本适用的硬件号，软件版本适用的硬件的信息例如可以为软件版本适用的硬件版本。

[0051] 本申请实施例对上述第一软件版本数据的传输方式不作限定。例如，第一软件版本数据可以是从第一服务器中的离线刷写软件管理后台处获取的。又例如，第一软件版本数据还可以是从内容分发网络（Content Delivery Network，CDN）处获取的。下文将结合图5详细介绍，为了简洁，在此不再赘述。

[0052] 上述第一硬件数据可以用于指示目标车辆的硬件相关的信息。在一些实现方式中，第一硬件数据可以包括目标车辆的VIN，目标车辆的控制单元（例如，ECU）信息，目标车辆的总成信息。其中，控制单元信息例如可以指示控制单元的控制功能，总成信息例如可以包括DU号。

[0053] 本申请实施例对上述第一硬件数据的传输方式不作限定。例如，第一硬件数据可以是从第二服务器中的制造执行系统（Manufacturing Execution System，MES）获取的。例如，第一硬件数据可以承载于车辆广播文件中，由MES系统向数据传输装置广播。其中，车辆广播文件可以是车辆在车间总装上线工位节点将制造相关的硬件配置及VIN数据向下游系统广播出来的一份解释性格式文本（例如，基于可扩展标记语言 (Extensible Markup Language, XML)的文本），供下游系统接收后处理后以准备好后续工位所需信息。其中，下游系统例如可以是诊断仪，或者车辆中心。下文结合图5详细介绍，为了简洁，在此不再赘述。

[0054] 上述目标车辆的车辆数据可以用于对目标车辆的第二状态进行检验（例如，进行电检），或者说，车辆数据中包括对目标车辆的第二状态进行检验所需的数据。例如，车辆数据可以包括第一软件版本数据以及第一硬件数据。

[0055] 在一些实现方式中，为了上述数据传输过程中的安全性，数据传输装置可以通过内网传输上述数据。例如，数据传输装置可以通过内网从第一服务器处获取第一软件版本数据。又例如，数据传输装置可以通过内网从第二服务器处获取第一硬件数据。又例如，数据传输装置可以通过内网将车辆数据发送给诊断仪。当然，在本申请实施例中，数据传输装置也可以通过公网传输上述数据，本申请实施例对此不作限定。

[0056] 需要说明的是，上述内网可以理解为一种局域网（Local Area Network，LAN），而局域网是一种私有网络，一般在一座建筑物内或建筑物附近，比如家庭、办公室或工厂。局域网络通常具有较高的安全性，因此，基于内网进行数据传输，有助于提高数据传输的安全性。

[0057] 在一些场景中，数据传输装置可能会从第一服务器中获取多个软件版本，此时，数据传输装置可以基于预设规则，确定与目标车辆匹配的软件版本数据（即第一软件版本数据）。也即是说，处理单元还用于：从第一服务器处获取多个软件版本数据，多个软件信息包括第一软件版本数据；基于预设规则，从预存的多个软件版本数据中确定第一软件版本数据，第一软件版本数据与目标车辆相匹配。

[0058] 需要说明的是，上述与目标车辆匹配的软件版本数据可以理解为是与目标车辆的车辆标识（例如，VIN）对应的软件版本，或者，还可以理解为是与目标车辆的硬件数据相匹配的软件版本。

[0059] 在一些实现方式中，为了减少重新搭建数据传输装置的成本，可以复用EOL系统作为上述数据传输装置。当然，在本申请实施例中，数据传输装置还可以是独立于EOL系统的独立系统。

[0060] 在本申请实施例中对预设规则的具体实现方式不作限定。下文结合实现方式1 3~分别进行介绍。

[0061] 实现方式1，预设规则用于指示目标车辆的车辆标识与软件版本数据的对应关系。

[0062] 相应地，处理单元用于基于预设规则，从多个软件版本数据中确定第一软件版本数据。

[0063] 在一些实现方式中，上述车辆标识可以为VIN，其中，车辆识别代码可以视为车辆的身份证号，它可以根据国家车辆管理标准确定。通常，VIN包含了车辆的生产厂家、年代、车型、车身型式及代码、发动机代码及组装地点等信息。在另一些实现方式中，上述车辆标识还可以是目标车辆的车牌号。

[0064] 在本申请实施例中，对车辆标识与软件版本的对应关系不作限定。在一些实现方式中，车辆标识可以与软件版本数据一一对应。在另一些实现方式中，软件版本数据可以对应多个车辆标识。

[0065] 在本申请实施例中，可以分别为车辆指定软件版本数据，有助于提高为车辆配置软件版本数据的准确率。

[0066] 实现方式2，预设规则用于指示目标车辆标识关联的车辆对应的软件版本数据。

[0067] 上述目标车辆标识关联的车辆包括在目标车辆标识指示的生产时间之后生产的车辆。也即是说，在目标车辆标识指示的生产时间之后生产的车辆，可以对应一个软件版本数据。这种类型的预设规则可以理解为将车辆的车辆标识作为一个断点，断点之后的生产的车辆可以对应一个软件版本数据，因此，该预设规则又可以称为“车辆标识断点控制”。

[0068] 相应地，处理单元还用于基于预设规则，从多个软件版本数据中确定与目标车辆标识对应的软件版本数据为第一软件版本数据，目标车辆的生产时间位于目标车辆标识指示的生产时间之后。

[0069] 例如，目标车辆标识指示的生产时间为2022年2月，则预设条件可以包括2022年2月之后的生产的车辆可以对应软件版本数据A。此时，若目标车辆的生产时间为2022年3月，则目标车辆对应的软件版本数据可以为软件版本数据A。

[0070] 当然，在本申请实施例中，上述目标车辆标识关联的车辆可以包括在在目标车辆标识指示的生产时间之前生产的车辆，也即是说，在目标车辆标识指示的生产时间之前生产的车辆可以对应一个软件版本数据。

[0071] 在本申请实施例中，预设规则的配置中可以将车辆的车辆标识作为一个断点，断点之后的生产的车辆可以对应一个软件版本数据，有助于简化预设规则的配置过程。

[0072] 实现方式3，预设规则用于指示目标时间关联的车辆对应的软件版本数据。

[0073] 上述目标时间关联的车辆包括在目标时间之后生产的车辆。也即是说，在目标时间之后生产的车辆可以对应一个软件版本数据。这种类型的预设规则可以理解为将车辆的生产时间作为一个断点，断点之后的生产的车辆可以对应一个软件版本数据，因此，该预设规则又可以称为“时间断点控制”。

[0074] 在本申请实施例中对目标时间不作限定。例如，目标时间可以以日期的形式表示。又例如，目标时间可以具体到某天中的一个小时。

[0075] 相应地，处理单元还用于基于预设规则，从多个软件版本中确定与目标时间对应的软件版本为目标软件版本，目标车辆的生产时间位于目标时间之后。

[0076] 例如，目标时间为2022年5月，则预设条件可以包括2022年5月之后的生产的车辆可以对应软件版本数据B。此时，若目标车辆的生产时间为2022年6月，则目标车辆对应的软件版本数据可以为软件版本数据B。

[0077] 当然，在本申请实施例中，上述目标时间关联的车辆可以包括在目标时间之前生产的车辆，也即是说，在目标时间之前生产的车辆可以对应一个软件版本数据。

[0078] 上文介绍的本申请实施例的中的预设条件的3种实现方式。上述3中实现方式可以单独使用，也可以相互结合使用。在一些实现方式中，上述实现方式2以及实现方式3之间可以相互结合使用，有助于提高为车辆配置软件版本数据的灵活性。

[0079] 例如，预设规则1采用实现方式2，预设规则2采用实现方式3。预设规则1中的目标车辆标识指示的生产时间为2022年2月，则预设条件1可以包括2022年2月之后的生产的车辆可以对应软件版本数据A。预设规则2中的目标时间为2022年5月，则预设条件2可以包括2022年5月之后的生产的车辆可以对应软件版本数据B。

[0080] 此时，在2022年2月至5月之间，生产的车辆可以对应软件版本数据A。在2022年5月之后生产的车辆可以对应软件版本数据B。

[0081] 在一些场景中，第一服务器中可能并未存储目标车辆中的硬件号以及硬件版本信息，但是，对目标车辆进行电检时可能需要这些硬件数据（下文又称“第二硬件数据”）。这些信息存储在委托方的服务器（又称“第三服务器”）中，或者说，第三服务器位于第一网络域，此时，数据传输装置还需要从第三服务器中获取目标车辆对应的第二硬件数据。但是，第三服务器中可能存储有多个第二硬件数据，数据传输装置需要从多个第二硬件数据找出与第一硬件数据相匹配的第二硬件数据，即为目标车辆的第二硬件数据。

[0082] 此时，基于上文的介绍可知第一硬件数据中包括控制单元信息，由于第二硬件数据中也包括控制单元信息，此时，可以基于第一硬件数据中的控制单元信息，以及第二硬件数据中的控制单元信息，来确定与第一硬件数据匹配的第二硬件数据。

[0083] 也即是说，第一硬件数据包括目标车辆的控制单元信息，第二硬件数据包括控制单元信息，处理单元还用于基于第一硬件数据中包括的控制单元信息，以及第二硬件数据中包括的控制单元信息，确定第一硬件数据与第二硬件数据是否匹配，控制单元信息用于指示控制单元对应的控制功能。

[0084] 在一些实现方式中，可以基于第二硬件数据确定与之匹配的第一软件版本数据，即第一软件版本数据包括硬件号以及硬件版本信息，第三接口单元，还用于从第三服务器处获取第二硬件数据，第二硬件数据包括硬件号以及硬件版本信息，第三服务器位于第一网络域；若第一硬件数据与第二硬件数据匹配，处理单元还用于基于第二硬件数据中的硬件号以及硬件版本信息与第一软件版本数据的硬件号以及硬件版本信息进行匹配，以确定第二硬件数据与第一软件版本数据是否匹配；若第二硬件数据与第一软件版本数据匹配，处理单元还用于基于第一软件版本数据、第一硬件数据以及第二硬件数据，生成目标车辆的车辆数据。

[0085] 本申请实施例中对第三服务器不作限定。在一些实现方式中，第三服务器可以与第一服务器为相同的服务器，或者第三服务器可以与第一服务器属于相同的服务器集群。在另一些实现方式中，第三服务器可以与第一服务器为不同的服务器，或者第三服务器可以与第一服务器属于不同的服务器集群。

[0086] 在一些实现方式中，第三服务器中可以设置有用于制造目标车辆的物料清单(Bill of Material，BOM)系统，相应地，数据传输装置可以从BOM系统中获取第二硬件数据。

[0087] 如前文介绍，数据传输装置可以生成对目标车辆进行功能检测所需的数据，也即是说，车辆数据中会包括第一硬件数据、第二硬件数据以及第一软件版本数据。为了确保车辆数据包含的上述数据相互之间是匹配的，除了需要将第一硬件数据与第二硬件数据之间进行匹配之外，还需要确定第一硬件数据是否与第一软件版本数据匹配，和/或第二硬件数据是否与第一软件版本数据匹配。

[0088] 在一些实现方式中，上述三种数据相互之间匹配，可以理解为满足以下一种或多种情况：第一软件版本数据包括软件版本适用的控制单元信息，且第一软件版本数据包括的控制单元信息与第一硬件数据中的控制单元信息匹配；第一软件版本数据包括软件版本适用的硬件的硬件号，第一软件版本数据中的硬件号与第二硬件数据中的硬件号匹配；第一软件版本数据包括软件版本适用的硬件版本信息，第一软件版本数据中的硬件版本信息与第二硬件数据中的硬件版本信息匹配。

[0089] 需要说明的是，本申请实施例中，对确定上述三种数据之间是否匹配的执行顺序不作限定。在一些实现方式中，可以先执行第一硬件数据与第一软件版本数据之间的匹配过程，再执行第一硬件数据与第二硬件数据之间的匹配过程，最后执行第一软件版本数据与第二硬件数据之间的匹配过程（又称“执行顺序1”）。在另一些实现方式中，可以先执行第一硬件数据与第二硬件数据之间的匹配过程，再执行第一软件版本数据与第一硬件数据和第二硬件数据之间的匹配过程。

[0090] 为了便于理解，下文以执行顺序1为例结合图3介绍本申请实施例的数据匹配过程。图3所示的步骤包括步骤S310至步骤S390。

[0091] 在步骤S310中，第二服务器向数据传输装置广播车辆广播文件，其中车辆广播文件中包括第一硬件数据。第一硬件数据包括目标车辆的VIN，目标车辆的ECU信息，目标车辆的DU号以及第一硬件数据的下发时间中的一种或多种。

[0092] 在步骤S320中，第一服务器向数据传输装置发送多个软件版本数据。

[0093] 在步骤S330中，数据传输装置基于预设规则，从多个软件版本数据中选择与第一硬件数据匹配的第一软件版本数据。第一软件版本数据包括目标车辆的ECU信息，目标车辆的车辆总成中包括的一个或多个硬件的硬件号；目标车辆的车辆总成中包括的一个或多个硬件的硬件版本；以及目标车辆的软件信息。

[0094] 在本申请实施例中，基于预设规则从多个软件版本数据中选择第一软件版本数据的方法可以参见上文关于预设规则实现方式的介绍，为了简洁，在此不再赘述。

[0095] 在步骤S340中，第三服务器向数据传输装置发送第二硬件数据。其中，第二硬件数据包括ECU信息，车辆总成信息，车辆总成中包括的一个或多个硬件的硬件号以及车辆总成中包括的一个或多个硬件的硬件版本。

[0096] 在步骤S350中，数据传输装置确定第一硬件数据是否与第二硬件数据匹配。

[0097] 在步骤S360中，若第一硬件数据与第二硬件数据匹配，数据传输装置确定第二硬件数据与第一软件版本数据是否匹配。

[0098] 在步骤S370中，若第二硬件数据与第一软件版本数据匹配，数据传输装置生成目标车辆的车辆数据。其中，目标车辆的车辆数据可以包括第一硬件数据、第二硬件数据以及第一软件版本数据。

[0099] 在步骤S380中，数据传输装置将目标车辆的车辆数据发送到诊断仪。

[0100] 在步骤S390中，诊断仪基于目标车辆的车辆数据对目标车辆进行检验。

[0101] 在一些实现方式中，在对目标车辆的功能进行检验之前，需要将目标车辆的配置数据发送到目标车辆，以便后续对目标车辆进行检验。因此，为了提高数据传输装置生成的车辆数据的完善性，可以在数据传输装置中设置车辆配置数据库，以存储目标车辆的配置数据。如此，数据传输装置可以基于车辆配置数据库获得目标车辆的配置数据。

[0102] 在一些实现方式中，上述配置数据可以是CAN 标定协议（CAN Calibration Protocol，CCP）配置字，即整车配置参数。在一些场景中，CCP配置字可以包括1556个配置参数，其中，每个配置参数代表一类属性。例如，CCP ID 为2时，对应的CCP CODE为02，可以用于描述车门数量。又例如，CCP ID 为3时，对应的CCP CODE为80，可以用于描述传动型式。又例如，CCP ID为4，对应的CCP CODE为80，可以用于描述电驱类型。又例如，CCP ID为8，对应的CCP CODE为01，可以用于描述方向盘位置。又例如，CCP ID为690对应的CCP CODE为01，可以用于描述车身颜色。

[0103] 如前文介绍，上述配置数据需要发送给目标车辆进行配置，在一些实现方式中，针对不同的配置数据可以配置给不同的ECU，以为对应的ECU配置控制功能。例如，CCP ID 为2时，对应的ECU可以为BGM。又例如，CCP ID 为3时，对应的ECU可以为BBM，BGM，IEM。又例如，CCP ID 为4时，对应的ECU可以为BGM，CCM，ECM3。又例如，CCP ID 为8时，对应的ECU可以为BGM，CCM，DDM。又例如，CCP ID 为690时，对应的ECU可以为CDC。

[0104] 在一些实现方式中，上述配置数据可以被承载于车辆数据中，发送给诊断仪。相应地，诊断仪拿到CCP配置字后可以写到目标车辆，然后目标车辆将各个配置数据广播给相关的ECU，各个ECU基于配置字实现各自的控制功能。

[0105] 在一些实现方式中，上述配置数据可以被承载于车辆数据中，发送给车辆中心，以便车辆中心可以基于配置数据进行调整，以满足客户需求。例如，数据传输装置中存储的CCP配置数据可以是车辆下线后的标准配置信息，或者说，是默认的车辆配置。相应地，车辆中心可以根据客户的要求，更改某些CCP配置数据。

[0106] 如前文所述，目标车辆的配置数据可以包括多个，相应地，数据传输装置中的处理单元可以对多个配置数据进行封装以生成车辆数据。在一些实现方式中，处理单元可以调用CCP解析逻辑对按照CCP ID的大小正序排序，并将每个CCP ID对应的CCP CODE拼接在一起，得到一个完整CCP数据（例如，0280800101），再对完整CCP数据进行CRC算法计算，得到一个长度4位的值（例如：03ce）。最后再将完整CCP数据与CRC计算后的值拼接起来，得到最终的CCP配置字（例如，028080010103ce）。

[0107] 在一些场景中，车辆配置数据库中存储的车辆配置为目标车辆的原始配置数据。当原始配置数据配置到目标车辆后，还需要对原始配置数据进行调整，得到目标配置数据以适配目标车辆。相应地，目标车辆的车辆数据中可以包括目标配置数据。

[0108] 在本申请实施例中，为了简化数据传输装置获取目标配置数据的过程，上述对原始配置数据的调整过程可以由数据传输装置执行。也即是说，上述车辆数据还包括目标车辆的目标配置数据，数据传输装置包括车辆配置数据库，车辆配置数据库，用于存储目标车辆的原始配置数据；处理单元，用于基于目标车辆的性能，对原始配置数据进行标定，得到目标配置数据；处理单元，还用于基于目标配置数据生成车辆数据。

[0109] 上述对原始配置数据的调整过程例如可以是对目标车辆的标定过程。在一些实现方式中，可以基于目标车辆的性能，对原始配置数据进行调整，以得到目标配置数据。在另一些实现方式中，可以基于目标车辆中某一硬件的性能，对原始配置数据进行调整，以得到目标配置数据。

[0110] 如上文所述，目标配置信息的生成需要依赖于标定协议，而不同的标定协议中数据的封装格式不同。而在生成车辆数据时，其中包含的是目标配置信息本身，并不是基于标定协议封装的目标配置信息。因此，为了简化数据传输装置获取目标配置信息的流程，数据传输装置中还可以设置有车辆配置数据的解析模块，以对基于标定协议的目标配置信息进行解封装，获取目标配置信息。

[0111] 在一些实现方式，为了对目标车辆的检验数据进行统一管理，可以在数据传输装置设置存储单元，以存储诊断仪上传的检验数据。通常，为了提高检验数据传输的安全性，诊断仪在传输检验数据之前可以对检验数据进行加密，相应地，数据传输装置接收到加密后的检验数据后，可以对加密的检验数据进行解密。

[0112] 也即是说，数据传输装置包括存储单元以及第四接口单元，用于从诊断仪处获取目标车辆的第一检验数据（又称电检数据），第一检验数据为目标车辆的第二检验数据的加密数据；处理单元，用于对第一检验数据进行解密，得到第二检验数据；存储单元，用于存储第二检验数据。

[0113] 在一些实现方式中，第一检验数据和/或第二检验数据可以包括以下一种或多种：目标车辆的检验结果数据，目标车辆的检验过程数据以及目标车辆的检验日志数据。以对目标车辆进行电检为例，上述第一电检数据和/或第二电检数据可以包括以下一种或多种：
目标车辆的电检结果数据，目标车辆的电检过程数据以及目标车辆的电检日志数据。

[0114] 在一些实现方式中，第一硬件数据可以封装在订单数据中，由第二服务器发送到数据传输装置，相应地，为了简化数据传输装置获取第一硬件数据的流程，可以在数据传输装置中设置订单解析模块，以对订单数据进行解析，获取第一硬件数据。

[0115] 在一些实现方式中，数据传输装置还可以将目标车辆的车辆数据发送到车辆中心，以便车辆中心记录目标车辆的车辆数据。相比于传统的方案中，目标车辆的车辆数据中不同的数据从不同的系统发送给车辆中心的方案，本申请实施例中，利用数据传输装置对车辆数据进行统一的管理，并将车辆数据作为一个整体发送到车辆中心，有助于减少车辆中心对目标车辆的车辆数据进行汇总时所需的工作量。

[0116] 另一方面，在本申请实施例中，利用数据传输装置可以将目标车辆的车辆数据分别发送到诊断仪以及车辆中心，相比于传统的方案中，由诊断仪以及车辆中心分别对车辆数据进行汇总，可能导致两方汇总后的车辆数据不匹配，有助于提高车辆数据的准确性。

[0117] 在一些实现方式中，数据传输装置可以位于委托方，为了保证数据传输装置访问的安全性，可以在数据传输装置中设置白名单，以管理代工方处可以访问数据传输装置的服务器。其中，白名单中例如可以存储有能够访问数据传输装置的服务器的网际互连协议（Internet Protocol，IP）地址，或者，白名单中例如可以存储有能够访问数据传输装置的服务器的标识信息。

[0118] 在一些实现方式中，可以设置软件管理单元来对上述多个软件版本数据进行管理。也即是说，第一服务器发送的多个软件版本数据可以存储在软件管理单元中，有助于对多个软件版本数据的统一管理。

[0119] 在一些实现方式中，为了降低重新搭建数据传输装置所需的成本，可以复用前文介绍的EOL，或者说，上述数据传输系统可以为EOL。当然，在本申请实施例中，数据传输装置可以是额外引入的装置。

[0120] 为了便于理解，下文结合图4和图5介绍本申请实施例中的数据传输装置。图4所示的数据传输装置400包括软件管理单元410、车辆配置数据库420、数据解析单元430、存储单元440。

[0121] 其中，软件管理单元410，用于存储从第一服务器的离线刷写软件管理后台，获取的多个软件版本数据。之后，软件管理单元410中存储的多个软件版本数据可以用于上文介绍的选择第一软件版本数据的过程。

[0122] 车辆配置数据库420，用于存储目标车辆的原始配置数据。之后，执行的目标车辆的标定过程中，可以从车辆配置数据库420中获取原始配置数据。

[0123] 数据解析单元430，包括配置数据解析单元431以及订单数据解析单元432。其中，配置数据解析单元431用于对基于标定协议封装的目标配置数据进行解析，以获取目标配置数据。订单数据解析单元432用于对第二服务器发送的订单数据进行解析，以获取订单数据中的第一硬件数据。

[0124] 存储单元440，用于存储从诊断仪处获取的目标车辆的第一检验数据和/或第二检验数据。

[0125] 图5示出了本申请实施例的数据传输装置与其他系统组成的网络拓扑结构。参见图5所示数据传输装置510可以与离线刷写软件管理后台520交互，以获取多个软件版本数据。其中，离线刷写软件管理后台520可以位于第一服务器。离线刷写软件管理后台520中的多个软件版本数据可以来自于位于云端的CDN 521以及虚拟服务提供商（Virtualization Service Provider，VSP）522。其中，CDN可以用于下发用于整车的软件版本数据，VSP用于下发多个软件版本数据，多个软件版本数据对应的软件下载地址，软件版本数据的启用指示以及软件版本数据的停用指示。

[0126] 数据传输装置510可以与诊断仪530进行通信，例如，数据传输装置510可以向诊断仪530发送目标车辆的车辆数据。又例如，数据传输装置510可以接收诊断仪530发送的目标车辆的第一检验数据和/或第二检验数据。

[0127] 其中，车辆数据除了上文介绍的数据之外，还可以包括目标车辆的胎压数据、用于选择软件版本数据的断点数据、CCP数据以及MES下线信息等。以检验数据为电检数据为例，电检数据可以包括电检过程数据，其中，电检过程数据可以包括固件空中下载软件升级（Firmware Over‑The‑Air，FOTA）记录，电检诊断记录、标记记录、钥匙匹配信息、目标车辆的软件版本数据、目标车辆的硬件版本数据、目标车辆的下线诊断完工信号。

[0128] 上述诊断仪530在获取到车辆数据和/或检验数据后，可以将车辆数据和/或检验数据传输到诊断仪产线管理模块531，以便诊断仪产线管理模块531对接收到的数据进行管理。其中，诊断仪产线管理模块531可以位于委托方的第一服务器。

[0129] 数据传输装置510可以从代工方的第二服务器获取目标车辆的第一硬件数据，以第一硬件数据包括胎压数据为例，第二服务器中可以设置有VCATS 541，相应地，VCATS可以将胎压数据发送到数据传输装置。另外，第二服务器中还可以设置有MES 542，MES除了可以向数据传输装置发送第一硬件数据之外，数据传输装置还可以将目标车辆的检验数据反馈给第二服务器中的MES。

[0130] 数据传输装置510可以将目标车辆的检验数据和/或目标车辆的车辆数据，发送到车辆中心550，以便车辆中心存储。

[0131] 在一些场景中，诊断仪530还可以与VSP进行通信，以便VSP下发多个软件版本数据，多个软件版本数据对应的软件下载地址，软件版本数据的启用指示以及软件版本数据的停用指示。

[0132] 在一些场景中，诊断仪530还可以与公钥基础设施(Public Key Infrastructure，PKI) 560进行通信，以便PKI向诊断仪发送PKI信息，PKI信息可以包括以下信息中的一种或多种：安全证书、VID、VIN、防盗信息、车身动态综合管理系统（VehicleDynamics Integrated Management，VDIM）序列号、子节点信息（例如，电子安全气囊（electronic control of safety airbag）信息）以及TCAM五码信息。

[0133] 在可选的实施例中，上述数据传输装置可以基于电子设备（例如，服务器）来搭建，相应地，所述第一接口单元210、第二接口单元220以及发送单元240可以为输入/输出接口630，所述处理单元230可以为处理器620，所述电子设备还可以包括存储器610，具体如图6所示。

[0134] 图6是本申请另一实施例的电子设备的示意性框图。图6所示的电子设备600可以包括：存储器610、处理器620以及输入/输出接口630。其中，存储器610、处理器620以及输入/输出接口630通过内部连接通路相连，该存储器610用于存储指令，该处理器620用于执行该存储器620存储的指令，以控制输入/输出接口630接收输入的数据和信息，输出操作结果等数据。

[0135] 应理解，在本申请实施例中，该处理器620可以采用通用的中央处理器（central processing  unit，CPU），微处理器，应用专用集成电路（application specific integrated circuit，ASIC），或者一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。

[0136] 该存储器610可以包括只读存储器和随机存取存储器，并向处理器620提供指令和数据。处理器620的一部分还可以包括非易失性随机存取存储器。例如，处理器620还可以存储设备类型的信息。

[0137] 在实现过程中，上述方法的各步骤可以通过处理器620 中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的用于请求上行传输资源的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器610，处理器620读取存储器610 中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。

[0138] 应理解，本申请实施例中，该处理器可以为中央处理单元（central processing unit，CPU），该处理器还可以是其他通用处理器、数字信号处理器（digital signal processor，DSP）、专用集成电路（application specific integrated circuit，ASIC）、现成可编程门阵列（field programmablegate array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

[0139] 上文结合图1至图6，详细描述了本申请的装置实施例，下面结合图6，详细描述本申请的方法实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

[0140] 图7是本申请实施例的用于车辆电检的方法的示意性流程图，所述方法应用于数据传输装置。图7所示的方法包括步骤S710至步骤S740。

[0141] 在步骤S710中，从第一服务器处获取目标车辆的第一软件版本数据。

[0142] 在步骤S720中，从第二服务器处获取所述目标车辆的第一硬件数据。

[0143] 在步骤S730中，基于所述第一软件版本数据以及所述第一硬件数据，生成所述目标车辆的车辆数据。

[0144] 在步骤S740中，向诊断仪发送所述车辆数据，所述车辆数据用于所述诊断仪对所述目标车辆的第二状态进行检验。

[0145] 在一些实现方式中，所述第一软件版本数据包括硬件号以及硬件版本信息，所述方法还包括：从第三服务器处获取第二硬件数据，所述第二硬件数据包括硬件号以及硬件版本信息，所述第三服务器位于所述第一网络域；若所述第一硬件数据与所述第二硬件数据匹配，基于所述第二硬件数据中的硬件号以及硬件版本信息与所述第一软件版本数据的硬件号以及硬件版本信息进行匹配，以确定所述第二硬件数据与所述第一软件版本数据是否匹配；若所述第二硬件数据与所述第一软件版本数据匹配，基于所述第一软件版本数据、所述第一硬件数据以及所述第二硬件数据，生成所述目标车辆的车辆数据。

[0146] 在一些实现方式中，所述第一硬件数据包括所述目标车辆的控制单元信息，所述第二硬件数据包括控制单元信息，所述方法还包括：基于所述第一硬件数据中包括的控制单元信息，以及所述第二硬件数据中包括的控制单元信息，确定所述第一硬件数据与所述第二硬件数据是否匹配，所述控制单元信息用于指示控制单元对应的控制功能。

[0147] 在一些实现方式中，所述方法还包括：从所述第一服务器处获取多个软件版本数据，所述多个软件版本数据包括所述第一软件版本数据；基于预设规则，从预存的多个软件版本数据中确定所述第一软件版本数据，所述第一软件版本数据与所述目标车辆相匹配。

[0148] 在一些实现方式中，所述预设规则用于指示所述目标车辆的车辆标识与软件版本数据的对应关系，所述方法还包括：基于所述预设规则，从所述多个软件版本数据中确定所述第一软件版本数据。

[0149] 在一些实现方式中，所述预设规则用于指示目标时间关联的车辆对应的软件版本数据，其中，所述目标时间关联的车辆包括在所述目标时间之后生产的车辆，所述方法还包括：基于所述预设规则，从所述多个软件版本中确定与所述目标时间对应的软件版本为所述目标软件版本，所述目标车辆的生产时间位于所述目标时间之后。

[0150] 在一些实现方式中，所述目标时间基于目标车辆标识确定，所述目标车辆标识中的目标字段用于指示所述目标时间。

[0151] 在一些实现方式中，所述方法还包括：从所述诊断仪处获取所述目标车辆的第一检验数据，所述第一检验数据为所述目标车辆的第二检验数据的加密数据；对所述第一检验数据进行解密，得到所述第二检验数据；存储所述第二检验数据，其中，所述第二检验数据包括以下一种或多种：所述目标车辆的检验结果数据，所述目标车辆的检验过程数据以及所述目标车辆的检验日志数据。

[0152] 在一些实现方式中，所述车辆数据包括以下一种或多种：所述目标车辆的车辆总成信息；所述目标车辆的车辆总成中包括的一个或多个硬件的硬件号；所述目标车辆的车辆总成中包括的一个或多个硬件的硬件版本；所述目标车辆的控制单元的信息，所述目标车辆的控制单元信息用于指示所述目标车辆中控制单元的功能。

[0153] 应理解，在本申请实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

[0154] 应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

[0155] 应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

[0156] 在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

[0157] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

[0158] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

[0159] 在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备、核心网设备、操作维护管理（operation administration and maintenance，OAM）或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber Line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用光盘（digital video disc，DVD））或者半导体介质（例如，固态硬盘（solid state disk，SSD））等。该计算机可读存储介质可以是易失性或非易失性存储介质，或可包括易失性和非易失性两种类型的存储介质。

[0160] 以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。