CN117055533A - Vehicle-mounted system fault processing method, device, equipment and medium - Google Patents
Vehicle-mounted system fault processing method, device, equipment and medium Download PDFInfo
- Publication number
- CN117055533A CN117055533A CN202311203355.6A CN202311203355A CN117055533A CN 117055533 A CN117055533 A CN 117055533A CN 202311203355 A CN202311203355 A CN 202311203355A CN 117055533 A CN117055533 A CN 117055533A
- Authority
- CN
- China
- Prior art keywords
- fault
- detection object
- target detection
- detection
- state
- 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
- 238000003672 processing method Methods 0.000 title abstract description 8
- 238000001514 detection method Methods 0.000 claims abstract description 358
- 238000012545 processing Methods 0.000 claims abstract description 44
- 238000000034 method Methods 0.000 claims abstract description 41
- 230000007246 mechanism Effects 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 16
- 238000004891 communication Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 15
- 230000003993 interaction Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000007689 inspection Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000000243 solution Substances 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 2
- 238000001994 activation Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the invention discloses a vehicle-mounted system fault processing method, device, equipment and medium. Wherein the method comprises the following steps: acquiring the current working state of a vehicle-mounted system; determining a target detection object based on the current working state; performing fault detection on the target detection object to obtain fault parameters; processing the target detection object according to the fault parameters to obtain a processed target detection object; and returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met. According to the technical scheme, the safety and the high reliability of the vehicle-mounted system can be improved.
Description
Technical Field
The present invention relates to the field of vehicle technologies, and in particular, to a method, an apparatus, a device, and a medium for processing a vehicle-mounted system fault.
Background
The embedded system based on the microcontroller and the microprocessor is gradually widely applied in the field of automobile control, the embedded system is based on computer software and hardware technology, and the software and the hardware can be cut, so that the embedded system is suitable for a special computer system with strict requirements on functions, safety, cost, power consumption and the like of the application system.
The safety is the most critical measure index of the embedded system of the automobile, the existing large fault diagnosis system is an external instrument and is not provided with an embedded device in the automobile, so that when a large automobile fault occurs, the automobile needs to be moved to a professional detection point for detection, the repairing time of the automobile is too long, and the embedded safety and high reliability problems of the automobile are not solved conveniently
Disclosure of Invention
The invention provides a vehicle-mounted system fault processing method, device, equipment and medium, which can improve the safety and high reliability of a vehicle-mounted system.
According to an aspect of the present invention, there is provided a vehicle-mounted system fault handling method, including:
acquiring the current working state of a vehicle-mounted system;
determining a target detection object based on the current working state;
performing fault detection on the target detection object to obtain fault parameters;
processing the target detection object according to the fault parameters to obtain a processed target detection object;
and returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met.
Optionally, the target detection object includes a first class detection object and a second class detection object;
Correspondingly, determining the target detection object based on the current working state comprises the following steps:
if the current working state is the starting state, the first class detection object is taken as a target detection object;
and if the current working state is the running state, taking the second-class detection object as a target detection object.
Optionally, performing fault detection on the target detection object includes:
acquiring a safety setting condition of the target detection object;
judging whether the target detection object meets the corresponding safety setting condition or not;
and if the target detection object does not meet the safety setting condition, the target detection object fails.
Optionally, the first class detection object includes at least one of compatibility detection, power supply state detection, hardware state detection, memory detection, and failure mechanism detection; the second class detection object includes at least one of power supply state detection, fault detection, register detection, operating system state detection, input or output signal state detection, and program running state detection.
Optionally, the fault parameters include a fault type and a reset number.
Optionally, processing the target detection object according to the fault parameter includes:
When the fault type is a hardware fault type, performing system reset processing on the corresponding target detection object;
and when the fault type is a software fault type, performing software reset processing on the corresponding target detection object.
Optionally, the method further comprises:
and if the reset times are larger than a set threshold value, executing a corresponding limp mode.
According to another aspect of the present invention, there is provided an in-vehicle system failure processing apparatus including:
the working state acquisition module is used for acquiring the current working state of the vehicle-mounted system;
the target detection object determining module is used for determining a target detection object based on the current working state;
the fault parameter obtaining module is used for carrying out fault detection on the target detection object to obtain fault parameters;
the processing module is used for processing the target detection object according to the fault parameters to obtain a processed target detection object;
and the fault detection return execution module is used for returning to execute the fault detection operation on the processed target detection object until the fault detection ending condition is met.
According to another aspect of the present invention, there is provided an electronic apparatus including:
At least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the vehicle-mounted system fault handling method according to any one of the embodiments of the present invention.
According to another aspect of the present invention, there is provided a computer readable storage medium storing computer instructions for causing a processor to execute the method for processing a vehicle-mounted system fault according to any one of the embodiments of the present invention.
According to the technical scheme, the current working state of the vehicle-mounted system is obtained; determining a target detection object based on the current working state; performing fault detection on the target detection object to obtain fault parameters; processing the target detection object according to the fault parameters to obtain a processed target detection object; and returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met. According to the technical scheme, the safety and the high reliability of the vehicle-mounted system of the automobile can be improved.
It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the invention or to delineate the scope of the invention. Other features of the present invention will become apparent from the description that follows.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of a method for handling a vehicle-mounted system fault according to a first embodiment of the present invention;
fig. 2 is a flowchart of a method for processing a failure of a vehicle-mounted system according to a second embodiment of the present invention;
fig. 3 is a schematic structural diagram of a fault handling device for an on-vehicle system according to a third embodiment of the present invention;
fig. 4 is a schematic structural diagram of an electronic device according to a fourth embodiment of the present invention.
Detailed Description
In order that those skilled in the art will better understand the present invention, a technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.
It should be noted that the terms "first," "second," "target," and the like in the description and claims of the present invention and in the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
Example 1
Fig. 1 is a flowchart of a vehicle-mounted system fault handling method according to a first embodiment of the present invention, where the method may be implemented by a vehicle-mounted system fault handling device, and the vehicle-mounted system fault handling device may be implemented in hardware and/or software, and the vehicle-mounted system fault handling device may be configured in an electronic device with data processing capability. As shown in fig. 1, the method includes:
The in-vehicle system in this embodiment may be an embedded system of a vehicle. The embodiment can detect objects such as the embedded kernel, the key register, the operating system, the key input signal, the memory and the like in real time aiming at the safety of the automobile embedded system, and provides a fault processing method and classified storage of faults, so that the safety of the automobile embedded system is improved.
S110, acquiring the current working state of the vehicle-mounted system.
The in-vehicle system may be an embedded system of the vehicle. The embedded system may be composed of hardware and software; specifically, the software content only includes the software running environment and the operating system thereof, and the hardware content can include various contents including a signal processor, a memory, a communication module and the like. The operating state may include a start state and an operating state of the vehicle-mounted system, and may be other operating states. In this embodiment, the current working state of the embedded system of the vehicle may be obtained.
S120, determining a target detection object based on the current working state.
The target detection object may be understood as an object to be detected. In this embodiment, the target detection object is determined based on the current working state, and specifically, different target detection objects may be determined according to different current working states.
After the vehicle-mounted system is powered on, the vehicle-mounted system can enter an initialization program, different objects of safety detection in different system working states are respectively set, and corresponding information such as safety detection parameters, fault processing parameters and the like is configured, so that the system enters the safety detection work of the current working state.
In this embodiment, optionally, the target detection object includes a first class detection object and a second class detection object; correspondingly, determining the target detection object based on the current working state comprises the following steps: if the current working state is the starting state, taking the first class detection object as a target detection object; and if the current working state is the running state, taking the second-class detection object as a target detection object.
The target detection objects can be divided into a first class detection object and a second class detection object according to different working states. In this embodiment, if the current working state is the start state, the first class detection object may be used as the target detection object; if the current working state is the running state, the second-class detection object can be used as the target detection object. In addition, in this embodiment, if the current working state is the running state, the period may be set to detect the second-class detection object. By the arrangement, specific different detection objects can be determined based on the working state of the vehicle-mounted system, so that the power consumption of the system is reduced, and the safety of the system is improved.
In this embodiment, optionally, the first class detection object includes at least one of compatibility detection, power supply state detection, hardware state detection, memory detection, and failure mechanism detection; the second class detection object includes at least one of power supply state detection, fault detection, register detection, operating system state detection, input or output signal state detection, and program running state detection.
The compatibility detection may be understood as a detection of compatibility before hardware and software in the system or compatibility before data software and a program, and may also include other compatibility detection, and may be set according to actual requirements. The power supply state detection can be understood as detecting the power supply state in the system, and can be undervoltage and/or overvoltage power supply, overcurrent power supply detection and the like of the embedded system. Hardware state detection may be understood as state detection of a drive path of a hardware circuit in a system. Hardware state detection may include control path checking involving power driving, shutdown path checking, and so forth. Memory inspection may be understood as inspecting the integrity of memory areas in a system. The memory detection in this embodiment may include integrity detection of the contents of the program area, the RAM area, and the EEPROM area. Fault mechanism detection may be understood as detecting a fault mechanism of a microcontroller chip core within an embedded system. In this embodiment, a software fault checking mechanism may be designed according to the characteristics of the MCU chip.
The fault mechanism detection may include detecting whether the fault mechanism is normal or not for a phase-locked loop, a bus state, an instruction access, a data access, and the like. The fault detection may be to detect a fault of a micro control chip in the embedded system and determine whether a core of the micro control chip has a fault. The fault detection in this embodiment may specifically include a phase-locked loop fault, a bus fault, an instruction fault, a data access fault, and the like. Register detection may be understood as detecting a specified register in a system. In this embodiment, a specified register in the system may be detected. The specified registers in this embodiment may include registers such as a system control, security module, and peripheral module. The operating system state detection may be detecting an operating state of the system. The operating system detection in this embodiment may include detection of system stack and operating system failure. The input or output signal state detection may be an input signal or output information state detection of the system. The input information state detection in this embodiment may include setting signals such as the range of the AD analog quantity and the redundant AD value for detection and verification. The output signal state detection may include detection of output value states including set key IO and PWM driving. Program running state detection may be to detect the execution sequence and execution time of a program. In this embodiment, the program of the important control function may be encoded, and the software detects the execution sequence and execution time of the program according to the execution sequence of the encoding detection program.
Further, the second class detection object in this embodiment may further include a specified memory information detection, a communication state detection, and the like. The specified memory information detection may be a detection of the memory information of the MCU, where the detection may be a detection of only the memory information of the set important area, and may be a detection of the memory including the parameters related to the function or performance of the control object. The communication state detection may be detection of a communication message currently running in the system.
Through such setting, the embodiment can detect different objects by dividing into the first class detection object and the second class detection object, and flexibly set the corresponding safety detection objects under different working states, thereby being more convenient and faster.
S130, performing fault detection on the target detection object to obtain fault parameters.
The fault detection is understood as detection of detecting a target detection object to determine whether a fault occurs. The failure parameter may be understood as an information parameter when the target detection object fails. In this embodiment, optionally, the fault parameters include a fault type and a reset number. The fault type may be understood as the type of the current target detection object. Specifically, the fault types of the present embodiment may be hardware faults and software faults. The number of resets may be the number of times the current target detection object performs a reset operation. In this embodiment, respective security setting conditions may be set for the target detection object, and if the target detection object does not meet the corresponding security setting conditions, corresponding fault parameter information may be obtained.
And S140, processing the target detection object according to the fault parameters to obtain the processed target detection object.
The processed target detection object may be a detection object obtained by detecting the processed target detection object based on the fault parameter. In this embodiment, the target detection object may be processed according to the fault type and the number of resets in the fault parameter, so as to obtain the processed target detection object.
And S150, returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met.
The fault detection end condition may be preset. The failure detection end condition in the present embodiment is set according to the actual demand. For example, the failure detection condition may be that the target detection object function is not functioning properly. The present embodiment may return the operation of performing the fault detection on the processed target detection object until the preset fault detection condition is satisfied.
According to the technical scheme, the current working state of the vehicle-mounted system is obtained; determining a target detection object based on the current working state; performing fault detection on the target detection object to obtain fault parameters; processing the target detection object according to the fault parameters to obtain a processed target detection object; and returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met. According to the technical scheme, the safety and the high reliability of the vehicle-mounted system of the automobile can be improved.
Example two
Fig. 2 is a flowchart of a vehicle-mounted system fault handling method according to a second embodiment of the present invention, which is optimized based on the above embodiment. The concrete optimization is as follows: performing fault detection on the target detection object, including: acquiring a safety setting condition of a target detection object; judging whether the target detection object meets the corresponding safety setting condition or not; if the target detection object does not meet the safety setting condition, the target detection object fails. As shown in fig. 2, the method includes:
s210, acquiring the current working state of the vehicle-mounted system.
S220, determining a target detection object based on the current working state.
S230, acquiring the safety setting condition of the target detection object.
The security setting condition may be a condition set for the target detection object. The safety setting conditions in this embodiment may be preset, and may be set according to actual requirements. The security setting conditions of the respective target detection objects in this embodiment are different. The security setting condition may be a condition that a setting threshold is satisfied or an algorithm check is satisfied. In this embodiment, whether the target detection object fails or not can be determined by the security setting condition. The present embodiment can acquire the security setting condition of the target detection object.
S240, judging whether the target detection object meets the corresponding safety setting condition.
In this embodiment, whether the target detection object meets the corresponding preset security setting condition may be determined.
S250, if the target detection object does not meet the safety setting condition, the target detection object fails to obtain a failure parameter.
In this embodiment, if the target detection object does not meet the corresponding security setting condition, it may be indicated that the target detection object fails, so as to obtain the corresponding failure parameters such as the failure type and the number of resets.
Specifically, the target detection object in the present embodiment may include a first class detection object and a second class detection object. The first class detection object comprises at least one of compatibility detection, power supply state detection, hardware state detection, memory detection and fault mechanism detection; the second class detection object includes at least one of power supply state detection, fault detection, register detection, operating system state detection, input or output signal state detection, and program running state detection.
In this embodiment, when the system operating state is the start stage and the target detection object is compatibility detection, the safety setting condition may be that compatibility detection is satisfied; if the compatibility check of the hardware equipment and the driving software in the system and the compatibility check of the program and data software version do not meet the compatibility detection, the corresponding fault parameters and fault codes are recorded when the compatibility fault is described. When the target detection object is a power supply state detection object, the safety setting condition of the target detection object can be set to set a set threshold range of power supply voltage and current; when the detected power supply voltage or current exceeds the set threshold range, the current power supply state is detected to have faults, and corresponding fault parameters and fault codes are recorded. When the target detection object is hardware state detection, the safety setting condition of the target detection object can be a control and/or enabling circuit of power driving and check the state of the power driving to reach an expected result; and when the hardware state is detected to not reach the expected result, indicating that the current hardware state is detected to have faults, recording corresponding fault parameters and fault codes. When the target detection object is memory detection, the security setting condition can be content integrity check of the appointed memory region; such as integrity checking of the contents of the program area, RAM area, and EEPROM area. The checking method can adopt CRC algorithm, hash and encryption algorithm. In this embodiment, when the integrity check of the designated memory area is detected to be failed, it is indicated that the memory detection fails, and the corresponding failure parameter and failure code are recorded. When the target detection object is fault mechanism detection, the safety setting condition can be that fault injection test is passed; in this embodiment, fault injection test may be performed on inspection items such as phase-locked loop, bus state, instruction access, and data access, and if a corresponding fault is detected, it is confirmed that the fault mechanism is normal; otherwise, the fault mechanism is abnormal, the fault mechanism is indicated to detect the occurrence of faults, and corresponding fault parameters and fault codes are recorded.
In this embodiment, when the system operating state is an operation stage and the target detection object is a power supply state detection, the safety setting condition may be set to a set threshold range for setting the power supply voltage and current; when the detected power supply voltage or current exceeds the set threshold range, the current power supply state is detected to have faults, and corresponding fault parameters and fault codes are recorded. When the target detection object is fault detection, the safety setting condition can be set to be in line with the software checking mechanism. In this embodiment, a software inspection mechanism may be designed according to the characteristics of the MCU chip. Specifically, in this embodiment, a software inspection mechanism may be designed according to the characteristics of the MCU chip, to detect whether the phase-locked loop, the bus, the instruction, the data access, and the like meet the security setting condition, and if the security setting condition is not met, it is indicated that the corresponding inspection item fails, and corresponding failure parameters and failure codes are recorded. When the target detection object is register detection, the security setting condition may be that the actual value of the register is consistent with the set value. In this embodiment, different values are set for each register based on the register difference. In this embodiment, the actual values of the registers such as the system control, the security module, and the peripheral module may be read, the detected actual values are compared with the set values, and when the actual values are inconsistent with the default values, it is indicated that the security setting conditions are not satisfied, and corresponding fault parameters and fault codes are recorded.
In this embodiment, when the target detection object is an operating system status detection, it may include a basic fault to the system stack and the operating system. In this embodiment, if the system stack is detected, the security setting condition may be that the usage rate is less than or equal to the set threshold; the set threshold may be 60% by way of example. When the system stack utilization rate is detected to be larger than a set threshold value, corresponding fault parameters and fault codes are recorded; when the system stack utilization rate is detected to be more than 100%, namely the stack overflow fault occurs, corresponding fault parameters and fault codes are recorded. In this embodiment, when detecting basic information of an operating system, by setting attributes such as time, activation, and resource access of a task of the operating system, when detecting faults such as task timeout, multiple activations, task loss, and resource deadlock, corresponding fault parameters and fault codes are recorded.
In this embodiment, when the target detection object is input or output signal state detection, the security setting condition for the input signal state detection may be that the set data range is satisfied. The input signal state detection in this embodiment may include range checking of AD analog quantity and/or redundant AD value verification, etc. When detecting that the AD analog quantity is larger than the set data range and/or the redundant AD value is checked to be wrong, the input signal state detection fault is indicated, and corresponding fault parameters and fault codes are recorded. For the output signal state detection, the safety setting condition may be a state in which the setting correspondence is satisfied. The output signal state detection in this embodiment may include IO and/or PWM drive output value states; the software in this embodiment can determine the output state by: firstly, the set value of the corresponding driving register can be read; second, the feedback signal driven by the MCU can be read; thirdly, the feedback signal output by the embedded system can be read, when the output state is detected to be not in accordance with the state corresponding to the setting, the output state is detected to have faults, and corresponding fault parameters and fault codes are recorded. In this embodiment, when the target detection object is the program running state detection, the safety setting condition may be that the set execution sequence and the set time threshold are met. The set time threshold may be 10 milliseconds, for example, and may be set according to actual conditions. The detection of the running state of the program in this embodiment may be detection of the execution sequence and/or execution time of the program. In this embodiment, the program for setting the control function is encoded, and when the software detects that the execution sequence does not conform to the set execution sequence and/or the execution time exceeds the set time threshold according to the execution sequence of the encoding detection program, it indicates that the safety setting condition is not satisfied, the program running state detects that a fault occurs, and the corresponding fault parameter and fault code are recorded.
In addition, in this embodiment, the system communication state may be detected by checking with an algorithm that satisfies the functional security standard, and when the communication packet is abnormal, the communication state fault is described, and the fault parameter is recorded.
By the arrangement, different safety setting conditions can be set for different target detection objects so as to record fault parameters when faults occur, and therefore safety of the automobile embedded system is improved.
And S260, processing the target detection object according to the fault parameters to obtain the processed target detection object.
In this embodiment, optionally, processing the target detection object according to the fault parameter includes: when the fault type is a hardware fault type, performing system reset processing on the corresponding target detection object; and when the fault type is the software fault type, performing software reset processing on the corresponding target detection object.
The system reset process can be understood as the complete reset of the hardware corresponding circuits and software. In this embodiment, when the fault type of the target detection object is detected to be a hardware fault type, all hardware corresponding circuits and software are reset for the corresponding target detection object; when the fault type of the target detection object is detected to be the software fault type, performing software reset processing on the corresponding target detection object. By the arrangement, different reset processing can be performed aiming at different fault types, flexible processing is achieved, and the processing efficiency of the system is improved.
The fault parameters in this embodiment may include stored information at the time of the fault and environmental information of the corresponding CPU at the time of the fault. The storage information when the fault occurs specifically comprises a CPU with the fault, a fault type, fault reason fault times and reset times; the context information of the corresponding CPU when the fault occurs includes context instruction information, call stack conditions, register information, and the like.
In this embodiment, when it is detected that the target detection object fails, parameters such as a failure code and failure times are recorded and stored, and then the failure function is reinitialized, and then the safety detection is continued. In this embodiment, after the fault function is reinitialized, when a related fault is still detected, the fault code, the fault frequency, the reset frequency and the like are recorded and stored.
In this embodiment, optionally, the method further includes: and if the reset times are larger than the set threshold, executing the corresponding limp mode.
The set threshold may be preset, and may be set according to actual requirements. The set threshold in this embodiment may be 8 times. The limp-home mode is a running mode when an electronic control unit in an automobile ECU malfunctions. The limp mode in this embodiment may be divided into two levels, the first level being a limit system portion control function; the second level is to limit the overall functionality. Different set thresholds may be set for the two levels of the limp mode in this embodiment.
In this embodiment, if the number of resets of the target detection object recorded in the fault parameter is greater than the set threshold, a corresponding limp-home function mode is executed. After the embedded system is reset in the embodiment, the system reset counter is accumulated, and when the reset times exceed the set threshold, the function faults determine the limp modes of different grades. The set threshold value of the reset times of the present embodiment sets different threshold values according to the target detection object. When the functional failure of the system is determined, the system enters a limp control mode, and the limp function is classified into a first class as a forbidden part control function according to the classification of safety monitoring; the second level is to disable all functions.
By the arrangement, the corresponding limp mode can be executed according to the reset times, and the safety of the automobile embedded system is further improved.
And S270, returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met.
In addition, the vehicle-mounted embedded system in the embodiment can be composed of a detection and processing subsystem, a man-machine interaction subsystem and an output unit. The detection and processing subsystem comprises an initialization unit, a safety monitoring unit, a fault processing unit, a control unit, a storage unit and a computer device thereof. In this embodiment, the history fault information may be read through a man-machine interaction system, so as to locate and solve a software fault. The man-machine interaction system comprises equipment based on XCP and equipment based on UDS, and the communication bus form of the man-machine interaction system comprises CAN, ethernet and the like.
According to the technical scheme, the current working state of the vehicle-mounted system is obtained; determining a target detection object based on the current working state; acquiring a safety setting condition of a target detection object; judging whether the target detection object meets the corresponding safety setting condition or not; if the target detection object does not meet the safety setting condition, the target detection object fails to obtain failure parameters; processing the target detection object according to the fault parameters to obtain a processed target detection object; and returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met. According to the technical scheme, the safety and the high reliability of the vehicle-mounted system of the automobile can be improved.
Example III
Fig. 3 is a schematic structural diagram of a fault handling device for an on-vehicle system according to a third embodiment of the present invention. As shown in fig. 3, the apparatus includes:
the working state obtaining module 310 is configured to obtain a current working state of the vehicle-mounted system.
The target detection object determining module 320 is configured to determine a target detection object based on the current working state.
The fault parameter obtaining module 330 is configured to perform fault detection on the target detection object to obtain a fault parameter.
And the processing module 340 is configured to process the target detection object according to the fault parameter, so as to obtain a processed target detection object.
The fault detection return execution module 350 is configured to return an operation of performing fault detection on the processed target detection object until a fault detection end condition is satisfied.
Optionally, the target detection object includes a first class detection object and a second class detection object;
correspondingly, the target detection object determining module 320 is specifically configured to take the first type of detection object as the target detection object if the current working state is the start state; and if the current working state is the running state, taking the second-class detection object as a target detection object.
Optionally, the fault parameter obtaining module 330 is specifically configured to obtain a security setting condition of the target detection object; judging whether the target detection object meets the corresponding safety setting condition or not; if the target detection object does not meet the safety setting condition, the target detection object fails.
Optionally, the first class detection object includes at least one of compatibility detection, power supply state detection, hardware state detection, memory detection, and failure mechanism detection; the second class detection object includes at least one of power supply state detection, fault detection, register detection, operating system state detection, input or output signal state detection, and program running state detection.
Optionally, the fault parameters include a fault type and a number of resets.
Optionally, the processing module 340 is specifically configured to perform a system reset process on the corresponding target detection object when the fault type is a hardware fault type; and when the fault type is the software fault type, performing software reset processing on the corresponding target detection object.
Optionally, the apparatus further comprises: and the limp execution module is used for executing a corresponding limp mode if the reset times are greater than the set threshold.
The vehicle-mounted system fault processing device provided by the embodiment of the invention can execute the vehicle-mounted system fault processing method provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.
Example IV
Fig. 4 is a schematic structural diagram of an electronic device according to a fourth embodiment of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. Electronic equipment may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed herein.
As shown in fig. 4, the electronic device 10 includes at least one processor 11, and a memory, such as a Read Only Memory (ROM) 12, a Random Access Memory (RAM) 13, etc., communicatively connected to the at least one processor 11, in which the memory stores a computer program executable by the at least one processor, and the processor 11 may perform various appropriate actions and processes according to the computer program stored in the Read Only Memory (ROM) 12 or the computer program loaded from the storage unit 18 into the Random Access Memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 may also be stored. The processor 11, the ROM 12 and the RAM 13 are connected to each other via a bus 14. An input/output (I/O) interface 15 is also connected to bus 14.
Various components in the electronic device 10 are connected to the I/O interface 15, including: an input unit 16 such as a keyboard, a mouse, etc.; an output unit 17 such as various types of displays, speakers, and the like; a storage unit 18 such as a magnetic disk, an optical disk, or the like; and a communication unit 19 such as a network card, modem, wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.
The processor 11 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various processors running machine learning model algorithms, digital Signal Processors (DSPs), and any suitable processor, controller, microcontroller, etc. The processor 11 performs the respective methods and processes described above, such as the in-vehicle system failure processing method.
In some embodiments, the on-board system fault handling method may be implemented as a computer program tangibly embodied on a computer readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 10 via the ROM 12 and/or the communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the above-described in-vehicle system failure processing method may be performed. Alternatively, in other embodiments, the processor 11 may be configured to perform the on-board system fault handling method in any other suitable manner (e.g., by means of firmware).
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.
A computer program for carrying out methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be implemented. The computer program may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of the present invention, a computer-readable storage medium may be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer readable storage medium may be a machine readable signal medium. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) through which a user can provide input to the electronic device. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), blockchain networks, and the internet.
The computing system may include clients and servers. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical hosts and VPS service are overcome.
It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present invention may be performed in parallel, sequentially, or in a different order, so long as the desired results of the technical solution of the present invention are achieved, and the present invention is not limited herein.
The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.
Claims (10)
1. A vehicle-mounted system fault handling method, comprising:
acquiring the current working state of a vehicle-mounted system;
determining a target detection object based on the current working state;
performing fault detection on the target detection object to obtain fault parameters;
processing the target detection object according to the fault parameters to obtain a processed target detection object;
and returning to the operation of executing fault detection on the processed target detection object until the fault detection ending condition is met.
2. The method of claim 1, wherein the target detection object comprises a first class detection object and a second class detection object;
correspondingly, determining the target detection object based on the current working state comprises the following steps:
if the current working state is the starting state, the first class detection object is taken as a target detection object;
and if the current working state is the running state, taking the second-class detection object as a target detection object.
3. The method according to claim 1, wherein performing fault detection on the target detection object comprises:
acquiring a safety setting condition of the target detection object;
judging whether the target detection object meets the corresponding safety setting condition or not;
and if the target detection object does not meet the safety setting condition, the target detection object fails.
4. The method of claim 2, wherein the first class detection object comprises at least one of compatibility detection, power state detection, hardware state detection, memory detection, and failure mechanism detection; the second class detection object includes at least one of power supply state detection, fault detection, register detection, operating system state detection, input or output signal state detection, and program running state detection.
5. The method of claim 1, wherein the fault parameters include fault type and number of resets.
6. The method of claim 5, wherein processing the target detection object according to the fault parameter comprises:
when the fault type is a hardware fault type, performing system reset processing on the corresponding target detection object;
and when the fault type is a software fault type, performing software reset processing on the corresponding target detection object.
7. The method as recited in claim 5, further comprising:
and if the reset times are larger than a set threshold value, executing a corresponding limp mode.
8. A vehicle-mounted system fault handling device, characterized by comprising:
the working state acquisition module is used for acquiring the current working state of the vehicle-mounted system;
the target detection object determining module is used for determining a target detection object based on the current working state;
the fault parameter obtaining module is used for carrying out fault detection on the target detection object to obtain fault parameters;
the processing module is used for processing the target detection object according to the fault parameters to obtain a processed target detection object;
And the fault detection return execution module is used for returning to execute the fault detection operation on the processed target detection object until the fault detection ending condition is met.
9. An electronic device, the electronic device comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores a computer program executable by the at least one processor to enable the at least one processor to perform the in-vehicle system fault handling method of any one of claims 1-7.
10. A computer readable storage medium storing computer instructions for causing a processor to implement the method for handling a vehicle-mounted system failure of any one of claims 1-7 when executed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311203355.6A CN117055533A (en) | 2023-09-18 | 2023-09-18 | Vehicle-mounted system fault processing method, device, equipment and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311203355.6A CN117055533A (en) | 2023-09-18 | 2023-09-18 | Vehicle-mounted system fault processing method, device, equipment and medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117055533A true CN117055533A (en) | 2023-11-14 |
Family
ID=88653744
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311203355.6A Pending CN117055533A (en) | 2023-09-18 | 2023-09-18 | Vehicle-mounted system fault processing method, device, equipment and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117055533A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117743012A (en) * | 2023-12-21 | 2024-03-22 | 一汽解放汽车有限公司 | Processing system and method for chip failure, electronic equipment and storage medium |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090030587A1 (en) * | 2007-07-27 | 2009-01-29 | Mitsubishi Electric Corporation | Vehicle-mounted engine control apparatus |
| CN107323433A (en) * | 2017-06-28 | 2017-11-07 | 奇瑞汽车股份有限公司 | Fault detect method for maintaining, device and the storage medium of vehicle |
| CN107380170A (en) * | 2017-06-12 | 2017-11-24 | 中国第汽车股份有限公司 | Motor vehicle driven by mixed power engine condition monitoring and fault handling method |
| CN108091129A (en) * | 2018-01-12 | 2018-05-29 | 北京摩拜科技有限公司 | Vehicle trouble processing method, server, detection device and Vehicular system |
| WO2020024743A1 (en) * | 2018-07-28 | 2020-02-06 | 上海商汤智能科技有限公司 | Smart driving control method and device, vehicle, electronic apparatus, medium, and product |
| CN114858480A (en) * | 2022-05-20 | 2022-08-05 | 中国第一汽车股份有限公司 | Component fault early warning method, device, equipment and medium applied to vehicle |
| CN115774858A (en) * | 2022-11-29 | 2023-03-10 | 中国第一汽车股份有限公司 | Fault processing method and device, electronic equipment and storage medium |
-
2023
- 2023-09-18 CN CN202311203355.6A patent/CN117055533A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090030587A1 (en) * | 2007-07-27 | 2009-01-29 | Mitsubishi Electric Corporation | Vehicle-mounted engine control apparatus |
| CN107380170A (en) * | 2017-06-12 | 2017-11-24 | 中国第汽车股份有限公司 | Motor vehicle driven by mixed power engine condition monitoring and fault handling method |
| CN107323433A (en) * | 2017-06-28 | 2017-11-07 | 奇瑞汽车股份有限公司 | Fault detect method for maintaining, device and the storage medium of vehicle |
| CN108091129A (en) * | 2018-01-12 | 2018-05-29 | 北京摩拜科技有限公司 | Vehicle trouble processing method, server, detection device and Vehicular system |
| WO2020024743A1 (en) * | 2018-07-28 | 2020-02-06 | 上海商汤智能科技有限公司 | Smart driving control method and device, vehicle, electronic apparatus, medium, and product |
| CN114858480A (en) * | 2022-05-20 | 2022-08-05 | 中国第一汽车股份有限公司 | Component fault early warning method, device, equipment and medium applied to vehicle |
| CN115774858A (en) * | 2022-11-29 | 2023-03-10 | 中国第一汽车股份有限公司 | Fault processing method and device, electronic equipment and storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117743012A (en) * | 2023-12-21 | 2024-03-22 | 一汽解放汽车有限公司 | Processing system and method for chip failure, electronic equipment and storage medium |
| CN117743012B (en) * | 2023-12-21 | 2024-11-26 | 一汽解放汽车有限公司 | Chip failure processing system, method, electronic device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112882796B (en) | Abnormal root cause analysis method and device and storage medium | |
| CN108872762B (en) | Electronic equipment leakage detection method and device, electronic equipment and storage medium | |
| CN104636221A (en) | Method and device for processing computer system fault | |
| CN108255728A (en) | The recognition methods of the failure mode of software and device | |
| CN107590042A (en) | A kind of server method for testing open/close machine and system based on linux system | |
| CN116907727B (en) | Method and device for detecting fault of pressure sensor before vortex, vehicle and storage medium | |
| CN117055533A (en) | Vehicle-mounted system fault processing method, device, equipment and medium | |
| CN112199642B (en) | Detection method for anti-debugging of android system, mobile terminal and storage medium | |
| CN117743012B (en) | Chip failure processing system, method, electronic device and storage medium | |
| CN117707112B (en) | Fault diagnosis method, system, equipment and storage medium | |
| CN109254898B (en) | Software module execution sequence monitoring method and system | |
| CN109726080B (en) | Method and device for monitoring working state of heterogeneous computing system | |
| CN116541201A (en) | Configuration verification method and device for register, vehicle and storage medium | |
| CN116361047A (en) | Code verification method, device, equipment and storage medium | |
| CN116627665A (en) | Bus deadlock recovery method, device, equipment and storage medium | |
| CN116300800A (en) | Signal verification method and device, vehicle and storage medium | |
| CN112231710B (en) | QNX BSP startup verification method and startup verification module | |
| CN115098224A (en) | A kind of cluster service process exception processing method, device and medium thereof | |
| CN116001705B (en) | Vehicle data monitoring method, device, equipment and storage medium | |
| CN118377644B (en) | A method and system for rapidly improving CPU fault diagnosis based on FPGA | |
| CN101546280B (en) | Time sequence logic circuit state monitor and method | |
| CN117290149B (en) | Method, device, equipment, system and medium for positioning reset fault of main control module | |
| CN117313072A (en) | Sequence number management method, device, consumable chip and medium | |
| CN118963861A (en) | A computer restart method, device, equipment and medium | |
| CN115757031A (en) | Application process processing 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 |