Software-defined industrial switch system based on multi-core processor

Abstract

The invention relates to the technical field of packet switching, in particular to a software-defined industrial switch system based on a multi-core processor, which comprises a control mapping module, a core group configuration module, a path adjustment module, a channel scheduling module and a frequency control cutting module. According to the method, quantitative identification of task depth and execution complexity is realized through hierarchical tagging processing of a control task path structure, and a multi-class mapping relation between tasks and cores is constructed in combination with performance characteristics of a multi-core processor, so that the resource matching accuracy and scheduling flexibility are improved; based on a task execution state, access and interruption characteristics are extracted, path offset behaviors are dynamically identified, real-time kernel redistribution is completed, the continuity and scheduling balance of a task execution process are guaranteed, a priority and channel state mapping mechanism is introduced in the aspect of communication path selection, linkage constraint and cutting optimization of processor frequency and resource distribution are realized, and the task execution efficiency is improved. And the adaptability of the system to complex working conditions and the communication load management capability are enhanced.

Description

Technical Field

[0001] This invention relates to the field of packet switching technology, and in particular to a software-defined industrial switch system based on a multi-core processor. Background Technology

[0002] Packet switching technology involves communication technologies that transmit data in packet form over a network, and is a core component of modern computer networks and communication systems. This technology primarily includes packet construction and parsing, routing and forwarding mechanisms, the structural design of switching nodes, the adaptation and management of communication protocols, network congestion control mechanisms, quality of service (QoS) assurance methods, and various control strategies related to network architecture. Packet switching is widely used in various communication scenarios, including the Internet, enterprise LANs, wireless communication systems, and industrial control networks, offering advantages such as efficient bandwidth utilization, support for multi-user communication, and improved transmission reliability. In recent years, with the rapid development of industrial automation and intelligent manufacturing, the importance of packet switching technology in industrial communication has become increasingly prominent, especially in industrial scenarios with high requirements for communication latency and real-time performance, placing higher demands on the performance, flexibility, and programmability of switching systems.

[0003] Traditional software-defined industrial switch systems refer to switching control devices built using a software-defined network architecture, serving industrial automation scenarios. They run specific control software on a general-purpose processor platform to centrally control and manage network forwarding behavior. Traditional software-defined industrial switch systems often use a single-core processor platform, relying on the operating system's scheduling mechanism to implement the forwarding control logic. Their main technical implementation methods include control plane communication based on the OpenFlow protocol, updating the forwarding table using the main control CPU, and using general-purpose network adapters for data plane packet forwarding. During operation, they suffer from limited processing resources, limited forwarding efficiency, and difficulty in meeting high concurrency and low latency requirements. Especially under complex operating conditions such as multi-task parallelism and dynamic load adjustment, their control capabilities and scalability are significantly constrained.

[0004] In existing technologies, software-defined industrial switch systems mainly rely on single-core processor platforms, and the forwarding control logic depends on the operating system for scheduling. When facing high concurrency or multi-path parallel processing of tasks, the limited core processing power creates a computational bottleneck, which can easily lead to problems such as task scheduling lag, increased response latency, and uneven path processing. The fixed control strategy for binding task paths and core resources lacks dynamic adaptability. During operation, it is difficult to adjust resource allocation and path binding according to the task execution status, which can easily cause channel resource congestion and data packet transmission conflicts. The lack of an adaptive control mechanism for frequency and resource utilization significantly restricts communication reliability and system scalability. Summary of the Invention

[0005] To address the shortcomings of existing technologies that rely on single-core processor platforms and whose forwarding control logic depends on operating system scheduling, the limited processing power of the core leads to computational bottlenecks when facing high concurrency or multi-path parallel processing. This can result in problems such as task scheduling delays, increased response latency, and uneven path processing. Fixed control strategies for binding task paths and core resources lack dynamic adaptability, making it difficult to adjust resource allocation and path binding based on task execution status during operation. This can easily cause channel congestion and data packet transmission conflicts. Furthermore, the lack of adaptive adjustment mechanisms for frequency and resource utilization significantly restricts communication reliability and system scalability. This invention provides a software-defined industrial switch system based on a multi-core processor. The technical solution is as follows: On the one hand, a software-defined industrial switch system based on a multi-core processor is provided, the system comprising: The control mapping module obtains the control task scheduling diagram deployed in the smart manufacturing workshop, collects the number of nodes accessed, the number of interrupt insertion points and the nesting level associated with the task path, determines the task level label, divides the task into three categories: shallow, medium and deep paths, and generates a path hierarchical label structure. The core group configuration module, based on the path hierarchical tag structure, checks the core performance of the multi-core processor, determines the core response type, interconnection method and cache parameters, and maps shallow tasks to the response speed priority core group, mid-level tasks to the general core group, and deep tasks to the independent bus channel core group according to the tag level, generating a multi-type task core binding structure. The path adjustment module calls the multi-type task core binding structure, extracts the number of cache address jumps and interrupt call frequencies that occur during task execution, and performs a difference judgment operation in combination with the task's initial path layer label to generate path offset core remapping results; Based on the path offset remapping result, the channel scheduling module extracts the priority field from the data packet to be sent, constructs the correspondence between priority parameters and channel status, and obtains the data packet scheduling path change record.

[0006] As a further embodiment of the present invention, the path hierarchical label structure includes path level categories, label hierarchy structure, and task depth markers; the multi-type task core binding structure includes a shallow task core mapping table, a mid-level task core allocation list, and a deep task-specific channel allocation table; the path offset core remapping result includes an offset task list, a core group replacement scheme, and a resource reallocation record; and the data packet scheduling path change record includes a scheduling change field, a backup channel path set, and a task channel binding table.

