A simulation scene switching method and device of a flexible direct control system, electronic equipment and storage medium

Abstract

The present application relates to the technical field of simulation switching, and particularly relates to a simulation scene switching method and device of a flexible direct control system, electronic equipment and a storage medium, which are used for improving switching efficiency, data consistency and system reliability of simulation scene switching. The method comprises the following steps: reading a model file of the flexible direct control system; generating runtime model instances of multiple scenes by using the model file; determining a current runtime model instance according to a start configuration; running the flexible direct control system by using the current runtime model instance to obtain a simulation result; when a running mode switching instruction is received, determining a target execution engine and a target runtime model instance according to the running mode switching instruction; obtaining state variables from the current runtime model instance and adding the state variables to the target execution engine according to a simulation virtual time axis; loading the target runtime model instance by using the target execution engine, running the flexible direct control system by using the target runtime model instance, and obtaining a simulation result after the running mode is switched.

Description

Technical Field

[0001] This invention relates to the field of simulation switching technology, and in particular to a simulation scene switching method, device, electronic device and storage medium for a flexible DC control system. Background Technology

[0002] With the deepening of the construction of new power systems, the scale of complex power electronic systems such as large-scale new energy grid connection, flexible DC transmission, and multi-terminal DC grids continues to expand, placing unprecedented demands on electromagnetic transient simulation technology. Before being put into field operation, the control and protection equipment of power systems must undergo thorough offline verification and online testing to ensure its correct operation under various working conditions. Traditional field testing is risky and costly; therefore, a testing and verification system based on a real-time simulation platform has become the industry standard. Against this backdrop, three simulation technologies—HIL (Hardware-in-the-Loop), SIL (Software-in-the-Loop), and PIL (Processor-in-the-Loop)—constitute a complete technical system for the full lifecycle verification of control and protection equipment. From algorithm development and code generation to final hardware integration, a closed-loop verification process based on Model-Basign (model-based design) is formed.

[0003] In the development of control and protection devices for actual engineering projects, teams typically need to frequently switch between three simulation scenarios: HIL, SIL, and PIL. During the initial algorithm design phase, engineers use SIL for rapid iterative verification; after code generation, they switch to PIL to verify code correctness and processor performance; and during system integration, they switch back to HIL for final closed-loop testing. Each scenario switch requires not only reconfiguring simulation platform parameters but also adjusting model interfaces, recompiling and linking, and manually comparing and verifying the continuity of simulation results. The entire switching process can take anywhere from several hours to several days.

[0004] Currently, mainstream real-time simulation platforms (such as RSCAD from RTDS Technologies and RT-LAB from OPAL-RT) provide their own independent HIL and SIL functional modules, each designed based on an independent software architecture and interface specifications. In existing solutions, engineers need to maintain multiple independent model files and configuration scripts for different simulation scenarios. When switching modes, they need to manually modify the model's I / O interface definition, change solver parameters (step type, solution algorithm), and reconfigure the I / O board driver to complete the mode switching.

[0005] However, the above solution has the following drawbacks: Poor switching efficiency: Existing solutions use different signal interface definition specifications for HIL and SIL modes. Specifically, in HIL mode, signals need to be mapped to physical I / O channels (including hardware parameters such as range, bias, and gain), while in SIL mode, signals exist as pure software variables. The interface description file formats of the two are completely incompatible. Engineers must manually modify ten to hundreds of signal mapping relationships each time they switch, resulting in a large amount of repetitive work and making it highly susceptible to human error, leading to unreliable test results.

[0006] Data inconsistency: HIL uses a fixed-step real-time operation, SIL uses a variable-step accelerated operation, and PIL uses a special cycle aligned with the processor cycle. The simulation data generated by these three modes have fundamental differences in density and alignment on the time axis. Existing solutions do not provide a unified time base conversion mechanism, resulting in misalignment of simulation waveforms before and after the switch on the time axis. Engineers cannot directly overlay and compare them, and need to use additional post-processing tools for time alignment, which is labor-intensive and has limited alignment accuracy.

[0007] The lack of a state preservation mechanism leads to simulation interruptions during scene switching, resulting in poor system reliability: Existing solutions require the simulation system to completely stop, reload the model, and start from scratch when switching scenarios, causing the loss of all internal states (such as integrator states, filter history values, and controller state variables). This means that after each switch, it is necessary to wait for the system to establish a steady state again. In scenarios requiring long startup processes, such as new energy control systems, this waiting time can be as long as tens of minutes, severely reducing testing efficiency. Summary of the Invention

[0008] This invention provides a simulation scene switching method, device, electronic equipment, and storage medium for a flexible direct current control system, which solves the technical problems of poor switching efficiency, data consistency, and system reliability in existing real-time simulation platforms.

[0009] This invention provides a simulation scene switching method for a flexible-conductive control system, comprising: Read the model file of the flexible-vertical control system; The model file is used to generate runtime model instances for various scenarios; Obtain the startup configuration and determine the currently running model instance based on the startup configuration; The flexible-vertical control system is run using the current runtime model instance to obtain simulation results; When a runtime mode switching instruction is received, the target execution engine and the target runtime model instance are determined according to the runtime mode switching instruction; The state variables are obtained from the current runtime model instance and added to the target execution engine according to the simulation virtual timeline; The target runtime model instance is loaded through the target execution engine, and the flexible-conductor control system is run using the target runtime model instance to obtain the simulation results after the operation mode is switched.

[0010] Optionally, the step of generating runtime model instances for multiple scenarios using the model file includes: Parse the model structure definition, parameter definition, signal interface definition, and scene adaptation annotation in the model file; The intermediate representation of the model is generated using the model structure definition, the parameter definition, the signal interface definition, and the scene adaptation annotation; The intermediate representation of the model is normalized to obtain a scene-independent main model; Based on the scenario-independent master model, a configuration suitable for real-time execution with a fixed step size is extracted, and a HIL instance for a hardware-in-the-loop simulation scenario is generated according to the configuration. Based on the scenario-independent master model, a SIL runtime graph suitable for variable step size solution is extracted, and the SIL runtime graph is used to generate a SIL instance of the software-in-the-loop simulation scenario. The scenario-independent master model is split into a control algorithm part and an object model part, and the control algorithm part and the object model part are used to generate a PIL instance of the processor-in-the-loop simulation scenario; Standard signal descriptors corresponding to the HIL instance, SIL instance, and PIL instance are generated respectively, and the HIL instance, SIL instance, and PIL instance are bound to the corresponding standard signal descriptors to obtain runtime model instances corresponding to the HIL instance, SIL instance, and PIL instance respectively.

[0011] Optionally, it also includes: Generate semantic mapping tables for the HIL instance, the SIL instance, and the PIL instance.

[0012] Optionally, the model file includes several interface signals; after the step of generating runtime model instances for multiple scenarios using the model file, the method further includes: Perform structural consistency checks, parameter consistency checks, and interface completeness checks on all instances of the runtime model. When the verification passes, each of the standard signal descriptors is registered in the global signal registry.

[0013] Optionally, the step of obtaining state variables from the current runtime model instance and adding the state variables to the target execution engine according to the simulation virtual timeline includes: Send a switching request flag to the current execution engine through the scene switching controller; When the scene switching controller receives a checkpoint arrival notification returned by the current execution engine, it extracts state variables from the current runtime model instance and adds the state variables to the target execution engine through the semantic mapping table according to the simulation virtual time axis. The checkpoint arrival notification is generated by the current execution engine after completing the current simulation step and pausing the execution of the current runtime model instance at the next safety checkpoint.

