A VCU fault data acquisition method and related device

Abstract

The present application discloses a fault data acquisition method and related device for a VCU, which relates to the field of intelligent detection technology. In the present application, during the fault testing process of the VCU, a fault data acquisition request is sent to the VCU; then, fault feedback information returned by the VCU based on the fault data acquisition request is received, and based on the fault data identifier carried in the fault feedback information, the amount of fault data matching the fault data identifier is determined; further, when it is determined that the amount of fault data meets a preset data amount threshold condition, a continuous data acquisition request is sent to the VCU, and the original fault data reaching the fault data amount returned by the VCU based on the continuous data request is received; finally, according to the preset data conversion format, the data format of each obtained original fault data is converted, thereby obtaining the target fault data corresponding to each fault data, thereby improving the efficiency of the fault data acquisition of the VCU.

Description

Technical Field

[0001] The present application relates to the field of intelligent detection technology, and in particular to a method for acquiring fault data of a VCU and related devices. Background Art

[0002] The Vehicle Control Unit (VCU), one of the three core electronic control systems in new energy vehicles, can directly impact the safety of the entire vehicle if damaged. Therefore, during VCU development, it's essential to verify the VCU's fault status under real vehicle conditions to ensure it meets design requirements.

[0003] Currently, in order to verify the actual vehicle fault status of the VCU, a hardware-in-the-loop (HIL) test system is usually used to perform fault injection testing on the VCU.

[0004] For example, see Figure 1 As shown, the host computer obtains the test case of the function to be tested of the VCU, and obtains the first analog signal of the first electronic control unit in the target vehicle through the hard-line signal simulation module; then, the second analog signal of the second electronic control unit in the target vehicle is obtained through the CAN signal simulation module; further, based on the test case of the function to be tested, the first analog signal and / or the second analog signal is modified to obtain the target analog signal; finally, the target analog signal is sent to the VCU of the target vehicle to complete the test of the VCU of the target vehicle.

[0005] Furthermore, after completing the VCU test, the corresponding diagnostic trouble code (DTC) can be obtained based on the fault information inside the VCU, and the DTC can be uploaded with the help of external tools (CAN card or fault diagnosis instrument) so that the subsequent HIL test system can verify the actual vehicle fault status based on the DTC.

[0006] However, the above-mentioned VCU fault injection test method requires the use of external tools (CAN card or fault diagnosis instrument) to upload DTC, that is, the tester manually injects the VCU fault, which results in a lot of time required to obtain the VCU fault data, and thus cannot ensure timely VCU fault injection testing.

[0007] Therefore, using the above method, the efficiency of acquiring fault data of the VCU is low. Summary of the Invention

[0008] The embodiments of the present application provide a method and related apparatus for acquiring fault data of a VCU, so as to improve the efficiency of acquiring fault data of the VCU.

[0009] In a first aspect, an embodiment of the present application provides a method for acquiring fault data of a VCU, the method comprising:

[0010] During the fault testing process of the VCU, a fault data acquisition request is sent to the VCU;

[0011] receiving fault feedback information returned by the VCU based on the fault data acquisition request, and determining, based on the fault data identifier carried in the fault feedback information, an amount of fault data of the VCU that matches the fault data identifier;

[0012] When it is determined that the amount of fault data meets the preset data amount threshold condition, a continuous data acquisition request is sent to the VCU, and the original fault data returned by the VCU based on the continuous data request is received until the corresponding received data amount reaches the fault data amount;

[0013] According to a preset data conversion format, data format conversion is performed on each of the obtained original fault data, and based on the converted original fault data, target fault data corresponding to each of the fault data is obtained.

[0014] In a second aspect, an embodiment of the present application further provides a VCU fault data acquisition device, the device comprising:

[0015] a request module, configured to send a fault data acquisition request to the VCU during a fault test of the VCU;

[0016] a receiving module, configured to receive fault feedback information returned by the VCU based on the fault data acquisition request, and determine, based on the fault data identifier carried in the fault feedback information, the amount of fault data of the VCU that matches the fault data identifier;

[0017] a determination module configured to, when determining that the amount of fault data meets a preset data amount threshold condition, send a continuous data acquisition request to the VCU, and receive original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount;

[0018] The conversion module is used to convert the data format of each acquired original fault data according to a preset data conversion format, and obtain the target fault data corresponding to each fault data based on the converted original fault data.

[0019] In a possible embodiment, based on the fault data identifier carried in the fault feedback information, determining the amount of fault data of the VCU that matches the fault data identifier, the receiving module is specifically configured to:

[0020] Analyze the fault feedback information and obtain the corresponding fault data identification;

[0021] The fault data volume of the VCU is determined based on the fault data identifier and a preset correspondence between the fault data identifier and the fault data volume.

