Universal test system suitable for multiple types of underwater acoustic equipment

Abstract

The invention discloses a general test system suitable for multiple types of underwater acoustic equipment, and aims to solve the problems that an existing test system is poor in adaptability, lack of unification of processes, low in module reuse rate and the like. The system is designed based on a unified universal test architecture and comprises a task definition module, a driving execution module, a data acquisition module, an index calculation module and a performance evaluation module, and a complete test process link is formed. A plug-in type structure is adopted for flow decoupling, plug-ins in all functional modules are registered and accessed through standard interfaces, and flexible adaptation of various underwater acoustic equipment types in the aspect of parameter performance testing is achieved. The test task is driven through a model and a case mechanism, structured configuration and automatic execution of the task are achieved, and the test efficiency and the reusability of the test process are improved. The system has good expandability, and is suitable for different test scenes of equipment level, module level, board card level and the like. The system has been verified in various underwater acoustic equipment projects, and has significant engineering application value.

Description

Technical Field

[0001] The invention relates to a universal testing system suitable for multiple types of underwater acoustic equipment, belonging to the technical field of underwater acoustic equipment performance testing. Background Art

[0002] With the widespread application of underwater acoustic equipment in fields such as ocean exploration, communication, and perception, its internal structure has gradually developed towards modularization and board-based design, significantly increasing the demand for module- and board-level performance testing. Underwater acoustic equipment is typically composed of multiple functional units, such as signal acquisition units, signal conditioning units, and transmit / receive control units. These units require functional verification and performance evaluation during the equipment development, integration, and delivery phases to ensure system reliability and stability.

[0003] Existing underwater acoustic equipment testing systems are mostly custom-developed, with test processes configured for specific equipment or tasks, lacking versatility and reusability. When modules are replaced or new equipment is introduced, test processes often need to be rebuilt, resulting in low development efficiency and high maintenance costs. Furthermore, existing testing methods often employ tightly coupled software architectures, making it difficult to independently update or replace functional modules and adapting to complex and diverse test scenarios and multi-layered equipment objects.

[0004] At the same time, although some test systems built on general test tool platforms (such as LabVIEW or Simulink) have certain signal processing capabilities, they still have problems such as low structural abstraction, inconsistent process control, and weak module adaptability in underwater acoustic equipment testing, making it difficult to achieve cross-device and cross-task test process reuse and automated execution.

[0005] In summary, the existing technology still lacks a universal performance testing platform with unified structure, decoupled modules, reusable processes, and applicable to multi-type and multi-level underwater acoustic equipment components. Summary of the Invention

[0006] Purpose of the invention: The present invention provides a universal test system applicable to multiple types of underwater acoustic equipment, solving the problems of poor universality, high structural coupling, difficult process reuse, and low adaptation efficiency of existing test systems. The present invention aims to construct a modular, plug-in test platform architecture, realize flexible replacement and combination of functional modules through standardized interfaces, and improve the scalability of the test system; introduce task modeling and use case driven mechanisms to realize structured configuration and automated execution of test task processes, and improve the adaptability and efficiency of test processes; through a unified data flow and control mechanism, adapt to the performance test requirements of underwater acoustic equipment at different levels, including module level, board level, and device-level objects composed thereof. Through the above means, the present invention realizes the high universality and automation of the underwater acoustic equipment test system, reduces the construction and migration costs of the test platform, and improves the test support capabilities for multiple devices, multiple scenarios, and multiple parameters, and has good engineering practical value and promotion significance.

[0007] Technical solution: The present invention proposes a universal test system applicable to various types of underwater acoustic equipment. The system adopts a modular design and is suitable for performance testing tasks of underwater acoustic equipment at the module level, board level, and their combined levels. It includes a task definition module, a driver execution module, a data acquisition module, an indicator calculation module, and a performance evaluation module. Each module implements specific functional logic through plug-in units and completes data interaction through a unified interface, thereby improving the decoupling and maintainability of the system. The system also introduces task modeling and use case driving mechanisms to achieve structured configuration and automated execution of the test process. It has good adaptability and reuse capabilities and can support a variety of test scenarios and equipment types.

[0008] (1) Task definition module: The task definition module is used to build, manage and store test task models and use case generation, as follows:

[0009] (11) Task model construction: used to establish a structured test task model, which includes a device information set, a multi-dimensional parameter information set, an indicator configuration set, a control strategy set, and an archiving strategy;

[0010] (12) Task model management: supports maintenance operations on task models, including adding, modifying, copying, deleting, and version management, and supports inheritance and reuse of models, which is used to flexibly organize and update test task information in a unified configuration environment;

