A power electronic virtual controller automatic evolution closed-loop verification method, device and equipment

Abstract

The application discloses a kind of electric power electronic virtual controller automatic evolution closed loop verification method, device and equipment, method includes: entity identification generates standardization test intent data;Enhanced prompt is constructed by searching knowledge base based on intent data;V-ECU code and test scene script are generated by inputting enhanced prompt into field fine-tuning large language model;V-ECU code and test scene script are executed multidimensional static constraint check, and are compiled into V-ECU image;V-ECU image is connected with digital power grid model and is accessed HIL and is carried out closed loop simulation test, obtains test response data;According to test response data, fitness function is constructed, and test vector is evolved by genetic variation algorithm iteration, and standardization verification report is generated.The application can solve the technical problems that the reuse rate of existing HIL simulation test is low and the cost is high, the coverage is limited to the definition boundary, and does not have the generation ability of virtual controller.

Description

Technical Field

[0001] This application relates to the field of power electronics technology, and in particular to a method, apparatus and equipment for automatic evolution closed-loop verification of a power electronic virtual controller. Background Technology

[0002] Power electronic equipment is a core component of new power systems, and its controllers must meet the stringent testing requirements of grid connection standards. Hardware-in-the-loop (HIL) simulation is the mainstream method for verifying the functionality and robustness of controllers. Current mainstream technologies employ a semi-automated testing scheme using model-driven engineering and a standardized script template library. Engineers configure test cases based on fixed template parameters, import them into the HIL platform for execution, and perform automatic evaluation.

[0003] However, this technical solution has significant drawbacks: First, the template library relies on manual maintenance, requiring item-by-item modification during standard updates, resulting in low reusability, high maintenance costs, and long test script development cycles. Second, test scenarios can only cover predefined typical operating conditions and cannot automatically generate boundary cases such as multiple fault superposition, limiting test coverage and leading to a high rate of missed hidden defects. Third, it lacks the ability to automatically generate virtual controllers (V-ECUs), requiring hardware prototypes for testing, thus coupling the verification process sequentially with hardware development. These issues result in low verification efficiency, insufficient coverage, and lengthy cycles for power electronic controllers, making it difficult to adapt to the needs of agile development and rapid standard iteration. Summary of the Invention

[0004] This application provides a method, apparatus, and equipment for automatic evolution closed-loop verification of power electronic virtual controllers, which solves the technical problems of existing HIL simulation testing relying on manual labor, resulting in low reusability and high cost. Its test scenario coverage is also limited by predefined boundaries, and it does not have the ability to generate virtual controllers, resulting in low actual verification efficiency, insufficient coverage, and long cycle, making it difficult to adapt to actual needs.

[0005] In view of this, the first aspect of this application provides a method for automatic evolution closed-loop verification of a power electronic virtual controller, comprising: S1: Perform entity recognition and structured parsing on natural language test intent to generate standardized test intent data; S2: Enhanced prompts are constructed by retrieving power electronics professional knowledge bases based on standardized test intent data. The enhanced prompts include standard clauses, fault cases, and code snippets. S3: Automatically generate V-ECU code and test scenario scripts that conform to HIL platform constraints from the enhanced prompt input domain fine-tuning large language model; S4: Perform multi-dimensional static constraint verification on the V-ECU code and the test scenario script. After the verification is passed, automatically compile it into a V-ECU image that can be executed by HIL and complete the deployment. S5: Connect the V-ECU image and the digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing, and obtain test response data, including test code coverage and fault trigger probability. S6: Construct a fitness function based on the test response data, iteratively evolve the test vector through a genetic mutation algorithm, and feed the test vector back to step S5 to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

[0006] Preferably, step S1 includes: A preset entity recognition model is used to perform entity recognition on the natural language test intent, and the entity recognition results are obtained. The entity recognition results include standard entities, power level entities, topology entities, fault type entities, and performance index entities. After the entity recognition results are structured and filled, the abnormal intent data is interactively completed to generate standardized test intent data.

[0007] Preferably, step S2 includes: The standardized test intent data is encoded into a retrieval vector and a similarity search is performed in the power electronics professional knowledge base to obtain multiple candidate knowledge fragments. The candidate knowledge fragments are subjected to contextual filtering based on semantic fine-ranking using a cross encoder to obtain the matching target fragments; The matched target fragment is concatenated with the standardized test intent data to construct an enhanced prompt.

[0008] Preferably, step S4 includes: Pin mapping verification, timing constraint verification, coding standard verification, and state machine activity verification are performed sequentially on the V-ECU code and the test scenario script. If the verification fails, the verification error information will be fed back to the domain fine-tuning large language model to regenerate V-ECU code and test scenario scripts that conform to the HIL platform constraints; The verified V-ECU code and the test scenario script are automatically compiled into a HIL-executable V-ECU image and deployed.

[0009] Preferably, step S5 includes: The V-ECU image and the digital power grid model are connected to the HIL real-time simulation engine, and electromagnetic transient real-time simulation is run with a preset step size not greater than the step size threshold. Based on the test scenario script, voltage dips, frequency disturbances, and phase jump fault excitations are injected into the simulation process, and simulated electrical quantities are collected at a preset sampling frequency. The simulated electrical quantities are compared and analyzed with preset criteria to obtain test response data.

[0010] Preferably, step S6 includes: The test scenario is encoded into individual gene fragments based on the genetic mutation algorithm, and the fitness function is the weighted value of the test code coverage and the fault trigger probability in the current test round. The population is iteratively mutated using tournament selection, uniform crossover, and Gaussian mutation algorithms to generate a test vector population. The test vector population is fed back to step S5 to re-execute the closed-loop simulation test until the coverage converges to less than the coverage threshold, and a standardized verification report is generated.

[0011] Preferably, step S6 further includes: New defect cases, effective test vectors, and verified V-ECU codes from the closed-loop simulation test process are annotated and archived into the power electronics professional knowledge base.

