Method for improving data acquisition / writing stability

Abstract

The invention discloses a method for improving data acquisition / writing stability, and relates to the technical field of industrial control systems. The method comprises the following steps: firstly, deploying a real-time operating system kernel on general computing hardware, and carrying out real-time transformation on a hardware interface driving program of the real-time operating system kernel so as to lay a deterministic response foundation; secondly, real-time adaptation is carried out on an engine when the container runs, so that the engine has the capability of calling a kernel real-time interface; meanwhile, a non-real-time data acquisition / write-in program is packaged in a standard container mirror image. And finally, through the adapted container runtime engine, creating and running the container instances on the real-time kernel, thereby ensuring the deterministic execution of key real-time tasks on a unified hardware platform, and flexibly deploying non-real-time tasks through a containerization technology to achieve the comprehensive target of efficient utilization of resources and performance isolation.

Description

Technical Field

[0001] This invention relates to the field of industrial control system technology, and in particular to a method for improving the stability of data acquisition / writing. Background Technology

[0002] In the industrial and industrial IoT fields, the stability of data acquisition and writing processes is a core prerequisite for ensuring the accuracy of production system control and operational safety. For the prevalent medium-level real-time requirements, existing technological paradigms face significant challenges in general-purpose computing environments: on the one hand, while solutions relying on excessive hardware resource provision are widely adopted, they struggle to provide reliable performance guarantees under high system loads and are accompanied by serious resource utilization efficiency issues; on the other hand, strategies that reduce data interaction frequency in exchange for stability inevitably compromise system responsiveness and overall production efficiency. Therefore, under non-full real-time constraints, how to construct a read / write task execution environment that combines cost-effectiveness, resource efficiency, and deterministic performance has become a key and unresolved technical challenge in this field.

[0003] Currently, the industry has developed several typical technical paths to address different levels of real-time requirements: For scenarios with extreme latency sensitivity, a full real-time solution is adopted. This solution integrates dedicated hardware, a real-time operating system, and customized applications to form a tightly coupled closed system. While it can provide extremely high performance determinism, it suffers from inherent defects such as system rigidity, high cost, and closed ecosystem. For general real-time requirements, resource redundancy solutions are commonly used. These solutions attempt to isolate real-time tasks by configuring hardware computing resources far exceeding actual needs. While this method can run under light system loads, it inevitably leads to resource idleness and cannot provide bounded latency guarantees under heavy system loads, resulting in significant stability risks. Performance throttling solutions serve as a compromise, maintaining basic system stability by actively reducing the frequency of data interaction, but in reality, it sacrifices response speed and productivity. Non-real-time general-purpose solutions are entirely based on standard hardware and software stacks. While they possess the best versatility, portability, and cost advantages, they are completely unable to meet the needs of any industrial application scenario with deterministic timing requirements.

[0004] For example, the industrial equipment controller and communication device announced in the invention patent announcement with announcement number CN111930083B includes: the communication device includes a housing, at least two receiving communication ports and one transmitting communication port disposed on the housing; the receiving communication ports are used to connect to external devices; the transmitting communication port is used to connect to the industrial equipment controller.

[0005] For example, the scalable PLC intelligent data acquisition method announced in the invention patent publication CN112099426B includes: classifying the data types of detection elements according to their data characteristics; establishing sample data blocks based on the data type classification results and data characteristics of the detection elements; writing element data blocks, including multiple sub-data acquisition modules, into the PLC according to the PLC's syntax characteristics and the type and number of detection elements connected to the PLC; setting data acquisition algorithms based on the data structure of the sub-data acquisition modules in the element data blocks; determining the start and end addresses according to data acquisition requirements; and using the data acquisition algorithms to acquire data based on the start and end addresses.

[0006] However, in the process of implementing the inventive technical solution in the embodiments of this application, it was found that the above-mentioned technology has at least the following technical problems: In existing technologies, under non-full real-time constraints, due to the scheduling uncertainty of general-purpose operating system kernels, the coarse-grained nature of resource management, and the lack of isolation mechanisms, read and write task execution environments with low cost-effectiveness, poor resource efficiency, and poor deterministic performance are formed. There is a problem that real-time tasks and non-real-time tasks interfere with each other, making it difficult to efficiently utilize computing resources while ensuring the determinism of critical tasks. Summary of the Invention

