Industrial data acquisition task dynamic scheduling method and device based on Actor model, equipment and medium

Abstract

The invention discloses an Actor model-based industrial data acquisition task dynamic scheduling method, which comprises the following steps of: creating a scheduler Actor, a connection management Actor and a protocol processing Actor in an Actor operation environment, and initializing a layered time wheel timer; dynamically creating an independent connection Actor instance for each data acquisition connection request through the connection management Actor; sending a data acquisition command message to a corresponding connection Actor instance through the scheduler Actor, so that the connection Actor instance performs data acquisition to obtain a data acquisition result message of a data acquisition result; standardizing a data acquisition result in the data acquisition result message through a protocol adaptation layer managed by a protocol processing Actor; and publishing the standardized data to a downstream system. Through the isolation characteristic of the Actor model and an asynchronous message driving mechanism, high-concurrency and low-delay industrial data acquisition is realized, the reliability, the expandability and the resource utilization efficiency of the system are remarkably improved, and the data acquisition requirement in a large-scale industrial Internet of Things scene can be effectively met.

Description

Technical Field

[0001] This application relates to the field of industrial Internet of Things (IoT) data acquisition technology, specifically to a method, device, equipment, and medium for dynamic scheduling of industrial data acquisition tasks based on the Actor model. Background Technology

[0002] With the rapid development of intelligent manufacturing, a large number of sensors, PLCs (Programmable Logic Controllers), DCS (Distributed Control Systems), and other devices have been deployed in industrial settings, generating massive amounts of real-time data. Traditional data acquisition systems often face the following technical challenges when dealing with large-scale, high-concurrency industrial scenarios: Synchronous blocking processing is inefficient: Traditional synchronous blocking data acquisition is prone to thread blocking when dealing with a large number of concurrent connections, which limits the system throughput and cannot meet the real-time requirements of industrial sites. Resource contention and lock conflicts: In a multi-threaded environment, the management of shared state can easily lead to resource contention and deadlock issues, affecting the stability and performance of the system; Lack of elastic scalability: Traditional architectures struggle to dynamically adjust resource allocation based on load, making them unable to effectively cope with fluctuations in data volume in industrial settings; Inadequate fault recovery mechanism: When the system malfunctions or restarts, there is a lack of an effective state recovery mechanism, which can easily lead to data loss or state inconsistency. Coarse task scheduling granularity: Traditional timed task scheduling mechanisms lack fine-grained task management and dynamic adjustment capabilities, making them unsuitable for complex industrial data acquisition scenarios.

[0003] Existing solutions often employ thread pools or message queues, but these methods still have limitations in handling complex industrial protocol adaptations, connection state management, and dynamic location adjustments. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, this application provides a method, apparatus, equipment and medium for dynamic scheduling of industrial data acquisition tasks based on the Actor model, so as to solve the above technical problems.

[0005] This application provides a dynamic scheduling method for industrial data acquisition tasks based on the Actor model, including: Construct the runtime environment for the Actor, and create a scheduler Actor, a connection management Actor, and a protocol processing Actor within the runtime environment of the Actor, as well as initialize a hierarchical time wheel timer; In response to external data acquisition connection requests, the connection management actor dynamically creates an independent connection actor instance for each data acquisition connection request. Based on the triggering of the hierarchical time wheel timer, the scheduler Actor sends a data acquisition command message to the corresponding connected Actor instance, so that the connected Actor instance responds to the data acquisition command message to perform data acquisition and obtains a data acquisition result message of the data acquisition result; The protocol adaptation layer managed by the protocol processing Actor standardizes the data collection results in the data collection result message to obtain standardized data. The standardized data is published to downstream systems to complete data scheduling.

[0006] In one embodiment of this application, the method further includes: The data acquisition command message and the data acquisition result message are processed asynchronously in a message-driven manner using a bounded message queue through a message processing engine.

[0007] In one embodiment of this application, the step of using a bounded message queue to process the data acquisition command message and the data acquisition result message in an asynchronous message-driven manner includes: Configure independent bounded message queues for the data acquisition command message and the data acquisition result message respectively; Processing priorities are set according to message type to determine the scheduling priority of the data acquisition command message and the data acquisition result message; The bounded message queues are monitored, and backpressure control is triggered when the fill level of any bounded message queue reaches a preset capacity threshold, so as to suppress the continued flow of messages into the message queue whose capacity has reached the preset threshold.

[0008] In one embodiment of this application, the connection Actor instance is managed for lifecycle through a connection state machine, and the lifecycle states of the connection Actor instance include: uninitialized, connected, and disconnected.

[0009] In one embodiment of this application, the method further includes: dividing collection points with the same collection period into the same task group according to the collection period of each collection point to form a batch data collection task, and registering the batch data collection task to the hierarchical time wheel timer; triggering the hierarchical time wheel timer to cause the connection Actor instance to execute the batch data collection task to perform data collection.

[0010] In one embodiment of this application, the method further includes: The system status of the Actor's runtime environment is collected in real time. The system status includes: the internal status of each Actor instance, the connection status of each connected Actor instance, and the execution status of the data acquisition tasks managed by the scheduler Actor corresponding to the data acquisition connection request. The system state is snapshotted and saved at predetermined intervals to generate snapshot data; When a system failure is detected, the system state of the Actor's runtime environment is restored from the most recently saved snapshot data.

