A method for generating typical underwater acoustic function components based on open architecture

Abstract

This invention discloses a method for generating typical underwater acoustic functional components based on an open architecture, belonging to the field of underwater acoustic system technology. The core of this method lies in pre-establishing an underwater acoustic functional model library containing standardized interface underwater acoustic functional atomic models, and a component configuration rule library containing configuration templates and constraints. When a component generation request is received, the system automatically selects, instantiates, and logically links multiple atomic models from the model library according to the rule library to form an initial functional component. Then, the component undergoes rigorous static verification and high-fidelity dynamic simulation verification combined with a physical model. After successful verification, the component is compiled and packaged into an executable functional component conforming to the open architecture standard. This invention solves the technical problems existing in traditional underwater acoustic system development, such as tight hardware-software coupling, poor reusability of functional components, long development and verification cycles, and insufficient deployment flexibility, through a standardized, modular, automated, and verification-driven integrated process.

Description

Technical Field

[0001] This invention belongs to the field of underwater acoustic system technology, specifically relating to a method for generating typical underwater acoustic functional components based on an open architecture. Background Technology

[0002] Underwater acoustic engineering is a key technology in fields such as ocean exploration, underwater communication, navigation, and target identification. Modern underwater acoustic systems, such as sonar, are becoming increasingly complex, typically involving multiple stages including signal transmission, reception, beamforming, signal processing, target detection, and tracking.

[0003] However, the current development and integration of underwater acoustic functional components still face many challenges: high degree of customization and coupling, with traditional underwater acoustic systems mostly custom-developed for specific tasks and hardware platforms. The deep coupling between functional components and underlying hardware, operating systems, and other components leads to numerous siloed systems. Modification, upgrades, or replacements of any component can trigger unforeseen compatibility issues, requiring extensive integration testing and rework. Poor component reusability, due to the lack of unified interface standards and data specifications, makes it difficult for algorithm models developed by different teams and at different times to interoperate directly; even components with similar functions cannot be "plug-and-play" across different systems due to interface differences, resulting in significant duplication of development and resource waste. Long development and verification cycles, the complexity and uncertainty of the underwater acoustic environment make system verification extremely difficult. Traditional verification methods often rely on expensive sea trials, which are time-consuming, costly, and have poor repeatability, and cannot cover all possible scenarios, becoming a major bottleneck for product iteration. The deployment flexibility is insufficient, and the generated components are usually bound to a specific runtime environment, making it difficult to migrate and deploy flexibly between different computing platforms (such as local servers, edge computing nodes, and cloud platforms). This makes it unable to meet the needs of future intelligent and networked underwater acoustic warfare systems for elastic computing and dynamic task allocation.

[0004] Therefore, there is an urgent need for a method for generating typical underwater acoustic functional components based on an open architecture, which can achieve rapid, reliable, and high-quality generation of underwater acoustic functional components and ensure their compatibility with open architecture standards. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method for generating typical underwater acoustic functional components based on an open architecture, which can achieve rapid, reliable, and high-quality generation of underwater acoustic functional components and ensure their compatibility with open architecture standards.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] This invention discloses a method for generating typical underwater acoustic functional components based on an open architecture, comprising the following steps:

[0008] S1. Establish an underwater acoustic functional model library and a component configuration rule library. The underwater acoustic functional model library stores multiple underwater acoustic functional atomic models with standardized interfaces. The component configuration rule library stores configuration templates and constraints for combining underwater acoustic functional atomic models.

[0009] S2. In response to the component generation request for the target underwater acoustic task, based on the component configuration rule base, select multiple corresponding underwater acoustic functional atomic models from the underwater acoustic functional model library for instantiation and logical linking to form the initial functional component.

[0010] S3. Perform static verification and dynamic simulation verification on the initial functional components. Static verification checks the consistency of data flow logic and interface compatibility within the initial functional components based on target constraints. Dynamic simulation verification verifies whether the runtime behavior and performance indicators of the initial functional components meet the preset requirements by injecting simulated underwater acoustic data or historical measured underwater acoustic data.

[0011] S4. Once the verification is successful, the initial functional components will be compiled and packaged into executable functional components that conform to the predetermined open architecture standard.

[0012] Furthermore, when establishing the underwater acoustic functional model library, the standardized interface of each underwater acoustic functional atomic model follows the interface definition specification based on the general data model. The general data model is a structured object used to encapsulate data in the underwater acoustic field, and its definition includes a data header field and a data body field. The data header field stores the metadata of the data, including at least the data source identifier, timestamp, coordinate system information, and data type identifier. The data body field stores the core data, and its structure is dynamically interpreted according to the data type identifier, supporting at least complex waveform data, beam domain data, azimuth-time history data, and target track point sequences.

