Multi-brand water quality sampler adaptive access and remote unified control method

Abstract

The application relates to a multi-brand water quality sampling instrument adaptive access and remote unified management and control method, a general object model abstract layer including a unified object model specification and an object model mapping configuration file is constructed, a mapping relationship between private fields of each brand and model sampling instrument and a unified object model is stored by taking brand identification and model identification as indexes; corresponding mapping configuration files and protocol adaptation plug-ins are loaded through protocol adaptation middleware, bidirectional conversion is carried out between sampling instrument private protocol messages and standard object model attribute values to complete adaptive access; then sampling mode of the sampling instrument is remotely configured, sampling control instructions with unique identifiers are issued, device states and execution feedback are collected, abnormalities are detected according to preset abnormality detection rules, and operation and maintenance work orders are automatically generated. The application enables newly added brand and model sampling instruments to be accessed without modifying platform core codes, and realizes unified remote management and control of heterogeneous multi-brand sampling instruments.

Description

Technical Field

[0001] This application relates to the technical field of online water quality monitoring and IoT device management, and in particular to a method for adaptive access and remote unified control of multi-brand water quality samplers. Background Technology

[0002] Water samplers are devices used in environmental monitoring and wastewater discharge supervision to automatically collect water samples according to set rules. They are widely deployed at locations such as wastewater outlets and surface water monitoring sections. Within a prefecture-level city-level regulatory area, water samplers from multiple manufacturers and of various models often coexist. Samplers from different manufacturers differ in communication protocols, data formats, and control commands, making it difficult to directly access and manage them using a single software.

[0003] Due to the dispersed deployment of samplers and the high cost of on-site personnel, regulators need to use a remote platform to uniformly distribute sampling tasks to samplers at various locations, conduct remote operation and maintenance, and monitor the equipment's operational status in a timely manner. If equipment goes offline or sampling fails and is not detected in time, the opportunity to obtain evidence of water quality exceeding standards may be missed. Therefore, centralized, remote, and real-time management and control of dispersed, heterogeneous samplers is of practical significance.

[0004] Existing water quality sampler management systems typically target a single brand and model of sampler, hard-coding that brand's proprietary communication protocols and data parsing logic into the platform. To accommodate more devices, various approaches exist, such as using unified industrial information modeling, installing protocol conversion gateways on-site, or calling cloud interfaces from different manufacturers. However, regardless of the method used, because the sampler's communication protocols and data formats are strongly coupled with the brand and model, the platform cannot uniformly connect to heterogeneous multi-brand samplers without developing separate systems for each new brand. Since the connection logic is brand-specific, connecting each new brand requires modifying the platform code, customizing gateway firmware, or interfacing with new manufacturer interfaces, often accompanied by service interruptions. This makes it difficult to unify cross-brand remote sampling control, equipment status monitoring, and maintenance under a single mechanism, limiting system scalability and weakening the ability to uniformly manage heterogeneous device groups. Summary of the Invention

[0005] In order to unify the access of heterogeneous multi-brand water quality samplers without developing separate systems for each new brand, and to achieve unified remote sampling control and status monitoring and maintenance, this application provides a method for adaptive access and unified remote management and control of multi-brand water quality samplers.

[0006] Firstly, this application provides a method for adaptive access and remote unified management of multi-brand water quality samplers, which adopts the following technical solution:

[0007] A method for adaptive access and remote unified management of multi-brand water quality samplers includes the following steps:

[0008] S1. Construct a general object model abstraction layer, which includes a unified object model specification and an object model mapping configuration file. For each brand and model of sampler, the object model mapping configuration file describes the mapping relationship between the sampler's private data fields and the unified object model specification, and stores them with brand identifier and model identifier as indexes.

[0009] S2. Construct protocol adaptation middleware; in response to sampler access, load the corresponding object model mapping configuration file and protocol adaptation plugin with brand and model identifiers. The protocol adaptation plugin performs bidirectional conversion between the sampler's private protocol messages and standard object model attribute values ​​to complete the sampler's adaptive access.

[0010] S3. Remotely configure the sampling mode of the sampler and issue sampling control commands, and assign a unique command identifier to each sampling control command.

[0011] S4. Collect the device status of the sampler and the execution feedback of the sampling control command, and detect the abnormality of the sampler according to the preset abnormality detection rules; in response to the detection of abnormality, automatically generate an operation and maintenance work order.

[0012] By adopting the above technical solution, the private data fields, control capabilities, and reported events of heterogeneous samplers are uniformly abstracted into a three-dimensional object model of attributes, services, and events. Brand differences are then decentralized into a mapping configuration file bound to the brand and model. This allows for the integration of new brand and model models simply by adding the corresponding mapping configuration file and protocol adaptation plugin, without modifying the platform's core code. Furthermore, the platform uses a protocol adaptation middleware to bidirectionally convert between the unified object model and the private protocols of each sampler. This enables the unified issuance of sampling control commands to heterogeneous multi-brand samplers using a single interface, matching execution feedback and monitoring device status using unique command identifiers, and automatically generating maintenance work orders. This ensures that access scalability and unified remote management across brands are both achieved within the same mechanism.

[0013] Optionally, the unified object model specification describes the sampler's device capabilities from three dimensions: attributes, services, and events. The object model mapping configuration file includes attribute mapping, service mapping, and event mapping. Attribute mapping includes the sampler's original field identifiers, corresponding standard attribute names, and conversion factors and offsets for converting the original values ​​into standard object model attribute values. Service mapping includes the command codes, parameter field order, and verification algorithm type used to convert unified service calls into sampler-specific control instructions. Event mapping includes rules for parsing the private event packets reported by the sampler into standard event structures.

[0014] By adopting the above technical solution, the mapping relationship is refined into three categories: attributes, services, and events, and the conversion coefficients and offsets are explicitly carried. This allows the private fields, control commands, and reported events of different brands of samplers to be converted to a unified object model through configuration, further reducing the access cost of new brands.

[0015] Optionally, the protocol adaptation middleware defines a unified protocol adaptation interface; S2 includes sub-steps S21-S24:

[0016] S21. Receive the registration data packet sent by the sampler. The registration data packet carries the brand identifier, model identifier and firmware version number.

[0017] S22. Query the object model configuration database using the brand identifier and model identifier, and load the corresponding object model mapping configuration file and protocol adapter plugin.

[0018] S23. Return the registration confirmation packet, which carries the session identifier and the server timestamp.

