Fault data acquisition method, fault diagnosis method, equipment, medium and product

Abstract

The invention provides a fault data acquisition method, which comprises the steps that a monitoring unit predicts the fault type of a fault to be generated by an embedding unit based on real-time monitoring data by using a fault prediction model, and the fault prediction model is a pre-trained model for predicting the fault type, the monitoring unit is a device for performing parameter configuration on the embedding unit; the monitoring unit determines target configuration parameters of the embedded unit according to the fault type, wherein the target configuration parameters are parameters of fault data collected by the embedded unit; and the embedding unit collects target fault data corresponding to the fault based on the target configuration parameter. The invention further provides a fault diagnosis method and device, a medium and a product.

Description

Technical Field

[0001] The present disclosure relates to the field of electronic technology, and in particular to a fault data collection method, a fault diagnosis method, a device, a medium, and a product. Background Art

[0002] Embedded units (such as power conversion equipment) are characterized by limited hardware resources, high real-time requirements, and a wide variety of fault types. Due to their limited hardware resources, embedded units lack the ability to store historical data. Therefore, fault data is typically collected by monitoring units. However, embedded units are high-frequency devices, and faults occur very quickly. Monitoring units are low-frequency devices, and the frequency of fault data collection and storage is low. Consequently, critical data at the moment of fault occurrence cannot be collected, which adversely affects fault reproduction and analysis. Summary of the Invention

[0003] The present disclosure provides a fault data collection method, a fault diagnosis method, a device, a medium, and a product.

[0004] In a first aspect, an embodiment of the present disclosure provides a fault data collection method, comprising:

[0005] The monitoring unit uses a fault prediction model to predict the type of fault that will occur in the embedded unit based on real-time monitoring data. The fault prediction model is a pre-trained model for predicting the type of fault. The monitoring unit is a device for configuring parameters of the embedded unit.

[0006] The monitoring unit determines the target configuration parameters of the embedded unit according to the fault type, and configures the acquisition parameters of the embedded unit to the target configuration parameters, wherein there is a corresponding relationship between the fault type and the acquisition parameters, and the target configuration parameters are the parameters for the embedded unit to collect fault data;

[0007] The embedded unit collects target fault data corresponding to the fault based on the target configuration parameters.

[0008] In a second aspect, an embodiment of the present disclosure provides a fault diagnosis method, including:

[0009] Acquire target fault data, where the target fault data is obtained using the fault data acquisition method provided by an embodiment of the present disclosure;

[0010] The target fault data is analyzed to determine the cause and location of the fault.

[0011] In a third aspect, an embodiment of the present disclosure provides an electronic device comprising a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements any one of the fault data collection methods or the fault diagnosis methods provided in the embodiments of the present disclosure.

[0012] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, it implements any one of the fault data collection methods or the fault diagnosis methods provided in the embodiments of the present disclosure.

[0013] In a fifth aspect, an embodiment of the present disclosure provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements any one of the fault data collection methods or fault diagnosis methods provided in the embodiments of the present disclosure.

[0014] The fault data collection method provided by the embodiment of the present disclosure uses a fault prediction model to predict the type of fault that will occur in the embedded unit based on real-time monitoring data, and determines the target configuration parameters of the embedded unit based on the fault type. The embedded unit collects target fault data corresponding to the fault based on the target configuration parameters, that is, the embedded unit collects fault data in a targeted manner according to its own high frequency, thereby being able to obtain the original data in real time with high accuracy. Therefore, it is possible to restore and reproduce the fault scene, and the amount of target fault data collected is small, without the need for additional hardware resources, and is suitable for embedded units with limited hardware resources. In addition, the fault prediction model is used to predict the impending fault, and the embedded unit parameters are actively configured according to the fault type, which is highly flexible. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In the accompanying drawings of the embodiments of the present disclosure:

[0016] Figure 1 This is an application scenario diagram for fault analysis in related technologies;

[0017] Figure 2 This is an application scenario diagram of the fault data collection method provided by an embodiment of the present disclosure;

[0018] Figure 3 A flowchart of a fault data collection method provided by an embodiment of the present disclosure;