[0014] Optionally, before the step of loading the target runtime model instance through the target execution engine, running the flexible-contraction control system using the target runtime model instance, and obtaining the simulation results after the operation mode switch, the method further includes: Perform consistency verification between the current execution engine and the target execution engine; The steps of loading the target runtime model instance through the target execution engine, running the flexible-conductor control system using the target runtime model instance, and obtaining simulation results include: When the consistency verification passes, the target runtime model instance is loaded through the target execution engine, and the flexible vertical control system is run using the target runtime model instance to obtain the simulation results after the operation mode switch.

[0015] Optionally, it also includes: If the consistency verification fails, switch back to the initial running mode.

[0016] The present invention also provides a simulation scene switching device for a flexible direct current control system, characterized in that it includes: The model file reading module is used to read the model files of the flexible vertical control system; The runtime model instance generation module is used to generate runtime model instances for various scenarios using the model file. The current running model instance determination module is used to obtain the startup configuration and determine the current running model instance based on the startup configuration; The first simulation result generation module is used to run the flexible-vertical control system using the current runtime model instance to obtain simulation results; The target execution engine and target runtime model instance determination module is used to determine the target execution engine and target runtime model instance according to the running mode switching instruction when a running mode switching instruction is received; The state variable addition module is used to obtain state variables from the current runtime model instance and add the state variables to the target execution engine according to the simulation virtual time axis; The second simulation result generation module is used to load the target runtime model instance through the target execution engine, run the flexible-vertical control system using the target runtime model instance, and obtain the simulation results after the operation mode is switched.

[0017] The present invention also provides an electronic device, the device comprising 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 simulation scene switching method as described above according to the instructions in the program code.

[0018] The present invention also provides a computer-readable storage medium for storing program code for executing the simulation scene switching method as described in any of the preceding claims.

[0019] As can be seen from the above technical solutions, the present invention has the following advantages: The present invention discloses a simulation scene switching method for a flexible vertical control system, specifically disclosing: reading the model file of the flexible vertical control system; generating runtime model instances for multiple scenarios using the model file; obtaining the startup configuration and determining the initial operating mode and the current operating model instance based on the startup configuration; running the flexible vertical control system using the current operating model instance to obtain simulation results; when a running mode switching command is received, determining the target execution engine and the target runtime model instance based on the running mode switching command; obtaining state variables from the current runtime model instance and adding the state variables to the target execution engine according to the simulation virtual time axis; loading the target runtime model instance through the target execution engine, running the flexible vertical control system using the target runtime model instance to obtain simulation results. The present invention realizes the temporal correlation of state variables of different operating scenarios through the simulation virtual time axis, thereby achieving semantic consistency conversion of signals between systems with different time steps, ensuring that simulation data before and after switching can be directly superimposed and compared on a unified time axis, thereby improving the switching efficiency, data consistency, and system reliability of simulation scene switching. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a simulation scene switching system structure diagram of a flexible-conductive control system provided in an embodiment of the present invention; Figure 2 Hierarchical dependency relationship and information flow diagram among the functional modules of the simulation scene switching system of the flexible-contact control system provided in the embodiments of the present invention; Figure 3 This is a diagram illustrating the working principle of signal routing in the interface abstraction layer. Figure 4 A flowchart illustrating the steps of a simulation scene switching method for a flexible-conductive control system provided in an embodiment of the present invention; Figure 5 A schematic diagram illustrating the working principle of seamless switching of simulation scenarios for the state management layer; Figure 6 A schematic diagram illustrating the unified principle of the virtual time axis for the rate conversion layer simulation; Figure 7 A schematic diagram of the seamless transition process from SIL to HIL; Figure 8 A diagram showing the collaborative relationships between the signal descriptor registration mechanism, the virtual time axis (VTA), the security checkpoint mechanism, the semantic mapping table (SMT), and the seven-state control (FSM). Figure 9 This is a structural block diagram of a simulation scene switching device for a flexible direct current control system provided in an embodiment of the present invention. Detailed Implementation

[0022] This invention provides a simulation scene switching method, device, electronic device, and storage medium for a flexible DC control system, which solves the technical problems of poor switching efficiency, data consistency, and system reliability in existing real-time simulation platforms.

[0023] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0024] Please see Figure 1 , Figure 1 This is a structural diagram of a simulation scene switching system for a flexible DC control system provided in an embodiment of the present invention. Figure 2 The hierarchical dependency relationship and information flow diagram between the functional modules of the simulation scene switching system provided in the embodiments of the present invention.

[0025] This invention provides a simulation scene switching system, including a simulation application layer, a middleware core layer, and an execution engine layer. The simulation application layer includes a simulation model management module (MMM). The middleware core layer includes an interface abstraction layer module (IALM), a rate conversion layer module (RCLM), a state management layer module (SMLM), and a scene switch controller module (SSCM). The execution engine layer includes multiple execution engine modules, such as the SIL Accelerated Engine Module (SAEM) and the PIL Processor-aligned Engine Module (PPEM).

[0026] HIL (Hardware-in-the-Loop): HIL simulation is a technique that embeds real physical hardware devices into a simulation closed-loop system for testing. In the field of electromagnetic transient simulation of power systems, HIL typically refers to connecting actual hardware devices such as controllers, protection devices, or power converters to a real-time simulation platform. The simulation platform runs the digital model of the system under test in real time at fixed steps (usually in the microsecond range, such as 1μs to 50μs), interacting with the real hardware through analog / digital I / O interfaces, thereby achieving high-fidelity testing and verification of the actual physical system in a laboratory environment.

[0027] SIL (Software-in-the-Loop): SIL simulation refers to the technology of running control algorithms or protection logic as pure software on a simulation platform, forming a closed-loop simulation system together with the model of the system under test. SIL does not require real hardware; all components exist in software form. Therefore, variable step-size solvers can be used to accelerate simulation, achieving simulation speeds tens to hundreds of times faster than real-time speeds. It is widely used in the initial verification of control algorithms, parameter tuning, and large-scale automated regression testing scenarios, and is a key means to reduce development costs and shorten verification cycles.

[0028] PIL (Processor-in-the-Loop): PIL simulation is an intermediate verification layer between SIL and HIL. Its core feature is that the control algorithm is compiled into executable code for the target processor and runs on the actual target processor chip (such as DSP, ARM, FPGA, etc.), while the controlled object model still runs in software on the simulation host. The two exchange data through serial communication or a dedicated interface. PIL can accurately simulate the low-level characteristics of the target processor, such as instruction execution cycle, fixed-point arithmetic truncation error, and interrupt latency, and is an effective means of discovering software and hardware coordination problems.

[0029] Simulation model management module: The simulation model management module is responsible for the unified management of simulation model files for HIL, SIL, and PIL scenarios. This module adopts the design concept of "Scene-Independent Model" (SIM), requiring all simulation models to be developed and stored using a unified model description format (Extended Model Description Language, XML-based). The XMDL format model file contains four parts: model structure definition, parameter definition, signal interface definition, and scenario adaptation annotations. Scenario adaptation annotations are the core innovation of this module, allowing users to declaratively annotate the adaptation rules for a signal or parameter in different scenarios without writing scenario judgment logic code. During system initialization, the model management module parses the XMDL file, generates runtime model instances for each simulation scenario, and registers the interface information of the instances to the interface abstraction layer.