[0022] In a possible embodiment, when sending a continuous data acquisition request to the VCU and receiving original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount, the determination module is specifically configured to:

[0023] Send continuous data acquisition requests to the VCU and receive the original fault data returned by the VCU in batches according to the preset data distribution threshold;

[0024] When the amount of received original fault data reaches the fault data amount, the receiving of data information returned by the VCU is stopped.

[0025] In a possible embodiment, when the amount of received original fault data reaches the fault data amount, the receiving of data information returned by the VCU is stopped, and the determination module is specifically configured to:

[0026] Receive a data stop acquisition request returned by the VCU based on the accumulated data volume;

[0027] Stop receiving data information returned by the VCU based on the data stop acquisition request.

[0028] In a possible embodiment, after obtaining target fault data corresponding to each fault data, the conversion module is specifically configured to:

[0029] Receive a fault type identification request sent by a target terminal, and obtain identification information of a corresponding target object from the fault type identification request;

[0030] Based on the correspondence between the target fault data and the fault type associated with the identification information, the fault type corresponding to each target fault data is confirmed respectively.

[0031] In a possible embodiment, the receiving module is further configured to:

[0032] If the fault feedback information does not include a fault data identifier, obtaining the single original fault data of the VCU from the fault feedback information;

[0033] According to the data conversion format, the obtained single original fault data is converted into a data format, and based on the converted single original fault data, corresponding target fault data is obtained.

[0034] In a third aspect, an electronic device is proposed, comprising a processor and a memory, wherein the memory stores a program code, and when the program code is executed by the processor, the processor executes the steps of the VCU fault data acquisition method described in the first aspect above.

[0035] In a fourth aspect, a computer-readable storage medium is proposed, which includes a program code. When the program code is run on an electronic device, the program code is used to enable the electronic device to execute the steps of the VCU fault data acquisition method described in the first aspect.

[0036] In a fifth aspect, a computer program product is provided. When the computer program product is called by a computer, the computer executes the steps of the VCU fault data acquisition method as described in the first aspect.

[0037] The beneficial effects of this application are as follows:

[0038] In the fault data acquisition method of the VCU provided in the embodiment of the present application, during the fault test process of the VCU, a fault data acquisition request is sent to the VCU; then, fault feedback information returned by the VCU based on the fault data acquisition request is received, and based on the fault data identifier carried in the fault feedback information, the amount of fault data of the VCU that matches the fault data identifier is determined; further, when it is determined that the amount of fault data meets a preset data amount threshold condition, a continuous data acquisition request is sent to the VCU, and the original fault data returned by the VCU based on the continuous data request is received until the corresponding received data amount reaches the fault data amount; finally, according to the preset data conversion format, the data format of each obtained original fault data is converted respectively, and based on the converted original fault data, the target fault data corresponding to each fault data is obtained.

[0039] In this way, when it is determined that the amount of fault data meets the preset data amount threshold condition, a continuous data acquisition request is sent to the VCU, and the original fault data returned by the VCU based on the continuous data request is received until the corresponding received data amount reaches the fault data amount. This avoids the technical disadvantage of the existing technology of using external tools (CAN card or fault diagnosis instrument) to upload DTC, that is, the tester manually injects VCU faults, which results in a lot of time being required to obtain VCU fault data, and thus cannot ensure timely VCU fault injection testing. Therefore, the efficiency of VCU fault data acquisition is improved.

[0040] In addition, other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or may be understood by practicing the present application. The objectives and other advantages of the present application can be realized and obtained through the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 The following is an exemplary diagram of a logic diagram of a fault injection test provided by an embodiment of the present application;

[0042] Figure 2 The following is an exemplary diagram of a logic diagram of automatic testing of VCU fault injection provided by an embodiment of the present application;

[0043] Figure 3 An exemplary system architecture diagram applicable to the embodiments of the present application is shown;

[0044] Figure 4 The following is a flow chart showing a method for acquiring fault data of a VCU provided in an embodiment of the present application;

[0045] Figure 5 A logic diagram for determining the amount of fault data of a VCU provided by an embodiment of the present application is exemplarily shown;

[0046] Figure 6 The following is a flow chart of a method for sending a continuous data acquisition request provided in an embodiment of the present application;

[0047] Figure 7 A schematic diagram of a specific application scenario of whether to stop sending a continuous data acquisition request provided in an embodiment of the present application is exemplified;

[0048] Figure 8 A schematic diagram of a specific application scenario for determining the fault type of target fault data provided by an embodiment of the present application is exemplarily shown;

[0049] Figure 9 This embodiment of the present application provides an exemplary method based on Figure 4 Schematic diagram of specific application scenarios;

