Process-level isolation method for embedded ai tool invocation

Abstract

The application relates to the cross field of embedded systems and artificial intelligence, and in particular to a process-level isolation method for embedded AI tool calling, which receives a master Agent tool calling request through a PF_UNIX domain socket, calls fork() to create an independent tool child process by an FCP master service process, creates a bidirectional anonymous pipe to realize parent-child process communication, and integrates the child process into a cgroup control group to realize CPU and memory resource hard limitation and realize resource autonomous release through a SIGTERM signal callback function; the FCP master service process adopts a two-stage ladder timeout control strategy. The application can realize process-level fault isolation, prevent tool plug-in abnormal expansion to core business, prevent business avalanche through resource limitation, support plug-in hot update without service restart, realize lightweight adaptation through pure Linux native system calling, and is suitable for resource-limited embedded terminal equipment.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a process-level isolation method for embedded AI tool calls. Background Technology

[0002] With the deepening application of artificial intelligence technology in the field of power measurement, embedded measurement devices such as intelligent fusion terminals are gradually introducing NPU computing units, equipped with large language models and machine learning models, to achieve AI capabilities such as semantic understanding, intelligent decision-making, task decomposition and planning. In this heterogeneous dual-core architecture, the NPU computing unit is responsible for AI model inference and decision-making, while the local main control unit carries the core business functions such as original measurement business driving, hardware peripheral control, and measurement data storage. During the inference process, the AI ​​model needs to call local tool plugins to complete specific business operations such as measurement data collection, parameter configuration, anomaly analysis, and log query. The scheduling and execution of these tools become the key link in connecting the AI ​​intelligent decision-making with the local business closed loop.

[0003] The AI ​​tool invocation mechanism of embedded terminals aims to achieve effective collaboration between the large language model inference decision layer and the local business tool execution layer. However, existing embedded terminals have many technical shortcomings in AI tool invocation.

[0004] Question 1: Existing solutions typically load tool plugins directly into the address space of the main service process as dynamic library (SO) files. When the tool plugin encounters exceptions such as memory leaks, deadlocks, segmentation faults, or illegal memory accesses, the exceptions will propagate directly to the main service process, causing it to crash and thus affecting the normal operation of the terminal's core measurement services.

[0005] Question 2: Tool plugins share all CPU and memory resources of the main process. Abnormal behavior of a single plugin, such as infinite loops or excessive memory allocation, can preempt the entire machine's resources, triggering a business cascading failure. Regarding timeout disaster recovery, existing solutions employ a single timeout strategy, directly killing the tool execution after a timeout. This approach carries the risk of resource leakage and lacks effective cleanup methods for scenarios such as deadlocks or signal blocking that cannot respond to ordinary termination signals.

[0006] Question 3: General AI tool scheduling frameworks are designed for server or cloud environments and rely on a complete network protocol stack and sufficient system resources. Their huge communication overhead and complex dependency system are not suitable for embedded terminals, while existing solutions lack lightweight tool scheduling mechanisms for low-power and high-real-time scenarios.

[0007] Question 4: In the existing solution, the tool plugin has the same system permissions as the main service and can directly access hardware devices, file systems and databases. When the tool plugin is maliciously tampered with or has logical defects, there is a risk of unauthorized operation.

[0008] The aforementioned technical issues severely restrict the reliable deployment and large-scale application of AI capabilities in embedded terminals. There is an urgent need for a process-level isolation method for AI tool calls in embedded terminals, which can achieve complete isolation between inference decision-making, tool scheduling and business execution, while meeting the lightweight and high real-time requirements of embedded resource-constrained environments. Summary of the Invention

[0009] The purpose of this invention is to address the problems mentioned in the background art by proposing a process-level isolation method for embedded AI tool calls.

[0010] The technical solution of this invention is: This invention provides a process-level isolation method for embedded AI tool calls, comprising the following specific steps: Step 1: The master agent sends a tool invocation request to the FCP master service process through the PF_UNIX domain socket; Step 2: After receiving the tool call request, the FCP main service process verifies the request. If the verification is successful, it calls the fork system function to create an independent tool child process and creates a bidirectional anonymous pipe. The downlink pipe is used to send the call parameters to the child process, and the uplink pipe is used for the child process to send back the execution result. Step 3: The FCP main service process writes the process identifier (PID) of the child process into a pre-created cgroup control group, and performs hard-limit binding on the CPU utilization and memory usage of the child process; Step 4: The child process closes unused pipe ports, registers a SIGTERM signal callback function, and receives JSON format call parameters sent by the main service process through the downlink pipe; Step 5: The child process dynamically loads the corresponding tool dynamic library file using dlopen based on the call parameters, obtains the tool's execution entry function, and executes the business logic; Step 6: The child process sends the execution result back to the FCP main service process through the uplink pipe. After the service is completed, it actively unloads the dynamic library, closes the pipe file descriptor, and exits the process. Step 7: After receiving the execution result, the FCP main service process performs two-level timeout control: If the child process does not exit within the first-level timeout period, a SIGTERM signal is sent to trigger the child process's signal callback function to release resources gracefully and exit gracefully; if the child process still does not exit after the second-level timeout period, a SIGKILL signal is sent to forcibly destroy the process. Step 8: The FCP main service process reclaims child process resources, cleans up pipe file descriptors and cgroup control group bindings, and waits for the next tool call.