[0007] This application provides a method to improve the stability of data acquisition / writing, solving the problem in the prior art where, under non-full real-time constraints, the scheduling uncertainty of the general-purpose operating system kernel, the coarse-grained nature of resource management, and the lack of isolation mechanisms result in a read / write task execution environment with low cost-effectiveness, poor resource efficiency, and poor deterministic performance. Furthermore, real-time and non-real-time tasks interfere with each other, making it difficult to efficiently utilize computing resources while ensuring the determinism of critical tasks. This application constructs a hybrid critical task co-loading environment that can simultaneously ensure the deterministic performance of critical tasks and the efficient coexistence of non-real-time tasks.

[0008] This application provides a method for improving the stability of data acquisition / writing, comprising the following steps: deploying a real-time operating system kernel on general-purpose computing hardware; modifying the hardware interface drivers in the real-time operating system kernel for real-time adaptation; adapting the container runtime engine for real-time adaptation, wherein the real-time adaptation enables the container runtime engine to call and interact with the real-time interface of the real-time operating system kernel; encapsulating the non-real-time data acquisition / writing program in a container image; and creating and running an instance of the container image on the real-time operating system kernel using the real-time adapted container runtime engine.

[0009] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By deploying a real-time operating system kernel and modifying its hardware drivers to be real-time, while adapting the container runtime engine to enable it to call the kernel's real-time interface, a unified platform with both real-time and containerization capabilities is built on general-purpose hardware. Non-real-time data programs are encapsulated in standard container images. This enables non-real-time applications to run in a containerized form on a real-time system in an isolated manner, ensuring that critical real-time tasks are not disturbed and significantly improving the flexibility of system resource utilization and application deployment.

[0010] 2. By identifying key hardware drivers, systematically reducing their kernel-mode latency and jitter, threading interrupt handling and assigning it high priority, and replacing it with a real-time network protocol stack, the hardware interface drivers are ensured to have extremely low and predictable response latency and extremely high determinism when processing real-time data streams. This achieves end-to-end timeliness of the entire real-time task from hardware interrupt to application processing, laying a solid foundation for building a highly reliable, hard real-time containerized system on a general-purpose hardware platform.

[0011] 3. By allocating high CPU scheduling priority to container instances and using control group mechanisms to implement fine-grained isolation and weight configuration of CPU, memory, and I / O resources, it is ensured that containers running data acquisition / writing programs can still obtain deterministic computing time, memory space, and I / O bandwidth in an environment of intense resource contention. This enables the stable coexistence of real-time and non-real-time tasks within the same system, building a hybrid mission-critical system with performance isolation, predictability, and guaranteed resources. Attached Figure Description

[0012] Figure 1 A flowchart illustrating a method for improving data acquisition / writing stability provided in this application embodiment; Figure 2 This is a flowchart illustrating the real-time modification of a hardware interface driver based on a method to improve data acquisition / writing stability, as provided in an embodiment of this application. Detailed Implementation

[0013] This application provides a method to improve the stability of data acquisition / writing, solving the problem in the prior art where, under non-full real-time constraints, the scheduling uncertainty of the general-purpose operating system kernel, the coarse-grained nature of resource management, and the lack of isolation mechanisms result in a read / write task execution environment with low cost-effectiveness, poor resource efficiency, and poor deterministic performance. Furthermore, real-time and non-real-time tasks interfere with each other, making it difficult to efficiently utilize computing resources while ensuring the determinism of critical tasks. The overall approach is as follows: After deploying a real-time operating system kernel on general-purpose computing hardware, the hardware interface drivers in the kernel are modified for real-time operation. At the same time, the container runtime engine is adapted for real-time operation, enabling it to call the real-time interface of the real-time operating system kernel and achieve effective interaction. Subsequently, the non-real-time data acquisition or writing program is packaged into the container image. Finally, with the help of the container runtime engine that has been adapted for real-time operation, an instance of the container image is created and run on the real-time operating system kernel.

