Dual-runtime engine collaboration method and system for industrial edge computing terminal

Abstract

The invention provides a dual-runtime engine collaboration method and system for an industrial edge computing terminal. Relates to the technical field of industrial edge computing. The method is applied to a system comprising a real-time runtime engine, a non-real-time runtime engine, a shared memory module and a resource monitoring module, and comprises the following steps: executing a real-time task and / or a non-real-time task, and performing data interaction between the real-time runtime engine and the non-real-time runtime engine through the shared memory module, periodically acquiring a resource use state of a hardware platform through a resource monitoring module, and dynamically adjusting available resources allocated to an engine during non-real-time operation according to the resource use state; and when the idle time window exists in the scheduling period of the real-time runtime engine, executing the non-real-time task in the idle time window through the non-real-time runtime engine. According to the invention, collaborative optimization of the system on the aspects of time certainty, flexible resource allocation and low-latency data exchange can be realized.

Description

Technical Field

[0001] This application relates to the field of industrial edge computing technology, and in particular to a dual-runtime engine collaborative method and system for an industrial edge computing terminal. Background Technology

[0002] In modern industrial scenarios, edge terminals not only need to execute real-time control tasks that are extremely sensitive to response time, but also need to handle a large number of non-real-time but computationally intensive data governance tasks. These two types of tasks have fundamental differences in time constraints, resource requirements and execution semantics, which makes the traditional task scheduling architecture increasingly show structural bottlenecks in dealing with the current industrial intelligent upgrading needs.

[0003] In related technologies, mainstream solutions mainly follow two paths: one is to use a single general-purpose operating system (such as Linux) to uniformly carry all tasks. However, this solution is difficult to avoid context switching jitter and scheduling latency accumulation when the system load is high. The other is to use a fixed partition heterogeneous architecture at the hardware level, which allocates independent computing resources to real-time and non-real-time tasks through physical isolation. However, this solution has problems such as poor overall system real-time performance, low resource utilization, and low efficiency. Therefore, there is an urgent need to build a collaborative runtime architecture and control method that can simultaneously meet the requirements of deterministic real-time control, high throughput of non-real-time tasks, dynamic resource adjustability, and low-latency interaction of dual-domain data. Summary of the Invention

[0004] This application provides a dual-runtime engine collaborative method and system for industrial edge computing terminals, which is used to achieve collaborative optimization of the system in terms of time determinism, elastic resource allocation and low-latency data exchange.

[0005] Firstly, this application provides a dual-runtime engine collaborative method for an industrial edge computing terminal, applied to a system including a real-time runtime engine, a non-real-time runtime engine, a shared memory module, and a resource monitoring module. The real-time runtime engine is used to execute real-time tasks with strict time constraints, and the non-real-time runtime engine is used to execute non-real-time tasks without strict time constraints. The method includes:

[0006] It executes real-time and / or non-real-time tasks and interacts with data between the real-time runtime engine and the non-real-time runtime engine through a shared memory module, wherein the shared memory module is a storage area in physical memory that can be accessed by both the real-time runtime engine and the non-real-time runtime engine.

[0007] The resource monitoring module periodically obtains the resource usage status of the hardware platform and dynamically adjusts the available resources allocated to the non-real-time runtime engine based on the resource usage status.

[0008] When there is an idle time window in the scheduling cycle of the real-time runtime engine, the non-real-time task is executed within the idle time window by the non-real-time runtime engine.

[0009] In one possible implementation, the method further includes the following before executing real-time and / or non-real-time tasks:

[0010] The priority of real-time tasks is determined according to the preset priority allocation rules. The priority includes ten discrete levels, with level one being the lowest and level ten being the highest.

[0011] Set the priority of non-real-time tasks to be lower than that of real-time tasks.

[0012] In one possible implementation, the priority of real-time tasks is determined according to a preset priority allocation rule, including:

[0013] When the execution cycle of a real-time task is less than the first time threshold and the execution time of a single task is less than the second time threshold, the priority of the real-time task is set to level eight to ten, and the real-time task is set as a core control task, wherein the first time threshold is greater than the second time threshold.

[0014] When the execution cycle of a real-time task is greater than the first time threshold and less than the third time threshold, and the execution time of a single execution is less than the first proportion of the execution cycle, the priority of the real-time task is determined to be level four to seven, and the real-time task is determined to be a normal control task. The third time threshold is greater than the first time threshold.

[0015] In one possible implementation, data interaction between the real-time runtime engine and the non-real-time runtime engine is achieved through a shared memory module, including:

[0016] When data interaction occurs in the real-time data area of ​​the shared memory module, before the first write operation is performed, the real-time runtime engine acquires a spinlock. After the first write operation is completed, the spinlock is released and a first readable semaphore is sent to the non-real-time runtime engine. After receiving the first readable semaphore, the non-real-time runtime engine performs the first read operation and returns a first read semaphore to the real-time runtime engine after the first read operation is completed.

[0017] When data interaction occurs in the non-real-time data area of ​​the shared memory module, before the second write operation is performed, the non-real-time runtime engine acquires a spinlock. After the second write operation is completed, the spinlock is released and a second readable semaphore is sent to the real-time runtime engine. After receiving the second readable semaphore, the real-time runtime engine performs the second read operation and returns the second read semaphore to the non-real-time runtime engine after the second read operation is completed.

[0018] In one possible implementation, a resource monitoring module periodically acquires the resource usage status of the hardware platform and dynamically adjusts the available resources allocated to the non-real-time runtime engine based on the resource usage status, including:

[0019] The resource monitoring module collects the CPU usage and physical memory usage of the engine during non-real-time operation at fixed time intervals.

[0020] When the CPU utilization rate exceeds the first resource threshold and / or the physical memory utilization rate exceeds the second resource threshold, a resource limit event is triggered. The resource limit event is used to reduce the priority of non-real-time tasks and shorten the time slice length of non-real-time tasks. The first resource threshold is the upper limit of CPU resources allocated to the non-real-time runtime engine, and the second resource threshold is the upper limit of physical memory allocated to the non-real-time runtime engine.

