A flight control simulation test method and system based on voice interaction and demand alignment

Abstract

The application relates to the technical field of flight control simulation testing, and discloses a flight control simulation testing method and system based on voice interaction and demand alignment. The method comprises the following steps: obtaining user voice demand, generating structured text through endpoint detection and term normalization; outputting an analysis result containing explicit constraints through semantic analysis; constructing a demand intermediate representation instance based on slot template mapping and version management; checking slot integrity and logical consistency through a multi-dimensional rule engine, and generating a checking report; completing intelligent interaction completion by combining voice follow-up guidance, obtaining a complete and consistent demand instance; performing component retrieval and simulation topology generation according to a parameterized template, and outputting a topology structure and an interface mapping table; and finally outputting an executable simulation program and a test report by completing simulation asset generation and closed-loop verification through parallel generation and intelligent repair strategies. The application realizes automatic generation from voice demand to a simulation program, and improves flight control simulation testing efficiency.

Description

Technical Field

[0001] This invention relates to the field of flight control simulation testing technology, and more specifically, to a flight control simulation testing method and system based on voice interaction and demand alignment. Background Technology

[0002] The flight control system is a core component of unmanned aerial vehicles (UAVs), and its performance directly affects flight safety and mission execution. During the development of flight control systems, simulation testing is a crucial means of verifying control algorithms and system performance. Traditional flight control simulation testing processes rely on manual modeling and configuration. Test engineers need to manually write simulation model code according to test requirements, configure sensor parameters, control law parameters, scenario parameters, and fault injection logic. This entire process is time-consuming and prone to errors.

[0003] While existing flight control simulation tools offer graphical modeling interfaces, testers still need professional simulation modeling knowledge. For complex multimodal switching scenarios and fault injection tests, repeated parameter debugging and configuration modifications are necessary, resulting in low efficiency. Furthermore, a semantic gap exists between requirement descriptions and simulation implementations. Testers' natural language requirements are difficult to directly translate into executable simulation programs, leading to misunderstandings and implementation errors.

[0004] To address the aforementioned issues, there is an urgent need for a method that can automatically transform natural language testing requirements into executable simulation programs, thereby automating the process from requirement description to simulation asset generation, lowering the testing threshold, improving testing efficiency, and ensuring consistency between requirements and implementation. Summary of the Invention

[0005] This invention provides a flight control simulation testing method and system based on voice interaction and requirement alignment, which solves the technical problems in related technologies, such as the low efficiency of flight control simulation testing relying on manual modeling and configuration, and the difficulty in directly converting natural language requirements into executable simulation programs, leading to inconsistencies between requirements and implementation.

[0006] This invention provides a flight control simulation testing method based on voice interaction and demand alignment, comprising the following steps: S1: Obtain user voice requirements, and use endpoint detection and domain terminology normalization to obtain structured text; S2 receives structured text, performs semantic parsing using intent recognition and entity relation extraction, and obtains semantic parsing results containing explicit constraints. S3 receives the semantic parsing results, uses slot template mapping and version management to obtain the structured requirement intermediate representation (IR) instance; S4 receives the IR instance, uses a multi-dimensional rule engine to verify slot integrity and logical consistency, and obtains a verification report. S5 receives the verification report and IR instance, and uses voice prompts to guide intelligent interactive completion to obtain a complete and consistent IR instance. S6: Receive a complete and consistent IR instance, use parameterized templates to perform component retrieval and simulation topology generation, and obtain the topology structure and interface mapping table; S7 receives the topology and interface mapping table and IR instance, and uses parallel generation and intelligent repair strategies to generate simulated assets and perform closed-loop verification, resulting in an executable simulation program and test report.

[0007] In a preferred embodiment, the endpoint detection and domain terminology normalization process in S1 includes: Speech endpoint detection and noise reduction preprocessing are based on dual-threshold energy detection. The acquired audio signal is pre-emphasized and filtered, and the pre-emphasized signal is segmented into frames and windowed using a Hamming window function. Short-time energy and short-time zero-crossing rate are calculated for each frame. A dual-threshold decision strategy is used to set high-energy threshold, low-energy threshold, and zero-crossing rate threshold for endpoint detection. Spectral subtraction is used to denoise the detected speech segments. This paper proposes a method for speech-to-text conversion based on the fusion of acoustic and language models. Mel-frequency cepstral coefficients are extracted from the denoised speech signal. The extracted feature sequence is then input into the acoustic model for frame-level phoneme recognition. The phoneme probability sequence output by the acoustic model is combined with the language model to perform word sequence search, yielding preliminary text transcription results. Based on a domain terminology database, we perform professional vocabulary correction and normalization. We scan the initial transcribed text word by word, calculate the edit distance between each word and each term in the terminology database, replace misidentified forms with standard term names, and standardize numerical units.

[0008] In a preferred embodiment, the semantic parsing performed in step S2 using intent recognition and entity relation extraction includes: Test type identification is based on an intent classification model. A text classification model is used to identify the intent of the input text and determine the test type of the user's needs. The text input to the model is processed by word embedding encoding and attention mechanism, and then the probability distribution of each test type is output through the classification layer. Named entity recognition and attribute extraction based on sequence labeling: This method uses a sequence labeling model to extract key entities and their attributes from text. Each word in the input text is labeled with an entity tag, and after the entity is identified, its attributes are further extracted. Entity relation reasoning is based on dependency parsing trees. Dependency parsing is performed on the text to construct a dependency relation tree between words. Relations are extracted using a method that combines rule matching based on dependency parsing trees with a relation classification model. The extracted relations are stored in the form of triples to form an entity relation graph. Constraint extraction is performed based on temporal logic expression parsing. Start time, end time or duration is extracted by identifying time prepositional phrases, and conditional expressions are extracted by identifying conditional connectors to construct formal logic expressions.

[0009] In a preferred embodiment, the slot template mapping and versioning management in S3 includes: The predefined hierarchical IR template structure is designed. The IR template includes a metadata field recording the unique identifier, version number, and timestamp of the IR instance, and creating the path to the user-associated original audio file. The aircraft description field includes an aircraft type identifier, mass parameters, inertial parameters, aerodynamic model references, propulsion model references, a body coordinate system definition, and a global physical unit system. The sensor list field stores each sensor object in array form. The actuator list field stores each actuator object. The control law field contains a set of available modes, a controller structure description for each mode, controller parameters, and mode switching logic. The simulation scenario field includes initial state, environmental conditions, task profile, stage events, and a fault injection list. The test assertion field stores acceptance assertion objects in array form. The semantic parsing results are mapped to IR slots using a strategy that combines rule-driven and semantic matching.

[0010] In a preferred embodiment, the slot integrity and logical consistency verification performed in step S4 using a multi-dimensional rule engine includes: Required field integrity check: Iterate through the IR template definition to extract the list of all required fields, then iterate through the current IR instance to check each required field for a non-empty value. If a required field is missing or has an empty value, record the complete path, field description, and error type of the corresponding field. The physical parameters are validated for rationality and range. The rationality of the physical parameters in IR is checked to ensure that the parameter values ​​conform to physical laws and engineering common sense. The pre-set parameter rationality rule library is queried. If the parameter violates the hard constraints, it is recorded as a fatal error. If the parameter exceeds the recommended range but does not violate the hard constraints, it is recorded as a warning. Global unit system consistency check: Extract the global unit system definition from the aircraft description domain of IR, traverse all fields involving physical quantities in IR and check whether the unit label of each field is consistent with the global unit system. For fields with inconsistent units, determine whether unit conversion is required.

[0011] In a preferred embodiment, the intelligent interactive completion using voice prompts in step S5 includes: The system generates follow-up questions based on error classification. It categorizes and processes errors according to their type: for errors involving missing required fields, it generates follow-up questions describing the missing information; for errors involving unreasonable parameters, it generates follow-up questions explaining the parameter anomaly and suggesting adjustments; for errors involving logical conflicts, it generates follow-up questions describing the conflict and selecting a solution; for errors involving inconsistent units or coordinate systems, it generates follow-up questions confirming the conversion requirement; and for low-confidence fields, it generates follow-up questions requesting confirmation. The system prioritizes and organizes follow-up questions in batches, prioritizing them by handling fatal errors first, then warnings, and finally suggestions. Within the same priority level, follow-up questions are sorted according to their dependencies, and those that can be processed in batches are identified and organized into a list format. User response parsing and IR dynamic updates: Update the IR instance based on the response content; for supplementary information responses, extract information and populate the corresponding fields in the IR; for selected solution responses, perform the corresponding repair operation; after the IR update is completed, increment the version number to record the change log of this update.

[0012] In a preferred embodiment, step S6, which uses a parameterized template for component retrieval and simulation topology generation, includes: The system retrieves matching components from a pre-built standardized flight control component library and automatically assembles the simulation topology. The component library adopts a parametric template architecture, where each component is defined as a template class rather than a fixed instance. The system matches dynamic templates based on the aircraft description domain of the IR, matches sensor templates based on the sensor list domain, matches actuator templates based on the actuator list domain, and matches control law templates based on the control law domain. The matching process uses type matching and semantic similarity calculation. After a successful match, the system extracts parameters from the IR to instantiate templates. The topology generation module automatically connects components based on the IR relation triplet and the data flow definition of the control law domain, establishing a closed-loop topology from dynamic output position, attitude, and velocity to sensor input, sensor output measurement value to controller input, controller output command to actuator input, actuator output momentum to dynamic input. At the same time, it generates an interface mapping table to record the source component port, target component port, signal type, unit sampling rate, and required conversion operations for each connection.

[0013] In a preferred embodiment, the simulation asset generation and closed-loop verification using a parallel generation and intelligent repair strategy in S7 includes: Multimodal simulation assets are generated in parallel. Component code, parameter files, scene configuration files, automated test scripts, and machine-readable acceptance assertion files are generated in parallel based on the topology and IR configuration. All generated assets are embedded with IR version number references to ensure traceability. Consistency verification and simulation execution: Before simulation, static checks are performed on the generated assets, including interface type matching verification, global unit system unified verification, coordinate system transformation chain verification, sampling rate synchronization verification, and so on. After the verification is passed, the compilation and building module calls the compiler to generate an executable simulation program package. The simulation execution module selects the software-in-the-loop or hardware-in-the-loop simulation architecture according to the test requirements, loads the scenario configuration file, starts the simulation engine, and executes the simulation according to the process defined in the test script. During the simulation, key signal data is collected in real time according to the monitoring signal list defined in the IR test assertion domain and stored in the log file.

