A resource optimal supply method for an underwater acoustic open architecture signal processor
By acquiring a list of computational middleware and open-source function libraries, and filtering and integrating candidate function sets, the problems of function omissions and interface mismatches in the underwater acoustic open architecture signal processor were solved, achieving optimal resource supply and normal operation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA SHIP DEV & DESIGN CENT
- Filing Date
- 2026-05-15
- Publication Date
- 2026-06-12
AI Technical Summary
In existing underwater acoustic open architecture signal processors, the configuration of computation function libraries relies on human experience, which can easily lead to function omissions and interface mismatches, making it difficult to achieve optimal resource allocation.
By acquiring a list of computational middleware and multiple open-source function libraries, a set of candidate functions that meet the functional and interface descriptions is selected, and the candidate functions are integrated in the hardware environment of the signal processor to ensure comprehensive coverage of computational functions and interface matching.
It achieves comprehensive coverage of computation functions and interface matching, avoids function omissions and calling errors, ensures that computation functions run normally in the hardware environment, and achieves optimal resource allocation.
Smart Images

Figure CN122196977A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of underwater acoustic signal processing technology, specifically relating to an optimal resource supply method for an underwater acoustic open architecture signal processor. Background Technology
[0002] Underwater acoustic open-architecture signal processors are key devices for underwater detection, communication, and navigation, supporting dynamic deployment of computing services across various application scenarios. With the increasing complexity of underwater acoustic signal processing algorithms and the diversification of hardware platforms, efficiently and accurately configuring the required computational function libraries for the signal processor to achieve optimal supply of computing resources has become a critical issue restricting system performance and development efficiency. Current technologies typically involve developers manually selecting suitable computational functions from various open-source libraries (such as FFTW, OpenBLAS, and CUDA libraries) based on signal processing requirements, and then adapting and integrating the interfaces. This approach relies on the developer's expert experience and is prone to human error, leading to function omissions or interface incompatibility, making it difficult to achieve optimal resource supply.
[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0004] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.
[0005] This disclosure provides a method for optimal resource allocation for an underwater acoustic open architecture signal processor. This method effectively avoids omissions of computational functions due to human error, avoids function call errors due to inconsistent interface descriptions, and ensures that all computational functions in the final target computational function library can run normally in the hardware environment of the signal processor, thereby achieving optimal resource allocation.
[0006] In some embodiments, a method for optimal resource provisioning for an underwater acoustic open-architecture signal processor includes: Obtain a list of computational middleware and multiple open-source function libraries; the list of computational middleware includes the first function functions and corresponding interface descriptions of the computational services required by the signal processor, and the open-source function libraries include multiple computational functions; Based on the computing middleware manifest, the computing functions in each open-source function library are screened to obtain the first candidate function set corresponding to each open-source function library; wherein, the first candidate function set includes multiple candidate computing functions, and the candidate computing functions represent computing functions that satisfy the functionality of any first function in the computing middleware manifest and the corresponding interface description; Based on the hardware environment of the signal processor, the target computation function library is obtained by integrating the various first candidate function sets.
[0007] The beneficial effects of this invention are as follows: By acquiring a middleware manifest, which includes multiple first-function functionalities and corresponding interface descriptions required by the signal processor for computational services, and then filtering the computational functions in various open-source function libraries based on this manifest, a first-candidate function set is obtained for each open-source function library. This ensures comprehensive coverage of the required computational service functionalities and effectively avoids omissions due to human error. Furthermore, each candidate computational function in this first-candidate function set represents a computational function that satisfies any first-function functionality and corresponding interface description in the middleware manifest, ensuring that the selected computational functions match the required functionalities and corresponding interface descriptions, thus avoiding function call errors caused by inconsistent interface descriptions. Finally, based on the signal processor's hardware environment, the candidate computational function sets are integrated to obtain the target computational function library, ensuring that all computational functions in the final target computational function library can run normally in the signal processor's hardware environment. In this way, by acquiring a list of computing middleware, screening open-source function libraries, and integrating candidate computing function sets based on the hardware environment, we can ensure the comprehensive coverage of the functions corresponding to the computing services required by the signal processor. This can effectively avoid the omission of computing functions due to human negligence, avoid function call errors due to inconsistent interface descriptions, and ensure that all computing functions in the final target computing function library can run normally in the hardware environment of the signal processor, thereby achieving optimal resource supply.
[0008] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description
[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a flowchart of a method for optimal resource allocation for an open-architecture underwater acoustic signal processor provided by the present invention. Detailed Implementation
[0010] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.
[0011] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.
[0012] Unless otherwise stated, the term "multiple" means two or more.
[0013] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.
[0014] The term "and / or" describes a dependency relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.
[0015] The term "correspondence" can refer to a dependency or binding relationship. The correspondence between A and B means that there is a dependency or binding relationship between A and B.
[0016] Combination Figure 1 As shown, this disclosure provides a method for optimal resource allocation for an underwater acoustic open architecture signal processor, including: Step S101: Obtain a list of computational middleware and multiple open-source function libraries; wherein, the list of computational middleware includes multiple first function functions and corresponding interface descriptions of the computational services required by the signal processor, and the open-source function libraries include multiple computational functions.
[0017] The function description includes the function name and / or functional description, while the interface description includes at least one of the following: the type, range, and format of input parameters and output results; parameter configuration; and usage examples. The middleware list should meet the needs of typical underwater acoustic applications and should include, but is not limited to, scalar elementary mathematical operations, vector analysis and operations, matrix analysis and operations, complex number and trigonometric function operations, data statistical analysis and engineering optimization, filtering, transformation, and solving, among other first-function functionalities.
[0018] After acquiring multiple open-source function libraries, the documentation should also include records or explanations of the methods, processes, and results for conducting conformity checks on each version of the open-source computing function libraries. The conformity checks should clearly define whether the computing function libraries provided by each unit are complete, whether the interfaces meet the interface requirements of the computing middleware manifest, and retain all compatible computing functions.
[0019] Step S102: Based on the computing middleware list, the computing functions in each open-source function library are screened to obtain the first candidate function set corresponding to each open-source function library; wherein, the first candidate function set includes multiple candidate computing functions, and the candidate computing functions represent computing functions that satisfy the functionality of any first function in the computing middleware list and the corresponding interface description.
[0020] Step S103: Based on the hardware environment of the signal processor, integrate the various first candidate function sets to obtain the target computation function library.
[0021] This disclosure provides a method for optimal resource provisioning for an open-architecture underwater acoustic signal processor. The method involves obtaining a middleware list, which includes multiple first function functionalities and corresponding interface descriptions required by the signal processor. Based on this list, computational functions in various open-source function libraries are screened to obtain first candidate function sets for each library. This ensures comprehensive coverage of required computational service functionalities and effectively avoids omissions due to human error. Furthermore, each candidate computational function in the first candidate function set represents a computational function that satisfies any first function functionality and corresponding interface description in the middleware list, ensuring that the screened computational functions match the required functionalities and corresponding interface descriptions, thus avoiding function call errors due to inconsistent interface descriptions. Finally, based on the signal processor's hardware environment, the candidate computational function sets are integrated to obtain a target computational function library, ensuring that all computational functions in the final target computational function library can run normally in the signal processor's hardware environment. In this way, by acquiring a list of computing middleware, screening open-source function libraries, and integrating candidate computing function sets based on the hardware environment, we can ensure the comprehensive coverage of the functions corresponding to the computing services required by the signal processor. This can effectively avoid the omission of computing functions due to human negligence, avoid function call errors due to inconsistent interface descriptions, and ensure that all computing functions in the final target computing function library can run normally in the hardware environment of the signal processor, thereby achieving optimal resource supply.
[0022] Preferably, obtaining a list of computational middleware includes: Based on expert experience and the dependencies between function functions, multiple second function functions are identified; Obtain at least one first specification document; For each second function, extract the matching third function and its corresponding interface description from each first specification file, and integrate all the third function and its corresponding interface description to obtain at least one first function and its corresponding interface description corresponding to the second function. Summarize at least one first function function corresponding to each second function function and its corresponding interface description to obtain a list of computing middleware.
[0023] In this way, by introducing dependencies between functions to supplement expert experience, functions that might be overlooked by experts can be added, effectively compensating for the incomplete function coverage caused by relying on expert experience. Furthermore, by extracting matching third functions and their corresponding interface descriptions from the first specification document using second functions, the domain knowledge advantage of expert experience is utilized, while the standardization and authority of the first specification document are leveraged to verify and supplement the functions and interface descriptions, improving the accuracy and standardization of the computing middleware manifest. By integrating all third functions and their corresponding interface descriptions to obtain multiple first functions and their corresponding interface descriptions, duplicate or redundant third functions can be uniformly merged, avoiding functional redundancy or interface conflicts in the computing middleware manifest, thereby improving the simplicity and usability of the manifest.
[0024] The first specification document includes at least one of the following in the field of underwater acoustic signal processing: standard specification documents, technical manuals, interface definition documents, and open-source function library documentation.
[0025] Preferably, based on expert experience and the dependencies between function functions, multiple second function functions are determined, including: Based on expert experience, a general function set and a special function set are determined; the general function set represents a set of functions that are common across fields, while the special function set represents a set of functions that are specific to the field of underwater acoustic signal processing. Based on the dependencies between functions, the first function set corresponding to the general function set is determined by using a pre-constructed general function dependency graph, the second function set corresponding to the special function set is determined by using a pre-constructed special function dependency graph, and the third function set corresponding to the special function set is determined by using a pre-fine-tuned first large language model. Based on the preset conflict resolution strategy, the second and third function sets are conflicted to obtain the fourth function set; Based on the general function set, the special function set, the first function set, and the fourth function set, multiple second function functions are determined.
[0026] The first function set, the second function set, the third function set, and the fourth function set each include at least one function.
[0027] The first function set is obtained by capturing the remaining functions with explicit dependencies on the general function using a general functional dependency graph. The second function set is obtained by capturing the remaining functions with explicit dependencies on the specific function using a specific functional dependency graph. The third function set is obtained by reasoning about the remaining functions with implicit dependencies on the general function using the first large language model based on domain knowledge. Thus, the general and specific function sets are determined based on expert experience. The first and second function sets corresponding to the general and specific function sets are determined using pre-constructed general and specific functional dependency graphs, ensuring accurate capture of explicit dependencies. The third function set corresponding to the specific function set is determined using a pre-fine-tuned first large language model, effectively identifying implicit dependencies and domain-specific dependencies not recorded in the graphs. Since the second and third function sets may contain the same or similar functions, potentially causing redundancy, a pre-defined conflict resolution strategy is used to resolve conflicts between the second and third function sets, obtaining a fourth function set. This achieves both the organic integration of structured knowledge and generative reasoning and effectively removes redundancy. Finally, based on the general function set, the special function set, the first function set, and the fourth function set, multiple second function functions are determined, so that the final second function function set has universality, professionalism, completeness, and accuracy, which significantly improves the quality of function function dependency mining, thereby ensuring the comprehensiveness and standardization of the computing middleware list.
[0028] In some embodiments, a general functional dependency graph is constructed by: obtaining multiple cross-domain common second specification files; performing semantic parsing on each second specification file to extract cross-domain common function dependency descriptions; and constructing a general functional dependency graph based on the extracted dependency descriptions. The second specification files include at least one of the following: open-source function library documentation, general algorithm standards, cross-domain technical manuals, etc.
[0029] In some embodiments, a dedicated functional dependency graph is constructed by: acquiring multiple third-party specification documents in the field of underwater acoustic signal processing; performing semantic parsing on each third-party specification document to extract dependency descriptions between functions specific to the field of underwater acoustic signal processing; and constructing a functional dependency graph based on the extracted dependency descriptions. The third-party specification documents include at least one of the following: underwater acoustic signal processing standards and specifications, sonar system technical manuals, and underwater acoustic signal processing algorithm literature.
[0030] In other embodiments, the functional dependency graph is constructed by: obtaining a knowledge graph in the field of underwater acoustic signal processing; extracting functional entities specific to the field of underwater acoustic signal processing and their dependencies from the knowledge graph; and constructing the functional dependency graph based on the extracted dependencies.
[0031] In some embodiments, the first major language model is fine-tuned by employing a few-shot learning strategy. This few-shot learning strategy involves taking a function description specific to the underwater acoustic signal processing domain as input and multiple functions that are dependent on this domain-specific function description as output, thereby fine-tuning the first major language model.
[0032] In some embodiments, large language models include LLaMA 2 / 3 (Meta), DeepSeek, etc., and are not limited here.
[0033] In some embodiments, the sample is input: beamforming; output: array element channel calibration, FFT transform, weighting coefficient calculation, and noise suppression.
[0034] Preferably, based on a preset conflict resolution strategy, conflict resolution is performed on the second and third function sets to obtain a fourth function set, including: Conflict detection is performed between the second and third function sets to determine the first differential function set; Calculate the first semantic similarity between each function in the first differential function set, and based on each first semantic similarity, merge each function in the first differential function set to obtain the first merged function set; Obtain the attribute information of each function in the first merged function set; wherein, the attribute information includes graph attributes in the dedicated function dependency graph or confidence scores generated in the first large language model; Based on the comparison results between the attribute information and the corresponding first preset threshold, the first merge function set is filtered to obtain the filtered function set; Find the intersection of the second and third function sets, and merge the resulting intersection with the filtering function set to obtain the fourth function set.
[0035] By performing conflict detection on the second and third function sets, a first discrepancy function set is determined, accurately locating the divergence points between the function-specific dependency graph and the first major language model in function inference. Then, the semantic similarity between functions within the first discrepancy function set is calculated and merged, effectively eliminating spurious conflicts caused by differences in expression. Next, by comparing the graph attributes or confidence levels of each function in the first merged function set with preset thresholds, a refined decision-making process for discrepancy functions is achieved, eliminating low-value redundant dependencies and low-confidence erroneous inferences. Thus, by combining the intersection of the second and third function sets with the filtered function set, a fourth function set is obtained. This ensures that consensus functions are not omitted and provides reasonable supplementation for functions omitted from a single source, making the fourth function set complete, accurate, and reliable.
[0036] Understandably, the first differential function set represents the set of non-overlapping functional functions between the second and third function sets. If a functional function in the first merged function set belongs to the second function set, its attribute information is a graph attribute in the dedicated functional dependency graph; if a functional function in the first merged function set belongs to the third function set, its attribute information is a confidence score generated in the first large language model. The first preset thresholds corresponding to the two are different.
[0037] Preferably, the first merged function set is filtered based on the comparison result between the attribute information and the first preset threshold to obtain a filtered function set, including: for functions belonging to the second function set in the first merged function set, the call frequency and / or node centrality are determined based on graph attributes. If the call frequency is less than a preset number threshold (e.g., 5 times) and / or the node centrality is less than a preset centrality threshold (e.g., 0.3), they are determined to be marginal dependencies and are removed; otherwise, they are retained. In this case, the first preset threshold includes the preset number threshold and the preset centrality threshold. For functions belonging to the third function set in the first merged function set, their generation probability and / or comparative evaluation score are obtained. If the generation probability is less than a preset probability threshold (e.g., 0.7) and / or the comparative evaluation score is less than a preset score threshold, they are determined to be low-confidence inferences and are removed; otherwise, they are retained. In this case, the first preset threshold includes the preset probability threshold and / or the preset score threshold.
[0038] In this way, for functions originating from dedicated functional dependency graphs, dual screening using call frequency and node centrality can accurately identify and eliminate non-core functions that are on the edge of the dependency graph and have low usage frequency. For functions originating from large language models, dual screening using generation probability and contrastive evaluation scores can effectively filter out uncertain inferences from the model.
[0039] Preferably, based on a general function set, a specific function set, a first function set, and a third function set, multiple second function sets are determined, including: taking the intersection of the general function set, the specific function set, the first function set, and the third function set as a candidate intersection, and taking the remaining function sets (excluding the candidate intersection) as a second difference function set; merging function sets with the same meaning in the second difference function set to obtain a second merged function set; and taking the union of the candidate intersection and the second merged function set as each second function set to determine multiple second function sets.
[0040] In this way, by integrating the general function set, the special function set, the first function set, and the third function set, multiple second function functions can be obtained quickly, accurately, and without redundancy.
[0041] Preferably, the matching third function functions and corresponding interface descriptions are extracted from each of the first specification documents, including: Calculate the cosine similarity between the second function and each function in each of the first specification files; Functions with a cosine similarity greater than or equal to a second preset threshold are designated as third functions that match the second function, thus obtaining matching third functions and their corresponding interface descriptions.
[0042] In this way, by calculating the cosine similarity between the second function and each function in the first specification file, automated semantic matching of function functions is achieved. Then, by setting a second preset threshold, the cosine similarity is filtered. Based on vectorized semantic representation, cosine similarity can accurately identify functions with similar semantics but different descriptions, effectively avoiding missed matches due to differences in description. This provides high-quality input for subsequent open-source function library selection and hardware environment integration, significantly improving the automation level and accuracy of the computational middleware manifest construction.
[0043] Preferably, by integrating all third function functionalities and corresponding interface descriptions to obtain at least one first function functionality and corresponding interface description corresponding to the second function functionality, including: Calculate the second semantic similarity between each third function and its corresponding interface description, and group the third functions whose second semantic similarity is greater than the third preset threshold into the same first function group; For each first functional group, multiple third functions within the first functional group are merged into one first functional function, and the interface descriptions corresponding to each third function within the first functional group are standardized to obtain the interface description corresponding to the first functional function. For a third function that cannot be classified into any first function group, it is treated as an independent first function and a corresponding interface description is obtained, so as to obtain at least one first function and a corresponding interface description corresponding to the second function.
[0044] In this way, by calculating the second semantic similarity between pairwise third function functions and their corresponding interface descriptions, the automatic identification and merging of duplicate or similar function functions can be achieved. This can solve the functional redundancy problem that may occur when extracting from multiple first specification files, avoid duplicate retention due to naming differences, and significantly improve the standardization and usability of the computing middleware manifest.
[0045] In some embodiments, merging multiple third function functions within a first function group into a single first function function includes: selecting the function function with the highest frequency of occurrence or any one of the third function functions within the first function group as the first function function corresponding to the first function group.
[0046] The interface descriptions corresponding to each third function within the first functional group are standardized to obtain the interface description corresponding to the first function. This can be achieved by selecting any interface description from the first functional group, or by selecting the interface description of the third function that appears most frequently within the first functional group. No specific limitation is imposed here.
[0047] Preferably, by integrating all third function functionalities and corresponding interface descriptions to obtain at least one first function functionality and corresponding interface description corresponding to the second function functionality, including: Each third function and its corresponding interface description are input into the second language model, along with a preset merging prompt. The second language model is instructed to identify and merge multiple third functions that represent the same meaning, and output the merged third function and its corresponding interface description to obtain multiple first functions and their corresponding interface descriptions.
[0048] In this way, by inputting all the third function functions and their corresponding interface descriptions into the second large language model, and inputting preset merging prompts, the semantic understanding capability of the large language model is used to automatically identify and merge multiple third function functions that represent the same meaning. This can effectively solve the problem of functional redundancy that occurs when extracting from multiple second specification documents, and significantly improve the automation level and accuracy of constructing the computing middleware manifest.
[0049] In some embodiments, outputting the merged third function and its corresponding interface description includes: outputting the third function with the highest frequency of occurrence or any one of the third functions in the first function group as the merged third function and its corresponding interface description for the first function group. No limitation is imposed here.
[0050] Preferably, based on the hardware environment of the signal processor, the various first candidate function sets are integrated to obtain the target computation function library, including: Obtain the hardware environment information of the signal processor; wherein, the hardware environment information includes at least one of the following: processor architecture, instruction set support, memory capacity, and operating system type; Obtain the hardware operating conditions for each candidate computation function in each first candidate function set; The hardware operating conditions of each candidate computation function in each first candidate function set are matched with the hardware environment information of the signal processor. Candidate computation functions whose hardware operating conditions do not meet the hardware environment information are eliminated to obtain the target computation function library.
[0051] In this way, by acquiring the hardware environment information of the signal processor, including at least one of the following: processor architecture, instruction set support, memory capacity, and operating system type, and by obtaining the hardware operating conditions required for each candidate computation function, the two are matched, and candidate computation functions that do not meet the hardware environment information are eliminated. This achieves precise adaptation between the computation functions and the hardware environment of the underwater acoustic signal processor, ensuring that all computation functions in the target computation function library can run normally on the signal processor. Furthermore, the hardware environment information of the signal processor can be flexibly configured according to the actual deployment scenario, adapting to different models and architectures of underwater acoustic signal processors. This improves the versatility and portability of the method, reduces the risk of deployment failure due to hardware incompatibility, and provides a guarantee for the efficient and reliable operation of the open architecture underwater acoustic signal processor.
[0052] Preferably, the hardware operating conditions of each candidate computation function in each first candidate function set are matched with the hardware environment information of the signal processor, and candidate computation functions whose hardware operating conditions do not meet the hardware environment information are eliminated to obtain the target computation function library, including: The hardware operating conditions of each candidate computation function in each first candidate function set are matched with the hardware environment information of the signal processor. Candidate computation functions whose hardware operating conditions do not meet the hardware environment information are eliminated to obtain the second candidate computation function library. For the candidate computation functions in the second candidate function set, they are grouped according to their corresponding first function functions, and multiple candidate computation functions belonging to the same first function function are grouped into the same second function group. For each second function group, select a candidate computation function from the second function group as the target computation function corresponding to the first function. The target calculation functions corresponding to all the first functions are integrated to obtain the target calculation function library.
[0053] In this way, based on hardware matching, the candidate computation functions in the second candidate computation function set are grouped according to the first function function, so that multiple candidate computation functions belonging to the same first function function are grouped into the same function group. Then, a candidate computation function is selected from each function group as the target computation function corresponding to that function. This realizes the deduplication and selection of computation functions, so that each function function in the target computation function library corresponds to only one computation function, which greatly reduces the complexity of the function library and facilitates subsequent function calls and maintenance.
[0054] In some embodiments, the selection within a group can be flexibly configured based on performance metrics (such as execution time, memory usage, compatibility, etc.) or optimization objectives (such as real-time priority, resource usage priority) to achieve optimal supply of computing resources, so that the target computing function library has hardware adaptability, functional completeness and resource optimization.
[0055] In some embodiments, the method further includes: having a technician perform a compatibility check on each calculation function in the target calculation function library; if an incompatible calculation function is found, a new calculation function can be selected from a set of calculation functions pointed to by the function corresponding to the incompatible function. This ensures that the calculation functions in the target calculation function library are compatible with each other.
[0056] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made to it in form and detail without departing from the scope defined by the claims of the present invention.
Claims
1. A method for optimal resource allocation for an underwater acoustic open-architecture signal processor, characterized in that, include: Obtain a list of computational middleware and multiple open-source function libraries; the list of computational middleware includes the first function functions and corresponding interface descriptions of the computational services required by the signal processor, and the open-source function libraries include multiple computational functions; Based on the computing middleware manifest, the computing functions in each open-source function library are screened to obtain the first candidate function set corresponding to each open-source function library; wherein, the first candidate function set includes multiple candidate computing functions, and the candidate computing functions represent computing functions that satisfy the functionality of any first function in the computing middleware manifest and the corresponding interface description; Based on the hardware environment of the signal processor, the target computation function library is obtained by integrating the various first candidate function sets.
2. The method according to claim 1, characterized in that, The process of obtaining the list of computing middleware includes: Based on expert experience and the dependencies between function functions, multiple second function functions are identified; Obtain at least one first specification document; For each second function, extract the matching third function and its corresponding interface description from each first specification file, and integrate all the third function and its corresponding interface description to obtain at least one first function and its corresponding interface description corresponding to the second function. Summarize at least one first function function corresponding to each second function function and its corresponding interface description to obtain a list of computing middleware.
3. The method according to claim 2, characterized in that, Based on expert experience and dependencies between function functions, multiple second function functions are identified, including: Based on expert experience, a general function set and a special function set are determined; the general function set represents a set of functions that are common across fields, while the special function set represents a set of functions that are specific to the field of underwater acoustic signal processing. Based on the dependencies between functions, the first function set corresponding to the general function set is determined by using a pre-constructed general function dependency graph, the second function set corresponding to the special function set is determined by using a pre-constructed special function dependency graph, and the third function set corresponding to the special function set is determined by using a pre-fine-tuned first large language model. Based on the preset conflict resolution strategy, the second and third function sets are conflicted to obtain the fourth function set; Based on the general function set, the special function set, the first function set, and the fourth function set, multiple second function functions are determined.
4. The method according to claim 3, characterized in that, The fourth function set is obtained by resolving conflicts between the second and third function sets based on a preset conflict resolution strategy, including: Conflict detection is performed between the second and third function sets to determine the first differential function set; Calculate the first semantic similarity between each function in the first differential function set, and based on each first semantic similarity, merge each function in the first differential function set to obtain the first merged function set; Obtain the attribute information of each function in the first merged function set; wherein, the attribute information includes graph attributes in the dedicated function dependency graph or confidence scores generated in the first large language model; Based on the comparison results between the attribute information and the corresponding first preset threshold, the first merge function set is filtered to obtain the filtered function set; Find the intersection of the second and third function sets, and merge the resulting intersection with the filtering function set to obtain the fourth function set.
5. The method according to claim 2, characterized in that, The extraction of matching third function functionalities and corresponding interface descriptions from various first specification documents includes: Calculate the cosine similarity between the second function and each function in each of the first specification files; Functions with a cosine similarity greater than or equal to a second preset threshold are designated as third functions that match the second function, thus obtaining matching third functions and their corresponding interface descriptions.
6. The method according to claim 2, characterized in that, The process of integrating all third function functionalities and corresponding interface descriptions to obtain at least one first function functionality and corresponding interface description corresponding to the second function functionality includes: Calculate the second semantic similarity between each third function and its corresponding interface description, and group the third functions with a second semantic similarity greater than a third preset threshold into the same first function group; For each first functional group, multiple third functions within the first functional group are merged into one first functional function, and the interface descriptions corresponding to each third function within the first functional group are standardized to obtain the interface description corresponding to the first functional function. For a third function that cannot be classified into any first function group, it is treated as an independent first function and a corresponding interface description is obtained, so as to obtain at least one first function and a corresponding interface description corresponding to the second function.
7. The method according to claim 2, characterized in that, The process of integrating all third function functionalities and corresponding interface descriptions to obtain at least one first function functionality and corresponding interface description corresponding to the second function functionality includes: Each third function and its corresponding interface description are input into the second language model, along with a preset merging prompt. The second language model is instructed to identify and merge multiple third functions that represent the same meaning, and output the merged third function and its corresponding interface description to obtain multiple first functions and their corresponding interface descriptions.
8. The method according to any one of claims 1 to 7, characterized in that, The signal processor-based hardware environment integrates various first candidate function sets to obtain the target computation function library, including: Obtain the hardware environment information of the signal processor; wherein, the hardware environment information includes at least one of the following: processor architecture, instruction set support, memory capacity, and operating system type; Obtain the hardware operating conditions for each candidate computation function in each first candidate function set; The hardware operating conditions of each candidate computation function in each first candidate function set are matched with the hardware environment information of the signal processor. Candidate computation functions whose hardware operating conditions do not meet the hardware environment information are eliminated to obtain the target computation function library.
9. The method according to claim 8, characterized in that, The step of matching the hardware operating conditions of each candidate computation function in each first candidate function set with the hardware environment information of the signal processor, and eliminating candidate computation functions whose hardware operating conditions do not meet the hardware environment information to obtain the target computation function library includes: The hardware operating conditions of each candidate computation function in each first candidate function set are matched with the hardware environment information of the signal processor. Candidate computation functions whose hardware operating conditions do not meet the hardware environment information are eliminated to obtain the second candidate computation function library. For the candidate computation functions in the second candidate function set, they are grouped according to their corresponding first function functions, and multiple candidate computation functions belonging to the same first function function are grouped into the same second function group. For each second function group, select a candidate computation function from the second function group as the target computation function corresponding to the first function. The target calculation functions corresponding to all the first functions are integrated to obtain the target calculation function library.