Edge data collection method, apparatus, device, storage medium, and program product

Abstract

The application discloses an edge data collection method and device, equipment, a storage medium and a program product, and relates to the technical field of data collection. In the application, the collection attribute information of the edge data to be collected is declared in advance in a mapping table, and a first request message for collecting the edge data of an edge device is constructed by loading the mapping table; based on the collection attribute information, the first request message meeting a preset merging condition is merged into a second request message; the second request message is sent to the edge device, and the edge data returned by the edge device based on the second request message is obtained. The efficiency of collecting the edge data of the edge device with high concurrency is improved.

Description

Technical Field

[0001] This application relates to the technical field of data acquisition, and in particular to edge data acquisition methods, edge data acquisition devices, edge data acquisition equipment, storage media, and computer program products. Background Technology

[0002] Common industrial edge data acquisition solutions include fixed-period polling for database writing and device-independent timer solutions. For the former: edge nodes (e.g., nodes running Node-RED) are configured with a fixed sampling period (e.g., 500ms or 1s) for each PLC or inverter, polling the corresponding registers and writing the returned data, line by line or batch by batch, to a time-series database via HTTP (InfluxDB HTTP API or Node-RED's InfluxDB out nodes). Error handling typically involves several retries, logging failures but often discarding the data. For the latter: a separate timer is created for each device, with threads triggering reads at the corresponding frequency. This solution is effective when the number of devices is small, but scalability and concurrency control are poor. Both are widely used in industrial scenarios with multiple protocols, multiple vendors' devices, and fluctuating networks, but they have several limitations. Specifically, they incur high request and network overhead: frequent line-by-line or small-batch database writing leads to numerous HTTP requests, consuming bandwidth and increasing latency. Equipment / PLC overload or increased timeouts: Insufficient concurrent control, a large number of read requests being initiated simultaneously (especially when polling at fixed intervals and with a large number of devices), slow PLC response or message congestion leading to increased timeouts / failures.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide an edge data acquisition method, an edge data acquisition device, an edge data acquisition equipment, a storage medium, and a computer program product, aiming to solve the technical problem of low efficiency in acquiring edge data from high-concurrency edge devices.

[0005] To achieve the above objectives, this application proposes an edge data acquisition method, which is applied to edge nodes and includes:

[0006] By loading the mapping table, a first request message for collecting edge data from the edge device is constructed, wherein the collection attribute information of the edge data to be collected has been pre-declared in the mapping table.

[0007] Based on the collected attribute information, the first request message that meets the preset merging conditions is merged into a second request message;

[0008] Send the second request message to the edge device and obtain the edge data returned by the edge device based on the second request message.

[0009] In one embodiment, the mapping table is a two-layer mapping table including a logical layer and a physical layer, and the method further includes:

[0010] Obtain the changed dataset of the mapping table, and after verifying the changed dataset of the mapping table, perform pre-verification of the new mapping table in simulation mode;

[0011] After passing the pre-verification in simulation mode, switch to the new mapping table;

[0012] If an anomaly is detected after the new mapping table takes effect, the system will automatically roll back to a historical stable version of the mapping table.

[0013] In one embodiment, after the step of constructing a first request message for collecting edge data from the edge device by loading a mapping table, the method further includes:

[0014] By embedding key nodes in the edge data acquisition link, key metric data can be obtained;

[0015] Based on a preset sliding sampling window, the response metrics of the edge device are calculated, wherein the response metrics include average response time and error rate;

[0016] Based on the response indicators, adjust the sampling interval of the edge data collected by the edge acquisition device.

[0017] In one embodiment, the step of merging the first request message that meets the preset merging conditions into a second request message includes:

[0018] Based on the maximum number of merged registers in the first request message that meets the preset merging conditions, the first weight corresponding to the average response time in the response indicators of the edge device, the second weight corresponding to the error rate, and the normalized weight of the device capability of the edge device, the merging window size for merging the first request message that meets the preset merging conditions into the second request message is adaptively adjusted.

[0019] Based on the merging window size, the first request messages that meet the preset merging conditions are merged into a second request message.

[0020] In one embodiment, the step of sending the second request message to the edge device and obtaining edge data returned by the edge device based on the second request message includes:

[0021] Based on the data format of the original edge data, the data values ​​are parsed and generated, and the time series data is generated based on the data values ​​and written into the time series database in batches.

[0022] In one embodiment, the step of writing the time-series data into the time-series database includes:

[0023] When the batch writing of the time series data to the time series database fails, the failed time series data will be appended to the local file in the callback.

[0024] A preset number of data records are periodically read from the local file and written back to the time-series database in sequence.

[0025] Furthermore, to achieve the above objectives, this application also proposes an edge data acquisition device, which includes:

[0026] The first module is used to construct a first request message for collecting edge data from the edge device by loading a mapping table, wherein the collection attribute information of the edge data to be collected has been pre-declared in the mapping table;

[0027] The second module is used to merge the first request message that meets the preset merging conditions into a second request message based on the collected attribute information.

[0028] The third module is used to send the second request message to the edge device and obtain the edge data returned by the edge device based on the second request message.

[0029] In addition, to achieve the above objectives, this application also proposes an edge data acquisition device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the edge data acquisition method as described above.

[0030] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the edge data acquisition method described above.

[0031] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the edge data acquisition method described above.

[0032] One or more technical solutions proposed in this application have at least the following technical effects:

[0033] In this application, the acquisition attribute information of the edge data to be collected is pre-declared in the mapping table. A first request message for collecting edge data from the edge device is constructed by loading the mapping table. Based on the acquisition attribute information, the first request message that meets the preset merging conditions is merged into a second request message. The second request message is sent to the edge device, and the edge data returned by the edge device based on the second request message is obtained. Thus, through declarative configuration driven by the mapping table, devices, fields, types, byte order, sampling frequency, etc., are centrally declared. Adding a new device only requires modifying the mapping table without changing the code, decoupling configuration from logic and improving engineering scalability. Furthermore, the poller can determine the merging conditions before sending the acquisition request and merge adjacent mapping items into a single batch read request, reducing the number of underlying messages and the PLC load. Ultimately, this improves the efficiency of high-concurrency acquisition of edge data from edge devices. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a flowchart illustrating the first embodiment of the edge data acquisition method of this application.

[0037] Figure 2 A schematic diagram of the overall system architecture provided for the edge data acquisition method of this application;

[0038] Figure 3 A schematic diagram of the poller workflow provided for the edge data acquisition method of this application;

[0039] Figure 4 A schematic diagram of the formatter parsing process provided for the edge data acquisition method of this application;

[0040] Figure 5 A schematic diagram of the local caching and playback process provided for the edge data acquisition method of this application;

[0041] Figure 6 A schematic diagram of the adaptive sampling process provided for the edge data acquisition method of this application;

[0042] Figure 7 This is a schematic diagram of the module structure of the edge data acquisition device according to an embodiment of this application;

[0043] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the edge data acquisition method in this application embodiment.

[0044] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0045] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0046] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0047] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or edge data acquisition device capable of performing the above functions. The following description uses an edge data acquisition device as an example to illustrate this embodiment and the subsequent embodiments.