[0014] In a preferred embodiment, S7 further includes automated judgment and intelligent failure tracing, as well as intelligent repair decision-making and closed-loop iteration: Automated judgment and intelligent failure tracing: The automatic judgment module loads the assertion file and performs assertion evaluation one by one. For each assertion, it extracts the data segment of the corresponding monitoring signal within a specified time window from the log, performs calculations according to the evaluation index type defined by the assertion, and compares the calculated actual index value with the qualified threshold defined by the assertion. When an assertion failure is detected, the failure tracing module uses a pre-built multi-level reverse mapping network to locate the surface assertion failure phenomenon layer by layer back to the deep root cause. Intelligent repair decision-making and closed-loop iteration adopt a dual-track repair strategy based on root cause classification. For consistent root causes, the rule-based automatic repair engine is called to directly correct the IR or generate assets. For the root cause repair module of the demand layer, highly targeted intelligent follow-up questions are generated. After each repair, the system automatically increments the IR version number to record the repair history and triggers a new round of slot verification component to retrieve assets, generate consistency verification simulation, and execute automatic judgment loop.

[0015] In a preferred embodiment, a flight control simulation test system based on voice interaction and demand alignment is used to perform the steps in the aforementioned flight control simulation test method based on voice interaction and demand alignment, including: The voice request acquisition module is used to acquire user voice requests and uses endpoint detection and domain terminology normalization to obtain structured text. The semantic parsing module receives structured text, performs semantic parsing using intent recognition and entity relation extraction, and obtains semantic parsing results containing explicit constraints. The IR construction module receives semantic parsing results and uses slot template mapping and versioning management to obtain an intermediate representation IR instance for structured requirements. The slot verification module receives IR instances, uses a multi-dimensional rule engine to verify slot integrity and logical consistency, and generates a verification report. The interactive completion module receives the verification report and IR instance, and uses voice prompts to guide intelligent interactive completion, resulting in a complete and consistent IR instance. The component retrieval and topology generation module receives a complete and consistent IR instance, uses a parameterized template to perform component retrieval and simulation topology generation, and obtains a topology structure and interface mapping table. The asset generation and closed-loop verification module receives the topology and interface mapping table and IR instance, and uses parallel generation and intelligent repair strategies to generate and verify simulated assets, resulting in an executable simulation program and test report.

[0016] The beneficial effects of this invention are as follows: By leveraging voice interaction and natural language processing technologies, the system achieves automatic conversion of user voice requirements into intermediate representations (IRs) of structured requirements. Employing techniques such as endpoint detection, domain terminology normalization, intent recognition, entity relation extraction, and implicit constraint explicitization, the system accurately transforms natural language requirements into machine-understandable structured representations. This reduces the professional skill requirements for testers and improves the convenience and accuracy of requirement description. By employing technologies such as multi-dimensional rule engine verification, intelligent interactive completion, parameterized template component retrieval, automated topology generation, and intelligent repair closed-loop iteration, the system achieves fully automated generation and verification from structured requirements to executable simulation programs, ensuring consistency between requirements and implementation. When tests fail, the system can automatically trace and locate the root cause and perform intelligent repair, forming a closed-loop self-healing process for requirement design, implementation, and verification, which significantly improves the efficiency and reliability of flight control simulation testing. Attached Figure Description

[0017] Figure 1 This is a flowchart of a flight control simulation test method based on voice interaction and demand alignment according to the present invention; Figure 2 This is a block diagram of a flight control simulation test system based on voice interaction and demand alignment according to the present invention. Detailed Implementation

[0018] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0019] At least one embodiment of the present invention discloses a flight control simulation test method based on voice interaction and demand alignment, such as... Figure 1As shown, it includes: S1: Obtain user voice requirements, and use endpoint detection and domain terminology normalization to obtain structured text; The input for this step is the flight control simulation test requirements described by the user through a microphone or voice input device. The requirements include the type of aircraft, such as vertical takeoff and landing fixed wing or quadcopter; the flight modes, such as hovering, cruise, and transition; the test conditions, such as normal flight boundary conditions and extreme disturbances; the fault injection, such as sensor failure, actuator saturation, and communication interruption; and the acceptance criteria, such as attitude tracking error, altitude holding accuracy, and response time.

[0020] S11: Speech endpoint detection and noise reduction preprocessing based on dual-threshold energy detection; The voice acquisition module acquires audio signals in real time, with a sampling rate set to 16 kHz to cover the speech frequency band. The acquired raw audio signal is processed by a pre-emphasis filter, which is a first-order high-pass filter. The high-frequency enhancement coefficient is typically set between 0.95 and 0.97 to compensate for energy attenuation in the high-frequency band of the speech signal and enhance clarity. The pre-emphasized signal is then processed into frames, with a frame length of 25 milliseconds and a frame shift of 10 milliseconds. A Hamming window function is used to window each frame to reduce spectral leakage. Short-time energy and short-time zero-crossing rate are calculated for each frame. Short-time energy reflects the signal amplitude, while short-time zero-crossing rate reflects the signal frequency characteristics. Endpoint detection employs a dual-threshold decision strategy, setting a high-energy threshold, a low-energy threshold, and a zero-crossing rate threshold. When the short-time energy of a frame exceeds the high-energy threshold and the short-time zero-crossing rate is within a reasonable range, it is determined as the start of speech. When the short-time energy of several consecutive frames is below the low-energy threshold, it is determined as the end of speech. This dual-threshold strategy ensures accurate detection of speech starts while avoiding misjudging soft or weak segments as silence. The detected speech segment signal undergoes noise suppression processing using spectral subtraction. First, the noise power spectrum is estimated in the silent segment before the speech start. Then, the noise power spectrum is subtracted from the power spectrum of each frame of the speech segment. After subtraction, negative values ​​are corrected to small positive values ​​close to zero or controlled using an over-subtraction factor and spectral bottom limit. The denoised speech signal serves as the input for subsequent recognition. The purpose of endpoint detection and noise reduction is to extract clean speech signal segments, remove silence and background noise interference, and improve the accuracy of subsequent recognition.

[0021] S12: Speech-to-text conversion based on the fusion of acoustic and language models; The denoised speech signal is input into the speech recognition engine for acoustic feature extraction and decoding. In the feature extraction stage, Mel-frequency cepstral coefficients (MFCC) feature extraction is performed on each frame of the signal. First, a Fast Fourier Transform (FFT) is performed on the windowed time-domain signal to obtain the spectrum. Then, the spectrum is passed through a Mel filter bank, which contains several triangular filters whose center frequencies are distributed according to the Mel scale. The Mel scale simulates the human ear's perception characteristics of different frequencies. The logarithmic energy of each filter output is calculated, and a Discrete Cosine Transform (DCT) is performed on the logarithmic energy to obtain the MFCC coefficients. Typically, 12 to 13-dimensional MFCC coefficients are extracted, and the first-order and second-order difference coefficients are calculated to reflect the dynamic changes of the features, ultimately forming a 39-dimensional feature vector. The extracted feature sequence is input into the acoustic model for frame-level phoneme recognition. The acoustic model uses a deep neural network acoustic model, such as an end-to-end model based on a Long Short-Term Memory (LSTM) network or a Transformer architecture. The model is pre-trained on a large-scale Chinese speech dataset to obtain general acoustic modeling capabilities. In the decoding stage, the phoneme probability sequence output by the acoustic model is combined with the language model to search for word sequences. The language model adopts an N-gram grammar model or a neural network-based language model, trained on general Chinese corpora and flight control-specific corpora. The flight control-specific corpora contains contextual co-occurrence patterns of professional terms such as flight mode names, sensor models, fault types, and control parameters. The decoder uses a beam search algorithm to search for the optimal word sequence under a weighted scoring criterion of acoustic and language scores. The beam width is set to a certain value to balance decoding speed and accuracy. The candidate word sequence output by decoding is the preliminary text transcription result.

[0022] S13: Error correction and normalization of professional terms based on domain terminology database; The initial transcribed text may contain misidentifications of flight control terminology, such as misidentifying hover mode as suspension mode, IMU gyroscope as IMU gyroscope, and Dryden turbulence model as Dryden turbulence model. These misidentifications stem from insufficient training of general speech recognition models with specialized terminology. To improve the accuracy of terminology recognition, the system pre-installs a flight control terminology database. This database is stored in a structured manner, including standard term names (e.g., hover mode), term categories (e.g., flight mode, sensor, fault), a list of synonyms (e.g., hover, hovering flight, stationary hovering), common misidentification forms (e.g., suspension mode, hovering mode), and the English abbreviations and full names of the terms (e.g., IMU, Inertial Measurement Unit). The terminology correction module scans the initial transcribed text word by word, calculating the edit distance (e.g., Levenshtein distance) between each word and other terms in the terminology database. The edit distance reflects the minimum number of steps required to transform two strings through insertion, deletion, and replacement operations. If the edit distance between a word and a term is less than a preset threshold (e.g., 2-3) and the word does not appear in a general dictionary, it is determined to be a misidentified form of the term and replaced with its standard name. For English abbreviations, the system detects uppercase letter sequences in the text, queries the terminology database to match the corresponding full English name and Chinese name, and annotates the text (e.g., labeling IMU as IMU inertial measurement unit) for subsequent semantic understanding. Normalization also includes standardizing numerical units, such as normalizing 10 meters per second, 10 m / s, and 10 meters per second to the standard form 10 meters per second, and unifying 5 degrees and 5 degrees to 5 degrees. After terminology correction and normalization, a structured text is obtained, with all technical terms expressed in a standardized manner, providing reliable input for subsequent semantic analysis.