[0030] Interface Abstraction Layer Module: The Interface Abstraction Layer (API) module contains three adapter sub-modules: the HIL adapter, the SIL adapter, and the PIL adapter. The API provides a unified signal read / write API (ReadSignal / WriteSignal) and parameter configuration API (SetParameter / GetParameter). All upper-layer modules interact with signals through these two APIs without needing to concern themselves with underlying implementation differences. The HIL adapter maintains a physical channel mapping table, recording the mapping relationship between each standard signal descriptor and the physical I / O board channel. It is responsible for performing engineering unit conversion during read / write operations, converting the raw ADC / DAC values ​​of the physical channel into physically meaningful engineering quantities (such as per-unit values ​​of voltage and current). The SIL adapter achieves high-speed signal exchange between processes through shared memory segments and POSIX semaphore mechanisms, with latency below 1μs. The PIL adapter establishes a communication link with the target processor development board via USB-JTAG or Ethernet UDP protocols, enabling microsecond to sub-millisecond data frame transmission and reception.

[0031] When a simulation model reads a signal value via the unified API call `ReadSignal(signal_uuid)` during runtime, the IALM runtime scheduler automatically routes the read operation to the corresponding adapter submodule based on the currently active simulation scenario. Before returning, it performs engineering quantity conversion to ensure that the upper-layer model always receives standard engineering quantity values ​​with unified physical meaning. The execution logic for write operations (`WriteSignal`) is similar. IALM is responsible for converting the standard engineering quantity value into the format required by the target scenario and then writing it to the corresponding underlying channel or shared memory area.

[0032] like Figure 3 As shown, Figure 3 This diagram illustrates the working principle of signal routing in the interface abstraction layer. All read and write operations of the user model are uniformly routed and distributed through the Global Signal Registry (GSR). Based on the currently active simulation scenario, the GSR dynamically routes requests to one of the HIL, SIL, or PIL adapters. These three adapters are responsible for translating standard signal descriptors into specific low-level operations for each scenario, achieving complete uniformity at the interface level. During scenario switching, the routing pointer in the GSR is atomically updated; the entire rebinding process is invisible to the user model, ensuring transparency during switching.

[0033] Rate conversion layer module: The rate conversion layer module manages the virtual time axis (VTA) and performs signal interpolation and decimation operations. Internally, this module maintains a sliding window data buffer, the size of which is dynamically adjusted based on the ratio of the current simulation step size to the target simulation step size, accommodating a maximum of 1024 sampling points. The interpolation algorithm library includes three algorithms: linear interpolation (suitable for auxiliary signals with lower accuracy requirements), fourth-order Hermite interpolation (suitable for main electrical signals), and B-spline interpolation (suitable for control reference signals). Users can specify the corresponding interpolation algorithm for each signal through parameter configuration. Before performing downsampling, the decimation algorithm performs low-pass filtering (using an IIR Chebyshev Type II filter) on the signal to prevent spectral aliasing and ensure that the frequency content of the decimated signal remains consistent with the original signal.

[0034] State Management Module: The state management layer module implements complete lifecycle management of simulation states. This module interacts with the simulation engine via a hook interface, triggering state serialization when the engine reaches a safety checkpoint. State serialization uses the Google Protocol Buffer (Protobuf) format, offering fast serialization speeds (typically completing state serialization for a medium-sized simulation system within 100 milliseconds) and compact serialization results (for a system with 5000 state variables, the serialization file size is typically between 1 and 5 MB). The state transition process supports both online migration (immediate migration after simulation pause) and offline migration (exporting the state package file first, then importing it into the target environment), meeting the needs of different engineering scenarios.

[0035] Scene switching controller module: The scene switching controller module is the scheduling core driving the entire switching process. This module uses a finite state machine (FSM) to achieve precise control of the switching process, defining seven states: IDLE, SWITCH_PREPARING, STATE_SNAPSHOT, ENGINE_SWITCHING, STATE_RESTORE, VERIFICATION, and RUNNING, along with corresponding state transition conditions and timeout protection mechanisms. The controller receives switching instructions (containing the target scene type and optional switching timestamp parameters) from the user interface or automated test scripts and coordinates the modules to complete the switching operation according to the predetermined switching sequence.

[0036] HIL Real-Time Execution Engine Module: The HIL Real-Time Execution Engine module is a fixed-step real-time execution engine optimized for HIL simulation scenarios. This engine runs on a Real-Time Operating System (RTOS) environment (preferably based on a Linux real-time kernel with the PREEMPT_RT patch), and ensures simulation step jitter is less than 100 nanoseconds through CPU core affinity and interrupt affinity configuration. The engine's numerical integration uses a 4th-order Runge-Kutta fixed-step algorithm, and at the end of each simulation step, it exchanges data with the physical I / O board via DMA, ensuring I / O latency is less than one simulation step.

[0037] SIL Accelerated Execution Engine Module: The SIL accelerated execution engine module employs a variable step-size adaptive solver, supporting dynamic switching between multiple solver algorithms such as DASSL, Radau, and CVODE. Internally, the engine implements a multi-threaded parallel computing framework, utilizing OpenMP to solve the various subsystems of the simulation model in parallel, achieving near-linear speedup in multi-core processor environments. The engine's running speed automatically adjusts within a range of 1 to 200 times the real-time speed based on system stiffness, and provides an external simulation progress interface for the state management layer to query the current simulation virtual time.

[0038] PIL processor aligned execution engine module: The core feature of the PIL processor-aligned execution engine module is that it uses the target processor's control interrupt cycle T_PIL as the simulation step size reference, ensuring that the controlled object model on the simulation host and the control code on the target processor are strictly synchronized on the virtual timeline. This engine synchronizes with the target processor through hardware handshake signals (RDY / ACK). After completing each T_PIL simulation step, it waits for the target processor to process the data for that cycle and send an ACK signal before continuing to the next step, thus accurately simulating the interaction timing between the controller and the controlled object in a real hardware scenario.

[0039] Based on the above simulation scenario switching system, please refer to Figure 4 , Figure 4 A flowchart illustrating the steps of a simulation scene switching method for a flexible direct current control system provided in an embodiment of the present invention.

[0040] The present invention provides a simulation scene switching method, which may specifically include the following steps: Step 401: Read the model file of the flexible vertical control system; In this embodiment of the invention, the Simulation Model Management Module (MMM) first reads the XMDL format model file of the flexible DC control system. This file contains the electromagnetic transient model of the ±500kV flexible DC system (including the MMC converter model, DC line distributed parameter model, and AC system equivalent model), the converter control system model (including sub-modules such as current inner loop control, voltage outer loop control, circulating current suppression control, and modulation algorithm), and interface definitions (containing approximately 350 signal interfaces, covering three-phase voltage, three-phase current, DC voltage, DC current, trigger pulse signal, and switching I / O).

[0041] Step 402: Use the model file to generate runtime model instances for various scenarios; In this embodiment of the invention, the model management module can parse the model file and generate three sets of runtime model instances corresponding to HIL, SIL, and PIL scenarios, respectively.