[0011] In one embodiment of this application, the method further includes: Based on preset business rules, the Actor instances are divided into critical Actor instances and non-critical Actor instances; Obtain the available resources of the Actor's runtime environment, and generate a degradation decision instruction when the available resources are lower than a preset resource threshold; In response to the degradation decision instruction, the execution of the collection tasks associated with the non-critical Actor instance is suspended or restricted, while the normal execution of the collection tasks associated with the critical Actor instance is maintained.

[0012] This application provides a dynamic scheduling device for industrial data acquisition tasks based on the Actor model, comprising: The environment creation module is used to build the runtime environment of the Actor, and create a scheduler Actor, a connection management Actor, and a protocol processing Actor in the runtime environment of the Actor, as well as initialize a hierarchical time wheel timer; The instance creation module is used to respond to external data acquisition connection requests by dynamically creating an independent connection Actor instance for each data acquisition connection request through the connection management Actor. The data acquisition module is used to send a data acquisition command message to the corresponding connected Actor instance through the scheduler Actor based on the triggering of the hierarchical time wheel timer, so that the connected Actor instance responds to the data acquisition command message to perform data acquisition and obtain a data acquisition result message of the data acquisition result; The data conversion module is used to standardize the data collection results in the data collection result message by processing the protocol adaptation layer managed by the Actor through the protocol processing, and to obtain standardized data. The data output module is used to publish the standardized data to downstream systems to complete data scheduling.

[0013] This application provides a dynamic scheduling device for industrial data acquisition tasks based on the Actor model, comprising: One or more processors; A memory is used to store one or more programs, which, when executed by one or more processors, enable the data processing to implement the steps of the above-described dynamic scheduling method for industrial data acquisition tasks based on the Actor model.

[0014] This application provides a computer-readable storage medium storing a computer program that, when executed by a computer's processor, causes the computer to perform the steps of the aforementioned dynamic scheduling method for industrial data acquisition tasks based on the Actor model.

[0015] The beneficial effects of this application are as follows: This application provides a dynamic scheduling method for industrial data acquisition tasks based on the Actor model, comprising: constructing an Actor runtime environment, and creating a scheduler Actor, a connection management Actor, and a protocol processing Actor within the Actor runtime environment, and initializing a hierarchical time wheel timer; responding to external data acquisition connection requests, dynamically creating an independent connection Actor instance for each data acquisition connection request through the connection management Actor; based on the triggering of the hierarchical time wheel timer, sending a data acquisition command message to the corresponding connection Actor instance through the scheduler Actor, so that the connection Actor instance responds to the data acquisition command message to perform data acquisition, and obtains a data acquisition result message; standardizing the data acquisition result in the data acquisition result message through the protocol adaptation layer managed by the protocol processing Actor, obtaining standardized data; and publishing the standardized data to the downstream system to complete data scheduling. This invention, through the isolation characteristics and asynchronous message-driven mechanism of the Actor model, achieves high-concurrency, low-latency industrial data acquisition, significantly improving the system's reliability, scalability, and resource utilization efficiency, and can effectively meet the data acquisition needs of large-scale industrial IoT scenarios.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] 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. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1This is a flowchart illustrating an exemplary embodiment of an industrial data acquisition task dynamic scheduling method based on the Actor model. Figure 2 A schematic diagram of the structure of an industrial data acquisition task dynamic scheduling device based on the Actor model is shown as an exemplary embodiment of this application; Figure 3 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0018] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0019] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0020] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0021] For ease of understanding, the following explains some key terms in this embodiment: The Actor runtime environment provides a concurrent computing model, where the Actor is the basic unit of concurrent computation. Actors communicate with each other through asynchronous message passing, and each Actor has its own independent internal state, thus avoiding the resource contention problem in traditional multithreaded programming.

[0022] Scheduler Actor: This Actor is responsible for managing and coordinating the execution of data acquisition tasks. Its main functions include receiving timer trigger events, sending data acquisition command messages to connected Actor instances, and scheduling data acquisition tasks as a whole.

[0023] Connection Management Actor: This actor is responsible for handling external data acquisition connection requests. When a new connection request is received, this actor dynamically creates and manages the corresponding connection actor instance to achieve independent management of each data acquisition connection. The connection management actor is also responsible for managing the lifecycle of all connection actors.

[0024] Protocol Processing Actor: This actor is responsible for handling various communication protocols involved in the data acquisition process. Internally, it includes a protocol adaptation layer used to convert raw data collected from different industrial devices into a unified, standardized format.

[0025] Layered Time Wheel Timer: This timer is a scheduled task scheduling mechanism that supports the registration and triggering of a large number of scheduled tasks through a multi-layered time wheel structure. It is especially suitable for scenarios that require periodic execution of data acquisition tasks.

[0026] Connection Actor Instance: This instance is an Actor dynamically created for each data acquisition connection request. Each connection Actor instance is independently responsible for connecting to a specific data acquisition point, executing data acquisition commands, and returning data acquisition results.