[0011] (13) Task model storage: The constructed task model is stored in a unified data format in the system database or configuration storage unit for subsequent scheduling calls;

[0012] (14) Execution Case Generation: The task definition module includes a use case generator, which performs a Cartesian product expansion on the multi-dimensional parameter information set in the task model to obtain all possible parameter combinations. It then combines each set of parameters with other elements in the model to generate multiple test cases. Each execution case has independent process control properties. At runtime, the system schedules the execution of functional modules based on the use case content, achieving a complete automated testing process.

[0013] (2) Driver execution module: The driver execution module is used to convert the execution use case information output by the task definition module into control instructions, and accordingly drive the input device and the acquisition device to enter the specified working state, specifically including:

[0014] (21) Control parameter parsing and loading: According to the parameter combination and device information configured in the execution case, complete the initialization of the excitation signal parameters and the preparation of the device status, including frequency, amplitude, channel status, trigger mode, etc.;

[0015] (22) Device excitation and control operation: Controls the output of the signal source and drives the target device or link to operate according to the set working mode; supports the issuance of various control instructions including waveform output, channel activation, acquisition synchronization, remote control, etc.

[0016] (23) Interface and protocol adaptation mechanism: Use a unified control interface specification to encapsulate the underlying control logic, support multiple communication methods (such as serial port, TCP / IP, SCPI, etc.) and control protocol adaptation of different types of equipment, and realize linkage control with external devices, scene modules, simulation platforms, etc.;

[0017] (24) Control process management: During the device control process, the driver execution module has the capabilities of status query, synchronous control, and interrupt response. Status query is used to detect the configuration status and operation feedback of the signal source before and after the control command is issued, such as whether the output is turned on and whether the frequency amplitude is set successfully. The synchronous control function is enabled when performing linkage testing with the acquisition device to ensure that the output of the excitation signal is coordinated with the triggering action of the sampling task. If a control timeout occurs during the test, the device responds abnormally, or an interrupt command issued by the scheduling module is received, the driver execution module will immediately execute the interrupt logic, terminate the waveform output, close the control channel, and release the occupied resources to ensure device safety and process reliability.

[0018] (3) Data acquisition module: The data acquisition module is used to control the acquisition equipment, perform data acquisition tasks, and complete the data structure restoration and format unification, specifically including:

[0019] (31) Acquisition control initialization: According to the parameter settings and device information set in the execution case, complete the initialization operation of the acquisition device, including channel setting, buffer configuration and trigger mode setting;

[0020] (32) Data acquisition execution: Supports task-level acquisition control and external synchronization mechanisms, and implements multi-channel synchronous sampling through time markers or trigger signals. The acquired data includes original time domain waveforms, communication messages, and device response results;

[0021] (33) Structural analysis and format restoration: Based on the structural description information defined in the task model, the original collected data is subjected to structural analysis and reorganization, and restored to time domain data with a unified structure to adapt to subsequent feature extraction and indicator analysis;

[0022] (34) Data quality judgment and anomaly detection: During the acquisition process, the module can automatically detect common data anomalies such as whether the channel has valid data, whether the data frame is complete, whether there is frame loss or disconnection, etc.

[0023] (4) Index calculation module: The index calculation module is used to process and analyze the collected and restored test data and calculate various parameter performance indicators, including:

[0024] (41) Signal preprocessing: performing data preprocessing operations such as DC removal, normalization, and filtering to provide standard input for subsequent indicator calculations;

[0025] (42) Parameter index extraction: Based on the preprocessed data, the corresponding indicator type is calculated according to the indicator configuration set and its corresponding parameter configuration obtained from the execution use case;

[0026] (43) Result output: The calculated results of various indicators are packaged into a unified format for use by the performance evaluation module.

[0027] (5) Performance evaluation module: The performance evaluation module is used to analyze and evaluate the index calculation results and generate test conclusions, specifically including:

[0028] (51) Indicator result judgment: Based on the control configuration in the execution use case, determine whether the results of each indicator meet the set requirements;

[0029] (52) Abnormal identification and retest suggestion: Identify the indicator results that do not meet the requirements, analyze the abnormality type, and output the corresponding retest suggestion and mark;

[0030] (53) Result output and archiving: Based on the archiving strategy in the execution use case, the evaluation results are packaged into a structured format and supported for exporting reports or archiving. The archiving strategy includes the storage path, file format, version identification, and naming rules for the original data, indicator results, and evaluation labels. It is used to standardize the storage method of test data and ensure the traceability and consistency of the results.

