Multi-core parallel processing method and system for industrial intelligent edge computing

Abstract

The application relates to a multi-core parallel processing method and system for industrial intelligent edge computing, belonging to the technical field of industrial intelligence and edge computing, and in particular to a multi-core parallel task scheduling and processing method applied to an industrial field edge computing unit. The method solves the technical problems that in the prior art, when multiple models are concurrently executed on an industrial edge computing unit with limited resources, the differentiated real-time requirements cannot be met, cross-core data interaction delay is high, and a core fault tolerance mechanism is lacked. The method comprises the following steps: priority division is performed on various industrial intelligent analysis models deployed in an industrial field. The multi-core parallel processing method and system for industrial intelligent edge computing are suitable for industrial automation production lines, intelligent numerical control machine tools, industrial robot clusters and edge intelligent monitoring and analysis scenes of various discrete / flow manufacturing.

Description

Technical Field

[0001] This invention relates to the field of industrial intelligence and edge computing technology, and in particular to a multi-core parallel task scheduling and processing method applied to edge computing units in industrial settings. Background Technology

[0002] With the rapid development of smart manufacturing, the Industrial Internet, and digital workshops, the number of sensors, controllers, robots, machine tools, production line equipment, and quality inspection devices deployed in industrial settings continues to increase. The production process generates a large amount of heterogeneous data from multiple sources, including vibration, temperature, current, voltage, pressure, speed, visual images, and control status. Problems such as equipment performance degradation, component wear, process fluctuations, and quality anomalies are becoming more frequent and complex in industrial settings. To ensure production continuity and product consistency, industrial systems need to possess the ability to continuously sense the status of critical equipment and processes, and to accurately identify, quickly locate, and promptly warn of anomalies at their early stages.

[0003] Traditional industrial equipment health management and quality analysis often rely on manual inspections, periodic offline reports, or uploading massive amounts of data to cloud platforms for centralized big data analysis. This approach has significant shortcomings in practical industrial applications, failing to meet requirements for real-time performance, continuity, and on-site reliability.

[0004] On the one hand, cloud transmission is easily constrained by factory network bandwidth limitations, instability caused by on-site electromagnetic interference, and stringent data security requirements (such as data not leaving the factory);

[0005] On the other hand, the control cycle of modern industrial production lines is extremely short. Abnormalities in some key processes (such as spindle collisions and tool breakage) need to be responded to within milliseconds or seconds. Simply relying on non-real-time analysis in the remote cloud is obviously insufficient to support emergency shutdown protection, real-time parameter fine-tuning, and maintenance decisions in a timely manner.

[0006] Therefore, pushing intelligent analytics capabilities down to industrial edge computing nodes, enabling real-time data processing, model reasoning, and result feedback to be completed directly near equipment and production lines, has become a core trend in current industrial intelligence.

[0007] However, analytical tasks in industrial intelligence scenarios typically exhibit characteristics of "multiple models coexisting, resource constraints, and high real-time requirements." For example, a single intelligent production line may simultaneously run a simple threshold rule model, a machine learning-based anomaly detection model, a complex deep learning prediction model, a multi-dimensional quality assessment model, and a remaining equipment lifespan assessment model. These different models vary significantly in terms of input data types, computational load, real-time response requirements, and data interaction relationships. Meanwhile, due to strict limitations on power consumption, heat dissipation, hardware costs, and equipment installation space in industrial settings, industrial edge devices typically cannot be configured with high-performance independent computing resources for each model. Instead, they generally employ compact edge gateways with integrated multi-core processors (such as ARM Cortex-A72 / A53 heterogeneous multi-core processors or similar AI accelerator chips).

[0008] Therefore, under the condition of limited multi-core computing power resources, how to break through the bottleneck of traditional single-thread or simple multi-thread scheduling, design a mechanism that enables multiple heterogeneous models to run in parallel efficiently, and take into account the real-time response of high-priority tasks, low-latency data sharing between models, and the core fault tolerance capability of the system, has become a key technical problem restricting the true implementation of industrial intelligent applications at the edge.

[0009] Different industrial equipment, production line units, and process steps have different real-time requirements for task processing. However, existing industrial edge computing systems generally adopt a single scheduling strategy (such as polling scheduling), which lacks the ability to finely distinguish and adaptively adjust different real-time levels.

[0010] More importantly, the impact of different equipment on production continuity and asset loss varies significantly in industrial settings. For example, an anomaly in the spindle of an industrial robot can paralyze the entire production line or even destroy the equipment; while a brief malfunction in an auxiliary temperature control system only affects the local environment and has a smaller impact on overall production. Therefore, even using the exact same anomaly detection model, the required response priority should differ depending on the equipment's importance. However, existing single scheduling strategies completely ignore this difference in equipment importance, causing anomalies in critical equipment to be delayed due to competition for resources with non-critical tasks, further exacerbating safety risks. For example:

[0011] For high-priority tasks such as safety protection, critical equipment shutdown early warning, and core quality control, a single scheduling strategy may not be able to respond in a timely manner, causing critical tasks to be preempted by other low-priority tasks during execution, resulting in missed safety incidents or delayed alarms, which may lead to equipment damage or production accidents in severe cases.

[0012] For tasks such as equipment status assessment, process stability analysis, and monitoring of critical components, a single scheduling strategy may not be able to effectively balance their periodic and sudden demands. When the system load fluctuates greatly, such tasks may either affect high-priority tasks due to excessive resource consumption or fail to complete the analysis within the specified period due to insufficient computing power, resulting in a lag in status assessment.

[0013] For tasks such as energy consumption statistics, log analysis, and auxiliary maintenance, using a single scheduling strategy may waste computing resources. This is because these tasks do not require real-time response, but under polling scheduling, they still have to compete with other tasks for CPU time slices, which not only consumes valuable computing power but also increases unnecessary context switching overhead, reducing the overall system efficiency.

[0014] In addition, most existing solutions do not consider the data correlation between models, have high latency in cross-core data interaction, and lack an effective single-core fault tolerance mechanism. Once a core malfunctions, the entire intelligent analysis function may be interrupted.

[0015] Therefore, there is an urgent need for a multi-core parallel processing architecture that can simultaneously meet differentiated real-time constraints, reduce cross-core communication overhead, and have fault tolerance capabilities, so as to improve the overall reliability, operating efficiency, and resource utilization efficiency of industrial edge computing systems. Summary of the Invention

[0016] This invention proposes a multi-core parallel processing method and system for industrial intelligent edge computing, which solves the technical problems in the prior art that, when multiple models are executed concurrently on resource-constrained industrial edge computing units, they cannot meet the differentiated real-time requirements, have high latency in cross-core data interaction, and lack core fault tolerance mechanisms.

[0017] The multi-core parallel processing method for industrial intelligent edge computing described in this invention includes the following steps:

[0018] Multiple industrial intelligent analysis models deployed on industrial edge computing units are prioritized and hierarchically classified. Weighted scores are applied based on three dimensions: equipment importance, process impact, and model real-time requirements. The models are then divided into core emergency level, important monitoring level, and auxiliary analysis level based on the comprehensive score.