[0019] Figure 4 This is a flow chart of parameter configuration for the embedded unit in an embodiment of the present disclosure;

[0020] Figure 5 This is a flowchart of uploading the first frame in an embodiment of the present disclosure;

[0021] Figure 6 This is a flowchart of uploading target fault data in an embodiment of the present disclosure;

[0022] Figure 7 This is a flowchart of the storage waiting of the first frame in the embodiment of the present disclosure;

[0023] Figure 8 A flowchart of a fault diagnosis method provided by an embodiment of the present disclosure;

[0024] Figure 9 A block diagram of an electronic device provided by an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0026] The present disclosure will be described more fully hereinafter with reference to the accompanying drawings, but the illustrated embodiments may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that the present disclosure will be thorough and complete and will fully understand the scope of the present disclosure to those skilled in the art.

[0027] The accompanying drawings of the embodiments of the present disclosure are used to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the detailed embodiments, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing the detailed embodiments with reference to the accompanying drawings.

[0028] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0029] The terms used in this disclosure are only used to describe specific embodiments and are not intended to limit the disclosure. As used in this disclosure, the term "and / or" includes any and all combinations of one or more related enumerated items. As used in this disclosure, the singular forms "a" and "the" are also intended to include plural forms, unless the context clearly indicates otherwise. As used in this disclosure, the terms "comprising" and "made of" specify the presence of the features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof.

[0030] Unless otherwise defined, all terms (including technical and scientific terms) used in this disclosure have the same meanings as those commonly understood by those skilled in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined in this disclosure.

[0031] The present disclosure is not limited to the embodiments shown in the drawings, but includes modifications of the configurations formed based on the manufacturing process. Therefore, the regions illustrated in the drawings have schematic properties, and the shapes of the regions shown in the drawings illustrate the specific shapes of the regions of the elements, but are not intended to be limiting.

[0032] Figure 1 This is an application scenario diagram of fault analysis in related technologies. Figure 1 As shown, during the operation of the power conversion unit (BDCI) 10, the data processing unit (BDPU) 20 collects fault data of the power conversion unit 10 through an internal protocol and stores the collected fault data in the storage unit 30. When it is necessary to analyze the fault of the power conversion unit 10, the fault data is transmitted to the host computer 40 through the northbound protocol, and the host computer 40 analyzes the fault of the power conversion unit 10.

[0033] Currently, there are two indirect analysis methods: one is to disassemble the power conversion unit 10 after the fault occurs, and then use an oscilloscope or other equipment to reproduce, observe and analyze it; the other is to collect historical data, historical alarms and operation records of the power conversion unit 10 through the data processing unit 20, and analyze them by the host computer 40.

[0034] The above methods are all passive analysis after the fault occurs, and cannot achieve prediction and active defense. Disassembly destroys the first scene, and the fault is very likely to have recovered by itself, making it difficult to reproduce the fault scene, which is not conducive to the analysis of the cause of the fault. The acquisition parameters are pre-defined and cannot be adjusted dynamically, lacking flexibility. Due to the hardware resource limitations of the power conversion unit 10, only part of the data can be selectively saved, but different faults focus on different fault data, resulting in the current method being unable to obtain the desired fault data when facing a wide variety of power conversion faults. Since the power conversion unit 10 does not have a historical data storage function, the data is generally stored by the data processing unit 20, and the data recorded by the data processing unit 20 is often not the original data of the power conversion unit 10, and cannot effectively reflect the real scene when the fault occurs. In addition, the power conversion unit 10 is a high-frequency device, and the fault occurs very quickly, while the data processing unit 20 is a low-frequency device, and the data acquisition and storage frequency is low, and it is impossible to record the key data at the time of the fault.

[0035] In a first aspect, an embodiment of the present disclosure provides a method for collecting fault data.

[0036] Figure 2 This is an application scenario diagram of the fault data collection method provided by the embodiment of the present disclosure. Figure 2 As shown, the embedded unit 100 includes power conversion products such as a power conversion unit, which is used for power conversion, charge and discharge control, and fault data collection. The embedded unit 100 in the disclosed embodiment has limited hardware resources, a wide variety of fault types, and difficulty in reproducing faults, which adversely affects fault analysis and location.

