Method, system and device for detecting dynamic scheduling of software process

Abstract

The invention discloses a method, a system and a device for detecting software process dynamic scheduling. The method, the system and the device are used for separating and detecting processes with different functions of software and improving the stability of a detection task through dynamic scheduling. The method comprises the steps that material obtaining processes and detection processes are established according to detection requirements, the number of the detection processes is not unique, and the detection processes are provided with independent cache regions; acquiring a detection material through the material acquisition process, and inputting the detection material into the detection process according to a preset rule for detection; monitoring the detection process in real time through a monitoring module to obtain resource occupation data of the detection process; performing dynamic resource allocation on the detection process according to the resource occupation data; when the detection process is abnormal, automatically restarting the detection process, and simultaneously pausing the material to obtain the working state of the process; when the detection process is restarted, the restarted detection process is controlled to obtain the intermediate state data of the detection task through the independent cache region, and the detection task continues to be executed according to the intermediate state data.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a method, system and device for detecting dynamic scheduling of software processes. Background Art

[0002] Automatic optical inspection systems are widely used in electronic manufacturing, industrial quality inspection and other fields. Their core task is to capture images through cameras and detect product defects using image processing algorithms.

[0003] In existing technologies, image acquisition and defect detection are typically integrated into the same software process. When an inspection task is triggered, the process controls the camera to capture images and directly executes the defect recognition algorithm on the image data.

[0004] Because photography and algorithm processing share the same process resources, especially in multi-threaded or multi-tasking environments, they can compete for CPU and memory, creating processing bottlenecks. Especially in high-load scenarios, CPU utilization can easily become excessive, leading to slower system responses, task delays, and even lags or freezes. Furthermore, because all tasks are concentrated in a single process, this architecture struggles to effectively utilize the advantages of multi-core processors, limiting system performance expansion and resulting in poor system stability and maintainability. Summary of the Invention

[0005] In order to solve the above technical problems, the present application provides a method, system and device for dynamic scheduling of detection software processes, which are used to separate processes with different functions of the detection software and improve the stability of the detection tasks through dynamic scheduling.

[0006] The technical solution provided in this application is described below: A first aspect of the present application provides a method for detecting dynamic scheduling of a software process, comprising: Establishing a material acquisition process and a detection process according to detection requirements. The number of the detection processes is not unique, and the detection processes are set up with independent buffer areas; Acquire test materials through the material acquisition process, and input the test materials into the test process for testing according to preset rules; Monitor the detection process in real time through a monitoring module to obtain resource usage data of the detection process; Dynamically allocating resources to the detection process according to the resource occupancy data; When the detection process is abnormal, the detection process is automatically restarted and the working state of the material acquisition process is suspended; When the detection process is restarted, the restarted detection process is controlled to obtain the intermediate state data of the detection task through the independent buffer area, and continue to execute the detection task according to the intermediate state data.

[0007] Optionally, when the detection process is abnormal, after automatically restarting the detection process and pausing the working state of the material acquisition process, the method further includes: When the detection process enters the restart state, the self-healing strategy is started; If the self-healing strategy fails to recover the detection process, the detection task of the detection process is allocated to other detection processes according to the resource occupation data.

[0008] Optionally, dynamically allocating resources to the detection process according to the resource occupancy data includes: Obtain prediction algorithms; Predicting the resource occupancy status of the detection process according to the prediction algorithm in combination with the resource occupancy data; Dynamically allocate resources to the detection process according to the resource occupancy status.

[0009] Optionally, after inputting the detection material into the detection process for detection according to preset rules, the method further includes: The intermediate state data generated by the detection process executing the detection task is stored in the independent buffer area.

[0010] Optionally, after dynamically allocating resources to the detection process according to the resource occupancy data, the method further includes: The resources allocated to the detection process are preheated by using a memory preheating technology.

[0011] Optionally, after automatically restarting the detection process when the detection process is abnormal, the method further includes: An error log is generated according to the abnormality of the detection process, and the error log records the abnormality type and running status of the detection process when the abnormality occurs.

[0012] Optionally, the method further includes: The detection process is simulated to enter an abnormal state through program code to test the self-healing strategy of the detection process. The abnormal state includes memory leakage, thread blocking, file I / O failure, and model loading delay.

[0013] A second aspect of the present application provides a system for detecting dynamic scheduling of software processes, the system comprising: A first acquisition unit is configured to establish a material acquisition process and a detection process according to detection requirements, wherein the number of the detection processes is not unique and the detection processes are configured with independent buffer areas; a second acquisition unit, configured to acquire detection materials through the material acquisition process, and input the detection materials into the detection process for detection according to preset rules; A monitoring unit, configured to monitor the detection process in real time through a monitoring module and obtain resource usage data of the detection process; a first allocation unit, configured to dynamically allocate resources to the detection process according to the resource occupancy data; An abnormality control unit, configured to automatically restart the detection process and suspend the working state of the material acquisition process when the detection process is abnormal; The restart unit is used to control the restarted detection process to obtain the intermediate state data of the detection task through the independent buffer area when the detection process completes the restart, and continue to execute the detection task according to the intermediate state data.

[0014] Optionally, the system further includes: A self-healing unit, configured to initiate a self-healing strategy when the detection process enters a restart state; The second allocating unit is configured to allocate the detection task of the detection process to other detection processes according to the resource occupancy data if the self-healing strategy fails to recover the detection process.