[0019] Based on the data correlation and computational load between models, the multiple industrial intelligent analysis models are dynamically clustered to form several cluster groups.

[0020] Based on the priority level and computational load of each cluster group, the cluster groups are dynamically bound to different cores of the multi-core processor, and a corresponding scheduling strategy is configured for each core.

[0021] Monitor the operating status of each core. When a core failure is detected, trigger the fault tolerance mechanism to migrate the tasks on the failed core to the redundant backup core and restore the task execution status using pre-synchronized data snapshots.

[0022] Furthermore, a preferred embodiment is provided, wherein the priority hierarchy includes:

[0023] The equipment importance, the degree of process impact, and the model real-time requirements are scored separately, with each dimension assigned 1 to 3 points according to preset standards;

[0024] Calculate the overall score S for each model, where S is the sum of the scores in the three dimensions;

[0025] When S≥8, it is determined to be at the core emergency level; when 5≤S≤7, it is determined to be at the important monitoring level; and when S≤4, it is determined to be at the auxiliary analysis level.

[0026] Furthermore, a preferred embodiment is provided, wherein the dynamic clustering includes:

[0027] Data affinity clustering: Based on direct data dependencies, shared input data, or associations with the same source data between models, models with frequent data interactions are clustered into one class;

[0028] Load balancing adjustment: Based on data affinity clustering, the preliminary clustering results are adjusted according to the priority and computational load of each model to ensure a balanced distribution of computational load among the cluster groups.

[0029] Furthermore, a preferred embodiment is provided, wherein dynamically binding cluster groups to different cores of a multi-core processor includes:

[0030] The different cores of the multi-core processor are divided into 4 groups;

[0031] Configure the first group of cores as dedicated P1 cores, bind them to the clusters of all cores with emergency priority, and adopt a preemptive scheduling mechanism;

[0032] The second core is configured as the P2 main core, bound to a portion of important monitoring-level clustering groups, and a time-sharing or periodic scheduling mechanism is adopted. Time slices are allocated according to the computational load of each model, while a predetermined proportion of computing resources are reserved for responding to the collaborative needs of core emergency-level tasks.

[0033] The third core is configured as a hybrid scheduling core, bound to the remaining important monitoring-level clustering groups and some auxiliary analysis-level clustering groups, and a priority adaptive scheduling mechanism is adopted.

[0034] The fourth core is configured as a redundant backup core, operating in dual mode. In normal processing mode, it binds some auxiliary analysis-level clustering groups, and in fault takeover mode, it takes over the tasks of other cores.

[0035] Furthermore, a preferred embodiment is provided, wherein allocating time slices according to the computational load of each model includes: for each model, assessing the computational load based on the computational resource consumption required for a single inference, and allocating the corresponding execution time slice length according to the relative proportion of the computational load of each model.

[0036] Furthermore, in a preferred embodiment, the method further includes the step of partitioning the on-chip shared cache of the multi-core processor:

[0037] The on-chip shared cache is divided into priority-specific partitions corresponding to priority levels, including P1, P2 and P3, each with different access permissions;

[0038] Within each priority-specific partition, it is further divided into cache sub-partitions according to cluster groups, and multiple models within the same cluster group share this cache sub-partition;

[0039] The size of the priority-specific partition is dynamically adjusted according to changes in on-site working conditions.

[0040] Furthermore, in a preferred embodiment, the method further includes a data preloading step:

[0041] Based on the clustering results and the data dependencies between models, the execution order and data preparation order of each model are derived.

[0042] While the current model is performing inference, the input data required by the model to be executed next is loaded from the main memory into the corresponding cache partition in advance; the cache partition is a priority-specific partition that matches the model priority, and a cache sub-partition corresponding to the cluster group to which the model belongs within the corresponding priority-specific partition.

[0043] Furthermore, in a preferred embodiment, the method further includes the step of dynamically adjusting the scheduling strategy according to the industrial production conditions:

[0044] Real-time monitoring of on-site operating conditions is achieved through the production status sensing module;

[0045] When a change in on-site operating conditions is detected, a dynamic adjustment mechanism is triggered:

[0046] Re-execute priority stratification: dynamically adjust the degree of process impact and model real-time requirements based on the current operating conditions, and recalculate the weighted score to realize online upgrading and downgrading of model priority;

[0047] Re-execute the binding and scheduling strategy configuration of cluster groups and cores: dynamically adjust the binding relationship and scheduling strategy of the industrial intelligent analysis model to which it belongs based on the current operating conditions.

[0048] The multi-core parallel processing system for industrial intelligent edge computing of the present invention is used to implement the multi-core parallel processing method for industrial intelligent edge computing as described in any of the above claims, and the system includes the following modules:

[0049] The model hierarchical module is used to prioritize multiple industrial intelligent analysis models deployed on industrial edge computing units. It performs weighted scoring based on three dimensions: equipment importance, process impact, and model real-time requirements. Based on the comprehensive score, the models are divided into core emergency level, important monitoring level, and auxiliary analysis level. Based on the data correlation and computing load between models, the multiple industrial intelligent analysis models are dynamically clustered to form several cluster groups.

[0050] The task scheduling module is used to dynamically bind cluster groups to different cores of a multi-core processor based on their priority level and computational load, and to configure corresponding scheduling strategies for each core; it also manages the on-chip shared cache of the multi-core processor by partitioning, performs data preloading, and dynamically adjusts the scheduling strategy according to industrial production conditions.

[0051] The fault tolerance module is used to monitor the operating status of each core. When a core failure is detected, the fault tolerance mechanism is triggered to migrate the tasks on the failed core to the redundant backup core and restore the task execution status using pre-synchronized data snapshots.

[0052] The data communication module is used to receive diverse industrial data and output model analysis results.

[0053] The present invention also proposes a computer storage medium storing a computer program, wherein when the computer program is executed, it performs the multi-core parallel processing method for industrial intelligent edge computing described in any of the above-mentioned embodiments.

[0054] The present invention has the following beneficial effects:

[0055] 1. The multi-core parallel processing method for industrial intelligent edge computing described in this invention effectively solves the resource competition problem when multiple models are running concurrently in industrial settings through the core scheduling strategy of "priority hierarchical - dynamic clustering - kernel affinity binding - fault redundancy backup" (4-core multi-model parallel scheduling). It ensures the hard real-time response of high-priority industrial intelligent models (such as safety protection and core quality control models) while ensuring the balanced utilization and high efficiency and stability of the overall system computing resources.

[0056] 2. The multi-core parallel processing method for industrial intelligent edge computing described in this invention significantly reduces communication latency and bandwidth consumption caused by cross-core data interaction between models by adopting a shared cache partitioning and data preloading mechanism, and reduces the overhead of frequent copying and repeated storage of data between different cores, thereby greatly improving the overall inference computing throughput and the processing efficiency of edge nodes.

[0057] 3. The multi-core parallel processing method for industrial intelligent edge computing described in this invention introduces a redundant backup core based on task snapshot and state recovery mechanism to obtain core fault tolerance capability. When a single-core hardware failure or task freeze occurs in the industrial edge computing unit, it can quickly take over all computing tasks on the faulty core, ensuring the continuity and reliability of intelligent analysis functions in the industrial field and avoiding production line shutdown due to single point of failure.

[0058] 4. The multi-core parallel processing method for industrial intelligent edge computing described in this invention, by combining dynamic scheduling and adjustment based on production condition perception, can flexibly adjust the clustering combination and core allocation ratio (computational load change) of various models according to different production stages such as production line start-up, stable production, and model changeover and debugging, as well as the load changes of the production line. This achieves (dynamic) precise adaptation of computing resources to production needs and enhances the robustness of the system in complex and ever-changing industrial environments.

[0059] The multi-core parallel processing method and system for industrial intelligent edge computing described in this invention are applicable to edge intelligent monitoring and analysis scenarios in industrial automated production lines, intelligent CNC machine tools, industrial robot clusters, and various discrete / process manufacturing. By using a multi-core processor to perform parallel scheduling of various industrial condition monitoring models, anomaly detection models, and quality analysis models, it achieves real-time and stable calculations of production equipment, production line units, and key process links, thereby improving the real-time performance, reliability, and resource utilization efficiency of intelligent analysis in industrial settings. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0061] Figure 1 This is a flowchart illustrating a multi-core parallel processing method for industrial intelligent edge computing in one embodiment of the present invention.

[0062] Figure 2 This is a schematic diagram illustrating the functional partitioning and core affinity allocation of a 4-core edge computing unit in one embodiment of the present invention.

[0063] Figure 3 A data flow diagram illustrating the application of a multi-core parallel processing method for industrial intelligent edge computing in a smart manufacturing production line, as described in one embodiment of the present invention.

[0064] Figure 4 This is a diagram of the interface of an industrial equipment condition monitoring and anomaly diagnosis simulation software in one embodiment of the present invention.

[0065] Figure 5 In one embodiment of the present invention, a diagram of the process of multi-core task binding and underlying resource monitoring is shown (terminal command line interface).

[0066] Figure 6 In one embodiment of the present invention, a background monitoring diagram of the multi-core parallel state after the fault tolerance mechanism is triggered (system resource and process status interface). Detailed Implementation

[0067] To make the technical solutions and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail and completely below with reference to the accompanying drawings. The various embodiments described below are only some preferred embodiments of the present invention, and not all of them; the various embodiments described below are intended to explain the present invention and should not be construed as limiting the present invention; reasonable combinations of the technical features defined in the various embodiments of the present invention, as well as all other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort, are all within the scope of protection of the present invention.

[0068] Implementation Method 1: Multi-core Parallel Processing Method for Industrial Intelligent Edge Computing

[0069] This implementation provides a 4-core multi-model parallel processing (or parallel computing) method for industrial intelligent scenarios, aiming to solve the resource scheduling and reliability problems of industrial edge computing nodes in multi-model concurrent scenarios; specifically:

[0070] It is used to ensure the real-time response of high-priority industrial intelligent models and can dynamically adapt to changes in different production stages, different production line loads and different model computational loads, reduce the latency of cross-core data interaction between models, and at the same time have core fault tolerance capabilities to ensure the continuous and reliable intelligent analysis function in the industrial field.

[0071] This method employs a 4-core parallel scheduling strategy. Its core idea follows four progressive stages: "priority hierarchical scheduling - dynamic clustering - core affinity binding - fault redundancy backup". The specific implementation steps are as follows:

[0072] Step 1: Model Prioritization Hierarchy and Dynamic Clustering:

[0073] Step 1.1: Input of diverse industrial data:

[0074] The industrial edge computing unit receives multi-dimensional industrial data in real time from field sensors, controllers, and production line systems, including but not limited to vibration, temperature, current, voltage, pressure, speed, visual images, and control status, as input sources for subsequent inference of various industrial intelligent analysis models.

[0075] Step 1.2: Model Priority Hierarchy:

[0076] Prioritize the various industrial intelligent analysis models (or industrial intelligent models, intelligent analysis models, intelligent models, or simply models) deployed in industrial sites.

[0077] The industrial intelligent analysis model refers to an algorithm program or computing module deployed in an industrial edge computing unit to process and infer multi-sensor data from industrial equipment, production line units, or process links in real time or periodically, in order to achieve functions such as equipment status monitoring, anomaly detection, quality analysis, life prediction, or assisted maintenance. The industrial intelligent analysis model includes, but is not limited to, equipment status monitoring models, anomaly detection models, quality analysis models, and assisted maintenance models.

[0078] The priority classification adopts a multi-dimensional weighted scoring model priority hierarchical method. It scores various industrial intelligent analysis models (hereinafter referred to as "models") deployed in industrial settings and classifies priorities based on total score ranges, thereby solving the problem of unreasonable classification caused by relying solely on a single dimension. Specifically:

[0079] (1) Define scoring dimensions and weights: The evaluation is based on three dimensions: equipment importance, process impact, and model real-time requirements. Each dimension is assigned a score of 1 to 3 points according to preset standards, with 3 points being the highest and 1 point being the lowest.

[0080] ① Equipment Importance Level: Based on the criticality of equipment in terms of production continuity, safety, and asset value, equipment is divided into three levels:

[0081] 3 points (core equipment): Equipment whose failure or shutdown will directly lead to production line shutdown, major safety accidents or huge economic losses, such as industrial robots, CNC machine tool spindles, key pump sets / compressors, power converters, etc.

[0082] 2 points (Important equipment): Equipment whose failure or downtime will affect the efficiency of local processes or product quality, but will not cause the entire line to stop, such as conveyor lines, temperature control systems, hydraulic stations, vision inspection equipment, etc.

[0083] 1 point (auxiliary equipment): Equipment whose failure or shutdown does not affect the current production process, but only affects auxiliary functions, such as energy consumption statistics module, auxiliary tooling, log server, etc.

[0084] ② Level of Process Impact: Based on the degree of direct intervention in the production process by the model output results, it is divided into three levels:

[0085] 3 points (direct impact): The model output results are directly used for safety protection, emergency shutdown or core quality judgment, etc. Delay or error will lead to safety risks or batch scrapping;

[0086] 2 points (indirect impact): The model output results are used for process parameter optimization, equipment status assessment or routine quality inspection. Their delay or deviation will affect process efficiency or product quality fluctuations, but will not directly lead to safety risks.

[0087] 1 point (virtually no impact): The model output is used for statistical analysis, log archiving, or decision support, and its delay or bias has no substantial impact on current production.

[0088] ③ Model Real-Time Requirement Levels: Based on the model's tolerance for response latency and task interruption, it is divided into three levels:

[0089] 3 points (Hard Real-Time): The model is required to complete inference and output results within a very short time (e.g., no more than 10 milliseconds) after receiving input data, and this execution process cannot be interrupted by any other task. Once a timeout or interruption occurs, it will lead to serious consequences.