[0023] Furthermore, due to the prevalence of multilingualism in flight control, such as mixed Chinese and English expressions, traditional terminology matching methods may not be effective in handling semantically equivalent but diverse expressions. Therefore, a terminology normalization method based on semantic embedding can be adopted to improve the robustness of cross-lingual and multi-expression terminology recognition. Specifically, a pre-trained multilingual semantic embedding model, such as multilingual BERT or a cross-lingual sentence encoder, is first used to map each word or phrase in the initial transcribed text to a high-dimensional semantic vector space. Simultaneously, all standard terms and their synonym variants in the terminology database are also mapped to the same semantic space. For each candidate term in the text, the cosine similarity between its semantic vector and the vectors of each standard term in the terminology database is calculated. If the similarity exceeds a preset threshold, such as 0.85 to 0.9, the candidate term is determined to be semantically equivalent to the standard term and is replaced with the standard term. This semantic embedding-based method does not rely on literal edit distance and can identify terms with significant differences in expression but the same semantics, such as hovering, stationary hovering, and hovering. All modes can be mapped to standard term hovering modes. In addition, for new sensors or new terms not included in the terminology database, the system calculates the similarity between them and the known term category center vectors. If the similarity with a certain category center is high, it is inferred that the term may belong to that category, and the system confirms this with the user in the subsequent interactive completion step. The semantic embedding method enhances the generalization ability of terminology normalization, enabling the system to adapt to the constantly evolving flight control technology terminology.

[0024] This step outputs structured text after endpoint detection, noise reduction, error correction, and normalization. All flight control terminology in the text uses standardized expressions to provide reliable input for subsequent semantic parsing.

[0025] S2 receives structured text, performs semantic parsing using intent recognition and entity relation extraction, and obtains semantic parsing results containing explicit constraints. S21: Test type identification based on intent classification model; The semantic understanding module first performs intent recognition on the input text to determine the type of test requested by the user. Test types are categorized as follows: normal operating condition tests verifying the flight control system's performance under standard flight profiles; boundary condition tests verifying the system's performance at flight envelope boundaries such as maximum speed, minimum speed, maximum attitude angle, and extreme wind speed; fault injection tests verifying the system's fault tolerance and reconstruction capabilities against sensor, actuator, and communication faults; performance benchmark tests quantifying performance indicators such as response time, overshoot, and steady-state error; and combined scenario tests simultaneously examining the coupling effects of multiple operating conditions and faults. Intent recognition employs a text classification model, fine-tuned on a pre-trained language model such as BERT on a labeled dataset in the flight control domain. This labeled dataset contains thousands of historical test request texts and their corresponding test type labels. After the text input to the model undergoes word embedding encoding and attention mechanism processing, the probability distribution of each test type is output through the classification layer, and the type with the highest probability is selected as the recognition result. For complex requirements containing multiple test intents, such as testing hovering-to-cruise transitions and injecting IMU faults, the system identifies it as a combined scenario test type and simultaneously labels the involved subtypes, such as mode switching tests and fault injection tests.

[0026] S22: Named entity recognition and attribute extraction based on sequence labeling; After intent recognition is completed, the system performs a Named Entity Recognition (NER) task to extract key entities and their attributes from the text. Entity types include aircraft entities such as vertical takeoff and landing fixed-wing UAVs, sensor entities such as nine-axis IMUs, barometers, and differential GPS, actuator entities such as rotor motors and fixed-wing control surfaces, controller entities such as attitude PID controllers and altitude hold controllers, scene entities such as a level 10 gust of wind and an initial hovering altitude of 50 meters, fault entities such as gyroscope drift and GPS signal loss, and performance indicator entities such as pitch overshoot and roll tracking error. Entity recognition uses a sequence labeling model based on a Conditional Random Field (CRF) or bidirectional LSTM-CRF architecture, trained on labeled corpora in the flight control domain. The model labels each word in the input text with an entity tag, using the BIO labeling system: B indicates the start of an entity, I indicates the interior of an entity, and O indicates a non-entity. For example, the nine-axis IMU gyroscope is labeled as B-sensor I-sensor I-sensor. After identifying entities, the system further extracts entity attributes, including numerical attributes such as initial height of 50 meters and wind speed of 15 meters per second, type attributes such as sensor type (9-axis IMU), and state attributes such as fault mode (gyroscope drift). Attribute extraction employs a combination of dependency parsing and pattern matching. Dependency parsing identifies grammatical dependencies between entity words and modifiers, such as noun-head relationships and quantitative relationships. Pattern matching defines domain-specific attribute extraction rules, such as entity name + value + unit pattern for extracting numerical attributes, and entity name + type word pattern for extracting type attributes. The extraction results are stored in a structured format; for example, the aircraft entity includes the type "vertical takeoff and landing fixed wing," the sensor entity IMU includes the type "9-axis" with a sampling rate of 200Hz, and the fault entity "gyroscope drift" includes an injection time of 10 seconds and a duration of 5 seconds.

[0027] S23: Entity relation reasoning based on dependency syntax trees; After entity recognition, the system infers the connection and interaction relationships between entities. Relationship types include installation relationships (e.g., sensors are installed at specific locations on the aircraft), data flow relationships (e.g., sensor output data flows to the controller), control relationships (e.g., the controller outputs control commands to drive actuators), influence relationships (e.g., wind field disturbances affect the aircraft's attitude), and constraint relationships (e.g., acceptance criteria constrain the range of a signal's value). Relationship extraction employs a combination of rule matching based on dependency parsing trees and a relation classification model. The system first performs dependency parsing on the text, constructing a dependency relationship tree between words. Dependency relationships, such as subject-verb, verb-object, and attributive-head relationships, reflect the grammatical roles of words in a sentence. Extraction rules are defined for specific relation patterns, such as the pattern "sensor entity + installed at + location word" extracting installation relationships, and the pattern "entity A + output + data + to + entity B" extracting data flow relationships. For complex relationships, a relation classification model is used. The model input consists of entity pairs and their context text, and the output is a probability distribution of relation types. The model is fine-tuned on a pre-trained language model on a relation-labeled dataset. The extracted relationships are stored in the form of triples, such as: sensor IMU - installed at - center of the aircraft body, sensor IMU - data flow to - attitude controller, controller attitude PID - control - actuator control surfaces. The relationship triples form an entity relationship graph, reflecting the topological connections and interaction logic of each component of the simulation system, providing a blueprint for the subsequent generation of the simulation model topology.

[0028] S24: Constraint extraction based on sequential logic expression parsing; User requirements often include time window constraints, logical condition constraints, and acceptance criterion constraints. These constraints define the timing logic and judgment criteria for simulation execution. Time window constraints specify the effective time range of an event or assertion, such as a pitch tracking error of less than 2 degrees within 10 to 15 seconds. Logical condition constraints specify the preconditions for triggering an operation, such as switching to cruise mode when the altitude is greater than 50 meters. Acceptance criterion constraints define the acceptable thresholds for performance indicators, such as mode switching time not exceeding 3 seconds and overshoot less than 5 degrees. Constraint extraction uses a combination of pattern matching and semantic role labeling. For time window constraints, the system identifies time prepositional phrases such as "within X to Y," "starting from X seconds," and "lasting Z seconds," extracting the start and end times or duration, parsing time units such as seconds and minutes, and converting them into a unified numerical representation such as seconds. For logical condition constraints, the system identifies conditional conjunctions such as "when," "if," and "once," extracting conditional expressions such as "altitude greater than 50 meters," parsing variables in the condition such as height, comparison operators such as "greater than," and thresholds such as 50 meters, constructing a formal logical expression such as "height > 50 AND unit = meter." For acceptance criteria constraints, the system identifies performance metrics such as overshoot, response time, and tracking error, extracts acceptable thresholds such as less than 5 degrees and not exceeding 3 seconds, parses comparison relationships such as less than, equal to, and greater than, and determines whether it is an absolute value constraint such as the absolute value of the error being less than 2 degrees. The extracted constraints are stored in a structured format, such as a time window object containing a start time of 10 seconds and an end time of 15 seconds, a logical condition object containing variable names, altitude operators, and thresholds greater than 50 meters, and an acceptance criterion object containing the metric name, pitch angle, overshoot comparison relationship, less than the threshold of 5 degrees, effective time window, and mode switching phase.

[0029] S25: Explicit completion of implicit constraints based on domain knowledge base; Users' natural language requirements often contain a large number of implicit technical constraints. These constraints are common sense for domain experts, but for automated systems, they need to be explicitly defined to correctly generate simulation assets. Implicit constraints include the technical specifications behind the terms, such as the timing coordination logic of the rotor motor gradually reducing thrust while the fixed wing control surface takes over control during hovering and cruise switching; physical modeling parameters of environmental conditions, such as the need to map level 10 gusts to wind speed power spectral density parameters conforming to the Dryden or von Karman turbulence spectrum model; mathematical models of failure modes, such as the need to correlate IMU gyroscope drift with the time constant and noise intensity parameters of the first-order Markov random walk noise model; and default engineering conventions, such as the default use of the NE-G coordinate system when not explicitly specified, the default unit of angles being degrees, and the default sampling rate of the control law being 200Hz. The system has a pre-built knowledge base for the flight control domain. This knowledge base is organized in ontology form, containing abstract concepts such as flight mode and sensor concepts defined at the concept layer; domain conventions and inference rules defined at the rule layer, such as the need for coordinated rotor and fixed-wing control outputs in transition modes; and specific technical specifications and parameters stored at the instance layer, such as the wind speed and power spectral density mapping table for the Dryden turbulence model and the noise parameter ranges for common IMU models. The implicit constraint explicitness module queries the knowledge base. For identified domain terms such as "level 10 gust," it retrieves the associated physical modeling methods, such as the Dryden turbulence model, and queries the average wind speed range corresponding to level 10 gusts, such as 24.5 to 28.4 meters per second, as well as recommended turbulence intensity parameters. These parameters are then added to the scene entities as explicit supplementary information. For identified flight mode transitions, such as hovering to cruise, the implicit control timing logic is retrieved, such as the rotor thrust linearly decreasing to zero in 2 seconds while the fixed-wing control surfaces deflect from zero to cruise trim angle and the airspeed accelerating from zero to cruise speed. These timing steps are explicitly defined as sub-scene events. For fault modes, such as gyro drift, the mathematical model type is retrieved, such as a first-order Markov process. Recommended model parameters, such as a correlation time constant of 100 seconds, noise intensity of 0.001 degrees per second, and √4 Hz, are used as the model configuration for the fault entity. For unspecified engineering conventions, the system completes them according to default rules, such as the coordinate system being completed by default as NE-GD navigation system and machine system, the unit system being completed by default as SI units as length in meters, speed in meters per second, and angle in radians, and the sampling rate being completed by default according to the control law type, such as 200Hz for attitude control and 50Hz for position control.