[0019] S24. The protocol adapter plugin parses the uplink data frames of the sampler into standard object model attribute values ​​and converts the unified service call into the sampler's private protocol message.

[0020] By adopting the above technical solution, the access process is standardized into a handshake process of registration, database lookup and loading, confirmation and uplink / downlink conversion, so that the sampler can automatically complete identity registration and resource loading after power-on, without the need for manual pre-configuration for each device.

[0021] Optionally, the remotely configurable sampling modes in S3 include equal time interval sampling, hourly timed sampling, traffic accumulation sampling, over-limit triggered sampling, mixed sampling, manual sampling, and uniform mixed sampling; among them, traffic accumulation sampling is configured to be triggered locally by the sampler based on the accumulated traffic, while hourly timed sampling and uniform mixed sampling are configured to be triggered by the platform side where the protocol adaptation middleware is located based on the server clock scheduling.

[0022] By adopting the above technical solutions, multiple sampling modes are provided for different monitoring scenarios, and local triggering and platform scheduling triggering are distinguished according to the triggering subject. This enables traffic-related sampling to respond in real time on the device side, and timed sampling to be scheduled by the platform after aligning the clock.

[0023] Optionally, in S3, issuing the same sampling control command to multiple samplers in batches includes sub-steps S31-S34:

[0024] S31. Divide multiple samplers into several brand groups according to brand and model identification.

[0025] S32. Call the corresponding protocol adapter plugin for each brand group to convert the same sampling control command into a private protocol message for the brand group, and convert each brand group only once.

[0026] S33. Assign a unique identifier to the sampling control command for each sampler and send them out concurrently.

[0027] S34. Aggregate the execution results of each sampler based on the unique identifier of the instruction to obtain a batch execution summary.

[0028] By adopting the above technical solution, the protocol conversion results are reused by brand group, so that the same instruction is converted only once for each brand. The execution results of each device are aggregated by the unique identifier of the instruction, so that the protocol conversion overhead and result collection during large-scale batch distribution can be managed in a unified manner.

[0029] Optionally, S3 also includes remote operation and maintenance of the sampler. The remote operation and maintenance includes device clock calibration and remote firmware upgrade. Device clock calibration includes sending a clock calibration service carrying a server timestamp to the sampler so that the sampler can update its local clock according to the server timestamp. Remote firmware upgrade includes sending a firmware package download address and firmware package verification value to the sampler so that the sampler can download the firmware package in chunks and upgrade the firmware after verification according to the firmware package verification value.

[0030] By adopting the above technical solutions, clock calibration and firmware upgrades are incorporated into remote operation and maintenance, enabling distributed samplers to maintain clock consistency and complete firmware updates without on-site operation, thereby reducing on-site operation and maintenance costs.

[0031] Optionally, in S4: the system detects whether the sampler is offline based on the arrival of the sampler's heartbeat packet; it matches the execution feedback returned by the sampler based on the unique identifier of the instruction and updates the execution status of the sampling control instruction in real time; preset anomaly detection rules include device offline, sampling failure, firmware upgrade failure, and hardware failure; in response to the detection of an anomaly, it queries whether there is a similar and unclosed maintenance work order on the sampler within a preset cooling time. If it exists, it adds an anomaly log to the maintenance work order; if it does not exist, it creates a new maintenance work order; the maintenance work order flows sequentially according to the lifecycle status of pending, processing, processed, and closed.

[0032] By adopting the above technical solutions, offline detection, instruction feedback matching, anomaly classification and work order deduplication are incorporated into a unified monitoring closed loop, enabling equipment anomalies to be detected in a timely manner, preventing repeated creation of work orders for the same type of duplicate anomalies, and tracking the progress of handling based on the work order lifecycle.

[0033] Optionally, S2 also includes access correctness verification: When loading the object model mapping configuration file in S22, the firmware version number reported by the sampler and the version of the object model mapping configuration file are determined to match according to a preset compatibility relationship to obtain the version matching status; after parsing the uplink data frame into standard object model attribute values ​​in S24, the standard object model attribute values ​​are compared with the reasonable value range defined by the unified object model specification for the corresponding standard attribute. If the standard object model attribute value exceeds the reasonable value range, a parsing anomaly is determined; in response to the parsing anomaly, the cause is attributed in combination with the version matching status. If the version matching status is mismatched, it is determined to be a configuration anomaly, a compatible configuration version is used for downgraded parsing, and an update work order is generated for the object model mapping configuration file; if the version matching status is matched, it is determined to be a sampler anomaly, and an operation and maintenance work order is generated.

[0034] By adopting the above technical solution, the compatibility judgment between firmware version and configuration version is used as the baseline, the reasonable range of the object model is used as the runtime verification, and the parsing anomalies are attributed to configuration problems or device problems according to the version matching status. This enables configuration errors in zero-code extension scenarios to be identified, located and dealt with in a targeted manner, avoiding the pollution of monitoring results by erroneous data.

[0035] Optionally, the system detects whether the sampler is offline based on the arrival of its heartbeat packets, including sub-steps S41-S43:

[0036] S41. Based on the statistics of the packet loss rate and arrival delay of the sampler's historical heartbeat packets, dynamically determine the sampler's heartbeat cycle and offline judgment threshold.

[0037] S42. In response to the fact that the time elapsed since the arrival of the most recent heartbeat packet from the sampler exceeds the offline judgment threshold, actively send a detection command to the sampler.

[0038] S43. If no response to the detection command is received from the sampler within the preset detection waiting time, the sampler is determined to be offline.

[0039] By adopting the above technical solution, the judgment threshold is dynamically adjusted according to the heartbeat of each sampler and a secondary confirmation is made by active detection, so that occasional packet loss in weak network conditions is not misjudged as offline, and real offline can be confirmed in a timely manner.

[0040] Optionally, the generation of maintenance work orders also includes root cause aggregation: based on the preset causal relationship between each type of anomaly in the preset anomaly detection rules, multiple different types of anomalies triggered by the same sampler within a preset time window and belonging to the same root cause are aggregated into a root cause maintenance work order.

[0041] By adopting the above technical solution, multiple anomalies caused by the same root cause are merged into one work order according to the causal relationship between anomaly types, so that a single physical root cause no longer generates multiple scattered work orders, reducing operational misjudgments and duplicate work orders.

[0042] Optionally, the standard attributes described by the attribute mapping include at least one of the following: online status, current sample count, remaining sample count, power status, network signal strength, and firmware version number.

