Method and system for embedding script engine in modeling field

Abstract

The invention relates to the technical field of script engine embedding, and provides a method for embedding a script engine in the modeling field, which comprises the following steps: S1, selecting an embedding mode of the script engine; s2, if the mode is a separation process mode, the host process creates and starts a sub-process with a script engine; if the mode is the shared process mode, the host process calls a function provided by a script engine; s3, if the mode is a separation process mode, the host process sends an instruction to a script engine sub-process through a cross-process communication channel, and the script engine sub-process reads and analyzes a script; if the mode is a shared process mode, the host process directly transmits a script file path or a pre-processed script content memory address to a script engine; s4, when the host process triggers to exit, if the mode is a separation process mode, the host process sends a closing instruction to the script engine sub-process; if the mode is the shared process mode, the host process calls a cleaning function of the script engine. And the software freedom degree and the new function realization efficiency are improved without depending on manufacturer customization.

Description

Technical Field

[0001] This invention relates to the technical field of script engine embedding, and more particularly to a method and system for embedding a script engine in the field of modeling. Background Technology

[0002] In the field of electronic circuit design and simulation, modeling software is a core tool supporting circuit performance verification, parameter optimization, and model construction. One of its core applications is helping users extract key model parameters from complex circuit simulation data and build circuit simulation models that meet actual needs based on these parameters. This process directly relates to the accuracy, reliability, and R&D efficiency of circuit design and is a crucial step for customers to achieve their personalized design goals. With the rapid iteration of electronic technology and the increasing complexity of circuit design scenarios, customers often propose numerous new concepts, methods, and ideas regarding model parameter extraction and model construction based on their own technical expertise and project requirements. This results in diverse and personalized customization needs for software functions.

[0003] However, the functional systems of mainstream modeling software are generally predefined and fixed by software vendors. Under this model, customers cannot independently fulfill specific functional requirements—whether it's recombining existing software functions to adapt to new modeling logic or developing entirely new functional modules to meet parameter extraction or model building needs in specific scenarios. They can only communicate with the software vendor, who will then develop or adjust the functionality based on their needs. This process has significant limitations: on the one hand, vendors need to go through a series of processes, including evaluating customer needs, initiating projects, developing, and testing, which typically takes a long time; on the other hand, for customized needs that are only applicable to specific customers or niche scenarios, vendors often prioritize these needs less, resulting in delayed implementation of customer requirements. This severely restricts the efficiency of customer modeling work and makes it difficult to meet customers' needs for rapid iteration of the modeling process.

[0004] The aforementioned customization model not only reduces the freedom of use of modeling software but also limits its application boundaries to some extent. Customers, as the actual implementers of modeling work, have the deepest understanding of their own needs and scenarios, yet they lack the means to independently invoke and combine software functions, making it impossible to quickly translate their technical ideas into actual software operation. Even if some requirements can be achieved simply through flexible combinations of existing functions, vendor intervention is still necessary, resulting in a waste of human and time costs and inhibiting customers' innovation in the modeling field. Therefore, the industry urgently needs a technical solution that can break this limitation, allowing customers to independently invoke existing functions of modeling software, freely combine functional modules, and even add custom functions without relying on vendors. This would significantly improve the software's flexibility and ease of use, empowering customers to quickly realize their personalized functional needs.

[0005] To address the aforementioned technical pain points, the field is gradually exploring the introduction of scalable functional execution units into modeling software, with script engines being a key technological direction. A script engine is essentially a tool capable of parsing and executing code. Its core capability lies in its ability to directly read script files written by users in specific programming languages ​​and execute corresponding functions according to the logic defined in the script. Currently, mainstream programming languages ​​supported by script engines include, but are not limited to, Python, Lua, JavaScript, Groovy, Perl, Ruby, and C#, adapting to different customers' technical habits and development stacks. By embedding a script engine into modeling software and exposing the software's application programming interface (API) to the aforementioned supported scripting languages, customers can leverage their familiar scripting languages ​​to independently call existing software functions, freely combine functional modules, and design entirely new functions based on their own needs—this technical approach effectively solves the efficiency problems of traditional function customization models, giving modeling software greater freedom and scalability. Summary of the Invention

[0006] To address the aforementioned issues, the present invention aims to provide a method and system for embedding a script engine in the modeling field. By embedding a script engine into modeling software and exposing the software API, customers can independently call and combine existing software functions or add custom functions using scripting languages ​​supported by Python, Lua, etc., without relying on vendor customization, thereby improving software flexibility and the efficiency of new function implementation. At the same time, the separate process mode can avoid script / engine issues from affecting the host process, while the shared process mode can ensure execution speed.

[0007] The above-mentioned objective of this invention is achieved through the following technical solutions: A method for embedding a script engine in the modeling domain includes the following steps: S1: Based on the functional customization requirements and performance stability requirements of the modeling software, select the embedding mode of the script engine. The embedding mode includes separate process mode and shared process mode. S2: Perform initialization operations on the script engine. If it is the separate process mode, the host process creates and starts a child process with the script engine after starting, and builds a cross-process communication channel. If it is the shared process mode, the host process calls the functions provided by the script engine to complete the engine initialization and specify configuration options. S3: In response to the user's instruction to execute the script, if it is the separated process mode, the host process sends the instruction to the script engine subprocess through the inter-process communication channel. The script engine subprocess reads and parses the script. For the host API that needs to be called, it serializes the API name and parameters and sends them back to the host process. The host process deserializes the API, executes it, and serializes the result and sends it back. The script engine subprocess deserializes the result, updates the execution context, and continues to execute the script. If it is the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types in the script into a format that the host process can recognize in order to call the host API. After the host API is executed, the wrapper function converts the return value into a format that the script engine can recognize and updates the execution context, and then continues to execute the script. S4: When the host process triggers exit, if it is in detached process mode, the host process sends a shutdown command to the script engine child process. The script engine child process performs object deletion and memory cleanup operations, closes the communication channel, and stops the process. If it is in shared process mode, the host process calls the cleanup function of the script engine. The script engine performs object deletion and memory cleanup operations and returns to the host process main function.