[0013] The standardized interface is implemented as follows: each underwater acoustic functional atomic model publishes the data type identifiers required by its input and output interfaces to the global service registry during initialization; at runtime, the upstream model encapsulates its output data into objects that conform to the general data model and publishes them through the middleware bus, and the downstream model receives and parses the objects according to the data type identifiers it subscribes to in order to extract the core data of the data body domain.

[0014] Furthermore, the constraints in the component configuration rule base include loop detection constraints based on directed graph theory and interface compatibility constraints based on data flow theory;

[0015] The loop detection constraint is implemented in the following way: after constructing the directed graph model of the initial functional components, a topology sorting algorithm based on depth-first search is used to detect loops;

[0016] Interface compatibility constraints are implemented by establishing an interface type system. The type system assigns a type signature to each input and output interface. The type signature is a tuple containing the basic data type, data dimension, and sampling rate. During logical linking, for edges in a directed graph, the compatibility between the source node's output type signature and the destination node's input type signature is checked. The compatibility rule is defined as follows: if and only if the output basic data type is a subtype of the input basic data type, the output data dimension meets the input requirements, and the output sampling rate is greater than or equal to the input sampling rate, it is considered compatible.

[0017] Furthermore, dynamic simulation verification was performed in a high-fidelity underwater acoustic channel simulation environment; the simulation environment used a simplified physical model to calculate the sound field propagation loss, and the formula for this model is:

[0018]

[0019] In the formula, The distance between the sound source and the receiver. , , Coefficients related to environmental parameters respectively;

[0020] The dynamic simulation verification process includes: generating or loading simulated underwater acoustic data containing preset target characteristics; simulating data propagation and superimposing channel effects in the simulation environment; inputting the processed data into the initial functional component; and comparing the component output with the actual parameters to quantify performance indicators, which at least include the detection probability. With false alarm probability The calculation formulas are as follows:

[0021]

[0022]

[0023] In the formula, To ensure the correct number of tests, For the actual target number of times, The number of false alarms. This represents the total number of judgment opportunities.

[0024] Furthermore, the static verification steps include data flow deadlock detection; data flow deadlock detection involves constructing a data flow graph model of the initial functional components and analyzing its liveness implementation; specifically: abstracting model instances as nodes and data channels as directed edges; identifying all strongly connected components in the graph; for each strongly connected component, analyzing its internal data triggering mode and data buffer capacity configuration; if there exists a strongly connected component where the execution of each node strictly depends on new data generated by the upstream node and all data buffer capacities are zero, then a data flow deadlock risk is identified.

[0025] Furthermore, in the dynamic simulation verification, for the verification of target tracking functions, the optimal sub-mode allocation distance is used as the performance evaluation index; let the set of real target tracks be... The estimated set of tracks is Calculate the optimal sub-pattern allocation distance :

[0026]

[0027] In the formula, To assign mappings, For actual waypoints with estimated waypoints Local costs between The penalty coefficient for not assigning a track. To estimate the total number of waypoints, This represents the total number of actual waypoints.

[0028] Furthermore, the compilation and packaging steps include: using containerization technology to encapsulate the verified initial functional components and their runtime dependencies into a lightweight container image; the container image building process includes: starting with a minimal operating system base image; copying the component executable code, configuration files, and binary dependency libraries to a predetermined path within the image; setting the container startup entry point command; and adding annotation tags to the container image that conform to the predetermined open architecture standard. The annotation tags must at least include the component identifier, version number, service port number, and resource requirement declaration.

[0029] Furthermore, the method for generating typical underwater acoustic functional components based on an open architecture, after compilation and packaging, also includes:

[0030] S5. Component Performance Profiling Steps: The component performance profiling steps involve running standardized benchmark test cases to collect performance data of executable functional components under different input data scales and hardware configurations, including at least execution latency. CPU utilization and peak memory usage A performance prediction model is constructed based on the collected data to estimate the resource consumption of components in the target deployment environment; the performance prediction model is a multiple linear regression model, and its form is as follows:

[0031]

[0032] in, To estimate execution delay, For the size of the input data, To deploy the basic CPU load of the environment, , , These are the model coefficients fitted using benchmark test data; performance profile data is stored along with executable functional components.

