Software refresh method, fault analysis method, vehicle, server, and storage medium

Abstract

The present application discloses a software refresh method, a fault analysis method, a vehicle, a server, and a storage medium. The software refresh method comprises: receiving a control instruction, wherein the control instruction comprises a target node address of a target node and target diagnostic data; if node addresses of control nodes within a vehicle includes the target node address, performing a software refresh operation on the target node on the basis of the control instruction; and storing node information of the target node and a receiving time of the control instruction, and / or, sending refresh indication information comprising the receiving time of the control instruction to a server communicatively connected to the vehicle, the refresh indication information being used to indicate that a software refresh operation exists at the target node. The method of the present application achieves local monitoring and remote monitoring of vehicle software refresh.

Description

Software refresh methods, fault analysis methods, vehicles, servers and storage media

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese application No. 2024114482304, filed on October 16, 2024, the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] This application relates to the field of vehicle technology, and more specifically, to a software refresh method, a fault analysis method, a vehicle, a server, and a storage medium. Background Technology

[0004] In the field of vehicle diagnostics, a diagnostic tool is typically connected to the vehicle, and then the vehicle's software is updated using the diagnostic tool. However, this method makes it difficult to monitor the vehicle's software update process. Summary of the Invention

[0005] This application proposes a software refresh method, a fault analysis method, a vehicle, a server, and a storage medium to provide a means of monitoring the software refresh process.

[0006] In a first aspect, embodiments of this application provide a software refresh method for a vehicle, the method comprising:

[0007] Receive control commands; the control commands include the target node address and target diagnostic data.

[0008] If the target node address exists in the node address of the control node in the vehicle, perform a software refresh operation on the target node based on the control command;

[0009] Store the node information of the target node and the time of receiving control commands, and / or send refresh indication information including the time of receiving control commands to a server connected to the vehicle; the refresh indication information is used to indicate that a software refresh operation has occurred on the target node.

[0010] Secondly, embodiments of this application provide a software refresh method for a server, the method comprising:

[0011] The system receives refresh indication information sent by the vehicle, including the reception time. The reception time refers to the time when the vehicle receives the control command. The control command includes the target node address and target diagnostic data. The refresh indication information is used to indicate that a software refresh operation has occurred on the target node.

[0012] Obtain the freeze frame corresponding to the fault diagnosis code to be analyzed from the target node of the vehicle;

[0013] Based on the frozen frame, determine the time of occurrence of the fault corresponding to the diagnostic code to be analyzed;

[0014] If the comparison between the fault occurrence time and the reception time in the refresh indication information shows that the fault occurrence time and the reception time are consistent, the cause of the fault is determined to be a software refresh operation performed on the target node.

[0015] Thirdly, embodiments of this application also provide a software refresh device for a vehicle, the device comprising:

[0016] The first receiving module is used to receive control commands; the control commands include the target node address and target diagnostic data of the target node.

[0017] The refresh module is used to perform a software refresh operation on the target node based on the control command if the target node address exists in the node address of the control node in the vehicle.

[0018] The storage module is used to store node information of the target node and the time of receiving control commands, and / or send refresh indication information including the time of receiving control commands to a server connected to the vehicle; the refresh indication information is used to indicate that a software refresh operation has occurred on the target node.

[0019] Fourthly, embodiments of this application also provide a software refresh device for a server, the device comprising:

[0020] The second receiving module is used to receive refresh indication information sent by the vehicle, including the receiving time. The receiving time refers to the time when the vehicle receives the control command. The control command includes the target node address and target diagnostic data of the target node. The refresh indication information is used to indicate that there is a software refresh operation on the target node.

[0021] The acquisition module is used to acquire the frozen frame corresponding to the fault diagnostic code to be analyzed of the target node from the vehicle;

[0022] The time determination module is used to determine the fault occurrence time corresponding to the fault diagnostic code to be analyzed based on the freeze frame.

[0023] The analysis module is used to determine the cause of the fault if the comparison between the fault occurrence time and the reception time in the refresh indication information shows that the fault occurrence time and the reception time are consistent, and the fault is caused by performing a software refresh operation on the target node.

[0024] Fifthly, embodiments of this application also provide a vehicle, the vehicle including: one or more processors; a memory; one or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more application programs are configured to perform the method described in the first aspect above.

[0025] In a sixth aspect, embodiments of this application also provide a server, the server comprising: one or more processors; a memory; one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the method described in the second aspect above.

