A device fault diagnosis method, device, system, apparatus and medium

Abstract

This invention relates to the field of Internet technology, and in particular to a method, apparatus, system, device, and medium for diagnosing equipment faults. By acquiring fault phenomenon information and equipment operation data of a target device, the fault phenomenon information is retrieved and matched with a preset diagnostic knowledge graph to determine a target diagnostic template. Based on the equipment operation data, target platform adaptation parameters corresponding to the target device are determined. The template variables in the target diagnostic template are replaced and rendered using the target platform adaptation parameters to generate a target diagnostic script corresponding to the target device. Therefore, this application improves the efficiency of equipment fault diagnosis by introducing a mechanism combining diagnostic knowledge graphs and platform adaptation parameters to generate target diagnostic scripts for target devices, effectively reducing reliance on human experience and meeting the fault diagnosis needs of large-scale equipment clusters.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a method, apparatus, system, device, and medium for diagnosing equipment faults. Background Technology

[0002] With the development of technology and the continuous improvement of people's lives, the use of various smart terminals such as smart TVs is becoming more and more widespread. Rapid diagnosis of equipment faults has become a key link in ensuring the stable operation of the system.

[0003] However, existing equipment fault diagnosis solutions often rely heavily on manual experience in practical applications. Limited by the experience level of maintenance personnel, these solutions are prone to misdiagnosis and missed diagnosis, especially for complex, coupled faults. This results in slow response times and low troubleshooting efficiency, making it difficult to meet the fault diagnosis needs of large-scale equipment clusters. Therefore, improving the efficiency of equipment fault diagnosis to meet the needs of large-scale equipment clusters has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0004] Therefore, in order to address the above-mentioned technical problems, this invention provides a method, apparatus, system, device, and medium for equipment fault diagnosis, which improves the efficiency of equipment fault diagnosis and meets the fault diagnosis needs of large-scale equipment clusters.

[0005] A first aspect of this application provides a method for diagnosing equipment faults, the method comprising: Acquire fault information and equipment operation data of the target device; The fault phenomenon information is retrieved and matched with a preset diagnostic knowledge graph to determine the target diagnostic template; Based on the device operation data, the target platform adaptation parameters corresponding to the target device are determined; The template variables in the target diagnostic template are replaced and rendered using the target platform adaptation parameters to generate the target diagnostic script corresponding to the target device.

[0006] A second aspect of this application provides a device for diagnosing equipment faults, the device comprising: The acquisition module is used to acquire fault information and equipment operation data of the target device. The matching module is used to search and match the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template; The determination module is used to determine the target platform adaptation parameters corresponding to the target device based on the device operation data; The generation module is used to replace and render the template variables in the target diagnostic template using the target platform adaptation parameters, and generate the target diagnostic script corresponding to the target device.

[0007] A third aspect of this application provides a device fault diagnosis system, the device fault diagnosis system including a control system; The control system is used to acquire fault phenomenon information and equipment operation data of the target device; search and match the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template; determine the target platform adaptation parameters corresponding to the target device based on the equipment operation data; and replace and render the template variables in the target diagnostic template using the target platform adaptation parameters to generate the target diagnostic script corresponding to the target device.

[0008] Fourthly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the device fault diagnosis method as described in the first aspect.

[0009] Fifthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the device fault diagnosis method as described in the first aspect.

[0010] In summary, this invention provides a method, apparatus, system, device, and medium for equipment fault diagnosis. By acquiring fault phenomenon information and equipment operating data of the target equipment, the fault phenomenon information is retrieved and matched with a preset diagnostic knowledge graph to determine a target diagnostic template. Based on the equipment operating data, target platform adaptation parameters corresponding to the target equipment are determined. The template variables in the target diagnostic template are replaced and rendered using the target platform adaptation parameters to generate a target diagnostic script corresponding to the target equipment. Therefore, this application improves the efficiency of equipment fault diagnosis by introducing a mechanism combining diagnostic knowledge graphs and platform adaptation parameters to generate target diagnostic scripts for target equipment, effectively reducing reliance on human experience and meeting the fault diagnosis needs of large-scale equipment clusters. Attached Figure Description

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

[0012] Figure 1This is a schematic diagram of the structure of an equipment fault diagnosis system provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the debugging path mapping module structure in an equipment fault diagnosis system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a fault diagnosis knowledge graph structure in an equipment fault diagnosis system provided by an embodiment of the present invention; Figure 4 This is a schematic flowchart of a device fault diagnosis method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a device for diagnosing equipment faults according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0013] 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, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] It should be understood that, when used in this specification and the appended claims, terms include indicating the presence of the described feature, integral, step, operation, element and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0015] It should also be understood that the terms used in this specification and the appended claims refer to any combination of one or more of the associated listed items and all possible combinations, and include such combinations.

[0016] As used in this specification and the appended claims, terms if can be interpreted in context as when... or once or in response to determination. Similarly, the phrase if determined or if matched to [described condition or event] can be interpreted in context as once determined or in response to determination or once matched to [described condition or event] or in response to matching to [described condition or event].

[0017] Furthermore, in the description of this invention and the appended claims, the terms first, second, third, etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0018] References to one or more embodiments described in this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of the invention. Therefore, phrases appearing in different parts of this specification as referring to one embodiment, some embodiments, some other embodiments, and others do not necessarily refer to the same embodiment, but rather mean one or more, but not all, embodiments, unless otherwise specifically emphasized. The terms include, comprise, have, and variations thereof mean including but not limited to, unless otherwise specifically emphasized.