[0021] When the CPU utilization rate is less than the third resource threshold and / or the physical memory utilization rate is less than the fourth resource threshold, a resource release event is triggered. The resource release event is used to restore the priority and time slice length of non-real-time tasks.

[0022] In one possible implementation, when an idle time window exists within the scheduling cycle of the real-time runtime engine, a non-real-time task is executed within the idle time window by the non-real-time runtime engine, including:

[0023] Record the actual execution time of real-time tasks and determine the idle time window at the end of each scheduling cycle. The idle time window is the difference between the execution cycle of the real-time task and the actual execution time.

[0024] An idle resource notification signal is sent to the non-real-time runtime engine via a dedicated interrupt line. The idle resource notification signal is used to indicate the start time and duration of the idle time window.

[0025] When the engine receives an idle resource notification signal, it schedules and executes non-real-time tasks within the idle time window.

[0026] In one possible implementation, the method also includes:

[0027] When the real-time runtime engine detects a new high-priority real-time task or an increase in the priority of an existing real-time task, it triggers a resource quota reduction event through the resource monitoring module, reducing the CPU utilization limit of the non-real-time runtime engine from the first resource threshold to the fifth resource threshold, and / or reducing the physical memory utilization limit of the non-real-time runtime engine from the second resource threshold to the sixth resource threshold.

[0028] When the real-time runtime engine detects that a high-priority real-time task has terminated or been downgraded, it triggers a resource quota recovery event through the resource monitoring module. This restores the CPU utilization limit of the non-real-time runtime engine to the first resource threshold and the physical memory utilization limit of the non-real-time runtime engine to the second resource threshold.

[0029] Secondly, this application provides a dual-runtime engine collaborative system for an industrial edge computing terminal, comprising: a real-time runtime engine, a non-real-time runtime engine, a shared memory module, and a resource monitoring module, wherein...

[0030] The real-time runtime engine uses a hard real-time operating system kernel and is configured to schedule and execute real-time tasks with strict time constraints.

[0031] The non-real-time runtime engine uses a general-purpose operating system kernel and is configured to schedule and execute non-real-time tasks without strict time constraints;

[0032] The shared memory module is configured as a storage area in physical memory that can be accessed by both the real-time runtime engine and the non-real-time runtime engine, and is used to enable data interaction between the two.

[0033] The resource monitoring module is configured to monitor the resource usage status of the non-real-time runtime engine and dynamically adjust the available resources allocated to the non-real-time runtime engine based on the resource usage status.

[0034] In one possible implementation, the shared memory module includes a real-time data area and a non-real-time data area, which are two physically contiguous and non-overlapping independent storage areas.

[0035] The capacity of the real-time data area is greater than the first capacity threshold. It is organized using a ring buffer structure and is used to store at least one of the following: control commands written by the real-time runtime engine, device status snapshots, and alarm event records.

[0036] The capacity of the non-real-time data area is greater than the second capacity threshold. It is organized using a block storage structure and is used to store at least one of the following: cleaned data written by the non-real-time runtime engine, model inference results, and statistical intermediates.

[0037] In one possible implementation, the real-time runtime engine is deployed and runs exclusively on at least one physical core of the same multi-core processor, while the non-real-time runtime engine is deployed and runs on the remaining physical cores of the multi-core processor. The physical cores maintain data consistency of the shared memory module's storage area through an internal cache coherence protocol.

[0038] The physical address mapping of the shared memory module is completed by the system bootloader during the startup phase and is fixed in the page table entries of the memory management unit, so that the real-time runtime engine and the non-real-time runtime engine can directly access the storage area of ​​the shared memory module in either user mode or kernel mode.

[0039] The dual-runtime engine collaboration method and system for industrial edge computing terminals provided in this application fundamentally solves the dual contradictions of unreliable real-time performance in traditional single-operating system architecture and lack of resource elasticity in fixed-partition architecture by constructing dual-runtime engines with strict isolation and dynamic collaboration capabilities at the software level. Through the resource monitoring module to schedule available resources in real time and the shared memory module to achieve efficient memory sharing, it realizes collaborative optimization of two types of heterogeneous tasks in three dimensions: time determinism, elastic resource allocation, and low-latency data exchange. Attached Figure Description

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

[0041] Figure 1 A schematic diagram of the structure of a dual-runtime engine collaborative system for an industrial edge computing terminal provided in this application embodiment;

[0042] Figure 2 A flowchart illustrating a dual-runtime engine collaboration method for an industrial edge computing terminal provided in this application embodiment;

[0043] Figure 3 for Figure 2 A flowchart illustrating the specific implementation of step S202 in the illustrated embodiment;

[0044] Figure 4 for Figure 2 The flowchart illustrating the specific implementation method of step S203 in the embodiment shown is as follows;

[0045] Figure 5 This is a schematic diagram illustrating the structure and data interaction mechanism of a shared memory module provided in an embodiment of this application.

[0046] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0048] With the deep integration of the Industrial Internet and intelligent manufacturing, industrial edge computing terminals, as the core hub connecting physical devices and cloud intelligence, are facing unprecedented challenges in terms of task capacity. In modern industrial scenarios, edge terminals not only need to execute real-time control tasks that are extremely sensitive to response time—such as high-precision motion axis synchronization, emergency alarm linkage, and equipment logic control—which typically require end-to-end latency to be strictly controlled within ten milliseconds, but also need to handle a large number of non-real-time but computationally intensive data governance tasks, including multi-source sensor data cleaning, artificial intelligence model inference, and persistent storage of historical operating data. These two types of tasks differ fundamentally in terms of time constraints, resource requirements, and execution semantics, making traditional task scheduling architectures increasingly reveal structural bottlenecks in addressing the current demands of industrial intelligent upgrades.

