An integrated information automation supervisory system and method for edge devices

Abstract

This invention discloses an integrated information automated monitoring system and method for edge devices, relating to the field of edge computing technology. The system's edge node management module connects to edge devices, generates basic attributes, and deploys containerized applications. A real-time monitoring and diagnostic module collects device operating data, identifies anomalies, locates fault types, and triggers alarms. An automated policy generation module generates customized repair policies. A MESH communication and repair execution module constructs an edge device self-organizing network, enabling online and offline policy transmission and execution of repair instructions. A solution knowledge base module stores device fault types, historical repair cases, and policy templates, and updates policy matching logic. An application deployment management module encapsulates applications using container images and distributes them to edge nodes in batches according to scenario templates. A centralized management module visually displays device status, fault alarms, and policy execution records, providing manual intervention and global policy configuration.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, specifically to an integrated information automated monitoring system and method for edge devices. Background Technology

[0002] In edge computing scenarios, traditional edge device management methods face multi-dimensional technical bottlenecks. On the one hand, edge devices are diverse in type and heterogeneous in protocol (such as Modbus, MQTT, etc.). Existing systems lack a unified device access and identification management mechanism, resulting in the inability to standardize the storage of basic device attributes (such as model, protocol, configuration parameters). Containerized application deployment processes are also inefficient due to the lack of automated parsing tools (such as YAML manifest parsing and image repository retrieval mechanisms), making it difficult to meet the rapid deployment requirements of large-scale edge nodes. On the other hand, real-time monitoring capabilities are limited to single parameter threshold detection (such as monitoring only energy consumption values), lacking multi-modal data fusion analysis of working status and log information. Furthermore, fault diagnosis relies on preset rules and cannot achieve intelligent extraction and accurate location of abnormal features through algorithmic models (such as support vector machines), leading to delayed fault type identification and failure to trigger timely repair processes with alarm information.

[0003] Furthermore, traditional systems suffer from significant deficiencies in fault repair: repair strategy generation relies on human experience and lacks automated matching mechanisms based on historical cases (such as K-nearest neighbor algorithm for knowledge base retrieval), making it difficult to quickly generate customized scripts; edge device communication is susceptible to network environment fluctuations, with significant policy transmission interruptions in offline states, and a lack of secure transmission mechanisms (such as AES encryption and digital signature verification); the solution knowledge base cannot achieve self-updating of policy matching logic through machine learning (such as gradient boosting tree algorithm for model optimization), resulting in low utilization of historical cases and the inability of system overreach repair efficiency to improve with data accumulation. Simultaneously, the centralized management interface lacks multi-dimensional visualization capabilities (such as energy consumption curves and status dashboards), and the manual intervention interface lacks real-time and permission verification mechanisms, making it difficult to achieve dynamic configuration and operation traceability of global policies.

[0004] To address the above problems, this invention proposes an integrated information automated monitoring system and method for edge devices. Summary of the Invention

[0005] The purpose of this invention is to provide an integrated information automated monitoring system and method for edge devices, in order to solve the problems raised in the prior art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] An integrated information automation monitoring system for edge devices includes an edge node management module, a real-time monitoring and diagnostic module, an automated policy generation module, a MESH communication and repair execution module, a solution knowledge base module, an application deployment management module, and a centralized control module. The edge node module is used for unified access to edge devices, generating unique device identifiers, recording basic attributes such as model, protocol, and configuration parameters, and deploying containerized applications. The real-time monitoring and diagnostic module continuously collects device operating data, including energy consumption, operating status, and log information, and analyzes it through preset rules and algorithms to identify anomalies, locate fault types, and trigger alarms. The automated policy generation module... Based on fault diagnosis results, device configuration parameters, and knowledge base cases, customized repair strategies are generated. The MESH communication and repair execution module constructs an edge device self-organizing network to achieve policy transmission and execution of repair instructions in both online and offline states. The solution knowledge base module stores device fault types, historical repair cases, and policy templates, and updates the policy matching logic through machine learning. The application deployment management module encapsulates applications, including energy consumption monitoring software and device management tools, into container images and distributes them to edge nodes in batches according to scenario templates. The centralized management module is used to visually display device status, fault alarms, and policy execution records, and provides a manual intervention and global policy configuration interface.

[0008] The edge node management module includes a device information management unit and an application deployment execution unit;

[0009] The device information management unit is responsible for building a multi-protocol compatible device access interface, assigning a globally unique UUID to each edge device as a device identifier, and storing basic attributes such as device model, communication protocol, and configuration parameters in a structured manner in preset fields of the embedded database to form a device information ledger.

[0010] The application deployment execution unit is responsible for parsing the YAML format containerized deployment manifest issued by the cloud, pulling the corresponding container image file from the specified image repository, calling the underlying virtualization engine through the container runtime interface, completing container instantiation according to the port mapping and storage volume mount parameters defined in the manifest, and maintaining the application running status through the process monitoring service.

[0011] The real-time monitoring and diagnostic module includes a data acquisition unit and a diagnostic analysis unit;

[0012] The data acquisition unit continuously acquires three types of operational data from the edge device—energy consumption, working status, and log information—through sensor interfaces, API interfaces, and log reading components. It then stores these data in a time-series database in a structured manner according to preset fields to form real-time data records.

[0013] The diagnostic analysis unit is used to call the rule engine and algorithm model to analyze the stored data. First, the rule engine performs preliminary screening based on preset thresholds to filter out invalid data. Then, feature vectors are generated from the filtered data. Where x1 is the normalized energy consumption value, x2 is the original status code value, and x3 is the TF-IDF value of the log keyword; the feature vector is calculated. Compared with the preset feature vector in the fault feature library The Euclidean distance d is used to determine an abnormal state when d < ε. The calculation formula is as follows:

[0014] ;

[0015] Then, alarm information containing fault type, occurrence time, and device identifier is generated and pushed to the centralized management module via Kafka message queue.

[0016] The automated policy generation module includes a policy matching unit and a script generation unit;

[0017] The strategy matching unit, based on the fault diagnosis result {T, P, C}, where T is the fault type identifier, P is the device communication protocol type, and C is the device configuration parameter set, retrieves the repair_cases table in the solution knowledge base using parameterized SQL statements to obtain a set of historical cases that perfectly match the current fault type and device protocol; and calculates the input fault feature vector using the K-nearest neighbor algorithm. Compared with the historical feature vectors recorded in the case library The Euclidean distance d1 is given by the following formula:

[0018] ;

[0019] Among them, C norm The configuration parameters are normalized; then, the matching degree is calculated based on d1 using the similarity formula, and the strategy template IDs corresponding to the three cases with the highest similarity are selected as candidate strategies; the formula is as follows:

[0020] ;

[0021] The script generation unit extracts the corresponding script framework code from the strategy_templates table based on the candidate strategy template ID, dynamically fills the device configuration parameter C into the template variable position through the template engine, and generates an executable script containing specific repair instructions. The generated script is subjected to syntax verification and permission verification to ensure that the script can be executed correctly in the Linux operating system environment of the target edge device. Finally, the generated script is transmitted to the MESH communication and repair execution module through a message queue.

[0022] The MESH communication and repair execution module includes a communication transmission unit and an instruction execution unit;

[0023] The communication transmission unit constructs an edge device MESH self-organizing network topology based on the IEEE 802.11s protocol, maintains the communication links between device nodes through a dynamic routing algorithm, forwards repair strategies through a cloud management platform as a relay node when connected to the network, and transmits strategies through multi-hop relays between adjacent devices when offline. The transmitted data includes a unique policy identifier, a target device identifier, and script content, and uses the AES-256 encryption algorithm to ensure data security during transmission.

[0024] After receiving the policy data, the instruction execution unit first verifies the legality of the instruction source through the RSA digital signature verification mechanism, then extracts the specific repair instructions through the instruction parser, calls the system interface of the edge device operating system to execute the operation, and records the execution time, execution status code and operation log in real time. Finally, the execution result is fed back to the automated policy generation module and the centralized management and control module through the communication transmission unit.

[0025] The solution knowledge base module includes a case storage unit and a learning and updating unit;

[0026] The case storage unit constructs a structured storage model using a relational database, defining three core data tables: a fault type table, a repair case table, and a strategy template table.

[0027] The fault type table is used to store the unique identifier of the fault type (fault type ID) and the fault characteristic description, and the data value range is constrained by an enumeration type.

[0028] The repair case table is associated with the fault type ID and records the unique identifier of the case, the device ID, the time of the fault occurrence, the repair step text, and the strategy template reference ID. The query efficiency is improved by using a composite index of fault type ID + device ID.

[0029] The strategy template table is used to store the template's unique identifier (template ID), applicable device protocol type, script framework code, and parameter description. It is associated with the repair case table through a one-to-many relationship via the template reference ID.

[0030] The learning update unit optimizes the policy matching logic based on a supervised learning framework. Specifically: First, it extracts fault feature vectors from historical repair cases from the case storage unit, including fault type ID, device protocol type, numerical results of configuration parameters, and corresponding policy template IDs, forming a training dataset. Then, it converts the device protocol type into one-hot encoding, and normalizes the configuration parameters to form a standardized feature matrix. Finally, it uses a gradient boosting tree algorithm to construct a policy matching model, defining the loss function as cross-entropy loss L, with the following formula:

[0031] ;

[0032] in This is the one-hot encoded value of the real policy template ID. The template ID probability distribution predicted by the model;

[0033] Finally, the model hyperparameters are optimized through cross-validation; learning and updates are performed. When the number of new cases added to the case storage unit reaches a preset threshold, the incremental training process is triggered, the original model structure is retained and the decision tree weights are updated. After training is completed, the online model is automatically replaced, and the model version number and training timestamp are recorded.

[0034] The application deployment management module includes an image template management unit and a distribution execution unit;

[0035] The image template management unit builds a standardized image template library using containerization technology. The specific process is as follows: the base image, dependent environment, and startup command of the application are defined using Dockerfile; the source code of applications such as energy consumption monitoring software and equipment management tools are copied to the image building context; and an executable container image is generated using the image building tool. The application templates are divided into three categories according to their functions: industrial control, energy consumption monitoring, and equipment management. Each template is assigned a unique label, and the protocol type and resource requirements of the edge devices associated with the template are recorded and stored in the metadata management table of the image repository.

[0036] The distribution execution unit implements batch deployment based on scene template tags. Specifically, it parses the JSON-formatted deployment task list sent from the cloud, extracts the target scene tag, target edge node group ID, and deployment strategy; retrieves the latest image version matching the scene tag through the image repository API interface, and generates an execution plan containing the image pull address and deployment order; and pushes the image to the target node group in batches using the HTTP chunked transfer protocol. After each node receives the image, it calls the application deployment execution unit interface of the edge node management module to complete container instantiation according to the resource requirement parameters in the image metadata, and monitors the deployment progress through a heartbeat mechanism. If three consecutive heartbeats are lost, a redistribution process is triggered.

[0037] The centralized management module includes a data display unit and a user operation unit;

[0038] The data display unit constructs a multi-dimensional display interface through a front-end visualization framework. Specifically, it obtains real-time data such as device energy consumption and operating status from the time-series database of the real-time monitoring and diagnostic module, and dynamically displays it in the form of line charts and status dashboards using ECharts chart components; it extracts fault alarm records and policy execution records from the relational databases of the automated policy generation module and the MESH communication and repair execution module. The fault alarm records include fault type, occurrence time, and device identifier; the policy execution records include execution time, status code, and operation log; and it displays the data in paginated form using a data table component, supporting filtering and querying by device identifier and time range.

[0039] The user operation unit is designed with an interaction interface based on a B / S architecture. Specifically, it receives manual intervention commands through a RESTful API interface, manually triggers fault repair strategies, and pauses / restarts edge node applications. JWT token verification and role permission verification are performed when the interface is called. The global policy configuration interface provides parameterized setting functions, including preset threshold adjustment, fault feature library update, and policy matching model version switching. The configuration data is stored in the configuration database of the centralized management module in JSON format and triggers the real-time synchronization mechanism of the automated policy generation module. During the operation, the user ID, operation time, and operation content are recorded in real time to the audit log table, and log export and operation traceability query are supported.

[0040] An integrated information automation monitoring method for edge devices includes the following steps:

[0041] S1. The edge node management module uniformly accesses edge devices, assigns a globally unique UUID to each device as an identifier, and stores the device model, communication protocol, configuration parameters and other basic attributes in a structured way in the embedded database. At the same time, it parses the cloud YAML format deployment list, pulls container images from the image repository, and calls the virtualization engine to complete the instantiation of application containers and maintain their running status.

[0042] S2. The real-time monitoring and diagnostic module continuously collects three types of data—equipment energy consumption, operating status codes, and log information—through sensor interfaces, API interfaces, and log reading components, and stores them in a time-series database. The diagnostic analysis unit calls the rule engine and support vector machine algorithm to identify anomalies by calculating the Euclidean distance between feature vectors and preset vectors. After locating the fault type, it generates alarm information and pushes it to the centralized management module.

[0043] S3, the automated strategy generation module, retrieves matching historical cases from the knowledge base based on fault type, device protocol, and configuration parameters using parameterized SQL statements; it uses the K-nearest neighbor algorithm to calculate feature vector similarity, selects the three most similar case templates to generate a Shell script containing specific repair instructions, and performs syntax validation and permission verification to ensure the script is executable;

[0044] The S4 and MESH communication and repair execution modules construct an ad hoc network topology based on the IEEE 802.11s protocol. When connected to the network, they transmit policy data via cloud relays and when offline, they transmit policy data via multi-hop relays. This includes the policy unique identifier, target device identifier, and script content. After verifying the digital signature, the instruction execution unit extracts the instruction, calls the system interface to execute the repair, and records the execution time, status code, and log feedback to the policy generation module.

[0045] S5, the solution knowledge base module stores fault type table, repair case table, and strategy template table in a relational database; the learning update unit periodically extracts fault feature vectors from cases, including one-hot encoded device protocol type and normalized configuration parameters, optimizes the strategy matching model based on gradient boosting tree algorithm and cross-entropy loss function, and triggers incremental training and updates the online model when the number of new cases reaches a preset threshold.

[0046] S6, the data display unit of the centralized management module dynamically displays equipment energy consumption curves, status dashboards, fault alarms, and policy execution record tables through the ECharts component, and supports filtering and querying by device identifier and time; the user operation unit receives manual instructions through RESTful API, performs JWT permission verification, executes policy configuration and model version switching operations, and records audit logs in real time for traceability and query.

[0047] Compared with the prior art, the beneficial effects of the present invention are:

[0048] 1. Unified Management and Efficient Containerized Deployment of Heterogeneous Devices: Addressing the issues of chaotic access protocols, duplicate identifiers, and low deployment efficiency in traditional edge device management, this invention constructs a multi-protocol compatible interface through an edge node management module. It assigns a globally unique UUID identifier to each device and structurally stores basic attributes such as device model, protocol, and configuration parameters in an embedded database, achieving standardized management of heterogeneous devices. Simultaneously, it automatically pulls container images by parsing the cloud-based YAML deployment manifest and calls the virtualization engine to complete application instantiation, solving the challenge of rapid deployment of large-scale edge nodes.

[0049] 2. Multimodal Data-Driven Precise Fault Diagnosis and Real-Time Alarming: Addressing the issues of traditional monitoring relying on single parameter thresholds and delayed fault identification, this invention uses a real-time monitoring and diagnostic module to simultaneously collect three types of data: equipment energy consumption values, operating status codes, and log information. These data are stored in a time-series database and analyzed using an algorithmic model for multi-feature fusion. Through preliminary screening using a rule engine and calculation of feature vector distances using a support vector machine algorithm, fault location time is reduced from hours to minutes. Real-time alarms are pushed via a message queue, achieving dynamic and precise monitoring of equipment operating status.

[0050] 3. Automated Repair Strategy Generation and System Self-Evolution Capability: Addressing the issues of traditional fault repair relying on manual experience and the inability of knowledge bases to iterate, this invention utilizes an automated strategy generation module to rapidly generate customized repair scripts based on the K-nearest neighbor matching algorithm of historical cases. Combined with MESH self-organizing network technology, it achieves secure policy transmission in both online and offline states, and ensures execution reliability through digital signature verification and system interface calls. The solution knowledge base employs a gradient boosting tree algorithm for incremental training, automatically optimizing the strategy matching model when new cases reach a preset threshold, continuously improving repair efficiency with data accumulation. The centralized management module provides a multi-dimensional visual interface and a manual intervention interface for permission verification, enabling dynamic global policy configuration and operation traceability, constructing a closed-loop intelligent monitoring system of detection-repair-optimization. Attached Figure Description

[0051] Figure 1 This is a system organization diagram of an integrated information automated monitoring system for edge devices according to the present invention;

