Immune algorithm based method for allocating multiple constraints resident application resources in ima system

Abstract

This invention discloses a resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm, comprising the following steps: S1) quantifying the resource capabilities and quantity of resident modules in the IMA system; S2) determining and quantifying the number of resident applications, the resource requirements of each application, and their constraints; S3) establishing a problem model based on the resource requirements and constraints of resident applications and the resource capabilities of resident modules, clarifying the constraint relationships and objectives; S4) solving the resource allocation scheme for multi-constraint resident applications in the IMA system using an immune algorithm based on the constraint relationships and objectives; S5) selecting the resource allocation scheme for resident applications in the IMA system with the lowest change cost. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm provided by this invention can solve the optimization problem of resident module allocation for multi-resident applications under multiple constraints, achieving global optimum.

Description

Technical Field

[0001] This invention relates to a method for allocating resources for system-resident applications, and more particularly to a method for allocating resources for multi-constraint-resident applications in an IMA system based on an immune algorithm. Background Technology

[0002] Avionics systems are the "brain" and "nerves" of an aircraft. Integrated Modular Avionics (IMA) is currently the mainstream architecture for aircraft avionics. Its open architecture enables the system to have good scalability and is easy to upgrade and reconfigure. One of its main advantages is that it can quickly integrate resident applications developed by different vendors through a resource-sharing platform to meet security requirements and reduce design cycles and development costs. The allocation of multi-constraint resident application resources in IMA systems runs through the design, implementation, and integration of IMA systems, and is a typical process of continuous iteration, feedback, and optimization. With the high integration of avionics systems and the widespread use of the IMA architecture, more and more applications reside on the IMA platform. How to ensure that reasonable computing and storage resources are allocated to resident applications developed by different vendors under the constraints of the computing and storage resources of the resident modules on the IMA platform, and under the constraints of strong coupling, has become one of the challenges in resource allocation.

[0003] The resource sharing and module performance constraints of the IMA platform dictate that resident applications need to compete for limited shared resources. Allocating resources to resident applications is an NP problem. Existing resource allocation methods rely on manual scheduling, subjective judgment, and personal experience, which is inefficient and cannot cope with dynamic scenarios. Some methods use greedy algorithms or genetic algorithms, which are highly random, have poor dynamic adaptability, are prone to getting trapped in local optima, and are prone to generating invalid solutions. Furthermore, these algorithms do not consider the isolation requirements of resident applications, specific resident needs, and partition execution cycle constraints, resulting in limited application scope.

[0004] Therefore, how to reasonably and effectively allocate a large number of resident applications from different vendors to different resident modules, ensuring that their computing resources, storage resources, and resident application isolation requirements are met, and forming an effective arrangement that meets the resident application partition execution cycle and satisfies the resident application allocation requirements of the IMA system, has always been a research hotspot in this field. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a resource allocation method for multi-constraint resident applications in IMA system based on immune algorithm, which can solve the optimization problem of resident application allocation in resident module under multi-constraint conditions and achieve global optimization.

[0006] The technical solution adopted by this invention to solve the above-mentioned technical problems is to provide a resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm, comprising the following steps: S1) quantifying the resource capabilities and quantity of resident modules in the IMA system; S2) determining the number of resident applications, the resource requirements of each application and their constraints, and quantifying them; S3) establishing a problem model based on the resource requirements and constraints of resident applications and the resource capabilities of resident modules, clarifying the constraint relationships and objectives; S4) using an immune algorithm based on the constraint relationships and objectives to solve the resource allocation scheme for multi-constraint resident applications in the IMA system; S5) selecting the resource allocation scheme for resident applications in the IMA system with the lowest change cost.

[0007] Further, step S1 quantifies module capabilities according to the following formula: Resource module set: CPM = {cpm1, cpm2, ..., cpm} n There are n resident modules in total; cpm j = (max_cal j max_mem j max_com j ); where cpm j This represents the j-th resident module in the IMA system, and the shared resources provided by the resident module for the resident applications; max_cal j This indicates the maximum computing resources that the resident module can provide; max_mem j This indicates the maximum storage resources that the resident module can provide; max_com j This indicates the maximum interface resources that the resident module can provide.

