System personalization customization method and system based on virtual system isolation, electronic device and computer readable storage medium

Abstract

Embodiments of the present application disclose a system personalization customization method and system based on virtual system isolation, an electronic device, and a computer readable storage medium. The present application provides an independent business logic definition environment by creating a corresponding virtual system instance for a user; receives target business logic submitted by the user in the virtual system instance, identifies a target syntax type to which the target business logic belongs; parses the target business logic into structured operation instructions through a syntax adapter corresponding to the target syntax type, and converts the structured operation instructions into a standardized operation instruction sequence; maps the operation instructions in the standardized operation instruction sequence to standardized interface calls of underlying system function modules, and distributes them to corresponding function modules for execution, thereby achieving the simultaneous guarantee of multi-user logic isolation and underlying resource sharing, and enabling the system to be free from changes to the underlying system with the addition of new industries or syntax types, thereby significantly improving the scalability and resource utilization of the system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, electronic device, and computer-readable storage medium for system personalization based on virtual system isolation. Background Technology

[0002] In the field of low-altitude unmanned aerial vehicle (UAV) operations, different industry clients have fundamentally different business needs for operational systems. Taking low-altitude inspection, low-altitude logistics, low-altitude emergency search and rescue, and low-altitude surveying and mapping as examples: inspection focuses on periodic data collection and defect identification; logistics focuses on multi-waypoint route optimization and timeliness management; emergency search and rescue focuses on area coverage search and multi-UAV collaborative command; and surveying and mapping focuses on precise route design and data accuracy control. These industries are not different configuration variations of the same business process, but rather independent business processes that differ greatly from each other.

[0003] In related technologies, low-altitude unmanned aerial vehicle (UAV) operation systems typically employ a SaaS (Software as a Service) multi-tenant architecture to provide unified services to customers across multiple industries. Business differences between these industries are adapted through tenant-level configuration parameters. However, for various industry scenarios with fundamentally different business models, a single set of core business logic code cannot simultaneously express multiple vastly different business processes. To meet the customized needs of different industries, existing technologies often deploy service instances independently for each industry. This results in the inability to share common module capabilities, maintenance costs increasing linearly with the number of industries, the need to repeatedly deploy complete services for new industries, low resource utilization, and poor scalability. Summary of the Invention

[0004] This application proposes a business logic customization method based on virtual system isolation, which aims to solve the problem that existing low-altitude UAV operation systems cannot adapt to the vastly different business needs of multiple industries due to shared business logic code, resulting in low system resource utilization and poor scalability.

[0005] This application provides a method for system personalization based on virtual system isolation, the method including: In response to a user's registration request for a business system, a corresponding virtual system instance is created for the user. The virtual system instance provides the user with an independent business logic definition environment. Receive the target business logic submitted by the user in the virtual system instance, and identify the target syntax type to which the target business logic belongs; The target business logic is parsed into structured operation instructions by using the syntax adapter corresponding to the target syntax type, and then the structured operation instructions are converted into a standardized sequence of operation instructions. The operation instructions in the standardized operation instruction sequence are mapped to the standardized interface calls of the underlying system functional modules and distributed to the corresponding functional modules for execution. The functional modules respond to the standardized interface calls to perform operations without recognizing virtual system instances or target syntax types.

[0006] Accordingly, this application also provides a system personalization customization system based on virtual system isolation, the system comprising: The virtual system instance management layer is used to create isolated virtual system instances for each user. The virtual system instance provides users with an independent business definition environment, runtime environment, and syntax version environment. The mapping engine layer communicates with the virtual system instance management layer. It is used to receive the target business logic submitted by the user in the virtual system instance, identify the target syntax type to which the target business logic belongs, parse the target business logic into structured operation instructions through the syntax adapter corresponding to the target syntax type, convert the structured operation instructions into a standardized operation instruction sequence, and map the operation instructions in the standardized operation instruction sequence into standardized interface calls and distribute them. The underlying system functional module layer contains multiple functional modules. Each functional module receives and executes interface calls distributed by the mapping engine layer through a standardized interface. The functional modules respond to the standardized interface calls to perform operations, without recognizing virtual system instances or target syntax types.

[0007] Accordingly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program to implement the above-described system personalization method based on virtual system isolation.

[0008] Accordingly, this application also provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the above-described system personalization method based on virtual system isolation.

[0009] This application addresses user registration requests for business systems by creating corresponding virtual system instances for users, providing them with an independent business logic definition environment. It receives target business logic submitted by users within the virtual system instance, identifies the target syntax type to which the target business logic belongs, parses the target business logic into structured operation instructions using a syntax adapter corresponding to the target syntax type, and converts these structured operation instructions into a standardized operation instruction sequence. The operation instructions in the standardized operation instruction sequence are mapped to standardized interface calls of the underlying system functional modules and distributed to the corresponding functional modules for execution. The functional modules respond to the standardized interface calls and execute operations without recognizing the virtual system instance or the target syntax type. This approach ensures multi-user logic isolation and underlying resource sharing while eliminating the need to modify the underlying system with the addition of new industries or syntax types, significantly improving system scalability and resource utilization. Attached Figure Description

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

[0011] in: Figure 1 This is a schematic diagram of a system personalization system based on virtual system isolation, provided as an embodiment of this application.

[0012] Figure 2 This is a flowchart illustrating a system personalization method based on virtual system isolation, provided as an embodiment of this application.

[0013] Figure 3 This is a flowchart illustrating another system personalization method based on virtual system isolation provided in an embodiment of this application.

[0014] Figure 4 This is a structural block diagram of a system personalization device based on virtual system isolation, provided as an embodiment of this application.

[0015] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0017] This application provides a system personalization method, apparatus, computer-readable storage medium, and electronic device based on virtual system isolation. Specifically, the system personalization method based on virtual system isolation in this application can be executed by an electronic device, which can be a terminal or a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0018] To address the aforementioned issues, embodiments of this application provide a system, electronic device, and computer-readable storage medium based on virtual system isolation. This method ensures multi-user logical isolation and underlying resource sharing while eliminating the need to modify the underlying system with the addition of new industry or syntax types, significantly improving system scalability and resource utilization.