[0050] Figure 10 The following is a schematic diagram showing the structure of a VCU fault data acquisition device provided in an embodiment of the present application;

[0051] Figure 11 A schematic structural diagram of an electronic device provided in an embodiment of the present application is exemplarily shown. DETAILED DESCRIPTION

[0052] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of the technical solutions of this application, but not all of them. Based on the embodiments described in this application document, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the technical solutions of this application.

[0053] It should be noted that in the description of this application, "multiple" is understood to mean "at least two." "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. A and B are connected, which can mean: A and B are directly connected, and A and B are connected through C. In addition, in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying an order.

[0054] In addition, the collection, dissemination, and use of data in the technical solution of this application comply with the requirements of relevant national laws and regulations.

[0055] Before introducing the VCU fault data acquisition method provided in the embodiment of the present application, for ease of understanding, some technical terms involved in the present application are first explained below.

[0056] (1) Battery Management System (BMS): commonly known as the battery nanny or battery butler, its main function is to intelligently manage and maintain each battery unit, prevent the battery from overcharging and over-discharging, extend the battery life, and monitor the battery status.

[0057] (2) Motor Control Unit (MCU): This is the motor controller. It controls the rotation of the motor according to the instructions from the VCU.

[0058] (3) Controller Area Network (CAN): The CAN bus data transmission and reception of the CAN card is completed by the CAN controller and CAN transceiver.

[0059] Next, the design concept of the embodiment of the present application is briefly introduced below:

[0060] The HIL simulation test system uses a real-time processor to run a simulation model to simulate the operating state of the controlled object, and connects to the VCU under test through the I / O interface to perform comprehensive and systematic testing on the VCU under test.

[0061] Considering safety, feasibility and reasonable cost, HIL simulation testing has become a very important part of the VCU development process. It reduces the number of actual vehicle road tests, shortens development time and reduces costs, while improving the software quality of the VCU and reducing safety risks after the vehicle is released.

[0062] In the new field of new energy vehicles, HIL simulation testing is very important for the three core electronic control systems: VCU, BMS and MCU. Among them, when performing HIL simulation testing on the VCU, the corresponding DTC can be obtained based on the fault information inside the VCU, and then the DTC can be uploaded with the help of external tools (CAN card or fault diagnosis instrument) so that the subsequent HIL test system can verify the actual vehicle fault status based on the DTC.

[0063] However, the above-mentioned VCU fault injection test method requires the use of external tools (CAN card or fault diagnosis instrument) to upload DTC, that is, the tester manually injects the VCU fault, which results in a lot of time required to obtain the VCU fault data, and thus cannot ensure timely VCU fault injection testing.

[0064] In view of this, in order to improve the efficiency of VCU fault data acquisition, such as Figure 2 As shown, in this embodiment of the present application, LabVIEW software was used to develop a plug-in based on the DTC portion of the UDS protocol. This plug-in can interact with the VCU by sending and receiving CAN data, reading fault information within the VCU, and then parsing the actual DTC. This plug-in then generates a corresponding DLL dynamic library for easy callability within the HIL test software, Veristand. This allows the test software, Veristand, to successfully read the DTCs of the VCU under test, allowing automated testing software to automatically test the VCU's fault injection and DTC reading capabilities. Signal mapping is configured for ease of operation.

[0065] In particular, the preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application. In addition, the embodiments of the present application and the features in the embodiments may be combined with each other if there is no conflict.

[0066] See Figure 3As shown, it is a schematic diagram of a system architecture for fault data acquisition provided in an embodiment of the present application. The system architecture includes: VCU301 and HIL test equipment 302, wherein VCU301 and HIL test equipment 302 can be connected through a line to complete the fault data acquisition of the VCU.

[0067] The present application embodiment does not impose any restrictions on the number of the above devices. Figure 3 As shown, only VCU 301 and HIL test equipment 302 are described as examples. The following briefly introduces the above devices and their respective functions.

[0068] VCU301 is responsible for the energy management and power system control functions of the entire vehicle. In the embodiment of the present application, it can obtain fault feedback information returned based on the fault data acquisition request, and the original fault data returned based on the continuous data request until the returned original fault data reaches the corresponding fault data volume.

[0069] The HIL test device 302 is used to send a fault data acquisition request to the VCU during the fault testing process of the VCU; then, receive fault feedback information returned by the VCU based on the fault data acquisition request, and determine the amount of fault data of the VCU that matches the fault data identifier based on the fault data identifier carried in the fault feedback information; further, when it is determined that the amount of fault data meets a preset data amount threshold condition, send a continuous data acquisition request to the VCU, and receive the original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount; finally, according to a preset data conversion format, respectively convert the data format of each obtained original fault data, and obtain the target fault data corresponding to each fault data based on the converted original fault data.