[0049] In relevant technical practices, mainstream solutions mainly follow two paths: The first is to use a single general-purpose operating system (such as Linux) to uniformly handle all tasks. While this approach has advantages in terms of software ecosystem and development convenience, the Linux kernel itself lacks a hard real-time guarantee mechanism. Its task scheduling relies on soft interrupts and priority scheduling strategies, making it difficult to avoid context switching jitter and accumulated scheduling latency under high system load. Real-world test data shows that when the CPU utilization rate of non-real-time tasks exceeds 70%, the response latency of real-time tasks generally exceeds 50 milliseconds, far exceeding the 10-millisecond threshold required for high-precision manufacturing scenarios, thus causing equipment control malfunctions or even false alarms and shutdowns. The second approach is to adopt a fixed-partition heterogeneous architecture at the hardware level, allocating independent computing resources to real-time and non-real-time tasks through physical isolation. While such solutions alleviate the resource contention problem to some extent, they fall into a new predicament due to the lack of a dynamic coordination mechanism: when real-time tasks are in a low-load cycle (e.g., a 10-millisecond cycle task only takes 5 milliseconds), their reserved resources cannot be effectively reused by non-real-time tasks, resulting in idle computing power; conversely, when there is a sudden surge in high-priority real-time tasks, the resource quota is fixed and cannot be flexibly expanded, resulting in delayed execution of critical control instructions.

[0050] However, as industrial scenarios increasingly demand faster "control-sensing-decision" closed-loop timeliness, the inherent contradictions between the two architectures mentioned above at the fundamental level become more pronounced. At its core, the problem doesn't stem simply from insufficient operating system selection or hardware configuration, but from the failure to construct a runtime abstraction layer that can both strictly guarantee real-time boundaries and achieve dynamic resource coordination. Specifically, a single operating system architecture essentially forces heterogeneous tasks into a homogeneous scheduling framework, ignoring the rigid requirement of real-time tasks for deterministic execution windows; while a fixed partition architecture overemphasizes isolation, sacrificing the overall system's resource elasticity and coordination efficiency. Furthermore, neither solution addresses the underlying mechanism for efficient data interaction between dual-domain tasks. Existing implementations often rely on network sockets or file systems for cross-domain communication, introducing protocol overhead and input / output (I / O) latency often exceeding 200 milliseconds, severely restricting the "sensing and responding" closed-loop capability at the edge. Against this backdrop, industry statistics show that approximately 30% of industrial edge terminals experience false alarms exceeding 15% due to improper scheduling strategies. This issue has become a key obstacle to stable production line operation and energy efficiency improvement, especially in scenarios highly sensitive to timing consistency, such as semiconductor manufacturing, precision assembly, and smart warehousing.

[0051] Therefore, how to construct a collaborative runtime architecture and scheduling method that can simultaneously meet the requirements of hard real-time control determinism, high throughput of non-real-time tasks, dynamic resource adjustability, and low-latency interaction of dual-domain data without increasing hardware costs has become a core technical challenge that needs to be overcome by those skilled in the art.

[0052] Based on this, this application provides a dual-runtime engine collaborative method and system for industrial edge computing terminals. By constructing dual-runtime engines with strict isolation and dynamic collaborative capabilities at the software level, it fundamentally solves the dual contradictions of the inability to guarantee real-time performance in traditional single operating system architecture and the lack of resource elasticity in fixed partition architecture. Through the resource monitoring module to schedule available resources in real time and through the shared memory module to achieve efficient memory sharing, it realizes collaborative optimization of two types of heterogeneous tasks in three dimensions: time determinism, resource elastic allocation, and low-latency data exchange.

[0053] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0054] Figure 1 This is a schematic diagram of the structure of a dual-runtime engine collaborative system for an industrial edge computing terminal provided in an embodiment of this application. Figure 1 As shown, the system includes: a real-time runtime engine, a non-real-time runtime engine, a shared memory module, and a resource monitoring module.

[0055] The system is deployed on the same industrial edge computing terminal device. This terminal device uses a multi-core processor as the central processing unit, with at least two physical CPU cores, no less than sixteen megabytes of physical memory, and an on-chip interconnect architecture that supports cache coherency protocols.

[0056] The real-time runtime engine uses a hard real-time operating system kernel and is configured to schedule and execute real-time tasks with strict time constraints. The non-real-time runtime engine uses a general-purpose operating system kernel and is configured to schedule and execute non-real-time tasks without strict time constraints. The shared memory module is configured as a storage area in physical memory that can be accessed by both the real-time and non-real-time runtime engines, used to enable data interaction between the two. The resource monitoring module is configured to monitor the resource usage status of the non-real-time runtime engine and dynamically adjust the available resources allocated to the non-real-time runtime engine based on the resource usage status.

[0057] The real-time runtime engine is built on a hard real-time operating system kernel, such as the FreeReal-Time Operating System (FreeRTOS) or the Real-Time Thread (RT-Thread) operating system. This engine is specifically designed to handle industrial control tasks with strict time constraints, i.e., real-time tasks. Examples of real-time tasks include high-precision motion axis synchronization control, emergency alarm linkage logic execution, and equipment status closed-loop feedback control. These tasks require a response within a defined time window; otherwise, equipment malfunction or production accidents may occur.

[0058] The non-real-time runtime engine is built on a general-purpose operating system kernel, such as Linux distributions like Ubuntu and Debian. This engine is used to execute computationally intensive data processing tasks without strict time constraints, i.e., non-real-time tasks. Examples of non-real-time tasks include cleaning raw data from multiple sensors, inference operations for artificial intelligence models, and persistent storage of historical runtime data.

[0059] The shared memory module is a key data channel connecting the real-time runtime engine and the non-real-time runtime engine. This module consists of two independent regions that are continuously divided in physical memory: the real-time data area and the non-real-time data area.

[0060] The real-time data area has a capacity greater than the first capacity threshold and is organized using a ring buffer structure. It is used to store at least one of the following: control commands written by the real-time runtime engine, device status snapshots, and alarm event records. The non-real-time data area has a capacity greater than the second capacity threshold and is organized using a block storage structure. It is used to store at least one of the following: cleaned data written by the non-real-time runtime engine, model inference results, and statistical intermediates.