[0043] By adopting the above technical solutions, the operating status attributes of the sampler can be uniformly characterized, which facilitates the platform to consistently present and monitor the status of heterogeneous devices.

[0044] Optionally, the unified service described by the service mapping includes at least one of start sampling, stop sampling, set sampling mode, clock calibration, and remote firmware upgrade.

[0045] By adopting the above technical solution, commonly used control capabilities are consolidated into a unified service set, enabling the platform to drive samplers of different brands with consistent service calls.

[0046] Optionally, the standard events described by the event map include at least one of the following: sampling completion event, device failure event, and sampling exception event.

[0047] By adopting the above technical solution, the types of events reported by the sampler are unified, which makes it easier for the platform to classify and process heterogeneous reports.

[0048] Optionally, the protocol adapter plugin may include at least one of the following, depending on the type of protocol it adapts to: message queue telemetry transmission protocol plugin, proprietary transmission control protocol plugin, and fieldbus protocol plugin.

[0049] By adopting the above technical solution, pluggable plugs can cover mainstream communication protocol types, allowing devices with new protocol types to be connected via new plugs.

[0050] Optionally, the execution status of the sampling control command includes execution in progress, execution successful, and execution failed.

[0051] By adopting the above technical solution, the status values ​​of instruction execution are refined, making it easier for the platform to track the progress of instruction processing based on feedback.

[0052] Optional hardware failures include sampling pump failure, liquid level sensor failure, and a full sampling bottle.

[0053] By adopting the above technical solutions, the specific circumstances of hardware anomalies can be clearly identified, making it easier for maintenance personnel to locate the fault location on-site.

[0054] Optionally, the maintenance work order includes the work order identifier, the installation address of the sampler, the type of abnormality, the time of the abnormality, and the responsible person; the generation of the maintenance work order also includes pushing the maintenance work order to the responsible person according to the preset push method, which includes SMS notification and in-system notification.

[0055] By adopting the above technical solutions, work order elements are standardized and proactively pushed to the responsible person, shortening the response time from the discovery of anomalies to their handling.

[0056] Optionally, sampling triggered by exceeding the standard will not be repeated for the same monitoring indicator if it exceeds the standard within a preset cooling period after the first trigger.

[0057] By adopting the above technical solution, the repeated triggering of the same indicator exceeding the standard is suppressed during the cooling period, thus avoiding repeated sampling in a short period of time.

[0058] Optionally, S4 also includes autonomous operation during disconnection and reconnection retransmission: In response to the loss of connection between the sampler and the platform, the sampler continues to perform sampling locally according to the sampling mode last issued before the loss of connection and caches sampling records and device status; In response to the reconnection of the sampler, the sampling records cached by the sampler during the disconnection period are retransmitted to the platform based on the unique instruction identifier and the server timestamp and backfilled into the operation and maintenance work order and monitoring view; Reconnection also includes the sampler reporting the last configuration version received before the loss of connection, and the platform issuing the configuration increment during the disconnection period. The configuration increment carries a monotonically increasing configuration version number. The sampler sorts and merges the configuration increments according to the configuration version number, discards expired increments, and performs idempotent processing on the same configuration version number.

[0059] By adopting the above technical solution, the device can continue sampling even when the network is interrupted or the platform's remote channel is unavailable, and the data and configuration can be replenished in sequence after reconnection, so that the sampling and evidence collection and device status are not lost during the period of disconnection.

[0060] Optionally, when issuing the same sampling control command in batches in S3, a differentiated response timeout window is set for each brand group based on the historical response delay distribution of each brand group, and sampling control commands are reissued a limited number of times for samplers that do not return execution feedback within the response timeout window.

[0061] By adopting the above technical solution, different timeouts are set according to brand response characteristics and resends are made to unresponsive devices, thus avoiding misjudgment of slow-response brands by uniform timeouts.

[0062] Optionally, in S4, in response to the detection of an anomaly, the platform will first issue a preset self-healing command based on the preset severity level of the anomaly. For anomalies below the preset severity level, the platform will automatically issue a preset self-healing command and retry a limited number of times. If the retry of the self-healing command fails, a maintenance work order will be generated.

[0063] By adopting the above technical solution, minor anomalies can be automatically self-healed and retried, and if they fail, the work order can be recreated, reducing invalid work orders caused by transient anomalies.

[0064] Optionally, during device clock calibration, the cycle for sending clock calibration services to the sampler can be adaptively adjusted based on the sampler's historical clock drift.

[0065] By adopting the above technical solution, the calibration frequency is adaptively adjusted according to the speed of equipment drift, so that equipment with large drift is calibrated more frequently, and equipment with small drift is calibrated less often.

[0066] Optionally, during remote firmware upgrades, the firmware package can be downloaded in chunks and resumed from where it was interrupted. Each firmware chunk is verified based on the chunk checksum, and the complete firmware package is verified based on the firmware package checksum.

[0067] By adopting the above technical solutions, the reliability of firmware upgrades under weak network conditions is improved by using breakpoint resume and segmented, full-packet dual-layer verification, avoiding the retransmission of the entire packet after interruption.

[0068] In summary, this application includes at least one of the following beneficial technical effects:

[0069] 1. By abstracting the private fields, control, and reporting of heterogeneous samplers into a three-dimensional object model of attributes, services, and events, and sinking brand differences into mapping configuration files indexed by brand and model and pluggable protocol adapters, new brand and model samplers can be connected without modifying the platform's core code, enabling unified remote management and control of heterogeneous samplers from multiple brands under the same set of interfaces.

[0070] 2. By providing multiple remote sampling modes, batch command issuance by brand group, remote operation and maintenance such as clock calibration and firmware upgrade, as well as status monitoring and work order closed loop matching of offline detection and command feedback, the distributed samplers can be remotely and uniformly scheduled, operated and maintained, and timely detected and handled when anomalies occur.

[0071] 3. By using firmware version and configuration version compatibility judgment and object model reasonable range verification to ensure the correctness of access during operation and attribute anomalies to configuration or device problems, and by using heartbeat statistics for adaptive offline judgment and active detection for secondary confirmation, as well as work order root cause aggregation based on the causal relationship of anomalies, configuration errors under zero-code extension can be located, offline misjudgments under weak network conditions can be suppressed, and multiple anomalies with the same root cause no longer generate scattered work orders. Attached Figure Description

