A method for verifying and reallocating resource allocation consistency of an avionics core processing system
By standardizing and automating the resource allocation scheme of the avionics core processing system, the problem of low automation in resource allocation consistency verification in existing technologies has been solved, achieving efficient resource allocation consistency verification and reallocation, and improving system integration efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING AERONAUTIC SCI & TECH RES INST OF COMAC
- Filing Date
- 2026-03-19
- Publication Date
- 2026-07-31
AI Technical Summary
Existing resource allocation consistency verification methods have low automation in integrated modular avionics systems, resulting in low verification efficiency, difficulty in early error detection, and heavy workload for subsequent configuration iterations.
The method of resource allocation consistency verification and reallocation of the avionics core processing system is adopted. By standardizing the initial resource allocation plan and the requirements of the resident applications, and combining the resource allocation principles and platform attributes, the system realizes automated resource allocation consistency verification and iterative reallocation.
It improves the accuracy of resource allocation and system integration efficiency, reduces the number of iterations, avoids omissions and errors caused by manual verification, and improves the accuracy and efficiency of verification.
Smart Images
Figure CN122489252A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Integrated Modular Avionics (IMA) technology, and more specifically to a method for verifying and reallocating resource allocation consistency in an avionics core processing system. Background Technology
[0002] Most large aircraft currently in service adopt the Integrated Modular Avionics Architecture (IMA). The IMA system provides computing resources, network resources, interface resources, etc., for the aircraft's onboard systems. Other aircraft systems use the resources provided by the IMA system in the form of resident applications or resident functions to interconnect with related systems and achieve system integration.
[0003] Based on the resource requirements of each aircraft system for the IMA system, and considering the IMA system architecture, resources including CPU processing time, memory space, communication bus bandwidth, storage capacity, and interface transmission need to be allocated to each system. The rationality of early resource allocation directly determines the performance of later system integration; therefore, rigorous resource allocation consistency verification is required in the early stages of allocation to ensure: 1) The resources allocated to each functional partition meet its performance and security requirements; 2) Achieve physical and logical isolation between functions of different security levels (DAL); 3) Resource allocation should be consistent with the design configuration table and requirement specifications.
[0004] Resource allocation for integrated modular avionics systems is based on the resources required for potential residency functions or applications, combined with the IMA platform architecture and platform module attributes. The resource allocation scheme directly impacts system integration performance, the residency scheme of the IMA system, and even the integration efficiency of the entire aircraft system. The correctness of the early resource allocation scheme directly affects the efficiency of subsequent resource configuration work. If the early resource allocation is inconsistent with the requirements and is not detected, it will lead to later resource configurations failing to meet resource requirements, necessitating a re-iteration of resource configuration work. In typical civil aircraft development, a single configuration iteration may take anywhere from several hours to several days. If the consistency between the resource allocation scheme and resource requirements can be verified at the initial stage of resource allocation, subsequent iteration work can be significantly reduced, shortening the iteration time.
[0005] Currently, existing methods for verifying resource allocation consistency mainly include static analysis, dynamic monitoring, isolation testing, stress and boundary testing, supplemented by toolchains to achieve partial automation. However, these existing methods have the following limitations: Static analysis methods are often implemented independently by different teams and tools, lacking a unified validation framework and data management. The consistency check between resource allocation plans and resource requirements still mainly relies on manual comparison of resource allocation plans and requirements documents, which is prone to overlooking errors or producing inconsistencies. Furthermore, the lack of automatic resource allocation consistency checks makes it difficult to maintain high efficiency during multiple iterations. Summary of the Invention
[0006] In view of this, the present invention proposes a method for verifying and reallocating the consistency of resource allocation in the core avionics processing system. This method aims to solve the problems of low verification efficiency, difficulty in early detection of errors, and heavy subsequent configuration iteration work caused by low automation and insufficient systemicity in the early stages of integrated modular avionics system design. This method improves the correctness of early resource allocation, reduces the number of resource allocation iterations, and improves the efficiency of resource allocation iteration and system integration.
[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for verifying and reallocating resource allocation consistency in an avionics core processing system, comprising the following steps: Resource allocation standardization steps: The preliminary resource allocation plan and resident application requirements of the avionics core processing system are standardized to obtain a standardized preliminary resource allocation plan and resident application requirements; Resource allocation consistency verification steps: Based on the standardized preliminary resource allocation scheme and the requirements of the resident applications, combined with the resource allocation principles, the architecture of the avionics core processing system and the attributes of the avionics core processing platform, the resource allocation scheme is systematically verified to obtain the resource allocation consistency verification results; Resource reallocation steps: Based on the resource allocation consistency verification results, iteratively correct the allocation schemes that do not meet the requirements, and output a resource reallocation scheme that meets the requirements.
[0008] In one specific implementation, the resource allocation standardization steps include: valid character reading, duplicate interface judgment, blank line filling, and conflict checking.
[0009] In a specific implementation scheme, the effective character reading includes: reading all characters, and only treating uppercase and lowercase English letters, underscores, Chinese and English commas, spaces, and newlines as effective characters; using newlines and English commas as delimiters to initially segment the read string; distinguishing based on the number of characters before and after spaces to determine whether consecutive spaces represent the same interface or different interfaces; and standardizing and merging different writing styles of the same interface using a fuzzy comparison method.
[0010] In a specific implementation scheme, the fuzzy comparison method uses a string similarity algorithm to calculate the similarity between two interface names. When the similarity exceeds a preset threshold, they are determined to be different spellings of the same interface and are merged into a unified standard name. The string similarity algorithm uses a weighted calculation method of edit distance similarity and token-level similarity, with edit distance similarity weight 'a' and token-level similarity weight 'b', and a+b=1. When the overall similarity is greater than 0.9, they are determined to be the same interface.
[0011] In a specific feasible implementation, the resource allocation consistency verification step includes: taking the standardization results, resource allocation principles, and platform attributes as input, performing isolation / binding requirement verification, redundancy requirement verification, and other resource allocation verification on computing resources and transmission / interface resources respectively, to obtain the resource allocation consistency verification result; the platform attributes include the platform architecture, the interface types and corresponding number of interfaces of each device in the platform, and the cabin information of the device.
[0012] In a specific implementation scheme, the verification of computing resources includes: comparing whether the computing resources required by each resident application or resident system match the allocated resources; calculating whether the total computing power allocated to each hardware exceeds the hardware capacity limit; and calculating whether the proportion of the allocated resources to the total capacity meets the allocation rules and requirements. The computing resources include: computing memory, storage capacity, file system size, computing time, and scheduling cycle.
[0013] In a specific feasible implementation, the verification of the transmission / interface resources includes: verifying whether the interface allocation meets the isolation / binding requirements; verifying whether the device location allocated to the interface meets the device bay requirements; verifying whether the interfaces with redundancy requirements greater than or equal to 1 are allocated the corresponding number of devices; verifying whether the bandwidth and power supply requirements match; and counting the number of interfaces allocated to the devices and comparing it with the device capabilities.
[0014] In a specific implementation, the resource reallocation step includes: reading conflict items in the resource allocation consistency verification result; when a conflict item exists, allocating resident applications or interfaces that do not meet the binding requirements to physical units or devices that meet the binding requirements according to the binding requirements; randomly selecting and adjusting from all possible physical units or devices according to the isolation requirements; and optimizing the allocation of interfaces or resident applications that have not been successfully modified using an integral strategy.
[0015] In a specific implementation scheme, the step of randomly selecting and adjusting according to isolation requirements includes: when an interface needs to be allocated, and its requirements include isolation from several interfaces and allocation to a designated equipment compartment, all possible physical units or devices to be allocated are all devices in the designated equipment compartment except for the devices that have been allocated isolated interfaces.
[0016] In one specific implementation, the integration strategy includes: for each unsuccessfully modified interface or resident application, listing all possible devices or physical units to which it may be allocated; and setting an initial integration score for each device. ,in , This represents the total number of allocatable devices; it calculates the percentage of isolation or binding requirements satisfied after the interface is assigned to a device. If not satisfied Save and sort all The value is selected based on the redundancy requirements of the interface. The largest Each device or physical unit serves as the final allocation scheme for this interface, where This refers to the number of redundant requirements.
[0017] Compared with existing technologies, the resource allocation consistency verification and reallocation method for avionics core processing systems described in this invention is used for verifying resource allocation schemes in the early stages of integrated modular avionics (IMA) system design. By capturing the computing, storage, interface, and isolation binding requirements of resident applications and comparing them with the preliminary resource allocation scheme, and combining resource allocation principles, IMA system architecture, and platform attributes as common constraints, the method achieves automated resource allocation consistency verification and iterative reallocation of the resource allocation scheme. This effectively improves the correctness of early resource allocation and system integration efficiency, and has the following beneficial effects: 1. It has achieved automated and systematic verification of resource allocation consistency.
[0018] This invention standardizes the initial resource allocation scheme and the requirements of the resident applications, and performs systematic classification and verification based on the standardization results, allocation principles and platform constraints. It can automatically compare the resource allocation scheme with the design requirements to avoid omissions, errors or inconsistencies that may be caused by traditional manual verification methods, thus improving the efficiency and accuracy of verification.
[0019] 2. It provides standardized requirements and allocation data management capabilities and supports automated redistribution iterations.
[0020] This invention utilizes methods such as effective character reading and fuzzy comparison to automatically standardize inconsistent names and formats in multi-source inputs, obtaining standardized data that can be used for subsequent verification. Furthermore, based on the resource allocation consistency verification results, an automated reallocation process—first random allocation followed by optimization based on an integral strategy—corrects allocation schemes that do not meet requirements. This provides support for quickly obtaining a suitable residency scheme in the early stages of design, reducing the risk of rework and iteration costs later on. Attached Figure Description
[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0022] Figure 1 This is an overall flowchart of the resource allocation consistency verification and reallocation method for the avionics core processing system described in this invention.
[0023] Figure 2 A standardized flowchart for resource allocation.
[0024] Figure 3 Flowchart for reading valid characters.
[0025] Figure 4 Flowchart for verifying consistency in resource allocation.
[0026] Figure 5 The flowchart shows the redistribution method. Detailed Implementation
[0027] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0028] Based on the requirements of resident applications, the preliminary resource allocation scheme of the avionics core processing system, the attributes of the avionics core processing platform, the resource allocation principles of the avionics core processing system, and the architecture of the avionics core processing system, this invention proposes a method for consistency verification and reallocation of avionics core processing system resource allocation. Through a standardized preprocessing, systematic classification verification, and intelligent iterative reallocation process, it achieves automated consistency verification and optimization of the avionics core processing system (IMA) resource allocation scheme. The purpose of this invention is to improve the correctness of early resource allocation, reduce the number of resource allocation iterations, and improve the efficiency of resource allocation iterations. Specifically, it verifies whether the preliminary resource allocation scheme of the avionics core processing system meets the resource requirements of resident applications, thereby supporting the functional implementation of resident applications or resident systems and meeting performance indicators. For allocation schemes that do not meet the requirements, reallocation is performed based on the initial scheme to ensure that it meets the resource allocation requirements of the avionics core processing system.
[0029] To better understand the technical solution of this invention, some technical terms used in this document are explained below. It should be noted that these explanations are illustrative and for ease of understanding, and should not be used to limit the scope of protection of this invention.
[0030] 1. Integrated Modular Avionics System (IMA): This refers to an avionics system that adopts a modular and open architecture, providing a common computing, networking, and interface resource platform for aircraft onboard systems.
[0031] 2. Avionics Core Processing System: This is a core component of the IMA system, responsible for providing computing resources, network resources, and interface resources to various aircraft systems. In this invention, the Avionics Core Processing System and the IMA system can be understood and used interchangeably.
[0032] 3. Avionics core processing platform: refers to the hardware platform that carries resident applications and resident functions, which consists of multiple processing modules, network switching modules and interface modules and other physical units / devices.
[0033] 4. Resident applications: These are system application software that runs in the form of software on the avionics core processing platform to perform specific functions.
[0034] 5. Resident Functions: These are system functions implemented using the resources of the avionics core processing platform (especially interface and network resources), and are usually completed by one or more resident applications.
[0035] 6. Resident Scheme: This refers to the final scheme formed after allocating resources on the avionics core processing platform based on the resource requirements of resident applications and resident functions for computing, storage, interfaces, networks, etc.
[0036] 7. Equipment / Physical Unit: refers to the smallest hardware unit that constitutes the core avionics processing platform, such as specific processing modules, network switches, remote data interface units, etc., and is the final carrier of resource allocation.
[0037] 8. Equipment bays: These refer to the different physical areas on an aircraft used for installing avionics equipment, such as the "cockpit," "forward electronic equipment bay (EE bay)," and "rear EE bay." Each piece of equipment has its own designated installation bay.
[0038] like Figure 1 As shown, the present invention provides a method for verifying and reallocating the consistency of resource allocation in an avionics core processing system. This method is applied to the verification of the consistency of resource allocation and the verification of the dwell scheme in the early design stage of the avionics core processing system in civil aircraft. Specifically, it includes three key stages: the resource allocation standardization stage, the resource allocation consistency verification stage, and the resource reallocation stage. The inputs to the method described in this invention include: resident application requirements, preliminary resource allocation scheme for the avionics core processing system, attributes of the avionics core processing platform, resource allocation principles for the avionics core processing system, and architecture of the avionics core processing system. The output of the method described in this invention includes: system resource allocation consistency verification results and resource reallocation scheme report.
[0039] The specific steps of the avionics core processing system resource allocation consistency verification and reallocation method described in this invention include: S1: Standardization stage of resource allocation; The purpose of this phase is to standardize the initial resource allocation plan and the requirements of the resident applications, providing a standardized and unified data foundation for subsequent resource allocation consistency verification. The resource allocation standardization process is as follows: Figure 2 As shown, the preliminary resource allocation plan and the requirements for resident applications are presented in tabular form. The columns are the interface name, the allocated device, the binding requirements, the isolation requirements, etc., and the rows are the allocation results or allocation requirements for different interfaces.
[0040] Resource allocation standardization: Taking the preliminary resource allocation plan for the avionics core processing system and the requirements of resident applications as input, valid characters are read (process as follows). Figure 3 (As shown), duplicate interface judgment, blank line filling and conflict checking, output the standardized preliminary resource allocation plan and resident application requirements.
[0041] Blank row filling refers to blank sections that appear during file reading due to table merging. The principle of blank row filling is to directly fill the previous section with content.
[0042] S2: Resource allocation consistency verification phase; Based on the standardized results, this phase systematically verifies the resource allocation scheme by considering resource allocation principles, the architecture of the avionics core processing system, and the attributes of the avionics core processing platform. The process is as follows: Figure 4 As shown. The specific steps are as follows: Resource allocation consistency verification: Taking the standardization results, the resource allocation principles of the avionics core processing system and platform attributes as input, the isolation / binding requirements, redundancy requirements and other resource allocation verifications are performed on computing resources and transmission / interface resources respectively to obtain the resource allocation consistency verification results; Platform attributes include the platform architecture, the interface types and corresponding number of each device within the platform, and the cabin information of the device. In the final step of resource allocation consistency verification, the actual total number of interfaces carried by each device is calculated and compared with the number of interfaces it can carry to determine whether the preliminary resource allocation plan exceeds the platform attribute limitations. The resource allocation consistency verification is performed in the following order: first verifying the isolation / binding requirements of resource allocation, then verifying redundancy requirements, and finally verifying other resource allocation requirements.
[0043] S3: Resource reallocation phase; Based on the above resource allocation consistency verification and standardization results, this stage automatically adjusts and optimizes conflicting resource allocation schemes. The specific process is as follows: Figure 5 As shown. The specific steps are as follows: Resource reallocation: Read conflicting items from the resource allocation consistency verification results, and reallocate and modify resident applications or interfaces that do not meet the isolation / binding requirements according to the isolation / binding requirements. When there are items that are not successfully modified, an integral strategy is used to optimize the allocation and output a resource reallocation scheme that meets the requirements.
[0044] In a specific implementation scheme, the valid character reading in S1 includes: reading all characters, only considering five types of characters—uppercase and lowercase English letters, underscores, Chinese and English commas, spaces, and newlines—as valid characters for reading; preliminary segmentation, using newlines and English commas as delimiters to divide the read string; space judgment and segmentation, distinguishing based on the number of characters before and after a space to determine whether consecutive spaces represent the same interface or different interfaces; and same interface judgment and merging, standardizing and merging different writing styles of the same interface through fuzzy comparison.
[0045] The following is a specific example of using spaces to determine separation: For the interface “get flight data” to be read, the characters before and after the two spaces are 3, 5, and 4 respectively. When the number of letters before and after the space is less than or equal to 5, it is considered to be the same interface, that is, “get flight data” is an interface name. For the interface “control_cmd_send get flight data” to be read, since there are 16 consecutive valid characters before the first space, the first space is used as the separator. The final reading result is two interfaces, “control_cmd_send” and “get flight data”.
[0046] Based on engineering experience, the number of valid characters for segmentation here is set to 5.
[0047] The fuzzy comparison method uses a string similarity algorithm (such as the edit distance algorithm) to calculate the similarity between two interface names. When the similarity exceeds a preset threshold (such as 0.9), it is determined to be different ways of writing the same interface and is merged into a unified standard name.
[0048] The method for calculating edit distance class similarity is as follows: Let the two interface name strings be respectively Where n and m are the string lengths, respectively. Edit distance is defined as... Transform into The minimum number of edits required, including inserting, deleting, and replacing characters. Let the edit distance be denoted as . .
[0049] Since edit distance is a "difference degree", this invention uses the following normalization process:
[0050] in, Used to eliminate the effects of string length differences; The larger the value, the closer the strings are.
[0051] The token-level similarity calculation method is as follows: First, the interface name is tokenized. Tokens can be split using camelCase (e.g., splitting getFlightData into {get, flight, data}) or underscores (e.g., splitting get_flight_data into {get, flight, data}). The resulting token sets are as follows:
[0052] Token Jaccard similarity is defined as:
[0053] Based on edit distance similarity and token-level similarity, a weighted fusion method is used to calculate the comprehensive similarity: , in, .
[0054] In practice, the edit distance similarity between the two interface name strings is first calculated. If the similarity is less than 0.9, they are directly identified as different interfaces; if the similarity is greater than or equal to 0.9, their Token Jaccard similarity is further calculated. Then, the comprehensive similarity is calculated according to the aforementioned weighted fusion formula (edit distance similarity weight 0.6, Token Jaccard similarity weight 0.4). When the comprehensive similarity is greater than 0.9, they are identified as the same interface and merged.
[0055] Final calculation results: `getFlightData <-> get_flight_data` (0.93) merges the two methods. sendControlCommand <-> control_cmd_send (0.85) should not be merged; `getFlightData <-> setFlightData` (≈0.72) does not merge.
[0056] In this invention, the threshold value is selected as 0.9.
[0057] In a specific implementation scheme, the duplicate interface judgment in S1 includes: judging whether there are duplicate interfaces in the interface name column of the resource allocation scheme, marking the duplicate interfaces but not removing them, so as to ensure subsequent problem tracing; judging whether there are duplicate interfaces in the isolation / binding requirements. Here, interface duplication refers to the possibility that there is an allocated interface in the isolation binding requirements. In this case, the duplicate interfaces are directly removed and noted in the remarks, which is the conflict check described in the next paragraph.
[0058] Interface duplication falls into two categories: duplicate interface names and duplicate interfaces within isolation / binding requirements. This can be understood as duplication of three columns of data: the interface name column, the isolation requirement column, and the binding requirement column. The specific methods for detecting and handling duplicates are as follows: The method for determining if an interface name is duplicated is to iterate through all interface names and record them in the same set. When an interface name appears twice, the second appearance of the interface name is marked and the final report indicates that the interface is duplicated. At the same time, the second appearance of the interface name is not recorded in the interface name set. In this way, it will not be checked or allocated repeatedly in the subsequent consistency verification and reallocation phase. The duplicate check for isolation / binding requirements involves checking if the interface itself exists in the isolation / binding requirement; if it does, it is deleted directly.
[0059] In a specific implementation, the conflict check in S1 includes: checking whether there is a conflict between the interface requirement and the interface itself. If the interface itself appears in the isolation requirement, the interface is directly removed from the isolation requirement. This is an example illustrating how conflict checking is performed on isolation binding; the conflict checking method for binding requirements is the same. There should be no mutual exclusion in isolation bindings, therefore no check is performed. If there is mutual exclusion in isolation binding requirements, it indicates an error in the provided requirement input, which is not within the scope of this invention's checks.
[0060] In a specific implementation scheme, the resource allocation consistency verification of the computing resource allocation scheme in S2 includes: comparing whether the computing resources required by each resident application or resident system match the allocated resources; calculating whether the total value of the computing power allocation for each hardware exceeds the hardware capability limit; and calculating whether the proportion of the allocated resources to the total capability meets the allocation rules and requirements. The computing resources include: computing memory, storage capacity, file system size, computing time, and scheduling cycle.
[0061] In a specific implementation scheme, the resource allocation consistency verification of the transmission / interface resource allocation scheme in S2 includes: verifying whether the interface allocation meets the isolation / binding requirements; verifying whether the device location allocated to the interface meets the device bay requirements; verifying whether the interfaces with redundancy requirements greater than or equal to 1 are allocated the corresponding number of devices; verifying whether the bandwidth and power supply requirements match; and counting the number of interfaces allocated to the devices and comparing it with the device capabilities.
[0062] This section provides a clear explanation and definition of equipment compartments, equipment, and physical units: Equipment slots: Aircraft are divided into multiple compartments, such as the "cockpit", "front EE compartment", and "middle EE compartment". Different equipment is placed in different compartments. The requirements document defines the equipment slot requirements for each resident application or interface. Each device or physical unit also has a corresponding equipment slot. During the resource allocation consistency verification process, it is necessary to compare whether the equipment slot required by the resident application or interface is consistent with the slot where the allocated device or physical unit is located.
[0063] Devices and physical units refer to the physical modules to which applications or interfaces reside; these can be specific devices or physical units.
[0064] In a specific feasible implementation, the resource reallocation in S3 adopts an iterative correction mechanism, including: reading the number of conflict items C in the resource allocation consistency verification result; when C is greater than 0, performing an adjustment operation; recalculating the adjusted number of conflict items C; when C is still greater than zero, entering a loop, recording the loop count j, and repeating the adjustment operation until j>5 or C=0, exiting the loop and outputting the resource reallocation scheme. The flowchart is as follows: Figure 5 As shown.
[0065] Experiments have shown that a loop count of 5 is sufficient to redistribute data with no more than 1500 interfaces. When the number of interfaces exceeds 1500, the loop count can be increased as needed. However, to ensure computation time, the loop count should generally not exceed 10.
[0066] In actual experiments, there were indeed cases where the number of loops was greater than 5 but C was not zero. In such cases, increasing the number of loops still could not reduce C to 0. At this point, the interfaces that had not been successfully assigned were marked, and these interfaces were subsequently manually adjusted and checked.
[0067] The adjustment operation includes: assigning resident applications or interfaces that do not meet the binding requirements to reasonable physical units or devices according to the binding requirements; randomly selecting and adjusting from all possible physical units or devices according to the isolation requirements; and optimizing the allocation by using an integral strategy if there are still interfaces or resident applications that have not been successfully modified after the above adjustments.
[0068] Random selection is just one allocation strategy to obtain the result of the redistribution. The final allocation scheme needs to be checked again. As long as the allocation scheme can meet the resource requirements, the allocation scheme is reasonable.
[0069] The random selection method is as follows: If interface 'a' needs to be assigned, and interface 'a' must be isolated from interfaces 'b', 'c', and 'd' in the requirements, and interface 'a' needs to be assigned to equipment slot S, then if interface 'b' is assigned to equipment A and interfaces 'c' and 'd' are assigned to equipment B, then all possible physical units or equipment that interface 'a' can be assigned to are all equipment in equipment slot S except for equipment A and B. During random selection, there may be a situation where "all possible physical units or equipment" is empty. In this case, the algorithm marks the interface and skips it, proceeding with subsequent interface assignments. This situation occurs because of an incorrect requirement, requiring manual verification of the requirement's accuracy. Therefore, when encountering this situation, the assignment of the interface is skipped, and the error is noted in the final report.
[0070] In one specific implementation, the integration strategy includes: for each unsuccessfully modified interface or resident application, listing all possible devices or physical units to which it may be allocated; and setting an initial integration score for each device. Let i = 1, 2, ..., j, where j is the total number of allocatable devices; calculate the value of each isolation or binding requirement satisfied after the interface is assigned to a device. If not satisfied Here, it refers to meeting the requirements of the interface itself. Examples of situations where the requirements are not met are as follows: It should be bound to interface B, but interface B does not exist on the target device; or it should be isolated from interface C, but interface C has already been assigned to the target device. Save and sort all Si values, and select the k devices or physical units with the largest Si as the final allocation scheme for the interface based on the redundancy requirements of the interface, where k is the number of redundancy requirements; recalculate the number of conflicts C of all allocation schemes after modification. If C>0, enter the loop; otherwise, save the allocation scheme and output it.
[0071] If the input requirements are complete, the results should converge in principle, and there should be no infinite loop. In actual implementation, since there may be some errors in the requirements document, the number of loops can be set and stopped after a certain number of loops is reached.
[0072] The initial integral Si is 0, and additions and subtractions are performed on it; Determine if "a requirement is met": For example, if interface a needs to be bound to interface b, and interface a needs to be isolated from interface c, read the device to which interface a is assigned. Assuming that interface a is assigned to device A, if interface b is assigned to device A, then interface a is considered to meet a binding requirement, Si+1; if none of the interfaces assigned to device A are interface c, then an isolation requirement is considered to be met, Si+1, and finally Si=2.
[0073] Cabin requirements: The interface requirements describe the specific cabin where the interface should be located. The equipment or physical units that may be assigned have fixed cabin locations. Cabin requirements must be considered during the allocation process. That is, during the reallocation process, for each interface to be modified, the equipment that may be assigned must be selected in the corresponding cabin.
[0074] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. An avionics core processing system resource allocation consistency verification and reallocation method, characterized in that, Includes the following steps: Resource allocation standardization steps: The preliminary resource allocation plan and resident application requirements of the avionics core processing system are standardized to obtain a standardized preliminary resource allocation plan and resident application requirements; Resource allocation consistency verification steps: Based on the standardized preliminary resource allocation scheme and the requirements of the resident applications, combined with the resource allocation principles, the architecture of the avionics core processing system and the attributes of the avionics core processing platform, the resource allocation scheme is systematically verified to obtain the resource allocation consistency verification results; Resource reallocation steps: Based on the resource allocation consistency verification results, iteratively correct the allocation schemes that do not meet the requirements, and output a resource reallocation scheme that meets the requirements.
2. The avionics core processing system resource allocation consistency verification and reallocation method of claim 1, wherein, The standardized steps for resource allocation include: reading valid characters, judging duplicate interfaces, filling blank lines, and checking for conflicts.
3. The avionics core processing system resource allocation consistency verification and reallocation method of claim 2, wherein, The effective character reading includes: reading all characters, only treating uppercase and lowercase English letters, underscores, Chinese and English commas, spaces, and newlines as effective characters; using newlines and English commas as delimiters to initially segment the read string; distinguishing based on the number of characters before and after spaces to determine whether consecutive spaces represent the same interface or different interfaces; and standardizing and merging different writing styles of the same interface through fuzzy comparison.
4. The avionics core processing system resource allocation consistency verification and reallocation method of claim 3, wherein, The fuzzy comparison method uses a string similarity algorithm to calculate the similarity between two interface names. When the similarity exceeds a preset threshold, they are determined to be different spellings of the same interface and are merged into a unified standard name. The string similarity algorithm uses a weighted calculation of edit distance similarity and token-level similarity, with edit distance similarity weight 'a' and token-level similarity weight 'b', and a+b=1. When the overall similarity is greater than 0.9, they are determined to be the same interface.
5. The avionics core processing system resource allocation consistency verification and reallocation method of claim 1, wherein, The resource allocation consistency verification step includes: taking the standardization results, resource allocation principles, and platform attributes as input, performing isolation / binding requirement verification, redundancy requirement verification, and other resource allocation verification on computing resources and transmission / interface resources respectively, to obtain the resource allocation consistency verification result; the platform attributes include the platform architecture, the interface types and corresponding number of interfaces of each device in the platform, and the cabin information of the device.
6. The avionics core processing system resource allocation consistency verification and reallocation method of claim 5, wherein, The verification of computing resources includes: comparing whether the computing resources required by each resident application or resident system match the allocated resources; calculating whether the total computing power allocated to each hardware exceeds the hardware capacity limit; and calculating whether the proportion of the allocated resources to the total capacity meets the allocation rules and requirements. The computing resources include: computing memory, storage capacity, file system size, computing time, and scheduling cycle.
7. The avionics core processing system resource allocation consistency verification and reallocation method of claim 5, wherein, The verification of the transmission / interface resources includes: verifying whether the interface allocation meets the isolation / binding requirements; verifying whether the device location allocated to the interface meets the device bay requirements; verifying whether the interfaces with redundancy requirements greater than or equal to 1 are allocated the corresponding number of devices; verifying whether the bandwidth and power supply requirements match; and counting the number of interfaces allocated to the devices and comparing it with the device capabilities.
8. The method for verifying and reallocating resource allocation consistency in an avionics core processing system according to claim 1, characterized in that, The resource reallocation step includes: reading conflict items in the resource allocation consistency verification result; when there are conflict items, allocating resident applications or interfaces that do not meet the binding requirements to physical units or devices that meet the binding requirements according to the binding requirements; randomly selecting and adjusting from all possible physical units or devices according to the isolation requirements; and optimizing the allocation of interfaces or resident applications that have not been successfully modified using an incentive strategy.
9. The avionics core processing system resource allocation consistency verification and reallocation method of claim 8, wherein, The adjustment based on random selection according to isolation requirements includes: when an interface needs to be allocated, and its requirements include isolation from several interfaces and allocation to a designated equipment compartment, all possible physical units or devices to be allocated are all devices in the designated equipment compartment except for the devices that have been allocated isolated interfaces.
10. The avionics core processing system resource allocation consistency verification and reallocation method of claim 8, wherein, The points allocation strategy includes: for each unsuccessfully modified interface or resident application, listing all possible devices or physical units to which it may be allocated; and setting an initial points for each device. ,in , This represents the total number of allocatable devices; it calculates the percentage of isolation or binding requirements satisfied after the interface is assigned to a device. If not satisfied Save and sort all The value is selected based on the redundancy requirements of the interface. The largest Each device or physical unit serves as the final allocation scheme for this interface, where This refers to the number of redundant requirements.