[0008] Further, in step S2, in the separated process mode, after the host process starts, it creates and starts a child process with a script engine to build a cross-process communication channel, specifically including: The core of the separated process mode is that the host process and the script engine process run independently. After the host process starts, it will actively create and start a child process that integrates the script engine. To enable data interaction and instruction transmission between the host process and the script engine child process, a cross-process communication channel needs to be built. The cross-process communication mechanisms used include signals, message queues, and shared memory. Furthermore, in the separated process mode, even if there are problems with the script writing or the script engine itself crashes, it will only cause the script engine subprocess to stop and will not affect the normal operation of the host process. After the host process detects that the script engine subprocess has crashed, it can restart a new script engine subprocess.

[0009] Further, in step S3, in the separated process mode, for the host API that needs to be called, the API name and parameters are serialized and sent back to the host process. The host process deserializes the API, executes it, and serializes and sends back the result. The script engine child process deserializes the result, updates the execution context, and continues to execute the script. Specifically: When the script engine subprocess reads and parses the script, if it recognizes the user's call request to the host API, it first serializes the name of the API and the corresponding parameters, that is, converts them into a set of binary or text data streams. Then, the serialized data stream is transmitted to the host process through the cross-process communication channel constructed in step S2, and the host process is waited for execution feedback. After receiving the data stream, the host process will deserialize it into a series of objects and parameters that it can recognize, and then execute the corresponding API function. After the API function finishes execution, the host process will serialize the execution result again and send it back to the script engine child process through the inter-process communication channel. After receiving the result data stream, the script engine child process deserializes it, updates its own execution context, and then continues to read and execute the remaining commands in the script.

[0010] Further, in step S2, in the shared process mode, the host process calls the functions provided by the script engine to complete engine initialization and specify configuration options, specifically including: The core of the shared process mode is that the script engine runs directly inside the host process and exists as part of the host process. For the host process, the script engine is equivalent to a set of directly callable built-in functions, which can directly call any function of the host process and directly obtain any variable of the host process. The data interaction and instruction execution speed is extremely fast. The host process completes the initialization of the script engine by calling a set of dedicated functions provided by the script engine, and specifies various configuration options required for the script engine to run during the initialization process; After initialization, the host process will not wait for the script engine, but will immediately switch to executing other tasks, including receiving the user's keyboard and mouse operations and performing corresponding specified actions based on the user's operations.

[0011] Further, in step S3, in the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types within the script into a format recognizable by the host process to call the host API. After the host API is executed, the wrapper function converts the return value into a format recognizable by the script engine and updates the execution context, thereby continuing to execute the script. Specifically: When a user triggers the command to execute a script, the host process first determines whether the script supports direct file reading or whether preprocessing is required. If the script supports direct file reading, the script file path is directly passed to the script engine. If the script does not support direct file reading or requires preprocessing, the host process first reads the script file content into memory, performs preset preprocessing operations on the content, and then passes the memory address storing the script content to the script engine. After receiving the file path or memory address, the script engine reads and parses the script. If it recognizes a call to the host API, it will complete the format conversion through its own preset wrapper function. The wrapper function first translates the function call logic and data type in the script engine into function call logic and data type that the host process can recognize, and then directly calls the corresponding API function in the host process. After the host API function completes its execution, if there is a return value, the wrapper function will translate the return value into a data type that the script engine can recognize and store it in the script engine's execution context. After completing an API call, the script engine will continue to execute the remaining commands in the script.

[0012] Furthermore, the deployment of the script engine requires the simultaneous installation of supporting files onto the client machine. These supporting files and deployment requirements specifically include: The core execution component of the script engine is one or a group of dynamic link library files. Under the Windows operating system, the dynamic link library file has the extension .dll. Under the Linux operating system, its extension is generally .so or .so.1.2.3 with a version number, where 1.2.3 represents the version number of the dynamic link library. In addition to dynamic link library files, the script engine also needs to deploy its own configuration files and self-used function library files for operation; If the separate process mode is adopted, an additional executable file needs to be deployed. This executable file has the extension .exe under the Windows operating system. Its function is to complete the initialization operation during the script engine startup phase and enter an infinite loop state to continuously check whether the host process sends instructions. Once the instructions sent by the host process are received, the script parsing and execution process is started immediately. All of the above-mentioned supporting files must be deployed on the client machine along with the script engine. If any file is missing, the script engine may encounter errors and fail to function properly.

[0013] Furthermore, in the separated process mode, after the script engine subprocess in step S3 has executed all the scripts, it will enter an infinite loop state and continuously wait for the next instruction from the host process. Meanwhile, in step S4, when the host process triggers exit, if it is in detached process mode, the host process sends a shutdown command to the script engine subprocess. After the script engine subprocess performs object deletion and memory cleanup operations, it closes the communication channel and stops the process. Specifically, after receiving the shutdown command from the host process, in addition to performing object deletion and memory cleanup operations, the script engine subprocess also needs to close the cross-process communication channel built in step S2 first to ensure that the data interaction link is safely terminated before stopping its own process. In addition, if the host process detects that the script engine subprocess has crashed due to a fault during script execution, it can directly restart a new script engine subprocess without stopping its own operation, so as to ensure the continuous availability of the modeling software.

