Data processing system for co-simulation

Abstract

This application relates to the field of simulation integration technology, specifically to a data processing system for co-simulation. The system includes an interaction module, a script parsing module, and a function adaptation module. The interaction module receives function instructions and source scripts. The script parsing module converts the source script into a lexical sequence; determines the type information corresponding to dynamic type variables in variable nodes; determines the parameter type characteristics of function call nodes based on a bidirectional mapping table; determines the intermediate code corresponding to the functional modules and sends the intermediate code to the algorithm platform. The function adaptation module generates adaptation rules for function instructions; adapts and transforms the input parameters to obtain adaptation parameters; constructs a scheduling strategy; and sends the function instructions, adaptation parameters, and scheduling strategy to the algorithm platform. This application solves the technical problem of low data interaction efficiency between algorithm platforms and general simulation platforms in related technologies.

Description

Technical Field

[0001] This application relates to the field of simulation integration technology, and more specifically, to a data processing system for co-simulation. Background Technology

[0002] In industry, the integration of algorithm platforms (scientific computing kernels) with general-purpose simulation platforms typically employs an architecture based on an intermediate adaptation layer. This relies heavily on interface encapsulation technology, data bridging technology, script compatibility parsing technology, and Multiple Input Multiple Output (MIMO) function call adaptation technology. Such solutions usually achieve instruction forwarding, data serialization / deserialization, script syntax conversion, and function call mapping between the simulation platform and the kernel by deploying independent protocol conversion components, data format mapping modules, or third-party adaptation middleware.

[0003] However, the relevant technologies have the following systemic flaws:

[0004] 1. High dependence on the intermediate adaptation layer leads to a lengthy system call chain and an increase in data forwarding links, introducing significant communication delays and processing overhead, making it difficult to meet the real-time requirements of high-frequency, low-latency simulation scenarios;

[0005] 2. The intermediate adaptation layer introduces additional redundant system components, which not only increases memory usage and computational overhead, but also significantly increases the density of system failure points, reduces overall operational reliability and security, and significantly increases the overall cost of research and development, testing, and maintenance.

[0006] 3. The simulation platform and the algorithm platform are fundamentally heterogeneous in terms of data type system, communication protocol specifications and script syntax and semantics. The related technologies rely on static configuration and manual mapping, which have weak compatibility, complex configuration and poor scalability, making it difficult to support seamless interaction between multi-source scripts and heterogeneous data.

[0007] 4. The MIMO function interface lacks dynamic perception and adaptive scheduling capabilities. It cannot automatically adjust parameter adaptation strategies and resource allocation schemes according to the scale, dimensional characteristics and execution dependencies of input parameters. This leads to problems such as resource contention, execution blocking and accuracy loss in complex multi-task concurrent scenarios, which seriously restricts the scalability and stability of the simulation system.

[0008] There is currently no effective solution to the above problems. Summary of the Invention

[0009] This application provides a co-simulation data processing system to at least solve the technical problem of low data interaction efficiency between algorithm platforms and general simulation platforms in related technologies.

[0010] According to one aspect of this application, a co-simulation data processing system is provided, comprising: an interaction module, a script parsing module, and a function adaptation module. The interaction module performs the following steps: receiving function instructions sent by a general simulation platform and a source script written in a programming language; forwarding the source script to the script parsing module and forwarding the function instructions to the function adaptation module. The script parsing module performs the following steps: converting the source script into a lexical sequence and parsing the lexical sequence into an abstract syntax tree, wherein the nodes in the abstract syntax tree include variable nodes, function call nodes, and operator nodes; determining the type information corresponding to the dynamic type variables in the variable nodes and annotating the type information to the corresponding variable nodes; determining the parameter type characteristics of the function call nodes based on a bidirectional mapping table and the annotated type information, wherein the bidirectional mapping table is based on the type signature of standard functions in the programming language, the parameter dimension constraints of the function call interface of the algorithm platform, and memory allocation. The requirements include: a pre-built bidirectional index structure; replacing function call nodes in the abstract syntax tree with corresponding function call nodes in the algorithm platform that match the parameter type features; splitting the replaced abstract syntax tree by functional modules to obtain intermediate code for each functional module, and sending the intermediate code to the algorithm platform; the function adaptation module performs the following steps: identifying the function type of the function instruction, extracting the execution dependency relationship corresponding to the function instruction, and generating adaptation rules for the function instruction, wherein the adaptation rules are used to determine the matching standard between the input parameters in the function instruction and the algorithm platform; parsing the attributes of the input parameters and identifying the constraint relationship between the input parameters; adapting and transforming the input parameters based on the kernel requirements of the algorithm platform, and correcting the transformation result based on the adaptation rules to obtain the adapted parameters; constructing a scheduling strategy based on the function type, execution dependency relationship, and resource consumption index of the algorithm platform; and sending the function instruction, adapted parameters, and scheduling strategy to the algorithm platform.

[0011] Optionally, receiving function instructions and source scripts written in a programming language sent by the general simulation platform includes the following steps: receiving a connection establishment request sent by the general simulation platform, wherein the connection establishment request includes: identity identification information; performing access verification based on the identity identification information; if the verification is successful, performing bidirectional negotiation of interface standards and data formats with the general simulation platform based on a preset protocol; if the negotiation result indicates success, establishing a bidirectional direct connection channel without an intermediate adaptation layer between the general simulation platform and the algorithm platform; and receiving function instructions and source scripts sent by the general simulation platform through the bidirectional direct connection channel.

[0012] Optionally, the source script is converted into a lexical sequence, and the lexical sequence is parsed into an abstract syntax tree, specifically including the following steps: scanning the source script based on preset syntax rules, identifying and extracting preset lexicals in the source script, wherein the preset lexicals include at least one of the following: keywords, variable names, operators, and constants; validating the preset lexicals, and generating a lexical sequence based on the preset lexicals that pass the validity check; recursively descent parsing the lexical sequence based on a context-free grammar to obtain an initial abstract syntax tree, wherein the context-free grammar is used to represent the grammatical production rules and symbol precedence constraints of the programming language, and the initial abstract syntax tree is used to represent the hierarchical nesting relationship and semantic information of the source script; preprocessing the initial abstract syntax tree to obtain an abstract syntax tree, wherein the preprocessing includes the following steps: identifying and removing invalid components and redundant placeholder nodes in the initial abstract syntax tree; pre-computing the operational expressions composed of constants in the initial abstract syntax tree, and replacing the corresponding operational nodes with the calculation results; simplifying the structure of conditional branches and loop paths in the initial abstract syntax tree based on the control flow logic of the source script.

[0013] Optionally, the replaced abstract syntax tree is split according to functional modules to obtain the intermediate code corresponding to each functional module. Specifically, this includes the following steps: identifying logical boundaries in the abstract syntax tree, where logical boundaries are used to represent function definitions, class definitions, or independent logical blocks; splitting the abstract syntax tree into multiple functional modules with independent execution characteristics using logical boundaries; mapping each functional module to code that can be recognized by the algorithm platform to obtain the intermediate code corresponding to each functional module, and constructing a global symbol table, where the global symbol table is used to record the interface call relationship between functional modules and the global variable reference relationship.

[0014] Optionally, after obtaining the intermediate code corresponding to each functional module, the script parsing module is also used to perform the following steps: obtain the modification status of the source script, locate the first functional module whose modification status indicates a change based on logical boundaries; analyze the scope of the influence of the first functional module on other functional modules using a global symbol table, and determine the second functional module affected by the change based on the scope of the influence; recompile the abstract syntax tree branches corresponding to the first and second functional modules; count the execution frequency of the intermediate code, and convert hot code into the native machine code of the algorithm platform using just-in-time compilation technology, wherein hot code is intermediate code with an execution frequency greater than a preset threshold; extract matrix operations that conform to parallelization characteristics from the intermediate code, and use a global symbol table to parse the data flow constraints of matrix operations between functional modules; generate parallel execution instructions based on the data flow constraints, and distribute the parallel execution instructions to the parallel scheduling engine of the algorithm platform.

[0015] Optionally, after sending the intermediate code to the algorithm platform, the script parsing module is also used to perform the following steps: receiving the calculation results returned by the algorithm platform and identifying the data type of the calculation results, wherein the data type includes matrix, array, or structure; matching the corresponding conversion rule from the bidirectional mapping table according to the identified data type; and converting the calculation results from the storage format of the algorithm platform to a result format data compatible with the source programming language standard of the general simulation platform based on the memory arrangement and data bit width characteristics defined in the conversion rule; wherein, for matrices or multidimensional arrays exceeding a preset size threshold, performing block conversion and data compression processing; sending the result format data to the general simulation platform and generating an execution log, wherein the execution log includes at least one of the following: execution time, performance indicators, and error information; and releasing the computing resources and cache space occupied by this script execution after the result format data is sent.

[0016] Optionally, the bidirectional mapping table is generated through the following steps: Extracting type signature data for each standard function from the standard function library of the programming language using static syntax analysis. The type signature data includes the function name, number of parameters, logical data type of each parameter, precision bit width of the return value, and dimension attributes. Obtaining the underlying physical constraints of the hardware execution unit corresponding to the function call interface of the algorithm platform. These underlying physical constraints include memory alignment step size, data addressing mode in the storage medium, and register bit width constraints of the computational core. Calculating the standard data types in the programming language based on the memory alignment step size and data addressing mode. The memory layout mapping values ​​between the algorithm platform interface and the target interface include rank transformation rules for converting from column-major storage at the source end to row-major storage at the target end, as well as data filling strategies or block splitting rules for register bit width constraints. Based on type signature data and memory layout mapping values, a bidirectional index structure between the source function identifier and the target interface pointer is established, and a bidirectional mapping table is generated according to the bidirectional index structure. The bidirectional index structure supports automatic adaptation and conversion of function calls during the script compilation stage, and supports reverse tracing back to the syntax nodes of the source script based on the feedback status of the target interface during the program execution stage.

[0017] Optionally, generating adaptation rules for function instructions includes the following steps: scanning the source code or intermediate representation of the function instructions and locating the function entry point through lexical and syntactic analysis; establishing a data flow topology graph of the internal operators of the function instructions using semantic analysis, wherein the data flow topology graph is used to represent the execution order and data transmission path between internal operators; extracting the input-output tensor dimensions, numerical range constraints, and logical dependencies between variables of the function instructions based on the data flow topology graph; and constructing a function feature model based on the input-output tensor dimensions, numerical range constraints, and logical dependencies between variables, wherein the function feature model is used to represent the function. The instructions specify the computational resource requirements; if a function instruction is found to have no matching item in the function feature library, it is determined to be a custom function, and multiple sets of probe vectors are constructed to test the custom function, capturing the output response and memory addressing patterns of the custom function under different input magnitudes; based on the output response and memory addressing patterns, the numerical mapping relationship and data layout of the custom function are determined, and the transformation logic of the custom function is extracted according to the numerical mapping relationship and data layout; according to the transformation logic, adaptation rules are generated, where the adaptation rules are used to represent the interface protocol mapping relationship and data alignment strategy between the custom function and the algorithm platform.