[0061] The first capacity threshold is, for example, one megabyte, meaning the real-time data area capacity is no less than one megabyte, supporting a first-in-first-out (FIFO) read / write operation mode. This area is used to store control commands generated by the real-time runtime engine, device operating status snapshots, and alarm event records.

[0062] The second capacity threshold, for example, is eight megabytes, meaning the non-real-time data area must be at least eight megabytes in size. This area is used to store cleaned data processed by the non-real-time runtime engine, the output results of artificial intelligence model inference, and intermediate products of statistical analysis. The two data areas do not overlap in their physical address spaces and each has its own independent access control bits to prevent unauthorized out-of-bounds access.

[0063] The resource monitoring module resides at the system's lowest level as a kernel-mode driver. Its main function is to periodically collect resource usage data, such as CPU utilization and physical memory utilization. The sampling period is, for example, one millisecond.

[0064] Furthermore, the resource monitoring module also includes a scheduler. The scheduler dynamically adjusts the available resources allocated to the non-real-time runtime engine based on resource usage. For example, when the CPU utilization of the non-real-time runtime engine exceeds 50% or the physical memory utilization exceeds 60%, the resource monitoring module triggers a resource limit event. This event notifies the scheduler of the non-real-time runtime engine via an interrupt. The scheduler then lowers the scheduling priority of all non-real-time tasks and reduces their time slice length from the default value of ten milliseconds to five milliseconds. Conversely, when the CPU utilization of the non-real-time runtime engine is below 30% and the physical memory utilization is below 40%, the resource monitoring module triggers a resource release event, and the scheduler restores the original priority and time slice length of the non-real-time tasks. This dynamic adjustment mechanism ensures that real-time tasks always receive sufficient computing resources when the system load fluctuates.

[0065] Optionally, the real-time runtime engine and the non-real-time runtime engine run on different physical cores of the same multi-core processor. Specifically, the real-time runtime engine occupies one or more physical cores, while the non-real-time runtime engine runs on the remaining physical cores. Data consistency in the shared memory module's storage area is maintained between cores through an internal processor cache coherency protocol, avoiding additional latency introduced by explicit refresh operations. This deployment method achieves physical isolation of computing resources at the hardware level, fundamentally preventing non-real-time tasks from interfering with the execution path of real-time tasks.

[0066] Optionally, the physical address mapping of the shared memory module is completed by the system bootloader during the startup phase. The mapping relationship is persisted in the page table entries of the memory management unit, ensuring that both runtime engines can directly access the storage area of ​​the shared memory module in either user mode or kernel mode, without needing virtual memory translation or system call proxies. This design significantly reduces the software overhead of data interaction, keeping the data transfer latency between the two engines stably controlled at the sub-millisecond level.

[0067] The dual-runtime engine collaborative system for industrial edge computing terminals provided in this application embodiment, by setting a real-time runtime engine with a hard real-time operating system kernel, can ensure deterministic scheduling and execution of real-time tasks with strict time constraints, effectively avoiding interference from non-real-time tasks on the execution process of real-time tasks; the non-real-time runtime engine with a general-purpose operating system kernel can efficiently carry out computationally intensive non-real-time data processing tasks, taking into account the system's ability to handle diverse tasks; the configured shared memory module, by dividing independent storage areas and cooperating with corresponding data access control mechanisms, realizes efficient data interaction between the two engines, significantly reducing the latency and overhead of cross-engine data transmission; the resource monitoring module can perceive the resource usage status of the non-real-time runtime engine in real time, and dynamically adjust its resource quota accordingly, realizing the elastic allocation and efficient utilization of system computing resources, solving the problems of insufficient real-time performance, severe resource conflicts, high latency of dual-domain data interaction, and low resource utilization in traditional architectures, and improving the overall operational reliability and task processing efficiency of industrial edge computing terminals.

[0068] Figure 2 This is a flowchart illustrating a dual-runtime engine collaboration method for an industrial edge computing terminal provided in an embodiment of this application. Figure 2 As shown, the method includes:

[0069] S201, Execute real-time tasks and / or non-real-time tasks, and exchange data between the real-time runtime engine and the non-real-time runtime engine through the shared memory module.

[0070] The shared memory module is a storage area in physical memory that can be accessed by both the real-time runtime engine and the non-real-time runtime engine.

[0071] Real-time tasks are executed by the real-time runtime engine, while non-real-time tasks are executed by the non-real-time runtime engine. Data interaction between the real-time and non-real-time runtime engines occurs through a shared memory module; that is, data required for task execution is read from or written to the shared memory module during the execution of either a real-time or non-real-time task. For example, during the execution of a real-time task, control commands generated by the real-time runtime engine, device operating status snapshots, and alarm event records can be written to the real-time data area of ​​the shared memory module. Similarly, during the execution of a non-real-time task, cleaned data processed by the non-real-time runtime engine, AI model inference outputs, and statistical analysis intermediates can be written to the non-real-time data area of ​​the shared memory module.

[0072] Optionally, before executing real-time tasks and / or non-real-time tasks, the method further includes: determining the priority of real-time tasks according to a preset priority allocation rule, wherein the priority includes ten discrete levels, with level one being the lowest and level ten being the highest; and setting the priority of non-real-time tasks to be lower than the priority of real-time tasks.

[0073] The real-time runtime engine employs a priority-based preemptive scheduling strategy, which prioritizes allocating resources and executing high-priority real-time tasks. Therefore, all real-time tasks are assigned a fixed priority value upon creation based on preset priority allocation rules, and this value cannot be changed during the task's lifecycle.

[0074] For example, the priority of a real-time task is determined according to a preset priority allocation rule, including: when the execution cycle of a real-time task is less than a first time threshold and the execution time of a single execution is less than a second time threshold, the priority of the real-time task is determined to be level eight to ten, and the real-time task is determined to be a core control task, wherein the first time threshold is greater than the second time threshold; when the execution cycle of a real-time task is greater than the first time threshold and less than a third time threshold, and the execution time of a single execution is less than a first proportion of the execution cycle, the priority of the real-time task is determined to be level four to seven, and the real-time task is determined to be a normal control task, wherein the third time threshold is greater than the first time threshold.