[0072] Figure 1 This is a schematic diagram of the overall architecture of the adaptive access and remote unified management method for multi-brand water quality samplers provided in the embodiments of this application.

[0073] Figure 2 This is a schematic diagram of the sampler adaptive registration and access process provided in an embodiment of this application.

[0074] Figure 3 A schematic diagram illustrating the structure of various sampling modes and their triggering methods provided in the embodiments of this application.

[0075] Figure 4 This is a flowchart illustrating the batch brand-specific sampling control instructions provided in an embodiment of this application.

[0076] Figure 5 This is a schematic diagram illustrating the process of equipment status monitoring and maintenance work order generation provided in the embodiments of this application. Detailed Implementation

[0077] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0078] This application discloses a method for adaptive access and remote unified management of multi-brand water quality samplers. This method abstracts the private data fields, control capabilities, and reported events of samplers from different brands and models into a unified object model. Brand differences are represented by a mapping configuration file bound to the brand and model. A protocol adaptation middleware performs bidirectional conversion between the unified object model and the private protocols of each sampler, thereby enabling unified access, remote sampling control, and status monitoring and maintenance of heterogeneous multi-brand samplers using a single interface. The overall architecture described above is as follows: Figure 1 As shown below. The following will first explain some of the technical terms involved in the embodiments of this application.

[0079] The object model is a structured abstract description of the capabilities of the sampler device. It is used to shield the differences in protocol formats between different brands and to characterize the readable and writable state variables of the sampler, the control methods that the platform can call, and the asynchronous notifications actively reported by the sampler from three dimensions: attributes, services, and events.

[0080] The object model mapping configuration file is a configuration file created for each brand and model sampler, describing the conversion rules between the brand's private data fields and the unified object model. It is stored with the brand identifier and model identifier as a composite primary key index. When adding a new brand or model, only one corresponding configuration file needs to be added.

[0081] Protocol adapter plugins are pluggable components that implement a unified protocol adapter interface according to the communication protocol type. They are responsible for performing bidirectional conversion between the sampler's private protocol messages and the attribute values ​​of the standard object model.

[0082] As an example, in the online water quality monitoring scenario of a drainage company, the monitoring network deploys water quality samplers of various brands and models. Some samplers communicate with the platform via message queue telemetry transmission protocol, some use binary frames of a custom transmission control protocol, and some use fieldbus protocol. The private data field formats of each sampler are different. Subsequent examples will follow this scenario.

[0083] A general object model abstraction layer is constructed, comprising a unified object model specification and object model mapping configuration files. For each brand and model of sampler, the object model mapping configuration file describes the mapping relationship between the sampler's private data fields and the unified object model specification, stored using brand and model identifiers as indexes. The general object model abstraction layer unifies the device capabilities of samplers from various brands into a single object model, and decentralizes brand differences into mapping configuration files bound to the brand and model. This allows for integration when adding a new brand or model, requiring only the addition of the corresponding mapping configuration file and protocol adapter plugin, without modifying the platform's core code. It should be understood that this general object model abstraction method is not limited to water quality samplers; it is also applicable to the unified access of other IoT devices with heterogeneous private protocols. Besides using a structured configuration file to carry the mapping relationship, the object model mapping configuration file can also use table-driven or rule engine formats to describe the mapping between private fields and the unified object model; no restrictions are placed here.

[0084] The Unified Object Model Specification describes the device capabilities of samplers from three dimensions: attributes, services, and events. The object model mapping configuration file includes attribute mapping, service mapping, and event mapping. Attribute mapping includes the sampler's original field identifiers, corresponding standard attribute names, and conversion factors and offsets for converting the original values ​​to standard object model attribute values. Service mapping includes the command codes, parameter field order, and verification algorithm type used to convert unified service calls into sampler-specific control instructions. Event mapping includes rules for parsing private event packets reported by the sampler into standard event structures. Taking attribute mapping as an example, after the platform reads the sampler's original fields, it converts the original values ​​to standard object model attribute values ​​based on the conversion factors and offsets. For example, for a sampler using a fieldbus protocol, if its current sample volume is stored in a holding register address 0x0003, and the unit of the original value is 0.1 ml, then the conversion factor configured for this attribute mapping is 0.1, and the offset is 0; the platform reads this register to obtain the original value. Then, the corresponding standard object model attribute values according to Calculations are performed in milliliters. Besides linear conversion using conversion factors and offsets, attribute mapping conversion rules can also employ piecewise linear, lookup table, or other non-linear forms to adapt to samplers where the relationship between the original and standard values ​​is non-linear; no restrictions are imposed here.

[0085] In some embodiments, the standard attributes described by the attribute mapping include at least one of online status, current sampled volume, remaining number of sampling bottles, power status, network signal strength, and firmware version number. As an example, online status is a Boolean value, current sampled volume and cumulative flow are floating-point numbers in milliliters and liters respectively, remaining number of sampling bottles is an integer, power status is an enumerated value of normal, low, or power off, and network signal strength is an integer value in decibels and milliwatts.

[0086] In other embodiments, the unified service described by the service mapping includes at least one of start sampling, stop sampling, set sampling mode, clock calibration, and remote firmware upgrade, and each service defines a unified input and output parameter data structure.

[0087] As an optional implementation, the standard events described by the event map include at least one of sampling completion events, device failure events, and sampling exception events, wherein the sampling completion event carries the sampling amount and timestamp, the device failure event carries the fault code and description, and the sampling exception event carries the exception reason.

[0088] A protocol adaptation middleware is constructed. In response to sampler access, the corresponding object model mapping configuration file and protocol adaptation plugin are loaded using the brand and model identifiers. The protocol adaptation plugin performs bidirectional conversion between the sampler's private protocol messages and standard object model attribute values, completing the sampler's adaptive access. The protocol adaptation middleware adopts a pluggable architecture, defining a unified protocol adaptation interface. This interface specifies two core methods: a parsing method and a construction instruction method. The parsing method parses the sampler's raw data frames into a set of standard object model attribute values, and the construction instruction method converts the unified service call into the sampler's private protocol control messages. It should be understood that this protocol adaptation mechanism is not limited to the above-mentioned protocol types. Samplers using other private protocols can also access the system by adding the corresponding protocol adaptation plugin. Besides using the above-mentioned pluggable protocol adaptation middleware, sampler access can also be achieved by uniformly modifying samplers from different brands to the same industry standard IoT protocol; no restrictions are placed here.