[0019] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0020] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0021] See Figure 1 , Figure 1 This invention provides a device fault diagnosis system, which includes a control system. The control system includes a running data identification layer, a platform parameter adaptation layer, a diagnostic knowledge template layer, and a script automatic generation layer. The running data identification layer can obtain the device running data of the target device, specifically including a probe command injection module and a response data module. The probe command injection module sends a standardized probe command sequence to the target device sequentially through a serial port. The probe command sequence includes: (1) obtaining the CPU model, hardware platform identifier string (Hardwarefield), and chip revision version; (2) obtaining the Linux kernel version number and compilation information; (3) obtaining the SoC series identifier; (4) obtaining the board / chip name in the Android system attributes (applicable to the Android TV platform); and (5) obtaining memory information to assist in determining the chip generation. Each probe command is equipped with an independent timeout waiting mechanism, which waits for 5 seconds by default. After the timeout, the current command is automatically skipped and the next command is executed, ensuring that the entire identification process is not blocked due to the lack of response to a certain command. The response data module receives the raw text data returned by the target device based on the probe command sequence and uses the raw text data as the device running data. Setting a timeout skip mechanism can ensure the stability of the detection process and adapt to the actual situation where some platforms do not respond to specific commands.

[0022] The platform parameter adaptation layer can determine the target platform adaptation parameters corresponding to the target device based on device operating data. That is, after the platform type is determined, it loads the complete set of diagnostic adaptation parameters corresponding to that platform, providing platform-related variable values ​​for the upper-layer diagnostic knowledge template. This layer contains three core modules: a serial port parameter configuration module, a debug path mapping module, and a command syntax adaptation module. The serial port parameter configuration module reads the serial communication parameters of the current platform from the fingerprint database and automatically fills them into the SecureCRT connection string template. It maintains default serial communication parameters for different chip platforms, including baud rate, data bits, stop bits, and parity, ensuring stable and reliable serial communication with the target device. Users can override the default values ​​through the front-end interface to adapt to special debugging scenarios. The debug path mapping module mainly maintains the debug file system path mapping table for each chip platform, i.e., debug path parameters. See [link to relevant documentation]. Figure 2 The debug path mapping module's structure diagram. The paths for PMIC (Power Management Integrated Circuit) registers, GPIO status nodes, interrupt statistics nodes, and power status nodes under ` / sys / ` and ` / sys / kernel / debug / ` differ across different chip platforms. This debug file system path mapping table is stored in JSON key-value pairs, where the keys are generic diagnostic path identifiers (such as "PMIC_STATUS_PATH", "GPIO_PATH", "INTERRUPT_PATH"), and the values ​​are the actual file system paths for that platform. The command syntax adaptation module handles the syntax differences between different platforms in the Shell environment and logging tools, i.e., command syntax parameters. For platforms running Android TV (such as Google TV), log collection uses the `logcat` command and supports parameters such as `-d` (exit after dumping) and `-ball` (collect all buffers); for platforms running native Linux systems (such as WebOS, Tizen, and some RTOS variants), log collection uses `dmesg`, `journalctl`, or `cat / var / log / syslog`. This module maintains a set of command syntax rules, storing each rule as a triple: platform type, target operation (e.g., LOG_CAPTURE / BOOT_LOG / POWER_LOG), and syntax template string. In the template string, (pattern) and (N) are runtime replacement placeholders, representing the keyword filtering mode and the number of rows to be truncated, respectively.

[0023] The diagnostic knowledge template layer is used to acquire fault phenomenon information of the target device and search and match the fault phenomenon information with the preset diagnostic knowledge graph to determine the target diagnostic template. It mainly includes the fault diagnosis knowledge graph and the template variable engine. The fault diagnosis knowledge graph is constructed using the "fault phenomenon—platform type—diagnostic step sequence" triple as the basic unit. See [link to relevant documentation]. Figure 3The structure diagram of the fault diagnosis knowledge graph. Fault phenomena are organized according to TV functional domains, including power-on (no power-on, stuck on logo during power-on, automatic power-off), display (black screen, distorted screen, flickering screen, backlight not working), power-on (abnormal standby power consumption, no response upon power-on, PMIC alarm), peripherals (no HDMI signal, USB not recognized, Bluetooth / WiFi malfunction), and system (repeated restarts, lag, application crashes). Each fault phenomenon is associated with one or more diagnostic step sequences. Each diagnostic step is an atomic unit, containing: step number, step description, Shell command template (where platform-related parameters are placed in the form of $ (variable name)), timeout, and expected result prompt. The template variable engine defines a standardized template variable system, abstracting platform-related elements in diagnostic commands into a finite set of variables. The core variables include: $(PMIC_PATH) — PMIC status read path, $(GPIO_PATH) — GPIO status read path, $(INTERRUPT_PATH) — interrupt statistics read path, $(POWER_SUPPLY_PATH) — power status path, $(LOG_CMD) — log collection command name and basic parameters, $(BOOT_LOG_CMD) — kernel boot log command, $(MEM_INFO_PATH) — memory information path, and $(UPTIME_CMD) — system runtime command. These variables are then parsed and populated from the parameter mapping table at runtime by the platform parameter adaptation layer based on the identified platform type.

[0024] Taking the "no power-on" fault as an example, its diagnostic template includes 6 diagnostic steps: (1) Kernel boot log: $(LOG_CMD)|head-100; (2) System uptime: $(UPTIME_CMD); (3) Power status detection: cat$(POWER_SUPPLY_PATH); (4) Power interrupt check: cat$(INTERRUPT_PATH)|grep-ipower; (5) PMIC register status: cat$(PMIC_PATH); (6) Boot / power related logs: $(LOG_CMD)|grep-iE"boot|init|power"|tail-50. When the target platform is identified as MTK, $(PMIC_PATH) is automatically filled with / sys / kernel / debug / pmic / *, and $(LOG_CMD) is automatically filled with logcat-d-ball; when the target platform is Amlogic, $(PMIC_PATH) is automatically filled with / sys / kernel / debug / aml_reg / *, and $(LOG_CMD) is automatically filled with dmesg. The same diagnostic template, driven by the template variable engine, can automatically adapt to different chip platforms.

