A multi-protocol isolation runtime and history compatible migration system and method for industrial edge data collection

Abstract

The application discloses a multi-protocol isolation runtime and historical compatible migration system and method for industrial edge data collection. The system comprises a metadata management module, a channel isolation runtime module, a multi-protocol connection adaptation module, a device-level collection scheduling module, a data quality processing and state semantic module, a historical compatible storage module, a cloud compensation and failure retry module, and a management interface and hot update coordination module. The method comprises the following steps: reading metadata; creating an independent actor and a protocol connection; creating a device-level periodic scheduler; sending a device identifier to the channel actor when the scheduler is triggered; reading the measurement point metadata and collecting in batches by the channel actor; converting the collection results into standard sample objects, performing quality semantic mapping, over-limit fallback and state determination; writing into storage according to the original system Redis latest value structure and Influx historical field structure; asynchronously uploading to the cloud and compensating and retrying when failing; and online synchronously changing according to the metadata change to call the hot update coordination logic.

Description

Technical Field

[0001] This invention relates to the fields of industrial Internet of Things and edge computing technology, and more specifically, to a multi-protocol isolated runtime and historical compatibility migration system and method for industrial edge data acquisition. Background Technology

[0002] Industrial enterprise edge data acquisition systems are typically used to connect to various industrial protocols such as OPC DA, OPC UA, Modbus TCP, and virtual channels. They collect data from field equipment measurement points in real time and write it to Redis, InfluxDB, and relational databases, providing a unified data service interface to management front-ends, dashboards, large screens, algorithm modules, and cloud systems.

[0003] Most existing industrial data acquisition systems are implemented based on the Java technology stack. Common approaches include: 1) periodic acquisition based on thread pools or timed task frameworks; 2) multi-protocol access methods that implement protocol connection and read / write logic separately for different protocols; 3) a dual-storage architecture that uses Redis to store the latest values ​​and InfluxDB to store historical values; and 4) managing the front-end to maintain channels, device and measurement point metadata, and having the runtime execute start / stop, acquisition and reconnection based on the metadata.

[0004] As edge data acquisition systems grow in scale, the following constraints typically exist in the field: First, a large amount of historical Redis latest values ​​and Influx historical time-series data already exist, which cannot be lost or completely reconstructed during runtime replacement; Second, existing management front-ends, dashboards, large screens, algorithms, and other modules already rely on existing API formats and return fields; Third, channel, device, and test point configurations change frequently, requiring runtime hot update capabilities and not relying on manual restarts; Fourth, edge device resources are limited, requiring reduction in CPU, memory, and startup overhead; Fifth, the types of protocols in the field are complex, and some protocols have special handling requirements such as quality codes, status, outliers, reconnection after disconnection, and cloud failure compensation. Summary of the Invention

[0005] The purpose of this invention is to provide a system and method for channel-isolated runtime hot updating and historical compatibility migration for multi-protocol data acquisition at the industrial edge. This solution maintains basic compatibility with existing MySQL metadata, the latest Redis value structure, Influx historical fields, and the management front-end and external API calls. It achieves a low-resource-consumption, high-fault-isolation, online hot-updateable, and easily migrated industrial data acquisition system by constructing a channel-level isolated runtime, device-level periodic scheduling, unified protocol abstraction, data quality processing semantics, a historical compatibility read / write mechanism, and a cloud migration failure compensation mechanism.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A multi-protocol isolated runtime and historical compatibility migration system for industrial edge data acquisition includes: a metadata management module, a channel isolation runtime module, a multi-protocol connection adaptation module, a device-level acquisition scheduling module, a data quality processing and status semantics module, a historical compatibility storage module, a cloud compensation and failure retry module, and a management interface and hot update coordination module. The metadata management module is connected to a relational database, the channel isolation runtime module, and the management interface and hot update coordination module. The channel isolation runtime module is connected to the metadata management module, the multi-protocol connection adaptation module, the device-level acquisition scheduling module, the data quality processing and status semantics module, the historical compatibility storage module, the cloud compensation and failure retry module, and the management interface. The module connects to the hot update coordination module; the multi-protocol connection adaptation module connects to the channel isolation runtime module and to the field devices; the device-level acquisition scheduling module connects to the channel isolation runtime module; the data quality processing and status semantics module connects to the channel isolation runtime module and the historical compatible storage module respectively; the historical compatible storage module connects to the data quality processing and status semantics module and the channel isolation runtime module respectively, and connects to the Redis cache database and the InfluxDB time series database; the cloud compensation and failure retry module connects to the channel isolation runtime module and connects to the cloud system; the management interface and hot update coordination module connect to the metadata management module and the channel isolation runtime module respectively, and connect to the management front end.