[0011] Furthermore, in step 1, The FCP main service process is an independently running background service process that holds terminal hardware driver, data read / write and system management permissions, and does not load any tool business code; The FCP main service process communicates with the main control agent using the FCP protocol based on the JSON-RPC message specification. The PF_UNIX domain socket creates a streaming socket based on the file system path. Communication data is transmitted between processes in the kernel space without going through the TCP / IP network protocol stack.

[0012] Furthermore, in step 2, each tool call generates an independent child process, and the lifecycle of the child process is bound to a single tool call. The child process is destroyed when the call ends. The bidirectional anonymous pipe includes a downlink pipe and an uplink pipe, both of which are kernel-mode pipes created by the Linux system's native pipe system call.

[0013] Furthermore, in step 3, the resource restrictions of the cgroup control group include CPU restrictions and memory restrictions; CPU limiting is based on the Linux CFS scheduling bandwidth limiting mechanism. By configuring the CPU usage percentage parameter, the scheduling cycle and CPU quota are automatically calculated. CPU quota = scheduling cycle × CPU usage percentage. The memory limit adopts a dual threshold strategy, including soft memory limit and hard memory limit. When the memory usage reaches the soft limit, the kernel memory reclamation warning is triggered but the process is not killed. When the memory usage reaches the hard limit, the OOM mechanism is triggered to forcibly kill abnormal child processes. The CPU limiting parameters, memory soft limiting parameters, memory hard limiting parameters, and OOM control switch are all uniformly managed through a configuration file.

[0014] Furthermore, in step 4, the specific implementation of the child process registering the SIGTERM signal callback function includes: Before the child process executes business logic, the SIGTERM signal handler function is registered first through the sigaction system call, and the pipe handle and dynamic library handle are mounted to global variables. When a child process receives a SIGTERM signal, the signal callback function is triggered to perform the following operations: close all pipe file descriptors to release IPC resources, call dlclose to unload loaded utility dynamic libraries to release code segment memory, set an exit flag, and exit the child process with a timeout error code.

[0015] Furthermore, in step 7, the two-tiered timeout control includes: The FCP main service process detects the exit status of child processes by non-blocking waitpid polling, with the polling interval being a preset time granularity value. Level 1 timeout: When triggered, the main service process sends a SIGTERM signal to the child process. After the child process catches the signal, it executes the signal callback function to release resources and exit gracefully. The main service process records the timeout exception log and returns the timeout error code. Level 2 timeout: When triggered, the main service process sends a SIGKILL signal to the child process, and the kernel directly destroys the process. The main service process returns a resource exception error code. Both the first-level timeout threshold and the second-level timeout threshold are set through the configuration file, and the first-level timeout threshold is less than the second-level timeout threshold.

[0016] Furthermore, during the service startup phase, the FCP main service process initializes sockets, pipes, cgroup control groups, logs, and watchdog modules, scans and verifies the preset hash signatures of all dynamic library files in the tool plugin directory, reads plugin metadata and writes it to the tool registry, and does not load any dynamic libraries into the main process memory space. The FCP main service process implements full-state management of tool plugins, including idle state, running state, abnormal circuit breaker state, and manually disabled state.

[0017] Furthermore, the unified execution entry function signature of the tool dynamic library file is int ToolRunFunc(const cJSON* args, cJSON* output); where args are JSON format request parameters read by the subprocess from the anonymous pipe, and output is the JSON structure output by the tool execution; each tool dynamic library exports a fixed global structure, which includes the tool name, function description, input parameter format definition, execution entry function pointer, scheduling priority, and timeout fields; the FCP main service process only reads the metadata of this structure for registration and scheduling, and does not execute the function pointers therein.

[0018] Furthermore, it also includes the hot update steps for tool plugins: When tool plugins need to be updated, the local dynamic library file is replaced. The FCP main service process does not need to be restarted. The newly forked child process will automatically load the new version of the dynamic library the next time the tool is called. If the new version of the plugin's subprocess malfunctions, it will automatically switch back to the old version of the plugin's scheduling. The running tool subprocesses are not affected by the hot update process.