[0070] The following describes the fault data acquisition method of the VCU provided by the exemplary embodiment of the present application in combination with the above-mentioned system architecture and reference to the accompanying drawings. It should be noted that the above-mentioned system architecture is only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this respect.

[0071] See Figure 4 As shown, it is a flowchart of a method for obtaining fault data of a VCU provided in an embodiment of the present application. Taking the execution subject as an HIL test device as an example, the specific implementation process of the method is as follows:

[0072] S401: During a fault test of a VCU, a fault data acquisition request is sent to the VCU.

[0073] Specifically, when executing step S401 , while the VCU is undergoing fault testing, the HIL test device sends a fault data acquisition request to the VCU under test through the plug-in program, thereby waiting for fault feedback information from the VCU under test.

[0074] For example, when the VCU is undergoing fault testing, the HIL test equipment sends a fault data acquisition request with DTC access ID: 7E0 and the corresponding hexadecimal data 03 19 02 FF (a complete data length is 8 bytes, and the unrepresented data is padded with 00 at the end, that is, 03 19 02 FF 00 00 00 00) to the VCU under test through the plug-in program, thereby waiting for fault feedback information from the VCU under test.

[0075] S402: Receive fault feedback information returned by the VCU based on the fault data acquisition request, and determine the amount of fault data of the VCU that matches the fault data identifier based on the fault data identifier carried in the fault feedback information.

[0076] For details, see Figure 5 As shown, when executing step S402, after sending a fault data acquisition request to the VCU, the HIL test equipment can wait for the fault feedback information returned by the tested VCU based on the fault data acquisition request, thereby parsing the fault feedback information to obtain the corresponding fault data identifier, and then determine the fault data volume of the VCU based on the fault data identifier and the corresponding relationship between the preset fault data identifier and the fault data volume.

[0077] For example, if the HIL test equipment receives the fault feedback information (VCU feedback ID: 7E8) returned by the VCU under test based on the fault data acquisition request, and then parses the fault feedback information, it will obtain an 8-byte hexadecimal data. When the first byte of the obtained 8-byte hexadecimal data is 10, it means that the amount of fault data of the VCU under test is more than one, that is, multiple DTCs are stored in the VCU under test.

[0078] Furthermore, in the aforementioned 8-byte hexadecimal data, the second byte (i.e., the fault data identifier) ​​represents the number of bytes of data that will be subsequently received by the HIL test equipment. For example, if the second byte is 17, it indicates that there are 23 bytes of data to follow. The 23 bytes of data include: the third to fifth bytes are the specific values ​​of the preset check bits, and the sixth to eighth bytes are the first three bytes of the first 4-byte DTC.

[0079] It should be noted that the number of DTCs stored in the tested VCU can also be known through the data of the second byte. For example, still taking the second byte as 17, the corresponding decimal number is 23, then the number of DTCs stored in the tested VCU is: (23-3) / 4=5.

[0080] In one possible implementation, after sending a fault data acquisition request to the VCU, the HIL test device receives fault feedback information returned by the tested VCU based on the fault data acquisition request, and parses the fault feedback information. If the fault feedback information does not include a fault data identifier, it indicates that the VCU only stores a single raw fault data.

[0081] For example, the HIL test equipment receives the fault feedback information (VCU feedback ID: 7E8) returned by the VCU under test based on the fault data acquisition request, and then parses the fault feedback information to obtain an 8-byte hexadecimal data. When the first byte of the obtained 8-byte hexadecimal data is 07, it indicates that the amount of fault data of the VCU under test is only one, that is, one DTC is stored in the VCU under test.

[0082] Furthermore, in the above 8-byte hexadecimal data, the second to fourth bytes are specific values ​​of the preset check bits, and the fifth to eighth bytes are 4 bytes of a single DTC.

[0083] S403: When it is determined that the amount of fault data meets the preset data amount threshold condition, a continuous data acquisition request is sent to the VCU, and the original fault data returned by the VCU based on the continuous data request is received until the corresponding received data amount reaches the fault data amount.

[0084] Specifically, when executing step S403, after determining the fault data volume of the VCU matching the fault data identifier, the HIL test equipment may determine whether the fault data volume meets the preset data volume threshold condition based on the preset data volume threshold condition.

[0085] For example, assuming that the preset data volume threshold condition is: the amount of original fault data is not less than 2, if the HIL test equipment determines that the amount of fault data of the VCU that matches the fault data identifier is 8, it is easy to know that the amount of fault data of the VCU is 8, which meets the preset data volume threshold condition: the amount of original fault data is not less than 2.