[0014] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0015] like Figure 1 The diagram shown is a flowchart of a method for improving data acquisition / writing stability provided in an embodiment of this application. The method includes the following steps: A real-time operating system (RTOS) kernel is deployed on general-purpose computing hardware. This ROS kernel uses open-source real-time patches such as Xenomai or PREEMPT_RT to transform the standard Linux kernel into a real-time Linux kernel. Hardware interface drivers (such as serial ports and network protocol stacks) within the ROS kernel are modified for real-time operation to ensure they meet the real-time requirements of data acquisition and writing in industrial scenarios. Container runtime engines (such as Docker's daemon dockerd) are adapted for real-time operation, enabling them to call and efficiently interact with the real-time interfaces provided by the ROS kernel, thus providing a reliable real-time runtime environment for upper-layer applications. Existing non-real-time data acquisition / writing programs are encapsulated in container images, maintaining their original logic. Finally, through the real-time adapted container runtime engine, an instance of the container image is created and run on the ROS kernel. This allows non-real-time programs to rely on the real-time kernel and real-time drivers, significantly improving the stability and reliability of data acquisition and writing without modifying existing code, increasing hardware costs, or reducing read / write frequency.

[0016] In this embodiment, the present invention constructs a software operating environment that combines high real-time performance with high deployment flexibility, thereby systematically solving the stability problem in industrial data acquisition and writing tasks without sacrificing economy and existing software assets. First, by using open-source real-time patches such as Xenomai or PREEMPT_RT to transform the standard Linux kernel into a real-time Linux kernel, the predictability of task scheduling is ensured from the operating system level. This strictly guarantees that high-priority data read and write tasks are responded to and executed within a defined, extremely short time window, fundamentally avoiding acquisition delays or write timeouts caused by normal system load fluctuations. Second, the real-time modification of the hardware interface driver establishes a real-time channel throughout the entire path from the application to the hardware device, ensuring that data commands can be transmitted to the physical device without blocking and with low jitter, effectively preventing data loss caused by driver queue blocking or interrupt delays during system busy periods. Third, by adapting the container runtime engine to real-time, enabling it to understand and call the dedicated interfaces of the real-time kernel, lightweight and standardized container technology can be integrated into real-time systems. This not only introduces the significant advantages of containers in encapsulation, isolation, and rapid deployment to the industrial field, but also allows legacy programs originally designed for non-real-time environments to run seamlessly on highly real-time environments without any code modifications. Finally, by encapsulating non-real-time data acquisition / writing programs in container images and deploying them through the adapted runtime, non-real-time programs achieve the effect of enjoying real-time protection. This allows for the complete reuse of existing business logic code, eliminating the need for enterprises to invest in expensive dedicated real-time hardware or perform complex software refactoring to improve stability, and avoiding compromises such as reducing read / write frequency at the expense of productivity. Even under varying system loads, the high reliability and stability of the data link can be maintained, significantly improving the overall operational resilience and efficiency of industrial automation and IoT systems.

[0017] like Figure 2 The diagram shows a flowchart of a real-time modification process for hardware interface drivers based on a method to improve data acquisition / write stability, as provided in an embodiment of this application. The steps for real-time modification of hardware interface drivers in a real-time operating system kernel include: identifying key hardware interface drivers on the data acquisition / write task path; these drivers include one or more of serial port drivers, parallel port drivers, or network interface drivers; reducing latency and jitter generated when the drivers execute in kernel mode; optimizing the interrupt handling model of the drivers to improve their deterministic response; and replacing the general network protocol stack with a real-time network protocol stack.

[0018] In this embodiment, real-time modification of the hardware interface drivers in the real-time operating system kernel is a core step in achieving end-to-end real-time performance and ensuring the stability of data acquisition and writing. First, by accurately identifying key hardware interface drivers (such as serial port drivers, parallel port drivers, or network interface drivers) along the data acquisition / writing task path, the specific targets for real-time modification are clarified, allowing resources to be concentrated on addressing the most significant performance bottlenecks. Subsequently, by refactoring the driver code to reduce latency and jitter during kernel-mode execution, the execution time fluctuations along the path from user space through the driver to the hardware port are significantly reduced. This provides a highly predictable time window for packet processing, effectively avoiding intermittent transmission interruptions caused by changes in system load or resource contention. Furthermore, optimizing the driver's interrupt handling model, for example by adopting a strategy of threading interrupts and binding them to real-time task priorities, improves the deterministic response to hardware events, ensuring that data or signals from the device can be responded to and processed immediately and without delay, fundamentally preventing data loss problems that may occur under high load conditions. This invention replaces the general, complex standard network protocol stack with a streamlined and deterministic real-time network protocol stack, completely solving the millisecond-level or even higher level of random latency introduced by the general protocol stack due to internal lock contention, dynamic memory allocation, and complex routing logic. It provides end-to-end hard real-time guarantee for networked data acquisition and instruction writing, enabling the underlying capabilities of the real-time operating system to be transferred to upper-layer applications without loss. It is an indispensable technical foundation for ultimately achieving stable and reliable data read and write performance for non-real-time programs in containers.

[0019] Further steps to reduce latency and jitter generated by the driver during kernel mode execution include: replacing the first spinlock held for more than a preset threshold in the driver with a preemptible real-time mutex and enabling the priority inheritance protocol for the real-time mutex; reducing the interrupt masking region on the driver's critical path based on the worst-case interrupt execution time and the system interrupt latency tolerance limit; and inserting conditional scheduling points in all loops of the driver.

[0020] In this embodiment, the priority inheritance protocol is a scheduling optimization mechanism for solving the priority inversion problem in real-time systems. When a low-priority task holds a lock required by a high-priority task, the priority of the low-priority task is temporarily raised to the same level as the highest-priority task waiting for the lock, allowing it to execute and release the lock as soon as possible. This avoids preemption by medium-priority tasks, which would prolong the blocking time of high-priority tasks. By dynamically adjusting task priorities, this protocol ensures that lock holders are not delayed by irrelevant tasks due to insufficient priority, ultimately guaranteeing that high-priority tasks can still meet their deadline requirements even in the worst-case scenario, significantly enhancing the real-time performance and determinism of the system. This invention constructs a highly deterministic, low-latency execution environment by systematically optimizing the kernel-mode execution process of the driver. By replacing spinlocks held for more than a preset threshold with preemptible real-time mutex locks and enabling the priority inheritance protocol, the priority inversion problem is effectively solved, ensuring that high-priority tasks can preempt lock resources in a timely manner. At the same time, the priority inheritance mechanism maintains the strict order and predictability of task scheduling. Building upon this foundation, based on the worst-case execution time of interrupt service routines and the system's tolerance limit, the interrupt masking area on the driver's critical path is reduced, significantly lowering the overall system interrupt latency and ensuring the real-time task response capability to hardware events in multi-device concurrent scenarios. Furthermore, conditional scheduling points are inserted into the driver loop to avoid verbose operations monopolizing CPU resources and eliminate the resulting scheduling starvation risk. These three measures work synergistically from three core levels—lock contention, interrupt response, and CPU scheduling—transforming the driver into a standard component that meets the requirements of real-time systems, providing stable and reliable underlying support for upper-layer data acquisition and writing applications.

[0021] Furthermore, steps to reduce the interrupt masking region on the driver's critical path include: limiting the interrupt masking region to atomic reads and writes to hardware registers if the worst-case execution time of the interrupt is less than the interrupt latency limit; threading interrupt handling via kernel configuration options; moving non-critical operations such as data buffering and status updates outside the interrupt masking region; and refactoring the interrupt service routine to shorten its worst-case execution time if the worst-case execution time is not less than the interrupt latency limit.

[0022] In this embodiment, the worst-case execution time of an interrupt refers to the maximum time required for the routine to complete all operations under any possible input and system state. This can be obtained through static code analysis, instruction cycle calculation, or experimental verification with the assistance of real-time tracing tools. The interrupt latency upper limit refers to the maximum time interval that the system can accept from the occurrence of a hardware interrupt to the start of its processing. This threshold needs to be determined based on a comprehensive analysis of the shortest deadline of the real-time task and the system scheduling characteristics. The code refactoring of the interrupt service routine is achieved in the following ways: it is split into time-sensitive urgent operations and deferred non-urgent operations, and the latter is moved out of the interrupt context; a lookup table method is used to replace complex runtime calculations; data structures and algorithm paths are optimized to reduce branch prediction failures and cache misses; hardware acceleration is used to replace software implementation, thereby systematically shortening its worst-case execution time. The interrupt masking area on the critical path of the driver is finely reduced to systematically improve interrupt response capability and reduce system interrupt latency in the worst case, thereby providing deterministic hardware event response guarantees for high-priority real-time tasks. First, based on the comparison between the worst-case execution time of an interrupt and the upper limit of system interrupt latency tolerance, interrupt masking operations are strictly limited to the necessary range of atomic reads and writes of hardware registers. This minimizes the global interrupt shutdown time and avoids loss of system responsiveness due to prolonged interrupt masking. Building on this, interrupt handling is threaded through kernel configuration. This transforms critical tasks triggered by hardware interrupts into kernel threads with clear priorities, manageable by the real-time scheduler. This allows high-priority tasks to preempt interrupt handling threads, completely resolving the system blocking problem caused by the unschedulable nature of traditional interrupt service routines. Furthermore, non-critical operations such as data buffering and state updates are moved outside the interrupt masking area. This ensures that the driver only completes necessary hardware interactions while holding the interrupt lock, and all non-urgent processing is executed asynchronously in an interrupt-enabled environment, thus completely eliminating the blocking of the interrupt response path by non-critical logic. These measures work synergistically to reconstruct the interrupt handling model from a potential system latency bottleneck into a highly efficient path with rapid response and deterministic behavior, laying a reliable interrupt layer foundation for real-time data acquisition and writing tasks.

[0023] Furthermore, optimizing the interrupt handling model of the driver includes adopting a threaded interrupt handling mechanism: dividing the interrupt handler into a top half and a bottom half, with the top half only performing emergency hardware responses; the bottom half running as a kernel thread that can be managed by the real-time scheduler and has an allocable priority; and allocating a higher CPU scheduling priority than regular real-time tasks to the bottom half thread corresponding to the hardware interrupt responsible for real-time data transmission and reception.

[0024] In this embodiment, emergency hardware response refers to the fastest and most critical necessary response to a hardware interrupt request executed by the top half of the interrupt handler. Its core purpose is to immediately acknowledge and clear the hardware's interrupt pending state after an interrupt is triggered, ensuring that the hardware can promptly exit the interrupt request and resume normal operation, avoiding data loss or device blockage due to response delays. This process typically involves only atomic read / write operations on device registers, such as recording the interrupt status or responding to the interrupt controller, without involving any complex data processing or business logic. This invention optimizes the driver interrupt handling model by employing a threaded interrupt handling mechanism that divides the interrupt handler into a top half and a bottom half: the top half only performs necessary emergency hardware response operations to minimize interrupt shutdown time; the bottom half runs as a kernel thread with assignable priorities, manageable by the real-time scheduler, thereby achieving threaded and schedulable interrupt handling; furthermore, the bottom half thread corresponding to the hardware interrupt responsible for real-time data transmission and reception is assigned a higher CPU scheduling priority than regular real-time tasks, ensuring its real-time responsiveness. This mechanism systematically transforms the traditional non-preemptible interrupt service process into a schedulable task with a clear priority attribute, enabling high-priority real-time tasks to preempt the execution of the interrupt handling thread. This effectively solves the problems of system response jitter and latency accumulation caused by the uncertainty of interrupt service routine execution, thereby maintaining stable low-latency interrupt response performance even under complex load environments, and providing hardware event processing guarantees with deterministic behavior for real-time data acquisition and writing tasks.

[0025] Furthermore, replacing the general network protocol stack with a real-time network protocol stack includes: when real-time tasks need to maintain compatibility with standard network devices or services, using a real-time TCP / IP protocol stack based on the Xenomai or PREEMPT_RT framework; when real-time tasks have extreme requirements for latency and jitter and the communication mode is fixed, bypassing the general network protocol stack in the kernel to establish a network data channel for the real-time data stream, specifically including: directly sending and receiving raw Ethernet frames in user space, and performing only the most basic data link layer processing in the kernel; or, loading a proprietary kernel module to implement a dedicated communication protocol and providing data access to user space.

[0026] In this embodiment, the present invention replaces the general network protocol stack with a real-time network protocol stack, solving the latency and jitter problems introduced by the complexity of protocol processing and the uncertainty of kernel scheduling in traditional network communication, and providing network communication guarantees with deterministic behavior for real-time data acquisition and writing tasks. The specific implementation includes two complementary paths: when the real-time task needs to maintain compatibility with standard network devices or services, a real-time TCP / IP protocol stack based on the Xenomai or PREEMPT_RT framework is adopted. While retaining the standard socket interface, it significantly reduces network round-trip latency and packet processing jitter by simplifying protocol processing logic, eliminating internal lock contention, and optimizing packet scheduling strategies. When the real-time task has extreme requirements for latency and jitter and the communication mode is fixed, the general network protocol stack is completely bypassed in the kernel to establish a dedicated network channel for the real-time data stream, or raw Ethernet frames are sent and received directly in user space, so that the data only undergoes the most basic data link layer processing in the kernel, completely avoiding the system overhead of each layer of the protocol stack; or a lightweight dedicated communication protocol is implemented by loading a proprietary kernel module, and efficient data access interfaces such as mapped memory or character devices are provided to user space. These two approaches together constitute a hierarchical real-time network solution: the former achieves predictable network behavior and low latency under the premise of compatibility, while the latter achieves microsecond-level end-to-end transmission determinism through a simplified communication architecture in specialized scenarios, thereby systematically meeting the real-time network communication needs of varying degrees of severity in industrial IoT environments.

[0027] Furthermore, when the hardware interface driver is a serial port driver, the real-time modification also includes: disabling the data buffering and flow control functions in the serial port driver; configuring the serial port controller to generate an interrupt immediately after receiving a single byte; setting the trigger threshold of the serial port controller's receive and transmit hardware buffers to 1; and implementing a hardware-based parity check and timeout error detection mechanism in the driver.

[0028] In this embodiment, the hardware buffer is a first-in-first-out (FIFO) queue. As soon as one byte of data is received in the hardware buffer, the controller immediately generates an interrupt to notify the CPU to read it, avoiding the delay caused by waiting for the FIFO queue to fill with multiple bytes before generating an interrupt. As soon as there is free space in the hardware buffer (enough to hold one byte), an interrupt is immediately generated to notify the CPU that the next byte can be sent, thus maintaining the continuity of the data stream. For the real-time modification of the serial port driver, this invention systematically eliminates the delays and uncertainties introduced by data buffering, batch transmission, and software verification mechanisms in traditional serial communication by implementing a hardware-level precise control strategy. By disabling data buffering and flow control at the driver layer, transmission delays caused by buffer queue accumulation or flow negotiation waiting are completely avoided. The serial port controller is configured to generate an interrupt immediately upon receiving a single byte, and the trigger thresholds for the serial port receive and transmit hardware buffers are set to 1, ensuring that each byte's transmission and reception triggers an independent interrupt response, thus achieving real-time byte-level data processing. Simultaneously, a hardware-based parity check and timeout error detection mechanism is implemented in the driver, transferring critical verification logic from software to the hardware level. This improves the real-time performance of error detection while avoiding the CPU resource consumption of software verification. These measures work synergistically to transform serial communication from a traditional batch transmission mode to a highly deterministic byte-level real-time transmission mode, effectively eliminating all unnecessary delays in the data transmission path and providing industrial real-time control systems with microsecond-level response accuracy and high reliability for serial communication.

[0029] Furthermore, inserting conditional scheduling points includes: identifying busy-wait loops and condition-based loops; for busy-wait loops, inserting conditional rescheduling function calls within the loop body; for condition-based loops, employing an interruptible timeout waiting mechanism, replacing the original spin or polling check loop with an interruptible timeout event function or a real-time mutex lock function.

[0030] In this embodiment, the present invention addresses the real-time task scheduling latency problem caused by the long-term CPU monopoly of loop structures by inserting conditional scheduling points into the driver. First, two key structures in the driver are identified: busy-waiting loops and conditional loops. For busy-waiting loops, a conditional rescheduling function call is inserted within the loop body, enabling the kernel to execute scheduling decisions in each iteration and promptly relinquish the CPU to higher-priority tasks. For conditional loops, an interruptible timeout waiting mechanism is adopted, replacing the original spin or polling check mode with a real-time wait function with scheduling awareness or a mutex operation supporting timeouts. This modification effectively prevents the scheduler monopoly behavior caused by loop execution in the driver, ensuring that even when the driver is waiting for hardware response or when specific conditions are met, the system's real-time task scheduling can still be executed normally according to priority, thereby significantly reducing the worst-case task response latency and enhancing the determinism of real-time performance in multi-task concurrent environments.

[0031] Furthermore, the insertion of conditional scheduling points also includes monitoring the number of loop iterations: setting a maximum iteration threshold for the loop based on the real-time level of its driver; when the number of loop iterations exceeds the maximum iteration threshold, triggering an error handling process and calling the scheduler; the error handling process includes: recording loop timeout error logs, marking the driver as an abnormal state, and performing a driver downgrade or reset operation.

[0032] In this embodiment, based on the insertion of conditional scheduling points in the driver, the present invention further implements a dynamic monitoring mechanism for the number of loop iterations. By setting a maximum iteration threshold that is dynamically adjusted based on the real-time level of its respective driver for various loop structures, a real-time detection and fault-tolerant protection system for loop execution anomalies is constructed. When the number of loop iterations exceeds the preset threshold, a structured error handling process is immediately triggered: the loop timeout error log is automatically recorded to provide diagnostic basis, the driver is marked as abnormal to block the propagation of subsequent error operations, and the driver is downgraded or reset to restore the basic functions of the system. At the same time, the scheduler is forcibly invoked to ensure that real-time task scheduling is not blocked. This mechanism effectively eliminates infinite loop execution or long-term occupation of CPU resources caused by hardware failure, abnormal state, or logical defects, fundamentally avoiding the risk of system-level real-time performance collapse caused by local anomalies of a single driver, and significantly enhancing the fault tolerance and functional reliability of real-time systems in complex industrial scenarios.

[0033] Furthermore, the steps for creating and running container image instances on a real-time operating system kernel using a container runtime engine adapted for real-time operation include: allocating a higher CPU scheduling priority to container instances running data acquisition / writing programs than to non-real-time tasks, ensuring their scheduling behavior conforms to the characteristics of real-time tasks; allocating dedicated computing resource quotas to container instances using cgroups control group technology, specifically including: ensuring minimum CPU time for process groups through the synergy of core binding and share weight within the CPU control group, specifically including: strictly limiting the workload of process groups to one or more specified CPU cores through core binding; configuring the CPU time share weight of process groups within the bound CPU core set; and when process groups... When multiple threads within a bound core compete for CPU time slices, the operating system's CPU scheduler allocates CPU time within the bound core set according to weight ratios. In the memory control group, a memory usage cap threshold is configured for the target process group. When the memory consumption of a process group exceeds the cap threshold, a kernel-triggered mechanism terminates one or more processes within that process group. In the block device input / output control group, I / O weights higher than the default values ​​are configured for the target process group. When multiple process groups compete for the I / O bandwidth of the same block device, the I / O scheduler allocates bandwidth based on the weights configured for each process group. The configured I / O weights grant process groups higher priority I / O bandwidth compared to process groups with default weights.

[0034] In this embodiment, the present invention creates and runs container instances on a real-time operating system kernel using a container runtime engine adapted for real-time operation, constructing a real-time task execution environment with strict resource isolation and deterministic scheduling characteristics. The process first allocates a higher CPU scheduling priority to container instances running data acquisition / writing programs than to non-real-time tasks, ensuring that their scheduling behavior conforms to the characteristics of real-time tasks. Then, multi-level resource management is implemented through cgroups control group technology: in the CPU control group, the workload of container process groups is strictly limited to specified CPU cores through core binding, and CPU time share weights are configured within the bound core set, allowing the operating system scheduler to allocate CPU time in a competitive environment based on weight ratios, thereby simultaneously ensuring the exclusivity and fairness of computing resources; in the memory control group, by configuring a memory usage upper limit threshold, the kernel automatically monitors and triggers a process termination mechanism when the limit is exceeded, preventing memory overflow from damaging system stability; in the block device I / O control group, by configuring I / O weights higher than the default values, the target process group receives higher priority I / O scheduling processing when multiple processes compete for the same device bandwidth, effectively ensuring the data throughput performance of real-time tasks. The above mechanisms work together to provide end-to-end resource guarantees for containerized real-time tasks at the computation, memory, and I / O levels, enabling them to exhibit behavioral determinism and stability close to that of dedicated real-time systems on a shared general-purpose hardware platform.

[0035] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0036] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0037] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0038] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0039] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0040] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method of improving data acquisition / write stability, characterized by, The method comprises the following steps: deploying a real-time operating system kernel on general computing hardware; real-time modification of hardware interface drivers in the real-time operating system kernel; real-time adaptation of a container runtime engine, which is used to enable the container runtime engine to call and interact with real-time interfaces of the real-time operating system kernel; encapsulating a non-real-time data acquisition / writing program in a container image; creating and running an instance of the container image on the real-time operating system kernel through the real-time adapted container runtime engine.