[0019] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0020] This application provides a business logic customization system based on virtual system isolation, including: The virtual system instance management layer is used to create isolated virtual system instances for each user. The virtual system instance provides users with an independent business definition environment, runtime environment, and syntax version environment. The mapping engine layer communicates with the virtual system instance management layer. It is used to receive the target business logic submitted by the user in the virtual system instance, identify the target syntax type to which the target business logic belongs, parse the target business logic into structured operation instructions through the syntax adapter corresponding to the target syntax type, convert the structured operation instructions into a standardized operation instruction sequence, and map the operation instructions in the standardized operation instruction sequence into standardized interface calls and distribute them. The underlying system functional module layer contains multiple functional modules. Each functional module receives and executes interface calls distributed by the mapping engine layer through a standardized interface. The functional modules respond to the standardized interface calls to perform operations, without recognizing virtual system instances or target syntax types.

[0021] For example, please see Figure 1 , Figure 1 This is a schematic diagram of a system customization system based on virtual system isolation, provided as an embodiment of this application. The system includes a virtual system instance management layer, a mapping engine layer, and a lower-level system functional module layer.

[0022] The virtual system instance management layer is used to create isolated virtual system instances for each user. For example... Figure 1 As shown, inspection users, logistics users, and search and rescue users each have their own independent virtual systems, which are isolated from each other. Each virtual system instance provides users with an independent business definition environment, runtime environment, and syntax version environment, and is bound to the user's tenant identifier. Users enter their own virtual system through identity authentication without being aware of the existence of other virtual systems.

[0023] The mapping engine layer communicates and connects with both the virtual system instance management layer and the underlying system functional module layer, such as... Figure 1 As shown, the mapping engine layer includes various syntax adapters (script adapter, orchestration graph compiler, natural language parser), a unified internal representation module, and a standardized operation instruction sequence generation module. The mapping engine layer receives the target business logic submitted by the user in the virtual system instance, identifies its syntax type, parses it into structured operation instructions through the corresponding adapter, converts it into a standardized operation instruction sequence in a unified format, and finally maps it into standardized interface calls for the underlying system functional modules and distributes them. The processing flow of the mapping engine layer is independent of which adapter the operation instructions originate from.

[0024] The underlying system functional module layer contains multiple functional modules, such as Figure 1 As shown, it includes modules such as equipment management, task scheduling, route planning, GIS (Geographic Information System) / map, alarm notification, and data query. Each functional module receives and executes interface calls distributed by the mapping engine layer through standardized interfaces.

[0025] This embodiment achieves complete decoupling between business logic definition and underlying execution through a three-tier architecture: different users can define business logic using different syntaxes in their respective isolated virtual system instances, which are then uniformly converted into standardized instructions by the mapping engine and executed by the underlying functional modules. The underlying modules are completely unaware of the source from the upper layer. Adding new industry clients or syntax types does not affect the underlying system functional modules, and the system possesses excellent multi-industry service capabilities and scalability.

[0026] For further details, please refer to Figure 2 , Figure 2This is a flowchart illustrating a system personalization method based on virtual system isolation, provided as an embodiment of this application. The specific process can be as follows: 101. In response to a user's registration request for a business system, create a corresponding virtual system instance for the user.

[0027] The business system refers to a comprehensive management platform that provides users with services such as device access, task scheduling, and operation management. For example, this business system could be a low-altitude unmanned aerial vehicle (UAV) operation service platform, serving multiple user groups in industries such as low-altitude inspection, low-altitude logistics, low-altitude emergency search and rescue, and low-altitude surveying and mapping. A registration request is an identity registration instruction sent by the client to the business system backend when a user uses the system for the first time. It includes at least the user's identity information, used to create a unique tenant identifier and establish the association between the user and the system.

[0028] In some embodiments, the step "create a corresponding virtual system instance for the user" may include the following operations: Based on the user's business type, determine the corresponding configuration template, and create a corresponding virtual system instance for the user according to the configuration template. The virtual system instance contains an independent business logic definition environment, runtime environment, and syntax version environment.

[0029] Specifically, after a user completes registration, the virtual system instance management layer loads the corresponding default configuration template from multiple preset configuration templates based on the user's business type, and creates a corresponding virtual system instance for the user accordingly. This instance contains three independent environments: a business definition environment, used to host user-defined scripts, orchestration diagrams, or natural language rules and other business logic; a runtime state environment, used to store runtime data such as variable context, execution history, and exception records, allowing users to view the execution status and results of business logic, forming a closed loop of "definition → execution → feedback"; and a syntax version environment, used to manage the syntax adapter version used by the user, ensuring that different users' syntax versions do not affect each other.

[0030] Once an instance is created, it is bound to the user's tenant identifier. Users can access their own virtual system through authentication without being aware of the existence of other virtual systems. Each virtual system instance is logically isolated; modifications to the business logic of any user do not affect other instances. Simultaneously, all instances share the underlying system's physical resources, which are uniformly allocated by the resource scheduling module according to priority and quotas, eliminating the need to deploy complete system services independently for each user.

[0031] In some embodiments, the method may further include the following steps: In response to user modifications to the target business logic within a virtual system instance, a timestamped state snapshot is automatically generated and saved. The state snapshot contains the complete modified business logic content. In response to a user's version rollback operation, the current business logic is rolled back to the version corresponding to the specified historical snapshot; In response to a user's branch creation operation, a new branch is created based on a specified historical snapshot. The branch is independent of the original business logic mainline. In response to a user's branch merge operation, the business logic on the branch is merged into the current business logic of the virtual system instance, and the merged business logic is submitted for processing as the target business logic.

[0032] In this embodiment, each virtual system instance maintains a customized operation session manager to provide users with traceable and branchable state management capabilities for their business definition process. This session manager is completely transparent to the mapping engine; that is, the mapping engine only receives and processes the business logic corresponding to the currently active version and is unaware of the version management process.

[0033] When a user modifies business logic in a virtual system instance, the session manager automatically generates and saves a timestamped state snapshot. The snapshot contains the complete business logic content at that moment, recording the complete evolution history of the business logic.

[0034] When a user rolls back a version, the session manager switches the current business logic to the version corresponding to the specified historical snapshot. This rollback operation only changes the active version pointer inside the virtual system instance and does not involve any operation of the mapping engine and the underlying system. The mapping engine and the underlying system are unaware of the version rollback.