[0075] The first time threshold is, for example, ten milliseconds, and the second time threshold is, for example, five milliseconds. That is, tasks with priority values ​​of eight to ten are defined as core control tasks, whose execution cycle can be configured to be within ten milliseconds, and the execution time of a single execution does not exceed five milliseconds.

[0076] The third time threshold is, for example, 100 milliseconds, and the first proportion is, for example, 50%. That is, tasks with priority values ​​of four to seven are defined as ordinary control tasks, whose execution cycle can be configured to be ten to one hundred milliseconds, and the execution time of a single execution does not exceed 50% of the corresponding cycle. At the beginning of each scheduling cycle, the scheduler of the real-time runtime engine selects the next task to be executed based on the task priority and readiness status, and ensures that high-priority tasks can immediately preempt the execution rights of low-priority tasks.

[0077] Furthermore, the non-real-time runtime engine also includes a scheduler, which by default sets the scheduling priority of all user-mode tasks (i.e., non-real-time tasks) to a lower level than the scheduling level of the lowest priority task in the real-time runtime engine. This means that at any given time, as long as there is a real-time task in a ready state, no non-real-time task can obtain CPU execution rights.

[0078] The aforementioned technical solution achieves refined priority division of real-time tasks by pre-setting real-time task priority allocation rules with ten discrete levels. This enables precise identification of core control tasks with stringent timeliness requirements and assigns them high priority, ensuring that core control tasks are prioritized for scheduling and execution, thus meeting the rigid timeliness requirements of critical tasks in industrial control scenarios. By setting the priority of non-real-time tasks to be lower than that of all real-time tasks, the scheduling mechanism completely eliminates the preemption and interference of non-real-time tasks on the execution process of real-time tasks, ensuring the time determinism of all real-time task execution and avoiding control inaccuracies caused by task preemption. By using quantified cycle and time consumption indicators as the basis for priority allocation, the priority allocation rules are standardized and operable, facilitating unified scheduling and management of the system, improving the stability and reliability of the dual-runtime engine collaborative scheduling strategy, and thereby optimizing the overall operating performance of industrial edge computing terminals.

[0079] S202. The resource monitoring module periodically obtains the resource usage status of the hardware platform and dynamically adjusts the available resources allocated to the non-real-time runtime engine according to the resource usage status.

[0080] Resource usage status, such as CPU utilization and physical memory utilization, is retrieved at a frequency of once per millisecond.

[0081] For example, see Figure 3 , Figure 3 for Figure 2 The flowchart illustrating the specific implementation of step S202 in the illustrated embodiment shows that the method includes:

[0082] S2021. The resource monitoring module collects the CPU usage and physical memory usage of the non-real-time running engine at fixed time intervals.

[0083] S2022. Determine whether the CPU utilization rate is greater than the first resource threshold and / or whether the physical memory utilization rate is greater than the second resource threshold.

[0084] When the CPU utilization rate is greater than the first resource threshold and / or the physical memory utilization rate exceeds the second resource threshold, proceed to step S2023; otherwise, proceed to steps S2024 to S2025.

[0085] S2023, triggers a resource constraint event, reduces the priority of non-real-time tasks, and shortens the time slice length of non-real-time tasks.

[0086] S2024. Determine whether the CPU utilization rate is less than the third resource threshold and / or whether the physical memory utilization rate is greater than the fourth resource threshold.

[0087] If the CPU utilization rate is less than the third resource threshold and / or the physical memory utilization rate is less than the fourth resource threshold, proceed to step S2025; otherwise, terminate the task.

[0088] S2025, Triggering a resource release event restores the priority and time slice length of non-real-time tasks.

[0089] Among them, the first to fourth resource thresholds are pre-set thresholds that can be dynamically adjusted according to actual needs. The size of each threshold can be different or the same. Each resource threshold is determined based on the total system resources and is in percentage form. That is, the resource threshold is a certain percentage of the total system resources, that is, a certain percentage of the total available central processing unit resources or a certain percentage of the total available physical memory of the system, which will be abbreviated as percentage below.

[0090] The first resource threshold is, for example, 50%, and the second resource threshold is, for example, 60%. That is, when the CPU utilization of the non-real-time runtime engine exceeds 50% or the physical memory utilization exceeds 60%, the resource monitoring module triggers a resource limit event. This event notifies the scheduler of the non-real-time runtime engine via an interrupt. The scheduler then lowers the scheduling priority of all non-real-time tasks and shortens their time slice length, for example, from 10 milliseconds to 5 milliseconds.

[0091] The third resource threshold is, for example, 30%, and the fourth resource threshold is, for example, 40%. That is, when the CPU utilization of the non-real-time runtime engine is lower than 30% and the physical memory utilization is lower than 40%, the resource monitoring module triggers a resource release event, and the scheduler restores the original priority and time slice length of the non-real-time task.

[0092] In the above method, the core resource usage status of the engine during non-real-time operation is periodically collected by the resource monitoring module. When the resource usage exceeds the threshold, a limiting operation is triggered to suppress the excessive use of system resources by non-real-time tasks and prevent them from interfering with the deterministic execution of real-time tasks. When the resource usage falls back below the threshold, a release operation is triggered to restore the scheduling parameters of non-real-time tasks and ensure the processing efficiency of non-real-time tasks. Ultimately, the elastic regulation and dynamic balance of system resources are achieved, improving the overall operational reliability and resource utilization of industrial edge computing terminals.

[0093] S203. When there is an idle time window in the scheduling cycle of the real-time runtime engine, the non-real-time task is executed in the idle time window by the non-real-time runtime engine.