[0007] As a further aspect of the present invention, the control mapping module includes: The scheduling graph parsing submodule obtains the control task scheduling graph deployed in the smart manufacturing workshop, extracts the node sequence data of multiple task paths, records the node access numbers included in the task path, calculates the total number of nodes as the access quantity value, and generates the node access quantity distribution value. The path structure quantification submodule collects the interruption insertion point number and frequency of occurrence in each task path based on the node access quantity distribution value, and combines the nesting relationship between path nodes to traverse and count the nesting level to generate a path interruption nesting structure. The level label determination submodule calls the path interruption nesting structure, performs correlation calculation on the number of interruption insertion points and nesting level data, sets the access number division threshold based on the node access number distribution value of the task path, calculates the access number division deviation value, and generates a path hierarchical label structure by combining the determination information of access number range, insertion point frequency and nesting level number.

[0008] As a further aspect of the present invention, the core group configuration module includes: The core feature retrieval submodule, based on the path hierarchical tag structure, looks up the core operating frequency, cache capacity and interconnection method of the multi-core processor, records the corresponding response time metric, interconnection type number and cache parameter configuration value, and generates a core feature parameter table; The task level matching submodule calls the core feature parameter table, compares the labels corresponding to shallow task paths with response time measurement indicators in intervals, identifies the response speed priority core group, associates and marks the core interconnection type number corresponding to the labels of mid-level task paths, identifies the general core group, filters the deep task path labels with cache parameter configuration values, identifies the independent bus channel core group, and generates a path level corresponding to the core group mapping table. The core group binding submodule calls the corresponding core group index for shallow, medium and deep path tags according to the core group mapping table corresponding to the path level, identifies the binding relationship between task path and core number, integrates it into a one-to-one mapping relationship structure between multiple types of task paths and core groups, and generates multiple types of task core binding structures.

[0009] As a further aspect of the present invention, the path adjustment module includes: The execution status extraction submodule calls the multi-type task core binding structure to collect cache address jump records and interrupt call log data generated by the task path during real-time runtime, counts the number of cache jumps and interrupt call frequency under each path, and generates a task execution status information set; The path offset identification submodule compares the number of cache jumps and interrupt call frequencies generated by the path task during operation with the execution stability threshold set by the tag level, performs a difference judgment operation, marks the offset task and records the offset path number, and generates a path offset status identifier set based on the task execution status information set. The core re-filtering submodule calls the path offset status identifier set, combines it with the task path marked as offset status, and filters the core group number set based on the cache jump frequency and interrupt call count, combined with the response time and interconnection method indicators in the core characteristic parameter table, to generate the core group index table corresponding to the offset path. The core group remapping submodule rematches the path number of the marked offset task with the core group number according to the core group index table corresponding to the offset path, constructs an updated path-to-core number mapping reference item, integrates the offset path binding update content, and generates the path offset core group remapping result.

[0010] As a further aspect of the present invention, the execution stability threshold is a joint threshold of the number of cache jumps and the frequency of interrupt calls set based on the task label level. The number of cache jumps is set in the range of 10 to 50 times, and the frequency of interrupt calls is set in the range of 5 to 30 times. The higher the label level, the lower the corresponding threshold of the number of cache jumps and the frequency of interrupt calls. In the difference judgment operation, when the number of cache jumps or interruption calls of any task path exceeds the execution stability threshold under the corresponding label level, the task is marked as an offset task, and the offset path number is the task path number where the number of jumps or call frequencies is abnormal. The response time is the average processing delay of the core group on scheduling signals under standard load, in microseconds. The interconnection method indicators include two types: direct connection between cores and bus connection. During the screening process of the core group number set, priority is given to core group numbers with a response time of no more than 100 microseconds and an interconnection method of direct connection between cores.

[0011] As a further aspect of the present invention, the channel scheduling module includes: The channel status acquisition submodule calls the path offset remapping result, extracts the priority field from the data packet content corresponding to the task, collects the task dwell time value, transmission cycle value and path hop value of the communication channel bound to the real-time task, matches the priority field with the corresponding channel status parameters, and generates a channel running status mapping table. The resource status judgment submodule performs a ratio calculation on the task dwell time value and transmission cycle value in the channel path according to the channel operation status mapping table, calculates the channel transmission density parameter per unit time, and combines the path hop count with the congestion threshold judgment benchmark to mark the bound channel number in the resource shortage state and generate a communication channel resource shortage identifier set. The scheduling path adjustment submodule calls the communication channel resource shortage identifier set, indexes and locates the task channel binding path in the resource shortage state, filters the backup channel number that matches the real-time priority field from the channel alternative path set, replaces the original binding channel number, and obtains the data packet scheduling path change record.

[0012] As a further aspect of the present invention, during the ratio calculation process, the ratio between the task dwell time value and the transmission cycle value is limited to a range greater than 0 and less than 1. If the ratio exceeds 0.8, the corresponding bound channel number is marked as being in a resource-scarce state. The congestion threshold judgment criterion is a graded threshold set based on the path hop value. When the path hop value is less than or equal to 3, the first congestion threshold is used. The value of the first congestion threshold is set to 0.75. When the path hop value is greater than 3 and less than or equal to 6, a second congestion threshold is used, and the value of the second congestion threshold is set to 0.65. When the path hop value is greater than 6, a third congestion threshold is used, and the value of the third congestion threshold is set to 0.5.

[0013] As a further aspect of the present invention, the system also includes a frequency-controlled cropping module: The frequency control pruning module calls the data packet scheduling path change record, collects the number of jump instructions, cache hits and inter-core communication times of the task in the previous cycle, normalizes the units and classifies the density level of the three data, and, in combination with the frequency range supported by the processing core, identifies the difference distribution between the density level and the frequency interval, and generates a frequency control interval constraint set for the processing core. The processing core frequency control interval constraint set includes a density level category, a frequency interval mapping table, and a core frequency control strategy set.