[0008] Further, step S2 quantifies the resident applications according to the following formula: Resident application set: HA = {ha1, ha2, ..., ha...} m There are a total of m resident applications; ha i = (cal i men i ,com i iso i ,peri i ,host i ); ha i This represents the resource requirements and application runtime constraints of the i-th resident application in the IMA system. The resource requirements are the shared resources that the resident module should provide for the resident application; cal i This indicates the computing resources required by the resident application, which are greater than the minimum partition execution time, and the result after subtracting the minimum partition time is an integer multiple of the time increment; mem i This indicates the storage resources required by the resident application; com i This indicates the interface resources required by the resident application; isoi This indicates the isolation requirements for the application; peri i This indicates the execution cycle of the resident application. The execution cycle of the IMA system's resident application is an integer multiple of the currently configured minimum execution cycle. i This indicates the specific residency requirements of the residency application.

[0009] Furthermore, the objective of step S3 is to allocate all resident applications to each resident module, with constraints including: the computing resources, storage resources, and interface resources allocated to each resident module for resident applications shall not exceed the total resources of the resident module, and shall meet the resident application isolation requirements, execution cycle scheduling requirements, and specific resident requirements.

[0010] Further, step S3 includes: S301, defining a decision variable x to represent the allocation of a resident application to a resident module. i,j = A decision variable of 1 indicates that the j-th resident module provides resources for the resident application, i.e., the decision variable is 1. i Assign to the j-th resident module; a decision variable of 0 indicates that cpm is not assigned to that module. j S302. Uniqueness of application allocation: Each resident application must be assigned to a resident module. , j=1, 2,...,n； S303, Describe specific residency requirements, residency application ha i Must be assigned to the specified resident module set CPM i CPM:x i,j =0, cpm i CPM i When CPM i When it is a certain CPM, it indicates that the resident application is HA. i Specify the allocation to this resident module; S304, describe the isolation requirements for resident applications, each ha i (iso) i This refers to an isolation group, where applications within the same isolation group are isolated: (iso) i Applications cannot be assigned to the same node; S305 describes the total resource constraints of the resident module and allocates them to the resident module's cpm. j The sum of computing resources of the resident applications shall not exceed the total computing resources of the resident module, the sum of storage resources shall not exceed the total storage resources of the resident module, and the sum of interface resources shall not exceed the total interface resources of the resident module. 。

[0011] Furthermore, step S3 also includes taking the remainder of the execution cycle of the resident application on each resident module with respect to the minimum execution cycle of the current configuration table, and determining whether the data item is odd or even based on the remainder. It requires that the sum of the execution times of the resident application computing resources allocated to the odd data item in the resident module within the cycle is less than the minimum execution cycle.

[0012] Further, step S4 includes: Step S401, Antibody Encoding and Population Initialization: The feasible solution to the problem is represented as antibodies in the solution space through encoding. The antibody is represented as an integer vector of length equal to the total number of resident applications. Each gene bit corresponds to an application, and the element value represents the resident application assigned to that resident module. The gene values ​​of module-bound applications with specific resident requirements are only allowed to be subsets of the specified resident modules, and the gene values ​​of redundant applications in the same group with application isolation requirements are mutually exclusive. Step S402, Affinity Calculation: Based on the objective and constraints, a suitable objective function is defined to evaluate the antibody quality. Constraints are used as penalty terms. The objective function adopts an affinity function with multiple constraints fusion to calculate the affinity of each antibody. Step S403, Immune Selection: An elite retention and dynamic elimination mechanism is adopted. The affinity of each antibody is calculated in each population update iteration. Step S404: Clonal Selection and Mutation: Based on antibody affinity, select high-affinity antibodies and perform targeted mutation on the clones. Step S405: Clonal Suppression: After clonal mutation, reselect the progeny antibodies generated by clonal mutation, suppress antibodies with low affinity, and retain antibodies with high affinity to enter the new antibody population. Step S406: New Antibodies and Population Update: Introduce random new antibodies that meet the constraints of the pretreatment, and sort them by affinity along with the antibodies retained in the memory bank and the clonal mutant antibodies. Select the top-ranked antibodies for population recombination to maintain a constant population size. Step S407: Termination and Output: Terminate when the maximum number of iterations is reached or there is no improvement for several consecutive generations, and output the high-affinity antibodies in the memory bank that meet the constraints, which is the optimal resident application allocation scheme.

[0013] Further, step S402 includes: designing the antibody affinity function as a weighted calculation of the variance of the resident module resource load and each constraint penalty term, or a weighted calculation of the average load rate of the resident module and each constraint penalty term.

[0014] Affinity = α·Load Variance +β·P capacity +γ·P module +δ·P redundancy +η·P period ；

[0015] Where: LoadVariance : Load variance between resident modules;

[0016] P capacity The penalty coefficient is calculated as the total number of times the module resource load exceeds the limit, and the constraint is that it cannot exceed the total load.