[0015] Optionally, the first allocating unit is specifically configured to: Obtain prediction algorithms; Predicting the resource occupancy status of the detection process according to the prediction algorithm in combination with the resource occupancy data; Dynamically allocate resources to the detection process according to the resource occupancy status.

[0016] Optionally, the system further includes: The storage unit is used to store the intermediate state data generated by the detection process executing the detection task into the independent buffer area.

[0017] Optionally, the system further includes: A preheating unit is used to preheat the resources allocated to the detection process by using a memory preheating technology.

[0018] Optionally, the system further includes: A generating unit is used to generate an error log according to the abnormality of the detection process, wherein the error log records the abnormality type and running status when the abnormality occurs in the detection process.

[0019] Optionally, the system further includes: The test unit is used to simulate the detection process entering an abnormal state through program code and test the self-healing strategy of the detection process. The abnormal state includes memory leakage, thread blocking, file I / O failure, and model loading delay.

[0020] A third aspect of the present application provides a device for detecting dynamic scheduling of a software process, the device comprising: processor, memory, input and output units, and buses; The processor is connected to the memory, the input and output unit, and the bus; The memory stores a program, and the processor calls the program to execute the first aspect and any optional method in the first aspect.

[0021] In a fourth aspect, the present application provides a computer-readable storage medium, on which a program is stored. When the program is executed on a computer, the program executes the first aspect and any optional method in the first aspect.

[0022] It can be seen from the above technical solutions that this application has the following advantages: This method separates the material acquisition process from multiple detection processes. Through independent caches and real-time resource monitoring, it dynamically allocates resources like CPU and memory, preventing resource waste or overload. If a detection process experiences an anomaly, it automatically restarts, pausing material acquisition. After the restart, the detection task can be resumed based on the cache, ensuring task continuity. Combined with dynamic scheduling and anomaly self-healing mechanisms, this method improves the parallel processing capabilities and operational efficiency of the detection system, adapting to high-frequency, high-load detection requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in this application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 This is a flow chart of an embodiment of a method for detecting dynamic scheduling of software processes in this application; Figure 2 This is a flow chart of another embodiment of the method for detecting dynamic scheduling of software processes in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of a system for detecting dynamic scheduling of software processes in this application; Figure 4 This is a schematic structural diagram of another embodiment of the system for detecting dynamic scheduling of software processes in this application; Figure 5 This is a schematic diagram of the structure of an embodiment of the device for detecting dynamic scheduling of software processes in this application. DETAILED DESCRIPTION

[0025] It should be noted that the method for dynamic scheduling of detection software processes provided in this application can be applied to terminals, systems, and servers. For example, the terminal can be a smartphone, computer, tablet computer, smart TV, smartwatch, portable computer terminal, or a fixed terminal such as a desktop computer. For ease of explanation, this application uses the detection terminal as the execution subject for example.

[0026] To accommodate diverse execution terminals, the present application introduces a hardware abstraction layer (HAL) design, adapting the system resource management mechanisms of different platforms through a modular interface. For example, on embedded Linux platforms, scheduling policies are configured through cgroups (a resource control mechanism provided by the Linux kernel) and sched_setscheduler() (a Linux system call used to set the scheduling policy and priority of a process) system calls to implement resource limits and priority settings. On the Android platform, task scheduling framework components such as JobScheduler and WorkManager are used to manage the detection process lifecycle. On hardware that supports GPU inference acceleration, the detection process will call the resource detection interface before the task starts, prioritizing the use of the GPU for image preprocessing and model inference to improve overall detection efficiency.

[0027] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0028] See also Figure 1 The present application first provides an embodiment of a method for detecting dynamic scheduling of a software process, the embodiment comprising: S101: Establish a material acquisition process and a detection process according to detection requirements. The number of detection processes is not unique, and independent buffer areas are set for each detection process. Taking defect detection of captured content through pictures as an example, the detection terminal needs to simultaneously control the camera to capture defect detection materials and perform defect detection on the captured content.

[0029] Specifically, when a detection task is triggered, the camera capture and detection algorithm execution are initiated in separate processes. The acquisition process is responsible for controlling the camera to capture images for detection, ensuring real-time acquisition of image data. The detection process is responsible for processing and analyzing detection data, obtaining image data from the capture process and performing detection.

[0030] The detection terminal creates a material acquisition process, which is used to control the camera or material acquisition tool. The material acquisition tool can be an external module or a wireless connection module, or it can be directly built into the actual device of the detection terminal. When the material acquisition process is created, independent memory space and thread resources are allocated to the material acquisition process.

[0031] The detection terminal creates detection processes, the number of which is preset based on actual needs. These processes are used to execute detection algorithms, with different detection algorithms corresponding to different detection tasks. In practice, different detection processes can perform the same or different detection tasks, specifically configured based on actual detection needs. After establishing the detection processes, the detection terminal allocates independent memory space and thread resources to each detection process. Furthermore, each detection process has an independent cache area, which is used to cache intermediate resources generated during the execution of the detection process.

[0032] Each detection process is allocated an independent cache area, which is used to store temporary data and status information of the task. All independent cache areas use efficient memory management algorithms to ensure fast reading, writing and storage of data.