[0042] In one example, step 402 may include the following sub-steps: S21, parse the model structure definition, parameter definition, signal interface definition and scene adaptation annotation in the model file; S22, the intermediate representation of the model is generated using the model structure definition, the parameter definition, the signal interface definition, and the scene adaptation annotation; S23, Normalize the intermediate representation of the model to obtain a scene-independent main model; S24, Based on the scenario-independent master model, extract the configuration suitable for real-time execution with a fixed step size, and generate a HIL instance of the hardware-in-the-loop simulation scenario according to the configuration; S25, Based on the scenario-independent master model, extract the SIL runtime graph suitable for variable step size solution, and use the SIL runtime graph to generate a SIL instance of the software-in-the-loop simulation scenario; S26, the scene-independent master model is split into a control algorithm part and an object model part, and the control algorithm part and the object model part are used to generate a PIL instance of the processor-in-the-loop simulation scene; S27, generate standard signal descriptors corresponding to the HIL instance, the SIL instance, and the PIL instance respectively, and bind the HIL instance, the SIL instance, and the PIL instance to the corresponding standard signal descriptors to obtain runtime model instances corresponding to the HIL instance, the SIL instance, and the PIL instance respectively; S28. Generate a semantic mapping table for the HIL instance, the SIL instance, and the PIL instance.

[0043] In the specific implementation, the process of generating runtime model instances is as follows: 1. XMDL parsing and intermediate representation construction: MMM first parses the model structure definition, parameter definition, signal interface definition, and scene adaptation annotation in the XMDL file to generate a unified intermediate representation (IR). The IR contains module topology, directed signal connection graph, state variable table, parameter table, sampling attributes, and scene annotation information.

[0044] 2. Scene-independent master model normalization: Normalization processing is performed on the IR, including unified variable naming, topological sorting, parameter default value filling, unit checking, dimensional consistency verification, and classification and registration of continuous state, discrete state, algebraic variables and I / O ports to form a scene-independent master model.

[0045] 3. HIL instance generation: Based on the scenario-independent master model, a subset and configuration suitable for fixed-step real-time execution are extracted. Specifically, this includes: solidifying the solution settings into a fixed-step mode; discretizing or mapping continuous modules into HREM executable forms; generating physical I / O mapping tables, board configuration tables, and engineering quantity conversion parameters based on scenario adaptation annotations; and compiling / instantiating runtime data structures into fixed-length arrays, circular buffers, and real-time task objects, ultimately forming a HIL runtime instance.

[0046] 4. SIL Instance Generation: Based on the scenario-independent master model, generate a SIL runtime graph suitable for variable step-size solutions. Specifically, this includes: preserving continuous state equations and event equations; constructing DASSL / Radau / CVODE-recognizable state vectors, residual functions, and Jacobian interfaces; generating shared memory variable tables, software signal ports, and debug observation points; and organizing runtime objects into data structures that support dynamic step-size and parallel solutions to form SIL runtime instances.

[0047] 5. PIL Instance Generation: Based on the scene-independent master model, the control algorithm part and the object model part are separated. Specifically, the object model is retained on the host side to form a PPEM executable instance; the controller part is exported as a target processor code image or a processor-side executable module according to the scene annotations; at the same time, the processor communication frame description, byte layout, scaling factor, fixed-point / floating-point format and RDY / ACK synchronization configuration are generated, and finally a PIL runtime instance is formed.

[0048] 6. State Semantic Mapping Generation: During the generation of the three sets of instances, MMM synchronously establishes the correspondence between state variables and storage locations, automatically generates SMT, and records the address description, data type and conversion rules of the same semantic state in the three instances of HIL / SIL / PIL, in preparation for subsequent state migration.

[0049] 7. Standard Signal Descriptor Binding: A standard signal descriptor is generated for each external signal and internal key state. The scenario adaptation annotation field in the descriptor records the physical I / O mapping of the signal in the HIL scenario (e.g., a three-phase voltage signal is mapped to channels 1 to 3 of the analog output board of the HIL simulation box, with a range of ±10V corresponding to ±1.0 per unit value), the shared memory mapping in the SIL scenario (e.g., the voltage signal corresponds to the offset 0x000 to 0x00B of the shared memory segment ID 0x0001), and the frame mapping in the PIL scenario (e.g., using Q15 format encoding, located in bytes 12 to 17 of the communication frame). Then, the RegisterSignal interface of IAL is called to register all 350 signal descriptors in batches to the Global Signal Registry (GSR).

[0050] GSR is a hash map table with signal unique identifiers (UUIDs) as keys. Each record contains specific binding information for the signal in three scenarios: HIL, SIL, and PIL. For the HIL scenario, the binding information includes the physical board number, channel number, electrical range (e.g., ±10V corresponds to ±1.0 per unit), and sampling filter parameters. For the SIL scenario, the binding information includes the shared memory base address and offset, memory barrier policy, and semaphore identifier. For the PIL scenario, the binding information includes the communication frame format, byte offset, data type (fixed-point or floating-point), and scaling factor.

[0051] In this embodiment of the invention, after step 402, the method may further include: performing structural consistency verification, parameter consistency verification, and interface completeness verification on all the runtime model instances; when the verification passes, registering each of the standard signal descriptors to the global signal registry.

[0052] Step 403: Obtain the startup configuration and determine the currently running model instance based on the startup configuration; In this embodiment of the invention, after generating runtime model instances for multiple scenarios, the Scenario Switching Controller (SSCM) module can determine the initial running mode and the current running model instance based on the startup configuration.

[0053] In a specific implementation, the initial operating mode can be determined in the following ways: 1. User explicit specification: Users can specify the initial_scene parameter in the simulation management interface, project configuration file or startup script, for example, initial_scene=SIL / HIL / PIL. SSCM will activate the corresponding scene according to this parameter after initialization.

[0054] 2. Default Project Template: If the user does not explicitly specify a template, the system will automatically select the initial scenario based on the preset project template. For control and protection algorithm development and parameter tuning scenarios, SIL is selected as the initial running mode by default because SIL has variable step size acceleration capability, which is suitable for quickly establishing steady state and completing initial verification.

[0055] 3. Hardware availability constraints: If the HIL physical I / O board is not ready, the target processor is not connected, or the PIL handshake fails during startup, SSCM will not select the corresponding mode as the initial scenario, but will fall back to SIL as the runnable default mode.

[0056] 4. Automated testing strategy: In batch regression testing or CI process, the test script can automatically pass in the initial mode according to the test case type; for example, algorithm correctness test cases default to SIL, processor code verification test cases default to PIL, and integration and acceptance test cases default to HIL.

[0057] In this embodiment of the invention, SIL is preferred as the initial operating mode because the flexible DC system requires a long simulation time to enter steady state from cold start. SIL can quickly complete steady state establishment and parameter tuning with about 50 times the real-time speed. Then, switch to HIL for closed-loop hardware verification. The overall testing efficiency is the highest.

[0058] Step 404: Run the flexible-vertical control system using the current runtime model instance to obtain simulation results; Taking the initial operating mode as SIL as an example, the scene switching controller first configures the system to SIL operating mode, and then the scene routing table of the interface abstraction layer module switches to the SIL adapter. The SIL accelerated execution engine runs the flexible vertical control system using the current runtime model instance, starts the simulation with the DASSL variable step size solver, sets the initial step size to 10μs, the maximum step size limit to 100μs, and the relative error tolerance to 1e. -6 .

[0059] In SIL mode, the simulation runs at approximately 50 times the real-time speed. The flexible DC system takes about 30 seconds in reality to establish stable operating conditions (DC voltage reaches rated value ±500kV, active / reactive power reaches set values) from a cold start (corresponding to approximately 25 minutes of simulation time). During this process, control engineers adjust the controller parameters in real time, quickly verifying the steady-state and dynamic performance of the control algorithm through SIL simulation. After confirming the control strategy is correct, they decide to switch to the HIL scenario for closed-loop hardware verification.

