CN116450395A - Vehicle software fault repairing method and device and cloud server - Google Patents
Vehicle software fault repairing method and device and cloud server Download PDFInfo
- Publication number
- CN116450395A CN116450395A CN202310424284.6A CN202310424284A CN116450395A CN 116450395 A CN116450395 A CN 116450395A CN 202310424284 A CN202310424284 A CN 202310424284A CN 116450395 A CN116450395 A CN 116450395A
- Authority
- CN
- China
- Prior art keywords
- vehicle
- data
- software
- repair
- strategy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 68
- 230000008439 repair process Effects 0.000 claims abstract description 101
- 238000004458 analytical method Methods 0.000 claims abstract description 73
- 238000012795 verification Methods 0.000 claims abstract description 43
- 238000013524 data verification Methods 0.000 claims abstract description 20
- 230000005856 abnormality Effects 0.000 claims abstract description 17
- 230000006870 function Effects 0.000 claims description 61
- 230000008569 process Effects 0.000 claims description 23
- 230000003993 interaction Effects 0.000 claims description 19
- 238000005067 remediation Methods 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 9
- 238000001514 detection method Methods 0.000 claims description 9
- 230000004044 response Effects 0.000 claims description 8
- 230000005059 dormancy Effects 0.000 claims description 6
- 230000007958 sleep Effects 0.000 claims description 3
- 238000004891 communication Methods 0.000 description 12
- 238000003745 diagnosis Methods 0.000 description 12
- 238000012360 testing method Methods 0.000 description 6
- 238000013522 software testing Methods 0.000 description 5
- 230000002159 abnormal effect Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000001680 brushing effect Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000000306 recurrent effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0718—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an object-oriented system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Vehicle Cleaning, Maintenance, Repair, Refitting, And Outriggers (AREA)
Abstract
The invention provides a vehicle software fault repairing method, device and cloud server, when a vehicle-mounted terminal has a software fault, failure data of a fault object when the fault occurs are obtained, related parties with abnormality in the vehicle-mounted terminal are determined based on the failure data, the failure data are analyzed to obtain analysis data, then data verification is carried out on the related parties based on the analysis data to obtain a verification result, a software repairing tool is adopted to generate a repairing strategy based on the verification result, when the driving function of the vehicle is not affected, the repairing strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs related software of the related parties, and the timely repairing of the vehicle is realized when the vehicle-mounted terminal has the software fault.
Description
Technical Field
The invention relates to the technical field of automobiles, in particular to a vehicle software fault repairing method and device and a cloud server.
Background
In recent years, with the progress of science and technology, the demands of people for functions of vehicles are continuously increased, and various software functions are continuously integrated in vehicle systems, so that the vehicles are not only simple mobility tools, but are provided with rich and colorful functions, different experiences are brought to different customers, but the controller software design is more and more complicated along with the richness of the functions of the vehicles, and then the problems of the controller software are more and more, and finally the problems of the after-sale vehicles are more and more. When a customer finds a function using problem in the process of driving a vehicle, the problem can be solved only by going to a 4S store for after-sales investigation, the customer needs to spend a large amount of time waiting in the process of solving the problem, and the same problem also has recurrent feasibility, so that the customer spends a large amount of time repeatedly going to the 4S store for after-sales, sometimes the 4S store has no set-up point in a remote area, and the customer needs to drive a long-distance journey to go to a nearby set-up point, so that how to solve the software problem existing in the vehicle in time becomes one of technical problems to be solved urgently by a person in the field.
Disclosure of Invention
In view of the above, the embodiment of the invention provides a vehicle software fault repairing method, device and cloud server, and the software faults of the vehicle-mounted terminal are solved in time.
In order to achieve the above object, the embodiment of the present invention provides the following technical solutions:
a vehicle software fault remediation method, comprising:
acquiring failure data uploaded by a vehicle-mounted terminal through a wireless network;
determining a related party with abnormality based on the failure data;
analyzing the failure data to obtain analysis data;
performing data verification on the related party based on the analysis data to obtain a verification result;
transmitting the verification result to a software repair tool;
acquiring a repair strategy fed back by the software repair tool;
judging whether the repair strategy is influence the driving function of the vehicle;
and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
Optionally, in the vehicle software fault repairing method, the data checking is performed on the related party based on the analysis data, and a checking result is obtained, including:
acquiring an inter-component interaction strategy and a dormancy wakeup strategy corresponding to the related party;
judging whether the related party accords with the inter-component interaction strategy or not based on the analysis data;
judging whether the sleep wake-up strategy is met in the use process of the related party based on the analysis data;
E2E algorithm verification is carried out on the related party based on the analysis data, and E2E verification results are obtained;
and carrying out SECOC algorithm verification on the related party based on the analysis data to obtain a SECOC verification result.
Optionally, in the vehicle software fault repairing method, the data verification is performed on the relevant party based on the analysis data, and a verification result is obtained, and the method further includes:
detecting the sending data of the related party to obtain a detection result;
detecting the received data of the related party to obtain a detection result;
and judging whether the transmission data between the related parties accords with a CAN/CANFD message data format or not based on the analysis data.
Optionally, in the vehicle software fault repairing method, after sending the verification result to a software repairing tool, the method further includes:
when feedback information for representing insufficient data fed back by the software repair tool is obtained, generating a data calling instruction for calling a whole vehicle part controller of a vehicle, and sending the data calling instruction to the vehicle-mounted terminal;
acquiring the data of a whole vehicle part controller fed back by the vehicle-mounted terminal in response to the data retrieval instruction;
and taking the data of the whole vehicle part controller and the acquired failure data as the failure data together, and determining a related party with abnormality based on the failure data and the follow-up steps in the executing step.
Optionally, in the vehicle software fault repairing method, after sending the verification result to a software repairing tool, the method further includes:
when the software repair tool is detected to fail in repair, the failure data is sent to a target object;
and obtaining a repair strategy fed back by the target object, executing the step of judging whether the repair strategy influences the driving function of the vehicle, and the subsequent step.
Optionally, in the vehicle software fault repairing method, determining whether the repairing policy affects a driving function of the vehicle includes:
judging whether the repair strategy affects the braking, starting, steering or headlight control system of the vehicle, and if so, indicating that the repair strategy affects the driving function of the vehicle.
Optionally, in the vehicle software fault repairing method, when the driving function of the vehicle is affected, whether the vehicle is in a stationary state is judged;
and when the vehicle is in a stationary state, feeding back the repair strategy to the vehicle-mounted terminal so that the vehicle-mounted terminal repairs the related software of the related party.
Optionally, in the foregoing vehicle software fault repairing method, when affecting a driving function of a vehicle, the method further includes:
and when the vehicle is not in a stationary state, issuing a soft part repair request to the vehicle-mounted terminal so as to prompt a user to switch the vehicle to the stationary state.
A vehicle software fault remediation device comprising:
the vehicle-mounted terminal interaction unit is used for acquiring failure data uploaded by the vehicle-mounted terminal;
a diagnostic analysis tool analysis unit for determining a relevant party to the occurrence of the abnormality based on the failure data; analyzing the failure data to obtain analysis data; performing data verification on the related party based on the analysis data to obtain a verification result; transmitting the verification result to a software repair tool in a software repair unit
The software repairing unit is used for acquiring a repairing strategy fed back by the software repairing tool; judging whether the repair strategy influences the driving function of the vehicle or not; and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
A cloud server, comprising: a memory and a processor;
the memory is used for storing programs;
the processor is configured to execute the program to implement each step of the vehicle software fault repairing method described in any one of the above.
Based on the technical scheme, when the vehicle-mounted terminal has a software fault, the method provided by the embodiment of the invention acquires the failure data of the fault object when the fault occurs, determines the related party with the abnormality in the vehicle-mounted terminal based on the failure data, analyzes the failure data to obtain analysis data, then performs data verification on the related party based on the analysis data to obtain a verification result, generates a repair strategy based on the verification result by adopting a software repair tool, and feeds back the repair strategy to the vehicle-mounted terminal when the vehicle driving function is not affected, so that the vehicle-mounted terminal repairs the related software of the related party, thereby realizing timely repair of the vehicle when the vehicle-mounted terminal has the software fault.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present invention, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic flow chart of a vehicle software fault repairing method disclosed in an embodiment of the present application;
FIG. 2 is a flow chart of a vehicle software fault remediation method disclosed in another embodiment of the present application;
fig. 3 is a schematic structural diagram of a vehicle software fault repairing device disclosed in an embodiment of the present application;
fig. 4 is a schematic structural diagram of a cloud server disclosed in an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
In order to effectively solve software problems existing in a vehicle in time, the application discloses a vehicle software fault repairing method, when the vehicle has software problems, invalid data generated when the software has problems are sent to a server through a wireless network, the server performs data verification through the invalid data, a corresponding repairing strategy is generated by a software repairing tool based on a verification result, and the repairing strategy is fed back to a vehicle-mounted terminal, so that the vehicle-mounted terminal repairs related software of a related party.
Referring to fig. 1, the present application discloses a vehicle software fault repair method, which may include:
step S101: and acquiring failure data uploaded by the vehicle-mounted terminal.
When a user uses a vehicle, and when the function of a certain controller fails, the situation that the software in the controller fails in the running process is indicated, at this time, relevant data of the failure function in the time period needs to be extracted, the data are recorded as failure data, namely failure log data (log data generally refers to records of a system or certain software on a finished process), the controller transmits the failure log data to a Gateway (GW), and the GW transmits the failure log data to a background through a vehicle wireless terminal (T_BOX), and the background transmits the failure log data to a cloud diagnosis platform through a wireless network for data analysis;
step S102: and determining a related party with abnormality based on the failure data.
In this step, by analyzing the failure data, the relevant parties that are abnormal are determined based on the analysis result, and these parties may refer to two electronic control units ECU that have abnormality in the data when sending and receiving the data; for example, when an abnormality occurs in the data interaction and response process of two ECUs, the relevant party refers to the two ECUs performing the data interaction.
Step S103: and analyzing the failure data to obtain analysis data.
In the scheme, the failure data is required to be analyzed, so that the functional state and the whole vehicle data of the related party when the abnormality occurs are determined, other data can be obtained through analysis, and the related party can be subjected to data verification through the data, so that the fault of the related party can be identified through the data verification.
Step S104: and carrying out data verification on the related party based on the analysis data to obtain a verification result.
In this step, the resolved
The data verification may include: inter-component interaction policy checking, dormancy wakeup policy checking, E2E check checking and SECOC check checking;
in making the above diagnosis, a specific diagnosis procedure is as follows:
regarding inter-component interaction policy diagnostics:
the diagnostic analysis tool acquires the use state of the function of the related party and the whole vehicle data from the analysis data; and acquiring interaction strategies among related parties, wherein the interaction strategies among the related parties can be acquired from a pre-configured database. Based on the function using state and the whole vehicle data, simulating the function state of the vehicle when the abnormality occurs, and detecting whether the related party executes data interaction according to the related interaction strategy, for example, if the condition that a key is required to be detected to be on line, the gear is P, the vehicle speed is zero and other preconditions are input when the vehicle is started, the vehicle can be started, if one item of the condition does not send data according to the strategy, the vehicle can not be started, at the moment, detecting whether the vehicle is executed according to the strategy when the vehicle is started, if the condition is executed according to the strategy, the condition that the interaction strategy diagnosis among the components is not abnormal is indicated, and otherwise, the interaction strategy diagnosis among the components is abnormal.
Diagnosis of sleep wake strategy:
in the step, the diagnostic and analytical tool acquires the whole vehicle data state from the analysis data, acquires the dormancy wakeup strategy of the relevant party from the database, judges whether the relevant party accords with the dormancy wakeup strategy in the using process, if the relevant party is found to wake up abnormally or dormancy in the detecting process, and records and feeds back the result.
Regarding E2E diagnostics:
in the scheme, a diagnostic analysis tool judges whether a counter and a CRC value are inconsistent or not in the checking process of a related party according to an E2E algorithm according to analysis data, if so, when a host (Head Unit, HUT) sends a frame of data to a T_BOX, the HUT firstly carries out operation according to the E2E checking algorithm to obtain a counter and a CRC result, the T_BOX carries out operation according to the same algorithm after receiving the data sent by the HUT to obtain the counter and the CRC result, the counter and the CRC value of the counter and the CRC result are compared, if the counter and the CRC value are consistent, the checking is passed, otherwise, the checking is failed.
Regarding SECOC diagnosis:
and judging whether the MAC and the fresh value are inconsistent in the verification process of the related party according to the SECOC algorithm during interaction by the diagnostic analysis tool and the analysis result, if the two party values pass the verification, the data are normally received, and otherwise, the data are normally received. In the scheme, the freshness value can be directly extracted from a freshness value module in the network security controller. The MAC is the related party through the mutual data and performing AES encryption algorithm operation.
Step S105: and sending the verification result to a software repair tool.
In the scheme, a software repair tool is prestored at the cloud server and is used for generating a repair strategy for repairing faults of related parties based on diagnosis results. The software repairing tool is preconfigured by a user, after the software repairing tool acquires the verification result, the software repairing tool can judge the program with the problem on the related party based on the verification result, and provides repairing schemes for the program with the problem, and the repairing schemes can be automatically executed by the vehicle-mounted terminal, so that the vehicle-mounted terminal can automatically repair the related party based on the repairing schemes.
Step S106: and acquiring a repair strategy fed back by the software repair tool.
The software repairing tool can call pre-stored software packages of related parties from a related database according to analysis results of the diagnostic analysis tool, the software repairing packages are screened out from the software packages, the software repairing packages are loaded in a repairing strategy, when the software packages matched with the analysis results are not found in the database, the software repairing tool can import the software packages of related parties of an upper edition to combine the diagnostic analysis results with the ECU standard strategy to carry out partial code modification, finally, software combination is completed, software package data and change points obtained by the software combination are output to a software testing tool, and after the software testing tool passes the test, the software package data is loaded in the repairing strategy.
In this embodiment, before the repair policy is sent to the vehicle-mounted terminal, a software testing tool may also be used to test the software package in the repair policy, and step S107 is executed after the test passes.
Step S107: and judging whether the repair strategy influences the driving function of the vehicle.
In this scheme, considering that the vehicle may be in a driving state when the vehicle-mounted terminal is automatically repairing, at this time, if the repaired object is some equipment related to the driving state of the vehicle, the driving function of the vehicle may be affected when repairing, so it needs to be judged whether the repairing object of the repairing strategy affects the driving function of the vehicle when repairing, if affecting, and when the vehicle is in the driving state, the repairing strategy will not be fed back to the vehicle-mounted terminal immediately, and if the driving function of the vehicle is not affected or the vehicle is in a stationary state, at this time, step S108 is executed to directly send the repairing strategy to the vehicle-mounted terminal.
For example, it is determined whether the repair strategy affects a braking, starting, steering or headlight control system of the vehicle, and if so, it is indicated that the repair strategy affects a driving function of the vehicle. When a determination is made as to whether the repair strategy affects only customer driving functions (e.g., sunroof, seat, steering wheel heating, etc.), it is indicated that the repair strategy does not affect vehicle driving functions.
Step S108: and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
When the driving function of the vehicle is affected, the vehicle-mounted terminal cannot be repaired in the running process of the vehicle, so that whether the vehicle is in a stationary state or not needs to be judged, when the vehicle is in the stationary state, the repairing strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs related software of the related party, and when the vehicle is not in the stationary state, a soft part repairing request is issued to the vehicle-mounted terminal, so that a user is prompted to switch the vehicle to the stationary state.
According to the technical scheme disclosed by the embodiment of the application, when the vehicle-mounted terminal has a software fault, failure data of a fault object when the fault occurs are obtained, an abnormal relevant party in the vehicle-mounted terminal is determined based on the failure data, the failure data are analyzed to obtain analysis data, then the relevant party is subjected to data verification based on the analysis data to obtain a verification result, a software repairing tool is adopted to generate a repairing strategy based on the verification result, when a vehicle driving function is not affected, the repairing strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs relevant software of the relevant party, and timely repairing of a vehicle when the vehicle-mounted terminal has the software fault is realized.
In the technical solution disclosed in this embodiment, in addition to performing the data verification of the above manner on the analysis data, data verification may be performed on data transmission and reception of the relevant party, so that data verification is performed on the relevant party based on the analysis data, to obtain a verification result, and the method may further include: detecting the sending data of the related party to obtain a detection result; detecting the received data of the related party to obtain a detection result; and judging whether the transmission data between the related parties accords with a CAN/CANFD message data format or not based on the analysis data.
When the related party is subjected to transmitted data detection, the specific process is as follows:
the diagnostic analysis tool detects whether the bus state is changed from 1 to 0 when the related party sends certain interactive data recorded in invalid data to the CAN/CANFD network segment in the same period, if so, the related party data is normally sent, otherwise, the related party data is abnormally sent.
When the related party detects the received data, the specific process is as follows:
when the diagnostic analysis tool detects that the related party receives CAN/CANFD data recorded in invalid data in the same time period, whether each related ECU responds with an ACK or not, if the bus displays 0 in the ACK interval period, the related party CAN be normally received, otherwise, the related party receives abnormality; wherein, each relevant ECU refers to an electrical appliance architecture network topology.
Judging whether the transmission data between the related parties accords with a CAN/CANFD message data format or not, wherein the specific process is as follows:
the diagnostic analysis tool judges whether the transmitted data accords with the CAN/CANFD message data format according to the related party transmission data recorded in the invalid data and the network segment information of the transmission data, if the transmission data is detected to pass the detection according to the CAN2.0 standard required data format, the message data format is proved to have no problem, and otherwise, the transmission data is proved to have the opposite problem.
When analyzing faults, if only analyzing the problem phenomenon, only the data related to the relevant party can be called, but the data related to other ECUs can not be called, but when the data error occurs to the relevant party, the fault is also possibly caused by the interference of other ECUs of the whole vehicle, and belongs to the comprehensive problem, the multi-party ECU data are needed to support at the moment, the searching range is enlarged, and the root cause of the problem is determined, so in the embodiment, when the analysis result of the detection process is transmitted to a software repairing tool, if the analysis result is found to be insufficient to output the analysis result (repairing strategy) in the analysis process of the software repairing tool, a demand feedback cloud diagnosis platform can be started to call the data demand of a part of controller of the whole vehicle through T_BOX and GW, the whole vehicle demand controller responds to and calls response data according to the call data demand, the response data have wider range compared with the failure data, after the response data are acquired, the response data are transmitted to the TSP tool through a reverse diagnosis platform as the analysis result, and the repairing data are transmitted to the TSP tool as the final diagnosis data to the software repairing tool, and the step 102 is generated; thus, after sending the verification result to the software repair tool, it further comprises:
step S201: when feedback information which is fed back by the software repair tool and used for representing insufficient data is obtained, a data calling instruction used for calling a vehicle whole part controller is generated, and the data calling instruction is sent to the vehicle-mounted terminal.
Step S202: and acquiring the data of the whole vehicle part controller fed back by the vehicle-mounted terminal in response to the data retrieval instruction.
Step S203: and taking the data of the whole vehicle part controller and the acquired failure data as the failure data together, and determining a related party with abnormality based on the failure data and the follow-up steps in the executing step.
In the technical scheme disclosed in this embodiment, if the diagnostic analysis tool and the software repair tool are combined with the whole vehicle data, the failure data and the database, and the repair strategy cannot be analyzed, the analysis conclusion of the diagnostic analysis tool and the software repair tool can be fed back to the TSP background, the TSP background can be sent to the technical specialist in a short message or system push mode, after receiving the information, the technical specialist can log in the TSP background to call relevant information for analysis, and after the conclusion is analyzed, the analysis problem process and the result are transmitted to the diagnostic tool specialist, the software repair tool specialist and the software test tool specialist for transverse expansion and perfecting the corresponding data of the diagnostic analysis tool and the software repair tool, so that the diagnostic analysis tool and the software repair tool after being completed have wider applicability, and meanwhile, the repair strategy of the specialist is obtained. Thus, after sending the verification result to the software repair tool, the method further comprises: when the software repair tool is detected to fail in repair, the failure data is sent to a target object; and obtaining a repair strategy fed back by the target object, executing the step of judging whether the repair strategy influences the driving function of the vehicle, and the subsequent step.
When the vehicle-mounted terminal is repaired, a plurality of functions of the vehicle-mounted terminal may need to be repaired, if the functions needing to be repaired simultaneously comprise functions to be repaired which influence the driving function of the client and functions to be repaired which do not influence the driving function of the client, the functions to be repaired which influence the driving function of the client can be repaired preferentially, after the functions to be repaired which influence the driving function of the client are repaired, other functions to be repaired which do not influence the driving function of the client are repaired, and of course, after the functions to be repaired which influence the driving function of the client are repaired are completed, prompt information which can start the vehicle by a user can be output to a user through the vehicle-mounted terminal.
The software testing tool combines software package data and change points provided by the software repairing tool to carry out software simulation test, after the test is passed, the cloud diagnosis platform transmits the TSP background, and when the static state of the vehicle is detected, the software package affecting the driving function controller is issued by the background preferentially, so that the related controller is quickly written; the driving function is not affected, and when the stationary state of the vehicle is detected and after the vehicle is agreed by a client, a corresponding controller is issued through a background to perform brushing; if the problem is still detected in the software testing process, the software repairing tool is modified and then tested, and the software package is issued until the test is free of the problem.
In the technical scheme disclosed in another embodiment of the present application, when the vehicle-mounted terminal performs software repair, the software repair may be performed in a stationary state of the vehicle, that is, before the repair policy is fed back to the vehicle-mounted terminal, whether the vehicle is in a stationary state is first determined, and if the vehicle is in a stationary state, the repair policy is fed back to the vehicle-mounted terminal.
In this embodiment, a vehicle software fault repairing device is disclosed, and specific working contents of each unit in the device are referred to the contents of the above method embodiment.
The following describes a vehicle software fault repairing device provided by an embodiment of the present invention, and the vehicle software fault repairing device described below and the vehicle software fault repairing method described above may be referred to correspondingly.
Referring to fig. 3, the vehicle software fault repairing apparatus includes:
the vehicle-mounted terminal interaction unit A is used for acquiring failure data uploaded by the vehicle-mounted terminal;
a diagnostic analysis tool analysis unit B for determining a relevant party with abnormality based on the failure data; analyzing the failure data to obtain analysis data; performing data verification on the related party based on the analysis data to obtain a verification result; transmitting the verification result to a software repair tool in a software repair unit
The software repairing unit C is used for acquiring a repairing strategy fed back by the software repairing tool; judging whether the repair strategy influences the driving function of the vehicle or not; and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
The specific functions of the vehicle-mounted terminal interaction unit a, the diagnostic analysis tool analysis unit B and the software repairing unit C are described with reference to the above method embodiments, and are not described here.
Fig. 4 is a hardware structure diagram of a cloud server according to an embodiment of the present invention, as shown in fig. 4, may include: at least one processor 100, at least one communication interface 200, at least one memory 300, and at least one communication bus 400;
in the embodiment of the present invention, the number of the processor 100, the communication interface 200, the memory 300 and the communication bus 400 is at least one, and the processor 100, the communication interface 200 and the memory 300 complete the communication with each other through the communication bus 400; it will be apparent that the communication connection schematic shown in the processor 100, the communication interface 200, the memory 300 and the communication bus 400 shown in fig. 4 is only optional;
alternatively, the communication interface 200 may be an interface of a communication module, such as an interface of a GSM module;
the processor 100 may be a central processing unit CPU, or a specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of the present invention.
Memory 300 may comprise high-speed RAM memory or may further comprise non-volatile memory (non-volatile memory), such as at least one disk memory.
The processor 100 is specifically configured to:
acquiring failure data uploaded by a vehicle-mounted terminal through a wireless network;
determining a related party with abnormality based on the failure data;
analyzing the failure data to obtain analysis data;
performing data verification on the related party based on the analysis data to obtain a verification result;
transmitting the verification result to a software repair tool;
acquiring a repair strategy fed back by the software repair tool;
judging whether the repair strategy influences the driving function of the vehicle or not;
and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
The processor is further configured to perform the steps disclosed in the other method embodiments, and specific processes are not described in detail.
For convenience of description, the above system is described as being functionally divided into various modules, respectively. Of course, the functions of each module may be implemented in the same piece or pieces of software and/or hardware when implementing the present invention.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for a system or system embodiment, since it is substantially similar to a method embodiment, the description is relatively simple, with reference to the description of the method embodiment being made in part. The systems and system embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
It is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description of the disclosed embodiments, to enable any person skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A method for repairing a software failure of a vehicle, comprising:
acquiring failure data uploaded by a vehicle-mounted terminal through a wireless network;
determining a related party with abnormality based on the failure data;
analyzing the failure data to obtain analysis data;
performing data verification on the related party based on the analysis data to obtain a verification result;
transmitting the verification result to a software repair tool;
acquiring a repair strategy fed back by the software repair tool;
judging whether the repair strategy influences the driving function of the vehicle or not;
and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
2. The vehicle software fault repair method according to claim 1, wherein performing data verification on the relevant party based on the analysis data to obtain a verification result, comprising:
acquiring an inter-component interaction strategy and a dormancy wakeup strategy corresponding to the related party;
judging whether the related party accords with the inter-component interaction strategy or not based on the analysis data;
judging whether the sleep wake-up strategy is met in the use process of the related party based on the analysis data;
E2E algorithm verification is carried out on the related party based on the analysis data, and E2E verification results are obtained;
and carrying out SECOC algorithm verification on the related party based on the analysis data to obtain a SECOC verification result.
3. The vehicle software fault repair method according to claim 2, wherein the data verification is performed on the relevant party based on the analysis data, and a verification result is obtained, further comprising:
detecting the sending data of the related party to obtain a detection result;
detecting the received data of the related party to obtain a detection result;
and judging whether the transmission data between the related parties accords with a CAN/CANFD message data format or not based on the analysis data.
4. The vehicle software fault repair method of claim 1, further comprising, after sending the verification result to a software repair tool:
when feedback information which is fed back by the software repair tool and used for representing insufficient data is obtained, generating a data calling instruction for calling a vehicle whole part controller, and sending the data calling instruction to the vehicle-mounted terminal;
acquiring the data of a whole vehicle part controller fed back by the vehicle-mounted terminal in response to the data retrieval instruction;
and taking the data of the whole vehicle part controller and the acquired failure data as the failure data together, and determining a related party with abnormality based on the failure data and the follow-up steps in the executing step.
5. The vehicle software fault remediation method of claim 4, wherein after sending the verification result to a software remediation tool, further comprising:
when the software repair tool is detected to fail in repair, the failure data is sent to a target object;
and obtaining a repair strategy fed back by the target object, executing the step of judging whether the repair strategy influences the driving function of the vehicle, and the subsequent step.
6. The vehicle software fault remediation method of claim 1, wherein determining whether the remediation strategy affects vehicle driving functions includes:
judging whether the repair strategy affects the braking, starting, steering or headlight control system of the vehicle, and if so, indicating that the repair strategy affects the driving function of the vehicle.
7. The vehicle software fault remediation method of claim 1, wherein when the remediation strategy affects the vehicle's driving function, determining whether the vehicle is in a stationary state;
and when the vehicle is in a stationary state, feeding back the repair strategy to the vehicle-mounted terminal so that the vehicle-mounted terminal repairs the related software of the related party.
8. The vehicle software fault remediation method of claim 7, further comprising:
and when the vehicle is not in a stationary state, issuing a soft part repair request to the vehicle-mounted terminal so as to prompt a user to switch the vehicle to the stationary state.
9. A vehicle software fault remediation device, comprising:
the vehicle-mounted terminal interaction unit is used for acquiring failure data uploaded by the vehicle-mounted terminal;
a diagnostic analysis tool analysis unit for determining a relevant party to the occurrence of the abnormality based on the failure data; analyzing the failure data to obtain analysis data; performing data verification on the related party based on the analysis data to obtain a verification result; transmitting the verification result to a software repair tool in a software repair unit
The software repairing unit is used for acquiring a repairing strategy fed back by the software repairing tool; judging whether the repair strategy influences the driving function of the vehicle or not; and when the vehicle driving function is not affected, the repair strategy is fed back to the vehicle-mounted terminal, so that the vehicle-mounted terminal repairs the related software of the related party.
10. A cloud server, comprising: a memory and a processor;
the memory is used for storing programs;
the processor for executing the program to implement the respective steps of the vehicle software fault repair method as claimed in any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310424284.6A CN116450395A (en) | 2023-04-19 | 2023-04-19 | Vehicle software fault repairing method and device and cloud server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310424284.6A CN116450395A (en) | 2023-04-19 | 2023-04-19 | Vehicle software fault repairing method and device and cloud server |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116450395A true CN116450395A (en) | 2023-07-18 |
Family
ID=87127197
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310424284.6A Pending CN116450395A (en) | 2023-04-19 | 2023-04-19 | Vehicle software fault repairing method and device and cloud server |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116450395A (en) |
-
2023
- 2023-04-19 CN CN202310424284.6A patent/CN116450395A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111775864B (en) | Remote debugging method and system and vehicle | |
| EP4116787B1 (en) | Remote vehicle diagnostic and detection method based on instant messaging communication, electronic device, and storage medium | |
| JP2014201085A (en) | Vehicle data recording apparatus, and vehicle diagnosis system | |
| CN108919776B (en) | Fault assessment method and terminal | |
| Oka et al. | Shift left: Fuzzing earlier in the automotive software development lifecycle using hil systems | |
| CN112990495A (en) | Method, device and system for vehicle after-sale diagnosis and storage medium | |
| CN111527389A (en) | Vehicle diagnosis method, vehicle diagnosis device and storage medium | |
| CN114326672A (en) | ECU simulation detection method, electronic device and storage medium | |
| KR20100051080A (en) | Method and system for diagnosing a malfunction of an automobile | |
| CN116450395A (en) | Vehicle software fault repairing method and device and cloud server | |
| CN108153285A (en) | Automotive safety monitoring method, device, storage medium and system | |
| CN110659885A (en) | Vehicle annual inspection method and related equipment | |
| CN109828857A (en) | Vehicle trouble reason localization method, device, equipment and storage medium | |
| CN113657733A (en) | Method, device, equipment and storage medium for managing new automobile product problem points | |
| CN115220429A (en) | Fault diagnosis method, device, equipment and storage medium | |
| JPH09153924A (en) | Procedure error detection system for communication control system | |
| CN112346441A (en) | Automobile online diagnosis method and system and automobile diagnosis equipment | |
| JP6406388B2 (en) | Vehicle diagnostic system | |
| JP5341726B2 (en) | Vehicle diagnostic apparatus and vehicle diagnostic method | |
| WO2023103131A1 (en) | Method and device for detecting abnormal behavior, and storage medium and apparatus | |
| CN116088486B (en) | Diagnostic method and device for vehicle electric control system and vehicle diagnostic equipment | |
| CN106998352A (en) | A kind of pre- diagnostic method of automobile and server | |
| CN118746977A (en) | System and method for detecting and diagnosing vehicle functions in vehicle offline and vehicle | |
| CN115576305A (en) | Vehicle diagnosis method and apparatus with separated upper and lower bodies, and storage medium | |
| CN118466920A (en) | Sensor programming method, device, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |