Data acquisition method for dynamic environment monitoring of cloud side end

Abstract

The invention discloses a data acquisition method for dynamic environment monitoring of a cloud side end, and relates to the technical field of dynamic environment monitoring, and the method comprises the steps that a local edge gateway periodically scans a local space-equipment-measuring point topological structure, generates topological configuration data, and actively pushes the topological configuration data to a cloud platform; and the cloud platform automatically analyzes and updates the global monitoring topology tree after verifying the request source IP and the JWT access token. When the edge gateway collects dynamic ring data, three-layer in-situ anomaly filtering is executed, and only effective data is uploaded. When the cloud platform generates an alarm work order and issues the alarm work order, the operation and maintenance personnel of the attribution confirms the disposal state through the terminal, the state is safely forwarded to the cloud platform through the edge gateway, and reliable synchronization is ensured through idempotent processing, local persistence and a regular account checking mechanism. According to the method, automatic topology synchronization and invalid data suppression are realized, and the automation, reliability and safety of a multi-belonging moving ring monitoring system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of environmental monitoring technology, and more specifically to a data acquisition method for cloud-edge-device environmental monitoring. Background Technology

[0002] With the continuous expansion and increasingly dispersed distribution of critical infrastructure such as data centers and communication equipment rooms, power and environmental (PE) monitoring systems have become an important support for ensuring their safe and stable operation. The current mainstream PE monitoring architecture generally adopts a three-level collaborative model of "end-edge-cloud": field sensors and devices act as the "end," locally deployed edge gateways act as the "edge," and the centralized monitoring platform acts as the "cloud." Under this architecture, the edge gateway is responsible for collecting local device data and uploading it to the cloud platform, enabling remote centralized monitoring and alarm management.

[0003] However, in real-world applications involving multiple locations and large scales, existing technologies still have several prominent pain points that severely restrict the system's automation level and operational efficiency: (a) The local topology relies on manual maintenance, which is slow to update and prone to errors.

[0004] The hierarchical relationships between the spatial structure (such as data centers and cabinets), access devices, and monitoring points of each location typically need to be compiled offline by operations and maintenance personnel and manually entered into the cloud platform. When devices are added, replaced, or taken offline in a location, failure to update the information in a timely manner will result in discrepancies between the cloud platform topology information and the actual site conditions, causing monitoring blind spots or false alarms, making it difficult to achieve accurate "what you see is what you get" monitoring.

[0005] (ii) The alarm handling status cannot be effectively reported back, and repeated notifications cause serious interference.

[0006] The cloud platform can generate alarm work orders and push them to the local authorities after detecting anomalies, but it lacks a closed-loop perception mechanism for the handling results. Even if on-site maintenance personnel have completed the handling, if they do not actively report back or the feedback link is unreliable, the cloud platform will continue to push alarms or send duplicate notifications, which not only disrupts normal operation and maintenance, but may also cover up the real risks.

[0007] (iii) The raw data was not effectively filtered, and outliers affected the accuracy of the analysis.

[0008] Field sensors are susceptible to electromagnetic interference, equipment aging, or sudden environmental changes, resulting in outlier data that deviates significantly from the normal range (such as a temperature sudden change to 1000℃). Existing systems often employ a "full upload" strategy, directly transmitting such invalid data to the cloud. This not only wastes network bandwidth but also contaminates data analysis models, reducing alarm accuracy and decision reliability.

[0009] (iv) Existing edge preprocessing schemes lack collaborative sensing capabilities.

[0010] Although some technologies have proposed ideas for data cleaning or local alarms at the edge, they have not yet solved the two core problems of automatic synchronization of local topology and cross-layer perception of alarm status, and cannot realize the cloud platform's dynamic mastery of the entire lifecycle and all elements of local monitoring status.

[0011] In summary, there is an urgent need for an environmental monitoring data acquisition method that can support automatic synchronization of local topology, on-site filtering of abnormal data, and reliable feedback of alarm handling status, in order to break down information gaps in cloud-edge-device collaboration and improve the level of monitoring intelligence and operation and maintenance automation in multi-local distributed scenarios. Summary of the Invention

[0012] In view of the above problems, this invention is proposed to provide a data acquisition method for cloud-edge-device environmental monitoring that overcomes or at least partially solves the above problems. By actively pushing local configurations, transmitting alarm handling status, automatically updating the topology, and filtering abnormal data locally, the cloud can achieve full lifecycle perception of the local monitoring status.

[0013] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, embodiments of the present invention provide a data acquisition method for cloud-edge-device environmental monitoring, comprising the following steps: The local edge gateway periodically scans the local space-device-measurement point topology and actively pushes the generated topology configuration data to the cloud platform; After receiving the topology configuration data, the cloud platform automatically parses and updates the global monitoring topology tree; The local edge gateway collects environmental data, performs on-site abnormal data filtering, and uploads the filtered environmental data to the cloud platform. The cloud platform identifies the device affiliation and determines anomalies in the uploaded environmental data based on the updated global monitoring topology tree. When an anomaly is detected, an alarm work order is generated and sent to the corresponding local operation and maintenance terminal based on the location information in the updated global monitoring topology tree. After the alarm is handled, the alarm handling status is submitted to the local edge gateway through the local operation and maintenance terminal. After the local edge gateway verifies the validity of the alarm handling status, it forwards it to the cloud platform. The cloud platform updates the lifecycle of the corresponding alarm work order based on the received alarm handling status and stops repeated notifications.

[0014] Preferably, the topology configuration data adopts a three-layer JSON format, including region, cabinet, device list, device type, device number, and a list of monitoring points corresponding to each device; the local edge gateway performs a local scan and pushes the data every 5 minutes.

[0015] Preferably, after receiving the topology configuration data, the cloud platform performs the following verification and processing operations in sequence: (a) Verify whether the Internet Protocol address from which the request originates belongs to the pre-configured Internet Protocol address whitelist of the local edge gateway; if it does not belong, reject the request and return a forbidden access error; (b) Verify that the access token carried in the request header is valid and has topology write permission; if invalid or without the corresponding permission, return an unauthorized error. (c) Parse whether the structure of the received topology configuration data conforms to the predefined format requirements; if it does not conform, return a request format error. (d) In the database transaction, based on the parsed topology configuration data, perform update if it exists and insert if it does not exist on the area table, cabinet table, equipment table and monitoring point table respectively, and synchronously update the global monitoring topology tree maintained by the cloud platform.

[0016] Preferably, the on-site anomaly data filtering process includes the following three-layer filtering mechanism: Basic rule filtering includes range filtering, mutation filtering, and null value handling; Adaptive point anomaly detection uses a sliding window to calculate a dynamic Z-score and mark suspected anomalies. Context and population consistency verification utilizes a lightweight time series model to predict the current value and combines the prediction residuals to determine context anomalies. Micro-clustering is performed on the readings of similar sensors within the same cabinet. If the readings deviate significantly from the population, they are determined to be true anomalies and filtered out; otherwise, they are considered as real environmental changes and the reference window is dynamically adjusted.

[0017] Preferably, after completing the handling, the alarm handling status is submitted to the local edge gateway through the local operation and maintenance terminal, and the local edge gateway and the cloud platform jointly perform the following reliability assurance operations: (a) After verifying the validity of the request source IP and access token of the alarm handling status, the local edge gateway persists the alarm handling status locally and marks it as being synchronized. (b) The local edge gateway forwards the alarm handling status to the cloud platform via the secure hypertext transfer protocol, and attaches its own gateway identifier, forwarding timestamp and digital signature generated based on the pre-shared key; (c) After the cloud platform verifies the digital signature and confirms the idempotency of the request, it updates the status of the corresponding alarm work order in the database transaction to "resolved" and stops sending duplicate notifications to the responsible person. (d) After receiving a successful response from the cloud platform, the local edge gateway updates the alarm handling status record stored locally to "synchronized"; if no response is received, it initiates an exponential backoff retry mechanism, retrying up to five times. (e) The cloud platform periodically performs reconciliation tasks, actively queries the actual handling status of alarm work orders that have been active for a long time at the corresponding local edge gateway, and corrects the cloud platform work order status based on the query results to achieve eventual consistency.

[0018] Preferably, all cloud platform interfaces use HTTPS protocol for encrypted communication.

[0019] Preferably, the access token is valid for 24 hours.

[0020] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a data acquisition method for cloud-edge-device environmental monitoring, which has the following effects: Automatic synchronization of monitoring topology: The local edge gateway periodically scans and actively pushes the space-device-measuring point topology structure, and the cloud platform updates the global monitoring topology tree in real time to ensure that the monitoring view is completely consistent with the actual site, eliminating manual configuration errors and monitoring blind spots.

[0021] Significantly reduces invalid data transmission: The edge side adopts a three-layer filtering mechanism (range verification, mutation suppression, and population consistency verification) to upload only valid environmental data, which greatly saves network bandwidth and improves the accuracy of cloud analysis and the reliability of alarms.

[0022] Ensuring a reliable closed-loop alarm handling system: Through a four-tiered mechanism of "local persistence + secure forwarding + idempotent processing + periodic reconciliation", the alarm handling status is 100% transparent, completely eliminating duplicate notifications and improving operational efficiency and user experience.

[0023] Enhance system security and robustness: All cloud platform interfaces use HTTPS encrypted communication, combined with IP whitelists, JWT token authentication (valid for 24 hours), and digital signature verification, to build a multi-layered security defense line and effectively prevent unauthorized access and data tampering.

[0024] In summary, this invention realizes an intelligent environmental monitoring system with efficient cloud-edge-device collaboration, reliable data uploading, and accurate alarm loop, which is particularly suitable for industrial application scenarios with multiple locations, weak networks, and high reliability requirements. Attached Figure Description

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

[0026] Figure 1 This is a flowchart of a data acquisition method for cloud-edge-device environmental monitoring provided in an embodiment of the present invention; Figure 2 This is a timing diagram of alarm handling status synchronization provided in an embodiment of the present invention. Detailed Implementation

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

[0028] This invention discloses a data acquisition method for cloud-edge-device environmental monitoring, such as... Figure 1 As shown, it includes the following steps: The local edge gateway periodically scans the local space-device-monitoring point topology and actively pushes the generated topology configuration data to the cloud platform. The topology configuration data adopts a three-layer JSON format, including region, cabinet, device list, device type, device number, and the monitoring point list corresponding to each device. The local edge gateway performs a local scan and pushes the data every 5 minutes. After receiving the topology configuration data, the cloud platform automatically parses and updates the global monitoring topology tree; The local edge gateway collects environmental data and performs on-site abnormal data filtering, then uploads the filtered environmental data to the cloud platform. The cloud platform identifies the device ownership and judges anomalies in the uploaded environmental data based on the updated global monitoring topology tree. When an anomaly is detected, an alarm work order is generated and sent to the corresponding local operation and maintenance terminal according to the location information in the updated global monitoring topology tree. After the alarm is handled, the alarm handling status is submitted to the local edge gateway through the local operation and maintenance terminal. After the local edge gateway verifies the validity of the alarm handling status, it forwards it to the cloud platform. The cloud platform updates the lifecycle of the corresponding alarm work order based on the received alarm handling status and stops repeated notifications.

[0029] In this embodiment, after receiving the topology configuration data, the cloud platform performs the following verification and processing operations in sequence: Step a: Request source IP whitelist verification The cloud platform first obtains the source IP address of the HTTP request and verifies whether the IP belongs to the pre-configured local edge gateway IP whitelist; If the IP address is in the whitelist, log "IP whitelist verification passed, client IP: [actual IP]" and proceed to the next step; If the IP address is not in the whitelist, a security alert log will be recorded: "An unauthorized IP attempted to access the topology synchronization interface, which has been denied. IP: [Actual IP]". Access will be immediately denied, and the response body will contain the error message "Access denied: This IP address is not in the whitelist". The subsequent processing will then be terminated.

[0030] Step b: Access token validity and permission verification The cloud platform extracts the Bearer-formatted access token from the request header and verifies its existence, signature validity, validity period, and topology write permissions; the access token is valid for 24 hours. If the token is valid and has the corresponding permissions, the ownership and gateway identification information are parsed from the token, the log is recorded as "Token authentication passed, user: [gateway ID], ownership: [owner name]", and the process proceeds to the next step; If the token is invalid, expired, or lacks topology write permissions, the security log will record "Token authentication failed, reason: [specific reason]", return an unauthorized error, the response body will contain the error message "Token is invalid or expired", and the subsequent processing will be terminated.

[0031] Step c: Verify the validity of the topology configuration data structure The cloud platform uses a JSON parser to parse the topology configuration data in the request body and verify whether it conforms to the predefined data model, including whether key fields such as region, cabinet, equipment list and monitoring point list corresponding to each equipment exist and are of the correct type. If the JSON structure is valid, the data will be converted into an internal data object, and the process will proceed to the next step. If the received topology configuration data has a JSON format error or is missing a necessary field, an error log is recorded with the content: "Unable to parse topology JSON, illegal format: [truncated raw data fragment]". At the same time, "Request format error" is returned, and the response message body includes specific error messages, such as "Invalid JSON format: missing necessary field 'device list'" or "JSON structure does not meet requirements: field 'rack' type is incorrect", and all subsequent processing is terminated.

[0032] Step d: Transactionally update the global monitoring topology tree in the database. Within a database transaction, the cloud platform performs the following operations sequentially based on the parsed topology configuration data: In the region table, perform an "update if it exists, insert if it does not exist" operation based on the region name to obtain the region identifier; In the rack table, combine the area identifier and rack name to perform an "update if it exists, insert if it does not exist" operation to obtain the rack identifier; Iterate through the device list, and for each device, perform an "update if it exists, insert if it does not exist" operation in the device table by combining the cabinet identifier, device type, and device number to obtain the device identifier; Iterate through the monitoring point list of each device, and perform the "update if it exists, insert if it does not exist" operation on each monitoring point in the monitoring point list in combination with the device identifier; Optionally, clear the records of old equipment or monitoring points not included in this instance under the cabinet to reflect the equipment's offline status; If the database transaction is successfully committed, the log will record "Topology data updated successfully, Location: [Location Name], Rack: [Rack Number], Number of Devices: [Quantity], Number of Measurement Points: [Quantity]", and proceed to the next step; If the database operation fails, the transaction is rolled back, an error log containing the exception stack trace is recorded, an internal server error or resource conflict is returned, the response body includes "topology database update failed", and the subsequent processing flow is terminated.

[0033] Step e: Push topology change events in real time The cloud platform constructs topology update event messages, which include the event type, location of the change, rack, operation type (add / update / delete), and timestamp. Push topology update events to all online clients via WebSocket message channel to notify all online clients (such as front-end monitoring dashboards) to refresh partial or full topology views; If the push is successful, debug logs can be recorded; if the push fails (e.g., the client is offline), only error logs are recorded, but committed database transactions are not rolled back, nor is the overall processing result of the interface changed, ensuring that the consistency of core data takes precedence over the reliability of real-time notifications.

[0034] In this embodiment, when the local edge gateway collects environmental data, it performs on-site anomaly data filtering on the raw sensor readings. The specific process includes the following three-level collaborative filtering mechanism: Level 1: Basic Rule Filtering During the data acquisition phase, the edge gateway first performs preliminary filtering of the raw data based on a preset physical reasonable range and rate of change: Range filtering: Discard data that exceeds the physical operating range of the device, with temperature values ​​limited to the range [-10℃, 60℃] and AC voltage values ​​limited to the range [198V, 242V]. Mutation filtering: Calculate the absolute difference between the current sampled value and the previous valid value. If the difference exceeds the preset mutation threshold (e.g., the temperature change rate is greater than 10℃ / second), it is determined to be instantaneous jump noise, the data point is discarded and the audit log is recorded. Null value handling: If no valid data is received three times in a row, the previous valid value is used to fill the gap, and the data is marked as interpolated data to indicate that the value is the interpolation result.

[0035] Second level: Adaptive point anomaly detection For the data filtered by the basic rules, further dynamic statistical analysis based on a sliding window is performed: Construct a sliding window of fixed length (e.g., the most recent 100 valid sampling points) and calculate the mean and standard deviation within the window in real time; The median absolute deviation (MAD) is introduced to robustly correct the standard deviation, thereby reducing the interference of instantaneous spikes on the statistic. Calculate the corrected Z-Score: z_score = |current value - mean| / standard deviation If the corrected Z-Score exceeds the threshold (e.g., 3.5), the point is marked as a "suspected anomaly" point and subjected to third-level filtering. If it does not exceed the threshold, third-level filtering is not required.

[0036] Third level: Context and group consistency verification For "suspected anomalies," a comprehensive judgment is made by combining time series trends and spatial group behavior: Context anomaly detection: A lightweight online prediction model (such as exponentially weighted moving average or minimal linear regression, which only needs to store a few state variables (such as slope and intercept) and has minimal computational overhead) is used to predict the current value based on the previous N historical points; if the residual between the actual current value and the predicted current value deviates significantly from the historical residual distribution (such as more than 2 times the residual standard deviation), then a time context anomaly is confirmed. Group consistency verification: For multiple sensors measuring the same physical quantity (such as temperature) in the same cabinet, their current readings are grouped into a miniature data cluster; through efficient nearest neighbor distance calculation, it is determined whether suspected anomalies deviate significantly from the group center; If the point is an isolated point (significantly different from the readings of other sensors), it will be ultimately determined as a "true anomaly" and filtered out. If the data point changes at a similar magnitude as most sensors in the group (indicating a real environmental event, such as the start and stop of an air conditioner), the data is retained, and the sliding window is dynamically expanded or the statistical reference benchmark is adjusted to enable the algorithm to quickly adapt to the new normal.

[0037] After the above three layers of filtering, only the valid data is compressed (using the gzip algorithm) and uploaded to the cloud platform's / api / data / upload interface via the HTTPS protocol, thereby significantly reducing the bandwidth of invalid data transmission and improving the accuracy of cloud alarms and the overall reliability of the system.

[0038] In this embodiment, after the cloud platform detects an anomaly (e.g., temperature above 35°C), it generates an alarm work order and sends it to the local maintenance terminal application. After the local maintenance personnel complete the on-site handling, they click the "Handled" button in the application, triggering the operation of submitting the alarm handling status to the local edge gateway, such as... Figure 2 As shown.

[0039] The specific process is as follows: I. Local maintenance terminal initiates alarm handling status request After maintenance personnel complete the alarm handling on-site, they click the "Processed" button on the local maintenance terminal application interface. The application then constructs a Hypertext Transfer Protocol (HTTP) POST request and sends it to the local edge gateway connected to its local network. This design ensures that the request is completed within the local area network, has low latency characteristics, and can still be initiated and temporarily stored in the event of network interruption.

[0040] The request body contains the following fields: Alarm ticket unique identifier: used to uniquely identify this alarm event; Status of handling: Values ​​are "Resolved" or "Confirmed"; Name of the person handling the situation: The name of the maintenance personnel who performed the handling operation; Handling Notes: Optional field used to record handling measures, such as "Restored to normal after restarting the uninterruptible power supply"; Local confirmation timestamp: A timestamp generated locally by the local maintenance terminal, indicating the time when the process was completed.

[0041] II. Local Edge Gateway Reception and Authentication As a trusted intermediary, the local edge gateway performs strict security verification and data validation on the received alarm handling status requests: Security verification: Verify whether the Internet Protocol address from which the request originates belongs to the pre-configured allowed address range of the operation and maintenance terminal; Verify that the access token carried in the verification request is valid and that the user has the authority to handle alarms.

[0042] Data validity verification: Check whether the format of the alarm work order's unique identifier conforms to the specifications; Check if the processing status is an enumerated value allowed by the system.

[0043] After successful verification, the local edge gateway immediately writes the alarm handling status request to its local storage medium (such as an SQLite database or log file) and marks its synchronization status as "synchronizing". This operation is the core mechanism to ensure that data is not lost and can effectively cope with unexpected gateway restarts or momentary network interruptions.

[0044] III. Local edge gateway forwards to cloud platform The local edge gateway encapsulates and enhances the original request content before forwarding it to the cloud platform's alarm confirmation interface via HTTPS. The enhanced request body additionally includes the following fields: Edge gateway's own identifier; Gateway forwarding timestamp; Digital signature: generated by the gateway using a key pair pre-shared with the cloud platform for the request content, used to prevent data from being tampered with during transmission.

[0045] IV. Cloud Platform Reception and Processing After receiving the forwarding request, the cloud platform executes the following processing procedure: Integrity and security verification: Use a pre-shared key to verify the validity of the digital signature, ensuring that the message source is authentic and the content has not been tampered with; Perform idempotency checks, using the alarm work order's unique identifier and local confirmation timestamp to determine if it is a duplicate request, thus avoiding duplicate processing caused by network timeout retries.

[0046] Business logic processing: In the database transaction, the status of the corresponding alarm work order is updated from "Active" to "Resolved", and the person in charge, the time of cloud reception, and the handling remarks are recorded. Trigger related actions: disable alarm notifications on the monitoring dashboard, synchronize and update the status of the external work order system, notify all online clients to refresh the alarm list via WebSocket, and stop sending repeated alarm notifications such as SMS or emails to the responsible person.

[0047] V. Response and Status Confirmation After the cloud platform successfully processes the data, it returns a success response to the local edge gateway. Upon receiving the response, the local edge gateway updates the status of the record stored locally to "synchronized" and returns a successful processing result to the local operations and maintenance terminal. The terminal interface then updates to "Reporting of handling status successfully".

[0048] Even better, to ensure reliable synchronization of alarm handling status under any network or device anomaly, the system employs a multi-layered protection mechanism: Edge Side: Local Persistence and Smart Retry All alarm handling status requests must first be successfully written to the local storage of the local edge gateway before an attempt can be made to upload them, thus achieving "storage upon landing"; The gateway maintains an asynchronous retry queue internally, periodically scanning records that are in "synchronization" status and have timed out. An exponential backoff strategy is used for retries (e.g., retrying after 30 seconds initially, then after 60 seconds, 120 seconds, etc.), with a maximum of 5 retries; if it still fails, it is marked as "synchronization failed" and a local alarm is triggered, but the record is retained for manual recovery later; Supports resume download after network interruption: Unfinished synchronization tasks will automatically resume after the network is restored.

[0049] Cloud: Idempotency and Transaction Consistency The cloud platform alarm confirmation interface is designed as an idempotent interface to ensure that multiple submissions of the same handling request will only take effect once. All status updates, logging, notification shutdown, and other operations are completed within a single database transaction, ensuring strong data consistency.

[0050] Cusp-of-fact mechanism: Periodic reconciliation to achieve eventual consistency The cloud platform scans all alarm work orders that are "active and last updated more than 4 hours ago" on a daily schedule. Actively initiate a status query to the corresponding local edge gateway; If the edge gateway reports that the alarm has been handled, the cloud platform will correct the status based on the query results; if there is no feedback, it will be considered unhandled, and the alarm level can be upgraded or a work order can be reissued. This mechanism can effectively repair data inconsistency issues in extreme scenarios (such as edge storage failure or long-term network interruption), ensuring that the system eventually reaches a consistent state.

[0051] This invention provides four layers of protection through "local persistence + asynchronous retry + idempotent design + periodic reconciliation", ensuring that the alarm handling status is 100% perceptible and the duplicate notification rate is reduced to 0; automatic synchronization of equipment changes reduces the monitoring blind spot rate to 0; and on-site filtering of abnormal data increases the data availability rate to 99.9%.