[0090] 2 points (soft real-time): The model is required to complete inference and output results within a specified period (e.g., once per second or per minute). It is allowed to be temporarily interrupted by higher priority tasks during execution, but execution must continue after the interruption ends and be made up in the current period or the next period.

[0091] 1 point (non-real-time): The model has no strict time constraints, is allowed to execute when the system is idle, can wait for a long time or delay the output, and can be interrupted at will without adverse consequences.

[0092] (2) Calculate the overall score of the model: For each model, determine its score in the three dimensions according to the above criteria, and sum them up to calculate the overall score S of the model:

[0093] S = Equipment importance score + Process impact score + Real-time requirement score;

[0094] (3) Based on the calculated comprehensive score S, all models are divided into three priority levels, and the specific division criteria are as follows:

[0095] ①P1 level (core emergency level):

[0096] When the comprehensive score S of an industrial intelligent analysis model is ≥ 8, its priority is determined to be P1 level:

[0097] The scheduling strategy for the P1-level model is a preemptive scheduling strategy. The system must guarantee that the P1-level model obtains the highest execution priority, executes immediately once ready, and is not interrupted by any other task during execution, ensuring that the response latency does not exceed 10 milliseconds.

[0098] For example, models for condition monitoring and fault early warning of core equipment such as industrial robots, CNC machine tool spindles, key pump sets / compressors, and power converters, as well as core quality control models.

[0099] ②P2 level (important monitoring level):

[0100] When the overall score of an industrial intelligent analysis model is 5≤S≤7, its priority is determined to be P2 level.

[0101] The scheduling strategy for the P2 level model is to adopt either time-sharing or periodic scheduling. The system allocates time slices according to the computational load of the model, allowing preemption and interruption when a P1 level task is ready, but the interrupted task must be resumed in the current or next cycle.

[0102] For example, models for condition assessment and anomaly detection of important equipment such as conveyor lines, temperature control systems, hydraulic stations, and visual inspection equipment, as well as process stability analysis models.

[0103] ③P3 level (auxiliary analysis level):

[0104] When the comprehensive score S≤4 of a certain industrial intelligent analysis model, its priority is determined to be level P3:

[0105] The scheduling strategy for the P3-level model is an adaptive priority scheduling strategy. It does not participate in real-time scheduling contention, but utilizes idle system CPU resources for asynchronous processing, allowing for long delays.

[0106] For example, a model that performs energy consumption analysis, log analysis, and provides auxiliary maintenance suggestions for auxiliary units such as energy consumption statistics modules, auxiliary tooling, and equipment logs.

[0107] Table 1 Priority Classification of Industrial Intelligent Analysis Models

[0108]

[0109] Step 1.3: Dynamic Clustering:

[0110] Considering the resource limitations of a quad-core chip and the data correlations between models, this step employs a dynamic clustering strategy. Multiple industrial intelligent analysis models are divided into several cluster groups, each of which will subsequently be bound to the same processor core to achieve a reasonable match between model tasks and processor cores. The dynamic clustering strategy includes the following two sub-steps:

[0111] (1) Data affinity clustering:

[0112] First, preliminary clustering is performed based on the frequency of data interaction between models. The clustering rule is to group models with frequent data interactions into one category, such as status monitoring, anomaly diagnosis, and fault early warning models for the same equipment, or quality inspection, process parameter analysis, and equipment status assessment models for the same production line station. This avoids latency and bandwidth consumption caused by frequent data transmission between different cores, while also reducing the overhead of redundant data storage and retrieval.

[0113] The "models with frequent data interactions" are determined based on the data dependencies and the degree of data sharing between models:

[0114] Direct data dependency: If the output data of one model is directly used as the input data of another model, then these two models are "models with frequent data interaction" and should be clustered into one class. For example, the output (spectral features) of the vibration feature extraction model is directly input into the fault diagnosis model, and the two have a direct data dependency relationship and should be clustered into one class.

[0115] Shared input data: If multiple models share the same set of sensor data or intermediate feature data as input, these models are "models with frequent data interaction" and should be clustered into one category. For example, temperature monitoring models, vibration monitoring models, and current monitoring models for the same device all use the device's raw sensor data as input, and the three should be clustered into one category.

[0116] Related data from the same source: If multiple models process data originating from the same physical entity (such as the same equipment, the same production line station, or the same process step), and these models have a temporal execution relationship or a logical complementary relationship, then these models are "models with frequent data interaction" and should be clustered into one category. For example, a quality inspection model, a process parameter analysis model, and an equipment status assessment model for the same production line station all process data originating from that station, and their analysis results corroborate each other; therefore, they should be clustered into one category.

[0117] (2) Load balancing adjustment:

[0118] Based on data affinity clustering, the preliminary clustering results are adjusted according to the priority and computational cost of each model, so that the total computational load of each cluster group is distributed as evenly as possible within the 4-core resource range, avoiding overload of a single core or idle resources, thereby ensuring the high efficiency and stability of the overall scheduling.

[0119] Specific adjustment methods include: splitting clusters with excessive computational cost into multiple smaller groups, or merging clusters with insufficient computational cost into other groups, while trying to maintain data affinity as much as possible.

[0120] Through the above two sub-steps, a cluster group that satisfies both data affinity and load balancing is finally obtained, which serves as the input for subsequent kernel affinity allocation.

[0121] Through the above two sub-steps, a set of clusters that satisfy both data affinity and load balancing is finally obtained, serving as the input for subsequent kernel affinity allocation. Wherein:

[0122] After dynamic clustering, if all models in a group are at the P1 level, it is called a P1-level cluster group; if all models in a group are at the P2 level, it is called a P2-level cluster group; and if all models in a group are at the P3 level, it is called a P3-level cluster group.

[0123] Step 2: Nuclear affinity allocation:

[0124] This step binds the cluster groups obtained in step 1 to the cores of the multi-core processor in the industrial edge computing unit and configures a corresponding scheduling strategy for each core. For ease of description, this embodiment uses a 4-core processor as an example, but those skilled in the art should understand that this method is equally applicable to other numbers of multi-core processors.

[0125] Step 2.1: Dynamic partitioning and binding of kernel functions:

[0126] Based on the priority level and computational load of each cluster group, the cluster groups are dynamically allocated to different cores, and corresponding scheduling strategies are configured:

[0127] Core 1 (as a dedicated P1 core): Binds to all P1-level cluster groups, dedicated to handling high-priority tasks such as security protection, critical equipment anomalies, and core quality control. Employs a preemptive scheduling mechanism to ensure that tasks in the P1-level model gain execution rights as soon as they are ready, and are not interfered with by other priority tasks during execution.