[0012] The second aspect of this application provides an automatic evolution closed-loop verification device for a power electronic virtual controller, comprising: The data parsing unit is used to perform entity recognition and structured parsing of natural language test intents to generate standardized test intent data. The suggestion construction unit is used to construct enhanced suggestions by retrieving power electronics professional knowledge base based on standardized test intent data. The enhanced suggestions include standard clauses, fault cases and code snippets. The code generation unit is used to automatically generate V-ECU code and test scenario scripts that conform to the HIL platform constraints from the enhanced prompt input domain fine-tuning large language model. The verification compilation unit is used to perform multi-dimensional static constraint verification on the V-ECU code and the test scenario script. After the verification is passed, it is automatically compiled into a HIL executable V-ECU image and deployed. The simulation test unit is used to connect the V-ECU image and the digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing and to obtain test response data, including test code coverage and fault trigger probability. The optimization verification unit is used to construct a fitness function based on the test response data, iteratively evolve the test vector through a genetic mutation algorithm, and feed the test vector back to the simulation test unit to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

[0013] Preferably, the data parsing unit is specifically used for: A preset entity recognition model is used to perform entity recognition on the natural language test intent, and the entity recognition results are obtained. The entity recognition results include standard entities, power level entities, topology entities, fault type entities, and performance index entities. After the entity recognition results are structured and filled, the abnormal intent data is interactively completed to generate standardized test intent data.

[0014] A third aspect of this application provides an automatic evolution closed-loop verification device for a power electronic virtual controller, the device including a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the automatic evolution closed-loop verification method for the power electronic virtual controller described in the first aspect according to the instructions in the program code.

[0015] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: This application provides an automatic evolution closed-loop verification method for power electronic virtual controllers, comprising: S1: performing entity recognition and structured parsing on natural language test intentions to generate standardized test intention data; S2: constructing enhanced prompts by retrieving power electronics professional knowledge bases based on standardized test intention data, the enhanced prompts including standard clauses, fault cases, and code snippets; S3: automatically generating V-ECU code and test scenario scripts that conform to HIL platform constraints by fine-tuning the large language model of the input domain of the enhanced prompts; S4: performing multi-dimensional static constraint verification on the V-ECU code and test scenario scripts, and automatically compiling them into a HIL-executable V-ECU image and completing deployment after the verification passes; S5: connecting the V-ECU image and digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing and obtaining test response data, the test response data including test code coverage and fault trigger probability; S6: constructing a fitness function based on the test response data, iteratively evolving the test vectors through a genetic mutation algorithm, and feeding the test vectors back to step S5 to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

[0016] The automatic evolution closed-loop verification method for power electronic virtual controllers provided in this application automatically generates V-ECU code and test scenario scripts that conform to HIL platform constraints through domain fine-tuning of a large language model. This eliminates the reliance on manually generated template libraries. Standard updates only require timely updates to the knowledge base, eliminating the need for rewriting scripts and reducing labor and time costs. The generated template library is also more suitable for various scenario characteristics and has a higher reusability. In addition, a genetic mutation algorithm is used to optimize and update test vectors with coverage and failure probability as fitness, breaking through the limitations of fixed template operating conditions and actively exploring uncovered state machine branches and boundary vulnerabilities, so that test coverage is no longer limited to predefined scenario boundaries. Furthermore, V-ECU code that conforms to HIL constraints is directly generated, compiled, and deployed through domain fine-tuning of a large language model. This process can achieve HIL closed-loop testing without hardware prototypes, has native V-ECU automatic generation capabilities, and supports pre-verification before hardware is available, changing the verification process from serial to parallel and significantly shortening the development cycle. Therefore, this application can solve the technical problems of existing HIL simulation testing, which relies on manual labor, resulting in low reusability and high cost. Its test scenario coverage is also limited by predefined boundaries and it does not have the ability to generate virtual controllers, resulting in low actual verification efficiency, insufficient coverage, long cycle, and difficulty in adapting to actual needs. Attached Figure Description

[0017] Figure 1 A flowchart illustrating an automatic evolution closed-loop verification method for a power electronic virtual controller provided in this application embodiment; Figure 2 A schematic diagram of the structure of an automatic evolution closed-loop verification device for a power electronic virtual controller provided in this application embodiment; Figure 3 This application provides an example diagram of the natural language intent parsing and structured process in its embodiments. Figure 4 Example diagram of the RAG retrieval enhancement generation process provided in the embodiments of this application; Figure 5 An example diagram illustrating the generation and verification process of V-ECU code and test scenario script provided in this application embodiment. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] Terminology Explanation: LLM (Large Language Model) is a deep neural network model based on the Transformer architecture and pre-trained on massive amounts of text, possessing powerful natural language understanding, reasoning, and code generation capabilities. In this invention, LLM serves as the core inference engine, receiving the user's test intent described in natural language, automatically parsing the functional requirements, timing constraints, and protocol specifications, and outputting a structured controller behavior description and a compilable code framework. Its key role is to bridge the cognitive gap between test engineers and the underlying code, achieving end-to-end automatic conversion from "intent" to "executable code."

[0020] Retrieval-Augmented Generation (RAG) is a technical architecture that combines dynamic retrieval from an external knowledge base with reasoning from a large language model. Before generating a response, the system first performs semantic vector retrieval on a dedicated knowledge base (including IEEE grid connection standards, historical fault test cases, and controller code libraries), injecting the most relevant reference fragments into the model context, thereby significantly improving the professional accuracy and domain consistency of the generated content. Compared to methods that purely rely on memorizing model parameters, RAG can reference the latest standard text in real time, effectively reducing the compliance error rate in the generated code, which is the key technical support for achieving high-precision automatic code generation in this invention.

[0021] HIL (Hardware-in-the-Loop) simulation is a testing method that embeds a real hardware controller into a real-time digital simulation loop, enabling it to interact in a closed loop with a high-fidelity mathematical model (power grid, converter, load, etc.) in real time. In this invention, the HIL platform (such as Typhoon HIL 604 or dSPACE SCALEXIO) handles the real-time signal exchange between the controller under test (including the generated V-ECU) and the digital power grid model. The simulation step size is typically no more than 1 μs, and it can realistically reproduce dynamic processes such as fault ride-through, frequency jumps, and islanding detection. It is the core execution environment for verifying the boundary behavior of the controller.