[0018] Optionally, the input parameters are adapted and their dimensions transformed based on the kernel requirements of the algorithm platform. This includes the following steps: First, the input parameters are converted to new data types and reordered by byte order according to the word length and endianness requirements in the kernel requirements to obtain preliminary adapted parameters. Second, the tensor computation step size and alignment threshold in the kernel requirements are extracted. If the dimensions of the preliminary adapted parameters are found to be inconsistent with the input specifications of the function instructions, dimensional expansion or compression is performed on the preliminary adapted parameters. Dimension expansion uses zero-padding or repetitive mapping strategies to align low-dimensional data to a high-dimensional computation space, while dimensional compression uses block slicing or strafing sampling strategies to extract feature subsets. Third, the transformation results are corrected based on the adaptation rules to obtain adapted parameters. This includes the following steps: First, the memory mapping algorithm defined in the adaptation rules is called according to the parallel computing architecture of the algorithm platform. Second, the memory layout of the parameters after dimensional expansion or compression is rearranged based on the memory mapping algorithm to perform the correction. Third, the rearranged parameters are transformed into a linearized data stream that meets the data alignment requirements in the adaptation rules using continuous address space mapping to obtain the adapted parameters.

[0019] Optionally, after sending the function instructions, adaptation parameters, and scheduling strategy to the algorithm platform, the function adaptation module is further configured to perform the following steps: receive the multiple output results and execution status information returned by the algorithm platform, and establish a full-link record; wherein, the multiple output results include the computational kernel output data corresponding to the function instructions, and the full-link record includes at least one of the following: input parameters, adaptation rules, scheduling strategy, and multiple output results; perform precision verification and integrity verification on the multiple output results; if the verification determines that the deviation of the multiple output results exceeds the preset range or the results are incomplete, then trace the function feature model in reverse according to the deviation data, and adjust the adaptation rules or reallocate computational resources based on the function feature model to request the algorithm platform to re-execute; after the multiple output results pass the verification, extract the effective adaptation features from the adaptation parameters and the corresponding execution status log, and synchronously update the effective adaptation features to the function feature library; synchronously transmit the verified multiple output results and execution status log back to the general simulation platform, wherein the execution status log is used to record the execution status of the adaptation process.

[0020] In this application, an interaction module, a script parsing module, and a function adaptation module are employed. The interaction module performs the following steps: receiving function instructions and source scripts written in a programming language from a general simulation platform; forwarding the source script to the script parsing module and the function instructions to the function adaptation module. The script parsing module performs the following steps: converting the source script into a lexical sequence and parsing the lexical sequence into an abstract syntax tree (AST), where the nodes in the AST include variable nodes, function call nodes, and operator nodes; determining the type information corresponding to the dynamic type variables in the variable nodes and annotating the type information to the corresponding variable nodes; determining the parameter type characteristics of the function call nodes based on a bidirectional mapping table and the annotated type information, where the bidirectional mapping table is a pre-constructed bidirectional index structure based on the type signatures of standard functions in the programming language, the parameter dimension constraints of the algorithm platform's function call interface, and memory layout requirements; replacing the function call nodes in the AST with corresponding function call nodes in the algorithm platform that match the parameter type characteristics; and disassembling the replaced AST according to functional modules. The simulation platform obtains intermediate code for each functional module and sends it to the algorithm platform. The function adaptation module performs the following steps: identifying the function type of the function instruction, extracting the execution dependency relationship corresponding to the function instruction, and generating adaptation rules for the function instruction. The adaptation rules are used to determine the matching standard between the input parameters in the function instruction and the algorithm platform. The module parses the attributes of the input parameters and identifies the constraint relationship between the input parameters. Based on the kernel requirements of the algorithm platform, the input parameters are adapted and their dimensions are transformed. The transformation results are then corrected based on the adaptation rules to obtain the adapted parameters. Based on the function type, execution dependency relationship, and resource consumption index of the algorithm platform, a scheduling strategy is constructed. The function instruction, the adapted parameters, and the scheduling strategy are sent to the algorithm platform. This achieves the goal of realizing native semantic alignment and direct connection for efficient collaboration of instructions, scripts, and parameters between the simulation platform and the algorithm platform without an intermediate adaptation layer. This improves the data interaction efficiency between the algorithm platform and the general simulation platform, thereby solving the technical problem of low data interaction efficiency between the algorithm platform and the general simulation platform in related technologies. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 This is a structural diagram of a co-simulation data processing system according to an embodiment of this application;

[0023] Figure 2This is a schematic diagram illustrating the interaction between a co-simulation data processing system and an external platform according to an embodiment of this application;

[0024] Figure 3 This is a flowchart of an interactive module according to an embodiment of this application;

[0025] Figure 4 This is a flowchart of a script parsing module according to an embodiment of this application;

[0026] Figure 5 This is a flowchart of a function adaptation module according to an embodiment of this application. Detailed Implementation

[0027] 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 should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] According to an embodiment of this application, a method embodiment for a co-simulation data processing system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] Figure 1 This is a structural diagram of a co-simulation data processing system 1 according to an embodiment of this application, as shown below. Figure 1 As shown, the co-simulation data processing system 1 includes: an interaction module 12, a script parsing module 14, and a function adaptation module 16.

[0031] The interaction module 12 is used to perform the following steps: receiving function instructions sent by the general simulation platform and source scripts written in a programming language; forwarding the source scripts to the script parsing module 14 and forwarding the function instructions to the function adaptation module 16.

[0032] The interaction module 12 serves as the unified entry point between the system and the external simulation platform. It receives source scripts written in programming languages ​​(such as MATLAB) and structured function instructions sent by the simulation platform. The source scripts describe the algorithmic logic of the simulation model, while the function instructions trigger specific computational tasks, such as MIMO controller calls or state solving. The interaction module 12 forwards the source scripts as is to the script parsing module 14 and directs the function instructions to the function adaptation module 16, thereby decoupling the communication layer from the computational logic layer and avoiding the latency and redundancy introduced by traditional intermediate adaptation layers in protocol conversion and format encapsulation.

[0033] The script parsing module 14 performs the following steps: converting the source script into a lexical sequence and parsing the lexical sequence into an abstract syntax tree (AST), where the nodes in the AST include variable nodes, function call nodes, and operator nodes; determining the type information corresponding to the dynamic type variables in the variable nodes and annotating the type information to the corresponding variable nodes; determining the parameter type characteristics of the function call nodes based on the bidirectional mapping table and the annotated type information, where the bidirectional mapping table is a pre-constructed bidirectional index structure based on the type signature of the standard functions of the programming language, the parameter dimension constraints of the function call interface of the algorithm platform, and the memory layout requirements; replacing the function call nodes in the AST with the corresponding function call nodes in the algorithm platform that match the parameter type characteristics; splitting the replaced AST according to functional modules to obtain the intermediate code corresponding to each functional module, and sending the intermediate code to the algorithm platform.

[0034] Specifically, after receiving the source script, the script parsing module 14 first performs lexical analysis, decomposing the script text into a sequence of basic tokens containing keywords, variables, operators, function names, etc., and then further constructs an abstract syntax tree reflecting the program structure through syntax analysis. The nodes of the abstract syntax tree can accurately identify semantic units such as variables, function calls, and operations.

[0035] In response to the characteristic of variables not having explicitly declared types in dynamically typed languages ​​such as MATLAB, the script parsing module 14 automatically identifies the potential data types (such as double-precision matrices, integer vectors, etc.) of each variable node through static analysis combined with context inference, and marks them on the corresponding nodes to form an abstract syntax tree with type semantics.

[0036] The script parsing module 14, based on a pre-built bidirectional mapping table and combined with the labeled variable types, accurately infers the parameter type characteristics of each function call node. This allows it to dynamically replace the source function call node in the AST with a semantically equivalent and interface-compatible target function node from the algorithm platform. The bidirectional mapping table records the type signatures of standard functions in the source language (such as inv, eig, and fft) and the core metadata such as parameter dimension constraints and memory layout specifications of the corresponding function interfaces on the algorithm platform.

[0037] After the replacement is completed, the script parsing module 14 modularly splits the abstract syntax tree according to the functional logic, generates several independent intermediate code units, and transmits the intermediate code to the algorithm platform for execution without loss through the direct connection channel established by the interaction module 12, so as to realize the zero-modification and high-fidelity operation of the source script on the algorithm platform.

[0038] The function adaptation module 16 performs the following steps: identifying the function type of the function instruction, extracting the execution dependencies corresponding to the function instruction, and generating adaptation rules for the function instruction, wherein the adaptation rules are used to determine the matching standard between the input parameters in the function instruction and the algorithm platform; parsing the attributes of the input parameters and identifying the constraint relationships between the input parameters; adapting and transforming the input parameters based on the kernel requirements of the algorithm platform, and correcting the transformation results based on the adaptation rules to obtain the adapted parameters; constructing a scheduling strategy based on the function type, execution dependencies, and resource consumption indicators of the algorithm platform; and sending the function instruction, adapted parameters, and scheduling strategy to the algorithm platform.

[0039] Specifically, the function adaptation module 16 first performs semantic recognition on the instruction to determine its function type (such as linear / nonlinear, static / dynamic) and analyzes its execution dependencies, such as whether it depends on the output of the previous cycle or whether it needs to synchronize multiple input signals. Then, it generates customized adaptation rules to clarify the matching standards between the function and the algorithm platform kernel in terms of parameter dimensions, precision, memory format, etc.

[0040] The function adaptation module 16 parses the data attributes (data type, dimension, precision, memory structure) of the input parameters one by one, identifies the constraint relationships between multiple parameters (such as dimensional consistency, energy conservation, and dimensional matching), and ensures the legality of the parameter combination.

[0041] The function adaptation module 16 performs automatic adaptation operations on the input parameters according to the hard requirements of the algorithm platform kernel. The automatic adaptation operations include, but are not limited to: type conversion (such as single precision to double precision), dimension expansion (such as one-dimensional array to two-dimensional matrix), and memory rearrangement (such as column priority to row priority).

[0042] The function adaptation module 16 performs compliance checks and anomaly corrections on the transformation results based on preset adaptation rules, ensuring that the parameters fully meet the kernel execution conditions. On this basis, the function adaptation module 16 dynamically constructs the optimal scheduling strategy by comprehensively considering function type, execution dependencies, and current resource indicators such as CPU, memory, and parallel unit load of the algorithm platform. This rationally allocates computing resources, enabling high-priority tasks to be executed first and dependent tasks to be started in parallel.

[0043] Finally, the function adaptation module 16 packages the adapted parameters, the corrected function instructions, and the scheduling strategy, and sends them directly to the algorithm platform kernel through the direct connection channel established by the interaction module 12. This achieves end-to-end low-latency and high-reliability response from instruction issuance to computation execution, completely eliminating the performance degradation and stability risks caused by multi-layer conversion in related technologies.

[0044] The above system, through the collaborative work of the interaction module 12, the script parsing module 14 and the function adaptation module 16, constructs an integrated architecture of kernel and simulation platform that is semantically natively compatible and dynamically adaptive without an intermediate adaptation layer. Its technical effects are mainly reflected in the following aspects.