[0128] Core 2 (as the P2 master core): Binds most (more than half) of the P2-level clustering groups. Employs time-sharing or periodic scheduling mechanisms, allocating time slices based on the computational load of each model. Simultaneously, a predetermined proportion (e.g., 20%) of computing resources is reserved to respond to temporary collaborative needs of P1-level models (e.g., when P1-level models require multi-core parallel acceleration). Specifically, time slice allocation based on computational load is as follows: For each P2-level model, its computational load is assessed based on the computational resource consumption required for a single inference (including data preprocessing overhead, model inference time, and post-processing overhead), and the corresponding execution time slice length is allocated according to the relative proportion of computational load among models; models with higher computational loads are allocated longer time slices, and models with lower computational loads are allocated shorter time slices, thus ensuring that each model can complete its inference task within its required cycle.

[0129] Core 3 (as a hybrid scheduling core): Binds the remaining P2-level cluster groups and some P3-level cluster groups. Employs a priority-adaptive scheduling mechanism: when the task load of P1 or P2-level models increases, P3-level tasks are paused to prioritize the execution of P2-level tasks; when the system load is low, P3-level tasks are processed with full force.

[0130] Core 4 (as a redundant backup core): operates in dual modes, specifically including:

[0131] Normal processing mode: Bind some P3-level cluster groups to help improve the processing efficiency of P3-level tasks;

[0132] Fault takeover mode (or backup mode): When any core from core 1 to core 3 fails, core 4 automatically switches to this mode, takes over all tasks on the failed core, and restores the task execution state through task snapshot and state recovery mechanisms to ensure that the industrial intelligent analysis function is not interrupted.

[0133] Step 2.2: Shared cache partition:

[0134] To reduce the latency of cross-core data interaction between models, a strategy of "shared cache partition + data preloading" is designed. Specifically:

[0135] Shared Cache Partitioning: This step involves logically partitioning the on-chip shared cache of a multi-core processor (hereinafter referred to as "processor"). The on-chip shared cache refers to the Last-Level Cache (LLC), accessible to all cores within the processor, such as L3 or L4 cache. This implementation uses a 4-core processor (or 4-core chip) as an example, but those skilled in the art should understand that this method is equally applicable to processors with other numbers of cores.

[0136] (1) Priority-specific partitioning:

[0137] Based on the three established priority levels, the on-chip shared cache storage space is divided into three logically independent priority-specific partitions: P1, P2, and P3.

[0138] The partitioning method can adopt hardware-supported logical partitioning methods such as address range mapping or cache way allocation, so that each partition is physically isolated from each other and does not encroach on each other's space.

[0139] P1 area: Dedicated to storing data (including input data, intermediate features, model parameters, etc.) of P1-level models and their respective cluster groups. This partition has the highest access privileges. Tasks executing P1-level models can exclusively use this partition, and P2-level and P3-level tasks have no right to write to or replace cache lines in the P1 area, thus preventing high-priority model data from being contaminated or evicted by low-priority tasks.