[0037] The monitoring unit 200 includes a parameter automatic configuration unit 201, a data storage unit 202 and a model prediction unit 203, wherein the parameter automatic configuration unit 201 is used to adaptively adjust the acquisition parameters of the embedded unit 100 according to the fault type predicted by the model prediction unit 203, receive the target fault data transmitted by the embedded unit 100, and support the manual parameter setting function and data acquisition function of the northbound protocol.

[0038] The data storage unit 202 is used to store data, such as target fault data. The parameter automatic configuration unit 201 annotates the target fault data and stores it in the data storage unit 202. The annotated information includes the fault time, fault type, and trigger conditions, facilitating subsequent fault reproduction, analysis, and location, and helping to identify the cause of the fault.

[0039] The model prediction unit 203 is used to monitor the operating status of the monitoring unit 200 in real time, identify abnormal characteristic parameters, infer the probability of fault occurrence and fault type through the fault model, and notify the parameter automatic configuration unit 201 to automatically configure the acquisition parameters of the embedded unit 100 to the target configuration parameters according to the predicted fault type.

[0040] During the operation of embedded unit 100, when embedded unit 100 collects target fault data, it transmits it to parameter automatic configuration unit 201 via an internal protocol. Parameter automatic configuration unit 201 stores the target fault data in data storage unit 202. Model prediction unit 203 predicts the fault type of embedded unit 100. Parameter automatic configuration unit 201 determines target configuration parameters based on the predicted fault type and configures embedded unit 100's collection parameters to the target configuration parameters, so that embedded unit 100 collects target fault data corresponding to the fault based on the target configuration parameters. When it is necessary to analyze the fault of embedded unit 100, the fault data is transmitted to northbound device 300 via the northbound protocol. Northbound device 300 then reproduces, analyzes, and locates the fault of embedded unit 100.

[0041] The internal protocol is used for communication between the embedded unit 100 and the parameter automatic configuration unit 201 , and the northbound protocol is used for communication between the parameter automatic configuration unit 201 and the northbound device 300 .

[0042] The northbound device 300 is used to train the fault prediction model, update the prediction model library, and interact with users.

[0043] Figure 3 This is a flow chart of a fault data collection method provided by an embodiment of the present disclosure. Figure 3 As shown, the fault data collection method provided by the embodiment of the present disclosure includes:

[0044] In step S301 , the monitoring unit uses a fault prediction model to predict the type of fault that will occur in the embedded unit based on real-time monitoring data.

[0045] The fault prediction model is a pre-trained model for predicting fault types, and the monitoring unit is a device for configuring parameters of the embedded unit.

[0046] The fault type is related to the embedded unit. Different embedded units have different fault types. The present disclosure does not limit the fault type. For example, the fault types of power conversion equipment include short circuit faults, metal oxide semiconductor field effect transistor (MOS) failure faults, etc.

[0047] In the embodiment of the present disclosure, the fault prediction model can be a prediction model obtained by training a preset machine learning model with a large amount of historical fault data. The embodiment of the present disclosure does not limit the type and training method of the fault prediction model. For example, the fault prediction model can be a long short-term memory neural network (LSTM) model, and the historical fault data includes but is not limited to actual historical data, and experimental data generated by various fault simulation analyses. First, the historical fault data is cleaned, and then the cleaned historical fault data is used to iteratively train the LSTM model to obtain a trained LSTM model. Then, the trained LSTM model is used to predict the type of fault that is about to occur in the embedded unit but has not yet occurred.

[0048] In some embodiments, the fault prediction model monitors the operating status of the monitoring unit in real time, and the fault prediction model predicts the type of impending fault based on the real-time monitoring data.

[0049] For example, real-time monitoring data includes board temperature, battery voltage, and battery current. If the fault prediction model predicts an abnormal rise in board temperature, a sudden drop in battery voltage, or an excess of battery current based on the real-time monitoring data, the fault type is determined to be a short circuit fault.