[0014] A system for embedding a script engine in a modeling domain, for performing the method described above, includes: The embedding mode selection module is used to select the embedding mode of the script engine based on the functional customization requirements and performance stability requirements of the modeling software. The embedding modes include separate process mode and shared process mode. The script engine initialization module is used to perform initialization operations on the script engine. In the case of the separate process mode, the host process creates and starts a child process with the script engine after starting, and establishes a cross-process communication channel. In the case of the shared process mode, the host process calls the functions provided by the script engine to complete the engine initialization and specify configuration options. The script execution and API interaction module is used to respond to user commands to execute scripts. In the separated process mode, the host process sends the command to the script engine subprocess through the inter-process communication channel. The script engine subprocess reads and parses the script. For the host API that needs to be called, it serializes the API name and parameters and sends them back to the host process. The host process deserializes the API, executes it, and serializes the result and sends it back. The script engine subprocess deserializes the result, updates the execution context, and continues to execute the script. In the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types in the script into a format that the host process can recognize in order to call the host API. After the host API is executed, the wrapper function converts the return value into a format that the script engine can recognize and updates the execution context, and then continues to execute the script. The script engine exit handling module is used when the host process triggers an exit. In detached process mode, the host process sends a shutdown command to the script engine child process, which then performs object deletion and memory cleanup operations, closes the communication channel, and stops the process. In shared process mode, the host process calls the script engine's cleanup function, which performs object deletion and memory cleanup operations and then returns to the host process's main function.

[0015] A computer device includes a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method described above.

[0016] A computer-readable storage medium storing computer code that, when executed, performs the method described above.

[0017] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) Significantly enhance customers' autonomy in customizing functions, reduce dependence on vendors, and accelerate the implementation of new functions. This invention embeds a script engine into modeling software and exposes the host script execution and API interaction module. It supports customers using various mainstream scripting languages ​​such as Python, Lua, and JavaScript to independently call existing software functions, freely combine functional modules, or add custom functions—eliminating the need for vendor-defined development for these modules. This design completely breaks away from the traditional "vendor-defined function" model of script execution and API interaction modules, allowing customers to quickly transform modeling ideas into actual software operations based on their own technical expertise and project needs. This significantly shortens the cycle from requirement to implementation, greatly improving the flexibility of modeling software usage and customer innovation efficiency.

[0018] (2) The dual embedding mode flexibly adapts to different scenario requirements, balancing stability and execution performance. This invention provides two script engine embedding modes: separate process and shared process, which can be flexibly selected according to the functional customization requirements of the modeling software, the scale of data processing, and stability requirements. The separate process mode ensures high stability of the host process: In this mode, the host and the script engine run independently. Even if the script is written incorrectly or the script engine crashes, it will only cause the script engine child process to stop and will not affect the normal operation of the host process. Moreover, the host can detect the child process crash and restart it to ensure that the modeling software is continuously available. It is especially suitable for modeling scenarios with high stability requirements and long-term operation.

[0019] The shared process mode enables efficient data interaction and instruction execution: In this mode, the script engine, as a built-in component of the host process, can directly call host functions and read host variables without cross-process communication delays; combined with wrapper functions, it enables rapid conversion between data types and calling logic, greatly improving the script execution speed and the efficiency of script execution and API interaction module calls, making it particularly suitable for modeling tasks that require a large amount of data reading and writing and have high performance requirements.

[0020] (3) Optimize the interaction logic between the script execution and API interaction modules to improve the smoothness and reliability of operation. This invention designs refined script execution and API interaction modules for two different embedding modes, and provides interaction flows for the API script execution and API interaction modules respectively: In the separate process mode, the standardized data interaction mechanism of the script execution and API interaction modules—"serialization of script execution and API interaction modules - transmission of script execution and API interaction modules - deserialization of script execution and API interaction modules"—ensures the accuracy of the script execution and API interaction module names, parameters, and execution results during cross-process transmission, avoiding data loss or format errors. Furthermore, after the script execution is completed, the engine subprocess enters an infinite loop to wait for the next instruction, reducing the overhead of repeated initialization.

[0021] In the shared process mode, the host can choose to pass the file path or the preprocessed memory address according to the script characteristics to adapt to the reading needs of different scripts; the wrapper function realizes the "two-way conversion" of the data format between the script and the host, the script execution and the API interaction module, ensuring that the script execution and the API interaction module call logic are accurately mapped, while avoiding execution interruption due to data format incompatibility, and improving the smoothness of operation.

[0022] (4) Define script engine deployment specifications to ensure cross-environment operational stability. This invention defines in detail the supporting deployment files and requirements for the script engine, including the dynamic link libraries (.dll / .so / .so.1.2.3) for the script execution and API interaction module under Windows / Linux systems, self-use configuration files and function libraries, and the .exe executable file for the script execution and API interaction module (responsible for engine initialization and instruction listening) specifically for the separate process mode. By forcibly requiring the synchronous deployment of all supporting files, engine runtime errors caused by missing files are avoided, ensuring that the script engine can work stably on different client machines and operating system environments, and reducing deployment and maintenance costs.