[0094] The idle time window is the difference between the execution cycle and the actual execution time. For example, if the execution cycle of a periodic task is ten milliseconds but the actual execution time is only five milliseconds, then the task generates a five-millisecond idle time window within that cycle.

[0095] For example, see Figure 4 , Figure 4 for Figure 2 The flowchart illustrating the specific implementation of step S203 in the illustrated embodiment shows that the method includes:

[0096] S2031. Record the actual execution time of real-time tasks.

[0097] S2032. Determine if an idle time window exists.

[0098] If the real-time execution time is less than the execution cycle, it indicates that there is an idle time window; otherwise, there is no idle time window.

[0099] If an idle time window exists, continue with step S2033 and subsequent steps; otherwise, terminate the task.

[0100] S2033, Determine the idle time window.

[0101] The idle time window can be determined by the difference between the execution cycle and the actual execution time.

[0102] S2034, Send an idle resource notification signal to the non-real-time runtime engine.

[0103] The idle resource notification signal is used to indicate the start time and duration of the idle time window.

[0104] S2035, Receive idle resource notification signals through the non-real-time runtime engine.

[0105] S2036, Non-real-time tasks are scheduled and executed within the idle time window through the non-real-time runtime engine.

[0106] The execution time of non-real-time tasks is strictly limited to the idle time window, and no system calls that may block are allowed to be requested, so as to ensure that the timely start of real-time tasks in the next cycle will not be affected.

[0107] In the above method, the idle time window is determined by calculating the difference between the execution cycle of the real-time task and the actual time consumed. The non-real-time running engine schedules and executes non-real-time tasks within the idle time window. On the one hand, this achieves efficient reuse of the idle computing power of the real-time engine, improves the overall resource utilization of the system, and avoids idle computing power. On the other hand, it strictly limits the execution period of non-real-time tasks, eliminates their interference with the deterministic execution process of real-time tasks, ensures the timeliness requirements of key tasks in industrial control scenarios, and ultimately achieves efficient collaborative operation of the two engines.

[0108] The dual-runtime engine collaboration method for industrial edge computing terminals provided in this application realizes data interaction between the two runtime engines through a shared memory module, significantly reducing the latency and protocol overhead of cross-engine data transmission and ensuring the efficiency and reliability of data interaction. By dynamically adjusting the resource quota of non-real-time runtime engines through a resource monitoring module, the rigid resource requirements of real-time tasks can be prioritized, avoiding interference from non-real-time tasks on the execution process of real-time tasks and ensuring the deterministic execution of real-time tasks. By reusing the idle time window of the real-time runtime engine to execute non-real-time tasks, the efficient utilization of system computing power is achieved, improving the overall operating performance of the industrial edge computing terminal. Without increasing hardware costs, the system achieves collaborative optimization in terms of time determinism, elastic resource allocation, and low-latency data exchange.

[0109] Optional, see Figure 5 , Figure 5 This is a schematic diagram illustrating the structure and data interaction mechanism of a shared memory module provided in an embodiment of this application.

[0110] The shared memory module includes a real-time data area and a non-real-time data area. When interacting with the real-time data area, the real-time runtime engine writes data to it, and the non-real-time runtime engine reads data from it. Similarly, when interacting with the non-real-time data area, the non-real-time runtime engine writes data to it, and the real-time runtime engine reads data from it.

[0111] Optionally, data interaction also includes a mutex and synchronization semaphore mechanism, including: when interacting with data in the real-time data area of ​​the shared memory module, before executing the first write operation, the real-time runtime engine acquires a spinlock, releases the spinlock after the first write operation is completed, and sends a first readable semaphore to the non-real-time runtime engine. After receiving the first readable semaphore, the non-real-time runtime engine executes the first read operation and returns a first read semaphore to the real-time runtime engine after the first read operation is completed; when interacting with data in the non-real-time data area of ​​the shared memory module, before executing the second write operation, the non-real-time runtime engine acquires a spinlock, releases the spinlock after the second write operation is completed, and sends a second readable semaphore to the real-time runtime engine. After receiving the second readable semaphore, the real-time runtime engine executes the second read operation and returns a second read semaphore to the non-real-time runtime engine after the second read operation is completed.

[0112] The first write operation is when the real-time runtime engine writes data to the real-time data area. The first readable semaphore is used to indicate that the first write operation has been completed. The first read operation is when the non-real-time runtime engine reads data from the real-time data area. The first read semaphore is used to indicate that the first read operation has been completed, that is, the data has been consumed.

[0113] The second write operation is when the non-real-time runtime engine writes data to the non-real-time data area. The second readable semaphore is used to indicate that the second write operation has been completed. The second read operation is when the real-time runtime engine reads data from the non-real-time data area. The second read semaphore is used to indicate that the second read operation has been completed, that is, the data has been consumed.

[0114] The holding time of the spinlock shall not exceed a preset threshold, such as one millisecond, in order to avoid blocking other high-priority real-time tasks.

[0115] In the above method, the atomicity of the writing process is ensured by controlling the data writing operation through spinlocks, avoiding data conflict caused by concurrent access of the two engines; the sequentiality of data interaction is achieved through bidirectional synchronous interaction between readable and read semaphores, effectively improving the reliability and efficiency of data interaction between the two engines and reducing the latency overhead of cross-engine data transmission.

[0116] Optionally, the method further includes: when the real-time runtime engine detects a new high-priority real-time task or an upgrade in the priority of an existing real-time task, triggering a resource quota reduction event through the resource monitoring module to lower the CPU utilization limit of the non-real-time runtime engine from the first resource threshold to the fifth resource threshold, and / or lowering the physical memory utilization limit of the non-real-time runtime engine from the second resource threshold to the sixth resource threshold; when the real-time runtime engine detects that a high-priority real-time task has terminated or been downgraded, triggering a resource quota recovery event through the resource monitoring module to restore the CPU utilization limit of the non-real-time runtime engine to the first resource threshold, and restore the physical memory utilization limit of the non-real-time runtime engine to the second resource threshold.