[0050] For example, real-time monitoring data includes busbar voltage, pulse width modulation (PWM) signal, current and midpoint voltage. If the fault prediction model predicts based on the real-time monitoring data that the busbar voltage is normal, the PWM signal is normal, the current increases abnormally and the midpoint voltage is less than 2V, the fault type is judged to be a MOS failure fault.

[0051] Step S302: The monitoring unit determines target configuration parameters of the embedded unit according to the fault type.

[0052] In the embodiment of the present disclosure, there is a corresponding relationship between the fault type and the collection parameter, and the target configuration parameter is a parameter for the embedded unit to collect fault data.

[0053] In some embodiments, the target configuration parameters include one or more of target data objects, trigger conditions, collection frequency, number of collection items, number of collection points, and collection point identifiers.

[0054] The present disclosure can configure the acquisition parameters of the embedded unit through the "set configuration parameters" command, and different target configuration parameters can be set for different fault types.

[0055] For example, a short circuit fault is a serious fault, and the target fault data to be collected must be small and large in volume. The target data objects include board temperature, battery voltage, and battery current. The target configuration parameters corresponding to a short circuit fault are listed in Table 1.

[0056] Table 1

[0057]

[0058] For example, a MOS failure is a critical fault, requiring a small interval and large amount of target fault data to be collected. The target data includes information such as board temperature, battery voltage, battery current, busbar voltage, midpoint voltage, and MOS tube PWM duty cycle. The target configuration parameters corresponding to the MOS failure are listed in Table 2.

[0059] Table 2

[0060]

[0061] Step S303: The embedded unit collects target fault data corresponding to the fault based on the target configuration parameters.

[0062] Figure 4 FIG. 1 is a flow chart of configuring parameters of the embedded unit in the embodiment of the present disclosure. Figure 4 As shown, the steps of configuring parameters of the embedding unit include:

[0063] Step S401: The monitoring unit synchronizes all configuration parameters.

[0064] All configuration parameters refer to the configuration parameters corresponding to known faults.

[0065] Step S402, determine whether the parameter has changed, if not, end; if so, execute step S403.

[0066] The monitoring unit determines whether the acquisition parameters of the embedded unit have changed according to the fault type. If the fault type has not changed, the process ends; if the fault type has changed, step S403 is executed.

[0067] Step S403: setting configuration parameters.

[0068] The monitoring unit configures the acquisition parameters of the embedded unit as target configuration parameters according to the fault type.

[0069] Step S404: Setting configuration parameter response.

[0070] Parameter response refers to the response time configured across modules. The parameter response time can be determined based on experience or the communication time between the embedded unit and the monitoring unit.

[0071] In some embodiments, before the embedded unit collects target fault data corresponding to the fault based on the target configuration parameters, it includes: the embedded unit monitors its own operating status data; the embedded unit determines whether the preset fault trigger condition is met based on the operating status data; when the fault trigger condition is met, the embedded unit executes the step of collecting target fault data corresponding to the fault based on the target configuration parameters.

[0072] Fault trigger conditions are pre-set, and different faults have corresponding trigger conditions. For example, the fault trigger conditions for a short circuit fault include a rise in battery temperature, a sudden drop in the battery voltage waveform, and an over-limit battery current. Another example is a MOS failure fault, where the fault trigger conditions include normal busbar voltage, normal PWM signal, abnormally increased battery current, and a midpoint voltage less than 2V.

[0073] The embedded unit monitors its own operating status data. When the operating status data meets the fault triggering conditions, it starts to collect fault data. If it is not triggered, it does not collect fault data. In this way, the collected fault data is highly accurate and the data volume is small.

[0074] In some embodiments, after the embedded unit collects target fault data corresponding to the fault based on the target configuration parameters, the method further includes: the embedded unit transmitting the target fault data to the monitoring unit; and the embedded unit clearing a cache space for caching the target fault data.

[0075] The target fault data collected by the embedded unit is cached in the cache space of the embedded unit. Since the cache space of the embedded unit is small, the target fault data needs to be transmitted to the monitoring unit in a timely manner and the cache space needs to be cleared to facilitate the collection of the target fault data of the next fault.