[0045] First, it significantly reduces system latency. By completely eliminating the traditional intermediate adaptation layer, all instructions and data are transmitted directly through a direct connection channel, eliminating redundant steps such as protocol conversion, serialization / deserialization, and multiple memory copies. This reduces the response time of script execution and function calls initiated by the simulation platform to the microsecond level, meeting the stringent requirements of control cycles in high-frequency real-time simulation scenarios.

[0046] Secondly, it achieves zero-modification, fully compatible cross-platform migration of the source script. The script parsing module 14, through lexical and syntactic analysis, dynamic type inference, and bidirectional mapping mechanisms, can automatically identify and convert implicit types, non-standard operations, and function calls in languages ​​such as MATLAB, accurately mapping them to equivalent implementations of the algorithm platform. Users do not need to rewrite any script code. At the same time, it retains the abstract syntax tree structure to support line-level breakpoints, variable monitoring, and single-step execution, enabling traditional MATLAB models to be seamlessly migrated to the kernel environment and possessing complete debugging capabilities.

[0047] Finally, dynamic adaptation and intelligent scheduling of MIMO functions are achieved. The function adaptation module 16 can automatically deduce adaptation rules based on the function type and the dimension, precision, and constraint relationship of the input parameters without manual pre-configuration of parameter mapping tables. It completes type conversion, dimension alignment, and memory layout optimization, and dynamically generates scheduling strategies in conjunction with real-time resource load. This enables parallel execution, priority scheduling, and optimal resource allocation of multiple MIMO tasks, effectively solving the problems of computation failure, resource contention, and execution blocking caused by parameter mismatch in related solutions.

[0048] The following are Figure 1Exemplary illustrations and explanations are provided.

[0049] According to some optional embodiments of this application, receiving function instructions and source scripts written in a programming language sent by a general simulation platform specifically includes the following steps: receiving a connection establishment request sent by the general simulation platform, wherein the connection establishment request includes: identity identification information; performing access verification based on the identity identification information; if the verification is successful, performing bidirectional negotiation of interface standards and data formats with the general simulation platform based on a preset protocol; if the negotiation result indicates success, establishing a bidirectional direct connection channel without an intermediate adaptation layer between the general simulation platform and the algorithm platform; and receiving function instructions and source scripts sent by the general simulation platform through the bidirectional direct connection channel.

[0050] In this embodiment, the general simulation platform actively initiates a connection establishment request. The connection establishment request includes unique identification information to identify the legitimacy and permission level of the initiator, such as the simulation module name, user permission level, or device serial number, to ensure that only authorized simulation systems can access the algorithm platform.

[0051] Upon receiving a connection request, the interaction module first verifies the identity information based on a pre-defined access control policy. This includes verifying whether the user exists on a pre-defined list, whether the information is valid, and whether the user has the necessary permissions to execute the current type of task. If the verification fails, the connection is rejected and a security log is logged, preventing unauthorized access and data breaches at the source.

[0052] Assuming successful verification, a bidirectional negotiation process for the protocol and interface is initiated. The interaction module, based on preset communication protocol specifications (such as FMI, TCP / IP, ProtoBuf, etc.), dynamically interacts and aligns with the general simulation platform on key parameters such as data transmission format, encoding method, message frame structure, error code definition, and heartbeat mechanism. This ensures semantic consistency between the two parties, preventing parsing failures or data misalignment due to protocol inconsistencies. This negotiation process is bidirectional and adaptive; the algorithm platform can proactively propose its supported best practice configurations (e.g., recommending double-precision floating-point and row-first memory layout), while the simulation platform can provide feedback on its environmental constraints (e.g., only supporting short TCP connections), ultimately reaching a mutually acceptable unified standard.

[0053] When the negotiation result is successfully confirmed, a direct bidirectional connection channel is established between the general simulation platform and the algorithm platform without the intervention of any intermediate adaptation components. The two ends of the bidirectional direct connection channel connect the general simulation platform and the algorithm platform respectively, forming an end-to-end point-to-point connection. In scenarios deployed on the same physical host or the same computing node, the bidirectional direct connection channel can be implemented based on the shared memory mechanism provided by the operating system. A physical memory region accessible to both processes is allocated in kernel mode or user mode. Access permissions are established through memory mapping or anonymous shared memory. The simulation platform directly writes instructions and input data to a designated buffer in this memory region, and the algorithm platform directly reads the contents of this region through polling or event notification mechanisms, without undergoing any system calls or data copying processes, thus achieving zero-copy data transmission. In cross-node deployment scenarios, the bidirectional direct connection channel can be implemented using a user-mode network protocol stack, such as a low-latency network communication stack built based on remote direct memory access technology or a data plane development kit. This type of implementation bypasses the kernel protocol processing flow of traditional transmission control protocols, directly completing the sending and receiving of data packets through the network card hardware, avoiding the overhead of kernel context switching, buffer copying, and protocol header processing. The communication messages can adopt a customized binary format with a simple structure, including necessary fields such as instruction type identifier, data length field, source / destination identifier, timestamp, and CRC32 checksum. There is no redundant encoding structure, ensuring minimum packet length and parsing efficiency for a single transmission. The bidirectional direct connection channel carries all subsequent instruction and data interactions with low overhead, high bandwidth, and low latency, completely avoiding the additional latency and single points of failure caused by the introduction of conversion proxies, message queues, or data gateways in related solutions. After the direct connection channel is established, the algorithm platform continuously listens for and receives data sent from the general simulation platform through this channel, including structured function instructions used to trigger specific computational tasks, as well as source script files or script strings.

[0054] This embodiment establishes a secure, standardized, direct connection channel without an intermediate adaptation layer through identity verification and bidirectional protocol negotiation, enabling efficient, reliable, and low-latency transmission of instructions and scripts between the simulation platform and the algorithm platform, thus ensuring communication security and system real-time performance.

[0055] According to some optional embodiments of this application, the source script is converted into a lexical sequence, and the lexical sequence is parsed into an abstract syntax tree, specifically including the following steps: scanning the source script based on preset grammar rules, identifying and extracting preset lexical units in the source script, wherein the preset lexical units include at least one of the following: keywords, variable names, operators, and constants; performing legality checks on the preset lexical units, and generating a lexical sequence based on the preset lexical units that pass the legality checks; performing recursive descent parsing on the lexical sequence based on a context-free grammar to obtain an initial abstract syntax tree, wherein the context-free grammar is used to represent the grammatical production rules and symbol priority constraints of the programming language, and the initial abstract syntax tree is used to represent the hierarchical nesting relationship and semantic information of the source script; preprocessing the initial abstract syntax tree to obtain an abstract syntax tree, wherein the preprocessing includes the following steps: identifying and removing invalid components and redundant placeholder nodes in the initial abstract syntax tree; pre-computing the operational expressions composed of constants in the initial abstract syntax tree, and replacing the corresponding operational nodes with the calculation results; and simplifying the structure of conditional branches and loop paths in the initial abstract syntax tree based on the control flow logic of the source script.

[0056] In this embodiment, the script text is first scanned character by character based on preset syntax rules to accurately identify and extract various preset words contained therein. These preset words include, but are not limited to, core keywords of programming languages ​​(such as if, for, function), variable identifiers, arithmetic and logical operators (such as +, ==), numerical constants (such as 3.14, 0x1F), and string literals, ensuring the integrity and accuracy of the lexical level.

[0057] Then, each extracted token is validated for legality, such as checking whether the variable name conforms to the naming convention, whether the operator usage conforms to the context semantics, whether the constant overflows or has a format error, etc. Illegal or semantically abnormal tokens are removed, and only legal tokens that conform to the syntax are retained. They are then organized into an ordered token sequence according to their order of appearance in the source code.

[0058] Furthermore, a recursive descent parsing algorithm based on Context-Free Grammar (CFG) is employed to progressively map the token sequence into an initial abstract syntax tree with a hierarchical structure. The CFG is precisely defined by the official grammar production rules of programming languages ​​(such as MATLAB) and incorporates semantic information such as operator precedence and associativity constraints to ensure that the parsing process conforms to language standards.

[0059] For example, the expression "a+b×c" is correctly parsed as a multiplication node nested under an addition node, rather than incorrectly forming a left-associative structure, thus fully preserving the original semantic intent of the source script. The generated initial AST fully reflects the nested structure and logical dependencies of statements such as function calls, variable assignments, conditional statements, and loop control in the source script, serving as the semantic carrier for subsequent semantic transformation and optimization.

[0060] To further improve parsing quality and execution efficiency, the initial AST undergoes multi-dimensional preprocessing to better suit the execution requirements of the algorithm platform. Specifically, invalid components without actual semantics in the initial AST are identified and removed, such as empty statement nodes, redundant parentheses placeholder nodes, and residual comment structures, making the tree structure compact and free of redundancy. Static expressions composed of constants (such as "2×3+5" or "sin(pi / 2)") are optimized using constant folding, directly calculating their results at compile time and replacing the corresponding operation nodes with the calculated values ​​(such as 11 or 1.0), thereby reducing runtime computation overhead. In addition, based on the control flow logic of the source script, the semantics of conditional branches and loop structures are simplified. For example, conditional judgments that are always true or always false (such as if(1>0)) are directly expanded into a single-path execution structure, or nested and repetitive loop bodies are merged to eliminate logical redundancy.

[0061] The final abstract syntax tree after the above preprocessing fully preserves the semantic integrity of the script and has the characteristics of being concise, efficient, and optimizable.

[0062] In some optional embodiments of this application, the replaced abstract syntax tree is split according to functional modules to obtain intermediate code corresponding to each functional module. Specifically, this includes the following steps: identifying logical boundaries in the abstract syntax tree, wherein logical boundaries are used to characterize function definitions, class definitions, or independent logical blocks; splitting the abstract syntax tree into multiple functional modules with independent execution characteristics using logical boundaries; mapping each functional module to code that can be recognized by the algorithm platform to obtain intermediate code corresponding to each functional module, and constructing a global symbol table, wherein the global symbol table is used to record interface call relationships and global variable reference relationships between functional modules.

[0063] In this embodiment, semantic analysis is used to identify logical boundaries in the abstract syntax tree. These logical boundaries correspond to functional units naturally present in the source script, including but not limited to function definitions (e.g., function y = myCalc(x)), class definitions (e.g., classdef MySystem), modular script blocks (e.g., independent calculation segments separated by comments), or explicitly encapsulated independent logical regions. After identifying the logical boundaries, the complete abstract syntax tree is decomposed into several subtrees using these boundaries as dividing points. Each subtree constitutes a functional module with independent input / output interfaces, closed internal states, and no external side effects, such as an independent control law function, a state observer module, or a signal preprocessing unit.

[0064] Furthermore, each functional module subtree is mapped to intermediate code that the algorithm platform can directly parse and execute. The intermediate code uses a neutral instruction set natively supported by the platform (such as LLVMIR or custom bytecode). Its instruction set design balances computational expressiveness and execution efficiency, accurately expressing high-level semantics such as matrix operations, loop iterations, and function calls, while shielding the differences in underlying hardware.