[0027] Please see Figure 1 , Figure 1 This is a flowchart illustrating an exemplary embodiment of an industrial data acquisition task dynamic scheduling method based on an Actor model. The method includes at least steps S110 to S150, which are described in detail below: Step S110: Construct the runtime environment for the Actor, and create the scheduler Actor, connection management Actor, and protocol processing Actor within the runtime environment, as well as initialize a hierarchical time wheel timer; Specifically, the Actor runtime environment can be a software platform based on the Actor model. Scheduler Actor, connection management Actor, and protocol processing Actor are instantiated as core functional modules. The hierarchical time wheel timer can be a timer used to manage the triggering of periodic data acquisition tasks. The time wheel scheduler uses a hierarchical hash time wheel algorithm, supports task scheduling with millisecond-level precision, enables the addition, deletion, and modification of scheduled tasks, and establishes a task cancellation mechanism to support dynamic task management.

[0028] Step S120: In response to an external data acquisition connection request, a separate connection Actor instance is dynamically created for each data acquisition connection request through the connection management Actor; Specifically, when the system receives a connection request from an industrial field device, the connection management Actor instantiates a new connection Actor, or connection Actor instance, based on the request parameters (such as device ID, IP address, port, etc.). For example, when a new sensor requests to connect, the connection management Actor creates a dedicated connection Actor instance for that sensor, responsible for communicating with it.

[0029] Step S130: Based on the triggering of the hierarchical time wheel timer, the scheduler Actor sends a data acquisition command message to the corresponding connected Actor instance, so that the connected Actor instance responds to the data acquisition command message to perform data acquisition and obtains a data acquisition result message of the data acquisition result. Specifically, when the hierarchical time wheel timer triggers at a preset time, it notifies the scheduler Actor. Based on the timer's trigger event, the scheduler Actor identifies the connected Actor instances that need to perform data acquisition tasks and sends them data acquisition command messages containing acquisition instructions. For example, if the timer triggers every second, the scheduler Actor sends a "read current temperature value" command message to all registered connected Actor instances.

[0030] Step S140: Standardize the data collection results in the data collection result message through the protocol adaptation layer managed by the protocol processing Actor to obtain standardized data; Specifically, after the connecting Actor instance completes data collection and generates a data collection result message, this message is sent to the protocol processing Actor. The protocol adaptation layer inside the protocol processing Actor is responsible for parsing the raw data collection results. After parsing, the raw data is converted into a unified data structure, i.e., standardized data.

[0031] Step S150: Standardized data is published to downstream systems to complete data scheduling.

[0032] Specifically, standardized data, after being processed by the protocol adaptation layer, can be sent to downstream systems such as message queues, databases, or cloud platforms. The publishing process can employ a publish-subscribe pattern. For example, standardized temperature data can be published to a Kafka topic for real-time monitoring systems to subscribe to.

[0033] This invention achieves high-concurrency, low-latency industrial data acquisition by leveraging the isolation characteristics of the Actor model and the asynchronous message-driven mechanism. This significantly improves the system's reliability, scalability, and resource utilization efficiency, effectively meeting the data acquisition needs of large-scale industrial IoT scenarios.

[0034] In one embodiment, the method further includes: using a bounded message queue to process data acquisition command messages and data acquisition result messages in an asynchronous message-driven manner via a message processing engine.

[0035] The message processing engine is the core component responsible for managing and executing message processing logic. This engine can distribute received data acquisition command messages and data acquisition result messages to the corresponding Actor instances for processing according to preset rules.

[0036] A bounded queue is a queue with limited storage space. A maximum capacity is set during creation; once this capacity is reached, subsequent insertion operations will be blocked or discarded. This type of queue is typically implemented using a fixed-size array or a circular linked list.

[0037] The asynchronous message-driven processing of the data acquisition command message and the data acquisition result message means that the generation and consumption of these messages are separate. When the scheduler actor sends a data acquisition command message, it is asynchronously placed into a message queue, allowing the scheduler actor to continue executing other tasks without waiting for the connected actor instance to complete acquisition. Similarly, when the connected actor instance completes data acquisition and generates a data acquisition result message, this message is also asynchronously placed into another message queue, awaiting further processing by the protocol processing actor or related components.

[0038] This application processes data acquisition command messages and data acquisition result messages using an asynchronous message-driven model, which can significantly improve the concurrent processing capability and system stability of the data scheduling system.

[0039] In one embodiment, a bounded message queue is used to process data acquisition command messages and data acquisition result messages in an asynchronous message-driven manner, including: Configure independent bounded message queues for data acquisition command messages and data acquisition result messages respectively; set processing priorities according to message type to determine the scheduling priority of data acquisition command messages and data acquisition result messages; monitor the bounded message queues, and trigger backpressure control when the fill amount of any bounded message queue reaches a preset capacity threshold to suppress the continued flow of messages into the message queue whose capacity has reached the preset threshold.

[0040] Specifically, separate bounded message queues are configured for data acquisition command messages and data acquisition result messages. This aims to achieve isolated processing of different message types, preventing a large influx of one message type from blocking or delaying the processing of the other. For example, data acquisition command messages typically have high real-time requirements, while data acquisition result messages may be voluminous but have relatively less stringent real-time requirements. By setting up separate queues for the two types of messages, it can be ensured that even a surge in the volume of data acquisition result messages will not directly affect the timely delivery of data acquisition command messages.