[0026] In a seventh aspect, embodiments of this application also provide a computer-readable storage medium storing processor-executable program code, which, when executed by the processor, causes the processor to perform the above-described method.

[0027] This application provides a software refresh method, a fault analysis method, a vehicle, a server, and a storage medium. Upon receiving a control command including the target node address and target diagnostic data, if the target node address exists in the node address of the control node within the vehicle, it is determined that the control command is an instruction to refresh the target node. The software refresh operation is then performed directly on the target node based on the control command. The node information of the target node and the reception time of the control command are stored locally within the vehicle, thus enabling local monitoring of the vehicle's software refresh. Simultaneously, refresh indication information, including the reception time, can be sent to a server connected to the vehicle. The server receives the refresh indication information, which is used to indicate that a software refresh operation has occurred on the target node. This enables remote monitoring of whether a software refresh operation has occurred on the vehicle based on the refresh indication information. Therefore, the method of this application achieves both local and remote monitoring of the vehicle's software refresh.

[0028] Other features and advantages of the embodiments of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the embodiments of this application. The objects and other advantages of the embodiments of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 shows a flowchart of a software refresh method according to an embodiment of this application.

[0031] Figure 2 shows a schematic diagram of a vehicle structure according to an embodiment of this application.

[0032] Figure 3 shows a flowchart of a fault analysis method according to an embodiment of this application.

[0033] Figure 4 shows a schematic diagram of a software refresh process in an embodiment of this application.

[0034] Figure 5 shows a structural block diagram of a software refresh device according to an embodiment of this application.

[0035] Figure 6 shows a structural block diagram of a fault analysis device according to an embodiment of this application.

[0036] Figure 7 shows a structural block diagram of a vehicle according to an embodiment of this application.

[0037] Figure 8 shows a structural block diagram of a server provided according to an embodiment of this application. Detailed Implementation

[0038] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. The components of the embodiments of the present application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without inventive effort are within the scope of protection of the present application.

[0039] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0040] Please refer to Figure 1, which shows a flowchart of a software refresh method according to an embodiment of this application for a vehicle. The method includes:

[0041] S110, Receive control commands.

[0042] The vehicle in this embodiment can be an electric vehicle or a fuel-powered vehicle, or it can be a sedan, SUV, bus, or truck, etc.

[0043] Control commands are instructions used to perform diagnostic operations, software updates, data backups, data interaction, or control operations on a vehicle. For example, a control command might be to turn on the vehicle lights, or to update a music player. Control commands can include the node address of the targeted control node and the control data.

[0044] A vehicle includes multiple control nodes. An ECU (Electronic Control Unit) within the vehicle can serve as a control node. The node address refers to the address of the control node, which can be either the physical address or the virtual address of the control node.

[0045] Control data refers to the data used to perform specific control operations on the control node. For example, if the control command is to turn on the vehicle lights, then the control data refers to the data used to turn on the vehicle lights. Similarly, if the control command is to refresh the music player, then the control data refers to the data used to refresh the music player.

[0046] If the control command includes target diagnostic data (i.e., the control data is target diagnostic data), then the software is refreshed in accordance with the steps S110-S130. In this case, the control node targeted by the control command is taken as the target node, and the node address of the target node is taken as the target node address.

[0047] Target diagnostic data is used to instruct software updates for target control nodes within the vehicle. In other words, if a control command includes target diagnostic data, it means the command is a software update instruction for the target node, and the target control node is the one specified in the command. If a control command does not include target diagnostic data, it means the command is not a software update instruction for the target node; in this case, the command may be another control operation, such as turning on the headlights or turning off the air conditioning.

[0048] In this application, for any control instruction, it can be determined whether the control instruction includes target diagnostic data by using the string in the target data segment of the control data of the control instruction.

[0049] For example, the target data segment can be the first six bits of the control instruction. If the target data segment of the control instruction is a target string, it is determined that the control instruction includes target diagnostic data, that is, the target string is the target diagnostic data; if the target data segment in the control instruction is not a target string, it is determined that the control instruction does not include target diagnostic data.

[0050] In some implementations, the target string can be "021002". That is, if the control instruction includes "021002XXXXXXXXXX", it is determined that the control instruction is used to refresh the target node; if the control instruction does not include "021002XXXXXXXXXX", it is determined that the control instruction is not used to refresh the target node.

[0051] Once it is determined that the control command is used to refresh the target node, the software refresh operation can be performed on the target node based on the specific content of the control command (that is, the target data segment and all the real data following the target data segment, such as the real data represented by "021002" and "XXXXXXXXXX" in the previous example).