2. The method of claim 1, wherein the data acquisition / write stability is improved by, The step of real-time modification of hardware interface drivers in the real-time operating system kernel comprises: identifying critical hardware interface drivers on the data acquisition / writing task path, including one or more of serial port drivers, parallel port drivers, or network interface drivers; reducing the delay and jitter generated when the drivers execute in kernel mode; optimizing the interrupt handling model of the drivers to improve their response determinism; replacing the general network protocol stack with a real-time network protocol stack.

3. The method of claim 2, wherein the data acquisition / write stability is improved by, The step of reducing the delay and jitter generated when the drivers execute in kernel mode comprises: replacing first spin locks in the drivers that hold time for more than a preset threshold with preemptible real-time mutexes, and enabling a priority inheritance protocol for the real-time mutexes; reducing the range of interrupt masking areas on the critical path of the drivers according to the worst-case interrupt execution time and the upper limit of system interrupt delay tolerance; inserting conditional scheduling points in all loops of the drivers.

4. The method of claim 3, wherein the data acquisition / write stability is improved by, The step of reducing the range of interrupt masking areas on the critical path of the drivers comprises: if the worst-case interrupt execution time is lower than the upper limit of interrupt delay, limiting the interrupt masking area to the range of atomic read and write of hardware registers; threading the interrupt handling through kernel configuration options; moving non-critical operations of data buffering and state updating outside the interrupt masking area; if the worst-case interrupt execution time is not lower than the upper limit of interrupt delay, performing code restructuring operations on the interrupt service routine.

