Energy storage system multi-source data fusion and fault root cause analysis method

Abstract

This invention provides a method for multi-source data fusion and root cause analysis of energy storage systems. The method includes establishing a semantic standard table, storing standard parameter names and their corresponding semantic vector codes for each combination of device type code and parameter type code, and recording the semantic descriptions corresponding to each parameter type code. When a fault alarm is triggered, the method queries the time-series data of the faulty device within a preset time window from a time-series database, and assembles the time-series data and the semantic descriptions corresponding to the parameter type codes into prompt words, which are then sent to a local inference model. The local inference model determines whether further analysis is needed. If the determination result indicates that analysis is needed, the method proceeds to the backend orchestration step. During the backend orchestration step, the method obtains the parameter type codes and corresponding semantic descriptions of each associated device, and the cloud-based inference model summarizes the diagnostic context. The diagnostic context is then sent to a cloud-based generation system, which generates a final diagnostic report containing root cause analysis and remedial recommendations.

Description

Technical Field

[0001] This invention relates to the field of fault diagnosis of energy storage systems, and in particular to a method for multi-source data fusion and root cause analysis of energy storage systems. Background Technology

[0002] In the fields of energy storage systems and industrial energy management, power plants (photovoltaic, energy storage, charging piles, etc.) typically deploy knowledge-based augmented generation (RAG) systems such as RAGFlow for intelligent diagnostic analysis of equipment faults. The existing process is as follows: after a work order is triggered, the system queries the equipment parameter model table (tdac_devparamodel) according to (devTypeCode, devClass) to obtain all data points, pulls recent data from the ClickHouse time-series database, assembles all the data into a natural language prompt, and then POSTs it to the RAGFlow webhook for diagnostic analysis.

[0003] However, this method has the following drawbacks: 1. There are many invalid calls. Even normally operating devices go through the entire RAGFlow process, wasting computing power and time; 2. Inconsistent naming conventions for device parameters across different manufacturers necessitate manual configuration of each paraType parameter when connecting new devices, which is slow and prone to errors. 3. Related data is prone to being missing. When equipment fails, only the location of the faulty equipment itself is checked, and related equipment is not checked, resulting in incomplete context. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-source data fusion and root cause analysis method for energy storage systems that can intercept normal data, reduce invalid data calls, automatically classify new devices into existing semantic standard tables when they are connected, and synchronously collect and analyze data from associated devices of faulty devices.

[0005] To address the aforementioned technical problems, this invention provides a method for multi-source data fusion and root cause analysis of energy storage systems, comprising the following steps: Step 1: Establish a semantic standard table to store the standard parameter name and its corresponding semantic vector code for each combination of device type code and parameter type code, and record the semantic description corresponding to each parameter type code; Step 2: Deploy the local inference model. When a fault alarm is triggered, query the time series data of the faulty device within a preset time window from the time series database, and assemble the time series data with the semantic descriptions corresponding to the parameter type codes in the semantic standard table into a prompt word and send it to the local inference model. The local inference model determines whether further analysis is needed. If the determination result is that no analysis is needed, the subsequent process is terminated and a log is recorded. If the determination result is that analysis is needed, proceed to the backend orchestration step. Step 3, during the backend orchestration process, recursively obtains the associated devices of the faulty device and constructs a device topology tree; obtains the parameter type code and corresponding semantic description of each associated device, and the cloud inference model summarizes the abnormal parameter information of the faulty device, the time series data of the associated devices, and the device topology relationship into a diagnostic context; Step 4: Send the diagnostic context to the cloud-based generation system, which will then generate a final diagnostic report containing root cause analysis and treatment recommendations.

[0006] Furthermore, in step one, when a new device is connected, the original parameter name of the new device is encoded using a new device semantic vector. The resulting new device semantic vector code is then matched with the semantic vector codes stored under the device type code of the new device in the semantic standard table using cosine similarity. This is used to classify the original parameter name of the new device as a standard parameter name.

[0007] Furthermore, in step three, the abnormal parameter information of the faulty device, the semantic description corresponding to the parameter type code of the associated device, and the device topology relationship are sent as context to the cloud inference model. The cloud inference model then filters out the devices and their parameter type codes that are related to the cause and effect of this fault. Based on the filtering results, the time series data of the corresponding devices are queried from the time series database, and the abnormal parameter information of the faulty device, the time series data of the filtered associated devices, and the device topology relationship are summarized into a diagnostic context.