[0023] (5) Improve the process exit mechanism to ensure resource recovery and system security. This invention designs a standardized cleanup process during the host process exit phase: In separate process mode, after the host sends a shutdown command, the script engine child process first performs object deletion and memory cleanup, and then closes the cross-process communication channel to avoid resource leaks and communication link remnants; in shared process mode, after the cleanup function is called to complete the engine resource reclamation, it returns to the host main function to ensure the host process exits normally. This design not only protects system resources from waste but also avoids software crashes or data corruption caused by abnormal exits, thus improving system security. Attached Figure Description

[0024] Figure 1 This is an overall flowchart of the method for embedding a script engine in the modeling field according to the present invention; Figure 2 This is a flowchart of the process separation mode of the present invention; Figure 3 This is a flowchart of the shared process mode of the present invention; Figure 4 This is a diagram showing the overall structure of the system for embedding a script engine in the modeling field according to the present invention. Detailed Implementation

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

[0026] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0027] The software itself is referred to as the host. In this invention, there are two common ways to embed the script engine into the script execution and API interaction modules: one is a separate process, and the other is a shared process. Separate processes mean that the host process and the script engine run in their own independent processes. Generally, after the host starts, it will start a child process with the script engine. The host and the script engine communicate using cross-process communication mechanisms, including but not limited to signals, message queues, and shared memory. When a user attempts to execute a script file, the host passes the user's instructions to the script engine. Upon receiving the instructions, the script engine opens the specified file path, reads, and executes the script. For APIs that the user attempts to call, the script engine, after recognizing the API, will process the API name and parameters... Serialization involves converting the script execution and API interaction module into a binary or text data stream. This stream is then transmitted to the host via inter-process communication. The host awaits feedback from the host. Upon receiving the data stream, the host deserializes it into a series of objects and parameters recognizable by the host. The host then executes the corresponding function. After execution, the result is serialized and sent to the script engine. The script engine receives the serialized data, deserializes it, updates its execution context, and continues reading and executing script commands. After executing all scripts, the script engine enters an infinite loop, awaiting commands from the host. The advantage of this separate process model is that if the script is poorly written, or if the script execution and API interaction module or the script engine itself crashes, it will not affect the host process. The host process only needs to restart a script engine process after discovering the script engine crash. The disadvantage is that cross-process communication is slower, and users need to wait longer when the script execution and API interaction module executes instructions that require reading and writing large amounts of data.

[0028] Another approach is process sharing. This means the script engine runs within the host process, existing as part of it. To the host process, the script engine is essentially a set of functions. It can directly call any function within the host process and access any variable. The execution speed is extremely fast. When a user attempts to execute a script file, the host process can directly call the corresponding function in the script engine and pass the user's instructions. Upon receiving the instructions, the script engine will open the specified file path. The script execution and API interaction module reads and executes the script. For API calls attempted by the user, the script engine typically has a wrapper function. This wrapper function first translates the function calls and data types within the script engine into function calls and data types recognizable by the host process. Then, it directly calls the corresponding function within the host process. After the function returns from the host process, if a return value exists, the wrapper function translates the return value into a data type recognizable by the script engine and places it in the script engine's execution context. This completes one function call. However, using a shared process approach, if the script engine itself crashes, it will cause the entire host process to crash.

[0029] A script engine is typically one or more dynamic link libraries. On Windows, these libraries have the .dll extension, while on Linux, they are usually .so or .so.1.2.3 (where 1.2.3 is the version number). A script engine also typically includes many other configuration files and its own function library files. These files need to be deployed on the client machine along with the script engine; otherwise, the script engine may encounter runtime errors.

[0030] For a separate process-based script engine, the script execution and API interaction module also has a separate executable file. On Windows, the script execution and API interaction module has the .exe extension. This executable file is used to initialize the script engine and then enters an infinite loop. The script execution and API interaction module continuously checks whether the host process has sent any instructions. Once the script execution and API interaction module receives an instruction from the host process, it begins to parse and execute it.

[0031] For shared-process script engines, the script execution and API interaction module also needs to first initialize the script engine. This typically involves calling a set of functions provided by the script engine, specifying options for the engine, and then the host process performs other tasks, such as accepting user keyboard and mouse input and executing the specified actions. When the user sends a command to execute a script file, the host process calls the functions provided by the script engine, passing the file path. For scripts that don't support direct file reading, or scripts requiring preprocessing, the host process first reads the file content into memory, performs some preprocessing, and then passes the memory address storing the file content to the script engine. After the script engine finishes execution, the host process continues to execute other user-specified operations.

[0032] When a user closes the host process, for a separate process, the host process sends a shutdown command to the script engine process. Upon receiving this command, the script engine performs operations such as deleting objects and cleaning up memory before terminating its own process. For a shared process script engine, the host process calls the script engine's cleanup function. Within this function, the script engine performs similar operations, deleting objects and cleaning up memory before returning to the host process's main function.

[0033] First Embodiment like Figure 1As shown, this embodiment provides a method for embedding a script engine in the modeling field, including the following steps: S1: Based on the functional customization requirements and performance stability requirements of the modeling software, select the embedding mode of the script engine. The embedding mode includes the separate process mode. Figure 2 ) and shared process mode ( Figure 3 ).

[0034] S2: Perform initialization operations on the script engine. If it is the separate process mode, the host process creates and starts a child process with the script engine after starting, and builds a cross-process communication channel. If it is the shared process mode, the host process calls the functions provided by the script engine to complete the engine initialization and specify configuration options.