[0065] During the generation of intermediate code, a global symbol table is constructed simultaneously. This global symbol table comprehensively records the call dependencies between various functional modules. For example, it records whether module A calls the output of module B, or whether module C references global variable X, as well as the definition location and scope of all global variables, shared parameters, and cross-module constants. Through the global symbol table, the correctness of function call chains, the legality of variable references, and the uniqueness of memory addresses can be ensured even when multiple modules are compiled independently, thus avoiding linking conflicts or duplicate symbol definitions.

[0066] Furthermore, the global symbol table supports a dynamic update mechanism. When a new module is added or an interface is modified, dependencies can be automatically re-resolved, enabling incremental compilation and hot updates without restarting the entire simulation process. Finally, the intermediate code of each functional module and the global symbol table together constitute an executable set of semantic units, which are efficiently transmitted to the algorithm platform kernel through a direct connection. The kernel's scheduling engine then loads, optimizes, and executes these units in parallel on demand, significantly improving system efficiency and engineering flexibility.

[0067] As some optional embodiments of this application, after obtaining the intermediate code corresponding to each functional module, the script parsing module is further used to perform the following steps: obtain the modification status of the source script, locate the first functional module whose modification status indicates a change based on logical boundaries; analyze the scope of the influence of the first functional module on other functional modules using a global symbol table, and determine the second functional module affected by the change based on the scope of the influence; recompile the abstract syntax tree branches corresponding to the first and second functional modules; count the execution frequency of the intermediate code, and convert the hot code into the native machine code of the algorithm platform using just-in-time compilation technology, wherein the hot code is the intermediate code whose execution frequency is greater than a preset threshold; extract matrix operations that conform to the parallelization characteristics in the intermediate code, and use a global symbol table to parse the data flow constraints of matrix operations between functional modules; generate parallel execution instructions based on the data flow constraints, and distribute the parallel execution instructions to the parallel scheduling engine of the algorithm platform.

[0068] In this embodiment, when the simulation platform updates the script content, the first functional module that has changed is located through logical boundaries, such as a control algorithm function whose parameters have been modified or added. Then, the global symbol table is used to analyze the call and dependency relationships of the first functional module, identifying the downstream modules it directly affects (such as the observer module it calls) and the upstream modules it indirectly depends on (such as the preprocessing module that provides data input), thereby determining the set of second functional modules affected by the change. This ensures that the compilation update is minimized and accurate, and only the affected modules and their dependency chains are locally recompiled, significantly shortening the response time after the script update and supporting real-time debugging and online iteration during the simulation process.

[0069] Simultaneously, runtime performance monitoring is performed on the generated intermediate code, analyzing the execution frequency of each code segment and identifying frequently invoked hotspots, such as matrix inversion, state equation solving, or filtering operations that are repeatedly executed in each simulation step. For these hotspots, just-in-time (JIT) compilation technology is enabled to dynamically compile the corresponding intermediate code into native machine instructions of the algorithm platform, bypassing the overhead of interpreted execution and significantly improving the computation speed of critical paths. This can achieve several times the performance improvement, especially in high-frequency, low-latency real-time simulations.

[0070] Furthermore, the system proactively identifies matrix operations in the intermediate code that exhibit parallelization characteristics, such as large-scale element-wise multiplication, batch vector addition, or iterative state updates. It then uses a global symbol table to analyze the data flow paths and dependencies between functional modules involved in these operations, determining whether data races, memory barriers, or cross-module synchronization constraints exist. Based on this analysis, fine-grained parallel execution instructions are automatically generated, clarifying which operations can be safely parallelized, which data should be loaded first, and which modules should be executed synchronously. These instructions are then distributed to the algorithm platform's built-in parallel scheduling engine, which coordinates multi-core CPUs, GPUs, or dedicated computing units for efficient parallel computation, achieving optimal utilization of computing resources.

[0071] This embodiment not only improves the overall throughput of complex simulation tasks, but also enables the system to adapt to input data of different scales and real-time loads, realize compile-time optimization and runtime adaptation, and provide continuous and automated acceleration capabilities for high-performance co-simulation.

[0072] In some optional embodiments of this application, after the intermediate code is sent to the algorithm platform, the script parsing module is further configured to perform the following steps: receive the calculation results returned by the algorithm platform and identify the data type of the calculation results, wherein the data type includes a matrix, array, or structure; match the corresponding conversion rule from the bidirectional mapping table according to the identified data type; and based on the memory arrangement and data bit width characteristics defined in the conversion rule, convert the calculation results from the storage format of the algorithm platform to a result format data compatible with the source programming language standard of the general simulation platform; wherein, for matrices or multidimensional arrays exceeding a preset size threshold, perform block conversion and data compression processing; send the result format data to the general simulation platform and generate an execution log, wherein the execution log includes at least one of the following: execution time, performance indicators, and error information; after the result format data is sent, release the computing resources and cache space occupied by this script execution.

[0073] In this embodiment, the raw calculation results returned by the algorithm platform are received through a bidirectional direct connection channel, and the underlying data structure of the results is deeply identified to accurately determine whether its data type is a matrix, array, or structure. The data type can be stored in the platform's native memory layout, such as a row-major contiguous array, a multidimensional tensor, or a pointer to a custom structure.

[0074] To ensure seamless reception by the general simulation platform, a bidirectional mapping table is used to find the semantically equivalent formula of the type in the source programming language (such as MATLAB) and match the corresponding reverse conversion rule. The bidirectional mapping table defines key details such as type mapping relationships (e.g., double[3x4] in the algorithm platform → 3×4 double-precision matrix in MATLAB), memory arrangement (e.g., from row-major to column-major), data bit width alignment (e.g., unified conversion of 64-bit double precision), and numerical range scaling (e.g., fixed-point to floating-point), ensuring that the converted data is semantically and numerically completely consistent with the native script environment.

[0075] For large-scale matrices or multidimensional arrays exceeding a preset size threshold, a combined block-based transformation and data compression strategy is employed. The massive array is divided into several sub-blocks, and format conversion and verification are performed block by block, avoiding system jitter or OutOfMemory (OOM) risks caused by excessive single memory allocation. Simultaneously, for data with continuous repetition or sparse structures, lightweight compression algorithms (such as run-length encoding or differential encoding) are used to reduce the amount of data transmitted while maintaining accuracy, thereby significantly reducing network bandwidth usage and transmission latency.

[0076] After conversion, the resulting data, conforming to the source language standard, is transmitted back to the general simulation platform via a direct connection, allowing it to be directly used for subsequent visualization rendering, simulation control, or data storage. Simultaneously, a complete execution log is automatically recorded. This log includes, but is not limited to, key performance indicators such as the total execution time of the script, peak memory usage, CPU utilization, parallel speedup ratio, computational accuracy deviation, and exception capture records, as well as any warnings or errors triggered during the parsing, conversion, or execution phases. The execution log is encapsulated in a structured format (such as JSON), supporting export, analysis, and long-term archiving, providing data support for simulation accuracy evaluation, system optimization, and fault tracing.

[0077] Furthermore, after the results are successfully transmitted back, the script parsing module initiates a resource cleanup process, releasing all temporary computing resources and cache space used in this execution, including intermediate AST nodes, temporary variable storage, JIT compilation cache, block buffers, and temporary copies of the symbol table, to avoid memory leaks and resource accumulation. This release process is atomic and automated, requiring no external intervention, ensuring the system maintains a stable and clean operating state throughout multiple consecutive script calls, providing a reliable foundation for the next simulation step or real-time interaction.

[0078] This embodiment not only ensures high-fidelity and low-latency transmission of calculation results, but also realizes intelligent resource recycling and continuous robustness of system operation, achieving efficient, secure, and traceable cross-platform collaborative execution.

[0079] As some alternative embodiments of this application, the bidirectional mapping table is generated through the following steps: In the standard function library of the programming language, type signature data of each standard function is extracted through static syntax analysis. The type signature data includes the function name, number of parameters, logical data type of each parameter, precision bit width of the return value, and dimension attributes. The underlying physical constraints of the hardware execution unit corresponding to the function call interface of the algorithm platform are obtained. These underlying physical constraints include memory alignment step size, data addressing mode in the storage medium, and register bit width constraints of the computational core. Based on the memory alignment step size and data addressing mode, the bidirectional mapping table in the programming language is calculated. The memory layout mapping values ​​between standard data types and algorithm platform interfaces are defined. These values ​​include rank transformation rules for converting from column-major storage at the source end to row-major storage at the target end, as well as data filling strategies or block splitting rules for register width constraints. Based on type signature data and memory layout mapping values, a bidirectional index structure is established between source function identifiers and target interface pointers. A bidirectional mapping table is generated based on this index structure. The bidirectional index structure supports automatic adaptation and conversion of function calls during script compilation and supports reverse tracing back to the syntax nodes of the source script based on the feedback status of the target interface during program execution.

[0080] This embodiment addresses the issue of low execution efficiency caused by incompatibility between data arrangement and function interfaces when high-level scripting languages ​​such as Matlab are converted to heterogeneous hardware platforms (such as specific DSPs or self-developed simulation kernels). The specific implementation logic is as follows:

[0081] First, the static analyzer is invoked to traverse the standard function library of the programming language. Taking the MATLAB matrix multiplication function C=mtimes(A,B) as an example, the function name mtimes and type signature data are extracted. Optionally, the function has two parameters and is a multidimensional matrix of type double. In particular, the attribute characteristics of the return value are labeled, including precision bit width (e.g., 64-bit) and dimensional attributes (e.g., the dynamic scaling of the output matrix M×N).

[0082] On the algorithm platform side, the underlying physical constraints of the execution unit are obtained through the hardware abstraction layer. Memory alignment step size: If the target DSP requires 128-bit alignment, the step size is set to 16 bytes. Addressing mode: The algorithm platform is checked to determine whether it supports circular addressing or bit-reversed addressing, in order to decide the stepping logic for data reading. The width of the single-instruction multiple-data register is obtained; for example, a 512-bit width means that a single instruction can process 8 double-precision floating-point numbers.

[0083] It is worth noting that since Matlab uses column-major storage by default, while many high-performance kernels use row-major storage, it is necessary to calculate the rank transformation rule.

[0084] Example scenario: When a 2×3 matrix is ​​input from the source, a mapping value is generated. How does the target end adapt the value through transposition or index remapping? Simultaneously, regarding register width, if the data length does not meet the 512-bit requirement, an automatic data padding strategy (adding zero values) or block splitting rule (cutting the large matrix into smaller blocks that fit the register size) is calculated to ensure full-load execution of computation instructions.

[0085] By associating the source function identifiers with the target interface pointers, a bidirectional index structure is established between the source function `mtimes` and the target kernel interface pointer `kernel_fma_v8`. When the compiler scans `mtimes` in the script, it directly replaces it with the `kernel_fma_v8` instruction through the table structure and automatically inserts it into memory to rearrange the code. When the algorithm platform encounters an error (such as an overflow) while executing `kernel_fma_v8`, it can quickly locate and report to the user which line and syntax node in the original M-script the error originated from, using the inverse pointer in the bidirectional index.