[0025] The script auto-generation layer can replace and render template variables in the target diagnostic template using target platform adaptation parameters, generating a target diagnostic script corresponding to the target device, i.e., automatically generating a .vbs script file that can be directly run in SecureCRT. This includes a template rendering engine, which receives the target diagnostic template returned by the diagnostic knowledge template layer and the target platform adaptation parameters returned by the platform parameter adaptation layer, and performs template variable replacement. The rendering engine first iterates through each step in the target diagnostic template, performing regular expression replacement on the Shell command template in each step, replacing all $ (variable name) placeholders with the corresponding actual path or command string in the debug path parameter; then, based on the command syntax parameters, it automatically selects the appropriate log collection command format. If a variable in the debug path parameter has no corresponding value (e.g., the platform does not support a certain debug path), the rendering engine automatically marks that step as "skipped" and retains the step description as a comment in the generated script, ensuring uninterrupted script execution.

[0026] The architecture of the aforementioned equipment fault diagnosis system achieves full automation of the entire process, from equipment operation data acquisition and dynamic platform parameter adaptation to fault diagnosis logic matching and automatic diagnostic script generation. This system can quickly generate accurately adapted target diagnostic scripts for different chip platforms and operating system environments without human intervention, and output them as executable scripts. This significantly improves the efficiency of equipment fault diagnosis, effectively reduces reliance on human experience, and meets the fault diagnosis needs of large-scale equipment clusters. Simultaneously, the decoupling of each layer through standardized interfaces and variable systems ensures system scalability and facilitates flexible integration with subsequent additions of platform types or diagnostic rules.

[0027] It is understood that the structural diagrams of the equipment fault diagnosis system described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system structure and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0028] It can be seen that the above Figure 1 The system architecture shown is merely an example, and the embodiments in this application do not impose any specific limitations on it.

[0029] Referring to the figure, it is a schematic flowchart of a device fault diagnosis method provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the fault diagnosis method for this device can be implemented through the following steps.

[0030] S401: Obtain fault information and equipment operation data of the target device.

[0031] In one implementation, taking a target television as the target device, a standardized sequence of probe commands is sent sequentially to the target television via a serial port. This sequence includes data such as CPU model, hardware platform identifier string, chip revision, Linux kernel version number, compilation information, SoC series identifier, board / chip name from Android system properties, and memory information. The probe command sequence comprises multiple probe commands, each equipped with an independent timeout mechanism. The default wait time is 5 seconds; after a timeout, the current command is automatically skipped, and the next command is executed, ensuring that the entire identification process is not blocked due to a single unresponsive command. The system then receives the raw text data returned by the target television based on the probe command sequence and uses this raw text data as the device's operational data. Fault information about the target device can be obtained through an operation and maintenance management platform, device monitoring system, or user reporting interface. This fault information includes fault description text and fault characteristics, such as "TV does not turn on, power light is not on."

[0032] Furthermore, after acquiring fault phenomenon information and equipment operation data from the target device, the fault phenomenon information can be standardized and preprocessed, including text segmentation, stop word filtering, synonym normalization, and fault code mapping. This transforms unstructured natural language descriptions into standardized fault representations that the system can recognize. The equipment operation data is then cleaned and structured, removing invalid data and duplicate data, and uniformly converted into JSON-formatted structured data objects to ensure data consistency in subsequent processing. Through these steps, comprehensive collection and standardized processing of fault phenomenon information and equipment operation data are achieved, providing complete data input for subsequent diagnostic template matching and platform parameter identification, thereby ensuring the accuracy and stability of the fault diagnosis process.

[0033] S402: The fault phenomenon information is searched and matched with the preset diagnostic knowledge graph to determine the target diagnostic template.

[0034] In one implementation, the fault phenomenon information is searched and matched against a pre-built diagnostic knowledge graph to determine the target diagnostic template that best matches the current fault. This diagnostic knowledge graph is a structured knowledge network centered on fault nodes, linking diagnostic steps and troubleshooting logic. Each fault node in the graph corresponds to a typical fault phenomenon, and nodes are connected by edges indicating fault causality and troubleshooting sequence. Each fault node is also associated with a parameterized diagnostic template. The diagnostic template is written using a generalized scripting framework, where parts related to specific hardware platforms are placed using template variables, decoupling the diagnostic logic from platform details. It is primarily constructed using the triplet "fault phenomenon—platform type—diagnostic step sequence" as its basic unit. The fault symptoms are categorized by TV function domain, including power-on (no power on, stuck on logo during power-on, automatic power-off), display (black screen, distorted screen, flickering screen, backlight not working), power-on (abnormal standby power consumption, no response upon power-on, PMIC alarm), peripherals (no HDMI signal, USB not recognized, Bluetooth / WiFi malfunction), and system (repeated restarts, lag, application crashes).

[0035] Furthermore, the system first performs precise matching based on fault keywords. If a corresponding fault node in the knowledge graph is matched, the diagnostic template associated with that node is directly obtained. If no precise match is found, the system retrieves the most similar fault node in the knowledge graph through semantic similarity calculation, and recommends candidate diagnostic templates based on similarity ranking. After manual confirmation or automatic scoring, the optimal template is selected. Through these steps, an automatic mapping from fault symptoms to diagnostic logic is achieved. This enables the rapid determination of the optimal diagnostic process based on fault symptoms, avoiding the subjectivity and experience dependence of manual selection of diagnostic solutions, significantly improving the accuracy of fault diagnosis, and laying a template foundation for subsequent cross-platform adaptation.

[0036] S403: Based on the device operation data, determine the target platform adaptation parameters corresponding to the target device.