[0031] (6) Plug-in structure mechanism: Each functional module of the test system adopts a plug-in structure mechanism. The module is composed of plug-in units and a unified interface, as follows:

[0032] Plug-in unit: encapsulates the specific functional implementation logic of each module. Each functional module can be associated with multiple plug-in units to support different types of test tasks. However, during each task execution, only one plug-in unit is selected and called according to the execution case configuration to complete the corresponding functional operation, realizing on-demand switching and function reuse;

[0033] Module interface: Each functional module defines an independent interface specification, which clarifies the calling method, input and output format, execution process and data interaction rules of the module plug-in and other modules of the system, so as to achieve high cohesion of module functions and low coupling of system structure;

[0034] Plug-in manager: The system configures an independent plug-in manager for each functional module, which is responsible for completing the loading, registration, unloading and switching of plug-in units during the task loading phase, ensuring the flexibility and stability of plug-in operation;

[0035] Plug-in configuration source: The calling path and initialization parameters of each plug-in unit are provided by the execution use case. When the module is executed, the corresponding plug-in is dynamically configured according to the use case content, supporting task-level customization.

[0036] Execution consistency assurance: The running results of all plug-in units must follow the unified data encapsulation standard to ensure the format consistency and compatibility of the results transmitted between modules.

[0037] Beneficial effects: The present invention proposes a universal test system applicable to various types of underwater acoustic equipment components, aiming to solve the problems of poor universality of existing test methods, high module coupling, and low degree of automation. The system is based on a modular and plug-in architecture design, and includes a task definition module, a driver execution module, a data acquisition module, an indicator calculation module, and a performance evaluation module. Each functional module encapsulates the specific implementation logic through a plug-in unit, and combines a unified interface to achieve low-coupling data interaction and high-cohesion functional organization, supporting flexible loading, registration, switching, and unloading of plug-ins. The system introduces a structured task modeling and execution use case driving mechanism, which supports the automatic expansion of structured configuration and parameter combinations of the test process, and can dynamically schedule module functions according to different test tasks, thereby improving the flexibility and reuse efficiency of the test. As the basic unit of system operation, the execution use case runs through various links such as module scheduling, control parameter distribution, data structure analysis, and indicator determination, realizing the full process automation and closed-loop execution of the test task. The test system of the present invention can be widely applied to underwater acoustic system performance evaluation scenarios at the module level, board level and device level, significantly improving the adaptability, scalability and maintainability of the test platform, while enhancing the structural uniformity of the test data and the traceability of the results, and has good engineering practical value and promotion potential. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 Schematic diagram of the overall module structure and plug-in implementation framework of the test system of the present invention;

[0039] Figure 2 This is a schematic diagram of the deployment module structure of the test system of the present invention;

[0040] Figure 3 A schematic diagram of the plug-in operation process and user interaction;

[0041] Figure 4 Schematic diagram of the plug-in adaptation structure of the data acquisition module;

[0042] Figure 5 This is a schematic diagram of the structural elements of the test task model;

[0043] Figure 6 A schematic diagram of the use case generation and execution process driven by the test task model;

[0044] Figure 7 Schematic diagram of the structured data table organization for the test model;

[0045] Figure 8 A schematic diagram of the process of generating standard control commands based on parameter configuration in the driver execution module and sending them to the device;

[0046] Figure 9 This is a schematic diagram of the data acquisition and processing flow based on the callback mechanism of the data acquisition module;

[0047] Figure 10 This is a schematic diagram of the module control flow of a general underwater acoustic test system;

[0048] Figure 11 Schematic diagram of the module data flow of the general underwater acoustic test system. DETAILED DESCRIPTION

[0049] To provide a clearer understanding of the present invention, the following describes in further detail the universal testing system for various types of underwater acoustic equipment, using the accompanying drawings and specific examples. It should be understood that this embodiment is intended only to illustrate the present invention and is not intended to limit its scope. Equivalent substitutions without departing from the principles of the present invention are also intended to fall within its scope.

[0050] (1) Overall system architecture

[0051] like Figure 1 As shown, the universal testing system proposed in this paper utilizes a basic process of "task definition → driver execution → data acquisition → indicator calculation → performance evaluation," establishing a modular functional architecture for underwater acoustic equipment testing. Each process step corresponds to a functional module, which performs tasks such as task configuration, equipment control, data acquisition, indicator analysis, and result evaluation. The modules are connected via standardized data interfaces, forming a data-driven serial execution chain that ensures process integrity and consistent information transmission.