[0030] Furthermore, since the explicit completion of implicit constraints relies on the completeness of the knowledge base, and flight control technology is constantly evolving, new sensors, control methods, or fault modes may emerge that are not covered by the knowledge base, a dynamic knowledge base expansion mechanism based on case-based reasoning can be adopted. The aim is to fill knowledge gaps and continuously accumulate domain knowledge during runtime. Specifically, when the system does not find the associated technical specifications for a certain term in the knowledge base, such as when a user describes a new type of lidar but the knowledge base only includes common ultrasonic and millimeter-wave lidar, the system marks the term as a missing knowledge item. In subsequent interactive completion steps, targeted follow-up questions are generated, such as: "If the system detects a new type of lidar not in the knowledge base, please describe its measurement principle (e.g., time-of-flight ranging or phase ranging), output data format (e.g., point cloud or distance value), interface protocol (e.g., serial port or CAN bus), and typical measurement accuracy." With varying update frequencies, users supplement information via voice or text replies. The system parses the replies to extract key attributes such as measurement principle (time-of-flight ranging), output format (distance value), interface (serial port), update frequency (20Hz), and accuracy (±0.1 meters). These attributes are stored as structured entries in a temporary extension area of ​​the knowledge base. Each entry includes a term name, new type of lidar term category, sensor type, attribute list, measurement principle, output format, interface protocol, update frequency, accuracy source, current IR instance ID, and confidence level explicitly provided by the user. The system also records the frequency of use of each extension entry. When the same or similar new terms appear repeatedly in multiple interactions, the system prompts domain experts for review and incorporates high-frequency extension entries into the standard knowledge base. Through case-based reasoning and dynamic expansion mechanisms, the system can adapt to evolving flight control technologies and continuously improve its ability to explicitly cover implicit constraints.

[0031] This step outputs semantic parsing results containing the test intent entity set and its attribute relationship triple graph, timing and logical constraint table, and explicit implicit constraints. These results are organized in the form of structured data objects, providing complete semantic information for subsequent IR construction.

[0032] S3 receives the semantic parsing results, uses slot template mapping and version management to obtain the structured requirement intermediate representation (IR) instance; S31: Predefined hierarchical IR template structure design; The Intermediate Representation (IR) for flight control simulation requirements is defined using a hierarchical structured format and stored in JSON or YAML format for easy machine parsing and version management. The IR template contains the following core fields: the first layer is the Meta field, which records the unique identifier (UUID) of the IR instance, version number, timestamp, and the path to the original audio file associated with the user. The second layer is the Vehicle field, which includes aircraft type identification (e.g., fixed-wing rotor vertical takeoff and landing), mass parameters (e.g., empty mass, full load mass), inertial parameters (e.g., rotational inertia tensors Ixx, Iyy, Izz, Ixy, Ixz, Iyz), aerodynamic model references (e.g., aerodynamic coefficient table file path or aerodynamic model type), propulsion model references (e.g., propeller model parameters or turbojet engine model), body coordinate system definition (e.g., origin position, coordinate axis direction), and global physical unit system (e.g., length unit meter, mass unit kilogram, time unit second, angle unit radian). The third layer is the Sensors list field, which stores each sensor object in array form. Each sensor object contains a sensor ID (string type, globally unique identifier), sensor type (enumerated string type, values ​​such as IMU_9AXIS, BAROMETER, GNSS, etc.), installation location (a three-dimensional floating-point array [x,y,z] in the body coordinate system, in meters), alignment matrix (a 3×3 orthogonal rotation matrix R from the sensor coordinate system to the body coordinate system, satisfying R^T·R=I and det(R)=+1, defaulting to an identity matrix if not specified), sampling frequency (positive integer type, in Hz), and noise model parameters (including white noise). Noise power spectral density (gyroscope unit: (° / h) / √Hz, accelerometer unit: μg / √Hz, barometer unit: Pa / √Hz); and first-order Markov noise time constant (unit: seconds, used in pairs with corresponding noise intensity); bias parameters (including zero bias and temperature drift coefficients, units are the same as sensor output dimensions); fault mode configuration (array type, supports multiple fault modes, each fault mode includes fault type such as GYRO_DRIFT, ACCEL_BIAS, SIGNAL_LOSS, etc., injection trigger time (unit: seconds), duration (unit: seconds), and fault amplitude (unit: same as sensor output dimensions)). The fourth layer is the Actuators list field, which stores each executor object in array form. Each executor object contains the executor ID (string type, globally unique identifier), executor type (enumerated string type, values ​​such as SERVO, MOTOR, THROTLE, etc.), saturation limit (including maximum and minimum values, servo units are degrees, motor units are rpm), dead zone size (floating-point type, unit is the same as saturation limit), rate limit (floating-point type, servo units are degrees / second, motor units are rpm / second), first-order delay time constant (floating-point type, unit is seconds), and fault injection configuration (array type, each fault object contains fault type such as STUCK, SATURATION, RESPONSE_DELAY, injection trigger time (unit is seconds), duration (unit is seconds), and fault parameters (for jamming, the jamming position value; for response delay, the additional delay time constant, unit is seconds)). The fifth layer is the Control domain, which includes the set of available modes (a string array enumerating all available flight mode names such as HOVER, TRANSITION, CRUISE), the controller configuration for each mode (including controller structure types such as CASCADE_PID, SINGLE_PID, LQR, controller parameters such as proportional gain Kp, integral gain Ki, and derivative gain Kd are all floating-point numbers, derivative filter coefficients N, feedforward gain Kff, and controller sampling rate in Hz), and mode switching logic (each switching rule includes source mode, target mode, trigger condition using formal logical expressions such as "airspeed > 15.0 AND altitude > 30.0", and switching timing coordination steps). The sixth layer is the simulation scenario domain, which includes the initial state (including initial position in latitude, longitude, and altitude format or NED coordinate system xyz format in meters; initial attitude in Euler angle format in degrees or quaternion format; initial velocity in meters per second; each field must indicate the coordinate system type used) and environmental conditions (including wind field model type such as DRYDEN or VON_KARMAN; average wind speed in meters per second; turbulence intensity level such as LIGHT / MODERATE / SEVERE; atmospheric density in kg / m³). 3The following are the parameters: atmospheric temperature (in degrees Celsius, atmospheric pressure (in Pa)); mission profile (an array of waypoints, each waypoint containing coordinates, desired speed in meters per second, desired altitude in meters, and arrival position tolerance in meters); stage events (each event containing an event name, trigger time in seconds, event type such as TAKEOFF / MODE_SWITCH / LANDING); and fault injection list (each fault item contains a fault object ID that must match the ID in Sensors or Actuators, fault type, injection trigger conditions supporting both time-based triggers in seconds or logical expressions, duration in seconds, and fault parameter units that are the same as the output units of the corresponding components). The seventh layer is the Tests assertion domain, which stores acceptance assertion objects in array form. Each assertion includes an assertion ID (string type, globally unique identifier), a monitoring signal path (using a point-to-level path format such as "Control.attitude_pid.output.pitch_cmd", and the names of each level must be consistent with the component ID and port name in the IR), an evaluation metric type (enumerated string type, with values ​​such as MAX_VALUE, MIN_VALUE, OVERSHOOT, RISE_TIME, SETTLING_TIME, STEADY_STATE_ERROR, etc.), a pass / fail threshold (including upper or lower bounds or equality constraints, with the same unit as the monitoring signal), an effective time window (including start and end times in seconds, or a trigger condition specified by a logical expression), and an assertion priority (enumerated string type, with values ​​of CRITICAL, MAJOR, MINOR).

[0033] Each field in the IR template is labeled with attribute metadata, including whether the field is required (e.g., aircraft mass is required, sensor bias parameters are optional), the field data type (e.g., numeric, string, array, object), the field value range (e.g., mass must be positive, angle range is -180 to 180 degrees), the field default value (if not specified, the default configuration is used), and the field dependencies (e.g., if the Dryden turbulence model is selected, wind speed and turbulence intensity parameters must be provided).

[0034] S32: Mapping and filling of semantic parsing results to IR slots; The IR construction module maps the semantic parsing results output in step S2 to the various field slots of the IR template. The mapping process employs a strategy combining rule-driven and semantic matching. For the metadata domain, the system automatically generates a UUID as a unique identifier for the IR instance, records the current timestamp, obtains user identity information, associates the original voice file path, and initializes the version number to 1.0. For the aircraft description domain, the aircraft type identifier is extracted from the aircraft entity in the semantic parsing results, and the standard mass and inertial parameters of the aircraft type are obtained by querying the aircraft database. If no match is found in the database, it is marked as needing completion. The aerodynamic and propulsion model references are automatically associated with the standard model library path based on the aircraft type, and the body coordinate system and unit system use the default configuration. For the sensor list domain, the sensor entities in the semantic parsing results are traversed, and an IR sensor object is created for each sensor. The sensor ID is automatically generated, the sensor type is obtained from the entity type attribute, and the installation location is extracted from the entity attribute or relation triple. For example, if the IMU is installed at the center of the body, it is mapped to xyz coordinates 0, 0, 0. The alignment matrix defaults to the identity matrix if not explicitly specified. The sampling frequency is obtained from the entity attribute or a default value is queried based on the sensor type. For example, the default is 200Hz for IMU and 10Hz for GNSS. The noise model parameters are obtained from the entity attribute or queried from the sensor model database. The fault mode configuration is extracted from the fault entity, including fault type, injection time, and duration, and mapped to the corresponding fields. For the actuator list domain, the mapping process is similar to that for the sensors. Parameters such as type, saturation limit, rate limit, and delay are extracted from the actuator entity. For the control law domain, the control mode and controller type are extracted from the controller entity in the semantic parsing results. PID parameters are extracted from the entity attributes. If the parameters are not explicitly specified, they are marked as pending completion. The mode switching logic is inferred from relation triples and logical constraints. For example, when the altitude is greater than 50 meters, the switch to cruise mode is mapped to the switching condition: height > 50m. The target mode is cruise. For the simulation scenario domain, initial state parameters are extracted from scenario entities, such as an initial hovering height of 50 meters mapped to an initial position height of 50 meters, an initial velocity of zero, and an initial attitude of horizontal. Environmental conditions are obtained from scenario entity attributes, such as a level 10 gust mapped to a wind field model with a dry wind speed of 25 meters per second and moderate turbulence. The mission profile is extracted from time-series constraints, including waypoints and stage events. The fault injection list is extracted from fault entities and associated with sensor or actuator IDs. For the test assertion domain, assertion information is extracted from acceptance criterion constraints, and assertion IDs are automatically generated. The monitoring signal path is inferred from performance index terms in the constraints, such as pitch angle overshoot inferred to the pitch angle output of the monitoring signal attitude estimation. The evaluation index type is overshoot. The pass threshold is extracted from thresholds in the constraints, such as less than 5 degrees mapped to an upper bound of 5 degrees. The effective time window is extracted from time window constraints, such as during mode switching, mapped to the start time, mode switching trigger time, end time, and stabilization time after switching is completed.During the mapping process, a confidence score is recorded for each filled field. The confidence score is determined based on the information source. If the information is directly extracted from the user's explicit statement, such as an initial height of 50 meters, the confidence score is 1.0. If the information is obtained through inference or querying default values, such as a default IMU sampling rate of 200Hz, the confidence score is 0.8. If the information is obtained through fuzzy matching or hypothesis completion, such as a wind field model that assumes Dryden, the confidence score is 0.5. The confidence score is used in subsequent slot verification to determine whether user confirmation is required.