[0041] Based on this, processing priorities are set according to message type to determine the scheduling priority of data acquisition command messages and data acquisition result messages. Message priorities are set based on business needs and message importance. For example, data acquisition command messages are typically assigned higher priority to ensure that the scheduler Actor can promptly send acquisition instructions to connected Actor instances, thereby guaranteeing the real-time startup of data acquisition tasks. Data acquisition result messages, on the other hand, can be assigned relatively lower priority based on their importance or the urgency of subsequent processing. When the message processing engine retrieves messages from the queue for processing, it prioritizes high-priority messages. This can be achieved by allocating different processing thread pools for messages of different priorities, or by using a priority scheduling algorithm within a single processing thread, thereby optimizing system response speed and resource allocation efficiency.

[0042] Furthermore, monitoring of the bounded message queue can be achieved by periodically querying the current queue fill level. A preset capacity threshold acts as a warning line; when the number of messages in the queue reaches this threshold, it indicates that the system's processing capacity may be nearing saturation or that a potential bottleneck exists. At this point, a backpressure control mechanism is activated to slow down or pause the production rate of upstream messages, preventing queue overflow. Specifically, this suppression can be achieved by sending a rejection signal to the message producer, causing it to suspend sending new messages. Backpressure control effectively avoids system overload, ensuring the smoothness and continuity of message processing.

[0043] In one embodiment, the connection Actor instance is managed for lifecycle through a connection state machine. The lifecycle states of the connection Actor instance include: uninitialized, connected, and disconnected.

[0044] Specifically, the connection actor instance is the core component for handling data acquisition connections, and its lifecycle management refers to the standardized control of the entire process from creation to destruction. Through the connection state machine, the behavior and executable operations of the connection actor instance at different stages can be clearly defined, ensuring the correctness and consistency of its state. For example, when a connection actor instance is created, it may enter an "uninitialized" state; after a successful connection is established, it enters a "connected" state; and when the connection is interrupted or no longer needed, it enters a "disconnected" state.

[0045] In one embodiment, the method further includes: dividing collection points with the same collection period into the same task group according to the collection period of each collection point to form a batch data collection task, and registering the batch data collection task to the hierarchical time wheel timer; triggering the hierarchical time wheel timer to enable the connected Actor instance to execute the batch data collection task for data collection.

[0046] Specifically, during system initialization or operation, all data collection points can be scanned and analyzed to obtain the preset collection period for each point, such as 1 second, 5 seconds, or 1 minute. Subsequently, the system aggregates data collection points with the same collection period into a task group. For example, all data collection points requiring collection every 5 seconds will be grouped into a "5-second collection task group." Each task group is encapsulated as an independent batch data collection task, which includes identifiers for all data collection points within the group and common collection parameters. After task grouping, the batch data collection tasks are registered to the hierarchical time wheel timer. During registration, each batch data collection task is placed in the corresponding slot of the hierarchical time wheel timer according to its corresponding collection period. The hierarchical time wheel timer periodically checks its slots, and when the time for a slot expires, it triggers the registered batch data collection task within it.

[0047] When a tiered time wheel timer triggers a batch data acquisition task, it sends a trigger notification to the scheduler actor. Upon receiving this notification, the scheduler actor parses the batch data acquisition task to obtain all the acquisition points it contains. Based on these acquisition points, the scheduler actor identifies one or more connected actor instances responsible for these acquisition points. Subsequently, the scheduler actor sends a batch data acquisition command message to these relevant connected actor instances. This batch data acquisition command message contains a list of acquisition points that need to be acquired in batches. Upon receiving this batch data acquisition command message, the connected actor instances iterate through the list of acquisition points specified in the message and execute the data acquisition operations sequentially. After completing the acquisition, the connected actor instances encapsulate the acquisition results into one or more data acquisition result messages and perform subsequent processing.

[0048] This application significantly reduces the number of scheduling events that the scheduler (Actor) needs to process by aggregating collection points with the same collection period into batch data collection tasks and uniformly registering them to a hierarchical time wheel timer for scheduling, thereby reducing the load on the scheduling system.

[0049] In one embodiment, the method further includes: real-time acquisition of the system state of the Actor's runtime environment, the system state including: the internal state of each Actor instance, the connection state of each connected Actor instance, and the execution state of the data acquisition tasks managed by the scheduler Actor corresponding to the data acquisition connection request; taking snapshots of the system state at predetermined intervals to generate snapshot data; and restoring the system state of the Actor's runtime environment from the most recently saved snapshot data when a system failure is detected.

[0050] The system status encompasses comprehensive operational information about the Actor runtime environment, specifically including the internal status of each Actor instance, the connection status of each connecting Actor instance, and the execution status of the data acquisition tasks managed by the scheduler Actor corresponding to the data acquisition connection requests. The internal status of each Actor instance refers to the current data and configuration parameters of each Actor (such as the scheduler Actor, connection management Actor, protocol processing Actor, and all dynamically created connecting Actor instances). The connection status of each connecting Actor instance indicates the current activity status of each data acquisition connection, such as whether a connection has been established, is transmitting data, or has been disconnected. The execution status of the data acquisition tasks managed by the scheduler Actor corresponding to the data acquisition connection requests records the current progress, next execution time, and other relevant parameters of all data acquisition tasks scheduled by the scheduler Actor.