[0007] Furthermore, the metadata management module reads and maintains metadata for channels, devices, and measurement points from a relational database; the channel isolation runtime module creates an independent channel runtime instance for each enabled channel; the multi-protocol connection adaptation module abstracts different industrial protocols into a unified standard protocol connection interface; the device-level acquisition scheduling module creates an independent device scheduler for each enabled and operational device; the data quality processing and status semantics module performs unified quality semantic processing and over-limit rollback on the acquisition results returned by different protocols; the historical compatibility storage module writes data according to the latest Redis value structure and Influx historical field structure of the original system; the cloud compensation and failure retry module asynchronously uploads the acquisition results to the cloud and performs compensation retry when the upload fails; the management interface and hot update coordination module performs hot update coordination on the runtime state according to changes in metadata. This invention also provides a method for multi-protocol isolated runtime and historical compatibility migration for industrial edge data acquisition, comprising the following steps: S1: Read all metadata of enabled channels from the relational database; S2: Create an independent channel actor for each enabled channel, and create a corresponding protocol connection instance based on the channel's protocol parameters; S3: Create a device-level periodic scheduler for each enabled device and establish a command relationship with the corresponding channel actor; S4: When the device scheduler triggers the acquisition cycle, it sends the corresponding device identifier to the corresponding channel actor; S5: The channel actor reads the measurement point metadata under the device and calls the protocol connection instance to perform batch acquisition; S6: Convert the collected results into standard sample objects and perform quality semantic processing, over-limit rollback, and state mapping; S7: Write the standard sample object into Redis and InfluxDB respectively according to the latest Redis value structure and the historical field structure of Influx in the original system; S8: If the device enables the cloud access function, the standard sample object is asynchronously written to the cloud access queue, and a failure mark is written to the historical storage when the sending fails, and the background retry task performs compensation and retry. S9: When the metadata of a channel, device, or measurement point changes, the hot update coordination logic is invoked according to the type of metadata change, so that the running state can be synchronously changed online.

[0008] Furthermore, the specific operation of the over-limit rollback in step S6 is as follows: when the collected value exceeds the maximum or minimum value configured in the measurement point metadata, the current collected value is discarded, and the previous valid latest value of the measurement point is used as the result of this collection; the quality semantic processing includes: uniformly mapping the original quality codes and error messages returned by different protocols to GOOD, BAD, UNCERTAIN or NotConnected status; the status mapping result is associated with the quality code and status text fields in the standard sample object.

[0009] Furthermore, when writing the latest value structure to Redis in step S7, the original system's device is maintained: <deviceid>Keys and items: <itemid>Field format; when writing to Influx historical fields, keep the original system's measurement name, field name, and label name unchanged, and at least retain the dataType, value, quality, sourcePoint, status, error_msg, and is_success fields.

[0010] Furthermore, the hot update coordination logic in step S9 includes: for the addition, activation, deactivation, modification, or deletion of a channel, calling the channel coordination method to start, stop, or rebuild the target channel actor; for the addition, activation, deactivation, modification of the acquisition cycle, or change of the channel to which a device belongs, calling the device coordination method to create, destroy, restart, or migrate the target device scheduler; for the addition, deletion, or modification of a measurement point, the device scheduler is not restarted, but the channel actor rereads the measurement point metadata in the next acquisition cycle.