[0035] When users need to verify multiple different business orchestration schemes in parallel, the session manager creates a new branch based on a specified historical snapshot. Users can independently modify the business logic on the branch without affecting the main branch.

[0036] Once the business logic on a branch is ready, the session manager merges the business logic on the branch into the current business logic of the virtual system instance, and submits the merged business logic as the target business logic for processing.

[0037] All state snapshots and branch data are stored in the independent state space of the virtual system instance, and the snapshots and branch data between different virtual system instances are isolated from each other.

[0038] Since session management is completely transparent to the mapping engine, the mapping engine does not need to be aware of the version management mechanism inside the virtual system instance. It only parses and distributes according to the business logic corresponding to the current active version, thus decoupling the flexible version management inside the virtual system instance from the stable execution of the underlying system.

[0039] 102. Receive the target business logic submitted by the user in the virtual system instance and identify the target syntax type to which the target business logic belongs.

[0040] The target business logic refers to the specific business rules and operational procedures defined by the user within the virtual system instance, which are to be executed by the system. The target business logic is a programmatic expression of the user's business requirements, and its content varies depending on the user's industry type and specific operational scenario.

[0041] Syntax type refers to the different categories of expressions or descriptive languages ​​used by users when defining business logic. Syntax type determines how users transform business requirements into business logic definitions that the system can recognize and process.

[0042] The mapping engine layer receives the target business logic submitted by the user in the virtual system instance, and identifies the target syntax type to which the target business logic belongs based on at least one of the following: data format, file extension, or content characteristics. The syntax type includes at least one of scripting language, visual orchestration diagram, and natural language description.

[0043] Specifically, users can define and submit business logic within the virtual system instance by choosing from methods such as script writing, node drag-and-drop arrangement, or natural language input, based on their skill level and usage habits. After receiving the target business logic, the mapping engine layer automatically identifies the corresponding syntax type based on its data format or content characteristics. For example, script files correspond to scripting languages, node connection data corresponds to visual arrangement diagrams, and natural language text corresponds to natural language descriptions. Alternatively, it can directly determine the syntax type based on the user's active selection during submission. After identifying the target syntax type, the mapping engine layer selects the corresponding syntax adapter for subsequent parsing.

[0044] The syntax version environment of the virtual system instance records the syntax adapter version information used by each user. Different users can use different versions of the syntax adapter, and each version runs independently in its own virtual system instance without interfering with each other.

[0045] 103. Parse the target business logic into structured operation instructions using the syntax adapter corresponding to the target syntax type, and convert the structured operation instructions into a standardized operation instruction sequence.

[0046] In some embodiments, the syntax type includes at least: scripting language, visual orchestration diagram, and natural language; the step "parses the target business logic into structured operation instructions using the syntax adapter corresponding to the target syntax type, and converts the structured operation instructions into a standardized sequence of operation instructions" may include the following operations: If the target syntax type is a scripting language, the target business logic is parsed through the script adapter to generate structured operation instructions; If the target syntax type is a visual orchestration diagram, the orchestration diagram compiler performs topology parsing on the nodes and connections in the target business logic to generate structured operation instructions; If the target syntax type is natural language, the target business logic is semantically parsed using a natural language parser to generate structured operation instructions; Structured operation instructions are converted into a unified format of operation instruction sequence to obtain a standardized operation instruction sequence. The operation instructions in the standardized operation instruction sequence include at least one of the following: functional module, operation action, parameter list, preconditions, and post-verification information.

[0047] For example, please refer to Table 1 below: Table 1 The mapping engine layer contains a variety of syntax adapters.

[0048] When the target syntax type is a scripting language, the script adapter performs lexical analysis and syntax verification on the script code, constructs an abstract syntax tree (AST), identifies the interface call sequence and its call order and parameters, and generates structured operation instructions; the script adapter supports multiple programming languages ​​such as Python, JavaScript, and C.

[0049] When the target syntax type is a visual orchestration diagram, the orchestration diagram compiler performs topological sorting and traversal of nodes and connections, extracts the configuration information of each node, and compiles the conditional branch logic to generate structured operation instructions.

[0050] When the target syntax type is natural language, the natural language parser calls the Large Language Model (LLM) for semantic understanding, identifies the device control intent, extracts state judgment conditions and action parameters, maps them to the corresponding system module interface, and generates structured operation instructions.

[0051] All three adapters output structured operation instructions using a unified internal representation format (such as a JSON-formatted sequence of operation instructions). Each operation instruction includes a functional module (the target module called by the instruction), an operation action (the specific operation to be performed), a parameter list (the parameters required to perform the operation), preconditions (conditions that must be met before execution), and post-verification information (the result that needs to be verified after execution).

[0052] Through a unified internal representation format, the processing flow of the mapping engine is independent of which adapter the operation instructions come from; all subsequent standardized conversions and distribution execution follow the same process.

[0053] The mapping engine layer converts structured operation instructions into a unified sequence of operation instructions, resulting in a standardized sequence. This standardized sequence can be directly mapped to standardized interface calls of the underlying system functional modules and distributed for execution. When a new syntax type needs to be added, only the corresponding syntax adapter needs to be added to the mapping engine layer; the underlying system functional modules do not require any modification.

[0054] In some embodiments, the target business logic can be low-altitude business logic, and low-altitude business includes at least one of low-altitude inspection, low-altitude logistics, low-altitude emergency search and rescue, and low-altitude surveying and mapping.

[0055] In some embodiments, the step "parse the target business logic using a script adapter to generate structured operation instructions" may include the following operations: The script adapter performs syntax parsing on the script code corresponding to the target business logic, and extracts the device status acquisition operation, status threshold judgment condition and device action control operation from the script code. The extracted operations are mapped to corresponding interface calls and instruction parameters, and a structured sequence of operation instructions is generated according to the execution order in the script code. Specifically, the script adapter is used to process target business logic written in scripting languages ​​(such as Python, JavaScript, C, etc.). Taking the "low battery alarm and forced return" business logic in a low-altitude inspection scenario as an example, the user-written script code is as follows: def check_and_alert(): drones = device.list_active() For drones in drones: status = device.get_status(drone.id) if status.battery<30: distance = gis.distance_to_home(status.position) if distance>5000: alert.send("WARNING", f"Device {drone.id} low battery forced return") mission.force_return(drone.id) The script adapter performs syntax parsing on the above script code and extracts three types of operation information from the script code: device status acquisition operations (device.list_active() to get the list of active devices, device.get_status(drone.id) to get the status of a single device), status threshold judgment conditions (status.battery<30, battery level below 30%, distance>5000, distance from base station greater than 5 kilometers), and device action control operations (alert.send() to send alarms, mission.force_return() to force return to home).

