CN116389467A

CN116389467A - Data transmission device, method for checking a vehicle, vehicle and computer program product

Info

Publication number: CN116389467A
Application number: CN202310666663.6A
Authority: CN
Inventors: 王鹏豪; 胡成亮; 刘啸尘; 万前进; 龙鹏飞
Original assignee: Beijing Jidu Technology Co Ltd
Current assignee: Beijing Jidu Technology Co Ltd
Priority date: 2023-06-07
Filing date: 2023-06-07
Publication date: 2023-07-04
Anticipated expiration: 2043-06-07
Also published as: CN116389467B

Abstract

The application provides a data transmission device, a checking method of a vehicle, a vehicle and a computer program product, the data transmission device comprises: the first interface unit is used for acquiring first software version data of the target vehicle from a first server, and the first server is located in a first network domain; the second interface unit is used for acquiring the first hardware data of the target vehicle from a second server, and the second server is positioned in a second network domain; a processing unit configured to generate vehicle data of the target vehicle based on the first software version data and the first hardware data; a transmission unit configured to transmit vehicle data to the diagnostic apparatus, the vehicle data being used for the diagnostic apparatus to verify a second state of the target vehicle; wherein, the network segment of the first network domain is different from the network segment of the second network domain. In this way, even if the software version data of the target vehicle is separated from the hardware data, the hardware data of the target vehicle can be acquired by the data transmission device.

Description

Data transmission device, method for checking a vehicle, vehicle and computer program product

Technical Field

The present application relates to the field of data transmission technology, and in particular, to a data transmission device, a method for inspecting a vehicle, and a computer program product.

Background

Currently, before checking the second state of a vehicle to be detected (also referred to as a "target vehicle"), it is necessary to acquire hardware data and software version data of the target vehicle as support to check the second state of the target vehicle. However, in the actual production process of the target vehicle, the manufacturer of the target vehicle (also referred to as "consignor") may consign other manufacturers (also referred to as "consignors") to manufacture some hardware of the target vehicle, and at this time, the hardware data corresponding to the hardware manufactured by the consignor may be stored in the server (under Wen Youchen "second server") of the consignor, so that the consignor cannot communicate with the second server to obtain the hardware data, and thus the consignor cannot check the second state of the target vehicle.

Disclosure of Invention

Embodiments of the present application are directed to a data transmission device, a checking method of a vehicle, and a computer program product, which are described below in several aspects.

In a first aspect, there is provided a data transmission apparatus comprising: a first interface unit, configured to obtain first software version data of a target vehicle from a first server, where the first server is located in a first network domain; the second interface unit is further used for acquiring the first hardware data of the target vehicle from a second server, and the second server is located in a second network domain; a processing unit configured to generate vehicle data of the target vehicle based on the first software version data and the first hardware data; a transmission unit configured to transmit the vehicle data for checking a second state of the target vehicle to a diagnostic apparatus in the first network domain; the data transmission device is located in the first network domain or the second network domain, and a network segment where the first network domain is located is different from a network segment where the second network domain is located.

In a second aspect, there is provided a method of inspecting a vehicle, the method being performed by a data transmission device, the method comprising: obtaining first software version data of a target vehicle from a first server, wherein the first server is positioned in a first network domain; acquiring first hardware data of the target vehicle from a second server, wherein the second server is positioned in a second network domain; generating vehicle data of the target vehicle based on the first software version data and the first hardware data; transmitting the vehicle data to a diagnostic device in the first network domain, the vehicle data for use by the diagnostic device in verifying a function of the target vehicle; the data transmission device is located in the first network domain or the second network domain, and a network segment where the first network domain is located is different from a network segment where the second network domain is located.

In a third aspect, there is provided an electronic device comprising an input/output interface, a processor for controlling the input/output interface to transceive data, and a memory for storing a computer program, the processor being for invoking and running the computer program from the memory to cause the electronic device to perform the method of the second aspect.

In a fourth aspect, there is provided a computer program product comprising a computer program/instruction which when executed by a processor implements the method as described in the second aspect.

In some implementations, the computer program product described above includes computer program code that can include computer program code that, when run on a computer, causes the computer to perform the control method shown in the above aspects.

In other implementations, the computer program product includes a computer readable medium storing program code that, when run on a computer, causes the computer to perform the control method shown in the above aspects.

The embodiment of the application provides a data transmission device, which can be communicated with a first server and a second server to acquire first hardware data of a target vehicle from the second server in a second network domain, acquire first software version data of the target vehicle from the first network domain, generate vehicle data of the target vehicle based on the first hardware data and the first software version data, and transmit the vehicle data of the target vehicle to a diagnostic apparatus to detect a second state of the target vehicle. Thus, even if the network segments corresponding to the first network domain where the first server is located and the second network domain where the second server is located are different, the software version data of the target vehicle and the hardware data are stored separately, and the hardware data of the target vehicle can be obtained through the data transmission device.

Drawings

Fig. 1 is a schematic diagram of a data transmission scenario in an embodiment of the present application.

Fig. 2 is a schematic diagram of a data transmission device in an embodiment of the present application.

Fig. 3 presents a schematic flow chart of a data matching process of an embodiment of the present application.

Fig. 4 is a schematic diagram of a data transmission device according to another embodiment of the present application.

Fig. 5 is a schematic diagram of a data transmission device according to another embodiment of the present application.

Fig. 6 is a schematic block diagram of an electronic device according to another embodiment of the present application.

Fig. 7 is a schematic flow chart of a method of inspecting a vehicle of an embodiment of the present application.

Detailed Description

The following description of the technical solutions in the embodiments of the present application will be made clearly and completely with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments.

With the rapid development of automobile technology, particularly artificial intelligence, automobiles are not simply a sofa plus four wheels product. A car is a cumbersome and lengthy process from development design to mass-production for sale to consumers. The method comprises 5 main stages of market research, conceptual design, engineering design, sample car test and mass production. The manufacturing process of the automobile is mainly divided into: five processes of stamping, welding, coating, final assembly and detection are known as four processes and detection of automobiles. The detection is also called "End Of Line (EOL) detection", which is a function detection before the electronic product Of the automobile goes offline, in short, the EOL detection uses a dedicated EOL device (for example, a device injected with EOL test software), and when the electronic product Of the automobile goes offline, the electronic product Of the automobile can be connected to the EOL device to detect whether the function Of the product is normal. To facilitate understanding, EOL detection is described below.

The vehicle off-line detection refers to the process of detecting the functions of parts and controlling the quality of the whole vehicle in the production and manufacturing process of the automobile. In other words, the vehicle off-line detection is a detection for a vehicle in a second state, where the second state may be understood as a vehicle state in which a part or all of hardware of the vehicle is assembled, and software is written for a part or all of the hardware that is assembled. Accordingly, the first state of the target vehicle corresponds to the second state. The first state may be understood as a vehicle state in which some or all of the hardware assembly of the vehicle is complete, but the software has not yet been written.