[0052] Each functional module of the system utilizes a plug-in architecture. The modules themselves do not implement specific execution logic, but rather load external plug-in units during operation to complete their functions. A plug-in unit typically encapsulates the control logic or data processing methods of a specific type of underwater acoustic equipment. Before a task is executed, the system determines the plug-in type based on the mission model or use case content, and loads and calls it, enabling rapid adaptation to a variety of equipment types.

[0053] like Figure 2 As shown, in addition to the five core functional modules, the system can also integrate a task scheduling module and a display module based on actual deployment requirements. The task scheduling module can be used for batch control scheduling and process management, while the display module provides graphical display and interactive operation of the test process. These modules maintain the same structure as the core modules and also connect to common test systems through interfaces, providing good scalability and adaptability.

[0054] (2) Plug-in structure implementation method

[0055] To achieve the above decoupling goals, the system builds a plug-in operating environment based on the Qt plug-in framework. The key practices are as follows:

[0056] ①Interface layer

[0057] Each functional module (task definition, driver execution, data acquisition, metric calculation, and performance evaluation) first declares a set of independent interface classes. These interfaces contain only input and output descriptions, core call functions, and error reporting mechanisms. They all inherit from QObject and are registered with the Qt meta-object system using Q_DECLARE_INTERFACE. During compilation, the general test system relies solely on the interface header files and is unaware of any plugin source code, thus completely isolating the framework from the business logic.

[0058] ②Plug-in unit

[0059] The business implementation corresponding to each interface is encapsulated as a plug-in unit and released as a dynamic link library (*.dll / .so). Developers simply derive the interface class and implement its declared methods to package control protocols for devices from different manufacturers, various acquisition card drivers, or specialized indicator algorithms as independent plug-ins. Because the interface has unified input, output, and error handling, any compliant plug-in can be seamlessly recognized and called by the system, allowing functional expansion and replacement without modifying the general test system.

[0060] ③Loading and calling process

[0061] The system's plug-in calling process can be referred to Figure 3 As shown: When the user triggers a test task through the main interface, the system will call the plug-in loader QPluginLoader class to complete the dynamic loading of the plug-in library according to the plug-in path and initialization parameters specified in the execution case, and obtain the corresponding interface instance. After successful loading, the general test system calls the functional logic or graphical interactive interface in the plug-in through the interface pointer. For example Figure 3 In the scenario demonstrated, the user triggers the plug-in's graphical interface by pressing a button. In response to the user's click, the plug-in executes predefined logic and reports the results to the main interface for unified display via standard output or signaling mechanisms. Upon completion, the plug-in automatically uninstalls itself according to process requirements, freeing up resources.

[0062] ④Multi-source adaptation example

[0063] Figure 4The system further demonstrates an example of the actual application of the plug-in structure in the data acquisition module. The system supports the simultaneous deployment of multiple types of data acquisition plug-ins, including network packet capture plug-ins, NI sampling plug-ins, file reading plug-ins, and user-defined plug-ins, which respectively adapt to network streams, acquisition card devices, offline data, and special format input. When a certain acquisition method is specified in the execution use case, the system loads the corresponding plug-in, injects initialization parameters (such as IP address, file path, channel number, etc.), executes the sampling process, and encapsulates the results in a unified format and submits them to the general test system for processing. Through this mechanism, the system can quickly switch between different acquisition methods without modifying the logic of the general test system, adapting to various test scenarios and device types.

[0064] ⑤Runtime management and hot replacement

[0065] During the task loading phase, the system parses and loads all required plugins for a complete test batch. If a subsequent test case requires a plugin replacement, the universal test system simply calls unload() / load() to release and reinject the plugin within milliseconds, achieving true hot swapping. All plugin execution results are required to adhere to unified data encapsulation specifications, ensuring format compatibility across modules and enabling consistent logging, fault isolation, and performance tuning.

[0066] This plug-in structure has been successfully applied to the implementation of various functional modules of the system, improving the functional organization and module independence of the system.

[0067] (3) Specific implementation of the model and use case mechanism

[0068] In order to realize the automatic deployment and scheduling control of the test process, the present invention introduces a structured task model and use case mechanism into the system, abstracts the process structure, module dependencies and parameter configuration information of the test task into a unified model representation, and generates independent execution use cases through analysis, thereby driving the orderly execution of each functional module.

[0069] like Figure 5 As shown in the figure, the task model encapsulates the core configuration information of the test task in a structured manner, which is defined as a five-tuple:

[0070] M=(D,P,I,C,A)

[0071] D is a device information set that describes the basic properties of the device under test involved in the current test task, including device type, device number, number of channels, default amplitude gain, etc.

[0072] P is a parameter setting set that describes all parameter configurations involved in the test task, including frequency point list, signal amplitude, sampling rate, sampling duration, signal source channel allocation scheme, and other information;

[0073] I is the indicator configuration set, which indicates the performance indicator set and algorithm reference method required for calculation in this test, such as whether amplitude consistency, phase consistency, channel isolation, etc. need to be calculated, and is associated with the corresponding algorithm function module or configuration option;

[0074] C is a set of control policies, which defines the system's abnormal response and process control logic during task execution, including whether to enable automatic retesting, the maximum number of retests, the type of abnormal threshold, and the failure handling method (skip, terminate, forced retest, etc.).

[0075] A is an archiving strategy set, which is used to describe the storage path and data structure of the test results, including the storage directory of the original sampling data, the test report file format and version marking strategy.

[0076] The known test model is M=(D,P,I,C,A), where P={P1,P2,...,P k} represents a test parameter set containing k parameter dimensions. Cartesian product expansion of each dimension parameter combination is performed to obtain all possible test configuration combinations:

[0077] ρ=P1×P2×…×P k

[0078] Each combination p i ∈ρ is the actual test process of the corresponding parameters, that is, a set of execution use cases:

[0079] Τ={T i =(D,p i ,I,C,A)|p i ∈ρ}

[0080] Among them, each use case T i The elements of the test model and the test parameters of the current use case are combined into p i Each execution use case T i Each has independent process control properties and is executed sequentially as a unit task during system scheduling. When a test case completes testing, the system determines the next step based on its result status and the control strategy C in the model, including whether to retest, skip, or terminate the current task.

[0081] like Figure 6 As shown in Figure 1, the test model drives the test process and its mechanism of action in each process link. nAs an example, the standardized execution process of each use case is shown: "Task definition → drive execution → data acquisition → indicator calculation → performance evaluation". Each test case represents a complete test process execution unit under a set of specific parameters. The system will call the use case scheduling module, which uniformly manages all pending use cases and supports mechanisms such as sequential scheduling, group execution, and retry on failure, providing a unified process control entry for the entire automated test system. It schedules the execution of each use case in a sequential or strategic manner: parameter combination p i It is mainly used in the configuration stage. The device model D and parameter combination jointly determine the drive control and collection methods. The indicator configuration I specifies the analysis content and algorithm call in the indicator calculation stage. The control configuration C and archiving strategy A respectively provide the exception handling logic after performance evaluation and determine the output location and format of data and reports in the performance evaluation stage.

[0082] In addition, the task model supports storage and management in the form of structured data in the system. Figure 7 The database structure presented here uses a three-tiered organizational structure: device information, test plans, and test tasks. The device table identifies the test object, the plan table defines various test logic configurations, and the task table records the parameter settings and run results for each test instance. This design supports the call, inheritance, and version management of task models, and provides a data foundation for programmatic model parsing and use case generation.

[0083] (4) Specific implementation of each module

[0084] ①Task definition module

[0085] The task definition module is implemented through structured parameter extraction and unified configuration generation mechanism. The relevant interface functions are shown in Table 1.

[0086] Table 1 Task definition module interface function table

[0087]

[0088] This module's implementation utilizes automatic parameter field parsing and structure encapsulation. First, it calls readModelFromDB() with the task ID passed in from the execution case to connect to a SQLite database and extract device information, parameter settings, and indicator configurations related to the current task. The extracted parameter fields are loaded into a QVariantMap structure as key-value pairs. parseModelParams() then parses the meaning of each field and converts it to a standard type.

[0089] In buildConfigStruct(), a custom data structure, TaskConfigStruct, is used to encapsulate incentive methods, channel configurations, and indicator lists, and then distributes them uniformly to each module. This structure uses built-in data validation functions to ensure parameter integrity and supports default filling or dynamic derivation of some fields, making it suitable for flexible adaptation scenarios of different test tasks.

[0090] During the interface implementation process, all functions inherit from the unified interface class ITaskDefinitionPlugin and are dynamically identified and called during the plug-in loading phase through Qt's Q_DECLARE_INTERFACE registration mechanism.

[0091] ②Drive execution module

[0092] The driver execution module uses a standard command generation mechanism and communication protocol adaptation method to complete the control and stimulation of the signal source device. The relevant interface functions are shown in Table 2.