[0019] Furthermore, the verification request in step 2 includes multiple levels: The first layer is message validity verification, which parses the JSON-RPC message format and verifies the integrity of the fields; The second layer is tool existence verification, which searches for a match in the local tool registry based on the tool name; The third layer is tool status verification, which checks whether the target tool is in an idle state; The fourth layer is the input parameter validation, which parses the call parameters and matches them with the input parameter format definitions recorded in the tool's registry.

[0020] The beneficial effects of this invention are: (1) Process-level fault isolation. This invention abandons the existing model of loading dynamic libraries in the same process. Each tool call creates an independent child process to run the tool plugin through fork(). Plugin deadlock, memory overflow, crash, illegal access and other exceptions will only destroy the current child process and will not spread to the FCP main service process and the terminal core measurement business. The risk of plugin failure affecting the terminal core business is completely eliminated at the process level.

[0021] (2) Hardware resource hard limit to prevent cascading failure. This invention is based on the Linux native cgroup component and limits the maximum CPU usage ratio and maximum memory usage limit for each tool subprocess. The single-core CPU usage is precisely limited by the CFS scheduling bandwidth limit mechanism, and the dual threshold strategy of soft limit and hard limit of memory is used to achieve hierarchical protection of early warning and recycling and strong killing when the limit is exceeded, so as to avoid the business cascading failure caused by a single tool abnormally occupying the CPU and memory resources of the whole machine.

[0022] (3) Two-tiered timeout disaster recovery. This invention adopts an industrial-grade two-tiered exit strategy. The first-tier timeout sends a SIGTERM signal, and the child process gracefully exits after autonomously closing the pipe file descriptor, unloading the dynamic library, and releasing memory resources through a pre-registered signal callback function, thus avoiding resource leaks. The second-tier timeout sends a SIGKILL signal as a fallback for extreme failures, forcibly destroying the process in scenarios where the child process cannot gracefully exit due to deadlock, infinite loop, signal blocking, etc. The two-tiered timeout thresholds are set through configuration files, taking into account both business integrity and system stability.

[0023] (4) Embedded Lightweight Adaptation. This invention is developed in pure C language, relying only on native Linux system calls, without any third-party framework dependencies. Upper-layer communication uses PF_UNIX domain sockets, bypassing the TCP / IP network protocol stack, reducing communication latency and CPU overhead; lower-layer communication uses anonymous pipes, with pure kernel-mode data transmission and no user-mode protocol parsing overhead. The overall solution is adapted to embedded edge devices.

[0024] (5) Layered and Controlled Security Isolation of Permissions. This invention consolidates system permissions into layers. The FCP main service process holds all permissions for hardware drivers, data read / write, peripheral control, and system management, but is only responsible for scheduling and forwarding and does not execute business code. Tool subprocesses only have temporary business execution permissions, without scheduling or process management permissions. All hardware operation requests must be authenticated and forwarded by the main service. This eliminates the security risk of tool plugins exceeding their permissions and affecting existing services from the permission level.

[0025] (6) Highly efficient resource utilization with immediate use and disposal. The lifecycle of the child process is strongly bound to a single tool call. The process is destroyed and all resources are reclaimed immediately after the call ends, leaving no residual background processes on the entire machine. This differs from the persistent background process mode, maximizing the saving of limited device resources. It also supports hot updates for plugins, allowing the main service to complete function iterations without restarting, adapting to the needs of unattended operation and maintenance on site.

[0026] Other features and advantages of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0027] The above and other objects, features and advantages of the present invention will become more apparent from the more detailed description of exemplary embodiments of the invention in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the invention.

[0028] Figure 1 This is a schematic diagram of the overall process of the method of the present invention; Figure 2 This is a schematic diagram of the architecture hierarchy of the present invention; Figure 3 This is a schematic diagram of anonymous pipe IPC communication between parent and child processes according to the present invention; Figure 4 This is a timing diagram for the two-level tiered timeout control of the present invention; Figure 5 This is a flowchart of the SIGTERM signal callback processing for the subprocess of this invention; Figure 6 This is a flowchart of the cgroup resource restriction binding process of the present invention; Figure 7 This is a diagram showing the state transitions throughout the entire lifecycle of the tool plugin of this invention. Detailed Implementation

[0029] Preferred embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0030] I. Overall System Architecture Design like Figure 2 As shown, the system of this invention adopts a three-layer isolation architecture, with each layer having unidirectional dependency and no reverse coupling: Layer 1: Master Agent. Deployed on the terminal's NPU computing unit, it carries an LLM large language model and is responsible for semantic understanding, intelligent decision-making, and task decomposition. The Master Agent issues tool call requests to the FCP main service process through the PF_UNIX domain socket, serving as the entry point for the entire tool scheduling system. The Master Agent is only responsible for AI inference and decision-making and has no terminal hardware or system operation permissions.