[0060] The Rate Conversion Layer (RCLM) module operates continuously during SIL operation, converting the variable step size data stream generated by SAEM to the VTA coordinate system and maintaining a sliding window buffer of 512 sampling points to store the most recent historical signal data, providing data support for subsequent interpolation operations.

[0061] Step 405: When a running mode switching instruction is received, the target execution engine and the target runtime model instance are determined according to the running mode switching instruction; In this embodiment of the invention, when a running mode switching instruction is received, the target execution engine and the target runtime model instance can be determined according to the running mode switching instruction.

[0062] Taking switching to the HIL scenario as an example, the running mode switching command can be triggered through the simulation management interface, such as by clicking the "Switch to HIL Scenario" button, or by calling the switching API through a Python automated test script: switch_manager.request_scene_switch( target_scene="HIL", switch_timestamp=None, # None indicates that the switch will occur immediately at the next security checkpoint. state_migration=True, # Enable state migration verification_enabled=True # Enable verification after switching ).

[0063] Step 406: Obtain state variables from the current runtime model instance, and add the state variables to the target execution engine according to the simulation virtual time axis; After determining the target execution engine and the target runtime model instance, state variables can be obtained from the current runtime model instance and added to the target execution engine according to the simulation virtual timeline.

[0064] In one example, step 406 may include the following sub-steps: S61, send a switching request flag to the current execution engine through the scene switching controller; S62, when the scene switching controller receives the checkpoint arrival notification returned by the current execution engine, it extracts the state variables from the current runtime model instance and adds the state variables to the target execution engine through the semantic mapping table according to the simulation virtual time axis. The checkpoint arrival notification is generated by the current execution engine after completing the current simulation step and pausing the execution of the current runtime model instance at the next safety checkpoint.

[0065] In the specific implementation, the Scene Switching Controller (SSCM) module's FSM transitions from the IDLE state to the SWITCH_PREPARING state, records the switching request parameters, sends a switching request flag to the current execution engine, and notifies the target execution engine to start preheating.

[0066] After completing the current simulation step, the current execution engine detects the switch request flag and actively pauses execution at the next safety checkpoint (i.e., when the current simulation step calculation is completed, the integrator history items have been updated, and the discrete event queue has been processed) and sends a checkpoint reached (CHECKPOINT_REACHED) notification to the SSCM.

[0067] Next, the SSCM's FSM migrates to the STATE_SNAPSHOT state and calls the State Management Module (SMLM) to perform serialization. The SMLM traverses the Semantic Map Table (SMT) and extracts all state variables from the current execution engine to add to the target execution engine.

[0068] SMLM is the foundation for achieving seamless switching between different scenarios. It specifically includes two core mechanisms: a security checkpoint mechanism and a state semantic mapping mechanism. Safety Checkpoint Mechanism: The simulation engine cannot safely serialize its state at all times during execution. This is because at certain execution phases (such as matrix inversion or updating historical items across time steps), the simulation state is in an intermediate, inconsistent state, and serialization at this point would result in an erroneous state snapshot. Therefore, this invention defines a set of safety checkpoints in each simulation engine. Safety checkpoints are located in the gap between the completion of each complete simulation step and the start of the next step, at which point the simulation system is in a completely deterministic, serializable, and consistent state. Upon receiving a switching request, the scene switching controller does not immediately interrupt the engine. Instead, it sets a switching request flag. After completing the calculation of the current step, the engine detects this flag and proactively pauses execution at the next safety checkpoint, notifying the state management layer to begin serialization.

[0069] State Semantic Mapping Mechanism: The internal data structures of the three simulation engines differ (e.g., the HIL engine uses a fixed-length array to store state vectors, the SIL engine uses a dynamic linked list, and the PIL engine's states are distributed in both the target processor's memory and the simulation host's memory). State data cannot be simply copied and migrated; it must be transformed through semantic mapping. The Semantic Mapping Table (SMT) is automatically generated by the simulation model management module during system initialization. It records the name, physical meaning, data type, and storage location descriptor of each state variable within the internal data structures of the three engines. During state serialization, the SML traverses the SMT, extracts the value of each state variable from the current engine, and assembles it into a scene-independent intermediate state package (ISP). During state recovery, the SML traverses the ISP, injects each state variable into the corresponding storage location of the target engine according to the storage location descriptor in the SMT, and completes the state transition.

[0070] like Figure 5 As shown, Figure 5 This diagram illustrates the working principle of seamless scene switching for the state management layer. Upon triggering a switching request, the simulation engine proactively pauses at a safety checkpoint and then initiates a state serialization operation, compressing all internal state variables into an intermediate state packet (ISP) independent of the engine. The semantic mapping table (SMT) plays a crucial role in this process, ensuring the physical semantics of the state data remain intact during the conversion from the source engine format to the target engine format. Finally, the state data is injected into the target engine, which resumes running from the precise point in time of the source simulation, achieving truly seamless scene switching.

[0071] It should be noted that, as Figure 6 As shown, the simulation virtual time axis (VTA) is a monotonically increasing unsigned 64-bit integer counter, initially set to 0 with a minimum resolution of 1 nanosecond, and continuously increasing throughout the simulation lifetime. The timestamps of the three simulation modes are converted to their corresponding VTA timestamps upon entering the rate conversion layer, with the conversion relationship as follows: HIL mode: VTA_timestamp = step_count × Δt_HIL_ns, where Δt_HIL_ns is the nanosecond value of the HIL step size; SIL mode: VTA_timestamp = the nanosecond value of the accumulated solution time, which is directly provided by the high-precision clock maintained internally by the variable step size solver; PIL mode: VTA_timestamp = control_interrupt_count × T_PIL_ns + communication_latency_compensation_ns, where the communication latency compensation value is automatically calibrated by the PIL processor alignment engine during the initialization phase through round-trip time (RTT) measurement.

[0072] When the system switches from HIL to SIL, RCL detects the relationship between the target step size (SIL variable step size, which may be much smaller than the HIL fixed step size) and the source step size, and automatically starts the upsampling (interpolation) mode: using the nearest sampling points in the HIL data buffer as control points, the Hermite interpolation algorithm is used to generate several dense interpolation samples in the VTA interval between two HIL sampling points for use by the SIL solver. During the reverse switch (SIL to HIL), RCL detects the need for downsampling, first applying a low-pass filter with a cutoff frequency of f_Nyquist_HIL = 1 / (2×Δt_HIL) to the high-density SIL data stream for anti-aliasing processing, and then uniformly decimating the data according to the HIL step size to generate the fixed-step data stream required by HIL.

[0073] For the PIL scenario, since the communication of the target processor has a fixed delay (usually in the range of 50μs to 500μs), RCL uses a delay compensation mechanism to shift the PIL data points forward by the corresponding compensation amount on the VTA time axis, so that the logical position of the PIL data on the VTA is precisely aligned with its corresponding actual simulation time.

[0074] In this embodiment of the invention, after transferring the state variables of the current runtime model instance to the target execution engine, the method further includes: performing a consistency verification between the current execution engine and the target execution engine; if the consistency verification fails, switching back to the initial running mode.

[0075] Step 407: Load the target runtime model instance through the target execution engine, run the flexible-vertical control system using the target runtime model instance, and obtain the simulation results after the operation mode switch.

[0076] In this embodiment of the invention, when the consistency verification passes, the target runtime model instance can be loaded through the target execution engine, and the flexible vertical control system can be run using the target runtime model instance to obtain the simulation results after the operation mode switch.

[0077] In one example, such as Figure 7 As shown, taking the switch from SIL to HIL as an example, the switching process is as follows: The Scene Switching Controller (SSCM) transitions its FSM from the IDLE state to the SWITCH_PREPARING state, records the switching request parameters, and sends a switching request flag to the SAEM. Simultaneously, it notifies the HIL Real-Time Execution Engine (HREM) to begin pre-warming. During the pre-warming phase, the HREM loads the HIL runtime model instance of the flexible vertical shaft system, configures the channel parameters of the physical I / O boards (automatically configuring the channel mapping, range, and filtering parameters of 350 signals based on the HIL binding information in the GSR), and completes the RTOS task scheduling configuration (binding the CPU core to the real-time core and configuring interrupt affinity to the dedicated interrupt controller), putting the HREM in a "ready to inject" state. The entire pre-warming process takes approximately 5 seconds.

[0078] After completing the current simulation step, SAEM detects the switch request flag and actively pauses execution at the next safety checkpoint (i.e., when the current simulation step calculation is completed, the integrator history has been updated, and the discrete event queue has been processed) and sends a CHECKPOINT_REACHED notification to SSCM.

[0079] The SSCM's FSM migrates to the STATE_SNAPSHOT state and calls the State Management Layer (SMLM) to perform serialization. The SMLM traverses the Semantic Map Table (SMT) and extracts all state variables from the SAEM, including: (a) the internal state of the DASSL solver: the integral history term array (7 historical steps of the 7th order BDF method), the current Jacobian matrix, and the step size control parameters; (b) the state variables of the flexible DC electromagnetic transient model: the capacitor voltage vectors of each bridge arm submodule of the MMC converter (a total of 2016 capacitors, each recording a double-type voltage value), the traveling wave state history of the DC line distributed parameter model (storing the historical values ​​of the most recent 1000 steps), and the historical current vector of the Thevenin equivalent circuit of the AC system; (c) the state variables of the control system model: the integral terms of each PI controller, the state register of the circulating current suppression controller, and the phase history of the modulation algorithm; (d) the interpolation buffer of the rate conversion layer: the most recent 512 VTA timestamps and the corresponding signal value matrix. All state data is serialized into intermediate state packets (ISPs) in Protobuf format. For the flexible vertical transmission system in this example, the ISP size is approximately 4.2 MB, and the serialization time is approximately 180 milliseconds.

[0080] The SSCM's FSM is migrated to the ENGINE_SWITCHING state.

[0081] The SSCM instructs the SMLM to migrate the state data in the ISP to the HREM. The SMLM traverses the ISP and, based on the HREM's storage location descriptor in the SMT, injects the state data item by item into the HREM's internal data structure: (a) Electromagnetic transient model state: the capacitor voltages of 2016 sub-modules are injected into the fixed-length capacitor voltage array of the HREM; the traveling wave history is injected into the HREM's ring buffer; (b) Control system state: all PI integral terms and state registers are injected into the state storage area of ​​the corresponding control module in the HREM; (c) Rate conversion layer state: the contents of the interpolation history buffer are injected into the corresponding RCL buffer of the HREM, and the decimation phase alignment parameters of the RCL are recalculated based on the fixed HIL step size (10μs in this example) and the VTA timestamp at the SIL switching time, to ensure that the data generated in the first HIL step is precisely aligned with the SIL switching point on the VTA.

[0082] After state injection is complete, IAL performs a hot rebinding operation, switches the scene routing table to the HIL adapter, enables the physical I / O board, and begins real-time data acquisition and output of 350 channels in fixed 10μs steps. The entire state transition and hot rebinding process takes approximately 50 milliseconds.

[0083] The SSCM's FSM migrates to the STATE_RESTORE state, and after completing state restoration, it migrates to the VERIFICATION state.

[0084] Before entering formal HIL operation, the system executes an automated conformance verification process, lasting approximately 200 milliseconds (corresponding to approximately 20,000 HIL simulation steps). The verification includes: (a) Conformity check of key state variables: comparing the SIL state values ​​recorded in the ISP at the switching moment with the current state values ​​after HIL injection. For each key state variable (DC voltage, average capacitor voltage of each bridge arm submodule, controller output), the normalized deviation is calculated, requiring the deviation of all key variables to be less than 0.1% (per unit); (b) Time continuity verification: RCL checks whether the timestamp of the first HIL step after switching on the VTA is continuous with the VTA timestamp of the SIL switching point (the deviation does not exceed 1 HIL step), ensuring that the time axis does not jump; (c) Signal validity verification: IAL checks whether the sampled values ​​of all physical I / O channels are within the valid range, identifies and reports any channel faults or wiring abnormalities.

[0085] If the verification passes (all check items meet the threshold requirements), the SSCM's FSM migrates from the VERIFICATION state to the RUNNING state, and the HREM continues to run in full-speed real-time mode (10μs fixed step size, real-time clock locked). The entire switching process, from the engineer clicking the switch button to the HIL entering the formal running state, takes approximately 6 to 8 seconds (including 5 seconds of preheating time). The SIL runs continuously during the preheating and switching preparation phases, and the actual pause window only occurs during the state snapshot, migration, and verification phases and is in the millisecond range, with invalid test time approaching zero.

[0086] If verification fails (any check item exceeds the threshold), FSM triggers the abnormal rollback mechanism: HREM stops running, IAL is hot-rebounded back to the SIL adapter, SAEM is restored from the ISP at the time of switchover to the SIL running state (using the serialized ISP to re-inject into SAEM), the system returns to the SIL running state before the switchover, and reports the specific reason for the verification failure to the user for engineers to troubleshoot and handle.

[0087] After successful verification, the system enters the formal HIL (Hybrid Intelligent Logic) operation phase. The flexible DC control and protection device (real hardware) is connected to the HIL simulation box via analog / digital I / O interfaces, receiving analog signals such as three-phase voltage and DC voltage output from the simulation model, and outputting trigger pulses and switching control signals to the simulation model. Because the system steady state is preserved during switching, the control and protection device does not need to be restarted, and fault injection tests (such as DC line grounding faults, AC three-phase short circuits, etc.) can be performed immediately, significantly saving testing time.

[0088] In one example, the switching process from SIL to PIL is as follows: 1. PIL Pre-initialization: During SIL operation, after receiving the switch to PIL request, SSCM notifies PPEM to preload the object model instance and downloads the compiled target code of the control algorithm to the DSP / ARM / FPGA development board; at the same time, it establishes a USB-JTAG or UDP communication link and completes the RDY / ACK handshake test.

[0089] 2. RTT calibration: PPEM sends multiple sets of test frames to measure the RTT between the host and the target processor, calculates communication_latency_compensation_ns, and writes it into the PIL delay compensation parameter table of RCL.

[0090] 3. Safety checkpoint pause and state snapshot: The SIL engine pauses at safety checkpoints, storing the SMLM serialized object model state, controller intermediate state, RCL buffer, and VTA timestamp; for controller states that will be migrated to processor execution, integral terms, filter history terms, state machine states, and timer values ​​also need to be extracted from the SIL control module.

[0091] 4. Cross-host / processor state injection: SMLM injects the object model state into the PPEM host side according to SMT, and writes the controller state to the target processor side according to the processor memory layout and data format requirements, such as floating point to Q15 / Q31 fixed point, byte order adjustment, and writing register or RAM mapped addresses.

[0092] 5. Routing Switching and Synchronous Startup: IAL switches the control-related signals to the PIL adapter; PPEM starts according to the T_PIL cycle, and the host-side object model and processor-side control code exchange input and output through communication frames, executing in cycle-by-cycle alignment based on RDY / ACK. 6. Post-Switching Verification: Verification items include the correctness of the processor's return frame CRC, whether the cycle jitter is within the threshold, whether the deviation between the critical control output and the SIL switching point is less than the set value, and whether the VTA timestamp continuity meets the requirements. After successful verification, PIL begins formal operation.

[0093] In one example, the switching process from PIL to HIL is as follows: 1. HIL preheating: HREM preloads the fixed-step real-time model, board configuration, and I / O mapping; PIL continues to run until the safety checkpoint.

[0094] 2. Dual-sided state capture: In addition to the host-side object model state, SMLM also needs to read the current controller state from the target processor, including PI integral term, filter state, phase-locked loop phase, state machine state and fault flag.

[0095] 3. Semantic mapping conversion: The processor-side fixed-point state is converted into the internal engineering state of the HIL engine through SMT and injected synchronously into the HREM control module or hardware interface buffer; the object model state is directly injected into the corresponding storage area of ​​HREM.

[0096] 4. Time alignment: RCL calculates the starting point of the first HIL step based on the VTA timestamp of PIL and communication_latency_compensation_ns, so that the first HIL fixed step is aligned with the last control interrupt logic time of PIL.

[0097] 5. IAL Hot Binding: Switch the communication frame interface to the HIL physical I / O interface and enable the analog / digital signal board.

[0098] 6. Consistency Verification: Check the input and output, critical status deviations, time continuity, and board range validity of the first cycle of HIL. After successful verification, proceed with HIL operation.

[0099] This invention improves the efficiency of simulation scenario switching, data consistency, and system reliability by reading the model file of a flexible-conductive control system; generating runtime model instances for various scenarios using the model file; obtaining the startup configuration and determining the initial operating mode and current running model instance based on the startup configuration; running the flexible-conductive control system using the current running model instance to obtain simulation results; when a running mode switching command is received, determining the target execution engine and target runtime model instance based on the operating mode switching command; obtaining state variables from the current running model instance and adding the state variables to the target execution engine according to the simulation virtual timeline; loading the target runtime model instance through the target execution engine; and running the flexible-conductive control system using the target runtime model instance to obtain simulation results.

[0100] In one embodiment, the technological basis for seamless switching capability is as follows: Standardized Signal Descriptor and Parallel Registration Mechanism for Three Scenarios: This invention designs a signal descriptor data structure containing seven fields and simultaneously registers the binding information of each signal in three simulation scenarios to the global signal registry during system initialization. This parallel registration mechanism eliminates the need for signal discovery and registration during scenario switching; only the routing pointer needs to be switched, thereby reducing interface reconfiguration time from minutes to milliseconds. In traditional solutions, signals are managed independently in each scenario, and the operation of re-registering signals during switching is one of the main reasons for long switching times. This feature fundamentally eliminates this bottleneck.

[0101] Multi-mode rate conversion algorithm system based on virtual time axis: This invention establishes a multi-mode rate conversion algorithm system with a 1 nanosecond resolution virtual time axis (VTA) as its core. It supports three upsampling algorithms: linear interpolation, Hermite interpolation, and B-spline interpolation, as well as an anti-aliasing downsampling algorithm based on a Chebyshev type II IIR filter. Users can independently configure the optimal interpolation / decimation algorithm for each signal, maximizing computational efficiency while ensuring accuracy. The introduction of VTA solves the fundamental problem in existing technologies where data from the three simulation modes cannot be compared in the same coordinate system.

[0102] A security checkpoint-driven non-intrusive state serialization mechanism: This invention avoids the problem of inconsistent states caused by forcibly interrupting the engine during intermediate calculation stages by defining security checkpoints in the simulation engine and using hook interfaces (non-intrusive probes) to trigger state serialization. This mechanism ensures the mathematical correctness of the serialized states and is a key guarantee for achieving continuity of simulation results after switching. The Protobuf-based serialization format provides cross-platform compatibility while ensuring speed, supporting state migration between simulation nodes with different operating systems and hardware architectures.

[0103] Semantic Map Table-Driven Cross-Engine State Transition: This invention introduces a Semantic Map Table (SMT) as a conversion medium between the internal data structures of three engines. By automatically generating the SMT during the model description phase, it solves the problem that states cannot be directly transferred due to differences in internal data organization between different engines. The automatic generation mechanism of the SMT eliminates the need for manual maintenance of state mapping relationships and reduces the complexity of system expansion (such as connecting new simulation engines).

[0104] Seven-state finite state machine driven switching process control: The scene switching controller of this invention adopts a seven-state FSM that includes timeout protection and an exception rollback mechanism to ensure that the switching process can safely roll back to the state before the switch under any abnormal conditions (such as state serialization timeout, target engine initialization failure, etc.), avoid the simulation system from entering an uncertain state, and ensure the robustness and reliability of the system.

[0105] In the specific implementation, the signal descriptor registration mechanism, virtual time axis (VTA), security checkpoint mechanism, semantic mapping table (SMT), and seven-state control (FSM) have the following collaborative relationship diagram: Figure 8 As shown. The signal descriptor registration mechanism provides the virtual time axis (VTA) with the time attribute information of the signal. The VTA transmits the time synchronization signal to the security checkpoint mechanism through the rate conversion layer. After the security checkpoint trigger state is serialized, the semantic mapping table (SMT) is responsible for the cross-engine state format conversion. Finally, the seven-state FSM uniformly schedules the entire handover process and feeds back the handover result to the signal registry to complete the route update, forming a complete handover control closed loop.

[0106] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0107] Please see Figure 9 , Figure 9 This is a structural block diagram of a simulation scene switching device for a flexible direct current control system provided in an embodiment of the present invention.

[0108] This invention provides a simulation scene switching device for a flexible direct current control system, comprising: The model file reading module 901 is used to read the model file of the flexible vertical control system; The runtime model instance generation module 902 is used to generate runtime model instances for various scenarios using the model file; The current running model instance determination module 903 is used to obtain the startup configuration and determine the current running model instance based on the startup configuration; The first simulation result generation module 904 is used to run the flexible-vertical control system using the current runtime model instance to obtain simulation results; The target execution engine and target runtime model instance determination module 905 is used to determine the target execution engine and target runtime model instance according to the running mode switching instruction when a running mode switching instruction is received; The state variable adding module 906 is used to obtain state variables from the current runtime model instance and add the state variables to the target execution engine according to the simulation virtual time axis; The second simulation result generation module 907 is used to load the target runtime model instance through the target execution engine, run the flexible-vertical control system using the target runtime model instance, and obtain the simulation results after the operation mode is switched.

[0109] In this embodiment of the invention, the runtime model instance generation module 902 includes: The parsing submodule is used to parse the model structure definition, parameter definition, signal interface definition, and scene adaptation annotation in the model file; The model intermediate representation generation submodule is used to generate the model intermediate representation using the model structure definition, the parameter definition, the signal interface definition, and the scene adaptation annotation; The scene-independent main model generation submodule is used to normalize the intermediate representation of the model to obtain the scene-independent main model; The HIL instance generation submodule is used to extract configurations suitable for real-time execution with fixed step size based on the scenario-independent master model, and generate HIL instances for hardware-in-the-loop simulation scenarios according to the configurations. The SIL instance generation submodule is used to extract a SIL runtime graph suitable for variable step size solution based on the scenario-independent master model, and to generate a SIL instance of the software-in-the-loop simulation scenario using the SIL runtime graph. The PIL instance generation submodule is used to split the scene-independent master model into a control algorithm part and an object model part, and use the control algorithm part and the object model part to generate a PIL instance of the processor-in-the-loop simulation scene. The runtime model instance generation submodule is used to generate standard signal descriptors corresponding to the HIL instance, the SIL instance, and the PIL instance respectively, and bind the HIL instance, the SIL instance, and the PIL instance to the corresponding standard signal descriptors to obtain runtime model instances corresponding to the HIL instance, the SIL instance, and the PIL instance respectively.

[0110] In this embodiment of the invention, the runtime model instance generation module 902 further includes: The semantic mapping table generation submodule is used to generate semantic mapping tables for the HIL instance, the SIL instance, and the PIL instance.

[0111] In this embodiment of the invention, it further includes: The verification module is used to perform structural consistency verification, parameter consistency verification, and interface completeness verification on all the runtime model instances. The registration module is used to register each of the standard signal descriptors to the global signal registry when the verification passes.

[0112] In this embodiment of the invention, the state variable adding module 906 includes: The switch request flag sending submodule is used to send a switch request flag to the current execution engine through the scene switching controller; The state variable addition submodule is used to extract state variables from the current runtime model instance when the scene switching controller receives a checkpoint arrival notification returned by the current execution engine, and add the state variables to the target execution engine according to the simulation virtual time axis through the semantic mapping table. The checkpoint arrival notification is generated by the current execution engine after completing the current simulation step and pausing the execution of the current runtime model instance at the next safety checkpoint.

[0113] In this embodiment of the invention, it further includes: The consistency verification module is used to perform consistency verification between the current execution engine and the target execution engine. The second simulation result generation module 907 includes: The second simulation result generation submodule is used to load the target runtime model instance through the target execution engine when the consistency verification passes, and run the flexible vertical control system using the target runtime model instance to obtain the simulation results after the operation mode switch.

[0114] In this embodiment of the invention, it further includes: The switching module is used to switch back to the initial running mode if the consistency verification fails.

[0115] This invention also provides an electronic device, 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 simulation scene switching method described in the embodiments of the present invention according to the instructions in the program code.

[0116] This invention also provides a computer-readable storage medium for storing program code for executing the simulation scene switching method described in this invention.

[0117] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0118] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0119] Those skilled in the art will understand that embodiments of the present invention can be provided as systems, methods, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0120] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0121] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0122] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0123] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0124] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0125] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0126] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail 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 the present invention.