[0089] To enable automatic access after the sampler is powered on, the protocol adaptation middleware defines a unified protocol adaptation interface. S2 includes sub-steps S21 to S24.

[0090] S21. Receive the registration data packet sent by the sampler. The registration data packet carries the brand identifier, model identifier and firmware version number. As an example, the registration data packet may also carry the unique device identifier of the sampler.

[0091] S22. Query the object model configuration database using the brand identifier and model identifier, load the corresponding object model mapping configuration file and protocol adapter plugin; if the corresponding configuration does not exist, refuse registration and log it.

[0092] S23. Return the registration confirmation packet, which carries a session identifier and a server timestamp. This server timestamp can be used for the initial clock calibration of the sampler.

[0093] S24. The protocol adaptation plugin parses the uplink data frames of the sampler into standard object model attribute values ​​and converts the unified service call into the sampler's private protocol message. Therefore, all uplink data from the sampler is parsed by the corresponding protocol adaptation plugin, and all downlink commands are converted and sent by the plugin, achieving fully automatic adaptation and access without manual intervention. The above adaptive registration and access process is as follows: Figure 2 As shown.

[0094] In one alternative implementation, the protocol adapter plugin includes at least one of the following, depending on the type of protocol it adapts to: message queue telemetry transport protocol plugin, proprietary transport control protocol plugin, and fieldbus protocol plugin.

[0095] The Message Queuing Telemetry Transmission Protocol (MQTP) plugin is used to interact with samplers that communicate via the MQTP protocol. Its data reporting topics and control command issuance topics are distinguished by device identifiers. Based on the brand object model mapping configuration, the plugin extracts and converts private fields in the reporting messages to generate standard object model attribute values.

[0096] A proprietary Transmission Control Protocol (TCP) plugin is used to process samplers that use custom TCP binary frames. It parses data frames based on the frame format definition in the mapping configuration, including the frame header byte sequence, length field offset, function code position, data area format, and checksum type.

[0097] The fieldbus protocol plugin is used to process samplers that use the fieldbus protocol. It is configured based on register address mapping, polls data by reading holding register function codes, and sends control parameters by writing single register or multiple register function codes.

[0098] The three types of protocol adapter plugins described above all implement a unified protocol adapter interface, forming a pluggable protocol adapter framework. It should be understood that for samplers using other communication protocol types, newly added protocol adapter plugins implementing the same interface can also be incorporated into this framework.

[0099] The platform remotely configures the sampling mode of the sampler and issues sampling control commands, assigning a unique identifier to each command. The platform supports remote configuration of multiple sampling modes for the sampler and assigns a globally unique identifier to each sampling control command in batch issuance scenarios. This ensures that even when the platform communicates concurrently with multiple samplers and feedback packets from each sampler arrive out of order, each feedback packet can still accurately correspond to the original command based on its unique identifier. As an example, the unique identifier can be in the form of a universally unique code. Besides using a universally unique code, the unique identifier can also be in other globally unique identifier forms, such as a globally incrementing sequence number generated by the platform according to the issuance order; no restrictions are placed here. The following describes the various remotely configurable sampling modes.

[0100] In some embodiments, the remotely configurable sampling modes in S3 include equal time interval sampling, hourly timed sampling, traffic accumulation sampling, over-limit triggered sampling, mixed sampling, manual sampling, and uniform mixed sampling; wherein, traffic accumulation sampling is configured to be triggered locally by the sampler based on the accumulated traffic, and hourly timed sampling and uniform mixed sampling are configured to be triggered by the platform side where the protocol adaptation middleware is located based on the server clock scheduling.

[0101] The parameters for time-interval sampling include the sampling interval, the sampling start time, and the sampling end time. The sampling interval ranges from 1 minute to 1440 minutes. Within the time window from the sampling start time to the sampling end time, a sampling is triggered when the elapsed time since the last sampling reaches the sampling interval.

[0102] The parameters for hourly timed sampling include a list of hourly times, with a maximum of 24 times to be configured simultaneously. The platform-side timed task scheduler sends an immediate sampling command to the target sampler at each configured hourly time. This mode is triggered by the platform side, and clock calibration affects its sampling time accuracy.

[0103] The parameters for cumulative traffic sampling include the traffic trigger threshold and the single sampling amount. The sampler's local flow meter measures the cumulative traffic at the outlet. Sampling is triggered when the difference between the cumulative traffic and the previously triggered traffic reaches the traffic trigger threshold, and the counting baseline is reset after each sampling. This mode is triggered locally by the sampler based on the cumulative traffic, thereby eliminating the impact of network latency on the triggering timing. The platform is only responsible for distributing the threshold parameter configuration.

[0104] The parameters for triggering sampling when the standard is exceeded include the monitoring indicator, threshold, comparison operator, and sampling quantity. The platform receives real-time data from the online monitoring instrument. When the monitoring value and threshold meet the conditions represented by the comparison operator, the platform immediately sends a sampling instruction to the associated sampling instrument and records the trigger time and trigger value in the work order for compliance auditing.

[0105] Hybrid sampling uses time and flow rate as dual conditions. The parameters include time interval and flow rate threshold. The logic of triggering is based on whichever condition is met first. Once either condition is met, the system is triggered. After triggering, both counters are reset simultaneously. This is suitable for operating conditions that require both ensuring the minimum sampling frequency and responding to sudden changes in flow rate.

[0106] Manual sampling is triggered by the operator through the control interface. The platform immediately sends a sampling command to the target sampler and waits for execution confirmation feedback.

[0107] The parameters for uniform mixed sampling include the total acquisition period, the number of sampling sessions, and the sample size per session. The platform divides the total acquisition period into several sub-intervals and sends multiple sampling commands to the same sampler sequentially according to the sub-intervals. All sub-samples are then combined into the same sampling container to form a mixed sample. This mode is scheduled by the platform based on the server clock, using the server's high-precision clock to ensure that the time interval between each sub-sample acquisition is uniform, avoiding uneven sub-sample time distribution caused by device local clock drift during long-cycle sampling.

[0108] The above-mentioned sampling triggers will not trigger repeated sampling for the same monitoring indicator if the same indicator exceeds the limit again within a preset cooldown period after the initial trigger. For example, the default cooldown period is 60 minutes; during this period, exceeding the limit for the same monitoring indicator will not trigger sampling again. The various sampling modes and their triggering methods are as follows: Figure 3 As shown.

[0109] In other embodiments, S3 includes sub-steps S31 to S34, which involve issuing the same sampling control command to multiple samplers in batches.