[0076] In some embodiments, the embedded unit transmits the target fault data to the monitoring unit, including: the embedded unit sends an initial frame to the monitoring unit, the initial frame carries the current acquisition parameters, and the current acquisition parameters are the parameters used by the embedded unit to currently acquire fault data; the monitoring unit verifies the current acquisition parameters based on the target configuration parameters, and if the verification is successful, the monitoring unit sends a first confirmation message to the embedded unit; the embedded unit transmits the target fault data to the monitoring unit.

[0077] The monitoring unit verifies the current acquisition parameters using the target configuration parameters, that is, compares the target configuration parameters and the current acquisition parameters to see if they are consistent. If they are inconsistent, the verification fails, indicating that the fault data currently collected by the embedded unit is not the target fault data that the monitoring unit wants. At this time, the monitoring unit does not respond, and this round of fault data acquisition process ends. If the target configuration parameters are consistent with the current acquisition parameters, the verification is successful, and the monitoring unit returns a first confirmation message to the embedded unit so that the embedded unit sends the target fault data to the monitoring unit. The embodiment of the present disclosure verifies the current acquisition parameters, which can avoid the fault data received by the monitoring unit being different from the target fault data, avoid ineffective fault analysis, and reduce waste of resources.

[0078] When a fault is triggered, the embedded unit first notifies the monitoring unit of the currently configured collection parameters through the SCI protocol's "actively report first frame" command. The collection parameters include the collection frequency, number of collection items, number of collection points, and collection point identification (ID). This information will be saved together with the corresponding fault data to facilitate the northbound device to ultimately parse and recover the fault site data.

[0079] In some embodiments, before the monitoring unit verifies the current acquisition parameters based on the target configuration parameters, it also includes: the monitoring unit determines whether it is necessary to store and wait for the first frame; if storage and waiting are not required, the first frame is timestamped.

[0080] In order to ensure that the first frame is received and avoid loss, the monitoring unit needs to determine whether the first frame needs to be stored and waited. If storage and waiting are required, the monitoring unit needs to timestamp the first frame, parse the first frame, and handle abnormal situations. When the first frame is received, a first confirmation message is sent to the embedded unit.

[0081] Figure 5 This is a flowchart of uploading the first frame in the embodiment of the present disclosure. Figure 5As shown, the steps for uploading the first frame include:

[0082] Step S501, determine whether the first frame is received, if so, execute step S502, if not, end.

[0083] Step S502, determine whether storage waiting is required, if so, end, if not, execute step S503.

[0084] Step S503: Timestamp the first frame.

[0085] The timestamp is the time when the first frame is received.

[0086] Step S504: parse the first frame and perform exception processing.

[0087] The first frame is parsed and any abnormal frame is processed to make it complete. If the abnormality cannot be processed, the frame is discarded.

[0088] Step S505: After the initial frame is received, a first confirmation message is sent to the embedded unit.

[0089] After the initial frame is successfully received and stored, the embedded unit sends fault data to the monitoring unit using the SCI protocol's "active data reporting" command until all fault data is acquired. Because the total amount of fault data is configurable, not all data in a single frame can be sent. To provide greater flexibility for different products, fault data is sent in batches, based on data frames, ensuring that all fault data reaches the monitoring unit and preventing omissions and data over-interpretation.

[0090] Table 3 shows the specific definitions of the SCI protocol instructions in the embodiment of the present disclosure.

[0091] Table 3

[0092]

[0093]

[0094] When sending the target fault data, in order to ensure the integrity of the target fault data, each data frame in the target fault data may also be checked.

[0095] In some embodiments, after the embedded unit transmits the target fault data to the monitoring unit, it also includes: the monitoring unit verifies each data frame in the target fault data; if the verification passes, sends a second confirmation message to the embedded unit; after the target fault data is received, the target fault data is stored in the storage space.

[0096] When receiving the target fault data, the monitoring unit verifies each data frame to ensure that the received data frame is complete, and stores the target fault data in the storage space after receiving all the target fault data. If the target fault data is not received in full, it continues to receive.