[0008] Furthermore, during the cosine similarity matching process, when the cosine similarity is greater than or equal to the first threshold, the original parameter name is classified as the corresponding standard parameter name; when the cosine similarity is between the first threshold and the second threshold, it is marked as a suggested classification of the corresponding standard parameter name and awaits confirmation; when the cosine similarity is less than or equal to the second threshold, it is marked as unclassified; the first threshold is greater than the second threshold.

[0009] Furthermore, in step two, when the local inference model determines whether further analysis is needed, it compares the time-series data in the prompt words with the range of judgment parameters point by point. If the data exceeds the range of judgment parameters, the model triggers a judgment result indicating that analysis is required.

[0010] Furthermore, the parameter range is judged in the following order: upper limit, upper limit, lower limit, and lower lower limit. When the time series data is between the upper limit and the upper limit, or between the lower limit and the lower lower limit, it is judged as a parameter abnormality but no analysis is required. When the time series data is higher than the upper limit or lower than the lower lower limit, it is judged as a parameter abnormality and analysis is required.

[0011] Furthermore, in step two, the preset time window is 5 minutes.

[0012] Furthermore, in step three, associating devices includes querying the device topology table and recursively obtaining all child devices and parent devices of the faulty device.

[0013] Furthermore, in step four, after receiving the diagnostic context, the cloud-based generation system retrieves relevant fault cases and maintenance documents from the cloud knowledge base, and generates a final diagnostic report containing root cause analysis and treatment recommendations based on the retrieval results.

[0014] Furthermore, the semantic vector encoding in the semantic standard table is a fixed-dimensional floating-point vector generated by a sentence embedding model from the standard parameter names.

[0015] The beneficial effects of this invention are as follows: 1. Significantly reduce invalid RAGFlow calls: Edge LLM intelligently filters faulty device data before it is sent into RAGFlow, and normal fluctuations and low-value alarms are intercepted at the edge.

[0016] 2. Improved efficiency of new vendor device access: The process has been changed from manual review to semantic cosine similarity matching for automatic classification, with the assistance of a small amount of manual review.

[0017] 3. More complete fault diagnosis context: Cloud-based LLM intelligent filtering of related device parameters ensures a complete causal chain required for diagnosis.

[0018] 4. Zero-intrusive design: The semantic standard table is an additional index layer, which is fully compatible with existing functions. Attached Figure Description

[0019] Figure 1 This is the overall system architecture diagram of the present invention.

[0020] Figure 2 This is a data model diagram of the semantic standard table in this invention.

[0021] Figure 3 This is a flowchart of the automatic semantic matching process in this invention.

[0022] Figure 4 This is a flowchart of the edge LLM pre-filtering process in this invention.

[0023] Figure 5 This is a timing diagram of the edge LLM pre-filter of the present invention.

[0024] Figure 6 This is the Agent orchestration flowchart of the present invention.

[0025] Figure 7 This is a flowchart of the existing fault analysis process. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention are within the scope of protection of the present invention.

[0027] Those skilled in the art should understand that, in the disclosure of this invention, the terms "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the above terms should not be construed as limiting this invention.

[0028] It is understood that the term "a" should be understood as "at least one" or "one or more", that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple, and the term "a" should not be understood as a limitation on the number.

[0029] like Figures 1-7 The present invention provides a method for multi-source data fusion and root cause analysis of energy storage systems, comprising the following steps: I. ParaType Semantic Standardization and Automatic Matching for Parameter Type Encoding: 1.1 Semantic Standard Table Design: The semantic standard table tdac_paratype_semantic stores the standard parameter name standardName and its corresponding semantic vector encoding embedding for each (device type code devTypeCode, parameter type code paraType) combination, as shown in Table 1 below.

[0030]

[0031] Table 1 In the existing system, paraType is a semantic classification number of type Integer, and its meaning is limited by devTypeCode. Globally, only paraType=1 is agreed to mean "unassigned". The meanings of the other numbers are manually determined by the operation and maintenance personnel according to the actual parameters of each device type. Therefore, there is no unified coding standard across device categories. The semantic vector encoding in the semantic standard table is a fixed-dimensional floating-point vector generated by embedding the standard parameter names into a sentence embedding model.

[0032] For example, in a PCS device, paraType=2 represents "PCS power" and paraType=5 represents "fault status", while in a BCMU device, paraType=5 does not represent a fault status.