[0017] P module The number of times a module-bound application is assigned to a non-allowed resident module × the penalty coefficient, constraining the module binding requirements;

[0018] P redundancy The penalty coefficient is the number of times a redundant application fails to meet the application isolation requirements after allocation, and the constraint satisfies the application isolation requirements.

[0019] P period The number of times the sum of the execution times of the resident application computing resources of odd data items allocated to the module is greater than the minimum execution cycle execution time multiplied by the penalty coefficient, and the constraint satisfies the minimum execution cycle total load.

[0020] α, β, γ, δ, η Optimize through experiments.

[0021] Further, step S404 includes: Module-oriented mutation: Forcibly correcting the resident module number of the module-bound application to ensure that it is mapped to the designated resident module, and randomly adjusting only within its allowed resident module range; Conflict resolution mutation: For redundant applications co-resident modules or overloaded resident modules, randomly select conflicting gene positions within the same group and migrate them to the lowest load device; Ordinary gene mutation: Randomly mutate other ordinary application coding positions in the antibody with a certain probability; Random mutation: For all antibodies, if the random probability is less than the defined mutation probability, then the antibody gene is randomly modified; Adaptive mutation: Dynamically adjust the mutation rate according to the antibody affinity, apply a high mutation rate to low affinity antibodies, and promote balanced optimization.

[0022] Further, step S5 includes: outputting multiple resident application allocation schemes that meet the constraints, comparing them with the original allocation scheme according to the resident applications allocated, and selecting the allocation scheme that meets the constraints with the smallest change in the resident position of the module, which is the optimal resident application allocation scheme.

[0023] Compared with existing technologies, this invention offers the following advantages: The immune algorithm-based resource allocation method for multi-constraint resident applications in IMA systems provided by this invention relies on a high-security IMA resource sharing platform and its partitioning and isolation characteristics. It fully considers the computational resource requirements, storage resource requirements, application isolation requirements, application partition execution cycle requirements, and the number and performance of resident modules for each application. Based on the immune algorithm, it employs antibody generation with preprocessing mechanisms, affinity function design for multi-constraint fusion, and a targeted mutation strategy for conflict reduction to solve the optimization problem of resident module allocation for multi-resident applications under multiple constraints. Previously, resident application resource allocation schemes required repeated iterations during engineering development. Typically, there are dozens or hundreds of resident applications with varying residency requirements, isolation requirements, and execution cycles. Each reallocation took more than ten days. The method of this invention can generate an effective allocation scheme in minutes, greatly improving the efficiency of multi-constraint resident application resource allocation in IMA systems. Attached Figure Description

[0024] Figure 1 This is a schematic diagram illustrating the mapping relationship between the IMA system application and the resident module of the present invention;

[0025] Figure 2 This is a flowchart of the resource allocation process for multi-constraint resident applications in the IMA system based on the immune algorithm of this invention.

[0026] Figure 3 This is a flowchart of the multi-constraint resident application resource allocation algorithm for the IMA system of the present invention;

[0027] Figure 4 This is a schematic diagram of the directional mutation and conflict resolution process of the present invention;

[0028] Figure 5 This is a diagram illustrating the implementation effect of the application allocation method of the present invention. Detailed Implementation

[0029] The present invention will now be further described with reference to the accompanying drawings and embodiments.

[0030] This invention studies a method for allocating resident applications in an IMA system based on an immune algorithm. The IMA system rapidly integrates resident applications developed by different vendors through a resource-sharing platform, meeting security requirements and reducing design cycle and development costs. However, the allocation and scheduling of resident applications also becomes more complex, and the resource allocation of a large number of resident applications becomes an NP-hard problem. The resident application allocation method studied in this invention is as follows: Figure 1 As shown, the resident application needs to be assigned to the resident module and the constraints need to be met. The specific implementation steps of the present invention are shown in Figure 2.

[0031] Step S1: Quantify module capabilities, determine the resource capabilities and quantity of the IMA system's resident modules, i.e., determine the computing power (including configurable partition execution cycle, minimum partition execution time, and time increment), storage capacity, interface capabilities, and number of resident modules for the application; the corresponding quantification formula is:

[0032] Resource module set: CPM = {cpm1, cpm2, ..., cpm} n There are a total of n resident modules;

[0033] cpm j = (max_cal j max_mem j max_com j ).

[0034] Among them, cpm j This represents the j-th resident module in the IMA system, and the shared resources provided by the resident module for the resident applications; max_cal j This indicates the maximum computing resources that the resident module can provide; max_mem j This indicates the maximum storage resources that the resident module can provide; max_com j This indicates the maximum interface resources that the resident module can provide.