[0035] In step S2, under the separated process mode, after the host process starts, it creates and starts a child process with a script engine to build a cross-process communication channel, specifically including: The core of the separated process mode is that the host process and the script engine process run independently. After the host process starts, it will actively create and start a child process that integrates the script engine. To enable data interaction and instruction transmission between the host process and the script engine child process, a cross-process communication channel needs to be built. The cross-process communication mechanisms used include signals, message queues, and shared memory. Furthermore, in the separated process mode, even if there are problems with the script writing or the script engine itself crashes, it will only cause the script engine subprocess to stop and will not affect the normal operation of the host process. After the host process detects that the script engine subprocess has crashed, it can restart a new script engine subprocess.

[0036] In step S2, under the shared process mode, the host process calls functions provided by the script engine to complete engine initialization and specify configuration options, specifically including: The core of the shared process mode is that the script engine runs directly inside the host process and exists as part of the host process. For the host process, the script engine is equivalent to a set of directly callable built-in functions, which can directly call any function of the host process and directly obtain any variable of the host process. The data interaction and instruction execution speed is extremely fast. The host process completes the initialization of the script engine by calling a set of dedicated functions provided by the script engine, and specifies various configuration options required for the script engine to run during the initialization process; After initialization, the host process will not wait for the script engine, but will immediately switch to executing other tasks, including receiving the user's keyboard and mouse operations and performing corresponding specified actions based on the user's operations.

[0037] Step S2 is the core initialization step in the script engine embedding process of this invention. Its core objective is to build a basic operating environment for subsequent script execution and interaction with the host process. It also needs to perform adaptive initialization operations according to the previously selected separate process mode or shared process mode to ensure that the script engine can form a stable cooperative relationship with the host process in both modes.

[0038] In the separate process mode, the core logic of the initialization operation revolves around "process independence." Since this mode is designed to ensure the stability of the host process (i.e., the modeling software itself), the host process actively creates and starts a child process that integrates the script engine, making the script engine's operation completely independent of the host process. To achieve the necessary data interaction and instruction transmission between the two, a cross-process communication channel needs to be built synchronously. The communication mechanisms used cover mainstream methods such as signals, message queues, and shared memory, which can be flexibly selected according to the data transmission volume and real-time requirements of the modeling software. For example, signals can be used when the data volume is small, while shared memory is more suitable when the data volume is large, to balance transmission efficiency and reliability. Meanwhile, the initialization design of this mode also implicitly includes the "fault isolation" feature: even if there are syntax errors, logical loopholes, or the script engine itself crashes during subsequent script writing, it will only cause the independent script engine subprocess to stop, without affecting the normal operation of the host process; and the host process has the ability to detect the status of the subprocess. Once the script engine subprocess crashes, a new script engine subprocess can be restarted immediately to ensure that the core functions of the modeling software are not interrupted. This is especially suitable for scenarios such as circuit simulation model parameter extraction that require long-term operation and have extremely high stability requirements.

[0039] In the shared process mode, the initialization operation is guided by "efficient collaboration"—the core advantage of this mode is improved script execution and API call speed. Therefore, the script engine is designed to run directly within the host process, essentially a set of built-in functions of the host process. It can directly call any function of the host process and directly access any variable of the host process, fundamentally avoiding the latency caused by cross-process communication. During the initialization process, the host process starts the engine by calling a set of dedicated functions provided by the script engine. Simultaneously, during the initialization phase, it specifies the necessary configuration options for the script engine (such as script language parsing rules, execution context storage path, etc.) to ensure that the script engine's runtime parameters match the host process's runtime environment. Crucially, after the initialization operation is completed in this mode, the host process does not need to wait for the script engine and will immediately switch to executing other tasks, including receiving and responding to user keyboard and mouse inputs. This design fully considers the actual usage scenarios of modeling software. For example, after completing the script engine initialization, the user can continue to operate the modeling software interface to build models, set parameters, etc., without interrupting the core modeling process while waiting for the script engine initialization, greatly improving the smoothness of user operation and laying the foundation for rapid response to subsequent script execution commands.

[0040] S3: In response to the user's instruction to execute the script, if it is the separated process mode, the host process sends the instruction to the script engine subprocess through the inter-process communication channel. The script engine subprocess reads and parses the script. For the host API that needs to be called, it serializes the API name and parameters and sends them back to the host process. The host process deserializes the API, executes it, and serializes the result and sends it back. The script engine subprocess deserializes the result, updates the execution context, and continues to execute the script. If it is the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types in the script into a format that the host process can recognize in order to call the host API. After the host API is executed, the wrapper function converts the return value into a format that the script engine can recognize and updates the execution context, and then continues to execute the script.

[0041] In step S3, under the separated process mode, for the host API that needs to be called, the API name and parameters are serialized and sent back to the host process. The host process deserializes the API, executes it, and serializes and sends back the result. The script engine child process deserializes the result, updates the execution context, and continues to execute the script. Specifically: When the script engine subprocess reads and parses the script, if it recognizes the user's call request to the host API, it first serializes the name of the API and the corresponding parameters, that is, converts them into a set of binary or text data streams. Then, the serialized data stream is transmitted to the host process through the cross-process communication channel constructed in step S2, and the host process is waited for execution feedback. After receiving the data stream, the host process will deserialize it into a series of objects and parameters that it can recognize, and then execute the corresponding API function. After the API function finishes execution, the host process will serialize the execution result again and send it back to the script engine child process through the inter-process communication channel. After receiving the result data stream, the script engine child process deserializes it, updates its own execution context, and then continues to read and execute the remaining commands in the script.