[0011] Furthermore, the standard sample object includes at least: measurement point identifier, channel identifier, device identifier, data value, data type, quality code, status text, error message, timestamp, and success identifier.

[0012] Furthermore, in step S8, when an upload fails, the success flag in the standard sample object is set to false or an equivalent flag is written back to the historical storage to record the failed sample; the background retry task re-uploads the failed sample, and updates its cloud upload result upon success.

[0013] Furthermore, when the management interface and the hot update coordination module detect that the target channel has not yet been loaded into the running state by the write interface, a hot load attempt is automatically performed based on the metadata.

[0014] Compared with traditional solutions, the present invention has the following advantages: (1) The lightweight runtime and channel-level independent actor structure can significantly reduce CPU and memory usage and reduce resource occupancy under the same acquisition scale.

[0015] (2) By reducing the overhead of the framework layer, unifying the batch acquisition process and simplifying the operation path, the acquisition response delay of this invention is significantly reduced.

[0016] (3) The present invention has strong fault isolation capability. When a single channel connection is abnormal, reconnection fails, or configuration is incorrect, it does not affect the normal operation of other channels.

[0017] (4) This invention supports online hot updates. Adding, deleting, modifying, starting, and stopping channels, devices, and measurement points can take effect without restarting the service.

[0018] (5) This invention is compatible with the existing Redis latest value structure, Influx historical data fields, and the calling methods of the management front-end and external interfaces, and has good historical compatibility.

[0019] (6) The data semantics of the present invention are unified. The quality codes, statuses, error messages and over-limit handling methods of different protocols are uniformly abstracted, which facilitates page display and anomaly statistics.

[0020] (7) Cloud failures will not block local data collection, and failed data can be tracked, retried, and compensated.

[0021] (8) The present invention can gradually replace the old operation according to the site, channel and protocol, thereby reducing the risk of production switching. Attached Figure Description

[0022] This manual includes the following figures, which illustrate the following: Figure 1 This is a schematic diagram of the overall module connection relationship of the system of the present invention; Figure 2 This is an overall flowchart of the method of the present invention; Figure 3 This is a schematic diagram of the internal structure of the channel isolation runtime module in this invention; Figure 4 This is a schematic diagram of the metadata update process of the present invention; Figure 5 This is a schematic diagram of the data acquisition and storage process of the present invention; Figure 6 This is a schematic diagram of the cloud compensation and failure retry process of the present invention; Figure 7 This is a schematic diagram of the measurement point status determination process of the present invention. Detailed Implementation

[0023] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, in order to help those skilled in the art to have a more complete, accurate and in-depth understanding of the inventive concept and technical solution of the present invention, and to facilitate its implementation.

[0024] like Figure 1 As shown, this embodiment provides a multi-protocol isolated runtime and historical compatibility migration system for industrial edge data acquisition. This system is deployed on an industrial edge gateway or edge server and includes a metadata management module, a channel isolation runtime module, a multi-protocol connection adaptation module, a device-level acquisition scheduling module, a data quality processing and status semantics module, a historical compatibility storage module, a cloud compensation and failure retry module, and a management interface and hot update coordination module. The channel isolation runtime module is directly connected to the metadata management module, multi-protocol connection adaptation module, device-level acquisition scheduling module, data quality processing and status semantics module, historical compatibility storage module, cloud compensation and failure retry module, and management interface and hot update coordination module, respectively. The metadata management module is directly connected to the management interface and hot update coordination module, providing metadata comparison information before and after the configuration change to the hot update process. The metadata management module is connected to a relational database, such as MySQL; the historical compatibility storage module is connected to both a Redis cache database and an InfluxDB time-series database; the multi-protocol connection adaptation module is connected to the field device; the cloud compensation and failure retry module is connected to the cloud system; and the management interface and hot update coordination module is connected to the management front-end.