[0035] S33: Versioning and serialization storage of IR instances; After the mapping is completed, an initial IR instance object is generated. The system manages IR instances using versioning, with version numbers in a semantic versioning format such as major version number.minor version number.revision number, and the initial version number is 1.0.0. IR instances are serialized into JSON format files, with the file name including the IR's UUID and version number, such as IR_UUID12345_v1.0.0.json. These files are stored in a version control repository, such as a Git repository. Each time the IR is updated, the version number is incremented and a new version is committed, preserving a complete version history for easy tracking and rollback. Metadata annotations are embedded in the IR file, with each field accompanied by annotations explaining its meaning, data source, confidence level, and the associated original voice segment timestamp. For example, the annotation for a PID parameter field might be: source user voice timestamp 00:35, original pitch, PID proportional gain set to 0.5, confidence level 1.0. Versioning ensures the traceability of requirement changes. When a user modifies the requirement in subsequent interactions, such as adjusting the pitch PID gain from 0.5 to 0.8, the system loads the current IR version, updates the corresponding field values, increments the version number to 1.0.1, submits the new version, and records the reason for the change and the time in the comments. All downstream generated simulation assets are embedded with the IR version number reference to ensure the accurate correspondence between the assets and the requirement version.

[0036] This step outputs a versioned, structured flight control simulation requirement intermediate representation, the IR instance. The IR instance is stored in JSON format and contains complete aircraft sensor actuator control law scenarios and test assertion configurations. Each field is labeled with confidence level and data source. The IR instance serves as the sole data source and true benchmark for all subsequent processes.

[0037] S4 receives the IR instance, uses a multi-dimensional rule engine to verify slot integrity and logical consistency, and obtains a verification report. S41: Integrity check of required fields; The slot verification module first performs a mandatory field integrity check to ensure that all fields marked as mandatory in the IR instance are filled and the confidence level reaches the preset threshold. The system iterates through the IR template definition, extracting a list of all mandatory fields, such as aircraft mass, aircraft inertia, sensor type, sensor sampling rate, controller type, controller parameters, scenario, initial state, test assertions, and monitoring signals. Then, it iterates through the current IR instance, checking each mandatory field for non-empty values. If a mandatory field is missing or has an empty value, the system records the complete path of that field, such as IR.Vehicle.mass (field description, aircraft mass, error type, fatal error, missing mandatory field). If a field is filled but the confidence level is below the threshold (e.g., confidence level 0.5, lower than the required 0.8), the system records a warning: insufficient confidence level for the mandatory field, and suggests the user confirm. For array-type mandatory fields, such as sensor lists containing at least one sensor object, the system checks if the array length is greater than zero. For composite object-type mandatory fields, such as controller objects requiring controller type and parameter subfields, the system recursively checks the mandatory subfields within the object. After the inspection is completed, a required field inspection report is generated. The report includes a list of missing fields, each containing the field path description and error type, and a list of low-confidence fields, each containing the field path, current confidence level, and suggested confirmation content.

[0038] S42: Verification of the rationality and value range of physical parameters; The verification module checks the rationality of the physical parameters in the IR to ensure that the parameter values ​​conform to physical laws and common engineering knowledge. The checks include: positive constraints on mass and inertia, verifying that the aircraft mass is greater than zero; that the diagonal elements Ixx, Iyy, and Izz of the moment of inertia tensor are all greater than zero and satisfy the triangle inequality (e.g., Ixx + Iyy > Izz); angular range constraints, verifying that Euler angles are within the range of -180 to 180 degrees or 0 to 360 degrees; quaternions satisfying the normalization constraint (i.e., the sum of the squares of the quaternion components is 1); physical reachability constraints on velocity and acceleration, verifying that the initial velocity does not exceed the aircraft's maximum velocity; actuator rate limits not exceeding the hardware physical limits; reasonableness constraints on sampling frequency, verifying that sensor sampling frequencies are within typical ranges (e.g., IMU typically 50 to 1000 Hz, GPS typically 1 to 20 Hz, control law sampling rates typically 50 to 500 Hz); stability constraints on PID parameters, verifying that the proportional gain, integral gain, and derivative gain are all non-negative, and that the parameters estimated based on the time constant of the controlled object are within the stability margin range; and non-negativity constraints on time parameters, verifying that the simulation duration and fault injection duration are all non-negative, and that the start time of the time window is less than the end time. For each parameter, the system queries a pre-defined parameter rationality rule base. This rule base defines recommended ranges and hard constraints for each type of parameter. For example, the recommended range for the mass of a fixed-wing aircraft is 1 to 50 kg, with a hard constraint greater than 0. The recommended range for IMU gyroscope noise is 0.0001 to 0.01 degrees per second per ohm hertz; exceeding this range may not conform to actual sensor performance. If a parameter violates a hard constraint, it is recorded as a fatal error (parameter exceeding physically feasible range). If a parameter exceeds the recommended range but does not violate hard constraints, it is recorded as a warning (parameter approaching boundary, recommendation for review). After the check is completed, a parameter rationality report is generated, including a list of erroneous parameters and a list of warning parameters.

[0039] S43: Global unit system consistency check; The verification module checks whether all physical quantities in the IR use a consistent unit system. The system first extracts the global unit system definition from the IR's Vehicle domain, such as length (meters), time (seconds), angle (radians), and pressure (Pascals). Then, it iterates through all fields in the IR involving physical quantities, such as sensor installation location coordinates (meters), velocity (meters per second), attitude angle (radians), and air pressure (Pascals), checking whether the unit label of each field is consistent with the global unit system. For fields with inconsistent units, the system determines whether unit conversion is needed. If a field is labeled in knots while the global velocity unit is meters per second, the system marks the field as needing unit conversion, records the conversion factor (knot to meters per second conversion factor 0.5144), and marks the connection in the interface mapping table as needing to insert a unit conversion function. For angle units, the system specifically checks for the mixing of degrees and radians, such as initial attitude in degrees while controller calculations are in radians, marking the need for degree-to-radian conversion. For composite units, such as acceleration (meters per second) and squared angular velocity (radians per second), the system analyzes the constituent dimensions of the unit to verify consistency. For dimensionless parameters such as PID gain, the system verifies whether its definition matches the unit system of the controlled object. For example, the proportional gain of a position PID is measured in units per position of the control output. If the control output is in radians and the position is in meters, then Kp is measured in radians per meter. The system checks whether this unit definition is reasonable. After the check is completed, a unit consistency report is generated, containing a list of units inconsistent. Each item includes the field path, current unit, target unit, conversion factor, and a list of connections where conversion functions need to be inserted.

[0040] S44: Verification of the integrity and orthogonality of the coordinate system transformation chain; The verification module verifies whether the coordinate system transformation chain defined in the IR is complete and mathematically correct. Flight control simulation involves multiple coordinate systems, including the geographic coordinate system (longitude, latitude, and altitude), the geocentric-ground-fixed coordinate system (ECEF), the local navigation coordinate system (NED or ENU), the body coordinate system (FRD or FLU), and sensor coordinate systems such as the IMU coordinate system, which may have installation deviations from the body coordinate system. The system first identifies all coordinate systems involved in the IR, extracts the body coordinate system definition from the Vehicle domain, extracts each sensor coordinate system and its alignment matrix from the Sensors domain, extracts the scene coordinate system definition from the Scenario domain (e.g., initial position using the geographic coordinate system or NED coordinate system), and extracts the controller calculation coordinate system from the Control domain (e.g., attitude control in the body system and position control in the NED system). Then, the system constructs a coordinate system transformation graph, where nodes represent each coordinate system and edges represent defined transformation matrices, such as the alignment matrix from the sensor system to the body system and the attitude rotation matrix from the NED system to the body system. The system checks the connectivity of the transformation graph, verifying the existence of a transformation path between any two coordinate systems that need data exchange. If a sensor output needs to be transformed to the controller input coordinate system but the transformation path is missing, it is recorded as a fatal error: incomplete coordinate system transformation chain. For defined transformation matrices, the system verifies their mathematical correctness. Rotation matrices should satisfy orthogonality constraints, i.e., the matrix transpose equals the inverse matrix, and a determinant of +1 indicates a right-handed or left-handed coordinate system. The system calculates whether the matrix transpose multiplied by the matrix equals the identity matrix and whether the determinant is +1 or -1. If these conditions are not met, it is recorded as a fatal error: non-orthogonal transformation matrix. For composite transformations, such as from the sensor system to the NED system requiring a path from the sensor system to the machine system and then to the NED system, the system verifies whether the composite transformation matrix is ​​correctly calculated as the product of transformation matrices of each order. After the check is completed, a coordinate system consistency report is generated, including a list of missing transformation chains, a list of transformation matrix errors, and a list of transformation modules that need to be automatically inserted.