[0033] Furthermore, the data header field of the general data model also includes a data quality indicator field; data quality indicator The formula for calculating the comprehensive scalar value is as follows:

[0034]

[0035] In the formula, For normalized signal-to-noise ratio, For data packet loss rate, For the confidence level of the data source, , , For the weighting coefficients, satisfying ;

[0036] The downstream underwater acoustic functional atomic model adjusts its processing strategy based on the data quality index Q.

[0037] The beneficial effects of this invention are as follows:

[0038] This invention liberates developers from tedious low-level coding and integration work by reusing and automating atomic models, enabling rapid response to new functional requirements. Rigorous static and dynamic verification processes, especially high-fidelity simulation verification, can identify and resolve most potential defects in the laboratory stage, reducing later testing risks and costs. Standardized interfaces and rule-based combination methods decouple functional components from specific hardware platforms, facilitating system upgrades and maintenance. New algorithm models can be easily incorporated into the model library and generated into components through standard processes, accelerating the engineering application of advanced underwater acoustic processing technologies. Attached Figure Description

[0039] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the following figures are provided for illustration:

[0040] Figure 1 This is a flowchart of an embodiment of the present invention. Detailed Implementation

[0041] like Figure 1 As shown, this invention discloses a method for generating typical underwater acoustic functional components based on an open architecture, comprising the following steps:

[0042] S1. Establish an underwater acoustic functional model library. The library contains multiple predefined and independently encapsulated underwater acoustic functional atomic models. Each underwater acoustic functional atomic model corresponds to a basic underwater acoustic signal processing or data analysis function. The basic underwater acoustic signal processing or data analysis function is selected from a set including but not limited to beamforming, signal detection, target tracking, noise suppression, and parameter estimation. Each underwater acoustic functional atomic model interacts with data through a standardized input / output interface. The standardized input / output interface defines a unified data format and communication protocol. Establish a component configuration rule library. The component configuration rule library stores configuration templates and constraints for logically connecting multiple underwater acoustic functional atomic models. The configuration template defines the topology structure for combining multiple underwater acoustic functional atomic models to achieve a specific underwater acoustic task. Specific underwater acoustic tasks include active sonar detection, passive sonar surveillance, or underwater acoustic communication. The constraints include verification rules for the execution order of underwater acoustic functional atomic models, data flow compatibility, and resource consumption limits.

[0043] S2. In response to the user's request to generate functional components for the target underwater acoustic task, select multiple target underwater acoustic functional atomic models from the underwater acoustic functional model library, and instantiate and logically link the multiple target underwater acoustic functional atomic models according to the target configuration template and target constraints corresponding to the target underwater acoustic task in the component configuration rule library to form the initial functional components.

[0044] S3. Perform static verification and dynamic simulation verification on the initial functional components. Static verification checks the consistency of data flow logic and interface compatibility within the initial functional components based on target constraints. Dynamic simulation verification verifies whether the runtime behavior and performance indicators of the initial functional components meet the preset requirements by injecting simulated underwater acoustic data or historical measured underwater acoustic data.

[0045] S4. Once the verification is successful, the initial functional components are compiled and packaged into executable functional components that conform to the predetermined open architecture standard. The predetermined open architecture standard specifies the encapsulation form of the software components, the service discovery mechanism, and the cross-platform deployment specifications.

[0046] In this solution, the core process is as follows: Infrastructure Construction Phase: First, two core knowledge bases are built: an underwater acoustic functional model library and a component configuration rule library. The model library stores a large number of fine-grained, single-function underwater acoustic atomic models (such as FFT calculators, beamformers, constant false alarm rate detectors, etc.), each following a unified standardized interface. The rule library stores the "blueprints" (configuration templates) and "assembly rules" (constraints) for how to combine these atomic models like "Lego bricks" into complete functions.

[0047] Component building phase: When the system receives a specific task request (such as "generate an active probe component"), it parses the request and automatically selects a series of required atomic models from the model library according to the corresponding configuration template in the rule base. Subsequently, the system creates instances of these models and connects their data interfaces according to the logical relationships defined in the template to form a complete, but not yet verified, initial functional component.

[0048] Verification and Assurance Phase: To ensure the correctness and reliability of the component, it undergoes two levels of verification. Static verification analyzes the component's internal data flow and control flow logic without running the code, checking for structural issues such as deadlocks and loops. Dynamic simulation verification runs the component on a simulation platform that simulates a real marine acoustic environment, inputs test data, and evaluates whether its output results meet the expected performance metrics.