Claims

1. A simulation scene switching method for a flexible direct current control system, characterized in that, include: Read the model file of the flexible-vertical control system; The model file is used to generate runtime model instances for various scenarios; Obtain the startup configuration and determine the currently running model instance based on the startup configuration; The flexible-vertical control system is run using the current runtime model instance to obtain simulation results; When a runtime mode switching instruction is received, the target execution engine and the target runtime model instance are determined according to the runtime mode switching instruction; The state variables are obtained from the current runtime model instance and added to the target execution engine according to the simulation virtual timeline; The target runtime model instance is loaded through the target execution engine, and the flexible-conductor control system is run using the target runtime model instance to obtain the simulation results after the operation mode is switched.

2. The method according to claim 1, characterized in that, The step of generating runtime model instances for multiple scenarios using the model file includes: Parse the model structure definition, parameter definition, signal interface definition, and scene adaptation annotation in the model file; The intermediate representation of the model is generated using the model structure definition, the parameter definition, the signal interface definition, and the scene adaptation annotation; The intermediate representation of the model is normalized to obtain a scene-independent main model; Based on the scenario-independent master model, a configuration suitable for real-time execution with a fixed step size is extracted, and a HIL instance for a hardware-in-the-loop simulation scenario is generated according to the configuration. Based on the scenario-independent master model, a SIL runtime graph suitable for variable step size solution is extracted, and the SIL runtime graph is used to generate a SIL instance of the software-in-the-loop simulation scenario. The scenario-independent master model is split into a control algorithm part and an object model part, and the control algorithm part and the object model part are used to generate a PIL instance of the processor-in-the-loop simulation scenario; Standard signal descriptors corresponding to the HIL instance, SIL instance, and PIL instance are generated respectively, and the HIL instance, SIL instance, and PIL instance are bound to the corresponding standard signal descriptors to obtain runtime model instances corresponding to the HIL instance, SIL instance, and PIL instance respectively.