[0052] For example, the structure of a vehicle is shown in Figure 2. The vehicle includes a body domain, a power domain, a chassis domain, a cabin domain, an intelligent driving domain, a gateway controller, an on-board automatic diagnostic system, and a remote communication terminal. The body domain, power domain, chassis domain, cabin domain, and intelligent driving domain all include multiple control nodes (i.e., ECUs in Figure 2).

[0053] The vehicle's gateway controller can connect to control nodes in various vehicle control domains, including the body domain, powertrain domain, chassis domain, cockpit domain, and intelligent driving domain, via the CAN (Controller Area Network) protocol. The gateway controller also connects to the vehicle's OBD (On-Board Diagnostics) system via the CAN protocol and to the vehicle's TBOX (Telematics Box) via the CAN protocol. The TBOX interacts with the server via the network.

[0054] In one embodiment, based on the aforementioned vehicle structure, the vehicle can receive control commands sent by diagnostic devices through its on-board diagnostic system (OBD). That is, the vehicle can connect to other diagnostic devices via the OBD interface, and the diagnostic devices can send control commands to the vehicle through the OBD interface. The OBD can then send the received control commands to the vehicle's gateway controller. Diagnostic devices can be, for example, vehicle diagnostic tools and computers.

[0055] In another embodiment, control commands sent by diagnostic devices can be received through the channel interface of the control domain where the target node is located. That is, the vehicle can also connect to other diagnostic devices through the channel interface of the control domain where the target node is located (generally the bus interface of that control domain). The diagnostic device sends control commands to the control domain where the target node is located through the channel interface of the control domain where the target node is located, and the control domain where the target node is located directly sends the control commands to the target node, so that the target node can perform software update operations based on the control commands.

[0056] In another embodiment, based on the aforementioned vehicle structure, the vehicle can receive control commands sent by the server via an onboard communication terminal. That is, the vehicle's TBOX receives the control commands sent by the server via the network, and then the onboard TBOX can send the control commands to the gateway controller via the CAN protocol.

[0057] After receiving control commands forwarded by TBOX or OBD, the gateway controller sends the control commands to the target control domain to which the target node belongs via the CAN protocol. The target control domain then sends the control commands to the target node, thereby controlling the target node.

[0058] S120. If the target node address exists in the node address of the control node in the vehicle, perform a software refresh operation on the target node based on the control command.

[0059] The presence of the target node address in the node address of the control node within the vehicle indicates that the control command is directed at the control node within the vehicle. In other words, the target control node is the control node within the vehicle, and the command is accurately sent to the vehicle, enabling control of the target node.

[0060] If the target node address is not found in the node address of the control node inside the vehicle, it means that the control command is not for the control node inside the vehicle. In other words, the target control node is not the control node inside the vehicle, and control of the target node cannot be achieved. At this time, a prompt message can be output to indicate that the control command was sent incorrectly.

[0061] Generally speaking, the node address of the control node in the vehicle conforms to a preset address format. For example, the node address of the control node in the vehicle conforms to a preset address format, which can be "7XX". For example, "720" is the node address of the body control node under the body domain, and "710" is the node address of the brake control node under the power domain.

[0062] Therefore, the vehicle can store the node addresses of each control node (the node addresses conform to the aforementioned preset address format), and thus, when a control command is received, it can directly determine whether the target node address of the control command exists in the node addresses of each control node.

[0063] In some implementations, S120 may further include: if the target node address exists in the node address of the control node in the vehicle, the target node enters refresh mode; in response to the target node entering refresh mode, a software refresh operation is performed on the target node based on control commands to update the corresponding target diagnostic data. Here, refresh mode refers to the Boot mode of the vehicle's control node.

[0064] Generally, vehicle control nodes have a Boot mode and an APP (application) mode (also called normal mode). In APP mode, the APP on the control node runs normally, and the control node can communicate normally with other control nodes in the vehicle to achieve information exchange between control nodes. In Boot mode, the APP on the control node stops running, and signal exchange and information exchange between the control node and other control nodes in the vehicle cease. The APP on the control node refers to the APP running on the control node or requiring the control node's participation during operation.

[0065] The software refresh operation is performed when the target node is in refresh mode. This avoids the situation where other control nodes cannot communicate with the target node when the target node is in APP mode, resulting in the recording of vehicle faults. This would lead to too much recorded fault information and make fault analysis more difficult, thus reducing the difficulty of fault analysis.