[0051] To enable effective recovery in the event of system failure, the real-time acquired system state needs to be periodically and persistently stored. Snapshot saving refers to serializing the complete system state of the current Actor runtime environment at preset time intervals and storing it as snapshot data. This snapshot data can be stored in a reliable persistent storage medium. When the system detects a failure, such as when an abnormality or crash in the Actor runtime environment is detected through a heartbeat mechanism, anomaly capture, or external health checks, the most recently successfully saved snapshot data is loaded from persistent storage. Subsequently, the system reconstructs the Actor runtime environment based on this snapshot data.

[0052] This application enables the system to quickly revert to the most recent stable state before the failure after a failure occurs, thereby significantly shortening the system recovery time, minimizing data loss, and ensuring the continuity and reliability of data scheduling services.

[0053] In one embodiment, the method further includes: dividing Actor instances into critical Actor instances and non-critical Actor instances based on preset business rules; obtaining the available resources of the Actor's runtime environment, and generating a degradation decision instruction when the available resources are lower than a preset resource threshold; and suspending or restricting the execution of collection tasks associated with non-critical Actor instances in response to the degradation decision instruction, while maintaining the normal execution of collection tasks associated with critical Actor instances.

[0054] The preset business rules are standards for classifying Actor instances based on actual business needs and system importance. Critical Actor instances typically refer to Actors essential to the core functions of the system, such as scheduler Actors, protocol processing Actors, and connection Actor instances that handle high-priority data. Non-critical Actor instances, on the other hand, refer to those that can be suspended or limited when resources are constrained without severely impacting core business operations, such as connection Actor instances that handle low-priority data. Available resources can be obtained by calling API interfaces provided by the operating system (e.g., interfaces for querying metrics such as CPU utilization, memory usage, network bandwidth, and disk I / O).

[0055] When available resources fall below a preset resource threshold, the system will generate a degradation decision instruction. For example, when CPU utilization consistently exceeds 80%, it is determined that resources are insufficient. Once resource insufficiency is detected, the system will immediately generate a degradation decision instruction.

[0056] In response to the degradation decision instruction, the system will suspend or restrict the execution of data acquisition tasks associated with the non-critical Actor instances. This way, when system resources are strained, the data acquisition tasks handled by those Actor instances marked as non-critical will be limited. Meanwhile, the system will maintain the normal execution of data acquisition tasks associated with the critical Actor instances.

[0057] This application categorizes Actor instances by criticality and dynamically manages system resources based on available resources. When system resources fall below a preset threshold, data acquisition tasks associated with non-critical Actor instances can be paused or restricted, rapidly releasing system resources and preventing overall system performance crashes, while ensuring the continued normal execution of data acquisition tasks associated with critical Actor instances. This significantly improves the reliability of the Actor-based dynamic scheduling method for industrial data acquisition tasks, guaranteeing the continuity and stability of core business data acquisition.

[0058] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0059] This application also provides a dynamic scheduling method for industrial data acquisition tasks based on the Actor model, including: This embodiment provides an implementation process for a dynamic scheduling method for industrial data acquisition tasks based on the Actor model, specifically including the following steps: Step S100: System Initialization and Actor Architecture Establishment During system startup, the Actor runtime environment is initialized, and an executor arbiter is created to manage thread resources. Within this runtime environment, core functional Actors are created, including: a scheduler Actor for registering and triggering scheduled tasks, a connection management Actor for managing the lifecycle of all connected Actors, and a protocol processing Actor for performing industrial protocol data conversion. Simultaneously, a hierarchical hash time wheel timer is initialized. This timer supports millisecond-level precision task scheduling and features a mechanism for dynamically adding, deleting, modifying, and canceling scheduled tasks.

[0060] Step S200: Connect Actor Dynamic Creation and Management In response to external connection requests, a separate connection Actor instance is created for each data acquisition connection through the connection management Actor. Each connection Actor instance maintains a connection state machine, which includes at least an uninitialized state, a connected state, and a disconnected state, and triggers the corresponding event handling process when the state transitions.

[0061] Step S300: Dynamic scheduling and execution of data acquisition tasks Precise scheduling of data acquisition tasks is achieved using a hierarchical hash timer. Tasks are grouped by acquisition interval, and points with the same interval are processed in batches. The system supports dynamically adding, updating, or deleting acquisition tasks during runtime and distributes tasks to multiple physical connection processors for execution through a load balancing mechanism.

[0062] Step S400: Asynchronous message-driven processing A bounded message queue is used to process messages asynchronously in the system. These messages include acquisition command messages, point acquisition result messages, and connection status change messages. A message priority scheduling mechanism is implemented to ensure that critical messages are processed first, and a backpressure control mechanism is established to suppress the inflow of upstream messages when the message queue reaches its capacity threshold.

[0063] Step S500: Protocol Adaptation and Data Processing The protocol adaptation layer supports data acquisition and conversion for various industrial protocols, including OPC UA, Modbus TCP, and analog protocols. It performs format conversion and standardization on the acquired raw data to generate a unified point acquisition value format, and performs data type validation and format standardization.