[0048] This application provides an edge data acquisition method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the edge data acquisition method of this application.

[0049] In this embodiment, the edge data acquisition method includes steps S10 to S30:

[0050] Step S10: By loading the mapping table, a first request message for collecting edge data from the edge device is constructed, wherein the collection attribute information of the edge data to be collected has been pre-declared in the mapping table.

[0051] In one embodiment, pre-deployment and environment preparation are performed: Node.js (version 18 or higher) and Node-RED (version 4.1.0) are installed on the edge computing host. The edge host refers to a server or industrial PC located near the production line, responsible for collecting and preprocessing data. Protocol nodes are installed in Node-RED: node-red-contrib-modbus (Modbus protocol node), node-red-node-influxdb (InfluxDB write node), node-red-contrib-opcua (OPC UA protocol node), node-red-contrib-ads-client (ADS protocol node), and node-red-dashboard (for simple visualization). An InfluxDB cluster (InfluxDB v1.8.10 in the example) is deployed in the backend. The HTTP write address (URL), database name (e.g., oled_timeseries), and authentication information (username / password or token) are verified. In a preferred embodiment, Node-RED is run as a system service (NSSM can be used under Windows) to ensure automatic restart and stable operation; InfluxDB is configured with a load balancer (such as NGINX) to distribute write traffic.

[0052] It should be noted that device and field information is centrally managed in the form of a JSON mapping table. Each entry in the mapping table includes device identifier, protocol type (Modbus / ADS / OPC UA), register start address and length, field name, field data type and byte order, sampling interval, priority, and tag. The device connectivity is as follows: edge nodes communicate directly with the field PLC / inverter through the corresponding protocol node (Modbus TCP / RTU, ADS, OPC UA). The mapping table is loaded into the global context by the edge node at startup or runtime for scheduling purposes. This declarative mapping completely decouples configuration from runtime logic; adding / modifying devices only requires adjusting the mapping table, without changing the process code, thus improving reproducibility and engineering scalability.

[0053] When loading and managing the mapping table, a JSON file (e.g., mapping.json) is used to declare all device and field information. The structure is an array, and each record contains: device_id (device identifier), protocol (protocol type, such as Modbus / ADS / OPC UA), unitId (Modbus station number), startAddr (register start address), length (number of registers), measurement (Influx measurement name), fieldNames (list of field names), types (data type and byte order description for each field, such as float32_be indicating big-endian 32-bit floating-point), interval_s (expected sampling interval, seconds), priority (priority), and tags (static tags). At startup, this JSON is read using Node-RED's File In node or startup script and written to Node-RED's Global Context: global.set('mapping', mappingArray). Poller retrieves the mapping table from the global Context at runtime.

[0054] Here is an example of a mapping.json file: [

[0056] {

[0057] "device_id":"VCD01",

[0058] "protocol":"modbus",

[0059] "unitId":1,

[0060] "startAddr":40001,

[0061] "length":4,

[0062] "measurement":"vcd",

[0063] "fieldNames":["chamber_vac","hotplate_temp","coldplate_temp","dummy"],

[0064] "types":["float32_be","float32_be","float32_be","uint16"],

[0065] "interval_s":1,

[0066] "priority":1,

[0067] } ]

[0069] In one feasible implementation, the mapping table is a two-layer mapping table including a logical layer and a physical layer, and the method further includes:

[0070] Obtain the changed dataset of the mapping table, and after verifying the changed dataset of the mapping table, perform pre-validation on the new mapping table in simulation mode;

[0071] After passing the pre-verification in simulation mode, switch to the new mapping table;

[0072] If an anomaly is detected after the new mapping table takes effect, the system will automatically roll back to the mapping table of a previous stable version.

[0073] It's important to note that the mapping table not only declares the device's logical attributes (measurement / tags / fieldNames), but also explicitly records the low-level addressing information required for physical access: protocol (Modbus / ADS / OPC UA), unitId (Modbus station number / node identifier), startAddr (low-level register start address), length (number of registers), and types defined by field (including byte order identifiers such as _be / _le). This information is used by the edge Poller to directly construct protocol messages and complete register-level access; therefore, the mapping table is not merely an abstract product model for the cloud, but a necessary structure driving edge runtime behavior and message organization.

[0074] To improve the reliability, security, and maintainability of the mapping table, this embodiment designs the mapping table as a two-layer structure and supports the verification, simulation, hot loading, and automatic rollback of change packets. Its data structure is as follows: product_mapping (logical layer) is used to declare semantics / measurement points: product_id, measurement, field names, tags, semantic information (semantic_info); physical_mapping (physical layer) is used to drive the low-level information accessed at the edge runtime: device identifier (device_id), protocol type (protocol), unitId, register address (startAddr), length, types, sampling interval (interval_s), priority; change packet (mapping_patch) structure: patch_id, prev_version, target_version, changes, checksum, digital signature, simulation flag (dry_run_flag).

[0075] The application change process (hot reloading and rollback) is as follows: 1) Upon receiving the mapping_patch, the edge node first verifies the checksum and signature. If the verification fails, it is rejected. 2) If dry_run_flag=true, the edge node performs a short-term data collection (e.g., 10 polling cycles) on the new mapping in simulation mode and detects parsing / merging anomalies. If an anomaly is detected, it is rejected and an error is reported. 3) After successful simulation, an atomic switch is performed: first, the system checkpoint is recorded (recording the current sequence number seq_no, outline offset, and active request status), and the global mapping table version is switched to ensure no data interruption during the switch. 4) If a serious anomaly is detected after the new version takes effect (e.g., a significant increase in parsing failure rate or timeout), the system automatically rolls back to the historical stable version prev_version based on the checkpoint, and generates event and audit logs for manual verification.

[0076] Thus, 1) configuration and operation logic are decoupled: the logic layer and physical layer are separated. When adding or modifying devices, only the corresponding level configuration of the mapping table needs to be adjusted, without modifying the core process code of the edge nodes, which greatly improves the scalability and reproducibility of the project and solves the operation and maintenance pain points of traditional solutions where configuration and code are bound together; 2) hot update reliability is guaranteed: through simulation pre-verification, atomic switching and automatic rollback, data acquisition anomalies, data acquisition stoppages or parsing errors are avoided when the mapping table is updated on site, meeting the core requirement of uninterrupted operation in industrial scenarios; 3) configuration security and maintainability are improved: checksum and digital signature mechanisms block illegal configuration changes, and version management and audit logs enable full-link traceability of configuration changes, reducing production risks caused by configuration errors in industrial sites; 4) multi-protocol scenario adaptation is supported: the physical layer centrally manages the underlying access parameters of different protocols (Modbus / ADS / OPC UA), and the logic layer has a unified semantic definition, providing a standardized data foundation for subsequent intelligent polling and unified parsing, solving the compatibility problem of multi-vendor device access.