[0035] Step S2: Quantify the resource requirements of resident applications. Based on the capabilities of the resident modules, determine the resource requirements of resident applications developed by different vendors, namely, the execution cycle, computing resource requirements (time slice ratio), storage resource requirements, interface requirements, application isolation requirements, specific resident requirements, and their combinations. The corresponding quantification formula is:

[0036] Set of resident applications: HA = {ha1, ha2, ..., ha m There are a total of m resident applications;

[0037] ha i = (cal i men i ,com i iso i ,peri i ,host i );

[0038] Among them, ha i This represents the resource requirements and application runtime constraints of the i-th resident application in the IMA system. The resource requirements are the shared resources that the resident module should provide for the resident application; cal iThis indicates the computing resources required by the resident application, which are greater than the minimum partition execution time, and the result after subtracting the minimum partition time is an integer multiple of the time increment; mem i This indicates the storage resources required by the resident application; com i This indicates the interface resources required by the resident application; iso i This indicates the isolation requirements for the resident application. Typically, from a security perspective, it defines that applications with the same function (redundant applications) should reside on different modules, or even on modules in different racks, to avoid single points of failure and improve security; peri i This indicates the execution cycle of the resident application. The execution cycle of the IMA system's resident application is an integer multiple of the currently configured minimum execution cycle. i This indicates the specific residency requirements of the resident application; some applications must be deployed to specific modules (such as those that depend on specific hardware features).

[0039] Step S3: Based on the resource requirements and constraints of resident applications and the resource capabilities of resident modules, establish a problem model. The goal is to allocate all resident applications to each resident module. Constraints include: the computing resources, storage resources, and interface resources allocated to each resident module for resident applications shall not exceed the total resources of the resident module, and the isolation requirements, execution cycle scheduling requirements, and specific resident requirements of resident applications must be met; that is, satisfying the resource requirement constraints of resident applications and the capability limitations of each resident module (hard constraints) and optimizing resident load balancing (soft objective). The mathematical models are established as follows:

[0040] S301. To describe the allocation of resident applications to resident modules, define the following decision variables:

[0041] x i,j =

[0042] A decision variable of 1 indicates that the j-th resident module provides resources for the resident application, i.e., the decision variable is 1. i Assign to the j-th resident module; a decision variable of 0 indicates that cpm is not assigned to that module. j ;

[0043] S302. Uniqueness of application assignment: Each resident application must be assigned to a resident module;

[0044] , j = 1, 2,..., n.

[0045] S303, Describe specific residency requirements, residency application ha i Must be assigned to the specified resident module set CPM i CPM:

[0046] x i,j =0, cpm i CPM i ;

[0047] When CPM i When it is a certain CPM, it indicates that the resident application is HA. i Specify the module to be assigned to.

[0048] S304, describes the isolation requirements for applications residing in the area, for each... i (iso) i This refers to an isolation group, where applications within the same isolation group are isolated: (iso) i Applications in the same node cannot be assigned to the same node. i (iso) i ) HA.

[0049] x p,j +x q,j ≤1， ha i (iso i )∈HA, ha p , ha q ∈ha i (iso i ）， j = 1, 2,..., n; ( cpm j ∈ CPM; )

[0050] There can be multiple ha within any of the above isolation groups. i The quarantine requirements remain unchanged.

[0051] S305. Describe the total resource constraints for the resident modules and allocate them to the resident modules' CPM. j The sum of computing resources of the resident applications shall not exceed the total computing resources of the resident modules, the sum of storage resources shall not exceed the total storage resources of the resident modules, and the sum of interface resources shall not exceed the total interface resources of the resident modules.

[0052] , j = 1, 2,..., n;

[0053] , j = 1, 2,..., n;

[0054] , j = 1, 2,..., n.

[0055] In addition to considering the total computing resource requirements of the resident modules, the execution cycle of the applications resident on them, i.e., cpm, also needs to be considered. j On the resident application ha i execution cycle peri i The minimum execution cycle of the current configuration table is moduloed. Based on the remainder, odd or even data items are determined. The requirement is that the sum of the execution times within the cycle of the resident application's computing resources for odd data items allocated to this module is less than the minimum execution cycle; that is, the computing cycle load capacity is less than the module's cycle processing capacity. This is because different resident applications have different time cycle requirements. To ensure system computing resource utilization, different resident applications are allocated different execution cycles. However, to ensure that the allocated time for content within the same time cycle does not overflow, execution cycle constraints need to be designed. For example: Resident application A has an execution cycle of 50ms and is allocated 35ms; Resident application B has an execution cycle of 100ms and is allocated 20ms; Resident application C has an execution cycle of 250ms and is allocated 20ms. If three resident applications A, B, and C are allocated to the same resident module, the total computing resources do not exceed the module's total computing resources, but the module cannot run. With a minimum execution cycle of 50ms, the computing resources for the fifth minimum execution cycle are insufficient, causing the system to time out. If this design requirement is met, the system will be able to run normally and will not time out after successful allocation.

[0056] Define odd data item: ha i (odd) i =mod(ha) i (peri) i () / min_peri)==1;