[0093] Table 2 Driver execution module interface function table

[0094]

[0095] The module's internal implementation is based on the VISA (Virtual Instrument Software Architecture) communication framework and uses the SCPI (Standard Commands for Programmable Instruments) command set to encapsulate and issue device control commands. After loading the parameters, the driver plug-in automatically maps control parameters such as waveform type, frequency, and amplitude to standard commands, and then sends the commands to the target device through a unified communication interface.

[0096] like Figure 8 As shown in the figure, the plug-in's execution process includes selecting a waveform type (such as SIN, SQU, RAMP, or NOISE), setting frequency and amplitude parameters (such as FREQ 10000Hz and VOLT 0.5V), and configuring the output channel switch (OUTP ON / OFF). This configuration information is then combined into a complete SCPI command sequence. The commands are sent to the device via the VISA interface, which responds and outputs stimulus. Finally, the plug-in reads the device's status through the queryStatus() interface, providing feedback on the execution success.

[0097] This structure encapsulates the underlying communication differences, improves the module's control abstraction layer and adaptability, and can support universal control of multi-brand, multi-interface protocol signal source devices, and is widely applicable to automated testing needs in multiple scenarios.

[0098] ③Data acquisition module

[0099] The data acquisition module controls the sampling equipment to complete operations such as raw signal acquisition, trigger synchronization, and format restoration. It uses a unified interface and plug-in mechanism to adapt to various types of acquisition hardware and outputs sampling results in a standardized structure for subsequent indicator analysis. Table 3 lists the main interface functions of the data acquisition module.

[0100] Table 3 Data acquisition module interface function table

[0101]

[0102] The system first initializes the sampling device according to the settings in the execution use case through initAcq(cfg), including channel selection, sampling rate configuration, buffer management, etc. Subsequently, it calls startAcq() to start the sampling task and waits for an external or software trigger signal through waitForTrigger(timeout) to ensure the synchronization of the multi-channel acquisition process.

[0103] like Figure 9 As shown in the figure, the entire acquisition process is driven by a dynamically created acquisition task. The system first completes resource scheduling and channel status configuration, then registers a callback function and sets the trigger conditions. When the trigger conditions are met, the callback function is invoked by the system, reads the data samples from the current device buffer, and organizes them into a structure. The plug-in performs preprocessing operations such as rearrangement, alignment, and data type conversion on the acquired data, and encapsulates it into a standard data matrix structure using the convertToMatrix() interface. After sampling is complete, the system calls stopAcq() to shut down the acquisition device and release resources.

[0104] During operation, the module also supports interfaces such as evaluateChannels() and checkAcqStatus() to determine whether the sampling of each channel is valid and whether the data is complete. If an abnormality occurs, the scheduling module can be notified in time to interrupt the task or execute the retest logic.

[0105] ④Indicator calculation module

[0106] The indicator calculation module is used to perform quantitative analysis on the collected test data, extract various parameter indicators, and encapsulate the results. The system loads different types of calculation algorithms through a plug-in mechanism to adapt to diverse testing needs.

[0107] Table 4 Index calculation module interface function table

[0108]

[0109] As shown in Table 4, the module first registers available algorithm plug-in types through the registerMetricPlugins() interface, enabling dynamic registration and expansion of metric analysis methods. Subsequently, the system calls bindMetricConfig(cfg) to receive the configuration parameters passed in by the task definition module and initialize the calculation path for the current task, including settings for the required metric type, processing channel, window length, and so on.

[0110] Data loading is accomplished through the loadInputData(data) API, which accepts sampled waveforms, recognition results, or pre-processed data, ensuring a unified input format for all computational algorithms. Metric calculations can be performed through two APIs: computeAllMetrics() supports batch calculations of all registered metrics, suitable for standardized testing processes; and computeMetric(name) performs on-demand calculations for a specific metric, suitable for targeted verification and debugging tasks.

[0111] The calculation results are encapsulated in a structured format using exportMetricResults(), facilitating subsequent module calls, report output, and archiving. Throughout the calculation process, the module outputs execution status and exception flags (such as missing data, calculation failure, etc.) in real time, allowing the scheduling module to make process judgments and processing decisions through the getCalcStatus() interface.

[0112] This module closely corresponds to the metric configuration set in the execution use case. All calculation operations are executed based on the metric type and parameter set specified in the use case, enabling streamlined and parameterized management of the calculation process. The system's plug-in architecture supports flexible expansion and reuse of different algorithms, making it a key unit in the test system's multi-scenario adaptation and consistent result assurance.