[0025] The overall process of the method of the present invention is as follows: Figure 2 As shown, the specific steps include S1 to S9.

[0026] S1: After system startup, the metadata management module connects to a relational database, such as MySQL. It executes SQL queries to read metadata for all enabled channels. For each channel, it retrieves its channel identifier, protocol type, connection parameters, start / stop status, and reconnection configuration. Further, for each channel, it cascades and reads metadata for all its subordinate devices, including device identifier, channel identifier, acquisition cycle, start / stop status, and cloud access switch. For each device, it reads metadata for all its subordinate measurement points, including measurement point identifier, source address, data type, read / write type, upper and lower thresholds, and extended parameters. The metadata management module caches this metadata in memory and provides a unified query interface. Simultaneously, the metadata management module sends the read metadata to the channel isolation runtime module and the management interface and hot update coordination module, providing a foundation for subsequent runtime creation and hot updates.

[0027] S2: The channel isolation runtime module uses an actor model, creating an independent channel actor for each enabled channel read in step S1. For example... Figure 3 As shown, each channel actor is an independent runtime entity with its own message queue, independent set of devices, and independent operational health status. During actor creation, the system calls the multi-protocol connection adaptation module based on the channel's protocol type. This module abstracts different industrial protocols into a unified standard protocol connection interface and creates corresponding protocol connection instances based on the channel's protocol parameters: for OPC DA, a connection is established via an HTTP proxy; for OPC UA, a secure session is created using the OPC UA client SDK; for Modbus TCP, a connection is established via a TCP socket; and for virtual channels, a logical mapping is established in memory or Redis. After creation, the channel actor calls the connection method to establish the actual communication link with the field devices and records the connection status in the runtime status variables. If the connection fails, the actor initiates an exponential backoff reconnection task and continues to attempt reconnection during subsequent health checks. Actors from different channels do not share any connections or states, thus achieving channel-level fault isolation.

[0028] S3: The device-level acquisition scheduling module iterates through all enabled and running devices, creating an independent device scheduler for each device. Each device scheduler is a periodic timed task, with its trigger period precisely equal to the acquisition period configured in the device's metadata. Internally, the scheduler maintains a timer and holds a reference to its associated channel actor or a message sending handle. When the scheduler is created, the system establishes a command relationship between the scheduler and the corresponding channel actor created in step S2, meaning the scheduler knows which channel actor to send the acquisition trigger message to. Because each device has an independent scheduler, the acquisition periods of different devices can run independently without interference, avoiding the resource waste or uneven latency issues caused by all devices using the same period in traditional global scanning methods. When a device is deactivated, deleted, or its acquisition period is modified, the corresponding scheduler can be destroyed or restarted individually without affecting other devices.

[0029] S4: As Figure 5 As shown, when each device scheduler reaches its set acquisition time, it constructs an acquisition trigger message carrying a unique device identifier and sends it to the channel actor that established the command relationship in step S3 via a message queue or direct method call. This message does not carry specific measurement point information; it only informs the channel actor which device needs to be acquired. This design decouples the scheduler from the acquisition logic, allowing the channel actor to flexibly handle acquisition requests based on its own state.

[0030] S5: After receiving the acquisition trigger message, the channel actor first queries the metadata management module for all measurement point metadata corresponding to the device identifier. Then, the channel actor assembles this measurement point information into a batch read request list and calls the batch read method of the protocol connection instance bound to it. The multi-protocol connection adaptation module converts this batch request into actual protocol messages according to the specific implementation of the underlying protocol. For Modbus TCP, multiple read holding register or read input register request frames are constructed sequentially and sent in a pipelined manner over the same TCP connection; for OPC UA, the read service is called to read multiple nodes at once; for OPC DA, the latest values ​​of multiple points are obtained in batches through the HTTP proxy service; for virtual channels, pre-written simulated values ​​are read directly from memory or Redis. After the field device returns a response, the multi-protocol connection adaptation module encapsulates the raw data returned by different protocols into a unified raw result list and returns it to the channel actor.