[0014] As a further aspect of the present invention, the frequency control cropping module includes: The operation density data extraction submodule calls the data packet scheduling path change record to collect the number of jump instructions, cache hits and inter-core communication times of the task in the previous cycle. It performs unit normalization operation on the three types of indicators and maps them to the same numerical range to generate a normalized operation indicator set. The density level determination submodule performs a weighted merging operation on the jump instruction value, cache hit value and communication count value according to the normalized operation index set, and performs a density level division operation according to the set classification threshold to generate a task density level distribution table. The frequency control constraint submodule calls the task density level distribution table, performs interval difference matching analysis between the density level code and the frequency range supported by the processing core, identifies task frequency configuration items with constraint conflicts or distribution boundary differences, constructs the constraint mapping relationship between density level and frequency interval, and generates the processing core frequency control interval constraint set.

[0015] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following: By hierarchically labeling the control task path structure, the system achieves quantitative identification of task depth and execution complexity. Combining the performance characteristics of multi-core processors, it constructs multiple mapping relationships between tasks and cores, improving the accuracy of resource matching and scheduling flexibility. Based on the task execution state, it extracts access and interrupt features, dynamically identifies path offset behavior, and completes real-time core reassignment, ensuring the continuity and scheduling balance of the task execution process. In terms of communication path selection, it introduces a priority and channel state mapping mechanism to improve the control capability of task-bound paths under resource-constrained conditions. Combining jump and communication density to identify frequency control interval differences, it realizes the linkage constraint and trimming optimization of processor frequency and resource distribution, enhancing the system's adaptability to complex working conditions and communication load management capabilities. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of the system provided by the present invention; Figure 2 This is a schematic diagram of the system framework of the present invention; Figure 3 This is a flowchart of the control mapping module in this invention; Figure 4 This is a flowchart of the core group configuration module in this invention; Figure 5 This is a flowchart of the path adjustment module in this invention; Figure 6 This is a flowchart of the channel scheduling module in this invention; Figure 7 This is a flowchart of the frequency control trimming module in this invention. Detailed Implementation

[0018] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0019] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0020] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, their intended meanings are consistent. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, their intended meanings are consistent.

[0021] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0022] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0023] This invention provides a software-defined industrial switch system based on a multi-core processor, such as... Figure 1-2 The diagram shown illustrates a software-defined industrial switch system based on a multi-core processor. The system includes: The control mapping module obtains the control task scheduling diagram deployed in the smart manufacturing workshop, collects the number of nodes accessed, the number of interrupt insertion points and the nesting level associated with the task path, determines the task level label, divides the task into three categories: shallow, medium and deep paths, and generates a path hierarchical label structure. The core group configuration module checks the core performance of the multi-core processor according to the path hierarchical tag structure, determines the core response type, interconnection method and cache parameters, and maps shallow tasks to the core group with priority response speed, medium tasks to the general core group and deep tasks to the core group with independent bus channel according to the tag level, generating a multi-type task core binding structure. The path adjustment module calls multiple task core binding structures, extracts the number of cache address jumps and interrupt call frequencies that occur during task execution, performs difference judgment operations in combination with the initial path layer labels of the task, identifies the offset status, and if it is marked as an offset task, it re-selects and matches the core group and completes the resource reallocation operation to generate path offset core remapping results. Based on the path offset remapping result, the channel scheduling module extracts the priority field from the data packet to be sent, collects the task dwell time, transmission cycle and path hop count of the communication channel, constructs the correspondence between priority parameters and channel status, determines whether the real-time binding channel is in a resource-scarce state, and if it is determined to be in a congested state, it reconstructs the channel and binds the task to the backup channel path, and obtains the data packet scheduling path change record. The frequency control pruning module calls the data packet scheduling path change record, collects the number of jump instructions, cache hits and inter-core communication times of the task in the previous cycle, normalizes the units and classifies the density level of the three data, and, in combination with the frequency range supported by the processing core, identifies the difference distribution between the density level and the frequency interval, and generates a constraint set of the frequency control interval of the processing core. The path hierarchical label structure includes path level categories, label hierarchy structure, and task depth marking. The multi-task core binding structure includes a shallow task core mapping table, a mid-level task core allocation list, and a deep task-specific channel allocation table. The path offset core remapping results include an offset task list, core group replacement schemes, and resource reallocation records. The data packet scheduling path change records include scheduling change fields, backup channel path sets, and task channel binding tables. The processing core frequency control interval constraint set includes density level categories, frequency interval mapping tables, and core frequency control strategy sets.