[0056] The script adapter maps the extracted operations to corresponding interface calls and instruction parameters (e.g., mapping device.list_active() to a query interface call to the device management module, and mapping alert.send() to a send interface call to the alarm notification module, passing in the alarm level and content as parameters). Following the execution order in the script code, it first traverses all active devices and obtains their status one by one, then uses nested conditions to precisely express the dual judgment of "battery threshold + distance threshold", and finally executes alarms and return-to-home in sequence, generating a structured operation instruction sequence.

[0057] In some embodiments, the step "performing topology analysis of nodes and connections in the target business logic using an orchestration graph compiler to generate structured operation instructions" may include the following operations: The orchestration diagram compiler traverses the nodes and connections in the target business logic to identify timed trigger nodes, device operation nodes, status judgment nodes and device control nodes. The execution order and conditional branching relationships between nodes are determined based on the connections, and corresponding structured operation instructions are generated according to the execution order and conditional branching relationships.

[0058] Specifically, the visual orchestration diagram consists of graphical nodes and directed connections between them. Taking the "low battery alarm and forced return" business logic in a low-altitude inspection scenario as an example, the user drags and connects the following nodes on the virtual system's orchestration canvas: [Timed trigger: Daily at 08:00] ↓ [Get list of active devices] → [Loop through devices] ↓↓ [Get Device Status] → [Condition Check: Battery Level < 30%] → [Condition Check: Distance > 5km] ↓ [Send Alarm] → [Force Return] The orchestration diagram compiler traverses the above nodes and connections, identifying timed trigger nodes ("Timed trigger: 08:00 every day", used to express execution at a fixed time every day), device operation nodes ("Get active device list", "Loop through devices", "Get device status", used to express processing each device in the set), status judgment nodes ("Condition judgment: Battery < 30%", "Condition judgment: Distance > 5km", used to express double condition filtering), and device control nodes ("Send alarm", "Force return", used to express the order of actions).

[0059] The arrangement diagram compiler determines the execution order and conditional branching relationship between nodes based on the connection direction (two conditional nodes are connected in sequence, and the process branch is entered only after both are passed; alarms and return are connected in sequence), and generates corresponding structured operation instructions according to the execution order and conditional branching relationship.

[0060] In some embodiments, the step "semantically parsing the target business logic using a natural language parser to generate structured operation instructions" may include the following operations: The natural language parser identifies time-triggered conditions, device control intentions, and device status determination conditions in the target business logic. Based on the device control intent, determine the device actions to be executed, and map the time trigger conditions, device status judgment conditions, and device actions into corresponding structured operation instructions.

[0061] Specifically, the natural language parser is used to process target business logic defined in the form of natural language text. It can call a large language model to perform semantic parsing on the natural language text input by the user. Taking the "low battery alarm and forced return" business logic in a low-altitude inspection scenario as an example, the user enters the following in the natural language input box of the virtual system: “Every morning at 8 o’clock, check all drones with a battery level below 30% and a distance of more than 5 kilometers from the base station, force them to return to base and send an alarm.” The natural language parser calls a large language model for semantic parsing: First, it performs intent recognition, identifying the user's device control intent as "force return to home" and "send alarm"; second, it extracts condition and time elements, extracting device status judgment conditions from "battery level below 30% and distance from base station exceeding 5 kilometers", and extracting time trigger conditions from "8 AM every day" (converted to cron expression 08***); then, it maps "send alarm" to an interface call to the alarm notification module, and "force return to home" to an interface call to the task scheduling module; finally, it maps the time trigger conditions, device status judgment conditions, and device actions to corresponding structured operation instruction sequences.

[0062] The structured operation instruction sequence is identical in format to the structured operation instructions generated by the script adapter and the orchestration diagram compiler. The same business problem defined by the three custom syntaxes is ultimately translated by the mapping engine into the exact same underlying system operation instruction sequence for execution. The underlying system is unaware of which syntax type the instructions originate from.

[0063] In some embodiments, the standardized operation instruction sequence is defined in the form of a low-altitude operational primitive system. Each primitive corresponds to a low-altitude operational action (such as inspection scanning, grid search, multi-waypoint delivery, surveying and mapping, etc.), encapsulating the collaborative logic of multiple underlying functional modules. Primitives are decoupled from the calling carrier and can be invoked in various ways, such as scripting languages, REST APIs, and visual orchestration nodes. The instruction sequence output by the script adapter, orchestration diagram compiler, and natural language parser is the operational primitive invocation sequence. Each adapter shares the same primitive list verification and security sandbox verification to ensure that all issued operation instructions conform to the system capability boundaries.

[0064] In some embodiments, the natural language parser employs a large language model parsing method based on the internalization of flight safety constraints. The system maintains a structured set of flight safety rules, each containing a rule ID, triggering conditions, constraint actions, and severity level. Before each LLM call, the safety rule set is injected into its context. When generating operational instructions, the LLM compares each safety rule, actively rejecting instructions that violate the rules and returning the rejection reason in the form of rule ID and violation description.

[0065] The parsing results are evaluated based on multi-dimensional confidence levels and then executed according to a tiered strategy. The confidence level evaluation dimensions include intent clarity, parameter completeness, module matching, and security compliance. Security compliance is a separate, veto-critical dimension; if security compliance fails, the parsing result is directly rejected. The tiered strategy is as follows: automatic execution occurs when the overall confidence level reaches the first threshold; execution occurs after user confirmation when the overall confidence level reaches the second threshold but is below the first threshold; execution is refused when the overall confidence level is below the second threshold, triggering multiple rounds of clarification dialogue to guide the user to supplement or clarify missing information until the execution conditions are met or the user actively cancels the execution.

[0066] 104. Map the operation instructions in the standardized operation instruction sequence to the standardized interface calls of the underlying system functional modules, and distribute them to the corresponding functional modules for execution.