3. The method according to claim 2, characterized in that, Also includes: Generate semantic mapping tables for the HIL instance, the SIL instance, and the PIL instance.

4. The method according to claim 2, characterized in that, The model file includes several interface signals; after the step of generating runtime model instances for various scenarios using the model file, the method further includes: Perform structural consistency checks, parameter consistency checks, and interface completeness checks on all instances of the runtime model. When the verification passes, each of the standard signal descriptors is registered in the global signal registry.

5. The method according to claim 3, characterized in that, The step of obtaining state variables from the current runtime model instance and adding the state variables to the target execution engine according to the simulation virtual timeline includes: Send a switching request flag to the current execution engine through the scene switching controller; When the scene switching controller receives a checkpoint arrival notification returned by the current execution engine, it extracts state variables from the current runtime model instance and adds the state variables to the target execution engine through the semantic mapping table according to the simulation virtual time axis. The checkpoint arrival notification is generated by the current execution engine after completing the current simulation step and pausing the execution of the current runtime model instance at the next safety checkpoint.

6. The method according to claim 5, characterized in that, Before the step of loading the target runtime model instance through the target execution engine, running the flexible-conductor control system using the target runtime model instance, and obtaining the simulation results after the operation mode switch, the method further includes: Perform consistency verification between the current execution engine and the target execution engine; The steps of loading the target runtime model instance through the target execution engine, running the flexible-conductor control system using the target runtime model instance, and obtaining simulation results include: When the consistency verification passes, the target runtime model instance is loaded through the target execution engine, and the flexible vertical control system is run using the target runtime model instance to obtain the simulation results after the operation mode switch.

7. The method according to claim 6, characterized in that, Also includes: If the consistency verification fails, switch back to the initial running mode.

8. A simulation scene switching device for a flexible direct current control system, characterized in that, include: The model file reading module is used to read the model files of the flexible vertical control system; The runtime model instance generation module is used to generate runtime model instances for various scenarios using the model file. The current running model instance determination module is used to obtain the startup configuration and determine the current running model instance based on the startup configuration; The first simulation result generation module is used to run the flexible-vertical control system using the current runtime model instance to obtain simulation results; The target execution engine and target runtime model instance determination module is used to determine the target execution engine and target runtime model instance according to the running mode switching instruction when a running mode switching instruction is received; The state variable addition module is used to obtain state variables from the current runtime model instance and add the state variables to the target execution engine according to the simulation virtual time axis; The second simulation result generation module is used to load the target runtime model instance through the target execution engine, run the flexible-vertical control system using the target runtime model instance, and obtain the simulation results after the operation mode is switched.

9. An electronic device, 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 simulation scene switching method according to any one of claims 1-7 according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for executing the simulation scene switching method according to any one of claims 1-7.

Images