[0033] In current conventional systems, due to the device type locality and manually defined nature of this numbering rule, new vendors cannot be directly mapped using the numbering system, requiring maintenance personnel to manually configure each item against a template. This solution introduces the semantic standard table tdac_paratype_semantic, explicitly transforming the semantics of paraType from "number" to "standard parameter name + semantic vector encoding," thereby achieving automatic semantic matching of parameters across vendors and fundamentally eliminating reliance on manual numbering experience.

[0034] 1.2 Cold Start Process (One-time, combined with manual review): ① Extract the paraName sample of each devTypeCode that has a pre-configured paraType; ② Manually define a standardName for each (devTypeCode, paraType); ③ Perform sentence embedding on standardName and write it into the semantic standard table; 1.3 New Device Access – Automatic Embedding Matching Process: When a new device is connected, its paraName is vector-encoded and matched with the semantic standard vector under the same devTypeCode using cosine similarity. The similarity classification decision rules are shown in Table 2 below.

[0035]

[0036] Table 2 It is worth mentioning that during the standardization and automatic matching of ParaType semantics in parameter type encoding, the scope of paraType semantics is limited by devTypeCode (the same int value has different meanings under different device categories); embedding is based on standardName Chinese short text encoding and uses the qwen3-embedding:0.8b model; existing configured devices are not affected - this table is an additional index layer and does not change the DevParaModelDO write logic; it is orthogonal to the existing getParaModelMap query: this interface queries MySQL to get the complete point list, and the auxiliary parameter types in this table are automatically filled.

[0037] II. Edge LLM pre-filtering: Edge LLM (Ollamaqwen3.5:4b) only determines whether the current data of the faulty device needs to be sent to RAGFlow analysis. 2.1 When a fault alarm is triggered, the backend queries the time series database for ClickHouse time series data of the faulty device within a preset time window of 5 minutes.

[0038] The reason for setting the time window for querying faulty equipment timing data to 5 minutes before the fault alarm is: 1. Data integrity: The system collects data at a frequency that changes and then uploads it (seconds) to the full upload (maximum 5 minutes). The 5-minute window can guarantee that at least one complete full upload cycle is covered, ensuring that all parameters have data. 2. Trend observability: Multiple data collections within a 5-minute window can form a time-series trend, allowing the local model to determine the direction of parameter changes (such as continuous decline, sudden jump, etc.), rather than relying solely on a single instantaneous value; 3. Cause-and-effect chain coverage: The time from the initial stage of a fault in an energy storage device to the triggering of an alarm is usually within a few minutes, and 5 minutes can cover the entire fault development process; 4. Controllable computational overhead: The window length directly affects the amount of data fed into the edge model. The 5-minute window strikes a balance between data density and inference latency.

[0039] 5. The parameters of this window can be configured and adjusted according to the actual acquisition frequency and fault characteristics.

[0040] 2.2 Assemble the time series data and the parameter type encoding paraType semantic description into a prompt word SystemPrompt and send it to the edge LLM that serves as the local inference model.

[0041] The output type of SystemPrompt is: [Alarm Information] Device type: {devTypeCode} Alarm Name: {alarmName} Alarm description: {alarmContent} Alarm level: {level} Alarm Rules and Trigger Values Regular expression: {formula + threshold} - Basic over-limit categories: such as "DC voltage < 450V (lower limit)" - Aggregation rule class: such as "stddev(paraType='23|24|25')over5m>30V" Actual trigger value: {value, e.g., 430.8V / 45.2V} Text description: {description} [All parameters of this device are within the normal range] |Parameter Name|Lower Limit|Upper Limit|Upper Upper Limit|Lower Lower Limit|Unit| |Phase A DC Voltage|450|850|900|400|V| |Phase B DC Voltage|450|850|900|400|V| |PCS Power|0|500|550|-50|kW| ... [Device timing data (5 minutes before alarm)] Time, Phase A DC voltage (V), Phase B DC voltage (V), PCS power (kW) 14:25:00, 780.2, 775.5, 320.5 14:26:00, 820.1, 710.3, 318.3 14:27:00, 830.5, 680.1, 310.2 14:28:00, 840.2, 650.3, 305.1 14:29:00, 845.1, 630.5, 298.6 2.3 LLM compares each bit with the normal_range to determine the degree of anomaly.

[0042] The normal_range is defined as follows: The normal range of parameters is stored in the device parameter model table tdac_devparamodel, which contains four limit fields: upper limit (highLimit), lower limit (lowLimit), upper upper limit (hihiLimit), and lower lower limit (lolowLimit). These thresholds are obtained through standardized synchronous upload on the device side or manually corrected by maintenance personnel.