[0067] The underlying system functional modules receive and execute interface call requests through standardized interfaces. They only respond to standardized interface call execution operations, do not recognize virtual system instances or target syntax types, and return the execution results to the mapping engine layer. After obtaining the execution results and exception information, the mapping engine layer synchronizes them to the runtime environment corresponding to the virtual system instance, allowing users to view the execution status and results of the business logic. Because the underlying system functional modules do not recognize virtual system instances or target syntax types, after a user modifies the business logic and resubmits it, the underlying system functional modules only need to receive and execute the redistributed standardized interface calls, without requiring a restart.

[0068] In some embodiments, the step "distribute to the corresponding functional module for execution" may include the following operations: According to the order of operation instructions in the standardized operation instruction sequence, each operation instruction is distributed to the corresponding functional module for execution in sequence, and the execution status of each operation instruction is monitored. When any operation instruction fails to execute, it is handled according to a predefined rollback strategy, which includes at least one of the retry strategy, skip strategy, and termination strategy.

[0069] The mapping engine layer distributes the operation instructions sequentially to the corresponding functional modules according to the order of the operation instructions in the standardized operation instruction sequence (i.e., the execution order defined by the user), and continuously monitors the execution status of each operation instruction (including execution success, execution failure, timeout, etc.). When any operation instruction fails, the mapping engine layer handles it according to a predefined rollback strategy: When the rollback strategy is a retry strategy, the failed operation instruction is re-executed (for example, when the interface call times out due to network jitter, it is automatically retried). When the rollback strategy is a skip strategy, the failed operation instructions are skipped and the subsequent operation instructions are distributed and executed (for example, if a non-critical operation (such as logging) fails, it is skipped and the main process is not affected). When the rollback policy is the termination policy, the distribution of subsequent operation instructions that have not yet been executed is terminated (for example, the entire sequence is terminated when a critical operation (such as forced return) fails, to avoid unpredictable execution results).

[0070] The rollback strategy can be pre-configured by the user or use the system default configuration. This rollback mechanism ensures data consistency and execution reliability for multiple operation instructions in a distributed execution environment.

[0071] In some embodiments, the method further includes the following steps: Obtain the execution results and exception information of the operation instructions executed by the functional module; The execution results and exception information are synchronized to the runtime environment corresponding to the virtual system instance, allowing users to view the execution status and results of the target business logic.

[0072] Specifically, after the underlying system functional modules execute standardized interface calls, they return the execution results (including success / failure status, returned data, etc.) and exception information (such as sandbox interception, device unavailability, network timeout, etc.) to the mapping engine layer. After obtaining the above execution results and exception information, the mapping engine layer pushes them to the runtime environment corresponding to the virtual system instance through a reverse synchronization mechanism.

[0073] The runtime environment stores the variable context, execution history, and exception records of the virtual system instance. Synchronized execution results and exception information are presented visually in the user interface, such as displaying the success or failure status of instructions, data returned by the device, and detailed reasons for exceptions in the virtual system instance's log view or status panel. Through this reverse synchronization mechanism, users can view the execution status and results of business logic in real time, pinpointing specific operation instructions and failure reasons when exceptions occur. Complete execution feedback can be obtained without logging into the underlying system or consulting system logs, forming a closed loop of "definition → execution → feedback."

[0074] Because each virtual system instance has an independent running environment, execution results and exception information are only synchronized to the corresponding virtual system instance. Execution data between different users are isolated from each other. Users can only view the execution status and results of their own business logic and cannot view the execution data of other users.

[0075] In some embodiments, the method may further include the following steps: In response to a user's update request for the target business logic, the operation of receiving the target business logic and distributing it for execution is re-executed, and the updated target business logic replaces the original target business logic. The updated target business logic takes effect immediately. During the re-execution process, the virtual system instance remains unchanged, and the functional modules only receive and execute the redistributed standardized interface calls without needing to be restarted.

[0076] After a user modifies the target business logic in a virtual system instance and resubmits it, the system re-executes the complete process of "receiving the target business logic → identifying the syntax type → adapter parsing → converting it into a standardized instruction → distributing and executing it", replacing the original business logic with the modified business logic.

[0077] The modified business logic takes effect immediately, meaning that changes submitted by users take effect without waiting for system deployment or restart. During re-execution, the instance identifier and syntax version environment of the virtual system instance remain unchanged. The underlying system functional modules only receive and execute the redistributed standardized interface calls, without requiring a restart. The underlying system functional modules are unaware of the changes in business logic and continue execution according to the redistributed standardized interface calls, thus enabling rapid iteration of business logic.

[0078] For further details, please refer to Figure 3 , Figure 3 This is a flowchart illustrating another system personalization method based on virtual system isolation provided in an embodiment of this application.

[0079] like Figure 3 As shown, the method includes the following steps: S1. Create a virtual system instance.

[0080] After a user completes registration on the business system, the system creates a corresponding virtual system instance for the user based on the user's business type (such as low-altitude inspection, low-altitude logistics, low-altitude emergency search and rescue, or low-altitude surveying and mapping). The virtual system instance includes an independent business definition environment, runtime environment, and syntax version environment. When the instance is created, the corresponding default configuration template is automatically loaded according to the user's industry, so that the user can obtain an initial framework of business logic that matches their industry needs upon first entry.

[0081] S2, Select Custom Syntax.

[0082] After entering their own virtual system instance, users can choose a customized syntax entry point to define business logic based on their skill level and usage habits. In this application, the system supports multiple customized syntax types, including at least scripting languages, visual orchestration diagrams, and natural language descriptions. Users can select different customized syntaxes for different tasks, and the system will automatically match the appropriate syntax adapter based on the user's selection.

[0083] S3. Define the target business logic.

[0084] Users define the target business logic using a selected custom syntax. Specifically, users with programming skills can define business logic by writing script code (such as Python, JavaScript, etc.); business operations personnel without programming skills can define business logic by dragging and dropping visual nodes and connecting them; management or front-line operators can directly state business requirements by inputting natural language descriptions. Regardless of the syntax type used, users define the same target business logic.

[0085] S4. Submit the target business logic.

[0086] After the user completes the business logic definition, they submit the target business logic to the mapping engine layer through the submission interface provided by the virtual system instance. Upon receiving the target business logic, the mapping engine layer identifies the syntax type of the target business logic based on its data format, file extension, or content characteristics, and automatically selects the corresponding syntax adapter for subsequent parsing.