[0033] S102, acquiring test materials through the material acquisition process, and inputting the test materials into the test process for testing according to preset rules; The actual workflow of the detection terminal is to obtain the detection material through the material acquisition process. After the detection terminal obtains the detection material through the material acquisition process, the detection terminal will input the detection material into the detection process for detection.

[0034] It should be noted that the detection terminal is a carrier that can run the material acquisition process and the detection process at the same time. It can obtain detection materials from the material acquisition process through the logical algorithm of information interaction, and input the detection materials into the detection process to complete the overall process of the detection task.

[0035] Specifically, the detection process is used to load the detection algorithm. Each detection process obtains material data from the material acquisition process, processes and analyzes the material data, and identifies different defects in the material data.

[0036] When the detection terminal runs multiple detection processes at the same time, the detection terminal needs to determine the input order of the detection materials into different detection processes and the detection processes that need to be input through all the detection algorithms currently actually executed by the detection processes. That is, in actual situations, there is a situation where the output data of one detection process is the input data of another detection process. The detection process will process the detection materials during the process of detecting the detection materials. For example, the detection materials provided in this application will denoise or adjust the grayscale values ​​of the image data during the material detection process, and perform corresponding processing to enhance the features of the defects to be detected.

[0037] It should be noted that the detection terminal supports a hot update mechanism for the detection algorithm to improve the system's dynamic adaptability to the detection logic during operation. Hot update refers to replacing and upgrading the algorithm model or parameter configuration used by the detection process without interrupting the detection task, without restarting the detection process or the terminal. In other words, the hot update mechanism refers to a mechanism that can update the detection algorithm model without restarting the detection process.

[0038] Specifically, the detection process uses a modular plug-in architecture (e.g., a dynamic link library (DLL) or a shared object (SO)) to load the detection algorithm. The algorithm logic is decoupled from the main process's operating environment, and the system uses a hot update controller to manage versioning, dynamically mounting, and uninstalling the algorithm module.

[0039] After the detection terminal receives the algorithm upgrade command, the hot update controller marks the currently used detection algorithm as "pending uninstallation" and automatically releases the resources occupied by the algorithm module after the detection process completes its current task. The new algorithm module is then installed in the corresponding location in the detection process, and the algorithm replacement is completed through the interface registration mechanism. The entire process is completed in milliseconds and does not affect subsequent task scheduling or intermediate cache status.

[0040] To ensure the correctness and compatibility of algorithm replacement, the detection terminal will perform integrity check and version compatibility verification before updating, and can optionally configure a "grayscale update" strategy, that is, only replace the algorithm for some detection processes first, and then gradually expand it to all processes after the operation is stable.

[0041] The algorithm hot update mechanism described in this embodiment is not only applicable to algorithm version iteration, but can also quickly replace the algorithm when switching detection tasks (such as switching from surface defect detection to structure recognition detection), effectively improving the versatility and adaptability of the detection system.

[0042] S103, monitoring the detection process in real time through a monitoring module to obtain resource usage data of the detection process; In actual situations, there is more than one detection process. In order to ensure that the detection process is more stable during operation, the detection terminal will enable a monitoring module to monitor the running status of the detection process when the detection process is running.

[0043] The resource usage data monitored by the monitoring module includes, but is not limited to, the terminal computing power resource usage of the detection process and the actual load generated by the detection process. After obtaining the detection process's resource usage data, the monitoring module uses a prediction algorithm to analyze the detection process's current usage trends to predict the detection process's future resource usage. This allows the detection terminal to more accurately allocate its own CPU resource usage to the process.

[0044] Specifically, after the detection task is started, the monitoring module begins to collect resource data such as CPU usage and memory usage of each process at a preset frequency, and records the data in a log file.

[0045] S104, dynamically allocating resources to the detection process according to the resource occupancy data; After the detection terminal obtains the resource usage data of the detection process, it will allocate resources to the detection process based on the feedback results of the prediction model on the current status of the resource usage data, so that the detection process will not be unable to respond in time due to insufficient computing power resources allocated by the CPU during operation.

[0046] The detection terminal dynamically adjusts resource allocation for each process based on predictions and real-time monitoring data. For example, based on historical operational data, if the detection terminal predicts that a detection process may encounter a memory bottleneck within the next few minutes, it will pre-allocate additional memory from the resource pool.

[0047] It should be noted that the independent cache area corresponding to the detection process is implemented through a shared memory mechanism or a circular buffer queue. The cache structure is divided into a metadata area and a content data area. The metadata area records the ID of the current detection task, processing progress (such as the number of images processed), and detection algorithm version information. The content data area is used to store intermediate image processing results generated during the detection process, such as tensor matrices after feature extraction, mask images, and other intermediate data. The independent cache area uses lightweight concurrent access control strategies, such as atomic locks or read-write locks, to ensure consistency and security when multi-threaded access data.

[0048] To achieve dynamic allocation of detection process resources, the detection terminal uses a scoring model based on resource occupancy priority to score all currently running detection processes. The scoring model considers multiple indicators such as the urgency of the detection task (such as the priority of real-time detection needs), historical resource utilization, current occupancy trends, and predicted volatility, and allocates resources after dynamic sorting based on weighted scores. When resources are insufficient, some low-priority detection processes are frozen or their memory usage is compressed to free up available resources. In addition, in conjunction with the NUMA (Non-Uniform Memory Access) architecture optimization strategy, resource allocation can be bound to the CPU node where the current thread of the detection process is located as much as possible, reducing cross-node access overhead.