[0086] Furthermore, when the HIL test equipment determines that the amount of fault data meets the preset data amount threshold condition, it sends a continuous data acquisition request to the VCU and receives the original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount. Figure 6As shown, it is a flowchart of an implementation method for sending a continuous data acquisition request provided in an embodiment of the present application. The specific implementation process of the method is as follows:.

[0087] S4031: Send a continuous data acquisition request to the VCU, and receive the original fault data returned by the VCU in batches according to a preset data distribution threshold.

[0088] Specifically, when executing step S4031, when the HIL test equipment determines that the amount of fault data of the VCU under test meets the preset data amount threshold condition, it can send a continuous data acquisition request to the VCU under test through the plug-in program, thereby receiving the original fault data returned in batches by the VCU under test according to the preset data distribution threshold.

[0089] For example, when it is determined that the amount of fault data of the VCU under test meets the preset data amount threshold condition, the HIL test equipment sends a DTC access ID: 7E0 to the VCU under test through the plug-in program, and the corresponding hexadecimal data is 30 00 1E (a complete data length is 8 bytes, and the unrepresented data is padded with 00 at the end, that is, 30 00 1E 00 00 00 00 00). The continuous data acquisition request (continuous frame request)

[0090] Furthermore, after the HIL test device sends a continuous data acquisition request to the VCU under test, it can receive the original fault data returned in batches by the VCU under test according to the preset data distribution threshold (for example, 8 bytes, that is, the amount of data returned to the HIL test device at a single time is 8 bytes). Among them, if the DTC data sent for the last time is less than 8 bytes, it needs to be padded with 0 to 8 bytes.

[0091] It should be noted that each time the tested VCU returns 8 bytes of data (VCU feedback ID: 7E8) based on the preset data distribution threshold, the value of the first byte is the number of counted items in the continuous frame, that is, the data returned this time is the nth return data, that is, the first data of the first 7E8 received after the continuous frame is sent is 21, the first data of the second item is 22, and so on.

[0092] In addition, the remaining 7 bytes of data in each returned raw fault data (each frame) are the raw data of the corresponding DTC. After obtaining the raw data of the DTC, the HIL test equipment can store the DTC raw data in sequence. Among them, the raw data of every 4 DTCs can form a complete DTC.

[0093] S4032: When the amount of received original fault data reaches the fault data amount, stop receiving data information returned by the VCU.

[0094] For details, see Figure 7 As shown, when executing step S4032, the HIL test equipment records the received data volume of the received original fault data each time after receiving the original fault data returned by the VCU according to the preset data distribution threshold. If the received data volume does not reach the fault data volume, the data information returned by the VCU will be kept received. If the received data volume reaches the fault data volume, the data information returned by the VCU will be stopped.

[0095] Furthermore, when the HIL test device determines that the received data volume of the received original fault data reaches the fault data volume, the receiving VCU stops obtaining the data based on the received data volume, thereby stopping obtaining the data based on the obtained data and stopping receiving the data information returned by the VCU.

[0096] S404: performing data format conversion on each of the obtained original fault data according to a preset data conversion format, and obtaining target fault data corresponding to each of the fault data based on the converted original fault data.

[0097] Specifically, when executing step S404, after the original fault data returned by the VCU based on continuous data requests reaches the fault data amount, the HIL test equipment can convert the data format of each obtained original fault data according to a preset data conversion format, and obtain the target fault data corresponding to each fault data based on the converted original fault data, thereby converting the saved DTC original data into a real hexadecimal DTC code.

[0098] In one possible implementation, after sending a fault data acquisition request to the VCU, the HIL test equipment receives fault feedback information returned by the VCU under test based on the fault data acquisition request, and parses the fault feedback information. If the fault feedback information does not include a fault data identifier, the single original fault data of the VCU is obtained from the fault feedback information. Then, the data format of the obtained single original fault data is converted according to a data conversion format, and corresponding target fault data is obtained based on the converted single original fault data, thereby converting the saved single DTC original data into a real hexadecimal DTC code.

[0099] Furthermore, after the fault data of the VCU is obtained, the HIL test equipment obtains each target fault data, and can confirm the fault type corresponding to each target fault data according to the fault type identification request sent by the target terminal, see Figure 8As shown, the HIL test equipment receives a fault type identification request sent by the target terminal, and obtains the identification information of the corresponding target object from the fault type identification request, thereby confirming the fault type corresponding to each target fault data based on the correspondence between the target fault data and the fault type associated with the identification information.

[0100] It should be noted that the target object may be different types of vehicles. Therefore, there are certain differences in the correspondence between the target fault data and the fault type of the VCU of different types of vehicles.