[0041] S45: Sampling rate synchronization and timing dependency consistency check; The verification module verifies the compatibility of sampling rate configurations for different components in the IR module and whether signal timing dependencies satisfy causality constraints. The system first extracts the sampling rates of all components, including the integration step size of the dynamic model (typically high-frequency, such as 1000Hz to ensure numerical stability), sensor sampling frequencies (e.g., IMU 200Hz, GPS 10Hz), control law execution frequencies (e.g., attitude control 200Hz, position control 50Hz), and actuator update frequencies (e.g., servo motor 50Hz). Then, the system constructs a data flow graph, with nodes representing components and edges representing signal connections, labeled with the signal sampling rate. The system checks the sampling rate relationship between adjacent components. If the source component's sampling rate is higher than the target component's sampling rate (e.g., 1000Hz for the dynamic model and 200Hz for the controller), the system marks it as needing downsampling and suggests inserting a downsampler or reading data at integer multiples of the input period of the target component, recording it as a suggestion to insert a downsampler to reduce the frequency from 1000Hz to 200Hz. If the sampling rate of the source component is lower than that of the target component (e.g., GPS output 10Hz to the controller 200Hz), the system marks it as needing upsampling or holding, and recommends inserting a zero-order hold or linear interpolator, recording it as "Recommended to insert a hold or interpolator to upsample from 10Hz to 200Hz". For connections where the sampling rates are not integer multiples of each other (e.g., one component is 30Hz and another is 200Hz), the system calculates the least common multiple (LCM), such as 600Hz, and recommends performing sampling rate conversion under a common time base, recording it as "Warning: Non-integer multiples of sampling rates may cause timing alignment problems". The system also checks for algebraic loops, i.e., cyclic dependencies of signals, such as component A outputting to component B, component B outputting to component C, and component C outputting back to component A, forming a closed loop within the same time step, causing causal conflicts. The system detects loops through topology sorting. If an algebraic loop is detected, it is recorded as a fatal error; a unit delay needs to be inserted, and it is recommended to insert a unit delay unit at a connection in the loop to break the instantaneous dependency. After the check is completed, a sampling rate and timing report is generated, which includes a list of sampling rate converters that need to be inserted, a list of algebraic rings, and suggested delay insertion positions.

[0042] S46: Model dependency closure completeness check; The verification module verifies that all external resources and dependencies referenced in the IR are complete and accessible. External resources include aerodynamic data table files (e.g., lookup tables for aerodynamic coefficients with angle of attack and sideslip), thrust model data files (e.g., mapping tables of propeller thrust and torque with rotational speed), terrain data files (e.g., digital elevation models, DEMs), and external library dependencies (e.g., dynamics integrator libraries, control algorithm libraries, and signal processing libraries). The system iterates through all file path references in the IR, such as aerodynamic table file paths referenced by the `Vehicle.aero_model_path` field, checking each file for existence at the specified path. If a file does not exist, it is recorded as a fatal error indicating a missing dependency file. If a file exists but its format is not as expected (e.g., an aerodynamic table should be in CSV format but is actually in text format), it is recorded as an error indicating a mismatched file format. For external library dependencies, the system checks whether the required libraries and their versions are installed in the compilation environment. For example, if the dynamics model requires a numerical integration library version 2.0 or higher, the system checks the library version; if it is not installed or the version is too low, it is recorded as a fatal error indicating a missing dependency library or version incompatibility. For interface dependencies between components, the system verifies whether each component's declared input ports have corresponding output port connections. If a component's input port is dangling and not connected, it is recorded as an error (input port not connected). If a component's output port is not used by any other component, it is recorded as a warning (output port not used, possibly indicating redundant configuration). After the check is completed, a dependency closure report is generated, including a list of missing files, missing libraries, unconnected ports, and redundant configurations.

[0043] This step outputs a comprehensive verification report, which is divided into three levels: a fatal error list containing all issues that must be fixed to prevent the generation of an executable simulation, such as missing required fields, incomplete transformation chains, missing algebraic loop dependency files, etc.; a warning list containing issues that may affect the accuracy or stability of the simulation, such as parameters approaching boundary values, non-integer multiples of sampling rates, low confidence fields, etc.; and a suggestion list containing optimization suggestions, such as cleaning up redundant configurations and recommending parameter adjustments. If the fatal error list is not empty, the verification result is marked as failed, triggering the interactive completion process. If the fatal error list is empty but the warning list is not empty, the verification result is marked as passed but requires confirmation. If all lists are empty, the verification result is marked as completely passed, and the process continues to the component retrieval step.

[0044] S5 receives the verification report and IR instance, and uses voice prompts to guide intelligent interactive completion to obtain a complete and consistent IR instance. S51: Generation of follow-up questions based on incorrect classification; If the verification report in step S4 contains fatal errors or warnings, the interactive completion module analyzes the report content and generates targeted voice follow-up questions. The system categorizes and processes errors according to their types. For errors involving missing required fields, the system generates follow-up questions describing the missing information. These questions include the field's function (e.g., aircraft mass used to calculate inertial forces in the dynamic equations), a typical value range (e.g., the mass of a fixed-wing UAV is typically between 5 and 30 kg), and asks the user to provide specific values ​​(e.g., please provide the empty mass of the UAV in kilograms), or whether to use a typical default value (e.g., if no precise data is available, a default value of 10 kg can be temporarily used and can be corrected later; confirmation is required). For errors involving unreasonable parameters, the system generates follow-up questions explaining the parameter anomalies and suggesting adjustments (e.g., if the initial airspeed is detected to be 5 m / s, lower than the minimum level flight speed of 12 m / s for this model, potentially causing stall in the initial stage of the simulation, it is recommended to adjust it to 15 m / s or higher; what value would you prefer to change it to?). For logical conflict errors, the system generates a conflict description and a follow-up question for solution selection. For example, if a sampling rate conflict is detected (control law configured at 200Hz but IMU configured at 100Hz), the following solutions are needed: Solution 1: Upsample the IMU to 200Hz using interpolation; Solution 2: Downsample the control law to 100Hz; Solution 3: Keep it unchanged but insert an interpolator at the controller input. Please select solution number one, two, or three. For unit or coordinate system inconsistencies, the system generates a conversion requirement confirmation follow-up question. For example, if the sensor outputs angular velocity in degrees per second while the controller inputs desired radians per second, the system will automatically insert a degree-to-radian conversion function. Please confirm whether to continue. For low-confidence fields, the system generates a confirmation request follow-up question. For example, if the system infers the gyroscope noise power spectral density to be 0.001 degrees per second per square Hz based on default rules (this parameter is based on empirical values), please provide the precise value if you have the sensor's datasheet; otherwise, please confirm the use of the default value.

[0045] S52: Prioritizing and organizing follow-up questions in batches; When a verification report contains multiple errors or warnings, the system prioritizes follow-up inquiries, handling fatal errors first, then warnings, and finally suggestions. Within the same priority level, inquiries are sorted according to dependency; for example, aircraft mass parameters affect the validity of inertia parameters, so mass is inquired about first, followed by inertia. The system also identifies inquiries that can be processed in batches. For example, if multiple sensors are missing noise parameters, the system organizes them into a list and inquires about the following missing noise parameter configurations for the following sensors: 1. IMU gyroscope, 2. Barometer, 3. Magnetic compass. Please provide the noise power spectral density for each sensor in sequence, or select to use typical default values ​​for all. For technical terms that users may not be familiar with, the system adds explanations in the follow-up inquiries. For example, noise power spectral density describes the frequency domain characteristics of sensor random errors; the smaller the value, the higher the sensor accuracy. The typical high-precision IMU gyroscope noise power spectral density is approximately 0.0001 to 0.001 degrees per second per square hertz.

[0046] S53: Speech synthesis and broadcasting with multimodal user response reception; The generated follow-up questions are converted into spoken audio and broadcast to the user via a speech synthesis module. The speech synthesis employs highly natural neural network speech synthesis technologies such as WaveNet or Tacotron, resulting in synthesized speech with clear rhythm and appropriate pauses, enhancing user comprehension. For follow-up questions containing numerical values ​​or technical terms, the system simultaneously displays text and options on the interface for user reference. Users can reply via either voice or text. Voice replies undergo speech recognition and text processing in step S1, while text replies are entered directly. For choice-based follow-up questions, such as "Please select option one, two, or three," the system identifies the option identifiers in the user's reply. For numerical follow-up questions, such as "Please provide quality," the system extracts the numerical value and unit from the reply, using named entity recognition technology to identify the numerical value (e.g., 15 kg is extracted as the numerical value 15 units kilograms). For confirmation-based follow-up questions, such as "Are you sure?", the system identifies affirmative or negative intent; "Yes," "Okay," and "Yes" are judged as affirmative, while "No," "No," and "Need to modify" are judged as negative.

[0047] S54: User Response Analysis and Dynamic IR Update; After parsing the user's reply, the system updates the IR instance based on the reply content. For replies providing supplementary information, the system extracts the information and populates the corresponding fields in the IR instance. For example, if the user replies that the mass is 12 kg, the system updates the IR.Vehicle.mass field to 12 kg and updates the confidence level of this field to 1.0, indicating that the data source was explicitly provided by the user. For replies indicating a selected solution, the system performs the corresponding repair operation. For example, if the user selects Solution 1 to upsample the IMU to 200Hz, the system updates the sampling rate field of the IMU object in IR.Sensors to 200Hz and marks the sampling rate in the metadata as adjusted to match the control law frequency. For confirmation replies, if the user confirms, the current configuration is maintained and the warning is marked as handled; if the user denies, the field is left as pending completion or rolled back to the point where the user provides new information. After the IR update is completed, the version number is incremented (e.g., from 1.0.0 to 1.0.1), and the change log for this update is recorded, including the changed field path, the values ​​before and after the change, the reason for the change, the user's reply content, and the timestamp.

[0048] S55: Iterate and verify until complete consistency is achieved; After each IR update, the system automatically triggers slot verification in step S4 to check if the updated IR still contains fatal errors or warnings. If the verification report still contains issues, the system generates new follow-up questions to continue the interaction. If the list of fatal errors in the verification report is empty, the system announces to the user that the required information has been completed and simulation asset generation will begin, ending the interactive completion loop. If the verification report still contains warnings but are not fatal, the system asks the user whether to confirm each warning item or continue generation directly if several warning items are detected, such as parameters approaching the boundary. If the user chooses to continue directly, the loop ends; if the user requests confirmation, follow-up questions continue. Through iterative interaction, the system ultimately obtains an IR instance with all required fields complete, parameters reasonable, units consistent, coordinate system complete, sampling rate compatible, and dependency closure complete.