[0140] P2 area: Dedicated to storing data for P2-level models and their respective cluster groups. This partition has the second-highest access permission, allowing tasks of P2-level models to read and write, but P1-level tasks can temporarily borrow cached resources in the P2 area through a priority preemption mechanism when necessary (with the scheduler's permission), while P3-level tasks do not have permission to access the P2 area.

[0141] P3 partition: Dedicated to storing data for P3-level models and their respective cluster groups. This partition has minimal access permissions, allowing only tasks of P3-level models to use it. When the load on P1 or P2-level tasks increases, the scheduler can reclaim some cache resources in the P3 partition for use by higher-priority tasks. The scheduler refers to a task scheduling module running in the operating system kernel of the industrial edge computing unit, or a hardware scheduling unit integrated into the firmware of a multi-core processor. Its responsibilities include: managing the task queues of each core, monitoring core load, triggering cache prefetch instructions, and maintaining cross-core data consistency.

[0142] (2) Shared sub-partitions within cluster groups:

[0143] Within each priority-specific partition, it is further subdivided according to cluster groups, with a cache sub-partition allocated to each cluster group. Multiple models within the same cluster group share this sub-partition, thus:

[0144] Reduce redundant data loading: The data required by the model within the same cluster group (such as shared raw sensor data) only needs to be loaded into the sub-partition once, and subsequent models can reuse it directly;

[0145] Reduce cross-core communication overhead: Since models in the same cluster group are bound to the same core, their data access is completed within the local core's cache sub-partition, without the need for cross-core transmission.

[0146] (3) Dynamic adjustment of zones:

[0147] The size of the aforementioned priority-specific partitions is not fixed but can be dynamically adjusted according to changes in industrial production conditions. For example, when the production line enters the anomaly handling phase, the load on P1-level tasks surges, and the scheduler can temporarily expand the capacity of the P1 partition and compress the capacity of the P3 partition to ensure the data caching needs of high-priority tasks.

[0148] Step 2.3: Data preloading:

[0149] To reduce data reading latency during model execution, this step designs a data preloading mechanism based on model execution order and data dependencies. This mechanism is uniformly coordinated and executed by the scheduler.

[0150] (1) Preloading timing and objectives:

[0151] Based on the cluster group division results determined in step 1.3 and the data dependencies between models (i.e., the execution order implied by direct data dependencies, the parallel loading strategy required by shared inputs, and the temporal relationship determined by homologous associations), the scheduler derives the execution order and data preparation order of each model. Combined with the cache partitioning plan established in step 2.2 (including priority-specific partitions and cache sub-partitions within cluster groups), while the current model is executing inference, the scheduler preloads the input data (such as raw sensor data, feature data, model parameters, etc.) required by the models to be executed later from main memory (DDR) into the corresponding cache partitions. These cache partitions refer to priority-specific partitions (P1, P2, or P3) that match the model's priority, and the corresponding cache sub-partitions within the corresponding priority partitions of the cluster group to which the model belongs. Specifically:

[0152] For models with direct data dependencies (e.g., the output of model A is the input of model B), the scheduler will prefetch the model parameters and initial input data required by model B during the execution of model A;

[0153] For models that share input data (e.g., multiple models share the same set of sensor data), the scheduler will load the shared data into the shared cache sub-partition once when the first model is executed, and subsequent models can reuse it directly.

[0154] For models with related data from the same source (such as different analysis models of the same device), the scheduler will prefetch the data required by each model in sequence according to the time sequence relationship.

[0155] (2) Specific implementation method of preloading:

[0156] The scheduler preloads data by sending prefetch instructions to the processor. These prefetch instructions can be non-blocking, meaning that after issuing a prefetch request, the scheduler returns immediately to continue executing the current task without waiting for the data to finish loading; the memory controller at the processor's backend completes the data transfer during idle periods. This approach leverages the overlap between computation and memory access, effectively hiding memory access latency.

[0157] (3) Write-back mechanism and cross-core data consistency:

[0158] To ensure data consistency when multiple cores access shared data simultaneously, this method employs a write-back cache consistency protocol. Under this protocol:

[0159] When a core modifies data in its private cache, the modification is only reflected in that core's cache and is not written back to main memory immediately.

[0160] When other cores need to access the same data block, they listen or query the directory through a cache consistency protocol (such as the MESI protocol) to ensure that other cores obtain the latest modified data (i.e., directly obtained from the modified core cache, rather than read from main memory).

[0161] The final result is written back to main memory only when the cache line is replaced or explicitly flushed.

[0162] The advantages of the write-back mechanism are:

[0163] This reduces frequent main memory write operations and lowers bus bandwidth usage;

[0164] Combined with data preloading, the prefetched data can be directly written to the cache without having to write to main memory first and then read from the cache, further shortening the data path;

[0165] By automatically maintaining the latest version of cross-core data through a hardware consistency protocol, the additional overhead caused by software synchronization is avoided.

[0166] (4) The synergistic effect of preloading and write-back:

[0167] Through the combined efforts of the aforementioned preloading mechanism and the write-back consistency protocol, when subsequent models begin execution, the data they require is highly likely already present in the local cache of the corresponding core (high hit rate), thereby significantly reducing data read latency. Simultaneously, because the write-back mechanism reduces the frequency of main memory writes, bus bandwidth is freed up, further improving the overall system throughput.

[0168] Step 2.4: Industrial Production Condition Judgment and Dynamic Adjustment:

[0169] Changes in the production stages and equipment operating conditions in industrial settings (such as production line startup, stable production, and abnormal handling) will cause dynamic changes in the model's computational load and priority. To ensure that the multi-core processor is always in an optimal working state, this step designs a dynamic feedback adjustment mechanism based on operating condition awareness (or a dynamic adjustment mechanism for multi-core task scheduling).

[0170] Step 2.4.1: Operating Condition Sensing and Triggering:

[0171] The system monitors the on-site working conditions in real time through the production status perception module, and obtains current working condition information, such as the production line start-up, stable production, changeover and debugging, abnormal handling and maintenance window.

[0172] When a change in the current industrial production condition is detected (e.g., from "stable production" to "abnormal handling"), the system determines that dynamic adjustment is required and triggers a feedback mechanism to re-enter the dynamic division and binding of the computing core function in step 2.1.

[0173] Step 2.4.2: Dynamically adjust the strategy:

[0174] When dynamic adjustment is triggered, the system dynamically adjusts the clustering groups and core allocation strategies of existing models based on new operating conditions to adapt to load changes:

[0175] Scenarios with sudden load increases (e.g., production line startup or handling of abnormalities):

[0176] At this point, the load on the P1 level (safety protection, core quality control) model surges. The system will perform the following adjustments:

[0177] Resource reallocation: The predetermined proportion (e.g., 20%) of computing resources reserved by Core 2 (P2 main core) is fully released, and Core 1 (P1 dedicated core) works together to handle the surge in P1-level tasks.

[0178] Task degradation: Core 3 (hybrid scheduling core) suspends some low-priority P3 level tasks (such as energy consumption statistics and log analysis) to prioritize the execution of P2 level equipment status assessment and process monitoring tasks.

[0179] Load balancing scenarios (e.g., stable production):

[0180] At this point, the system load is stable. The system will restore the default allocation strategy, with some resources released from core 2 being reallocated to P2-level tasks, and core 3 resuming normal processing of P3-level auxiliary analysis tasks to ensure maximum overall resource utilization.

[0181] Through the above dynamic adjustments, this method achieves adaptive optimal allocation of computing resources under complex and variable working conditions in industrial settings.

[0182] Step 3: Fault Tolerance and Task Migration

[0183] To improve the reliability of industrial edge computing systems, this step designs a fault tolerance mechanism based on redundant backup cores. This ensures that when any computing core fails, tasks can be automatically migrated (to other cores) and the state can be restored, guaranteeing uninterrupted industrial intelligent analysis functions.

[0184] Step 3.1: Synchronize runtime status and save data snapshots:

[0185] Core 4 serves as a redundant backup core. While running in normal processing mode, it synchronizes the running status of all tasks on cores 1 through 3 in real time and periodically saves data snapshots of each task, specifically including:

[0186] (1) Execution status synchronization:

[0187] Core 4 obtains the execution status information of each task on Cores 1 to 3 in real time through the inter-core communication channel.

[0188] The execution status information includes, but is not limited to: the current scheduling stage of the task (ready, running, suspended, or blocked), the priority level of the task, the core number bound to the task, the task heartbeat information, and the timestamp of the last execution completion. The real-time requirements for execution status synchronization are high, aiming to enable core 4 to monitor the macro-level operation of tasks on each core at any time.

[0189] (2) Data snapshot saving:

[0190] Core 4 periodically or at key execution nodes (such as when model inference completes an iteration or generates intermediate results) saves data snapshots for each task.

[0191] A data snapshot is a fixed record of the task's runtime context at a specific point in time, including but not limited to: the current intermediate calculation results of each task, model parameters and weights, cache status, program counter, register status, input data pointers, and output buffers. Data snapshots are used to provide a recoverable micro-level runtime data foundation for the task in the event of a failure.

[0192] (3) The synergistic relationship between the two:

[0193] Execution status information and data snapshots constitute two complementary elements of fault recovery:

[0194] The execution status information serves as a "macro index," indicating "which tasks need to be taken over and what scheduling stage they are currently in."

[0195] Data snapshots, as "micro-entities," provide "specific data on where the task continues to be executed."

[0196] When a failure occurs, core 4 first determines the set of tasks to be taken over and their scheduling attributes based on the synchronized execution status information. Then, it restores the runtime context of each task using the most recently saved data snapshot, ensuring that the tasks are executed continuously from the point of interruption, rather than starting from the beginning, thereby achieving seamless recovery.

[0197] The redundant backup core architecture used in this embodiment differs fundamentally from the "lockstep" fault-tolerance mechanism commonly found in traditional industrial control. Traditional lockstep schemes typically require a pair of identical computing cores, both executing the same instruction stream simultaneously to compare results in real time and detect faults. While this approach is logically simple, it has significant drawbacks in resource-constrained scenarios like industrial edge computing: the backup core remains in full-speed computing mode for extended periods, resulting in the prolonged and ineffective use of valuable computing resources and electrical energy, greatly increasing the heat dissipation pressure and hardware costs of edge nodes.

[0198] In contrast, the redundant backup core (core 4) employs an intelligent strategy of "hot standby and silent awareness".

[0199] In normal processing mode: the standby core is released to a non-computing state and only maintains task status information. That is, the standby core (core 4) does not continuously execute heavy model inference tasks like the main core, but mainly maintains a low-power standby or silent state. It only uses a lightweight bus listening or interrupt mechanism to synchronize the execution status of all tasks on cores 1 to 3 in real time and periodically capture data snapshots. This design concept greatly reduces the system energy consumption during normal operation and concentrates the limited edge computing power on the front-end business processing.

[0200] In failover mode: When an anomaly is detected in the computing core, the backup core (core 4) is quickly activated. Based on the task snapshot and model execution status, the task takeover is completed quickly. While ensuring zero-interruption fault tolerance for single-core failures, it cleverly avoids the long-term computing power waste problem caused by traditional multi-replica fault tolerance methods, perfectly meeting the stringent requirements of industrial edge computing devices for low power consumption and high resource utilization.

[0201] Step 3.2: Core operating status acquisition:

[0202] The core status monitoring module collects real-time operating status parameters of each computing core, including but not limited to instruction execution cycle, core temperature, operating voltage, CPU utilization, and heartbeat signal.

[0203] Step 3.3: Core Fault Detection:

[0204] Analyze the collected operational status parameters to determine if any core components have malfunctioned. Fault determination criteria include:

[0205] The instruction execution cycle exceeded the preset threshold;

[0206] The core is unresponsive or the heartbeat signal is lost;

[0207] The core temperature exceeds the safe operating range;

[0208] Other abnormal indicators.

[0209] Step 3.4: Computation Task Migration and Recovery:

[0210] When a failure is detected in any core (core 1 through core 3), the fault tolerance mechanism is immediately triggered:

[0211] Task takeover: Core 4 (redundant backup core) automatically switches from normal processing mode to fault takeover mode, taking over all tasks on the faulty core;

[0212] State recovery: Core 4 uses pre-synchronized data snapshots to quickly restore the execution state of each task, ensuring that tasks continue (continuously) from the point of interruption, rather than starting from the beginning;

[0213] Load redistribution: Return to step 2.1 to re-execute the dynamic partitioning and binding of computing cores. The scheduler readjusts the task allocation of each core based on the resource status of the remaining available cores to avoid overloading the remaining cores.

[0214] Through the above mechanism, this method achieves zero-interruption task migration in the event of a single-core failure, significantly improving the reliability and robustness of industrial edge computing systems.

[0215] Implementation method 2: The working condition perception and triggering steps also include a dynamic priority update mechanism for model priority hierarchy:

[0216] The aforementioned priority hierarchy is not static; the system also incorporates a dynamic priority update mechanism to adapt to the complex and ever-changing working conditions in industrial settings. Specifically:

[0217] The system first determines the model's "basic priority" based on the importance of the equipment, the degree of process impact, and the model's real-time requirements;

[0218] During system operation, when the production status perception module detects changes in on-site conditions such as production line startup, stable production, changeover debugging, abnormal handling, or maintenance windows, the system will dynamically adjust the "degree of process impact" and "real-time score" based on the current conditions, and recalculate the comprehensive score S, thereby realizing online upgrading and downgrading of model priority.

[0219] For example, during the normal and stable production phase of the production line, the monitoring model of some key equipment may only need to maintain a low background scan frequency; however, once the system detects that "changeover and commissioning" has begun and the status of the equipment fluctuates frequently, the system will dynamically increase its process impact level and real-time score, thus raising its priority.

[0220] When priorities change, the system will synchronously trigger system-wide resource rebinding instructions, specifically including: dynamically adjusting the cluster group to which the model belongs, replanning core binding relationships, adjusting the size of the on-chip shared cache partition, and updating the takeover order list of redundant backup cores. Through this end-to-end dynamic linkage, the system can ensure that it maintains optimal resource matching and computational efficiency under any operating conditions.

[0221] Implementation Method 3: Application of Multi-core Parallel Processing Method for Industrial Intelligent Edge Computing in a Smart Manufacturing Production Line:

[0222] This embodiment takes an equipment status monitoring and anomaly diagnosis system for a smart manufacturing production line as an example to further illustrate the specific implementation of the present invention.

[0223] Multiple industrial intelligent analysis models are deployed and run on the Xiangchengpai AIpro hardware platform; the scheduling strategy of this invention is implemented using a 4-core processor, and the processing results are transmitted back to industrial simulation software or production line monitoring platform via Ethernet.

[0224] Using industrial equipment condition monitoring and anomaly diagnosis simulation software, the model calculation results of 19 key equipment, workstation modules and auxiliary units in a certain intelligent manufacturing production line were read and analyzed.

[0225] Execution Step 1: Model Priority Hierarchy:

[0226] The key equipment and model tasks in the industrial field were prioritized. Based on the importance of the equipment, the degree of process impact, and the real-time requirements, the 19 industrial intelligent analysis models were divided into three priority levels, P1 to P3, as shown in Table 2.

[0227] Table 2 Component (Priority) Classification Information

[0228]

[0229] Step 2: Initial clustering and kernel affinity binding:

[0230] Multi-core task binding is performed, and the tasks bound to each core are described below:

[0231] Core 1 (as a dedicated P1 core): Binds all four P1-level industrial intelligent analysis models, including the industrial robot joint servo anomaly detection model, the CNC machine tool spindle status early warning model, the critical pump / compressor fault diagnosis model, and the power converter / drive cabinet safety monitoring model. A preemptive scheduling mechanism is employed to ensure that the task response latency of all P1-level models does not exceed 10 milliseconds and is not interfered with by other priority tasks.

[0232] Core 2 (as the P2 master core): This core is responsible for binding six key monitoring models with close data interaction within the P2 level, including the conveyor drive unit status monitoring model, the visual inspection camera quality assessment model, the temperature control system status evaluation model, the hydraulic station health monitoring model, the pneumatic system fault diagnosis model, and the welding power supply stability analysis model. A time-sharing scheduling mechanism is employed, allocating time slices according to the computational load of each model, while reserving a predetermined proportion (e.g., 20%) of computing resources to respond to temporary collaborative needs of the P1 level models.

[0233] Core 3 (as a hybrid scheduling core): Binds the remaining 6 P2-level models and 1 P3-level model. The P2-level models include the AGV scheduling status assessment model, the automated warehouse lifting mechanism monitoring model, the environmental sensor gateway status diagnosis model, the PLC controller operation status monitoring model, the MES edge gateway communication quality assessment model, and the quality detection model drift analysis model; the P3-level model is the energy consumption statistical analysis model. A priority adaptive scheduling mechanism is adopted, prioritizing the execution of tasks from the P2-level models.

[0234] Core 4 (as a redundant backup core): operates in dual modes. In normal processing mode, it is bound to the remaining two P3-level auxiliary analysis models, namely the auxiliary tooling status analysis model and the device log analysis model, to help improve the processing efficiency of P3-level tasks; at the same time, it synchronizes the execution status and data snapshots of all tasks on cores 1 to 3 in real time, and has the ability to take over faults.

[0235] During production line startup or anomaly handling, the computational workload of P1-level model tasks surges. Core 2 activates a predetermined proportion (e.g., 20%) of its reserved computing resources to work with Core 1 to process P1-level models. Core 3 suspends some P3-level auxiliary analysis tasks to fully ensure the execution of P2-level tasks such as critical equipment status assessment models and process monitoring models.

[0236] Step 3: Simulate a core fault to trigger the fault tolerance mechanism:

[0237] If Core 2 fails, Core 4 (redundant backup core) immediately switches from normal processing mode to fault takeover mode. It restores the execution status of models such as conveyor lines, vision inspection, temperature control, hydraulics, pneumatics, and welding power supply on Core 2 through pre-synchronized data snapshots and takes over the task execution. At the same time, the scheduler temporarily migrates some P2-level tasks on Core 3 to Core 4 to avoid overloading Core 3.

[0238] Through the above implementation methods, 19 industrial intelligent analysis models have achieved efficient parallel processing on a quad-core processor: the task response latency of the P1 level model is no more than 8 milliseconds, the task response latency of the P2 level model is no more than 40 milliseconds, and the task migration time during core failures is no more than 5 milliseconds, which can meet the requirements of real-time performance, reliability and resource utilization efficiency of multi-model parallel computing in industrial intelligent scenarios.

[0239] The above description of several specific embodiments further details the technical solution provided by the present invention in order to highlight the advantages and benefits of the technical solution provided by the present invention. However, the above-described specific embodiments are not intended to limit the present invention. Any reasonable modifications and improvements to the present invention, reasonable combinations of embodiments, and equivalent substitutions based on the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-core parallel processing method for industrial intelligent edge computing, characterized in that, The method includes the following steps: Multiple industrial intelligent analysis models deployed on industrial edge computing units are prioritized and hierarchically classified. Weighted scores are applied based on three dimensions: equipment importance, process impact, and model real-time requirements. The models are then divided into core emergency level, important monitoring level, and auxiliary analysis level based on the comprehensive score. Based on the data correlation and computational load between models, the multiple industrial intelligent analysis models are dynamically clustered to form several cluster groups. Based on the priority level and computational load of each cluster group, the cluster groups are dynamically bound to different cores of the multi-core processor, and a corresponding scheduling strategy is configured for each core. Monitor the operating status of each core. When a core failure is detected, trigger the fault tolerance mechanism to migrate the tasks on the failed core to the redundant backup core and restore the task execution status using pre-synchronized data snapshots.

2. The multi-core parallel processing method for industrial intelligent edge computing according to claim 1, characterized in that, The priority hierarchy includes: The equipment importance, the degree of process impact, and the model real-time requirements are scored separately, with each dimension assigned 1 to 3 points according to preset standards; Calculate the overall score S for each model, where S is the sum of the scores in the three dimensions; When S≥8, it is determined to be at the core emergency level; when 5≤S≤7, it is determined to be at the important monitoring level; and when S≤4, it is determined to be at the auxiliary analysis level.

3. The multi-core parallel processing method for industrial intelligent edge computing according to claim 1, characterized in that, The dynamic clustering includes: Data affinity clustering: Based on direct data dependencies, shared input data, or associations with the same source data between models, models with frequent data interactions are clustered into one class; Load balancing adjustment: Based on data affinity clustering, the preliminary clustering results are adjusted according to the priority and computational load of each model to ensure a balanced distribution of computational load among the cluster groups.

4. The multi-core parallel processing method for industrial intelligent edge computing according to claim 1, characterized in that, The method of dynamically binding cluster groups to different cores of a multi-core processor includes: The different cores of the multi-core processor are divided into 4 groups; Configure the first group of cores as dedicated P1 cores, bind them to the clusters of all cores with emergency priority, and adopt a preemptive scheduling mechanism; The second core is configured as the P2 main core, bound to a portion of important monitoring-level clustering groups, and a time-sharing or periodic scheduling mechanism is adopted. Time slices are allocated according to the computational load of each model, while a predetermined proportion of computing resources are reserved for responding to the collaborative needs of core emergency-level tasks. The third core is configured as a hybrid scheduling core, bound to the remaining important monitoring-level clustering groups and some auxiliary analysis-level clustering groups, and a priority adaptive scheduling mechanism is adopted. The fourth core is configured as a redundant backup core, operating in dual mode. In normal processing mode, it binds some auxiliary analysis-level clustering groups, and in fault takeover mode, it takes over the tasks of other cores.

5. The multi-core parallel processing method for industrial intelligent edge computing according to claim 4, characterized in that, The allocation of time slices based on the computational load of each model includes: for each model, assessing the computational load required for a single inference run, and allocating the corresponding execution time slice length according to the relative proportion of the computational load of each model.

6. The multi-core parallel processing method for industrial intelligent edge computing according to claim 1, characterized in that, The method also includes the step of partitioning the on-chip shared cache of a multi-core processor: The on-chip shared cache is divided into priority-specific partitions corresponding to priority levels, including P1, P2 and P3, each with different access permissions; Within each priority-specific partition, it is further divided into cache sub-partitions according to cluster groups, and multiple models within the same cluster group share this cache sub-partition; The size of the priority-specific partition is dynamically adjusted according to changes in on-site working conditions.

7. The multi-core parallel processing method for industrial intelligent edge computing according to claim 6, characterized in that, The method also includes a data preloading step: Based on the clustering results and the data dependencies between models, the execution order and data preparation order of each model are derived. While the current model is performing inference, the input data required by the model to be executed next is loaded from the main memory into the corresponding cache partition in advance; the cache partition is a priority-specific partition that matches the model priority, and a cache sub-partition corresponding to the cluster group to which the model belongs within the corresponding priority-specific partition.

8. The multi-core parallel processing method for industrial intelligent edge computing according to claim 1, characterized in that, The method also includes the step of dynamically adjusting the scheduling strategy according to industrial production conditions: Real-time monitoring of on-site operating conditions is achieved through the production status sensing module; When a change in on-site operating conditions is detected, a dynamic adjustment mechanism is triggered: Re-execute priority stratification: dynamically adjust the degree of process impact and model real-time requirements based on the current operating conditions, and recalculate the weighted score to realize online upgrading and downgrading of model priority; Re-execute the binding and scheduling strategy configuration of cluster groups and cores: dynamically adjust the binding relationship and scheduling strategy of the industrial intelligent analysis model to which it belongs based on the current operating conditions.

9. A multi-core parallel processing system for industrial intelligent edge computing, used to implement the multi-core parallel processing method for industrial intelligent edge computing as described in any one of claims 1 to 8, characterized in that, The system includes the following modules: The model hierarchical module is used to prioritize multiple industrial intelligent analysis models deployed on industrial edge computing units. It performs weighted scoring based on three dimensions: equipment importance, process impact, and model real-time requirements. Based on the comprehensive score, the models are divided into core emergency level, important monitoring level, and auxiliary analysis level. Based on the data correlation and computing load between models, the multiple industrial intelligent analysis models are dynamically clustered to form several cluster groups. The task scheduling module is used to dynamically bind cluster groups to different cores of a multi-core processor based on the priority level and computing load of each cluster group, and to configure a corresponding scheduling strategy for each core. It also manages the on-chip shared cache of multi-core processors by partitioning, performs data preloading, and dynamically adjusts the scheduling strategy according to industrial production conditions. The fault tolerance module is used to monitor the operating status of each core. When a core failure is detected, the fault tolerance mechanism is triggered to migrate the tasks on the failed core to the redundant backup core and restore the task execution status using pre-synchronized data snapshots. The data communication module is used to receive diverse industrial data and output model analysis results.

10. A computer storage medium, characterized in that, The storage medium stores a computer program, which, when executed, performs the multi-core parallel processing method for industrial intelligent edge computing as described in any one of claims 1 to 8.

Images