[0049] S105: When the detection process is abnormal, automatically restart the detection process and suspend the working state of the material acquisition process; When the detection process inevitably enters an abnormal state, the detection terminal will restart the detection process to release the resources occupied by the current detection process and reallocate resources to the detection process. When the detection process is restarted due to an abnormality, the working status of the detection process will be suspended, which will cause the processing of the detection task to stagnate. In order to avoid material loss, when the detection process enters the restart state due to an abnormality, the detection terminal will notify the control material acquisition process to obtain the detection material to ensure the integrity of the actual detection process.

[0050] Specifically, detecting a process anomaly usually triggers an automatic restart, but it may also be restarted due to external control instructions.

[0051] S106 . When the detection process is restarted, the restarted detection process is controlled to obtain the intermediate state data of the detection task through the independent buffer area, and continue to execute the detection task according to the intermediate state data.

[0052] When generating a detection process, the detection terminal will allocate a different independent cache area to each detection process. The independent cache area is used to store the intermediate nodes of unfinished detection tasks, so that after the detection process is restarted due to an abnormality, the restarted detection process can directly obtain the intermediate data through the independent cache area. The detection process determines the detection task node corresponding to the intermediate data through the intermediate data, and continues to execute the detection task from the task node.

[0053] When the detection process is restarted, the detection terminal will reallocate the CPU computing power resources required to execute the detection task to the detection process. If the detection process completes the restart, it means that the remaining computing power of the current detection terminal satisfies the detection process to continue to execute the detection task. Otherwise, the detection terminal will fail to restart and re-enter the restart state cycle until the detection process completes the restart.

[0054] Among them, during the execution of the detection task, the intermediate results and status information of the task are stored in the independent buffer area, including but not limited to: the number of processed images, the type and location of the identified defects, the progress of the algorithm execution and other key data.

[0055] This embodiment separates the material acquisition process from multiple detection processes. By using independent caches and real-time resource monitoring, it dynamically allocates resources like CPU and memory, preventing resource waste or overload. If a detection process experiences an anomaly, it automatically restarts, pausing material acquisition. After restarting, the detection task can be resumed based on the cache, ensuring task continuity. Combined with dynamic scheduling and anomaly self-healing mechanisms, this improves the parallel processing capabilities and operational efficiency of the detection terminal, adapting to high-frequency, high-load detection requirements.

[0056] See also Figure 2 , an embodiment of the present application provides another embodiment of a method for detecting dynamic scheduling of a software process, the embodiment comprising: S201: Establish a material acquisition process and a detection process according to detection requirements. The number of detection processes is not unique, and each detection process is set with an independent buffer area; Step S201 in this embodiment is similar to step S101 in the aforementioned embodiment, and will not be described in detail here.

[0057] S202, simulating the detection process entering an abnormal state through program code to test the self-healing strategy of the detection process, wherein the abnormal state includes a memory leak state, a thread blocking state, a file I / O failure, and a model loading delay; This step is to test the self-healing strategy of the detection process, that is, to force the detection process to enter an abnormal state so that the detection terminal can test the self-healing strategy of the detection process to determine whether the detection process can correctly pass through the abnormal state and enter the self-healing strategy before the detection task is executed, and actively repair the abnormal state of the detection process.

[0058] Specifically, the self-healing strategy primarily tests the terminal's ability to self-learn, predict, and correct errors while executing detection tasks. This detection process simulates the detection process entering abnormal states, such as memory leaks, blocked threads, file I / O failures, and model loading delays, through program code. Ten minutes after the detection task is started and running, the abnormal code segment is manually triggered, causing the detection process to enter the corresponding abnormal state based on the abnormal code content.

[0059] When the monitoring module detects an anomaly in the detection process, it immediately triggers the memory handling mechanism. For example, if a memory leak occurs, the detection terminal attempts to free up excess memory for the detection process and records a detailed error log. Furthermore, if the memory usage of the detection process exceeds the preset confidence interval, the detection terminal triggers immediate resource scheduling intervention to ensure the detection process can continue to run stably.

[0060] S203, acquiring test materials through the material acquisition process, and inputting the test materials into the test process for testing according to preset rules; Step S203 in this embodiment is similar to step S102 in the aforementioned embodiment, and will not be described in detail here.

[0061] S204, storing the intermediate state data generated by the detection process executing the detection task into the independent buffer area; Intermediate state data is non-result data generated during the execution of a detection task by a detection process. Intermediate state data is periodically written to the data in an independent cache area through a state snapshot mechanism. Specifically, if a detection process is restarted due to an abnormality, the detection terminal will control the detection process to restore the task state of the detection task from the independent cache area and continue to execute the unfinished task. In addition to actively restarting when an abnormality is detected, the detection process may also be restarted unexpectedly due to a failure or human intervention. When the detection process is restarted during the execution of a detection task, the relevant data of the detection task will be cached in its corresponding independent cache area. After the restart, the detection process will switch to the task recovery mode to restore the execution state of the detection task through the data state of the independent cache area and / or the detection task execution state of the detection terminal, so that the detection process can restore the task execution environment according to the cached data, reload the algorithm model and parameters, and continue to execute the unfinished detection task.

[0062] S205: Monitor the detection process in real time through a monitoring module to obtain resource usage data of the detection process; Step S205 in this embodiment is similar to step S103 in the aforementioned embodiment, and will not be described in detail here.

[0063] S206, obtaining a prediction algorithm; To improve the accuracy of the prediction model, the detection terminal automatically collects and saves resource usage data for each run while performing detection tasks. In this embodiment, data collection is performed once per second to ensure timely capture of changes in resource usage. Key metrics collected include CPU usage and memory usage, and resource usage data reports are generated regularly (e.g., hourly). The report content covers key metrics such as resource usage trends, peak and valley values, and average usage for each process over different time periods. The report displays data intuitively in the form of tables, bar charts, and line graphs for easy user viewing.

[0064] In this embodiment, the prediction algorithm uses a time series analysis algorithm and a long short-term memory network (LSTM) or a Transformer model.

[0065] Specifically, time series analysis algorithms (such as ARIMA and exponential smoothing) are used to fit and predict resource usage data. This allows the detection terminal to analyze historical data, identify cyclical and trend changes in resource usage, and thus generate a resource demand forecast curve for the future.

[0066] Long Short-Term Memory (LSTM) or Transformer models are used to predict future resource demand. These models capture both long-term dependencies and short-term fluctuations in resource usage, providing more accurate forecasts. The detection terminal uses LSTM or Transformer models to generate confidence intervals for each forecast result. These confidence intervals are dynamically adjusted based on historical forecast errors and data volatility.

[0067] The upper and lower bounds of the confidence interval are dynamically adjusted based on historical data volatility and forecast error to ensure the reliability of the forecast results. If actual resource consumption exceeds the upper bound of the confidence interval, indicating abnormally high resource usage, the detection terminal triggers an immediate resource scheduling intervention mechanism to prioritize more resources for high-load processes. If actual resource consumption falls below the lower bound of the confidence interval, indicating low resource usage, the detection terminal attempts to reallocate some resources to other processes to improve resource utilization.

[0068] During the execution of detection tasks in this embodiment, the detection terminal improves resource scheduling accuracy by integrating multiple prediction models. Specifically, the base layer uses the ARIMA model to capture cyclical changes, the middle layer uses the LSTM network to capture long-term trends and sudden fluctuations, and the high-level Transformer model with an attention mechanism is used to determine the risk of short-term load surges. The prediction results are weighted averaged across multiple models and dynamically revised using confidence intervals. The scheduling module ultimately uses them as the basis for resource allocation. The prediction error is fed back to the model training system during each detection cycle, forming a closed-loop optimization loop.

[0069] S207: predicting the resource occupancy status of the detection process according to the prediction algorithm and the resource occupancy data; Resource usage status is determined by dividing the confidence interval into preset proportions. This information allows users to intuitively determine the resource usage status of the current detection process based on the confidence interval. Furthermore, resource usage status reflects the CPU computing power requirements of the current detection process, allowing the detection terminal to provide feedback to the corresponding detection process based on this resource usage status.

[0070] S208, dynamically allocating resources to the detection process according to the resource occupancy status; The detection terminal dynamically adjusts resource allocation for each process based on predictions and real-time monitoring data. If a process is predicted to face a resource bottleneck in the future, the detection terminal will pre-allocate additional resources from the resource pool to that process. Using memory preheating technology, the detection terminal accelerates the process's initial use of newly allocated memory, reducing latency. Based on actual resource usage and predictions, the detection terminal dynamically adjusts resource allocation for each process to ensure overall performance and stability during detection tasks.

[0071] S209, preheating the resources allocated to the detection process using a memory preheating technology; Memory preheating involves loading the data, models, or resources required for resource usage into memory before the detection process uses the allocated resources. This reduces wait times for subsequent calls and improves program responsiveness and execution efficiency. By preloading critical resources, we can reduce task latency, avoid cold start delays, and improve continuity and responsiveness.

[0072] Specifically, memory preheating technology is implemented by preloading the weight parameters required by the detection model, shared library files called by the algorithm, and basic image processing modules (such as filter functions in the OpenCV library) into RAM. It then proactively executes an unloaded inference task to activate the GPU cache. For typical neural network models, inference engines such as TensorRT are pre-invoked during the detection terminal startup phase to generate an inference cache (such as a CUDA graph or engine file) to reduce initial detection latency. This technology is particularly suitable for embedded detection terminals with limited hardware resources, significantly improving model loading and task response speeds.

[0073] S210: When the detection process is abnormal, automatically restart the detection process and suspend the working state of the material acquisition process; Step S210 in this embodiment is similar to step S105 in the aforementioned embodiment, and will not be described in detail here.

[0074] S211. When the detection process enters the restart state, a self-healing strategy is started; The self-healing strategy is generally triggered automatically when the detection terminal deems the detection process abnormal. In addition to restarting the process, the detection process abnormality also includes abnormalities triggered by the monitoring module detecting that the defects currently being processed by the detection process exceed the threshold. After the detection process triggers an abnormality, the detection terminal will control the detection process to restart and attempt to repair the process by reloading the algorithm library of the detection process, clearing cache data, and other operations.

[0075] It should be noted that the reasons for the detection process restart include external operational errors and the detection terminal actively controlling the detection process restart when the detection process is abnormal. Therefore, after the detection process restarts, the self-healing strategy will be activated, allowing the detection process to obtain the execution progress of the detection task through the independent cache area.

[0076] The self-healing strategy process consists of three phases: diagnosis, repair attempt, and alternative execution. The diagnosis phase is triggered by the monitoring module through a combination of stack traceback, exception type identification (such as NullPointerException and OOM), and system resource status determination. The repair attempt phase involves releasing resources, resetting the detection module status, and reloading the model. If the repair fails, the alternative execution phase begins, reassigning the detection task interrupted by the anomaly detection process to another detection process with sufficient resources. The task interruption point information is read from an independent cache and execution continues, ensuring uninterrupted tasks.

[0077] In some cases, such as when the detection terminal also integrates a fault prediction module, this module is used to proactively predict potential abnormalities in the detection process. This module models and analyzes historical operational data (such as resource utilization rate changes, error code frequency, and execution time fluctuations) to identify high-risk indicators that could lead to process interruption. For example, if a detection process experiences a continuous and rapid increase in memory usage per unit time, accompanied by a significant increase in processing latency, the prediction module will flag it as a potential fault node.

[0078] When a detection process is predicted to become abnormal, the detection terminal will trigger a pre-task migration strategy. This strategy includes the following steps: first, freezing the task allocation of the current detection process and suspending the issuance of new tasks; second, backing up the intermediate state data of the currently processing task to a redundant cache; third, prioritizing other detection processes that are idle or have low resource usage as migration targets; and fourth, migrating the backed-up task state data to the independent cache of the target detection process and updating the scheduling table.

[0079] Through this approach, the detection terminal can preemptively switch tasks to healthy detection processes before a fault actually occurs, avoiding task interruption or duplication, and improving overall system stability and task continuity. This strategy not only enhances the proactive self-healing mechanism of the detection process but also significantly reduces system performance fluctuations caused by process anomalies in high-frequency detection environments through fault warnings and dynamic task migration.

[0080] S212: If the self-healing strategy fails to recover the detection process, allocating the detection task of the detection process to other detection processes according to the resource usage data; If the detection process is still in an abnormal state after restart and the execution of the detection task cannot be resumed, the detection terminal will reallocate resources according to the preset resource adjustment strategy. That is, the detection terminal will temporarily allocate part of the resources originally allocated to the current detection process to other normally running detection processes to ensure that the progress of the overall detection task is not affected.

[0081] S213: Generate an error log based on the abnormality of the detection process, wherein the error log records the abnormality type and running status of the detection process when the abnormality occurs; After determining that the inspection process cannot continue the inspection task, the inspection terminal will generate a detailed error log based on the inspection process anomaly. The specific error log includes: the specific time the error occurred (such as 2025-06-17 15:30:22), the anomaly type (such as "defects exceed the preset threshold"), the location of the occurrence (such as "image analysis module of the inspection process"), and the inspection process status at that time (such as memory utilization of 85% and CPU utilization of 90%). The generated log file is stored in the inspection terminal's log directory. The error log file is named using the preset error log file name and timestamp to facilitate subsequent analysis and troubleshooting of the anomaly cause.

[0082] In this embodiment, the error log structure is uniformly encoded in JSON format and contains the following fields: "time_stamp" (timestamp), "process_id" (process number), "exception_type" (exception type), "cpu_usage" (CPU usage), "mem_usage" (memory usage), "stack_trace" (error stack), "task_progress" (detection task progress), and "last_cache_state" (cache area status). The detection terminal triggers a multi-layer alarm mechanism while recording the log, and issues alarms through different channels (local pop-up windows, sound prompts, administrator emails, or platform SMS) based on the level of the exception. Severity levels include "more than three consecutive restart failures," "resource leakage causing system crashes," and "detection delays exceeding the limit," ensuring the stability of detection tasks and the efficiency of operation and maintenance response.

[0083] S214: When the detection process is restarted, control the restarted detection process to obtain the intermediate state data of the detection task through the independent buffer area, and continue to execute the detection task according to the intermediate state data.

[0084] Step S214 in this embodiment is similar to step S106 in the aforementioned embodiment, and will not be described in detail here.

[0085] To further improve the resource coordination efficiency and task processing stability of the detection system, some embodiments support a collaboration mechanism between detection processes to achieve information sharing between tasks and centralized scheduling of computing resources. Specifically, the detection terminal sets a master detection process to uniformly collect the operating status information of each detection sub-process, including resource usage, intermediate status data, task execution progress, etc. Based on the collected information, the master detection process performs global scheduling management of the task scheduling order, resource allocation priority, and intermediate data processing order of all detection processes.

[0086] In scenarios where inspection tasks are complex or task chains have dependencies, the inspection terminal supports sharing of intermediate results between inspection processes. This means that after a specific inspection process completes a specific image preprocessing operation, it stores the results in a shared cache, which can be directly accessed by downstream inspection processes (such as defect classification). This avoids duplicate calculations and reduces overall resource consumption. Access control mechanisms and synchronization flags are set up within the shared cache to ensure data consistency and task scheduling synchronization during concurrent reads and writes.

[0087] In addition, to improve the efficiency of task collaborative processing, the detection terminal implements task slicing and phased parallelism between detection processes. When a certain detection task can be divided into multiple stages (such as image cropping, feature extraction, and defect judgment), the detection terminal assigns different stages to different detection processes for parallel processing, and transfers context data through the cache area at the task switching node, thereby improving processing throughput and system concurrency performance.