Common detection processes include size matching detection, static function detection, front beam hub test, emission detection, rain and road test, etc., wherein the detection of the quality of the whole vehicle electronic and electric appliance (also called as electric detection) is increasingly complex and important. Taking an electronic control unit (Electric Control Unit, ECU) as an example, with diversification of requirements of people for vehicle functions, there are more and more ECUs that can be integrated on a vehicle (for example, more than 100 ECUs integrated in some vehicles). In this case, it becomes important to perform comprehensive detection of the electronic and electric systems of the off-line vehicle. However, if the vehicle is electrically inspected manually, the production efficiency of the vehicle is affected.

Assuming that a vehicle has 50 ECUs, 100 functions need to be checked, a single function manual check takes 30 seconds, and it takes about 50 minutes to check a vehicle, which is an obstacle to mass production of vehicles. Thus, automated inspection systems (e.g., end Off Line (EOL) systems have evolved that are similar to a vehicle data assembly shop, load all vehicle-required data into a vehicle, and fully check the vehicle's electrical functions.

Usually, before the vehicle is taken off line, the steps of ECU coding (data writing of an ECU) according to vehicle configuration, basic setting, testing and the like are required to be completed, the EOL system is based on diagnosis, and according to the section distribution of a final assembly workshop, the EOL system is usually provided with electric checking stations at different sections: instrument panel electrical apparatus detection station, door electrical apparatus detection station, pre-detection station, liquid feeding station, whole car electrical apparatus function detection station, toe-in and four-wheel positioning, hub detection, tail gas detection and whole car electrical apparatus final inspection.

Efficient operation of EOL systems also depends on efficient vehicle production information systems from which the EOL system needs to obtain vehicle orders, including production identification codes, serial numbers, production times, vehicle types, equipment lists, controller information, etc. for each vehicle, only if such information is obtained, can the EOL system properly personalize the vehicle (at this point, the vehicle is in the second state, i.e., the vehicle state after the completion of the software brush); in addition, the VTS needs to upload part of information to the production information system during the vehicle configuration process, including the detection results of each station of the vehicle, the serial number of the ECU, the torque value of the important bolts, the chassis adjustment value, and the like.

As described above, the EOL system will generally be provided with an electrical inspection station at a different station, and a common electrical inspection station will be described below as an example.

1, pre-detection working position

The instrument board detection station and the vehicle door detection station can be classified into pre-detection, and in fact, the instrument board detection station and the vehicle door detection station are eliminated for part of whole vehicle factories. The pre-test station is often arranged after the instrument panel is installed, and the controllers of the gateway, instrument, entertainment system, etc. are installed, so that the order of the vehicle is usually input into the tester because the communication between the vehicle and the EOL system is the first time. The pre-detection station can complete the initialization of the installed ECU, wherein the initialization refers to the encoding of the controller according to the source of a product development department, and in addition, detection steps which need to be executed in the offline detection process of the controller comprise encoding, basic setting, calibration, testing and the like (the specific controller may also need to be refreshed with software). In the present vehicles, many functions are not responsible for one controller, so that it is possible for the function to operate normally after all controllers that need to participate in the function have completed the step of detecting the offline. When the detection system is communicated with any one ECU on the vehicle, the information (part number, software version, hardware version and the like) of the ECU is firstly read, and then the information is compared with the information of the ECU which should be installed on the vehicle in the production system, so that the problem of incorrect installation of parts is timely found.

In addition to initializing some installed parts, for some vehicle models, the anti-theft application needs to be completed, so that the matching of the anti-theft system mainly refers to that the related information of the ECU (the serial number of the ECU) and the information of the specific vehicle to which the ECU is to be installed (for example, the vehicle identification codes Vehicle Identification Number and VIN) are sent to the server of the entruster, the binding of the ECU and the vehicle on the server is completed, the ECU also receives the secret key sent by the server, and the secret key needs to be written into the ECU, so that the vehicle cannot be started when the illegal ECU is installed on the vehicle.

2, liquid adding station

The liquid adding station is responsible for completing vehicle cooling liquid (cooling an engine, and consists of water, an antifreezing agent and an additive), the air conditioner refrigerant is the most widely used medium-low temperature environment-friendly refrigerant, and glass washing liquid and brake liquid (liquid medium for transmitting brake pressure in a hydraulic brake system, and commonly comprises: alcohol type, synthetic type, mineral oil type). Wherein the addition of brake fluid involves communication with the electronic stability system (Electronic Stability Program, ESP) of the vehicle body, and the filling device is operated separately and incorporated into the EOL system, but the filling process is similar, and the relevant routine of the ESP is performed in accordance with defined operating steps, the operation of the filling device being coordinated.

3, detecting station for functions of whole electric appliances

After the installation of the parts of the whole vehicle is basically finished, preparation is needed for the first starting of the vehicle, at the moment, the vehicle enters a function detection station of the electric appliance of the whole vehicle, the station can finish the initialization and the test of all controllers, namely, data needed by all ECUs are written in, the basic setting of part of ECUs is finished, test items of the ECUs are needed to be executed, the test items comprise automatic test and manual test, the station is always the heaviest task in all electric detection stations, and the problem is the greatest.

The initialization part comprises ECU data writing, basic setting of part of the ECU and vehicle anti-theft matching. The data writing of all the ECUs can be completed, even if part of the ECUs are written with data during pre-detection, the complete vehicle electrical appliance detection station needs to ensure that the vehicle completes all the electrical detection (the reason of the previous execution failure is solved) and is smoothly disconnected even if the pre-detection execution fails or is not executed during production. Because of the large number of vehicle ECUs, the ECUs are generally distinguished according to buses in the actual operation process, and a parallel data writing method is adopted. The method has the characteristics of large data writing quantity in the process, large number of operation controllers, easy occurrence of accidental writing errors, difficult tracking and recording and high analysis difficulty, and can refer to previous project experience in production to optimize parallel design. In order to reduce the bus load in the writing process, the diagnosis service control part ECU can be used for stopping sending the message, and the function of the ECU is recovered after the data writing is completed. The basic setting of the initialization part comprises position learning of a vehicle window, position learning of a sky window and air door matching of an air conditioner, and the controller is required to control the action of the actuator to know the start and stop positions after the completion of assembly because the state of the actuator after installation is not known when the controller is developed. After the above is completed, all the ECU fault codes (DiagnosticTrouble Code, DTCs) need to be deleted, since many active DTCs become passive and can be cleared after the data writing, base set-up and anti-theft matching are completed.

The test part comprises automatic test and manual test, wherein the diagnostic service in the automatic test item activates a routine designed during the development of the ECU and used for checking the input and output functions of the ECU (such as a routine that the BCM can sequentially test the external lights of the vehicle), and tests on specific input and output of the ECU (such as the activation of the heating function of the external rearview mirror). The manual test is a test item which cannot be independently finished by the ECU, and mainly comprises an actuator and a sensor test, for example, whether a vehicle horn works normally (the actuator), and whether a passenger monitoring sensor of a seat works normally (the sensor) needs the participation of an operator.

4, toe-in station

The toe-in station (different stations, equipment and detection items of the main machine factory exist) is used for weighing the vehicle, four-wheel positioning (adjusting the toe-in and camber of the wheels to meet the definition of a development department), headlight adjustment and controller calibration (adaptive cruise control system (Adaptive Cruise Control, ACC), a multifunctional camera, lane changing assistance, head up display and the like). Unlike pre-detection and full vehicle function detection stations, the toe-in station, the hub turning station and the filling station need to perform information communication between the EOL system and detection equipment (filling equipment, toe-in equipment, hub turning equipment) in addition to information communication between the EOL system and the vehicle. When the ACC is calibrated, the tester firstly tells the front beam equipment to move the ACC calibration target plate to the front of the vehicle and is in the detection range of the ACC, then the tester sends a diagnosis instruction to the ACC to require the ACC to start calibration, the calibration process is similar to the automatic focusing of the digital camera, the user operation activates the automatic focusing function of the digital camera, the focusing process is completed by the digital camera, the calibration process is started after the ACC receives the command of the tester, and if all the calibration processes are normal, the ACC can be calibrated successfully. The front beam station usually designs four-wheel positioning, light adjustment and controller calibration into parallel test, so that working hours are saved, but a certain logic relationship exists in parallel, and the design is required according to actual conditions.

The EOL system applicable to the embodiment of the present application is described above, and a scenario applicable to the embodiment of the present application is described below with reference to fig. 1. The scenario illustrated in fig. 1 includes a first network domain 110, which may be located at a consigner of a target vehicle, and a second network domain 120, which may be located at a proxy of the target vehicle, wherein the first network domain 110 and the second network domain 120 are located at different network segments (network segments). A network segment generally refers to that portion of a computer network that is capable of direct communication using the same physical layer device (e.g., transmission medium, repeater, hub, etc.). Accordingly, the first network domain 110 and the second network domain 120 are located in different network segments, so that direct communication between the device in the first network domain (e.g., the first server) and the device in the second network domain (e.g., the second server) is not possible, or communication between the first network domain and the second network domain is isolated. The first network domain 110 may include a first server, a detector, etc. The first server 111 is configured to store first software version data of a target vehicle.

The second network domain 120 may include a second server 121, wherein the second server may be used to store the first hardware data of the target vehicle. The first hardware data may include hardware data of hardware in a target vehicle manufactured by a substitute party. In some implementations, the first hardware data may include vehicle assembly information for the target vehicle, where the vehicle assembly may be understood to be a vehicle component that includes several parts, components, assemblies, or combinations of accessories assembled and having independent functionality, e.g., the vehicle assembly may include one or more of an engine, a transmission, a steering gear, a front axle, a rear axle, a body, a frame, and a cab.

In the embodiment of the present application, the first hardware data is not limited. In some implementations, the first hardware data may also include a vehicle identification number (Vehicle Identification Number, VIN) of the target vehicle, or the like.

In addition, based on the above description, the first server and/or the second server may be understood as participating in the manufacturing process of the target vehicle, that is, the first server and/or the second server may be located on the production line of the production target vehicle, and thus, the first server and/or the second server may be also referred to as the production line server.

Currently, before checking the second state of a vehicle to be detected (also referred to as a "target vehicle"), it is necessary to acquire hardware data and software version data of the target vehicle as support to check the second state of the target vehicle. However, in the actual production process of the target vehicle, the manufacturer of the target vehicle (also referred to as "consignor") may consign other manufacturers (also referred to as "consignors") to manufacture some hardware of the target vehicle, and at this time, the hardware data corresponding to the hardware manufactured by the consignor may be stored in the server (under Wen Youchen "second server") of the consignor, so that the consignor cannot communicate with the second server to obtain the hardware data, and thus the consignor cannot check the second state of the target vehicle based on the hardware data.

Therefore, in view of the above-mentioned problems, the embodiments of the present application provide a data transmission device that may communicate with a first server and a second server to obtain first hardware data of a target vehicle from the second server in a second network domain, obtain first software version data of the target vehicle from the first network domain, generate vehicle data of the target vehicle based on the first hardware data and the first software version data, and then transmit the vehicle data of the target vehicle to a diagnostic apparatus to detect a second state of the target vehicle. Thus, even if the network segments corresponding to the first network domain where the first server is located and the second network domain where the second server is located are different, the hardware data of the target vehicle can be obtained through the data transmission device even if the software version data of the target vehicle is stored separately from the hardware data.

For ease of understanding, a data transmission device according to an embodiment of the present application is described below with reference to fig. 2. Fig. 2 is a schematic diagram of a data transmission device in an embodiment of the present application. The data transmission apparatus 200 shown in fig. 2 may include a first interface unit 210, a second interface unit 220, a processing unit 230, and a transmitting unit 240.

A first interface unit 210 for acquiring first software version data of the target vehicle from the first server 111;

the second interface unit 220 is further configured to obtain first hardware data of the target vehicle from the second server 121;

a processing unit 230 for generating vehicle data of the target vehicle based on the first software version data and the first hardware data;

and a transmission unit 240 for transmitting vehicle data for checking the second state of the target vehicle to the diagnostic apparatus.

As previously described, the second state may be understood as a vehicle state in which some or all of the hardware of the vehicle is assembled and software is written for some or all of the hardware that is assembled. Wherein the hardware assembly may be performed, for example, by a related device in the second network domain. The software flashing may be controlled, for example, by an associated device in the first network domain.

In some implementations, the data transmission device may be located in the second network domain, that is, the data transmission device may be located in a network domain of the vehicle proxy, which helps to improve reliability of the second server sending the first hardware data to the data transmission device. Of course, in the embodiment of the present application, the data transmission device may also be located in the first network domain, which is helpful for improving the reliability of the first server sending the first software version data.

The first software version data may be used to indicate software related information. In some implementations, the first software version data may include one or more of information of a control unit (e.g., ECU) to which the software version applies, information of hardware to which the software version applies, and software information. The information of the hardware suitable for the software version may be, for example, a hardware number suitable for the software version, and the information of the hardware suitable for the software version may be, for example, a hardware version suitable for the software version.

The embodiment of the application does not limit the transmission mode of the first software version data. For example, the first software version data may be obtained from an offline flashing software management background in the first server. As another example, the first software version data may also be obtained from a content delivery network (Content Delivery Network, CDN). The details of the process will be described in conjunction with fig. 5, and are not repeated here for brevity.

The first hardware data may be used to indicate hardware-related information of the target vehicle. In some implementations, the first hardware data may include VIN of the target vehicle, control unit (e.g., ECU) information of the target vehicle, and assembly information of the target vehicle. The control unit information may indicate a control function of the control unit, and the assembly information may include a DU number, for example.

The embodiment of the application does not limit the transmission mode of the first hardware data. For example, the first hardware data may be obtained from a manufacturing execution system (Manufacturing Execution System, MES) in the second server. For example, the first hardware data may be carried in a vehicle broadcast file that is broadcast by the MES system to the data transfer device. The vehicle broadcast file may be an explanatory format text (e.g., text based on extensible markup language (Extensible Markup Language, XML)) that the vehicle broadcasts the manufacturing-related hardware configuration and VIN data to downstream systems at the shop assembly on-line station node for the downstream systems to receive information needed for the subsequent stations after post-processing. The downstream system may be, for example, a diagnostic device, or a vehicle center. The following description is detailed in conjunction with fig. 5, and for brevity, will not be repeated here.

The vehicle data of the target vehicle may be used to verify (e.g., electrically check) the second state of the target vehicle, or the vehicle data may include data required to verify the second state of the target vehicle. For example, the vehicle data may include first software version data and first hardware data.

In some implementations, the data transmission device may transmit the data through an intranet for security in the data transmission process. For example, the data transmission device may obtain the first software version data from the first server through the intranet. For another example, the data transmission device may obtain the first hardware data from the second server through the intranet. For another example, the data transmission device may send the vehicle data to the diagnostic apparatus via an intranet. Of course, in the embodiment of the present application, the data transmission device may also transmit the data through the public network, which is not limited in the embodiment of the present application.

It should be noted that the intranet is understood to be a local area network (Local Area Network, LAN), which is a private network, typically in or near a building, such as a home, office, or factory. Local area networks generally have higher security, so that data transmission is performed based on an intranet, which is helpful for improving the security of data transmission.

In some scenarios, the data transmission device may acquire multiple software versions from the first server, and at this time, the data transmission device may determine software version data (i.e., the first software version data) that matches the target vehicle based on a preset rule. That is, the processing unit is further configured to: obtaining a plurality of software version data from a first server, the plurality of software information including the first software version data; based on a preset rule, determining first software version data from a plurality of pre-stored software version data, wherein the first software version data is matched with a target vehicle.

It should be noted that, the software version data matching with the target vehicle may be understood as a software version corresponding to a vehicle identifier (for example, VIN) of the target vehicle, or may be understood as a software version matching with hardware data of the target vehicle.

In some implementations, to reduce the cost of re-building the data transmission device, the EOL system may be multiplexed as the data transmission device. Of course, in the embodiment of the present application, the data transmission device may also be a stand-alone system independent of the EOL system.

The specific implementation manner of the preset rule in the embodiment of the present application is not limited. The following description is provided in connection with the implementation modes 1 to 3, respectively.

In implementation 1, the preset rule is used to indicate a correspondence between a vehicle identifier of the target vehicle and software version data.

Accordingly, the processing unit is configured to determine the first software version data from the plurality of software version data based on a preset rule.

In some implementations, the vehicle identification may be VIN, where the vehicle identification code may be considered an identification number of the vehicle, which may be determined according to national vehicle management standards. In general, VIN contains information about the manufacturer, age, model, body type and code, engine code, and assembly location of the vehicle. In other implementations, the vehicle identifier may also be a license plate number of the target vehicle.

In the embodiment of the present application, the correspondence between the vehicle identifier and the software version is not limited. In some implementations, the vehicle identification may be in one-to-one correspondence with the software version data. In other implementations, the software version data may correspond to a plurality of vehicle identifications.

In the embodiment of the application, the software version data can be respectively designated for the vehicle, so that the accuracy of configuring the software version data for the vehicle is improved.

In implementation 2, the preset rule is used to indicate software version data corresponding to the vehicle associated with the target vehicle identifier.

The vehicle associated with the target vehicle identification includes a vehicle that is produced after a production time indicated by the target vehicle identification. That is, a vehicle produced after the production time indicated by the target vehicle identification may correspond to one software version data. A preset rule of this type may be understood as a vehicle identification of a vehicle as a breakpoint, and a produced vehicle after the breakpoint may correspond to a software version data, and thus the preset rule may also be referred to as "vehicle identification breakpoint control".

Correspondingly, the processing unit is further configured to determine, from the plurality of software version data, that the software version data corresponding to the target vehicle identifier is the first software version data, based on a preset rule, where the production time of the target vehicle is located after the production time indicated by the target vehicle identifier.

For example, if the target vehicle identification indicates a production time of 2022 months 2, the preset conditions may include that the vehicle produced 2 months after 2022 may correspond to software release data a. At this time, if the production time of the target vehicle is 2022, 3 months, the software version data corresponding to the target vehicle may be software version data a.

Of course, in the embodiment of the present application, the vehicle associated with the target vehicle identifier may include a vehicle that is produced before the production time indicated by the target vehicle identifier, that is, a vehicle that is produced before the production time indicated by the target vehicle identifier may correspond to one software version data.

In the embodiment of the application, in the configuration of the preset rule, the vehicle identifier of the vehicle can be used as a breakpoint, and the produced vehicle after the breakpoint can correspond to software version data, so that the configuration process of the preset rule is simplified.

In implementation 3, the preset rule is used to indicate software version data corresponding to the vehicle associated with the target time.

The above-described target time-associated vehicle includes a vehicle produced after the target time. That is, the vehicle produced after the target time may correspond to one software version data. A preset rule of this type may be understood as taking the production time of the vehicle as a break point, and the vehicle produced after the break point may correspond to a software version data, and thus the preset rule may also be referred to as "time break point control".

The target time is not limited in the embodiment of the present application. For example, the target time may be expressed in the form of a date. For another example, the target time may be specific to one hour of a day.

Correspondingly, the processing unit is further used for determining that the software version corresponding to the target time is the target software version from the plurality of software versions based on the preset rule, and the production time of the target vehicle is located after the target time.

For example, the target time is 2022 month 5, and the preset condition may include that the produced vehicle after 2022 month 5 may correspond to the software version data B. At this time, if the production time of the target vehicle is 2022, 6 months, the software version data corresponding to the target vehicle may be software version data B.

Of course, in the embodiment of the present application, the vehicle associated with the target time may include a vehicle that is produced before the target time, that is, the vehicle that is produced before the target time may correspond to one software version data.

The above-described 3 implementations of preset conditions in the embodiments of the present application. The implementation manner in the above 3 may be used alone or in combination with each other. In some implementations, implementation 2 and implementation 3 may be used in combination with each other, which helps to improve flexibility in configuring software version data for a vehicle.

For example, preset rule 1 employs implementation 2, and preset rule 2 employs implementation 3. If the production time indicated by the target vehicle identifier in the preset rule 1 is 2022 months 2, the preset condition 1 may include that the produced vehicle after 2022 months 2 may correspond to the software version data a. The target time in the preset rule 2 is 2022 month 5, and then the preset condition 2 may include that the produced vehicle after 2022 month 5 may correspond to the software version data B.

At this time, between 2 months and 5 months in 2022, the produced vehicle may correspond to the software version data a. Vehicles produced after 5 months 2022 may correspond to software release data B.

In some scenarios, the first server may not store the hardware number and hardware version information in the target vehicle, but may need such hardware data (next Wen Youchen "second hardware data") when the target vehicle is electrically checked. The information is stored in a server (also called a third server) of the consignor, or the third server is located in the first network domain, and the data transmission device also needs to acquire second hardware data corresponding to the target vehicle from the third server. However, the third server may store a plurality of second hardware data, and the data transmission device needs to find out the second hardware data matched with the first hardware data from the plurality of second hardware data, that is, the second hardware data of the target vehicle.

At this time, it is known based on the above description that the control unit information is included in the first hardware data, and since the control unit information is also included in the second hardware data, at this time, the second hardware data matching the first hardware data can be determined based on the control unit information in the first hardware data and the control unit information in the second hardware data.

That is, the first hardware data includes control unit information of the target vehicle, the second hardware data includes control unit information, and the processing unit is further configured to determine whether the first hardware data matches the second hardware data based on the control unit information included in the first hardware data and the control unit information included in the second hardware data, where the control unit information is configured to indicate a control function corresponding to the control unit.

In some implementations, the first software version data matched with the second hardware data can be determined based on the second hardware data, namely the first software version data comprises a hardware number and hardware version information, the third interface unit is further used for acquiring the second hardware data from a third server, the second hardware data comprises the hardware number and the hardware version information, and the third server is located in the first network domain; if the first hardware data is matched with the second hardware data, the processing unit is further used for matching the hardware number and the hardware version information in the second hardware data with the hardware number and the hardware version information of the first software version data so as to determine whether the second hardware data is matched with the first software version data or not; if the second hardware data is matched with the first software version data, the processing unit is further configured to generate vehicle data of the target vehicle based on the first software version data, the first hardware data and the second hardware data.

The third server is not limited in this embodiment of the present application. In some implementations, the third server may be the same server as the first server, or the third server may belong to the same server cluster as the first server. In other implementations, the third server may be a different server than the first server, or the third server may belong to a different server cluster than the first server.

In some implementations, a Bill of materials (BOM) system for manufacturing the target vehicle may be provided in the third server, and accordingly, the data transmission device may acquire the second hardware data from the BOM system.

As described above, the data transmission device may generate data required for functional detection of the target vehicle, that is, the vehicle data may include the first hardware data, the second hardware data, and the first software version data. In order to ensure that the above-mentioned data contained in the vehicle data are matched with each other, it is necessary to determine whether the first hardware data matches the first software version data and/or whether the second hardware data matches the first software version data, in addition to the first hardware data and the second hardware data.

In some implementations, the above three data matches each other, which can be understood to satisfy one or more of the following: the first software version data comprises control unit information applicable to the software version, and the control unit information included in the first software version data is matched with the control unit information in the first hardware data; the first software version data comprises a hardware number of hardware suitable for the software version, and the hardware number in the first software version data is matched with the hardware number in the second hardware data; the first software version data comprises hardware version information applicable to the software version, and the hardware version information in the first software version data is matched with the hardware version information in the second hardware data.

In the embodiment of the present application, the execution order for determining whether the three data are matched is not limited. In some implementations, the matching process between the first hardware data and the first software version data may be performed first, then the matching process between the first hardware data and the second hardware data may be performed, and finally the matching process between the first software version data and the second hardware data may be performed (also referred to as "execution sequence 1"). In other implementations, the matching process between the first hardware data and the second hardware data may be performed first, and then the matching process between the first software version data and the first hardware data and the second hardware data may be performed.

For ease of understanding, the data matching process of the embodiments of the present application will be described below with reference to fig. 3 by taking order of execution 1 as an example. The steps shown in fig. 3 include steps S310 to S390.

In step S310, the second server broadcasts a vehicle broadcast file to the data transmission device, wherein the vehicle broadcast file includes the first hardware data. The first hardware data includes one or more of VIN of the target vehicle, ECU information of the target vehicle, DU number of the target vehicle, and issue time of the first hardware data.

In step S320, the first server transmits a plurality of software version data to the data transmission device.

In step S330, the data transmission apparatus selects first software version data matching the first hardware data from the plurality of software version data based on a preset rule. The first software version data includes ECU information of the target vehicle, a hardware number of one or more hardware included in a vehicle assembly of the target vehicle; a hardware version of one or more hardware included in a vehicle assembly of a target vehicle; and software information of the target vehicle.

In this embodiment of the present application, the method for selecting the first software version data from the plurality of software version data based on the preset rule may be referred to the above description about the implementation manner of the preset rule, and for brevity, will not be described herein.

In step S340, the third server transmits the second hardware data to the data transmission device. Wherein the second hardware data includes ECU information, vehicle assembly information, a hardware number of one or more hardware included in the vehicle assembly, and a hardware version of one or more hardware included in the vehicle assembly.

In step S350, the data transmission apparatus determines whether the first hardware data matches the second hardware data.

In step S360, if the first hardware data matches the second hardware data, the data transmission device determines whether the second hardware data matches the first software version data.

In step S370, if the second hardware data matches the first software version data, the data transmission device generates vehicle data of the target vehicle. The vehicle data of the target vehicle may include first hardware data, second hardware data, and first software version data, among others.

In step S380, the data transmission device transmits the vehicle data of the target vehicle to the diagnostic apparatus.

In step S390, the diagnostic apparatus checks the target vehicle based on the vehicle data of the target vehicle.

In some implementations, prior to verifying the functionality of the target vehicle, configuration data of the target vehicle needs to be sent to the target vehicle for subsequent verification of the target vehicle. Therefore, in order to improve the integrity of the vehicle data generated by the data transmission device, a vehicle configuration database may be provided in the data transmission device to store the configuration data of the target vehicle. In this way, the data transmission device can obtain the configuration data of the target vehicle based on the vehicle configuration database.

In some implementations, the configuration data may be a CAN calibration protocol (CAN Calibration Protocol, CCP) configuration word, i.e., vehicle configuration parameters. In some scenarios, a CCP configuration word may include 1556 configuration parameters, where each configuration parameter represents a class of attributes. For example, when CCP ID is 2, the corresponding CCP CODE is 02, which can be used to describe the number of doors. For another example, when the CCP ID is 3, the corresponding CCP CODE is 80, which can be used to describe the transmission type. Also for example, a CCP ID of 4 and a corresponding CCP CODE of 80 may be used to describe the type of electric drive. For another example, a CCP ID of 8 and a corresponding CCP CODE of 01 may be used to describe the steering wheel position. For another example, a CCP CODE corresponding to a CCP ID of 690 being 01 may be used to describe the body color.

As described above, the configuration data may be sent to the target vehicle for configuration, and in some implementations, different ECU may be configured for different configuration data to configure control functions for the corresponding ECU. For example, when the CCP ID is 2, the corresponding ECU may be BGM. For another example, when the CCP ID is 3, the corresponding ECU may be BBM, BGM, IEM. For another example, when CCP ID is 4, the corresponding ECU may be BGM, CCM, ECM3. For another example, when the CCP ID is 8, the corresponding ECU may be BGM, CCM, DDM. For another example, when the CCP ID is 690, the corresponding ECU may be CDC.

In some implementations, the configuration data may be carried in vehicle data and sent to a diagnostic instrument. Accordingly, the diagnostic instrument can write to the target vehicle after receiving the CCP configuration word, and then the target vehicle broadcasts each configuration data to the associated ECU, each ECU implementing its respective control function based on the configuration word.

In some implementations, the configuration data may be carried in vehicle data and sent to a vehicle center so that the vehicle center may adjust to meet customer needs based on the configuration data. For example, CCP configuration data stored in the data transmission device may be standard configuration information after the vehicle is taken off line, or alternatively, a default vehicle configuration. Accordingly, the vehicle center may alter certain CCP configuration data based on customer requirements.

As previously described, the configuration data of the target vehicle may include a plurality, and accordingly, the processing unit in the data transmission device may encapsulate the plurality of configuration data to generate the vehicle data. In some implementations, the processing unit may invoke the CCP parsing logic to sort in positive order of the sizes of CCP IDs and concatenate CCP CODEs corresponding to each CCP ID to obtain a complete CCP data (e.g., 0280800101), and then perform CRC algorithm calculation on the complete CCP data to obtain a value of 4 bits in length (e.g., 03 ce). Finally, the complete CCP data is spliced with the CRC calculated value to obtain the final CCP configuration word (e.g., 028080010103 ce).

In some scenarios, the vehicle stored in the vehicle configuration database is configured as raw configuration data for the target vehicle. When the original configuration data is configured to the target vehicle, the original configuration data is also required to be adjusted to obtain the target configuration data so as to adapt to the target vehicle. Accordingly, the target configuration data may be included in the vehicle data of the target vehicle.

In the embodiment of the present application, in order to simplify the process of the data transmission device acquiring the target configuration data, the above-mentioned adjustment process for the original configuration data may be performed by the data transmission device. That is, the above-mentioned vehicle data further includes target configuration data of the target vehicle, and the data transmission device includes a vehicle configuration database for storing raw configuration data of the target vehicle; the processing unit is used for calibrating the original configuration data based on the performance of the target vehicle to obtain target configuration data; and the processing unit is also used for generating vehicle data based on the target configuration data.

The above-described adjustment process to the original configuration data may be, for example, a calibration process to the target vehicle. In some implementations, the raw configuration data may be adjusted based on the performance of the target vehicle to obtain the target configuration data. In other implementations, the raw configuration data may be adjusted based on the performance of a piece of hardware in the target vehicle to obtain the target configuration data.

As described above, the generation of the target configuration information needs to depend on the scaling protocol, and the encapsulation formats of the data in different scaling protocols are different. And when generating the vehicle data, the target configuration information is contained in the vehicle data, and is not the target configuration information packaged based on the calibration protocol. Therefore, in order to simplify the process of acquiring the target configuration information by the data transmission device, the data transmission device may be further provided with an analysis module of the vehicle configuration data, so as to unpack the target configuration information based on the calibration protocol and acquire the target configuration information.

In some implementations, for unified management of the test data of the target vehicle, a storage unit may be provided at the data transmission device to store the test data uploaded by the diagnostic apparatus. In general, in order to improve the security of the transmission of the test data, the diagnostic device may encrypt the test data before transmitting the test data, and accordingly, the data transmission device may decrypt the encrypted test data after receiving the encrypted test data.

That is, the data transmission device includes a storage unit and a fourth interface unit for acquiring first test data (also called as electrical test data) of the target vehicle from the diagnostic apparatus, the first test data being encrypted data of second test data of the target vehicle; the processing unit is used for decrypting the first check data to obtain second check data; and a storage unit for storing the second verification data.

In some implementations, the first verification data and/or the second verification data may include one or more of: inspection result data of the target vehicle, inspection process data of the target vehicle, and inspection log data of the target vehicle. Taking an electrical inspection of a target vehicle as an example, the first electrical inspection data and/or the second electrical inspection data may include one or more of the following: electric inspection result data of the target vehicle, electric inspection process data of the target vehicle, and electric inspection log data of the target vehicle.

In some implementations, the first hardware data may be encapsulated in order data and sent to the data transmission device by the second server, and accordingly, in order to simplify a flow of the data transmission device for obtaining the first hardware data, an order analysis module may be provided in the data transmission device to analyze the order data and obtain the first hardware data.

In some implementations, the data transmission device may also send the vehicle data of the target vehicle to the vehicle center so that the vehicle center records the vehicle data of the target vehicle. Compared with the scheme that different data in the vehicle data of the target vehicle are sent to the vehicle center from different systems in the traditional scheme, in the embodiment of the application, the data transmission device is used for uniformly managing the vehicle data and sending the vehicle data to the vehicle center as a whole, so that the workload required by the vehicle center for summarizing the vehicle data of the target vehicle is reduced.

On the other hand, in the embodiment of the application, the data transmission device can be used for respectively sending the vehicle data of the target vehicle to the diagnostic instrument and the vehicle center, and compared with the traditional scheme, the diagnostic instrument and the vehicle center respectively summarize the vehicle data, which may result in mismatching of the summarized vehicle data of the two parties, and is beneficial to improving the accuracy of the vehicle data.

In some implementations, the data transmission device may be located at a trusted party, and to ensure security of access to the data transmission device, a whitelist may be set in the data transmission device to manage servers at the agent that may access the data transmission device. The white list may store, for example, an internet protocol (Internet Protocol, IP) address of a server capable of accessing the data transmission apparatus, or may store, for example, identification information of a server capable of accessing the data transmission apparatus.

In some implementations, a software management unit may be configured to manage the plurality of software version data. That is, the plurality of software version data transmitted from the first server may be stored in the software management unit, which facilitates unified management of the plurality of software version data.

In some implementations, the EOL described above may be multiplexed, or the data transmission system described above may be EOL, in order to reduce the cost required to re-build the data transmission device. Of course, in the embodiment of the present application, the data transmission device may be an additionally introduced device.

For ease of understanding, the data transmission device in the embodiment of the present application is described below with reference to fig. 4 and 5. The data transmission apparatus 400 shown in fig. 4 includes a software management unit 410, a vehicle configuration database 420, a data parsing unit 430, and a storage unit 440.

The software management unit 410 is configured to store a plurality of software version data acquired from an offline software management background of the first server. Thereafter, the plurality of software version data stored in the software management unit 410 may be used in the above-described process of selecting the first software version data.

The vehicle configuration database 420 is used to store raw configuration data of the target vehicle. Thereafter, during the calibration of the target vehicle, raw configuration data may be obtained from the vehicle configuration database 420.

The data parsing unit 430 includes a configuration data parsing unit 431 and an order data parsing unit 432. The configuration data parsing unit 431 is configured to parse the target configuration data encapsulated based on the calibration protocol to obtain the target configuration data. The order data parsing unit 432 is configured to parse the order data sent by the second server to obtain first hardware data in the order data.

The storage unit 440 is used for storing the first test data and/or the second test data of the target vehicle acquired from the diagnostic apparatus.

Fig. 5 shows a network topology of the data transmission device and other systems according to the embodiment of the present application. Referring to fig. 5, the data transfer device 510 may interact with an offline flash software management background 520 to obtain a plurality of software version data. Wherein the offline software management background 520 may be located on the first server. The plurality of software version data in the offline flash software management background 520 may come from the cloud-located CDN 521 and virtual service provider (Virtualization Service Provider, VSP) 522. The CDN may be configured to issue software version data for the whole vehicle, and the VSP may be configured to issue a plurality of software version data, software download addresses corresponding to the plurality of software version data, an enable indication of the software version data, and a disable indication of the software version data.

The data transmission device 510 may be in communication with the diagnostic instrument 530, for example, the data transmission device 510 may transmit vehicle data of the target vehicle to the diagnostic instrument 530. For another example, the data transmission device 510 may receive the first test data and/or the second test data of the target vehicle transmitted by the diagnostic device 530.

The vehicle data may include tire pressure data of the target vehicle, breakpoint data for selecting software version data, CCP data, MES-off-line information, and the like, in addition to the data described above. Taking test data as electrical test data, the electrical test data may include electrical test process data, where The electrical test process data may include Firmware Over-The-Air (FOTA) records, electrical test diagnostic records, tag records, key matching information, software version data of The target vehicle, hardware version data of The target vehicle, and off-line diagnostic complete signals of The target vehicle.

After the diagnostic apparatus 530 acquires the vehicle data and/or the inspection data, the vehicle data and/or the inspection data may be transmitted to the diagnostic apparatus line management module 531 so that the diagnostic apparatus line management module 531 manages the received data. Wherein the diagnostic instrument production line management module 531 may be located at the first server of the consignor.

The data transmission device 510 may acquire first hardware data of the target vehicle from a second server of the substitute side, for example, the first hardware data includes tire pressure data, and the second server may be provided therein with the VCATS 541, and accordingly, the VCATS may transmit the tire pressure data to the data transmission device. In addition, the second server may be further provided with an MES 542, and the MES may send the first hardware data to the data transmission device, and the data transmission device may feed back the inspection data of the target vehicle to the MES in the second server.

The data transmission device 510 may transmit the inspection data of the target vehicle and/or the vehicle data of the target vehicle to the vehicle center 550 for storage by the vehicle center.

In some scenarios, diagnostic apparatus 530 may also communicate with a VSP to issue a plurality of software version data, a software download address corresponding to the plurality of software version data, an enable indication of the software version data, and a disable indication of the software version data.

In some scenarios, the diagnostic apparatus 530 may also communicate with a public key infrastructure (Public Key Infrastructure, PKI) 560 for the PKI to send PKI information to the diagnostic apparatus, which may include one or more of the following: security certificates, VID, VIN, theft protection information, vehicle body dynamic integrated management system (VehicleDynamics Integrated Management, VDIM) serial numbers, child node information (e.g., electronic airbag (electronic control of safety airbag) information) and TCAM five code information.

In an alternative embodiment, the data transmission apparatus may be built based on an electronic device (e.g. a server), and accordingly, the first interface unit 210, the second interface unit 220, and the sending unit 240 may be the input/output interface 630, and the processing unit 230 may be the processor 620, and the electronic device may further include the memory 610, as shown in fig. 6 in particular.

Fig. 6 is a schematic block diagram of an electronic device according to another embodiment of the present application. The electronic device 600 shown in fig. 6 may include: memory 610, processor 620, and input/output interface 630. The memory 610, the processor 620, and the input/output interface 630 are connected through an internal connection path, the memory 610 is used for storing instructions, and the processor 620 is used for executing the instructions stored in the memory 620, so as to control the input/output interface 630 to receive input data and information, and output data such as operation results.

It should be appreciated that in the embodiments of the present application, the processor 620 may be a general-purpose central processing unit (central processing unit, CPU), a microprocessor, an application-specific integrated circuit (application specific integrated circuit, ASIC), or one or more integrated circuits for executing related programs to implement the solutions provided in the embodiments of the present application.

The memory 610 may include read only memory and random access memory and provides instructions and data to the processor 620. A portion of the processor 620 may also include non-volatile random access memory. For example, the processor 620 may also store information of the device type.

In implementation, the steps of the above method may be performed by integrated logic circuitry in hardware or instructions in software in the processor 620. The method for requesting uplink transmission resources disclosed in connection with the embodiments of the present application may be directly embodied as a hardware processor executing or may be executed by a combination of hardware and software modules in the processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory 610, and the processor 620 reads the information in the memory 610 and, in combination with its hardware, performs the steps of the method described above. To avoid repetition, a detailed description is not provided herein.

It should be appreciated that in embodiments of the present application, the processor may be a central processing unit (central processing unit, CPU), the processor may also be other general purpose processors, digital signal processors (digital signal processor, DSP), application specific integrated circuits (application specific integrated circuit, ASIC), off-the-shelf programmable gate arrays (field programmablegate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The apparatus embodiments of the present application are described above in detail with reference to fig. 1 to 6, and the method embodiments of the present application are described below in detail with reference to fig. 6. It is to be understood that the description of the method embodiments corresponds to the description of the device embodiments, and that parts not described in detail can therefore be seen in the preceding method embodiments.

Fig. 7 is a schematic flow chart of a method for vehicle electric inspection, which is applied to a data transmission device, according to an embodiment of the present application. The method shown in fig. 7 includes steps S710 to S740.

In step S710, first software version data of a target vehicle is acquired from a first server.

In step S720, first hardware data of the target vehicle is acquired from a second server.

In step S730, vehicle data of the target vehicle is generated based on the first software version data and the first hardware data.

In step S740, the vehicle data is transmitted to a diagnostic apparatus for use by the diagnostic apparatus in verifying a second state of the target vehicle.

In some implementations, the first software version data includes a hardware number and hardware version information, the method further comprising: obtaining second hardware data from a third server, wherein the second hardware data comprises a hardware number and hardware version information, and the third server is positioned in the first network domain; if the first hardware data is matched with the second hardware data, matching the hardware number and the hardware version information in the second hardware data with the hardware number and the hardware version information of the first software version data to determine whether the second hardware data is matched with the first software version data or not; and if the second hardware data is matched with the first software version data, generating vehicle data of the target vehicle based on the first software version data, the first hardware data and the second hardware data.

In some implementations, the first hardware data includes control unit information of the target vehicle, the second hardware data includes control unit information, the method further includes: and determining whether the first hardware data is matched with the second hardware data or not based on control unit information included in the first hardware data and control unit information included in the second hardware data, wherein the control unit information is used for indicating a control function corresponding to a control unit.

In some implementations, the method further comprises: obtaining a plurality of software version data from the first server, the plurality of software version data including the first software version data; and determining the first software version data from a plurality of pre-stored software version data based on a preset rule, wherein the first software version data is matched with the target vehicle.

In some implementations, the preset rule is used to indicate a correspondence between a vehicle identifier of the target vehicle and software version data, and the method further includes: and determining the first software version data from the plurality of software version data based on the preset rule.

In some implementations, the preset rules are used to indicate software version data corresponding to a target time-associated vehicle, where the target time-associated vehicle includes a vehicle that is produced after the target time, and the method further includes: and determining that the software version corresponding to the target time is the target software version from the plurality of software versions based on the preset rule, wherein the production time of the target vehicle is located after the target time.

In some implementations, the target time is determined based on a target vehicle identification, a target field in the target vehicle identification being used to indicate the target time.

In some implementations, the method further comprises: acquiring first test data of the target vehicle from the diagnostic apparatus, wherein the first test data is encrypted data of second test data of the target vehicle; decrypting the first verification data to obtain the second verification data; storing the second verification data, wherein the second verification data includes one or more of: the inspection result data of the target vehicle, the inspection process data of the target vehicle, and the inspection log data of the target vehicle.

In some implementations, the vehicle data includes one or more of: vehicle assembly information of the target vehicle; a hardware number of one or more hardware included in a vehicle assembly of the target vehicle; a hardware version of one or more hardware included in a vehicle assembly of the target vehicle; and information of a control unit of the target vehicle, wherein the control unit information of the target vehicle is used for indicating the function of the control unit in the target vehicle.

It should be understood that in the embodiments of the present application, "B corresponding to a" means that B is associated with a, from which B may be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may also determine B from a and/or other information.

It should be understood that the term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, a network device, a user device, a core network device, an operation and maintenance administration (operation administration and maintenance, OAM), or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital versatile disk (digital video disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like. The computer readable storage medium may be volatile or nonvolatile storage medium, or may include both volatile and nonvolatile types of storage medium.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A data transmission apparatus, comprising:

a first interface unit, configured to obtain first software version data of a target vehicle from a first server, where the first server is located in a first network domain;

a second interface unit, configured to obtain first hardware data of the target vehicle from a second server, where the second server is located in a second network domain;

a processing unit configured to generate vehicle data of the target vehicle based on the first software version data and the first hardware data;

a transmitting unit configured to transmit the vehicle data to a diagnostic apparatus, the vehicle data being used by the diagnostic apparatus to verify a second state of the target vehicle, wherein the diagnostic apparatus is located in the first network domain;

The data transmission device is located in the first network domain or the second network domain, and a network segment where the first network domain is located is different from a network segment where the second network domain is located.

2. The data transmission apparatus of claim 1, wherein the first software version data includes a hardware number and hardware version information, the data transmission system further includes a third interface unit,

the third interface unit is further configured to obtain second hardware data from a third server, where the second hardware data includes a hardware number and hardware version information, and the third server is located in the first network domain;

if the first hardware data is matched with the second hardware data, the processing unit is further configured to determine whether the second hardware data is matched with the first software version data based on matching of the hardware number and the hardware version information in the second hardware data with the hardware number and the hardware version information of the first software version data;

and if the second hardware data is matched with the first software version data, the processing unit is further used for generating vehicle data of the target vehicle based on the first software version data, the first hardware data and the second hardware data.

3. The data transmission apparatus according to claim 2, wherein the first hardware data includes control unit information of the target vehicle, the second hardware data includes control unit information,

the processing unit is further configured to determine whether the first hardware data is matched with the second hardware data based on control unit information included in the first hardware data and control unit information included in the second hardware data, where the control unit information is used to indicate a control function corresponding to the control unit.

4. The data transmission apparatus of claim 1, wherein the processing unit is further configured to:

obtaining a plurality of software version data from the first server, the plurality of software version data including the first software version data;

and determining the first software version data from the plurality of software version data based on preset rules, wherein the first software version data is matched with the target vehicle.

5. The data transmission apparatus according to claim 4, wherein the preset rule is for indicating a correspondence between a vehicle identification of the target vehicle and software version data,

The processing unit is further configured to determine the first software version data from the plurality of software version data based on the preset rule.

6. The data transmission device of claim 4, wherein the predetermined rule is for indicating software version data corresponding to a target time-associated vehicle, wherein the target time-associated vehicle comprises a vehicle produced after the target time,

the processing unit is further configured to determine, from the plurality of software versions, that a software version corresponding to the target time is the target software version, based on the preset rule, where the production time of the target vehicle is located after the target time.

7. The data transmission apparatus of claim 6, wherein the target time is determined based on a target vehicle identification, a target field in the target vehicle identification being used to indicate the target time.

8. The data transmission device of claim 1, wherein the vehicle data comprises one or more of:

vehicle assembly information of the target vehicle;

a hardware number of one or more hardware included in a vehicle assembly of the target vehicle;

A hardware version of one or more hardware included in a vehicle assembly of the target vehicle;

and information of a control unit of the target vehicle, wherein the control unit information of the target vehicle is used for indicating the function of the control unit in the target vehicle.

9. A method of inspecting a vehicle, the method being performed by a data transmission device, the method comprising:

obtaining first software version data of a target vehicle from a first server, wherein the first server is positioned in a first network domain;

acquiring first hardware data of the target vehicle from a second server, wherein the second server is positioned in a second network domain;

generating vehicle data of the target vehicle based on the first software version data and the first hardware data;

transmitting the vehicle data to a diagnostic instrument, the vehicle data for use by the diagnostic instrument in verifying a second state of the target vehicle;

10. An electronic device comprising an input/output interface, a processor for controlling the input/output interface to transceive data, and a memory for storing a computer program, the processor for calling and running the computer program from the memory, causing the electronic device to perform the method of claim 9.

11. A computer program product comprising computer programs/instructions for implementing the method of claim 9 when the computer programs/instructions are executed by a processor.