[0049] Product generation stage: Only initial functional components that have passed all verifications will enter the final compilation and packaging process, and be packaged into executable functional components that conform to industry-standard open architectures (such as HOST, SOSA, etc.) and can be deployed and executed independently.

[0050] This solution liberates developers from tedious low-level coding and integration work by reusing atomic models and automating their assembly, enabling rapid response to new functional requirements. Rigorous static and dynamic verification processes, especially high-fidelity simulation verification, can identify and resolve most potential defects in the laboratory stage, reducing later testing risks and costs. Standardized interfaces and rule-based assembly methods decouple functional components from specific hardware platforms, facilitating system upgrades and maintenance. New algorithm models can be easily incorporated into the model library and generated into components through standard processes, accelerating the engineering application of advanced underwater acoustic processing technologies.

[0051] In one embodiment of the present invention, when establishing the underwater acoustic functional model library, the standardized interface of each underwater acoustic functional atomic model follows the interface definition specification based on the general data model; the general data model is a structured object used to encapsulate data in the underwater acoustic field, and its definition includes a data header field and a data body field; the data header field stores the metadata of the data, including at least the data source identifier, timestamp, coordinate system information and data type identifier; the data body field stores the core data, and its structure is dynamically interpreted according to the data type identifier, supporting at least complex waveform data, beam domain data, azimuth-time history data and target track point sequences;

[0052] The standardized interface is implemented as follows: each underwater acoustic functional atomic model publishes the data type identifiers required by its input and output interfaces to the global service registry during initialization; at runtime, the upstream model encapsulates its output data into objects that conform to the general data model and publishes them through the middleware bus, and the downstream model receives and parses the objects according to the data type identifiers it subscribes to in order to extract the core data of the data body domain.

[0053] In this scheme, the general data model is a carefully designed "data envelope," consisting of a header field and a body field. The header field, like an address label on an envelope, clearly indicates the data's "identity information" (source, time, coordinate system) and "content type" (data type identifier). The body field contains the actual data, its internal structure (e.g., whether it's a one-dimensional array or a two-dimensional matrix) uniquely determined by the data type identifier. The system predefines various standard data body structures, such as complex waveforms and beam data. The entire system is based on a "publish-subscribe" model. When each atomic model starts, it "declares" to a central directory (global service registry) what kind of data it needs (input interface type) and what kind of data it will produce (output interface type). When the data processing flow begins, the upstream model encapsulates its output data according to the general data model format and then "delivers" it to a public "post office" (middleware bus). The downstream model continuously "listens" to the post office; when it detects a data type it has subscribed to, it "receives" the data envelope, parses the data body according to the type identifier in the header field, and processes it.

[0054] This interface design allows any two underwater acoustic functional atomic models to establish a data connection as long as their data type identifiers match, eliminating the need for customized interface adapter development and achieving decoupling and plug-and-play functionality between models. Models do not communicate directly but interact indirectly through a middleware bus, ensuring that replacing or upgrading any model will not directly affect other models. The rich metadata carried in the data header field makes the flow and status of data throughout the entire processing chain clearly traceable, facilitating debugging and performance analysis.

[0055] In one embodiment of the present invention, the constraints in the component configuration rule base include loop detection constraints based on directed graph theory and interface compatibility constraints based on data flow theory.

[0056] The loop detection constraint is implemented in the following way: after constructing the directed graph model of the initial functional components, a topology sorting algorithm based on depth-first search is used to detect loops;

[0057] Interface compatibility constraints are implemented by establishing an interface type system. The type system assigns a type signature to each input and output interface. The type signature is a tuple containing the basic data type, data dimension, and sampling rate. During logical linking, for edges in a directed graph, the compatibility between the source node's output type signature and the destination node's input type signature is checked. The compatibility rule is defined as follows: if and only if the output basic data type is a subtype of the input basic data type, the output data dimension meets the input requirements, and the output sampling rate is greater than or equal to the input sampling rate, it is considered compatible.

[0058] This embodiment details the systematic constraints in the component configuration rule base used to ensure the logical correctness of components. These constraints mainly include two categories: loop detection constraints: The system abstracts the initial functional components into a directed graph, where nodes represent models and edges represent data flow directions. Then, a depth-first search (DFS) algorithm is used for topological sorting. If the graph can be completely topologically sorted (i.e., all nodes can be included in the sequence), it indicates that the graph is free of cycles; conversely, if there are nodes that cannot be sorted, it proves that a cycle exists, meaning that data is cyclically dependent among certain models and cannot flow forward.