[0086] The above methods significantly improve the performance of simulation scripts on the algorithm platform.

[0087] Optionally, after establishing a bidirectional index structure between the source function identifier and the target interface pointer, the script parsing module is also used to perform the following steps:

[0088] Extract the logical functional attributes corresponding to the source function identifier, and associate and store the logical functional attributes, type signature data and memory layout mapping values ​​to encapsulate and form an index metadata entry that includes semantic features and physical layout features; wherein, the index metadata entry serves as an intermediate exchange carrier between the source script semantics and the target hardware logic;

[0089] The algorithm detects multiple execution units in the platform and obtains the underlying physical interface address corresponding to each execution unit. Based on the logical function attributes, it matches multiple physical interface addresses that meet the computing requirements and establishes a many-to-many dynamic mapping relationship between index metadata entries and physical interface address sets to construct a bidirectional index structure and generate a target interface pointer pool that supports runtime redirection.

[0090] During the algorithm platform operation phase, the execution status feedback of the target interface pointer is obtained by capturing the running status data; if the execution status triggers the preset abnormal threshold, the bidirectional index structure is called, and the coordinate system is reversed for the underlying physical address where the abnormality occurred according to the rank transformation inverse rule, so as to obtain the logical index of the target variable under the source storage topology.

[0091] By using logical indexes and the transformed coordinate mapping relationship, the physical memory offset pointed to by the target interface pointer is restored across layers to the corresponding variable syntax node or logical branch identifier in the source script, so as to determine the mapping relationship between the underlying hardware exception and the semantics of the top-level script.

[0092] In some optional embodiments, generating adaptation rules for function instructions specifically includes the following steps: scanning the source code or intermediate representation of the function instructions and locating the function entry point through lexical and syntactic analysis; establishing a data flow topology graph of the internal operators of the function instructions using semantic analysis, wherein the data flow topology graph is used to represent the execution order and data transmission path between internal operators; extracting the input-output tensor dimensions, numerical range constraints, and logical dependencies between variables of the function instructions based on the data flow topology graph; and constructing a function feature model based on the input-output tensor dimensions, numerical range constraints, and logical dependencies between variables, wherein the function feature model is used to represent... The system demonstrates the computational resource requirements of function instructions. If a function instruction does not have a matching item in the function feature library, it is determined to be a user-defined function. Multiple sets of probe vectors are constructed to test the user-defined function, capturing its output response and memory addressing patterns under different input magnitudes. Based on the output response and memory addressing patterns, the numerical mapping relationship and data layout of the user-defined function are determined. The transformation logic of the user-defined function is extracted based on the numerical mapping relationship and data layout. Adaptation rules are generated based on the transformation logic, whereby the adaptation rules represent the interface protocol mapping relationship and data alignment strategy between the user-defined function and the algorithm platform.

[0093] In this embodiment, to achieve intelligent recognition and seamless adaptation of arbitrary function instructions (including standard library functions and user-defined functions), the function adaptation module first performs a deep scan of the function's source code or intermediate representation, identifies key syntactic structures of the function declaration (such as the `function` keyword, parameter list, and return value identifier) ​​through lexical analysis, and then accurately locates the function's entry node and scope boundary by combining syntactic analysis, ensuring that subsequent analysis revolves around complete and independent function units.

[0094] Building upon this foundation, the function adaptation module performs semantic analysis to construct a data flow topology graph connecting all operators within the function (such as addition, matrix multiplication, conditional jumps, and loop iterations). This data flow topology graph, presented as a directed acyclic graph, precisely depicts the input source, output flow, and execution order of each operator, clearly demonstrating how variables are passed and transformed layer by layer from the input, ultimately converging into the output result, thus fully reconstructing the function's computational logic.

[0095] Based on the data flow topology graph, the core features of the function are further extracted. These core features include, but are not limited to: the dimensions of all input and output tensors (e.g., [3, 128, 128]), numerical range constraints (e.g., input is [0, 1] normalized floating point, output is [-10, 10] signed value), and explicit or implicit logical dependencies between variables (e.g., an intermediate variable is referenced by multiple branches, or an output depends on the result of the previous loop iteration).

[0096] Then, the aforementioned dimensions, scope, and dependency information are comprehensively modeled to generate a structured function feature model. This function feature model not only characterizes the input / output interface specifications of a function but also quantifies its computational resource requirements, such as whether it involves large-scale parallel matrix operations, whether there is load skew due to branch imbalance, and whether it relies on high-precision floating-point operations or special vector instructions.

[0097] When the function adaptation module fails to find a known pattern matching the current function in its built-in function feature library, it determines that the function is a user-defined function. At this point, an adaptive learning mechanism is activated: by constructing a set of probe vector inputs covering different magnitudes (e.g., 1×1, 10×10, 1000×1000) and different distributions (uniform, sparse, abrupt edge changes), the function execution is actively triggered, and its output response pattern and memory access trajectory are captured in the algorithm platform kernel. The output response pattern refers to the systematic changes in the function's output in terms of value, structure, and timing after receiving different input probe vectors; the memory access trajectory reflects the function's access patterns to system memory resources and its hardware interaction characteristics during execution.

[0098] Based on the output response pattern and memory access trajectory, the numerical mapping relationship of the custom function (such as whether the input x and output y have a linear, polynomial, or nonlinear function relationship) and the data layout pattern (such as whether it is stored in row-major order or whether there is a sparse compression pattern in a specific dimension) are derived in reverse. Further, by combining the control flow structure inside the function, the essential transformation logic is determined, such as "normalizing each column of the input matrix, performing an FFT, and then squaring the real part" or "dynamically selecting the outputs of two sub-functions based on a threshold."

[0099] The above transformation logic is abstracted into a set of encodeable semantic rules to generate precise adaptation rules. These adaptation rules include, but are not limited to: the specific interface functions that the algorithm platform needs to call, the format conversion requirements of the input parameters (such as changing from column-major to row-major), the data alignment strategy (such as padding each row with zeros to 32 bytes), the memory copy method (whether zero copy is supported), and the post-processing instructions for the output results (such as whether truncation or saturation processing is required).

[0100] This embodiment combines static analysis and dynamic detection to achieve fully automated feature modeling and adaptation rule generation for standard and custom functions. It accurately maps function semantics, computing power requirements, and hardware execution behavior, enabling complex functions to achieve high-fidelity, low-overhead adaptation and efficient execution in heterogeneous algorithm platforms.

[0101] According to some preferred embodiments of this application, the adaptation and dimensional transformation of input parameters based on the kernel requirements of the algorithm platform specifically includes the following steps: Based on the word length specifications and endianness requirements in the kernel requirements, the input parameters are converted to different data types and reordered by bytes to obtain preliminary adaptation parameters; the tensor computation step size and alignment threshold in the kernel requirements are extracted; if the dimension of the preliminary adaptation parameters is found to be inconsistent with the input specifications of the function instructions, dimensional expansion or dimensional compression is performed on the preliminary adaptation parameters; wherein, dimensional expansion uses zero-padding or repetitive mapping strategies to align low-dimensional data to a high-dimensional computation space, and dimensional compression uses block slicing or strafing sampling strategies to extract feature subsets; the transformation results are corrected based on adaptation rules to obtain adaptation parameters, specifically including the following steps: Based on the parallel computing architecture of the algorithm platform, the memory mapping algorithm defined in the adaptation rules is called; based on the memory mapping algorithm, the memory layout of the parameters after dimensional expansion or dimensional compression is rearranged to perform the correction; the rearranged parameters are transformed into a linearized data stream that meets the data alignment requirements in the adaptation rules using continuous address space mapping to obtain adaptation parameters.

[0102] In this embodiment, the function adaptation module parses the kernel's word length specification (e.g., a mandatory 64-bit double-precision floating-point requirement) and endianness requirements (e.g., big-endian or little-endian), and accordingly performs precise data type conversion and byte order reordering on the input parameters. For example, if the simulation platform transmits a 32-bit single-precision floating-point array, it automatically promotes it to double-precision format and performs endianness reversal at the byte level to ensure that the values ​​are correctly interpreted in the algorithm platform's registers and memory, avoiding numerical distortion or computational crashes caused by bit width mismatch or byte order reversal.

[0103] Furthermore, the computational step size (such as the memory offset for each dimension) and alignment threshold (such as 16-byte boundary alignment) of the kernel for tensor operations are extracted, and the actual dimensions of the initially adapted parameters are compared with the input specifications declared in the target function instructions. When a dimension mismatch is found, for example, the simulation platform inputs a one-dimensional vector, while the target function expects a two-dimensional matrix.

[0104] The function adaptation module automatically performs dimensional transformations according to preset strategies: if dimensionality needs to be increased, a zero-padding strategy (padding zeros on the new dimension) or a repetitive mapping strategy (such as copying a scalar as a matrix along a specified axis) is adopted to expand the low-dimensional data into a high-dimensional tensor that conforms to the function signature; if dimensionality needs to be reduced, a block slicing strategy (cutting out a specific dimensional range) or a step sampling strategy (taking one every N elements to achieve downsampling) is adopted to extract key feature subsets from the high-dimensional data, avoiding information redundancy and waste of computing resources.

[0105] After dimensional transformation, the process enters the memory layout optimization stage to adapt to the parallel computing architecture characteristics of the algorithm platform. Based on the embedded adaptation rule library, memory mapping algorithms that match the target hardware architecture (such as multi-core CPUs, GPUs, or AI accelerators) are invoked. These include vectorized layout for SIMD instruction sets, cache-friendly tile rearrangement, or NUMA-aware allocation for heterogeneous memory. The memory mapping algorithm is used to rearrange the parameters after dimensional transformation, converting the originally loose or non-contiguous storage structure into a highly compact, aligned linear data flow. This ensures that the arrangement of each data element in physical memory fully conforms to the alignment constraints (such as 16-byte or 32-byte alignment) and access mode requirements defined in the adaptation rules.

[0106] Finally, through contiguous address space mapping technology, the rearranged tensor is encapsulated into a gapless, padding-free unified data buffer that can be directly read by the hardware instruction stream, generating adaptation parameters. These adaptation parameters not only meet the function's dimension and type requirements but also achieve interface with the underlying computing engine at the memory layout level, thereby maximizing data transfer efficiency and parallel execution throughput without sacrificing semantic integrity.

[0107] According to some optional embodiments of this application, after sending the function instructions, adaptation parameters, and scheduling strategies to the algorithm platform, the function adaptation module is further configured to perform the following steps: receiving multiple output results and execution status information returned by the algorithm platform, and establishing a full-link record; wherein, the multiple output results include the computational kernel output data corresponding to the function instructions, and the full-link record includes at least one of the following: input parameters, adaptation rules, scheduling strategies, and multiple output results; performing precision verification and integrity verification on the multiple output results; if the verification determines that the deviation of the multiple output results exceeds a preset range or the results are incomplete, then the function feature model is traced back based on the deviation data, and the adaptation rules are adjusted or computational resources are reallocated based on the function feature model to request the algorithm platform to re-execute; after the multiple output results pass the verification, the effective adaptation features in the adaptation parameters and the corresponding execution status log are extracted, and the effective adaptation features are synchronously updated to the function feature library; the multiple output results and execution status log after verification are synchronously transmitted back to the general simulation platform, wherein the execution status log is used to record the execution status of the adaptation process.