[0088] In practice, the detection system can be deployed across multiple physical terminals within different execution entities to build a detection platform that supports distributed scheduling and collaboration. This platform includes multiple detection terminals with independent detection capabilities, each of which runs a material acquisition process and multiple detection processes. Data exchange and task allocation are carried out between the terminals via a local area network or wide area network.

[0089] Specifically, the system introduces a Global Task Coordinator (GTC), which can be deployed on any detection terminal or independent server. This scheduling unit is responsible for coordinating task allocation, resource monitoring, and failover across terminals. When the resource usage of a detection terminal exceeds a threshold, or the detection process fails for more than a set number of consecutive times, the GTC automatically migrates pending tasks to other idle or low-load terminals for execution. This migration process is implemented through a unified task state serialization format and cache synchronization mechanism, ensuring seamless connection between detection progress and intermediate states.

[0090] To ensure concurrent consistency across multiple terminals, the system uses a distributed consistency protocol (such as the RAFT algorithm) to maintain a global task schedule and cache index. Each terminal regularly reports its local status to the GTC, including metrics such as CPU / memory usage, test progress, and error logs. The GTC then makes scheduling decisions based on this information, enabling system-level dynamic resource integration and task redundancy.

[0091] By introducing a distributed detection collaboration mechanism, the present invention can adapt to detection scenarios with high load and heterogeneous equipment deployment, such as large-scale industrial detection pipelines and city-level image processing platforms. While ensuring detection continuity and response speed, it significantly improves the system's fault tolerance and processing scale.

[0092] In addition, this embodiment also provides a necessary information visualization solution for interface design, that is, provides a user-friendly visualization interface.

[0093] Specifically, the left side of the interface displays an inspection progress bar, reflecting the progress of the three inspection processes in real time. The right side displays inspection results, including the number of inspected images, identified defect types, and statistical charts. The bottom of the interface features a system status bar for the inspection terminal, providing real-time updates on hardware resource usage, such as current CPU usage of 65% and memory usage of 4.2GB / 16GB. If the user discovers insufficient defect detection accuracy during the inspection process, they can adjust the accuracy slider to a higher level using the "Inspection Parameters" tab. After receiving user input, the inspection terminal dynamically adjusts the inspection strategy for each inspection process. The inspection process reloads the model based on the new accuracy parameters and applies them to subsequent inspection tasks (this triggers a restart of the inspection process). After the user adjusts the accuracy parameters of an inspection process, the inspection terminal displays the results in real time on the interface, allowing users to visually compare the results before and after the adjustments. If the inspection terminal detects a significant defect (such as a defect area exceeding the preset alarm threshold) or a process anomaly (such as if a process, including the material acquisition process, fails to restart three times in a row), the inspection terminal immediately triggers an alarm. Alarms notify users through various methods, including audio prompts (such as a continuous beep), pop-up alerts (a red warning box appears with the message "Major defect detected, please address promptly"), and email notifications (an alarm email is sent to the administrator's preset email address with the subject line "Defect Detection System Alarm Notification"). After receiving an alarm, users can view detailed information and take appropriate action by clicking the "Alarm Details" button on the interface.

[0094] The above is a detailed description of the method for detecting dynamic scheduling of software processes in the embodiment of the present application. The following is a detailed description of the system and device for detecting dynamic scheduling of software processes.

[0095] See also Figure 3The present application provides an embodiment of a system for detecting dynamic scheduling of software processes, which includes: The first acquisition unit 301 is used to establish a material acquisition process and a detection process according to the detection requirements. The number of the detection processes is not unique, and the detection processes are set with independent buffer areas; A second acquisition unit 302 is configured to acquire detection materials through the material acquisition process, and input the detection materials into the detection process for detection according to preset rules; The monitoring unit 303 is configured to monitor the detection process in real time through a monitoring module to obtain resource usage data of the detection process; an allocation unit 304, configured to dynamically allocate resources to the detection process according to the resource occupancy data; An abnormality control unit 305 is configured to automatically restart the detection process and suspend the working state of the material acquisition process when the detection process is abnormal; The restart unit 306 is configured to control the restarted detection process to obtain the intermediate state data of the detection task through the independent buffer area when the detection process completes the restart, and continue to execute the detection task according to the intermediate state data.

[0096] In this embodiment, the functions of each unit are the same as those described above. Figure 1 The steps in the illustrated embodiment correspond to each other and will not be repeated here.

[0097] See also Figure 4 The present application provides an embodiment of a system for detecting dynamic scheduling of software processes, which includes: The first acquisition unit 401 is used to establish a material acquisition process and a detection process according to the detection requirements. The number of the detection processes is not unique, and the detection processes are set with independent buffer areas; The testing unit 402 is used to simulate the detection process entering an abnormal state through program code and test the self-healing strategy of the detection process. The abnormal state includes memory leakage, thread blocking, file I / O failure, and model loading delay.

[0098] A second acquisition unit 403 is configured to acquire detection materials through the material acquisition process, and input the detection materials into the detection process for detection according to preset rules; The storage unit 404 is configured to store the intermediate state data generated by the detection process executing the detection task into the independent buffer area.

[0099] The monitoring unit 405 is configured to monitor the detection process in real time through a monitoring module to obtain resource usage data of the detection process; A first allocation unit 406 is configured to dynamically allocate resources to the detection process according to the resource occupancy data; The preheating unit 407 is configured to preheat the resources allocated to the detection process using a memory preheating technology.

[0100] An abnormality control unit 408 is configured to automatically restart the detection process and suspend the working state of the material acquisition process when the detection process is abnormal; A self-healing unit 409 is configured to start a self-healing strategy when the detection process enters a restart state; The second allocating unit 410 is configured to allocate the detection task of the detection process to other detection processes according to the resource occupancy data if the self-healing strategy fails to recover the detection process.

[0101] The generating unit 411 is configured to generate an error log according to the abnormality of the detection process, wherein the error log records the abnormality type and running status of the detection process when the abnormality occurs.

[0102] The restart unit 412 is configured to control the restarted detection process to obtain the intermediate state data of the detection task through the independent buffer area when the detection process completes the restart, and continue to execute the detection task according to the intermediate state data.

[0103] In this embodiment, the first allocating unit 406 is specifically configured to: Obtain prediction algorithms; Predicting the resource occupancy status of the detection process according to the prediction algorithm in combination with the resource occupancy data; Dynamically allocate resources to the detection process according to the resource occupancy status.

[0104] In this embodiment, the functions of each unit are the same as those described above. Figure 2 The steps in the illustrated embodiment correspond to each other and will not be repeated here.

[0105] See also Figure 5 The present application provides an embodiment of a device for detecting dynamic scheduling of a software process, including: Processor 501, memory 502, input and output unit 503, bus 504; The processor 501 is connected to the memory 502, the input and output unit 503 and the bus 504; The processor 501 specifically performs Figures 1 to 2 The operations corresponding to the steps in the method are not described in detail here.

[0106] The present application also relates to a computer-readable storage medium, on which a program is stored. When the program is run on a computer, the computer is caused to execute any of the above methods.

[0107] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0108] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0109] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0110] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0111] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk, and other media that can store program code.