[0064] Step S600: State Management and Fault Tolerance Comprehensive monitoring of system operation status is implemented, including connection status, task execution status, and system resource usage. A snapshot mechanism is used to periodically persist system state to storage devices to support fault recovery. Retry mechanisms, timeout controls, and graceful degradation strategies are also established to address scenarios involving network anomalies, device failures, and resource shortages.

[0065] Step S700: Data Output and System Monitoring Data that has undergone protocol adaptation and standardization is published to downstream systems via the cluster data bus.

[0066] In one embodiment, the system initialization and Actor architecture establishment steps further include: The Actor runtime environment construction sub-step creates the Actor runtime environment, initializes the executor arbiter used to manage thread resources, and configures the mailbox capacity limit and Actor supervision policy for each Actor. The core function, the Actor instantiation sub-step, creates a scheduler Actor, a connection management Actor, and a protocol processing Actor in the Actor runtime environment. The scheduler Actor is configured to register and trigger scheduled tasks, the connection management Actor is configured to manage the lifecycle of all connection actors, and the protocol processing Actor is configured to schedule and execute data conversions for industrial protocols. The initial sub-step of the hierarchical time wheel timer initializes the hierarchical time wheel timer that supports task scheduling with millisecond-level precision, and enables the dynamic addition, deletion, modification, and cancellation management of the timed tasks. The cluster communication infrastructure construction sub-step establishes a cluster data bus and service discovery mechanism to support the distributed deployment of the Actor runtime environment, and configures the heartbeat detection function between nodes to continuously monitor the health status of cluster nodes.

[0067] In one embodiment, the step of dynamically creating and managing connected Actors further includes: The connection actor instantiation sub-step creates an independent connection actor instance for each external data acquisition connection and initializes the connection state machine corresponding to the instance, setting its initial state to the unconnected state. At the same time, a message processing loop is established to asynchronously respond to connection operation commands. The connection state machine management sub-step implements a three-state connection state machine including uninitialized state, connected state, and disconnected state. It executes the state transition logic for connection establishment, connection disconnection, and connection reconnection, and records error information during the connection process to support fault diagnosis and recovery. The physical connection control sub-step instantiates the corresponding physical connection processor according to the industrial protocol type adapted by each connection Actor instance, and implements connection timeout control, automatic retry and periodic connection health checks based on the processor. The message communication management sub-step configures a message mailbox with a capacity limit for each connected Actor instance. Backpressure control and message priority scheduling mechanisms are implemented in the mailbox, and persistent storage of messages is supported to ensure message recoverability in failure scenarios.

[0068] In one embodiment, the step of dynamically scheduling and executing the data acquisition task further includes: The task grouping and registration sub-steps divide the data collection points into different task groups based on their collection intervals. Points with the same collection interval are grouped into a batch data collection task, and the batch data collection task is registered to the hierarchical time wheel timer. At the same time, a mapping relationship between task identifiers and task instances is established to support task search and cancellation. The high-precision timing scheduling sub-step achieves millisecond-level precision timing task scheduling based on a hierarchical time wheel timer. It supports long-cycle acquisition tasks through a time wheel hierarchical overflow handling mechanism and uses a time compensation algorithm to reduce the impact of system clock drift on scheduling accuracy. The task load balancing sub-step dynamically distributes batch collection tasks to multiple processor cores for parallel execution. It uses a work-stealing algorithm to dynamically balance the load among processors and adaptively adjusts the task allocation strategy based on the real-time system load. The dynamic management sub-step for data acquisition tasks supports adding new data acquisition tasks dynamically during system operation, hot updating of parameters for registered data acquisition tasks, and cancellation and resource cleanup operations for specified data acquisition tasks.

[0069] In one embodiment, the asynchronous message-driven processing steps further include: The message queue configuration sub-step creates multiple bounded message queues with capacity limits, which are used to cache collection command messages, collection result data messages, and system status change messages, respectively. A message priority scheduling mechanism is implemented in each message queue to ensure that critical messages are processed first, and a backpressure control strategy is established to suppress the continued inflow of upstream messages when the queue capacity reaches the threshold. The asynchronous task scheduling sub-step performs asynchronous scheduling and processing of execution messages based on the asynchronous runtime framework, implements race condition control for multiple concurrent asynchronous operations, and provides a task cancellation interface to support the graceful termination of asynchronous tasks. The message routing and reliable transmission sub-step establishes a message routing table to guide message transmission between different Actor instances. During the routing process, messages are filtered and format converted to maintain data format consistency, and message acknowledgment and retransmission mechanisms ensure reliable message delivery. The message exception handling sub-step captures and handles exceptions that occur during message processing, establishes a dead letter queue to store messages that cannot be delivered normally, and implements message retry for recoverable exceptions and executes a degradation handling strategy for unrecoverable exceptions.