[0049] S6: Receive a complete and consistent IR instance, use parameterized templates to perform component retrieval and simulation topology generation, and obtain the topology structure and interface mapping table; The input for this step is the complete IR instance output from step S5. The system retrieves matching components from a pre-built standardized flight control component library and automatically assembles the simulation topology. The component library adopts a parametric template architecture, where each component is defined as a template class rather than a fixed instance. Templates include six-DOF dynamics templates that define rigid body motion equations but use mass and inertia as parameters, aerodynamic templates that define lift and drag calculation methods but use aerodynamic coefficient tables as parameters, and sensor templates such as nine-axis IMU templates that define measurement equations and error models but use noise parameters as configuration items. The system matches dynamics templates based on the Vehicle field of the IR, sensor templates based on the Sensors field, actuator templates based on the Actuators field, and control law templates based on the Control field. The matching process uses type matching and semantic similarity calculation. When the IR specifies a vertical takeoff and landing fixed wing, it matches the VTOL dynamics template; when the IR specifies a nine-axis IMU, it matches the corresponding sensor template. After a successful match, the system extracts parameters from the IR to instantiate templates, such as instantiating a dynamics template with a mass of 12 kg and an IMU template with gyroscope noise of 0.001 degrees per second per square hertz. The topology generation module automatically connects components based on the IR relationship triplet and the data flow definition of the Control domain, establishing a closed-loop topology from dynamic output position, attitude, and velocity to sensor input; sensor output measured values ​​to controller input; controller output commands to actuator input; and actuator output momentum to dynamic input. Simultaneously, it generates an interface mapping table recording the source component port, target component port, signal type, unit sampling rate, and required transformation operations such as unit transformation, coordinate system transformation, and sampling rate synchronization for each connection.

[0050] S7 receives the topology and interface mapping table and IR instance, and uses parallel generation and intelligent repair strategies to generate simulated assets and perform closed-loop verification to obtain an executable simulation program and test report. S71: Parallel generation of multimodal simulation assets; The asset generation module generates four types of standardized simulation assets in parallel based on the topology and IR configuration. The first type consists of component code and parameter files. Based on the parameter configurations of each component in the IR, it generates directly compilable C language source code. This code includes component initialization functions (e.g., initializing the state-space equations of the dynamic model based on mass and inertia), periodic execution functions (e.g., calling the dynamic integrator, sensor measurement functions, and control law calculation functions at each simulation step), and parameter configuration files storing PID gain, sensor noise parameters, fault injection schedules, and more in JSON format. The second type is scenario configuration files. Based on the IR's Scenario field, it generates configuration files defining the initial simulation conditions, including the aircraft's initial position, attitude, and velocity; environmental parameters such as wind speed, turbulence intensity, and atmospheric density; and mission profiles such as waypoint coordinates and desired velocities. The third type is automated test scripts. These scripts control the simulation execution process, including loading scenario configurations, starting the simulation engine, setting the simulation step size and total duration, injecting fault signals according to the fault schedule defined by the IR, collecting monitoring signals specified in the Tests field of the IR, and saving data logs after the simulation ends. The fourth category is machine-readable acceptance assertion files, which convert each assertion in the Tests field of IR into a formally defined assertion object, including assertion ID, monitoring signal path evaluation index type such as overshoot, rise time, steady-state error, pass threshold, effective time window, assertion priority, and all generated assets are embedded with IR version number references to ensure traceability.

[0051] S72: Consistency verification and simulation execution; Before simulation, the consistency verification module performs static checks on the generated assets, executes interface type matching checks to verify the data type compatibility of each pair of connected source and target ports, performs global unit system uniformity checks to check whether all physical quantities use a consistent unit system, performs coordinate system transformation chain verification to verify the completeness and correctness of the coordinate transformation chain from the sensor measurement space to the controller calculation space, performs sampling rate synchronization checks to identify components with different sampling rates and automatically insert interpolators or downsampling devices to ensure signal synchronization, and checks for algebraic loops, i.e., causal conflicts caused by signal cyclic dependencies. After the verification passes, the compilation and build module calls the compiler to generate an executable simulation program package. The simulation execution module selects a software-in-the-loop or hardware-in-the-loop simulation architecture according to the test requirements, loads the scenario configuration file, starts the simulation engine, and executes the simulation according to the process defined in the test script. During the simulation, key signal data is collected in real time according to the monitoring signal list defined in the Tests field of the IR and stored in the log file.

[0052] S73: Automated judgment and intelligent failure tracing; The automatic judgment module loads the assertion file and performs assertion evaluation one by one. For each assertion, it extracts the data segment of the corresponding monitoring signal within the specified time window from the log, performs calculations according to the evaluation index type defined in the assertion, such as calculating the overshoot, rise time, and steady-state error. It compares the calculated actual index value with the qualified threshold defined in the assertion. If the actual value is within the threshold range, the assertion is marked as "passed"; otherwise, it is marked as "failed" and the deviation between the actual value and the threshold is recorded. When an assertion failure is detected, the failure tracing module uses a pre-built multi-level reverse mapping network to trace the surface assertion failure phenomenon back to the deep root cause layer by layer. The tracing network establishes a four-layer mapping relationship: the first layer maps the assertion to the monitoring signal, the second layer maps the signal to the component port, the third layer maps the component port to the internal state and parameters, and the fourth layer maps the parameters to the IR field and associates them with the original voice requirement segment. For each failed assertion, the four-layer tracing is performed to obtain a list of possible root causes. Root causes are classified as follows: requirement-level root causes, such as the user not specifying key parameters, resulting in the use of default values ​​for mismatched configurations; implementation-level root causes, such as sensor noise model parameters not matching the actual hardware; consistency-level root causes, such as the control law sampling rate not matching the actuator response delay; and environmental root causes, such as wind field disturbance intensity exceeding the controller design envelope. The tracing module sorts the root causes by confidence level according to the historical failure case library and expert rules.

[0053] S74: Intelligent Repair Decision-Making and Closed-Loop Iteration; The intelligent repair module employs a dual-track repair strategy based on root cause classification. For consistency root causes such as unit mismatch, missing coordinate system transformation, and sampling rate conflict, the repair module calls the rule-based automatic repair engine to directly correct the IR or generate assets. Specific operations include: if a unit mismatch is detected, inserting a unit transformation flag in the corresponding component connection of the IR; if a coordinate system transformation is missing, supplementing the transformation matrix definition in the IR; if a sampling rate conflict occurs, adjusting the component sampling rate configuration or inserting a synchronizer. After automatic repair is completed, the IR version number is updated and the module directly returns to step S6 to regenerate the topology and assets. For root causes in the requirement layer, such as unspecified parameters, unreasonable parameters, or logical constraint conflicts, the repair module generates highly targeted intelligent follow-up questions. The follow-up questions detail the problem based on the root cause. For example, if an 8-degree pitch angle overshoot is detected, exceeding the 5-degree threshold, the problem is traced back to the transition mode pitch PID controller parameter. The user has not specified the expected damping ratio, and the current default value of 0.5 may cause oscillation. It is recommended to set the damping ratio to 0.7 to 1.0 and provide the expected damping ratio value. The follow-up questions are broadcast via voice synthesis, and the user replies via voice or text. The semantic understanding module parses the user's reply and extracts the corrected parameters. The IR construction module updates the corresponding fields of the IR based on the user's reply. The updated IR returns to step S4 to re-execute slot verification and subsequent processes. After each repair, the system automatically increments the IR version number to record the repair history and triggers a new round of the "slot verification → component retrieval → asset generation → consistency verification → simulation execution → automatic judgment" loop. This loop iterates until all assertions pass or the user actively terminates the process. Finally, the system outputs the successfully tested IR version simulation asset and test report, achieving a complete self-healing closed-loop verification of the requirement design.

[0054] This step outputs the following: the executable simulation package test execution log, the automatic judgment result test report; if the test fails, the output will be a list of failure root causes and the repaired IR instance; if the test succeeds, the output will be a complete test pass report including all monitoring signal waveforms and performance index statistics.

[0055] The following is an example of the application of this invention in the multi-modal switching simulation test of a certain type of vertical takeoff and landing fixed-wing UAV. The test engineer describes the test via voice description of the UAV switching from hovering mode to cruise mode in a level 10 gust of wind. The initial hovering altitude is 50 meters. During the switching process, an IMU gyroscope drift fault is injected, with a drift rate of 0.5 degrees per second. The switching time is required to be no more than 3 seconds, with pitch overshoot less than 5 degrees and roll tracking error not exceeding 2 degrees throughout the entire process. The system obtains structured text through speech recognition terminology normalization, and semantic parsing extracts the test intent as mode switching test plus fault injection. Entities include: aircraft type, vertical takeoff and landing fixed-wing, scenario, level 10 gust of wind, initial altitude 50 meters, fault type, gyroscope drift, drift rate 0.5 degrees per second, acceptance criteria, switching time less than 3 seconds, pitch overshoot less than 5 degrees, and roll error less than 2 degrees. The system constructs an IR instance, mapping the level 10 gust of wind to a Dryden turbulence model with a wind speed of 25 meters per second and moderate turbulence intensity through a knowledge base, and mapping the gyroscope drift to a first-order Markov noise model. Slot verification revealed missing aircraft mass and inertia parameters. The system requested the user to provide the unloaded mass of the drone or select a typical value of 10 kg. The user replied with a mass of 12 kg, and the system updated the IR. Component retrieval and matching were performed using the VTOL dynamics template, nine-axis IMU template, Dryden wind field template, and attitude and position cascaded PID controller template. The topology was instantiated and assembled. The generated simulation assets included parameterized C code defining a mass of 12 kg and an inertia obtained from the aircraft model database. The scene configuration included initial position (longitude, latitude, altitude) of 50 meters, initial attitude (horizontal), initial velocity (zero), and wind field parameters. The test script defined the injection of gyroscope drift at the 10-second mark of the simulation. The assertion file defined the monitoring of the attitude controller output pitch and roll angles within a 10-13 second time window to evaluate switching time and overshoot. After the consistency check is passed, an executable program is compiled and generated. The simulation runs and collects data. It automatically determines that the pitch overshoot has reached 8 degrees, exceeding the 5-degree threshold. The failure is traced back to the pitch PID controller's proportional gain being too high and the user not specifying the desired damping ratio. The system asks for confirmation that the pitch overshoot of 8 degrees has been detected and suggests setting the transition mode damping ratio to 0.8. After the user confirms, the system calculates the PID parameters based on the damping ratio, updates the IR, and regenerates the simulation. In the second round of testing, all assertions pass, and a test report is generated, including signal waveforms and performance indicators. The entire process, from voice input to test pass, takes about 8 minutes, which is dozens of times more efficient than the traditional manual modeling and debugging that takes several weeks.