[0031] The second layer: FCP main service process (FCP Server). Deployed in the terminal main control unit, it runs independently in the background and has full authority over all terminal hardware drivers, measurement data read / write, peripheral control, system maintenance, process management, and cgroup management. The FCP main service process is the sole service entry point for connecting to the main control agent, responsible for request parsing, permission verification, child process creation and destruction, resource limit binding, pipeline parameter forwarding, and result aggregation. Crucially, the FCP main service process does not load any tool SO libraries or execute business code; it is only responsible for scheduling and control.

[0032] The third layer consists of isolated tool subprocesses and tool plugin SO libraries. Tool subprocesses are generated by the FCP main service process via `fork()`, and their lifecycle follows each single tool call. Upon startup, the subprocess is immediately added to the cgroup control group, responsible only for loading the corresponding tool SO library and executing business logic; it has no scheduling or process management permissions. Tool plugin SO libraries are dynamically loaded only within the subprocess, possessing no independent lifecycle, no network port, and no autonomous execution capability.

[0033] The above three-layer architecture achieves complete isolation between AI inference and decision-making, FCP main service scheduling, and tool business execution: failure of the main control agent does not affect the FCP main service; failure of the tool sub-process does not affect the FCP main service; failure of the FCP main service does not affect the terminal's existing measurement business (because the FCP main service is an independent background process). The technical solution of the present invention will be further described in detail below through embodiments and in conjunction with the accompanying drawings.

[0034] like Figure 1 As shown, a complete tool invocation process of the method of the present invention includes the following steps: Access Request: The master agent issues a JSON-RPC request to the FCP master service process via the tools / call utility through the PF_UNIX domain socket. The PF_UNIX domain socket creates a streaming socket based on a file system path (e.g., / temp / fcp_server.sock), supports concurrent connections from multiple clients and automatic reconnection after disconnection, and communication data is transferred between processes in kernel space without going through the TCP / IP network protocol stack.

[0035] Request verification: The FCP main service process performs message validity verification, input parameter verification, tool status verification, and permission verification, and matches it against the local tool registry. If the tool is in an abnormal circuit breaker state or manually disabled, the call is rejected and the corresponding error code is returned.

[0036] Process creation: The FCP main service process calls the fork() system function to generate an independent utility child process, and at the same time creates a set of bidirectional anonymous pipes (downstream pipe parent2child and upstream pipe child2parent), binding the communication handles of the parent and child processes.

[0037] Resource binding: The FCP main service process writes the child process PID to the cgroup.procs file of the preset cgroup control group to complete the hard limit binding of CPU and memory resources.

[0038] Parameter delivery: The FCP main service process sends JSON-formatted call parameters to the child process through a downlink anonymous pipe.

[0039] Business execution: The child process reads the pipe parameters, dynamically loads the target tool SO library using dlopen, and executes the business code.

[0040] Result feedback: The child process sends the execution result and error code back to the FCP main service process through the uplink pipe.

[0041] Timeout Management: The FCP main service process performs a two-tiered timeout check (see Section 4 below for details).

[0042] Resource reclamation: After the FCP main service process reads the results, it reclaims pipe file descriptors and cgroup resources to prevent zombie processes.

[0043] like Figure 3 As shown, after the FCP main service process forks to create a tool child process, it completes local inter-process communication without network access through bidirectional anonymous pipes. The anonymous pipes are created using the Linux system's native pipe() system call, enabling pure kernel-mode data transmission with no user-mode protocol parsing overhead, thus adapting to the low-latency requirements of embedded systems.