[0077] Step S20: Based on the collected attribute information, merge the first request message that meets the preset merging conditions into a second request message;

[0078] Regarding the poller entry point (Poller): In Node-RED, a timed trigger (Inject node) is used to trigger the Poller (Function node). The Poller retrieves the mapping table from global.get('mapping') and maintains the internal states context.idx (polling index), context.lastSuccess (last success time on each device), and context.active (current concurrency count). The Poller's tasks are: to determine which mapping entries have reached the sampling time (based on interval_s), to decide whether to merge adjacent mapping entries (if they are on the same station number and have consecutive addresses and the number of registers after merging is within the threshold), to construct a request message msg and send it to the protocol adapter node (msg contains msg._mapping, msg._request_ts, msg.payload.address / quantity, and optional msg._merge_info). In a preferred embodiment: a concurrency token (activeCount) is implemented in the Poller to control the number of concurrent requests (e.g., maxConcurrent=3), and merging is implemented at the Poller layer to reduce the number of messages and keep the process simple.

[0079] Step S30: Send a second request message to the edge device and obtain the edge data returned by the edge device based on the second request message.

[0080] Regarding the protocol adapters (Modbus / ADS / OPC UA), for Modbus TCP: Configure the Modbus client on the Node-RED (fill in the controller PLC's IP, port, and timeout), and use the modbus-read or modbus-flex node to send read requests. The msg.payload.address, msg.payload.quantity, and msg.unitId sent by the Poller are received and executed by the protocol node. For ADS or OPC UA: Use the corresponding Node-RED node, configuring timeout and retry policies for each node; some OPC UA nodes directly return parsed values ​​(instead of register arrays), and the Formatter needs to be compatible with these different return formats. In a preferred embodiment, Modbus TCP (network version) is preferred; if the field uses Modbus RTU (serial port), access is through the RTU gateway or serial port node.

[0081] In another feasible implementation, the step of sending a second request message to the edge device and obtaining edge data returned by the edge device based on the second request message includes:

[0082] Based on the data format of the original edge data, the data values ​​are parsed and then time series data is generated based on the data values. The time series data is then written into the time series database in batches.

[0083] Regarding the formatter—parsing and building time-series points: The formatter is a function node that receives raw data returned by the protocol adapter (common fields such as direct values ​​of OPC UA). The formatter uses the types in the mapping table to specify the data format of each field (e.g., float32_be represents big-endian 32-bit floating-point), first converting the register array into binary register buffer data (each register occupies 2 bytes), and then parsing the values ​​sequentially according to the field type. For requests that have been merged by the Poller, the formatter, based on the offset recorded in msg._merge_info, splits large blocks of data back into their original mapping items and parses them separately. After parsing, it generates InfluxDB points. Each point contains measurement, tags, fields (field name → value), and time (timestamp), and adds quality (quality flag, 1 / 0) and src_ts (device raw timestamp or request time) to the fields. Finally, a batch of points is placed into the batch write queue. In a preferred embodiment, the field type and byte order are explicitly written in the mapping table to avoid runtime guessing or manual debugging; the batch queue size is set to 200–1000 and the time precision is set to ms.

[0084] In one feasible implementation, the step of writing time-series data into the time-series database includes:

[0085] When the batch writing of time series data to the time series database fails, the failed time series data will be appended to the local file in the callback.

[0086] A preset number of data records are periodically read from a local file and written back to the time-series database in sequence.

[0087] In this embodiment, a local ordered caching and replay module ensures zero data loss and ordered replay: When a batch write to InfluxDB (a time-series database) fails (e.g., due to an HTTP error or cluster unavailability), the batch of points is serialized into a single line of NDJSON (one JSON object per line) and appended to the local file outbox.log in the callback. Recorded fields include monotonically increasing seq_no, original timestamp src_ts, a points array, first failure time first_failed_ts, and number of attempts attempts. This ensures persistent retention even during edge restarts. The replay unit periodically (e.g., every 10 seconds) reads the first N records from the cache file and writes the points back to InfluxDB in batches according to src_ts or seq_no. During writing, a write-back flag replay_flag=1 is added to each point for distinction. Successful writes delete or mark the cached entry; failures result in exponential backoff retries and an alarm when a threshold is exceeded.

[0088] In this embodiment, writing to the TSDB (Time Series Database) and visualization: Pre-built points are written in batches using Node-RED's influxdb out node or by directly calling the Influx HTTP API. During writing, time precision (e.g., precision=ms) and batch size (recommended batchSize: 200–1000 points, optimized based on on-site throughput) are configured. The visualization layer uses Grafana (connected to InfluxDB) or Node-RED's Dashboard to display key variables (such as vacuum level, temperature, etc.) for operational convenience. Grafana is an open-source monitoring solution for visualizing large-scale metric data. Node-RED Dashboard is a plugin that provides a visualization interface for IoT and automation projects, allowing users to quickly build monitoring and control panels without writing front-end code. Preferred solution: Configure retention policies for key measurement points (e.g., retain raw data for 7 days, retain 1-minute downsampled data for longer) to save storage and support historical analysis. InfluxDB can process tens of thousands of data entries per second. Saving all of this data would consume a lot of storage space. Sometimes it may not be necessary to store all historical data, and InfluxDB itself does not provide data deletion operations. Therefore, InfluxDB introduced Retention Policies (RPs) to customize the retention time of data.

[0089] In one feasible implementation, after the step of constructing a first request message for collecting edge data from the edge device by loading a mapping table, the method further includes:

[0090] By embedding key nodes in the edge data acquisition link, key metric data can be obtained;

[0091] Based on a preset sliding sampling window, the response metrics of the edge device are calculated, including average response time and error rate.

[0092] Adjust the sampling interval of edge data collected by edge devices based on the response indicators.

[0093] In this embodiment, runtime closed-loop optimization is achieved through a metrics acquisition and adaptive control module: key information is collected at nodes such as Poller, Protocol, and Formatter, including request time (request_ts), response time (response_ts), latency (latency_ms), success / failure flag (success), cache queue length (cache_queue_len), and batch write latency (db_write_latency). This metric data is written to Influx measurement variables (e.g., named node_red_metrics) for adaptive control calculations. The adaptive controller calculates the average response time (RTT_mean) and error rate (ERR_rate) for each device using a sliding window (e.g., the most recent 60 samples). When these metrics exceed preset thresholds, the sampling interval (interval_s) for the corresponding device is automatically increased (e.g., multiplied by α>1), and the merging strategy is tightened (reducing the merging size). When the metrics recover well, the sampling interval is gradually reduced (multiplied by β<1) to restore high-frequency sampling. The adjustment operation is constrained by the cooldown period (e.g., 60 seconds) and the minimum / maximum interval boundary to avoid frequent oscillations.

[0094] In another feasible implementation, the step of merging the first request message that meets the preset merging conditions into a second request message includes:

[0095] Based on the maximum number of merged registers in the first request message that meets the preset merging conditions, the first weight corresponding to the average response time in the response indicators of the edge device, the second weight corresponding to the error rate, and the normalized weight of the device capability of the edge device, the merging window size for merging the first request message that meets the preset merging conditions into the second request message is adaptively adjusted.

[0096] Based on the merge window size, first request messages that meet the preset merge conditions are merged into second request messages.

[0097] In this embodiment, a device capability awareness (DeviceProfile) and event-driven (i.e., supporting upper-layer event triggering) mechanism are added to the original Poller. This allows the merge window and concurrent allocation to adaptively adjust at runtime based on the device's real-time capabilities and network conditions (such as sliding window average round-trip latency (RTT_mean), error rate (ERR_rate), local cache queue length (cache_len), and PLC maximum capacity (PLC_capacity_estimate)). This protects the PLC and network during periods of fluctuation or peak activity and improves merging efficiency during idle periods. Its module composition is as follows:

[0098] DeviceProfile: Maintains RTT_mean (sliding window average round-trip delay in milliseconds), ERR_rate (errors 0-1), cache_len (local write queue length), and PLC_capacity (device capacity estimate, register reads / second) for each device.

[0099] MergeDecision: Calculates merge based on the thresholds configured in DeviceProfile and mapping. window ;

[0100] EventHandler: Receives events from the upper layer and triggers immediate sampling of the corresponding mapping items according to priority;

[0101] Poller main loop: Builds merge requests based on MergeDecision and calls the protocol adapter.

[0102] Define merge window (in units of registers) merge window The calculation formula is:

[0103]

[0104] in: Configure the maximum number of merged registers (maxBatchRegisters in the mapping table, recommended engineering value is 80–120). The weights based on RTT_mean are defined as follows: ; The average round-trip time (ms) for the device sliding window; For reference delay (e.g., 100ms);

[0105] This is a smoothing coefficient, typically set between 0.5 and 2, used to control the rate at which the RTT (Recovery Time) decays within the merging window. A higher RTT results in a smoother finish. The smaller the value, the smaller the merging window, in order to reduce the amount of data requested per request and the pressure on the PLC;

[0106] The weights based on the error rate ERR_rate are defined as follows: ; The error rate of the most recent sliding window (0~1), This is the weight sensitivity coefficient, recommended to be 1-5, to control the impact of the error rate on the linear reduction of the merge window. A higher error rate results in a lower sensitivity coefficient. The lower the value, the less likely the merging will be to increase the probability of success. The normalized weights for PLC capabilities are defined as follows: . The maximum register reading per second (approximate value) that the PLC can withstand is obtained by probe and historical observation. The maximum capacity or configuration limit of all PLCs is used for normalization (to avoid the influence of extreme values). If the PLC has strong capabilities, the merge window is enlarged; if it has weak capabilities, it is shrunk.

[0107] It should be noted that in the aforementioned calculation formula, floor (rounding down, its symbol is: (meaning rounding down x) and ensuring that the number of registers is at least 1. and It can be tuned and recorded as a mapping / configuration item during deployment. This formula, at runtime, causes the merge window to decrease as device latency or error rate increases, thus protecting the PLC.

[0108] In addition, Poller checks the concurrency token `activeCount` before initiating a request; if `activeCount` is less than the maximum concurrency limit `maxConcurrent` (global or device-level), it postpones the request. `maxConcurrent` can be configured globally or at the device level. The number of incomplete read requests is managed through the concurrency token (`activeCount`), preventing the PLC from being overwhelmed when multiple devices collect data simultaneously. Furthermore, upper-level events carry a priority flag; when an event is triggered, Poller temporarily increases the priority of the corresponding device and can utilize the "event priority token pool" to preempt concurrent resources, ensuring the immediate sampling needs of critical business scenarios.

[0109] Therefore, the PLC and network load are dynamically optimized: by adjusting the merging window through device capability awareness, the merging scale is reduced in high latency and high error rate scenarios, the amount of data in a single request is reduced, and the processing pressure on the PLC is reduced; when the load is low, the merging window is expanded to reduce the number of messages and network overhead, thus solving the problem of poor load adaptability of traditional fixed merging strategies.

[0110] Improve the success rate of data acquisition in high-concurrency scenarios: The combination of concurrent token control and event priority scheduling not only avoids PLC timeouts caused by a massive influx of requests at the same time, but also ensures timely response to critical events, thus addressing the pain points of insufficient concurrent control in traditional solutions.

[0111] Closed-loop optimization supporting adaptive sampling: The latency, error rate, and other metrics collected by DeviceProfile provide core data input for the adaptive sampling module of the overall solution, enabling coordination between merging strategy adjustment and sampling interval optimization, forming a closed loop of perception-decision-execution, and improving the overall robustness of the system.

[0112] Adapting to the dynamic needs of industrial scenarios: Event-driven scheduling supports real-time sampling triggered by upper-level business processes such as process switching and abnormal alarms, breaking through the limitations of traditional fixed-cycle polling, and meeting the on-demand collection needs of industrial production lines for key operating condition data, such as the sudden monitoring scenarios of printhead temperature and vacuum degree in OLED inkjet printing systems.

[0113] With the increasing number of devices and the diversification of protocol types (such as Modbus / ADS / OPC UA) in industrial production lines, traditional data acquisition solutions such as fixed-period polling for database writing and device-specific timers are prone to problems such as high request and network overhead, PLC overload leading to increased timeouts, data loss or out-of-order processing, heterogeneous register parsing errors, and lack of adaptive sampling capabilities. These issues make it difficult to meet the high reliability requirements of time-series analysis and quality traceability in industrial scenarios. To address this problem, this application relates to an industrial edge data acquisition and time-series data playback method, particularly for multi-protocol industrial environments (such as OLED inkjet printing production lines). It describes a method and system for highly reliable acquisition, orderly storage, and playback of data from field controllers (PLCs / inverters) based on edge nodes, achieving efficient access to multi-protocol devices and ensuring data consistency, thereby improving the stability and scalability of industrial data acquisition.

[0114] Reference Figure 2 In one application scenario of this application, a mapping table-driven adaptive edge data acquisition and ordered playback method for multi-protocol industrial environments (such as OLED inkjet printing systems) is proposed. This method addresses the shortcomings of traditional fixed polling in terms of concurrency pressure, data loss, and parsing consistency through five mechanisms: mapping table driving, intelligent polling merging, unified parsing, ordered persistent playback, and adaptive sampling, achieving highly reliable and scalable data acquisition and playback. The system can be deployed based on Node-RED and InfluxDB, and specifically includes the following steps:

[0115] 1. Declarative configuration driven by mapping tables. Devices / fields / types / byte order / sampling frequency are declared centrally. Adding a new device only requires modifying the mapping table without changing the code. Configuration and logic are decoupled, resulting in strong project scalability.

[0116] 2. Mapping table-driven intelligent polling and batch merging: The poller can determine the merging conditions before sending and merge adjacent mapping items into a single batch read request, reducing the number of underlying messages and PLC load. (1) The mapping table-driven poller is triggered by a short period of time and generates read tasks from the mapping table according to priority / index. The poller supports batch merging of entries from the same site, with consecutive addresses or close neighbors to reduce messages. (2) Before initiating a request, a concurrent token (activeCount) is used to limit concurrent reads that have not yet been completed, and a limited number of retries and exponential backoff are implemented for failed requests.

[0117] Traditional solutions often lack a unified type / byte order parsing strategy for heterogeneous registers, leading to value parsing errors. 3. A unified formatter and type / byte order support, achieved by controlling the number of concurrent requests through `activeCount` and employing exponential backoff and maximum retries to reduce the impact of short-term jitter on the PLC: The formatter receives the raw register values ​​returned by the protocol node and, based on the `types` description in the mapping table (uint16 / int16 / uint32 / float32_be / float32_le, etc.), performs byte reassembly and type conversion according to data type and byte order, generating unified timing points (measurement / tags / fields / time). If merging is performed during polling, the formatter restores the fields of each original mapping item based on the merge offset information. This enables declarative type / byte order parsing at the edge, resolving parsing errors caused by encoding differences between different vendors in one go, and reporting parsing quality and source timestamps (src_ts) at each point for downstream disinfection and traceability.

[0118] Traditional solutions lack an ordered persistent replay mechanism when write operations fail. Simply discarding data or randomly retrying can lead to data loss or out-of-order replay, affecting time-series analysis and quality traceability. 4. Ordered persistent caching and source-based time-series replay (Cache & Replay): The Formatter supports declaring types (including float / int and byte order) in the mapping, accurately parsing different vendor register encodings at runtime to reduce parsing errors. When a write operation fails, data is written to an append-only cache according to the monotonic sequence number and src_ts (Redis's append-only file mechanism is a persistence method that ensures data reliability by recording each write operation command). After recovery, data is replayed in an ordered manner according to time / sequence number, with the replay source marked to avoid out-of-order replay and data loss. An append-only ordered persistent cache (NDJSON / local DB) records batches of write failures. Cache entries include monotonic seq_no, original src_ts, and dotted arrays. The replay module writes back in batches according to seq_no / src_ts order when the database is available, marking the replay_flag during the write operation. Therefore, it can ensure zero data loss and consistent data timing after playback in the event of short-term database failure or network instability, without compromising the timing assumptions of subsequent quality analysis.

[0119] Currently, fixed sampling strategies cannot automatically adjust based on runtime latency, errors, and capacity, resulting in a mismatch between performance and reliability. 5. Adaptive Sampling and Closed-Loop Control: This involves automatically adjusting the sampling interval and merging strategy for each device based on runtime latency and error rate to achieve a dynamic balance between performance and data accuracy. Edge nodes continuously collect runtime metrics (Request Time To Transaction (RTT), error rate, cache queue length, etc.), and calculate RTT_mean and ERR_rate for each device using a sliding window. When a metric exceeds a threshold, the sampling interval for that device is proportionally increased, and the merging scale is reduced. Once the metric recovers, the sampling interval is gradually reduced. Adjustments are made based on cooling-off periods and min / max boundary constraints to avoid oscillations. Therefore, a metric-driven adaptive sampling closed-loop is introduced to achieve a runtime strategy that prioritizes load protection and maximizes accuracy within acceptable limits. This automatically protects the PLC and database during peak loads while resuming high-frequency sampling during idle periods.

[0120] The above is especially important for industrial production lines (such as OLED inkjet printers): ensuring reliable acquisition of high-frequency key variables (vacuum, printhead temperature, etc.) while maintaining stable system operation under large-scale equipment.

[0121] The following is for reference Figure 3 The poller will be introduced below:

[0122] Timing trigger: Use the Inject node of Node-RED as a timing trigger, with a default of once per second; you can also use the cron-plus node to create more complex trigger strategies (such as triggering by minute table or by process section). Using Inject (1s) is simple and reliable, saving implementation costs.

[0123] Read mapping[idx]: The Poller reads the mapping table array from global.get('mapping'), and uses context.idx as the loop index to check each item one by one to see if it's time to sample. Here, idx is the index variable of the mapping table array; maintain context.lastSuccess[device_id] (the last successful read time) to determine if interval_s has been reached. Preferred solution: Also maintain the device priority (priority field), and check high-priority devices first during polling to ensure that key measurement points are sampled first.

[0124] Check interval_s (if it has expired): Calculate now - lastSuccess >= interval_s * 1000, that is, check if the time difference between the current time now and the last successful read time lastSuccess has expired. If it is satisfied, this mapping item can be sampled; to avoid a large number of simultaneous triggers caused by "time jitter", a small random jitter can be added to interval_s to stagger the sampling time. Jitter (a small amount of random offset) can be used to reduce the peak of simultaneous triggers.

[0125] Concurrent token judgment activeCount < maxConcurrent: Maintain active (the number of ongoing requests) in the context, and check active < maxConcurrent before issuing a new request. If the upper limit has been reached, skip this trigger or wait for the next round. maxConcurrent can be set to 3 to 5, and this value can be adjusted during deployment based on the PLC's load capacity and network conditions.

[0126] Merge judgment (canMerge): The merge conditions generally include: the same unitId (the same Modbus station number), adjacent starting addresses, or the address spacing within an acceptable threshold (for example, adjacent starting addresses or address spacing ≤ 2 register memory lengths), and the total number of registers after merging ≤ maxBatchRegisters (for example, 80 - 120, limited by the Modbus message length). During implementation, traverse the subsequent items in the mapping table to determine if they can be merged with the current item, and only merge within the same round (to avoid delaying the current item by waiting for data from other cycles).

[0127] Build the request (merged or single): Construct the message to be sent. Key fields include:

[0128] msg._mapping: The current mapping item (or an array when merging).

[0129] msg._request_ts: Request initiation timestamp (milliseconds).

[0130] msg.payload={address:startAddr,quantity:length}: Modbus read address / number of registers.

[0131] msg.unitId: Station number.

[0132] msg._merge_info (optional): If merging, record the offset and length of each sub-item in the merge block. Example: [{entryIndex,offsetRegs,length},...].

[0133] Among them, merge_info can be recorded with an explicit structure, which makes it easier for Formatter to recover.

[0134] Issue a read request and increment `active`, which increments the ongoing request count (`active`) by 1. Send the constructed message to the corresponding protocol node (Modbus / ADS / OPC UA), and before sending, perform `context.set('active', active+1)`, which increments `context.active` (the current concurrency count) by 1 and then updates the original `context.active`. After sending, wait for the callback. It's best to add a trace index (`trace_id`) to the message (for log tracing). You can carry the trace index `trace_id` or the log index `log_id` in the message for end-to-end tracing of a request (for easier troubleshooting).

[0135] Waiting for callbacks: After receiving a response, the protocol node sends the result along with the original message (with _mapping, _merge_info, _request_ts) to the Formatter; if a timeout or error occurs, the error callback path is followed. A reasonable timeout (e.g., 2 seconds) should be set on the protocol node to avoid occupying concurrent tokens for an extended period. Specifically, the protocol node sets a timeout threshold and returns a clear error code upon timeout or error. The Poller or upstream node then determines whether to retry or record the failure based on the error code.

[0136] Callback success / failure handling: Success path: The protocol node sends the data to the Formatter; simultaneously, `context.active--` is decremented by 1 (the number of ongoing requests is active), and `context.lastSuccess[device_id] = Date.now()` is updated to the success time, where `Date.now()` represents the current time, meaning the current time is used as the success time to update `context.lastSuccess[device_id]` (the last successful read time). Failure path: Maintain `retryCount` (retry count). If `retryCount <= retryMax`, where `retryMax` is the preset retry count threshold, then the request is rescheduled according to exponential backoff (e.g., preset baseDelay × 2^retryCount); if the number of retries is exceeded, the collection point is recorded as failed (e.g., writing a point with quality=0 or generating a log / alarm), and `active--` is applied. Preferably, `retryMax` = 3 and `baseDelay` = 200ms; for critical measurement points, the maximum number of retries can be increased or the priority can be raised, and a manual alarm can be triggered.

[0137] The following is for reference Figure 4 This section introduces formatters:

[0138] Receive the raw register array: The raw return value is uniformly obtained in the Formatter node and normalized into an array `regs`. `t_request = msg._request_ts` (request time) and `t_response = Date.now()` (response time) are recorded, and the real-time response latency (`latency = t_response - t_request`) is written as a metric parameter to `node_red_metrics`. If the protocol has already returned a directly parsed value (OPC UA), these values ​​are directly wrapped into dots, skipping the register-to-buffer conversion step.

[0139] Register array to Buffer (endian / big-endian writing): Converts a register array to a Node.js Buffer (2 bytes per register). For example, big-endian syntax:

[0140] function regsToBufferBE(regs){

[0141] let buf = Buffer.alloc(regs.length*2);

[0142] for (let i=0;i <regs.length;i++){

[0143] buf.writeUInt16BE(regs[i]&0xFFFF,i*2);

[0144] }

[0145] return buf;

[0146] }

[0147] Handle little-endian or special byte order as needed. Preferably, explicitly specify the byte order (float32_be or float32_le) in the mapping table types, and avoid guessing at runtime.

[0148] Parsing is performed field by field according to mapping.types: Iterating through mapping.fieldNames and mapping.types, the corresponding number of registers is consumed based on the type (e.g., uint16 / int16 occupies 1 register, float32 / uint32 occupies 2 registers), and the actual value is parsed using the buffer's read methods (e.g., readFloatBE, readUInt32BE, etc.). If the request is a merged read (msg._merge_info is available), the merged block is first split into the register sequence of each original mapped item according to the offset, and then parsed according to its type. For non-standard values ​​obtained from parsing (e.g., NaN, Infinity, or extreme values), protection logic can be set; if parsing fails, the quality of that field is set to 0 and an error log is logged.

[0149] Constructing Influx data points: Each field creates an Influx point structure (measurement, tags, fields, time), for example:

[0150] let point={

[0151] measurement:mapping.measurement,

[0152] tags:Object.assign({device_id:mapping.device_id}, mapping.tags ||{}),

[0153] fields:{},

[0154] time:src_ts || t_request

[0155] };

[0156] point.fields[fieldName] = val;

[0157] point.fields.quality=(val===null ? 0 : 1);

[0158] point.fields.src_ts=src_ts || t_request;

[0159] Collect points from multiple fields into an array `points`, ready for batch writing. If the PLC can provide device timestamps, prioritize using `src_ts`; simultaneously, record `write_ts` (write time) after writing for comparison and auditing.

[0160] Batch write strategy: Use a memory queue `batchBuffer`. Writes are triggered when `batchBuffer.length` (the length of the `batchBuffer`) is greater than or equal to `batchSize` or when `batchTimeout` (a time threshold) is reached. Writes are performed in batches to InfluxDB via the `influxdb out` node or the HTTP API. An initial recommended `batchSize` is 200 to 1000, which should be adjusted based on actual write latency and memory availability.

[0161] Success or failure handling for write: Successful write: Send single or aggregated data to the Dashboard, record and write delay to the metric parameter, and process the next batch.

[0162] Serialize the batch into NDJSON lines and append them to the local outbox.log (see...) Figure 4 This triggers the replay process and records information such as first_failed_ts and attempts=1.

[0163] In one embodiment, an operational alarm (email / SMS / work order) is generated immediately upon failure, while data is cached to ensure no data loss.

[0164] The following is for reference Figure 5 This section introduces local caching and playback:

[0165] Detecting database write failures (Chinese description): When an InfluxDB out node or an HTTP write request throws an error or returns a 5xx / 4xx status, a failure branch is triggered. The error type (e.g., network timeout, 503 service unavailable, authentication error, etc.) is recorded for subsequent analysis. 5xx (server error) errors are cached and retried; 4xx (client / authentication error) errors are directly alerted and batch writes are paused to avoid accumulating useless cache.

[0166] Added to local append-only cache: The cache format uses NDJSON (each line is a JSON object, facilitating appending and line-by-line reading), example fields:

[0167] {

[0168] "seq_no":12345,

[0169] "src_ts":"2025-08-10T12:00:00Z",

[0170] "points":[...],

[0171] "attempts":1,

[0172] "first_failed_ts":"2025-08-10T12:02:00Z"

[0173] }

[0174] Usage: In the failure callback, call the file append write (be careful of locking or atomic operations for concurrent writes). You can use local Kafka or Redis Streams for temporary persistence.

[0175] The replay scheduler reads from the cache: The replayer runs at fixed intervals (e.g., every 10 seconds), reading the first N entries in ascending order of seq_no (the size of N is set according to system throughput and DB recovery performance, typically 50–200), and assembling these entries into a replay batch. If a file is used, the replay progress is saved using a read offset (checkpoint) method; if SQLite is used, replayed rows can be deleted directly.

[0176] Batch replay and success determination: During replay, the records are sorted according to the original `src_ts`, written to InfluxDB, and `replay_flag=1` is injected into the field for future differentiation and analysis. If the write is successful, the record is deleted from the cache or marked as replayed; if the write fails, "attempts" is incremented by 1 (e.g., changed from 1 to 2), and retrying continues according to the retry strategy (exponential backoff). An alert and manual intervention are triggered when the attempt limit is exceeded. The replay rate can be limited (e.g., a limit on the number of records written per second) to avoid overwhelming the database by writing a large amount of cached data back in a short period.

[0177] Replay success deletion or failure alarm: Success path: Delete or mark the cached entry, and record the number of replays, replay latency, etc. in metrics; Failure path: If attempts exceed the threshold (e.g., 10 times), trigger an operation and maintenance alarm and save the entry as a manual intervention item. Additionally, replay logs (including replay_flag) can be maintained, and replay events can be written to the audit log for quality traceability.

[0178] The following is for reference Figure 6 This section introduces adaptive sampling:

[0179] Metrics Collection: Necessary metrics are recorded on the Poller, Formatter, and Protocol nodes: request_ts, response_ts, latency_ms (response latency), success (1 or 0), device_id, payload_size (effective payload size), cache_queue_len, db_write_latency, etc. These metrics are periodically written to node_red_metrics (Influx measurement) for adaptive control to read. A sliding window (e.g., the most recent 60 samples) can be used to calculate RTT_mean (mean round-trip latency) and ERR_rate (error rate) to avoid being affected by individual timeouts. For unified external monitoring, these metrics can be exported to Prometheus and threshold alerts can be generated using Grafana / Alertmanager. Prometheus is an open-source monitoring and alerting tool designed for dynamic cloud environments and widely used for monitoring microservices and Kubernetes clusters. Alertmanager is a separate component in the Prometheus monitoring system responsible for processing and sending alerts.

[0180] Threshold Determination: For each device, if RTT_mean > RTT_threshold or ERR_rate > ERR_threshold (e.g., RTT_threshold = 500ms, ERR_threshold = 3%), where RTT_threshold is the preset threshold for the device's average response time (i.e., average round-trip latency RTT_mean), and ERR_threshold is the preset threshold for the error rate ERR_rate, then the device is determined to be in a "high latency / high error" state, requiring downsampling or a reduction in concurrency priority. Conversely, at lower latency and lower error rates, the sampling rate can be appropriately increased to obtain higher resolution data. The threshold is configurable and can be adjusted based on historical baselines (e.g., based on the median of the past week + a safety factor).

[0181] Adjust interval_s and merging strategy: If downsampling is required, interval_s := min(interval_s*α, maxInterval) (e.g., α=1.5), where maxInterval is the preset maximum expected sampling interval threshold of the desired sampling interval_s; if upsampling is possible: interval_s := max(interval_s*β, minInterval) (e.g., β=0.9), where minInterval is the preset minimum expected sampling interval threshold of the desired sampling interval_s. Simultaneously adjust maxBatchRegisters (merging threshold) according to the current load, reducing merging under high load to reduce instantaneous pressure on individual PLCs. Set reasonable minInterval (≥1s) and maxInterval (based on process tolerance, e.g., 60s), and set a cooldown period (e.g., 60s) after adjustment to avoid frequent fluctuations.

[0182] Update the mapping and prevent oscillations: Write the new sampling interval back to global.mapping (e.g., mapping[idx].interval_s=newVal;global.set('mapping',mapping)), where newVal is the latest sampling interval based on the latest monitored object, and write it to the change log for auditing. Set a cooldown period during which no further adjustments should be made to the device. You can first run the new parameters in simulation mode for a period of time (dry-run) to observe the effect, and only officially apply them after confirming that they will not cause new problems.

[0183] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the edge data acquisition method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0184] This application also provides an edge data acquisition device, please refer to... Figure 7 The edge data acquisition device includes:

[0185] The first module 10 is used to construct a first request message for collecting edge data from the edge device by loading a mapping table, wherein the collection attribute information of the edge data to be collected has been pre-declared in the mapping table;

[0186] The second module 20 is used to merge a first request message that meets the preset merging conditions into a second request message based on the collected attribute information.

[0187] The third module 30 is used to send a second request message to the edge device and obtain edge data returned by the edge device based on the second request message.

[0188] In one embodiment, the mapping table is a two-layer mapping table including a logical layer and a physical layer, and the edge data acquisition device further includes a fourth module for:

[0189] Obtain the changed dataset of the mapping table, and after verifying the changed dataset of the mapping table, perform pre-validation on the new mapping table in simulation mode;

[0190] After passing the pre-verification in simulation mode, switch to the new mapping table;

[0191] If an anomaly is detected after the new mapping table takes effect, the system will automatically roll back to the mapping table of a previous stable version.

[0192] In one embodiment, after the step of constructing a first request message for collecting edge data from the edge device by loading a mapping table, the edge data acquisition device further includes a fifth module for:

[0193] By embedding key nodes in the edge data acquisition link, key metric data can be obtained;

[0194] Based on a preset sliding sampling window, the response metrics of the edge device are calculated, including average response time and error rate.

[0195] Adjust the sampling interval of edge data collected by edge devices based on the response indicators.

[0196] In one embodiment, the second module is further configured to:

[0197] Based on the maximum number of merged registers in the first request message that meets the preset merging conditions, the first weight corresponding to the average response time in the response indicators of the edge device, the second weight corresponding to the error rate, and the normalized weight of the device capability of the edge device, the merging window size for merging the first request message that meets the preset merging conditions into the second request message is adaptively adjusted.

[0198] Based on the merge window size, first request messages that meet the preset merge conditions are merged into second request messages.

[0199] In one embodiment, the third module is further configured to:

[0200] After the step of sending a second request message to the edge device and obtaining edge data returned by the edge device based on the second request message:

[0201] Based on the data format of the original edge data, the data values ​​are parsed and then time series data is generated based on the data values. The time series data is then written into the time series database in batches.

[0202] In one embodiment, the third module is further configured to:

[0203] When the batch writing of time series data to the time series database fails, the failed time series data will be appended to the local file in the callback.

[0204] A preset number of data records are periodically read from a local file and written back to the time-series database in sequence.

[0205] The edge data acquisition device provided in this application, employing the edge data acquisition method described in the above embodiments, can solve the technical problem of low efficiency in acquiring edge data from high-concurrency edge devices. Compared with the prior art, the beneficial effects of the edge data acquisition device provided in this application are the same as those of the edge data acquisition method described in the above embodiments, and other technical features in the edge data acquisition device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0206] This application provides an edge data acquisition device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the edge data acquisition method in Embodiment 1 above.

[0207] The following is for reference. Figure 8This document illustrates a structural schematic diagram of an edge data acquisition device suitable for implementing embodiments of this application. The edge data acquisition device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The edge data acquisition device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0208] like Figure 8 As shown, the edge data acquisition device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the edge data acquisition device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the edge data acquisition device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows edge data acquisition devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0209] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0210] The edge data acquisition device provided in this application, employing the edge data acquisition method described in the above embodiments, can solve the technical problem of low efficiency in acquiring edge data from high-concurrency edge devices. Compared with the prior art, the beneficial effects of the edge data acquisition device provided in this application are the same as those of the edge data acquisition method described in the above embodiments, and other technical features of this edge data acquisition device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0211] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0212] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0213] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the edge data acquisition method described in the above embodiments.