[0022] A V-ECU (Virtual Electronic Control Unit) is a controller model described purely in software and running on a real-time simulation platform. Its behavior and semantics are completely equivalent to a real physical ECU, but no actual hardware is required. The V-ECU retains complete input / output pin mappings, interrupt service routine timings, PWM carrier frequency, and other constraints, and can directly participate in HIL closed-loop testing. This invention automatically generates V-ECU code using LLM+RAG, enabling rapid iteration of controller logic and parallel verification of multiple versions, compressing the traditional controller prototype development cycle of several weeks to several hours.

[0023] The Genetic Mutation Algorithm (GMAL) is a heuristic global optimization method that draws inspiration from biological evolution. It iteratively generates test scenarios with higher coverage and closer to the system boundary by selecting, crossing over, and mutating a set of test cases. In this invention, the algorithm uses controller coverage metrics (branch coverage, state coverage) and historical fault trigger probabilities as fitness functions to automatically evolve extreme test vectors capable of detecting boundary defects such as dead-zone vulnerabilities and steady-state error exceeding limits. This achieves adaptive optimization of test cases and significantly improves the detection capability of latent defects.

[0024] For easier understanding, please refer to Figure 1 An embodiment of an automatic evolution closed-loop verification method for a power electronic virtual controller provided in this application includes: Step 101: Perform entity recognition and structured parsing on the natural language test intent to generate standardized test intent data.

[0025] Users can submit natural language test intents in the form of natural language text. This text can include, but is not limited to, references to test standards, specifications of the tested object such as rated power, topology type, and DC-side voltage range, descriptions of test conditions such as fault type, duration, and recovery slope, and acceptance indicators such as the upper limit of total harmonic distortion (THD) and the upper limit of active power recovery time. A BERT-based entity recognition model can be used to extract the above key information and generate a structured intent representation, i.e., a standardized test intent, providing an accurate query vector for subsequent RAG retrieval.

[0026] Further, step 101 includes: A pre-defined entity recognition model is used to perform entity recognition on the natural language test intent, and the entity recognition results are obtained. The entity recognition results include standard entities, power level entities, topology entities, fault type entities, and performance index entities. After the entity recognition results are structured and filled in, the abnormal intent data is interactively completed to generate standardized test intent data.

[0027] Please see Figure 3 After receiving the natural language test intent text input by the user, the system can perform word segmentation on the natural language test intent, and then use a preset entity recognition model to identify entities. In this embodiment, a NER model for the power electronics field, which is an entity recognition model, is pre-trained and can identify the following entity types: standard entities, power level entities, topology entities, fault type entities, and performance index entities. For the entity recognition results obtained after recognition, the system fills various entities into a predefined intent representation template to generate a structured data object containing four top-level fields: "test standard", "test object specification", "fault scenario", and "acceptance index", ensuring the accuracy of subsequent RAG retrieval queries.

[0028] Specifically, the user can input the following natural language test intent information: "Please perform LVRT verification on the 1MW three-phase full-bridge photovoltaic inverter controller. According to the Class III requirements of IEEE 1547-2018, the test conditions include: (1) the three-phase symmetrical voltage drops to 0.05pu and recovers after 1s; (2) the single-phase voltage drops to 0.1pu and lasts for 0.5s; (3) a two-phase ground fault, the voltage drops to 0.2pu and lasts for 0.32s. The rated voltage of the inverter DC side is 650V and the rated frequency is 60Hz. Acceptance criteria: the reactive current injection during the fault is not less than 1.5 times the rated current, the active power recovers to 90% of the value before the fault within 1s after the voltage recovers, and the current THD does not exceed 5%."

[0029] The preset entity recognition model then analyzes the input, identifying the following entities: standard entity, power rating, three-phase full-bridge topology, DC voltage, rated frequency, three fault scenarios, and three acceptance criteria: reactive current injection ≥1.5 pu, active power recovery time ≤1s, and THD ≤5%. After generating the intent structured data, the system automatically detects that the "inverter rated current" field is empty and prompts the engineer: "Please fill in the inverter rated current value (A) or rated capacity (kVA) to complete the pin range configuration." The engineer enters "rated capacity 1000kVA, rated current 1443A," and the system automatically calculates the rated current and fills it into the intent structured data, completing the intent completion.

[0030] For ambiguous or incomplete intent descriptions, the system analyzes the missing fields in the intent structured data and poses targeted supplementary questions to the user in natural language, such as "Please confirm the DC side rated voltage range of the inverter under test." After the user answers, the system automatically merges the supplementary information into the intent structured data until all required fields are complete, thus obtaining standardized test intent data. This is the interactive completion operation, which can fill in missing or abnormal fields.

[0031] Step 102: Construct enhanced hints by retrieving power electronics professional knowledge base based on standardized test intent data. Enhanced hints include standard clauses, fault test cases, and code snippets.

[0032] The process of enhancing the generation of RAGs requires maintaining a multi-source heterogeneous professional knowledge base, namely the power electronics professional knowledge base. This knowledge base covers full-text vectorized indexes of various grid connection standards, historical fault use case libraries, and general power electronics control code template libraries. The historical fault use case library includes fault types, triggering conditions, controller vector characteristics, and remediation measures.

[0033] The power electronics knowledge base needs to be pre-built before its first use. Simply input a collection of different documents into the knowledge base building tool. In this embodiment, the tool can perform various processing on each document, such as: PDF / text parsing: extracting plain text content while preserving the chapter hierarchy; block segmentation: segmenting according to semantic paragraphs and code function boundaries, with each block length controlled between 200 and 500 tokens; vector encoding: calling a power electronics vertically fine-tuned version of the semantic encoder to encode each text block into a 768-dimensional vector; metadata annotation: annotating each vector block with metadata such as source document, chapter number, and document type; vector storage: batch writing vectors and metadata into the FAISS index, using IVF-PQ quantization for acceleration, supporting millisecond-level retrieval. After initialization, the knowledge base contains approximately 150,000 vector blocks, with a total storage space of approximately 2GB.