[0101] In a possible implementation, after the HIL test equipment obtains the above-mentioned target fault data, it can automatically call the above-mentioned target fault data and edit them into an automatically readable sequence to subsequently implement the task of automatically testing the DTC.

[0102] Based on the above VCU fault data acquisition method steps, refer to Figure 9 As shown, it is a schematic diagram of a specific application scenario of a VCU fault data acquisition method provided by an embodiment of the present application. During the fault test of the VCU, the HIL test equipment sends a fault data acquisition request Fau.Data.Re to the VCU; then, the fault feedback information Fau.Feedback returned by the VCU based on the fault data acquisition request Fau.Data.Re is received, and based on the fault data identifier ID.F1 carried by the fault feedback information Fau.Feedback, it is determined that the amount of fault data of the VCU matching the fault data identifier ID.F1 is 5; further, when it is determined that the amount of fault data 5 meets the preset data amount threshold condition Data.Y.Conditions (for example, the amount of fault data is not less than 2), a fault data acquisition request Fau.Data.Re is sent to the VCU. Send a continuous data acquisition request Suc.Data.Re, and receive the original fault data Ori.Fau.Data returned by the VCU based on the continuous data acquisition request Suc.Data.Re, until the corresponding received data volume reaches the fault data volume 5; finally, according to the preset data conversion format Data.Format, perform data format conversion on each obtained original fault data (for example, Ori.Fau.Data1, Ori.Fau.Data2 and Ori.Fau.Data3), and based on the converted original fault data, obtain the target fault data corresponding to each fault data (in order: Tra.Fau.Data1, Tra.Fau.Data2 and Tra.Fau.Data3).

[0103] In summary, in the VCU fault data acquisition method provided in the embodiment of the present application, during the fault test of the VCU, a fault data acquisition request is sent to the VCU; then, the fault feedback information returned by the VCU based on the fault data acquisition request is received, and based on the fault data identifier carried by the fault feedback information, the amount of fault data of the VCU that matches the fault data identifier is determined; further, when it is determined that the amount of fault data meets the preset data amount threshold condition, a continuous data acquisition request is sent to the VCU, and the original fault data returned by the VCU based on the continuous data request is received until the corresponding received data amount reaches the fault data amount; finally, according to the preset data conversion format, the data format of each obtained original fault data is converted respectively, and based on the converted original fault data, the target fault data corresponding to each fault data is obtained.

[0104] In this way, when it is determined that the amount of fault data meets the preset data amount threshold condition, a continuous data acquisition request is sent to the VCU until the original fault data returned by the VCU based on the continuous data request reaches the fault data amount. This avoids the technical disadvantage of the existing technology of using external tools (CAN card or fault diagnosis instrument) to upload DTC, that is, the tester manually injects VCU faults, which results in a lot of time being required to obtain VCU fault data, and thus cannot ensure timely VCU fault injection testing. Therefore, the efficiency of VCU fault data acquisition is improved.

[0105] Furthermore, based on the same technical concept, the embodiment of the present application also provides a VCU fault data acquisition device, which is used to implement the above method flow of the embodiment of the present application. Figure 10 As shown, the VCU fault data acquisition device includes: a request module 1001, a receiving module 1002, a determination module 1003 and a conversion module 1004, wherein:

[0106] The request module 1001 is configured to send a fault data acquisition request to the VCU during a fault test of the VCU;

[0107] The receiving module 1002 is configured to receive fault feedback information returned by the VCU based on the fault data acquisition request, and determine the amount of fault data of the VCU that matches the fault data identifier based on the fault data identifier carried in the fault feedback information;

[0108] The determination module 1003 is configured to, when determining that the amount of fault data meets a preset data amount threshold condition, send a continuous data acquisition request to the VCU, and receive original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount;

[0109] The conversion module 1004 is configured to perform data format conversion on each of the obtained original fault data according to a preset data conversion format, and obtain target fault data corresponding to each of the fault data based on the converted original fault data.

[0110] In a possible embodiment, based on the fault data identifier carried in the fault feedback information, determining the amount of fault data of the VCU that matches the fault data identifier, the receiving module 1002 is specifically configured to:

[0111] Analyze the fault feedback information and obtain the corresponding fault data identification;

[0112] The fault data volume of the VCU is determined based on the fault data identifier and a preset correspondence between the fault data identifier and the fault data volume.

[0113] In a possible embodiment, when sending a continuous data acquisition request to the VCU and receiving original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount, the determining module 1003 is specifically configured to:

[0114] Send continuous data acquisition requests to the VCU and receive the original fault data returned by the VCU in batches according to the preset data distribution threshold;

[0115] When the amount of received original fault data reaches the fault data amount, the receiving of data information returned by the VCU is stopped.