[0110] S31. Divide multiple samplers into several brand groups according to brand and model identification.

[0111] S32. Call the corresponding protocol adapter plugin for each brand group to convert the same sampling control command into a private protocol message for the brand group, and convert each brand group only once.

[0112] S33. Assign a unique identifier to the sampling control command for each sampler and send them out concurrently.

[0113] S34. Aggregate the execution results of each sampler based on the unique identifier of the instruction to obtain a batch execution summary.

[0114] Therefore, only one conversion is needed for each brand group, and the number of protocol conversions when issuing the same instruction in batches equals the number of brand groups. The platform aggregates the success, failure, and timeout results of each sampler based on the unique identifier of the instruction, forming a batch execution summary. This summary includes the total number of instructions issued, the number of successes, the number of failures, and the number of timeouts. The above-mentioned batch brand-specific group sending process is as follows: Figure 4 As shown.

[0115] In an optional implementation, S3 also includes remote operation and maintenance of the sampler, including device clock calibration and remote firmware upgrade.

[0116] Device clock calibration involves sending a clock calibration service carrying a server-side timestamp to the sampler, allowing the sampler to update its local clock based on the server-side timestamp. As an example, the platform sends a clock calibration service to the online sampler every 24 hours, with the server-side timestamp accurate to the millisecond level, to meet the compliance audit requirement for hourly sampling, which requires a sampling time recording error of less than 1 second.

[0117] Remote firmware upgrades involve sending the firmware package download address and firmware package checksum to the sampler. The sampler then downloads the firmware package in chunks and upgrades the firmware after verifying the checksum. For example, the sampler downloads the firmware package in 512-byte chunks by default. After receiving all chunks, it calculates the complete digest of the firmware package and compares it with the sent 256-bit digest checksum. If the verification passes, the firmware is flashed, and the new firmware version number is reported upon completion. If the verification fails, the upgrade is abandoned, and an upgrade failure status code is reported.

[0118] The system collects the device status of the samplers and the execution feedback of sampling control commands, and detects sampler anomalies according to preset anomaly detection rules. In response to an anomaly detection, it automatically generates a maintenance work order. The platform polls the operating status attributes of each sampler at preset intervals. As an example, by default, it polls the remaining number of sampling bottles, power status, current sampling volume, and cumulative traffic every 5 minutes, updating the device status view to provide maintenance personnel with a comprehensive overview of device health. In addition to the above-mentioned periodic polling method, device operating status can also be collected using an event-driven method where the samplers actively report changes in status; this is not a restriction here. The mechanism of device status monitoring and maintenance work orders is explained below.

[0119] In S4, the system detects whether the sampler is offline based on the arrival of the sampler's heartbeat packet. It matches the execution feedback returned by the sampler based on the unique identifier of the instruction and updates the execution status of the sampling control instruction in real time. The preset anomaly detection rules include device offline, sampling failure, firmware upgrade failure, and hardware failure. In response to the detection of an anomaly, the system queries whether there is a similar and unclosed maintenance work order on the sampler within the preset cooling time. If it exists, an anomaly log is added to the maintenance work order. If it does not exist, a new maintenance work order is created. The maintenance work order flows sequentially according to the life cycle status of pending, processing, processed, and closed.

[0120] Under normal operating conditions, the sampler sends a heartbeat packet to the platform once every heartbeat cycle. The platform records the arrival time of the most recent heartbeat packet for each sampler. Let the heartbeat cycle be... The current time is The most recent heartbeat packet arrival time of this sampler is When satisfied When the sampler is offline, it is determined that the sampler is offline. This includes the heartbeat cycle. The default setting is 60 seconds, which can be configured independently by each brand. It uses twice the heartbeat cycle as the offline judgment threshold, which can tolerate the occasional loss of a single heartbeat packet and avoid false alarms caused by network jitter.

[0121] Each sampling control command issued by the platform carries a unique command identifier. The feedback packet returned by the sampler carries the same unique command identifier and execution status code. The platform updates the execution status of the corresponding command in real time based on this. If the platform does not receive feedback with the corresponding unique command identifier within the preset timeout period after issuing the command, the command status is updated to "timeout and no response" and included in the failure statistics. As an example, the preset timeout period is 30 seconds by default, and 300 seconds by default for time-consuming operations such as firmware upgrades.

[0122] The preset anomaly detection rules include four categories: device offline, sampling failure, firmware upgrade failure, and hardware failure. Meeting any one of these rules triggers a maintenance work order. In response to an anomaly detection, the platform checks if a similar, unclosed maintenance work order already exists for the sampler within a preset cooldown period. If it exists, an anomaly log is appended to that work order without creating a duplicate; otherwise, a new maintenance work order is created. For example, the default cooldown period is 30 minutes. Maintenance work orders progress through their lifecycle stages: pending, processing, processed, and closed, ensuring full traceability of anomaly handling. The process of device status monitoring and maintenance work order generation described above is as follows: Figure 5 As shown.

[0123] The execution status of the above sampling control command includes executing, executing successfully, and executing failed. As an example, executing, executing successfully, and executing failed correspond to status codes 0x01, 0x02, and 0x03, respectively, with executing being applicable to time-consuming operations such as firmware upgrades.

[0124] The aforementioned hardware faults include sampling pump failure, liquid level sensor failure, and a full sampling bottle. For example, sampling pump failure, liquid level sensor failure, and a full sampling bottle correspond to hardware fault codes 0x01, 0x02, and 0x03, respectively.

[0125] In some embodiments, the maintenance work order includes a work order identifier, the installation address of the sampler, the type of anomaly, the time of the anomaly, and the responsible person. Generating the maintenance work order also includes pushing the work order to the responsible person according to a preset push method, which includes SMS notification and in-system notification. As an example, the responsible person is determined by querying the responsible person configuration table based on the region where the sampler is located. After the work order is generated, it is simultaneously pushed to the responsible person via SMS and in-system notification.

[0126] In other embodiments, in addition to the adaptive access described above, the access also includes access correctness verification. Since new brand models are accessed using a zero-code extension method, the mapping configuration file is manually written and may not match the actual firmware version of the sampler, resulting in incorrect attribute values ​​obtained from the parsing. Access correctness verification uses firmware version and configuration version compatibility as a baseline, and a reasonable value range for the object model as a runtime verification. Based on the version matching status, parsing anomalies are attributed to configuration or device issues.