[0024] Specifically, such as Figure 2 , 3 As shown, the control mapping module includes: The scheduling graph parsing submodule obtains the control task scheduling graph deployed in the smart manufacturing workshop, extracts the node sequence data of multiple task paths, records the node access numbers included in the task path, calculates the total number of nodes as the access quantity value, and generates the node access quantity distribution value. The control task scheduling graph is input into the system in the form of a directed graph. Each node in the graph represents the operation steps of a control task, and each edge represents the sequential dependency relationship of the tasks. The system extracts the node sequence data of each task path using a graph traversal algorithm (such as Depth-First Search (DFS) or Breadth-First Search (BFS). For example, assuming there is a task path A→B→C→D, the system starts from the initial node A and records the number of each visited node in sequence, forming the node sequence [1, 2, 3, 4]. The number of visits to each node in the path is counted to form a frequency table for each node. For example, if node 1 appears 3 times, node 2 appears 5 times, node 3 appears 2 times, and node 4 appears 5 times, then the total number of nodes is 4, and the number of visits is the sum of the number of visits to each node, i.e., 3 + 5 + 2 + 5 = 15. Then... Based on the number of visits to each node, their distribution is statistically analyzed. For example, there is 1 node with 2 visits, 1 node with 3 visits, and 2 nodes with 5 visits, forming a node visit distribution value vector [1, 1, 2]. The "statistics", "records", and "extracts" operations in this process are specifically implemented by writing a scheduling graph processing program. The networkx library in Python is used to process the nodes and path traversal of the task graph, and the node number and corresponding frequency are recorded by a dictionary structure, such as dict={1:3, 2:5, 3:2, 4:5}. The total number of nodes is obtained by len(dict), and the number of visits is calculated by sum(dict.values()). The node visit distribution can be generated by constructing a frequency distribution table using the Counter module.

[0025] The path structure quantification submodule collects the interruption insertion point numbers and frequency of occurrence in each task path based on the node access quantity distribution value, and combines the nesting relationship between path nodes to traverse and count the nesting level to generate the path interruption nesting structure. The system collects the number and frequency of interruption insertion points in the task path. Assuming there are nodes in the path structure where interrupted tasks are inserted between nodes, such as A→B→C→D where an auxiliary task E is inserted between B and C, the interruption insertion point is numbered as node 2 (B) or 3 (C). By traversing the task path, the frequency of each insertion point is counted. For example, node 2 appears 5 times as an insertion point, and node 3 appears 2 times. The system records the insertion behavior number and frequency between each pair of adjacent nodes. It also analyzes whether there are nested relationships between nodes in the path, i.e., a task path nests another complete sub-path, such as A→B→C→B→C→D, where B→C appears multiple times as a nested path. During the structure quantization process, the system tracks the node nesting level using a stack structure. If a node reappears before completing its previous task... If a path segment is encountered, the nesting level is incremented by 1. For example, in the example above, B→C appears twice, indicating a nesting level of 2. After traversing the path, the system records the maximum nesting level of each path, forming a path interruption nesting structure. The "frequency statistics" involved in this process are implemented by constructing a counter for the insertion point number. For example, if the insertion point record is insert_points=[2, 2, 2, 3, 3, 2, 2], then Counter(insert_points)={2:5, 3:2}. The nesting level count is implemented by judging duplicate path segments through the node push and pop stack structure. Each node is pushed onto the stack using a stack structure. If an existing node is encountered and has not been popped from the stack, the level is incremented by 1; otherwise, it is popped normally. The maximum nesting level of each path can be obtained, generating a path interruption nesting structure.

[0026] The level label determination submodule calls the path interruption nesting structure, performs correlation calculation on the number of interruption insertion points and nesting level data, sets the access number division threshold based on the node access number distribution value of the task path, calculates the access number division deviation value, and generates a path hierarchical label structure by combining the determination information of access number range, insertion point frequency and nesting level. The deviation value for the number of visits is determined using the following formula: ; in, Representing the The deviation value for the number of accesses corresponding to each task path. Representing the The first path The number of visits to each node. Representing the The first path The frequency of occurrence of each node in the interrupt insertion point record. Representing the The first path The number of nesting levels of a node. Representing the The first path The path depth of each node relative to the starting point of the nested upper layer. Representing the The total number of nodes in the path; Formula calculation logic: By comprehensively comparing the access status of each node in the path with factors such as structural complexity and anomaly frequency, the deviation of the overall access division of each path is calculated. For each node, the absolute difference between the actual number of visits and an "expected access value" obtained by combining interruption insertion frequency, nesting level and path depth is calculated. The node deviations are summed and averaged to obtain the average access division deviation of the path. This method can effectively reveal the degree of deviation between the actual access of nodes in the path and the reasonable structural expectation, and reflect the abnormal distribution problem in path scheduling or design. The access count deviation value measures the difference between the actual number of times a node is accessed and the expected number of accesses in the model. The larger the deviation value, the more inconsistent the node access behavior is with the expected structural complexity and abnormal frequency. It is used to judge whether the task path design is reasonable and whether there is an imbalance in node access allocation. Parameter meaning and calculation process: : No. The total number of nodes in a path is a measure of the path length; : Represents the first The first path The actual number of visits to each node is statistically analyzed through log analysis; : Represents the first The first path The frequency of each node in the interrupt insertion point record is obtained by counting the number of times the node is called in the abnormal insertion task record. : Represents the first The first path The number of nesting levels of a node quantifies the depth complexity of a node in a hierarchical structure. : Represents the first The first path The path depth of a node relative to the starting point of the nested layer above reflects the logical distance between that node and the initial layer node. Parameter acquisition and quantization process: Based on the data monitoring mechanism in conventional task systems, the following data acquisition and quantification methods are designed: Actual number of visits, obtained by: statistics from API call logs during task execution or business access tracing systems (such as ELK log systems); Example: In a certain path, if node 3 is accessed 123 times by a user, then... ; Interruption insertion frequency, obtained by analyzing the task's abnormal insertion log and marking abnormal calls on each node; Example: If node 3 experiences 6 interruptions within 3 days, then... ; Nesting level (non-numerical quantification): Define the nesting level as follows: If node A calls node B, and node B then calls node C, then C is the second level relative to A. The quantification standard is set as follows: direct child nodes = 1 level, and increment by 1 with each recursive iteration; Example: If the nested call structure of the third node is "root → module A → module B → node", then ; Path depth, obtained by: calculating the path distance from the root node to the target node through path topology analysis; Example: If the node is the 5th node from the beginning of the path, then , Parameter settings and calculation examples: Assuming the current analysis task path , including the total number of nodes The parameters are set as follows: Table 1: Node Parameter Table in Task Path Table 1 lists the collected data for the five nodes in the first task path. Substitute into the formula and calculate According to the formula: ; Calculate item by item: : ; ; : ; ; : ; ; : ; ; : ; ; Summation and average: ; The results show that the deviation value of the number of visits is 90.566. The upper limit of the average deviation allowed by the system (the benchmark value) is set at 75 times. This value is set based on the fact that 95% of the paths in the comparison data have a deviation of less than 80; combined with the system's abnormal alarm threshold, 75 is defined as a reasonable upper limit. Current calculations show that The value significantly exceeds the baseline of 75, indicating a substantial deviation between the path access and the model expectation. Optimization of interruption insertion frequency or nested path design is needed. The advantage of this formula is that: Introduction This approach not only focuses on the frequency of node anomalies but also considers structural complexity (nesting hierarchy) to differentiate between nodes that are "highly complex but have few anomalies" and those that are "lowly complex but have frequent anomalies." By performing weighting, the probability of amplifying deviations in deep nodes is effectively reduced. Through absolute value and averaging operations, path deviations are measured as a whole, enhancing contrast and aggregation, and improving the controllability and transparency of abnormal path deviations, which helps to dynamically adjust task scheduling strategies.

[0027] Specifically, such as Figure 2 , 4 As shown, the core group configuration module includes: The core feature retrieval submodule, based on the path hierarchical tag structure, looks up the core operating frequency, cache capacity, and interconnection method of the multi-core processor, records the corresponding response time metric, interconnection type number, and cache parameter configuration value, and generates a core feature parameter table. The system extracts the necessary core attributes for shallow, mid, and deep paths. It obtains the operating frequency information of each core by parsing the hardware parameter document of the multi-core processor or calling low-level interfaces; for example, core A operates at 2.4GHz, and core B at 3.0GHz. It collects cache information for each core, recording the size of L1, L2, and existing L3 caches, and distinguishes and numbers them according to storage levels. It also checks the interconnection method of each core; for example, some cores are connected via a bus, while others are in a ring interconnection structure. Different interconnection modes are identified by different structure numbers. After completing parameter collection, the system performs basic response performance tests on each core, such as observing response latency under a given stress test task group. It records the average response time of each core through a standardized test process. Simultaneously, the system assigns a corresponding number to each interconnection method, generates configuration values ​​for the cache level, and generates a core characteristic parameter table.

[0028] The task level matching submodule calls the core feature parameter table, compares the labels corresponding to shallow task paths with response time measurement indicators within a range, identifies the core group with priority response speed, associates and marks the core interconnection type number corresponding to the labels of mid-level task paths, identifies the general core group, filters the labels of deep task paths with cache parameter configuration values, identifies the independent bus channel core group, and generates a mapping table of core groups corresponding to path levels. The system systematically filters and compares the path sets corresponding to shallow, mid, and deep path labels. For shallow paths, the system focuses on response time parameters. By comparing the response latency value of each core with a preset performance reference value, the system identifies cores with faster response speeds and forms a response-priority core group. This group is suitable for the rapid scheduling and binding of tasks with shallow labels. The mid-level path matching process focuses on the interconnection structure type between cores. By comparing the interconnection method of each core with the preset mid-level path adaptation structure type, the system selects cores suitable for running in the interconnection topology and classifies them into a general core group. For deep path tasks, the system primarily uses cache capacity to select cores with larger cache configurations. These cores have high-load task processing capabilities and are therefore assigned to an independent bus channel core group. In practice, each task path is compared one by one with the label and core characteristics, and the system automatically matches the optimal core category according to its level, generating a path level-to-core group mapping table.

[0029] The core group binding submodule calls the corresponding core group index for shallow, medium and deep path tags according to the core group mapping table corresponding to the path level, identifies the binding relationship between task path and core number, integrates it into a one-to-one mapping relationship structure between multiple types of task paths and core groups, and generates multiple types of task core binding structures. Entering the one-to-one binding phase between paths and cores, the system calls the corresponding core groups according to the tags of shallow, medium, and deep tasks. In the shallow path binding process, the system traverses the list of shallow path numbers and selects the core with the lowest current load from the response priority core group for each path to bind. This process uses round-robin or load statistics to ensure balanced core usage. For medium-level paths, the system calls the appropriate core from the general core group, also aiming to reduce redundant core usage and establish a clear binding record between the path and the core. The deep path binding method is more fixed. Due to higher processing requirements, the system prioritizes allocating the core with the largest cache capacity to complete the direct binding between deep paths and high-cache cores. The entire binding process is stored in the system in a structured table, recording the level of each path, the core number bound to it, and the core group category. This ensures that when executing path tasks, the target core can be quickly located according to the binding structure, realizing a closed loop of mapping between path numbers and core numbers, and generating multiple types of task core binding structures.

[0030] Specifically, such as Figure 2 , 5 As shown, the path adjustment module includes: The execution status extraction submodule calls multiple task core binding structures, collects cache address jump records and interrupt call log data generated by the task path during real-time runtime, counts the number of cache jumps and interrupt call frequency under each path, and generates a task execution status information set; The system monitors the runtime status of each task path that has completed core binding. During the path execution phase, the system connects to the scheduling control bus in real time to capture cache address jump records and interrupt call logs generated when the task runs on the specific core. The data is provided by the hardware layer or the log acquisition module. For example, the starting address, target address, and jump timestamp are recorded for each cache jump, and the interrupt source, call time, and processing result number are recorded for each interrupt call. The system performs path-level aggregation on the collected data, counts the number of cache jumps for each task path in the entire execution cycle, i.e., the count of jumps from one address to another, and the interrupt call frequency, i.e., the total number of interrupt events triggered during path execution. By storing the data in a structured manner, the system constructs execution status record entries for each path. Path p12 has 95 cache jumps and 12 interrupt calls during one run. After parsing the logs, the system organizes the information into structured records to generate a task execution status information set.

[0031] The path offset identification submodule compares the number of cache jumps and interrupt call frequencies generated by the path task during operation with the execution stability threshold set by the tag level based on the task execution status information set, performs difference judgment operation, marks the offset task and records the offset path number, and generates a path offset status identifier set. The system compares the actual number of cache jumps and interrupt call frequencies collected during the operation of each path with the preset execution stability thresholds for the path's tag level. A set of stability threshold configuration tables is established according to the tag level, setting the cache jump and interrupt call ranges that should be met during normal operation for shallow, medium, and deep paths respectively. When the actual operating state of a path significantly exceeds or falls below the range, it is considered that an execution offset has occurred. For example, path p12 is classified as a medium-level path, and its set reasonable range for interrupt call frequency is 5 to 10 times, while the actual frequency is 12 times, thus marking it as an offset task. During the offset identification process, the system compares the actual path records with the standard values ​​to determine whether it exceeds the limits, records the task path numbers that meet the offset conditions, forming an offset path number list, and marks the offset item of each path in the status identifier, generating a path offset status identifier set.

[0032] The core re-filtering submodule calls the path offset status identifier set, combines the task path marked with the offset status, and filters the core group number set based on the cache jump frequency and interrupt call count, combined with the response time and interconnection method indicators in the core feature parameter table, and generates the core group index table corresponding to the offset path. For task paths marked as offset, a new core adaptation analysis is performed. The system extracts the cache jump frequency and interrupt call count of the path from the execution status information set as reference data for the severity of the offset. At the same time, it compares the response time and interconnection method information of the cores in the core characteristic parameter table and performs matching logic filtering again. The system selects a set of core group numbers that are more suitable for the execution requirements based on the abnormal characteristics of the offset path. For example, paths with a significant increase in cache jumps in the offset path can be recommended to use cores with shorter response times and higher cache response efficiency, or core structures with more flexible interconnection methods. The filtering process is implemented in the system with a classification filtering strategy, which performs multi-dimensional comparison between offset characteristics and core capabilities to generate an index table of core groups corresponding to the offset path.

[0033] The core group remapping submodule rematches the path number of the marked offset task with the core group number according to the core group index table corresponding to the offset path, constructs the updated path-to-core number mapping reference item, integrates the offset path binding update content, and generates the path offset core group remapping result. The system performs core group re-matching on each task path number marked as offset. During the matching process, the system calls the core group set recommended for the path in the index table and selects the target core with the most suitable current running load from the core group to bind and replace the path. For example, the original core bound to the path p12 was core B. After re-filtering, the recommended core group is {D, E}. Since the current running load of core E is low, the core bound to the path p12 is updated to E. The process follows the strategy of first identifying and then replacing to complete the core re-binding operation of the offset path item by item. The system merges and updates the new path to core number pairing information with the original binding structure to ensure that the path and core binding structure are complete and consistent. The system organizes the updated mapping relationship into a result structure, identifies the old and new binding items and the change information, and generates the path offset core re-mapping result.

[0034] Specifically, such as Figure 2 , 6 As shown, the channel scheduling module includes: The channel status acquisition submodule calls the path offset remapping result, extracts the priority field from the data packet content corresponding to the task, collects the task dwell time value, transmission cycle value and path hop value of the communication channel bound to the real-time task, matches the priority field with the corresponding channel status parameter, and generates a channel running status mapping table. The system extracts the priority field from each data packet in the task path that has been marked with offsets and remapped to the core. This field is set by the scheduling policy when the task generates the data packet. For example, high-priority tasks have shorter response times or lower latency tolerance, and their corresponding field values ​​are higher. The system parses the field content immediately after receiving the data packet. At the same time, the system obtains the current communication channel status of each task from the actual operating environment, including the task's dwell time on the channel (the total time it takes for the data packet to complete the transmission from entering the channel), the transmission cycle value (the interval between the periodic activation of transmission by the task in the channel), and the path hop count (the number of channel segments the data packet passes through from the sender to the target core). All status parameters are collected and archived in real time through the communication operation monitoring interface. During the collection process, the system binds and matches the task priority field with the channel status parameters to ensure that each record is completely associated with the task level and communication resource status, generating a channel operation status mapping table.

[0035] The resource status judgment submodule performs a ratio calculation on the task dwell time value and transmission cycle value in the channel path according to the channel operation status mapping table, calculates the channel transmission density parameter per unit time, and combines the path hop count with the congestion threshold judgment benchmark to mark the bound channel number that is in a resource shortage state and generate a communication channel resource shortage identifier set. The system reads the corresponding task dwell time and transmission cycle value for each channel. It then performs a ratio analysis based on these two data points to reflect the transmission density of active tasks on the channel per unit time. A higher ratio indicates more severe task queuing or latency on the channel, and the system uses this result as a direct reflection of transmission density. Simultaneously, it combines channel path hop count information for comprehensive evaluation. A higher path hop count indicates more nodes the data packet needs to pass through during transmission, representing increased overall resource consumption and latency risk. The system analyzes the ratio result in conjunction with the hop count data and sets basic standards for judging whether a channel is in a resource-scarce state. For example, a channel is considered congested when the transmission density per unit time exceeds a reference baseline and the path hop count exceeds the average path length. These standards can be dynamically adjusted based on the communication frequency, task density, and system architecture in the actual scenario. When the system detects that a channel simultaneously meets the above-mentioned scarcity conditions, it marks the channel number, writes it to the resource scarcity status identifier list, and generates a communication channel resource scarcity identifier set.

[0036] The scheduling path adjustment submodule calls the communication channel resource shortage identifier set, indexes and locates the task channel binding path in the resource shortage state, filters the backup channel number that matches the real-time priority field from the channel alternative path set, replaces the original binding channel number, and obtains the data packet scheduling path change record; The system retrieves and locates affected task paths based on a resource-scarce identifier set, searching for the bound communication channel numbers one by one. After location, it filters available channel numbers from the system-maintained alternative path set for replacement. During the filtering process, the system prioritizes backup channels that match the original task priority field; that is, data packets with higher task priority are preferentially matched with channel resources that have higher current idle levels and shorter path hop counts. The filtering strategy is based on a comprehensive decision made according to the real-time network structure, task type, and current channel load. When the system determines that a certain channel can meet the scheduling requirements and matches the current task level, it performs a channel replacement operation, replacing the original bound channel number with a new channel number. At the same time, it records detailed information such as the task path number, original channel number, new channel number, and replacement timestamp of this replacement event. The process is executed one by one until the paths marked as resource-scarce are replaced, resulting in a data packet scheduling path change record.

[0037] Specifically, such as Figure 2 , 7 As shown, the frequency control cropping module includes: The runtime density data extraction submodule calls the data packet scheduling path change record, collects the number of jump instructions, cache hits and inter-core communication times of the task in the previous cycle, performs unit normalization operation on the three types of indicators, maps them to the same numerical range, and generates a normalized runtime indicator set. The system immediately analyzes and extracts data from the execution trajectory of each task within the previous scheduling cycle, focusing on three types of operational metrics: jump instruction count, cache hit count, and inter-core communication count. These three data points are automatically collected during processor operation by the instruction counter, cache monitoring module, and communication bus recording system. The system locates the corresponding execution record based on the task number and extracts the number of instruction jumps triggered during task execution within the cycle. This data reflects the complexity of the program flow. The cache hit count reflects the efficiency of the task's use of the local cache and is recorded by the cache access statistics module. The system derives the total number of hits from the cache access to hit ratio within the sampling cycle. The inter-core communication count records the frequency of data exchange between multiple cores and is recorded by the multi-core synchronization module to measure inter-task dependencies and communication density. Since these three metrics have different dimensions and orders of magnitude, the system performs unit normalization after extraction. This involves scaling the metrics proportionally to convert them into numerical ranges of the same size, ensuring comparability and composability of data from different dimensions. The normalized data serves as the operational density feature value, generating a normalized operational metric set.

[0038] The task density level determination submodule performs a weighted merging operation on the jump instruction value, cache hit value and communication count value based on the normalized operation index set, and performs a density level division operation according to the set classification threshold to generate a task density level distribution table. The system performs weighted merging of the normalized jump instruction value, cache hit value, and communication count value corresponding to each task. Following a preset index weighting scheme, the system assigns weights to these three types of data to generate a unified comprehensive operational density value. This value serves as an expression of the task's operational density characteristics for the current cycle. The concentration level reflects the task's resource consumption and system load during the operational phase. The system classifies tasks based on their operational density characteristic value and a set multi-level density threshold standard. For example, with a three-level density structure, the system categorizes tasks into low, medium, and high density levels based on the range in which their comprehensive value falls. Different levels reflect the task's frequency adjustment needs and priority reference during scheduling. After the density level classification is completed, the system establishes a one-to-one correspondence between each task number and its assigned density level, storing this information in a structured form. This summarizes the density assessment results of tasks in the current operational cycle and provides a reference for the core processing frequency configuration control and dynamic adjustment, generating a task density level distribution table.

[0039] The frequency control constraint submodule calls the task density level distribution table, performs interval difference matching analysis between the density level code and the frequency range supported by the processing core, identifies task frequency configuration items with constraint conflicts or distribution boundary differences, constructs the constraint mapping relationship between density level and frequency interval, and generates the frequency control interval constraint set of the processing core. The system analyzes and compares the relationship between task intensity level codes and the operating frequency ranges supported by each processing core. It reads the minimum and maximum operating frequencies supported by each core and maps these frequency ranges to the frequency ranges required by the current intensity level of the task. If the operating frequency requirement corresponding to a task's intensity level exceeds the supported frequency band of the currently bound core, a frequency control constraint conflict is identified, or there is a significant difference between the frequency boundary value of the task intensity level and the core frequency support range. For example, if the task requirement is within a boundary fluctuation range, but the core frequency does not support fine-grained frequency jumps, this situation is also marked as a potential frequency control distribution boundary difference. After analysis, the system records information such as the task number, the currently bound core number, the intensity level code, and the core frequency range where conflicts or mismatches occur. These records are organized into a constraint relationship table, forming a unified matching constraint mapping structure between intensity levels and core frequencies, and generating a set of processing core frequency control range constraints.

[0040] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A software-defined industrial switch system based on a multi-core processor, characterized in that, The system includes: The control mapping module obtains the control task scheduling diagram deployed in the smart manufacturing workshop, collects the number of nodes accessed, the number of interrupt insertion points and the nesting level associated with the task path, determines the task level label, divides the task into three categories: shallow, medium and deep paths, and generates a path hierarchical label structure. The core group configuration module, based on the path hierarchical tag structure, checks the core performance of the multi-core processor, determines the core response type, interconnection method and cache parameters, and maps shallow tasks to the response speed priority core group, mid-level tasks to the general core group, and deep tasks to the independent bus channel core group according to the tag level, generating a multi-type task core binding structure. The path adjustment module calls the multi-type task core binding structure, extracts the number of cache address jumps and interrupt call frequencies that occur during task execution, and performs a difference judgment operation in combination with the task's initial path layer label to generate path offset core remapping results; Based on the path offset remapping result, the channel scheduling module extracts the priority field from the data packet to be sent, constructs the correspondence between priority parameters and channel status, and obtains the data packet scheduling path change record.

2. The software-defined industrial switch system based on a multi-core processor according to claim 1, characterized in that: The path hierarchical label structure includes path level categories, label hierarchy structure, and task depth markers. The multi-type task core binding structure includes a shallow task core mapping table, a mid-level task core allocation list, and a deep task-specific channel allocation table. The path offset core remapping result includes an offset task list, a core group replacement scheme, and a resource reallocation record. The data packet scheduling path change record includes a scheduling change field, a backup channel path set, and a task channel binding table.

3. The software-defined industrial switch system based on a multi-core processor according to claim 1, characterized in that: The control mapping module includes: The scheduling graph parsing submodule obtains the control task scheduling graph deployed in the smart manufacturing workshop, extracts the node sequence data of multiple task paths, records the node access numbers included in the task path, calculates the total number of nodes as the access quantity value, and generates the node access quantity distribution value. The path structure quantification submodule collects the interruption insertion point number and frequency of occurrence in each task path based on the node access quantity distribution value, and combines the nesting relationship between path nodes to traverse and count the nesting level to generate a path interruption nesting structure. The level label determination submodule calls the path interruption nesting structure, performs correlation calculation on the number of interruption insertion points and nesting level data, sets the access number division threshold based on the node access number distribution value of the task path, calculates the access number division deviation value, and generates a path hierarchical label structure by combining the determination information of access number range, insertion point frequency and nesting level number.

4. The software-defined industrial switch system based on a multi-core processor according to claim 3, characterized in that: The core group configuration module includes: The core feature retrieval submodule, based on the path hierarchical tag structure, looks up the core operating frequency, cache capacity and interconnection method of the multi-core processor, records the corresponding response time metric, interconnection type number and cache parameter configuration value, and generates a core feature parameter table; The task level matching submodule calls the core feature parameter table, compares the labels corresponding to shallow task paths with response time measurement indicators in intervals, identifies the response speed priority core group, associates and marks the core interconnection type number corresponding to the labels of mid-level task paths, identifies the general core group, filters the deep task path labels with cache parameter configuration values, identifies the independent bus channel core group, and generates a path level corresponding to the core group mapping table. The core group binding submodule calls the corresponding core group index for shallow, medium and deep path tags according to the core group mapping table corresponding to the path level, identifies the binding relationship between task path and core number, integrates it into a one-to-one mapping relationship structure between multiple types of task paths and core groups, and generates multiple types of task core binding structures.

5. The software-defined industrial switch system based on a multi-core processor according to claim 4, characterized in that: The path adjustment module includes: The execution status extraction submodule calls the multi-type task core binding structure to collect cache address jump records and interrupt call log data generated by the task path during real-time runtime, counts the number of cache jumps and interrupt call frequency under each path, and generates a task execution status information set; The path offset identification submodule compares the number of cache jumps and interrupt call frequencies generated by the path task during operation with the execution stability threshold set by the tag level, performs a difference judgment operation, marks the offset task and records the offset path number, and generates a path offset status identifier set based on the task execution status information set. The core re-filtering submodule calls the path offset status identifier set, combines it with the task path marked as offset status, and filters the core group number set based on the cache jump frequency and interrupt call count, combined with the response time and interconnection method indicators in the core characteristic parameter table, to generate the core group index table corresponding to the offset path. The core group remapping submodule rematches the path number of the marked offset task with the core group number according to the core group index table corresponding to the offset path, constructs an updated path-to-core number mapping reference item, integrates the offset path binding update content, and generates the path offset core group remapping result.

6. The software-defined industrial switch system based on a multi-core processor according to claim 5, characterized in that: The execution stability threshold is a joint threshold of the number of cache jumps and the frequency of interrupt calls set based on the task label level. The number of cache jumps is set from 10 to 50 times, and the frequency of interrupt calls is set from 5 to 30 times. The higher the label level, the lower the corresponding thresholds for the number of cache jumps and the frequency of interrupt calls. In the difference judgment operation, when the number of cache jumps or interruption calls of any task path exceeds the execution stability threshold under the corresponding label level, the task is marked as an offset task, and the offset path number is the task path number where the number of jumps or call frequencies is abnormal. The response time is the average processing delay of the core group on scheduling signals under standard load, in microseconds. The interconnection method indicators include two types: direct connection between cores and bus connection. During the screening process of the core group number set, priority is given to core group numbers with a response time of no more than 100 microseconds and an interconnection method of direct connection between cores.

7. The software-defined industrial switch system based on a multi-core processor according to claim 5, characterized in that: The channel scheduling module includes: The channel status acquisition submodule calls the path offset remapping result, extracts the priority field from the data packet content corresponding to the task, collects the task dwell time value, transmission cycle value and path hop value of the communication channel bound to the real-time task, matches the priority field with the corresponding channel status parameters, and generates a channel running status mapping table. The resource status judgment submodule performs a ratio calculation on the task dwell time value and transmission cycle value in the channel path according to the channel operation status mapping table, calculates the channel transmission density parameter per unit time, and combines the path hop count with the congestion threshold judgment benchmark to mark the bound channel number in the resource shortage state and generate a communication channel resource shortage identifier set. The scheduling path adjustment submodule calls the communication channel resource shortage identifier set, indexes and locates the task channel binding path in the resource shortage state, filters the backup channel number that matches the real-time priority field from the channel alternative path set, replaces the original binding channel number, and obtains the data packet scheduling path change record.

8. The software-defined industrial switch system based on a multi-core processor according to claim 7, characterized in that: During the ratio calculation process, the ratio between the task dwell time value and the transmission cycle value is limited to a range greater than 0 and less than 1. If the ratio exceeds 0.8, the corresponding bound channel number is marked as being in a resource-scarce state. The congestion threshold judgment criterion is a graded threshold set based on the path hop value. When the path hop value is less than or equal to 3, the first congestion threshold is used. The value of the first congestion threshold is set to 0.

75. When the path hop value is greater than 3 and less than or equal to 6, a second congestion threshold is used, and the value of the second congestion threshold is set to 0.

65. When the path hop value is greater than 6, a third congestion threshold is used, and the value of the third congestion threshold is set to 0.

5.

9. The software-defined industrial switch system based on a multi-core processor according to claim 1, characterized in that: The system also includes a frequency control clipping module: The frequency control pruning module calls the data packet scheduling path change record, collects the number of jump instructions, cache hits and inter-core communication times of the task in the previous cycle, normalizes the units and classifies the density level of the three data, and, in combination with the frequency range supported by the processing core, identifies the difference distribution between the density level and the frequency interval, and generates a frequency control interval constraint set for the processing core. The processing core frequency control interval constraint set includes a density level category, a frequency interval mapping table, and a core frequency control strategy set.

10. The software-defined industrial switch system based on a multi-core processor according to claim 9, characterized in that: The frequency control clipping module includes: The operation density data extraction submodule calls the data packet scheduling path change record to collect the number of jump instructions, cache hits and inter-core communication times of the task in the previous cycle. It performs unit normalization operation on the three types of indicators and maps them to the same numerical range to generate a normalized operation indicator set. The density level determination submodule performs a weighted merging operation on the jump instruction value, cache hit value and communication count value according to the normalized operation index set, and performs a density level division operation according to the set classification threshold to generate a task density level distribution table. The frequency control constraint submodule calls the task density level distribution table, performs interval difference matching analysis between the density level code and the frequency range supported by the processing core, identifies task frequency configuration items with constraint conflicts or distribution boundary differences, constructs the constraint mapping relationship between density level and frequency interval, and generates the processing core frequency control interval constraint set.

Images