[0057] Define decision variables:

[0058] y i,j =

[0059] The decision variable is 1, representing the resident application ha on the j-th resident module. i For odd data items; a decision variable of 0 indicates that the application is resident (ha). i The data item is either not residing in the j-th module or resides in the j-th module and is an even data item.

[0060] , j = 1, 2,..., n;

[0061] This means that the module cpm needs to be assigned to it. j The sum of the execution times of the resident application computing resources for odd data items within a given cycle is less than the minimum execution cycle, where... Indicates the resident application ha i Execution time within the period, min_peri i Assigned to the resident module cpm j The minimum execution cycle of a resident application. For example: resident applications ha1, ha3, and ha5 are assigned to the same resident module and are odd data items. The execution times of ha1, ha3, and ha5 are x1ms, x3ms, and x5ms respectively. The minimum execution cycle is defined as 50ms. Then, x1 + x3 + x5 < 50.

[0062] Non-empty resident modules: Each resident module has at least one resident application;

[0063] , j = 1, 2,..., n;

[0064] Describing resident load balancing (soft objective), minimizing the standard deviation of module resource usage (balance priority):

[0065] Minimize std( ), j=1,2,...,n.

[0066] Step S4: Based on the constraints and objectives, an immune algorithm is used to solve the resource allocation scheme for multi-constraint resident applications in the IMA system. The immune algorithm incorporates antibody diversity and a memory mechanism, possessing stronger global search capabilities and avoiding the local optima or backtracking problems of genetic algorithms. For example... Figure 3 As shown, the specific execution of the algorithm includes the following steps.

[0067] Step S401: Antibody Encoding and Population Initialization

[0068] 1) Encoding rule: The feasible solution of the problem is represented as antibodies in the solution space by encoding. The antibody is represented as an integer vector of length equal to the total number of resident applications. Each gene position corresponds to an application. The gene value ∈ n represents the target resident module number of the application. That is, the antibody structure is: a permutation of length m (number of resident applications), and the element value represents the resident application assigned to the resident module (1~n).

[0069] 2) Constraint preprocessing:

[0070] Generate results based on prior knowledge constraints in the problem domain, reducing invalid searches.

[0071] Specific residency requirements: For module-bound applications, gene values ​​are only allowed to be a subset of the specified residency modules (for example, application ha1 can only be assigned to residency modules {2,5,7}).

[0072] Application isolation requirements: For redundant applications, the gene values ​​of applications in the same group are different (e.g., applications ha2-ha4 need to be assigned to 3 different resident modules); in this case, it is necessary to perform constraint preprocessing when encoding case antibodies and initializing the population, and to intervene in the antibody generation process to remove invalid solutions in advance and speed up the algorithm operation.

[0073] 3) Initialization strategy:

[0074] The antibodies in the initial population are usually generated randomly to ensure the diversity of the solution space. An initial antibody population is generated by initializing the population to meet the constraints of the preprocessing conditions, and the generated initial antibody population is used as the initial solution.

[0075] ① Prioritize the allocation of module-bound and redundant applications to ensure that their constraints are met;

[0076] ② The remaining applications are randomly assigned, but the modules are guaranteed to be non-empty.

[0077] Alternatively, an initial antibody population can be randomly generated, and its specific residency and application isolation requirements can be checked to ensure that the module is not empty.

[0078] 4) Parameter initialization

[0079] Input the resident module resource capabilities, resident application list and constraint rules, and define the antibody selection ratio, mutation ratio and number of random new antibodies.

[0080] Step S402: Affinity Calculation

[0081] Based on the objectives and constraints, a suitable objective function is defined to evaluate antibody quality. The constraints are used as penalty terms. The objective function adopts an affinity function with multiple constraints. The affinity of each antibody is calculated so that the solution must meet these constraints to be accepted. In the process of evolution, solutions that do not meet the conditions are gradually eliminated.