[0043] These four limits also serve as the threshold source for Grafana's basic out-of-limit alert rules.

[0044] For alarms based on aggregate metrics (such as standard deviation and grid connection power), the rule expressions are configured independently by operations and maintenance personnel in Grafana and are not included in the four limits.

[0045] In one embodiment of this solution, the determination of whether it is necessary to send the data to the next stage is based on factors such as the degree of parameter deviation, the trend of change, multi-parameter linkage, and alarm level. Specifically: ① Deviation degree: The deviation of the actual value of the parameter from the threshold. Severe deviation (e.g., exceeding hihiLimit / lolowLimit under the four-limit rule) is given priority for analysis. ② Trend of change: The direction of parameter change in time series data. Continuous deterioration is the priority to be analyzed, while recovery after instantaneous jitter can be determined as not requiring analysis (e.g., false alarms caused by instantaneous voltage jumps or data delays). ③ Multi-parameter linkage: In addition to the parameters that trigger the alarm, are there any abnormal signs in other parameters? Multi-parameter linkage anomalies are prioritized for analysis (multiple anomalies triggered at the same site will be analyzed simultaneously). ④ Alarm Level: Fault-related alarms (level=1) are prioritized for analysis (level configured in Grafana).

[0046] 2.4 LLM outputs structured JSON: {"needAnalysis":true / false,"reason":"reason for judgment"}.

[0047] 2.5 needAnalysis=false: Log logging terminates; needAnalysis=true: Enter Agent orchestration.

[0048] It is worth mentioning that this solution uses edge LLM for pre-filtering. Since the qwen3.5:4b level model performs binary judgment, the task is simple enough and will not produce hallucination-level bias. The input only contains the data of the faulty device itself and does not involve multi-step reasoning. The JSON mode forces the output structure to avoid free divergence. The filtered out are normal fluctuations and low-value alarms, and the risk of missed reports is controllable.

[0049] 3. Backend Agent Related Data Expansion: After edge LLM determination requires analysis, the backend agent takes over. The agent relies on the cloud model deepseekv4flash for orchestration decisions, sending the fault context and paraType semantic descriptions of related devices to deepseek, which then determines which parameters are relevant to the current fault. 3.1 Device tree expansion: Query the device topology table and recursively obtain all child devices (all levels) and parent devices of the faulty device.

[0050] The device topology is stored in the `parent_id` field of the device table (`tdac_device`), organized in a tree-like nested structure. The typical hierarchy is: Master node → Power station → Various devices (PCS, BMS, meters, air conditioners, etc.), and multi-level recursive nesting is supported (e.g., PCS → BMS → BCMU → Battery module).

[0051] The topology is established as follows: when devices connect to the platform, hardware personnel manually configure the topology based on physical connections, or the system automatically associates them according to preset rules (e.g., devices on the same communication link are grouped into the same parent node). Maintenance personnel can manually adjust the topology hierarchy in the management platform at any time.

[0052] In the fault analysis process, the Agent orchestration module obtains the current topology in real time by recursively querying the parent_id field, without relying on caching or snapshots. Therefore, subsequent adjustments to the topology do not affect the accuracy of the analysis.

[0053] The recursive scope includes all sub-devices and parent devices at all levels of the faulty device, ensuring coverage of the complete causal chain.

[0054] 3.2 Constructing the LLM context: Faulty device: list of paraTypes + current value of each parameter + normal_range; Each associated device: devTypeCode + devClass + paraType list (standardName); Device topology (hierarchy).

[0055] 3.3 DeepSeek v4 Flash Decision: Deepseek receives abnormal parameters from the faulty device, along with the normal_range parameter, semantic descriptions of the paraType parameters for candidate related devices, and the device topology. The output is: {devices:[{deviceId,selectedParaTypes:[1,3,5]}]}. It does not involve diagnosis; it only filters which parameters are likely causally related to the current fault.

[0056] The cloud-based inference model's selection decision is based on semantic reasoning across the following three dimensions: (1) Fault physical semantic analysis: Understand the physical nature of the fault based on the alarm rule expression, trigger value and parameter semantic description. For example, "low DC voltage" means that the upstream power supply may be abnormal, rather than a problem with the downstream load.