[0052] Figure 2 This is a system workflow diagram of an integrated information automated monitoring system for edge devices according to the present invention. Detailed Implementation

[0053] 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. 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.

[0054] Example: Figures 1-2 As shown, the present invention provides a technical solution.

[0055] An integrated information automation monitoring system for edge devices includes an edge node management module, a real-time monitoring and diagnostic module, an automated policy generation module, a MESH communication and repair execution module, a solution knowledge base module, an application deployment management module, and a centralized control module. The edge node module is used for unified access to edge devices, generating unique device identifiers, recording basic attributes such as model, protocol, and configuration parameters, and deploying containerized applications. The real-time monitoring and diagnostic module continuously collects device operating data, including energy consumption, operating status, and log information, and analyzes it through preset rules and algorithms to identify anomalies, locate fault types, and trigger alarms. The automated policy generation module... Based on fault diagnosis results, device configuration parameters, and knowledge base cases, customized repair strategies are generated. The MESH communication and repair execution module constructs an edge device self-organizing network to achieve policy transmission and execution of repair instructions in both online and offline states. The solution knowledge base module stores device fault types, historical repair cases, and policy templates, and updates the policy matching logic through machine learning. The application deployment management module encapsulates applications, including energy consumption monitoring software and device management tools, into container images and distributes them to edge nodes in batches according to scenario templates. The centralized management module is used to visually display device status, fault alarms, and policy execution records, and provides a manual intervention and global policy configuration interface.

[0056] The edge node management module includes a device information management unit and an application deployment execution unit;

[0057] The device information management unit is responsible for building a multi-protocol compatible device access interface, assigning a globally unique UUID to each edge device as a device identifier, and storing basic attributes such as device model, communication protocol, and configuration parameters in a structured manner in preset fields of the embedded database to form a device information ledger.

[0058] The application deployment execution unit is responsible for parsing the YAML format containerized deployment manifest issued by the cloud, pulling the corresponding container image file from the specified image repository, calling the underlying virtualization engine through the container runtime interface, completing container instantiation according to the port mapping and storage volume mount parameters defined in the manifest, and maintaining the application running status through the process monitoring service.

[0059] The real-time monitoring and diagnostic module includes a data acquisition unit and a diagnostic analysis unit;

[0060] The data acquisition unit continuously acquires three types of operational data from the edge device—energy consumption, working status, and log information—through sensor interfaces, API interfaces, and log reading components. It then stores these data in a time-series database in a structured manner according to preset fields to form real-time data records.

[0061] The diagnostic analysis unit is used to call the rule engine and algorithm model to analyze the stored data. First, the rule engine performs preliminary screening based on preset thresholds to filter out invalid data. Then, feature vectors are generated from the filtered data. Where x1 is the normalized energy consumption value, x2 is the original status code value, and x3 is the TF-IDF value of the log keyword; the feature vector is calculated. Compared with the preset feature vector in the fault feature library The Euclidean distance d is used to determine an abnormal state when d < ε. The calculation formula is as follows:

[0062] ;

[0063] Then, alarm information containing fault type, occurrence time, and device identifier is generated and pushed to the centralized management module via Kafka message queue.

[0064] The automated policy generation module includes a policy matching unit and a script generation unit;

[0065] The strategy matching unit, based on the fault diagnosis result {T, P, C}, where T is the fault type identifier, P is the device communication protocol type, and C is the device configuration parameter set, retrieves the repair_cases table in the solution knowledge base using parameterized SQL statements to obtain a set of historical cases that perfectly match the current fault type and device protocol; and calculates the input fault feature vector using the K-nearest neighbor algorithm. Compared with the historical feature vectors recorded in the case library The Euclidean distance d1 is given by the following formula:

[0066] ;

[0067] Among them, C norm The configuration parameters are normalized; then, the matching degree is calculated based on d1 using the similarity formula, and the strategy template IDs corresponding to the three cases with the highest similarity are selected as candidate strategies; the formula is as follows:

[0068] ;

[0069] The script generation unit extracts the corresponding script framework code from the strategy_templates table based on the candidate strategy template ID, dynamically fills the device configuration parameter C into the template variable position through the template engine, and generates an executable script containing specific repair instructions. The generated script is subjected to syntax verification and permission verification to ensure that the script can be executed correctly in the Linux operating system environment of the target edge device. Finally, the generated script is transmitted to the MESH communication and repair execution module through a message queue.

[0070] The MESH communication and repair execution module includes a communication transmission unit and an instruction execution unit;

[0071] The communication transmission unit constructs an edge device MESH self-organizing network topology based on the IEEE 802.11s protocol, maintains the communication links between device nodes through a dynamic routing algorithm, forwards repair strategies through a cloud management platform as a relay node when connected to the network, and transmits strategies through multi-hop relays between adjacent devices when offline. The transmitted data includes a unique policy identifier, a target device identifier, and script content, and uses the AES-256 encryption algorithm to ensure data security during transmission.

[0072] After receiving the policy data, the instruction execution unit first verifies the legality of the instruction source through the RSA digital signature verification mechanism, then extracts the specific repair instructions through the instruction parser, calls the system interface of the edge device operating system to execute the operation, and records the execution time, execution status code and operation log in real time. Finally, the execution result is fed back to the automated policy generation module and the centralized management and control module through the communication transmission unit.

[0073] The solution knowledge base module includes a case storage unit and a learning and updating unit;

[0074] The case storage unit constructs a structured storage model using a relational database, defining three core data tables: a fault type table, a repair case table, and a strategy template table.

[0075] The fault type table is used to store the unique identifier of the fault type (fault type ID) and the fault characteristic description, and the data value range is constrained by an enumeration type.