[0087] S5, Syntax Adapter Parsing.

[0088] The corresponding syntax adapter parses the target business logic. Specifically: If the target syntax type is a scripting language, the script adapter performs syntax verification and abstract syntax tree (AST) construction on the script code, and extracts the device status acquisition operation, status threshold judgment condition and device action control operation from the script code; If the target syntax type is a visual orchestration diagram, the orchestration diagram compiler performs a topological sorting traversal of the nodes and connections in the orchestration diagram, extracts the configuration information of each node, and compiles the conditional branch logic. If the target syntax type is natural language, the natural language parser calls the Large Language Model (LLM) to perform intent recognition on the natural language text, extract condition and action information, and map it to the corresponding system module.

[0089] All three adapters output structured operation instructions after parsing. It should be noted that regardless of the syntax type used to define the target business logic, the output of the adapter will always be structured operation instructions with the same format.

[0090] S6. Generate a unified internal representation.

[0091] The structured operation instructions output by the three syntax adapters adopt a unified internal operation instruction sequence. Each operation instruction includes a functional module, operation action, parameter list, preconditions, and post-validation information. The processing flow of the mapping engine layer is independent of which syntax adapter the instruction originates from, thus achieving decoupling between multi-syntax adaptation and underlying standardized execution.

[0092] S7, mapping engine translation.

[0093] The mapping engine maps the operation instructions in the unified internal representation to standardized interface calls of the underlying system functional modules one by one, and fills in the actual parameter values. For example, "get device status" is mapped to a status query interface call to the device management module, and "force return" is mapped to a forced return interface call to the task scheduling module, with the corresponding device identifier passed as a parameter.

[0094] S8, Instruction Distribution and Execution.

[0095] The mapping engine distributes standardized interface calls to the corresponding functional modules for execution according to the order of the standardized operation instruction sequence. Each functional module of the underlying system (including the device management module, task scheduling module, route planning module, GIS / map module, alarm notification module, data query module, etc.) receives and executes the interface calls distributed to it through the standardized interface, performs the actual business operations, and returns the execution results to the mapping engine layer. Each functional module only responds to standardized interface calls to execute operations and does not recognize virtual system instances or target syntax types.

[0096] S9, Result Reverse Synchronization.

[0097] The mapping engine layer obtains the execution results and exception information (such as sandbox interception, device unavailability, network timeout, etc.) returned by each functional module, and then synchronizes the execution results and exception information back to the runtime environment corresponding to the virtual system instance. Users can view the execution status and results of business logic in the virtual system instance and understand the execution status of business logic in real time.

[0098] The changes take effect immediately.

[0099] Users can modify the target business logic at any time within the virtual system instance. When a user modifies the business logic and resubmits it, the system re-executes steps S4 to S9, replacing the original target business logic with the modified one. The modified business logic takes effect immediately. Throughout the re-execution process, the virtual system instance remains unchanged; the underlying system functional modules only receive and execute the redistributed standardized interface calls, requiring no restart. Because the underlying system functional modules do not recognize the target syntax type or perceive changes in business logic, user modifications to the business logic do not affect the stable operation of the underlying system, achieving rapid iteration and immediate effectiveness of business logic.

[0100] To facilitate understanding of the technical solution of this application, the following example illustrates the specific application scenario of a low-altitude unmanned aerial vehicle (UAV) operation platform simultaneously serving customers in two industries: inspection and monitoring, and logistics and distribution.

[0101] A certain low-altitude drone operation platform serves clients in both the power line inspection and logistics industries. The inspection client operates 10 drones for power line inspections, while the logistics client operates 15 drones for last-mile delivery in urban areas. The business processes of the two industries are completely different, but they share the underlying system's equipment pool and core modules.

[0102] After inspection and logistics customers register on the platform, the system loads the corresponding default configuration templates based on their respective industries, creating virtual system instance A for inspection customers and virtual system instance B for logistics customers. The two instances are logically completely independent, each with its own independent business definition environment, runtime environment, and syntax version environment.

[0103] After the technical staff of the inspection client enters virtual system instance A, they select scripting syntax (Python) to write the inspection script. After the business staff of the logistics client enters virtual system instance B, they select the visual orchestration method to drag and drop the delivery process node diagram. The two clients define their business logic in parallel within their respective virtual system instances, without affecting each other.

[0104] After a customer submits a script for inspection, the script adapter parses the script to generate a structured sequence of operation instructions. Similarly, after a customer submits a scheduling diagram, the scheduling diagram compiler performs topology parsing to generate a structured sequence of operation instructions in the same format. Even though the business logic has two different syntax definitions, the output structured sequence of operation instructions is identical after being parsed by different adapters.

[0105] The mapping engine translates the structured operation command sequence of inspection customers into standardized interface calls, which are then distributed to the underlying system functional modules for execution, triggering the call chain `device.list_available() → route.plan() → mission.assign()`. Simultaneously, it translates the structured operation command sequence of logistics customers into standardized interface calls, distributing them to the underlying system functional modules for execution, triggering the call chain `route.optimize() → mission.create() → mission.start()`. The underlying system functional modules only respond to the standardized interface calls and do not distinguish whether the operation commands originate from the inspection customer's script or the logistics customer's orchestration diagram. Execution results are back-synchronized to their respective virtual system instance views, allowing both customers to view the execution status and results of their respective business logic. When inspection customers modify their inspection scripts or logistics customers adjust delivery nodes, the changes take effect immediately without requiring a restart of the underlying system.

[0106] To facilitate better implementation of the system personalization method based on virtual system isolation provided in this application, this application also provides a system personalization device based on virtual system isolation, which is based on the above-described system personalization method based on virtual system isolation. The meanings of the terms used are the same as in the above-described system personalization method based on virtual system isolation, and specific implementation details can be found in the descriptions in the method embodiments.

[0107] Please see Figure 4 , Figure 4A structural block diagram of a system personalization device based on virtual system isolation provided in this application embodiment, the device comprising: The creation unit 301 is used to respond to the user's registration request for the business system and create a corresponding virtual system instance for the user. The virtual system instance provides the user with an independent business logic definition environment. The receiving unit 302 is used to receive the target business logic submitted by the user in the virtual system instance and identify the target syntax type to which the target business logic belongs; The parsing unit 303 is used to parse the target business logic into structured operation instructions through the syntax adapter corresponding to the target syntax type, and convert the structured operation instructions into a standardized operation instruction sequence; The execution unit 304 is used to map the operation instructions in the standardized operation instruction sequence to the standardized interface calls of the underlying system functional modules, and distribute them to the corresponding functional modules for execution. The functional modules respond to the standardized interface calls to perform operations, without recognizing virtual system instances and target syntax types.