[0052] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0053] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data collection method for cloud edge ring monitoring, characterized in that, The method comprises the following steps: The local edge gateway periodically scans the local space-device-measurement point topology and actively pushes the generated topology configuration data to the cloud platform; After receiving the topology configuration data, the cloud platform automatically parses and updates the global monitoring topology tree; The local edge gateway collects dynamic environmental data and performs on-site abnormal data filtering processing, and uploads the filtered dynamic environmental data to the cloud platform; The cloud platform identifies the equipment ownership and judges the abnormality of the uploaded dynamic environmental data according to the updated global monitoring topology tree; when an abnormality is detected, an alarm work order is generated, and the alarm work order is sent to the corresponding local operation and maintenance terminal according to the local information in the updated global monitoring topology tree; After the treatment is completed, the local operation and maintenance terminal submits the alarm treatment status to the local edge gateway, and the local edge gateway verifies the validity of the alarm treatment status and forwards it to the cloud platform; The cloud platform updates the life cycle of the corresponding alarm work order according to the received alarm treatment status and stops repeated notification.

2. The method of claim 1, wherein, The topology configuration data adopts a three-layer structure JSON format, including region, cabinet, device list, device type, device number and corresponding monitoring point list of each device; the local edge gateway performs local scanning and pushing every 5 minutes.

3. The method of claim 2, wherein, After receiving the topology configuration data, the cloud platform performs the following verification and processing operations in turn: (a) Verify whether the Internet Protocol address of the request source belongs to the pre-configured local edge gateway Internet Protocol address white list; if not, reject the request and return an access prohibited error; (b) Verify whether the access token carried in the request header is valid and has topology write permission; if not valid or without corresponding permission, return an unauthorized error; (c) Analyze whether the structure of the received topology configuration data meets the pre-defined format requirements; if not, return a request format error; (d) In the database transaction, according to the parsed topology configuration data, perform the operation of updating if existing and inserting if not existing on the region table, cabinet table, device table and monitoring point table respectively, and synchronize the global monitoring topology tree maintained by the cloud platform.

4. The method of claim 1, wherein, The on-site abnormal data filtering processing includes the following three-layer filtering mechanism: Basic rule filtering, including range filtering, mutation filtering and null value processing; Adaptive point anomaly detection, based on sliding window calculation dynamic Z-Score, marking suspected abnormal points; Context and group consistency verification, using a lightweight time series model to predict the current value, combining the prediction residual to judge the context anomaly; performing micro-clustering on the readings of the same type of sensors in the same cabinet, if the readings significantly deviate from the group, it is determined as a true anomaly and filtered, otherwise it is considered as a real environmental change and the reference window is dynamically adjusted.

5. The method of claim 3, wherein, After the local edge gateway and the cloud platform cooperatively perform the following reliability guarantee operations: (a) After verifying the validity of the request source IP and access token of the alarm treatment status, the local edge gateway persistently stores the alarm treatment status locally and marks it as synchronized; (b) The local edge gateway forwards the alarm handling status to the cloud platform through secure hypertext transfer protocol, and attaches its own gateway identification, forwarding timestamp, and digital signature generated based on a pre-shared key; (c) After the cloud platform verifies the digital signature and confirms the request idempotency, it updates the status of the corresponding alarm ticket to "solved" in a database transaction, and stops sending repeated notifications to the responsible person; (d) After receiving the successful response from the cloud platform, the local edge gateway updates the alarm handling status record stored locally to "synchronized"; If no response is received, an exponential backoff retry mechanism is started, with a maximum of five retries; (e) The cloud platform performs a reconciliation task periodically, actively queries the actual handling status of alarm tickets that have been in an active state for a long time at the corresponding local edge gateway, and corrects the cloud platform ticket status according to the query result to achieve eventual consistency.

6. The method of claim 1, wherein, The cloud platform interfaces all use HTTPS protocol to encrypt communication.

7. The method of claim 3, wherein, The access token is valid for 24 hours.

Images