[0037] In one implementation, after receiving device operation data returned based on the probe command sequence, a multi-dimensional fingerprint feature is extracted from the device operation data using a regular expression matching strategy. This multi-dimensional fingerprint feature is then used to form a fingerprint feature vector. If a fingerprint feature is missing, the corresponding vector component is set to empty, without affecting subsequent matching. Subsequently, this fingerprint feature vector is matched against a pre-built fingerprint database. This database stores standard fingerprint feature vectors for various target platforms under different firmware versions and hardware configurations in a JSON structured format. The database includes information such as platform name, platform codename, chip manufacturer, CPU model regular expression, Hardware field keywords, kernel version features, SoC series identifier, serial port default parameters (baud rate, data bits, parity bits, stop bits), debug file system root path, and default login credentials. The matching algorithm employs a weighted multi-feature voting strategy. Each component of the fingerprint feature vector is compared with each candidate fingerprint in the fingerprint database. If a match is successful, the weight corresponding to that component is accumulated. Finally, the platform with the highest weighted score is selected as the identification result, and the target platform adaptation parameters corresponding to that target platform type are determined, thereby achieving accurate cross-platform compatibility adaptation. A minimum pre-set reliability threshold of 60% is set. If the highest score is lower than the threshold, the system will prompt "No known platform identified, please select manually" and list candidate platforms for engineers to confirm manually, thus avoiding misjudgment. It should be noted that the specific pre-set reliability threshold can be set according to the actual situation, and this application does not impose any restrictions on it.

[0038] Platform adaptation parameters are a set of configuration parameters related to specific hardware platforms, operating systems, and debugging environments, including platform-related implementation details such as serial communication parameters, debugging path parameters, command syntax parameters, permission configuration parameters, and log path parameters.

[0039] Specifically, the system extracts multi-dimensional fingerprint features from device operating data, including operating system type and version, kernel version number, CPU architecture, device tree information, system directory structure features, installed toolchain versions, and command return format features. This fingerprint feature vector is then matched against a pre-defined fingerprint database to automatically identify the target device's platform type, such as embedded Linux, Android, VxWorks, Windows IoT, and RT-Thread. Based on the identified platform type, a pre-defined mapping relationship is queried to obtain the corresponding target platform adaptation parameters. These parameters are a set of configuration parameters related to the specific hardware platform, operating system, and debugging environment, including platform-related implementation details such as serial communication parameters, debugging path parameters, and command syntax parameters. When the fingerprint matching confidence is insufficient, the system also supports prompting maintenance personnel to manually confirm the platform type via an interactive interface to ensure the accuracy of platform identification. Through these steps, automatic identification of device platform types and accurate acquisition of adaptation parameters are achieved, enabling subsequent diagnostic templates to automatically adapt to devices from different manufacturers and models without manual configuration of platform parameters, thus significantly improving the cross-platform reusability of diagnostic scripts.

[0040] S404: Use the target platform adaptation parameters to replace and render the template variables in the target diagnostic template to generate the target diagnostic script corresponding to the target device.

[0041] In one implementation, the determined target platform adaptation parameters are used as context variables. The target diagnostic template undergoes variable replacement and rendering to generate a target diagnostic script that can be directly executed on the target device platform. By using the rendering engine to parse variable placeholders and control tags in the diagnostic template, placeholders such as general path variables and command syntax variables are replaced with specific parameter values ​​corresponding to the target platform. Simultaneously, the rendering engine conditionally renders the corresponding command branches and syntax formats based on platform characteristics. If a variable in the parameter mapping table has no corresponding value (e.g., the platform does not support a certain debugging path), the rendering engine automatically marks that step as "skipped" and retains a step description as a comment in the generated script, ensuring uninterrupted script execution. Finally, after rendering, the system automatically assembles the generated script into a complete target diagnostic script according to preset script syntax specifications. Through these steps, automatic conversion from a general diagnostic template to a platform-specific executable script is achieved, significantly reducing the amount of repetitive development work for diagnostic scripts, thereby ensuring the syntactic correctness of the generated script and effectively improving the accuracy and efficiency of device fault diagnosis.

[0042] In summary, this invention provides a method, apparatus, system, device, and medium for equipment fault diagnosis. By acquiring fault phenomenon information and equipment operating data of the target equipment, the fault phenomenon information is retrieved and matched with a preset diagnostic knowledge graph to determine a target diagnostic template. Based on the equipment operating data, target platform adaptation parameters corresponding to the target equipment are determined. The template variables in the target diagnostic template are replaced and rendered using the target platform adaptation parameters to generate a target diagnostic script corresponding to the target equipment. Therefore, this application improves the efficiency of equipment fault diagnosis by introducing a mechanism combining diagnostic knowledge graphs and platform adaptation parameters to generate target diagnostic scripts for target equipment, effectively reducing reliance on human experience and meeting the fault diagnosis needs of large-scale equipment clusters.

[0043] In one embodiment, specifically in step S402, which involves searching and matching the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template, the following steps are included: Keyword extraction is performed on the fault phenomenon information to obtain a fault keyword set; The set of fault keywords is searched and matched with fault nodes in the preset diagnostic knowledge graph to obtain matching results; If the matching result is that there is no completely matching fault node, then the semantic similarity between the fault phenomenon information and each fault node in the diagnostic knowledge graph is calculated, and the candidate diagnostic sequence templates are obtained by sorting them in descending order of semantic similarity. According to the preset screening rules, the diagnostic template with the highest score will be selected from the candidate diagnostic sequence templates and determined as the target diagnostic template. If the matching result shows that there is a completely matching fault node, then the diagnostic template associated with the fault node is determined as the target diagnostic template.

[0044] In one implementation, a keyword extraction algorithm combining dictionary and statistical methods is first employed. In conjunction with a professional dictionary of fault characteristics, word segmentation, part-of-speech tagging, and named entity recognition are performed on the fault phenomenon information to extract key entity words such as fault location, fault type, fault manifestation, and fault code. Simultaneously, stop words and interjections without practical diagnostic significance are filtered out, ultimately yielding a set of fault keywords representing the core features of the fault. For example, for the fault description "The link light on the device's eth0 network port is not lit and cannot obtain an IP address," the extracted keyword set includes core words such as "eth0," "network port," "link light," "not lit," and "cannot obtain IP." The fault keyword set is then searched and matched with fault nodes in a pre-defined diagnostic knowledge graph to obtain the matching results.