[0056] The initial data obtained is shown in Table 1: Table 1, Example of Initial Data The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A flight control simulation test method based on voice interaction and demand alignment, characterized in that, Includes the following steps: S1: Obtain user voice requirements, and use endpoint detection and domain terminology normalization to obtain structured text; S2 receives structured text, performs semantic parsing using intent recognition and entity relation extraction, and obtains semantic parsing results containing explicit constraints; S3 receives the semantic parsing results, uses slot template mapping and version management to obtain the structured requirement intermediate representation (IR) instance; S4 receives the IR instance, uses a multi-dimensional rule engine to verify slot integrity and logical consistency, and obtains a verification report. S5 receives the verification report and IR instance, and uses voice prompts to guide intelligent interactive completion, resulting in a complete and consistent IR instance; including: The system generates follow-up questions based on error classification. It categorizes and processes errors according to their types. For errors such as missing required fields, it generates follow-up questions describing the missing information. For errors such as unreasonable parameters, it generates follow-up questions explaining the parameter anomalies and suggesting adjustments. For errors such as logical conflicts, it generates follow-up questions describing the conflicts and selecting solutions. For errors such as inconsistent units or coordinate systems, it generates follow-up questions confirming the conversion requirements. For low-confidence fields, it generates follow-up questions requesting confirmation. Follow-up questions are prioritized and batch-organized. Follow-up questions are prioritized, with fatal errors handled first, warnings handled second, and suggestions handled last. Within the same priority level, follow-up questions are sorted according to their dependencies. Follow-up questions that can be batch-processed are identified and organized into a list format. User response parsing and IR dynamic updates: Update the IR instance based on the response content; For supplementary information responses, extract information and populate the corresponding fields in the IR; For selected solution responses, perform the corresponding repair operation; After the IR update is completed, increment the version number to record the change log of this update. S6 receives a complete and consistent IR instance, uses parameterized templates for component retrieval and simulation topology generation, and obtains a topology structure and interface mapping table; including: The system retrieves matching components from a pre-built standardized flight control component library and automatically assembles simulation topologies. The component library adopts a parameterized template architecture, where each component is defined as a template class rather than a fixed instance. The system matches dynamic templates based on the aircraft description domain of the IR, matches sensor templates based on the sensor list domain, matches actuator templates based on the actuator list domain, and matches control law templates based on the control law domain. The matching process uses type matching and semantic similarity calculation. After a successful match, the system extracts parameters from the IR to instantiate templates. The topology generation module defines automatic connection components based on the IR relation triplet and the data flow of the control law domain. It establishes a closed-loop topology from the dynamic output position, attitude, and velocity to the sensor input, the sensor output measurement value to the controller input, the controller output command to the actuator input, and the actuator output momentum to the dynamic input. At the same time, it generates an interface mapping table to record the source component port, target component port signal type, unit sampling rate, and required conversion operation for each connection. S7 receives the topology and interface mapping table and IR instance, and uses a parallel generation and intelligent repair strategy to generate simulation assets and perform closed-loop verification, resulting in an executable simulation program and test report; including: Multimodal simulation assets are generated in parallel. Component code, parameter files, scene configuration files, automated test scripts, and machine-readable acceptance assertion files are generated in parallel based on the topology and IR configuration. All generated assets are embedded with IR version number references to ensure traceability. Consistency verification and simulation execution: Before simulation, static checks are performed on the generated assets, including interface type matching verification, global unit system uniform verification, coordinate system transformation chain verification, and sampling rate synchronization verification. After the verification is passed, the compilation and building module calls the compiler to generate an executable simulation program package. The simulation execution module selects the software-in-the-loop or hardware-in-the-loop simulation architecture according to the test requirements, loads the scene configuration file, starts the simulation engine, and executes the simulation according to the process defined in the test script. During the simulation, key signal data is collected in real time according to the monitoring signal list defined in the IR test assertion domain and stored in the log file.

2. The flight control simulation test method based on voice interaction and demand alignment according to claim 1, characterized in that, The endpoint detection and domain terminology normalization process used in S1 includes: Speech endpoint detection and noise reduction preprocessing are performed based on dual-threshold energy detection. The acquired audio signal is pre-emphasized and filtered. The pre-emphasized signal is then segmented into frames and windowed using a Hamming window function. The short-time energy and short-time zero-crossing rate are calculated for each frame. A dual-threshold decision strategy is adopted, setting high energy threshold, low energy threshold, and zero-crossing rate threshold for endpoint detection. The detected speech segment signal is then denoised using spectral subtraction. Speech-to-text conversion is performed based on the fusion of acoustic and language models. Mel frequency cepstral coefficient features are extracted from the denoised speech signal. The extracted feature sequence is input into the acoustic model for frame-level phoneme recognition. The phoneme probability sequence output by the acoustic model is combined with the language model to search for word sequences and obtain preliminary text transcription results. Based on a domain terminology database, we perform professional vocabulary correction and normalization. We scan the initial transcribed text word by word, calculate the edit distance between each word and each term in the terminology database, replace misidentified forms with standard term names, and standardize numerical units.

3. The flight control simulation test method based on voice interaction and demand alignment according to claim 1, characterized in that, The semantic parsing performed in S2 using intent recognition and entity relation extraction includes: Test type identification is based on intent classification model. The text classification model is used to identify the intent of the input text to determine the test type of the user's needs. The text input to the model is processed by word embedding encoding attention mechanism and then outputs the probability distribution of each test type through classification layer. Named entity recognition and attribute extraction based on sequence labeling: Key entities and their attributes are extracted from text using a sequence labeling model. Each word in the input text is labeled with an entity tag, and entity attributes are further extracted after the entity is identified. Entity relation reasoning is based on dependency syntax trees. Dependency syntax analysis is performed on the text to construct a dependency relation tree between words. Relations are extracted by combining rule matching and relation classification models based on dependency syntax trees. The extracted relations are stored in the form of triples to form an entity relation graph. Constraint extraction is performed based on temporal logic expression parsing, identifying time prepositional phrases, extracting start time, end time or duration, identifying conditional connectors, extracting conditional expressions, and constructing formal logic expressions.

4. The flight control simulation test method based on voice interaction and demand alignment according to claim 1, characterized in that, The S3 uses slot template mapping and version management, including: The predefined hierarchical IR template structure is designed. The IR template includes a metadata field that records the unique identifier, version number, timestamp, and original voice file path of the IR instance, which is associated with the user. The aircraft description field includes the aircraft type identification mass parameters, inertial parameters, aerodynamic model references, propulsion model references, and body coordinate system definition of the global physical unit system. The sensor list field stores each sensor object in array form. The actuator list field stores each actuator object. The control law field includes the set of available modes, the controller structure description of each mode, controller parameters, and mode switching logic. The simulation scenario field includes the initial state, environmental conditions, mission profile, stage events, and fault injection list. The test assertion field stores acceptance assertion objects in array form. The mapping and filling of semantic parsing results to IR slots adopts a strategy that combines rule-driven and semantic matching to map the semantic parsing results to the field slots of the IR template.

5. The flight control simulation test method based on voice interaction and demand alignment according to claim 1, characterized in that, The S4 process employs a multi-dimensional rule engine to perform slot integrity and logical consistency checks, including: Required field integrity check: Iterate through the IR template definition to extract the list of all required fields, and iterate through the current IR instance to check whether each required field has a non-empty value. If a required field is missing or has an empty value, record the complete path of the corresponding field, the field description, and the error type. Physical parameter rationality and value range verification: The physical parameters in IR are checked for rationality to ensure that the parameter values ​​conform to physical laws and engineering common sense. The preset parameter rationality rule library is queried. If the parameter violates the hard constraints, it is recorded as a fatal error. If the parameter exceeds the recommended range but does not violate the hard constraints, it is recorded as a warning. Global unit system consistency check: Extract the global unit system definition from the aircraft description domain of IR, traverse all fields involving physical quantities in IR to check whether the unit label of each field is consistent with the global unit system, and determine whether unit conversion is needed for fields with inconsistent units.

6. The flight control simulation test method based on voice interaction and demand alignment according to claim 1, characterized in that, The S7 also includes automated judgment and intelligent failure tracing, as well as intelligent repair decision-making and closed-loop iteration: Automated judgment and intelligent failure tracing: The automatic judgment module loads the assertion file and performs assertion evaluation one by one. For each assertion, it extracts the data segment of the corresponding monitoring signal within the specified time window from the log, performs calculations according to the evaluation index type defined by the assertion, and compares the calculated actual index value with the qualified threshold defined by the assertion. When an assertion failure is detected, the failure tracing module uses a pre-set multi-level reverse mapping network to locate the surface assertion failure phenomenon to the deep root cause layer by layer. Intelligent repair decision-making and closed-loop iteration adopt a dual-track repair strategy based on root cause classification. For consistent root causes, the rule-based automatic repair engine is called to directly correct the IR or generate assets. For the root cause repair module of the demand layer, highly targeted intelligent follow-up questions are generated. After each repair, the system automatically increments the IR version number to record the repair history and triggers a new round of slot verification component to retrieve assets, generate consistency verification simulation, and execute automatic judgment loop.

7. A flight control simulation test system based on voice interaction and demand alignment, used to execute the steps in the flight control simulation test method based on voice interaction and demand alignment as described in any one of claims 1-6, characterized in that, include: The voice request acquisition module is used to acquire user voice requests and uses endpoint detection and domain terminology normalization to obtain structured text. The semantic parsing module receives structured text, performs semantic parsing using intent recognition and entity relation extraction, and obtains semantic parsing results containing explicit constraints. The IR building module is used to receive semantic parsing results, and uses slot template mapping and version management to obtain the intermediate representation IR instance of structured requirements; The slot verification module receives IR instances, uses a multi-dimensional rule engine to verify slot integrity and logical consistency, and obtains a verification report. The interactive completion module receives the verification report and IR instance, and uses voice prompts to guide intelligent interactive completion to obtain a complete and consistent IR instance; The component retrieval and topology generation module is used to receive complete and consistent IR instances, perform component retrieval and simulation topology generation using parameterized templates, and obtain the topology structure and interface mapping table. The asset generation and closed-loop verification module receives the topology and interface mapping table and IR instance, and uses parallel generation and intelligent repair strategies to generate and verify simulated assets, resulting in an executable simulation program and test report.

Images