[0113] ⑤Performance evaluation module

[0114] This module adopts a strategic judgment method driven by evaluation rules, supporting functions such as common threshold comparison, abnormal pattern recognition and automatic generation of retest suggestions. The execution logic is uniformly coordinated by the scheduling module and connected to the indicator calculation results.

[0115] Table 5 Performance evaluation module interface function table

[0116]

[0117] During the actual operation of the plug-in, the system loads task-level rules and sets the execution process based on the control policy set bound to the execution case. The indicator result judgment process supports multiple threshold types (absolute value / relative difference / upper and lower limits, etc.) and scoring logic (single indicator forced rejection / multiple weighted comprehensive evaluation, etc.), and can be customized and extended through the plug-in interface.

[0118] When the module detects abnormal behavior (such as amplitude jitter exceeding the set limit or obvious phase drift trend), it will trigger the abnormal analysis module, which will combine the control strategy to decide whether to initiate automatic retesting or interrupt the process. If necessary, it will generate retesting suggestions and feedback to the scheduling system.

[0119] In addition, all evaluation results can generate structured outputs based on the archiving strategy defined in the execution use case, support channel tagging, result summary and report export, and be stored in the system database in a unified manner to ensure that the results can be traced and reviewed.

[0120] 5. System control flow and data flow

[0121] To ensure that the test tasks of various types of underwater acoustic equipment can be executed efficiently and orderly within the system, the present invention designs an inter-module interaction mechanism for a universal test system from the two levels of control logic and data flow. The control flow path is uniformly managed through the task scheduling module, and the data flow between modules is managed through a structured format.

[0122] (1) System control flow design

[0123] like Figure 10 As shown in the figure, the system adopts a centralized control strategy, with the task scheduling module as the core of the process, which sequentially schedules functional modules such as task definition, driver execution, data acquisition, indicator calculation and performance evaluation, forming a clear execution closed loop. The main steps of control flow design include:

[0124] ① Model loading and initial configuration: After a test task is initiated, the task scheduling module first calls the task definition module to load the task model bound to the current device. This model includes signal configuration, sampling parameters, calculation metrics, control strategy, and archiving requirements. After the task definition module parses the model, it returns the structured configuration to the task scheduling module.

[0125] ②Driver module excitation control: The scheduling module calls the driver execution module based on the model configuration, controlling the signal source to output waveforms according to the frequency, amplitude, and channel specified in the task. The internal plug-in of the driver module maps the parameters to standard device control commands, completing device configuration and excitation startup.

[0126] ③ Data Acquisition Module: After the stimulus stabilizes, the scheduling module calls the data acquisition module to initialize the sampling device channels and synchronization configuration. Data acquisition begins when the set trigger conditions are met. After sampling is completed, the original waveform data is returned to the scheduling module.

[0127] ④Indicator calculation execution: The sampling data is passed from the scheduling module to the indicator calculation module. The module calls the corresponding plug-in to complete the indicator extraction according to the indicator type set in the model (such as amplitude consistency, phase consistency, isolation, etc.) and returns the structured calculation results.

[0128] ⑤ Performance Assessment and Retest Strategy: The scheduling module calls the performance evaluation module to assess the aforementioned metrics and generate anomaly attribution and retest recommendations for channels with deviations. If the retest conditions are met, the scheduling module recycles the sampling process.

[0129] ⑥Result display and archiving: After the test is completed, the scheduling module submits the evaluation results to the display module for graphical display, and at the same time calls the performance evaluation module to complete data archiving and report preservation, forming a complete closed-loop process.

[0130] (2) System data flow design

[0131] like Figure 11 As shown in the figure, during the test, the data transmission path between modules is clear, data flows in an orderly manner under the scheduling of the task scheduling module, and each data structure is encapsulated in a unified format to ensure compatibility and processing efficiency. The key path of data flow design is as follows:

[0132] ① Raw data acquisition and structured packaging: The raw signal collected by the acquisition hardware is preprocessed by the data acquisition module and packaged into a matrix data frame, which contains information such as sampling value, channel number, timestamp, etc., and is passed to the scheduling module.

[0133] ② Data transfer and zero-copy processing: The scheduling module directly passes the reference or index of the original data buffer to the indicator calculation module, avoiding redundant copying. The indicator calculation plug-in accesses the data through mapping and extracts various performance indicators, improving processing efficiency.

[0134] ③ Calculation result transmission and graphical display: The indicator calculation module outputs structured results, including indicator name, value, unit, and threshold, and, if necessary, compressed waveform data. The scheduling module transmits the results to the display module for graphical display and abnormal highlighting.