[0082] The antibody affinity function is designed as a weighted calculation of the variance (balance) of the resident module's resource load and each constraint penalty term, or a weighted calculation of the average load rate of the resident module and each constraint penalty term.

[0083] Affinity = α·Load Variance +β·P capacity +γ·P module +δ·Predundancy +η·P period ；

[0084] Where: Load Variance : Load variance (balance) among resident modules;

[0085] P capacity The penalty coefficient is calculated as the total number of times the module resource load exceeds the limit, and the constraint is that it cannot exceed the total load.

[0086] P module The number of times a module-bound application is assigned to a non-allowed resident module × the penalty coefficient, constraining the module binding requirements;

[0087] P redundancy The penalty coefficient is the number of times a redundant application fails to meet the application isolation requirements after allocation, and the constraint satisfies the application isolation requirements.

[0088] P period The constraint is defined as follows: the number of times the sum of the execution times of the resident application computing resources for odd data items allocated to the module exceeds the minimum execution cycle execution time multiplied by a penalty coefficient, while satisfying the minimum execution cycle total load. α, β, γ, δ, η can Optimize through experiments.

[0089] Computing performance is usually the main factor limiting the allocation of resident applications. Therefore, the computing resources and execution cycle of resident modules should be considered. If computing performance is not the limiting factor, but storage or interface resources are, storage load and interface load should be considered, and computing resource load can be ignored.

[0090] Step S403: Immune Selection

[0091] An elite retention and dynamic elimination mechanism is adopted. In each population update iteration, the affinity of each antibody is calculated, and excellent antibodies are selected and stored in the memory bank to prevent the loss of high-quality solutions.

[0092] Immunoselective methods:

[0093] Based on affinity-based immune selection, each generation retains the antibodies with the highest fitness as memory cells.

[0094] Similarity suppression defines a similarity function between antibodies. Based on Hamming distance or affinity function, it calculates the distance between antibodies. If the similarity is greater than a threshold, low-affinity antibodies are randomly eliminated to maintain population diversity and avoid premature convergence.

[0095] Step S404: Clonal Selection and Mutation

[0096] Cloning and amplification: Based on antibody affinity, the selected superior antibodies are replicated in proportion. That is, the selected superior antibodies are cloned and targeted mutation operations are performed to enhance the exploration ability and maintain the diversity of the population.

[0097] Targeted mutation strategy: Perform targeted mutation on clones, employing conflict resolution strategies and hierarchical correction, such as... Figure 4 As shown.

[0098] Module-oriented mutation: Forces correction of the resident module number of the module-bound application to ensure that it is mapped to the specified resident module, and only randomly adjusts it within the range of its allowed resident modules;

[0099] Conflict resolution mutation: For redundant application co-resident modules or overloaded resident modules, randomly select conflicting gene sites within the same group and migrate them to the lowest load device;

[0100] Common gene mutations, with probability of random mutations at other common application coding positions in antibodies.

[0101] Mutation strategy selection:

[0102] Random mutation: For all antibodies, if the random probability is less than the defined mutation probability, then the antibody's gene is randomly modified (by applying coding position mutation).

[0103] Adaptive mutation: The mutation rate is dynamically adjusted based on antibody affinity, and the mutation probability is defined as p. m p m =k m × Affinity / Affinity max Applying a high mutation rate to low-affinity antibodies promotes balanced optimization.

[0104] Step S405: Clonal inhibition

[0105] After clonal mutation, the progeny antibodies produced by the clonal mutation are reselected to suppress antibodies with low affinity and retain antibodies with high affinity to enter a new antibody population.

[0106] Step S406: New Antibodies and Population Update

[0107] Novel Antibodies: Introduce random novel antibodies to maintain population diversity. The random novel antibodies should meet the constrained preprocessing conditions, so that invalid solutions can be screened out in advance and the algorithm iteration process can be accelerated.

[0108] Population recombination: Retaining memory bank antibodies, clonal variant antibodies, and random new antibodies, and sorting them by affinity, the population size is kept constant. During the population renewal process, excellent antibodies are retained, while maintaining population diversity and avoiding premature convergence.

[0109] Step S407: Termination and Output

[0110] The process terminates when the maximum number of iterations is reached or when there is no improvement for several consecutive generations. The output is the high-affinity antibody in the memory that meets the constraints, which is the optimal resident application allocation scheme.