[0066] In some implementations, if the target node address exists in the node address of the control node within the vehicle, and the control command does not include target diagnostic data, the target node is directly controlled to perform the corresponding control operation based on the control command. For example, if the control command is to open a music player, and it is determined that the control command does not include target diagnostic data, the target node is directly controlled to open the music player based on the control command.

[0067] S130, store the node information of the target node and the time of receiving the control command, and / or send refresh indication information including the time of receiving the control command to the server connected to the vehicle.

[0068] The refresh indication information is used to indicate that a software refresh operation has occurred on the target node. The refresh indication information may include at least the time the control command was received, and may also include the target node's node information, the target node's software version information before the refresh (e.g., version number), and the target node's software version information after the refresh. The control node's node information may include the control node's identifier and node address, etc. The node identifier may be the control node's name, control node number, etc., and the receipt time may be in the form of a timestamp.

[0069] The target node's node information and the time of receiving control commands can be stored in the vehicle's local memory.

[0070] The vehicle can also send refresh instruction information to the server, which stores the refresh instruction information, thereby enabling remote monitoring of the vehicle's software refresh. The refresh instruction information can be in the format of a network message; for example, it can be a GW_VehicleFlashMode bus message.

[0071] In this application, the vehicle can send refresh instruction information to the gateway controller via the CAN protocol, the gateway controller can then send the refresh instruction information to the TBOX via the CAN protocol, and the TBOX can then send the gateway instruction information to the server.

[0072] When a vehicle receives a control command, it refreshes the software of the target node according to the control command. Therefore, the time of receiving the control command can be used as the software refresh time of the target node.

[0073] In some implementations, prior to S130, the method further includes: in response to receiving a control command, acquiring a time signal from the vehicle's onboard communication terminal; and determining the time of receiving the control command based on the time signal.

[0074] Upon receiving a control command, the vehicle can obtain a time signal from the onboard communication terminal and determine the timestamp in the obtained time signal as the time the control command was received. This achieves the purpose of obtaining the time of control command reception.

[0075] In this embodiment, after receiving a control command including the target node address and target diagnostic data, if the target node address exists in the node address of the control node in the vehicle, it is determined that the control command is an instruction to refresh the target node. The software refresh operation is then performed directly on the target node based on the control command, storing the node information of the target node and the reception time of the control command. Thus, the vehicle's local storage of the target node's node information and the reception time of the control command enables local monitoring of the vehicle's software refresh. Simultaneously, refresh indication information including the reception time can be sent to a server connected to the vehicle. The server receives the refresh indication information, which is used to indicate that a software refresh operation has occurred on the target node. This enables remote monitoring by the server of whether a software refresh operation has occurred on the vehicle based on the refresh indication information. Therefore, the method of this application achieves both local and remote monitoring of the vehicle's software refresh.

[0076] Please refer to Figure 3, which shows a flowchart of a fault analysis method according to another embodiment of this application, for a server, the method including:

[0077] S210, Receive refresh indication information sent by the vehicle, including the reception time.

[0078] Among them, the refresh indication information is used to indicate that a software refresh operation has occurred on the target node; the reception time refers to the time when the vehicle receives the control command; the control command includes the target node address and target diagnostic data of the target node to which the control command is directed.

[0079] The specific description in S210 here is the same as that in S110-S130 above, and will not be repeated here.

[0080] S220. Obtain the freeze frame corresponding to the fault diagnosis code to be analyzed for the target node from the vehicle.

[0081] Diagnostic Trouble Codes (DTCs) are generated by the aforementioned control nodes in the vehicle to indicate faults or anomalies in the engine, transmission, or other systems. When a vehicle malfunctions, its control nodes record a DTC. A freeze frame refers to the vehicle's operating status information recorded by the vehicle's control nodes at the instant the fault occurs.

[0082] The fault diagnostic code to be analyzed refers to any fault diagnostic code obtained from the vehicle for the target node. That is, the fault diagnostic code generated by the target node is used as the fault diagnostic code to be analyzed. The freeze frame corresponding to the fault diagnostic code to be analyzed is a freeze frame that includes the fault diagnostic code to be analyzed.

[0083] S230. Based on the freeze frame, determine the fault occurrence time of the fault to be analyzed to which the diagnostic code to be analyzed belongs.

[0084] The fault to be analyzed, which is the fault indicated by the diagnostic code to be analyzed, refers to the fault to be analyzed.

[0085] Based on the obtained freeze frame, the timestamp indicating the occurrence time of the fault to be analyzed is determined in the freeze frame and used as the occurrence time of the fault to be analyzed. Specifically, this occurrence time refers to the time when the fault to be analyzed occurs on the target node.