[0127] S2 also includes access correctness verification. In S22, when loading the object model mapping configuration file, the platform determines whether the firmware version number reported by the sampler matches the compatible firmware version declared in the object model mapping configuration file according to a preset compatibility relationship, resulting in a matching or non-matching version matching status. In S24, after parsing the uplink data frame into standard object model attribute values, the platform compares the standard object model attribute values ​​with the reasonable value range defined by the unified object model specification for the corresponding standard attribute. For example, for the current sampled volume in milliliters, the reasonable value range is from zero milliliters to the maximum capacity of a single bottle. If the parsed attribute value exceeds this range, a parsing anomaly is determined. In response to the parsing anomaly, the platform attributes the cause based on the version matching status: if the version matching status is non-matching, it is determined to be a configuration anomaly, a compatible configuration version is used for downgrading the parsing of the data frame, and an update work order is generated for the object model mapping configuration file; if the version matching status is matching, it is determined to be a sampler anomaly, and a maintenance work order is generated. In addition to using interval verification with a reasonable range of values, the above-mentioned runtime verification can also use other correctness verification methods such as statistical outlier determination based on historical data distribution, and there are no restrictions here.

[0128] During device clock calibration, the platform can also adaptively adjust the frequency of clock calibration services sent to the sampler based on its historical clock drift. For example, the platform calculates the drift of the local clock relative to the server clock for each sampler between two consecutive calibrations, shortens the calibration cycle for samplers with larger drifts, and extends the calibration cycle for samplers with smaller drifts, so that the calibration frequency matches the actual drift rate of the device.

[0129] In remote firmware upgrades, the segmented download of firmware packages supports resume download after interruption. Each firmware segment is verified using its checksum, and the entire firmware package is verified using its checksum. For example, the sampler records the sequence number of successfully received segments during the segmented download process. If the download is interrupted, it resumes downloading from the most recent incomplete segment without re-downloading the entire firmware package. Each received segment's integrity is verified using its checksum. After all segments have been received, the integrity of the entire package is verified using the 256-bit digest checksum of the firmware package, forming a two-layer verification system of segmented and overall package checks.

[0130] When issuing the same sampling control command in batches, the platform can also set differentiated response timeout windows for each brand group based on the historical response latency distribution of each brand group. For samplers that do not return execution feedback within the response timeout window, the platform can reissue the sampling control command a limited number of times. For example, the platform analyzes the historical response latency from command issuance to feedback arrival for each brand group, setting longer response timeout windows for slower-responding brand groups and shorter response timeout windows for faster-responding brand groups. For samplers that still do not return feedback after exceeding the corresponding brand group's response timeout window, the platform will reissue the sampling control command within a preset number of times.

[0131] Based on the above offline determination based on a fixed multiple threshold, detecting whether the sampler is offline based on the arrival of the sampler's heartbeat packet may also include sub-steps S41 to S43.

[0132] S41. Based on the statistics of the historical packet loss rate and arrival delay of the sampler's heartbeat packets, dynamically determine the sampler's heartbeat cycle and offline judgment threshold. As an example, for samplers with high historical packet loss rates or large fluctuations in arrival delay, increase the heartbeat cycle multiple corresponding to their offline judgment threshold accordingly.

[0133] S42. In response to the fact that the time elapsed since the arrival of the most recent heartbeat packet from the sampler exceeds the offline judgment threshold, actively send a detection command to the sampler.

[0134] S43. If no response to the detection command is received from the sampler within the preset detection waiting time, the sampler is determined to be offline.

[0135] Therefore, occasional packet loss in weak network conditions will not be mistakenly identified as offline by a fixed multiple threshold, while genuine offline situations can be confirmed through active detection. The statistical measures used to determine the offline threshold, besides packet loss rate and arrival delay, can also be other statistical measures such as quantiles of the heartbeat arrival interval or the mean plus variance; no restrictions are placed here.

[0136] The generation of maintenance work orders also includes root cause aggregation. Since a single physical root cause may trigger multiple types of anomalies—for example, a sampling pump failure can simultaneously trigger both hardware failure and sampling failure—creating separate work orders would result in multiple scattered work orders pointing to the same root cause. The platform predefines the causal relationships between different anomaly types, aggregating multiple different types of anomalies triggered by the same sampler within a preset time window, causally attributed to the same root cause, into a single root cause maintenance work order. For example, if a sampler reports both a sampling pump hardware failure and a sampling failure within the same time window, and both are attributed to the sampling pump failure as the root cause according to a preset causal relationship, then they are aggregated into a single root cause maintenance work order. The causal relationships between the above anomaly types can be defined in the form of a preset rule graph, or automatically summarized based on historical anomaly co-occurrence statistics; this is not restricted here.

[0137] In other embodiments, for situations where the sampler loses connection with the platform, S4 also includes autonomous operation during disconnection and reconnection data transmission. In cases of network interruption or unavailability of the platform's remote channel, to ensure that sampling and evidence collection and device status are not lost during the disconnection period, the sampler maintains local sampling during the disconnection period and replenishes data and configuration in chronological order after reconnection. The configuration increments issued upon reconnection carry monotonically increasing configuration version numbers, enabling the sampler to perform idempotent merging of configuration increments according to version numbers, avoiding inconsistent configuration status caused by duplicate or out-of-order configuration increments. In response to the sampler detecting a disconnection with the platform, the sampler continues to perform sampling locally according to the sampling mode last issued before the disconnection, and caches the sampling records and device status locally. In response to the sampler reconnecting with the platform, the sampler retransmits the cached sampling records from the disconnection period to the platform based on the unique instruction identifier and server timestamp. The platform then populates the corresponding maintenance work order and monitoring view with the retransmitted sampling records. Reconnection also includes configuration negotiation: the sampler reports the last received configuration version before the connection loss, and the platform distributes the configuration increments generated during the connection loss period accordingly. Each configuration increment carries a monotonically increasing configuration version number. The sampler sorts and merges the configuration increments according to the configuration version number, discards expired increments with version numbers earlier than the current local configuration, and performs idempotent processing on increments carrying the same configuration version number. Local sampling during the connection loss period can be maintained by the sampler itself or by edge proxy nodes deployed on the sampler side, and then retransmitted after reconnection; there are no restrictions here.