[0034] During retrieval, the standardized test intent data can be converted into vectors first, and then the vectors can be used for querying. The top K (K=5~10) most relevant segments can be retrieved from the power electronics professional knowledge base using cosine similarity and then concatenated as enhanced hints.

[0035] Further, step 102 includes: Standardized test intent data is encoded into retrieval vectors and similarity retrieval is performed in the power electronics professional knowledge base to obtain multiple candidate knowledge fragments. A cross-encoder is used to perform contextual filtering on candidate knowledge fragments based on semantic ranking to obtain matching target fragments; The target fragment is matched with standardized test intent data to construct an enhanced prompt.

[0036] Specifically, a dual encoder can be used to encode standardized test intent data into retrieval vectors; all documents in the power electronics professional knowledge base also need to be encoded into 768-dimensional dense vectors through a professional semantic encoder to form a professional knowledge vector base; then, a query is performed through the retrieval vector, the cosine similarity between the vector and all document vectors in the professional knowledge vector base is calculated, and the top K retrieval results are taken as candidate knowledge fragments.

[0037] To further improve accuracy, this embodiment introduces a cross-encoder after retrieval to perform semantic refinement on the K candidate knowledge fragments, filtering out semantically related fragments that do not match the technical context, thus obtaining the matching target fragment. Concatenating the matching target fragment with standardized test intent data yields enhanced prompts; the format of the enhanced prompts includes system role descriptions, standard clause text, reference code snippets, historical fault test cases, user intent structured data, and output format instructions. For detailed retrieval and generation processes, please refer to [link / reference]. Figure 4 .

[0038] Specifically, in this embodiment, K=20, meaning 20 candidate knowledge fragments are selected. After fine sorting by the cross-encoder, the first 8 fragments are retained. These include: the LVRT voltage-time curve definition in Section 6.4.1 of IEEE 1547-2018; the Class III voltage threshold parameter table in Table 1 of IEEE 1547-2018; the reactive current injection requirements in Section 7.4 of IEEE 1547-2018; the current quality requirements in Section 6.5 of IEEE 1547-2018, including THD limits; the LVRT state machine template in the internal code template library, including LVRT trigger condition judgment; the reactive current slope control code fragment, approximately 150 lines of C code; three-phase symmetrical LVRT test cases in the historical test case library, including fault injection timing scripts and pass / fail criterion configurations; single-phase LVRT test cases in the historical test case library; and a three-phase fault injection call example in the Typhoon HIL platform interface reference. These eight fragments were spliced ​​together to form an enhanced context, which, together with the intent-structured data, constituted a model input of approximately 8,000 words.

[0039] Step 103: The enhanced input domain fine-tuning language model will automatically generate V-ECU code and test scenario scripts that conform to the HIL platform constraints.

[0040] This embodiment of the domain-specific fine-tuning large language model is based on an open-source basic large language model. It utilizes a power electronics corpus for supervised fine-tuning and reinforcement learning based on human feedback to obtain a domain-specific model. The power electronics corpus includes standard clauses, control algorithm descriptions, and HIL configuration manuals. The inference inputs of the domain-specific fine-tuning large language model include enhanced prompts and standardized test intent data. The inference outputs include V-ECU code and test scenario scripts. The V-ECU code describes the behavior of the V-ECU, while the test scenario scripts describe the test scenarios using a test case description language. Furthermore, the model's inference process employs a thought chain prompt strategy to ensure that the inference process with complex constraints is traceable and auditable.

[0041] Specifically, the vertical fine-tuning of the domain-specific large language model in this embodiment includes two stages. The first stage is continuous pre-training of the domain, using approximately 50GB of power electronics-related corpus on the basic LLM to enable the model to master the domain's vocabulary distribution and knowledge structure. The second stage is instruction fine-tuning, constructing a professional instruction dataset. Each data point contains a test intent description, the corresponding standard V-ECU code, and a test scenario script, totaling approximately 5000 high-quality instruction pairs. The LoRA (Low-Rank Adaptation) parameter-efficient fine-tuning method is adopted, which trains only the low-rank adaptation matrix with a rank r=16 while keeping the basic LLM parameters frozen, significantly reducing the computational cost of fine-tuning.

[0042] Specifically, after receiving enhanced cues, the domain fine-tuning large language model infers and determines the top-level state machine mechanism of the controller, including states such as INIT, MPPT_NORMAL, LVRT_DETECT, LVRT_ACTIVE, and RESTORE, and their transition conditions. Then, corresponding control algorithm code is generated for each state, such as the disturbance observation algorithm in the MPPT tracking state and the reactive current injection strategy in the LVRT state. Next, a PWM modulation module is generated, which includes the SVPWM lookup table implementation and dead time insertion logic. Finally, interrupt service routines and the main loop framework are generated.

[0043] The transition conditions for each state in the state machine structure are as follows: MPPT_NORMAL → LVRT_DETECT is triggered by a voltage monitoring interrupt; LVRT_DETECT → LVRT_ACTIVE is triggered by two consecutive sampling periods T=1ms confirming that the voltage drop exceeds the threshold; LVRT_ACTIVE → RESTORE is triggered by the voltage recovering to above 0.9pu for 50ms; RESTORE → MPPT_NORMAL is triggered by the active power recovering to 90% of the rated value.

[0044] The LVRT_ACTIVE state control code calculates the reactive current injection amount based on linear characteristics:

[0045] in, This represents the reactive current injection factor required by IEEE 1547-2018 Category III. This is the measured voltage per unit value. The rated current is 1443A.

[0046] The active power constraint is expressed as:

[0047] in, This means that the maximum allowable operating current overcurrent is 10%. The current controller adopts synchronous rotating coordinate system PI control, with a current loop bandwidth of 1kHz, corresponding to a control period of 100μs. PI parameters: Kp=0.5, Ki=100.

[0048] SVPWM modulation is adopted, with a carrier frequency of 10kHz, a corresponding carrier period of 100μs, and a dead time of 4μs. The real-time computing burden is reduced by using a lookup table method, with a lookup table resolution of 1024 points and an angular resolution of approximately 0.35°.