[0057] (2) Topological causal chain reasoning: Reasoning along the device topology hierarchy for possible causal transmission paths. The upper-level device (parent device) may be the source of the fault, and the lower-level device (child device) may be the consequence of the fault or the object of further verification. Devices at the same level usually have no direct causal relationship, but common factors can be ruled out.

[0058] (3) Parameter semantic correlation matching: Match the physical quantities involved in the fault (voltage, current, temperature, etc.) with the parameter semantic names of the candidate devices, select only the parameter types that are causally related to the physical quantities of the fault, and exclude irrelevant parameters.

[0059] This screening process does not involve the generation of fault diagnosis conclusions, but only outputs a structured decision result of "which parameter types need to be queried for each associated device". The diagnosis is completed by the cloud-based RAGFlow knowledge enhancement module.

[0060] 3.4 ClickHouse On-Demand Query: Only query the (devTypeCode, devClass, paraType) → paraCode → ClickHouse time-series data in the filtered results, reusing the existing MqttApi / HistoryApi interface.

[0061] 3.5 Context Summary: Faulty device data + filtered related data + device topology relationships + parameter semantic descriptions are summarized into a complete prompt and sent to RAGFlow.

[0062] After receiving the diagnostic context, the cloud-based generation system retrieves relevant fault cases and maintenance documents from the cloud knowledge base, and generates a final diagnostic report containing root cause analysis and treatment recommendations based on the search results.

[0063] The diagnostic report uses a standardized Markdown structure and includes the following fixed sections: (1) Fault Overview: Summarize work order number, faulty equipment, alarm rules, trigger values ​​and occurrence time. (2) Data anomaly identification: Analyze each telemetry and teleindication data item by item for exceeding limits, sudden changes or trend anomalies, and list the abnormal data points; (3) Fault location: Infer the faulty equipment and location by combining alarm content, abnormal data and equipment topology; (4) Possible causes: List the hypotheses of cause of failure in descending order of probability, and each one must be supported by data; (5) Handling recommendations: Provide on-site inspection, remote operation and safety precautions for each possible cause; (6) Supplementary explanation: Indicate the links where the data is insufficient for judgment and suggest supplementary monitoring data; (7) Reference knowledge base cases: Link historical cases in the knowledge base and explain their relevance. This can be omitted if there is no match.

[0064] The report requires that all conclusions be supported by data, electrical parameters must include units, and technical terms must be accurate and standardized.

[0065] It is worth mentioning that the reasons for choosing Deepseek v4 flash for decision-making in this scheme are shown in Table 3 below.

[0066]

[0067] Table 3 Based on this, the main advantages of this solution compared to existing system solutions are shown in Table 4 below.

[0068]

[0069] Table 4 Furthermore, to illustrate the specific implementation of this solution in more detail, the following embodiment is used as an example: A photovoltaic energy storage power station deploys multiple inverters, battery management systems (BMS), and power storage converters (PCS). The equipment comes from various manufacturers, and the parameter naming differs for the same type of equipment. The system has completed a cold start of the ParaType semantic standard table, containing approximately 300 semantic standard records. Its implementation path and dependency constraints are shown in Tables 5 and 6 below.

[0070]

[0071] Table 5

[0072] Table 6 Scenario 1: Connection of a new manufacturer's inverter The parameter names of newly connected inverters include "DC voltage of inverter #1" and "DC_VOLT_PHASE_A". The system automatically encodes the paraName using qwen3-embedding:0.8b and performs cosine matching with 30 semantic standard records under the INVERTER type. "DC voltage of inverter #1" has a similarity of 0.92 (>0.85) to "DC voltage", and is automatically classified as paraType=1. "DC_VOLT_PHASE_A" has a similarity of 0.78 (0.60-0.85) to "DC voltage A phase", and is marked as source=suggest pending confirmation. The entire process is completed in seconds.

[0073] Scenario 2: Routine Alarm Filtering A minor inverter voltage fluctuation alarm is triggered. After point-by-point comparison by the edge LLM, all parameters are determined to be within the normal range, and the system outputs {“needAnalysis”:false,“reason”:“Voltage fluctuation within ±2%”}. The system terminates the process without calling RAGFlow.