5. The method of claim 2, wherein the data acquisition / write stability is improved by, The step of optimizing the interrupt handling model of the drivers comprises adopting a threaded interrupt handling mechanism: dividing the interrupt handling program into a top half and a bottom half, with the top half only performing urgent hardware responses; the bottom half runs as a kernel thread; allocating a higher CPU scheduling priority to the bottom half thread corresponding to the hardware interrupt responsible for real-time data transmission than to regular real-time tasks.

6. The method of claim 2, wherein the data acquisition / write stability is improved by, The step of replacing the general network protocol stack with a real-time network protocol stack comprises: when real-time tasks need to maintain compatibility with standard network devices or services, using a real-time TCP / IP protocol stack of a preset framework; when real-time tasks have extreme requirements for delay and jitter and the communication mode is fixed, bypassing the general network protocol stack in the kernel to establish a network data channel for real-time data flow, specifically including: directly transmitting raw Ethernet frames in the user space and only performing the most basic data link layer processing in the kernel; or, loading a proprietary kernel module to implement a dedicated communication protocol and providing data access to the user space.

7. The method of improving data acquisition / write stability as claimed in claim 2, wherein, When the hardware interface driver is a serial port driver, the real-time modification further comprises: Disable the data buffering and flow control function in the serial port driver; Configure the serial port controller to generate an interrupt immediately after receiving a single byte; Set the receive and transmit hardware buffer trigger thresholds of the serial port controller to 1; Implement a hardware-based parity check and timeout error detection mechanism in the driver.