[0097] In the disclosed embodiment, the target fault data is transferred to the monitoring unit in batches. After receiving the target fault data, the battery management system (BMS) will package the target fault data and the corresponding target configuration parameters and store the target fault data using the file system. The target fault data supports a maximum of 1000 batches, each batch represents a fault and contains a number of fault data. The specific number can be configured through parameters. The data packaging method is as follows:

[0098] The target fault data of each batch shown in Table 4 starts with the timestamp of the fault occurrence and ends with the checksum and cyclic redundancy check (CRC). In the middle, it contains the target configuration parameters (that is, the content of the first frame) and the target fault data corresponding to the target configuration parameters.

[0099] Table 4

[0100]

[0101]

[0102] In some embodiments, before the monitoring unit verifies each data frame in the target fault data, it also includes: the monitoring unit determines whether the data frame needs to be stored and waited, and whether the first frame has been received; if there is no need to store and wait and the first frame has been received, the monitoring unit verifies each data frame in the target fault data.

[0103] The transmission of data frames also requires determining whether storage and waiting are required. If storage and waiting are not required and the initial frame has been received, data frame reception begins. When receiving data frames, the monitoring unit verifies each data frame in the target fault data to prevent incomplete data frames and frame loss. When receiving data frames, the data frames are parsed and exception handling is performed for any abnormal data frames.

[0104] Figure 6 This is a flowchart of uploading target fault data in the embodiment of the present disclosure. Figure 6 As shown in the figure, the steps for uploading target fault data include:

[0105] Step S601, determine whether the data frame is received and whether the first frame is received. If so, execute step S602; if not, end.

[0106] Step S602, determine whether storage waiting is required, if so, end, if not, execute step S603.

[0107] Step S603: parse the first frame and perform exception processing.

[0108] The data frame is parsed and exception handling is performed on the data frame with exceptions to make the data frame complete.

[0109] Step S604: Send a second confirmation message to the embedded unit.

[0110] Step S605 , determining whether the target fault data has been received. If so, executing step S606 ; if not, returning to executing step S601 .

[0111] Step S606 : the parameter automatic configuration unit stores the target fault data and enters the storage waiting state of the data storage unit.

[0112] The parameter automatic configuration unit performs target fault data storage and enters the storage waiting state of the data storage unit so as to store the target fault data in the data storage unit.

[0113] It should be noted that the embodiments of the present disclosure do not limit the method of parsing and abnormally handling the initial transmission frame and data frame, and the parsing and abnormal handling can be performed according to the corresponding data transmission protocol regulations.

[0114] The storage and waiting steps for the first frame and the data frame are the same. The following takes the storage and waiting steps for the first frame as an example to introduce. Figure 7 FIG. 1 is a flowchart of the storage waiting of the first frame in the embodiment of the present disclosure. Figure 7 As shown, the steps of storing and waiting for the first frame include:

[0115] Step S701: Use a counter to time the storage wait.

[0116] When storage waiting is required, a counter is used to start timing the storage waiting time.

[0117] Step S702, determine whether the storage waiting time reaches the time threshold, if so, execute step S703; if not, return to step S701 and continue timing.

[0118] The time threshold is a preset threshold, which can be set by the user or by a default value, and is not limited in this embodiment of the present disclosure.

[0119] Step S703: Clear the storage waiting flag and timer.

[0120] When the storage wait reaches the wait time threshold, the storage wait flag and the timer are cleared, that is, the timer is reset to zero.

[0121] In some embodiments, after the embedded unit transmits the target fault data to the monitoring unit, the method further includes: the monitoring unit uploading the target fault data to the northbound device so that the northbound device can restore the fault, analyze the cause, and locate the fault.

[0122] When it is necessary to analyze and locate the fault of the embedded device, the monitoring unit uploads the target fault data to the northbound device through the northbound protocol so that the northbound device can restore the fault, analyze the cause and locate the fault.

[0123] In the disclosed embodiments, in addition to the automatic parameter configuration unit being able to automatically configure parameters, northbound devices can also proactively set configuration parameters and retrieve stored target fault data. This disclosure does not limit the northbound protocol; for example, a remote download communication protocol can be used to store and export target fault data in the form of files, as well as to set configuration parameters. Northbound protocols offer high export efficiency, facilitate integration with other platform protocols, and offer strong versatility.