[0045] Furthermore, each fault node in the diagnostic knowledge graph is pre-labeled with a corresponding set of keywords. The system calculates the intersection of the extracted fault keyword set and the tag set of each node, and performs TF-IDF weighted matching. If a fault node has a complete keyword match or a matching degree that reaches a preset threshold, it is determined to be a completely matched fault node, and the diagnostic template associated with that fault node is directly determined as the target diagnostic template. If the matching result is that no completely matched fault node exists, the semantic similarity between the fault phenomenon information and each fault node in the diagnostic knowledge graph is further calculated. Specifically, a pre-trained domain language model is used to encode the fault phenomenon text and the description text of each fault node into semantic vectors. The semantic similarity score is obtained by calculating the cosine similarity between the vectors. Candidate diagnostic sequence templates are obtained by sorting them in descending order of similarity score. Then, according to preset screening rules, the candidate templates are comprehensively scored by considering factors such as semantic similarity score, fault node priority, historical usage frequency, and diagnostic success rate. The diagnostic template with the highest score is selected as the target diagnostic template. At the same time, the Top N candidate template list can also be pushed to the operation and maintenance personnel for manual confirmation and selection, further improving the accuracy of template matching. Through the above steps, flexible adaptation to new fault scenarios is achieved, avoiding matching failures caused by non-standard fault descriptions or the failure to record new faults in the atlas. While ensuring matching efficiency, the matching accuracy of the target diagnostic template is improved.

[0046] In one embodiment, specifically step S403, which involves determining the target platform adaptation parameters corresponding to the target device based on the device operating data, the following steps are included: Multidimensional feature extraction is performed on the device operation data to obtain a fingerprint feature vector; The fingerprint feature vector is weighted and calculated with a preset fingerprint database to obtain the matching confidence of the fingerprint feature vector with each candidate fingerprint in the preset fingerprint database. If the matching confidence is greater than or equal to the preset confidence threshold, then the candidate platform type corresponding to the highest matching confidence is determined as the target platform type; Based on the target platform type and the pre-defined mapping relationship, the target platform adaptation parameters corresponding to the target device are determined, wherein the mapping relationship is the pre-defined correspondence between platform type and platform adaptation parameters.

[0047] In one implementation, multi-dimensional feature extraction is first performed on the device's operational data to obtain multi-dimensional fingerprint features. These multi-dimensional fingerprint features include operating system type and version, kernel version number, CPU architecture, device tree information, system directory structure features, installed toolchain versions, command return formats, and other fingerprint features. Each fingerprint feature is normalized and encoded, converting discrete features into one-hot vectors and standardizing numerical features. Finally, these are concatenated to form a fixed-dimensional fingerprint feature vector, which uniquely identifies the platform identity of the target device. The fingerprint feature vector is then weighted and calculated against a pre-defined fingerprint database to obtain the matching confidence score between the fingerprint feature vector and each candidate fingerprint in the database. This fingerprint database stores standard fingerprint feature vectors for various target platforms under different firmware versions and hardware configurations in a JSON structured format. It includes information such as platform name, platform codename, chip manufacturer, CPU model regular expression, Hardware field keywords, kernel version characteristics, SoC series identifier, serial port default parameters (baud rate, data bits, parity bits, stop bits), debug file system root path, and default login credentials. The matching algorithm employs a weighted multi-feature voting strategy. It compares each component of the fingerprint feature vector with candidate fingerprints in the database. If a match is found, the weight corresponding to that component is accumulated. Finally, the platform with the highest weighted score is selected as the identification result, and the target platform adaptation parameters corresponding to that target platform type are determined, thereby achieving accurate cross-platform compatibility adaptation.

[0048] Furthermore, if the matching confidence level is greater than or equal to a preset confidence threshold (e.g., 0.85), the candidate platform type corresponding to the highest matching confidence level is determined as the target platform type. Based on the determined target platform type, a pre-defined platform parameter mapping table is queried. This table pre-inputs a complete set of platform adaptation parameters for each platform type, including serial communication parameters such as serial port baud rate, data bits, and parity bits; debugging path parameters such as / dev, / proc, and / sys; and command syntax parameters under different shells. The corresponding parameter set is directly extracted as the target platform adaptation parameters. Through these steps, automatic identification of the target platform type and accurate matching of platform adaptation parameters are achieved without manual configuration of platform information. This allows the diagnostic script to automatically adapt to different hardware platforms, thereby providing an accurate runtime environment context for subsequent fault diagnosis modules.

[0049] In one embodiment, that is, after obtaining the matching confidence of the fingerprint feature vector with each candidate fingerprint in the preset fingerprint database, the following steps are included: If the matching confidence level is less than the preset confidence threshold, a platform confirmation request is generated. Receive a manual selection instruction triggered based on the platform confirmation request, and determine the candidate platform type specified by the manual selection instruction as the target platform type; Based on the target platform type and the pre-defined mapping relationship, the target platform adaptation parameters corresponding to the target device are determined, wherein the mapping relationship is the pre-defined correspondence between platform type and platform adaptation parameters.

[0050] In one implementation, if the matching confidence score is less than a preset confidence threshold, it indicates that the target device's platform characteristics are not typical enough. This could be a new model device, a customized system, or a platform not covered by the fingerprint database. In this case, instead of forcibly making an automatic determination, a platform confirmation request is generated. This platform confirmation request includes key feature information of the current device, a list of the top 3 candidate platform types with the highest confidence scores, and a matching degree description for each candidate platform. This platform confirmation request can be pushed to the responsible operations and maintenance personnel through the message notification channel of the operations and maintenance management platform, using various notification methods such as in-platform messages, email, and WeChat Work.