[0108] In this embodiment, the function adaptation module first receives multiple output results and precise execution status information returned by the algorithm platform through a high-reliability channel. The multiple output results include, but are not limited to, multiple tensors, structures, or heterogeneous data streams, each corresponding to multiple output ports defined by the function instruction. The execution status information includes, but is not limited to, key operational metrics such as computation time, resource utilization, whether an exception was triggered, parallelism utilization, and the number of floating-point exceptions.

[0109] In addition, to ensure that the entire process is traceable and auditable, the function adaptation module automatically generates a full-link record, which structurally associates all context information of this execution. The context information includes, but is not limited to, a complete copy of the original input parameters, the version of the adaptation rules in the actual application, the scheduling decision basis (such as priority and resource allocation scheme), and the final returned multiple output results, forming a complete data chain.

[0110] Then, a dual verification mechanism is implemented for multiple output results: on the one hand, precision verification is performed by comparing the output value with the preset numerical range of the function feature model, the expected precision threshold (such as relative error ≤1e-6), or the historical convergence curve to identify whether there is systematic drift, rounding accumulation, or numerical instability; on the other hand, integrity verification is performed by checking whether the number of outputs is consistent with the function signature, whether the dimensions of each tensor match, whether there are null values, NaN, or abnormal overflows, to ensure that the data is not lost or damaged due to transmission interruption, memory out-of-bounds, or kernel crash.

[0111] If any verification fails, the result is not discarded directly. Instead, an intelligent feedback correction mechanism is activated: based on the deviation data in the end-to-end record, the mechanism traces back to the feature model of the function to analyze whether the error is due to a dimension mapping error in the adaptation rules, an inappropriate data alignment strategy, or computational distortion caused by resource contention due to the scheduling strategy. The adaptation rules are then dynamically adjusted (e.g., correcting the padding strategy or adjusting the data bit width) or computational resources are reallocated (e.g., adding parallel units or extending the timeout threshold), and the algorithm platform is automatically triggered to re-execute until the result meets the accuracy and integrity constraints, thus achieving closed-loop fault tolerance.

[0112] After successful verification, the system enters a continuous learning and model evolution phase. Representative and effective adaptation features are extracted from the adaptation parameters and execution status logs of this successful execution. Examples include "when the input size is greater than 512×512, switching from column-first to row-first improves efficiency by 40%" or "using 16-byte alignment reduces DMA transfers by 30%." This empirical knowledge is then structured and injected into the function feature library to update or expand the existing model of the function. This mechanism enables the system to continuously self-optimize. Each successful execution provides more accurate prior knowledge for adapting similar functions in the future, gradually reducing reliance on dynamic probing and improving overall adaptation efficiency. Finally, the verified multi-output results and execution status logs are synchronously transmitted back to the general simulation platform via a bidirectional direct connection.

[0113] Figure 2 This is a schematic diagram illustrating the interaction between a co-simulation data processing system 1 and an external platform according to an embodiment of this application, as shown below. Figure 2 As shown, by constructing a bidirectional direct connection architecture to eliminate the intermediate adaptation layer, direct interaction of instructions and data between the algorithm platform (such as the Beitai Tianyuan kernel) and the general simulation platform can be achieved; the script parsing module can achieve seamless adaptation and debugging capabilities of general simulation syntax; and the function adaptation module can achieve automatic expansion, intelligent scheduling, and data verification of multi-input and multi-output functions, ultimately forming a lightweight, highly compatible, low-latency, and highly reliable seamless integration architecture.

[0114] Figure 3 This is a flowchart of an interactive module according to an embodiment of this application, such as... Figure 3 As shown, the specific working steps of the interaction module are as follows.

[0115] 1. Initiate connection request: The general simulation platform sends a connection establishment request to the bidirectional direct connection module, triggering the integration process.

[0116] 2. Protocol / Interface Negotiation: The bidirectional direct connection module and the simulation platform complete bidirectional negotiation of multiple protocols such as FMI, TCP, and ProtoBuf to match the interface standards of both parties.

[0117] 3. Establish a two-way direct connection channel: After the negotiation is completed, a two-way direct connection channel without an intermediate adaptation layer is established to realize direct interaction between commands and data.

[0118] 4. Issuing Invocation Commands: The general simulation platform issues simulation calculation invocation commands, parameters, and M-scripts to the directly connected modules.

[0119] 5. Instruction parsing and format conversion: The direct-connect module completes instruction syntax parsing, data type identification, and lossless format conversion, eliminating heterogeneous differences between the platform and the kernel.

[0120] 6. Direct instruction forwarding to the algorithm platform: The converted instructions are directly forwarded to the scientific computing kernel without delay or loss.

[0121] 7. Perform numerical computation / matrix computation / script processing: The scientific computing kernel performs core computational tasks such as high-precision numerical computation, matrix operations, and M-script execution.

[0122] 8. Return calculation result data: The kernel sends the calculated result data back to the bidirectional direct connection module.

[0123] 9. Data Validation and Format Conversion: The direct connection module performs integrity and legality checks on the result data and completes format adaptation and conversion.

[0124] 10. Results are directly transmitted back to the platform: Results that pass verification are directly transmitted back to the general simulation platform without intermediate forwarding loss.

[0125] 11. Receive simulation results: The simulation platform receives the results and completes subsequent business processes such as simulation scheduling and visualization.

[0126] 12. Connection Status Monitoring / Anomaly Handling: Real-time monitoring of connection status throughout the entire process, enabling automatic reconnection, data retransmission, and fault tolerance to ensure stable system operation.

[0127] Figure 4 This is a flowchart of a script parsing module according to an embodiment of this application, such as... Figure 4 As shown, the specific working steps of the script parsing module are as follows.

[0128] 1. Receive scripts from the general simulation platform.

[0129] 1.1 It receives M-script files / strings from the general simulation platform through the standardized interface of the bidirectional direct connection module, supporting multiple formats such as .m files, script fragments, and function scripts;

[0130] 1.2 Built-in script integrity verification, which verifies that the script transmission is not corrupted through MD5 signature, and supports breakpoint resume and large file segment reception;

[0131] 1.3 Automatically recognizes script encoding formats (UTF-8 / GBK, etc.) and performs unified encoding conversion to avoid garbled characters.

[0132] 2. Syntax preprocessing + dependency analysis.

[0133] 2.1 Preprocessing: Automatically remove comments, blank lines, and redundant formatting from the script, unify code indentation and syntax, and generate standardized script text;

[0134] 2.2 Dependency Analysis: Through static code scanning, dependencies such as import, run, and calls to external functions in the script are automatically identified, and a dependency tree is constructed;

[0135] 2.3 Dependency Loading: Automatically loads dependent script files, function libraries, and data files, achieving automatic dependency completion without manual configuration.

[0136] 3. Lexical / syntactic analysis + AST construction.

[0137] 3.1 Lexical Analysis: Based on Matlab syntax rules, the script text is split into a sequence of tokens (keywords, variables, operators, constants, etc.) to complete lexical validity verification;

[0138] 3.2 Syntactic Analysis: Based on a custom Matlab grammar context-free grammar (CFG), the token sequence is parsed into an abstract syntax tree (AST), preserving the complete syntactic structure and semantic information of the script;

[0139] 3.3 AST Optimization: Redundant nodes are eliminated, constants are folded, and control flow is optimized in the AST to lay the foundation for subsequent compilation and execution.

[0140] 4. Syntax compatibility check + adaptation.

[0141] 4.1 Compatibility check: Match the AST with the syntax set supported by the scientific computing kernel to identify incompatible syntax, functions, and data types;