[0049] The test scenario script is written using the HIL platform script interface and includes three test case functions: three-phase symmetrical LVRT test (three-phase symmetrical drop to 0.05 pu, 1s); single-phase LVRT test (single-phase drop to 0.1 pu, 0.5s); and two-phase ground LVRT test (two-phase ground drop to 0.2 pu, 0.32s). Each function includes: pre-fault steady-state operation confirmation (checking if the DC bus voltage is 630±20V and the output power is above 95% of the rated value); fault injection (calling the platform voltage setting interface to set the three-phase voltage amplitude); real-time data acquisition (recording three-phase voltage, three-phase current, active power, reactive power, and DC bus voltage at a 10kHz sampling rate); pass / fail criterion evaluation (calling the built-in numerical comparison function to check reactive current, active power recovery time, and THD); and fault clearing and steady-state recovery confirmation.

[0050] Since the generated V-ECU code and test scenario script need to be input into the HIL platform for simulation analysis, the process of generating code and scripts based on the model also needs to meet the constraints of the HIL platform. These constraints may include input format constraints, runtime condition constraints, etc. For example, verifying whether the PWM carrier frequency falls within the range of 200Hz to 20Hz supported by the HIL platform, whether the sampling rate setting meets the Nyquist criterion, whether the I / O pin mapping is consistent with the platform hardware connection expression, and whether there is deadlock in the state machine transition conditions.

[0051] This embodiment designs a unified HIL platform abstraction interface layer, enabling transparent switching between mainstream HIL platforms such as TyphoonHIL supported by the driver adapter mode, dSPACE() supported by the SCALEXIO Python Interface, and RTDS supported by RSCAD Python Scripting. During V-ECU code generation, CodeGen-Verifier automatically selects the corresponding pin mapping macro definition header file and compilation toolchain based on the target platform type, ensuring that the same logic intermediate representation generated by the LLM can be deployed seamlessly to different brands of HIL platforms.

[0052] In addition, the target HIL platform information needs to be filled in the HAL configuration file: platform type; IP address; I / O card slot configuration: Slot 1: analog output card, 16 channels; Slot 2: digital I / O card, 64 channels; Slot 3: high-speed acquisition card, 8 channels, sampling rate 10MHz; three-phase voltage output pin numbers; three-phase current acquisition pin numbers; PWM input pin numbers. After configuration, proceed to the compilation stage.

[0053] In addition to generating V-ECU code and test scenario scripts based on large language models, a structured rule database can be selected to manually convert grid connection standard clauses into machine-readable rule entries beforehand. The rule engine then automatically matches and assembles the test scenario scripts based on the user's parameterized test requests. Its advantages include fully interpretable and non-random generation logic, high accuracy of rule entries after manual review, no need for large-scale GPU computing power during runtime, and low deployment costs. Its disadvantages are: the construction and maintenance of the rule base still requires significant manual input, and the rule coverage is limited, resulting in insufficient flexibility when facing non-standardized test requirements described in natural language; when encountering complex requirements with cross-standards and multiple constraints, the rule combination explosion problem makes the system difficult to scale; and the V-ECU code generation capability is extremely weak, making it unable to handle the automatic synthesis of control algorithm logic. Compared to the LLM solution, this approach has significant disadvantages in flexibility, coverage, and V-ECU generation capability, and is only suitable for factory test scenarios with fixed requirements and stable standards.

[0054] Step 104: Perform multi-dimensional static constraint verification on the V-ECU code and test scenario script. After the verification is passed, automatically compile it into a V-ECU image that can be executed by HIL and complete the deployment.

[0055] To improve the accuracy of simulation testing, this embodiment requires verification of the code and scripts through multi-dimensional static constraints before conducting closed-loop simulation testing based on the code. Specifically, this may include, but is not limited to, mapping verification, timing verification, encoding verification, and state machine liveness verification. Only code and scripts that pass the verification can proceed to the subsequent compilation and deployment stage. Code and scripts that fail the verification can be discarded directly, or the verification results can be fed back to the code generation stage to readjust the generation mechanism, update the code and scripts, until the constraints are met and the verification is passed.

[0056] Once verified, the V-ECU code can be compiled using the HIL platform cross-compilation toolchain to obtain a platform-specific image, namely the V-ECU image. The V-ECU image is then automatically uploaded to the HIL host via the local area network to complete model loading and initialization. The entire process requires no manual operation, greatly reducing the influence and dependence on human factors.

[0057] Further, step 104 includes: Pin mapping verification, timing constraint verification, coding standard verification, and state machine activity verification are performed sequentially on the V-ECU code and test scenario script. If the verification fails, the verification error information will be fed back to the domain fine-tuning large language model to regenerate V-ECU code and test scenario scripts that conform to the HIL platform constraints. The verified V-ECU code and test scenario scripts are automatically compiled into an HIL-executable V-ECU image and deployed.

[0058] Specifically, pin mapping verification compares the I / O pin identifiers in the code with the hardware connection configuration file of the target HIL platform one by one to ensure that all referenced pins are defined in the configuration file and their types match, such as analog inputs and digital outputs; timing constraint verification checks whether the integer multiple relationship between the PWM carrier period and the ADC sampling interrupt period is satisfied, and whether the estimated execution time of the main loop of the control algorithm is less than the simulation step size limit; coding standard verification calls PC-lint or Polyspace tools to perform static rule checks on the generated code, automatically correcting common violations such as uninitialized variables and pointer out-of-bounds errors; state machine liveness verification uses model verification tools such as SPIN or NuSMV to perform deadlock, livelock, and reachability analysis on the formal description of the state machine, ensuring that all states are reachable and there are no deadlock paths. If any verification item fails, the system automatically sends a verification report to Domain-LLM, triggering a code correction and regeneration process, which can be iterated up to 3 times. For the entire code and script generation and verification process, please refer to [link to documentation]. Figure 5 .