[0051] Furthermore, after receiving a confirmation request from the platform, maintenance personnel can select the correct platform type from the candidate platform list based on the actual hardware model and operating system information of the device, or manually enter the information for a newly added platform type to trigger a manual selection command. Upon receiving this manual selection command, the candidate platform type specified in the command is determined as the target platform type. Simultaneously, the device fingerprint and corresponding platform type confirmed in this manual selection are automatically added to a preset fingerprint database for incremental learning. This allows for automatic identification when encountering devices with the same characteristics, enabling continuous iterative optimization of the fingerprint database. After determining the target platform type, the pre-defined mapping relationship is queried to determine the target platform adaptation parameters corresponding to the target device. If a newly added platform type is manually selected and there are no corresponding parameters in the mapping table, maintenance personnel must be guided to enter the adaptation parameters for the new platform and save them to the mapping database. Through these steps, the accuracy of platform identification is ensured, avoiding the generation of incorrect diagnostic scripts due to misidentification, thereby improving the reliability and compatibility of fault diagnosis.

[0052] In one embodiment, specifically in step S404, which involves replacing and rendering the template variables in the target diagnostic template using the target platform adaptation parameters to generate the target diagnostic script corresponding to the target device, the following steps are included: The target diagnostic template is parsed to determine the general path variables and command syntax variables; Based on the serial communication parameters, debugging path parameters, and command syntax parameters in the platform adaptation parameters, the general path variables and the command syntax variables are replaced and rendered to generate an initial diagnostic script. Based on the preset script specifications, the initial diagnostic script is assembled and encoded to generate the target diagnostic script corresponding to the target device.

[0053] In one implementation, the platform adaptation parameters specifically include three main categories: serial communication parameters, debug path parameters, and command syntax parameters. Serial communication parameters include serial port device node path, baud rate, data bits, stop bits, parity check, and flow control settings, used to adapt to differences in serial port debugging connections across different platforms. Debug path parameters include system log path, proc file system mount point, sysfs path, temporary file directory, and diagnostic result output path, used to adapt to differences in directory structure across different operating systems. Command syntax parameters include shell type, command parameter format, output field separator, privilege escalation commands, and return value judgment rules, used to adapt to syntax differences in command-line environments across different platforms. First, the target diagnostic template undergoes lexical and syntactic parsing to identify common path variables and command syntax variables defined in the template. For example, common path variables include console device path, proc file path, and other file system path-related variables; command syntax variables include command prompt, command suffix, error prefix, line terminator, and other command format-related variables; in addition, there are serial port-related variables, etc. The parsing process constructs an abstract syntax tree for the template, recording the position and type of each variable.