[0044] Pipeline structure definition: typedef struct { int parent2child[2]; / / Downstream pipeline: main writes, sub-reads int child2parent[2]; / / Upstream pipe: child writes, parent reads PipePair; Downlink Pipeline (Master → Child): The FCP master service process sends JSON-formatted call parameters and timeout control instructions to the child process through the downlink pipeline.

[0045] Upstream Pipeline (Child → Master): The child process reports the tool execution results, runtime logs, and exception error messages to the master service process through the upstream pipeline.

[0046] Port management: After a child process is created, it prioritizes closing pipe ports that it doesn't need—closing the downlink pipe write end and the uplink pipe read end, leaving only the downlink pipe read end and the uplink pipe write end open to prevent file descriptor leaks. The main service process also closes the ports used by the child processes.

[0047] The maximum message length of the pipeline is limited to a preset value (e.g., 1024 bytes) to adapt to short message scenarios in measurement services and prevent excessively long messages from causing pipeline blockage.

[0048] like Figure 4 As shown, the two-tiered timeout control of this invention is the core innovation of the disaster recovery system, and the complete timing sequence is as follows: Normal process: The child process completes its business on time → actively releases resources (unloads the SO library, closes the pipe file descriptor, and releases memory) → exits normally without sending any signals.

[0049] Level 1 Timeout (SIGTERM Graceful Exit): When the execution time of the child process reaches the Level 1 timeout threshold (e.g., 2000ms), the FCP main service process sends a SIGTERM signal to the child process. The child process has pre-registered a SIGTERM signal callback function before business execution. Upon receiving the signal, the callback is triggered immediately, and the following operations are performed: Set the global exit flag g_child_need_exit = 1; Call pipe_close_child() to close all pipe file descriptors and release IPC resources; Call dlclose() to unload the loaded utility SO dynamic library and release the memory of the code segment; The child process is quickly exited by calling _exit() with a timeout error code of 1005.

[0050] This mechanism ensures that child processes can autonomously clean up resources before exiting, avoiding file descriptor leaks and memory leaks.

[0051] Level 2 Timeout (SIGKILL Forced Kill): When a child process fails to respond to the SIGTERM signal due to deadlock, infinite loop, signal blocking, or other reasons, and has not exited after reaching the Level 2 timeout threshold (e.g., 3000ms), the FCP main service process sends a SIGKILL signal to the child process. The SIGKILL signal is handled directly by the kernel and cannot be caught, blocked, or ignored; the process is immediately destroyed. The main service process then reclaims the child process's exit status using waitpid() and returns a 1012 resource exception error code.

[0052] Polling detection mechanism: The FCP main service process uses a non-blocking `waitpid(pid, &status, WNOHANG)` function to poll and check the exit status of child processes. The polling interval is 5 milliseconds (`usleep(5000)`), which has low overhead and does not consume CPU. In each poll, it checks whether the current waiting time exceeds the first or second level timeout threshold and sends the corresponding signal accordingly.

[0053] The two-level timeout duration, CPU resource threshold, and memory hardware and software limits are all managed in the configuration file (ai_fcp.conf). On-site operations and maintenance personnel do not need to modify the code or recompile; they can dynamically adjust the parameters by simply modifying the configuration file.

[0054] like Figure 5 As shown, the SIGTERM signal callback handling of the child process is a key part of the two-level timeout strategy, ensuring that the child process can terminate autonomously under the first-level timeout. The specific implementation steps are as follows: 1. Disable redundant pipe ports: After the child process is created, it will prioritize closing the pipe read and write ports that it does not need to use, and only keep the downlink pipe read end and the uplink pipe write end.

[0055] 2. Signal Acquisition Pre-initialization: Before executing business logic, register the SIGTERM signal handler function via the sigaction() system call. Simultaneously, attach the pipe handle and empty SO library handle to global variables (g_child_pipe_handle, g_child_so_handle) to ensure the signal callback function can access the resource handle correctly.

[0056] 3. Receive Invocation Parameters: Receive JSON-formatted tool invocation parameters from the main service process via a blocking downlink pipe. If parameter reception fails, the pipe is closed and the child process exits, returning a communication error code 1010.

[0057] 4. Dynamically load tool SO libraries: Based on the tool path specified in the input parameters, dynamically load the business plugin using dlopen to obtain the unified execution entry function for the tool. After loading, update the SO library handle to the global variable g_child_so_handle for use by the signal callback function for unloading.

[0058] 5. Proactive release of routine resources: After the business is completed normally, the child process actively releases the memory of the JSON message, unloads the SO library (dlclose), closes the pipe port, and actively calls _exit(0) to exit the process.

[0059] 6. Abnormal signal fallback handling: If a SIGTERM signal is received from the main service process during business operation, the signal callback function is immediately triggered to forcibly reclaim all IPC resources and dynamic library resources, and the child process exits with a 1005 timeout error code.

[0060] like Figure 6 As shown, this invention implements hard resource management for tool child processes based on the Linux native cgroup v1 kernel interface, including the following aspects: 6.1 CPU resource limitations Based on the Linux CFS (Complete Fair Scheduler) bandwidth limiting mechanism, precise CPU utilization is achieved through two kernel parameters: cpu.cfs_period_us: CFS scheduling period, fixed at 100,000 microseconds (100ms), which is the default standard value for Linux systems; cpu.cfs_quota_us: CPU quota, which is automatically calculated by the code based on the CPU usage percentage configured in the business layer. The formula is: quota = period × ratio / 100.

[0061] For example, if the CPU utilization percentage is configured to 10%, then cpu.cfs_quota_us = 100000 × 10 / 100 = 10000 microseconds. Operations personnel only need to modify the intuitive percentage parameter (cpu_max_ratio), and the underlying code automatically synchronizes the kernel quota, eliminating the need to concern themselves with microsecond-level kernel parameters.

[0062] 6.2 Memory Resource Limitations A dual-threshold strategy is employed to differentiate between soft and hard limits: memory.soft_limit_in_bytes (soft limit): When the memory usage of a child process reaches this value, the kernel memory reclamation mechanism is triggered to issue a warning, but the process will not be killed, allowing the business to continue to execute; memory.limit_in_bytes (hard limit): When the memory usage of a child process reaches this value, the OOM (Out-Of-Memory) mechanism is triggered directly, forcibly killing the abnormal child process; memory.oom_control: OOM control switch. Setting it to 1 enables automatic process killing when memory exceeds the limit, while setting it to 0 only logs alarms.

[0063] This dual-threshold design avoids the problem of business processes being killed directly due to slight memory fluctuations, balancing business stability and resource protection capabilities.

[0064] 6.3 Initialization and Binding Process When the FCP main service process starts, it calls cgroup_init() to read configuration file parameters and recursively create cgroup root directories. Automatically calculate CPU quotas and write them to the cpu.cfs_quota_us file; Set the CFS scheduling period and write it to the cpu.cfs_period_us file; Set a soft limit on memory and write it to the memory.soft_limit_in_bytes file; Set a hard limit on memory and write it to the memory.limit_in_bytes file; Configure the OOM control switch and write it to the memory.oom_control file; After each fork of a child process, call cgroup_add_pid() to write the child process's PID to the cgroup.procs file to complete the binding; When the service exits, call cgroup_destroy() to clean up all residual processes and cgroup directories.

[0065] like Figure 7 As shown, the state management of tool plugins includes the following four state transitions: 1. Service Startup Phase: The FCP main service process initializes sockets, pipes, cgroup control groups, logs, and watchdog modules, and scans and verifies all tool SO plugins. Verification includes SHA256 signature verification and dynamic library validity verification, blocking malicious plugins. The main process only reads ToolPluginInfo metadata and writes it to the tool registry; it does not load any dynamic libraries into the main process's memory space.

[0066] 2. Call Execution Phase: Receive call request → Verification successful → Fork child process → Bind cgroup → Pass parameters via pipe → Child process loads SO execution tool. The tool's registry records the currently running child process's PID (run_pid field), used for monitoring and destroying the main process.

[0067] 3. Abnormal Circuit Breaker Phase: After a child process times out, crashes, or exceeds memory limits and is killed by cgroup, the main process immediately reclaims process resources and increments the tool's error count (error_count). When the error count reaches a threshold, the current tool is marked as being in a circuit breaker state (TOOL_ERROR), and the tool is prohibited from being rescheduled for a period of time.

[0068] 4. Hot Update Maintenance Phase: The main process replaces the local SO plugin file. The next time it's called, the newly forked child process automatically loads the new plugin. The main process does not need to be restarted, and running child processes are unaffected. If the new plugin child process malfunctions, the system automatically switches back to the old plugin, achieving automatic rollback in case of failure.

[0069] 5. End of call phase: After a single tool execution is completed, the child process actively exits, the main process automatically reclaims all IPC and process resources, and there are no residual background processes on the entire machine.

[0070] This invention defines a unified tool execution entry function: typedef int (*ToolRunFunc)(const cJSON* args, cJSON* output); All tool plugins export a fixed global structure: typedef struct { const char* tool_name; / / Unique identifier for the tool const char* description; / / Description of the tool's functionality const char* input_schema; / / Input parameter format definition ToolRunFunc run; / / Entry point function for tool business execution int priority; / / Tool scheduling priority int timeout; / / Tool execution timeout (ms) ToolPluginInfo; This invention adds two child process-specific error codes to adapt to process isolation scenarios:

[0071] In practice: The following example, using the intelligent fusion terminal voltage measurement and acquisition tool, illustrates the specific implementation process of this invention: Implementation environment: Intelligent converged terminal, with the main control unit equipped with an ARM Cortex-A processor, 2GB of RAM, 16GB of storage, and running an embedded Linux operating system. The NPU computing unit is equipped with an LLM large model.

[0072] Configuration parameters: Level 1 timeout threshold: 20000ms, Level 2 timeout threshold: 30000ms, CPU usage limit: 10%, Memory soft limit: 100MB, Memory hard limit: 128MB, cgroup root path: / sys / fs / cgroup / fcp_tool / ; Invocation process: 1. The master agent sends a request through the PF_UNIX domain socket: {"jsonrpc":"2.0","id":3,"method":"tools / call","params":{"name":"measure.voltage.get","arguments":{}}} 2. The FCP main service process passes the verification. Fork() creates a child process (PID=1523) and a bidirectional pipe is created.

[0073] 3. The main service process writes PID 1523 to / sys / fs / cgroup / fcp_tool / cgroup.procs to complete the cgroup binding.

[0074] 4. The child process closes redundant pipe ports, registers a SIGTERM signal callback function, and mounts the pipe handle and empty SO library handle to global variables.

[0075] 5. The child process receives JSON parameters through the downlink pipe.

[0076] 6. The subprocess dlopen loads measure_voltage.so, obtains the entry point of the tool_get_voltage function, and executes the three-phase voltage acquisition service.

[0077] 7. The child process sends back the result via the uplink pipe: {"code":0,"msg":"success","data":{"u_a":"220.1V","u_b":"219.8V","u_c":"220.3V"}} 8. The child process actively uses dlclose to unload the SO library, closes the pipe port, and calls _exit(0) to exit.

[0078] 9. The main service process waitpid detects that the child process has exited normally, reclaims pipe resources, clears the PID field in the registry, and returns the result to the Agent.

[0079] Example of a timeout scenario: If the voltage acquisition tool in step 6 above freezes due to an RS-485 communication malfunction, and the child process does not exit within 20000ms: 1. When the main service process detects that the waiting time has reached 2000ms (Level 1 timeout), it sends a SIGTERM signal to the child process.

[0080] 2. When the child process signal callback function is triggered, the pipe fd is closed, dlclose is used to unload the SO library and release memory, and the process exits with _exit(1005).

[0081] 3. When the main service process detects that the child process has exited, it returns a 1005 timeout error code and records the exception in the log.

[0082] If the child process is unable to respond to the SIGTERM signal due to deadlock, at 30000ms: 1. When the main service process sends a SIGKILL signal, the kernel directly destroys the process.

[0083] 2. The main service process waitpid reclaims the child process and returns a resource exception error code of 1012.

[0084] 3. The main service process increments the error_count of this tool. If the threshold is reached, the tool is marked as TOOL_ERROR circuit breaker status.

[0085] Hot update example: When it is necessary to update the acquisition logic of the voltage acquisition tool: 1. Maintenance personnel can trigger tool list reload via the remote command RELOAD_TOOL.

[0086] 2. Replace the file / opt / ai_fcp / tools / measure_voltage.so with the latest version.

[0087] 3. The FCP main service process does not need to be restarted; it scans for new SO files and updates registry metadata.

[0088] 4. The next time measure.voltage.get is called, the newly forked child process will automatically load and execute the new version of the SO library.

[0089] 5. If the new version of the SO library malfunctions, it will automatically switch back to the old version of the plugin files.

[0090] This invention adheres to the following core constraints in its system design to ensure the reliability of the isolation mechanism: One-way process dependency: Child processes depend on the main process for creation and management, but the main process does not depend on child processes for execution. Child process failures will not affect the main process. Centralized resource permissions: All system, hardware, process, and cgroup permissions belong to the FCP main process; child processes only have business execution permissions. Layered separation of responsibilities: The main process manages scheduling, process control, resource limits, and communication forwarding; child processes manage tool business execution, with clear boundaries and no overstepping of responsibilities. No cross-process shared memory: Parent and child processes are prohibited from sharing memory space; all data interaction is done through pipe copying, completely avoiding the risk of memory address out-of-bounds errors. Horizontal scalability: The main service base is fixed and stable; measurement tools can be added as needed. All new tools reuse the same fork + pipe + cgroup isolation mechanism, requiring no modification to the framework code.

[0091] These constraints together form the core design basis of this invention, ensuring an effective balance between reliability, security, and scalability of the system.

[0092] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

Claims

1. A process-level isolation method for embedded AI tool calls, characterized in that, The specific steps include the following: Step 1: The master agent sends a tool invocation request to the FCP master service process through the PF_UNIX domain socket; Step 2: After receiving the tool call request, the FCP main service process verifies the request. If the verification is successful, it calls the fork system function to create an independent tool child process and creates a bidirectional anonymous pipe. The downlink pipe is used to send the call parameters to the child process, and the uplink pipe is used for the child process to send back the execution result. Step 3: The FCP main service process writes the process identifier (PID) of the child process into a pre-created cgroup control group, and performs hard-limit binding on the CPU utilization and memory usage of the child process; Step 4: The child process closes unused pipe ports, registers a SIGTERM signal callback function, and receives JSON format call parameters sent by the main service process through the downlink pipe; Step 5: The child process dynamically loads the corresponding tool dynamic library file using dlopen based on the calling parameters, obtains the tool's execution entry function, and executes the business logic; Step 6: The child process sends the execution result back to the FCP main service process through the uplink pipe. After the service is completed, it actively unloads the dynamic library, closes the pipe file descriptor, and exits the process. Step 7: After receiving the execution result, the FCP main service process performs two-level timeout control: If the child process does not exit within the first-level timeout period, a SIGTERM signal is sent to trigger the child process's signal callback function to release resources gracefully and exit gracefully; if the child process still does not exit after the second-level timeout period, a SIGKILL signal is sent to forcibly destroy the process. Step 8: The FCP main service process reclaims child process resources, cleans up pipe file descriptors and cgroup control group bindings, and waits for the next tool call.

2. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, In step 1, The FCP main service process is an independently running background service process that holds terminal hardware driver, data read / write and system management permissions, and does not load any tool business code; The FCP main service process communicates with the main control agent using the FCP protocol based on the JSON-RPC message specification. The PF_UNIX domain socket creates a streaming socket based on the file system path. Communication data is transmitted between processes in the kernel space without going through the TCP / IP network protocol stack.

3. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, In step 2, each tool call generates an independent child process. The lifecycle of the child process is bound to a single tool call, and the child process is destroyed when the call ends. The bidirectional anonymous pipe includes a downlink pipe and an uplink pipe, both of which are kernel-mode pipes created by the Linux system's native pipe system call.

4. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, In step 3, the resource limits of the cgroup control group include CPU limits and memory limits; CPU limiting is based on the Linux CFS scheduling bandwidth limiting mechanism. By configuring the CPU usage percentage parameter, the scheduling cycle and CPU quota are automatically calculated. CPU quota = scheduling cycle × CPU usage percentage. The memory limit adopts a dual threshold strategy, including soft memory limit and hard memory limit. When the memory usage reaches the soft limit, the kernel memory reclamation warning is triggered but the process is not killed. When the memory usage reaches the hard limit, the OOM mechanism is triggered to forcibly kill abnormal child processes. The CPU limiting parameters, memory soft limiting parameters, memory hard limiting parameters, and OOM control switch are all uniformly managed through a configuration file.

5. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, In step 4, the specific implementation of the child process registering the SIGTERM signal callback function includes: Before the child process executes business logic, the SIGTERM signal handler function is registered first through the sigaction system call, and the pipe handle and dynamic library handle are mounted to global variables. When a child process receives a SIGTERM signal, the signal callback function is triggered to perform the following operations: close all pipe file descriptors to release IPC resources, call dlclose to unload loaded utility dynamic libraries to release code segment memory, set an exit flag, and exit the child process with a timeout error code.

6. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, In step 7, the two-tiered timeout control includes: The FCP main service process detects the exit status of child processes by non-blocking waitpid polling, with the polling interval being a preset time granularity value. Level 1 timeout: When triggered, the main service process sends a SIGTERM signal to the child process. After the child process catches the signal, it executes the signal callback function to release resources and exit gracefully. The main service process records the timeout exception log and returns the timeout error code. Level 2 timeout: When triggered, the main service process sends a SIGKILL signal to the child process, and the kernel directly destroys the process. The main service process returns a resource exception error code. Both the first-level timeout threshold and the second-level timeout threshold are set through the configuration file, and the first-level timeout threshold is less than the second-level timeout threshold.

7. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, During the service startup phase, the FCP main service process initializes sockets, pipes, cgroup control groups, logs and watchdog modules, scans and verifies the preset hash signatures of all dynamic library files in the tool plugin directory, reads plugin metadata and writes it to the tool registry, and does not load any dynamic libraries into the main process memory space. The FCP main service process implements full-state management of tool plugins, including idle state, running state, abnormal circuit breaker state, and manually disabled state.

8. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, The unified execution entry function signature of the tool dynamic library file is int ToolRunFunc(const cJSON* args, cJSON*output); where args are JSON format request parameters read by the child process from the anonymous pipe, and output is the JSON structure output by the tool execution; each tool dynamic library exports a fixed global structure, which includes the tool name, function description, input parameter format definition, execution entry function pointer, scheduling priority, and timeout fields; the FCP main service process only reads the metadata of this structure for registration and scheduling, and does not execute the function pointers in it.

9. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, This also includes the hot update steps for tools and plugins: When tool plugins need to be updated, the local dynamic library file is replaced. The FCP main service process does not need to be restarted. The newly forked child process will automatically load the new version of the dynamic library the next time the tool is called. If the new version of the plugin's subprocess malfunctions, it will automatically switch back to the old version of the plugin's scheduling. The running tool subprocesses are not affected by the hot update process.

10. The process-level isolation method for embedded AI tool calls according to claim 1, characterized in that, The verification request in step 2 includes multiple levels: The first layer is message validity verification, which parses the JSON-RPC message format and verifies the integrity of the fields; The second layer is tool existence verification, which searches for a match in the local tool registry based on the tool name; The third layer is tool status verification, which checks whether the target tool is in an idle state; The fourth layer is the input parameter validation, which parses the call parameters and matches them with the input parameter format definitions recorded in the tool's registry.

Images