[0138] In S4, when an anomaly is detected, the platform can first determine the severity level of the anomaly. For anomalies below the preset severity level, the platform can automatically issue a preset self-healing command and retry a limited number of times. If the retry fails, a maintenance work order is generated. For example, for minor anomalies such as short-term fluctuations in network signal, the platform can automatically issue a reconnection or reset command and retry within a preset number of times. A maintenance work order is only generated if the retry still fails, thereby reducing invalid work orders caused by transient anomalies.

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

Claims

1. A method for adaptive access and remote unified management of multi-brand water quality samplers, characterized in that, Includes the following steps: S1. Construct a general object model abstraction layer, which includes a unified object model specification and an object model mapping configuration file; for each brand and model of sampler, the object model mapping configuration file describes the mapping relationship between the sampler's private data fields and the unified object model specification, and stores them with brand identifier and model identifier as indexes; S2. Construct a protocol adaptation middleware; in response to the sampler access, load the corresponding object model mapping configuration file and protocol adaptation plugin with the brand identifier and the model identifier, and the protocol adaptation plugin performs bidirectional conversion between the sampler's private protocol message and the standard object model attribute value to complete the adaptive access of the sampler; S3. Remotely configure the sampling mode of the sampler and issue sampling control commands, and assign a unique command identifier to each sampling control command; S4. Collect the device status of the sampler and the execution feedback of the sampling control command, and detect the abnormality of the sampler according to the preset abnormality detection rules; In response to the detection of the anomaly, an operation and maintenance work order is automatically generated.

2. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 1, characterized in that, The unified object model specification describes the device capabilities of the sampler from three dimensions: attributes, services, and events. The object model mapping configuration file includes attribute mapping, service mapping, and event mapping. The attribute mapping includes the sampler's original field identifier, the corresponding standard attribute name, and the conversion coefficient and offset for converting the original value into the standard object model attribute value. The service mapping includes the command code, parameter field order, and verification algorithm type used to convert the unified service call into the sampler's private control command. The event mapping includes rules for parsing the private event packets reported by the sampler into standard event structures.

3. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 1, characterized in that, The protocol adaptation middleware defines a unified protocol adaptation interface; step S2 includes the following sub-steps: S21. Receive the registration data packet sent by the sampler, the registration data packet carrying the brand identifier, the model identifier and the firmware version number; S22. Query the object model configuration database using the brand identifier and the model identifier, and load the corresponding object model mapping configuration file and the protocol adaptation plugin; S23. Return a registration confirmation packet, which carries a session identifier and a server-side timestamp; S24. The uplink data frames of the sampler are parsed into standard object model attribute values ​​by the protocol adaptation plugin, and the unified service call is converted into the private protocol message of the sampler.

4. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 1, characterized in that, The remotely configurable sampling modes in S3 include equal time interval sampling, hourly timed sampling, cumulative traffic sampling, over-limit triggered sampling, mixed sampling, manual sampling, and uniform mixed sampling; wherein, the cumulative traffic sampling is configured to be triggered locally by the sampler based on the cumulative traffic, and the hourly timed sampling and the uniform mixed sampling are configured to be triggered by the platform side where the protocol adaptation middleware is located based on the server clock scheduling.

5. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 1, characterized in that, The step S3, which involves issuing the same sampling control command to multiple samplers in batches, includes the following sub-steps: S31. Divide the multiple samplers into several brand groups according to the brand identifier and the model identifier; S32. For each brand group, call the corresponding protocol adapter plugin to convert the same sampling control instruction into a private protocol message of the brand group, and each brand group is converted only once; S33. Assign a unique identifier to the sampling control command for each of the samplers and send them out concurrently; S34. Aggregate the execution results of each sampler according to the unique identifier of the instruction to obtain a batch execution summary.

6. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 1, characterized in that, The S3 also includes remote operation and maintenance of the sampler, including device clock calibration and remote firmware upgrade; The device clock calibration includes sending a clock calibration service carrying a server timestamp to the sampler, so that the sampler can update its local clock according to the server timestamp; the remote firmware upgrade includes sending a firmware package download address and a firmware package verification value to the sampler, so that the sampler can download the firmware package in blocks and upgrade the firmware after verification according to the firmware package verification value.

7. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 1, characterized in that, In S4: The system detects whether the sampler is offline based on the arrival status of the sampler's heartbeat packets. The execution feedback returned by the sampler is matched with the unique identifier of the instruction, and the execution status of the sampling control instruction is updated in real time. The preset anomaly detection rules include device offline, sampling failure, firmware upgrade failure, and hardware failure. In response to the detection of the anomaly, the system queries whether there is a similar, unclosed maintenance work order on the sampler within a preset cooling period. If it exists, an anomaly log is added to the maintenance work order; otherwise, a new maintenance work order is created. The maintenance work order flows sequentially through its lifecycle status: pending, in process, processed, and closed.

8. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 3, characterized in that, S2 also includes access correctness verification: When loading the object model mapping configuration file in step S22, the firmware version number reported by the sampler and the version of the object model mapping configuration file are determined to be compatible according to a preset compatibility relationship to obtain the version matching status. After parsing the uplink data frame into standard object model attribute values ​​in step S24, the standard object model attribute values ​​are compared with the reasonable value range defined by the unified object model specification for the corresponding standard attribute. If the standard object model attribute value exceeds the reasonable value range, a parsing anomaly is determined. In response to the parsing anomaly, the cause is attributed based on the version matching status. If the version matching status is mismatched, it is determined to be a configuration anomaly, a compatible configuration version is used for downgraded parsing, and an update work order is generated for the object model mapping configuration file. If the version matching status is matched, it is determined to be a sampler anomaly, and the maintenance work order is generated.

9. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 7, characterized in that, The step of detecting whether the sampler is offline based on the arrival of the sampler's heartbeat packets includes the following sub-steps: S41. Based on the statistics of the packet loss rate and arrival delay of the historical heartbeat packets of the sampler, dynamically determine the heartbeat cycle and offline judgment threshold of the sampler; S42. In response to the fact that the time elapsed since the arrival of the most recent heartbeat packet from the sampler exceeds the offline determination threshold, actively send a detection command to the sampler; S43. In response to not receiving a response from the sampler to the detection command within a preset detection waiting time, determine that the sampler is offline.

10. The method for adaptive access and remote unified management of multi-brand water quality samplers according to claim 7, characterized in that, The generation of the maintenance work order also includes root cause aggregation: based on the preset causal relationship between each type of anomaly in the preset anomaly detection rules, multiple different types of anomalies triggered by the same sampler within a preset time window and belonging to the same root cause are aggregated into a root cause maintenance work order.

Images