[0070] In one embodiment, the protocol adaptation and data processing steps further include: The multi-protocol adaptation sub-step constructs a protocol adaptation layer that supports OPC UA, Modbus TCP, and simulated protocols, including: The OPC UA protocol adapter module is used to perform node browsing, data subscription, and read / write operations; The Modbus TCP protocol adapter module is used to perform register read and write functions; The simulation protocol adaptation module provides simulation data based on a preset data generation algorithm; The data standardization processing sub-step defines a unified data format within the system, converts raw data collected from different protocols into the unified data format, and performs data type mapping, precision adjustment, and unit conversion during the conversion process to ensure data consistency and interpretability. The data quality assessment sub-step involves performing quality checks on the standardized data, identifying abnormal data and data loss, verifying data integrity through a verification mechanism, and establishing data quality assessment indicators to provide a basis for system operation optimization.

[0071] In one embodiment, the state management and fault tolerance steps further include: The runtime status monitoring sub-step monitors the runtime environment metrics of the Actor in real time. These metrics include at least processor utilization, memory usage, and network throughput. It also tracks the connection status of each connected Actor instance and the execution progress of the collection tasks managed by the scheduler Actor. Finally, it triggers system anomaly alarms based on preset thresholds. The system status snapshot sub-step performs snapshot saving of the system status in the Actor runtime environment at a predetermined period. The saved snapshot includes the connection status of each connected Actor instance, the numerical and quality status of each collection point, and the configuration and execution status of registered collection tasks. Incremental snapshot method is used to reduce the resource consumption of status saving, and the generated snapshot data is compressed and encrypted to optimize storage efficiency and security. The fault self-recovery sub-step automatically restores the system state of the Actor runtime environment from the most recently saved snapshot when a system fault is detected; after the state recovery is completed, system function verification is performed to ensure that the system operates as expected after recovery; The service degradation protection sub-step divides system functions into critical and non-critical functions according to preset strategies. When system resources are detected to be below the protection threshold, the execution of non-critical functions is suspended or limited, while priority is given to maintaining the continuous operation of the collection tasks corresponding to critical functions.

[0072] In one embodiment, the data output and system monitoring steps further include: The standardized data publishing sub-step publishes standardized data, which has been adapted and processed by the protocol, to the message bus. It supports multiple data serialization formats, including JSON and Protobuf, and improves data transmission efficiency through a serialization optimization mechanism. The system operation monitoring sub-step provides a system status monitoring interface for external queries, enables real-time export of key performance indicators to support system performance analysis, and establishes a health check endpoint to adapt to containerized deployment environments. The runtime resource management sub-step dynamically adjusts the size of the thread pool in the Actor runtime environment to adapt to different system loads, implements a connection pool management mechanism to improve the efficiency of physical connection reuse, and prevents system resource exhaustion through resource quota limits. The system expansion and integration sub-steps provide a plug-in architecture to support the expansion of custom industrial protocols and functional modules, enable hot updates of system configurations to support dynamic adjustments at runtime, and achieve seamless integration with downstream third-party systems through standardized data and interface definitions.

[0073] Figure 2 This is a schematic diagram illustrating the structure of an industrial data acquisition task dynamic scheduling device based on the Actor model, as an exemplary embodiment of this application. Figure 2 As shown, this application provides a dynamic scheduling device for industrial data acquisition tasks based on the Actor model. The device includes: The environment creation module 210 is used to build the runtime environment of the Actor, and create the scheduler Actor, connection management Actor and protocol processing Actor in the runtime environment of the Actor, as well as initialize a hierarchical time wheel timer; The instance creation module 220 is used to respond to external data acquisition connection requests by dynamically creating an independent connection Actor instance for each data acquisition connection request through the connection management Actor; The data acquisition module 230 is used to send data acquisition command messages to the corresponding connected Actor instances through the scheduler Actor based on the triggering of the hierarchical time wheel timer, so that the connected Actor instances respond to the data acquisition command messages to perform data acquisition and obtain the data acquisition result messages of the data acquisition results; Data conversion module 240 is used to standardize the data collection results in the data collection result message through the protocol adaptation layer managed by the protocol processing Actor to obtain standardized data; The data output module 250 is used to publish standardized data to downstream systems to complete data scheduling.

[0074] It should be noted that the Actor-based dynamic scheduling device for industrial data acquisition tasks and the Actor-based dynamic scheduling method for industrial data acquisition tasks provided in the above embodiments belong to the same concept. The specific methods by which each module and unit performs its operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the Actor-based dynamic scheduling device for industrial data acquisition tasks provided in the above embodiments can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0075] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the dynamic scheduling method for industrial data acquisition tasks based on the Actor model provided in the above embodiments.

[0076] Figure 3 A schematic diagram of a computer system suitable for implementing the memory of embodiments of this application is shown. It should be noted that... Figure 3 The computer system with the memory shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0077] like Figure 3 As shown, the computer system 300 includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage into Random Access Memory (RAM) 303. The RAM also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0078] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0079] Specifically, according to embodiments of this application, the processes described in the above-referenced flowchart can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing a computer program for performing the aforementioned Actor-based dynamic scheduling method for industrial data acquisition tasks. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium 311. When the computer program is executed by the central processing unit (CPU) 301, it performs various functions defined in the system of this application.

[0080] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM) 303, read-only memory (ROM) 302, erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0081] 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. Each block in the flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing the 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, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block or combination of blocks in the block diagram or flowchart may 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.