[0031] S6: The channel actor sends the list of raw results obtained in step S5 to the data quality processing and status semantics module. This module first converts each raw result into a standard sample object, which contains at least the following fields: measurement point identifier, channel identifier, device identifier, data value, data type, quality code, status text, error message, timestamp, and success identifier. Subsequently, the data quality processing and status semantics module performs quality semantic processing, mapping the quality code according to protocol-specific meanings, such as status codes in OPC UA, Modbus exception codes, or custom virtual channel statuses, to one of four standard statuses: GOOD (data is available), BAD (data is completely unavailable), UNCERTAIN (data is uncertain but may be partially available), or NotConnected (connection is interrupted). For samples with a status of BAD or NotConnected, the module directly sets the success identifier to false, records the error message, skips subsequent over-limit rollback processing, and directly proceeds to the storage stage in step S7. For samples with a status of GOOD or UNCERTAIN, the module further performs over-limit rollback processing. It reads the maximum and minimum values ​​configured for that measurement point from the measurement point metadata to determine if the current collected value exceeds this threshold range. If it does not exceed the threshold, the current value is directly used as the sample value; if it does, the current collected value is discarded, and the last valid latest value of the measurement point is used instead. Specifically, the module maintains an LRU-based cache, using the measurement point identifier as the key, storing the most recently successfully collected sample value and its timestamp. When an over-limit occurs, the module queries this cache. If a valid historical value exists, it uses that historical value as the value of the current sample, while simultaneously recording the original actual value in the log for diagnostic purposes and adding a marker to the status text. If no valid historical value exists in the cache, the status of the current sample is forcibly set to BAD, the success flag is set to false, and the error message is set to exceeding the upper and lower limits and having no valid rollback value. The processed standard sample object is then sent to the historical compatibility storage module.

[0032] S7: After receiving the standard sample object, the historical compatibility storage module performs a write operation that is fully compatible with the original system. Specifically, for storing the latest Redis value, the module follows the key naming rules agreed upon by the original system: using the string "DEVICE" plus the device identifier as the key of the Redis hash table, and using "ITEM:" plus the measurement point identifier as the field name in this hash table. The field value is stored as a JSON string, and the structure of this JSON object is fully compatible with the "ItemDTO" in the original system, containing at least three fields: value, quality, and timestamp. The historical compatibility storage module executes the HSET command to update the corresponding fields, thereby ensuring that the front end can read "DEVICE:" through the original API. <deviceid>Keys and items: <itemid>The module obtains the expected data structure for each field and writes the latest values. For InfluxDB historical time-series storage, the module maintains the exact same measurement names, label sets, and field sets as the original system: the collected results are written to the time-series database according to the exact same measurement, label, and field structure as the original system.

[0033] S8: After step S7 is completed, if the cloud access switch field in the device metadata is enabled, the channel actor will send a copy of the standard sample object to the cloud access compensation and failure retry module. For example... Figure 6 As shown, this module internally maintains a blocking queue to receive samples to be uploaded to the cloud from all channel actors. Simultaneously, the module starts one or more background sending threads to retrieve samples from the queue in batches and upload them by calling the cloud system's API interface. When the cloud system responds successfully, the sending thread records a successful upload log and removes the sample from the queue. When a network timeout, a server error returned by the cloud, or other retryable exception occurs, the sending thread does not discard the sample but performs a failure compensation operation: it keeps the success flag in the standard sample object set to true and inserts a record into a separate failure record store. This failure record can be stored in a dedicated table in a relational database or written to InfluxDB and marked as pending retry with an additional field. Furthermore, the cloud compensation and failure retry module starts a separate timed retry task, which scans all failure records at regular intervals and re-calls the cloud API for each failed sample. If the retry is successful, the failure record is updated or deleted; if the maximum number of consecutive retries is reached and the failure still fails, the failure record is marked as permanently failed and an alarm is issued.