[0142] 4.2 Automatic adaptation: Automatically convert compatible syntax (e.g., convert Matlab's dot matrix multiplication operation to the corresponding operation in the scientific computing kernel, and adapt the syntax of control flow statements).

[0143] 4.3 Error Prompt: For syntax that cannot be automatically adapted, a detailed compatibility report is generated, indicating the incompatible locations, reasons, and modification suggestions, and manual intervention is supported.

[0144] 5. Function library mapping + instruction conversion.

[0145] 5.1 Function Mapping Table: A bidirectional mapping table between the built-in Matlab standard function library (matrix operations, numerical computation, signal processing, etc.) and scientific computing kernel functions, covering more than 90% of commonly used Matlab functions;

[0146] 5.2 Instruction Conversion: Automatically replace Matlab function calls in the AST with corresponding function calls in the scientific computing kernel, completing bidirectional adaptation of function instructions;

[0147] 5.3 Support for custom functions: Supports automatic parsing and mapping of user-defined Matlab functions, enabling direct execution of custom functions.

[0148] 6. Modular compilation + pre-execution optimization.

[0149] 6.1 Modular compilation: The AST is split into functional modules and modularly compiled to generate intermediate code (IR) that can be executed by the scientific computing kernel, supporting incremental compilation and hot updates;

[0150] 6.2 JIT Just-In-Time Compilation: JIT just-in-time compilation is performed on frequently accessed code, converting intermediate code into machine code to improve execution efficiency;

[0151] 6.3 Parallel Optimization: Automatically identifies parallelizable matrix operations and loop statements, generates parallel execution instructions, and adapts to the parallel computing scheduling engine of the scientific computing kernel.

[0152] 7. Breakpoint debugging + execution control.

[0153] 7.1 Breakpoint Management: Supports inserting breakpoint markers into AST nodes, enabling the setting and management of row-level breakpoints and conditional breakpoints;

[0154] 7.2 Execution Control: Provides control commands such as single-step execution, continue execution, pause, and terminate to control the execution flow of the script in real time;

[0155] 7.3 Variable monitoring: Capture variable values ​​in real time during execution, support variable viewing, modification, and log output, and achieve full-process debuggability.

[0156] 8. Forward the execution instructions to the algorithm platform.

[0157] 8.1 The transformed and optimized code is forwarded to the algorithm platform through the two-way direct connection interaction module.

[0158] 9. The algorithm platform performs numerical / matrix calculations.

[0159] 9.1 The compiled intermediate code is sent to the algorithm platform, which calls the numerical computation engine, matrix operation library and parallel scheduling engine of the algorithm platform to perform calculations;

[0160] 9.2 Real-time synchronization of execution status, progress, and log information, and feedback to the simulation platform and debugging module;

[0161] 9.3 Supports asynchronous execution, batch execution, and scheduled execution of scripts, adapting to the timing control requirements of simulation platforms.

[0162] 10. Return the settlement result.

[0163] The 10.1 scientific computing kernel performs computations and returns the results to the M-script compatible parsing module via a bidirectional direct-connection interaction module.

[0164] 11. Reverse conversion of result format.

[0165] 11.1 Receive the calculation results returned by the scientific computing kernel and automatically identify the data type (matrix, array, structure, etc.).

[0166] 11.2 Following the Matlab data format standard, perform reverse data conversion to generate a Matlab-compatible result format;

[0167] 11.3 Large-size matrices and multidimensional arrays are segmented, converted, and compressed to ensure efficient and complete data transmission.

[0168] 12. Result feedback + log output.

[0169] The 12.1M script-compatible parsing module transmits results and logs to the general simulation platform via a two-way direct-connection interactive module.

[0170] 13. Simulation platform receives results and logs.

[0171] 13.1 The converted Matlab-compatible results are sent back to the general simulation platform via a bidirectional direct connection module for simulation scheduling and visualization.

[0172] 13.2 Generates a complete execution log, including script execution time, performance data, error messages, debugging records, etc., and supports log export and analysis;

[0173] 13.3 Complete the resource release for this script execution to prepare for the next script execution.

[0174] Figure 5 This is a flowchart of a function adaptation module according to an embodiment of this application, such as... Figure 5 As shown, the specific working steps of the function adaptation module are as follows.

[0175] 1. Receive MIMO function commands and multiple input parameters issued by the general simulation platform.

[0176] 1.1 Through the standardized interface of the bidirectional direct connection module, it receives MIMO function instructions (function name, execution priority, timing requirements) and multiple sets of input parameters (matrix, array, constant, etc.) issued by the general simulation platform, supporting both batch and asynchronous issuance modes;

[0177] 1.2 Built-in parameter integrity check: Checks whether the number, dimensions, and data type of input parameters meet the basic requirements of the MIMO function. Missing parameters are automatically triggered to complete the request. Abnormal parameters (such as null values ​​or values ​​outside the range) are initially marked.

[0178] 1.3 Synchronously receive timing control instructions (such as execution deadline and priority) from the simulation platform to provide a basis for subsequent intelligent scheduling and ensure that the adaptation process is consistent with the timing requirements of the simulation platform.

[0179] 2. Dynamic identification and classification of MIMO functions.

[0180] 2.1 Based on the built-in MIMO function feature library, the system automatically identifies the type of MIMO function through function name matching and parameter structure analysis: distinguishing between linear MIMO functions (such as solving multiple input multiple output linear equation systems) and nonlinear MIMO functions (such as nonlinear simulation models), as well as static MIMO functions (with fixed parameters) and dynamic MIMO functions (with parameters changing in real time).

[0181] 2.2 Through static code scanning and semantic analysis, the input and output dimensions, parameter constraints, and execution dependencies (such as whether they depend on the execution results of other functions) of the MIMO function are extracted, and a function feature model is constructed.

[0182] 2.3 For unrecognized custom MIMO functions, the feature learning mechanism is automatically triggered to extract the input-output patterns of the function, generate temporary adaptation rules, and achieve compatibility adaptation of custom MIMO functions.

[0183] 3. Parameter parsing and dimension / precision identification.

[0184] 3.1 The received multiple sets of input parameters are analyzed one by one to identify the data type (integer, floating-point number, matrix, structure, etc.), dimension (one-dimensional array, two-dimensional matrix, multi-dimensional tensor), precision (single precision, double precision) and numerical range of each parameter;

[0185] 3.2 Through parameter correlation analysis, identify the correlation relationships (such as dependency relationships and constraint relationships) between multiple input parameters, avoid parameter conflicts, and ensure that the parameter combination meets the execution requirements of the MIMO function;

[0186] 3.3 Store the parsed parameter information in the parameter management library to establish the correspondence between input parameters and MIMO functions, providing data support for subsequent parameter adaptation and scheduling optimization.

[0187] 4. Dynamic parameter adaptation (format / type / precision adjustment).

[0188] 4.1 Based on the parameter requirements of the scientific computing kernel, the input parameters are automatically adapted and adjusted: format adaptation (converting the parameter format of the simulation platform into a format that the kernel can recognize), type adaptation (e.g., converting integer parameters into floating-point types to meet the needs of high-precision calculation), and precision adaptation (unifying parameter precision to avoid precision loss).

[0189] 4.2 To address the issue of dimension mismatch in multiple input parameters, the system automatically performs dimension expansion or compression (e.g., expanding a one-dimensional array into a two-dimensional matrix, or reducing the dimension of a high-dimensional matrix) to ensure that the parameter dimensions are consistent with the input requirements of the MIMO function.

[0190] 4.3 Supports dynamic adjustment of parameters. Based on subsequent execution feedback (such as insufficient accuracy), the parameter adaptation strategy is optimized in real time to improve calculation accuracy and execution efficiency.

[0191] 5. Adaptation rule verification and abnormal parameter correction.

[0192] 5.1 Compare the adapted parameters with the MIMO function's adaptation rule base to verify the rationality of the parameter adaptation (such as whether the parameter range meets the function requirements and whether the precision meets the computational needs), and ensure that the adapted parameters can be directly used for kernel computation;

[0193] 5.2 For abnormal parameters that fail the verification, an automatic correction mechanism is triggered: minor abnormalities (such as insufficient accuracy) are automatically completed and corrected, while serious abnormalities (such as parameters exceeding the reasonable range) are fed back to the simulation platform to request the parameters to be reissued or manual intervention is required.

[0194] 5.3 Record the parameter adaptation and verification process and generate adaptation logs to provide a basis for subsequent troubleshooting and adaptation rule optimization.

[0195] 6. Intelligent scheduling and resource allocation.

[0196] 6.1 Based on the type, computational load, and execution priority of the MIMO function, combined with the real-time resource usage of the scientific computing kernel (CPU, memory, and parallel computing unit load), computing resources are dynamically allocated to avoid resource waste and conflicts.

[0197] 6.2 For scenarios involving concurrent execution of multiple MIMO functions, a strategy combining time-sharing scheduling and parallel scheduling is adopted: high-priority, high-real-time MIMO functions are allocated resources first, and parallel MIMO functions that can be executed in parallel (without dependencies) are started for parallel computation to improve overall execution efficiency;

[0198] 6.3 Built-in scheduling algorithms (such as greedy algorithms and priority scheduling algorithms) optimize scheduling strategies in real time and dynamically adjust resource allocation schemes according to function execution progress and resource changes to ensure the real-time performance and stability of the simulation system.

[0199] 7. Issue the adapted commands and parameters.

[0200] 7.1 The adapted MIMO function instructions and input parameters, combined with scheduling strategies (such as execution order and resource allocation schemes), are directly sent to the scientific computing kernel through the bidirectional direct connection module without intermediate layer, ensuring that the instructions and parameters are transmitted without delay or loss.

[0201] 7.2 During the distribution process, execution control instructions (such as execution timeout and interrupt conditions) are transmitted synchronously to facilitate the kernel control function execution flow. At the same time, an instruction distribution feedback mechanism is established to confirm that the kernel has successfully received the instructions and parameters.

[0202] 7.3 For batch-issued MIMO functions, issue them sequentially according to the scheduling order to ensure the timing consistency of function execution and avoid conflicts between multiple function executions.

[0203] 8. The algorithm platform executes the MIMO function for multi-input computation.

[0204] 8.1 After receiving the adapted instructions and parameters, the algorithm platform calls the numerical calculation engine and matrix operation library to perform multi-input collaborative calculation of the MIMO function. It selects the corresponding calculation algorithm according to the function type (linear / nonlinear) to ensure calculation accuracy and efficiency.

[0205] 8.2 During the calculation process, the execution progress and resource usage are synchronized in real time to the MIMO function dynamic adaptation module, which facilitates real-time monitoring and scheduling adjustment of the module;

[0206] 8.3 After the calculation is completed, multiple sets of output results are generated (corresponding to the input parameters, supporting multiple formats such as matrices, arrays, and structures), and the results are initially verified to ensure the integrity of the results.

[0207] 9. Receive multiple output results returned by the kernel.

[0208] 9.1 Receive multiple output results of the MIMO function returned by the scientific computing kernel through the bidirectional direct connection module channel, and simultaneously receive the execution status (success / failure, computational accuracy, execution time) fed back by the kernel.

[0209] 9.2 Built-in result reception verification mechanism to check whether the quantity, dimensions, and format of the results are consistent with expectations, to confirm that the results are not damaged or lost during transmission, and to automatically trigger a retransmission request if a transmission abnormality occurs.

[0210] 9.3 The received results are associated with and stored with the corresponding MIMO function and input parameters to establish a complete "input-adaptation-computation-output" link record, which facilitates subsequent traceability and optimization.

[0211] 10. Verification of result accuracy and completeness.

[0212] 10.1 Perform dual verification on the received multiple output results: accuracy verification (compare the deviation of the result with the expected accuracy to ensure that the deviation is within the allowable range) and integrity verification (check whether the result is complete, without missing or outliers).

[0213] 10.2 For cases where the accuracy is not up to standard or the results are incomplete, an optimization mechanism is automatically triggered: the parameter adaptation strategy is adjusted, resources are reallocated, and the kernel is requested to re-execute the MIMO function calculation until the results meet the requirements;

[0214] 10.3 Generate a result verification report, recording the verification results, deviation data, and optimization measures, providing data support for subsequent adaptation rule optimization and scheduling strategy adjustment.

[0215] 11. The general simulation platform receives result data and execution status logs.

[0216] 11.1 The multiple output results of the verified MIMO function are converted into a format that can be recognized by the general simulation platform and sent back to the simulation platform through the bidirectional direct connection module for simulation scheduling, visualization, and execution of subsequent simulation steps;

[0217] 11.2 Synchronously transmit the execution status log of the MIMO function (execution time, resource usage, accuracy data, adaptation process) to facilitate the simulation platform to monitor the entire execution process and troubleshoot abnormal issues;

[0218] 11.3 Complete the resource release for this MIMO function adaptation and execution, update the module's resource status and adaptation rule base, and prepare for the next MIMO function adaptation and execution.

[0219] In summary, this embodiment completely eliminates the traditional intermediate adapter layer and constructs a bidirectional direct connection architecture between the kernel and the simulation platform, realizing zero-relay, low-overhead direct interaction between instructions and data, significantly shortening the call chain, and compressing the system's end-to-end response time to the microsecond level, effectively meeting the stringent requirements of high-frequency, high-real-time simulation in aerospace, intelligent driving, and other application scenarios.

[0220] By deeply integrating the script parsing module, it supports lossless parsing, automatic conversion, and debugging execution of native MATLAB syntax (including functions, control flow, matrix operations, and custom scripts). Users can run directly on the scientific computing kernel without modifying any existing scripts, significantly reducing cross-platform migration costs and improving the compatibility and versatility of the scientific computing ecosystem.

[0221] Through the function adaptation module, the system can automatically identify input and output dimensions, parameter types, and execution dependencies, enabling automatic parameter alignment, adaptive dimension transformation, on-demand resource allocation, and concurrent scheduling for multi-input and multi-output functions. No manual configuration is required, and the system can flexibly handle simulation tasks of different scales and complexities, significantly improving the automation level and ease of use of the system.

[0222] By adopting a flattened architecture design, redundant overhead and single point of failure risks caused by intermediate components are eliminated, reducing system complexity. Combined with multi-level data verification, abnormal retransmission and status monitoring mechanisms, the integrity of the calculation process and the reliability of the results are ensured, comprehensively improving the robustness, security and overall operating efficiency of the system.

[0223] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0224] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0225] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

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