[0117] The fifth resource threshold is less than the first resource threshold; for example, the fifth resource threshold is 30%. The sixth resource threshold is less than the second resource threshold; for example, the sixth resource threshold is 40%. That is, when the real-time runtime engine detects a new high-priority task or an existing task's priority being increased, its scheduler immediately reports the task load change event to the resource monitoring module. Based on this, the resource monitoring module dynamically lowers the resource quota limit of the non-real-time runtime engine, reducing the CPU utilization limit from 50% to 30%, or the physical memory utilization limit from 60% to 40%. Conversely, when the real-time runtime engine detects a high-priority task terminating or being downgraded in priority, the resource monitoring module correspondingly raises the resource quota limit of the non-real-time runtime engine, restoring its original resource usage capacity.

[0118] In the above method, the real-time runtime engine senses the load changes of high-priority tasks, and the resource monitoring module dynamically adjusts the upper limit of the resource quota of the non-real-time runtime engine. On the one hand, it prioritizes the rigid resource requirements of high-priority real-time tasks, avoids the execution delay of real-time tasks caused by non-real-time tasks preempting resources, and ensures the deterministic execution of critical control tasks. On the other hand, it restores the resource quota of the non-real-time runtime engine in a timely manner when the load of high-priority real-time tasks decreases, effectively improving the overall resource utilization of the system and realizing the efficient collaboration of the two engines.

[0119] In one specific embodiment, the dual-runtime engine collaborative system of the industrial edge computing terminal provided in this application is deployed on an industrial edge computing terminal equipped with a quad-core ARM Cortex-A72 processor and 16GB of Double Data Rate Fourth Generation (DDR4) memory. The real-time runtime engine runs on Core0, using the RT-Thread 5.0 kernel; the non-real-time runtime engines run on Core1 to Core3, using the Ubuntu 22.04 Long-Term Support (LTS) operating system. The shared memory module is divided within the physical memory address range of 0x80000000 to 0x80900000, where 0x80000000 to 0x80100000 is the real-time data area (one megabyte), and 0x80100000 to 0x80900000 is the non-real-time data area (eight megabytes). The resource monitoring module samples the system resource status every millisecond and sends resource adjustment events to the non-real-time runtime engine through the Generic Interrupt Controller version 3 (GICv3).

[0120] To verify the technical effectiveness of this application, the following comparative test was conducted. The comparative test used a traditional single Linux kernel architecture, implementing soft real-time capabilities through preemptible real-time patches (PREEMPT_RT), and using control groups (cgroups) for resource partitioning. The test scenario simulated an assembly line with twenty servo motors, each requiring a 10-millisecond cycle to receive synchronous control commands, while simultaneously generating 5,000 sensor data points per second for an artificial intelligence model to detect anomalies. Table 1 shows the comparison results between the embodiment of this application and the comparative test on key performance indicators:

[0121]

[0122] Test data shows that the method in this application exhibits high stability in real-time task response latency, with a standard deviation of only 0.3 milliseconds, far superior to the comparative method's 3.8 milliseconds. Non-real-time task CPU utilization is effectively controlled below 50%, while the comparative method, lacking a dynamic resource adjustment mechanism, frequently exceeds the preset upper limit for CPU utilization. Data interaction latency between the two engines is consistently below 50 milliseconds in this invention, while the comparative method, relying on virtual file systems or network sockets for inter-process communication, suffers from significantly increased latency. Overall system resource utilization is improved to over 90%, demonstrating the effectiveness of the idle cycle reuse mechanism. The significant reduction in device fault false alarm rate reflects the positive impact of high-fidelity transmission of control commands and status feedback on system reliability.

[0123] In another embodiment, the invention is applied to the edge control system of a wind turbine generator. During real-time operation, the engine is responsible for pitch angle adjustment and yaw control, with an execution cycle of five milliseconds; during non-real-time operation, the engine is responsible for vibration signal analysis and power prediction model inference. In the shared memory module, the real-time data area is used to transmit current wind speed, generator speed, and control commands, while the non-real-time data area is used to transmit predicted power curves and health status assessment results. The resource monitoring module dynamically adjusts the resource quotas for non-real-time tasks based on the urgency of grid dispatch commands. During a 30-day field operation, the system did not experience any control timeout events due to resource contention, and the average data interaction latency was 28 milliseconds, fully verifying the engineering applicability of the invention in complex industrial scenarios.

[0124] In summary, this application achieves a deep integration of hard real-time control and high-throughput data processing on a single hardware platform by constructing a dual-runtime engine architecture and utilizing dynamic resource scheduling, efficient shared memory interaction, idle cycle reuse, and adaptive load adjustment. This solution not only meets the stringent time determinism requirements of industrial automation but also fully leverages the parallel computing capabilities of modern multi-core processors, providing a highly reliable, efficient, and low-cost software runtime solution for industrial edge computing terminals.

[0125] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A dual-runtime engine collaborative method for an industrial edge computing terminal, characterized in that, The method is applied to a system comprising a real-time runtime engine, a non-real-time runtime engine, a shared memory module, and a resource monitoring module. The real-time runtime engine is used to execute real-time tasks with strict time constraints, and the non-real-time runtime engine is used to execute non-real-time tasks without strict time constraints. The method includes: The real-time task and / or the non-real-time task are executed, and data interaction is performed between the real-time runtime engine and the non-real-time runtime engine through the shared memory module, wherein the shared memory module is a storage area in physical memory that can be accessed by both the real-time runtime engine and the non-real-time runtime engine. The resource monitoring module periodically acquires the resource usage status of the hardware platform and dynamically adjusts the available resources allocated to the non-real-time runtime engine based on the resource usage status. When there is an idle time window in the scheduling cycle of the real-time runtime engine, the non-real-time task is executed by the non-real-time runtime engine within the idle time window.

2. The method according to claim 1, characterized in that, Before executing the real-time task and / or the non-real-time task, the method further includes: The priority of the real-time task is determined according to the preset priority allocation rules, wherein the priority includes ten discrete levels, with level one being the lowest and level ten being the highest. Set the priority of the non-real-time task to be lower than that of the real-time task.