[0116] In a possible embodiment, when the cumulative amount of received original fault data reaches the fault data amount and the data information returned by the VCU is stopped, the determining module 1003 is specifically configured to:

[0117] Receive the data stop acquisition request returned by the VCU based on the amount of received data;

[0118] Stop receiving data information returned by the VCU based on the data stop acquisition request.

[0119] In a possible embodiment, after obtaining the target fault data corresponding to each fault data, the conversion module 1004 is specifically configured to:

[0120] Receive a fault type identification request sent by a target terminal, and obtain identification information of a corresponding target object from the fault type identification request;

[0121] Based on the correspondence between the target fault data and the fault type associated with the identification information, the fault type corresponding to each target fault data is confirmed respectively.

[0122] In a possible embodiment, the receiving module 1002 is further configured to:

[0123] If the fault feedback information does not include a fault data identifier, obtaining the single original fault data of the VCU from the fault feedback information;

[0124] According to the data conversion format, the obtained single original fault data is converted into a data format, and based on the converted single original fault data, corresponding target fault data is obtained.

[0125] Based on the same technical concept, the embodiment of the present application also provides an electronic device, which can implement the VCU fault data acquisition method provided in the above embodiment of the present application. In one embodiment, the electronic device can be a server, or a terminal device or other electronic device. Figure 11 As shown, the electronic device may include:

[0126] At least one processor 1101, and a memory 1102 connected to the at least one processor 1101. The specific connection medium between the processor 1101 and the memory 1102 is not limited in the embodiment of the present application. Figure 11 In the example, the processor 1101 and the memory 1102 are connected via the bus 1100. Figure 11 The bus 1100 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 11 The diagram is represented by only one thick line, but this does not mean that there is only one bus or one type of bus. Alternatively, the processor 1101 may also be referred to as a controller, without limitation to the name.

[0127] In the embodiment of the present application, the memory 1102 stores instructions that can be executed by at least one processor 1101. The at least one processor 1101 can execute the VCU fault data acquisition method discussed above by executing the instructions stored in the memory 1102. The processor 1101 can implement Figure 10 The functions of each module in the device shown.

[0128] Among them, the processor 1101 is the control center of the device, which can use various interfaces and lines to connect the various parts of the entire control device, and monitor the device as a whole by running or executing instructions stored in the memory 1102 and calling data stored in the memory 1102, the various functions of the device and processing data.

[0129] In one possible design, processor 1101 may include one or more processing units. Processor 1101 may integrate an application processor and a modem processor. The application processor primarily processes the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 1101. In some embodiments, processor 1101 and memory 1102 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0130] Processor 1101 can be a general-purpose processor, such as a CPU, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the VCU fault data acquisition method disclosed in the embodiments of this application can be directly implemented and executed by a hardware processor, or by a combination of hardware and software modules in the processor.

[0131] Memory 1102 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. Memory 1102 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. Memory 1102 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 1102 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0132] By designing and programming the processor 1101, the code corresponding to the VCU fault data acquisition method described in the above embodiment can be fixed into the chip, so that the chip can execute the code when running. Figure 4The steps of a method for acquiring fault data of a VCU in the embodiment shown are as follows: How to design and program the processor 1101 is a technique well known to those skilled in the art and will not be described in detail here.

[0133] Based on the same inventive concept, an embodiment of the present application further provides a storage medium storing computer instructions. When the computer instructions are executed on a computer, the computer executes a VCU fault data acquisition method discussed above.

[0134] In some possible implementations, various aspects of the method for acquiring fault data of a VCU provided by the present application may also be implemented in the form of a program product, which includes program code. When the program product is run on an apparatus, the program code is used to enable the control device to execute the steps of the method for acquiring fault data of a VCU according to various exemplary implementations of the present application described above in this specification.

[0135] It should be noted that although several units or subunits of the device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, depending on the embodiment of the application, the features and functions of two or more units described above can be embodied in a single unit. Conversely, the features and functions of a single unit described above can be further divided and embodied by multiple units.

[0136] Furthermore, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0137] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0138] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a server, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0139] The program code used to perform the operations of the present application may be written using any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's device, as a stand-alone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0140] Where a remote computing device is involved, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., through the Internet using an Internet service provider).