[0054] Furthermore, based on the serial communication parameters, debugging path parameters, and command syntax parameters in the platform adaptation parameters, the variable placeholders in the template are replaced one by one during rendering. This involves replacing general path variables with the actual absolute paths corresponding to the target platform, replacing serial port-related variables with specific serial port device nodes and communication parameters, and replacing command syntax variables with the actual command and parameter formats available on that platform, thus generating the initial diagnostic script. The template engine also supports conditional rendering, automatically enabling or disabling certain diagnostic command branches based on the platform type. For example, using simplified command parameters in the BusyBox environment and full parameters in the GNU environment. Based on preset script specifications, the initial diagnostic script is assembled and coded to obtain the target diagnostic script. The specific initial diagnostic script includes the following components in sequence: (1) SecureCRT script header declaration (#$language="VBScript", #$interface="1.0"); (2) script metadata comment block (generation time, fault description, target platform type); (3) variable definition area (log save path, file system object); (4) serial port connection establishment area (constructing Connect call using platform-adapted serial port parameters); (5) log recording enable area; (6) diagnostic command execution loop area—each diagnostic step expands to crt.Screen.Send to send commands, crt.Screen.WaitForString to wait for response, and loops to the next step; (7) log closing and completion prompt area. By strictly following the SecureCRT 8.x VBScript interface specification, the generated script can be directly loaded and run in the SecureCRTScript-Run menu. As can be seen, by setting the correct file permission bits, organizing function definitions and main flow structures according to specifications, unifying indentation format and encoding style, and selecting the corresponding newline characters and file encoding formats based on the target platform (e.g., using UTF-8 encoding and LF newlines on Linux platforms, and GBK encoding and CRLF newlines on Windows platforms), a standardized target diagnostic script that can be directly executed on the target device is finally generated. Through these steps, precise replacement of template variables is achieved, quickly and accurately generating the target diagnostic script, ensuring the executableness of the generated script on different platforms, and further enhancing cross-platform adaptability.

[0055] In one embodiment, that is, after step S404, i.e. after generating the target diagnostic script corresponding to the target device, the following steps are included: Perform syntax compliance checks on the target diagnostic script and obtain the check results; If the verification result is that the verification passes, then the target diagnostic script is executed; If the verification result is that the verification fails, a syntax error message is generated, and the step of replacing and rendering the template variables in the target diagnostic template using the target platform adaptation parameters is re-executed.

[0056] In one implementation, after generating the target diagnostic script but before its formal execution, the script needs to undergo syntax compliance verification to obtain the verification results. The verification process includes two levels: static syntax checking and runtime environment pre-checking. Static syntax checking calls the corresponding syntax checking tool based on the script type. For example, a shell script calls the shellcheck tool for syntax scanning, while a Python script calls the py_compile module for compilation checks. The checks include syntax errors, unclosed quotes, undefined variables, missing commands, and invalid paths. Runtime environment pre-checking verifies whether critical commands referenced in the script exist in the target platform's adaptation parameters, whether critical paths are accessible, and whether serial port device nodes are valid.

[0057] Furthermore, if the verification result is successful, indicating that the script syntax is correct and the runtime environment meets the requirements, the target diagnostic script will be automatically sent to the target device through the corresponding channel, execution permissions will be set, and execution will begin. The script file can be downloaded via a browser, or the script content can be directly pasted into the SecureCRT script editor to load and run. At this time, the serial port connection will be automatically established, and diagnostic commands will be sent and executed one by one in a preset order. The output of each command will be recorded in real time to the log file. After all diagnostic commands have been executed, the script will automatically close the log recording and pop up a completion prompt dialog box, displaying the log file save path. If the verification result is unsuccessful, a detailed syntax error message will be generated, indicating the line number of the error, the error type, and the correction suggestion, and the re-rendering process will be automatically triggered. During re-rendering, relevant parameters can be automatically adjusted according to the error type or rolled back to the parameter configuration of the previous stable version, and the variable substitution and script generation steps will be re-executed for verification again, forming an automatic error correction closed loop of "rendering-verification-re-rendering". If the verification still fails after multiple re-renderings, the error information will be reported to the maintenance personnel for manual intervention and correction. By following the steps above, we can effectively avoid the problem of scripts with syntax errors being sent to devices, which could lead to execution failures or system anomalies. This reduces the workload of manually debugging scripts and improves the reliability and security of the automated diagnostic process.

[0058] For example, if there are encoding compatibility issues after the generated target diagnostic script is verified, several steps need to be performed, namely: (1) Add UTF-8 BOM (ByteOrderMark, EFBBBF) to the beginning of the file to ensure that the Windows VBScript engine correctly parses Chinese characters; (2) Ensure that there are no spaces between # and $ in the SecureCRT script header declaration (i.e., "#$language" instead of "#$language") to avoid the VBScript engine misinterpreting # as a date literal prefix, resulting in a compilation error; (3) Strictly arrange the parameter order of the crt.Dialog.MessageBox method according to the SecureCRT specification as "message, title, button type" to avoid runtime type mismatch errors; (4) Replace UnicodeEmoji characters with pure ASCII text marks to avoid garbled characters in non-Unicode environments; (5) Replace the VBScript constant combination operator from addition (+) to bitwise OR (Or). Although the two are numerically equivalent, Or is the standard VBScript convention to avoid potential type casting exceptions. It can completely avoid common problems such as compilation errors caused by missing BOM and runtime exceptions caused by incorrect parameter order. The generated target diagnostic script contains complete metadata comments and platform identifiers, which facilitates later auditing and script version management.

[0059] Please see Figure 5 , Figure 5 This is a schematic diagram of the equipment fault diagnosis device provided in an embodiment of the present invention. This equipment fault diagnosis device corresponds one-to-one with the equipment fault diagnosis methods in the above embodiments. Please refer to [link / reference] for details. Figure 4 as well as Figure 4 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 5 The equipment fault diagnosis device 50 includes: an acquisition module 51, a matching module 52, a determination module 53, and a generation module 54.

[0060] The acquisition module 51 is used to acquire fault phenomenon information and equipment operation data of the target device; The matching module 52 is used to search and match the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template; The determining module 53 is used to determine the target platform adaptation parameters corresponding to the target device based on the device operation data; The generation module 54 is used to replace and render the template variables in the target diagnostic template using the target platform adaptation parameters, and generate the target diagnostic script corresponding to the target device.

[0061] Optionally, the matching module 52 described above is specifically used for: Keyword extraction is performed on the fault phenomenon information to obtain a fault keyword set; The set of fault keywords is searched and matched with fault nodes in the preset diagnostic knowledge graph to obtain matching results; If the matching result is that there is no completely matching fault node, then the semantic similarity between the fault phenomenon information and each fault node in the diagnostic knowledge graph is calculated, and the candidate diagnostic sequence templates are obtained by sorting them in descending order of semantic similarity. According to the preset screening rules, the diagnostic template with the highest score will be selected from the candidate diagnostic sequence templates and determined as the target diagnostic template. If the matching result shows that there is a completely matching fault node, then the diagnostic template associated with the fault node is determined as the target diagnostic template.

[0062] Optionally, the aforementioned determining module 53 is specifically used for: Multidimensional feature extraction is performed on the device operation data to obtain a fingerprint feature vector; The fingerprint feature vector is weighted and calculated with a preset fingerprint database to obtain the matching confidence of the fingerprint feature vector with each candidate fingerprint in the preset fingerprint database. If the matching confidence is greater than or equal to the preset confidence threshold, then the candidate platform type corresponding to the highest matching confidence is determined as the target platform type; Based on the target platform type and the pre-defined mapping relationship, the target platform adaptation parameters corresponding to the target device are determined, wherein the mapping relationship is the pre-defined correspondence between platform type and platform adaptation parameters.

[0063] Optionally, the aforementioned determining module 53 is further configured to: If the matching confidence level is less than the preset confidence threshold, a platform confirmation request is generated. Receive a manual selection instruction triggered based on the platform confirmation request, and determine the candidate platform type specified by the manual selection instruction as the target platform type; Based on the target platform type and the pre-defined mapping relationship, the target platform adaptation parameters corresponding to the target device are determined, wherein the mapping relationship is the pre-defined correspondence between platform type and platform adaptation parameters.

[0064] Optionally, the above-mentioned generation module 54 is specifically used for: The platform adaptation parameters include serial communication parameters, debugging path parameters, and command syntax parameters. The target diagnostic template is parsed to determine the general path variables and command syntax variables; Based on the serial communication parameters, debugging path parameters, and command syntax parameters in the platform adaptation parameters, the general path variables and the command syntax variables are replaced and rendered to generate an initial diagnostic script. Based on the preset script specifications, the initial diagnostic script is assembled and encoded to generate the target diagnostic script corresponding to the target device.

[0065] Optionally, after the above-mentioned generation module 54, it is specifically used for: Perform syntax compliance checks on the target diagnostic script and obtain the check results; If the verification result is that the verification passes, then the target diagnostic script is executed; If the verification result is that the verification fails, a syntax error message is generated, and the step of replacing and rendering the template variables in the target diagnostic template using the target platform adaptation parameters is re-executed.

[0066] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0067] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 6 As shown, the electronic device of this embodiment includes: at least one processor ( Figure 6 The diagram shows only one of the following: a memory and a computer program stored in the memory and capable of running on at least one processor. When the processor executes the computer program, it implements the steps in any of the above-described embodiments of the device fault diagnosis method.

[0068] The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 6 This is merely an example of an electronic device and does not constitute a limitation on electronic devices. Electronic devices may include more or fewer components than shown, or combinations of certain components, or different components, such as network interfaces, displays, and input systems.

[0069] In one embodiment, a computer-readable storage medium is provided that, when the instructions in the computer-readable storage medium are executed by a processor in an electronic device, enables the electronic device to perform the steps of any embodiment of the device fault diagnosis method disclosed in this invention, which will not be repeated here. The computer-readable storage medium may be non-volatile or volatile.

[0070] The processor referred to can be a CPU, but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0071] Memory includes readable storage media, internal memory, etc., wherein internal memory can be the RAM of an electronic device, providing an environment for the operation of the operating system and computer-readable instructions stored in the readable storage media. The readable storage media can be the hard drive of an electronic device, or in other embodiments, it can be an external storage device of the electronic device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, memory can include both internal storage units and external storage devices of the electronic device. Memory is used to store the operating system, cooperative applications, bootloader, data, and other programs, such as program code of computer programs. Memory can also be used to temporarily store data that has been output or will be output.