[0059] The platform uses the GCC-ARM cross-compilation toolchain to compile the V-ECU code, generating machine code for the Typhoon HIL FPGA processor, which is then packaged into a .cde format image file, approximately 380KB in size. Simultaneously, the test script Python file is uploaded directly after syntax verification. Then, it connects to the Typhoon HIL 604 main control software via Ethernet 192.168.1.100 and executes the following steps in sequence: loading the digital microgrid model (a 1MW photovoltaic system including photovoltaic arrays, inverter main circuits, LCL filters, transformers, and distribution network impedance, totaling 58 nodes, with a simulation step size of 1μ); loading the V-ECU image and binding it to the controller interface in the HIL model; completing the I / O pin mapping configuration; and performing a cold start, with the HIL real-time simulation starting at t=0 and waiting for the system to reach steady state, categorized by DC bus voltage deviation <1% and output power stabilization time >2s. The entire deployment process takes approximately 8 minutes and requires no manual operation of the HIL software interface.

[0060] Step 105: Connect the V-ECU image and the digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing, and obtain test response data, including test code coverage and fault trigger probability.

[0061] Further, step 105 includes: The V-ECU image and digital power grid model are connected to the HIL real-time simulation engine, and electromagnetic transient real-time simulation is run with a preset step size not greater than the step size threshold. Based on the test scenario script, voltage drop, frequency disturbance and phase jump fault excitation are injected into the simulation process, and simulated electrical quantities are collected at a preset sampling frequency; The simulated electrical quantities are compared and analyzed with preset criteria to obtain test response data.

[0062] The HIL real-time simulation engine is the interface layer between the system and the physical HIL hardware. It manages the real-time operation of the digital power grid model, with a preset step size of 1µs. Accelerated by FPGA, it coordinates signal exchange between the V-ECU and the digital power grid model, simulating I / O, digital I / O, and high-speed serial communication. It executes fault injection instructions from the test scenario script and records the full simulation waveform at high-speed data flow to obtain simulated electrical quantities. The preset sampling frequency can be between 1 and 10kHz, and it can compare preset criteria online to generate preliminary conclusions, i.e., test response data. The preset step size must be less than or equal to a step size threshold, which can be set according to actual conditions and is not limited here. It is understood that the test response data includes, but is not limited to, test code coverage and fault trigger probability.

[0063] In this embodiment, the HIL simulation executes three test cases: First, a three-phase symmetrical LVRT test is run. After fault injection, the HIL platform waveform shows that the three-phase voltage drops to 0.05 pu within one sampling period T=100μs; the controller enters the LVRT_ACTIVE state after a detection delay of 2ms, and the reactive current rises to 2.16kA within 3ms, approximately 1.5 times the rated current, meeting the IEEE 1547-2018 Class III requirements; the voltage recovers 1s after the fault, and the controller enters the RESTORE state after the voltage remains above 0.9 pu for more than 50ms, and the active power recovers to 92% of the rated value within 0.82s, meeting the requirement of recovering to 90% within 1s; the total current THD is 3.2%, meeting the 5% upper limit; this test case is judged to pass.

[0064] This embodiment integrates an automatic waveform analysis engine based on the SciPy signal processing library. It can perform FFT harmonic analysis, transient response time extraction, and steady-state error calculation on voltage, current, and power waveforms acquired from HIL. It automatically compares numerical indicators with pass / fail criteria and generates a visual report with waveform screenshot annotations. The report supports both HTML and PDF output formats. All test records include complete timestamps, version information, and test environment metadata, ensuring full traceability.

[0065] Step 106: Construct a fitness function based on the test response data, iteratively evolve the test vector using a genetic mutation algorithm, and feed the test vector back to Step 105 to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

[0066] The genetic mutation test evolution process takes the code coverage matrix and fault trigger records of the current test round as input to maintain a test vector population. Then, iterative mutation optimization through an optimization algorithm generates the next generation of test vectors until the coverage converges, resulting in a standardized verification report. The fitness function is constructed by comprehensively considering both test code coverage and fault trigger probability. These two factors can be weighted to generate the fitness function, which ensures that the evolutionary direction always points to the test interval with the lowest coverage and the highest probability of hidden defects.

[0067] Further, step 106 includes: The test scenario is encoded into individual gene fragments based on the genetic mutation algorithm, and the fitness function is the weighted value of the test code coverage and the fault trigger probability in the current test round. The population is iteratively mutated using tournament selection, uniform crossover, and Gaussian mutation algorithms to generate a test vector population. The test vector population is fed back to step S5 to re-execute the closed-loop simulation test until the coverage converges to less than the coverage threshold, and a standardized verification report is generated.

[0068] Specifically, the scenarios in the test scenario script can be encoded as individual gene fragments, meaning that each individual represents a complete test scenario configuration. The gene fragment encoding includes fault type (three-phase symmetry / single-phase grounding / two-phase grounding / phase-to-phase short circuit, 4-bit unique thermal encoding), fault duration (continuous variable, ranging from 20ms to 5000ms), fault depth (voltage drop amplitude, 0% to 100% of rated voltage), frequency deviation (-5Hz to +5Hz), phase jump amplitude (-60° to +60°), fault recovery slope (0.1pu / s to 100pu / s), DC component injection amplitude (0% to 5% of rated current), and multi-fault superposition delay (0ms to 500ms).

[0069] A fitness function can be constructed by weighting the test code coverage and fault trigger probability in the current test round. In this embodiment, the weight of test code coverage is 0.6 and the weight of fault trigger probability is 0.4. Furthermore, this embodiment maintains a test vector population with a size of 50-200 individuals.

[0070] During fitness evaluation, the test scenario corresponding to each individual is executed on the HIL platform. The code branch coverage increment and fault detection probability triggered by the scenario are extracted, and then weighted and calculated together with the above weight values ​​to obtain the comprehensive fitness. After evaluation, a tournament selection algorithm is used to select parent individuals, and offspring are generated by uniform crossover with a crossover rate of 0.8. The offspring are randomly introduced into a Gaussian mutation algorithm with a mutation rate of 0.1 and a standard deviation of 5% of each gene range to generate the next generation population. The evolution here is limited to a maximum of 50 generations, or until the coverage converges. The convergence condition is that the increase in test code coverage between two consecutive generations is less than the coverage threshold of 0.1%.