[0082] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0083] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a computer's processor, causes the computer to perform the aforementioned dynamic scheduling method for industrial data acquisition tasks based on the Actor model. This computer-readable storage medium may be included in the memory described in the above embodiments, or it may exist independently without being assembled into that memory.

[0084] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the Actor-based dynamic scheduling method for industrial data acquisition tasks provided in the various embodiments above.

[0085] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A dynamic scheduling method for industrial data acquisition tasks based on the Actor model, characterized in that, include: Construct the runtime environment for the Actor, and create a scheduler Actor, a connection management Actor, and a protocol processing Actor within the runtime environment of the Actor, as well as initialize a hierarchical time wheel timer; In response to external data acquisition connection requests, the connection management actor dynamically creates an independent connection actor instance for each data acquisition connection request. Based on the triggering of the hierarchical time wheel timer, the scheduler Actor sends a data acquisition command message to the corresponding connected Actor instance, so that the connected Actor instance responds to the data acquisition command message to perform data acquisition and obtains a data acquisition result message of the data acquisition result; The protocol adaptation layer managed by the protocol processing Actor standardizes the data collection results in the data collection result message to obtain standardized data. The standardized data is published to downstream systems to complete data scheduling.

2. The dynamic scheduling method for industrial data acquisition tasks based on the Actor model according to claim 1, characterized in that, The method further includes: The data acquisition command message and the data acquisition result message are processed asynchronously in a message-driven manner using a bounded message queue through a message processing engine.

3. The dynamic scheduling method for industrial data acquisition tasks based on the Actor model according to claim 2, characterized in that, The process of using a bounded message queue to process the data acquisition command message and the data acquisition result message in an asynchronous message-driven manner includes: Configure independent bounded message queues for the data acquisition command message and the data acquisition result message respectively; Processing priorities are set according to message type to determine the scheduling priority of the data acquisition command message and the data acquisition result message; The bounded message queues are monitored, and backpressure control is triggered when the fill level of any bounded message queue reaches a preset capacity threshold, so as to suppress the continued flow of messages into the message queue whose capacity has reached the preset threshold.

4. The dynamic scheduling method for industrial data acquisition tasks based on the Actor model according to claim 1, characterized in that, The connection Actor instance manages its lifecycle through a connection state machine. The lifecycle states of the connection Actor instance include: uninitialized, connected, and disconnected.

5. The dynamic scheduling method for industrial data acquisition tasks based on the Actor model according to claim 1, characterized in that, The method further includes: dividing collection points with the same collection period into the same task group according to the collection period of each collection point to form a batch data collection task, and registering the batch data collection task to the hierarchical time wheel timer; triggering the hierarchical time wheel timer to make the connected Actor instance execute the batch data collection task to collect data.

6. The dynamic scheduling method for industrial data acquisition tasks based on the Actor model according to claim 1, characterized in that, The method further includes: The system status of the Actor's runtime environment is collected in real time. The system status includes: the internal status of each Actor instance, the connection status of each connected Actor instance, and the execution status of the data acquisition tasks managed by the scheduler Actor corresponding to the data acquisition connection request. The system state is snapshotted and saved at predetermined intervals to generate snapshot data; When a system failure is detected, the system state of the Actor's runtime environment is restored from the most recently saved snapshot data.

7. The dynamic scheduling method for industrial data acquisition tasks based on the Actor model according to claim 1, characterized in that, The method further includes: Based on preset business rules, the Actor instances are divided into critical Actor instances and non-critical Actor instances; Obtain the available resources of the Actor's runtime environment, and generate a degradation decision instruction when the available resources are lower than a preset resource threshold; In response to the degradation decision instruction, the execution of the collection tasks associated with the non-critical Actor instance is suspended or restricted, while the normal execution of the collection tasks associated with the critical Actor instance is maintained.

8. A dynamic scheduling device for industrial data acquisition tasks based on the Actor model, characterized in that, include: The environment creation module is used to build the runtime environment of the Actor, and create a scheduler Actor, a connection management Actor, and a protocol processing Actor in the runtime environment of the Actor, as well as initialize a hierarchical time wheel timer; The instance creation module is used to respond to external data acquisition connection requests by dynamically creating an independent connection Actor instance for each data acquisition connection request through the connection management Actor. The data acquisition module is used to send a data acquisition command message to the corresponding connected Actor instance through the scheduler Actor based on the triggering of the hierarchical time wheel timer, so that the connected Actor instance responds to the data acquisition command message to perform data acquisition and obtain a data acquisition result message of the data acquisition result; The data conversion module is used to standardize the data collection results in the data collection result message by processing the protocol adaptation layer managed by the Actor through the protocol processing, and to obtain standardized data. The data output module is used to publish the standardized data to downstream systems to complete data scheduling.

9. A dynamic scheduling device for industrial data acquisition tasks based on the Actor model, characterized in that, include: One or more processors; A memory for storing one or more programs, which, when executed by one or more processors, cause the Actor-based industrial data acquisition task dynamic scheduling device to implement the steps of the Actor-based industrial data acquisition task dynamic scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the computer's processor, causes the computer to perform the steps of the dynamic scheduling method for industrial data acquisition tasks based on the Actor model as described in any one of claims 1 to 7.

Images