[0042] In step S3, under the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types within the script into a format recognizable by the host process to call the host API. After the host API is executed, the wrapper function converts the return value into a format recognizable by the script engine and updates the execution context, thereby continuing to execute the script. Specifically: When a user triggers the command to execute a script, the host process first determines whether the script supports direct file reading or whether preprocessing is required. If the script supports direct file reading, the script file path is directly passed to the script engine. If the script does not support direct file reading or requires preprocessing, the host process first reads the script file content into memory, performs preset preprocessing operations on the content, and then passes the memory address storing the script content to the script engine. After receiving the file path or memory address, the script engine reads and parses the script. If it recognizes a call to the host API, it will complete the format conversion through its own preset wrapper function. The wrapper function first translates the function call logic and data type in the script engine into function call logic and data type that the host process can recognize, and then directly calls the corresponding API function in the host process. After the host API function completes its execution, if there is a return value, the wrapper function will translate the return value into a data type that the script engine can recognize and store it in the script engine's execution context. After completing an API call, the script engine will continue to execute the remaining commands in the script.

[0043] Step S3 is the core step in the present invention where the script engine responds to and executes user instructions. Its core objective is to transform the user-triggered script execution requirements into actual functional operations. At the same time, based on the architectural differences between the two modes of separate processes and shared processes, adaptive interaction logic is designed to ensure smooth connection between script parsing, API calls and result feedback, ultimately enabling users to independently call and extend the functions of the modeling software.

[0044] In the separate process mode, since the host process and the script engine child process are independent of each other, their data interaction relies on the cross-process communication channel. Therefore, the core design of step S3 revolves around "standardized data format"—serialization and deserialization become the key technical means to realize API call interaction. When the script engine child process reads and parses the user script, once it recognizes the call requirement to the host API, it will first serialize the API name and corresponding parameters, that is, convert the function identifier and parameter format that the script engine can recognize into a binary or text data stream. The purpose of this conversion is to eliminate the data format differences in cross-process communication and ensure that information is not lost or distorted during transmission. Subsequently, the serialized data stream will be transmitted to the host process through the cross-process communication channel built in step S2, and the script engine child process will enter a waiting state to ensure that it can receive the execution feedback from the host in a timely manner. After receiving the data stream, the host process needs to first deserialize it to restore it into objects and parameters that it can recognize—this step is a prerequisite for realizing API function calls. Only by restoring the standardized data transmitted across processes to a format familiar to the host can the corresponding API function be accurately matched and executed. After the API function finishes execution, the host process will serialize the execution result again and send it back to the script engine child process through the same communication channel. After receiving the result, the script engine child process will deserialize it and update the result in its own execution context. The update of the execution context is crucial. It can ensure that the execution of subsequent script commands can be based on the result of the previous API call, avoid the break in execution logic, and ultimately ensure that the entire script is executed completely as expected by the user.

[0045] In shared process mode, since the script engine runs directly within the host process, step S3 focuses on "efficient interaction" and "compatibility adaptation," eliminating the overhead of cross-process communication. When a user triggers the script execution command, the host process first determines the script's reading and parsing conditions: if the script supports direct file reading (as some scripting languages ​​have built-in file reading capabilities), the script file path is directly passed to the script engine, reducing redundant data copying operations; if the script does not support direct file reading, or has preprocessing requirements (such as syntax checking or variable substitution), the host process first reads the script file content into memory for preprocessing, and then passes the memory address storing the script content to the script engine—this dual adaptation design of "path passing + memory address passing" can cover the parsing needs of different types of scripts and improve the compatibility of script execution. After receiving a file path or memory address, the script engine quickly reads and parses the script content. When it detects a call to the host API, a pre-defined wrapper function within the script engine acts as a bridge: on one hand, it translates the function call logic (such as the function call syntax specific to the scripting language) and data types (such as script-specific variable types) within the script engine into a format recognizable by the host process, ensuring that the host can accurately understand and execute the API call; on the other hand, after the host API function completes execution, if there is a return value, the wrapper function performs a reverse conversion, translating the output format of the host process into a data type recognizable by the script engine and storing it in the execution context. This bidirectional conversion mechanism completely solves the differences in call logic and data format between the script engine and the host process, and significantly improves the speed of API calls and script execution because it eliminates the need for cross-process communication. After completing an API call, the script engine continues to read and execute the remaining commands in the script based on the updated execution context, ensuring the continuity and integrity of the entire script execution process.

[0046] S4: When the host process triggers exit, if it is in detached process mode, the host process sends a shutdown command to the script engine child process. The script engine child process performs object deletion and memory cleanup operations, closes the communication channel, and stops the process. If it is in shared process mode, the host process calls the cleanup function of the script engine. The script engine performs object deletion and memory cleanup operations and then returns to the host process main function.

[0047] Furthermore, the deployment of the script engine requires the simultaneous installation of supporting files on the client machine. These supporting files and deployment requirements specifically include: the core execution component of the script engine is one or a set of dynamic link library files. Under Windows, these dynamic link library files have the extension .dll; under Linux, they typically have the extension .so or .so.1.2.3 with a version number, where 1.2.3 represents the version number of the dynamic link library. In addition to the dynamic link library files, the script engine also needs to deploy its own configuration files and self-used function library files. If a separate process mode is used, an additional executable file needs to be deployed. This executable file has the extension .exe under Windows. Its function is to complete the initialization operation during the script engine startup phase and enter an infinite loop state, continuously checking whether the host process sends instructions. Once an instruction is received from the host process, the script parsing and execution process is immediately started. All of the above supporting files must be deployed on the client machine simultaneously with the script engine. The absence of any file may cause the script engine to malfunction and fail to operate normally.