[0072] Those skilled in the art will understand that implementing all or part of the processes in the methods of the above embodiments can be accomplished by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0073] Those skilled in the art will understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this invention. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0074] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for diagnosing equipment faults, characterized in that, include: Acquire fault information and equipment operation data of the target device; The fault phenomenon information is retrieved and matched with a preset diagnostic knowledge graph to determine the target diagnostic template; Based on the device operation data, the target platform adaptation parameters corresponding to the target device are determined; The template variables in the target diagnostic template are replaced and rendered using the target platform adaptation parameters to generate the target diagnostic script corresponding to the target device.

2. The equipment fault diagnosis method as described in claim 1, characterized in that, The step of searching and matching the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template includes: Keyword extraction is performed on the fault phenomenon information to obtain a fault keyword set; The set of fault keywords is searched and matched with fault nodes in the preset diagnostic knowledge graph to obtain matching results; If the matching result is that there is no completely matching fault node, then the semantic similarity between the fault phenomenon information and each fault node in the diagnostic knowledge graph is calculated, and the candidate diagnostic sequence templates are obtained by sorting them in descending order of semantic similarity. According to the preset screening rules, the diagnostic template with the highest score will be selected from the candidate diagnostic sequence templates and determined as the target diagnostic template. If the matching result shows that there is a completely matching fault node, then the diagnostic template associated with the fault node is determined as the target diagnostic template.

3. The equipment fault diagnosis method as described in claim 1, characterized in that, The step of determining the target platform adaptation parameters corresponding to the target device based on the device operating data includes: Multidimensional feature extraction is performed on the device operation data to obtain a fingerprint feature vector; The fingerprint feature vector is weighted and calculated with a preset fingerprint database to obtain the matching confidence of the fingerprint feature vector with each candidate fingerprint in the preset fingerprint database. If the matching confidence is greater than or equal to the preset confidence threshold, then the candidate platform type corresponding to the highest matching confidence is determined as the target platform type; Based on the target platform type and the pre-defined mapping relationship, the target platform adaptation parameters corresponding to the target device are determined, wherein the mapping relationship is the pre-defined correspondence between platform type and platform adaptation parameters.

4. The equipment fault diagnosis method as described in claim 3, characterized in that, After obtaining the matching confidence score between the fingerprint feature vector and each candidate fingerprint in the preset fingerprint database, the process includes: If the matching confidence level is less than the preset confidence threshold, a platform confirmation request is generated. Receive a manual selection instruction triggered based on the platform confirmation request, and determine the candidate platform type specified by the manual selection instruction as the target platform type; Based on the target platform type and the pre-defined mapping relationship, the target platform adaptation parameters corresponding to the target device are determined, wherein the mapping relationship is the pre-defined correspondence between platform type and platform adaptation parameters.

5. The equipment fault diagnosis method as described in claim 1, characterized in that, The platform adaptation parameters include serial communication parameters, debugging path parameters, and command syntax parameters. The step of using the target platform adaptation parameters to replace and render template variables in the target diagnostic template to generate the target diagnostic script corresponding to the target device includes: The target diagnostic template is parsed to determine the general path variables and command syntax variables; Based on the serial communication parameters, debugging path parameters, and command syntax parameters in the platform adaptation parameters, the general path variables and the command syntax variables are replaced and rendered to generate an initial diagnostic script. Based on the preset script specifications, the initial diagnostic script is assembled and encoded to generate the target diagnostic script corresponding to the target device.

6. The equipment fault diagnosis method as described in claim 1, characterized in that, After generating the target diagnostic script corresponding to the target device, the process includes: Perform syntax compliance checks on the target diagnostic script and obtain the check results; If the verification result is that the verification passes, then the target diagnostic script is executed; If the verification result is that the verification fails, a syntax error message is generated, and the step of replacing and rendering the template variables in the target diagnostic template using the target platform adaptation parameters is re-executed.

7. A device for diagnosing equipment faults, characterized in that, include: The acquisition module is used to acquire fault information and equipment operation data of the target device. The matching module is used to search and match the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template; The determination module is used to determine the target platform adaptation parameters corresponding to the target device based on the device operation data; The generation module is used to replace and render the template variables in the target diagnostic template using the target platform adaptation parameters, and generate the target diagnostic script corresponding to the target device.

8. A device fault diagnosis system, characterized in that, The equipment fault diagnosis system includes a control system; The control system is used to acquire fault phenomenon information and equipment operation data of the target equipment; and to search and match the fault phenomenon information with a preset diagnostic knowledge graph to determine the target diagnostic template. Based on the device operation data, the target platform adaptation parameters corresponding to the target device are determined; the template variables in the target diagnostic template are replaced and rendered using the target platform adaptation parameters to generate the target diagnostic script corresponding to the target device.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the device fault diagnosis method as described in any one of claims 1 to 6.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the device fault diagnosis method as described in any one of claims 1 to 6.

Images