[0227] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0228] 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.

[0229] 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 related technologies, 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0230] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data processing system for co-simulation, characterized in that, include: The module includes an interaction module, a script parsing module, and a function adaptation module. The interaction module is used to perform the following steps: receiving function instructions sent by the general simulation platform and source scripts written in a programming language; forwarding the source scripts to the script parsing module and forwarding the function instructions to the function adaptation module; The script parsing module performs the following steps: converting the source script into a lexical sequence and parsing the lexical sequence into an abstract syntax tree (AST), wherein the nodes in the AST include variable nodes, function call nodes, and operator nodes; determining the type information corresponding to the dynamic type variables in the variable nodes and annotating the type information to the corresponding variable nodes; determining the parameter type characteristics of the function call nodes based on a bidirectional mapping table and the annotated type information, wherein the bidirectional mapping table is a bidirectional index structure pre-constructed according to the type signatures of the standard functions of the programming language and the parameter dimension constraints and memory layout requirements of the function call interface of the algorithm platform; replacing the function call nodes in the AST with the corresponding function call nodes in the algorithm platform that match the parameter type characteristics; splitting the replaced AST by functional modules to obtain the intermediate code corresponding to each functional module, and sending the intermediate code to the algorithm platform; The function adaptation module performs the following steps: identifying the function type of the function instruction, extracting the execution dependencies corresponding to the function instruction, and generating adaptation rules for the function instruction, wherein the adaptation rules are used to determine the matching criteria between the input parameters in the function instruction and the algorithm platform; parsing the attributes of the input parameters and identifying the constraint relationships between the input parameters; adapting and transforming the input parameters based on the kernel requirements of the algorithm platform, and correcting the transformation results based on the adaptation rules to obtain adaptation parameters; constructing a scheduling strategy based on the function type, the execution dependencies, and the resource consumption indicators of the algorithm platform; and sending the function instruction, the adaptation parameters, and the scheduling strategy to the algorithm platform.

2. The data processing system for co-simulation according to claim 1, characterized in that, Receiving function instructions and source scripts written in a programming language sent by the general simulation platform includes the following steps: Receive a connection establishment request sent by the general simulation platform, wherein the connection establishment request includes: identity identification information; Access verification is performed based on the aforementioned identity information; If the verification passes, bidirectional negotiation of interface standards and data formats is conducted with the general simulation platform based on a preset protocol; If the negotiation result indicates success, a bidirectional direct connection channel without an intermediate adaptation layer is established between the general simulation platform and the algorithm platform. The function instructions and source script sent by the general simulation platform are received through the bidirectional direct connection channel.

3. The data processing system for co-simulation according to claim 1, characterized in that, The source script is converted into a lexical sequence, and the lexical sequence is parsed into an abstract syntax tree, specifically including the following steps: The source script is scanned based on preset syntax rules to identify and extract preset words in the source script, wherein the preset words include at least one of the following: keywords, variable names, operators, and constants; The preset word elements are validated for legality, and a word element sequence is generated based on the preset word elements that pass the validity validation. Based on a context-free grammar, the lexical sequence is recursively parsed by descent to obtain an initial abstract syntax tree. The context-free grammar is used to represent the grammatical production rules and symbol precedence constraints of the programming language, and the initial abstract syntax tree is used to represent the nested relationship and semantic information of the source script. The initial abstract syntax tree is preprocessed to obtain the abstract syntax tree, wherein the preprocessing includes the following steps: Identify and remove invalid components and redundant placeholder nodes from the initial abstract syntax tree; Pre-compute the operational expressions composed of constants in the initial abstract syntax tree, and replace the corresponding operational nodes with the computation results; Based on the control flow logic of the source script, the conditional branches and loop paths in the initial abstract syntax tree are structurally simplified.

4. The data processing system for co-simulation according to claim 1, characterized in that, The replaced abstract syntax tree is split according to functional modules to obtain the intermediate code corresponding to each functional module. The specific steps include the following: Identify logical boundaries in the abstract syntax tree, wherein the logical boundaries are used to characterize function definitions, class definitions, or independent logical blocks; The abstract syntax tree is divided into multiple functional modules with independent execution characteristics using the logical boundaries. Each of the functional modules is mapped to code recognizable by the algorithm platform to obtain intermediate code corresponding to each functional module, and a global symbol table is constructed, wherein the global symbol table is used to record the interface call relationship between the functional modules and the global variable reference relationship.

5. The data processing system for co-simulation according to claim 4, characterized in that, After obtaining the intermediate code corresponding to each of the aforementioned functional modules, the script parsing module is further configured to perform the following steps: Obtain the modification status of the source script, and locate the first functional module whose modification status indicates a change based on the logical boundary; The global symbol table is used to analyze the scope of the influence of the first functional module on other functional modules, and the second functional module affected by the change is determined based on the scope of the influence. The abstract syntax tree branches corresponding to the first functional module and the second functional module are recompiled. The execution frequency of the intermediate code is statistically analyzed, and the hot code is converted into the native machine code of the algorithm platform using just-in-time compilation technology. The hot code is intermediate code whose execution frequency is greater than a preset threshold. Extract the matrix operations that conform to the parallelization characteristics from the intermediate code, and use the global symbol table to resolve the data flow constraints of the matrix operations between the functional modules; Based on the data flow constraints, parallel execution instructions are generated and distributed to the parallel scheduling engine of the algorithm platform.

6. The data processing system for co-simulation according to claim 1, characterized in that, After sending the intermediate code to the algorithm platform, the script parsing module is further configured to perform the following steps: Receive the calculation results returned by the algorithm platform and identify the data type of the calculation results, wherein the data type includes a matrix, an array, or a structure; Based on the identified data type, the corresponding conversion rule is matched from the bidirectional mapping table; Based on the memory arrangement and data bit width characteristics defined in the conversion rules, the calculation results are converted from the storage format of the algorithm platform to a result format data compatible with the source programming language standard of the general simulation platform; wherein, for matrices or multidimensional arrays exceeding a preset size threshold, block conversion and data compression processing are performed. The result format data is sent to the general simulation platform, and an execution log is generated, wherein the execution log includes at least one of the following: execution time, performance indicators, and error information; After the result format data is sent, release the computing resources and cache space occupied by this script execution.

7. The data processing system for co-simulation according to claim 1, characterized in that, The bidirectional mapping table is generated through the following steps: In the standard function library of the programming language, type signature data of each standard function is extracted through static syntax analysis. The type signature data includes function name, number of parameters, logical data type of each parameter, precision bit width and dimension attribute of return value. Obtain the underlying physical constraints of the hardware execution unit corresponding to the function call interface of the algorithm platform, wherein the underlying physical constraints include memory alignment step size, data addressing mode in storage medium, and register bit width constraints of the computing core. Based on the memory alignment step size and data addressing mode, calculate the memory layout mapping value between the standard data type in the programming language and the algorithm platform interface; wherein, the memory layout mapping value includes the rank transformation rule for converting from source column-first storage to target row-first storage, and the data filling strategy or block splitting rule for the register bit width constraint; Based on the type signature data and the memory layout mapping value, a bidirectional index structure is established between the source function identifier and the target interface pointer, and the bidirectional mapping relationship table is generated according to the bidirectional index structure; wherein, the bidirectional index structure supports automatic adaptation and conversion of function calls during the script compilation stage, and supports reverse tracing back to the syntax node of the source script according to the feedback status of the target interface during the program execution stage.

8. The data processing system for co-simulation according to claim 1, characterized in that, Generating adaptation rules for the function instructions specifically includes the following steps: The source code or intermediate representation of the function instructions is scanned, and the function entry point is located through lexical and syntactic analysis; A data flow topology graph of the internal operators of the function instruction is established using semantic analysis, wherein the data flow topology graph is used to represent the execution order and data transmission path between the internal operators; Based on the data flow topology graph, extract the input and output tensor dimensions, numerical range constraints, and logical dependencies between variables of the function instructions; Based on the input and output tensor dimensions, the numerical range constraints, and the logical dependencies between the variables, a function feature model is constructed, wherein the function feature model is used to represent the computing power requirements of the function instruction for computing resources. If the function instruction is found to have no matching item in the function feature library, it is determined to be a custom function. Multiple sets of probe vectors are constructed to test the custom function, and the output response and memory addressing pattern of the custom function under different input magnitudes are captured. Based on the output response and the memory addressing rules, the numerical mapping relationship and data layout of the custom function are determined, and the transformation logic of the custom function is extracted according to the numerical mapping relationship and the data layout. Based on the transformation logic, adaptation rules are generated, wherein the adaptation rules are used to represent the interface protocol mapping relationship and data alignment strategy between the custom function and the algorithm platform.

9. The data processing system for co-simulation according to claim 1, characterized in that, Based on the kernel requirements of the algorithm platform, the input parameters are adapted and their dimensions transformed, specifically including the following steps: Based on the word length specification and endianness requirements in the kernel requirements, the input parameters are converted in data type and reordered in byte order to obtain preliminary adaptation parameters; Extract the tensor computation step size and alignment threshold from the kernel requirements. If the dimension of the preliminary adaptation parameter is found to be inconsistent with the input specification of the function instruction, perform dimension expansion or dimension compression on the preliminary adaptation parameter. The dimension expansion uses a zero-padding or repeat mapping strategy to align low-dimensional data to a high-dimensional computation space, and the dimension compression uses a block slicing or step sampling strategy to extract feature subsets. The transformation results are corrected based on the adaptation rules to obtain the adaptation parameters, specifically including the following steps: Based on the parallel computing architecture of the algorithm platform, the memory mapping algorithm defined in the adaptation rules is invoked; Based on the memory mapping algorithm, the parameters after performing dimensional expansion or dimensional compression are rearranged in memory layout to perform the correction; The rearranged parameters are transformed into a linearized data stream that conforms to the data alignment requirements in the adaptation rules by using continuous address space mapping, thus obtaining the adaptation parameters.

10. The data processing system for co-simulation according to claim 8, characterized in that, After sending the function instruction, the adaptation parameters, and the scheduling strategy to the algorithm platform, the function adaptation module is further configured to perform the following steps: The algorithm platform receives multiple output results and execution status information, and establishes a full-link record; wherein, the multiple output results include the computation kernel output data corresponding to the function instruction, and the full-link record includes at least one of the following: the input parameters, the adaptation rules, the scheduling strategy, and the multiple output results; The multiple output results are subjected to accuracy and completeness verification. If the verification determines that the deviation of the multiple output results exceeds the preset range or the results are incomplete, the function feature model is traced back based on the deviation data, and the adaptation rules are adjusted or computing resources are reallocated based on the function feature model to request the algorithm platform to re-execute. After the multiple output results pass the verification, the adaptation parameters and the corresponding effective adaptation features in the execution status log are extracted, and the effective adaptation features are synchronously updated to the function feature library. The multiple output results after successful verification, along with the execution status log, are synchronously transmitted back to the general simulation platform. The execution status log is used to record the execution status of the adaptation process.

Images