[0048] Furthermore, in the separated process mode, after the script engine subprocess executes all scripts in step S3, it will enter an infinite loop state, continuously waiting for the next instruction from the host process. Simultaneously, in step S4, when the host process triggers exit, if it is in separated process mode, the host process sends a shutdown command to the script engine subprocess. The script engine subprocess performs object deletion and memory cleanup operations, then closes the communication channel and stops the process. Specifically, after receiving the shutdown command from the host process, in addition to performing object deletion and memory cleanup operations, the script engine subprocess must first close the cross-process communication channel built in step S2 to ensure the safe termination of the data interaction link before stopping its own process. Furthermore, if the host process detects that the script engine subprocess has crashed due to a fault during script execution, it can directly restart a new script engine subprocess without stopping its own operation, thus ensuring the continuous availability of the modeling software.

[0049] Second Embodiment like Figure 4 As shown, this embodiment provides a system for embedding a script engine in the modeling domain for executing the method of embedding a script engine in the modeling domain as in the first embodiment, comprising: The embedding mode selection module is used to select the embedding mode of the script engine based on the functional customization requirements and performance stability requirements of the modeling software. The embedding modes include separate process mode and shared process mode. The script engine initialization module is used to perform initialization operations on the script engine. In the case of the separate process mode, the host process creates and starts a child process with the script engine after starting, and establishes a cross-process communication channel. In the case of the shared process mode, the host process calls the functions provided by the script engine to complete the engine initialization and specify configuration options. The script execution and API interaction module is used to respond to user commands to execute scripts. In the separated process mode, the host process sends the command to the script engine subprocess through the inter-process communication channel. The script engine subprocess reads and parses the script. For the host API that needs to be called, it serializes the API name and parameters and sends them back to the host process. The host process deserializes the API, executes it, and serializes the result and sends it back. The script engine subprocess deserializes the result, updates the execution context, and continues to execute the script. In the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types in the script into a format that the host process can recognize in order to call the host API. After the host API is executed, the wrapper function converts the return value into a format that the script engine can recognize and updates the execution context, and then continues to execute the script. The script engine exit handling module is used when the host process triggers an exit. In detached process mode, the host process sends a shutdown command to the script engine child process, which then performs object deletion and memory cleanup operations, closes the communication channel, and stops the process. In shared process mode, the host process calls the script engine's cleanup function, which performs object deletion and memory cleanup operations and then returns to the host process's main function.

[0050] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0051] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0052] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0053] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for embedding a script engine in the field of modeling, characterized in that, Includes the following steps: S1: Based on the functional customization requirements and performance stability requirements of the modeling software, select the embedding mode of the script engine. The embedding mode includes separate process mode and shared process mode. S2: Perform initialization operations on the script engine. If it is the separate process mode, the host process creates and starts a child process with the script engine after starting, and builds a cross-process communication channel. If it is the shared process mode, the host process calls the functions provided by the script engine to complete the engine initialization and specify configuration options. S3: In response to the user's instruction to execute the script, if it is the separated process mode, the host process sends the instruction to the script engine subprocess through the inter-process communication channel. The script engine subprocess reads and parses the script. For the host API that needs to be called, the API name and parameters are serialized and sent back to the host process. The host process deserializes the API, executes the API, and serializes and sends back the result. The script engine subprocess deserializes the result, updates the execution context, and continues to execute the script. In the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types in the script into a format that the host process can recognize in order to call the host API. After the host API is executed, the wrapper function converts the return value into a format that the script engine can recognize and updates the execution context, and then continues to execute the script. S4: When the host process triggers an exit, if it is in detached process mode, the host process sends a shutdown command to the script engine child process. The script engine child process performs object deletion and memory cleanup operations, closes the communication channel, and stops the process. In shared process mode, the host process calls the cleanup function of the script engine. After the script engine performs object deletion and memory cleanup operations, it returns to the host process's main function.

2. The method for embedding a script engine in the modeling field according to claim 1, characterized in that, In step S2, under the separated process mode, after the host process starts, it creates and starts a child process with a script engine to build a cross-process communication channel, specifically including: The core of the separated process mode is that the host process and the script engine process run independently. After the host process starts, it will actively create and start a child process that integrates the script engine. To enable data interaction and instruction transmission between the host process and the script engine child process, a cross-process communication channel needs to be built. The cross-process communication mechanisms used include signals, message queues, and shared memory. Furthermore, in the separated process mode, even if there are problems with the script writing or the script engine itself crashes, it will only cause the script engine subprocess to stop and will not affect the normal operation of the host process. After the host process detects that the script engine subprocess has crashed, it can restart a new script engine subprocess.

3. The method for embedding a script engine in the modeling field according to claim 1, characterized in that, In step S3, under the separated process mode, for the host API that needs to be called, the API name and parameters are serialized and sent back to the host process. The host process deserializes the API, executes it, and serializes and sends back the result. The script engine child process deserializes the result, updates the execution context, and continues to execute the script. Specifically: When the script engine subprocess reads and parses the script, if it recognizes the user's call request to the host API, it first serializes the name of the API and the corresponding parameters, that is, converts them into a set of binary or text data streams. Then, the serialized data stream is transmitted to the host process through the cross-process communication channel constructed in step S2, and the host process is waited for execution feedback. After receiving the data stream, the host process will deserialize it into a series of objects and parameters that it can recognize, and then execute the corresponding API function. After the API function finishes execution, the host process will serialize the execution result again and send it back to the script engine child process through the inter-process communication channel. After receiving the result data stream, the script engine child process deserializes it, updates its own execution context, and then continues to read and execute the remaining commands in the script.