[0034] S9: When the metadata of a channel, device, or measurement point changes, the hot update coordination logic is invoked based on the type of metadata change, enabling online synchronization of changes in the runtime state. For example... Figure 4 As shown, the management interface and hot update coordination module expose a REST API for the management frontend to call. When the frontend modifies the configuration of a channel, device, or measurement point, this module receives the configuration change instruction, first obtains the changed metadata from the metadata management module, and compares it with the old metadata cached in memory. Depending on the type of change, the module sends different hot update coordination signals to the channel isolation runtime module, specifically in the following three cases. For adding, enabling, disabling, modifying parameters, or deleting a channel, the signal instructs the channel isolation runtime module to start, stop, or rebuild the target channel actor: when adding a channel, a new channel actor is created and a protocol connection is established; when disabling a channel, the actor is stopped and connection resources are released; when modifying channel parameters, the old actor is stopped first, and then a new actor is created with the new parameters; when deleting a channel, the actor and all its subordinate schedulers are completely destroyed. For the addition, activation, deactivation, modification of acquisition cycle, or change of channel for a device, the signal indicates the creation, destruction, restart, or migration of the target device scheduler: When adding a device, an independent scheduler is created and bound to the channel actor; when deactivating a device, the scheduler is destroyed; when modifying the acquisition cycle, the scheduler is restarted to run with the new cycle; when changing the channel to which a device belongs, the original scheduler is destroyed first, and then a scheduler is created under the new channel. For the addition, deletion, or modification of measurement points, the signal indicates that no device scheduler is restarted, but only the measurement point information in the metadata cache is updated, which takes effect naturally when the channel actor rereads the measurement point metadata in the next acquisition cycle. In addition, when the management interface and the hot update coordination module detect that a target channel pointed to by a certain write interface has not yet been loaded into the running state, it will actively send a hot load signal to the channel isolation runtime module. The channel isolation runtime module automatically creates a runtime instance of the channel and establishes a protocol connection based on the metadata, realizing on-demand hot loading of the configuration.

[0035] Furthermore, this invention also provides a unified method for determining the state of measuring points, such as... Figure 7 As shown. When the management frontend or other external systems query the latest status of a measurement point via API, the data quality processing and status semantics module reads the latest sample of that measurement point from Redis. DEVICE: <deviceid>Keys and items: <itemid>The field stores JSON. If the sample does not exist, the status is determined to be empty or without a latest value; if it exists, the quality code, timestamp, success flag, and status text are extracted. The judgment rules are as follows: if the success flag is false, a fault status is returned directly with an error message; if the success flag is true but the quality code is mapped to BAD, unusable is returned; if the quality code is UNCERTAIN, indeterminate is returned; if the quality code is GOOD but the difference between the current timestamp and the current system time exceeds a preset time threshold, it is determined to be a data timeout; only when the quality code is GOOD and the timestamp is within the valid window is a normal status returned.

[0036] The system in this embodiment employs a lightweight actor model to create an independent runtime instance for each channel. Each channel actor only maintains its own necessary protocol connections, device sets, and message queues, avoiding the heavy framework layer and thread pool overhead of traditional Java data acquisition systems. The memory usage of this invention is approximately 40% to 60% of that of traditional solutions, CPU utilization is reduced by about 30%, and startup time is shortened to one-third of the original system.

[0037] In this embodiment, if the Modbus TCP channel of production line A enters a reconnection loop due to a network interruption, the OPC UA channel actor of production line B remains completely unaffected and continues to collect data normally at a 1-second cycle. This effect stems from the fact that each channel actor has an independent protocol connection instance, an independent command queue, and an independent execution context. When a channel experiences a connection timeout, protocol parsing error, or configuration anomaly, the fault is confined within that channel actor and will not affect other channels. Compared to the problem of fault propagation caused by multiple acquisition tasks sharing the same connection pool or scheduling thread pool in traditional solutions, the fault isolation capability of this invention significantly improves the overall robustness of the system, ensuring that data acquisition of critical production lines is not interrupted by failures of non-critical channels.