3. The method according to claim 2, characterized in that, Determining the priority of the real-time task according to a preset priority allocation rule includes: When the execution cycle of the real-time task is less than the first time threshold and the execution time of a single execution is less than the second time threshold, the priority of the real-time task is determined to be level eight to ten, and the real-time task is determined to be a core control task, wherein the first time threshold is greater than the second time threshold. When the execution cycle of the real-time task is greater than the first time threshold and less than the third time threshold, and the execution time of a single execution is less than a first proportion of the execution cycle, the priority of the real-time task is determined to be level four to seven, and the real-time task is determined to be a normal control task, wherein the third time threshold is greater than the first time threshold.

4. The method according to claim 1, characterized in that, The data interaction between the real-time runtime engine and the non-real-time runtime engine via the shared memory module includes: When data interaction occurs in the real-time data area of ​​the shared memory module, before the first write operation is performed, the real-time runtime engine acquires a spinlock. After the first write operation is completed, the spinlock is released, and a first readable semaphore is sent to the non-real-time runtime engine. After receiving the first readable semaphore, the non-real-time runtime engine performs a first read operation and returns a first read semaphore to the real-time runtime engine after the first read operation is completed. When data interaction occurs in the non-real-time data area of ​​the shared memory module, before the second write operation is performed, the non-real-time runtime engine acquires the spinlock. After the second write operation is completed, the spinlock is released, and a second readable semaphore is sent to the real-time runtime engine. After receiving the second readable semaphore, the real-time runtime engine performs the second read operation and returns a second read semaphore to the non-real-time runtime engine after the second read operation is completed.

5. The method according to claim 1, characterized in that, The step of periodically acquiring the resource usage status of the hardware platform through the resource monitoring module and dynamically adjusting the available resources allocated to the non-real-time runtime engine based on the resource usage status includes: The resource monitoring module collects the CPU usage and physical memory usage of the non-real-time runtime engine at fixed time intervals. When the CPU utilization rate is greater than a first resource threshold and / or the physical memory utilization rate exceeds a second resource threshold, a resource limit event is triggered. The resource limit event is used to reduce the priority of the non-real-time task and shorten the time slice length of the non-real-time task. The first resource threshold is the upper limit of CPU resources allocated to the non-real-time runtime engine, and the second resource threshold is the upper limit of physical memory allocated to the non-real-time runtime engine. When the CPU utilization rate is less than the third resource threshold and / or the physical memory utilization rate is less than the fourth resource threshold, a resource release event is triggered. The resource release event is used to restore the priority and time slice length of the non-real-time task.

6. The method according to claim 1, characterized in that, When an idle time window exists within the scheduling cycle of the real-time runtime engine, the non-real-time task is executed by the non-real-time runtime engine within the idle time window, including: The actual execution time of the real-time task is recorded, and the idle time window is determined at the end of each scheduling cycle. The idle time window is the difference between the execution cycle of the real-time task and the actual execution time. An idle resource notification signal is sent to the non-real-time runtime engine via a dedicated interrupt line. The idle resource notification signal is used to indicate the start time and duration of the idle time window. Upon receiving the idle resource notification signal, the non-real-time runtime engine schedules and executes non-real-time tasks within the idle time window.

7. The method according to claim 5, characterized in that, The method further includes: When the real-time runtime engine detects a new high-priority real-time task or an increase in the priority of an existing real-time task, it triggers a resource quota reduction event through the resource monitoring module, reducing the upper limit of the CPU utilization rate of the non-real-time runtime engine from the first resource threshold to the fifth resource threshold, and / or reducing the upper limit of the physical memory utilization rate of the non-real-time runtime engine from the second resource threshold to the sixth resource threshold. When the real-time runtime engine detects that a high-priority real-time task has terminated or been downgraded, it triggers a resource quota recovery event through the resource monitoring module to restore the CPU utilization limit of the non-real-time runtime engine to the first resource threshold and the physical memory utilization limit of the non-real-time runtime engine to the second resource threshold.

8. A dual-runtime engine collaborative system for an industrial edge computing terminal, characterized in that, include: The system comprises a real-time runtime engine, a non-real-time runtime engine, a shared memory module, and a resource monitoring module. The real-time runtime engine uses a hard real-time operating system kernel and is configured to schedule and execute real-time tasks with strict time constraints. The non-real-time runtime engine uses a general-purpose operating system kernel and is configured to schedule and execute non-real-time tasks without strict time constraints. The shared memory module is configured as a storage area in physical memory that can be accessed by both the real-time runtime engine and the non-real-time runtime engine, for the purpose of enabling data interaction between the two. The resource monitoring module is configured to monitor the resource usage status of the non-real-time runtime engine and dynamically adjust the available resources allocated to the non-real-time runtime engine based on the resource usage status.

9. The system according to claim 8, characterized in that, The shared memory module includes a real-time data area and a non-real-time data area, which are two physically contiguous and non-overlapping independent storage areas. The capacity of the real-time data area is greater than the first capacity threshold, and it is organized in a ring buffer structure to store at least one of the following: control instructions written by the real-time runtime engine, device status snapshots, and alarm event records. The capacity of the non-real-time data area is greater than the second capacity threshold, and it is organized using a block storage structure to store at least one of the following: cleaned data written by the non-real-time runtime engine, model inference results, and statistical intermediates.

10. The system according to claim 8, characterized in that, The real-time runtime engine is deployed and runs exclusively on at least one physical core of the same multi-core processor, and the non-real-time runtime engine is deployed and runs on the remaining physical cores of the multi-core processor. The physical cores maintain data consistency of the storage area of ​​the shared memory module through an internal cache coherence protocol. The physical address mapping of the shared memory module is completed by the system bootloader during the startup phase and is fixed in the page table entry of the memory management unit, so that both the real-time runtime engine and the non-real-time runtime engine can directly access the storage area of ​​the shared memory module in user mode or kernel mode.

Images