4. The method for embedding a script engine in the modeling field according to claim 1, characterized in that, In step S2, under the shared process mode, the host process calls functions provided by the script engine to complete engine initialization and specify configuration options, specifically including: The core of the shared process mode is that the script engine runs directly inside the host process and exists as part of the host process. For the host process, the script engine is equivalent to a set of directly callable built-in functions, which can directly call any function of the host process and directly obtain any variable of the host process. The data interaction and instruction execution speed is extremely fast. The host process completes the initialization of the script engine by calling a set of dedicated functions provided by the script engine, and specifies various configuration options required for the script engine to run during the initialization process; After initialization, the host process will not wait for the script engine, but will immediately switch to executing other tasks, including receiving the user's keyboard and mouse operations and performing corresponding specified actions based on the user's operations.

5. The method for embedding a script engine in the modeling field according to claim 1, characterized in that, In step S3, under the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types within the script into a format recognizable by the host process to call the host API. After the host API is executed, the wrapper function converts the return value into a format recognizable by the script engine and updates the execution context, thereby continuing to execute the script. Specifically: When a user triggers the command to execute a script, the host process first determines whether the script supports direct file reading or whether preprocessing is required: if the script supports direct file reading, the script file path is directly passed to the script engine. If the script does not support direct file reading or has preprocessing requirements, the host process first reads the script file content into memory, performs preset preprocessing operations on the content, and then passes the memory address storing the script content to the script engine. After receiving the file path or memory address, the script engine reads and parses the script. If it recognizes a call to the host API, it will complete the format conversion through its own preset wrapper function. The wrapper function first translates the function call logic and data type in the script engine into function call logic and data type that the host process can recognize, and then directly calls the corresponding API function in the host process. After the host API function completes its execution, if there is a return value, the wrapper function will translate the return value into a data type that the script engine can recognize and store it in the script engine's execution context. After completing an API call, the script engine will continue to execute the remaining commands in the script.

6. The method for embedding a script engine in the modeling field according to claim 1, characterized in that, The deployment of the script engine requires the simultaneous installation of supporting files to the client machine. These supporting files and deployment requirements specifically include: The core execution component of the script engine is one or a group of dynamic link library files. Under the Windows operating system, the dynamic link library file has the extension .dll. Under the Linux operating system, its extension is generally .so or .so.1.2.3 with a version number, where 1.2.3 represents the version number of the dynamic link library. In addition to dynamic link library files, the script engine also needs to deploy its own configuration files and self-used function library files for operation; If the separate process mode is adopted, an additional executable file needs to be deployed. This executable file has the extension .exe under the Windows operating system. Its function is to complete the initialization operation during the script engine startup phase and enter an infinite loop state to continuously check whether the host process sends instructions. Once the instructions sent by the host process are received, the script parsing and execution process is started immediately. All of the above-mentioned supporting files must be deployed on the client machine along with the script engine. If any file is missing, the script engine may encounter errors and fail to function properly.

7. The method for embedding a script engine in the modeling field according to claim 1, characterized in that, In the separated process mode, after the script engine subprocess in step S3 has executed all the scripts, it will enter an infinite loop state and continuously wait for the next instruction from the host process. Meanwhile, in step S4, when the host process triggers exit, if it is in detached process mode, the host process sends a shutdown command to the script engine subprocess. After the script engine subprocess performs object deletion and memory cleanup operations, it closes the communication channel and stops the process. Specifically, after receiving the shutdown command from the host process, in addition to performing object deletion and memory cleanup operations, the script engine subprocess also needs to close the cross-process communication channel built in step S2 first to ensure that the data interaction link is safely terminated before stopping its own process. In addition, if the host process detects that the script engine subprocess has crashed due to a fault during script execution, it can directly restart a new script engine subprocess without stopping its own operation, so as to ensure the continuous availability of the modeling software.

8. A system for embedding a script engine in a modeling domain for performing the method of embedding a script engine in a modeling domain as described in any one of claims 1-7, characterized in that, include: The embedding mode selection module is used to select the embedding mode of the script engine based on the functional customization requirements and performance stability requirements of the modeling software. The embedding modes include separate process mode and shared process mode. The script engine initialization module is used to perform initialization operations on the script engine. If it is the separated process mode, after the host process starts, it creates and starts a child process with the script engine to build a cross-process communication channel. If it is the shared process mode, the host process calls the function provided by the script engine to complete the engine initialization and specify the configuration options; The script execution and API interaction module is used to respond to user instructions to execute scripts. If it is the separated process mode, the host process sends the instructions to the script engine subprocess through the cross-process communication channel. The script engine subprocess reads and parses the script. For the host API that needs to be called, the API name and parameters are serialized and sent back to the host process. The host process deserializes the API, executes it, and serializes and sends back the result. The script engine subprocess deserializes the result, updates the execution context, and continues to execute the script. In the shared process mode, the host process directly passes the script file path or the memory address of the preprocessed script content to the script engine. The script engine reads and parses the script, and uses a wrapper function to convert the function calls and data types in the script into a format that the host process can recognize in order to call the host API. After the host API is executed, the wrapper function converts the return value into a format that the script engine can recognize and updates the execution context, and then continues to execute the script. The script engine exit handling module is used to send a shutdown command to the script engine child process when the host process triggers an exit. If it is in detached process mode, the host process sends the shutdown command to the script engine child process. The script engine child process performs object deletion and memory cleanup operations, closes the communication channel, and stops the process. In shared process mode, the host process calls the cleanup function of the script engine. After the script engine performs object deletion and memory cleanup operations, it returns to the host process's main function.

9. A computer device comprising a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer code, wherein when the computer code is executed, the method of any one of claims 1 to 7 is performed.

Images