[0108] In some embodiments, the syntax type includes at least: scripting language, visual orchestration diagram, and natural language; The parsing unit 303 may include: The first parsing subunit is used to parse the target business logic through the script adapter and generate structured operation instructions if the target syntax type is a scripting language. The second parsing subunit is used to perform topological parsing on the nodes and connections in the target business logic through the orchestration diagram compiler if the target syntax type is a visual orchestration diagram, and generate structured operation instructions. The third parsing subunit is used to perform semantic parsing of the target business logic through a natural language parser and generate structured operation instructions if the target syntax type is natural language. The conversion subunit is used to convert structured operation instructions into a unified format of operation instruction sequence to obtain a standardized operation instruction sequence. The operation instructions in the standardized operation instruction sequence include at least one of the following: functional module, operation action, parameter list, precondition and post-verification information.

[0109] In some embodiments, the target business logic is low-altitude business logic, and low-altitude business includes at least one of low-altitude inspection, low-altitude logistics, low-altitude emergency search and rescue, and low-altitude surveying and mapping. The first parsing subunit can be used to: perform syntax parsing on the script code corresponding to the target business logic through the script adapter, extract the device status acquisition operation, status threshold judgment condition and device action control operation in the script code; map the extracted operations to the corresponding interface calls and instruction parameters, and generate a structured operation instruction sequence according to the execution order in the script code; The second parsing subunit can be used to: traverse the nodes and connections in the target business logic through the orchestration diagram compiler, identify the timed trigger nodes, device operation nodes, status judgment nodes and device control nodes among the nodes; determine the execution order and conditional branching relationship between each node according to the connection, and generate the corresponding structured operation instructions according to the execution order and conditional branching relationship.

[0110] The third parsing subunit can be used to: identify time-triggered conditions, device control intentions, and device status determination conditions in the target business logic through a natural language parser; determine the device actions to be executed based on the device control intentions; and map the time-triggered conditions, device status determination conditions, and device actions into corresponding structured operation instructions.

[0111] In some embodiments, the device may further include: The acquisition unit is used to acquire the execution results and exception information of the operation instructions executed by the functional module; The synchronization unit is used to synchronize execution results and exception information to the runtime environment corresponding to the virtual system instance, so that users can view the execution status and results of the target business logic.

[0112] In some embodiments, the device may further include: The update unit is used to respond to the user's update request for the target business logic, re-execute the operation of receiving the target business logic and distributing it for execution, replace the target business logic before the update with the updated target business logic, and the updated target business logic takes effect immediately. During the re-execution process, the virtual system instance remains unchanged, and the functional modules only receive and execute the redistributed standardized interface calls without needing to be restarted.

[0113] In some embodiments, the creation unit 301 may include: The first determining subunit is used to determine the corresponding configuration template based on the user's business type, and to create a corresponding virtual system instance for the user based on the configuration template. The virtual system instance contains an independent business logic definition environment, runtime environment, and syntax version environment. The device may also include: The generation unit is used to automatically generate and save a timestamped state snapshot in response to user modifications to the target business logic in a virtual system instance. The state snapshot contains the complete modified business logic content. The rollback unit is used to respond to the user's version rollback operation and roll back the current business logic to the version corresponding to the specified historical snapshot; The branch creation unit is used to respond to the user's branch creation operation and create a new branch based on a specified historical snapshot. The branch is independent of the original business logic main line. The merge unit is used to respond to the user's branch merge operation, merge the business logic on the branch into the current business logic of the virtual system instance, and submit the merged business logic as the target business logic for processing.

[0114] In some embodiments, the execution unit 304 may include: The distribution subunit is used to distribute each operation instruction to the corresponding functional module for execution in the order of the operation instructions in the standardized operation instruction sequence, and to monitor the execution status of each operation instruction. The processing subunit is used to handle any operation instruction failure according to a predefined rollback strategy. The rollback strategy includes at least one of the retry strategy, skip strategy, and termination strategy.

[0115] Accordingly, embodiments of this application also provide an electronic device. For example... Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 400 includes a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, and a computer program stored in the memory 402 and executable on the processor. The processor 401 and the memory 402 are electrically connected. Those skilled in the art will understand that... Figure 5 The electronic device structures shown herein do not constitute a limitation on electronic devices and may include, but are not limited to, those shown. Figure 5 It can show more or fewer parts, or combine certain parts, or arrange different parts.

[0116] The processor 401 is the control center of the electronic device 400. It connects various parts of the electronic device 400 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 402, and calling data stored in the memory 402, it performs various functions of the electronic device 400 and processes data, thereby monitoring the electronic device 400 as a whole.

[0117] In this embodiment of the application, the processor 401 in the electronic device 400 loads the instructions corresponding to the processes of one or more applications into the memory 402 according to the following steps, and the processor 401 runs the applications stored in the memory 402 to realize various functions.

[0118] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0119] Optional, such as Figure 5 As shown, the electronic device 400 may further include a display 403 and an input unit 404. The processor 401 is electrically connected to both the display 403 and the input unit 404. Those skilled in the art will understand that... Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0120] Display 403 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. Display 403 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, guidance information, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include a touch detection device and a touch controller.

[0121] The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 401. It can also receive and execute commands from the processor 401. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 401 to determine the type of touch event. Subsequently, the processor 401 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and display panel can be integrated into the display 403 to achieve input and output functions. However, in some embodiments, the touch panel and display panel can be implemented as two independent components to achieve input and output functions. That is, the display 403 can also be used as part of the input unit 404 to achieve input functions.

[0122] The input unit 404 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0123] In some embodiments, the electronic device may further include an audio circuit, which can provide an audio interface between the user and the electronic device via a speaker and a microphone. The audio circuit can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by the audio circuit, converted back into audio data, and output to processor 401 for processing. The audio data is then transmitted via radio frequency circuitry to, for example, another electronic device, or output to memory 402 for further processing. The audio circuit may also include an earphone jack to provide communication between peripheral headphones and the electronic device.

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