[0071] Single-phase LVRT and two-phase grounding test cases were executed using the same method as the simulation test cases. After all three standard test cases passed, GA-Evolver was launched. Based on the branch coverage matrix of the three test cases, the first generation of 50 extended test vectors was generated, with an initial coverage of 68%. The following uncovered areas were explored in detail: the transition range with fault depth between 0.05 pu and 0.2 pu (current coverage 0%); ultra-brief faults with a fault duration of less than 20 ms (current coverage 0%); and multiple fault superposition scenarios, such as voltage dips superimposed with frequency deviations (current coverage 0%).

[0072] The standardized verification report generated in this embodiment includes multi-round test data, specifically waveform screenshots, pass / fail matrices, coverage heatmaps, and defect location lists. The standardized verification report is presented in a structured format. Specifically, it aggregates all test data and automatically generates an HTML format test report, including: a summary of the test environment, HIL platform model, tested controller version, and test date; detailed pass / fail records for three standard test cases; GA evolution process statistics, with a total of 423 test scenarios and coverage increasing from 68% to 91.3%; one defect found, including defect ID, triggering conditions, reproduction steps, controller response waveform screenshot, and deviation from acceptance criteria; and suggested repair directions, such as adjusting the active power slope limiting logic in the RESTORE state and adding a special processing branch for high-slope voltage recovery scenarios. A PDF version of the report is also output simultaneously, which can be directly used for project archiving.

[0073] Furthermore, step 106, followed by: New defect cases, effective test vectors, and verified V-ECU codes from the closed-loop simulation testing process are annotated and archived in the power electronics professional knowledge base.

[0074] Labeling and archiving the information generated during closed-loop simulation testing enables the continuous accumulation and automatic evolution of system knowledge, providing more complete and richer searchable information for subsequent retrieval, thus creating a virtuous cycle that optimizes the simulation testing effect.

[0075] Specifically, the discovered race condition defects are written into the vector database as new labeled fault test cases. These test cases include structured trigger condition data, waveform features, and defect classification labels. Simultaneously, the V-ECU code that passed this verification is archived as a new code template for future reference in similar projects. After the update, the knowledge accumulated in this verification will be useful in the RAG retrieval of the next similar project, enabling the system to continuously accumulate engineering experience and continuously improve the quality of code generation.

[0076] For example, after iteratively evolving the optimization algorithm to its 8th generation and executing approximately 420 test scenarios, a boundary defect was discovered. Specifically, when all three-phase voltages simultaneously dropped to 0.07 pu, falling between the most severe 0.05 pu and the single-phase 0.1 pu, and the recovery slope was extremely high (100 pu / s), meaning the voltage fully recovered within approximately 7 ms, the active power recovery slope control logic in the controller's RESTORE state encountered a race condition. This caused a brief overvoltage to the DC bus voltage of 710V, exceeding the control target of 650V by 9%, triggering an overvoltage protection alarm but not reaching the hardware overvoltage protection threshold of 800V. The measured active power recovery time was 1.18 s, slightly exceeding the 1-s acceptance requirement. This defect was recorded in the report, and the test vector triggering the defect and the controller response waveform were archived in the RAG knowledge base.

[0077] The automatic evolution closed-loop verification method for power electronic virtual controllers provided in this application automatically generates V-ECU code and test scenario scripts that conform to HIL platform constraints through domain fine-tuning of a large language model. This eliminates the reliance on manually generated template libraries. Standard updates only require timely updates to the knowledge base, eliminating the need for rewriting scripts and reducing labor and time costs. The generated template library is also more suitable for various scenario characteristics and has a higher reusability. In addition, a genetic mutation algorithm is used to optimize and update test vectors with coverage and failure probability as fitness, breaking through the limitations of fixed template operating conditions and actively exploring uncovered state machine branches and boundary vulnerabilities, so that test coverage is no longer limited to predefined scenario boundaries. Furthermore, V-ECU code that conforms to HIL constraints is directly generated and compiled and deployed through domain fine-tuning of a large language model. This process can achieve HIL closed-loop testing without hardware prototypes, has native V-ECU automatic generation capabilities, and supports pre-verification before hardware is available, making the verification process change from serial to parallel and significantly shortening the development cycle. Therefore, the embodiments of this application can solve the technical problems of existing HIL simulation testing, which relies on manual labor, resulting in low reuse rate and high cost. Its test scenario coverage is also limited by predefined boundaries and it does not have the ability to generate virtual controllers, resulting in low actual verification efficiency, insufficient coverage, long cycle, and difficulty in adapting to actual needs.

[0078] For easier understanding, please refer to Figure 2 This application provides an embodiment of an automatic evolution closed-loop verification device for a power electronic virtual controller, comprising: The data parsing unit 201 is used to perform entity recognition and structured parsing of natural language test intents to generate standardized test intent data; The suggestion construction unit 202 is used to construct enhanced suggestions by retrieving power electronics professional knowledge base based on standardized test intent data. The enhanced suggestions include standard clauses, fault cases and code snippets. The code generation unit 203 is used to automatically generate V-ECU code and test scenario scripts that conform to the constraints of the HIL platform from the enhanced prompt input domain fine-tuning large language model; Verification compilation unit 204 is used to perform multi-dimensional static constraint verification on V-ECU code and test scenario script. After the verification is passed, it is automatically compiled into a V-ECU image that can be executed by HIL and deployed. The simulation test unit 205 is used to connect the V-ECU image and the digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing and to obtain test response data, including test code coverage and fault trigger probability. The optimization verification unit 206 is used to construct a fitness function based on the test response data, iteratively evolve the test vector through a genetic mutation algorithm, and feed the test vector back to the simulation test unit to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

[0079] Furthermore, the data parsing unit 201 is specifically used for: A pre-defined entity recognition model is used to perform entity recognition on the natural language test intent, and the entity recognition results are obtained. The entity recognition results include standard entities, power level entities, topology entities, fault type entities, and performance index entities. After the entity recognition results are structured and filled in, the abnormal intent data is interactively completed to generate standardized test intent data.