[0076] The repair case table is associated with the fault type ID and records the unique identifier of the case, the device ID, the time of the fault occurrence, the repair step text, and the strategy template reference ID. The query efficiency is improved by using a composite index of fault type ID + device ID.

[0077] The strategy template table is used to store the template's unique identifier (template ID), applicable device protocol type, script framework code, and parameter description. It is associated with the repair case table through a one-to-many relationship via the template reference ID.

[0078] The learning update unit optimizes the policy matching logic based on a supervised learning framework. Specifically: First, it extracts fault feature vectors from historical repair cases from the case storage unit, including fault type ID, device protocol type, numerical results of configuration parameters, and corresponding policy template IDs, forming a training dataset. Then, it converts the device protocol type into one-hot encoding, and normalizes the configuration parameters to form a standardized feature matrix. Finally, it uses a gradient boosting tree algorithm to construct a policy matching model, defining the loss function as cross-entropy loss L, with the following formula:

[0079] ;

[0080] in This is the one-hot encoded value of the real policy template ID. The template ID probability distribution predicted by the model;

[0081] Finally, the model hyperparameters are optimized through cross-validation; learning and updates are performed. When the number of new cases added to the case storage unit reaches a preset threshold, the incremental training process is triggered, the original model structure is retained and the decision tree weights are updated. After training is completed, the online model is automatically replaced, and the model version number and training timestamp are recorded.

[0082] The application deployment management module includes an image template management unit and a distribution execution unit;

[0083] The image template management unit builds a standardized image template library using containerization technology. The specific process is as follows: the base image, dependent environment, and startup command of the application are defined using Dockerfile; the source code of applications such as energy consumption monitoring software and equipment management tools are copied to the image building context; and an executable container image is generated using the image building tool. The application templates are divided into three categories according to their functions: industrial control, energy consumption monitoring, and equipment management. Each template is assigned a unique label, and the protocol type and resource requirements of the edge devices associated with the template are recorded and stored in the metadata management table of the image repository.

[0084] The distribution execution unit implements batch deployment based on scene template tags. Specifically, it parses the JSON-formatted deployment task list sent from the cloud, extracts the target scene tag, target edge node group ID, and deployment strategy; retrieves the latest image version matching the scene tag through the image repository API interface, and generates an execution plan containing the image pull address and deployment order; and pushes the image to the target node group in batches using the HTTP chunked transfer protocol. After each node receives the image, it calls the application deployment execution unit interface of the edge node management module to complete container instantiation according to the resource requirement parameters in the image metadata, and monitors the deployment progress through a heartbeat mechanism. If three consecutive heartbeats are lost, a redistribution process is triggered.

[0085] The centralized management module includes a data display unit and a user operation unit;

[0086] The data display unit constructs a multi-dimensional display interface through a front-end visualization framework. Specifically, it obtains real-time data such as device energy consumption and operating status from the time-series database of the real-time monitoring and diagnostic module, and dynamically displays it in the form of line charts and status dashboards using ECharts chart components; it extracts fault alarm records and policy execution records from the relational databases of the automated policy generation module and the MESH communication and repair execution module. The fault alarm records include fault type, occurrence time, and device identifier; the policy execution records include execution time, status code, and operation log; and it displays the data in paginated form using a data table component, supporting filtering and querying by device identifier and time range.

[0087] The user operation unit is designed with an interaction interface based on a B / S architecture. Specifically, it receives manual intervention commands through a RESTful API interface, manually triggers fault repair strategies, and pauses / restarts edge node applications. JWT token verification and role permission verification are performed when the interface is called. The global policy configuration interface provides parameterized setting functions, including preset threshold adjustment, fault feature library update, and policy matching model version switching. The configuration data is stored in the configuration database of the centralized management module in JSON format and triggers the real-time synchronization mechanism of the automated policy generation module. During the operation, the user ID, operation time, and operation content are recorded in real time to the audit log table, and log export and operation traceability query are supported.

[0088] An integrated information automation monitoring method for edge devices includes the following steps:

[0089] S1. The edge node management module uniformly accesses edge devices, assigns a globally unique UUID to each device as an identifier, and stores the device model, communication protocol, configuration parameters and other basic attributes in a structured way in the embedded database. At the same time, it parses the cloud YAML format deployment list, pulls container images from the image repository, and calls the virtualization engine to complete the instantiation of application containers and maintain their running status.

[0090] S2. The real-time monitoring and diagnostic module continuously collects three types of data—equipment energy consumption, operating status codes, and log information—through sensor interfaces, API interfaces, and log reading components, and stores them in a time-series database. The diagnostic analysis unit calls the rule engine and support vector machine algorithm to identify anomalies by calculating the Euclidean distance between feature vectors and preset vectors. After locating the fault type, it generates alarm information and pushes it to the centralized management module.

[0091] S3, the automated strategy generation module, retrieves matching historical cases from the knowledge base based on fault type, device protocol, and configuration parameters using parameterized SQL statements; it uses the K-nearest neighbor algorithm to calculate feature vector similarity, selects the three most similar case templates to generate a Shell script containing specific repair instructions, and performs syntax validation and permission verification to ensure the script is executable;

[0092] The S4 and MESH communication and repair execution modules construct an ad hoc network topology based on the IEEE 802.11s protocol. When connected to the network, they transmit policy data via cloud relays and when offline, they transmit policy data via multi-hop relays. This includes the policy unique identifier, target device identifier, and script content. After verifying the digital signature, the instruction execution unit extracts the instruction, calls the system interface to execute the repair, and records the execution time, status code, and log feedback to the policy generation module.