[0074] Scenario 3: Real-world fault diagnosis The inverter reports a fault alarm, and the edge LLM determines needAnalysis=true (DC voltage is significantly low). Backend Agent: Step 1: Expanding the device tree reveals that the inverter is connected to two BMS sub-devices and has a combiner box parent device at the top. Step 2: Construct the context, including a list of paraTypes for faulty devices and their outliers, semantic descriptions of paraTypes for associated devices, and the topology hierarchy; Step 3: Deepseek determines the BMS to check cell temperature, SOC, and individual cell voltage, and the combiner box to check AC side voltage and current. Step 4: Search for relevant device data in ClickHouse based on the filtered results; Step 5: Compile all data and send it to RAGFlow to generate a diagnostic report containing root cause analysis and treatment recommendations.

[0075] This invention is not limited to the preferred embodiments described above. Anyone can derive other products in various forms under the guidance of this invention. However, regardless of any changes in shape or structure, any technical solution that is the same as or similar to this application falls within the protection scope of this invention.

Claims

1. A method for multi-source data fusion and fault root cause analysis of an energy storage system, characterized in that, Includes the following steps: Step 1: Establish a semantic standard table to store the standard parameter name and its corresponding semantic vector code for each combination of device type code and parameter type code, and record the semantic description corresponding to each parameter type code; Step 2: Deploy the local inference model. When a fault alarm is triggered, query the time series data of the faulty device within a preset time window from the time series database, and assemble the time series data with the semantic descriptions corresponding to the parameter type codes in the semantic standard table into a prompt word and send it to the local inference model. The local inference model determines whether further analysis is needed. If the determination result is that no analysis is needed, the subsequent process is terminated and a log is recorded. If the determination result is that analysis is needed, proceed to the backend orchestration step. Step 3, during the backend orchestration process, recursively obtains the associated devices of the faulty device and constructs a device topology tree; obtains the parameter type code and corresponding semantic description of each associated device, and the cloud inference model summarizes the abnormal parameter information of the faulty device, the time series data of the associated devices, and the device topology relationship into a diagnostic context; Step 4: Send the diagnostic context to the cloud-based generation system, which will then generate a final diagnostic report containing root cause analysis and treatment recommendations.

2. The method of claim 1, wherein: In step one, when a new device is connected, the original parameter name of the new device is encoded using a semantic vector. The resulting semantic vector code is then matched with the stored semantic vector codes under the device type code of the new device in the semantic standard table using cosine similarity. This is used to classify the original parameter name of the new device as a standard parameter name.

3. The method of claim 1, wherein: In step three, the abnormal parameter information of the faulty equipment, the semantic description corresponding to the parameter type code of the associated equipment, and the equipment topology relationship are sent as context to the cloud inference model, which then filters out the equipment and its parameter type code that are related to the cause of the fault. Based on the filtering results, the time series data of the corresponding device is queried from the time series database, and the abnormal parameter information of the faulty device, the time series data of the filtered related devices, and the device topology relationship are summarized into a diagnostic context.

4. The method of claim 2, wherein: During the cosine similarity matching process, when the cosine similarity is greater than or equal to the first threshold, the original parameter name is classified as the corresponding standard parameter name; when the cosine similarity is between the first threshold and the second threshold, it is marked as the suggested classification of the corresponding standard parameter name and awaits confirmation; when the cosine similarity is less than or equal to the second threshold, it is marked as unclassified; the first threshold is greater than the second threshold.

5. The method of claim 1, wherein: In step two, when the local inference model determines whether further analysis is needed, it compares the time-series data in the prompt words with the range of judgment parameters point by point. If the data exceeds the range of judgment parameters, the model triggers a judgment result indicating that analysis is required.

6. The method of claim 5, wherein: The parameter range is determined by the following parameters in sequence: upper limit, upper limit, lower limit, and lower lower limit. When the time series data is between the upper limit and the upper limit, or between the lower limit and the lower lower limit, it is determined to be a parameter anomaly but no analysis is required. When the time series data is higher than the upper limit or lower than the lower lower limit, it is determined to be a parameter anomaly and analysis is required.

7. The method of claim 1, wherein: In step two, the preset time window is 5 minutes.

8. The method of claim 1, wherein: In step three, associating devices involves querying the device topology table and recursively obtaining all child devices and parent devices of the faulty device.

9. The method of claim 1, wherein: In step four, after receiving the diagnostic context, the cloud-based generation system retrieves relevant fault cases and maintenance documents from the cloud knowledge base, and generates a final diagnostic report containing root cause analysis and treatment recommendations based on the search results.

10. The method of claim 1, wherein: The semantic vector encoding in the semantic standard table is a fixed-dimensional floating-point vector generated by a sentence embedding model from the standard parameter names.

Images