[0059] Interface compatibility constraints: The system defines fine-grained type signatures for the input and output interfaces of each model. This is a tuple containing the basic data type (e.g., "ComplexFloat"), data dimension (e.g., "[256,1]"), and sampling rate (e.g., "48kHz"). When connecting two models, the system performs strict type checking.

[0060] Type inheritance check: The output type must be a subtype or the same type as the input type (for example, "ComplexFloat" can be assigned to "Float", but not vice versa).

[0061] Dimension matching check: The dimensions of the output data must meet the expectations of the input.

[0062] Sampling rate sufficiency check: The output sampling rate must not be lower than the input sampling rate to prevent downstream models from becoming "starved" due to insufficient data supply.

[0063] In this solution, fatal logical errors can be detected through automated checks in the initial stage of component generation, preventing defective components from flowing into the subsequent time-consuming verification and deployment stages. Systematic type signing and compatibility rules act like "insurance" for the data flow, ensuring that data can flow and be processed smoothly and error-free within the component. Enabling computers to understand and reason about the connection logic between models is the key technological support for achieving fully automated component generation.

[0064] In one embodiment of the present invention, dynamic simulation verification is performed in a high-fidelity underwater acoustic channel simulation environment; the simulation environment uses a simplified physical model to calculate the sound field propagation loss, the formula of which is:

[0065]

[0066] In the formula, The distance between the sound source and the receiver. , , Coefficients related to environmental parameters respectively;

[0067] The dynamic simulation verification process includes: generating or loading simulated underwater acoustic data containing preset target characteristics; simulating data propagation and superimposing channel effects in the simulation environment; inputting the processed data into the initial functional component; and comparing the component output with the actual parameters to quantify performance indicators, which at least include the detection probability. With false alarm probability The calculation formulas are as follows:

[0068]

[0069]

[0070] In the formula, To ensure the correct number of tests, For the actual target number of times, The number of false alarms. This represents the total number of judgment opportunities.

[0071] This embodiment focuses on how to perform quantitative performance evaluation using a high-fidelity underwater acoustic channel simulation model during the dynamic simulation verification process. The dynamic simulation is conducted in an environment capable of simulating real-world ocean acoustic physics effects (such as absorption, scattering, and multipath propagation) using a simplified propagation loss model that balances computational efficiency and physical accuracy. .in, , , The coefficients are set based on actual marine environmental parameters (such as water temperature, salinity, and seabed sediment). This model simulates the energy attenuation of sound waves propagating in the ocean. Verification process: Generate ideal underwater acoustic data containing the echo signal of a simulated target (such as a submarine); input this ideal data into a high-fidelity channel simulator. The simulator calculates the propagation loss of the signal from the sound source to the receiver according to the above formula, and superimposes this effect (along with noise, reverberation, etc.) onto the original data to obtain simulated data "contaminated" with the characteristics of the real ocean channel; input the simulated data into the initial functional component to be verified; after the component finishes processing, compare its output detection results with the actual location of the preset target. By statistically analyzing the number of correct detections and false alarms, the detection probability is accurately calculated. and false alarm probability These two key tactical performance indicators.

[0072] This scheme introduces a physical channel model, making the verification environment closely approximate real ocean conditions, thus providing more valuable evaluation results; it also provides detection probabilities. and false alarm probability Objective and quantitative indicators enable R&D personnel and users to clearly and accurately grasp the performance level of components; a large amount of performance verification and algorithm optimization work can be completed in the laboratory, reducing the reliance on expensive and uncontrollable sea trials.

[0073] In one embodiment of the present invention, the static verification step includes data flow deadlock detection; data flow deadlock detection is achieved by constructing a data flow graph model of the initial functional components and analyzing its activity; specifically: abstracting model instances as nodes and data channels as directed edges; identifying all strongly connected components in the graph; for each strongly connected component, analyzing its internal data triggering mode and data buffer capacity configuration; if there exists a strongly connected component in which the execution of each node strictly depends on the new data generated by the upstream node and all data buffer capacities are zero, then it is determined that there is a risk of data flow deadlock.

[0074] This embodiment supplements static verification, explaining in detail the principle of data flow deadlock detection, which is performed on the data flow graph model of the component.

[0075] Model abstraction: Each atomic model instance is regarded as a node in a graph, and the data channels between models are regarded as directed edges.