[0214] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0215] The aforementioned computer-readable storage medium may be included in the edge data acquisition device; or it may exist independently and not be assembled into the edge data acquisition device.

[0216] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the edge data acquisition device, the edge data acquisition device: constructs a first request message for acquiring edge data from the edge device by loading a mapping table, wherein the acquisition attribute information of the edge data to be acquired has been pre-declared in the mapping table; merges the first request message that meets the preset merging conditions into a second request message based on the acquisition attribute information; sends the second request message to the edge device, and obtains the edge data returned by the edge device based on the second request message.

[0217] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0218] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0219] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0220] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described edge data acquisition method, thereby solving the technical problem of low efficiency in acquiring edge data from high-concurrency edge devices. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the edge data acquisition method provided in the above embodiments, and will not be repeated here.

[0221] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the edge data acquisition method described above.

[0222] The computer program product provided in this application can solve the technical problem of low efficiency in acquiring edge data from high-concurrency edge devices. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the edge data acquisition method provided in the above embodiments, and will not be repeated here.

[0223] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An edge data collection method, characterized by, The edge data acquisition method is applied to edge nodes and includes: By loading the mapping table, a first request message for collecting edge data from the edge device is constructed. The mapping table has pre-declared the collection attribute information of the edge data to be collected. The mapping table is a two-layer mapping table, including a logical layer for declaring semantics / measurement points and a physical layer for driving the low-level information accessed during edge runtime. Based on the collected attribute information, the first request message that meets the preset merging conditions is merged into a second request message; Send the second request message to the edge device to obtain edge data returned by the edge device based on the second request message; The step of merging the first request message that meets the preset merging conditions into a second request message includes: Based on the maximum number of merged registers in the first request message that meets the preset merging conditions, the first weight corresponding to the average response time in the response indicators of the edge device, the second weight corresponding to the error rate, and the normalized weight of the device capability of the edge device, the merging window size for merging the first request message that meets the preset merging conditions into the second request message is adaptively adjusted. Based on the merging window size, the first request messages that meet the preset merging conditions are merged into a second request message; in, ; To merge window sizes; Maximum number of merged registers; As the first weight, , The average round-trip delay of the device's sliding window. For reference delay, For smoothing coefficients; As the second weight, , The error rate of the most recent sliding window. This is the weight sensitivity coefficient; For equipment capability normalization weights, , This refers to the maximum register reading that the PLC can withstand per second, obtained through probe and historical observations. This represents the maximum capacity or configuration limit for all PLCs based on experience.