[0038] In this embodiment, when an administrator adds a vibration measurement point via the front end, the system only updates the metadata cache and does not restart any device schedulers or channel actors. In the next data collection cycle, the channel actor automatically reads the new measurement point's metadata, and the new measurement point is then included in the collection range. For modifications to the collection cycle of a device, the system only restarts the corresponding device scheduler; the collection of other devices remains unaffected. For modifications to channel parameters, the system first stops the old channel actor and then creates a new one; the entire process is transparent to the front end and requires no manual service restart.

[0039] In this embodiment, the latest Redis values ​​and historical InfluxDB data inherited from the original Java data acquisition system are completely preserved. The new system writes data according to the exact same key naming rules and field structure. The front-end, dashboard, and algorithm modules can directly query the new system data without any modifications. The old and new data coexist naturally in the same database, and historical trend queries can display complete curves across replacement time points.

[0040] In this embodiment, both the raw register values ​​from the Modbus TCP protocol and the node values ​​from the OPC UA protocol are converted into unified standard sample objects, and the quality codes are mapped to four states: GOOD, BAD, UNCERTAIN, and NotConnected. When the temperature measurement point's collected value of 105℃ exceeds the upper limit of 100℃, the system automatically falls back to the previous valid value of 98℃, avoiding abnormal jump values ​​from polluting the real-time database and preventing spikes in the front-end trend chart. If a measurement point fails consecutively, the system returns states such as fault, unavailable, or data timeout through unified status judgment logic, rather than the original error codes of each protocol. This unified semantic processing eliminates the need for upper-layer applications to write differentiated logic for different protocols, greatly simplifying front-end development and maintenance.

[0041] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.< / itemid> < / deviceid> < / itemid> < / deviceid> < / itemid> < / deviceid>

Claims

1. A multi-protocol isolated runtime and historically compatible migration system for industrial edge data acquisition, characterized in that, include: The system comprises a metadata management module, a channel isolation runtime module, a multi-protocol connection adaptation module, a device-level acquisition and scheduling module, a data quality processing and status semantics module, a historical compatibility storage module, a cloud compensation and failure retry module, and a management interface and hot update coordination module. The metadata management module is connected to a relational database, the channel isolation runtime module, and the management interface and hot update coordination module. The channel isolation runtime module is connected to the metadata management module, the multi-protocol connection adaptation module, the device-level acquisition and scheduling module, the data quality processing and status semantics module, the historical compatibility storage module, the cloud compensation and failure retry module, and the management interface and hot update coordination module. The multi-protocol connection adaptation module... The module is connected to the channel isolation runtime module and to the field device; the device-level acquisition and scheduling module is connected to the channel isolation runtime module; the data quality processing and status semantics module is connected to the channel isolation runtime module and the historical compatible storage module respectively; the historical compatible storage module is connected to the data quality processing and status semantics module and the channel isolation runtime module respectively, and is connected to the Redis cache database and the InfluxDB time series database; the cloud compensation and failure retry module is connected to the channel isolation runtime module and is connected to the cloud system; the management interface and hot update coordination module are connected to the metadata management module and the channel isolation runtime module respectively, and are connected to the management front end.

2. The multi-protocol isolated runtime and historical compatibility migration system for industrial edge data acquisition according to claim 1, characterized in that, The metadata management module reads and maintains metadata for channels, devices, and measurement points from a relational database; the channel isolation runtime module creates an independent channel runtime instance for each enabled channel; the multi-protocol connection adaptation module abstracts different industrial protocols into a standard protocol connection interface; the device-level acquisition scheduling module creates an independent device scheduler for each enabled and operational device; the data quality processing and status semantics module performs unified quality semantic processing and over-limit rollback on the acquisition results returned by different protocols; the historical compatibility storage module writes data according to the latest Redis value structure and Influx historical field structure of the original system; the cloud compensation and failure retry module asynchronously uploads the acquisition results to the cloud and performs compensation retry when the upload fails; the management interface and hot update coordination module performs hot update coordination on the runtime state according to changes in metadata.