[0086] S240. If the comparison between the fault occurrence time and the reception time in the refresh indication information shows that the fault occurrence time and the reception time are consistent, the cause of the fault is determined to be the execution of a software refresh operation on the target node.

[0087] After obtaining the occurrence time of the fault to be analyzed in the target node, the occurrence time can be compared with the receiving time of the software refresh instruction in the refresh instruction information to determine the cause of the fault to be analyzed.

[0088] If the comparison results show that the occurrence time and the reception time are consistent, the cause of the fault is determined to be a software refresh operation performed on the target node. If the comparison results show that the occurrence time and the reception time are consistent, it means that the fault to be analyzed occurred when the target node was software refreshed. Therefore, it is determined that the software refresh of the target node caused the target node to malfunction—the fault to be analyzed.

[0089] If the comparison results show that the occurrence time and the reception time are inconsistent, it is determined that the cause of the fault is not the software refresh operation performed on the target node. If the comparison results show that the occurrence time and the reception time are inconsistent, it means that the fault to be analyzed did not occur when the software refresh was performed on the target node. Therefore, it is determined that the software refresh of the target node did not cause the fault to be analyzed to occur on the target node.

[0090] In this embodiment, the server can perform fault analysis based on the freeze frame corresponding to the fault diagnostic code to be analyzed and the refresh indication information of the target node, so as to determine the cause of the fault indicated by the fault diagnostic code to be analyzed. This realizes the determination of whether the vehicle fault is caused by software refresh based on the refresh indication information of the target node, thereby avoiding the situation where it is difficult to determine whether the vehicle fault is caused by software refresh, which leads to a large difficulty in vehicle fault analysis and low efficiency in vehicle fault analysis, thus improving the efficiency of vehicle fault analysis.

[0091] In one example, the software refresh process is shown in Figure 4. The vehicle receives control commands through the onboard communication terminal or the onboard automatic diagnostic system. The gateway controller identifies the target node address and target diagnostic data. The gateway controller determines whether the target node address and target diagnostic data exist. It can store the reception time and the node information of the target node locally. At the same time, it determines that the refresh flag bit is 1. A refresh flag bit of 1 indicates that a software refresh operation should be performed on the target node. Then, based on the refresh flag bit being 1, refresh instruction information is created. After that, the refresh instruction information is sent to the server through the onboard communication terminal. Finally, the gateway controller determines whether to continue sending control commands including other target node addresses. If so, the software refresh process continues according to the above process; if not, the process ends.

[0092] Referring to Figure 5, Figure 5 shows a structural block diagram of a software refresh device according to an embodiment of this application. For use in a vehicle, the device 800 includes:

[0093] The first receiving module 810 is used to receive control commands; the control commands include the target node address and target diagnostic data of the target node.

[0094] The refresh module 820 is used to perform a software refresh operation on the target node based on the control command if the target node address exists in the node address of the control node in the vehicle.

[0095] The storage module 830 is used to store node information of the target node and the time of receiving control commands, and / or send refresh indication information including the time of receiving control commands to a server connected to the vehicle; the refresh indication information is used to indicate that a software refresh operation has occurred on the target node.

[0096] Optionally, the refresh module 820 is further configured to: if the node address of the control node in the vehicle contains the address of the target node, the target node enters refresh mode; in response to the target node entering refresh mode, perform a software refresh operation on the target node based on the control command to update the corresponding target diagnostic data.

[0097] Optionally, the storage module 830 is also configured to, in response to receiving a control command, acquire a time signal from the vehicle's onboard communication terminal; and, based on the time signal, determine the time of receiving the control command.

[0098] Optionally, the first receiving module 810 is further configured to receive control commands sent by the diagnostic equipment through the vehicle's on-board automatic diagnostic system; receive control commands sent by the diagnostic equipment through the channel interface of the control domain where the target node is located; and receive control commands sent by the server through the vehicle's on-board communication terminal.

[0099] Optionally, the refresh module 820 is also used to determine that the control instruction includes target diagnostic data if the target data segment in the control instruction is a target string.

[0100] Referring to Figure 6, Figure 6 shows a structural block diagram of a fault analysis device according to an embodiment of this application. For use with a server, the device 900 includes:

[0101] The second receiving module 910 is used to receive refresh indication information sent by the vehicle, including the receiving time. The receiving time refers to the time when the vehicle receives the control command. The control command includes the target node address and target diagnostic data of the target node. The refresh indication information is used to indicate that there is a software refresh operation on the target node.