Claims

1. A method for detecting dynamic scheduling of software processes, characterized in that: The method comprises: Establishing a material acquisition process and a detection process according to detection requirements. The number of the detection processes is not unique, and the detection processes are set up with independent buffer areas; Acquire test materials through the material acquisition process, and input the test materials into the test process for testing according to preset rules; Monitor the detection process in real time through a monitoring module to obtain resource usage data of the detection process; Dynamically allocating resources to the detection process according to the resource occupancy data; When the detection process is abnormal, the detection process is automatically restarted and the working state of the material acquisition process is suspended; When the detection process is restarted, the restarted detection process is controlled to obtain the intermediate state data of the detection task through the independent buffer area, and continue to execute the detection task according to the intermediate state data.

2. The method according to claim 1, characterized in that After automatically restarting the detection process and pausing the working state of the material acquisition process when the detection process is abnormal, the method further includes: When the detection process enters the restart state, the self-healing strategy is started; If the self-healing strategy fails to recover the detection process, the detection task of the detection process is allocated to other detection processes according to the resource occupation data.

3. The method according to claim 1, characterized in that The dynamically allocating resources to the detection process according to the resource occupancy data includes: Obtain prediction algorithms; Predicting the resource occupancy status of the detection process according to the prediction algorithm in combination with the resource occupancy data; Dynamically allocate resources to the detection process according to the resource occupancy status.

4. The method according to claim 1, wherein After inputting the detection material into the detection process for detection according to preset rules, the method further includes: The intermediate state data generated by the detection process executing the detection task is stored in the independent buffer area.

5. The method according to claim 1, characterized in that After dynamically allocating resources to the detection process according to the resource occupancy data, the method further includes: The resources allocated to the detection process are preheated by using a memory preheating technology.

6. The method according to any one of claims 1 to 5, characterized in that After automatically restarting the detection process when the detection process is abnormal, the method further includes: An error log is generated according to the abnormality of the detection process, and the error log records the abnormality type and running status of the detection process when the abnormality occurs.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: The detection process is simulated to enter an abnormal state through program code to test the self-healing strategy of the detection process. The abnormal state includes memory leakage, thread blocking, file I / O failure, and model loading delay.

8. A system for detecting dynamic scheduling of software processes, characterized in that: The system comprises: A first acquisition unit is configured to establish a material acquisition process and a detection process according to detection requirements, wherein the number of the detection processes is not unique and the detection processes are configured with independent buffer areas; a second acquisition unit, configured to acquire detection materials through the material acquisition process, and input the detection materials into the detection process for detection according to preset rules; A monitoring unit, configured to monitor the detection process in real time through a monitoring module and obtain resource usage data of the detection process; an allocation unit, configured to dynamically allocate resources to the detection process according to the resource occupancy data; An abnormality control unit, configured to automatically restart the detection process and suspend the working state of the material acquisition process when the detection process is abnormal; The restart unit is used to control the restarted detection process to obtain the intermediate state data of the detection task through the independent buffer area when the detection process completes the restart, and continue to execute the detection task according to the intermediate state data.

9. A device for detecting dynamic scheduling of software processes, characterized in that: The device comprises: processor, memory, input and output units, and buses; The processor is connected to the memory, the input and output unit, and the bus; The memory stores a program, and the processor calls the program to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program, and when the program is executed on a computer, the method according to any one of claims 1 to 7 is executed.

Images