2. The edge data acquisition method as described in claim 1, characterized in that, The method further includes: Obtain the changed dataset of the mapping table, and after verifying the changed dataset of the mapping table, perform pre-verification of the new mapping table in simulation mode; After passing the pre-verification in simulation mode, switch to the new mapping table; If an anomaly is detected after the new mapping table takes effect, the system will automatically roll back to a historical stable version of the mapping table.

3. The edge data acquisition method as described in claim 1, characterized in that, After the step of constructing a first request message for collecting edge data from the edge device by loading a mapping table, the method further includes: By embedding key nodes in the edge data acquisition link, key metric data can be obtained; Based on a preset sliding sampling window, the response metrics of the edge device are calculated, wherein the response metrics include average response time and error rate; Based on the response indicators, adjust the sampling interval of the edge data collected by the edge acquisition device.

4. The edge data acquisition method as described in claim 1, characterized in that, After the step of sending the second request message to the edge device and obtaining the edge data returned by the edge device based on the second request message, the following is included: Based on the data format of the original edge data, the data values ​​are parsed and generated, and the time series data is generated based on the data values ​​and written into the time series database in batches.

5. The edge data acquisition method as described in claim 4, characterized in that, The step of writing the time series data into the time series database includes: When the batch writing of the time series data to the time series database fails, the failed time series data will be appended to the local file in the callback. A preset number of data records are periodically read from the local file and written back to the time-series database in sequence.