[0111] Step S5: The algorithm supports design iteration or reuse of experience from similar models. If there is already an allocation scheme for similar models, with only some resident applications different, in order to utilize model experience and reduce the workload of changes, the algorithm can output multiple resident application allocation schemes that meet the constraints. These schemes are compared with the original allocation scheme according to the resident applications, and the allocation scheme that meets the constraints with the smallest change in the resident position of the modules is selected as the optimal resident application allocation scheme.

[0112] The implementation effect of the application allocation method is illustrated as follows: Figure 5 As shown, the method of the present invention can stably and quickly complete the allocation of resident applications (without conflicts and with sufficient capacity).

[0113] In summary, this invention provides a method for the layout and interface resource allocation of network transmission and interface conversion equipment in an IMA system. Based on the installation locations, interface types, and quantities of equipment from different vendors, and considering the total resource volume of each interface type and on-board layout constraints, a two-stage collaborative optimization method based on genetic algorithms and mixed-integer programming is employed. This includes spatial layout optimization and dynamic allocation optimization. An improved genetic algorithm is used to optimize the spatial layout of the interface data conversion equipment, and mixed-integer programming is used for the dynamic allocation of access interfaces. Finally, through joint cost evaluation of layout and allocation costs, and considering dynamic constraint processing and cost weight balancing, global optimality is achieved, thus solving the problem of interface data conversion equipment layout and interface resource allocation in an IMA system under multiple constraints.

[0114] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications and improvements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.

Claims

1. A resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm, characterized in that, Includes the following steps: S1) Quantify the resource capabilities and quantity of the IMA system's resident modules; S2) Determine the number of resident applications, the resource requirements and constraints of each application, and quantify them; S3) Based on the resource requirements and constraints of the resident applications and the resource capabilities of the resident modules, establish a problem model and clarify the constraints and objectives; S4) Based on the constraints and objectives, use an immune algorithm to solve the resource allocation scheme for multi-constraint resident applications in the IMA system; S5) Select the IMA system resident application resource allocation scheme with the lowest change cost; The goal of step S3 is to allocate all resident applications to each resident module. The constraints include: the computing resources, storage resources, and interface resources allocated to each resident module for resident applications shall not exceed the total resources of the resident module, and the resident application isolation requirements, execution cycle scheduling requirements, and specific resident requirements shall be met. Step S3 includes: S301. To describe the allocation of resident applications to resident modules, define the following decision variables: x i,j = ； A decision variable of 1 indicates that the j-th resident module provides resources for the resident application, i.e., the decision variable is 1. i Assign to the j-th resident module; a decision variable of 0 indicates that cpm is not assigned to that module. j ; S302. Uniqueness of application assignment: Each resident application must be assigned to a resident module; , j = 1, 2, ..., n; S303, Describe specific residency requirements, residency application ha i Must be assigned to the specified resident module set CPM i CPM: x i,j =0, cpm j CPM i ; When CPM i When it is a certain CPM, it indicates that the resident application is HA. i Specify the module to be assigned to; S304, describes the isolation requirements for applications residing in the area, for each... i iso i Represents an isolation group, where applications within the group are isolated: ISOs within the same isolation group... i Applications in the same node cannot be assigned to the same node; S305. Describe the total resource constraints for the resident modules and allocate them to the resident modules' CPM. j The sum of computing resources of the resident applications shall not exceed the total computing resources of the resident module, the sum of storage resources shall not exceed the total storage resources of the resident module, and the sum of interface resources shall not exceed the total interface resources of the resident module. Step S3 further includes taking the remainder of the execution cycle of the resident application on each resident module with respect to the minimum execution cycle of the current configuration table, and determining whether the data item is odd or even based on the remainder. It requires that the sum of the execution times of the resident application computing resources allocated to the odd data item of the resident module within the cycle is less than the minimum execution cycle.

2. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm as described in claim 1, characterized in that, Step S1 quantifies the module capability according to the following formula: Resource module set: CPM = {cpm1, cpm2, ..., cpm} n There are a total of n resident modules; cpm j =(max_cal j max_mem j max_com j ); Among them, cpm j This represents the j-th resident module in the IMA system, and the shared resources provided by the resident module for the resident applications; max_cal j This indicates the maximum computing resources that the resident module can provide; max_mem j This indicates the maximum storage resources that the resident module can provide; max_com j This indicates the maximum interface resources that the resident module can provide.

3. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm as described in claim 1, characterized in that, Step S2 quantifies the resident application according to the following formula: Set of resident applications: HA = {ha1, ha2, ..., ha m There are a total of m resident applications; ha i =(cal i ,men i ,com i ,iso i ,peri i ,host i ); ha i This represents the resource requirements and application runtime constraints of the i-th resident application in the IMA system. The resource requirements are the shared resources that the resident module should provide for the resident application; cal i This indicates the computing resources required by the resident application, which are greater than the minimum partition execution time, and the result after subtracting the minimum partition time is an integer multiple of the time increment; mem i This indicates the storage resources required by the resident application; com i This indicates the interface resources required by the resident application; iso i This indicates the isolation requirements for the application; peri i This indicates the execution cycle of the resident application. The execution cycle of the IMA system's resident application is an integer multiple of the currently configured minimum execution cycle. i This indicates the specific residency requirements of the residency application.

4. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm as described in claim 1, characterized in that, Step S4 includes: Step S401, Antibody Encoding and Population Initialization: The feasible solutions to the problem are represented as antibodies in the solution space through encoding. The antibody is represented as an integer vector of length equal to the total number of resident applications. Each gene bit corresponds to an application, and the element value represents the resident application assigned to that resident module. The gene values ​​of module-bound applications with specific resident requirements are only allowed to be a subset of the specified resident modules, and the gene values ​​of redundant applications in the same group with application isolation requirements are mutually exclusive. Step S402, Affinity Calculation: Based on the objective and constraints, define an appropriate objective function to evaluate antibody quality, use constraints as penalty terms, and adopt an affinity function with multiple constraints to calculate the affinity of each antibody. Step S403, Immune Selection: An elite retention and dynamic elimination mechanism is adopted. In each population update iteration, the affinity of each antibody is calculated, and excellent antibodies are selected and stored in the memory bank. Step S404, Clonal Selection and Mutation: Based on antibody affinity, replicate the best antibodies selected by immunization in proportion, and perform targeted mutation on the clones; Step S405, Clonal Suppression: After the clonal mutation operation, the progeny antibodies produced by the clonal mutation are reselected to suppress antibodies with low affinity and retain antibodies with high affinity to enter the new antibody population. Step S406, New Antibodies and Population Update: Introduce random new antibodies that meet the constraints of pretreatment, and sort them by affinity along with antibodies that retain the memory library and clonal variant antibodies. Select the top-ranked antibodies for population recombination to maintain a constant population size. Step S407, Termination and Output: Terminate when the maximum number of iterations is reached or when there is no improvement for several consecutive generations. Output the high-affinity antibodies in the memory that meet the constraints, which is the optimal resident application allocation scheme.

5. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm as described in claim 4, characterized in that, Step S402 includes: The antibody affinity function is designed as a weighted calculation of the variance of the resource load of the resident module and each constraint penalty term, or a weighted calculation of the average load rate of the resident module and each constraint penalty term. Affinity = α·Load Variance +β·P capacity +γ·P module +δ·P redundancy +η·P period ； Where: Load Variance : Load variance between resident modules; P capacity The penalty coefficient is calculated as the total number of times the module resource load exceeds the limit, and the constraint is that it cannot exceed the total load. P module The number of times a module-bound application is assigned to a non-allowed resident module × the penalty coefficient, constraining the module binding requirements; P redundancy The penalty coefficient is the number of times a redundant application fails to meet the application isolation requirements after allocation, and the constraint satisfies the application isolation requirements. P period The number of times the sum of the execution times of the resident application computing resources of odd data items allocated to the module is greater than the minimum execution cycle execution time multiplied by the penalty coefficient, and the constraint satisfies the minimum execution cycle total load. α, β, γ, δ, η Optimize through experiments.

6. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm as described in claim 4, characterized in that, Step S404 includes: Module-oriented mutation: Forces correction of the resident module number of the module-bound application to ensure that it is mapped to the specified resident module, and only randomly adjusts it within the range of its allowed resident modules; Conflict resolution mutation: For redundant application co-resident modules or overloaded resident modules, randomly select conflicting gene sites within the same group and migrate them to the lowest load device; Common gene mutations randomly mutate other common application coding positions in antibodies with a certain probability; Random mutation: For all antibodies, if the random probability is less than the defined mutation probability, then the antibody's gene is randomly modified; Adaptive mutation: The mutation rate is dynamically adjusted according to antibody affinity, and a high mutation rate is applied to antibodies with low affinity to promote balanced optimization.

7. The resource allocation method for multi-constraint resident applications in an IMA system based on an immune algorithm as described in claim 1, characterized in that, Step S5 includes: outputting multiple resident application allocation schemes that meet the constraints, comparing them with the original allocation scheme according to the resident applications allocated, and selecting the allocation scheme that meets the constraints with the smallest change in the resident position of the module, which is the optimal resident application allocation scheme.

Images