[0124] The present disclosure takes into account that the cache space (FLASH) of the embedded device cannot be erased and written frequently, so the embedded unit needs to have a data cleaning mechanism. If the fault is triggered again within a preset time period, the fault data corresponding to the fault will no longer be collected, and only the target fault data at the time of the first trigger will be recorded.

[0125] For faults that cannot disappear automatically, the target fault data corresponding to the fault is not collected repeatedly. Only the fault data at the first trigger is collected to prevent duplicate data from covering all records.

[0126] The fault data collection method provided by the disclosed embodiment is a method in which a monitoring unit uses a fault prediction model to predict the type of fault that will occur in an embedded unit based on real-time monitoring data, and determines the target configuration parameters of the embedded unit based on the fault type. The embedded unit then collects target fault data corresponding to the fault based on the target configuration parameters. That is, the embedded unit collects fault data in a targeted manner according to its own high frequency, thereby obtaining the original data in real time with high accuracy. Therefore, the fault scene can be restored and reproduced. Moreover, the amount of target fault data collected is small, and no additional hardware resources are required, making it suitable for embedded units with limited hardware resources. In addition, by using the fault prediction model to predict the impending fault, the embedded unit's parameters are proactively configured based on the fault type, which provides high flexibility.

[0127] In a second aspect, an embodiment of the present disclosure provides a fault diagnosis method.

[0128] Figure 8 This is a flow chart of a fault diagnosis method provided by an embodiment of the present disclosure. Figure 8 As shown, the fault diagnosis method provided by the embodiment of the present disclosure includes:

[0129] Step S801: Acquire target fault data.

[0130] The target fault data is obtained by the fault data collection method provided in the embodiment of the present disclosure. To save space, the detailed steps of the fault data collection method are not described here.

[0131] Step S802: Analyze the target fault data to determine the cause and location of the fault.

[0132] After obtaining the fault cause and fault location, it is possible to determine whether the target fault data collected by the embedded device is correct based on the fault cause and fault location, and optimize the fault prediction model to improve the accuracy of the fault prediction model.

[0133] The fault diagnosis method provided by the embodiment of the present disclosure utilizes a fault prediction model to predict the type of fault that will occur in the embedded unit based on real-time monitoring data, and determines the target configuration parameters of the embedded unit according to the fault type. The embedded unit collects target fault data corresponding to the fault based on the target configuration parameters, and uses the target fault data for diagnosis to obtain the cause and location of the fault. Since the embedded unit collects fault data in a targeted manner according to its own frequency, it can obtain high-accuracy original data in real time. Therefore, it can restore and reproduce the fault scene, thereby accurately determining the cause and location of the fault. Moreover, the amount of target fault data collected is small, and no additional hardware resources are required, which is suitable for embedded units with limited hardware resources. In addition, the fault prediction model is used to predict the impending fault, and the embedded unit parameters are actively configured according to the fault type, which is highly flexible.

[0134] In a third aspect, an embodiment of the present disclosure provides an electronic device.

[0135] Figure 9 FIG. 1 shows a block diagram of an electronic device provided by an embodiment of the present disclosure. Figure 9 As shown, an electronic device provided by an embodiment of the present disclosure includes a processor 901 and a memory 902; the memory 902 stores a computer program that can be executed by the processor 901, and when the computer program is executed by the processor 901, any one of the fault data collection methods or fault diagnosis methods of the embodiments of the present disclosure is implemented.

[0136] In some embodiments, the electronic device also includes an I / O interface (read-write interface) 903, which is connected between the processor 901 and the memory 902, and can realize information interaction between the memory 902 and the processor 901, including but not limited to a data bus (Bus), etc.

[0137] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, which can realize information exchange between the memory and the processor, including but not limited to the data bus (Bus), etc.

[0138] Those skilled in the art will appreciate that all or some of the steps, systems, and functional modules / units in the apparatus disclosed above may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0139] An embodiment of the present disclosure further provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any one of the fault data collection methods or fault diagnosis methods described in the embodiments of the present disclosure.