6. An edge data acquisition device, characterized in that, The edge data acquisition device includes: The first module is used to construct a first request message for collecting edge data from the edge device by loading a mapping table. The mapping table has pre-declared the collection attribute information of the edge data to be collected. The mapping table is a two-layer mapping table, including a logical layer for declaring semantics / measurement points and a physical layer for driving the low-level information accessed during edge runtime. The second module is used to merge the first request message that meets the preset merging conditions into a second request message based on the collected attribute information. The third module is used to send the second request message to the edge device and obtain the edge data returned by the edge device based on the second request message; The step of merging the first request message that meets the preset merging conditions into a second request message includes: Based on the maximum number of merged registers in the first request message that meets the preset merging conditions, the first weight corresponding to the average response time in the response indicators of the edge device, the second weight corresponding to the error rate, and the normalized weight of the device capability of the edge device, the merging window size for merging the first request message that meets the preset merging conditions into the second request message is adaptively adjusted. Based on the merging window size, the first request messages that meet the preset merging conditions are merged into a second request message; in, ; To merge window sizes; Maximum number of merged registers; As the first weight, , The average round-trip delay of the device's sliding window. For reference delay, For smoothing coefficients; As the second weight, , The error rate of the most recent sliding window. This is the weight sensitivity coefficient; For equipment capability normalization weights, , This refers to the maximum register reading that the PLC can withstand per second, obtained through probe and historical observations. This represents the maximum capacity or configuration limit for all PLCs based on experience.

7. An edge data acquisition device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the edge data acquisition method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the edge data acquisition method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the edge data acquisition method as described in any one of claims 1 to 5.

Images