[0102] The acquisition module 920 is used to acquire the frozen frame corresponding to the fault diagnostic code to be analyzed of the target node from the vehicle;

[0103] The time determination module 930 is used to determine the fault occurrence time corresponding to the fault diagnostic code to be analyzed based on the freeze frame.

[0104] The analysis module 940 is used to determine the cause of the fault as a software refresh operation performed on the target node if the comparison between the fault occurrence time and the reception time in the refresh indication information is consistent.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0106] Furthermore, the functions in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module.

[0107] Please refer to Figure 7, which shows a structural block diagram of a vehicle according to an embodiment of this application. The vehicle 500 in this application may include one or more components such as a processor 510, a memory 520, and one or more application programs. The one or more application programs may be stored in the memory 520 and configured to be executed by one or more processors 510, and the one or more programs are configured to perform the methods described in the foregoing method embodiments.

[0108] The processor 510 may include one or more processing cores. The processor 510 connects to various parts within the vehicle 500 using various interfaces and lines, and performs various functions and processes data of the vehicle 500 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 520, and by calling data stored in the memory 520. Optionally, the processor 510 may be implemented using at least one of the following hardware forms: Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 510 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 510 and may be implemented separately using a communication chip.

[0109] The memory 520 may include random access memory (RAM) or read-only memory (ROM). The memory 520 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 520 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the vehicle 500 during use (such as phonebooks, audio and video data, chat log data, etc.).

[0110] Please refer to Figure 8, which shows a structural block diagram of a server provided according to an embodiment of this application. It should be noted that the server 1200 shown in Figure 8 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] As shown in Figure 8, the server 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0112] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0113] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0114] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0115] On the other hand, this application also provides a computer-readable storage medium storing program code that can be called by a processor to execute the methods described in the above method embodiments.

[0116] Computer-readable storage media can be electronic storage devices such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or a cluster of ROMs. Optionally, computer-readable storage media include non-transitory computer-readable storage media. The computer-readable storage medium has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in a suitable form.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A software refresh method, characterized in that, For use in a vehicle, the method includes: Receive control commands; the control commands include the target node address and target diagnostic data of the target node; If the target node address exists in the node address of the control node in the vehicle, perform a software refresh operation on the target node based on the control command; The system stores the node information of the target node and the reception time of the control command, and / or sends refresh indication information including the reception time of the control command to a server connected to the vehicle; the refresh indication information is used to indicate that the target node has a software refresh operation.

2. The method according to claim 1, characterized in that, If the target node address exists in the node address of the control node within the vehicle, the step of performing a software refresh operation on the target node based on the control command includes: If the target node address exists in the node address of the control node in the vehicle, the target node enters refresh mode; In response to the target node entering the refresh mode, a software refresh operation corresponding to the target diagnostic data is performed on the target node based on the control command.

3. The method according to claim 1, characterized in that, Before storing the node information of the target node and the time of receiving the control command, the method further includes: In response to receiving the control command, a time signal is obtained from the vehicle's onboard communication terminal; Based on the time signal, the receiving time of the control command is determined.

4. The method according to claim 1, characterized in that, The received control command includes at least one of the following: The vehicle receives the control commands sent by the diagnostic equipment through its on-board automatic diagnostic system. The control commands sent by the diagnostic device are received through the channel interface of the control domain where the target node is located; The vehicle receives the control commands sent by the server through its onboard communication terminal.

5. The method according to claim 1, characterized in that, The method further includes: If the target data segment in the control instruction is a target string, then the control instruction includes target diagnostic data.

6. A fault analysis method, characterized in that, For use with a server, the method includes: The system receives refresh indication information sent by the vehicle, including the reception time, where the reception time refers to the time when the vehicle receives the control command, and the control command includes the target node address and target diagnostic data of the target node; the refresh indication information is used to indicate that the target node has a software refresh operation. Obtain the freeze frame corresponding to the fault diagnosis code to be analyzed of the target node from the vehicle; Based on the frozen frame, determine the fault occurrence time corresponding to the fault diagnostic code to be analyzed; If the comparison between the fault occurrence time and the reception time in the refresh indication information shows that the fault occurrence time and the reception time are consistent, the cause of the fault is determined to be the execution of a software refresh operation on the target node.

7. A vehicle, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the method as described in any one of claims 1-5.

8. A server, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the method as described in claim 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores processor-executable program code, which, when executed by the processor, causes the processor to perform the method according to any one of claims 1-7.

Images