[0125] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of computer programs that can be loaded by a digital signal processor to execute steps in any of the system personalization methods based on virtual system isolation provided in embodiments of this application.

[0126] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0127] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0128] Since the computer program stored in the computer-readable storage medium can execute the steps in any of the system personalization methods based on virtual system isolation provided in the embodiments of this application, the beneficial effects that any of the system personalization methods based on virtual system isolation provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0129] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for system personalization customization based on virtual system isolation, characterized in that, The method includes: In response to a user's registration request for a business system, a corresponding virtual system instance is created for the user, and the virtual system instance provides the user with an independent business logic definition environment; Receive the target business logic submitted by the user in the virtual system instance, and identify the target syntax type to which the target business logic belongs; The target business logic is parsed into structured operation instructions by the syntax adapter corresponding to the target syntax type, and the structured operation instructions are converted into a standardized operation instruction sequence. The operation instructions in the standardized operation instruction sequence are mapped to standardized interface calls of the underlying system functional modules and distributed to the corresponding functional modules for execution. The functional modules respond to the standardized interface calls to perform operations without recognizing the virtual system instance or the target syntax type.

2. The method according to claim 1, characterized in that, The syntax types include at least: scripting languages, visual orchestration diagrams, and natural languages; The step of parsing the target business logic into structured operation instructions using the syntax adapter corresponding to the target syntax type, and converting the structured operation instructions into a standardized sequence of operation instructions, includes: If the target syntax type is the scripting language, the target business logic is parsed using a script adapter to generate the structured operation instructions; If the target syntax type is the visual orchestration diagram, the orchestration diagram compiler performs topology parsing on the nodes and connections in the target business logic to generate the structured operation instructions; If the target syntax type is natural language, the target business logic is semantically parsed by a natural language parser to generate structured operation instructions; The structured operation instructions are converted into a unified format operation instruction sequence to obtain the standardized operation instruction sequence. The operation instructions in the standardized operation instruction sequence include at least one of the following: functional module, operation action, parameter list, preconditions, and post-verification information.

3. The method according to claim 2, characterized in that, The target business logic is low-altitude business logic, and the low-altitude business includes at least one of the following: low-altitude inspection, low-altitude logistics, low-altitude emergency search and rescue, and low-altitude surveying and mapping. The step of parsing the target business logic through a script adapter to generate the structured operation instructions includes: The script adapter performs syntax parsing on the script code corresponding to the target business logic, and extracts the device status acquisition operation, status threshold judgment condition and device action control operation from the script code. The extracted operations are mapped to corresponding interface calls and instruction parameters, and a structured operation instruction sequence is generated according to the execution order in the script code. The process of using an orchestration graph compiler to perform topology parsing on the nodes and connections in the target business logic to generate the structured operation instructions includes: The orchestration diagram compiler traverses the nodes and connections in the target business logic to identify timed trigger nodes, device operation nodes, status judgment nodes and device control nodes among the nodes. The execution order and conditional branching relationship between each node are determined based on the connection, and corresponding structured operation instructions are generated according to the execution order and the conditional branching relationship. The step of semantically parsing the target business logic using a natural language parser to generate structured operation instructions includes: The natural language parser identifies the time-triggered conditions, device control intentions, and device status determination conditions in the target business logic. Based on the device control intent, determine the device action to be executed, and map the time triggering condition, the device status determination condition, and the device action into corresponding structured operation instructions.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the execution result and exception information of the operation instruction executed by the functional module; The execution results and the exception information are synchronized to the runtime environment corresponding to the virtual system instance, so that the user can view the execution status and results of the target business logic.

5. The method according to claim 1, characterized in that, The method further includes: In response to the user's update request for the target business logic, the operation of receiving the target business logic and distributing it for execution is re-executed, and the updated target business logic replaces the original target business logic. The updated target business logic takes effect immediately. During the re-execution process, the virtual system instance remains unchanged, and the functional module only receives and executes the redistributed standardized interface calls without needing to be restarted.

6. The method according to claim 1, characterized in that, Creating a corresponding virtual system instance for the user includes: Based on the user's business type, a corresponding configuration template is determined, and a corresponding virtual system instance is created for the user according to the configuration template. The virtual system instance includes an independent business logic definition environment, a runtime environment, and a syntax version environment. The method further includes: In response to the user's modification operation on the target business logic in the virtual system instance, a state snapshot with a timestamp is automatically generated and saved, and the state snapshot contains the complete modified business logic content; In response to the user's version rollback operation, the current business logic is rolled back to the version corresponding to the specified historical snapshot; In response to the user's branch creation operation, a new branch is created based on the specified historical snapshot, and the branch is independent of the original business logic mainline; In response to the user's branch merge operation, the business logic on the branch is merged into the current business logic of the virtual system instance, and the merged business logic is submitted for processing as the target business logic.

7. The method according to claim 1, characterized in that, The process of distributing the code to the corresponding functional module for execution includes: According to the order of the operation instructions in the standardized operation instruction sequence, each operation instruction is distributed to the corresponding functional module for execution in sequence, and the execution status of each operation instruction is monitored. When any operation instruction fails to execute, it is handled according to a predefined rollback strategy, which includes at least one of a retry strategy, a skip strategy, and a termination strategy.

8. A business logic customization system based on virtual system isolation, characterized in that, include: The virtual system instance management layer is used to create mutually isolated virtual system instances for each user, and the virtual system instances provide the user with an independent business definition environment, runtime environment, and syntax version environment; The mapping engine layer, which is connected to the virtual system instance management layer, is used to receive the target business logic submitted by the user in the virtual system instance, identify the target syntax type to which the target business logic belongs, parse the target business logic into structured operation instructions through the syntax adapter corresponding to the target syntax type, convert the structured operation instructions into a standardized operation instruction sequence, and map the operation instructions in the standardized operation instruction sequence into standardized interface calls and distribute them. The underlying system functional module layer contains multiple functional modules. Each functional module receives and executes interface calls distributed by the mapping engine layer through a standardized interface. The functional module responds to the standardized interface calls to perform operations, without recognizing the virtual system instance or the target syntax type.

9. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program to implement the system personalization method based on virtual system isolation as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to execute the system personalization method based on virtual system isolation as described in any one of claims 1 to 7.

Images