[0080] This application also provides an automatic evolution closed-loop verification device for a power electronic virtual controller, the device including a processor and a memory; The memory is used to store program code and transfer the program code to the processor; The processor is used to execute the automatic evolution closed-loop verification method for the power electronic virtual controller in the above method embodiment according to the instructions in the program code.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0082] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0084] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for executing all or part of the steps of the methods described in the various embodiments of this application through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0085] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for automatic evolution closed-loop verification of a power electronic virtual controller, characterized in that, include: S1: Perform entity recognition and structured parsing on natural language test intent to generate standardized test intent data; S2: Enhanced prompts are constructed by retrieving power electronics professional knowledge bases based on standardized test intent data. The enhanced prompts include standard clauses, fault cases, and code snippets. S3: Automatically generate V-ECU code and test scenario scripts that conform to HIL platform constraints from the enhanced prompt input domain fine-tuning large language model; S4: Perform multi-dimensional static constraint verification on the V-ECU code and the test scenario script. After the verification is passed, automatically compile it into a V-ECU image that can be executed by HIL and complete the deployment. S5: Connect the V-ECU image and the digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing, and obtain test response data, including test code coverage and fault trigger probability. S6: Construct a fitness function based on the test response data, iteratively evolve the test vector through a genetic mutation algorithm, and feed the test vector back to step S5 to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

2. The automatic evolution closed-loop verification method for power electronic virtual controllers according to claim 1, characterized in that, Step S1 includes: A preset entity recognition model is used to perform entity recognition on the natural language test intent, and the entity recognition results are obtained. The entity recognition results include standard entities, power level entities, topology entities, fault type entities, and performance index entities. After the entity recognition results are structured and filled, the abnormal intent data is interactively completed to generate standardized test intent data.

3. The automatic evolution closed-loop verification method for power electronic virtual controllers according to claim 1, characterized in that, Step S2 includes: The standardized test intent data is encoded into a retrieval vector, and a similarity search is performed in the power electronics professional knowledge base to obtain multiple candidate knowledge fragments; The candidate knowledge fragments are subjected to contextual filtering based on semantic fine-ranking using a cross encoder to obtain the matching target fragments; The matched target fragment is concatenated with the standardized test intent data to construct an enhanced prompt.

4. The automatic evolution closed-loop verification method for power electronic virtual controllers according to claim 1, characterized in that, Step S4 includes: Pin mapping verification, timing constraint verification, coding standard verification, and state machine activity verification are performed sequentially on the V-ECU code and the test scenario script. If the verification fails, the verification error information will be fed back to the domain fine-tuning large language model to regenerate V-ECU code and test scenario scripts that conform to the HIL platform constraints. The verified V-ECU code and the test scenario script are automatically compiled into a HIL-executable V-ECU image and deployed.

5. The automatic evolution closed-loop verification method for power electronic virtual controllers according to claim 1, characterized in that, Step S5 includes: The V-ECU image and the digital power grid model are connected to the HIL real-time simulation engine, and electromagnetic transient real-time simulation is run with a preset step size not greater than the step size threshold. Based on the test scenario script, voltage dips, frequency disturbances, and phase jump fault excitations are injected into the simulation process, and simulated electrical quantities are collected at a preset sampling frequency. The simulated electrical quantities are compared and analyzed with preset criteria to obtain test response data.

6. The automatic evolution closed-loop verification method for power electronic virtual controllers according to claim 1, characterized in that, Step S6 includes: The test scenario is encoded into individual gene fragments based on the genetic mutation algorithm, and the fitness function is the weighted value of the test code coverage and the fault trigger probability in the current test round. The population is iteratively mutated using tournament selection, uniform crossover, and Gaussian mutation algorithms to generate a test vector population. The test vector population is fed back to step S5 to re-execute the closed-loop simulation test until the coverage converges to less than the coverage threshold, and a standardized verification report is generated.

7. The automatic evolution closed-loop verification method for power electronic virtual controllers according to claim 1, characterized in that, Step S6, followed by: New defect cases, effective test vectors, and verified V-ECU codes from the closed-loop simulation test process are annotated and archived into the power electronics professional knowledge base.

8. A power electronic virtual controller automatic evolution closed-loop verification device, characterized in that, include: The data parsing unit is used to perform entity recognition and structured parsing of natural language test intents to generate standardized test intent data. The suggestion construction unit is used to construct enhanced suggestions by retrieving power electronics professional knowledge base based on standardized test intent data. The enhanced suggestions include standard clauses, fault cases and code snippets. The code generation unit is used to automatically generate V-ECU code and test scenario scripts that conform to the HIL platform constraints from the enhanced prompt input domain fine-tuning large language model. The verification compilation unit is used to perform multi-dimensional static constraint verification on the V-ECU code and the test scenario script. After the verification is passed, it is automatically compiled into a HIL executable V-ECU image and deployed. The simulation test unit is used to connect the V-ECU image and the digital power grid model to the HIL real-time simulation engine for closed-loop simulation testing and to obtain test response data, including test code coverage and fault trigger probability. An optimized verification unit is used to construct a fitness function based on the test response data, iteratively evolve the test vector through a genetic mutation algorithm, and feed the test vector back to the simulation test unit to re-execute the closed-loop simulation test until the coverage converges and a standardized verification report is generated.

9. The automatic evolution closed-loop verification device for power electronic virtual controllers according to claim 8, characterized in that, The data parsing unit is specifically used for: A preset entity recognition model is used to perform entity recognition on the natural language test intent, and the entity recognition results are obtained. The entity recognition results include standard entities, power level entities, topology entities, fault type entities, and performance index entities. After the entity recognition results are structured and filled, the abnormal intent data is interactively completed to generate standardized test intent data.

10. An automatic evolution closed-loop verification device for a power electronic virtual controller, characterized in that, The device includes a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the automatic evolution closed-loop verification method for power electronic virtual controllers according to any one of claims 1-7, based on the instructions in the program code.

Images