8. The method of improving data acquisition / write stability as claimed in claim 3 wherein, The inserted conditional scheduling points include: Identify busy-wait loops and condition-based loops; For busy-wait loops, insert a conditional reschedule function call within the loop body; For condition-based loops, use an interruptable timeout waiting mechanism.

9. The method of claim 8, wherein the data acquisition / write stability is improved by, The inserted conditional scheduling points also include monitoring the number of loop iterations: Set a maximum iteration threshold for the loop, which is dynamically set according to the real-time level of the driver to which the loop belongs; When the number of loop iterations exceeds the maximum iteration threshold, trigger an error handling process and call the scheduler; The error handling process includes logging a loop timeout error, marking the driver as abnormal, and performing a downgrade or reset operation on the driver.

10. The method of improving data acquisition / write stability of claim 1, wherein, The step of running the instance of the container image on the real-time operating system kernel through the container runtime engine adapted in real time includes: Allocating a higher CPU scheduling priority than non-real-time tasks for the container instance running the data collection / writing program; Allocating exclusive computing resource quotas for the container instance, specifically including: In the CPU control group, ensuring the minimum CPU time for the process group through the cooperative action of core binding and share weight, specifically including: strictly limiting the workload of the process group to execute on a designated CPU core or a set of cores through core binding; Configuring the CPU time share weight of the process group within the bound CPU core set; When multiple threads in the process group compete for CPU time slices on the bound cores, the CPU scheduler of the operating system allocates CPU time within the bound core set according to the weight ratio; In the memory control group, configuring an upper limit threshold for the memory usage of the target process group, and when the memory consumption of the process group exceeds the upper limit threshold, triggering the kernel mechanism to terminate one or more processes in the process group; In the block device input / output control group, configuring the I / O weight of the target process group to be higher than the default value; When multiple process groups compete for the I / O bandwidth of the same block device, the I / O scheduler allocates bandwidth based on the weights configured for each process group.

Images