[0135] ④ The indicator data and the original index are passed to the evaluation module together: The performance evaluation module not only uses the calculated indicators, but also references the corresponding original data index to achieve in-depth analysis, such as mutation detection, waveform structure integrity identification and other operations.

[0136] ⑤ Test model configuration objects are used throughout the entire process: The task definition module provides a unified configuration object at the beginning of the test, which contains the initialization parameters required by all plug-ins. This configuration serves as the task context throughout the execution of each module to ensure consistency in the test process.

Claims

1. A universal test system applicable to various types of underwater acoustic equipment, characterized in that: include: Task definition module, used to configure test task models and parameters; Driver execution module, used to control the working status of input devices and acquisition devices; Data acquisition module, used to collect test signals output by the equipment and unify the data format; Index calculation module, used to extract features and calculate performance indicators of collected data; Performance evaluation module, used to evaluate calculation results and generate test reports; Among them, each functional module is implemented using a plug-in structure so that the module function can be replaced or expanded when needed; the system adopts a configuration method based on the model and use case mechanism, and the task model generates the corresponding execution use case, and schedules each module according to the use case to complete the automated test.

2. The universal testing system according to claim 1, characterized in that: Each functional module consists of a plug-in unit and an interface. The plug-in unit encapsulates the function implementation logic, and the interface is used to define a unified data interaction specification. The system sets up a plug-in manager for each functional module to load, register, unload and switch the plug-in unit of the module.

3. The universal testing system according to claim 1, characterized in that: The task model is in a structured form and is used to describe the node configuration, module calling path and parameter information of the test process, and supports the calling, inheritance and reuse of the task model.

4. The universal testing system according to claim 1, characterized in that: The task definition module includes a use case generator, which is used to generate corresponding execution use cases according to the task model; the system also includes a module scheduler, which is used to schedule the operation of each functional module in a predetermined order according to the execution use case to complete the automated execution of the test process.

5. The universal testing system according to claim 1, characterized in that: The data acquisition module has the function of data structure analysis and restoration. It can perform corresponding analysis and structural reorganization processing on the collected data according to the data format description information preset in the test task model, and restore the original data in different formats into time domain data with a unified structure to support subsequent feature extraction and performance analysis.

6. The universal testing system according to claim 1, characterized in that: The performance evaluation module is used to calculate various performance indicators, analyze and evaluate the results based on the indicators, and generate a test report; the performance indicators include amplitude consistency, phase consistency, channel isolation and self-noise range.

7. The universal testing system according to claim 1, characterized in that: The system integrates a task scheduling module and a display module according to actual deployment requirements; the task scheduling module is used for the control scheduling and process management functions of batch use cases; the display module is used for graphical display and interactive operation of the test process; the task scheduling module and the display module are connected to the general test system through an interface.

8. The universal testing system according to claim 1, wherein: During the implementation of the plug-in structure, a plug-in operating environment is constructed based on the Qt plug-in framework; at the interface layer, each module first declares a set of independent interface classes, which only contain input and output descriptions, set core call functions, and error return mechanisms. All of them inherit QObject and use Q_DECLARE_INTERFACE to register with the Qt meta-object system; the business implementation corresponding to each interface is encapsulated as a plug-in unit and published in the form of a dynamic link library; when the user triggers the test task through the main interface, the system will call the plug-in loader QPluginLoader class to complete the dynamic loading of the plug-in library according to the plug-in path and initialization parameters specified in the execution case, and obtain the corresponding interface instance; after successful loading, the functional logic or graphical interaction interface in the plug-in is called through the interface pointer; the user triggers the plug-in graphical interface through a button, and the plug-in executes the predefined logic in response to the user's click, and feeds back the execution results to the main interface for unified display through standard output or signal mechanism; After the task is completed, the plug-in is automatically uninstalled according to the process requirements to release resources; The system supports the simultaneous deployment of multiple types of data acquisition plug-ins, including network packet capture plug-ins, NI sampling plug-ins, file reading plug-ins, and user-defined plug-ins. When a certain acquisition method is specified in the execution use case, the system loads the corresponding plug-in, injects initialization parameters, executes the sampling process, and encapsulates the results in a unified format. In a complete test batch, the system will parse the list of plug-ins required for all steps at one time and complete the loading during the task loading phase. If subsequent test cases require plug-ins to be replaced, the system only needs to call unload() / load() to complete the release and re-injection of the plug-in.

Images