[0141] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0142] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0143] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A method for acquiring fault data of a vehicle controller (VCU), characterized in that: include: During a fault test of the VCU, a fault data acquisition request is sent to the VCU; The fault data acquisition request is sent by the test device to the VCU through a plug-in program; receiving fault feedback information returned by the VCU based on the fault data acquisition request, and determining, based on a fault data identifier carried in the fault feedback information, an amount of fault data of the VCU that matches the fault data identifier; When it is determined that the amount of fault data meets a preset data amount threshold condition, sending a continuous data acquisition request to the VCU, and receiving the original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount; Performing data format conversion on each of the obtained original fault data according to a preset data conversion format, and obtaining target fault data corresponding to each of the original fault data based on the converted original fault data; The sending a continuous data acquisition request to the VCU and receiving original fault data returned by the VCU based on the continuous data request until a corresponding amount of received data reaches the amount of fault data includes: Sending the continuous data acquisition request to the VCU, and receiving the original fault data returned by the VCU in batches according to a preset data distribution threshold; the continuous data acquisition request is sent to the VCU under test through a plug-in program; When the amount of received original fault data reaches the fault data amount, the receiving of data information returned by the VCU is stopped.

2. The method according to claim 1, wherein The determining, based on the fault data identifier carried in the fault feedback information, the amount of fault data of the VCU that matches the fault data identifier, includes: Analyze the fault feedback information to obtain a corresponding fault data identifier; The fault data volume of the VCU is determined based on the fault data identifier and a preset correspondence between the fault data identifier and the fault data volume.

3. The method according to claim 1, wherein When the amount of received original fault data reaches the fault data amount, stopping receiving data information returned by the VCU includes: receiving a data stop acquisition request returned by the VCU based on the amount of received data; Based on the data stop acquisition request, stop receiving the data information returned by the VCU.

4. The method according to any one of claims 1 to 3, wherein After obtaining the target fault data corresponding to each of the original fault data, the method further includes: Receiving a fault type identification request sent by a target terminal, and obtaining identification information of a corresponding target object from the fault type identification request; Based on the correspondence between the target fault data and the fault type associated with the identification information, the fault type corresponding to each target fault data is respectively confirmed.

5. The method according to claim 1, wherein The method further comprises: If the fault feedback information does not include a fault data identifier, obtaining single original fault data of the VCU from the fault feedback information; According to the data conversion format, the obtained single original fault data is converted into a data format, and corresponding target fault data is obtained based on the converted single original fault data.

6. A VCU fault data acquisition device, characterized in that: include: a request module, configured to send a fault data acquisition request to the VCU during a fault test of the VCU; The fault data acquisition request is sent by the test device to the VCU through a plug-in program; a receiving module, configured to receive fault feedback information returned by the VCU based on the fault data acquisition request, and determine, based on the fault data identifier carried in the fault feedback information, an amount of fault data of the VCU that matches the fault data identifier; a determination module, configured to, when determining that the amount of the fault data meets a preset data amount threshold condition, send a continuous data acquisition request to the VCU, and receive original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount; a conversion module, configured to convert the data format of each acquired original fault data according to a preset data conversion format, and obtain target fault data corresponding to each of the original fault data based on the converted original fault data; When sending a continuous data acquisition request to the VCU and receiving original fault data returned by the VCU based on the continuous data request until the corresponding received data amount reaches the fault data amount, the determining module is specifically configured to: Sending the continuous data acquisition request to the VCU, and receiving the original fault data returned by the VCU in batches according to a preset data distribution threshold; the continuous data acquisition request is sent to the VCU under test through a plug-in program; When the amount of received original fault data reaches the fault data amount, the receiving of data information returned by the VCU is stopped.

7. The device according to claim 6, characterized in that When determining the amount of fault data of the VCU that matches the fault data identifier carried by the fault feedback information, the receiving module is specifically configured to: Analyze the fault feedback information to obtain a corresponding fault data identifier; The fault data volume of the VCU is determined based on the fault data identifier and a preset correspondence between the fault data identifier and the fault data volume.

8. The device according to claim 6, wherein When the amount of received original fault data reaches the fault data amount, and the receiving of data information returned by the VCU is stopped, the determining module is specifically configured to: receiving a data stop acquisition request returned by the VCU based on the amount of received data; Based on the data stop acquisition request, stop receiving the data information returned by the VCU.

9. The device according to any one of claims 6 to 8, characterized in that After obtaining the target fault data corresponding to each of the original fault data, the conversion module is specifically configured to: Receiving a fault type identification request sent by a target terminal, and obtaining identification information of a corresponding target object from the fault type identification request; Based on the correspondence between the target fault data and the fault type associated with the identification information, the fault type corresponding to each target fault data is respectively confirmed.

10. The device according to claim 6, wherein The receiving module is further configured to: If the fault feedback information does not include a fault data identifier, obtaining single original fault data of the VCU from the fault feedback information; According to the data conversion format, the obtained single original fault data is converted into a data format, and corresponding target fault data is obtained based on the converted single original fault data.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 5 is implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

13. A computer program product, characterized in that When the computer program product is called by a computer, the computer is caused to execute the method according to any one of claims 1 to 5.

Images