[0093] S5, the solution knowledge base module stores fault type table, repair case table, and strategy template table in a relational database; the learning update unit periodically extracts fault feature vectors from cases, including one-hot encoded device protocol type and normalized configuration parameters, optimizes the strategy matching model based on gradient boosting tree algorithm and cross-entropy loss function, and triggers incremental training and updates the online model when the number of new cases reaches a preset threshold.

[0094] S6, the data display unit of the centralized management module dynamically displays equipment energy consumption curves, status dashboards, fault alarms, and policy execution record tables through the ECharts component, and supports filtering and querying by device identifier and time; the user operation unit receives manual instructions through RESTful API, performs JWT permission verification, executes policy configuration and model version switching operations, and records audit logs in real time for traceability and query.

[0095] Assume the scenario is an edge device monitoring system application in a smart industrial park, containing 100 edge devices, including 50 industrial sensors (Model Sensor-V1, MQTT communication protocol), 30 smart controllers, and 20 energy consumption monitoring devices (Model EMU-03, OPC UA communication protocol). Taking one of the smart controllers (device identifier UUID-Ctrl001, configuration parameters: control threshold 220V, sampling period 50ms) as an example, after system startup, the initialization process begins: the edge node management module connects to the devices uniformly through multi-protocol interfaces, assigns a globally unique UUID to each device and stores it in the embedded database, and simultaneously pulls a container image (energy consumption monitoring image version v1.2.3) from the image repository. Based on the YAML manifest issued by the cloud, the container is instantiated, with instantiation parameters including port mapping 8080:5000 and storage volume mount path / data / monitor. After application deployment, the devices enter real-time monitoring mode, and the modules begin to work collaboratively.

[0096] The data acquisition unit of the real-time monitoring and diagnostic module collects the energy consumption value (initial value 185V), operating status code (initial value 0x00 indicating normal), and log information (no abnormal keywords) of UUID-Ctrl001 every 200ms via the API interface. The data is stored in a structured time-series database. At a certain moment, the device's energy consumption value increases to 255V (exceeding the preset threshold of 240V), the status code changes to 0x02 (overload warning), and the keyword "voltage overflow" appears in the log. The diagnostic analysis unit generates a feature vector X=[1.06 (normalized energy consumption), 0x02, 0.85 (TF-IDF value)], and calculates the Euclidean distance d==0.078 with the preset vector W=[1.0, 0x02, 0.8] in the fault feature library. Since this distance is less than the threshold ε=0.1, the fault is determined to be "voltage overload". An alarm message {Type: voltage overload, Time: 2025-05-25 14:30:15, Device ID: UUID-Ctrl001} is generated and pushed to the centralized management module via Kafka, triggering the subsequent repair process.

[0097] The automated strategy generation module receives the fault diagnosis result {T=voltage overload, P=Modbus TCP, C={threshold 220V, period 50ms}}, and retrieves the historical case set matching the protocol from the repair_cases table using parameterized SQL. The K-nearest neighbor algorithm is used to calculate the Euclidean distance between the input feature vector F=[T,P,Cnorm=0.95] and the vectors in the case library. The three cases with the highest similarity are selected (case IDs: C001, C007, C012, corresponding to template IDs: S003, S005, S009). The script generation unit extracts template code from the strategy_templates table, dynamically fills in parameters to generate an executable shell script (content: "sudo modprobe -r voltage_controller && sudo modprobe voltage_controllerthreshold=230V"), and transmits it to the MESH network after syntax verification and AES-256 encryption. When connected to the network, the communication transmission unit delivers the policy to the target device via a cloud relay. After verifying the RSA signature, the instruction execution unit calls the system interface to execute the script, with an execution status code of 0x00. The log records "Repair complete, threshold adjusted to 230V" and sends feedback to the centralized management module. Simultaneously, the solution knowledge base adds this repair case. When the number of stored cases reaches 50, incremental training of the gradient boosting tree model is triggered, updating the policy matching logic. The centralized management module displays the device's energy consumption curve as dropping back to 210V via ECharts, indicating a return to normal status. The operation log records no manual intervention. The entire closed-loop process takes 47 seconds, and the system enters a new monitoring cycle.

[0098] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An integrated information automated monitoring system for edge devices, characterized in that: The system comprises an edge node management module, a real-time monitoring and diagnostic module, an automated policy generation module, a MESH communication and repair execution module, a solution knowledge base module, an application deployment management module, and a centralized control module. The edge node module provides unified access to edge devices, generates unique device identifiers, records basic attributes such as model, protocol, and configuration parameters, and enables containerized application deployment. The real-time monitoring and diagnostic module continuously collects device operating data, including energy consumption, operating status, and log information, and analyzes it using preset rules and algorithms to identify anomalies, locate fault types, and trigger alarms. The automated policy generation module generates customized repair policies based on fault diagnosis results, device configuration parameters, and knowledge base cases. The MESH communication and repair execution module constructs an edge device self-organizing network to achieve policy transmission in both online and offline states and executes repair commands. The solution knowledge base module stores device fault types, historical repair cases, and policy templates, and updates the policy matching logic through machine learning. The application deployment management module encapsulates applications, including energy consumption monitoring software and device management tools, into container images and distributes them to edge nodes in batches according to scenario templates; the centralized management module is used to visually display device status, fault alarms, and policy execution records, and provides a manual intervention and global policy configuration interface. S2. The real-time monitoring and diagnostic module continuously collects three types of data—equipment energy consumption, operating status codes, and log information—through sensor interfaces, API interfaces, and log reading components, and stores them in a time-series database. The diagnostic analysis unit calls the rule engine and support vector machine algorithm to identify anomalies by calculating the Euclidean distance between feature vectors and preset vectors. After locating the fault type, it generates alarm information and pushes it to the centralized management module. S3, the automated strategy generation module, retrieves matching historical cases from the knowledge base based on fault type, device protocol, and configuration parameters using parameterized SQL statements; it uses the K-nearest neighbor algorithm to calculate feature vector similarity, selects the three most similar case templates to generate a Shell script containing specific repair instructions, and performs syntax validation and permission verification to ensure the script is executable; The S4 and MESH communication and repair execution modules construct an ad hoc network topology based on the IEEE 802.11s protocol. When connected to the network, they transmit policy data through cloud relays and when offline, they transmit policy data through multi-hop relays, including policy unique identifiers, target device identifiers, and script content. After verifying the digital signature, the instruction execution unit extracts the instruction, calls the system interface to execute the repair, and records the execution time, status code, and log feedback to the policy generation module; S5, the solution knowledge base module stores fault type tables, repair case tables, and strategy template tables in a relational database; the learning update unit periodically extracts fault feature vectors from cases, including one-hot encoded device protocol types and normalized configuration parameters, optimizes the strategy matching model based on gradient boosting tree algorithm and cross-entropy loss function, and triggers incremental training and updates the online model when the number of new cases reaches a preset threshold.

2. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The edge node management module includes a device information management unit and an application deployment execution unit; The device information management unit is responsible for building a multi-protocol compatible device access interface, assigning a globally unique UUID to each edge device as a device identifier, and storing basic attributes such as device model, communication protocol, and configuration parameters in a structured manner in preset fields of the embedded database to form a device information ledger. The application deployment execution unit is responsible for parsing the YAML format containerized deployment manifest issued by the cloud, pulling the corresponding container image file from the specified image repository, calling the underlying virtualization engine through the container runtime interface, completing container instantiation according to the port mapping and storage volume mount parameters defined in the manifest, and maintaining the application running status through the process monitoring service.

3. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The real-time monitoring and diagnostic module includes a data acquisition unit and a diagnostic analysis unit; The data acquisition unit continuously acquires three types of operational data from the edge device—energy consumption, working status, and log information—through sensor interfaces, API interfaces, and log reading components. It then stores these data in a time-series database in a structured manner according to preset fields to form real-time data records. The diagnostic analysis unit is used to call the rule engine and algorithm model to analyze the stored data. First, the rule engine performs preliminary screening based on preset thresholds to filter out invalid data. Then, feature vectors are generated from the filtered data. Where x1 is the normalized energy consumption value, x2 is the original status code value, and x3 is the TF-IDF value of the log keyword; the feature vector is calculated. Compared with the preset feature vector in the fault feature library The Euclidean distance d is used to determine an abnormal state when d < ε. The calculation formula is as follows: ； Then, alarm information containing fault type, occurrence time, and device identifier is generated and pushed to the centralized management module via Kafka message queue.

4. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The automated policy generation module includes a policy matching unit and a script generation unit; The strategy matching unit, based on the fault diagnosis result {T, P, C}, where T is the fault type identifier, P is the device communication protocol type, and C is the device configuration parameter set, retrieves the repair_cases table in the solution knowledge base using parameterized SQL statements to obtain a set of historical cases that perfectly match the current fault type and device protocol; and calculates the input fault feature vector using the K-nearest neighbor algorithm. Compared with the historical feature vectors recorded in the case library The Euclidean distance d1 is given by the following formula: ； Among them, C norm The configuration parameters are normalized; then, the matching degree is calculated based on d1 using the similarity formula, and the strategy template IDs corresponding to the three cases with the highest similarity are selected as candidate strategies; the formula is as follows: ； The script generation unit extracts the corresponding script framework code from the strategy_templates table based on the candidate strategy template ID, dynamically fills the device configuration parameter C into the template variable position through the template engine, and generates an executable script containing specific repair instructions. The generated script is subjected to syntax verification and permission verification to ensure that the script can be executed correctly in the Linux operating system environment of the target edge device. Finally, the generated script is transmitted to the MESH communication and repair execution module through a message queue.

5. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The MESH communication and repair execution module includes a communication transmission unit and an instruction execution unit; The communication transmission unit constructs an edge device MESH self-organizing network topology based on the IEEE 802.11s protocol, maintains the communication links between device nodes through a dynamic routing algorithm, forwards repair strategies through a cloud management platform as a relay node when connected to the network, and transmits strategies through multi-hop relays between adjacent devices when offline. The transmitted data includes a unique policy identifier, a target device identifier, and script content, and uses the AES-256 encryption algorithm to ensure data security during transmission. After receiving the policy data, the instruction execution unit first verifies the legality of the instruction source through the RSA digital signature verification mechanism, then extracts the specific repair instructions through the instruction parser, calls the system interface of the edge device operating system to execute the operation, and records the execution time, execution status code and operation log in real time. Finally, the execution result is fed back to the automated policy generation module and the centralized management and control module through the communication transmission unit.

6. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The solution knowledge base module includes a case storage unit and a learning and updating unit; The case storage unit constructs a structured storage model using a relational database, defining three core data tables: a fault type table, a repair case table, and a strategy template table. The fault type table is used to store the unique identifier of the fault type (fault type ID) and the fault characteristic description, and the data value range is constrained by an enumeration type. The repair case table is associated with the fault type ID and records the unique identifier of the case, the device ID, the time of the fault occurrence, the repair step text, and the strategy template reference ID. The query efficiency is improved by using a composite index of fault type ID + device ID. The strategy template table is used to store the template's unique identifier (template ID), applicable device protocol type, script framework code, and parameter description. It is associated with the repair case table through a one-to-many relationship via the template reference ID. The learning update unit optimizes the policy matching logic based on a supervised learning framework. Specifically: First, it extracts fault feature vectors from historical repair cases from the case storage unit, including fault type ID, device protocol type, numerical results of configuration parameters, and corresponding policy template IDs, forming a training dataset. Then, it converts the device protocol type into one-hot encoding, and normalizes the configuration parameters to form a standardized feature matrix. Finally, it uses a gradient boosting tree algorithm to construct a policy matching model, defining the loss function as cross-entropy loss L, with the following formula: ； in This is the one-hot encoded value of the real policy template ID. The template ID probability distribution predicted by the model; Finally, the model hyperparameters are optimized through cross-validation; learning and updates are performed. When the number of new cases added to the case storage unit reaches a preset threshold, the incremental training process is triggered, the original model structure is retained and the decision tree weights are updated. After training is completed, the online model is automatically replaced, and the model version number and training timestamp are recorded.

7. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The application deployment management module includes an image template management unit and a distribution execution unit; The image template management unit builds a standardized image template library using containerization technology. The specific process is as follows: the base image, dependent environment, and startup command of the application are defined using Dockerfile; the source code of applications such as energy consumption monitoring software and equipment management tools are copied to the image building context; and an executable container image is generated using the image building tool. The application templates are divided into three categories according to their functions: industrial control, energy consumption monitoring, and equipment management. Each template is assigned a unique label, and the protocol type and resource requirements of the edge devices associated with the template are recorded and stored in the metadata management table of the image repository. The distribution execution unit implements batch deployment based on scene template tags. Specifically, it parses the JSON-formatted deployment task list sent from the cloud, extracts the target scene tag, target edge node group ID, and deployment strategy; retrieves the latest image version matching the scene tag through the image repository API interface, and generates an execution plan containing the image pull address and deployment order; and pushes the image to the target node group in batches using the HTTP chunked transfer protocol. After each node receives the image, it calls the application deployment execution unit interface of the edge node management module to complete container instantiation according to the resource requirement parameters in the image metadata, and monitors the deployment progress through a heartbeat mechanism. If three consecutive heartbeats are lost, a redistribution process is triggered.

8. The integrated information automated monitoring system for edge devices according to claim 1, characterized in that: The centralized management module includes a data display unit and a user operation unit; The data display unit constructs a multi-dimensional display interface through a front-end visualization framework. Specifically, it obtains real-time data such as device energy consumption and operating status from the time-series database of the real-time monitoring and diagnostic module, and dynamically displays it in the form of line charts and status dashboards using ECharts chart components; it extracts fault alarm records and policy execution records from the relational databases of the automated policy generation module and the MESH communication and repair execution module. The fault alarm records include fault type, occurrence time, and device identifier; the policy execution records include execution time, status code, and operation log; and it displays the data in paginated form using a data table component, supporting filtering and querying by device identifier and time range. The user operation unit is designed with an interaction interface based on a B / S architecture. Specifically, it receives manual intervention commands through a RESTful API interface, manually triggers fault repair strategies, and pauses / restarts edge node applications. JWT token verification and role permission verification are performed when the interface is called. The global policy configuration interface provides parameterized setting functions, including preset threshold adjustment, fault feature library update, and policy matching model version switching. The configuration data is stored in the configuration database of the centralized management module in JSON format and triggers the real-time synchronization mechanism of the automated policy generation module. During the operation, the user ID, operation time, and operation content are recorded in real time to the audit log table, and log export and operation traceability query are supported.

9. An integrated information automated monitoring method for edge devices, applied to an integrated information automated monitoring system for edge devices according to any one of claims 1-8, characterized in that: Includes the following steps: S1. The edge node management module uniformly accesses edge devices, assigns a globally unique UUID to each device as an identifier, and stores the device model, communication protocol, configuration parameters and basic attributes in a structured way in the embedded database. At the same time, it parses the cloud YAML format deployment list, pulls container images from the image repository, and calls the virtualization engine to complete the instantiation of application containers and maintain their running status. S2. The real-time monitoring and diagnostic module continuously collects three types of data—equipment energy consumption, operating status codes, and log information—through sensor interfaces, API interfaces, and log reading components, and stores them in a time-series database. The diagnostic analysis unit calls the rule engine and support vector machine algorithm to identify anomalies by calculating the Euclidean distance between feature vectors and preset vectors. After locating the fault type, it generates alarm information and pushes it to the centralized management module. S3, the automated strategy generation module, retrieves matching historical cases from the knowledge base based on fault type, device protocol, and configuration parameters using parameterized SQL statements; it uses the K-nearest neighbor algorithm to calculate feature vector similarity, selects the three most similar case templates to generate a Shell script containing specific repair instructions, and performs syntax validation and permission verification to ensure the script is executable; The S4 and MESH communication and repair execution modules construct an ad hoc network topology based on the IEEE 802.11s protocol. When connected to the network, they transmit policy data through cloud relays and when offline, they transmit policy data through multi-hop relays, including policy unique identifiers, target device identifiers, and script content. After verifying the digital signature, the instruction execution unit extracts the instruction, calls the system interface to execute the repair, and records the execution time, status code, and log feedback to the policy generation module; S5, the solution knowledge base module stores fault type table, repair case table, and strategy template table in a relational database; the learning update unit periodically extracts fault feature vectors from cases, including one-hot encoded device protocol type and normalized configuration parameters, optimizes the strategy matching model based on gradient boosting tree algorithm and cross-entropy loss function, and triggers incremental training and updates the online model when the number of new cases reaches a preset threshold. S6, the data display unit of the centralized management module dynamically displays equipment energy consumption curves, status dashboards, fault alarms, and policy execution record tables through the ECharts component, and supports filtering and querying by device identifier and time; the user operation unit receives manual instructions through RESTful API, performs JWT permission verification, executes policy configuration and model version switching operations, and records audit logs in real time for traceability and query.

Images