3. A migration method for a multi-protocol isolated runtime and historically compatible migration system for industrial edge data acquisition as described in any one of claims 1-2, characterized in that, Includes the following steps: S1: Read all metadata of enabled channels from the relational database; S2: Create an independent channel actor for each enabled channel, and create a corresponding protocol connection instance based on the channel's protocol parameters; S3: Create a device-level periodic scheduler for each enabled device and establish a command relationship with the corresponding channel actor; S4: When the device scheduler triggers the acquisition cycle, it sends the corresponding device identifier to the corresponding channel actor; S5: The channel actor reads the measurement point metadata under the device and calls the protocol connection instance to perform batch acquisition; S6: Convert the collected results into standard sample objects and perform quality semantic processing, over-limit rollback, and state mapping; S7: Write the standard sample object into Redis and InfluxDB respectively according to the latest Redis value structure and the historical field structure of Influx in the original system; S8: If the device enables the cloud access function, the standard sample object is asynchronously written to the cloud access queue, and a failure mark is written to the historical storage when the sending fails, and the background retry task performs compensation and retry. S9: When the metadata of a channel, device, or measurement point changes, the hot update coordination logic is invoked according to the type of metadata change, so that the running state can be synchronously changed online.

4. The multi-protocol isolated runtime and historical compatibility migration method for industrial edge data acquisition according to claim 3, characterized in that, The over-limit rollback in step S6 specifically means: when the collected value exceeds the maximum or minimum value configured in the measurement point metadata, discard the current collected value and use the previous valid latest value of the measurement point as the result of this collection; The quality semantic processing includes: uniformly mapping the raw quality codes and error messages returned by different protocols to GOOD, BAD, UNCERTAIN or NotConnected states; The state mapping result is associated with the quality code and state text fields in the standard sample object.

5. The multi-protocol isolated runtime and historical compatibility migration method for industrial edge data acquisition according to claim 3, characterized in that, When writing the latest value structure to Redis in step S7, the original system's device must be maintained. <deviceid>Keys and items: <itemid> Field format; when writing to Influx historical fields, keep the original system's measurement name, field name, and label name unchanged, and at least retain the dataType, value, quality, sourcePoint, status, error_msg, and is_success fields.< / itemid> < / deviceid> 6. The multi-protocol isolated runtime and historical compatibility migration method for industrial edge data acquisition according to claim 3, characterized in that, The hot update coordination logic in step S9 includes: for the addition, activation, deactivation, modification, or deletion of a channel, calling the channel coordination method to start, stop, or rebuild the target channel actor; for the addition, activation, deactivation, modification of the acquisition cycle, or change of the channel to which a device belongs, calling the device coordination method to create, destroy, restart, or migrate the target device scheduler; for the addition, deletion, or modification of a measurement point, the device scheduler is not restarted, but the channel actor rereads the measurement point metadata in the next acquisition cycle.

7. The multi-protocol isolated runtime and historical compatibility migration method for industrial edge data acquisition according to claim 3, characterized in that, The standard sample object includes at least: measurement point identifier, channel identifier, device identifier, data value, data type, quality code, status text, error message, timestamp, and success identifier.

8. The multi-protocol isolated runtime and historical compatibility migration method for industrial edge data acquisition according to claim 3, characterized in that, In step S8, when an upload fails, the success flag in the standard sample object is set to false or an equivalent flag is written back to the historical storage to record the failed sample. The background retry task re-uploads failed samples and updates their cloud upload results upon successful retry.

9. The multi-protocol isolated runtime and historical compatibility migration method for industrial edge data acquisition according to claim 3, characterized in that, When the management interface and the hot update coordination module detect that the target channel has not yet been loaded into the running state by the write interface, a hot load attempt is automatically performed based on the metadata.

Images