[0140] The embodiments of the present disclosure further provide a computer program product, which includes a computer program. When the computer program is executed by a processor, any one of the fault data collection methods or fault diagnosis methods described in the embodiments of the present disclosure is implemented.

[0141] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation.

[0142] Those skilled in the art will appreciate that all or some of the steps, systems, and functional modules / units in the apparatus disclosed above may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0143] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation.

[0144] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; compact disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cassettes, tapes, disk storage or other magnetic storage; any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0145] The present disclosure has disclosed example embodiments, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A fault data collection method, comprising: The monitoring unit uses a fault prediction model to predict the type of fault that will occur in the embedded unit based on real-time monitoring data. The fault prediction model is a pre-trained model for predicting the type of fault. The monitoring unit is a device for configuring parameters of the embedded unit. The monitoring unit determines the target configuration parameters of the embedded unit according to the fault type, and the target configuration parameters are the parameters of the embedded unit for collecting fault data; The embedded unit collects target fault data corresponding to the fault based on the target configuration parameters.

2. The method according to claim 1, wherein After the embedded unit collects target fault data corresponding to the fault based on the target configuration parameters, the method further includes: The embedded unit transmits the target fault data to the monitoring unit; The embedded unit clears the cache space for caching the target fault data.

3. The method according to claim 1, wherein The embedded unit transmits the target fault data to the monitoring unit, including: The embedded unit sends an initial frame to the monitoring unit, wherein the initial frame carries current acquisition parameters, which are parameters currently used by the embedded unit to acquire fault data; The monitoring unit verifies the current acquisition parameters based on the target configuration parameters; If the verification is successful, the monitoring unit sends a first confirmation message to the embedded unit; The embedded unit transmits the target fault data to the monitoring unit.

4. The method according to claim 3, wherein: Before the monitoring unit verifies the current acquisition parameter based on the target configuration parameter, the monitoring unit further includes: The monitoring unit determines whether it is necessary to store and wait for the first frame; In the case where there is no need for storage waiting, the first frame is timestamped.

5. The method according to claim 2, wherein: After the embedded unit transmits the target fault data to the monitoring unit, the method further includes: The monitoring unit verifies each data frame in the target fault data; If the verification is successful, sending a second confirmation message to the embedded unit; After the target fault data is received, the target fault data is stored in a storage space.

6. The method according to claim 5, wherein: Before the monitoring unit verifies each data frame in the target fault data, the monitoring unit further includes: The monitoring unit determines whether it is necessary to store and wait for the data frame, and whether the first frame has been received; In the case that storage waiting is not required and the first frame is completely received, the monitoring unit verifies each data frame in the target fault data.

7. The method according to claim 2, wherein: After the embedded unit transmits the target fault data to the monitoring unit, the method further includes: The monitoring unit uploads the target fault data to the northbound device so that the northbound device can restore the fault, analyze the cause, and locate the fault.

8. The method according to claim 1, wherein Before the embedded unit collects target fault data corresponding to the fault based on the target configuration parameters, the method includes: The embedded unit monitors its own operating status data; The embedded unit determines whether a preset fault trigger condition is met based on the operating status data; When the fault triggering condition is met, the embedded unit collects target fault data corresponding to the fault based on the target configuration parameters.

9. The method according to claim 1, wherein: If the fault is triggered again within a preset time period, the fault data corresponding to the fault will no longer be collected; Furthermore, for a fault that cannot disappear automatically, target fault data corresponding to the fault is not repeatedly collected.

10. A fault diagnosis method comprising: Acquire target fault data, wherein the target fault data is obtained by the fault data acquisition method according to claim 1; The target fault data is analyzed to determine the cause and location of the fault.

11. An electronic device comprising a memory and a processor; the memory stores a computer program executable by the processor, and when the computer program is executed by the processor, it implements the fault data collection method according to any one of claims 1 to 9 or the fault diagnosis method according to claim 10.

12. A computer-readable medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program implements the fault data collection method according to any one of claims 1 to 9 or the fault diagnosis method according to claim 10.

13. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the fault data collection method according to any one of claims 1 to 9 or the fault diagnosis method according to claim 10.

Images