[0076] Identifying strongly connected components (SCCs): First, find all the largest strongly connected subgraphs in the graph (i.e., SCCs, where any two nodes can reach each other). SCCs are regions where deadlocks may occur.

[0077] Liveness Analysis: For each SCC, conduct an in-depth analysis of its internal data triggering mechanism and buffer settings. If an SCC is found to meet the following two conditions, it is considered to have a deadlock risk:

[0078] Strict dependency: The execution of each node must wait for its direct upstream node to generate new data to trigger the process;

[0079] Zero buffering: The buffer capacity of all data channels connecting these nodes is zero.

[0080] In this scenario, if there is no initial data source within the SCC, all nodes will be stuck in an indefinite blocking state while waiting for data from each other.

[0081] This solution can detect deep-seated problems related to execution timing and scheduling that are difficult to expose in simple functional tests. By eliminating the risk of deadlock during the design phase, it ensures the stability of generated components under long-term operation.

[0082] In one embodiment of the present invention, in the dynamic simulation verification, for the verification of target tracking functions, the optimal sub-mode allocation distance is used as the performance evaluation index; assuming the set of real target tracks is... The estimated set of tracks is Calculate the optimal sub-pattern allocation distance :

[0083]

[0084] In the formula, To assign mappings, For actual waypoints with estimated waypoints Local costs between The penalty coefficient for not assigning a track. To estimate the total number of waypoints, This represents the total number of actual waypoints.

[0085] This embodiment refines the target tracking performance evaluation in dynamic simulation verification, introducing more advanced evaluation metrics. For target tracking components, simply looking at the detection probability and false alarm probability is insufficient; Optimal Submode Assignment Distance (OSPA) provides a comprehensive metric by finding an "optimal" matching method to associate the algorithm-estimated waypoints with the actual waypoints. The calculation process is as follows:

[0086] The set of real waypoints is The algorithm outputs the estimated set of waypoints as follows: ;

[0087] By optimizing the algorithm, an allocation scheme can be found. This makes the "distance" (local cost) between all matched point pairs. The sum of distances (such as Euclidean distances) is minimized;

[0088] A fixed penalty is applied to estimated waypoints that fail to match (i.e., false alarms). .

[0089] The final distance of this plan A smaller value indicates better tracking performance. It penalizes not only position errors but also track splitting, merging, and false alarms. The OSPA metric reflects tracking accuracy, continuity, and stability simultaneously, making it more reliable than a single metric. It provides a fair and unified benchmark for comparing different tracking algorithms, contributing to advancements in tracking technology.

[0090] In one embodiment of the present invention, the compilation and packaging steps include: encapsulating the verified initial functional components and their runtime dependencies into a lightweight container image using containerization technology; the container image building process includes: starting with a minimized operating system base image; copying the component executable code, configuration files, and binary dependency libraries to a predetermined path within the image; setting the container startup entry point command; adding annotation tags to the container image that conform to a predetermined open architecture standard, wherein the annotation tags at least include a component identifier, version number, service port number, and resource requirement declaration.

[0091] This embodiment details the specific techniques for compiling and packaging verified components into standardized, portable products; the packaging process employs containerization technology (such as Docker), specifically:

[0092] Building the foundation: Start with an extremely minimal operating system image;

[0093] Injecting components: Copy the component's executable file, configuration file, and all its dependent library files to a specified location in this image file system;

[0094] Configure the startup command: Configure the image so that it can automatically run our functional components at startup;

[0095] Add standard tags: In the image's metadata, write tags that conform to open architecture standards (such as SOSA) to clearly inform the deployment platform of the component's identity, version, network service port, and CPU / memory requirements.

[0096] The packaged container image of this solution can run in exactly the same way on any platform that supports this container technology. The component is managed as an independent, lightweight container, supporting rapid startup, shutdown, migration and scaling, making it very suitable for cloud-native and edge computing environments. By following the label specifications of the open architecture, the component can be discovered, understood and invoked by other systems that conform to the same standard.

[0097] In one embodiment of the present invention, the method for generating typical underwater acoustic functional components based on an open architecture, after compilation and packaging, further includes:

[0098] S5. Component Performance Profiling Steps: The component performance profiling steps involve running standardized benchmark test cases to collect performance data of executable functional components under different input data scales and hardware configurations, including at least execution latency. CPU utilization and peak memory usage A performance prediction model is constructed based on the collected data to estimate the resource consumption of components in the target deployment environment; the performance prediction model is a multiple linear regression model, and its form is as follows:

[0099]

[0100] in, To estimate execution delay, For the size of the input data, To deploy the basic CPU load of the environment, , , These are the model coefficients fitted using benchmark test data; performance profile data is stored along with executable functional components.

[0101] This embodiment describes the steps for creating a performance profile for a component after it has been generated, specifically:

[0102] Benchmarking: Running the generated executable components on a series of pre-defined test cases with different amounts and complexities of data;

[0103] Data Acquisition: During testing, key performance indicators of the components are monitored and recorded in real time, such as execution time ( CPU utilization and peak memory usage ;

[0104] Model Construction: Based on the large amount of performance data collected, a multiple linear regression model is established: By fitting, the coefficients are obtained. , , ;

[0105] Application: When this component needs to be deployed to a new compute node, the system can input the expected data load for that node. and current base CPU load This model can be used to quickly predict the runtime of components in this environment, providing a basis for resource scheduling and task allocation decisions.

[0106] This solution quantifies the resource consumption characteristics of components, enabling system administrators to predict and plan resources in advance; it provides key input for building an intelligent resource management system, thereby optimizing the overall system performance.

[0107] In one embodiment of the present invention, the data header field of the general data model further includes a data quality indicator field; the data quality indicator The formula for calculating the comprehensive scalar value is as follows:

[0108]

[0109] In the formula, To normalize the signal-to-noise ratio, reflecting signal clarity, This refers to the packet loss rate during data transmission or buffering. The confidence level given by the front-end model or sensor itself that generated the data. , , These are weighting coefficients, which can be adjusted according to actual applications to meet certain requirements. ;

[0110] The downstream underwater acoustic functional atomic model adjusts its processing strategy based on the data quality index Q.

[0111] This embodiment enhances the general data model by adding data quality metrics to improve the robustness of components under harsh conditions.

[0112] Add a new data quality metric to the data header field of the general data model. Field. It is a value between 0 and 1, calculated by weighting multiple factors that affect the reliability of the data:

[0113]

[0114] When the downstream model receives data, it will first read... Value, if The value is very high (e.g.) If so, then use a high-precision, but noise-sensitive, standard algorithm; if Lower values ​​(e.g.) If so, it may switch to a more computationally complex but robust algorithm; if The value is very low (e.g.) If the data frame is not properly configured, it may be discarded directly to avoid introducing error messages.

[0115] This solution enables functional components to sense changes in data quality and dynamically adjust their behavior, thus maintaining a certain level of functional output even under poor channel conditions or incomplete data, thereby improving the system's survivability. In extreme cases, the system will not suddenly crash, but will maintain basic operation by reducing performance or ignoring some unreliable data.

[0116] 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 generating typical underwater acoustic functional components based on an open architecture, characterized in that, Includes the following steps: S1. Establish an underwater acoustic functional model library and a component configuration rule library. The underwater acoustic functional model library stores multiple underwater acoustic functional atomic models with standardized interfaces. The component configuration rule library stores configuration templates and constraints for combining underwater acoustic functional atomic models. S2. In response to the component generation request for the target underwater acoustic task, based on the component configuration rule base, select multiple corresponding underwater acoustic functional atomic models from the underwater acoustic functional model library for instantiation and logical linking to form the initial functional component. S3. Perform static verification and dynamic simulation verification on the initial functional components. Static verification checks the consistency of data flow logic and interface compatibility within the initial functional components based on target constraints. Dynamic simulation verification verifies whether the runtime behavior and performance indicators of the initial functional components meet the preset requirements by injecting simulated underwater acoustic data or historical measured underwater acoustic data. S4. Once the verification is successful, compile and package the initial functional components into executable functional components that conform to the predetermined open architecture standard. The constraints in the component configuration rule base include loop detection constraints based on directed graph theory and interface compatibility constraints based on data flow theory. The loop detection constraint is implemented in the following way: after constructing the directed graph model of the initial functional components, a topology sorting algorithm based on depth-first search is used to detect loops; Interface compatibility constraints are implemented by establishing an interface type system. The type system assigns a type signature to each input and output interface. The type signature is a tuple containing the basic data type, data dimension, and sampling rate. During logical linking, for edges in a directed graph, the compatibility between the source node's output type signature and the destination node's input type signature is checked. The compatibility rule is defined as follows: if and only if the output basic data type is a subtype of the input basic data type, the output data dimension meets the input requirements, and the output sampling rate is greater than or equal to the input sampling rate, it is considered compatible. Dynamic simulation verification was performed in a high-fidelity underwater acoustic channel simulation environment. The simulation environment used a simplified physical model to calculate the sound field propagation loss, and the formula for this model is: In the formula, The distance between the sound source and the receiver. , , Coefficients related to environmental parameters respectively; The dynamic simulation verification process includes: generating or loading simulated underwater acoustic data containing preset target characteristics; simulating data propagation and superimposing channel effects in the simulation environment; inputting the processed data into the initial functional component; and comparing the component output with the actual parameters to quantify performance indicators, which at least include the detection probability. With false alarm probability The calculation formulas are as follows: In the formula, To ensure the correct number of tests, For the actual target number of times, The number of false alarms. Total number of judgment opportunities; The static verification steps include data flow deadlock detection. Data flow deadlock detection involves constructing a data flow graph model of the initial functional components and analyzing its liveness implementation. Specifically, this involves: abstracting model instances as nodes and data channels as directed edges; identifying all strongly connected components in the graph; for each strongly connected component, analyzing its internal data triggering mode and data buffer capacity configuration; if there exists a strongly connected component where the execution of each node strictly depends on new data generated by the upstream node and all data buffer capacities are zero, then a risk of data flow deadlock is identified. In dynamic simulation verification, for target tracking functions, the optimal sub-mode allocation distance is used as the performance evaluation index; let the set of real target tracks be... The estimated set of tracks is Calculate the optimal sub-pattern allocation distance : In the formula, To assign mappings, For actual waypoints with estimated waypoints Local costs between The penalty coefficient for not assigning a track. To estimate the total number of waypoints, This represents the total number of actual waypoints.

2. The method for generating typical underwater acoustic functional components based on an open architecture according to claim 1, characterized in that: When establishing the underwater acoustic functional model library, the standardized interface of each underwater acoustic functional atomic model follows the interface definition specification based on the general data model; the general data model is a structured object used to encapsulate data in the underwater acoustic field, and its definition includes a data header field and a data body field; The header field stores the metadata of the data, including at least the data source identifier, timestamp, coordinate system information, and data type identifier; the data body field stores the core data, the structure of which is dynamically interpreted according to the data type identifier, and at least supports complex waveform data, beam domain data, azimuth-time history data, and target waypoint sequences. The standardized interface is implemented as follows: each underwater acoustic functional atomic model publishes the data type identifiers required by its input and output interfaces to the global service registry during initialization; at runtime, the upstream model encapsulates its output data into objects that conform to the general data model and publishes them through the middleware bus, and the downstream model receives and parses the objects according to the data type identifiers it subscribes to in order to extract the core data of the data body domain.

3. The method for generating typical underwater acoustic functional components based on an open architecture according to claim 2, characterized in that: The compilation and packaging steps include: using containerization technology to encapsulate the verified initial functional components and their runtime dependencies into a lightweight container image; the container image building process includes: starting with a minimal operating system base image; copying the component executable code, configuration files, and binary dependency libraries to a predetermined path within the image; setting the container startup entry point command; and adding annotation tags to the container image that conform to the predetermined open architecture standard. The annotation tags must at least include the component identifier, version number, service port number, and resource requirement declaration.

4. The method for generating typical underwater acoustic functional components based on an open architecture according to claim 3, characterized in that: The method for generating typical underwater acoustic functional components based on an open architecture, after compilation and packaging, further includes: S5. Component Performance Profiling Steps: The component performance profiling steps involve running standardized benchmark test cases to collect performance data of executable functional components under different input data scales and hardware configurations, including at least execution latency. CPU utilization and peak memory usage A performance prediction model is constructed based on the collected data to estimate the resource consumption of components in the target deployment environment; the performance prediction model is a multiple linear regression model, and its form is as follows: in, To estimate execution delay, For the size of the input data, To deploy the basic CPU load of the environment, , , These are the model coefficients fitted using benchmark test data; performance profile data is stored along with executable functional components.

5. The method for generating typical underwater acoustic functional components based on an open architecture according to claim 4, characterized in that: The header field of the general data model also includes an extended data quality metric field; data quality metric The formula for calculating the comprehensive scalar value is as follows: In the formula, For normalized signal-to-noise ratio, For data packet loss rate, For the confidence level of the data source, , , For the weighting coefficients, satisfying ; The downstream underwater acoustic functional atomic model adjusts its processing strategy based on the data quality index Q.

Images